사용자가 없을 때 애플리케이션 ID 자격 증명 제공

아티클
04/17/2024

개발자가 사용자가 아닌 애플리케이션을 빌드하는 경우 사용자 이름 및 암호 또는 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가 가장 좋습니다.

다음 단계

단일 및 다중 테넌트 앱 에 대해 지원되는 ID 및 계정 유형은 앱이 Microsoft Entra 테넌트, Microsoft Entra 테넌트 또는 개인 Microsoft 계정을 가진 사용자만 허용하는지 여부를 선택하는 방법을 설명합니다.
애플리케이션 권한 전략을 개발하면 자격 증명 관리에 대한 애플리케이션 권한 접근 방식을 결정하는 데 도움이 됩니다.
사용자가 없을 때 애플리케이션 ID 자격 증명을 제공하면 Azure에서 서비스(비 사용자 애플리케이션)에 가장 적합한 제로 트러스트 클라이언트 자격 증명 사례가 Azure 리소스에 대한 관리 ID인 이유를 설명합니다.
권한 부여 모범 사례는 애플리케이션에 대한 최상의 권한 부여, 권한 및 동의 모델을 구현하는 데 도움이 됩니다.
애플리케이션 개발 수명 주기에서 제로 트러스트 ID 및 액세스 관리 개발 모범 사례를 사용하여 보안 애플리케이션을 만듭니다.
id에 대한 제로 트러스트 접근 방식을 사용하여 앱을 빌드하면 사용 권한 및 액세스 모범 사례에 대한 개요를 제공합니다.

Share via