A seguranca representa aproximadamente 30% do exame SAA-C03. O primeiro desafio e projetar "quem pode acessar o que." Se voce pensa no IAM apenas como uma ferramenta de gerenciamento de usuarios, vai errar as questoes do exame. O IAM e a espinha dorsal de seguranca de todo o AWS.
O que e IAM?
Pense no sistema de seguranca de um edificio corporativo. Para entrar, voce precisa de um cracha de acesso. Cada cracha tem regras diferentes: "cafeteria e lobby permitidos, sala de servidores proibida." O AWS IAM funciona exatamente assim.
O IAM (Identity and Access Management) controla o acesso aos recursos da AWS. Ele responde a pergunta: "Esta pessoa (ou servico) pode realizar esta acao neste recurso?"
O IAM tem quatro componentes principais:
Usuario: Representa uma pessoa real. Como um cracha de acesso pessoal. Grupo: Agrupamento de usuarios no estilo departamental. Conceda permissoes ao grupo "Equipe Dev" e todos os membros as herdam. Funcao (Role): Cracha temporario emitido para servicos ou aplicacoes, nao para pessoas. Quando uma instancia EC2 precisa acessar o S3, ela usa uma funcao. Politica: Documento JSON com as regras de permissao reais. Por exemplo, "permitir leitura de buckets S3."
Quatro tipos de politicas IAM
As politicas diferem com base no que estao anexadas.
Politicas baseadas em identidade sao anexadas diretamente a usuarios, grupos ou funcoes. "Este funcionario pode ler o S3": voce esta concedendo permissao a identidade.
Politicas baseadas em recursos sao anexadas ao proprio recurso. A politica de bucket S3 e o exemplo classico. "Apenas usuarios desta conta especifica podem acessar este bucket": a regra fica no recurso.
Limites de permissao (Permission Boundaries) limitam as permissoes maximas que uma identidade pode ter. Mesmo que alguem conceda admin completo, um limite de permissao pode restringir o que esse usuario realmente pode fazer.
SCPs (Service Control Policies) sao regras mestras aplicadas no nivel organizacional. Elas se aplicam a todas as contas sob uma OU do AWS Organizations. Se uma SCP bloqueia uma acao, nenhuma politica IAM nessa conta pode anular isso.
!4 tipos de política do IAM
Logica de avaliacao de politicas — Como a AWS decide
Quando uma solicitacao de acesso chega, a AWS a avalia nesta ordem:
Etapa 1: Se houver um Deny explicito em qualquer lugar, o acesso e bloqueado imediatamente. Nenhum Allow pode substituir um Deny.
Etapa 2: Se houver um Allow explicito, o acesso e concedido.
Etapa 3: Se nenhum dos dois for encontrado, o padrao e o Deny implicito. A AWS bloqueia tudo por padrao.
Regra principal: o Deny explicito sempre vence sobre qualquer Allow, sem excecoes.
Gerenciamento de multiplas contas — AWS Organizations
Grandes empresas operam multiplas contas AWS: desenvolvimento, producao, seguranca, financas. O AWS Organizations permite gerenciar todas como uma unica organizacao.
Uma OU (Organizational Unit) agrupa contas como departamentos. Voce pode ter uma "OU de Dev" e uma "OU de Prod" com regras diferentes.
SCPs aplicadas a uma OU definem as permissoes maximas para cada conta nesse grupo. Por exemplo: "contas na OU de Dev nunca podem excluir bancos de dados de producao", independentemente do que as politicas IAM digam.
O AWS Control Tower se baseia no Organizations para configurar automaticamente um ambiente de multiplas contas seguindo as melhores praticas da AWS. Ele aplica guardrails (regras obrigatorias e recomendadas) para manter a governanca em toda a organizacao.
Acesso entre contas — STS AssumeRole
Imagine uma funcao Lambda na Conta A que precisa ler um bucket S3 na Conta B. Voce resolve isso com funcoes entre contas e STS (Security Token Service).
O processo funciona assim:
Etapa 1: Na Conta B (onde fica o bucket S3), crie uma funcao IAM. Em sua politica de confianca, especifique "a Conta A pode assumir esta funcao."
Etapa 2: A Lambda na Conta A chama STS AssumeRole e recebe credenciais temporarias (validas de 15 minutos a 36 horas).
Etapa 3: Use essas credenciais temporarias para acessar o bucket S3 da Conta B.
As credenciais temporarias expiram automaticamente, tornando isso muito mais seguro do que compartilhar chaves de acesso permanentes.
Federacao — Conectando sistemas de login externos
E tedioso para os funcionarios fazerem login no console da AWS separadamente de suas contas corporativas. Se ja tem uma conta do Active Directory, deveria poder usa-la para a AWS tambem. Isso e federacao.
O IAM Identity Center (antes AWS SSO) fornece login unico em multiplas contas AWS. Integra-se com provedores de identidade externos como Microsoft Active Directory e Google Workspace.
O Amazon Cognito gerencia a autenticacao de usuarios para aplicativos moveis e web. Os User Pools gerenciam o cadastro e login de usuarios. Os Identity Pools concedem aos usuarios autenticados acesso aos recursos AWS.
Pontos-chave para o exame
"Principio do menor privilegio" — base de todo projeto de acesso; permita apenas o necessario
"Bloquear um servico especifico em contas membro" — SCP (mesmo que o IAM permita, a SCP substitui)
"Tanto SCP quanto IAM devem permitir para o acesso funcionar" — avaliacao de intersecao de politicas
"Acessar recursos em outra conta" — funcao entre contas + STS AssumeRole
"SSO em multiplas contas AWS" — IAM Identity Center
"Autenticacao de usuarios para apps moveis/web" — Amazon Cognito
"EC2 precisa acessar S3" — funcao IAM via perfil de instancia; nunca codifique chaves de acesso
"Limitar as permissoes maximas de um usuario IAM" — Permission Boundary
O Deny explicito sempre vence sobre qualquer Allow, sem excecoes