A gestão de acesso a aplicativos em ambientes corporativos evoluiu. Se antes aceitávamos políticas genéricas de consentimento como padrão, hoje o cenário exige controle refinado e consciente sobre quem pode acessar o quê, e com quais permissões. Este artigo mergulha profundamente na criação e aplicação de políticas de consentimento personalizadas no Microsoft Entra ID, demonstrando como equilibrar segurança, produtividade e governança usando práticas modernas e técnicas avançadas com PowerShell e API.
Todo administrador do Entra ID eventualmente se depara com a seguinte dúvida:
“Devo permitir que meus usuários consintam aplicações por conta própria?”
Permitir consentimento irrestrito pode levar a exposições de dados sensíveis, especialmente quando permissões como Files.Read.All ou Sites.ReadWrite.All estão envolvidas.
Tenha cuidado ao permitir que seus usuários façam a consentimento para tudo!
isso é pessimo!
A Política “Brick Wall” – Consentimento Bloqueado
Se você configurar sua política como “Não permitir consentimento por usuários”, o usuário verá um erro (a “parede de tijolos”) e será instruído a procurar um administrador.
📌 Melhoria: Ativar o Admin Consent Workflow permite que o usuário envie um pedido de consentimento com justificativa, que é recebido pelo(s) administrador(es). isso é bom, bloqueia tudo, e o solicitante vai ter que solicitar analise por parte do administrador (a) do ambiente.
A Política “Goldilocks” – O Equilíbrio Ideal
Permite consentimento de apps de publishers verificados e apenas para permissões classificadas como “low”:
Exemplo de permissões “low”:
openid
profile
User.Read
🧠 Permite adoção de apps confiáveis, mas com segurança baseada em classificação de risco.
Autorize o consentimento de acordo com o nivel de risco e permissão que a aplicação vai ter em seu ambiente! no meu caso, um Lab, coloquei três permissões!
Se o usuário solicitar o consentimento para alguma aplicação que tenha apenas essas permissões, ele consegue de forma automatica.
Há três classificações de permissão: “Baixa”, “Média” (prévia) e “Alta” (prévia). Atualmente, apenas permissões delegadas que não exigem consentimento do administrador podem ser classificadas.
As permissões mínimas necessárias para fazer login básico São openid, profile, emaile offline_access, todas elas delegadas no Microsoft Graph. Com essas permissões, um aplicativo pode ler detalhes do perfil do usuário conectado e manter esse acesso mesmo quando o usuário não estiver mais usando o aplicativo.
Exemplo de Uso
Imagina o seguinte aplicativo com permissão:
A Aplicação solicita “User.read” para redirecionar para a URL das aplicação, que neste caso é Chesley.com.br.
Após autenticar o usuário solicita permissão ao Administrador do Tenant se não houver uma politica de liberação para acesso controlado
Com a politica criada, liberando o acesso “User.read” como exemplo, o usuário consegue acessar a aplicação sem uma autorização.
Obvio, toda permissão MS Graph deve ser analisada com muito cuidado!
Microsoft User Default Recommended (Política Recomendada)
🔄 A partir de julho/2025, todos os tenants que estiverem com a política legada Microsoft-user-default-legacy serão migrados para a nova política recomendada.
🔐 O que muda:
As permissões abaixo deixarão de ser consentíveis por usuários e passarão a exigir aprovação administrativa:
Files.Read.All
Files.ReadWrite.All
Sites.Read.All
Sites.ReadWrite.All
🎯 Objetivo: Reduzir exposição acidental de dados sensíveis do OneDrive, SharePoint e Teams.
Estratégias Avançadas:
Delegar Consentimento: Atribua políticas diferentes para grupos como Segurança, Power Platform ou SharePoint.
Revisão e Governança: Combine com Access Packages e Identity Governance para controle refinado.
Tenant-wide Consent + Group Assignment: Consentimento centralizado com escopo restrito via user assignment required.
Ações Recomendadas Imediatas
Ative o fluxo de Admin Consent se ainda não o fez.
Classifique permissões (low, medium, high) no portal.
Revise os consentimentos existentes e crie políticas personalizadas.
Migre voluntariamente antes de 16 de julho para controlar o impacto.
Monitore regularmente os logs para novas tentativas de consentimento.
Na proxima Postagem vamos estudar sobre o novo modelo de politica de consentimento que será implementado pela Microsoft.
O modelo wide‑open (microsoft-user-default-legacy) deixava o usuário conceder qualquer permissão que não tivesse AdminConsentRequired = true. A política “Microsoft User Default Recommended” bloqueará quatro permissões consideradas perigosas:
Nova exigência de Admin Consent
Motivo
Files.Read.All / Files.ReadWrite.All
Acesso a todo OneDrive da pessoa
Sites.Read.All / Sites.ReadWrite.All
Acesso a todos os sites SharePoint
(Demais permissões não mudam). Resultado: mais solicitações chegam ao administrador. Prepare‑se!
Em nossa proxima postagem vamos explorar essa nova politica a fundo, criar regras, aplicar em grupos, segmentar por acesso!
Permitir ou negar o consentimento de certas permissões
Delegar acesso a grupos com políticas específicas
Controlar o risco de exposição de dados com base no tipo de permissão
Criar regras de aprovação por área ou departamento
Conclusão
O consentimento de aplicativos no Microsoft Entra ID não deve ser tratado com descuido. Nem com medo.
A solução está na governança consciente: ✔️ Políticas personalizadas ✔️ Workflows de aprovação ✔️ Auditoria constante ✔️ Classificação e segmentação por risco
Você não precisa bloquear tudo — precisa entender, classificar e controlar.
Gostou do conteúdo? Compartilhe com seus colegas de segurança, deixe seu comentário abaixo e continue acompanhando nosso blog para mais conteúdos técnicos e práticos sobre o ecossistema Microsoft!
Blog do Chesley 