AWS vs GCP vs Azure: hierarquia da organização, IAM e gerenciamento de chaves, lado a lado

Se você já conhece o modelo de governança de uma nuvem, você conhece 80% das outras duas — os conceitos são idênticos e apenas o vocabulário muda. Toda nuvem faz você responder às mesmas três perguntas antes de lançar qualquer coisa real: como eu organizo minhas contas, quem tem permissão para fazer o quê e como minhas chaves de criptografia são criadas e controladas? Este post mapeia AWS, Google Cloud e Azure umas nas outras, camada por camada, e aponta os quatro pontos onde a analogia silenciosamente se quebra.

Essas quatro camadas — hierarquia, guardrails, identidade e gerenciamento de chaves — são também a espinha dorsal de todo exame de arquitetura e segurança em nuvem. Assim, a mesma leitura que economiza uma semana de confusão entre nuvens constitui grande parte do conteúdo para uma certificação. As certificações para aprofundar cada camada estão linkadas no final.

Os três problemas que toda nuvem resolve

Deixando de lado o marketing, toda discussão sobre governança se resume a três camadas empilhadas uma sobre a outra:

• Estrutura — um conjunto aninhado de contêineres (organização → agrupamento → limite de workload) para que você possa isolar ambientes, aplicar guardrails e dividir a fatura.
• Identidade e permissões — quais principals podem realizar quais ações em quais recursos, além do teto que limita o que qualquer concessão pode distribuir.
• Gerenciamento de chaves — onde as chaves criptográficas vivem, quem pode usá-las e quem pode administrá-las — duas perguntas diferentes que as pessoas constantemente confundem.

A maioria dos engenheiros consegue listar as peças da nuvem que melhor conhece. A parte difícil é a visão completa: as camadas que são fáceis de esquecer e como cada peça se traduz para as outras duas nuvens.

Camada 1 — a hierarquia de recursos

Cada nuvem tem um organization node de nível superior, uma camada intermediária de agrupamento opcional que você aninha para departamentos ou ambientes, e um limite de workload que também serve como unidade de cobrança e blast radius. As políticas definidas no nível superior fluem para baixo em todas as três.

• Raiz da organização — AWS: uma Organization com uma management account. GCP: o organization node. Azure: o management group raiz do tenant, apoiado por um tenant do Microsoft Entra.
• Contêiner de agrupamento (aninhável) — AWS: Organizational Unit (OU). GCP: folder. Azure: management group.
• Limite de workload e cobrança — AWS: account. GCP: project. Azure: subscription.
• Agrupamento de recursos dentro do limite — AWS: nenhum (tags, ou por account). GCP: nenhum — o project é o contêiner. Azure: o resource group, que é obrigatório; todo recurso vive em exatamente um.

A primeira divergência real se esconde aqui. Na AWS, a account é uma parede sólida — a unidade padrão de blast radius — razão pela qual ambientes AWS maduros executam dezenas ou centenas de accounts. No GCP, o project faz dois trabalhos ao mesmo tempo: é tanto a unidade de agrupamento quanto a unidade de cobrança/isolamento, então não há um conceito separado de "resource group". O Azure adiciona um quarto nível que os outros não têm — o resource group — posicionado abaixo da subscription como um contêiner de ciclo de vida que você implanta e desativa como uma unidade.

Camada 2 — guardrails preventivos (o teto de permissões)

Antes de conceder qualquer coisa a alguém, cada nuvem permite que você defina um limite superior sobre quais permissões podem existir abaixo de um nó — um teto que nenhuma concessão individual pode ultrapassar. Isso não é o mesmo que conceder acesso; é a camada "você nunca poderá, em toda a organização".

• Limite do que os principals podem fazer — AWS: Service Control Policy (SCP). GCP: restrições de Organization Policy mais IAM deny policies. Azure: Azure Policy.
• Limite de quem pode tocar um recurso — AWS: Resource Control Policy (RCP). GCP: políticas de permissão/negação de IAM no recurso. Azure: Azure Policy mais deny assignments.
• Impor a configuração do serviço — AWS: declarative policies. GCP: restrições de Organization Policy. Azure: Azure Policy (deny / audit / deployIfNotExists).

A AWS dividiu essa tarefa em duas. As SCPs são centradas no principal ("nossas pessoas não podem fazer X") e as RCPs mais recentes são centradas no recurso ("ninguém — nem mesmo uma account externa — pode tocar neste bucket S3, KMS key ou role, a menos que esteja em nossa organização"). Usados juntos, eles fecham lacunas que nenhum cobre sozinho. A armadilha: na AWS e no GCP, uma SCP ou Org Policy nunca concede nada — apenas subtrai. O Azure é conectado de forma diferente, separando claramente RBAC (permissões) de Azure Policy (compliance e configuração), então a tarefa de guardrail pertence principalmente ao Azure Policy, enquanto "quem pode fazer o quê" pertence inteiramente ao RBAC.

Camada 3 — identidade e permissões

Cada nuvem expressa uma concessão como o mesmo triplo — um principal, um role (um pacote de permissões) e um scope — mas monta as peças de forma diferente.

• Diretório de identidades — AWS: IAM mais IAM Identity Center (SSO). GCP: Cloud Identity / Google Workspace mais IAM. Azure: Microsoft Entra ID.
• Pacote de permissões (o "role") — AWS: uma IAM policy, managed ou inline. GCP: um IAM role — basic, predefined ou custom. Azure: uma RBAC role definition, built-in ou custom.
• A concessão em si — AWS: uma policy anexada a um user, group ou role. GCP: um IAM binding (member + role, opcionalmente uma condition) em um recurso. Azure: um role assignment (principal + role + scope).
• Condições e negação explícita — AWS: IAM condition keys e Deny explícito. GCP: IAM Conditions e deny policies. Azure: RBAC conditions e deny assignments.

A diferença mais profunda é onde a concessão reside. Na AWS, você geralmente anexa a policy à identity — uma role ou user — e a permissão viaja com eles. No GCP, a allow policy é anexada ao recurso: você concede ao principal P o role R no recurso X, e ele herda pela hierarquia. O role assignment do Azure se assemelha ao binding do GCP, mas se ancora a um scope na cadeia management group → subscription → resource group → resource. Internalize "AWS = anexado à identity, GCP e Azure = anexado ao recurso/scope" e muita confusão entre nuvens desaparece.

Camada 3b — workload identity (a parte que as pessoas esquecem)

Humanos não são os únicos principals. Seu código também precisa de uma identity, e acertar isso é a maior alavanca única no least privilege. A regra de ouro em todos os lugares: nunca implemente chaves estáticas de longa duração — anexe uma managed identity à workload em vez disso.

• Identidade para uma workload em execução — AWS: um IAM role, assumido via instance profile, task role ou OIDC. GCP: um service account anexado ao recurso. Azure: uma managed identity, system- ou user-assigned.
• App / principal não humano — AWS: IAM role. GCP: service account. Azure: service principal.
• Confiança sem chaves de fora da nuvem — AWS: IAM roles com federação OIDC/SAML. GCP: Workload Identity Federation. Azure: workload identity federation.

Observe a sobreposição de nomes que confunde a todos: um "IAM role" na AWS é uma workload identity que você assume, enquanto um "role" no GCP e Azure é apenas um pacote de permissões — a identity é um service account ou managed identity. Mesma palavra, dois trabalhos diferentes. As service-account keys do GCP e os service-principal secrets do Azure ainda existem, mas ambas as nuvens agora impulsionam fortemente a federação sem chaves para qualquer coisa executando fora de seu perímetro.

Camada 4 — key management

Finalmente, criptografia. Cada nuvem tem um serviço de chaves gerenciado, organiza as chaves em uma pequena hierarquia e — crucialmente — separa usar uma chave (encrypt/decrypt) de administrar uma chave (rotate, disable, set policy).

• Serviço — AWS: KMS, mais CloudHSM para hardware dedicado. GCP: Cloud KMS, mais Cloud HSM / external. Azure: Key Vault, mais Managed HSM para hardware dedicado.
• Organização das chaves — AWS: KMS keys (CMKs), aliases, multi-Region keys. GCP: key ring → key → key version. Azure: vault → key / secret / certificate.
• Controle de acesso — AWS: key policy + grants + IAM (os três combinam). GCP: Cloud KMS IAM bindings nos níveis project, key ring ou key. Azure: RBAC por padrão, ou access policies legadas por vault; o Managed HSM usa seu próprio RBAC local.
• Divisão entre usar e administrar — AWS: ações de encrypt/decrypt vs. ações de administração de chaves. GCP: cryptoKeyEncrypterDecrypter vs. roles de admin. Azure: roles do tipo "Crypto User" vs. "Crypto Officer".

Um detalhe atual que vale a pena saber: para novos Key Vaults em versões recentes da API, o Azure RBAC é agora o modelo de acesso padrão, e as access policies mais antigas por vault são o caminho legado — o que finalmente alinha o Key Vault com a forma como o resto do Azure lida com permissões. A AWS permanece a exceção: a key policy de uma KMS key é autoritativa e pode conceder acesso independentemente do IAM, então um erro clássico da AWS é se trancar para fora de uma chave ao editar o IAM e esquecer a key policy. No GCP, o acesso ao KMS é IAM puro, como todo o resto.

Onde o modelo mental se quebra

Um mapeamento limpo é perigoso se você confiar nele literalmente demais. Os quatro lugares onde a analogia vaza:

• "IAM role" significa duas coisas diferentes. Na AWS, é uma identity assumível; no GCP e Azure, um "role" é apenas um conjunto de permissões, com a identity mantida separada. Nunca o traduza palavra por palavra.
• A AWS anexa permissões a identities; o GCP e Azure as anexam a recursos e scopes. Seu instinto de "onde procuro para auditar o acesso?" precisa ser invertido ao mudar de nuvem.
• Account, project e subscription não são o mesmo blast radius. Uma AWS account é uma parede forte; um GCP project é parede, fatura e agrupamento em um só; uma Azure subscription é principalmente um limite de cobrança e escala, com o resource group lidando com o ciclo de vida diário.
• Guardrails subtraem, grants adicionam — exceto que o Azure divide as tarefas. SCPs e Org Policies apenas limitam permissões; o Azure limita via Policy e concede via RBAC como dois sistemas separados.

O princípio subjacente aos três é o mesmo: least privilege, aplicado por estrutura. Coloque guardrails no alto (org, OU, folder, management group), conceda de forma restrita e prefira roles em vez de chaves estáticas, e mantenha "pode usar uma chave" separado de "pode administrar uma chave". Os nomes mudam entre as nuvens; a disciplina não.

Conclusões práticas

• Projete a hierarquia antes da primeira workload. Adaptar accounts, projects ou subscriptions posteriormente causa problemas em todas as nuvens.
• Defina tetos altos, conceda baixo. SCP/RCP, Org Policy ou Azure Policy no topo; roles específicas no scope mais restrito que funcione.
• Prefira managed identities por padrão. IAM roles na AWS, service accounts no GCP, managed identities no Azure — e federação sem chaves para qualquer coisa que cruze um limite de nuvem.
• Trate a administração de chaves como privilegiada. Separe encrypt/decrypt de rotate/disable/set-policy, e na AWS sempre verifique a key policy, não apenas o IAM.
• Se você usa Terraform ou OpenTofu, essas primitivas são exatamente o que você irá codificar — aws_organizations_*, google_folder, azurerm_management_group e os recursos de IAM/RBAC e KMS abaixo deles.

Aprofunde cada camada, por nuvem

As certificações de arquitetura e segurança de cada nuvem são construídas diretamente sobre a hierarquia de recursos, IAM/RBAC e key management. Se você quer praticá-las com questões reais de exames, CertLabPro tem um caminho para cada uma:

• AWS — Solutions Architect Associate (SAA-C03) para a hierarquia e IAM, e Security Specialty (SCS-C03) para SCPs, RCPs e KMS. Novo na AWS? Comece com Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect para organization, folders, projects e IAM, e Professional Cloud Security Engineer para IAM deny policies, Org Policy e Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) para management groups e governança, e Security Engineer (AZ-500) para RBAC, Azure Policy e Key Vault. Novo no Azure? Comece com Azure Fundamentals (AZ-900).

Em suma

AWS, Google Cloud e Azure não são tão diferentes quanto suas documentações fazem parecer. Cada uma oferece uma hierarquia para organizar contas, um modelo de identidade construído em principal-role-scope, uma camada de guardrail que limita as permissões que podem existir, e um serviço de chaves que separa o uso de chaves da administração delas. Aprenda as quatro camadas uma vez e a tradução entre nuvens é principalmente vocabulário — e aprenda os quatro pontos onde a analogia vaza, e você evitará os erros que o vocabulário esconde. Esses fundamentos são exatamente o que os bancos de questões do CertLabPro são construídos para exercitar, em todas as três nuvens.