c1.2 Criptografe os dados de inferência com chaves KMS gerenciadas pelo cliente
Criptografe prompts, respostas e quaisquer dados de inferência armazenados com uma chave gerenciada por você, em vez de depender apenas das chaves gerenciadas pela AWS por padrão.
Guia de implementação
Como implementar na AWS
Crie uma chave KMS gerenciada pelo cliente para os dados de inferência e referencie-a ao configurar o Bedrock, os guardrails e qualquer armazenamento S3 de prompts/logs. Use políticas de chave mais IAM para restringir a descriptografia e habilite a rotação.
Por que uma chave gerenciada pelo cliente
Por padrão, o Amazon Bedrock criptografa os dados com uma chave gerenciada pela AWS, que você não pode inspecionar, restringir nem auditar em nível de política. Uma chave gerenciada pelo cliente (CMK) permite decidir exatamente quais entidades e quais serviços podem usar a chave, rotacioná-la no seu cronograma e ver cada uso no CloudTrail. Para cargas de inferência reguladas, esse controle sobre a chave — e não apenas sobre os dados — costuma ser o requisito.
Restrinja a chave ao Bedrock com uma política de chave
A política de chave é a raiz de confiança de uma chave do KMS. Conceda ao principal de serviço do Bedrock apenas as operações de que ele precisa e restrinja-as ao Bedrock com a condição kms:ViaService, para que a chave não possa ser usada por outros serviços:
{
"Sid": "AllowBedrockToUseTheKey",
"Effect": "Allow",
"Principal": { "Service": "bedrock.amazonaws.com" },
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": { "kms:ViaService": "bedrock.us-east-1.amazonaws.com" }
}
}
O Bedrock cria um grant sobre a chave (via kms:CreateGrant) para poder usar a CMK em trabalhos de longa duração, como a personalização de modelos; mantenha essa permissão na política acima.
Criptografe também os dados que saem do modelo
Prompts e respostas também são gravados onde você enviar os registros de invocação do modelo. Aponte esse registro para um bucket do S3 ou um grupo do CloudWatch Logs que seja criptografado com a mesma CMK, para que a cópia armazenada dos dados de inferência fique protegida com a chave que você controla, e não com a chave padrão aws/s3. Veja Monitor model invocation using CloudWatch Logs and Amazon S3.
Ative a rotação e o descriptografar com privilégio mínimo
- Habilite a rotação automática anual da CMK.
- Na política de chave, separe os administradores da chave (que a gerenciam) dos usuários da chave (que podem fazer
Decrypt); a função em execução deve poder descriptografar, não administrar. - Acompanhe o uso do KMS pelo Bedrock com o CloudTrail — veja Monitoring your encryption keys for the Amazon Bedrock service.
Nota de nomenclatura: substituaus-east-1no valor dekms:ViaServicepela sua região. Use uma CMK distinta (e uma linhakms:ViaServiceseparada) por região em vez de uma única chave compartilhada.
Critérios de aceitação
Os dados de inferência em repouso são criptografados com uma chave gerenciada pelo cliente; a política da chave limita a descriptografia a papéis aprovados; a rotação está habilitada.
Implementação prática
Como este controle é implementado em cada arquitetura de referência:
Uma chave gerenciada pelo cliente vive na conta de IA generativa e criptografa guardrails, logs de invocação e o armazenamento de prompts/respostas; sua política de chave concede descriptografia apenas a papéis aprovados.
- Crie uma chave KMS gerenciada pelo cliente na conta de IA generativa e referencie-a ao configurar os guardrails do Bedrock, o registro de invocação de modelos e qualquer bucket S3 que armazene prompts ou respostas.
- Escreva uma política de chave que conceda kms:Decrypt apenas aos papéis específicos de invocação e de registro, e habilite a rotação anual automática da chave.
- Conceda ao papel leitor da conta de Log archive a permissão mínima de descriptografia necessária para processar os logs centralizados, via grant ou sentença da política de chave.
Como validar: Todo o armazenamento relacionado à inferência mostra a chave gerenciada pelo cliente (não a chave padrão aws/bedrock); a política de chave lista apenas os principais de descriptografia aprovados; a rotação está habilitada.
Evite: Depender da chave gerenciada pela AWS padrão de modo que a criptografia esteja 'ligada' mas você não possa restringir nem auditar quem descriptografa. Use uma chave gerenciada pelo cliente com uma política de chave rígida.
Uma chave gerenciada pelo cliente na conta criptografa todos os dados de inferência, com uma política de chave restrita apenas aos papéis de execução e de registro.
- Crie uma chave KMS dedicada gerenciada pelo cliente e aplique-a aos guardrails do Bedrock, ao registro de invocação de modelos e aos buckets S3 que guardam prompts/respostas/logs.
- Restrinja kms:Decrypt na política de chave ao papel de invocação de modelo e ao papel de registro; negue-o a principais amplos; habilite a rotação da chave.
- Mantenha os administradores da chave KMS separados dos papéis em execução para que o app não possa alterar nem desabilitar a chave.
Como validar: O armazenamento de inferência é criptografado com a chave gerenciada pelo cliente; apenas os papéis de invocação/registro podem descriptografar; a rotação está habilitada; o papel do app em execução não pode administrar a chave.
Evite: Uma única chave compartilhada entre cargas não relacionadas com uma política de chave aberta. Use uma chave dedicada e restrinja a descriptografia aos papéis que de fato processam dados de inferência.
Ameaças atendidas
- Dados de prompt ou resposta legíveis se uma chave padrão ou o armazenamento for comprometido.
- Modificação não autorizada da configuração do guardrail ou do modelo.
Serviços AWS
Preços
Cada chave gerenciada pelo cliente tem uma pequena taxa mensal, além de uma cobrança por solicitação pelas chamadas à API do KMS durante as operações de criptografia/descriptografia. Não há cobrança pelas chaves gerenciadas pela AWS, portanto o custo da CMK é o preço do controle e da auditabilidade adicionais.
Mapeamentos de frameworks
OWASP GenAI/LLM Top 10 (2026)
- LLM02 Sensitive Information Disclosure
NIST AI Risk Management Framework (AI 100-1)
- MANAGE.1 AI risks are prioritized, responded to and managed
AWS Security Hub — AI Security Best Practices
- Bedrock.1 Amazon Bedrock data sources should be encrypted with customer managed AWS KMS keys
AWS Well-Architected Generative AI Lens (Security)
- GENSEC01-BP03 Implement least privilege access to data stores
Recursos de aprendizado
Referências
- AWS SRA para IA — Capacidade 1, Segurança de dados
AI Security Maturity Model