Gerenciamento de identidade e acesso

Pontos-chave

• Usuários: credenciais de longo prazo (uma senha e até 2 chaves de acesso). Use só quando uma role não resolve, como em algumas ferramentas de terceiros.
• Grupos: anexam políticas a vários usuários de uma vez. Um usuário pode estar em até 10 grupos, e grupos não podem conter outros grupos.
• Roles: sem credenciais de longo prazo. São assumidas por usuários, serviços da AWS (instance profile do EC2, execution role do Lambda) ou identidades federadas para obter credenciais temporárias.
• Políticas: as baseadas em identidade (gerenciadas ou inline) se anexam a principals. As baseadas em recurso (bucket policy, política de fila, key policy do KMS) indicam um Principal e permitem acesso entre contas.
• Menor privilégio: comece pelas políticas gerenciadas pela AWS e depois restrinja com políticas gerenciadas pelo cliente, condições e a geração de políticas do IAM Access Analyzer a partir da atividade no CloudTrail.

Pontos-chave

• Negação explícita: um Deny em qualquer política aplicável anula todos os Allow.
• Mesma conta: as permissões são a união das políticas baseadas em identidade e em recurso, então um allow em qualquer uma basta.
• Entre contas: o principal precisa de um Allow na sua política de identidade e de um Allow na política baseada em recurso da outra conta.
• Permissions boundary: uma política gerenciada que define o máximo de permissões de um usuário ou role. O efetivo é a interseção com as políticas de identidade, e o boundary sozinho não concede nada.
• Guardrails: SCPs, RCPs e session policies apenas limitam. A ação precisa ser permitida por todas as que se aplicam.

Pontos-chave

• AssumeRole: a sessão dura de 15 minutos até a duração máxima da role, que você configura entre 1 e 12 horas. O padrão é 1 hora.
• Role chaining: usar uma role para assumir outra limita a sessão a 1 hora.
• Trust policy: a política baseada em recurso da role que diz quem pode assumi-la com sts:AssumeRole. A política de permissões diz o que a sessão pode fazer.
• Role vs política de recurso: quem assume uma role abre mão das próprias permissões. O acesso via política baseada em recurso as mantém, o que ajuda a copiar dados entre contas.
• External ID: condição na trust policy quando um terceiro assume uma role na sua conta. Serve para evitar o problema do confused deputy.
• APIs de federação: AssumeRoleWithSAML para IdPs SAML 2.0 e AssumeRoleWithWebIdentity para tokens OIDC.

Pontos-chave

• MFA: a AWS exige MFA para o root por padrão. Recomenda-se MFA resistente a phishing, como passkeys e chaves de segurança.
• Dia a dia: use um usuário administrativo no IAM Identity Center, nunca o root. Apague as chaves de acesso do root que não forem necessárias.
• Tarefas exclusivas do root: encerrar uma conta avulsa, restaurar permissões do IAM quando o único administrador se trancou para fora, registrar-se como vendedor no Reserved Instance Marketplace, ativar MFA delete em um bucket S3.
• Acesso root centralizado: no AWS Organizations dá para remover as credenciais root das contas membro e executar tarefas privilegiadas a partir da conta de gerenciamento, como destravar uma bucket policy que nega todo mundo.
• SCPs se aplicam: uma SCP restringe o root de uma conta membro, mas nunca a conta de gerenciamento.

Pontos-chave

• Fonte de identidade: o diretório do Identity Center, o Active Directory (AWS Managed Microsoft AD ou AD Connector) ou um IdP externo via SAML 2.0.
• Permission sets: defina uma vez as permissões de uma função de trabalho, provisione em várias contas e atribua a usuários e grupos.
• Instância de organização: implantada na conta de gerenciamento, é o único tipo de instância que gerencia acesso a contas da AWS. Instâncias de conta servem a implantações isoladas de aplicações.
• AWS access portal: uma página de login que lista todas as contas e aplicações atribuídas ao usuário, com credenciais de curto prazo para console e CLI.
• Trusted identity propagation: aplicações gerenciadas pela AWS, como o Amazon Quick, repassam a identidade do usuário a serviços como o Amazon Redshift para autorização e auditoria.

Pontos-chave

• SAML 2.0: um IdP corporativo, como o Active Directory Federation Services, autentica o usuário, e o STS AssumeRoleWithSAML devolve credenciais de uma role do IAM.
• Grupos do diretório em roles: a asserção do IdP mapeia usuários ou grupos do diretório para roles do IAM, então o acesso segue a participação nos grupos.
• OIDC: tokens de provedores como o GitHub Actions são trocados via AssumeRoleWithWebIdentity, e os pipelines rodam sem chaves guardadas.
• IAM ou Identity Center: a federação direta no IAM serve para uma conta avulsa ou para usuários de máquina. Para muitas contas, federe uma vez no IAM Identity Center.
• IAM Roles Anywhere: workloads fora da AWS obtêm credenciais temporárias com um certificado X.509 da sua PKI.

Pontos-chave

• User pools: diretório de usuários e provedor OIDC que emite JWTs (tokens de ID e de acesso). Suporta cadastro, MFA, login social e IdPs corporativos SAML ou OIDC.
• Identity pools: trocam um token confiável por credenciais temporárias da AWS, com privilégio limitado, emitidas pelo STS. Também podem dar acesso não autenticado a visitantes.
• Juntos: o login acontece no user pool, e o token do user pool é trocado no identity pool por credenciais para chamar o S3 ou o DynamoDB diretamente.
• Proteção de APIs: o API Gateway valida tokens do user pool antes de chamar o backend, e o AWS WAF pode proteger o user pool.
• Controle de acesso: identity pools escolhem uma role do IAM por usuário (baseado em role) ou mapeiam claims para session tags (baseado em atributos).

Pontos-chave

• AWS Managed Microsoft AD: um AD real do Windows Server operado pela AWS. Suporta trusts com o AD on-premises, MFA, extensões de schema e Amazon RDS for SQL Server.
• Edições: a Standard mira até cerca de 30.000 objetos no diretório, a Enterprise até cerca de 500.000.
• AD Connector: proxy que encaminha os logins para os controladores de domínio on-premises, sem sincronizar o diretório. Pode usar o seu MFA via RADIUS.
• Simple AD: diretório compatível com AD, de baixo custo, baseado em Samba 4. Sem trusts, sem MFA e sem RDS for SQL Server.