Segurança, IAM e conformidade para cargas de trabalho de IA

Segurança é o segundo domínio mais pesado do exame AIF-C01: o Domínio 2 "Segurança, Conformidade e Governança" carrega 24% da pontuação, de um exame de 65 questões (50 pontuadas + 15 não pontuadas) sem penalidade por chute. O que o torna difícil não é o vocabulário: é que a AWS enquadra o mesmo requisito em quatro lugares diferentes, e o exame recompensa você por saber qual lugar é autoritativo. "O Bedrock é compatível com HIPAA?" tem uma resposta correta diferente dependendo de se você lê uma página de marketing, a documentação do próprio serviço ou a tabela AWS Services in Scope.

Ao final desta lição você será capaz de:

• nomear cada tipo de role de IAM que uma carga de trabalho de IA pode usar e dizer quem o assume;
• escrever um SageMaker execution role de mínimo de privilégio e explicar por que AmazonSageMakerFullAccess ainda precisa de um segundo statement de S3;
• aplicar a regra de cross-account corretamente: um Allow é necessário tanto na policy de identidade quanto na policy de recurso;
• escolher entre SSE-S3 e SSE-KMS (e saber quando apenas um é possível);
• projetar uma VPC privada de ML: gateway endpoint vs. interface endpoint vs. NAT, e por que endpoints SageMaker precisam de duas subnets em duas Availability Zones;
• separar os eventos de gerenciamento do CloudTrail dos data events para bedrock-runtime, bedrock-mantle e SageMaker;
• provar uma afirmação de conformidade do jeito da AWS: Services in Scope → AWS Artifact → BAA para serviços elegíveis a HIPAA;
• defender o veredito comparativo: IAM vs. chaves compartilhadas, VPC endpoint vs. NAT, SSE-KMS vs. SSE-S3.

---

1. Responsabilidade compartilhada, e o que a "segurança de IA" adiciona

1.1 A frase que a AWS realmente publica

A própria documentação de segurança do Amazon Bedrock não lhe entrega uma checklist. Ela diz que a responsabilidade "é determinada pela sensibilidade dos seus dados, pelos objetivos de conformidade da sua empresa e pelas leis e regulamentações aplicáveis". Essa frase é a filosofia inteira: a AWS protege a infraestrutura e o serviço, você protege o que você coloca nele e quem tem permissão para tocá-lo: e a sensibilidade de uma carga de trabalho de IA (prompts, embeddings, dados de fine-tuning, saídas do modelo) é a variável que o exame continua testando.

1.2 A divisão, camada por camada

• 📚 Você sabia? A AWS publica 143 ofertas de conformidade em seus serviços. A contagem é um distrator de propósito: o exame nunca pergunta o total, ele pergunta se este serviço específico está no escopo deste programa específico: e a única resposta autoritativa é a tabela AWS Services in Scope by Compliance Program, não uma página de marketing do serviço.

1.3 A primeira armadilha: "certificado HIPAA" não existe

Não existe certificação HIPAA para a AWS, para o Amazon Bedrock, para o SageMaker, ou para qualquer provedor de serviço em nuvem. A redação correta, e a redação que o exame usa, é:

1. assine um Business Associate Agreement (BAA) com a AWS, e
2. use apenas serviços elegíveis a HIPAA para armazenar ou processar informações de saúde protegidas (PHI).

A AWS ainda mapeia a HIPAA Security Rule para FedRAMP e NIST SP 800-53 (orientação para a qual é SP 800-66), e é por isso que esses dois nomes aparecem juntos em toda opção correta de HIPAA.

---

2. Identidade: os roles atrás de cada job de IA

2.1 Os tipos de role, em uma tabela

O próprio SageMaker documenta quatro tipos de role, e o Bedrock adiciona mais dois. Aprenda quem assume cada um: é isso que a questão sempre testa.

Dois detalhes que valem a pena memorizar:

• ExecutionRoleSessionNameMode = USER_IDENTITY coloca o usuário final (não um nome de job compartilhado) no CloudTrail: a configuração que transforma "o job fez isso" em "as credenciais de Priya fizeram isso".
• As personas do Role Manager são Data scientist, MLOps e SageMaker AI compute: três roles, não uma lista de texto livre.

2.2 Exemplo 1: um SageMaker execution role de mínimo de privilégio

Quatro statements, uma conta (111122223333), um bucket (acme-ml-artifacts), uma Região (us-east-1). Compare isto com a managed policy da próxima subseção: a diferença é a resposta do exame.

2.3 A ressalva de S3 do AmazonSageMakerFullAccess

A AWS documenta uma restrição específica dentro do AmazonSageMakerFullAccess: certas ações de S3 são concedidas apenas em buckets e objetos cujos nomes contêm SageMaker, Sagemaker, sagemaker ou aws-glue, além de uma lista curta de ações que se aplicam a qualquer recurso S3. Consequências:

• um bucket chamado acme-ml-artifacts não é coberto: você precisa anexar uma segunda policy, exatamente como no Exemplo 1;
• uma opção afirmando que "FullAccess concede s3:* em cada bucket da conta" é falsa;
• uma opção afirmando que "FullAccess não concede permissões de S3" é igualmente falsa.

A lição prática é mais ampla que o S3: uma managed policy é um ponto de partida, não um design. O exame recompensa repetidamente o candidato que diz "policy gerenciada pelo cliente com escopo no ARN do recurso".

2.4 Exemplo 2: permitir uma família de modelo, negar outra

Note o acoplamento: negar InvokeModel mais InvokeModelWithResponseStream também nega Converse/ConverseStream, porque os últimos são construídos sobre os primeiros. Para impor isso em toda a organização você sai do limite da conta e escreve um SCP sobre bedrock:Invoke*, bedrock:Converse* e sagemaker:InvokeEndpoint*.

2.5 Exemplo 3: um Bedrock service role de customização que resiste ao confused deputy

Três hábitos estão empacotados nesta policy:

1. aws:SourceAccount na policy de confiança: o guarda de confused-deputy que a AWS recomenda para todo Bedrock service role (customização, importação, lote, agents, knowledge bases, Flows, avaliações);
2. aws:SourceArn por cima dele para escopo em nível de job;
3. para o Bedrock especificamente, iam:PassedToService = bedrock.amazonaws.com onde o chamador passa um role: e um statement correspondente de policy de chave para que o KMS realmente permita o job.

2.6 Como uma requisição é avaliada: tudo limita, nada concede

A regra que o exame continua reenunciando: uma permissions boundary, uma service control policy (SCP) e uma resource control policy (RCP) todas limitam as permissões máximas possíveis: nenhuma delas concede nada. Uma boundary sem nenhuma policy de identidade anexada dá a um usuário permissões efetivas zero, não as permissões da boundary.

2.7 Exemplo 4: uma permission boundary limitando um desenvolvedor de ML

Permissão efetiva = policy de identidade ∩ boundary. O desenvolvedor mantém o que quer que a policy de identidade dele permita, mas nunca pode exceder estes quatro serviços, e nunca pode deletar um modelo ou um endpoint mesmo que a policy de identidade diga sagemaker:*.

Ordene as etapas de construir esse role:

---

3. Identidade no Bedrock: policies gerenciadas, policies de recurso e cross-account

3.1 Sete policies gerenciadas, e suas datas

O Amazon Bedrock entrega 7 policies gerenciadas pela AWS, e o exame gosta da linha do tempo:

3.2 Baseada em identidade e baseada em recurso, e por que guardrails precisam de ambas

O Bedrock aceita policies baseadas em identidade (quem você é) e policies baseadas em recurso (qual objeto está sendo tocado). Guardrails e inference profiles aceitam policies de recurso, e a AWS afirma que uma policy de recurso é obrigatória para aplicação em nível de organização: para impedir que uma organização inteira invoque um modelo sem um guardrail anexado, você anexa uma policy de recurso avaliada com bedrock:GuardrailIdentifier e a sustenta com um SCP. Uma policy de identidade sozinha não pode expressar "este guardrail deve estar presente".

3.3 Cross-account: o Allow deve existir nos dois lados

Concretamente, para um bucket S3 compartilhado e um guardrail compartilhado:

1. A conta B (444455556666) cria role/CrossAccountBedrock confiando em {"AWS":"arn:aws:iam::111122223333:root"} e coloca uma policy de recurso no bucket/guardrail permitindo a conta A;
2. A conta A anexa uma policy de identidade com {"Action":"sts:AssumeRole","Resource":"arn:aws:iam::444455556666:role/CrossAccountBedrock"};
3. ambos os Allows são necessários: para KMS você deve passar seu próprio CMK, porque uma policy de chave S3 gerenciada pela AWS não pode ser compartilhada daquela forma.

Exemplo 5: a metade que falta: a policy de recurso no bucket da conta B.

A conta 111122223333 (identidade) mais este statement em 444455556666 (recurso) = os dois Allows que a regra exige; o segundo statement ainda impõe TLS em trânsito no bucket.

3.4 Permission boundaries, SCPs e RCPs comparados

• 📚 Você sabia? O recurso Role Manager e o caminho do service-linked role estão ambos ligados ao Studio Classic. No Studio (a experiência atual) você atribui roles de domínio, espaço e usuário por persona: e é por isso que uma opção descrevendo "deixar o SageMaker criar o role automaticamente" é uma resposta de Studio Classic, e uma opção descrevendo três personas é uma resposta de Role Manager.

---

4. Criptografia: em repouso e em trânsito

4.1 Em trânsito: TLS 1.2 é o número

A AWS declara TLS 1.2 como o mínimo em trânsito para estes serviços. No CloudTrail você pode verificar a versão negociada através de tlsDetails.tlsVersion. Qualquer opção oferecendo "TLS 1.0 ou superior", "SSL" ou "apenas TLS 1.3" está errada em direções opostas.

4.2 Em repouso: padrões, opções e as duas exceções

Duas exceções carregam peso desproporcional no exame:

1. Um volume SageMaker sem chave recebe uma chave transitória que é descartada após a criptografia: então "volumes do SageMaker são não criptografados" é falso, e "você deve fornecer uma chave KMS" também é falso.
2. Acesso cross-account ao S3 precisa do seu CMK. Se a conta A lê o bucket da conta B, a política de chave padrão gerenciada pela AWS da conta B não vai cooperar; a conta A deve fornecer e controlar uma chave gerenciada pelo cliente.

4.3 Escolhendo entre SSE-KMS e SSE-S3 em uma frase

SSE-S3 é o padrão, não tem sobrecarga de gerenciamento de chave e não tem cobranças de requisição do KMS; SSE-KMS lhe dá uma chave gerenciada pelo cliente com uma trilha de auditoria no CloudTrail, policies e grants de chave e rotação por chave: e é a única maneira de satisfazer um requisito cross-account ou uma política que exige aplicação de CMK. Regras do AWS Config como sagemaker-endpoint-config-kms-key-required e sagemaker-featuregroup-encryption-at-rest existem precisamente para detectar quando você manteve o padrão.

---

5. Isolamento de rede: VPCs, gateway endpoints e PrivateLink

5.1 O contrato do VpcConfig

O VpcConfig do SageMaker aceita 1 to 16 subnets e 1 to 5 security groups, e o SageMaker cria elastic network interfaces (ENIs) em cada subnet. A regra rígida que os candidatos perdem:

Um endpoint SageMaker precisa de pelo menos 2 subnets em pelo menos 2 Availability Zones: mesmo que você lance uma única instância.

Jobs de treinamento precisam de pelo menos 2 IPs privados por instância (pelo menos 5 com EFA), e o security group deve permitir TCP 443 de entrada no caminho da ENI.

5.2 Os sete serviços PrivateLink do Bedrock

Com PrivateLink você obtém: sem internet gateway, sem NAT, sem requisito de VPN ou Direct Connect, e sem IPs públicos. DNS privado habilitado significa que seu código não muda; DNS privado desabilitado significa que você reescreve as chamadas para {vpce-id}.bedrock-runtime.{region}.vpce.amazonaws.com. O security group do endpoint deve permitir 443 de entrada, e você pode anexar uma policy de endpoint custom para restringir quais ações ou ARNs de modelo são alcançáveis.

5.3 Quatro padrões VPC e o que eles custam

5.4 Exemplo 6: um layout funcional de Bedrock + SageMaker privado (Padrão B)

1. 10.20.0.0/16 com privada 10.20.1.0/24 (AZ-a) e 10.20.2.0/24 (AZ-b); sem rota de IGW, sem NAT;
2. S3 gateway endpoint anexado a ambas as tabelas de rotas, com uma policy de endpoint limitada a arn:aws:s3:::acme-*;
3. interface endpoints em ambas as subnets para bedrock-runtime, bedrock, sagemaker, sagemaker.api, sagemaker.runtime, ecr.api, ecr.dkr, logs e kms; security group do endpoint com 443 de entrada de 10.20.0.0/16;
4. VpcConfig = {Subnets:[a,b], SecurityGroupIds:[sg-ml]}; egress de sg-ml limitado a 443 em direção ao security group do endpoint; notebook DirectInternetAccess = Disabled;
5. fluxo: usuário do Studio → ENI do SageMaker → ENI do endpoint → Bedrock runtime pela rede da AWS com TLS 1.2. O CloudTrail registra a chamada como um evento de gerenciamento na Região de origem, e o GuardDuty AI Protection o lê através de seu canal service-linked. Fallback (Padrão C) adiciona um IGW, subnets públicas e um NAT gateway apenas quando uma dependência não tem interface endpoint.

5.5 A arquitetura segura de VPC / ML

---

6. Auditoria: CloudTrail, log de invocações, GuardDuty e Config

6.1 Eventos de gerenciamento vs. data events: a linha grátis/pago

Eventos de gerenciamento são gratuitos e ligados por padrão; data events são opt-in e cobrados. O histórico de eventos do CloudTrail retém 90 dias de eventos de gerenciamento no console.

6.2 O log de invocação de modelo é uma chave separada, e está desligado

O model invocation logging do Bedrock está desligado por padrão. Quando você o habilita:

• os destinos são CloudWatch Logs e/ou S3, e eles devem estar na mesma conta e na mesma Região;
• um corpo inline de prompt/conclusão de ≤100 KB é armazenado inline: corpos maiores vão para um prefixo S3 sob data/;
• o log não é CloudTrail: o CloudTrail lhe diz quem chamou o quê, o log de invocação lhe diz o que foi dito.

6.3 GuardDuty AI Protection

O AI Protection do GuardDuty lê data events do Bedrock, AgentCore e SageMaker mais eventos de gerenciamento, através de um canal service-linked do CloudTrail que o GuardDuty cria para você. Achados notáveis:

Estes são achados e alertas, não bloqueios: o GuardDuty lhe diz que um guardrail foi intervido; apenas o próprio guardrail bloqueia conteúdo.

6.4 AWS Config: regras e packs para IA

Regras do Config com prefixo sagemaker- incluem:

• sagemaker-notebook-no-direct-internet-access
• sagemaker-notebook-instance-inside-vpc
• sagemaker-endpoint-config-kms-key-required
• sagemaker-featuregroup-encryption-at-rest

E há três conformance packs voltados para IA: Best Practices for Amazon Bedrock, Best Practices for Amazon SageMaker AI e Best Practices for AI/ML Supporting Infrastructure. O controle 3.1.1 do NIST SP 800-171 mapeia para sagemaker-notebook-no-direct-internet-access, e a AWS afirma que templates de exemplo não garantem passar em uma auditoria de conformidade.

• 📚 Você sabia? Uma remoção de Guardrail e uma virada do log de invocação de modelo para desabilitado são ambos tratados como eventos de segurança pelo plano Foundational do GuardDuty. Isso é incomum, a maioria do "configuration drift" só é visível no Config, e é uma forte dica de que o exame considera "desligar discretamente sua rede de segurança" um ato de ataque, não uma tarefa de administração.

6.5 Painel de status (outubro de 2026)

---

7. Conformidade: HIPAA, AWS Artifact e o que o Bedrock realmente publica

7.1 A única cadeia autoritativa

Três regras saem desse diagrama:

1. AWS Services in Scope é a única tabela autoritativa de "está coberto": ✓ significa in scope nos relatórios atuais;
2. AWS Artifact é onde os relatórios reais de SOC / ISO / FedRAMP vivem: nunca uma página de serviço, nunca um link de console rotulado "Compliance";
3. para HIPAA você precisa de um BAA mais serviços elegíveis a HIPAA; a AWS mapeia a Security Rule para FedRAMP + NIST 800-53.

7.2 O que o Amazon Bedrock publica

O conjunto de conformidade publicado do Amazon Bedrock é: ISO, SOC, CSA STAR Level 2, GDPR, HIPAA eligible e FedRAMP High no AWS GovCloud (US-West): mais uma matriz FedRAMP por modelo (publicada em 18 de setembro de 2026) cobrindo modelos Classe C/D e IL4/IL5.

7.3 Números que valem a pena carregar para o exame

• 📚 Você sabia? A frase "in scope" tem um significado preciso: ela diz que o serviço foi incluído no relatório do auditor para aquele período: não que a sua carga de trabalho está em conformidade. É por isso que toda opção de conformidade que diz "habilitar o GuardDuty alcança conformidade com HIPAA" é falsa: você pode estar in scope e ainda falhar com suas próprias obrigações sob o modelo de responsabilidade compartilhada.

---

8. Governança de dados: retenção, residência e moderação de conteúdo

8.1 Modos de retenção do Bedrock

Os modos de retenção são none, default, aws_review, provider_data_share e inherit, com o escopo fluindo projeto → conta → padrão do modelo, por Região, sem propagação entre Regiões. Os fatos examináveis:

• aws_review mantém os dados dentro do limite da AWS por ≤30 dias e ele nunca é dado ao provedor do modelo;
• as condition keys do plano de controle são bedrock:DataRetentionMode / bedrock-mantle:DataRetentionMode, aplicáveis com SCP e IAM;
• dados de fine-tuning são usados apenas para fazer fine-tuning, nunca para treinar os modelos Titan base, e nada é armazenado após o job, mas o modelo com fine-tuned ainda pode replay-los, então filtre ou delete linhas sensíveis antes de começar;
• no lançamento não há UI de console para modos de retenção: apenas API/SDK.

8.2 Exemplo 7: aplicando retenção zero de dados em toda a organização (SCP)

Efeito: apenas none pode ser definido; um modelo que requer aws_review então retorna ValidationException / status: unavailable. A variante do plano de controle troca para bedrock:PutAccountDataRetention e bedrock:DataRetentionMode.

8.3 Inferência cross-Region: Geographic vs Global

O CloudTrail registra a chamada na Região de origem. Nenhum dos modos adiciona um sobrepreço de roteamento, e nenhum suporta Provisioned Throughput.

8.4 Moderação de conteúdo: a caixa de ferramentas completa

Específicos dos Guardrails do digest: 6 categorias de filtro, Hate, Insults, Sexual, Violence, Misconduct e Prompt Attack, mais o tier CLASSIC|STANDARD e mensagens de resposta bloqueada de 1 to 500 caracteres. A detecção de PII é ML probabilística, e é exatamente por isso que você pode escolher mascarar em vez de bloquear.

8.5 Limites de moderação do Rekognition

DetectModerationLabels aceita apenas JPEG e PNG, usa uma taxonomia de 3 níveis com MinConfidence padrão de 50%, e funciona com o Amazon A2I para revisão humana. O limite rígido que a AWS declara por escrito: as APIs não detectam conteúdo ilegal como CSAM: nenhum limiar de confiança conserta isso, e nenhuma opção de exame deve afirmar o contrário.

• 📚 Você sabia? A própria orientação de guardrails da AWS diz: "Desabilite o Invocation Logs se você não quiser que conteúdo bloqueado apareça como texto simples nos logs." Em outras palavras, o log que você habilita para auditoria pode se tornar o lugar onde o próprio conteúdo que você bloqueou é armazenado verbatim: um trade-off de design genuíno, e um caso raro em que a AWS recomenda explicitamente desligar um recurso de log.

---

9. Veredito comparativo

---

10. Armadilhas do exame e os números que valem a pena memorizar

10.1 Os números testáveis

10.2 Sinalizado como não verificado nesta lição

Para evitar que uma lacuna de pesquisa vire uma resposta errada: escopo PCI DSS do Amazon Bedrock (ausente das próprias páginas do Bedrock); elegibilidade HIPAA do SageMaker (a HIPAA Eligible Services Reference não foi recuperada); disponibilidade por Região do GuardDuty AI Protection; conteúdo por regra dos três conformance packs de IA; preços exatos para NAT gateways, interface endpoints, PrivateLink e GuardDuty AI Protection (as afirmações de custo aqui são direcionais); pesos por tópico do AIF-C01 (apenas os pesos de domínio 20/24/28/14/14 são publicados); e disponibilidade do Role Manager para novos clientes. Trate cada um deles como "verifique a página de origem antes de afirmar".

---

Casos Reais

Cinco histórias de clientes publicadas pela AWS, recuperadas para este curso em 6 de outubro de 2026, exercitam controles do Domínio 2 em produção. Leia-as como evidência, não marketing: toda porcentagem abaixo é um número alegado pelo cliente/pela AWS, não auditado, e apenas a Sun Finance (n = 585 imagens) e a Adobe (seu próprio conjunto de teste) divulgam uma base amostral. O exame não pedirá que você memorize estes números: ele pede que você reconheça qual controle cada um deles prova.

Evidência de estudos de caso para o Domínio 2

O que os casos realmente provam

Os padrões de falha são tão examináveis quanto os sucessos: inferência DIY (a Forethought abandonou sua própria stack Amazon EKS por multi-model endpoints do SageMaker em −66% e Serverless Inference em ≈−80%), OCR só com LLM (Sun Finance, acima) e visão computacional custom in-house (Chronomics, quatro meses contra três a quatro semanas). Cada um é uma questão sobre escolher o nível certo, que é Domínio 1: mas cada um também tem uma cauda do Domínio 2: quem é dono das credenciais, onde os dados ficam, e que evidência você pode produzir depois.

• 📚 Você sabia? A AWS publica exatamente uma taxa de resultado de projeto: 65% dos projetos do Generative AI Innovation Center chegaram à produção em 2025 (alguns em apenas 45 dias), de mais de 1.000 implementações e organizadas em torno do framework dos Cinco Vs: Value → Visualize → Validate → Verify → Venture. Os outros 35% não foram a produção. Qualquer opção afirmando que "todos os pilotos de IA generativa da AWS têm sucesso" contradiz o próprio blog da AWS.

---

Regulação e mudanças de serviços AWS

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

Tudo abaixo foi verificado para este curso em 6 de outubro de 2026 e vem de fontes de primeira party: a página de framework regulatório da Comissão Europeia, os próprios avisos de certificação e disponibilidade de serviços da AWS e as páginas de produto da AWS. As datas são escalonadas, e colapsá-las é o jeito clássico de perder esta marca.

Tetos de penalidade sob o EU AI Act:

Dois frameworks de governança ficam atrás destas datas e ainda são voluntários: o NIST AI Risk Management Framework (AI 100-1, jan de 2023: Govern, Map, Measure, Manage, 19 categorias / 72 subcategorias) com seu Generative AI Profile NIST AI 600-1 (jul de 2024, 12 riscos), e ISO/IEC 42001:2023 (dez de 2023), o primeiro Sistema de Gestão de IA certificável. A posição da AWS sobre tudo isso é inalterada: evidência de conformidade vem de AWS Services in Scope e AWS Artifact, e HIPAA ainda significa BAA + serviços elegíveis a HIPAA.

• 📚 Você sabia? A AWS define um ciclo de vida de serviço de três palavras que aparece em opções de exame: Maintenance (nenhum cliente novo, nenhum recurso novo, ainda suportado), Sunset (fim de operações planejado, tipicamente 12 meses) e Full Shutdown (removido do portfólio). Em 30 de jul de 2026 um grande bloco de recursos do SageMaker, incluindo Role Manager, mudou para manutenção, e é por isso que notas de estudo antigas descrevendo-os como "o caminho atual para uma nova carga de trabalho" já estão erradas.

---

Perguntas de Prática (Practice Questions)

---