Tudo nesta página é calculado no build a partir dos mesmos datasets que alimentam as páginas de detalhe. Nenhum número é escrito à mão, e cada recorte diz de onde vem e o que não cobre.
A classificação de tier e o marcador de privilegiada são editoriais do IAM Scope em cinco das seis plataformas — não são publicados pelos provedores. As bases de contagem não são a mesma coisa entre as clouds: cada seção declara a sua.
As seis lado a lado, pelo Enterprise Access Model
Cada plataforma tem a própria escada de tiers, e elas não se comparam diretamente — "Contributor" no Azure e "Power User" na AWS não querem dizer a mesma coisa. O que compara é a normalização para os três níveis do Enterprise Access Model, que o site já usa em Tier 0 Comparison.
A normalização é nossa e mora em src/lib/eamLevels.ts. Ela agrupa: uma proporção alta de Tier 0 diz que a plataforma concentra poder em poucas roles, não que ela é mais insegura.
Distribuição pelos tiers de cada plataforma
A escada nativa de cada uma, na ordem de severidade. O tier de topo é o único com marcação de risco — a ordem vem da posição na lista e do rótulo, não da cor.
Quantas são privilegiadas
Em número e em proporção do catálogo de cada plataforma. As duas leituras contam histórias diferentes: a proporção responde "quanto do catálogo eu preciso vigiar", o número absoluto responde "quantas páginas isso é".
As permissões concedidas por mais roles
Busca reversa aplicada ao catálogo inteiro: para cada permissão, quantas roles a concedem. É o inverso do que uma página de role mostra, e o que revela onde o acesso se concentra — a permissão do topo de uma lista aparece em quase todo desenho de acesso daquela plataforma.
- microsoft.office365.webPortal/allEntities/standard/read84
- microsoft.office365.supportTickets/allEntities/allTasks56
- microsoft.office365.serviceHealth/allEntities/allTasks52
- microsoft.azure.serviceHealth/allEntities/allTasks48
- microsoft.azure.supportTickets/allEntities/allTasks45
- microsoft.office365.usageReports/allEntities/allProperties/read21
- microsoft.office365.network/performance/allProperties/read19
- microsoft.office365.messageCenter/messages/read18
- microsoft.directory/authorizationPolicy/standard/read17
- microsoft.directory/auditLogs/allProperties/read12
- Microsoft.Authorization/*/readpadrão247
- Microsoft.Resources/subscriptions/resourceGroups/read241
- Microsoft.Resources/deployments/*padrão156
- Microsoft.Insights/alertRules/*padrão152
- Microsoft.Support/*padrão131
- Microsoft.ResourceHealth/availabilityStatuses/read60
- Microsoft.Resources/subscriptions/read53
- Microsoft.Resources/subscriptions/operationresults/read41
- Microsoft.Resources/deployments/read31
- Microsoft.Network/virtualNetworks/read27
- ec2:DescribeSubnets268
- iam:PassRole256
- ec2:DescribeSecurityGroups235
- ec2:DescribeVpcs231
- iam:CreateServiceLinkedRole221
- ec2:CreateTags176
- s3:ListBucket175
- s3:GetObject172
- ec2:DescribeInstances171
- iam:GetRole151
- resourcemanager.projects.get1.535
- resourcemanager.projects.list1.452
- serviceusage.services.get182
- serviceusage.groups.list173
- serviceusage.consumerpolicy.get171
- serviceusage.effectivepolicy.get171
- serviceusage.groups.listMembers171
- serviceusage.values.test171
- serviceusage.consumerpolicy.analyze166
- serviceusage.groups.listExpandedMembers166
A IBM não publica ação por role: as ações são mapeadas por cada serviço, não pelo catálogo de IAM. É a mesma lacuna que mantém a IBM Cloud fora do Permission Scope.
- View organizational units4
- View user profiles and your organizational structure3
- Add, view, edit, and transfer resold customers2
- Privileges can be scoped to all groups, only security groups, or only non-security groups2
- Accept the Terms of Service for a product1
- Access and manage a customer's Admin console, Google Workspace Admin SDK, and support cases1
- Access settings in the Partner Sales Console to view and edit support information1
- Add a security label to a group1
- Add locations1
- ADMIN_APIS_ALL1
O Google publica o mapa de privilégio legível por máquina para 1 das 14 admin roles. O que entra aqui é a lista de capacidades em prosa, que é o que existe para as demais.
Entrada marcada como padrão é um wildcard (Microsoft.Support/*), não uma operação: ela cobre um conjunto de ações, e por isso aparece em mais roles do que qualquer ação literal.
Tamanho de role
Mediana e máximo de permissões por role. A mediana, e não a média: em toda plataforma aqui um punhado de roles gigantes puxaria a média para longe do que uma role típica realmente concede.
Compare estas seis colunas com cuidado — a base de cada uma está declarada ao lado, e três delas contam coisas diferentes.
| Plataforma | Mediana | Máximo | Base |
|---|---|---|---|
| Entra ID | 6 | 254 | Contagem literal: não há wildcard neste dataset. |
| Azure RBAC | ≥ 49 | ≥ 17.591 | Efetivo — wildcards expandidos. É um piso. |
| AWS IAM | 10 | 4.533 | Entradas do documento de policy: "*" conta 1. |
| GCP IAM | 12 | 6.545 | Contagem literal: não há wildcard neste dataset. |
| IBM Cloud | — | — | O provedor não publica permissão por role. |
| Google Workspace | 5 | 13 | Capacidades publicadas pelo provedor, não permissões de API. |
Este número é efetivo: os wildcards da definição foram expandidos contra 17.591 ações de 151 providers, e as NotActions subtraídas. É um piso — o universo vem da documentação da Microsoft, e a Management API expõe mais. Por isso o ≥.
Atenção: aqui o número conta entradas do documento de policy, e um wildcard conta 1. A AdministratorAccess é ["*"] — uma entrada, o account inteiro. 536 das 1.582 policies têm ao menos um padrão, então a mediana e o máximo desta linha são um piso frouxo, não a permissão concedida.
GCP IAM — 21 roles ficaram de fora da conta: o provedor não publica a lista de permissões delas.
Cobertura de SoD por plataforma
Como as regras do catálogo se distribuem. Uma regra que cruza duas plataformas conta nas duas — filtrar por igualdade esconderia justamente as regras de cruzamento, que envolvem as duas pontas.
Nenhuma regra cruza provedores, por decisão de produto: acumular acesso na AWS e no Entra ID é fato de governança, não conflito de segregação — não existe caminho técnico entre os dois e as mitigações não se encontram. Só há cruzamento onde os planos de identidade se tocam.
A cobertura de AWS e GCP é por amostra curada dos tiers privilegiados, não exaustiva — são milhares de policies e roles. Entra ID e Azure RBAC têm cobertura fechada nas privilegiadas.
Fora do catálogo de SoD: IBM Cloud. O IAM da IBM tem sete roles genéricas, e a segregação real dela vive nas permissões da infraestrutura clássica, que não são roles — o modelo "regra = par de roles" não as representa sem distorcer o dado.
Frescor por dataset
Quando cada conjunto de dados foi conferido pela última vez contra a fonte oficial. Aparece por plataforma nas páginas de referência; esta é a lista inteira, que é o que permite ver qual dataset está mais atrasado.