Aprofundando em AWS IAM: Políticas, SCPs, Delegação e Boas Práticas Avançadas

Introdução

O AWS Identity and Access Management (IAM) é, sem dúvida, a espinha dorsal da segurança e governança na nuvem AWS. Embora muitos profissionais conheçam o básico – criação de usuários e grupos, aplicação de políticas gerenciadas, etc. – existem diversos recursos avançados que podem levar o controle de acesso a um nível muito mais refinado e seguro. Neste artigo, vamos aprofundar em alguns conceitos avançados e mostrar dicas para um uso mais estratégico do IAM.

1. Relembrando o Básico: Identity-Based vs. Resource-Based Policies

• Identity-Based Policies: associadas a uma identidade (usuário, grupo ou função). Ex.: políticas do tipo IAM::Policy que concedem permissões específicas.
• Resource-Based Policies: acopladas diretamente a um recurso (ex.: um bucket S3). Aqui, definimos quem pode acessar e o nível de permissão no próprio objeto.

Apesar de parecer simples, entender claramente essa divisão é fundamental para evoluir em estruturas mais complexas.

2. Service Control Policies (SCPs) e AWS Organizations

Quando gerenciamos múltiplas contas dentro de uma Organização (via AWS Organizations), podemos controlar permissões de forma global usando Service Control Policies (SCPs).

• O que são SCPs?
  São políticas aplicadas no nível da organização, pasta (OU) ou conta, definindo um “guarda-chuva” de permissões máximas. Mesmo que um usuário dentro de uma conta tenha permissões IAM para realizar determinada ação, uma SCP pode bloquear essa ação se estiver fora do escopo permitido.
• Cenário de Uso: Restringir que qualquer conta dentro da sua organização crie instâncias EC2 em regiões não aprovadas, ou bloquear a criação de certos tipos de recursos, como IAM Keys.

Dica: Sempre use a SCP “FullAWSAccess” (padrão) e vá estreitando as permissões somente depois que tiver certeza de que as políticas não irão bloquear processos críticos.

3. Permission Boundaries

Permission Boundaries são um recurso que permite definir o limite máximo de permissões que uma entidade (usuário ou função) pode ter.

• Por que usar?
  É útil em cenários em que equipes precisam criar suas próprias funções IAM, mas você quer limitar até onde elas podem ir (por exemplo, impedir a criação de funções com permissões “:”).
• Exemplo: Você define uma boundary que especifica que os usuários podem apenas criar funções com permissão de leitura em S3 e leitura em DynamoDB. Assim, mesmo que um usuário associe uma política mais permissiva, ele não conseguirá ultrapassar a boundary.

4. Políticas de Acesso Baseadas em Atributos (ABAC)

ABAC (Attribute-Based Access Control) permite conceder permissões IAM baseadas em tags (atributos) que identificam recursos, usuários ou funções.

• Exemplo: Se cada usuário ou recurso tiver a tag “Departamento=Financeiro”, você pode criar uma política IAM que restringe o acesso somente a recursos com a mesma tag.
• Vantagem: Escalabilidade. Ao invés de gerenciar diversos usuários/grupos para cada permissão, você controla as tags de cada recurso/identidade, facilitando o controle de acesso dinâmico.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}

Acima, um exemplo simplificado de como usar tags para alinhar permissões (o usuário só pode acessar buckets S3 que tenham a mesma tag “Department” que ele).

5. Delegação de Acesso Entre Contas (Cross-Account Roles)

Não é incomum trabalhar com várias contas AWS em um mesmo ambiente corporativo. Para não precisar gerenciar usuários e credenciais separadas em cada conta, a solução é fazer uso de funções (roles) cross-account.

• Benefícios:
  • Menor necessidade de credenciais estáticas.
  • Centralização de usuários em uma única conta (ex.: conta “Identity” ou “Master”).
  • Logs unificados das ações realizadas, pois ficam vinculadas à role que o usuário assumiu.
• Como Configurar:
  1. Na conta de destino, crie uma role confiável pela conta de origem.
  2. Defina políticas indicando quais ações são permitidas.
  3. Na conta de origem, crie uma política IAM que permita o usuário chamar sts:AssumeRole para a role criada.

Exemplo de Trust Policy (na conta destino):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Isso diz que a conta 111111111111 (origem) pode assumir essa role.

6. Autenticação Federada (SAML, OIDC e Cognito)

Organizações que já usam um IdP (Identity Provider) corporativo, como Okta, Active Directory Federation Services (ADFS) ou Azure AD, podem federar com a AWS via SAML.

• Vantagens:
  • Single Sign-On (SSO).
  • Gerenciamento centralizado de credenciais fora da AWS.
  • Menos riscos de chaves expostas ou senhas duplicadas.
• Exemplo: Configurar uma trust relationship entre o IdP e o IAM usando um provedor SAML, permitindo que usuários se autentiquem no IdP e, então, recebam credenciais temporárias para a AWS.

Para aplicações web e mobile, o Amazon Cognito é uma excelente opção para gerenciar logins de usuários, incluindo suporte a provedores sociais (Google, Facebook, Apple, etc.) e OIDC.

7. Boas Práticas Avançadas

1. Use MFA (Multi-Factor Authentication) em Todo Lugar

   • Especialmente para usuários root e contas com privilégios administrativos.
   • Considere a adoção de Hardware MFA (YubiKeys) para aumentar a segurança.

2. Evite Usuário Root para Tarefas Diárias

   • Crie uma role administrativa com MFA para operações rotineiras.
   • Guarde as credenciais root em local seguro e use-as apenas quando estritamente necessário (ex.: criar conta nova em Organizations).

3. Integração com CloudTrail

   • Monitore todos os eventos de login, as tentativas de AssumeRole e mudanças em políticas IAM.
   • Configure alertas via CloudWatch/SNS para qualquer comportamento anormal.

4. Rotacione Chaves de Acesso Periodicamente

   • Se você precisar usar chaves de acesso (ideia não recomendada para usuários humanos), defina políticas de rotação e verifique usuários com chaves expiradas ou não utilizadas.

5. Esteja Atento a Novos Recursos

   • A AWS lança frequentemente atualizações e novos recursos em IAM (por exemplo, suporte a tags em roles, refinamentos em SCPs, etc.). Fique de olho nos anúncios.

Conclusão

O AWS IAM é um pilar fundamental para garantir a governança e segurança de qualquer ambiente na nuvem. Ao entender e aplicar esses recursos avançados – SCPs, ABAC, Permission Boundaries, Cross-Account Roles e Federação – você obtém um controle muito mais detalhado e reduz o risco de configurações inseguras.

No próximo post, vamos explorar exemplos práticos e demos de como implementar algumas dessas configurações passo a passo. Fique de olho e até lá!

Links e Referências Úteis

• Documentação Oficial do IAM
• Exemplos de SCP (Service Control Policies)
• ABAC - Attribute-Based Access Control na AWS
• Best Practices da AWS para IAM

Ficou com alguma dúvida ou quer compartilhar sua experiência?

Deixe um comentário abaixo ou entre em contato. Será um prazer ajudar a fortalecer sua postura de segurança e governança na Nuvem AWS!

Até breve e boas configurações de IAM!