애플리케이션 권한 전략 개발

제로 트러스트 원칙을 사용하여 개발하는 방법을 알아보면 권한 획득을 검토하여 리소스에 액세스하고 위임된 권한 전략을 개발한 후 이 문서를 참조하세요. Microsoft ID 플랫폼 사용하여 애플리케이션을 인증하고 권한을 부여하고 사용 권한 및 동의를 관리할 때 자격 증명 관리에 대한 애플리케이션 권한 접근 방식을 정의합니다.

관련된 사용자가 없는 경우 애플리케이션에 항상 미리 할당된 사용 권한이 부여되므로 유효한 권한 모델이 없습니다.

• 앱은 권한을 요청하는 앱임을 증명합니다. 애플리케이션 은 다음 방법 중 하나를 사용하여 자체 ID 를 증명합니다.

  • 최상의 옵션인 인증서 또는
  • 정교한 비밀 관리 시스템의 비밀 또는
  • Azure에서 서비스를 개발할 때 Azure 리소스에 대한 관리 ID를 사용하고 다음 애플리케이션 자격 증명 관리 섹션을 검토합니다.

• 앱에는 항상 사전 관리자 동의가 필요합니다. 애플리케이션이 범위를 사용하여 이 권한을 요청합니다 .default . 관리자가 애플리케이션에 할당하는 권한을 요청합니다.

• Trans 사용자 기능. 기본적으로 User.ReadWrite.All 애플리케이션은 모든 사용자의 프로필을 업데이트할 수 있습니다. 애플리케이션 권한으로 애플리케이션에서 테넌트에 있는 모든 사용자의 프로필을 읽고 업데이트할 수 있습니다.

• 앱에 부여된 사용 권한은 항상 사용되는 권한입니다. 위임된 권한과 달리 애플리케이션 권한은 특정 사용자가 수행할 수 있는 작업으로 제한되지 않습니다.

애플리케이션 권한 제한

애플리케이션을 전역 액세스보다 작게 제한하는 세 가지 방법이 있습니다.

• Microsoft Teams 앱에는 애플리케이션이 엔터프라이즈의 모든 팀에 액세스하는 대신 특정 팀에 액세스할 수 있는 RSC(리소스별 동의 )가 있습니다. RSC는 앱이 API 엔드포인트를 사용하고 특정 리소스를 관리할 수 있도록 하는 Microsoft Teams 및 Microsoft Graph API 통합입니다. 해당 사용 권한 모델을 사용하면 Teams 및 채팅 소유자가 애플리케이션에서 Teams 및 채팅 데이터에 액세스하고 수정할 수 있도록 동의를 부여할 수 있습니다.

• Microsoft Exchange 관리자는 PowerShell 스크립트를 사용하여 특정 사서함에 대한 앱 액세스를 제한하는 Exchange 애플리케이션 정책을 만들 수 있습니다. 특정 애플리케이션을 사용하거나 Mail.Read 액세스하는 특정 사서함으로 Calendar.Read 제한할 수 있습니다. 예를 들어 하나의 사서함만 읽거나 한 사서함에서만 메일을 보낼 수 있고 엔터프라이즈의 모든 사용자가 메일을 보낼 수 없는 자동화를 빌드할 수 있습니다.

• SharePoint에는 애플리케이션을 사용하여 SharePoint에 액세스하기 위한 세분화된 권한을 허용하는 특정 범위 로 Sites.Selected가 있습니다. Sites.Selected 다른 권한 중 하나 대신 애플리케이션을 선택하면 기본적으로 애플리케이션에서 SharePoint 사이트 모음에 액세스할 수 없습니다. 관리자는 사이트 권한 엔드포인트를 사용하여 애플리케이션에 읽기, 쓰기 또는 읽기 및 쓰기 권한을 부여합니다.

애플리케이션 자격 증명 관리

자격 증명 위생은 애플리케이션이 잠재적 위반으로부터 신속하게 복구되도록 할 수 있습니다. 다음 모범 사례는 가동 중지 시간을 방지하고 합법적인 사용자에게 영향을 주면서 검색 및 수정을 수행하는 애플리케이션을 개발하는 방법을 안내합니다. 이러한 권장 사항은 보안 인시던트에 대응할 준비를 할 때 위반을 가정하는 제로 트러스트 원칙을 지원합니다.

• 코드 및 구성에서 모든 비밀을 제거합니다. Azure 플랫폼을 사용하는 경우 Key Vault에 비밀을 배치하고 Azure 리소스에 대한 관리 ID를 통해 액세스합니다. 손상이 발생할 경우 비밀 회전을 처리하도록 코드를 복원력 있게 만듭니다. IT 관리자는 애플리케이션을 중단하거나 합법적인 사용자에게 영향을 주지 않고 비밀 및 인증서를 제거하고 회전할 수 있습니다.

• 비밀 관리를 위한 보안 프로세스가 없는 한 클라이언트 비밀 대신 인증서를 사용합니다. 공격자는 클라이언트 비밀이 덜 안전하게 처리되는 경향이 있으며 유출된 비밀 사용량을 추적하기 어렵다는 것을 알고 있습니다. 손상된 경우 인증서를 더 잘 관리하고 해지할 수 있습니다. 비밀을 사용하는 경우 보안 노터치 배포 및 롤오버 프로세스를 빌드하거나 사용합니다. 설정된 만료 기간(예: 1년, 2년)에 비밀을 사용하고 만료되지 않도록 합니다.

• 애플리케이션에서 복원력을 구축하기 위해 인증서 및 비밀을 정기적으로 롤오버하고 긴급 롤오버로 인한 중단을 방지합니다.

다음 단계

• 리소스에 액세스하기 위한 권한 부여를 획득하면 애플리케이션에 대한 리소스 액세스 권한을 획득할 때 제로 트러스트 가장 잘 확인하는 방법을 이해하는 데 도움이 됩니다.
• 위임된 권한 전략을 개발하면 애플리케이션에서 사용 권한을 관리하는 최상의 방법을 구현하고 제로 트러스트 원칙을 사용하여 개발하는 데 도움이 됩니다.
• 권한 부여 모범 사례는 애플리케이션에 대한 최상의 권한 부여, 권한 및 동의 모델을 구현하는 데 도움이 됩니다.
• 관리 동의 가 필요한 요청 권한은 애플리케이션 사용 권한에 관리 동의가 필요한 경우 사용 권한 및 동의 환경을 설명합니다.
• API Protection은 등록을 통해 API를 보호하고, 사용 권한 및 동의를 정의하고, 제로 트러스트 목표를 달성하기 위해 액세스를 적용하는 모범 사례를 설명합니다.
• Azure 리소스에 대한 관리 ID가 Azure의 서비스(비사용자 애플리케이션)에 가장 적합한 클라이언트 자격 증명 사례인 이유를 설명하는 사용자가 없는 경우 애플리케이션 ID 자격 증명을 제공합니다.