Controle de Acesso Baseado em Funções para Aplicações no Exchange Online

Este artigo orienta-o ao longo da utilização de um controlo de acesso granular e dimensionável com âmbito de recursos: Controle de Acesso Baseado em Funções (RBAC) para Aplicações no Exchange Online.

Visão Geral

O RBAC para Aplicações no Exchange Online permite que os administradores concedam permissões a uma aplicação que acede de forma independente aos dados no Exchange Online. Esta concessão pode ser emparelhada com um âmbito de acesso (âmbito do recurso) para especificar as caixas de correio a que uma aplicação pode aceder. Esta funcionalidade expande o modelo RBAC atual no Exchange Online e substitui as Políticas de Acesso da Aplicação. Estas concessões de permissão são independentes das concessões não selecionadas no Microsoft Entra ID.

O núcleo deste sistema é a configuração da atribuição de função de gestão, que expressa a intenção de um administrador de permitir que um principal aceda aos dados. Neste caso, permitir que uma aplicação efetue alguma função num conjunto de recursos de destino. Por exemplo, um administrador pode configurar um sistema de reservas de salas com acesso a dados de calendário apenas em regiões específicas através de um Âmbito de Gestão. O diagrama seguinte ilustra o modelo de atribuição de funções:

Instruções de Configuração

Os passos seguintes orientam-no para criar estas atribuições RBAC da Aplicação:

1. Criar um novo âmbito de recurso (opcional)
2. Criar um ponteiro para um principal de serviço Microsoft Entra
3. Selecione a função de aplicação adequada
4. Criar uma nova atribuição de função
5. Testar o novo principal de serviço

Requisitos

O grupo de funções Gestão da Organização tem a atribuição de função delegada para as novas funções RBAC da Aplicação. Tem de ser membro do grupo de funções Gestão da Organização para atribuir estas permissões. Em alternativa, pode utilizar Exchange Online RBAC para conceder atribuições delegadas a estas funções de aplicação conforme entender. No Microsoft Entra ID, precisa da função de Administrador do Exchange para atribuir estas permissões.

Definir Âmbito do Recurso

• Âmbitos de Gestão: Uma entidade do Exchange que representa um conjunto de caixas de correio através de uma expressão de filtro nas propriedades dessas caixas de correio.
• Unidades de Administração: um recurso Microsoft Entra que pode ser um contentor para outros recursos Microsoft Entra que contenham apenas grupos de utilizadores ou dispositivos. Para saber mais, veja Unidades administrativas no Microsoft Entra ID e Criar ou eliminar unidades administrativas.

Âmbitos de Gestão

Os âmbitos de gestão permitem a um administrador definir o âmbito de um conjunto de caixas de correio com base nas propriedades destes objetos. Veja a documentação do Âmbito de Gestão para adicionar, remover, definir. Eis uma lista das propriedades filtráveis num Âmbito de Gestão.

Entidades de serviço

Os Principais de Serviço representam uma instância de uma aplicação na sua organização. Deve considerar o Principal de Serviço no Exchange como um ponteiro para um Principal de Serviço existente no Microsoft Entra ID. Os Principais de Serviço não podem ser criados diretamente com ferramentas de Exchange Online. Microsoft Entra ferramentas são utilizadas para gerir registos do Principal de Serviço nas organizações. O Exchange impede a criação de um ponteiro inválido e reflete quaisquer eliminações de Principais de Serviço no Microsoft Entra ID automaticamente.

Novo Principal de Serviço

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

A captura de ecrã seguinte ajuda-o a encontrar estes IDs no Microsoft Entra ID:

Pode utilizar outra abordagem para localizar estes IDs com Get-MgServicePrincipal.

Remover Principal de Serviço

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

Definir Principal de Serviço

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

Funções de Aplicação

As funções de aplicação são um tipo especial de função de gestão no Exchange Online, que só é atribuível a uma Aplicação. Estas funções podem ser enumeradas com Get-ManagementRole.

Atribuições de Funções

As atribuições de funções de gestão associam um principal, função e âmbito de recurso personalizado de acesso. Esta atribuição funciona como a atribuição de permissões para um principal de serviço que desempenha uma função num âmbito.

Nova Atribuição de Função

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

Definir Atribuição de Função

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

Remover Atribuição de Função

Para remover uma atribuição de função, veja Remover atribuição de gestão.

Autorização de Teste

Um cmdlet de teste pode ser utilizado para simular o comportamento ativado pelas atribuições RBAC para um principal de serviço específico.

Ao testar a autorização, pode incluir um parâmetro de recurso opcional para avaliar que permissões de âmbito se aplicam a essa caixa de correio de destino. InScope will = true or false para representar se, verdadeiro, essa permissão aplica-se a essa caixa de correio para esse principal de serviço ou falso que o principal de serviço tem essa permissão, mas não através dessa caixa de correio específica. Omitir este sinalizador resulta em "Não Executado".

Os resultados dos testes incluem sempre o âmbito de recurso permitido para uma permissão atribuída específica.

Testar o Acesso ao Principal de Serviço

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

Exemplos

Depois de utilizar o Connect-ExchangeOnline no PowerShell, siga estes passos:

Exemplo Um: configurar o acesso de leitura do calendário para utilizadores canadianos com um âmbito de gestão

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 users" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"

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

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

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

Exemplo Dois: Configurar o Mail.Read para todas as caixas de correio da Unidade de Administração Da Europa

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

Exemplo Três: Testar permissões atribuídas a um principal de serviço

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

Limitações

• As aplicações não podem tornar-se membros de um Grupo de Funções.
• As funções de aplicação só podem ser atribuídas a Principais de Serviço.
• As funções de aplicação não podem ser copiadas ou derivadas.
• Os âmbitos de gestão exclusivos não restringem o acesso à aplicação.
• As alterações às permissões da aplicação estão sujeitas a uma manutenção da cache que varia entre 30 minutos e 2 horas, consoante a utilização recente da aplicação. Quando testa configurações, o comando de teste ignora esta cache. A cache de uma aplicação sem chamadas de entrada para APIs é reposta após 30 minutos. A cache de uma aplicação ativa é mantida viva até 2 horas.

Protocolos Suportados

• MS Graph
• EWS

Funções de Aplicação Suportadas

Poderá reparar que estas funções representam permissões do Microsoft Graph que pode consentir noutras partes da plataforma de Identidade do Azure. Estas permissões têm o mesmo efeito que as permissões do Graph, exceto para estas atribuições de funções que permitem o acesso granular ao âmbito do recurso.

Perguntas frequentes

Porque é que a minha aplicação ainda tem acesso a caixas de correio que não são concedidas pelo âmbito que utilizei no RBAC da Aplicação Exchange Online?

Tem de se certificar de que removeu as permissões não selecionadas atribuídas em toda a organização Microsoft Entra ID. As permissões atribuídas através do RBAC da Aplicação atuam para além das concessões que efetuar no Microsoft Entra ID. Microsoft Entra permissões só podem ser limitadas através das Políticas de Acesso da Aplicação. Por outras palavras, as permissões atribuídas são uma operação união nas permissões de Microsoft Entra ID e nas permissões atribuídas no EXCHANGE ONLINE RBAC. Cada autoridade pode agir de forma independente.

Por exemplo, se o Principal de Serviço tiver Mail.Read concedido no Microsoft Entra ID e configurar uma permissão com âmbito Mail.Read de recursos no RBAC da Aplicação, é importante que remova a atribuição de Mail.Read de Microsoft Entra ID. Caso contrário, a união de uma subvenção não âmbitoda Mail.Read de Microsoft Entra e de uma concessão no âmbito do recurso Mail.Read no RBAC da Aplicação não resulta num âmbito de recursos eficaz.

Como posso ver e modificar todas as permissões de aplicação numa única interface?

Para garantir que os administradores têm uma vista consolidada das permissões da aplicação, apresentamos estas permissões concedidas no Exchange Online numa experiência de administrador Microsoft Entra. Esta funcionalidade é futura, mantenha-se atento.

Como migrar das Políticas de Acesso da Aplicação para o RBAC para Aplicações?

Com as Políticas de Acesso à Aplicação, tem um principal de serviço, consentimento de permissões no Azure e uma política associada a um principal de serviço no Exchange Online. Embora possa reestruturar o mecanismo de âmbito com Âmbitos de Gestão do Exchange ou Unidades Administrativas, eis algumas orientações sobre como reutilizar grupos numa Política de Acesso de Aplicações como o âmbito da concessão do RBAC para Aplicações. Este processo não resulta em qualquer interrupção de utilização para a sua aplicação.

Passos de migração:

1. Crie um novo âmbito de gestão, que aponta para o grupo de âmbito da Política de Acesso à Aplicação.

2. Crie o objeto de ponteiro do principal de serviço.

3. Atribua as permissões necessárias ao principal de serviço no Exchange Online com a restrição de âmbito de gestão.

4. Remova o consentimento da permissão no Azure.

5. Remova a Política de Acesso à Aplicação.

   Ao criar o âmbito de gestão no passo 1, utilize um filtro de destinatário com o parâmetro MemberOfGroupde filtro . Veja um exemplo:

   "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"

Limitações:

• Os membros do grupo aninhados são considerados fora do âmbito. Apenas a associação direta a grupos faz com que o membro seja considerado no âmbito da autorização.
• Grupos do Microsoft 365, Mail-Enabled Grupos de Segurança e Listas de Distribuição são suportados.

Como funciona o RBAC para Aplicações juntamente com as Políticas de Acesso da Aplicação?

Compatibilidade com a Política de Acesso de Aplicações:

O RBAC para Aplicações substitui as Políticas de Acesso da Aplicação.

A Interoperabilidade de autorização pode ser descrita da seguinte forma:

• As Políticas de Acesso à Aplicação restringem APENAS as permissões atribuídas no Microsoft Entra ID.

• O RBAC para Aplicações oferece uma expressão alternativa de autorização com um âmbito de recurso associado.

• Uma aplicação pode ter permissões Microsoft Entra e atribuições RBAC consentidas. Esperamos este caso quando uma aplicação tem (por exemplo) toda Mail.Read a organização e âmbito .Mail.Send

• Os consentimentos de permissão são aditivos.

Exemplo Um: consentimentos de 2 sistemas:

• Uma aplicação tem Mail.Read em Microsoft Entra ID.
• Esta aplicação está confinada ao grupo de segurança com capacidade de correio 1 através de uma Política de Acesso à Aplicação.
• A mesma aplicação deu Calendar.Read consentimento para o Âmbito de Gestão 1 no RBAC para Aplicações.
• A Caixa de Correio A está no grupo de segurança 1 com capacidade de correio.
• A caixa de correio B está no âmbito do Âmbito de Gestão 1.

MS Graph access to an endpoint requiring both Mail.Read and Calendar.Read for App 1:

• Filtrar Caixa de Correio A: falha.
• A filtragem da Caixa de Correio B: falha.

Este ponto final precisa de Mail.Read e Calendar.Read. Embora a aplicação tenha estas permissões individualmente em duas caixas de correio separadas, não tem ambas as permissões relativamente a uma caixa de correio.

Exemplo Dois: atribuir a mesma permissão duas vezes:

• Uma aplicação tem Mail.Read em Microsoft Entra ID.
• Esta aplicação está confinada ao grupo de segurança 1 com capacidade de correio através de uma política de Acesso à Aplicação.
• A mesma aplicação deu Mail.Read consentimento para o Âmbito de Gestão 1 com o RBAC para Aplicações.
• A Caixa de Correio A está no grupo de segurança 1 com capacidade de correio.
• O Âmbito de Gestão 1 permite o acesso a todas as caixas de correio, exceto a Caixa de Correio A (de acordo com algum filtro, como Alias -ne mbxa).

ACESSO do MS Graph a um ponto final necessário para a Mail.Read Aplicação 1:

• Filtrar Caixa de Correio A: permitir.
• Filtrar Caixa de Correio B: permitir.

Embora a Mail.Read de Microsoft Entra apenas permita o acesso à Caixa de Correio A, a atribuição RBAC permite o acesso a tudo, exceto A. Com efeito, esta atribuição permite o acesso a tudo porque "A e Não A" significa tudo.

Embora tenhamos delineado estes casos edge para fins de conclusão, não esperamos que as Políticas de Acesso da Aplicação sejam normalmente utilizadas com o RBAC para Aplicações. As permissões ao nível da organização devem ser atribuídas no Microsoft Entra ID enquanto as permissões no âmbito do recurso devem ser concedidas com o RBAC para Aplicações.

Quantas aplicações são suportadas pelo RBAC para Aplicações?

Pode ter até 10 000 aplicações por organização através do RBAC para Aplicações. Informe-nos se este limite lhe causar um problema. Criámos o RBAC para Aplicações de forma altamente dimensionável para acomodar as necessidades dos nossos maiores clientes.

Por que motivo a Deteção Automática não está a funcionar?

Atualmente, o serviço de Deteção Automática não pode ser acedido ao utilizar funções de Aplicação RBAC.

Se eliminar um principal de serviço no Microsoft Entra o que acontece no Exchange?

Os principais de serviço eliminados no Microsoft Entra também são removidos automaticamente no Exchange. Esta remoção elimina todas as atribuições efetuadas a estes principais de serviço, mas deixa os âmbitos de gestão não afetados.

Comentários sobre esta funcionalidade

Os comentários sobre esta funcionalidade podem ser partilhados com exoapprbacpreview@microsoft.com.