Data perimeter com RCPs e condições de Org

Um data perimeter é um conjunto de guardrails preventivos que garante uma frase simples:

• SCP limita o que os principais das suas contas podem fazer, em qualquer recurso. Ideal para o perímetro de recurso: "minhas roles não escrevem em bucket de fora".
• RCP (Resource Control Policy) limita o que qualquer principal, inclusive de fora da org, pode fazer nos recursos das suas contas. Ideal para o perímetro de identidade: "ninguém de fora lê meus buckets, mesmo que alguém erre uma bucket policy".

Como SCPs, RCPs nunca concedem permissão; só definem o teto. Valem só para serviços suportados (S3, KMS, STS, SQS, Secrets Manager e uma lista que cresce; confira a documentação atual).

Baseada nos exemplos oficiais de data perimeter da AWS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceOrgIdentities",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:*", "kms:*", "sqs:*", "secretsmanager:*", "sts:AssumeRole"],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-exemplo" },
        "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
      }
    }
  ]
}

Leia as duas condições juntas (AND). O Deny se aplica quando:

1. o principal não é da org o-exemplo (ou não tem org), e
2. o principal não é um service principal da AWS.

A RCP acima libera todo service principal. Para fechar a brecha da lição 18, adicione um segundo statement exigindo que o serviço aja em nome de um recurso da sua org:

1
2
3
4
5
6
7
8
9
10
11
12

{
  "Sid": "EnforceConfusedDeputyProtection",
  "Effect": "Deny",
  "Principal": "*",
  "Action": ["s3:*", "kms:*", "sqs:*", "secretsmanager:*"],
  "Resource": "*",
  "Condition": {
    "StringNotEqualsIfExists": { "aws:SourceOrgID": "o-exemplo" },
    "Null": { "aws:SourceAccount": "false" },
    "Bool": { "aws:PrincipalIsAWSService": "true" }
  }
}

Só se aplica a service principals (Bool: true) que trazem um recurso de origem (Null: false), e nega se esse recurso não for da sua org.

O padrão Principal: "*" + aws:PrincipalOrgPaths numa key policy é um Allow por perímetro. Funciona bem para roles e usuários das OUs, mas:

• aws:PrincipalOrgPaths é multivalorada: use ForAnyValue:StringLike com o caminho completo (o-xxx/r-xxx/ou-xxx/.../*). A lição 20 explica o porquê.
• aws:PrincipalOrgID é single-valued: use StringEquals, sem ForAnyValue.
• Não dependa desse Allow para serviços agindo por você. Cite a SLR ou o service principal explicitamente, e em cross-account use grant (lição 17).

1. Comece por uma conta de teste, depois uma OU pequena e, por último, a raiz.
2. Monitore AccessDenied no CloudTrail antes e depois de cada etapa.
3. Mapeie integrações de terceiros (SaaS, parceiros) que precisam de exceção.
4. Use IAM Access Analyzer (external access) para descobrir quem já acessa de fora.

Perímetro de identidade com RCP, perímetro de recurso com SCP e perímetro de rede com ambos. Sempre trate service principals à parte (IfExists + PrincipalIsAWSService) e proteja contra confused deputy com aws:SourceOrgID. Implante de baixo para cima, observando o CloudTrail.

Alinhada com Define permission guardrails for your organization e Share resources securely within your organization.

• Ver Define permission guardrails no Well-Architected Framework
• Ver Share within organization no Well-Architected Framework

• Resource control policies (RCPs)
• Data perimeters on AWS
• aws-samples/data-perimeter-policy-examples
• AWS global condition context keys