Compartilhamento seguro e acesso emergencial

Organizações modernas operam em múltiplas contas. Recursos (subnets, buckets, datasets) frequentemente precisam ser usados por outras contas ou parceiros. A pergunta não é "copio?" — é "como compartilho com segurança?".

O AWS Resource Access Manager compartilha recursos entre contas da mesma AWS Organization sem duplicação nem policies manuais. Suporta:

• Subnets VPC — conta A cria a VPC, conta B usa as subnets.
• Transit Gateway attachments.
• License Manager configs.
• Route 53 Resolver rules.
• Vários outros.

Benefício: centralização real da infraestrutura compartilhada. Quem usa o recurso vê-o como se fosse da própria conta.

O padrão universal: conta B cria uma role, cuja trust policy permite a conta A assumi-la.

1
2
3
4
5
6
7
8
9

// Trust policy da role (conta B)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::AAAAAAAAAAAA:root" },
    "Action": "sts:AssumeRole"
  }]
}

A identidade na conta A chama sts:AssumeRole e recebe credenciais temporárias para operar como essa role na conta B.

Quando você compartilha acesso com um parceiro SaaS (vendor de monitoring, consultoria, etc.), não confie só na conta. Use external ID para prevenir confused deputy:

1
2
3
4
5
6
7
8

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::TERCEIRO:role/MonitoringRole" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "unique-per-customer-e9f2a1b4" }
  }
}

Para buckets S3 entre contas:

• Bucket policy na conta dona lista o principal da outra conta.
• Identity policy na outra conta permite s3:GetObject no bucket.
• Lembre: cross-account é interseção (Lição 11).

Para datasets estruturados, considere AWS Lake Formation (governança de dados) ou DataZone, que trazem controle fino por coluna/linha.

Acesso muda com o tempo:

• Joiner: pessoa nova chega. Deve ter acesso mínimo desde o dia 1, provisionado via IdP e grupos.
• Mover: pessoa muda de time. Acesso antigo deve ser revogado ao receber o novo.
• Leaver: pessoa sai. Tudo revogado imediatamente — user no IdP, access keys, CI/CD credentials, segredos específicos.

Na prática: centralize em IAM Identity Center + IdP corporativo para que mudanças no HR/IdP se propaguem automaticamente. Use Unused Access Analyzer para detectar "leavers" esquecidos.

Quando o provedor de identidade falha (SAML fora do ar, SSO quebrado), você ainda precisa operar. Tenha um processo de break-glass:

1. Um pequeno número de IAM Users com MFA de hardware, credenciais em password manager corporativo (ou cofre físico em empresas grandes) com acesso restrito e auditado.
2. Uso exige aprovação humana documentada (ticket).
3. Toda ação do break-glass gera alerta automático (CloudWatch alarm em CloudTrail).
4. Senha e MFA rotacionadas após cada uso.
5. Acesso auditado trimestralmente.

Dentro da org: RAM. Entre contas: AssumeRole. Com terceiros: AssumeRole + ExternalId. Lifecycle: automatize via IdP. Emergência: break-glass com auditoria.

Você completou o nível Avançado. Se quiser ir além, o Módulo 5 — Especialista traz casos reais de produção: KMS cross-account, serviços agindo por você, perímetro de dados e armadilhas de condições.

Esta lição está alinhada com várias boas práticas do Well-Architected Framework: Establish emergency access process, Manage access based on lifecycle, Share resources securely within your organization e Share resources securely with a third party.

• Ver Emergency access process no Well-Architected Framework
• Ver Manage access based on lifecycle no Well-Architected Framework
• Ver Share within organization no Well-Architected Framework
• Ver Share with third party no Well-Architected Framework

• AWS Resource Access Manager
• Granting access via external ID
• Cross-account access to third party