다음을 통해 공유

사용자가 없는 경우 애플리케이션 ID 자격 증명 제공

  • 아티클

개발자가 비사용자 애플리케이션을 빌드하는 경우 사용자 이름 및 암호 또는 MFA(다단계 인증)를 묻는 메시지를 표시할 수 있는 사용자가 없습니다. 애플리케이션의 ID를 자체적으로 제공해야 합니다. 이 문서에서는 Azure의 서비스(비사용자 애플리케이션)에 가장 적합한 제로 트러스트 클라이언트 자격 증명 사례가 Azure 리소스에 대한 관리 ID인 이유를 설명합니다.

서비스 계정 관련 문제

"서비스 계정"(사용자 계정을 만들고 서비스에 사용)을 사용하는 것은 좋은 솔루션이 아닙니다. Microsoft Entra ID에는 서비스 계정 개념이 없습니다. 관리자가 서비스에 대한 사용자 계정을 만든 다음 개발자와 암호를 공유하는 경우 안전하지 않습니다. 암호가 없거나 MFA를 가질 수 없습니다. 사용자 계정을 서비스 계정으로 사용하는 대신 다음 클라이언트 자격 증명 옵션 중 하나를 사용하는 것이 가장 좋습니다.

클라이언트 자격 증명 옵션

애플리케이션을 식별할 수 있는 네 가지 유형의 클라이언트 자격 증명이 있습니다.

비밀 키 또는 인증서?

엔터프라이즈에 정교한 비밀 관리 인프라(예: Azure Key Vault)가 있는 경우 비밀 키를 사용할 수 있습니다. 그러나 IT 전문가가 비밀 키를 생성한 다음, 스프레드시트와 같은 안전하지 않은 위치에 저장할 수 있는 개발자에게 메일을 보내면 비밀 키가 제대로 보호되지 않는 시나리오의 비밀 키입니다.

인증서 기반 클라이언트 자격 증명은 비밀 키보다 더 안전합니다. 인증서는 비밀 자체가 아니기 때문에 더 잘 관리됩니다. 비밀은 전송의 일부가 아닙니다. 비밀 키를 사용하는 경우 클라이언트는 비밀 키의 실제 값을 Microsoft Entra ID로 보냅니다. 인증서를 사용하는 경우 인증서의 프라이빗 키는 디바이스에서 나가지 않습니다. 누군가가 전송을 가로채고, 디코딩하고, 암호화를 해제하더라도, 가로채기 당사자에 프라이빗 키가 없기 때문에 비밀은 여전히 안전합니다.

모범 사례: Azure 리소스에 대한 관리 ID 사용

Azure에서 서비스(비사용자 애플리케이션)를 개발하는 경우 Azure 리소스용 관리 ID는 Microsoft Entra ID에서 자동으로 관리 ID를 제공합니다. 앱은 자격 증명을 관리하지 않고 Microsoft Entra 인증을 지원하는 모든 서비스에 인증할 수 있습니다. 비밀을 관리할 필요가 없습니다. 손실 또는 잘못 처리의 가능성을 해결할 필요가 없습니다. 비밀은 네트워크를 통해 이동하지 않으므로 가로챌 수 없습니다. Azure에서 서비스를 빌드하는 경우 Azure 리소스에 대한 관리 ID가 가장 좋습니다.

다음 단계