Controlo de Acesso Baseado em Funções para Aplicações no Exchange Online
Este artigo irá orientá-lo ao longo da utilização do controlo de acesso granular e dimensionável no âmbito de recursos: Controlo 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 de Aplicações.
Observação
O serviço de Deteção Automática não pode ser acedido ao utilizar funções de Aplicação RBAC. Se precisar de efetuar pedidos de Deteção Automática no Exchange Online, utilize as permissões do Microsoft Entra ID com a Política de Acesso da Aplicação para limitar o acesso à caixa de correio.
No centro deste sistema está a configuração da atribuição de funções 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. Veja o diagrama abaixo que ilustra o modelo de atribuição de funções:
Instruções de Configuração
Os passos seguintes irão orientá-lo para criar estas atribuições RBAC da Aplicação:
- Criar um novo âmbito de recurso (opcional)
- Criar um ponteiro para um principal de serviço do Microsoft Entra
- Selecione a função de aplicação adequada
- Criar uma nova atribuição de função
- 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 o RBAC do Exchange Online 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 do Microsoft Entra que pode ser um contentor para outros recursos do Microsoft Entra que contenham apenas grupos de utilizadores ou dispositivos. Para saber mais, consulte Unidades administrativas no ID do Microsoft Entra 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.
Observação
Embora exista uma propriedade denominada Unidades Administrativas, recomendamos que utilize o parâmetro Unidades de Administração nativas numa atribuição de função para evitar criar um âmbito como um objeto de ponteiro intermediário.
Entidades de serviço
Os Principais de Serviço representam uma instância de uma aplicação no seu inquilino. 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 as ferramentas do Exchange Online. As ferramentas do Microsoft Entra são utilizadas para gerir registos do Principal de Serviço nos inquilinos. O Exchange impede a criação de um ponteiro inválido e reflete automaticamente quaisquer eliminações de Principais de Serviço no Microsoft Entra ID.
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 irá ajudá-lo a encontrar estes IDs no ID do Microsoft Entra:
Observação
Não utilize os IDs da página Registos de Aplicações, uma vez que mostra valores diferentes. O vermelho descrito "ID da Aplicação" é o AppID e o "ID do Objeto" é o ServiceID.
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.
Observação
Este método exclui as permissões que podem ser concedidas separadamente no ID do Microsoft Entra.
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 resultará 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 funcionários 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 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
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. Ao testar as configurações, o comando de teste ignora esta cache. Uma aplicação sem chamadas de entrada para APIs terá a reposição da cache dentro de 30 minutos, enquanto uma aplicação utilizada ativamente manterá a cache viva até 2 horas.
Protocolos Suportados
- MS Graph
- EWS
Funções de Aplicação Suportadas
Nome | Protocolo | Lista de Permissões | Descrição |
---|---|---|---|
Application Mail.Read | MS Graph | Mail.Read | Permite que a aplicação leia e-mails em todas as caixas de correio sem um utilizador com sessão iniciada. |
Application Mail.ReadBasic | MS Graph | Mail.ReadBasic | Permite que a aplicação leia e-mails exceto o corpo, previewBody, anexos e quaisquer propriedades expandidas em todas as caixas de correio sem um utilizador com sessão iniciada |
Application Mail.ReadWrite | MS Graph | Mail.ReadWrite | Permite que a aplicação crie, leia, atualize e elimine e-mails em todas as caixas de correio sem um utilizador com sessão iniciada. Não inclui permissão para enviar correio. |
Correio da Aplicação.Enviar | MS Graph | Mail.Send | Permite ao aplicativo enviar emails como qualquer usuário sem um usuário conectado. |
Caixa de Correio da AplicaçãoDefinições.Ler | MS Graph | MailboxSettings.Read | Permite que a aplicação leia as definições da caixa de correio do utilizador em todas as caixas de correio sem um utilizador com sessão iniciada. |
Caixa de Correio da AplicaçãoDefinições.ReadWrite | MS Graph | MailboxSettings.ReadWrite | Permite que a aplicação crie, leia, atualize e elimine as definições da caixa de correio do utilizador em todas as caixas de correio sem um utilizador com sessão iniciada. |
Calendários da Aplicação.Ler | MS Graph | Calendars.Read | Permite ao aplicativo ler eventos de todos os calendários sem um usuário conectado. |
Calendários da Aplicação.ReadWrite | MS Graph | Calendars.ReadWrite | Permite ao aplicativo criar, ler, atualizar e excluir eventos de todos os calendários sem um usuário conectado. |
Contactos da Aplicação.Ler | MS Graph | Contacts.Read | Permite ao aplicativo ler todos os contatos em todas as caixas de correio sem um usuário conectado. |
Contactos da Aplicação.ReadWrite | MS Graph | Contacts.ReadWrite | Permite ao aplicativo criar, ler, atualizar e excluir todos os contatos em todas as caixas de correio sem um usuário conectado. |
Acesso Total ao Correio da Aplicação | MS Graph | Mail.ReadWrite, Mail.Send | Permite que a aplicação crie, leia, atualize e elimine e-mails em todas as caixas de correio e envie correio como qualquer utilizador sem um utilizador com sessão iniciada. |
Acesso Total do Exchange de Aplicações | MS Graph | Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite, Calendars.ReadWrite, Contacts.ReadWrite | Sem um utilizador com sessão iniciada: permite que a aplicação crie, leia, atualize e elimine e-mails em todas as caixas de correio e envie correio como qualquer utilizador. Permite que a aplicação crie, leia, atualize e elimine as definições da caixa de correio do utilizador em todas as caixas de correio. Permite que a aplicação crie, leia, atualize e elimine eventos de todos os calendários. Permite que a aplicação crie, leia, atualize e elimine todos os contactos em todas as caixas de correio. |
EWS da aplicação. AccessAsApp | EWS | EWS. AccessAsApp | Permite que a aplicação utilize os Serviços Web exchange com acesso total a todas as caixas de correio. |
Poderá reparar que estas funções representam permissões do Microsoft Graph que pode dar consentimento noutro local na plataforma de Identidade do Azure. Estas permissões terão o mesmo efeito que essas 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 através do RBAC?
Tem de se certificar de que removeu as permissões não selecionadas ao nível do inquilino que atribuiu no Microsoft Entra ID. As permissões atribuídas através do RBAC atuam para além das concessões que efetuar no Microsoft Entra ID. As permissões do Microsoft Entra só podem ser limitadas através das Políticas de Acesso da Aplicação.
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 de aplicações, iremos apresentar estas permissões concedidas no Exchange Online numa experiência de administração do 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 seu mecanismo de âmbito de qualquer forma que funcione bem para si ao utilizar Â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 resultará em qualquer interrupção de utilização para a sua aplicação.
Passos de migração:
- Criar um novo âmbito de gestão, que aponta para o grupo de âmbito da Política de Acesso à Aplicação
- Criar o objeto de ponteiro do principal de serviço
- Atribua as permissões necessárias ao principal de serviço no Exchange Online com a restrição de âmbito de gestão
- Remover o consentimento da permissão no Azure
- Remover a Política de Acesso à Aplicação
Ao criar o âmbito de gestão no passo 1, irá utilizar um filtro de destinatário com o parâmetro MemberOfGroup
de filtro .
Eis um exemplo: "MemberOfGroup -eq 'CN=mesga20220818210551,OU=Fabrikam346.onmicrosoft.com,UO=Microsoft Exchange Hosted Organizations,DC=NAMPR00A001,DC=prod,DC=outlook,DC=com'"
Observação
Este parâmetro de filtro utiliza o nome único do grupo, que pode encontrar com Get-Group cmdlets.
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.
- Os 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 do Microsoft Entra consentidas e atribuições RBAC. Esperamos este caso quando uma aplicação tem o Mail.Read e o Mail.Send no âmbito do inquilino, por exemplo.
Os consentimentos de permissão são aditivos.
Exemplo Um: consentimentos de 2 sistemas
- Uma aplicação tem Mail.Read no 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 tem o Calendar.Read consentido para o Âmbito de Gestão 1 no RBAC para Aplicações
- Caixa de Correio A está no grupo de segurança com capacidade de correio 1
- A caixa de correio B está no âmbito do Âmbito de Gestão 1
O acesso do MS Graph a um ponto final que requer o Mail.Read e o Calendar.Read para a Aplicação 1:
- Filtrar Caixa de Correio A: falha
- Filtrar a 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 no 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 tem o Mail.Read consentido para o Âmbito de Gestão 1 com o RBAC para Aplicações
- Caixa de Correio A está no grupo de segurança com capacidade de correio 1
- 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")
O acesso do MS Graph a um ponto final que requer o Mail.Read para a Aplicação 1:
- Filtrar Caixa de Correio A: permitir
- Filtrar Caixa de Correio B: permitir
Embora o Mail.Read do Microsoft Entra-only permita o acesso à Caixa de Correio A, a atribuição RBAC permite o acesso a tudo, exceto A. Na verdade, isto 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 do inquilino devem ser atribuídas no ID do Microsoft Entra, enquanto as permissões no âmbito do recurso devem ser concedidas através do RBAC para Aplicações.
Quantas aplicações são suportadas pelo RBAC para Aplicações?
Pode ter até 10 000 aplicações por inquilino 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.
Comentários sobre esta funcionalidade
Os comentários sobre esta funcionalidade podem ser partilhados com exoapprbacpreview@microsoft.com.