다음을 통해 공유


권한 부여 모범 사례

제로 트러스트 원칙을 사용하여 개발하는 방법을 배우면서 이 문서는 권한 부여 획득에서 리소스 액세스, 위임된 권한 전략 개발 및 애플리케이션 권한 전략 개발에서 계속됩니다. 개발자는 애플리케이션에 대한 최상의 권한 부여, 권한 및 동의 모델을 구현하는 데 도움이 됩니다.

액세스 제어가 필요한 애플리케이션 또는 솔루션 내에서 권한 부여 논리를 구현할 수 있습니다. 인증 방법에서 인증된 엔터티에 대한 정보를 사용하는 경우 애플리케이션은 인증 중에 교환되는 정보(예: 보안 토큰 내에서 제공된 정보)를 평가할 수 있습니다. 보안 토큰에 정보가 포함되어 있지 않으면 애플리케이션이 외부 리소스를 호출할 수 있습니다.

애플리케이션 내에 권한 부여 논리를 완전히 포함할 필요는 없습니다. 전용 권한 부여 서비스를 사용하여 권한 부여 구현 및 관리를 중앙 집중화할 수 있습니다.

사용 권한에 대한 모범 사례

Microsoft Entra ID에서 가장 널리 채택된 애플리케이션은 동의 및 권한 부여 모범 사례를 따릅니다. Microsoft Graph 및 Microsoft Graph 권한 참조 작업에 대한 모범 사례를 검토하여 사용 권한 요청을 신중하게 처리하는 방법을 알아봅니다.

  • 최소 권한을 적용 합니다. 필요한 권한만 요청합니다. 증분 동의를 사용하여 적시에 세분화된 권한을 요청합니다. JIT/JEA(Just-In-Time and Just-Enough-Access), 위험 기반 적응 정책 및 데이터 보호를 사용하여 사용자 액세스를 제한합니다.

  • 시나리오에 따라 올바른 사용 권한 유형을 사용합니다. 동일한 앱에서 애플리케이션 및 위임된 권한을 모두 사용하지 않도록 합니다. 로그인한 사용자가 있는 대화형 애플리케이션을 빌드하는 경우 애플리케이션에서 위임된 권한을 사용해야 합니다. 그러나 애플리케이션이 백그라운드 서비스 또는 디먼과 같은 로그인한 사용자 없이 실행되는 경우 애플리케이션은 애플리케이션 권한을 사용해야 합니다.

  • 서비스 약관 및 개인정보처리방침을 제공합니다. 사용자 동의 환경은 사용자가 앱을 신뢰할 수 있다는 것을 알 수 있도록 서비스 약관 및 개인정보처리방침을 사용자에게 표시합니다. 사용자 연결 다중 테넌트 앱에 특히 중요합니다.

사용 권한을 요청하는 경우

일부 권한은 관리자가 테넌트 내에서 동의를 부여해야 합니다. 관리자 동의 엔드포인트를 사용하여 전체 테넌트에 권한을 부여할 수 있습니다. 사용 권한 또는 범위를 요청하기 위해 수행할 수 있는 세 가지 모델이 있습니다.

  • 로그인 또는 첫 번째 액세스 토큰 요청 시 동적 사용자 동의를 구현합니다. 동적 사용자 동의는 앱 등록에 아무 것도 필요하지 않습니다. 특정 조건(예: 처음으로 사용자를 로그인할 때)에서 필요한 범위를 정의할 수 있습니다. 해당 권한을 요청하고 동의를 받은 후에는 사용 권한을 요청할 필요가 없습니다. 그러나 로그인 또는 첫 번째 액세스 시 동적 사용자 동의를 받지 못하면 권한 환경을 통과합니다.

  • 필요에 따라 증분 사용자 동의를 요청합니다. 동적 사용자 동의와 결합된 증분 동의를 사용하면 한 번에 모든 권한을 요청할 필요가 없습니다. 몇 가지 권한을 요청한 다음 사용자가 애플리케이션의 다른 기능으로 이동하면 더 많은 동의를 요청할 수 있습니다. 이 방법은 애플리케이션에 증분 권한을 부여할 때 사용자의 편안함 수준을 높일 수 있습니다. 예를 들어 애플리케이션에서 OneDrive 액세스를 요청하는 경우 일정 액세스도 요청하는 경우 의심이 발생할 수 있습니다. 대신 나중에 OneDrive에 대해 일정 미리 알림을 추가하도록 사용자에게 요청합니다.

  • /.default 범위를 사용합니다. 이 범위는 /.default 애플리케이션 등록에 입력한 내용을 살펴보고 필요한 동의를 파악한 다음 아직 부여되지 않은 모든 동의를 요청한 이전 기본 환경을 효과적으로 모방합니다. 앱 등록에 있으므로 코드에 필요한 권한을 포함할 필요가 없습니다.

확인된 게시자 되기

Microsoft 고객은 때때로 애플리케이션이 사용자에 로그인하거나 API를 호출하여 Microsoft ID 플랫폼 액세스할 수 있도록 허용할 시기를 결정하는 데 어려움을 설명합니다. 제로 트러스트 원칙을 채택하면서 다음을 원합니다.

  • 향상된 표시 유형 및 제어.
  • 보다 사전 예방적이고 보다 쉽게 사후 결정을 내릴 수 있습니다.
  • 데이터를 안전하게 유지하고 의사 결정 부담을 줄이는 시스템입니다.
  • 신뢰할 수 있는 개발자를 위한 앱 채택 가속화
  • 게시자가 확인된 낮은 위험 권한이 있는 앱에 대한 제한된 동의입니다.

Microsoft Graph와 같은 API의 데이터에 액세스하면 풍부한 애플리케이션을 빌드할 수 있지만 조직 또는 고객은 앱의 신뢰성과 함께 앱이 요청하는 권한을 평가합니다.

Microsoft 검증된 게시자가 되면 고객에게 애플리케이션 요청을 더 쉽게 수락할 수 있는 환경을 제공할 수 있습니다. 애플리케이션이 확인된 게시자, 사용자, IT 전문가 및 고객으로부터 제공되는 경우 Microsoft가 비즈니스 관계를 맺고 있는 사람으로부터 온 것임을 알고 있습니다. 게시자의 이름 옆에 파란색 확인 표시가 나타납니다(아래 사용 권한 요청 동의 프롬프트 예제의 구성 요소 #5, Microsoft Entra 애플리케이션 동의 환경의 구성 요소 테이블 참조). 사용자는 동의 프롬프트에서 확인된 게시자를 선택하여 자세한 정보를 볼 수 있습니다.

연결된 Microsoft Entra 애플리케이션 동의 환경 문서에 설명된 대로 요청된 사용 권한 대화 상자의 스크린샷은 구성 요소 구성 요소를 보여줍니다.

확인된 게시자인 경우 사용자와 IT 전문가는 확인된 엔터티이므로 애플리케이션에 대한 신뢰를 얻습니다. 게시자 확인은 애플리케이션에 대한 향상된 브랜딩과 투명성 향상, 위험 감소 및 고객에 대한 원활한 엔터프라이즈 채택을 제공합니다.

다음 단계

  • 위임된 권한 전략을 개발하면 애플리케이션에서 사용 권한을 관리하는 최상의 방법을 구현하고 제로 트러스트 원칙을 사용하여 개발하는 데 도움이 됩니다.
  • 애플리케이션 사용 권한 전략을 개발하면 자격 증명 관리에 대한 애플리케이션 사용 권한 접근 방식을 결정하는 데 도움이 됩니다.
  • 애플리케이션 개발 수명 주기에서 제로 트러스트 ID 및 액세스 관리 개발 모범 사례를 사용하여 보안 애플리케이션을 만듭니다.
  • 애플리케이션 속성 에 대한 보안 모범 사례는 리디렉션 URI, 액세스 토큰, 인증서 및 비밀, 애플리케이션 ID URI 및 애플리케이션 소유권을 설명합니다.
  • 토큰 사용자 지정은 Microsoft Entra 토큰에서 받을 수 있는 정보를 설명합니다. 최소 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 향상시키기 위해 토큰을 사용자 지정하는 방법을 설명합니다.
  • 토큰 에서 그룹 클레임 및 앱 역할을 구성하면 앱 역할 정의를 사용하여 앱을 구성하고 앱 역할에 보안 그룹을 할당하는 방법을 보여 줍니다. 이러한 방법은 최소한의 권한으로 애플리케이션 제로 트러스트 보안을 강화하면서 유연성과 제어를 개선하는 데 도움이 됩니다.
  • API Protection은 등록을 통해 API를 보호하고, 사용 권한 및 동의를 정의하고, 제로 트러스트 목표를 달성하기 위해 액세스를 적용하는 모범 사례를 설명합니다.
  • 리소스에 액세스하기 위한 권한 부여를 획득하면 애플리케이션에 대한 리소스 액세스 권한을 획득할 때 제로 트러스트 가장 잘 확인하는 방법을 이해하는 데 도움이 됩니다.