O que existe aqui no site
As páginas desta cloud, com o que cada uma cataloga hoje. As contagens vêm dos datasets, não são escritas à mão.
Números, distribuição por tier e atalhos para as listas filtradas.
Roles de diretório, classificadas pelo Enterprise Access Model.
As actions que compõem as roles, filtráveis por tier.
Permissions do Microsoft Graph, application e delegadas.
Como o Privileged Identity Management muda o risco de uma atribuição.
Ferramentas multi-cloud
Não pertencem a nenhuma cloud e é o que o IAM Scope tem de próprio. Ficam repetidas em todas as referências porque quem chega direto numa página interna não tem outro caminho para descobri-las.
Procura por nome, slug, GUID ou ARN em todas as roles e policies das seis clouds.
Busca reversa: dada uma permission, mostra quem a concede em cada cloud.
Equivalência de função entre as seis plataformas.
Regras de segregação de funções em cinco plataformas, e a matriz de conflito.
Script somente leitura para rodar no seu tenant e medir o risco real.
Cole uma role e veja a cloud detectada e a classificação.
Descreva a tarefa e receba candidatas de menor privilégio.
O que conta como Tier 0 em cada cloud, lado a lado.
Enterprise Access Model (EAM)
O Enterprise Access Model é o framework da Microsoft para classificar o risco de identidades e permissões em Azure e Entra ID. Cada role e cada role action cai em um destes tiers:
Controle total do tenant. Comprometimento leva a takeover completo. Isole de planos inferiores.
Abreviação usada nos badges: Tier 0
Funcoes de gestao de TI enterprise-wide. Alto impacto, mas sem controle total do tenant.
Abreviação usada nos badges: Tier 1
Acesso de usuario e leitura basica. Menor impacto de seguranca.
Abreviação usada nos badges: Tier 2
Sem classificacao de tier definida.
Abreviação usada nos badges: -
O tier de uma role é o tier da sua action mais alta. Uma role com uma única action de Control Plane é Control Plane, ainda que todas as outras sejam User Access — por isso a página da role mostra a composição, e não só o rótulo.
Categorias de role
Cada built-in role recebe uma categoria funcional, para navegação:
| Badge | Descrição |
|---|---|
| Identity | Usuário, grupo, senha, autenticação e a estrutura do diretório |
| Application | Registro de aplicação, service principal e permissão de API |
| Security | Política de segurança, Conditional Access, Identity Protection e auditoria |
| Compliance | Conformidade, proteção de dado, atributo de classificação e Purview |
| Microsoft 365 | Serviços do Microsoft 365: Exchange, SharePoint, Teams, Viva e afins |
| Device | Dispositivo registrado ou integrado ao Entra ID |
| Other | O que não cabe nas categorias funcionais acima |
Role Actions
Role actions — também chamadas de directory permissions ou resource actions — são as permissões atômicas que compõem uma role. Toda action segue o formato:
{namespace}/{resource...}/{verb}O que cada parte significa:
| Parte | Exemplo | Significado |
|---|---|---|
| Namespace | microsoft.directory | O serviço ou recurso raiz, antes da primeira barra |
| Resource | users/password | Os segmentos do meio — o recurso sobre o qual se opera |
| Verb | update | A operação: read, update, delete, allTasks e afins |
A página de Role Actions junta todas as actions únicas e mostra quais roles usam cada uma — é por ali que se descobre o menor privilégio que resolve uma operação específica.
API Permissions (Microsoft Graph)
API permissions são permissões do Microsoft Graph usadas por aplicações registradas no Entra ID. Existem dois tipos:
| Tipo | Badge | Descrição |
|---|---|---|
| Application | AppRole | A aplicação age por conta própria, sem usuário logado. Exige consentimento de administrador, e não há usuário para limitar o alcance — é o tipo de maior impacto. |
| Delegated | Delegated | A aplicação age em nome do usuário logado. O efetivo é a interseção entre o que a app pede e o que aquele usuário já pode fazer. |
O nome segue o padrão Resource.Action.Scope — User.ReadWrite.All indica leitura e escrita sobre todos os usuários.
Custom roles — o que elas não fazem
Custom roles permitem montar perfis granulares, mas não alcançam tudo que uma built-in role alcança. As limitações que costumam surpreender:
Requisitos
- Licença Microsoft Entra ID P1 ou P2 (ou equivalente via Microsoft 365)
- Teto de 5.000 definições de custom role por tenant
- Criação pelo portal do Entra, pelo PowerShell (
New-MgRoleManagementDirectoryRoleDefinition) ou pela API do Microsoft Graph
Permissões disponíveis — um subconjunto
Nem toda role action das built-in roles está aberta para custom role: algumas ficam reservadas às roles nativas da Microsoft.
Para listar o que está disponível no seu tenant, pergunte ao Microsoft Graph:
GET https://graph.microsoft.com/v1.0/roleManagement/directory/resourceNamespaces
# ou via PowerShell:
Get-MgRoleManagementDirectoryResourceNamespace | ForEach-Object {
Get-MgRoleManagementDirectoryResourceNamespaceResourceAction -UnifiedRbacResourceNamespaceId $_.Id
}Limites de escopo de atribuição
- Atribuição no tenant inteiro ou numa Administrative Unit
- Sem escopo por objeto individual — algumas built-in roles têm escopos especiais que custom roles não reproduzem
- Suporte parcial a Eligible assignment no PIM, dependendo da licença
Operações que custom role não cobre
| Tipo | Descrição |
|---|---|
| Permissões em preview | Action marcada como preview pela Microsoft só entra em custom role quando vira GA |
| Permissões cross-service | Permissão que atravessa serviços (Exchange + SharePoint, por exemplo) não é composível em custom role; exige built-in |
| Herança de permissão | Custom role não herda permissão implícita: cada uma precisa ser declarada |
| Controle do próprio tenant | Operações sobre as propriedades do tenant continuam restritas a built-in roles como Global Administrator |
| Permissões de parceiro (CSP) | Partner Tier1/Tier2 Support são reservadas a parceiros Microsoft e não se replicam em custom role |
Ao desenhar uma custom role, use a página de Role Actions deste site para achar o conjunto mínimo — e confirme no endpoint resourceNamespaces que cada action escolhida está de fato disponível, antes de colocá-la na definição.
Fontes de dados
| Fonte | Conteúdo | Atualização |
|---|---|---|
| AzurePrivilegedIAM (EntraOps) | Classificação EAM das roles e role actions | Comunidade (Thomas Naunheim) |
| Microsoft Learn — Permissions Reference | Descrição oficial de cada role e do que ela permite | Microsoft |
| Microsoft Graph Permissions Reference | Documentação das API permissions do Microsoft Graph (Application e Delegated) | Microsoft |
Os dados são atualizados manualmente a partir dos arquivos de classificação do AzurePrivilegedIAM. Para corrigir algo, abra uma issue no repositório do site.
Frescor dos dados
Última verificação de cada conjunto de dados desta plataforma contra a fonte oficial. Veja a página Sobre para o frescor das 6 clouds.
| Conjunto de dados | Última verificação |
|---|---|
| Entra ID — Directory Roles (144) | 2026-06-30 |
| Entra ID — API Permissions do Microsoft Graph (1.504) | 2026-08-04 |