다음을 통해 공유

Microsoft Entra ID로 애플리케이션, 리소스 및 워크로드 권한 부여

  • 아티클

이 문서에서는 개인이 애플리케이션과 상호 작용하고 애플리케이션을 지시할 때, API(애플리케이션 프로그래밍 인터페이스)가 사용자를 위해 작동할 때 권한 부여에 대해 토론합니다. 또한 애플리케이션이나 서비스가 독립적으로 작동하는 경우도 다룹니다. 이는 ISV(독립 소프트웨어 개발자)가 Microsoft Entra ID용 애플리케이션을 빌드하고 최적화하는 방법에 대한 문서 시리즈 중 네 번째입니다. 이 시리즈에서는 다음 항목에 대해 자세히 알아볼 수 있습니다.

애플리케이션의 권한 부여

이 섹션에서는 개인이 애플리케이션과 상호 작용하고 애플리케이션을 지시하는 시나리오를 다룹니다. 리소스(API)의 권한 부여 섹션에서는 사용자가 리소스에 액세스하기 위해 권한 부여가 필요하지만 Microsoft Entra ID가 최종 권한 부여를 수행하지 않는 경우 API가 권한 부여를 수행하는 방법을 설명합니다. 워크로드 권한 부여 섹션에서는 애플리케이션이나 서비스가 독립적으로 작동하는 시나리오를 다룹니다.

애플리케이션은 사용자의 리소스에 액세스해야 할 때 다음 권한 부여가 필요합니다.

  • 애플리케이션에는 현재 사용자의 특정 리소스 내의 특정 작업에 액세스할 수 있는 권한이 있어야 합니다.
  • 사용자는 현재 조건에서 리소스에 액세스할 수 있는 권한이 있어야 합니다.
  • 사용자는 리소스에 액세스할 수 있는 권한이 있어야 합니다.

권한 부여 프로세스는 OAuth 2.0을 사용하여 사용자의 특정 리소스 내의 특정 작업에 액세스하기 위해 Microsoft Entra ID의 액세스 토큰을 요청하는 애플리케이션으로 시작됩니다. 위임된 액세스에서는 앱이 사용자의 대리자 역할을 합니다.

개발자의 경우 리소스는 Microsoft Graph, Azure Storage 또는 자체 API와 같은 API일 수 있습니다. 그러나 대부분의 API에는 읽기, 쓰기 등 다양한 작업이 있습니다. 애플리케이션이 API에서만 읽는 경우 앱에는 읽기 작업에 대한 권한만 부여되어야 합니다. 이 방식은 애플리케이션이 손상되지 않도록 보호하고 개발자가 의도한 것보다 더 많은 액세스를 위해 사용합니다. 개발자는 애플리케이션이 필요한 작업에 대해서만 권한을 부여할 때 최소 권한 원칙을 따릅니다.

애플리케이션에 필요한 특정 API의 특정 작업을 지정하기 위해 개발자는 OAuth 2.0 요청의 범위 매개 변수를 사용합니다. API 디자이너는 API 앱 등록의 일부로 애플리케이션이 요청할 수 있는 범위를 게시합니다. 예를 들어, Microsoft Power BI 서비스 범위에는 다음이 포함됩니다.

Power BI 서비스 범위 작업
https://analysis.windows.net/powerbi/api/Capacity.Read.All 앱은 로그인한 사용자가 액세스할 수 있는 모든 Power BI Premium 및 Power BI Embedded 용량을 볼 수 있습니다.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 앱은 로그인한 사용자가 액세스할 수 있는 모든 Power BI Premium 및 Power BI Embedded 용량을 보고 편집할 수 있습니다.

애플리케이션이 용량만 읽는 경우 앱은 https://analysis.windows.net/powerbi/api/Capacity.Read.All 범위를 요청합니다. 애플리케이션이 용량을 편집하면 앱은 https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 범위를 요청합니다.

범위에는 API의 ID와 작업의 ID가 포함됩니다. https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All 범위에서 API는 https://analysis.windows.net/powerbi/api입니다. 작업은 Capacity.ReadWrite.All입니다. Microsoft Graph API의 광범위한 도달 범위와 인기도를 고려하여 개발자는 범위의 API 구성 요소 없이 Microsoft Graph 범위를 요청할 수 있습니다. 예를 들어, Microsoft Graph는 전체 범위 이름을 사용하는 대신 애플리케이션이 Files.Read를 사용하여 요청할 수 있는 https://graph.microsoft.com/Files.Read 범위를 정의합니다.

첫 번째 권한 부여를 완료하려면 애플리케이션에 현재 사용자의 특정 리소스 내의 특정 작업에 액세스할 수 있는 권한이 있어야 하며, Microsoft Entra ID는 먼저 현재 사용자를 인증해야 합니다. SSO(Single Sign-On)는 이 인증을 충족할 수 있거나 새로운 사용자 상호 작용이 필요할 수 있습니다.

Microsoft Entra ID는 사용자를 확인한 후 해당 사용자가 요청된 범위에 대해 애플리케이션에 권한을 부여했는지 확인합니다. 이 프로세스를 동의 부여라고 합니다. 사용자가 동의한 경우 권한 부여 프로세스가 계속될 수 있습니다. 관리자 동의를 통해 관리 사용자는 자신과 전체 조직에 대해 동의할 수 있습니다. Microsoft Entra ID는 애플리케이션에 범위에 대한 관리자 동의가 있는지 확인합니다. 동의가 부여되면 권한 부여 프로세스가 계속됩니다.

범위 디자인 중에 API 디자이너는 관리자만 동의할 수 있는 범위를 지정할 수 있습니다. 관리자 동의가 필요한 범위는 관리 사용자가 아닌 사용자가 애플리케이션에 부여할 수 있는 권한을 가져서는 안 될 만큼 API 디자이너가 더 중요하고 강력하거나 광범위하게 암시한다고 간주하는 작업을 나타냅니다.

API 디자이너는 관리자 동의가 필요한 범위에 대한 첫 번째 결정권을 갖고 있지만 최종 결정권은 없습니다. API 디자이너가 범위에 관리자 동의가 필요하다고 지정하면 해당 범위에는 항상 관리자 동의가 필요합니다. API 디자이너가 관리자 동의가 필요한 것으로 지정하지 않은 범위의 경우 테넌트 관리자가 관리자 동의를 요구할 수 있음 또는 위험 기반 단계적 동의가 관리자 동의 요구 사항을 결정할 수 있습니다. 개발자는 토큰 요청에 관리자 동의가 필요한지 여부를 예측할 수 없습니다. 그러나 이 제한 사항은 필요한 코드에 영향을 미치지 않습니다. 동의 거부는 토큰 요청이 거부되는 여러 이유 중 하나일 뿐입니다. 애플리케이션은 항상 토큰을 받지 못하는 것을 적절하게 처리해야 합니다.

사용자 또는 관리자가 동의하지 않은 경우 다음 예와 같이 사용자에게 동의 확인 프롬프트가 표시됩니다.

사용자 동의 확인 프롬프트 스크린샷

다음 예에 표시된 것처럼 관리 사용자는 동의 확인 프롬프트를 통해 조직을 대신하여 동의를 선택하여 테넌트의 모든 사용자에게 동의를 부여할 수 있습니다.

관리자 동의 확인 프롬프트 스크린샷.

애플리케이션은 사용자 동의 확인 프롬프트의 타이밍을 제어합니다. Microsoft Entra ID는 정적 동의를 지원합니다. 즉, 애플리케이션이 .default 범위를 사용할 때 앱은 앱 등록에 선언된 모든 권한을 요청합니다. 정적 동의를 통해 앱은 필요할 수 있는 모든 권한을 미리 요청합니다.

정적 동의는 사용자와 관리자가 앱의 액세스 요청을 승인하지 못하게 할 수 있습니다. 동의 요청 프로세스의 가장 좋은 방법은 애플리케이션 시작 시 애플리케이션의 기본 기능에 대해 필요한 권한을 동적으로 요청하고 필요할 경우 더 많은 범위를 요청하는 것입니다. 애플리케이션이 해당 범위가 필요한 작업을 수행함에 따라 더 많은 범위를 요청합니다. 이 방식을 통해 사용자는 기능 타이밍과 관련된 다른 권한을 더 잘 이해할 수 있습니다. 각 API 액세스 토큰에 대해 Microsoft Entra ID에는 요청의 범위뿐만 아니라 이전에 애플리케이션에 부여된 모든 범위가 포함됩니다.

예를 들어, 애플리케이션은 애플리케이션이 시작될 때 사용자를 로그인하고 사용자 프로필에 액세스하도록 https://graph.microsoft.com/user.read를 요청할 수 있습니다. 나중에 사용자가 OneDrive에 저장을 선택하면 애플리케이션이 사용자의 OneDrive에 파일을 쓰도록 https://graph.microsoft.com/files.readwrite를 요청합니다. 사용자는 앱이 OneDrive에 쓰기를 요청하는 이유를 확인하므로 권한을 부여하고 앱은 사용자의 OneDrive에 파일을 저장합니다. 그런 다음 사용자는 앱을 닫습니다. 다음에 앱이 시작되면 https://graph.microsoft.com/user.read를 요청합니다. Microsoft Entra ID는 https://graph.microsoft.com/user.read 및 https://graph.microsoft.com/files.readwrite 범위의 액세스 토큰을 반환합니다. https://graph.microsoft.com/files.readwrite 범위에 대한 토큰 요청에는 사용자가 부여한 동의가 필요하지 않습니다. MSAL(Microsoft 인증 라이브러리)의 토큰 캐싱은 부여된 권한에 따라 캐싱 토큰을 자동으로 처리합니다. 이 예에서 앱을 다시 시작한 후 https://graph.microsoft.com/files.readwrite 범위의 토큰을 얻기 위해 MSAL을 호출하면 https://graph.microsoft.com/user.read 범위에 대한 앱의 초기 요청에서 캐시된 토큰이 반환됩니다. Microsoft Entra ID를 다시 호출하지 않아도 됩니다.

동적 및 증분 동의에는 애플리케이션 등록 중에 선언된 권한이 필요하지 않습니다. 그러나 정적 동의를 지원하기 위해 애플리케이션이 앱 등록 시 필요할 수 있는 모든 권한을 애플리케이션이 선언하는 것이 좋습니다. 관리자는 Microsoft Entra 관리 센터에서 Microsoft Graph PowerShell 또는 Microsoft Graph API를 사용하여 관리자 동의를 부여할 수 있습니다.

애플리케이션에 대한 관리자 동의를 부여하기 위해 Microsoft Entra 관리 센터는 앱에 대한 .default 범위에 대한 동의를 요청하여 정적 동의를 사용합니다. 개발자가 앱 등록에서 선언하지 않은 경우 관리자는 권한이 필요한 앱에 대해 Microsoft Entra 관리 센터에서 관리자 동의를 부여할 수 없습니다.

Microsoft Entra ID 고객은 조건부 액세스 정책을 사용하여 리소스(API) 및 브라우저 기반 애플리케이션을 보호할 수 있습니다. 기본값으로 관리자는 네이티브 앱 인증에 조건부 액세스 정책을 적용할 수 없습니다. 테넌트 관리자는 모든 리소스(이전의 '모든 클라우드 앱')를 대상으로 하거나 사용자 지정 보안 특성을 사용하여 조건부 액세스 정책을 사용하여 네이티브 앱을 대상으로 지정할 수 있습니다. 다른 대상으로 지정된 경우에도 정책 적용에는 Microsoft Graph 또는 Azure AD Graph에 액세스하는 일부 앱이 포함되지 않습니다.

다음 시나리오가 적용되지 않는 한 애플리케이션에는 일반적으로 조건부 액세스에 대한 특수 코드가 필요하지 않습니다.

  • On-Behalf-Of 흐름을 수행하는 앱
  • 여러 서비스 또는 리소스에 액세스하는 앱
  • MSAL.js를 사용하는 단일 페이지 앱
  • 리소스를 호출하는 웹앱

앱이 이러한 시나리오 중 하나를 구현하는 경우 Microsoft Entra 조건부 액세스에 대한 개발자 지침을 검토합니다.

무료 Microsoft Entra ID 테넌트는 조건부 액세스를 활용할 수 없습니다(라이선스 요구 사항 참조). 회사의 프로덕션 테넌트에 필요한 라이선스가 있을 수 있습니다. 테스트를 위해 프로덕션 테넌트를 사용하기 전에 이러한 조건을 평가합니다. 테스트 테넌트 만들기에 대한 지침이 있습니다.

기본적으로 조건부 액세스 정책은 앱이 앱 수준에서 액세스하는 애플리케이션 및 리소스에 적용됩니다. IT 관리자는 개발자의 참여 없이 모든 앱에 앱 수준 정책을 적용할 수 있습니다. 일부 애플리케이션과 시나리오에는 더 세분성이 필요합니다. 예를 들어, 재무 앱은 일반적인 사용을 위해 다단계 인증이 필요할 수 있습니다. 그러나 지정된 금액 이상의 트랜잭션에는 관리 디바이스가 필요할 수 있습니다. 개발자는 IT 관리자가 조건부 액세스 인증 컨텍스트를 구현하여 애플리케이션의 다양한 영역에 단계적 조건부 액세스 정책을 할당할 수 있도록 할 수 있습니다. 조건부 액세스 인증 컨텍스트에 대한 개발자 가이드는 이러한 기능에 대한 좋은 참고 자료입니다.

기본적으로 Microsoft Entra ID는 설정된 시간 동안 유효한 액세스 토큰을 발급합니다. 애플리케이션은 수명 길이를 가정해서는 안 됩니다. Microsoft Entra ID가 액세스 토큰과 함께 반환하는 expires_in 매개 변수를 사용해야 합니다. MSAL은 이 시나리오를 자동으로 처리합니다. 액세스 토큰의 수명 동안 사용자는 권한 부여 당시의 조건에 따라 리소스에 액세스할 수 있는 권한을 갖습니다.

조건이 변경되는 시점과 정책 변경 적용이 발생하는 시점 사이의 지연은 관리자와 사용자에게 문제가 될 수 있습니다. 예를 들어, 사용자가 디바이스를 분실한 경우 IT 관리자는 사용자의 세션을 철회할 수 있습니다. 그러나 분실된 디바이스의 앱은 토큰이 만료될 때까지 사용자를 위해 Microsoft Graph에 계속 액세스할 수 있습니다. Microsoft CAE(지속적인 액세스 권한 평가)는 CAE를 채택한 애플리케이션에 대한 사용자 세션 해지 후 액세스를 방지할 수 있습니다. 애플리케이션이 한 시간에 한 번 이상 Microsoft Graph를 호출하는 경우 CAE를 채택할 수 있습니다. 애플리케이션에서 지속적인 액세스 권한 평가 지원 API를 사용하는 방법에 구현 세부 정보가 나와 있습니다.

MSAL을 기반으로 빌드할 수 없는 경우 앱은 OAuth 2.0을 사용하여 Microsoft Entra ID에서 액세스 토큰을 요청해야 합니다. Microsoft ID 플랫폼 및 OAuth 2.0 인증 코드 흐름은 Microsoft Entra ID가 지원하는 흐름에 대한 구현 세부 정보를 제공합니다.

모바일 디바이스 앱을 빌드하는 경우 모바일 앱의 SSO 및 앱 보호 정책 지원을 검토합니다. 토큰 획득, Intune MAM(모바일 애플리케이션 관리) 및 앱 보호 정책을 지원하는 방법을 알아봅니다.

리소스(API) 권한 부여

애플리케이션 권한 부여 섹션에서는 애플리케이션이 사용자의 리소스에 액세스해야 할 때 필요한 세 가지 권한 부여를 소개했지만 처음 두 가지만 다루었습니다. 사용자가 리소스에 액세스하려면 권한이 있어야 하지만 Microsoft Entra ID는 최종 권한을 수행하지 않습니다. 리소스(API)가 권한 부여를 수행합니다.

API는 사용자를 대신하여 작업할 때 두 가지 권한 부여를 적용해야 합니다.

  • API는 앱이 API를 호출하도록 권한 부여해야 합니다. 액세스 토큰의 scp(범위) 클레임에 필수 범위가 포함되어 있는지 확인합니다.
  • API는 사용자에게 특정 리소스에 액세스할 수 있는 권한을 부여해야 합니다. 토큰의 oid(개체 ID) 및 sub(주제) 클레임은 사용자 ID를 나타냅니다.

권한 부여를 위해 oid 및 sub 클레임을 권장합니다.

Microsoft Entra ID는 쌍별 sub 클레임을 구현하므로 sub 클레임은 클레임하는 앱의 고유 사용자 ID입니다. 다른 앱을 사용하는 동일한 사용자가 다른 sub 클레임을 가지고 있습니다. oid 클레임은 모든 앱의 사용자에 대해 일정합니다.

애플리케이션은 Microsoft Entra ID가 http 요청 인증 헤더에서 보호하는 API에 필수 액세스 토큰을 전달자 토큰으로 제공합니다. 토큰이 Microsoft Entra ID에서 직접 제공되지 않기 때문에 API는 수신된 토큰의 유효성을 완전히 검사해야 합니다. 토큰 유효성 검사가 완료될 때까지 호출 앱을 신뢰할 수 없는 것으로 간주합니다. 액세스 토큰 참조 및 클레임 유효성 검사 참조 문서에서는 Microsoft Entra ID 액세스 토큰 유효성 검사에 대한 세부 정보를 제공합니다.

Microsoft Entra ID는 API가 토큰 서명의 유효성을 검사하는 데 사용하는 공개 키를 게시합니다. 이러한 키는 주기적으로 그리고 상황에 따라 공개 키 롤오버가 필요할 때마다 롤오버됩니다. 애플리케이션은 공개 키 롤오버에 대해 설정된 일정을 가정해서는 안 됩니다. Microsoft ID 플랫폼의 서명 키 롤오버에서는 공개 키 롤오버를 적절하게 처리하는 방법을 설명합니다.

토큰 유효성 검사를 수행하려면 잘 관리된 라이브러리를 사용하는 것이 좋습니다. ASP.NET 또는 ASP.NET Core에서 웹앱이나 API를 빌드하는 경우 Microsoft.Identity.Web을 사용하여 토큰 유효성 검사를 처리합니다. 보호된 웹 API 방법 문서에서는 Microsoft.Identity.Web을 사용하여 API를 보호하는 방법을 설명합니다.

API는 경우에 따라 다른 API를 호출해야 합니다. 앱이 사용자를 위해 작동하면 API는 현재 사용자의 ID가 포함된 위임된 액세스 토큰을 받습니다. API가 현재 사용자의 ID를 확인하려면 Microsoft Entra ID의 유효성 검사된 토큰만 신뢰해야 합니다. 이 방식은 사용자가 다른 사용자를 가장하고 다른 사용자의 리소스에 액세스하는 등의 애플리케이션 손상을 방지합니다. 한 API가 다른 API를 호출할 때 이와 동일한 보호를 위해 On Behalf Of OAuth 흐름을 사용하여 API가 호출된 사용자를 위해 API를 호출하기 위한 액세스 토큰을 얻습니다. 웹 API를 호출하는 웹 API 빌드는 API가 현재 앱 사용자를 위해 다른 API를 호출하는 단계를 제공합니다.

위임된 액세스 외에도 API는 애플리케이션을 지원하고 현재 사용자 없이 독립적으로 작동해야 할 수도 있습니다. Microsoft Entra ID는 이러한 애플리케이션을 워크로드라고 합니다. 워크로드 권한 부여를 적용하기 위해 API는 scp(범위) 클레임을 사용하지 않습니다. 대신 API는 roles 클레임을 사용하여 워크로드에 필요한 동의가 있는지 유효성을 검사합니다. API는 워크로드가 리소스에 액세스할 수 있는 권한을 갖도록 강제 적용하는 역할을 합니다.

워크로드 권한 부여

워크로드는 독립적으로 작동하며 현재 사용자가 없는 애플리케이션입니다. 애플리케이션 권한 부여 섹션에서 설명한 위임된 액세스와 마찬가지로 앱 전용 액세스에는 몇 가지 권한 부여가 필요합니다.

  • 애플리케이션에는 특정 리소스 내의 특정 작업에 액세스할 수 있는 권한이 있어야 합니다.
  • 애플리케이션에는 현재 조건에서 리소스에 액세스할 수 있는 권한이 있어야 합니다.
  • 애플리케이션에는 리소스에 액세스할 수 있는 권한이 있어야 합니다.

프로세스는 .default 범위(예: https://graph.microsoft.com/.default)의 액세스 토큰을 요청하는 워크로드로 시작됩니다. 위임된 액세스(애플리케이션이 동적으로 증분적으로 범위를 요청할 수 있음)와 달리 워크로드는 항상 정적 동의와 .default 범위를 사용해야 합니다.

API 디자이너는 API의 앱 등록에 역할을 추가하여 API에 대한 앱 권한을 만듭니다. 이러한 역할에는 워크로드에 대한 역할 할당을 허용하는 애플리케이션이라는 멤버 형식이 허용됩니다. Microsoft Entra 관리 센터 또는 Microsoft Graph를 사용하여 워크로드에 역할을 할당합니다. Microsoft Entra 관리 센터에서는 워크로드를 실행하기 전에 할당된 역할에 대한 관리자 동의가 필요합니다.

기본적으로 앱 권한은 워크로드에 리소스의 모든 인스턴스에 액세스할 수 있는 권한을 부여합니다. 예를 들어, https://graph.microsoft.com/user.read.all은 테넌트에 있는 모든 사용자의 전체 사용자 프로필에 액세스하도록 워크로드를 권한 부여합니다. IT 관리자는 이러한 광범위한 권한을 부여하는 것을 꺼리는 경우가 많습니다.

Microsoft Graph에 액세스하는 워크로드의 경우 다음 방법을 사용하여 애플리케이션 권한을 제한합니다.

사용자가 있는 애플리케이션과 달리 워크로드는 Microsoft Entra ID로 자신을 인증합니다.

Microsoft Azure에서 실행되는 워크로드의 경우 워크로드 자체를 인증하는 가장 좋은 방법은 Azure 리소스에 대한 관리 ID입니다. 관리 ID 기능을 사용하면 워크로드에 대한 자격 증명을 관리할 필요가 없습니다. 액세스 가능한 자격 증명이 없습니다. Microsoft Entra ID는 자격 증명을 완벽하게 관리합니다. 관리할 자격 증명이 없으므로 자격 증명이 손상될 위험이 없습니다.

보안이 강화되면 관리 ID의 복원력도 높아집니다. 관리 ID는 수명이 긴 액세스 토큰과 Microsoft Entra ID의 정보를 사용하여 토큰이 만료되기 전에 새 토큰을 획득합니다. 관리 ID는 서비스 종속성을 통합하여 지역을 벗어난 오류를 방지하는 데 도움이 되는 지역별 엔드포인트를 사용합니다. 지역 엔드포인트는 지리적 영역에서 트래픽을 유지하는 데 도움이 됩니다. 예를 들어 Azure 리소스는 WestUS2에 있고, 모든 트래픽은 WestUS2에 있습니다.

워크로드가 Microsoft Azure에서 실행되고 있지 않으면 워크로드가 OAuth 2.0 클라이언트 자격 증명 흐름을 통해 자체적으로 인증되어야 합니다.

Microsoft Entra ID는 다음과 같은 클라이언트 자격 증명 유형을 지원합니다.

  • 인증서. 작업 로드는 프라이빗 키로 어설션에 서명하여 프라이빗 키를 소유하고 있음을 입증합니다. 프라이빗 키는 Microsoft Entra ID로 전송되지 않습니다. 어설션만 전송됩니다. 클라이언트 암호 대신 인증서가 더 안전하고 관리가 더 잘되는 인증서를 사용하는 것이 좋습니다.
  • 페더레이션된 자격 증명. 워크로드 ID 페더레이션를 사용하면 Microsoft Azure에서 실행되지 않는 워크로드가 다른 ID 공급자, GitHub Actions 또는 Kubernetes 클러스터의 ID를 사용할 수 있습니다. 페더레이션된 사용자 인증 정보와 인증서 사용자 인증 정보와 동일한 방식으로 워크로드 요청 토큰. 차이점은 서명된 JSON Web Token인 어설션이 페더레이션 ID 공급자에서 나온다는 것입니다.
  • 클라이언트 암호. 애플리케이션 비밀이라고도 불리는 클라이언트 암호는 워크로드가 자신을 식별하는 데 사용할 수 있는 문자열 값입니다. 비밀의 텍스트 값은 토큰에 대한 POST 요청을 통해 워크로드에서 Microsoft Entra ID로 전송됩니다. 클라이언트 암호는 인증서 또는 워크로드 ID 페더레이션보다 보안 수준이 낮습니다. 워크로드에서 비밀 정보를 사용하는 경우 비밀 관리 모범 사례를 따릅니다.

Microsoft Entra 제품군에는 Microsoft Entra ID 외에도 Microsoft Entra Workload ID가 포함되어 있습니다. Microsoft Entra Workload ID에는 워크로드 보안을 강화하기 위한 다음과 같은 프리미엄 기능이 있습니다.

  • 조건부 액세스에서는 워크로드 ID에 대한 위치 또는 위험 기반 정책을 지원합니다.
  • Microsoft Entra ID Protection에서는 손상된 자격 증명, 비정상적인 로그인 및 의심스러운 계정 변경에 대한 보고서를 제공합니다.
  • 액세스 검토를 사용하면 가장 중요한 권한 있는 역할에 포커스를 맞춰 적절한 사람에게 검토 위임을 수행할 수 있습니다.
  • 앱 상태 권장 사항은 애플리케이션 포트폴리오의 ID 예방 조치 간격을 해결하고 테넌트 보안 및 복원력 상태를 개선하는 방법을 제안합니다.

워크로드가 한 시간에 한 번 이상 Microsoft Graph를 호출하는 경우 CAE(지속적인 액세스 권한 평가)를 지원할 수 있습니다. CAE를 지원하려면 워크로드가 단일 테넌트 애플리케이션이어야 하며 앱이 Microsoft Graph에 액세스하는 테넌트에 등록되어 있어야 합니다. 워크로드가 이러한 요구 사항을 충족하는 경우 구현 단계는 이 샘플을 참조하세요.

다음 단계