소스 코드에서 API 키를 숨기는 가장 좋은 방법

응용 프로그램, 특히 ac # .NET 응용 프로그램에서 개인 API 키를 보호하는 방법에 대한 아이디어가 필요합니다.

첫째, 소스 코드에 아무것도 숨기는 것이 이론적으로 불가능하다는 것을 이해하므로 다른 아이디어를 생각해 냈지만 그것이 얼마나 타당한 지 잘 모르겠습니다. 어쨌든 웹 서버와 통신하여 개인 키를 확인한 다음 응용 프로그램과 대화하여 합법적 인 핸드 셰이크인지 확인할 수 있습니까?

공개 키 (이름에서 알 수 있듯이 개인 키와 동일하게 취급 할 필요가 없음)와 다른 키로부터 안전하게 보호해야하는 개인 키의 두 가지 키가 있습니다.

내가 어떻게 할 수 있는지에 대한 아이디어는 크게 감사하겠습니다.

요약:

• 공급 업체가 귀하에게 API 키를 발급하여 해당 API를 사용할 수 있으며 다른 사람이이 키를 알지 못하게 할 의무가 있습니다.
• 애플리케이션 코드에서 해당 공급 업체의 API (API 키가 필요한)를 호출합니다.
• 고객이 바이너리에 액세스 할 수있는 시스템에 애플리케이션을 배치하여 코드를 디 컴파일 / 비난 독화하거나 트래픽을 가로 챌 수 있음

이 키의 손상을 방지하는 가장 좋은 방법은 키를 계속 제어하는 ​​것입니다. 즉, 사용자 이외의 다른 사람이 이진을 읽을 수있는 서버에 배포해서는 안되며 제어 할 수없는 통신 링크를 거치지 않아야합니다.

궁극적으로 바이너리가 제어 범위를 벗어나면 모든 바이너리가 제어 범위를 벗어납니다. 마찬가지로 누군가가 트래픽을 가로 챌 수 있으면 API 키를 캡처 할 수 있습니다 ( SSL을 사용하는 경우에도 ).

이를 수행하는 두 가지 기본 방법을 볼 수 있습니다. 두 가지 방법 모두 배포 된 응용 프로그램에 개인 API 키를 포함하지 않습니다.

각 배포마다 고유 한 API 키를 얻습니다.

키를 얻거나 고객이 키를 얻을 수있는 공급 업체와의 추가 관계가 필요합니다.

예를 들어 Google Maps API를 사용하는 제품에서 실제로는 일반적입니다. 소프트웨어 제작자는 사본을 개발 / 실행할 때 사용하는 자체 키를 가지고 있지만 소프트웨어에 소프트웨어를 포함하지 않으며 대신 소프트웨어를 설치 한 사용자가 Google에 가서 자신의 API를 가져와야합니다. 키. 이 소프트웨어에는 Google Maps API 키를 사용하도록 설정하는 구성 옵션 만 있습니다.

실제로, API 키를 계약 적으로 제공하는 많은 공급 업체는 이러한 방식으로 작업을 수행해야하므로 어쨌든 잘못된 경로를 벗어날 수도 있으며 이는 공급 업체의 서비스 약관에 따라 사용할 수있는 유일한 솔루션 일 수 있습니다. 및 / 또는 귀하와 체결 한 법적 계약.

프록시 사용

애플리케이션이 서버에서 API를 호출하는 프록시 API를 설정 한 다음 API는 키를 사용하여 공급 업체의 API를 호출합니다.

애플리케이션에 대해서만 API를 보호하기위한 추가 보호가 필요할 수 있습니다. 이 작업은 다음과 같이 수행 할 수 있습니다.

• 기능을 너무 구체적으로 지정하면 앱에서만 사용할 수 있습니다.
• IP 화이트리스트
• 서버에 대해 이미 가지고있는 일부 기존 라이센스 / 권한 메커니즘
• 고객에게 키를 발급 할 수있는 고유 한 API 키 시스템

여기서 명심해야 할 것은 당신이 이것을 할 수 없다는 것입니다. 공급 업체에 "집계 서비스"또는 프록시를 구축하지 못하게하는 서비스 약관 또는 법적 계약이있을 수 있으므로이를 확인해야합니다.

오작동 처리

키가 손상되지 않더라도 고객 중 하나가 공급 업체가 키를 차단하게하는 작업을 수행하는 경우 갑자기 모든 고객이 비활성화되고 유일한 해결 방법은 다른 모든 사람을 업데이트하는 것입니다.

경우 마찬가지로, 당신은 당신의 고객 중 하나를 차단하려는 당신이 다른 사람에 대한 업데이트를 실행 한 다음 키를 해제하지 않고 그것을 할 수 없습니다 (예를 들면, 그들은 등등, 소프트웨어를 불법 복제 한 지불 중지).

소수의 고객을 넘어서는 무엇이든이를위한 물류는 신속하게 확보 할 수 없게됩니다.

프록시 역할을하는지 또는 각 설치마다 고유 한 키를 사용하든 관계없이 이러한 상황을 비교적 쉽게 처리 할 수 ​​있습니다 (다른 사람에게는 거의 영향을 미치지 않음).

소프트웨어에 키가 포함되어있는 동안 키를 보호하려는 것은 궁극적으로 헛된 노력입니다. 어떤 작업을 수행하든 바이너리, 소스 및 / 또는 통신 채널에 액세스 할 수 있고 키를 확보 할 수있는 충분한 공격자는 그렇게 할 수 있습니다.

따라서 포함시키지 마십시오. "이기는 유일한 방법은 플레이하지 않는 것입니다."

객체 코드에 키가 있으면 정의에 따라 공개됩니다. 객체 코드를 빠르게 디 컴파일하는 난독 화 도구에는 해킹이 있습니다. 개인 키는 객체 코드 외부와 다른 파일에 있습니다. 어려운 부분은이 개인 키를 사용자에게 제공하는 것입니다. 개인 키가 제공되면 파일 끝에 고정 된 개인 키의 서명과 응용 프로그램 내의 공개 키를 사용하여 개인 키의 무결성을 확인할 수 있습니다. 보안 통신 채널이있는 경우 웹 서버에서이 확인을 수행 할 수도 있습니다.