Segurança

IAM e Zero Trust: como implementar na AWS

Equipe RFX Tecnologia 28 Abr 2026 13 min de leitura
Atualizado em Março 2026

Zero Trust é um modelo de segurança que elimina a confianca implicita em qualquer usuário, dispositivo ou rede, exigindo verificação contínua para cada acesso. Na AWS, o Zero Trust é implementado principalmente através do IAM (Identity and Access Management) com princípio de menor privilégio, Service Control Policies (SCPs), Permission Boundaries e AWS Identity Center para autenticação centralizada.

O modelo de segurança tradicional baseado em perímetro, o famoso "confie em tudo dentro da rede", não funciona na nuvem. Com workloads distribuídos, acesso remoto e APIs públicas, a superfície de ataque é muito mais ampla. O Zero Trust inverte essa lógica: "nunca confie, sempre verifique". Cada requisição, cada acesso, cada operação deve ser autenticada, autorizada e auditada, independente de onde venha.

Na AWS, o IAM (Identity and Access Management) é o serviço central para implementar Zero Trust. Neste guia, vamos cobrir desde os fundamentos até configurações avançadas com SCPs, Permission Boundaries e AWS Identity Center.

Princípios do Zero Trust na AWS

O Zero Trust na AWS se apoia em cinco princípios fundamentais:

  • Least Privilege: conceda apenas as permissões estritamente necessárias, pelo menor tempo possível
  • Verificação contínua: autentique e autorize cada request, não apenas no login inicial
  • Segmentação de acesso: isole workloads e dados com fronteiras de segurança claras
  • Visibilidade total: monitore e registre todas as ações para detecção e auditoria
  • Assume breach: projete a arquitetura assumindo que uma violação pode (e vai) acontecer

IAM Policies: o alicerce do controle de acesso

Políticas IAM definem quem pode fazer o quê em quais recursos. A diferença entre uma política segura é uma vulnerável está nos detalhes. Veja a evolução de uma política de acesso a S3:

iam-policy-evolução.json 
// RUIM: acesso total a tudo (nunca faça isso!)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}

// MELHOR: acesso restrito a bucket específico
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::app-dados-prod/*"
  }]
}

// IDEAL: com conditions para Zero Trust completo
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowS3WithConditions",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::app-dados-prod/*",
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "sa-east-1",
        "s3:x-amz-server-side-encryption": "aws:kms"
      },
      "Bool": {
        "aws:SecureTransport": "true"
      },
      "IpAddress": {
        "aws:SourceIp": ["10.0.0.0/8", "172.16.0.0/12"]
      },
      "NumericLessThan": {
        "aws:MultiFactorAuthAge": "3600"
      }
    }
  }]
}

A política "ideal" acima implementa múltiplas camadas de Zero Trust: restrição por região, exigência de criptografia KMS, obrigatoriedade de HTTPS, limitação por IP de origem e exigência de MFA recente (menos de 1 hora).

Service Control Policies (SCPs) e AWS Organizations

As SCPs são guardrails aplicados no nível da organização que definem o teto máximo de permissões para todas as contas de uma OU (Organizational Unit). Mesmo que um administrador de conta conceda permissão total a um usuário, a SCP pode bloquear ações específicas.

scp-guardrails.json 
// SCP: Impedir desativação de CloudTrail e GuardDuty
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyRootAccountUsage",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "RequireIMDSv2",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": {
          "ec2:MetadataHttpTokens": "required"
        }
      }
    },
    {
      "Sid": "DenyNonBrazilRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "sts:*",
        "s3:GetBucketLocation",
        "cloudfront:*",
        "route53:*",
        "support:*",
        "organizations:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["sa-east-1", "us-east-1"]
        }
      }
    }
  ]
}

Esta SCP implementa quatro guardrails críticos: protege serviços de segurança contra desativação, bloqueia uso da conta root, exige IMDSv2 para instâncias EC2 (prevenindo ataques SSRF) e restringe operações às regiões autorizadas.

AWS IAM Identity Center (antigo SSO)

O IAM Identity Center é o serviço recomendado pela AWS para gerenciar acesso humano a múltiplas contas AWS e aplicações. Ele centraliza a autenticação, simplifica o provisionamento de usuários e elimina a necessidade de criar usuários IAM individuais em cada conta.

Benefícios chave para Zero Trust:

  • Credenciais temporárias: usuários recebem sessões de curta duração (1-12h), eliminando credenciais de longa vida
  • MFA centralizado: configure MFA obrigatório uma vez, aplicado em todas as contas
  • Integração com IdP externo: conecte com Okta, Azure AD, Google Workspace ou qualquer provedor SAML 2.0
  • Permission Sets: defina conjuntos de permissões reutilizáveis e atribua a grupos de usuários por conta
  • Auditoria centralizada: todas as autenticações e mudanças são registradas no CloudTrail

Permission Boundaries: o limite da delegação

Permission Boundaries são um recurso avançado do IAM que define o máximo de permissões que uma entidade IAM pode ter. São particularmente úteis quando você precisa delegar a criação de roles e usuários para times de desenvolvimento sem perder o controle.

permission-boundary.json 
// Permission Boundary para roles criadas por desenvolvedores
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCommonServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "sqs:*",
        "sns:*",
        "lambda:*",
        "logs:*",
        "xray:*",
        "cloudwatch:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenySecurityServicesModification",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:AttachRolePolicy",
        "organizations:*",
        "cloudtrail:*",
        "guardduty:*",
        "config:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyBillingAccess",
      "Effect": "Deny",
      "Action": [
        "aws-portal:*",
        "budgets:*",
        "ce:*",
        "cur:*"
      ],
      "Resource": "*"
    }
  ]
}

Com essa boundary, mesmo que um desenvolvedor crie uma role com Action: *, ela nunca poderá modificar serviços de segurança, gerenciar IAM ou acessar dados de billing. A boundary funciona como uma "cerca" que não pode ser ultrapassada.

MFA: a camada essencial

A autenticação multifator e a medida de segurança com melhor relação custo-benefício. Na AWS, existem diferentes formas de implementar MFA:

  • Virtual MFA (TOTP): apps como Google Authenticator ou Authy. Mínimo aceitável.
  • FIDO2/WebAuthn: chaves de segurança físicas (YubiKey) ou biometria. Mais seguro, resistente a phishing.
  • MFA condicional: exija MFA apenas para operações sensíveis (exclusão de recursos, acesso a produção) usando a condition aws:MultiFactorAuthPresent.

Para Zero Trust completo, recomendamos MFA obrigatório para todos os acessos humanos e credenciais temporárias (STS) com duração máxima de 1 hora para acessos programáticos a ambientes de produção.

IAM Access Analyzer: validação contínua

O IAM Access Analyzer, complementado por ferramentas de observabilidade, identifica automaticamente recursos que estão compartilhados com entidades externas à sua conta ou organização. Ele analisa policies de S3, KMS, SQS, Lambda, IAM Roles e outros serviços para detectar acessos não intencionais.

Além disso, o Access Analyzer pode gerar políticas baseadas no uso real: ele analisa os logs do CloudTrail para identificar quais permissões uma role efetivamente utiliza e sugere uma política com least privilege real, não teórico.

"Zero Trust não é um produto que você compra, é uma filosofia que você implementa gradualmente. Comece pelo IAM, evolua para SCPs e Identity Center, e construa camadas de verificação em cada nível da sua arquitetura."

Checklist Zero Trust para AWS

  • Conta root protegida com MFA de hardware e sem access keys
  • IAM Identity Center configurado com MFA obrigatório
  • Sem usuários IAM de longa vida: use Identity Center ou roles com STS
  • SCPs aplicadas em todas as OUs com guardrails de segurança
  • Permission Boundaries para delegação segura de criação de roles
  • Todas as policies com conditions (região, MFA, IP, criptografia)
  • IAM Access Analyzer ativo e monitorado
  • CloudTrail habilitado em todas as regiões e contas. Veja também nosso guia completo de segurança na nuvem
  • Rotação automática de credenciais com Secrets Manager
  • IMDSv2 obrigatório em todas as instâncias EC2

Na Prática: implementação Zero Trust em empresa regulada

Uma operadora de saúde com dados de 500.000 beneficiários precisava atender requisitos da ANS e LGPD para acesso a dados sensíveis na AWS. O ambiente tinha 5 contas AWS sem Organizations, 47 usuários IAM com access keys e nenhuma política de menor privilégio.

  • Semana 1: criamos a estrutura de AWS Organizations com OUs separadas (Security, Production, Development, Sandbox). Migramos as 5 contas existentes e aplicamos SCPs para proteger serviços de segurança, bloquear uso de root e restringir regiões a sa-east-1.
  • Semana 2: configuramos IAM Identity Center com Okta como IdP externo, MFA FIDO2 obrigatório e Permission Sets granulares (ReadOnly, Developer, Admin, SecurityAuditor). Eliminamos todos os 47 usuários IAM e suas access keys.
  • Semana 3: implementamos Permission Boundaries para a equipe de desenvolvimento poder criar roles Lambda sem ultrapassar o perímetro de segurança. Usamos IAM Access Analyzer para gerar políticas baseadas no uso real dos últimos 90 dias do CloudTrail.
  • Semana 4: configuramos alertas automatizados para eventos de segurança: uso de root (mesmo bloqueado por SCP, o alerta serve como canário), criação de IAM users, mudanças em SCPs e acesso fora do horário comercial.
terminal 
# Gerar política de menor privilégio com IAM Access Analyzer
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::123456789:role/AppLambdaRole",
    "cloudTrailDetails": {
      "trails": [{
        "cloudTrailArn": "arn:aws:cloudtrail:sa-east-1:123456789:trail/org-trail",
        "allRegions": true
      }],
      "accessRole": "arn:aws:iam::123456789:role/AccessAnalyzerRole",
      "startTime": "2025-12-01T00:00:00Z",
      "endTime": "2026-03-01T00:00:00Z"
    }
  }' --region sa-east-1

# Listar todos os IAM users com console access (devem ser zero)
aws iam get-credential-report > /dev/null 2>&1
aws iam get-credential-report --query 'Content' --output text | \
  base64 --decode | awk -F',' '$4=="true" {print $1, "Console:", $4, "Keys:", $9}'

# Verificar IAM Access Analyzer findings (acessos externos)
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:access-analyzer:sa-east-1:123456789:analyzer/org-analyzer" \
  --filter '{"status": {"eq": ["ACTIVE"]}}' \
  --query 'findings[*].{Resource:resource,Type:resourceType,Principal:principal}' \
  --output table --region sa-east-1

Resultado: a empresa passou na auditoria da ANS com zero findings de acesso. O número de entidades IAM com permissões excessivas caiu de 47 para zero. O tempo médio de provisionamento de acesso para novos funcionários caiu de 3 dias (ticket manual) para 15 minutos (self-service via Okta + Identity Center).

KPIs para o Decisor

  • Usuários IAM com credenciais de longa vida (count): número de users com access keys ou console password. Target: zero (use Identity Center e roles STS).
  • Policies com wildcard (*) em Action ou Resource (count): número de políticas excessivamente permissivas. Target: zero em produção.
  • IAM Access Analyzer findings ativos (count): recursos compartilhados externamente. Target: zero findings não intencionais.
  • Tempo de provisionamento/desprovisionamento de acesso: de request até acesso funcional. Target: menos de 30 minutos com Identity Center.
  • MFA coverage (%): percentual de acessos humanos protegidos por MFA. Target: 100%.
  • Credenciais com mais de 90 dias sem rotação (count): Target: zero. Monitore com Config Rule access-keys-rotated.

Como a RFX Tecnologia pode ajudar

Implementar Zero Trust na AWS é uma jornada que exige planejamento e expertise. Confira nossos serviços de segurança avançada. Na RFX Tecnologia, ajudamos empresas a avaliar sua postura atual de IAM, desenhar a arquitetura de identidade com AWS Organizations e Identity Center, implementar SCPs e Permission Boundaries, e treinar equipes para operar com segurança.

Nosso IAM Assessment analisa mais de 100 controles de identidade e acesso no seu ambiente AWS e entrega um roadmap priorizado de melhorias. Agende uma consultoria gratuita para começar.

IAM Zero Trust Segurança AWS SCP Identity Center
Fale Conosco
Assessment gratuito do seu ambiente AWS
Agendar Agora