🔐 Criando uma política de consentimento personalizada do zero usando o PowerShell – Parte 2

A segurança moderna não começa no antivírus, nem na autenticação multifator. Começa na permissão que você dá a uma aplicação para acessar seus dados.

Neste artigo, você vai entender como funcionam as políticas de consentimento no Microsoft Entra ID (antigo Azure AD), como se preparar para a nova política “Microsoft User Default Recommended”, e como aplicar controles personalizados para garantir que somente aplicações seguras sejam aprovadas.

Assim, apenas aquilo que foi aprovado será de fato utilizado, caso o desenvolvedor mude o codigo será necessário uma nova aprovação.

🚨 O Problema: O Consentimento Perigoso

Permitir que os usuários consintam em nome próprio para aplicações pode abrir brechas enormes:

Permissões como Files.Read.All ou Sites.ReadWrite.All permitem que toda a estrutura do SharePoint e OneDrive seja lida ou alterada.
Algumas permissões permitem elevar privilégios até nível de administrador global, como AppRoleAssignment.ReadWrite.All.

Muitos administradores enfrentam dois extremos:

Bloqueiam tudo por medo.
Aprovam tudo por comodidade.

Ambos os caminhos são perigosos.

🔧 Como o Consentimento Funciona?

Políticas de consentimento de aplicativos personalizadas no Microsoft Entra ID (antigo Azure AD) permitem que os administradores controlem quais usuários ou grupos podem conceder permissões a aplicativos — e sob quais condições. Este guia orienta você no processo de criação de uma política de consentimento com escopo, atribuição por meio de uma função personalizada e validação da configuração.

Com o aumento dos riscos de segurança impostos por aplicativos com excesso de permissões, definir políticas de consentimento precisas é essencial. Este tutorial demonstra como criar uma política que permite que apenas usuários específicos aprovem permissões limitadas (por exemplo, Mail.Send) para um aplicativo designado (por exemplo, o aplicativo ChesleyApp). Você também aprenderá a definir o escopo e atribuir a política corretamente usando o Microsoft Graph e o PowerShell.

🧱 Criando sua Politica Personalizada

Nas próximas etapas, você notará que o processo não segue a mesma ordem lógica, mas você começará:

Crie primeiro a política de consentimento personalizada.
Definir o escopo da política para incluir/excluir aplicativos específicos, permissões, etc.
Criando a função personalizada.
Atribuir a função personalizada a um grupo ou usuário que posteriormente consentirá com as permissões.

Pré-requisitos

Antes de prosseguir, certifique-se das seguintes funções e permissões:

Funções necessárias

Administrador com função privilegiada OU
Função de diretório personalizada com permissões para gerenciar políticas de consentimento de aplicativos

Microsoft Graph Permissions

Policy.ReadWrite.PermissionGrant
RoleManagement.ReadWrite.Directory
Group.ReadWrite.All
Application.Read.All

Configurando o Ambiente

Instalar e conectar ao Microsoft Graph:

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes “Policy.ReadWrite.PermissionGrant”, “RoleManagement.ReadWrite.Directory”,”Group.ReadWrite.All”, “Application.Read.All”

Passo a passo: Crie uma política de consentimento personalizada

Etapa 1: preparar IDs de objeto

O Microsoft Graph depende de IDs de Objeto em vez de nomes de exibição. Você precisará dos IDs do aplicativo, da API do Graph e das permissões que deseja conceder.

# Busque o  service principal ID
$ChesleyApp = Get-MgServicePrincipal -Filter "displayName eq 'chesleyapp'"

# Busque as Permissões Microsoft Graph service principal for permission IDs
$GraphApp = Get-MgServicePrincipal -Filter "servicePrincipalNames/any(n:n eq 'https://graph.microsoft.com/')"

# Especifique as permissões permitidas exemplo Mail.Send and User.Read
$MailSendPermission = $GraphApp.Oauth2PermissionScopes | Where-Object {$_.Value -eq "Mail.Send"}
$UserReadPermission = $GraphApp.Oauth2PermissionScopes | Where-Object {$_.Value -eq "User.Read"}

Etapa 2: Crie a Política de Consentimento

Crie um objeto de política de consentimento vazio:

New-MgPolicyPermissionGrantPolicy `
    -Id "chesleyapp-restricted-policy" `
    -DisplayName "Chesleyapp Application Restricted Access Policy" `
    -Description "Política personalizada para restringir o acesso do aplicativo chesleyapp às permissões Mail.Send e User.Read para grupos de usuários específicos"

Etapa 3: definir condições de inclusão

Aqui você define quais aplicativos e permissões a política permitirá. Use os IDs recuperados anteriormente.

Dica : Você pode usar condições de exclusão para bloquear aplicativos ou permissões específicas.

New-MgPolicyPermissionGrantPolicyInclude `
    -PermissionGrantPolicyId "Chesleyapp-restricted-policy" ` 
    -PermissionType "delegated" ` 
    -ResourceApplication $GraphApp.AppId ` #Graph Api Id 
    -Permissions @($MailSendPermission.Id, $UserReadPermission.Id) `# The permissions IDs Step-1. 
    -ClientApplicationIds @($chesleyApp.AppId) # Chesley app ID step_1.

No entanto, você pode restringir o escopo apenas a permissões de baixa classificação ou definir o locatário para permitir apenas aplicativos de um locatário específico ou apenas do seu, etc. Aqui está uma lista dos parâmetros suportados: Gerenciar políticas de consentimento de aplicativos – ID do Microsoft Enterprise | Microsoft Learn

Etapa 4: Crie uma função personalizada com permissões de consentimento

Para permitir que os usuários concedam consentimento sob esta política, crie uma função de diretório personalizada com permissão de escopo.

“microsoft.directory/servicePrincipals/managePermissionGrantsForSelf.{id}“

Onde {id} é substituído pelo ID de uma política de consentimento de aplicativo da etapa 2. Em nosso exemplo aqui, o ID é: chesleyapp-restricted-policy

$params = @{
	description = "Permite que os usuários consintam no aplicativo chesleyapp com permissões restritas"
	displayName = "chesley app Consent Manager"
	rolePermissions = @(
		@{
			allowedResourceActions = @(
            "microsoft.directory/servicePrincipals/managePermissionGrantsForSelf.chesleyapp-restricted-policy"
		)
	}
)
isEnabled = $true
}
New-MgRoleManagementDirectoryRoleDefinition -BodyParameter $params

Etapa 5: Atribuir a função personalizada

Atribua a função a um grupo de usuários autorizados a aprovar o consentimento do aplicativo:

$chesleyGroup = Get-MgGroup -Filter "displayName eq 'security'"

New-MgRoleManagementDirectoryRoleAssignment `
    -RoleDefinitionId $CustomRole.Id `
    -PrincipalId $chesleyGroup.Id `
    -DirectoryScopeId "/"

A atribuição de função pode ser revisada na GUI em Central de administração do Entra > Identidade, funções e administração:
Etapa 6: Validar a configuração

Revise a política:

Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "chesleyapp-restricted-policy" | fl

Verifique as condições de inclusão:

Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "chesleyapp-restricted-policy" | fl

Verifique a função e as permissões:

Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Chesleyapp Application Consent Manager'" | fl

Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Chesleyapp Application Consent Manager'" | Select -ExpandProperty RolePermissions | fl

Etapa 7: Dicas para solução de problemas

Se o consentimento falhar ou os usuários não puderem conceder permissões:

Verifique se os usuários são membros do grupo atribuído.

Revise os logs de entrada no centro de administração do Microsoft Entra para obter códigos de erro e IDs de aplicativo/usuário.

Confirme se o aplicativo Contoso existe e corresponde à política.

Certifique-se de que a função personalizada esteja ativa e atribuída.

Blog do Chesley

Sempre uma novidade!