Hardening de segurança: KMS, IAM de mínimo privilégio e isolamento de rede

As lições 01 to 13 construíram um lake que funciona: buckets, formatos, Iceberg, ingestão, um catálogo, transformação, uma camada de consulta, um warehouse, orquestração, governança com Lake Formation e tratamento de PII. Tudo o que você construiu é também um conjunto de decisões que um atacante pode ler e que uma má configuração pode desfazer. Uma CMK cuja key policy nunca delegou para a conta, uma bucket policy que prende o tráfego a um VPC endpoint que ninguém usa, um SCP escrito com o operador estrito em vez de IfExists, uma Lambda de rotação faltando uma action do KMS: cada um falha de um modo que nomeia o último hop no erro, não o controle quebrado.

Esta lição endurece o lakehouse na ordem em que a própria orientação de segurança da AWS a descreve: identidades → chaves → defaults de storage → rede → guardrails de organização → secrets → auditoria. A regra de ensino: default não é enforced, allowed não é alcançável, e alcançável não é auditado. Todo número abaixo está datado de outubro de 2026, e todo esboço de policy é um que você pode colar num sandbox antes que ele toque em produção.

Nesta lição você vai:

• escolher entre chaves customer managed, AWS managed e AWS owned para cada classe de dados do lakehouse, e justificar com as necessidades de auditoria e de raio de explosão;
• compor key policy e IAM corretamente, delegação primeiro, allow de identidade segundo, deny explícito sempre vencendo, e escrever o fluxo de grant + grant token que a automação do Lake Formation e do Glue precisa;
• fazer a aritmética de custo do bucket key e mostrar o que a rotação re-criptografa e o que não re-criptografa;
• escolher chaves multi-Region apenas para os dois padrões para os quais elas existem: replicação cross-Region e consumidores cross-Region;
• aplicar service roles, external ID, condition keys, session policies e boundaries como um único sistema de mínimo privilégio;
• construir o controle de acesso do S3 em ordem de construção: Object Ownership, Block Public Access em nível de conta, statements deny-insecure, pinagem de rede, escopo por prefixo;
• precificar gateway endpoint vs interface endpoint vs NAT para o mesmo tráfego de S3, com números de outubro de 2026;
• escrever SCPs de data perimeter (negação de Região, negação de PutObject não criptografado, negação de ACL pública) com os operadores IfExists que impedem que eles quebrem Athena e Glue;
• ligar a rotação no Secrets Manager para credenciais JDBC do Glue, incluindo o grant do KMS que todo mundo esquece;
• entregar quatro artefatos JSON trabalhados: uma role de job do Glue de mínimo privilégio, uma role cross-account de S3+KMS com external ID, um conjunto de SCP e um selector de data events escopado do CloudTrail com sua conta;
• estudar o Security Lake da Siemens com 800 contas, uma caixa de atualização de outubro de 2026 com fontes, três verificações interativas, seis diagramas e onze questões no estilo de exame.

---

1. Contra o que o lake endurecido está se defendendo

O próprio enquadramento da AWS para o conjunto de controles desta lição é direto: a ameaça é "UNINTENDED DATA DISCLOSURE DUE TO MISCONFIGURATIONS", não uma exploração inédita, mas uma bucket policy que alguém copiou, uma key policy que ninguém editou, uma Região que alguém deixou aberta (sessão IAM301 do AWS re:Inforce 2023, deck em d1.awsstatic.com, acesso em 2026-10-11). Um data perimeter é "um conjunto de controles preventivos que ajuda a garantir que apenas suas identidades confiáveis acessem recursos confiáveis a partir de redes esperadas", e tem exatamente três áreas, identidade, recurso e rede (AWS Security Blog, Establishing a data perimeter on AWS, data da página 2025-08-28).

Dois hábitos fazem o resto desta lição funcionar. Primeiro, escreva denies, não só allows, a própria orientação do time do S3 no re:Invent é "Sempre bloqueie o acesso ('Deny') quando… a request não corresponder à sua policy" (STG304, deck do re:Invent 2024, acesso em 2026-10-11). Segundo, teste primeiro em uma conta non-production, os posts de data perimeter da AWS dizem isso explicitamente: "Recomendamos que você teste e implante essas policies em uma conta de teste antes de aplicá-las em uma conta de produção" (AWS Security Blog, 2024-11-13).

---

2. KMS para lakes: CMKs, AWS managed, AWS owned

2.1 Os três níveis de propriedade, nos eixos que importam para um lake

A documentação do KMS da AWS desenha os níveis por propriedade e visibilidade, não por força: "AWS KMS keys (KMS keys) are the fundamental logical entities of AWS KMS"; "AWS owned keys are KMS keys that AWS services use to protect your data… You can't view or manage AWS owned keys"; e "Resource policies for AWS managed keys are managed by the corresponding AWS service" (KMS Developer Guide: Concepts, acesso em 2026-10-11).

A regra do lakehouse: CMK quando você precisa provar quem descriptografou qual classe de dado; AWS managed quando conveniência basta e ninguém vai pedir para você enumerar decrypts. Nunca espere que uma AWS owned key apareça na sua lista de chaves: essa ausência é por design, não um bug (KMS concepts, acesso em 2026-10-11).

• 📚 Você sabia? O nível AWS managed no console é parcialmente legado: a documentação do KMS da AWS diz "As AWS managed keys que você vê no console são AWS managed keys legadas… os serviços da AWS usam um conjunto diferente de AWS managed keys daqueles que aparecem no console", e chaves legadas carregam o padrão de alias aws/service. É por isso que você consegue ver aws/s3 numa lista do console e ainda encontrar serviços criptografando discretamente com chaves que nunca lhe serão mostradas (KMS concepts, acesso em 2026-10-11).

2.2 A key policy é o portão; o IAM é o segundo portão

Quatro frases do guia de key policies decidem quase todo ticket de suporte do KMS com que você vai trabalhar:

1. "Key policies are the primary way to control access to KMS keys."
2. "Toda chave do KMS deve ter exatamente uma key policy, que é criada quando você cria a chave do KMS."
3. "Um principal do IAM na mesma conta da chave do KMS pode usar policies do IAM para permitir acesso à chave do KMS somente se a key policy da chave do KMS permitir o principal."
4. "…an IAM deny statement in an IAM policy takes precedence… you can use IAM deny statements in IAM policies to prevent principals in the same AWS account from using the KMS key, even if the key policy allows it." (KMS Developer Guide: Key policies, acesso em 2026-10-11)

Leia como dois portões que compõem em vez de empilhar: a key policy responde "esta conta ou role pode usar esta chave de jeito nenhum?"; o IAM responde "este chamador específico pode usá-la para esta action agora?" O uso cross-account é sempre via key policy: uma policy de identidade na outra conta é inerte até que a key policy do produtor a nomeie. E um deny do IAM manda independente do que a key policy disse.

Exemplo resolvido E1: uma key policy que realmente delega (S3 + Glue + um leitor cross-account)

Repare na forma: arn:aws:iam::<account>:root significa esta conta, via suas policies de IAM, não "o usuário root é privilegiado"; service principals recebem conditions aws:SourceAccount/aws:SourceArn para que o delegado não possa ser apontado para o bucket de outra pessoa; e o leitor cross-account recebe apenas decrypt, nunca kms:*. Se você trocasse o principal do primeiro statement por "*" teria o buraco canônico. Se você tivesse apenas um allow de IAM na conta 444455556666 e não o statement quatro, o analista falharia com um erro que nomeia kms:Decrypt e não lhe ensina nada (falha classe F1: "Habilitei a CMK mas o serviço ainda não consegue criptografar").

2.3 Grants e grant tokens: a camada de máquina para máquina

Grants são o canal de permissão temporária que serviços e fluxos de SDK usam em vez de reescrever sua key policy: "Um grant é uma forma alternativa de definir permissões para chaves do AWS KMS"; "Cada grant aplica-se a apenas uma chave do KMS"; "Você não pode usar um grant para negar acesso"; e "CreateGrant is the only AWS KMS API operation that returns a grant token" (KMS Developer Guide: Grants, acesso em 2026-10-11).

O token existe porque mudanças de grantee e de encryption context são eventualmente consistentes: "A grant token… makes the permissions specified in a grant available immediately rather than after eventual consistency", e a lista completa de grants se estabiliza "within five minutes". Passe o token para a chamada seguinte de Encrypt/GenerateDataKey ou seu grant recém-criado vai parecer quebrado por minutos.

Exemplo resolvido E2, o fluxo CreateGrant + token para um job de re-criptografia do Lake Formation / Batch

A sequência de chamadas importa mais que o JSON:

Use grants para exatamente três padrões de lakehouse: re-criptografias do S3 Batch Operations, fluxos de serviço que precisam de GenerateDataKey por dez minutos, e automação do Lake Formation / adjacente ao metastore onde você não pode se dar ao luxo de editar uma key policy por execução. A própria orientação da AWS é pareá-los com IAM e key policies em vez de substituí-los: "We recommend using IAM policies and key policies together… Consider using grants to give temporary permissions to applications that are running on EC2 instances" (KMS, key policy vs IAM policy, acesso em 2026-10-11). Um grant esquecido é um privilégio permanente, e RetireGrant/RevokeGrant são as APIs de limpeza, ninguém audita o que eles nunca listam.

• 📚 Você sabia? O KMS separa deliberadamente as permissões do lado de encrypt e do lado de decrypt para que um pipeline "somente escrita" seja expressível: GenerateDataKeyWithoutPlaintext retorna apenas a data key embrulhada, e o uso do plaintext ainda exige kms:Decrypt pelo chamador (AWS KMS service authorization reference, acesso em 2026-10-11). É por isso que uma role de job do Glue normalmente precisa de kms:Decrypt e kms:GenerateDataKey, enquanto uma role de ingestão que só embrulha pode receber o par mais estreito.

2.4 Bucket keys: o toggle de maior ROI em qualquer bucket de analytics

"Por padrão, o Amazon S3 criptografa todos os novos dados quando gravados em um bucket do S3": com SSE-S3 desde 2023-01-05, sem custo adicional, mas objetos sob uma chave de criptografia default do KMS "são cobrados pela taxa de requisição do KMS de $0.03 por 10,000 requisições, mais a cobrança padrão de requisição do S3, mesmo quando a criptografia é aplicada automaticamente" (S3: data protection; S3: Using SSE-KMS, acesso em 2026-10-11). O bucket key existe para colapsar essas chamadas: "Usar uma chave em nível de bucket para SSE-KMS pode reduzir os custos de requisição do AWS KMS em até 99 por cento diminuindo o tráfego de requisições do Amazon S3 para o AWS KMS" (S3: Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys, acesso em 2026-10-11).

Exemplo resolvido E3: aritmética de custo do bucket key num caminho de leitura quente de dashboard (em out de 2026)

Volumes menores ainda mostram a forma: 5,000 GETs de objeto criptografado custam $0.015 em requisições do KMS sem um bucket key, trivial, e é exatamente por isso que as equipes esquecem de habilitar o toggle até o tráfego do dashboard chegar. Duas exclusões para decorar: bucket keys não são suportadas para DSSE-KMS, e DSSE-KMS não é suportado para S3 Replication (páginas de bucket-key e Using SSE-KMS do S3, acesso em 2026-10-11), então você não pode empilhar features de "criptografia máxima".

2.5 Rotation: três significados diferentes, só um deles re-criptografa algo

A AWS declara o limite sem rodeios: "key rotation will not mitigate the effect of a compromised data key" (KMS, Rotating AWS KMS keys, acesso em 2026-10-11). A elegibilidade também é uma parede, não uma preferência: a rotação automática suporta apenas chaves do KMS de criptografia simétrica com key material gerado pelo AWS KMS (KeySpec SYMMETRIC_DEFAULT, KeyOrigin AWS_KMS), assimétricas, HMAC, material importado e custom key stores precisam de rotação manual ou sob demanda. Duas notas operacionais que valem carregar: backing keys se acumulam para que ciphertext antigo continue descriptografando, e "the first two rotation generations of backing keys incur a full monthly key charge" (mesma página), então uma frota de CMKs de longa duração é uma linha mensal pequena mas não zero.

2.6 Chaves multi-Region: para CRR e consumidores cross-Region, mais nada

"Chaves multi-Region são chaves do AWS KMS que têm o mesmo key material e o mesmo key ID em diferentes Regiões da AWS"; você cria uma primary numa Região e "replicar a MRK para a mesma conta da AWS em outras Regiões da AWS"; você não pode converter uma chave existente em uma multi-Region key nem voltar atrás; e "cada chave multi-Region conta como uma chave do KMS em sua conta para as quotas do AWS KMS e para calcular seus custos do AWS KMS" (KMS: Multi-Region keys, acesso em 2026-10-11). Réplicas carregam o prefixo mrk- em seus key IDs.

A recompensa do cross-Region replication do S3: "O AWS S3 criptografa cada versão de objeto com uma data key criptografada com a chave do KMS na Região de origem… Se você usa uma chave multi-Region relacionada, o Amazon S3 descriptografa e re-criptografa as data keys na Região de destino": a data key em plaintext nunca sai da Região de destino, e você evita o hop de chave cross-Region que pagaria de outra forma ao replicar para uma chave diferente.

Exemplo resolvido E4: conta do MRK e decisão de CRR (em out de 2026)

Duas arestas duras: uma chave SSE-KMS precisa estar na mesma Região do bucket ("quando você usa criptografia SSE-KMS com um bucket do S3, as chaves do AWS KMS devem estar na mesma Região do bucket": S3, acesso em 2026-10-11), e o key material de MRK não pode ser exportado. Se sua replicação é same-Region, pare de ler esta subsection e mantenha chaves single-Region.

2.7 A matriz de KMS por serviço

Leia esta tabela como "quem precisa estar na key policy, e o que o chamador precisa no IAM". Service principals e padrões de ARN recomendados vêm da página de integração de serviços do KMS (acesso em 2026-10-11).

• 📚 Você sabia? Uma security configuration do Glue são quatro coisas separadamente criptografáveis, e as equipes rotineiramente cobrem três: dados intermediários no S3, CloudWatch Logs, job bookmarks (apenas SSE-KMS) e shuffle/spill do Spark (apenas SSE-S3). Os bookmarks são o cavalo de Troia: um bookmark é o ponteiro do já processado, então deixá-lo no default é ao mesmo tempo um risco de correção e uma superfície de vazamento (docs de security-configuration do Glue, acesso em 2026-10-11).

---

3. Padrões de IAM: service roles, external ID, condition keys, sessions, boundaries

3.1 Service roles: a trust policy é a permissão

Todo engine deste curso roda sob uma service role cuja trust policy nomeia um service principal. O padrão é idêntico em toda a stack: o principal glue.amazonaws.com para jobs, lakeformation.amazonaws.com para a role de localização registrada, encryption.athena.amazonaws.com para criptografia de resultados do workgroup, redshift.amazonaws.com para caminhos de cluster, logs.amazonaws.com para criptografia de log group. A policy de identidade então faz o escopo: essa é a divisão de trabalho: a trust decide quem pode criar a session; a policy de identidade decide o que a session pode fazer.

A role do Lake Formation é o exemplo mais claro: "Lake Formation supplies temporary credentials that the caller, such as Amazon Athena, uses to access the data", e para localizações registrados no LF "You must specify an IAM role… This role is called the registered-location IAM role" (LF Developer Guide: Underlying data access permissions, acesso em 2026-10-11). Os consumidores (Athena, Redshift Spectrum, QuickSight) chamam lakeformation:GetDataAccess, e essa action precisa carregar Resource: "*" porque "AWS Lake Formation does not support specifying a resource ARN in the Resource element of the IAM policy" (LF service authorization reference, acesso em 2026-10-11).

3.2 External ID: o guard do confused deputy, na trust policy

"O problema do confused deputy é um problema de segurança que pode surgir quando um serviço é enganado a usar suas permissões em nome de outro principal", e "O external ID ajuda a evitar um confused deputy quando você usa a operação AssumeRole" (IAM User Guide: Providing access to third parties, acesso em 2026-10-11). Duas propriedades decidem onde ele pertence:

• A AWS "não trata o external ID como um segredo… não é um segredo, é um identificador compartilhado… deve ser único para o cliente", então ele autentica intenção, não identidade. A autenticação de verdade continua sendo o principal confiável na trust policy.
• O comprimento é de 2–1,224 caracteres (IAM quotas, acesso em 2026-10-11).
• Ele vive na trust policy da role sob sts:ExternalId: nunca na key policy do KMS e nunca numa policy de identidade. Colocá-lo na key policy é o erro de posicionamento mais comum de todos (classe F20).

Exemplo resolvido E5: a role cross-account de S3 + KMS com external ID

Três documentos precisam concordar: a bucket policy do produtor, a key policy do produtor, e a trust da role mais a policy de identidade do consumidor. Mais nada precisa de edição.

O lado do produtor (não repetido aqui) é dois statements no estilo do E1: uma bucket policy permitindo s3:GetObject/s3:PutObject em arn:aws:s3:::shared-bronze/ingest/* para arn:aws:iam::444455556666:role/lake-reader, e uma key policy delegando kms:Decrypt/kms:GenerateDataKey/kms:DescribeKey para o mesmo ARN de role. O parceiro então chama:

Se o seu consumidor é a sua própria segunda conta em vez de um terceiro, o external ID é opcional, mas é higiene barata, e tem 2 to 1,224 caracteres, é único por cliente e não é um segredo (IAM, third-party access, acesso em 2026-10-11). O que ele não é: um fator de autenticação. O ARN do principal confiável faz a autenticação; o external ID impede que um parceiro seja enganado ao assumir sua role quando pretendia a de outro cliente.

3.3 As condition keys que esta lição realmente usa

A regra de wildcard da página de condition keys do IAM é inegociável: "Don't use wildcard values (*) with aws:SecureTransport, aws:SourceIp, aws:SourceVpce, aws:SourceVpc, aws:PrincipalOrgID" (IAM: condition operators and keys, acesso em 2026-10-11).

3.4 Session policies e permission boundaries: a regra da interseção

Os três filtros de "permissão máxima" se comportam do mesmo jeito, e a redação da AWS é precisa:

• Permission boundary: "um recurso avançado para usar uma managed policy e definir as permissões máximas que uma policy baseada em identidade pode conceder a uma identidade do IAM"; "A permission boundary de uma entidade não concede à entidade nenhuma permissão" (IAM: permissions boundaries, acesso em 2026-10-11).
• Session policy: passada no AssumeRole, vale só para aquela session.
• SCPs: "elas especificam as permissões máximas para as contas membro"; "SCPs não concedem permissões… eles filtram" (Organizations: SCPs, acesso em 2026-10-11).

Avaliação: permissões finais = identidade ∩ recurso ∩ session ∩ boundary ∩ SCP, e qualquer deny explícito em qualquer policy aplicável vence. Boundaries são como você deixa um time de plataforma criar roles sem deixá-los escalar para iam:* ou kms:*; session policies são como uma role de job-runner pode receber um contexto mais apertado para uma execução.

Exemplo resolvido E6: boundary + session policy como uma interseção real

A armadilha documentada: "NotPrincipal… quando você usa NotPrincipal em um deny statement junto com uma permission boundary… o deny statement pode ser aplicado inesperadamente" (IAM: permissions boundaries, acesso em 2026-10-11). Prefira escopo positivo com Principal ou conditions aws:PrincipalArn a denies com NotPrincipal.

3.5 Exemplo resolvido E7: a role de job do Glue de mínimo privilégio, ponta a ponta

Um job, uma role, quatro coisas criptografáveis, zero wildcards. Essa é a metade de identidade de uma security configuration do Glue; a security configuration em si (S3 SSE-KMS + CloudWatch SSE-KMS + bookmark SSE-KMS, tudo na mesma CMK, tudo na mesma Região do job) é a metade de criptografia.

Trust policy da mesma role, e a única linha que torna tudo isso assumível:

O que torna isso mínimo privilégio em vez de "uma policy com uns ARNs nela": um ARN de chave, duas raízes de bucket com uma condition s3:prefix no List, um prefixo de log group que casa apenas com a security configuration deste job, um único database do Glue e um secret. Acrescente uma permission boundary (o teto do E5) por cima e nem um job comprometido consegue cunhar a si mesmo iam:*. O statement do KMS não é opcional: sem ele o job morre na primeira leitura criptografada com um erro que nomeia kms:Decrypt em vez do grant que falta (classe F1).

---

4. Hardening do S3, em ordem de construção

Controle de acesso num bucket de lake não é uma checklist que você completa em qualquer ordem; é uma pilha onde cada camada assume a de baixo. A ordem abaixo é a ordem própria do time do S3 no re:Invent (STG304, acesso em 2026-10-11): Block Public Access de conta e de bucket, Access Analyzer para achar exposição, Object Ownership com ACLs desabilitadas, bucket keys para SSE-KMS, gateway endpoints e policies deny-first.

4.1 Object Ownership: ACLs desligadas, o dono do bucket é dono de tudo

"Object Ownership is a bucket-level setting that you can use to disable access control lists (ACLs)… When Object Ownership is set to Bucket owner enforced, ACLs are disabled, and the bucket owner owns every object" (S3: Object Ownership, acesso em 2026-10-11). O caso de uso recomendado, nas palavras da AWS, inclui "data lakes". Duas consequências: um upload carregando headers de ACL devolve AccessControlListNotSupported (um delicioso incidente de "por que meu job de cópia começou a falhar"), e disputas cross-account de propriedade de objeto deixam de existir porque não sobra nada para disputar.

4.2 Block Public Access: quatro configurações, nível de conta, nível de organização

As quatro configurações são BlockPublicAcls (ACLs em nível de bucket e de objeto), IgnorePublicAcls (o S3 ignora grants públicos que encontra), BlockPublicPolicy (bucket policies que ficam públicas são rejeitadas com "Access Denied") e RestrictPublicBuckets ("mesmo que a bucket policy permita acesso público… o Amazon S3 não permite acesso público", enquanto acesso same-account não é bloqueado) (S3: Block public access, acesso em 2026-10-11). Duas regras de escopo decidem se seu controle realmente existe: as configurações em nível de conta "são aplicadas a todos os buckets da conta, mesmo aqueles criados depois que as configurações são ativadas", e "Você pode aplicar todas as configurações do Block Public Access como uma única policy unificada no nível do AWS Organizations". Deixar o BPA de nível de org desligado significa que todo bucket futuro nasce potencialmente público até que quatro toggles sejam virados por alguém que se lembre.

4.3 A bucket policy deny-first

Leia os dois últimos statements juntos: aws:SourceVpce está presente apenas quando a chamada veio por um endpoint, e aws:SecureTransport/aws:SourceIp/s3:TlsVersion são redigidos quando serviços da AWS chamam S3 em seu nome: "Para evitar esse comportamento, inclua a condition key aws:PrincipalIsAWSService definida como false no mesmo statement das condition keys" (S3: Amazon S3 policy keys, acesso em 2026-10-11). Sem esse carve-out você quebra Athena/Glue/Lake Formation silenciosamente ou acredita ter um bucket só-TLS que seu caminho de serviço ignora. E lembre: criptografia default não é enforcement: "Default ≠ enforced"; apenas o statement DenyUnencryptedPutObject torna o SSE-KMS obrigatório.

---

5. Isolamento de rede: gateway endpoints, PrivateLink, NAT e endpoint policies

5.1 Os três caminhos saindo de uma VPC, precificados

Gateway endpoints são "um dispositivo virtual de roteamento… você acessa o endpoint usando uma rota na sua route table", e você anexa uma endpoint policy para permitir ou negar (VPC: Gateway endpoints, acesso em 2026-10-11). Interface endpoints são faturados de outro jeito: "Endpoints são cobrados por cada hora em que estão disponíveis em cada Availability Zone, com hora cheia cobrada independentemente do uso" (AWS PrivateLink pricing, acesso em 2026-10-11).

Exemplo resolvido E8: NAT vs gateway endpoint para 500 GB/mês de tráfego de S3 (em out de 2026)

Essa é a economia clássica de lakehouse: grátis, e ainda compra uma condition key. Mantenha o NAT apenas para egress não-S3.

Exemplo resolvido E9: a conta real da stack privada (3 interface endpoints)

Misture deliberadamente: gateway para S3 e DynamoDB, interface apenas onde não existe gateway, e nunca assuma "VPC endpoint = grátis": só S3 e DynamoDB têm o free tier.

5.2 Endpoint policies: um quinto deny surface

Uma endpoint policy se aplica a chamadas que atravessam aquele endpoint, independentemente da policy de identidade, o que a torna o lugar natural para "não há deleção de chave a partir desta VPC" ou "apenas este secret". O próprio exemplo do Secrets Manager da AWS "allows secretsmanager:GetSecretValue on a specific secret ARN and denies secretsmanager:DeleteSecret" (Secrets Manager, VPC endpoints, acesso em 2026-10-11). Para o Lake Formation, o nome do serviço do endpoint é com.amazonaws.region.lakeformation, e endpoint policies chegaram junto com o suporte a PrivateLink em 2021-10-11, o exemplo escopa lakeformation:GetDataAccess, exatamente a chamada que cunha credenciais temporárias de S3/KMS (LF, Connecting via PrivateLink, acesso em 2026-10-11).

A armadilha aqui é real: uma endpoint policy é deny-by-default na prática: omita lakeformation:GetDataAccess de um endpoint do LF e o lakehouse para de emitir credenciais; negue s3:GetObject no ARN de bucket errado e toda consulta falha. Teste num sandbox (a própria instrução dos posts de data perimeter).

---

6. Data perimeters: SCPs, RCPs e as três áreas de controle

6.1 O modelo

"Um data perimeter é um conjunto de controles preventivos… identidade, recurso e rede", enforced através de "service control policies (SCPs) do AWS Organizations, resource control policies (RCPs) do AWS IAM e… endpoint policies de VPC", e a AWS é explícita de que ele "não é um substituto para… autorização de granulação fina" (AWS Security Blog, 2025-08-28; IAM, Data perimeter policies, acesso em 2026-10-11). Os três perímetros mapeiam para três perguntas:

SCPs são a mecânica estrutural, e sua semântica é o que as pessoas erram: "SCPs don't grant permissions, they filter… an SCP never grants permissions"; eles "don't affect resource-based policies"; "don't apply to users or roles in the management account"; e "don't apply to service-linked roles… or service principals" (Organizations: Service control policies, acesso em 2026-10-11).

6.2 A disciplina do IfExists

O SCP canônico do AWS Security Blog (2024-11-13) é construído com três operadores não-estritos por uma razão documentada: "aws:SourceVpc e aws:SourceVpce só estão presentes no contexto da request se a chamada foi feita por um endpoint de VPC". Tire o IfExists e você nega toda chamada de serviço AWS e toda chamada não-VPC: que é exatamente como um data perimeter derruba Athena, Glue e Lake Formation na sexta-feira.

Exemplo resolvido E10, o conjunto de SCPs de quatro statements (cole numa OU non-production primeiro)

Três pontos didáticos sobre este documento. Primeiro, o allow-list com NotAction do statement um para serviços globais (CloudFront, IAM, Organizations, Route 53, Support, STS) é a forma exata tanto do exemplo de region deny da documentação do IAM quanto do guardrail do Control Tower, "AWS Control Tower provides a region deny policy… You cannot exclude your home Region" (Control Tower, primary Region deny policy, acesso em 2026-10-11). Segundo, o statement dois pareia StringNotEquals com Null: true para que um cliente que envie nenhum header de criptografia também seja negado, as duas conditions juntas cobrem "algoritmo errado" e "sem algoritmo". Terceiro, o Deny em s3:PutBucketPublicAccessBlock impede desabilitar o BPA, não habilitá-lo; não confunda a direção. A AWS publica versões curadas de todas essas em aws-samples/service-control-policy-examples, cujo README diz que os exemplos são "a starting point… test in a non-production environment", faça fork deles, nunca escreva Deny * à mão numa organização de produção.

---

7. Rotação de secrets para credenciais JDBC do Glue

Uma conexão JDBC do Glue nunca deve segurar uma senha em plaintext: guarde-a no AWS Secrets Manager, criptografe-a com uma CMK e deixe o schedule de rotação fazer o trabalho. A rotação é um protocolo de quatro etapas com staging label, e a ordem não é decorativa:

1. createSecret: a Lambda cria a nova versão e move o staging label AWSCURRENT para ela;
2. setSecret: a Lambda diz ao banco de dados para mudar as credenciais;
3. getSecretValue com AWSCURRENT: a Lambda recupera e testa as novas credenciais;
4. removeSecret, o label AWSPREVIOUS e a versão antiga são apagados.

(Secrets Manager: Rotating secrets that use AWS Lambda, acesso em 2026-10-11.)

Exemplo resolvido E11: a role da Lambda de rotação para uma fonte JDBC do Glue

O exercício de falha que vale a pena rodar uma vez num sandbox: revogue o statement do KMS, dispare a rotação e veja-a falhar na etapa 3 com um erro que nomeia o secret ou o banco de dados em vez da chave. Depois restaure. Esse único experimento ensina o F25 melhor que qualquer tabela.

---

8. Auditoria: um org trail único, data events seletivos e a conta que você precisa escopar

O CloudTrail é o plano de evidência, e sua precificação tem uma armadilha: management events são baratos, data events não. "By default, CloudTrail doesn't log data events"; "Data events… are often high-volume activities… you are charged an additional fee for logging data events"; e você os seleciona com advanced event selectors, "You can't mix basic event selectors and advanced event selectors in a trail" (CloudTrail, Logging data events, acesso em 2026-10-11).

Exemplo resolvido E12: data events escopados e o que eles custam

• 📚 Você sabia? A proteção S3 do GuardDuty e seu próprio trail de auditoria são objetos diferentes. O GuardDuty "evaluates CloudTrail management events and CloudTrail data events for S3" e "enables its own trail for S3 protection, you don't need to configure CloudTrail data events yourself" (GuardDuty, S3 protection, acesso em 2026-10-11). Então um bucket pode ser monitorado enquanto seu trail de evidência não registra nada: detecção ≠ retenção de evidência. Mantenha seu próprio org trail com selectors escopos, envie-o para uma conta de logs separada, e proteja o bucket de logs com um SCP que nega s3:DeleteBucketPolicy e cloudtrail:StopLogging (Seção 6.2).

---

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

A AWS publica como esses controles se comportam em escala de produção. Todo número abaixo é afirmação do cliente ou da AWS e não auditado, com fonte e data nomeadas para você poder conferir, o ponto examinável é o padrão, não o marketing.

Caso A, Siemens: um data lake de segurança com 800 contas que se paga

A lição para este curso é estrutural: o funil da Siemens é o seu design de auditoria da Seção 8: um ponto de coleta em nível de organização no S3, um caminho de saída filtrado por endpoint e policy, e uma decisão por prefixo sobre o que recebe o tratamento caro. Repare também no que o caso não afirma: Security Lake é um serviço de agregação de logs de segurança, não AWS Lake Formation. As histórias de governança (IAS, FanDuel) pertencem à Lição 12; esta é sobre volume, retenção e o custo da evidência.

Caso B, USAA: meça o perímetro antes de impô-lo

Leia os 70% como um dado de caso de um deck público, não um benchmark de indústra. A lição durável é a sequência: analisar primeiro (CloudTrail Lake ou Athena sobre seus próprios eventos: lembre-se de habilitar os S3 data events, ou a análise não tem nada para ler), depois impor, depois medir de novo.

---

Perguntas de Prática (Practice Questions)