APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma decisão IAM junta principal, role e recurso. Começa pela tarefa concreta: ler objetos de um bucket não exige administrar toda a organização. Roles predefinidas facilitam gestão quando correspondem ao requisito; custom roles podem reduzir ações adicionais, mas precisam de proprietário e manutenção. A análise deve incluir herança. Remover uma atribuição local não retira uma permissão que continua concedida por um ancestral. Considera também deny e outros controlos aplicáveis antes de concluir acesso efetivo. O diagnóstico deve registar identidade, ação, recurso e política relevante para tornar a revisão reproduzível. Uma lista de nomes de roles sem contexto não é suficiente para decidir se o acesso é proporcional.
Aplicação guiada
Service accounts introduzem fronteiras adicionais. Poder anexar uma conta a uma VM através de actAs não significa automaticamente poder criar todos os tipos de token dessa conta. Um pedido para gerar credenciais precisa da permissão correspondente e de um âmbito limitado. Numa passagem de projeto a APS, usa identidades separadas quando as responsabilidades diferem e testa com a identidade que operará realmente o serviço. Um administrador fazer o ensaio com privilégios amplos não demonstra que o role de contingência funciona. Guarda a justificação de cada concessão, o responsável por a rever e os testes de acesso permitido e recusado, incluindo herança de pastas.
Se o utilizador perde uma role no projeto mas mantém acesso, investiga grupos e ancestrais antes de concluir que a remoção falhou.
Armadilhas comuns
Owner como diagnóstico; remoção local como revogação total; role personalizada sem manutenção; actAs como qualquer token.
Tópicos relacionados: Federação, impersonation e pipelines · Projetos, contexto, quotas e custos
A autorização deve ser explicável pela tarefa, pelo recurso e pela identidade efetiva.
Referência: IAM overview · Standard exam guide linked 2026-09-29; edition date unconfirmed