User's blog

Como garantir retenção zero de dados no Amazon Bedrock com Bedrock Projects e políticas de controle de serviço

Written by

Make.com Service User

in

Por que o controle de retenção de dados no Bedrock ficou mais crítico

Com a chegada de modelos que exigem compartilhamento de dados com provedores terceiros — como o Claude Fable 5 — a AWS reforçou os mecanismos disponíveis para que organizações controlem com precisão o que acontece com seus prompts e respostas após cada chamada de inferência. O Amazon Bedrock já oferecia controle sobre retenção de dados, mas agora a necessidade de aplicar essas políticas de forma centralizada e auditável ficou ainda mais evidente.

Este artigo explica como os modos de retenção funcionam, quais ferramentas estão disponíveis para gerenciá-los e como verificar que as configurações estão funcionando corretamente — informações essenciais para times de segurança e engenharia que operam no Bedrock.

Entendendo os modos de retenção de dados

O Bedrock oferece quatro modos de retenção que determinam o que acontece com os dados após cada requisição de inferência. Consulte a documentação oficial do Amazon Bedrock para verificar quais modelos exigem retenção ou compartilhamento de dados.

  • none: Retenção zero. Prompts e respostas são processados e descartados imediatamente. Nenhum dado é compartilhado com o provedor do modelo.
  • default: Sem configuração explícita de compartilhamento. Alguns modelos podem reter dados por até 30 dias para verificações de segurança e confiança. Permite APIs que exigem retenção por natureza (como a Batch API e a Responses API com store=true). Modelos que suportam retenção zero continuam operando sem retenção.
  • inherit: Sem configuração explícita — herda o modo do escopo superior (projeto herda da conta, conta herda do padrão do serviço). Este é o padrão para novas contas.
  • provider_data_share: Dados são compartilhados com o provedor do modelo e retidos por até 30 dias para fins de segurança e confiança.

Nota importante: Para combater a disseminação de material de abuso sexual infantil (CSAM), o Amazon Bedrock usa mecanismos automatizados de identificação nesse tipo de conteúdo nas entradas e saídas dos modelos. Conteúdos sinalizados podem ser armazenados e revisados mesmo quando o modo está configurado como none.

O modo como teto, não como piso

Um conceito fundamental: o modo configurado é o limite máximo de retenção que você aceita, não o que toda requisição vai usar. Configurar uma conta como provider_data_share não significa que todas as requisições passarão a reter e compartilhar dados.

Modelos que suportam retenção zero continuarão operando com retenção zero, independentemente do modo da conta. Pense nisso como um teto de permissões:

  • Conta em provider_data_share + modelo Claude Sonnet (suporta none) → retenção zero, o Sonnet não exige compartilhamento
  • Conta em provider_data_share + Claude Fable 5 (exige provider_data_share) → dados retidos por até 30 dias e possivelmente compartilhados
  • Conta em none + Claude Sonnet → retenção zero
  • Conta em none + Claude Fable 5 → bloqueado; o teto da conta está abaixo do que o modelo exige

Além disso, provider_data_share não é herdado de um modelo — é um opt-in explícito configurado no nível da conta ou do projeto. Se a conta estiver em inherit ou default, nenhum modelo acionará o compartilhamento de dados com o provedor.

Ferramentas disponíveis para gerenciar retenção

A AWS disponibiliza múltiplas camadas de controle que podem ser usadas de forma independente ou combinadas para uma defesa em profundidade:

  • Console do Amazon Bedrock: configuração por conta e por região, com visibilidade imediata do modo atual.
  • Amazon Bedrock Projects: isolamento de cargas de trabalho com necessidades diferentes de retenção dentro da mesma conta, para modelos compatíveis.
  • Políticas de Controle de Serviço (SCPs): aplicação em toda a organização, impedindo qualquer conta de habilitar o compartilhamento de dados.
  • Políticas do IAM: controle granular por conta ou por principal, incluindo a conta de gerenciamento (que SCPs não cobrem).

Usando o Amazon Bedrock Projects para controle granular

Nem toda carga de trabalho dentro de uma conta tem os mesmos requisitos de retenção. Com o Amazon Bedrock Projects — disponível no endpoint bedrock-mantle — é possível isolar o tráfego que pode aceitar retenção daquele que não pode, mesmo dentro da mesma conta.

Por exemplo, uma organização pode ter:

  • Um projeto de pesquisa onde a equipe precisa de acesso aos modelos mais recentes (incluindo os que exigem provider_data_share) para experimentação.
  • Um projeto de produção que lida com dados de clientes onde retenção zero é obrigatória.

Com o Bedrock Projects, é possível configurar provider_data_share no projeto de pesquisa e manter o projeto de produção bloqueado em none. Cada projeto aplica seu próprio teto de retenção de forma independente.

A lógica de resolução do modo efetivo segue a hierarquia: projeto → conta → padrão do serviço. O primeiro valor não-inherit encontrado nessa cadeia é o modo aplicado.

Importante: O Bedrock Projects só está disponível no endpoint bedrock-mantle, com modelos acessados via APIs compatíveis com OpenAI (Responses, Chat Completions) e a API Anthropic Messages no endpoint mantle. Verifique a disponibilidade por modelo e endpoint antes de planejar sua arquitetura.

Isolamento no endpoint bedrock-runtime

Se você usa o endpoint bedrock-runtime (APIs Invoke e Converse), o controle por projeto não está disponível — o modo de retenção da conta se aplica a todas as requisições. Para alcançar isolamento nesse endpoint, a recomendação da AWS é usar contas AWS separadas, organizadas em Unidades Organizacionais (OUs) do AWS Organizations com SCPs aplicadas seletivamente.

Organization Root
├── OU: Zero-Retention (SCP attached — blocks provider_data_share)
│   ├── Account: Production-App-A
│   └── Account: Production-App-B
└── OU: Research (no SCP — allows provider_data_share)
    └── Account: ML-Experimentation

Usando SCPs para aplicação em toda a organização

Para organizações que precisam de uma garantia absoluta de que nenhuma conta pode habilitar o compartilhamento de dados — independentemente de quem tem acesso administrativo — as SCPs oferecem o mecanismo de aplicação mais forte.

Uma SCP é uma barreira definida no nível organizacional. Ela se sobrepõe a todos os principais da organização, incluindo administradores de conta e usuários root. Mesmo com permissões de administrador completo, um deny de SCP não pode ser sobrescrito por uma política do AWS Identity and Access Management (IAM).

As SCPs cobrem tanto o plano de controle do Amazon Bedrock (bedrock:PutAccountDataRetention) quanto o endpoint mantle (bedrock-mantle:PutAccountDataRetention, bedrock-mantle:CreateProject, bedrock-mantle:UpdateProject).

A política SCP para retenção zero

Atenção: Novas contas têm o modo padrão inherit, não none. Antes de anexar a SCP, é necessário configurar explicitamente cada conta para none:

aws bedrock put-account-data-retention --region us-east-1 --mode none

Para centenas ou milhares de contas, consulte o artigo do AWS re:Post Automate Bedrock Zero Data Retention Across All Accounts in Your Organization para aprender como escalar esse processo.

A política SCP que restringe a retenção somente ao modo none:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RESTRICTBEDROCKDATARETENTION",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutAccountDataRetention"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:DataRetentionMode": "none"
        }
      }
    }
  ]
}

O bloco Condition usa StringNotEquals, o que significa que o deny é acionado para qualquer valor diferente de none. Com essa política em vigor: ninguém pode habilitar o compartilhamento de dados com provedores de modelos; modelos que exigem provider_data_share (como Claude Fable 5 e Claude Mythos 5) ficam permanentemente indisponíveis; todos os outros modelos continuam funcionando normalmente.

Bloqueando também as configurações por projeto

O endpoint bedrock-mantle suporta configurações de retenção por projeto. Sem cobertura adicional na SCP, alguém poderia criar ou atualizar um projeto com provider_data_share, contornando a restrição no nível da conta. Para evitar isso, estenda a SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RESTRICTBEDROCKDATARETENTION",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutAccountDataRetention",
        "bedrock-mantle:PutAccountDataRetention",
        "bedrock-mantle:CreateProject",
        "bedrock-mantle:UpdateProject"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:DataRetentionMode": "none"
        }
      }
    }
  ]
}

O endpoint bedrock-runtime não precisa dos bloqueios de projeto porque projetos não existem nesse endpoint — apenas a ação bedrock:PutAccountDataRetention já é suficiente para cobri-lo.

Retenção de dados e inferência entre regiões

Ao usar perfis de inferência entre regiões (cross-Region inference profiles), o modo de retenção é avaliado na região de origem da requisição — a região onde a chamada de API é feita. Não é necessário configurar o modo em cada região de destino.

Porém, há um ponto de atenção: embora a verificação do modo ocorra na região de origem, os dados podem ser retidos na região de destino onde a inferência é processada. Isso é relevante para organizações que monitoram onde os dados retidos residem geograficamente.

Uma vantagem importante das SCPs nesse contexto: uma única SCP anexada à OU raiz bloqueia provider_data_share em todas as regiões automaticamente, sem necessidade de configuração por região.

Verificando suas configurações

A AWS oferece três formas de verificar as configurações de retenção: o console do Amazon Bedrock, a Interface de Linha de Comando da AWS (AWS CLI) (versão 2.35+) e a API bedrock-mantle.

Verificar o modo atual da conta

Via AWS CLI:

aws bedrock get-account-data-retention --region us-east-1

Resposta esperada:

{
  "mode": "none",
  "updatedAt": "2026-07-01T01:58:34.684Z"
}

Via API bedrock-mantle (usando uma chave de API do Bedrock):

curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY"

Verificar o modo efetivo de um modelo específico

curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \
  -H "x-api-key: $BEDROCK_API_KEY"

Resposta:

{
  "id": "anthropic.claude-fable-5",
  "status": "available",
  "data_retention": {
    "mode": "provider_data_share",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Se o modelo aparecer com "status": "unavailable", o campo status_reason explicará o conflito de modo de retenção.

Confirmar que a SCP está funcionando

Tente definir o modo como provider_data_share:

aws bedrock put-account-data-retention \
  --region us-east-1 \
  --mode provider_data_share

Se a SCP estiver funcionando, você receberá um erro de acesso negado:

An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation: User: arn:aws:iam::123456789012:user/admin is not authorized to perform: bedrock:PutAccountDataRetention with an explicit deny in a service control policy

Se a requisição for bem-sucedida, a SCP não está funcionando. Reverta imediatamente com --mode none e verifique: se a SCP está anexada à OU raiz (não a uma OU filha), a sintaxe da política e as condition keys, e lembre-se de que a conta de gerenciamento do AWS Organizations é isenta de SCPs — use uma política IAM para cobri-la.

Gerenciando retenção no nível do projeto

O gerenciamento de retenção por projeto é feito exclusivamente via API bedrock-mantle — não há comando AWS CLI para configurações no nível do projeto.

# Definir um projeto como provider_data_share
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "provider_data_share" } }'

# Definir um projeto como none (retenção zero)
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "none" } }'

# Verificar a configuração atual de um projeto
curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY"

Recursos adicionais

Fonte

Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies (https://aws.amazon.com/blogs/security/enforce-zero-data-retention-on-amazon-bedrock-with-bedrock-projects-and-service-control-policies/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts