회사 내에서 내부 API 키를 공유하지 않도록하려면 어떻게해야합니까?

새로운 서비스를 개발 중입니다.이 서비스는 사용자 장치의 응용 프로그램에서 직접 호출 될 수 있습니다. 이러한 응용 프로그램은 우리가 제공하는 데이터에 따라 모든 조직의 여러 개발 팀에서 개발하고 지원합니다.

우리는 어떤 애플리케이션이 어떤 요청을 보내고 있는지 식별하여 사용 패턴과 책임 개발자를 식별 할 수 있도록 노력하고 있습니다. (의심을 피하기 위해 사용자 인증은 별도로 처리됩니다.)

우리의 솔루션은 응용 프로그램 당 하나씩 API 키를 요구하는 것입니다. 개발 팀에 대한 연락처 정보가 있습니다.

API 키를 마찰의 원천으로 삼고 싶지는 않지만 개발자가 다른 팀의 동료와 공유 할 것을 염려합니다. 즉, 더 이상 하나의 애플리케이션에 대한 트래픽을 식별 할 수 없습니다.

내부적으로 API 키를 공유하지 않도록 개발자에게 인센티브를 줄 수있는 방법은 무엇입니까?

팀간에 이러한 키를 공유하려면 팀이 서로 대화하고 공유하기로 동의 한 다음 공유해야합니다. 시간이 걸립니다. 따라서 팀이 더 빠르고 쉽게 API 키를 요청할 수 있다면 공유 할 동기가 없습니다.

그리고 키를 요청하는 가장 쉬운 방법은 키를 선점하는 것입니다. API 키가 필요한 다른 모든 팀을 알고 있다고 가정하면 서비스를 제공하기 전에이를 작성하고 공유하십시오.

디버깅 지원이라는 또 다른 인센티브가 있습니다. 이러한 팀은 업무와 서비스를 통합 할 때 제대로 작동하지 않을 때 도움을 원할 것입니다. 이러한 API 키를 사용하면 특정 요청을 추적 할 수 있으므로 문제를 디버깅하는 데 도움이됩니다. 따라서 " 사용 패턴 및 책임 개발자 식별 "보다는 키의 이유로 판매하십시오 .

좋은 대답은 이미, 나는 당신에게 효과가 있거나 그렇지 않을 수도있는 다른 접근법을 생각했습니다.

포함 할 키를 발행하는 대신 웹 브라우저와 같이 프론트 엔드 애플리케이션의 개발자가 작성 및 형식화하기 위해 프론트 엔드 애플리케이션의 이름을 포함하도록 요청 헤더를 요구할 수 있습니다. 그렇게하면 프런트 엔드는 여전히 다른 응용 프로그램 인 것처럼 가장 할 수 있지만 그렇게하지 않으면 이점이 없을 것 같습니다. 프론트 엔드가 자신을 식별하고 비어 있지 않은 문자열을 수락하도록하십시오.

한마디로 :

첫째 : 촉진과 혜택; 필요한 경우 : 마찰과 경찰.

더 많은 단어

촉진 : 먼저 팀이 새로운 API 키를 쉽게 얻을 수 있도록합니다. 예를 들어, 새 프로젝트를 시작하기위한 회사 절차에 알림을 추가하고 정당성을 요구하지 않고 사용하기 쉬운 서비스를 통해 새 키를 요청하십시오.

이점 : 자체 API 키를 사용하면 팀 또는 제품 소유자에게 도움이됩니다. 예를 들어, 해당 키를 기반으로 한 앱 사용에 대한 피드백을 제안하십시오.

마찰 : 키 기능에 따라 키가 응용 프로그램 정의 도메인에 연결된 경우와 같이 마찰을 일으킬 수 있습니다 (예 : 키를 재사용해도 원하는 모든 서비스에 액세스 할 수있는 것은 아님).

치안 : 마지막으로, 몇 가지 치안 조치를 예견해야 할 수도 있습니다. 예를 들어, api 키로 api 기능 사용을 모니터링하고 지정된 시간이 지난 후 기준선을 고려하지 않은 api 부품의 사용에 대한 질문을하여 기준선을 설정합니다. 또는 이것이 현실적이지 않은 경우, 단순히 기업 프로젝트 검토 체크리스트에 유효한 키가 사용되었다는 확인을 포함 시키십시오.

비고 : API 키 정책에 대해 명확해야 할 수도 있습니다. 새 주요 버전 에는 자체 API 키가 필요합니까? 포크로 무엇입니까, 또는 앱이 분할 된 경우? 다른 팀이 담당하는 경우 등

일반적으로 개발자가 "올바른 일을하도록"하는 가장 쉬운 방법은 개발자가 쉽게 할 수 있도록하는 것입니다.

이를 위해 웹 페이지 / 사이트를 발행하는 API 키를 작성하는 것이 좋습니다. 가장 간단한 형태는 단지 로그인 (기업 AD / LDAP에 연결되어 있음)과 응용 프로그램 이름을 요청하고 키를 발행하는 페이지 일 수 있습니다.

하루가 끝나면 언제든지 키를 취소 할 수 있으므로 사이트에서 실제로 필요한 것은 키를 요청한 사람 (사용자 이름)과 키를 사용하여 수행 할 작업 (응용 프로그램 이름)을 기록하는 것입니다. 나중에 키를 취소하십시오.

티켓팅 시스템과 비슷한 작업을 수행 할 수 있지만 하루가 끝나면 키를 복사하여 하나의 앱에서 다른 앱으로 붙여 넣기가 매우 쉬워 지므로 새 키를 요청하는 것이 매우 쉬워야합니다. 행동.

적극적으로 행동하십시오.

가능성있는 개발자를 식별하고 미리 보안 채널에서 고유 한 API 키를 제공하십시오. 새로운 API 키를 요청하는 쉬운 방법을 제공하십시오. 새로운 사람들이 새로운 API 키를 요청하는 쉬운 수단을 제공하십시오. 새로운 인턴 또는 직원이 팀에 합류 할 때 설명의 단계와 함께 JIRA 티켓 또는 이와 유사한 "API 키 요청"을 제공하십시오.

사용 된 API 키와 사용하지 않은 API 키를 추적하십시오. Bob이 프로젝트에서 티켓을 제출했지만 API 키를 사용하지 않은 경우 다른 사람이 빌린 것일 수 있습니다.

경영진의 지원을 받으십시오. 중요하지 않은 규칙을 만드는 것은 코지 낸시가 아닙니다. 말 그대로 경영진이 중요하다고 확신 한 다음 그룹에게 중요하다고 확신시키는 사람들입니다. 모든 사람을 설득하기 위해 노력하지 마십시오.

그리고 가장 성 가시고 폭정하기 쉬운 제안 : 오용에 대해 알고 당일에 단속하십시오. 같은 시간이 최고입니다. "나쁜 못된 개발자"라고 말하지 말고 "적절한 단계는 다음과 같습니다"라고 말합니다. 반복해서 수행하는 경우 잘못 사용 된 키를 비활성화하십시오. 이것은 주주와 차용 한 사람 모두에게 번거롭고, 나중에 주저는 "아니오, 제대로해라"고 말할 것입니다. 라이브 프로젝트에있는 키를 비활성화하지 마십시오.

내부적으로 API 키를 공유하지 않도록 개발자에게 인센티브를 줄 수있는 방법은 무엇입니까?

• 셀프 서비스 애플리케이션 등록 의 결과로 키를 생성하십시오 .
• 키가 활성화되기 전에 접점이 필요합니다 .
• 그리고 공유하지 요청합니다. (서비스의 약관을 작성 및 / 또는 더 나은 이유를 그들에게 그들을 위해 공유하지.)

rate-limiting 도 구현해야합니다 . 이것은 그 자체로 키 공유를 방해 할 수 있습니다. 그것은 혹독한 응용 프로그램으로부터 시스템을 어느 정도 보호합니다. (그리고 명백한 악의적 인 것들도 있습니다.) 그리고 서비스 가능한 트래픽이 크게 증가하기 전에 약간의 정보를 얻도록 보장합니다. (용량을 추가 할 수있는 시간을주기를 바랍니다.)

또한 속도 제한을 통해 응용 프로그램에 더 높은 제한이 필요한 경우 키에 등록 된 POC가있는 대화 상자가 열립니다. 키를 공유하고 있는지 묻고, 왜 유해한지 설명하고 , 요청 된 속도 제한 변경 대신 적절한 키를 추가로 제공 할 수 있습니다 . 기타.

특히 팀이 공유 빌드 시스템 (또는 적어도 충분히 일반적인 시스템)을 사용하는 경우 작업을 수행하는 한 가지 방법은 API 키를 생성하고 발급하는 내부 서버를 설정하는 것입니다 (사용하는 제품에 대한 몇 가지 기본 정보가 제공됨) ). 그런 다음 각 빌드 또는 버전 업데이트마다 서버에서 새 API 키를 가져 오는 스크립트를 사용하십시오. 개발자가 스크립트를 실행하여 로컬 빌드에 다른 키를 얻도록하십시오. (가능한 경우, 빌드의 일부로 이것을 자동화하여 생각할 필요조차 없습니다.)

이를 통해 프로덕션, QA 또는 개발자 중 어떤 것이 문제 였는지, 그리고 어떤 버전 / 빌드에서 문제가 시작되었는지 알 수 있습니다.

가장 먼저 할 수있는 일은 응용 프로그램 이름을 쉽게 읽을 수있는 형식으로 포함하고 키를 변경해도 작동하지 않도록 키의 형식을 지정하는 것입니다.

팀이 잘못된 키를 사용하는 것이 분명한 경우, 그렇게하지 않기 위해 노력할 것입니다.

그런 다음 주기적으로 키를 만료시킵니다. 어쨌든 이 작업을 수행해야하며 , 키가 만료 될 때 키를 소유 한 팀에 새 키를 보낼 수 있습니다. 그런 다음 키를 사용하는 팀은 키를 소유 한 팀인지 확인하여 만료시 새로운 키를 얻도록 동기를 부여합니다.