Roteando intervenções do Amazon Bedrock Guardrails para o Amazon Security Lake

O problema: dados de IA isolados do restante da telemetria de segurança

Quando uma equipe de segurança investiga um incidente envolvendo sistemas de Inteligência Artificial (IA), ela precisa cruzar dados de comportamento do modelo com informações de identidade, rede e aplicação. O desafio é que, até então, os eventos de intervenção do Amazon Bedrock Guardrails ficavam disponíveis apenas no Amazon CloudWatch — separados do restante da telemetria de segurança centralizada no Amazon Security Lake.

A AWS publicou uma solução que resolve exatamente isso: um pipeline automatizado que captura eventos de intervenção do Amazon Bedrock, os transforma em registros compatíveis com o Open Cybersecurity Schema Framework (OCSF) e os entrega ao Security Lake como uma fonte personalizada. A partir daí, analistas do Centro de Operações de Segurança (SOC) podem consultar violações de guardrails lado a lado com dados de AWS Identity and Access Management (IAM), logs de fluxo do Amazon Virtual Private Cloud (Amazon VPC) e outras fontes — tudo via Amazon Athena.

Por que isso importa para segurança?

Quando um guardrail bloqueia uma tentativa de injeção de prompt ou redige informações sensíveis, esse evento tem valor investigativo comparável a uma tentativa de login mal-sucedida ou a um alerta de intrusão de rede. Ignorar essa telemetria ou mantê-la isolada significa perder correlações críticas.

Considere o cenário de uma organização financeira que utiliza o Amazon Bedrock em múltiplas unidades de negócio. Cada unidade aplica guardrails para bloquear conteúdo prejudicial, prevenir consultas fora do escopo, redigir Informações de Identificação Pessoal (PII) como números de conta, e detectar injeções de prompt. A equipe de segurança precisa responder a perguntas como:

Quais contas de usuário disparam mais intervenções de guardrail — e essas mesmas contas têm atividade IAM suspeita?
Tentativas de injeção de prompt estão correlacionadas com endereços IP que também aparecem nos logs de fluxo do VPC?
Qual é a tendência de violações em toda a organização comparada aos últimos 30 dias?

Com os eventos roteados para o Security Lake, uma única query no Athena cobre as três perguntas.

Visão geral da solução

A arquitetura do pipeline captura logs de invocação de modelos do Amazon Bedrock que contêm dados de rastreamento de guardrails, filtra apenas os eventos onde houve intervenção efetiva e os transforma em registros Detection Finding do OCSF (class_uid 2004). Os arquivos resultantes são gravados no Amazon Simple Storage Service (Amazon S3) do Security Lake no formato Apache Parquet comprimido com Zstandard (zstd).

A mesma infraestrutura — filtro de assinatura, transformação via AWS Lambda, gravação em Parquet e particionamento no S3 — suporta múltiplos tipos de evento apenas alterando o padrão de filtro e o mapeamento OCSF:

Intervenções de guardrail → DETECTION_FINDING 2004
Chamadas de API de invocação de modelo → API_ACTIVITY 6003
Rastreamentos de guardrail de agentes → DETECTION_FINDING 2004
Anomalias de consumo de tokens → DETECTION_FINDING 2004

Arquitetura do pipeline

O fluxo de dados percorre as seguintes etapas:

Uma aplicação chama o Amazon Bedrock via API InvokeModel ou Converse com um guardrail configurado.
O Amazon Bedrock avalia o guardrail e registra a invocação — incluindo os dados de rastreamento do guardrail — em um grupo de logs do CloudWatch Logs via logging de invocação de modelos.
Um filtro de assinatura identifica as entradas de log onde a ação do guardrail foi INTERVENED (conteúdo bloqueado ou mascarado).
O filtro entrega os registros correspondentes para uma função AWS Lambda responsável pela transformação OCSF.
A função Lambda transforma cada evento em um registro Detection Finding OCSF (class_uid 2004), agrupa os registros e os converte para o formato Parquet comprimido com zstd.
O arquivo Parquet é gravado no bucket S3 do Security Lake usando o caminho de partição obrigatório: ext/BedrockGuardrails/region=/accountId=/eventDay=/.
Em caso de falha no processamento, a mensagem é roteada para uma fila de mensagens mortas do Amazon Simple Queue Service (Amazon SQS) para análise posterior.
O Security Lake gerencia os dados Parquet no bucket S3. Um crawler do AWS Glue detecta novas partições e cataloga os arquivos para acesso por query.
Analistas do SOC consultam os dados de violação de guardrails junto a outras fontes de segurança via Athena.

Mapeamento OCSF

Os campos dos eventos de intervenção do Amazon Bedrock Guardrails são mapeados para atributos do Detection Finding OCSF (class_uid 2004) da seguinte forma:

class_uid: estático — 2004 (Detection Finding)
category_uid: estático — 2 (Findings)
severity_id: derivado do tipo de política — 3 (Médio) para conteúdo/tópico; 4 (Alto) para injeção de prompt
activity_id: estático — 1 (Create)
time: timestamp do log de invocação
cloud.provider: estático — AWS
cloud.region: região do log de invocação
cloud.account.uid: accountId do log de invocação
actor.user.uid: ARN de identidade do log de invocação
finding_info.title: derivado do tipo de política (ex: ContentPolicy Intervention)
finding_info.desc: ação/tópico do rastreamento do guardrail (ex: Blocked: HATE content detected on INPUT)
resource.uid: ARN do modelo
resource.type: estático — AwsBedrock:Model
metadata.product.name: estático — Amazon Bedrock Guardrails
unmapped.guardrail_id, guardrail_arn, guardrail_version, guardrail_content_source, guardrail_policy_type: campos adicionais extraídos do rastreamento do guardrail

A severidade é definida como Alta para intervenções de injeção de prompt e Média para intervenções de conteúdo, tópico ou informações sensíveis.

Pré-requisitos e implementação

Para implantar a implementação de referência, é necessário ter:

Uma conta AWS com o AWS Cloud Development Kit (AWS CDK) inicializado na região alvo
Security Lake habilitado na região alvo
Python 3.12 ou superior
Node.js 20 ou superior (para o CLI do AWS CDK)
Um guardrail do Amazon Bedrock existente (ou criado durante a implantação)
Logging de invocação de modelos habilitado no Amazon Bedrock (com dados de rastreamento de guardrail ativados)

O primeiro passo é clonar o repositório:

git clone https://github.com/aws-samples/sample-bedrock-guardrails-security-lake.git
cd sample-bedrock-guardrails-security-lake

A implementação de referência implanta três stacks do CloudFormation: SecurityLakeSourceStack, TransformPipelineStack e MonitoringStack. Os comandos abaixo implantam as stacks na ordem correta de dependência:

cdk deploy SecurityLakeSourceStack \
  -c security_lake_bucket=<your-security-lake-bucket> \
  -c source_location=ext/BedrockGuardrails \
  -c security_lake_enabled=true

cdk deploy TransformPipelineStack \
  -c security_lake_bucket=<your-security-lake-bucket> \
  -c source_location=ext/BedrockGuardrails

cdk deploy MonitoringStack \
  -c security_lake_bucket=<your-security-lake-bucket> \
  -c source_location=ext/BedrockGuardrails

Habilitar logging de invocação de modelos

O logging de invocação de modelos captura os dados de rastreamento do guardrail. É necessário ativar o logging completo de requisição e resposta para um grupo de logs do CloudWatch Logs, configurando textDataDeliveryEnabled para capturar os corpos de texto — que incluem a saída de rastreamento do guardrail quando ele está associado à invocação.

Registrar fonte personalizada no Security Lake

O BedrockGuardrails deve ser registrado como uma fonte personalizada no Security Lake usando a classe de evento DETECTION_FINDING. O Security Lake cria o prefixo S3 e o papel IAM para a fonte. A stack configura o papel do crawler do AWS Glue para descoberta de partições.

Criar o filtro de assinatura

É necessário criar um filtro de assinatura do CloudWatch Logs no grupo de logs de invocação de modelos com o padrão de filtro:

{ $.output.guardrailAction = "INTERVENED" }

Esse filtro captura apenas os eventos onde o guardrail bloqueou ou modificou conteúdo — não os eventos de passagem bem-sucedida. Isso reduz o número de invocações do Lambda e, consequentemente, os custos.

Consultando violações no Athena

Após a implantação, as violações de guardrail geralmente aparecem nas tabelas do Security Lake em 5 a 10 minutos, dependendo do agendamento do crawler do AWS Glue. A partir daí, é possível executar queries de correlação entre serviços.

O exemplo abaixo identifica usuários que disparam tanto intervenções de injeção de prompt quanto atividade IAM incomum:

WITH guardrail_violators AS (
  SELECT actor.user.uid AS user_arn,
         COUNT(*) AS violation_count
  FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_bedrockguardrails"
  WHERE eventDay >= '20260701'
    AND unmapped.guardrail_policy_type = 'PromptAttack'
  GROUP BY actor.user.uid
),
iam_failures AS (
  SELECT actor.user.uid AS user_arn,
         COUNT(*) AS failure_count
  FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_cloud_trail_mgmt_2_0"
  WHERE eventDay >= '20260701'
    AND status_id = 2
  GROUP BY actor.user.uid
)
SELECT g.user_arn,
       g.violation_count,
       i.failure_count
FROM guardrail_violators g
JOIN iam_failures i ON g.user_arn = i.user_arn
ORDER BY g.violation_count DESC;

Também é possível acompanhar a tendência de violações por tipo de política ao longo do tempo para estabelecer baselines e detectar picos. A query abaixo mostra a tendência de 30 dias:

SELECT eventDay,
       unmapped.guardrail_policy_type AS policy_type,
       COUNT(*) AS violation_count
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_bedrockguardrails"
WHERE eventDay >= '20260623'
GROUP BY eventDay, unmapped.guardrail_policy_type
ORDER BY eventDay, violation_count DESC;

O mapeamento OCSF foi validado contra a versão 1.3.0 do schema, e o crawler do AWS Glue do Security Lake detecta corretamente os arquivos Parquet particionados para consulta.

Considerações de escala e múltiplas contas

Em volumes baixos de intervenção (dezenas de eventos por hora), gravações diretas via Lambda produzem arquivos Parquet de tamanho aceitável. Para volumes maiores, a AWS recomenda usar o Amazon Data Firehose com sua conversão nativa para Parquet e intervalo de buffer de 5 minutos — gerando arquivos maiores e menos numerosos, o que otimiza o desempenho de queries no Athena.

Para ambientes multi-conta, o esquema de particionamento (accountId=<account>) já suporta esse cenário nativamente. O pipeline de filtro e transformação deve ser implantado em cada conta de workload onde o logging de invocação de modelos estiver habilitado. Cada pipeline grava de forma cross-account no bucket do Security Lake do administrador delegado. A distribuição pode ser feita via CloudFormation StackSets em toda a organização.

Alternativa para quem ainda não usa o Security Lake

Para organizações que ainda não adotaram o Security Lake, é possível consultar eventos de intervenção de guardrails diretamente no CloudWatch Logs Insights usando o mesmo grupo de logs do filtro de assinatura. O CloudWatch Logs Insights suporta queries entre múltiplos grupos de logs, permitindo correlacionar eventos de guardrails com outras fontes do CloudWatch sem a etapa de transformação OCSF.

O Security Lake agrega valor quando é necessário fazer joins com fontes fora do CloudWatch em uma única camada de query — como logs de fluxo do VPC, logs DNS do Amazon Route 53 e findings de terceiros.

Limpeza do ambiente

Para evitar cobranças contínuas, as stacks devem ser destruídas na ordem inversa de dependência:

cdk destroy MonitoringStack --force \
  -c security_lake_bucket=<your-security-lake-bucket> \
  -c source_location=ext/BedrockGuardrails

cdk destroy TransformPipelineStack --force \
  -c security_lake_bucket=<your-security-lake-bucket> \
  -c source_location=ext/BedrockGuardrails

cdk destroy SecurityLakeSourceStack --force \
  -c security_lake_bucket=<your-security-lake-bucket> \
  -c source_location=ext/BedrockGuardrails \
  -c security_lake_enabled=true

Conclusão

A integração entre o Amazon Bedrock Guardrails e o Amazon Security Lake representa um avanço importante para equipes de segurança que operam ambientes de IA na AWS. Ao transformar eventos de intervenção em registros OCSF padronizados e entregá-los ao Security Lake, a telemetria de IA deixa de ser um silo isolado e passa a fazer parte da análise unificada de segurança.

Analistas de SOC ganham a capacidade de correlacionar eventos de intervenção de IA com dados de IAM, rede e aplicação em uma única query — algo que antes exigiria múltiplas ferramentas e integrações manuais. A implementação de referência está disponível para clone e adaptação conforme a configuração de guardrails de cada organização.

Referências

Fonte

Route Amazon Bedrock Guardrails interventions to Amazon Security Lake (https://aws.amazon.com/blogs/security/route-amazon-bedrock-guardrails-interventions-to-amazon-security-lake/)