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.
Managed policies com descrição oficial, datas, versão e o documento real.
Actions por serviço, com as policies que concedem cada uma.
Onde Service Control Policies e Identity Policies se sobrepõem — e onde nã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.
Tiers de Acesso
Unrestricted access to a service or the entire account — treat as privileged
Broad service access without IAM management capabilities
List and describe resources only — no write or delete actions
Operational tasks: start/stop, deploy, patch — limited create/delete
Narrow-purpose policies for specific use cases or service integrations
Tipos de policy
Criadas e mantidas pela AWS, e atualizadas sozinhas quando entra serviço novo. Bom ponto de partida, quase sempre mais amplas do que a necessidade.
Assumidas por um serviço da AWS (Lambda, ECS, EC2) para que ele alcance outros recursos em seu nome, sem credencial guardada.
Usadas pelo IAM Identity Center para acesso federado em várias contas. Reúnem managed policies num pacote atribuível via SSO.
Policy customer-managed que define o teto de permissão de uma identidade. O efetivo é a interseção com a identity policy — nunca a união.
Permission boundaries — como a avaliação funciona
Uma permission boundary não concede nada por si só: ela define o teto do que a identity policy consegue conceder. A permissão efetiva é a interseção entre as duas, nunca a soma.
Identity Policy
s3:*, ec2:*
Permission Boundary
s3:*, deny iam:*
Efetivo
Sobra s3:* — ec2:* é cortado pela boundary
Ao contrário das managed policies, que têm ARN oficial, boundary é customer-managed: a AWS não publica catálogo nomeado nenhum. Os exemplos catalogados aqui (ver policies de IAM) seguem os padrões documentados no AWS Security Blog e no AWS Prescriptive Guidance para delegação da administração de IAM.
Para o mecanismo equivalente no nível de conta e organização, em vez de por identidade, veja SCP vs Identity Policies.
Categorias por Serviço
Boas práticas
Troque por policies por serviço e use SCP na organização para conter o raio de alcance — a SCP é o que segura escalonamento de privilégio dentro da conta.
Role não tem credencial de longo prazo. Instance profile para EC2, execution role para Lambda e ECS — a credencial nasce e morre com a chamada.
Centralize o acesso multi-conta em permission sets e conecte ao IdP corporativo via SAML ou OIDC. Um lugar para conceder, um lugar para revogar.
A boundary limita o que uma role consegue conceder a terceiros. É o que torna seguro delegar criação de role em ambiente multi-tenant.
Aponta recurso acessível de fora da conta e gera policy de menor privilégio a partir de 90 dias de CloudTrail — permissão que ninguém usou aparece sozinha.
Exija por SCP na organização, não por convenção. Para acesso programático, credencial temporária por STS AssumeRole.
Documentação Oficial
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 |
|---|---|
| AWS IAM — Managed Policies / Service Roles (1.553) | 2026-07-31 |