Controlo de Acessos com AWS IAM: Políticas, Roles e Boas Práticas

O AWS Identity and Access Management (IAM) é o serviço que governa a autenticação e a autorização de cada chamada API efetuada ao seu ambiente AWS. Determina quem pode iniciar sessão, que ações pode executar e sobre que recursos — em todos os serviços AWS, em todas as regiões, para cada conta. Configurar corretamente o IAM não é opcional; de acordo com as próprias análises pós-incidente da AWS, políticas IAM mal configuradas estão envolvidas na maioria das fugas de segurança na nuvem que chegam a divulgação pública. Este artigo aborda a arquitetura do IAM, a lógica de avaliação de políticas, padrões práticos para escalar o controlo de acessos e os erros operacionais que o SOC da Opsio encontra repetidamente em centenas de contas AWS.

Pontos-Chave

• O AWS IAM é o serviço base que controla quem pode fazer o quê em cada recurso AWS, e a sua má configuração é a causa raiz mais comum de incidentes de segurança na nuvem.
• Um IAM eficaz exige a sobreposição de políticas de identidade, políticas de recurso, permission boundaries e Service Control Policies — não basta associar managed policies a utilizadores.
• Organizações sujeitas à NIS2, ao RGPD ou ao DPDPA 2023 devem tratar a configuração IAM como um controlo de conformidade, não como uma mera conveniência operacional.
• O ABAC (attribute-based access control) através de tags é atualmente o padrão recomendado para organizações com mais do que um punhado de contas, mas a maioria das equipas continua a usar apenas RBAC.
• As maiores falhas de IAM que o SOC da Opsio investiga não são escalações de privilégios — são credenciais obsoletas e service roles com permissões excessivas que ninguém revê.

Como Funciona o AWS IAM: O Modelo Central

O IAM opera num modelo de deny-by-default. Cada pedido de API AWS é avaliado face a um conjunto de políticas e, salvo se a avaliação produzir um Allow explícito — sem qualquer Deny a sobrepô-lo — o pedido é rejeitado. Compreender esta cadeia de avaliação é o conceito mais importante em todo o controlo de acessos AWS.

Principals, Actions, Resources e Conditions

Cada declaração de uma política IAM tem quatro componentes:

• Principal — a entidade que efetua o pedido (IAM user, IAM role, identidade federada, serviço AWS)
• Action — a operação API específica (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — o(s) ARN(s) aos quais a ação se aplica
• Condition — restrições opcionais (IP de origem, estado MFA, hora do dia, tags do recurso)

Uma política é um documento JSON contendo uma ou mais declarações, cada uma com um Effect de Allow ou Deny. O poder — e a complexidade — advêm da forma como múltiplas políticas interagem durante a avaliação.

A Cadeia de Avaliação de Políticas

Quando um principal efetua um pedido dentro de uma AWS Organization, a avaliação segue esta ordem:

1. Service Control Policies (SCPs) — guardrails ao nível da organização que definem as permissões máximas para contas-membro

2. Resource-based policies — associadas ao próprio recurso (e.g., políticas de bucket S3, políticas de chave KMS)

3. IAM permission boundaries — as permissões máximas que uma entidade IAM pode ter, independentemente das suas identity policies

4. Session policies — passadas ao assumir uma role, restringindo ainda mais a sessão

5. Identity-based policies — as políticas associadas ao IAM user, grupo ou role

Um Deny explícito em qualquer nível sobrepõe-se a todas as declarações de Allow. Este modelo por camadas permite aplicar guardrails ao nível da organização (via SCPs) mesmo que administradores de contas individuais tentem conceder acessos mais amplos.

Compreender esta cadeia não é académico — o NOC da Opsio rastreia regularmente erros de access-denied até restrições de SCPs que os administradores de conta desconheciam existir. Se está a resolver um 403 numa chamada API onde a identity policy claramente diz Allow, verifique primeiro as SCPs.

Blocos Fundamentais do IAM na Prática

IAM Users vs. IAM Roles vs. Identidades Federadas

Os IAM users são identidades de longa duração com credenciais permanentes. Ainda existem e funcionam, mas para operadores humanos devem ser considerados legacy. A orientação atual da AWS — e a posição operacional da Opsio — é federar o acesso humano através do IAM Identity Center (anteriormente AWS SSO), que emite credenciais temporárias via SAML 2.0 ou OIDC.

Os IAM roles são os cavalos de batalha do IAM moderno. Uma role não possui credenciais permanentes; em vez disso, os principals assumem a role e recebem tokens de segurança temporários (via AWS STS). As roles são utilizadas para:

• Acesso entre contas (a workload da Conta A assume uma role na Conta B)
• Acesso serviço-a-serviço (instance profile de EC2, execution role de Lambda)
• Acesso humano via federação (assumir uma role após autenticação no IdP)

As identidades federadas autenticam-se contra um fornecedor de identidades externo (Okta, Azure AD / Entra ID, Google Workspace) e assumem IAM roles. Este é o padrão que qualquer organização com mais de dez engenheiros deveria estar a utilizar para acesso à consola e ao CLI.

Políticas IAM: Managed, Inline e Personalizadas

As AWS managed policies (e.g., ReadOnlyAccess, PowerUserAccess) são mantidas pela AWS e cobrem padrões comuns. São convenientes, mas frequentemente demasiado amplas para uso em produção. AdministratorAccess é a managed policy mais frequentemente associada que o SOC da Opsio encontra em auditorias — e quase nunca se justifica para operações do dia-a-dia.

As customer managed policies são a escolha correta por omissão. Escreva-as você mesmo, delimite-as às suas workloads reais, controle-as em Git e implemente-as via Infrastructure as Code (Terraform, CloudFormation ou CDK).

As inline policies são embebidas diretamente num user, grupo ou role. Têm uma relação estrita 1:1. Utilize-as apenas quando uma política não pode ser acidentalmente associada a outra entidade — o que é raro.

Service Control Policies (SCPs)

As SCPs são a camada mais poderosa — e mais mal compreendida — no stack IAM. Não concedem permissões; definem o limite máximo do que qualquer principal numa conta-membro pode fazer. Uma SCP que negue s3:DeleteBucket significa que ninguém nessa conta pode eliminar um bucket, mesmo que tenha AdministratorAccess.

Padrões práticos de SCPs que a Opsio implementa para clientes:

• Restrição por região — negar todas as ações fora de eu-west-3 (Paris), eu-south-2 (Espanha) e eu-west-1 (Irlanda), impondo a soberania de dados para o RGPD
• SCPs de guardrail — impedir a desativação do CloudTrail, a eliminação de VPC flow logs ou a modificação da role de auditoria IAM
• Lista de bloqueio de serviços — bloquear serviços que a organização não utiliza (e.g., Lightsail, GameLift) para reduzir a superfície de ataque

Guardrails de segurança AWS

RBAC vs. ABAC: Escolher o Modelo Adequado

RBAC (Role-Based Access Control)

RBAC na AWS significa criar IAM roles distintas para cada função — DevOps-Engineer, Data-Analyst, Security-Auditor — e associar políticas a essas roles. É intuitivo e funciona bem quando:

• Tem menos de ~20 roles distintas
• As equipas estão claramente separadas
• A proliferação de contas é limitada

A desvantagem é a explosão combinatória. Se tem 5 funções profissionais, 4 ambientes (dev/staging/prod/sandbox) e 3 projetos, pode necessitar de 60 definições de roles — cada uma com políticas separadas.

ABAC (Attribute-Based Access Control)

O ABAC utiliza tags em principals e recursos para tomar decisões de autorização. Em vez de 60 roles, escreve-se um conjunto mais reduzido de políticas com condições como:

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Isto permite que um developer com as tags Project=payments, Environment=dev aceda apenas aos recursos com as mesmas tags — sem criar roles específicas por projeto ou por ambiente.

A documentação IAM da AWS recomenda explicitamente o ABAC como o modelo preferencial para escalar. Na prática, a maioria das organizações geridas pela Opsio utiliza um modelo híbrido: RBAC para a separação ampla por função profissional, ABAC para a delimitação granular de recursos dentro dessas roles.

A ressalva operacional: o ABAC só funciona se a política de tagging for disciplinada. Se as equipas não aplicarem tags de forma consistente, as condições falham de forma aberta ou fechada de modos imprevisíveis. Aplique o tagging com SCPs e regras AWS Config antes de apostar no ABAC.

Governação de tags e FinOps

Boas Práticas IAM: O Que Realmente Importa

O Pilar de Segurança do AWS Well-Architected Framework define boas práticas IAM em cinco áreas. Eis o que constatamos ser mais relevante em produção — não em teoria:

1. Eliminar Access Keys de Longa Duração

Cada access key é uma credencial que pode ser exfiltrada. O SOC da Opsio já investigou incidentes em que access keys publicadas em repositórios GitHub públicos foram exploradas em minutos por scanners automatizados. A solução:

• Utilizar IAM roles com credenciais temporárias para todas as workloads (instance profiles de EC2, task roles de ECS, execution roles de Lambda)
• Federar o acesso humano via IAM Identity Center
• Nos raros casos em que access keys são inevitáveis (integrações legacy), impor rotação via regra AWS Config access-keys-rotated com idade máxima de 90 dias

2. Impor MFA — Em Tudo o Que Importa

MFA na conta root é o mínimo absoluto. Mas imponha também MFA para:

• Todos os IAM users humanos (se ainda os tiver)
• Assumir roles sensíveis (iam:AssumeRole com Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• O fluxo de autenticação do IAM Identity Center (MFA por notificação push, não por SMS)

3. Aplicar o Privilégio Mínimo de Forma Iterativa

Ninguém acerta no privilégio mínimo à primeira tentativa. A abordagem prática:

1. Começar com AWS managed policies ligeiramente mais amplas do que o necessário

2. Ativar o IAM Access Analyzer para monitorizar quais permissões são efetivamente utilizadas

3. Após 30-90 dias, gerar uma política de privilégio mínimo baseada na atividade registada no CloudTrail

4. Substituir a política ampla pela gerada

5. Repetir trimestralmente

A funcionalidade de geração de políticas do IAM Access Analyzer é genuinamente útil e subutilizada. Lê os logs do CloudTrail e produz uma política delimitada contendo apenas as ações e os recursos efetivamente invocados.

4. Usar Permission Boundaries para Administração Delegada

Se permitir que developers ou team leads criem IAM roles (e.g., para funções Lambda), defina uma permission boundary que limite o que essas roles criadas podem fazer. Sem isto, um developer pode criar uma role com AdministratorAccess — o que constitui um caminho de escalação de privilégios.

5. Auditar Continuamente, Não Anualmente

Uma revisão anual de IAM é um exercício de checkbox. Em alternativa:

• Execute o IAM Access Analyzer continuamente para detetar acessos externos e não utilizados
• Monitorize chamadas API IAM anómalas via CloudTrail + Amazon GuardDuty
• Utilize regras AWS Config para sinalizar automaticamente configurações IAM não conformes
• Encaminhe os findings para um SIEM centralizado ou para o pipeline de alertas do seu SOC

Monitorização SOC 24/7

IAM numa AWS Organization Multi-Conta

Ambientes AWS de conta única são cada vez mais raros em produção. O AWS Organizations, combinado com o IAM Identity Center, é o padrão standard para gerir acessos em dezenas ou centenas de contas.

IAM Identity Center (Anteriormente AWS SSO)

O IAM Identity Center oferece um ponto único para gerir o acesso humano em todas as contas da organização. Os utilizadores autenticam-se uma vez (através do IdP corporativo ou do diretório integrado) e recebem credenciais temporárias para a conta e o permission set que selecionarem.

Os permission sets no IAM Identity Center são abstrações que criam IAM roles em cada conta de destino. São definidos uma vez centralmente e atribuídos a utilizadores ou grupos por conta. Isto é drasticamente mais simples do que gerir IAM roles de forma independente em cada conta.

Assumir Roles Entre Contas

Para acesso serviço-a-serviço entre contas (e.g., um pipeline CI/CD na conta de tooling a implementar em produção), o padrão é:

1. Criar uma role na conta de destino com uma trust policy que permita a role da conta de origem

2. A workload de origem invoca sts:AssumeRole para obter credenciais temporárias

3. Utilizar external IDs para prevenir ataques confused-deputy quando terceiros estão envolvidos

A Opsio configura o acesso entre contas utilizando um modelo hub-and-spoke: uma conta de segurança central detém roles de auditoria que podem ler (mas não escrever) em todas as contas-membro. Este desenho suporta tanto as operações SOC como a recolha de evidências de conformidade.

Estratégia multi-conta

Dimensões de Conformidade: NIS2, RGPD e DPDPA 2023

A configuração IAM é diretamente referenciada em todos os principais quadros de conformidade que a Opsio encontra:

Diretiva NIS2 (UE) — O Artigo 21.º exige "políticas de controlo de acesso" incluindo a gestão de acessos privilegiados. Organizações classificadas como entidades essenciais ou importantes devem demonstrar que os controlos IAM são proporcionais ao risco, que o acesso privilegiado é monitorizado e que as revisões de acesso são realizadas regularmente. Na AWS, isto mapeia para SCPs, CloudTrail, IAM Access Analyzer e procedimentos documentados de revisão de acessos. Em Portugal, a CNPD e a legislação nacional de transposição da NIS2 reforçam estas obrigações para entidades nos setores abrangidos.

RGPD — O Artigo 32.º exige "a capacidade de assegurar a confidencialidade, integridade, disponibilidade e resiliência permanentes dos sistemas e serviços de tratamento", o que os reguladores — incluindo a CNPD — interpretam como abrangendo a gestão de identidades e acessos. Os responsáveis pelo tratamento devem demonstrar que o acesso a dados pessoais é limitado ao pessoal que dele necessita — o que implica políticas IAM delimitadas a tabelas DynamoDB específicas, prefixos S3 ou instâncias RDS que contenham dados pessoais.

DPDPA 2023 (Índia) — A Secção 8 impõe aos data fiduciaries a obrigação de implementar "medidas de segurança razoáveis". Para empresas indianas a executar workloads em ap-south-1 (Mumbai) ou ap-south-2 (Hyderabad), isto significa controlos IAM documentados, trilhos de auditoria e evidência de revisão periódica — similar em espírito aos requisitos do Artigo 32.º do RGPD.

O fio condutor: os três quadros regulamentares exigem não apenas que os controlos existam, mas que sejam monitorizados e revistos. Configuração IAM sem logging via CloudTrail e revisão periódica de acessos não satisfaz nenhum deles.

Erros Comuns de IAM que o SOC da Opsio Encontra

Com base em incidentes reais e findings de auditoria nas contas que gerimos:

1. ARNs de recurso com wildcards em políticas de produção — "Resource": "*" é aceitável em prototipagem. Em produção, significa que um principal comprometido pode aceder a todos os recursos desse tipo na conta.

2. Service roles com AdministratorAccess — Funções Lambda e tarefas ECS devem ter execution roles estritamente delimitadas. Associar acesso de administrador "porque é mais fácil" transforma cada vulnerabilidade aplicacional numa compromissão total da conta.

3. Ausência de SCPs de guardrail em contas-membro — Sem SCPs, qualquer administrador de conta pode conceder a si próprio qualquer permissão. As SCPs são o único mecanismo que restringe mesmo o utilizador root da conta (em contas-membro).

4. IAM users e access keys obsoletas — Encontramos rotineiramente IAM users de colaboradores que deixaram a organização há meses ou anos. Utilize a regra AWS Config iam-user-unused-credentials-check e configure-a para sinalizar credenciais não utilizadas há 45 dias.

5. Ignorar resource-based policies — Políticas de bucket S3, políticas de chave KMS e políticas de fila SQS podem conceder acesso independentemente das identity policies. Um bucket S3 com "Principal": "*" na sua bucket policy é publicamente acessível, independentemente de quão restritivas são as suas IAM roles.

Como Começar: Uma Sequência Prática

Para organizações que ainda não formalizaram a governação IAM, eis a ordem que produz resultados mais rapidamente:

1. Ativar o CloudTrail em todas as contas, em todas as regiões, com logging para um bucket S3 centralizado numa conta de arquivo de logs

2. Ativar o IAM Access Analyzer em cada conta (é gratuito)

3. Migrar o acesso humano de IAM users para IAM Identity Center com MFA

4. Implementar SCPs base — negar regiões não utilizadas (permitindo apenas, por exemplo, eu-west-3, eu-south-2 e eu-west-1), proteger a infraestrutura de auditoria, exigir encriptação

5. Auditar IAM roles e políticas existentes — utilizar os findings do Access Analyzer para identificar roles não utilizadas e políticas com permissões excessivas

6. Implementar Infrastructure as Code para todos os recursos IAM — sem mais ClickOps na consola IAM

Migração e modernização na nuvem

Esta sequência funciona quer tenha 2 contas ou 200. A diferença está no tempo que o passo 5 demora.

Perguntas Frequentes

O que são controlos de acesso IAM?

Os controlos de acesso IAM são as políticas, roles e mecanismos dentro do AWS Identity and Access Management que determinam quais principals (utilizadores, roles, serviços) podem executar quais ações em quais recursos. Funcionam num modelo de deny-by-default: salvo se uma política permitir explicitamente uma ação, esta é negada. Os controlos incluem políticas baseadas em identidade, políticas baseadas em recurso, permission boundaries, session policies e Service Control Policies ao nível da organização.

O IAM é RBAC ou ABAC?

O AWS IAM suporta ambos. O controlo de acesso baseado em roles (RBAC) é conseguido criando IAM roles com conjuntos de permissões específicos e atribuindo-os a utilizadores ou grupos. O controlo de acesso baseado em atributos (ABAC) utiliza tags em principals e recursos para tomar decisões de autorização dinâmicas. A AWS recomenda o ABAC para escalar em múltiplas contas, porque reduz o número de políticas distintas a gerir. A maioria dos ambientes de produção utiliza um modelo híbrido.

O que é o acesso IAM na AWS?

O acesso IAM na AWS refere-se à capacidade autenticada e autorizada de um principal — um IAM user, identidade federada ou IAM role — interagir com serviços e recursos AWS. Cada chamada API à AWS é avaliada face às políticas IAM. O acesso só é concedido quando as políticas aplicáveis produzem um Allow explícito e nenhuma política aplicável produz um Deny explícito.

Quais são os 4 pilares do IAM?

Os quatro pilares comummente referenciados na gestão de identidades são: autenticação (provar quem se é), autorização (o que se está autorizado a fazer), administração (gerir identidades e políticas em escala) e auditoria (registar e rever a atividade de acesso). Em termos AWS, correspondem aos mecanismos de autenticação IAM, às políticas IAM, ao AWS Organizations/IAM Identity Center e ao AWS CloudTrail, respetivamente.

Qual a relação entre o AWS IAM e a conformidade com a NIS2?

A NIS2 exige que entidades essenciais e importantes implementem políticas de controlo de acesso proporcionais ao risco, mantenham capacidades de resposta a incidentes e demonstrem responsabilização pelo acesso privilegiado. O AWS IAM fornece os controlos técnicos — MFA, políticas de privilégio mínimo, SCPs, logging via CloudTrail — mas a conformidade requer processos documentados, revisões periódicas de acessos e evidência de que estes controlos são ativamente monitorizados. Um SOC gerido pode colmatar a diferença entre ter os controlos e provar que funcionam.