Exchange Online 애플리케이션에 대한 역할 기반 Access Control

이 문서에서는 Exchange Online 애플리케이션에 대한 RBAC(역할 기반 Access Control)라는 세분화되고 확장 가능한 리소스 범위 액세스 제어를 사용하는 방법에 대해 설명합니다.

개요

Exchange Online 애플리케이션용 RBAC를 사용하면 관리자가 Exchange Online 데이터에 독립적으로 액세스하는 애플리케이션에 권한을 부여할 수 있습니다. 이 권한 부여는 액세스 scope(리소스 scope)와 페어링하여 앱이 액세스할 수 있는 사서함을 지정할 수 있습니다. 이 기능은 Exchange Online 현재 RBAC 모델을 확장하고 애플리케이션 액세스 정책을 대체합니다.

이 시스템의 핵심은 보안 주체가 데이터에 액세스할 수 있도록 허용하려는 관리자의 의도를 나타내는 관리 역할 할당 구성입니다. 이 경우 앱이 대상 리소스 집합에 대해 일부 역할을 수행할 수 있도록 허용합니다. 예를 들어 관리자는 관리 범위를 사용하여 특정 지역의 일정 데이터에만 액세스할 수 있는 객실 예약 시스템을 구성할 수 있습니다. 역할 할당 모델을 보여 주는 아래 다이어그램을 참조하세요.

구성 지침

다음 단계에서는 이러한 애플리케이션 RBAC 할당을 만드는 방법을 안내합니다.

1. 새 리소스 scope 만들기(선택 사항)
2. Microsoft Entra 서비스 주체에 대한 포인터 만들기
3. 적절한 애플리케이션 역할 선택
4. 새 역할 할당 만들기
5. 새 서비스 주체 테스트

요구 사항

조직 관리 역할 그룹에는 새 애플리케이션 RBAC 역할에 대한 위임 역할 할당이 있습니다. 이러한 권한을 할당하려면 조직 관리 역할 그룹의 구성원이어야 합니다. 또는 EXCHANGE ONLINE RBAC를 사용하여 이러한 애플리케이션 역할에 대한 위임 할당을 부여할 수 있습니다. Microsoft Entra ID 이러한 권한을 할당하려면 전역 관리자 또는 Exchange 관리자 역할이 필요합니다.

리소스 범위 정의

• 관리 범위: 해당 사서함의 속성에 대한 필터 식을 사용하여 사서함 집합을 나타내는 Exchange 엔터티 입니다.
• 관리 단위: 사용자 그룹 또는 디바이스만 포함하는 다른 Microsoft Entra 리소스의 컨테이너가 될 수 있는 Microsoft Entra 리소스입니다. 자세한 내용은 Microsoft Entra ID 관리 단위 및 관리 단위 만들기 또는 삭제를 참조하세요.

관리 범위

관리 범위를 사용하면 관리자가 이러한 개체의 속성에 따라 사서함 집합을 scope 수 있습니다. 추가, 제거, 설정은 관리 범위 설명서를 참조하세요. 다음은 관리 범위의 필터링 가능한 속성 목록입니다.

참고

관리 단위라는 속성이 있지만 scope 중간 포인터 개체로 만들지 않도록 역할 할당에 네이티브 관리 Units 매개 변수를 사용하는 것이 좋습니다.

서비스 주체

서비스 주체는 테넌트 내에서 애플리케이션의 instance 나타냅니다. Exchange의 서비스 주체는 Microsoft Entra ID 기존 서비스 주체에 대한 포인터로 간주해야 합니다. 서비스 주체는 Exchange Online 도구를 사용하여 직접 만들 수 없습니다. Microsoft Entra 도구는 테넌트 내에서 서비스 주체 등록을 관리하는 데 사용됩니다. Exchange는 잘못된 포인터를 만들지 못하게 하고 Microsoft Entra ID 서비스 주체의 삭제를 자동으로 반영합니다.

새 서비스 주체

New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>

다음 스크린샷은 Microsoft Entra ID 이러한 ID를 찾는 데 도움이 됩니다.

참고

앱 등록 페이지에서 다른 값을 표시하므로 ID를 사용하지 마세요. 빨간색으로 설명된 "애플리케이션 ID"는 AppID이고 "개체 ID"는 ServiceID입니다.

Get-MgServicePrincipal을 사용하여 이러한 ID를 찾는 다른 방법을 사용할 수 있습니다.

서비스 주체 제거

Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName> 

서비스 주체 설정

Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>

애플리케이션 역할

애플리케이션 역할은 애플리케이션에만 할당할 수 있는 Exchange Online 특별한 유형의 관리 역할입니다. 이러한 역할은 Get-ManagementRole을 사용하여 열거할 수 있습니다.

역할 할당

관리 역할 할당은 액세스 주체, 역할 및 사용자 지정 리소스 scope 함께 연결합니다. 이 할당은 scope 역할을 수행하는 서비스 주체에 대한 권한 할당 역할을 합니다.

새 역할 할당

New-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

역할 할당 설정

Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)

역할 할당 제거

역할 할당을 제거하려면 관리 할당 제거를 참조하세요.

테스트 권한 부여

테스트 cmdlet을 사용하여 특정 서비스 주체에 대한 RBAC 할당에서 사용하도록 설정된 동작을 시뮬레이션할 수 있습니다.

참고

이 메서드는 Microsoft Entra ID 별도로 부여될 수 있는 권한을 제외합니다.

권한 부여를 테스트할 때 선택적 리소스 매개 변수를 포함하여 해당 대상 사서함에 적용되는 범위가 지정된 권한을 평가할 수 있습니다. InScope will = true or false 을 나타내려면 해당 사용 권한이 해당 서비스 주체의 해당 사서함에 적용되거나 해당 서비스 주체에 해당 권한이 있지만 특정 사서함을 초과하지 않는 경우 false입니다. 이 플래그를 생략하면 "실행되지 않음"이 발생합니다.

테스트 결과에는 항상 특정 할당된 권한에 대해 허용되는 리소스 scope 포함됩니다.

테스트 서비스 주체 액세스

Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>

예제

PowerShell에서 Connect-ExchangeOnline 을 사용한 후 다음 단계를 수행합니다.

예제 1: 관리 scope 사용하여 캐나다 직원에 대한 일정 읽기 액세스 구성

New-ServicePrincipal -AppId 71487acd-ec93-476d-bd0e-6c8b31831053 -ObjectId 6233fba6-0198-4277-892f-9275bf728bcc -DisplayName "example"

DisplayName   ObjectId                              AppId
-----------   ---------                              -----
example       6233fba6-0198-4277-892f-9275bf728bcc   71487acd-ec93-476d-bd0e-6c8b3183105

New-ManagementScope -Name "Canadian employees" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

Name                 ScopeRestrictionType      Exclusive      RecipientRoot          RecipientFilter 
----                 --------------------      ---------      -------------          --------------- 
Canadian employees    RecipientScope            False                                CustomAttribute1 -eq '012332'

New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian Employees"

Name                      Role                 RoleAssigneeName       RoleAssigneeType        AssignmentMethod
----                      ----                 ----------------       ----------------        ----------------
Application Calendar...   Application Ca...    6233fba6-0198-...      ServicePrincipal        Direct

예제 2: 모든 유럽 관리 단위 사서함에 대해 Mail.Read 구성

New-ServicePrincipal -AppId eb19847b-5563-42ea-b719-ea47cb0cf4b3 -ObjectId 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -DisplayName "example"

DisplayName    ObjectId                                  AppId
-----------    ---------                                  -----
example        59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36       eb19847b-5563-42ea-b719-ea47cb0cf4b3

New-ManagementRoleAssignment -App 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -Role "Application Mail.Read" -RecipientAdministrativeUnitScope 4d819ce9-9257-44d7-af20-68a49e6697f4

Name                         Role                RoleAssigneeName         RoleAssigneeType             AssignmentMethod
----                         ----                ----------------          ----------------            ----------------
Application Mail.Rea...      Application Ma...   59b7c6cb-58d3-...         ServicePrincipal            Direct

예제 3: 서비스 주체에 할당된 권한 테스트

Test-ServicePrincipalAuthorization -Resource b -Identity "DemoB" | Format-Table

RoleName                      GrantedPermissions          AllowedResourceScope        ScopeType                 InScope 
--------                      ------------------          --------------------        ---------                 ------
Application Mail.Read         Mail.Read                   Scope-MESGaDN                CustomRecipientScope     False 
Application Calendars.Read    Calendars.Read              Scope-DL1                    CustomRecipientScope     False 
Application Contacts.Read     Contacts.Read               Scope-MESGa                  CustomRecipientScope     False 

제한 사항

• 애플리케이션은 역할 그룹의 구성원이 될 수 없습니다.
• 애플리케이션 역할은 서비스 주체에만 할당할 수 있습니다.
• 애플리케이션 역할은 복사하거나 파생할 수 없습니다.
• 단독 관리 범위는 앱 액세스를 제한하지 않습니다.
• 앱 사용 권한에 대한 변경 내용은 앱의 최근 사용량에 따라 30분에서 2시간 사이에 달라지는 캐시 유지 관리의 적용을 받습니다. 구성을 테스트할 때 테스트 명령은 이 캐시를 무시합니다. API에 대한 인바운드 호출이 없는 앱은 30분 안에 캐시를 재설정하는 반면, 적극적으로 사용되는 앱은 캐시를 최대 2시간 동안 유지합니다.

지원되는 프로토콜

• MS 그래프
• EWS

지원되는 애플리케이션 역할

이름	Protocol(프로토콜)	사용 권한 목록	설명
Application Mail.Read	MS 그래프	Mail.Read	앱이 로그인한 사용자 없이 모든 사서함에서 전자 메일을 읽을 수 있도록 허용합니다.
Application Mail.ReadBasic	MS 그래프	Mail.ReadBasic	로그인한 사용자가 없는 모든 사서함의 본문, previewBody, 첨부 파일 및 확장 속성을 제외한 전자 메일을 앱에서 읽을 수 있습니다.
Application Mail.ReadWrite	MS 그래프	Mail.ReadWrite	앱에서 로그인한 사용자 없이 모든 사서함에서 전자 메일을 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다. 메일을 보낼 수 있는 권한이 포함되지 않습니다.
Application Mail.Send	MS 그래프	Mail.Send	앱이 로그인한 사용자 없이 모든 사용자로 메일을 보낼 수 있도록 허용합니다.
Application MailboxSettings.Read	MS 그래프	MailboxSettings.Read	앱이 로그인한 사용자 없이 모든 사서함에서 사용자의 사서함 설정을 읽을 수 있도록 허용합니다.
Application MailboxSettings.ReadWrite	MS 그래프	MailboxSettings.ReadWrite	앱에서 로그인한 사용자 없이 모든 사서함에서 사용자의 사서함 설정을 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다.
Application Calendars.Read	MS 그래프	Calendars.Read	앱에서 로그인한 사용자 없이 모든 일정의 이벤트를 읽을 수 있습니다.
Application Calendars.ReadWrite	MS 그래프	Calendars.ReadWrite	앱에서 로그인한 사용자 없이 모든 일정의 이벤트를 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다.
Application Contacts.Read	MS 그래프	Contacts.Read	앱이 로그인한 사용자 없이 모든 사서함의 모든 연락처를 읽을 수 있도록 허용합니다.
Application Contacts.ReadWrite	MS 그래프	Contacts.ReadWrite	앱에서 로그인한 사용자 없이 모든 사서함의 모든 연락처를 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다.
애플리케이션 메일 전체 액세스	MS 그래프	Mail.ReadWrite, Mail.Send	앱에서 모든 사서함에서 전자 메일을 만들고, 읽고, 업데이트하고, 삭제하고, 로그인한 사용자 없이 모든 사용자로 메일을 보낼 수 있습니다.
Application Exchange 전체 액세스	MS 그래프	Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite, Calendars.ReadWrite, Contacts.ReadWrite	로그인한 사용자 없이: 앱에서 모든 사서함에서 전자 메일을 만들고, 읽고, 업데이트하고, 삭제하고, 모든 사용자로 메일을 보낼 수 있습니다. 앱에서 모든 사서함에서 사용자의 사서함 설정을 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다. 앱에서 모든 일정의 이벤트를 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다. 앱에서 모든 사서함의 모든 연락처를 만들고, 읽고, 업데이트하고, 삭제할 수 있습니다.
애플리케이션 EWS. AccessAsApp	EWS	Ews. AccessAsApp	앱이 모든 사서함에 대한 모든 액세스 권한으로 Exchange Web Services를 사용할 수 있도록 허용합니다.

이러한 역할은 Azure ID 플랫폼의 다른 곳에서 동의할 수 있는 Microsoft Graph 권한을 나타낼 수 있습니다. 이러한 권한은 세분화된 리소스 범위 액세스를 허용하는 이러한 역할 할당을 제외하고 해당 Graph 권한과 동일한 영향을 줍니다.

FAQ

내 애플리케이션에 RBAC를 사용하여 부여되지 않은 사서함에 대한 액세스 권한이 여전히 있는 이유는 무엇인가요?

Microsoft Entra ID 할당한 테넌트 전체 범위 해제 권한을 제거했는지 확인해야 합니다. RBAC를 사용하여 할당된 권한은 Microsoft Entra ID 부여 외에도 작동합니다. Microsoft Entra 권한은 애플리케이션 액세스 정책을 사용하여만 제한할 수 있습니다.

한 인터페이스에서 모든 애플리케이션 권한을 보고 수정하려면 어떻게 해야 하나요?

관리자가 앱 권한에 대한 통합 보기를 갖도록 하기 위해 Microsoft Entra 관리자 환경에서 Exchange Online 부여된 이러한 권한을 표시합니다. 이 기능은 곧 출시될 예정이며, 계속 지켜봐 주시기 바랍니다.

애플리케이션 액세스 정책에서 애플리케이션용 RBAC로 마이그레이션하는 방법

애플리케이션 액세스 정책을 사용하면 서비스 주체, Azure의 권한 동의 및 Exchange Online 서비스 주체와 연결된 정책이 있습니다. Exchange 관리 범위 또는 관리 단위를 사용하여 어떤 방식으로든 잘 작동하는 범위 지정 메커니즘을 재구성할 수 있지만 애플리케이션용 RBAC 권한 부여에 대한 scope 앱 액세스 정책에서 그룹을 다시 사용하는 방법에 대한 몇 가지 지침은 다음과 같습니다. 이 프로세스로 인해 앱에 대한 사용이 중단되지 않습니다.

마이그레이션 단계:

1. 애플리케이션 액세스 정책에서 범위 지정 그룹을 가리키는 새 관리 scope 만듭니다.
2. 서비스 주체 포인터 개체 만들기
3. 관리 scope 제한으로 Exchange Online 서비스 주체에 필요한 권한 할당
4. Azure에서 권한에 대한 동의 제거
5. 애플리케이션 액세스 정책 제거

1단계에서 관리 scope 만들 때는 필터 매개 변수 MemberOfGroup와 함께 받는 사람 필터를 사용합니다. "MemberOfGroup -eq 'CN=mesga2020818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

참고

이 필터 매개 변수는 Get-Group cmdlet을 사용하여 찾을 수 있는 그룹의 고유 이름을 사용합니다.

제한 사항:

• 중첩된 그룹 멤버는 scope 제외된 것으로 간주됩니다. 직접 그룹 멤버 자격만 사용하면 멤버가 권한 부여에 대해 scope 고려됩니다.
• Microsoft 365 그룹, Mail-Enabled 보안 그룹 및 배포 Lists 지원됩니다.

애플리케이션용 RBAC는 애플리케이션 액세스 정책과 함께 어떻게 작동하나요?

앱 액세스 정책과 호환성

애플리케이션용 RBAC는 애플리케이션 액세스 정책을 대체합니다.

권한 부여 상호 운용성은 다음과 같이 설명될 수 있습니다.

• 애플리케이션 액세스 정책은 Microsoft Entra ID 할당된 권한만 제한합니다.

• 애플리케이션용 RBAC는 연결된 리소스 scope 사용하여 권한 부여의 대체 식을 제공합니다.

• 앱에는 Microsoft Entra 동의한 권한과 RBAC 할당이 모두 있을 수 있습니다. 예를 들어 앱에 테넌트 전체 Mail.Read 및 범위가 Mail.Send인 경우를 예상합니다.

• 사용 권한 동의는 가산적입니다.

예제 1: 2개 시스템의 동의

• 앱에 Mail.Read가 Microsoft Entra ID
• 이 앱은 애플리케이션 액세스 정책을 사용하여 메일 사용 보안 그룹 1로 범위가 지정됩니다.
• 동일한 앱에 애플리케이션용 RBAC의 관리 범위 1에 대해 Calendar.Read가 동의했습니다.
• 사서함 A가 메일 사용 가능 보안 그룹 1에 있습니다.
• 사서함 B가 관리 범위 1에 대한 scope 있습니다.

앱 1에 대해 Mail.Read 및 Calendar.Read가 모두 필요한 엔드포인트에 대한 MS Graph 액세스:

• 사서함 A 대상 지정: 실패
• 사서함 B 대상 지정: 실패

이 엔드포인트에는 Mail.Read 및 Calendar.Read가 모두 필요합니다. 앱에는 두 개의 개별 사서함에 대해 개별적으로 이러한 권한이 있지만 하나의 사서함에 대한 두 가지 권한이 모두 없습니다.

예제 2: 동일한 권한을 두 번 할당

• 앱에 Mail.Read가 Microsoft Entra ID
• 이 앱은 애플리케이션 액세스 정책을 사용하여 메일 사용 보안 그룹 1로 범위가 지정됩니다.
• 동일한 앱에 애플리케이션용 RBAC를 사용하여 관리 범위 1에 대해 Mail.Read가 동의했습니다.
• 사서함 A가 메일 사용 가능 보안 그룹 1에 있습니다.
• 관리 범위 1에서는 사서함 A를 제외한 모든 사서함에 액세스할 수 있습니다('별칭 -ne mbxa'와 같은 일부 필터에 따라).

앱 1용 Mail.Read가 필요한 엔드포인트에 대한 MS Graph 액세스:

• 사서함 A 대상 지정: 허용
• 사서함 B 대상 지정: 허용

Microsoft Entra Mail.Read는 사서함 A에 대한 액세스를 허용하지만 RBAC 할당을 통해 A를 제외한 모든 항목에 액세스할 수 있습니다. 실제로 "A 및 Not A"는 모든 것을 의미하기 때문에 모든 항목에 액세스할 수 있습니다.

완전성을 위해 이러한 에지 사례를 간략하게 설명해 왔지만 애플리케이션 액세스 정책이 일반적으로 애플리케이션용 RBAC와 함께 사용될 것으로 기대하지는 않습니다. 애플리케이션용 RBAC를 사용하여 리소스 범위 권한을 부여해야 하는 동안 테넌트 전체 권한을 Microsoft Entra ID 할당해야 합니다.

애플리케이션용 RBAC에서 지원되는 애플리케이션은 몇 개입니까?

애플리케이션용 RBAC를 사용하여 테넌트당 최대 10,000개의 애플리케이션을 가질 수 있습니다. 이 제한으로 문제가 발생할 수 있는지 알려주세요. 가장 큰 고객의 요구를 수용하기 위해 확장성이 뛰어난 방식으로 애플리케이션용 RBAC를 빌드했습니다.

이 기능에 대한 피드백

이 기능에 대한 피드백은 와 exoapprbacpreview@microsoft.com공유할 수 있습니다.