다음을 통해 공유

리소스에 액세스하기 위한 권한 부여 획득

  • 아티클

이 문서는 개발자가 애플리케이션에 대한 리소스 액세스 권한을 획득할 때 제로 트러스트 가장 잘 확인하는 방법을 이해하는 데 도움이 됩니다. 전자 메일 또는 일정 데이터와 같은 보호된 리소스에 액세스하려면 애플리케이션에 리소스 소유자의 권한 부여가 필요합니다. 리소스 소유자는 앱의 요청에 동의하거나 거부할 수 있습니다. 리소스 소유자가 동의를 부여하면 앱이 액세스 토큰을 받습니다. 리소스 소유자가 액세스를 거부할 때 앱이 액세스 토큰을 받지 않습니다.

개념 검토

Microsoft ID 플랫폼 사용하여 애플리케이션을 인증하고 권한을 부여하고 사용 권한 및 동의를 관리할 수 있습니다. 몇 가지 개념부터 살펴보겠습니다.

  • 인증(때로는 AuthN으로 단축됨)은 클레임된 ID가 정확하다는 것을 증명하는 프로세스입니다. Microsoft ID 플랫폼은 OpenID Connect 프로토콜을 사용하여 인증을 처리합니다. 권한 부여(때로는 AuthZ로 단축됨)는 인증된 당사자에게 작업을 수행할 수 있는 권한을 부여합니다. 인증된 당사자가 액세스할 수 있는 데이터를 지정합니다. Microsoft ID 플랫폼 권한 부여를 처리하기 위해 OAuth2.0 프로토콜을 사용합니다. 권한 부여 옵션 에는 ACL(액세스 제어 목록), 역할 기반 액세스 제어 및 ABAC(특성 액세스 제어)가 포함됩니다. 인증은 종종 권한 부여의 요소입니다.

  • 위임된 액세스 (로그인한 사용자를 대신하여 작동) 또는 직접 액세스 (애플리케이션의 고유 ID로만 작동)를 사용하면 애플리케이션이 데이터에 액세스할 수 있습니다. 위임된 액세스에는 위임된 권한(범위라고도 함)이 필요하며, 클라이언트와 사용자는 별도로 요청을 할 수 있는 권한을 부여받아야 합니다. 직접 액세스에는 애플리케이션 권한(앱 역할이라고도 함)이 필요할 수 있습니다. 애플리케이션에 앱 역할이 부여되면 애플리케이션 사용 권한이라고 할 수 있습니다.

  • 위임된 액세스와 함께 사용되는 위임된 권한은 애플리케이션이 사용자를 대신하여 사용자가 액세스할 수 있는 권한에만 액세스할 수 있도록 허용합니다. 직접 액세스와 함께 사용되는 애플리케이션 권한은 애플리케이션이 사용 권한이 연결된 모든 데이터에 액세스할 수 있도록 허용합니다. 서비스 주체의 관리자 및 소유자만 애플리케이션 권한에 동의할 수 있습니다.

  • 동의 는 애플리케이션이 권한을 받는 방식입니다. 사용자 또는 관리자는 보호된 리소스에 액세스하도록 애플리케이션에 권한을 부여합니다. 동의 프롬프트에는 게시자 정보와 함께 애플리케이션에 필요한 사용 권한이 나열됩니다.

  • 사전 인증 은 리소스 애플리케이션 소유자가 클라이언트 앱에 대한 액세스 권한을 부여하는 방식입니다. Azure Portal에서 또는 Microsoft Graph와 같은 PowerShell 및 API를 사용하여 수행할 수 있습니다. 사용자가 사전 인증된 권한 집합에 대한 동의 프롬프트를 볼 필요 없이 리소스 권한을 부여할 수 있습니다.

위임된 권한과 애플리케이션 권한의 차이점

애플리케이션은 사용자가 있는 경우(위임된 권한) 및 사용자(애플리케이션 권한)가 없는 경우의 두 가지 모드로 작동합니다. 애플리케이션 앞에 사용자가 있는 경우 해당 사용자를 대신하여 작업해야 합니다. 애플리케이션 자체를 대신하여 행동해서는 안 됩니다. 사용자가 애플리케이션을 지시하는 경우 해당 사용자의 대리자 역할을 합니다. 토큰이 식별하는 사용자를 대신하여 작업할 수 있는 권한을 얻게 됩니다.

서비스 유형 애플리케이션(백그라운드 작업, 디먼, 서버-서버 프로세스)에는 자신을 식별하거나 암호를 입력할 수 있는 사용자가 없습니다. 서비스 애플리케이션을 대신하여 역할을 수행하려면 애플리케이션 권한이 필요합니다.

제로 트러스트 애플리케이션 권한 부여 모범 사례

권한 부여 방법은 애플리케이션에 있는 사용자와 호출하는 리소스에 연결할 때 구성 요소로 인증됩니다. 애플리케이션이 사용자를 대신하여 작동하는 경우 호출 애플리케이션을 신뢰하지 않아 사용자가 누구인지 알려주거나 애플리케이션에서 사용자가 누구인지 결정하게 합니다. Microsoft Entra ID는 토큰의 사용자에 대한 정보를 확인하고 직접 제공합니다.

애플리케이션이 리소스에 액세스할 수 있도록 애플리케이션이 API를 호출하거나 애플리케이션에 권한을 부여하도록 허용해야 하는 경우 최신 권한 부여 체계는 권한 및 동의 프레임워크를 통해 권한 부여를 요구할 수 있습니다. 리디렉션 URI, 액세스 토큰(암시적 흐름에 사용), 인증서 및 비밀, 애플리케이션 ID URI 및 애플리케이션 소유권을 포함하는 애플리케이션 속성에 대한 참조 보안 모범 사례입니다.

다음 단계

  • 토큰 사용자 지정은 Microsoft Entra 토큰에서 받을 수 있는 정보를 설명합니다. 최소 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 향상시키기 위해 토큰을 사용자 지정하는 방법을 설명합니다.
  • 토큰 에서 그룹 클레임 및 앱 역할을 구성하면 앱 역할 정의를 사용하여 앱을 구성하고 앱 역할에 보안 그룹을 할당하는 방법을 보여 줍니다. 이러한 방법은 최소한의 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 개선하는 데 도움이 됩니다.
  • 위임된 권한 전략을 개발하면 애플리케이션에서 사용 권한을 관리하는 최상의 방법을 구현하고 제로 트러스트 원칙을 사용하여 개발하는 데 도움이 됩니다.
  • 애플리케이션 사용 권한 전략을 개발하면 자격 증명 관리에 대한 애플리케이션 사용 권한 접근 방식을 결정하는 데 도움이 됩니다.
  • Azure 리소스에 대한 관리 ID가 Azure의 서비스(비사용자 애플리케이션)에 가장 적합한 클라이언트 자격 증명 사례인 이유를 설명하는 사용자가 없는 경우 애플리케이션 ID 자격 증명을 제공합니다.
  • 권한 부여 모범 사례는 애플리케이션에 대한 최상의 권한 부여, 권한 및 동의 모델을 구현하는 데 도움이 됩니다.
  • 애플리케이션 개발 수명 주기에서 제로 트러스트 ID 및 액세스 관리 개발 모범 사례를 사용하여 보안 애플리케이션을 만듭니다.
  • id에 대한 제로 트러스트 접근 방식을 사용하는 앱 빌드는 제로 트러스트 ID 및 액세스 관리 개발 모범 사례 문서에서 계속 진행되어 SDLC(소프트웨어 개발 수명 주기)에서 ID에 대한 제로 트러스트 방법을 사용하는 데 도움이 됩니다.