95% da segurança na nuvem é decidida na camada do Cloud IAM
Mais de 90% dos incidentes de segurança na nuvem têm origem em configurações incorretas do Cloud IAM. Uma chave de Service Account com permissões excessivas acidentalmente enviada a um repositório público no GitHub, um ex-funcionário cuja conta ainda tem acesso a recursos de produção semanas após o desligamento, alguém que silenciosamente concede permissões de proprietário sem que ninguém perceba até que o dano esteja feito — todos esses cenários começam com uma falha no Cloud IAM. No exame de Associate Cloud Engineer, o domínio do Cloud IAM corresponde a aproximadamente 17% das questões e avalia o julgamento real de segurança, não a memorização mecânica. Este artigo cobre o panorama completo: o modelo do Cloud IAM, como usar Service Accounts com segurança, como Workload Identity e Workload Identity Federation eliminam a necessidade de chaves de longa duração, e como Cloud Audit Logs fornecem visibilidade sobre tudo o que acontece no seu ambiente.
---
O modelo Cloud IAM: membros, papéis e Policy Bindings
O Cloud IAM opera sobre três conceitos fundamentais. Um membro responde à pergunta "quem?", um papel responde "o que ele pode fazer?", e um Policy Binding conecta um membro a um papel em um recurso específico.
Existem cinco tipos de membros no Cloud IAM.
| Tipo de membro | Descrição | Exemplo | |----------------|------------|---------| | Google Account | Identidade pessoal do Google | user@gmail.com | | Service Account | Identidade para aplicações e VMs | my-app@project-id.iam.gserviceaccount.com | | Google Group | Coleção de contas gerenciadas como unidade | dev-team@company.com | | Google Workspace Domain | Todas as contas de um domínio | @company.com | | allAuthenticatedUsers | Qualquer identidade autenticada com o Google | (usar com cuidado em recursos públicos) |
Vincular um papel a um Google Group em vez de usuários individuais é o padrão recomendado em escala. Uma vez que o grupo tem o binding, você só precisa gerenciar a associação ao grupo — a política do Cloud IAM em si nunca muda, o que reduz significativamente a complexidade de auditoria. Uma única política suporta até 1.500 bindings.
Armadilha do exame: allUsers significa qualquer pessoa na internet sem autenticação necessária, enquanto allAuthenticatedUsers significa qualquer identidade que tenha se autenticado com uma conta do Google. Use allUsers apenas em buckets do Cloud Storage que sejam intencionalmente públicos e nunca em recursos que contenham dados sensíveis.
---
Três tipos de papéis e o princípio do privilégio mínimo
O Cloud IAM oferece três categorias de papéis. Entender quando cada um é apropriado é um dos caminhos mais claros para uma pontuação mais alta no exame.
| Tipo de papel | Exemplos | Escopo | Sinal no exame | |---------------|----------|--------|---------------| | Básico | roles/owner, roles/editor, roles/viewer | Projeto completo, muito amplo | Quase sempre errado — viola o privilégio mínimo | | Predefinido | roles/compute.admin, roles/bigquery.dataViewer | Escopo por serviço e ação | Resposta correta na maioria dos cenários | | Personalizado | Combinações de permissões selecionadas pelo usuário | Controle extremamente granular | Usar quando nenhum papel predefinido se encaixa |
Os papéis básicos são desencorajados por razões concretas. roles/editor pode modificar quase qualquer recurso em um projeto, e roles/owner concede controle total, incluindo a capacidade de alterar políticas do Cloud IAM. Conceder qualquer um desses papéis a alguém que só precisa gerenciar um único serviço viola o princípio do privilégio mínimo. Quando uma questão do exame inclui frases como "com as permissões mínimas" ou "sem conceder acesso desnecessário", procure o papel predefinido mais específico que se aplique.
Os papéis personalizados existem para situações em que nenhum papel predefinido atende ao requisito. Uma restrição crítica: papéis personalizados só podem ser criados no nível de organização ou projeto — papéis personalizados no nível de pasta não são suportados. O IAM Recommender usa 90 dias de dados de uso e aprendizado de máquina para identificar permissões que nunca foram exercidas e recomenda removê-las. Qualquer cenário do exame que envolva uma iniciativa de privilégio mínimo em toda a organização após uma auditoria deve apontar para o IAM Recommender.
!3 tipos de funções do IAM
Herança de políticas e IAM Conditions
Os recursos do GCP são organizados em uma hierarquia, e as políticas do Cloud IAM se propagam para baixo nessa hierarquia.
| Nível | Descrição | Direção de herança | |-------|-----------|--------------------| | Organization | Unidade de nível superior (empresa ou domínio) | Flui para todos os filhos | | Folder | Agrupamento por departamento ou ambiente | Flui para projetos filhos | | Project | Limite principal de isolamento de recursos | Flui para recursos filhos | | Resource | Instância do Compute Engine, bucket do Cloud Storage, etc. | Nível mais baixo — apenas recebe |
A regra crítica da herança é que as permissões concedidas em um nível superior não podem ser revogadas em um nível inferior. Se um membro recebe roles/editor no nível de Folder, todos os projetos dentro dessa pasta herdam acesso de editor e não existe mecanismo para bloqueá-lo em um projeto filho específico. Isso torna a colocação dos bindings de papéis tão importante quanto a escolha do papel — conceda no escopo mais estreito que satisfaça o requisito.
IAM Conditions estende os Policy Bindings com controle de acesso baseado em atributos. Você pode anexar condições baseadas em tempo, nome do recurso ou tipo de recurso para tornar um binding sensível ao contexto. Um padrão operacional comum é conceder a um engenheiro de implantação acesso elevado apenas durante uma janela de manutenção aprovada, com o binding expirando automaticamente quando a janela fecha — sem necessidade de limpeza manual.
| Tipo de condição | Exemplo de uso | Cenário | |-----------------|----------------|--------| | Baseada em tempo | Permitir acesso apenas durante horário comercial (09:00–18:00) | Restrição de acesso ao ambiente de desenvolvimento | | Nome do recurso | Aplicar apenas a buckets que correspondam a um padrão de nomenclatura específico | Separar buckets de dev e prod por ambiente | | Tipo de recurso | Aplicar apenas a compute.googleapis.com/Instance | Papel de gerenciamento exclusivo de VMs |
---
Contas de serviço: natureza dual e risco de gerenciamento de chaves
Uma Service Account desempenha dois papéis distintos simultaneamente no Cloud IAM. Como membro, recebe papéis do Cloud IAM e age como a identidade que acessa recursos do GCP. Como recurso, pode ser o sujeito de um Policy Binding que controla quem pode se passar por ela. Toda superfície de computação do GCP — instâncias do Compute Engine, serviços do Cloud Run, Cloud Functions — anexa uma Service Account para interagir com outros serviços do GCP.
Chaves de Service Account (arquivos de credenciais JSON) estão entre os artefatos mais perigosos em um ambiente GCP.
| Método de acesso | Nível de segurança | Recomendado | Observações | |-----------------|-------------------|-------------|-------------| | Chave de Service Account (JSON) | Baixo | Não recomendado | Sem expiração; risco imediato se exposta | | Representação de Service Account | Alto | Recomendado | Tokens de curta duração; rastreabilidade no Cloud Audit Logs | | Workload Identity (GKE) | Muito alto | Fortemente recomendado | Sem chaves; credenciais com rotação automática | | Workload Identity Federation (externo) | Muito alto | Fortemente recomendado | Identidade de IdP externo trocada por tokens GCP de curta duração |
Arquivos de chave não têm expiração incorporada. Uma vez emitida, uma chave permanece válida indefinidamente a menos que seja explicitamente revogada. A inclusão acidental em repositórios do GitHub, imagens Docker ou arquivos de log é uma classe recorrente de incidentes. A orientação oficial do Google é eliminar chaves de Service Account em favor dos mecanismos de Workload Identity sempre que possível.
A representação de Service Account funciona concedendo a um principal o papel roles/iam.serviceAccountTokenCreator, o que lhe permite solicitar tokens OAuth de curta duração que carregam as permissões da Service Account. Esses tokens expiram automaticamente após no máximo uma hora, e cada evento de representação é registrado no Cloud Audit Logs, fornecendo uma trilha de auditoria completa. Em ambientes legados onde as chaves não podem ser evitadas, implemente rotação regular, exclusão imediata de chaves não utilizadas e armazenamento gerenciado pelo Cloud KMS.
---
Workload Identity e Workload Identity Federation
Distinguir entre esses dois mecanismos de autenticação sem chaves é um foco consistente do exame de Associate Cloud Engineer.
| Atributo | Workload Identity (GKE) | Workload Identity Federation (externo) | |----------|-------------------------|------------------------------------------| | Alvo | Pods do GKE exclusivamente | AWS, Azure, GitHub Actions, sistemas on-premises | | Mecanismo | Kubernetes Service Account → vínculo com GCP Service Account | Token de IdP externo trocado por token GCP de curta duração | | Chaves necessárias | Nenhuma | Nenhuma | | Cenário típico | Carga de trabalho GKE chamando APIs do GCP | Pipeline de CI/CD externo ou multi-cloud chamando APIs do GCP |
Workload Identity vincula uma Kubernetes Service Account (KSA) dentro de um pod do GKE a uma GCP Service Account (GSA). O pod chama APIs do GCP sem nenhum material de chave; as credenciais são obtidas automaticamente do servidor de metadados e rotacionadas sem intervenção do operador.
Workload Identity Federation permite que o GCP confie em provedores de identidade externos — AWS IAM Roles, Azure Managed Identities, tokens OIDC do GitHub Actions e outros. O sistema externo apresenta seu token de identidade ao Security Token Service (S