Mail.Send? Ainda causa medo?? Governança de Aplicações no Microsoft 365: RBAC, Managed Identities, Segurança de Dados Sensíveis, Logic App e Azure Functions

Eu uso Identidades Gerenciadas no Azure para vários cenários diferentes de automação, por exemplo, se quero rodar um Logic App ou uma Função Azure que deva chamar uma API com segurança como o Microsoft Graph.

Nesse cenário, a Identidade Gerenciada, representada por seu “Service Principal”, precisa receber permissões de aplicação para a API. Vamos supor, por exemplo, que você queira listar Dispositivos Gerenciados no Intune em sua Organização usando a Microsoft Graph API, usando um Function App ou Logic App, por exemplo, e conectar à API Graph usando uma Identidade Gerenciada.

Depois, você precisaria atribuir a essa Identidade Gerenciada uma atribuição de Função de Aplicativo para a permissão da aplicação no Graph, chamada DeviceManagementManagedDevices.Read.All. Se você usar essa Identidade Gerenciada, por exemplo, em um Function App ou Logic App, eles poderiam então chamar a Microsoft Graph API, como ilustrado abaixo:

Lembre-se que essa logica serve para muitas coisas, inclusive para aquela permissão que assusta meio mundo de administradores e administradoras do M365, “Mail.send”.

Isso mesmo, o Mail .send, uma vez uma identidade gerenciada com essa permissão pode enviar e-mails de todas as caixas de correio do seu locatário. Para limitar isso, precisávamos usar Políticas de Acesso de Aplicativos no Exchange Online para restringir o acesso a caixas de correio específicas. bom, ainda funciona e funciona bem! mas tem algo mais simples e acredite, mais gerenciável.

Poxa, então por que devemos mudar para outro conceito, RBACs, se a Politica de Acesso de Aplicativos ainda funcionam? Bom. a imagem abaixo não é nova.

Essa mudança também foi anunciada no site da Microsoft Tech Community: Aposentadoria da Personificação de Aplicação RBAC no Exchange Online – Microsoft Community Hub

Ou seja, Policitcas de Acesso de Aplicativos, sim, é legado. no link abaixo a @microsoft afirma o mesmo: https://learn.microsoft.com/en-us/exchange/permissions-exo/application-access-policies

NÃO USE LEGADO NO SEU AMBIENTE DE PRODUÇÃO.

Para descobrir rapidamente se seu locatário está usando as políticas de acesso legadas, execute:

Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers

Vasculhando a documentação, descobri que esse ‘novo’ recurso suportava tanto Unidades Administrativas do Entra ID quanto Grupos de Segurança. Deixe-me explicar rapidamente o que essa funcionalidade faz:

O RBAC para Aplicações no Exchange Online permite que administradores concedam permissões a um aplicativo que está acessando dados de forma independente no Exchange Online. No centro desse sistema está a configuração de atribuição de funções, que expressa a intenção do administrador de permitir que um Service Principal ou identidade gerenciada acesse os dados. Nesse caso, permitir que uma identidade gerenciada envie correspondências de caixas de correio específicas.

Entederam a logica?

Uma Atribuição de Função é construída a partir de três partes:

Aplicação: Para quem é essa apólice? Neste caso, a identidade gerenciada.
Função de Candidatura: Quais permissões? Neste caso, Formulário de Solicitação Mail.Send. (Veja todas as permissões suportadas)
Escopo de Recursos: para quais caixas de correio? Neste caso, podemos usar “escopos embutidos” Unidades Administrativas e Grupos de Segurança no Entra ID.

Ok, é isso para a parte teórica. Agora vou mostrar como é feito para deixar mais claro.

Passo 1. Service Principal

Agora, quando digo “Service principal“, estou falando do Service Principal no Exchange Online. Você deve considerar o Service Principal no Exchange Online como um indicador para um Service Principal ou Identidade Gerenciada existente no Microsoft Entra ID. Os Service Principals não podem ser criados diretamente usando o Exchange Online.

Para o propósito desta demonstração, criei uma identidade gerenciada . Você pode usar qualquer identidade gerenciada ou um novo service princial ou existente no Entra ID para começar.

Vamos abrir o PowerShell e conectar ao PowerShell do Exchange Online. Certifique-se de que você tem as permissões corretas. O grupo de funções de Gestão Organizacional tem a atribuição de delegação para as novas funções de Aplicação RBAC. Você precisa ser membro do grupo de funções de Gestão Organizacional para atribuir essas permissões. Alternativamente, você pode usar o Exchange Online RBAC para delegar tarefas para essas vagas de aplicação conforme achar adequado. No Microsoft Entra ID, você precisa dos papéis de Administrador Global ou Administrador do Exchange para atribuir essas permissões.

Para criar o novo Principal de Serviço, você precisará do ID da Aplicação e do ID do Objeto do Entra ID.

Connect-ExchangeOnline

New-ServicePrincipal -AppId f2c4d492-84cd-40ea-bfc8-64fe2305a33e -ObjectId 4127459c-4606-43a0-81b6-8f26b946f55e -DisplayName "Mail.Send"

Passo 2. O Escopo

Agora que definimos o Principal de Serviço (que aponta para nossa identidade gerenciada no Entra ID), podemos focar no escopo dos recursos. Em outras palavras: de quais caixas de correio a identidade gerenciada pode enviar correspondências?

Como dito na introdução, podemos usar tanto grupos de segurança quanto Unidades Administrativas para isso. Então, nesta demonstração, começaremos criando uma nova Unidade de Administração e adicionaremos nosso primeiro usuário a ela.

No Exchange, você pode verificar rapidamente se essa Unidade Administrativa existe executando:

Get-AdministrativeUnit -Identity <id>

Se você não quiser usar Unidades Administrativas ou grupos de Segurança, também pode usar os filtros do Exchange Online para criar um escopo de recursos. Aqui está um exemplo:

New-ManagementScope -Name "CaixaCompartilhada" -RecipientRestrictionFilter "UserPrincipalName -eq 'lester@chesley.com.br' "

Passo 3. A Atribuição de Funções

Agora que temos tanto o Principal de Serviço quanto o Escopo, podemos conectá-los criando uma nova Atribuição de Funções. Você vai precisar do ApplicationID da Identidade Gerenciada e do ObjectID da Unidade Administrativa.

New-ManagementRoleAssignment -App f2c4d492-84cd-40ea-bfc8-64fe2305a33e -Role "Application Mail.Send" -RecipientAdministrativeUnitScope 7da0570e-f768-46de-a0a7-ecb2faf96e69

Para uma visão geral das funções de aplicação suportadas, confira isto: Controle de Acesso Baseado em Funções para Aplicações no Exchange Online | Microsoft Learn

Se você usou os filtros para definir o escopo do recurso, use o parâmetro -CustomResourceScope:

New-ManagementRoleAssignment -App f2c4d492-84cd-40ea-bfc8-64fe2305a33e -Role "Application Mail.Send" -CustomResourceScope "lester@chesley.com.br"

Passo 4. Teste

Com tudo pronto, é hora de testar usando este cmdlet:

Test-ServicePrincipalAuthorization -Identity f2c4d492-84cd-40ea-bfc8-64fe2305a33e -Resource lester@chesley.com.br

Agora vou testar com uma usuário que não está na minha Unidade Administrativa

Test-ServicePrincipalAuthorization -Identity f2c4d492-84cd-40ea-bfc8-64fe2305a33e -Resource chesley.silva@chesley.com.br

Passo 5. Agora envie esse e-mail!

Agora é relativamente fácil enviar e-mails usando a API do Graph.

Vou testar agora com envio com um usuário que não está na unidade administrativa

A melhor melhoria aqui é que a identidade gerenciada não precisa de permissão de aplicação para Graph API no Entra ID, dando acesso a todas as caixas de correio. Em vez disso, fornecemos acesso mais detalhado no Exchange Online, utilizando Unidades Administrativas ou Grupos de Segurança existentes.