Transformando eventos do Bedrock Guardrails em OCSF com o CloudWatch

O problema: telemetria de IA isolada do resto da segurança

Equipes de segurança que investigam incidentes relacionados a Inteligência Artificial (IA) precisam cruzar dados de intervenção de guardrails com a telemetria de segurança já existente. Quando um guardrail bloqueia uma tentativa de injeção de prompt ou redige informações sensíveis, esse evento carrega valor investigativo comparável a uma falha de autenticação ou a um alerta de intrusão de rede.

O AWS Bedrock publica essa telemetria no AWS CloudWatch — em métricas e nos logs de invocação de modelos — para monitoramento operacional. O desafio é que esses dados ficam isolados por Região e em formato bruto, separados dos dados de identidade, rede e auditoria que o time de segurança já utiliza.

A AWS publicou uma solução que resolve exatamente esse problema: transformar os eventos de intervenção do AWS Bedrock Guardrails em registros estruturados no padrão Open Cybersecurity Schema Framework (OCSF) — Estrutura Aberta de Esquema de Cibersegurança — e armazená-los no CloudWatch unified data store.

O que é o CloudWatch unified data store?

Lançado em dezembro de 2025, o CloudWatch unified data store (armazenamento unificado de dados do CloudWatch) consolida dados operacionais, de segurança e de conformidade de serviços AWS e fontes de terceiros em uma única plataforma. Analistas de Centro de Operações de Segurança (SOC) e analistas de ameaças podem consultar eventos de guardrails lado a lado com dados de identidade, rede e endpoints — incluindo AWS CloudTrail e VPC Flow Logs — usando AWS Athena ou CloudWatch Logs Insights.

Caso de uso: correlação entre guardrails e outras fontes de segurança

Imagine uma organização que usa o AWS Bedrock em várias aplicações com guardrails como controle de governança. Esses guardrails detectam e bloqueiam conteúdo prejudicial, consultas fora do escopo, informações sensíveis como Informações de Identificação Pessoal (PII) e tentativas de injeção de prompt.

Sem uma camada de consolidação, as intervenções dos guardrails ficam isoladas como métricas do CloudWatch por Região e entradas nos logs brutos de invocação — separadas dos dados de identidade, rede e auditoria que o time de segurança já usa. O CloudWatch unified data store foi construído para eliminar exatamente esse tipo de silo.

Com os registros normalizados de guardrail no data store, o time consegue responder perguntas que cruzam múltiplas fontes de dados:

Quais contas de usuário geram mais intervenções de guardrail? Essas mesmas contas também apresentam atividade incomum no AWS Identity and Access Management (IAM), como chamadas de API com falha ou alterações de privilégio?
Tentativas de injeção de prompt se correlacionam com endereços IP específicos que também aparecem nos VPC Flow Logs? Isso ajuda a distinguir um cliente mal configurado de um padrão coordenado de ataque.
Como a tendência de violações de guardrail evoluiu nos últimos 30 dias? O volume atual é ruído de política ou uma mudança emergente no comportamento de atacantes?

Vale destacar que o AWS GuardDuty já contribui nesse cenário: seu recurso de Proteção de IA analisa eventos de dados do CloudTrail para o AWS Bedrock e produz findings gerenciados de ameaças, incluindo detecção direta de injeção de prompt e achados de invocação anômala de modelos. O pipeline descrito neste artigo é complementar ao GuardDuty — ele captura os próprios registros brutos de intervenção de guardrail, normaliza-os para OCSF e os deposita no data store unificado para correlação entre fontes e análise de tendências de longo prazo.

Por que é necessário um passo de transformação customizado?

O CloudWatch oferece conversão nativa para OCSF por meio do processador ParseToOCSF para fontes específicas da AWS. No momento da publicação, esse processador suporta cinco fontes: CloudTrail, AWS Route 53 Resolver, VPC Flow Logs, logs de auditoria do AWS EKS e AWS WAF. O AWS Bedrock Guardrails não está entre essas fontes, portanto os traces de guardrail não são convertidos automaticamente para OCSF.

Além disso, os traces de guardrail exigem uma lógica de transformação que processadores de ingestão não oferecem: um único log de invocação de modelo pode conter múltiplas avaliações de guardrail — por exemplo, um filtro de política de conteúdo e uma correspondência de política de informações sensíveis na mesma requisição. O passo de transformação divide essa entrada em um registro OCSF Detection Finding (Descoberta de Detecção) por avaliação, em vez de um único registro combinado. Essa expansão de um-para-muitos, combinada com a atribuição condicional de severidade por tipo de política, é lógica de aplicação — não apenas normalização de campos.

Visão geral da solução e arquitetura

Em alto nível, a solução captura eventos de intervenção de guardrail nos logs de invocação de modelos do AWS Bedrock, transforma-os em registros OCSF Detection Finding com uma função AWS Lambda, e os deposita no CloudWatch unified data store, onde analistas de SOC os consultam com Athena ou CloudWatch Logs Insights.

O fluxo de dados segue as seguintes etapas:

Uma aplicação chama o AWS Bedrock (API InvokeModel ou Converse) com um guardrail associado.
O AWS Bedrock avalia o guardrail e registra a invocação — incluindo os dados de trace do guardrail — em um grupo de logs do CloudWatch via model invocation logging.
Um filtro de assinatura identifica entradas de log onde a ação do guardrail é INTERVENED (conteúdo bloqueado ou mascarado).
O filtro de assinatura entrega os registros correspondentes a uma função Lambda (OCSF Transform), que expande cada avaliação de guardrail em seu próprio OCSF Detection Finding.
A função Lambda grava os registros OCSF JSON em um grupo de logs dedicado do CloudWatch e define campos contextuais (ID da conta e Região) em cada registro durante a transformação.
Se a função Lambda falhar ao processar um registro, a mensagem é roteada para uma fila de mensagens mortas do AWS Simple Queue Service (AWS SQS) para análise posterior.
O grupo de logs de destino é associado ao AWS S3 Tables por meio da integração gerenciada do CloudWatch unified data store, que armazena os registros OCSF como uma tabela Apache Iceberg.
Analistas de SOC consultam os dados com Athena, usando funções json_extract para ler os campos OCSF, e os correlacionam com fontes de segurança nativas (CloudTrail, VPC Flow Logs) que compartilham o mesmo catálogo.

Como o AWS Bedrock Guardrails é uma fonte customizada, cada registro é armazenado como OCSF JSON em uma coluna gerenciada chamada cwl__message, em vez de colunas tipadas. Os campos OCSF são lidos em tempo de consulta com funções json_extract do Athena, e podem ser correlacionados com as fontes nativas que compartilham o mesmo catálogo.

Mapeamento de campos OCSF

A tabela abaixo mostra como os campos de intervenção do AWS Bedrock Guardrails são mapeados para os atributos do OCSF Detection Finding (class_uid 2004):

class_uid: estático — 2004 (Detection Finding)
category_uid: estático — 2 (Findings)
severity_id: derivado do tipo de política — 3 (Medium) para conteúdo/tópico; 4 (High) 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: definido pela função de transformação
cloud.account.uid: definido pela função de transformaçã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 trace do guardrail
resource.uid: ARN do modelo
resource.type: estático — AwsBedrock:Model
unmapped.guardrail_id / guardrail_arn / guardrail_version / guardrail_content_source / guardrail_policy_type: campos do trace do guardrail

Pré-requisitos e implementação

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

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

Os pré-requisitos incluem: uma conta AWS com o AWS Cloud Development Kit (AWS CDK) inicializado na Região de destino, Python 3.12 ou superior, Node.js 20 ou superior (para a CLI do AWS CDK), um guardrail do AWS Bedrock existente e o model invocation logging habilitado com trace de guardrail ativado. A Região de destino deve suportar o CloudWatch unified data store e a integração com AWS S3 Tables (consulte a disponibilidade regional do CloudWatch pipelines).

Habilitando o model invocation logging

O model invocation logging captura os dados de trace do guardrail necessários. É preciso ativar o logging completo de requisição e resposta para um grupo de logs do CloudWatch e configurar textDataDeliveryEnabled para capturar os corpos de texto que incluem a saída do trace do guardrail. O comando a seguir via AWS Command Line Interface (AWS CLI) habilita essa configuração:

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/aws/bedrock/model-invocation-logs",
      "roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole"
    },
    "textDataDeliveryEnabled": true
  }'

Como o logging é um pré-requisito em nível de conta, as stacks do CDK não o gerenciam. Ele deve ser habilitado uma vez em cada conta antes do deploy.

Fazendo o deploy do pipeline de transformação

A implementação de referência implanta duas stacks do CloudFormation: TransformPipelineStack e MonitoringStack. Os comandos a seguir fazem o deploy na ordem correta de dependência:

cdk deploy TransformPipelineStack \
  -c destination_log_group=/aws/cloudwatch-uds/bedrock-guardrails-ocsf

cdk deploy MonitoringStack \
  -c alarm_email=your-team@example.com

Ou para fazer o deploy de ambas as stacks de uma vez:

cdk deploy --all \
  -c destination_log_group=/aws/cloudwatch-uds/bedrock-guardrails-ocsf \
  -c alarm_email=your-team@example.com

A TransformPipelineStack implanta a função Lambda, o filtro de assinatura, o grupo de logs de destino e a fila de mensagens mortas. O filtro de assinatura captura apenas os eventos onde um guardrail bloqueou ou modificou conteúdo — não os eventos de passagem bem-sucedidos — o que reduz invocações e custos. A severidade é definida como High para intervenções de injeção de prompt e Medium para intervenções de conteúdo, tópico ou informações sensíveis.

Configurando a integração com S3 Tables

Para tornar os registros OCSF consultáveis via Athena, é necessário associar o grupo de logs de destino ao AWS S3 Tables. Isso envolve duas etapas: criar uma integração S3 Tables e associar o grupo de logs como fonte de dados.

Primeiro, adicione as tags cw:datasource:name (por exemplo, bedrock_guardrails) e cw:datasource:type (por exemplo, ocsf) ao grupo de logs de destino. O nome da tabela gerada une os dois valores com sublinhado duplo — essas tags de exemplo produzem uma tabela chamada bedrock_guardrails__ocsf.

Em seguida, crie a integração com CreateS3TableIntegration (CloudWatch Observability Admin), fornecendo uma configuração de criptografia e uma função IAM. Isso retorna um ARN de integração. Por fim, associe a fonte de dados com AssociateSourceToS3TableIntegration (CloudWatch Logs), passando o ARN da integração e os valores de dataSource. A implementação de referência realiza essas etapas automaticamente via CDK.

Após a associação, os registros OCSF ficam disponíveis como uma tabela Apache Iceberg no catálogo gerenciado, no caminho "s3tablescatalog/aws-cloudwatch"."logs"."bedrock_guardrails__ocsf". É possível consultá-la com Athena, AWS Redshift ou qualquer ferramenta compatível com Iceberg.

Para habilitar o acesso analítico, é necessário ainda ativar a integração de analytics do AWS S3 Tables no console do S3 e conceder permissões de leitura via AWS Lake Formation aos papéis IAM que executarão as consultas. Sem essa concessão, as consultas do Athena retornarão erro de acesso negado mesmo com a política IAM correta.

Consultando as intervenções

Após o deploy, os dados de intervenção de guardrail ficam disponíveis por dois caminhos de consulta.

Athena (via AWS S3 Tables): correlação entre fontes e análise histórica

O exemplo a seguir identifica usuários que disparam tanto intervenções de injeção de prompt quanto atividade com falha no CloudTrail. O lado do guardrail extrai campos de cwl__message; o lado do CloudTrail é uma fonte nativa com colunas OCSF tipadas:

WITH guardrail_violators AS (
  SELECT json_extract_scalar(cwl__message, '$.actor.user.uid') AS user_arn,
         COUNT(*) AS violation_count
  FROM bedrock_guardrails_ocsf
  WHERE json_extract_scalar(cwl__message, '$.unmapped.guardrail_policy_type') = 'PromptAttack'
  GROUP BY json_extract_scalar(cwl__message, '$.actor.user.uid')
),
iam_failures AS (
  SELECT "actor.user.uid" AS user_arn,
         COUNT(*) AS failure_count
  FROM aws_cloudtrail__management
  WHERE "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;

Para acompanhar tendências de violação por tipo de política ao longo do tempo:

SELECT date_trunc('day', from_unixtime(
         cast(json_extract_scalar(cwl__message, '$.time') as bigint) / 1000)) AS event_day,
       json_extract_scalar(cwl__message, '$.unmapped.guardrail_policy_type') AS policy_type,
       COUNT(*) AS violation_count
FROM bedrock_guardrails_ocsf
GROUP BY 1, 2
ORDER BY event_day, violation_count DESC;

CloudWatch Logs Insights: consultas operacionais em tempo real

Para consultas operacionais sobre dados recentes sem join de tabelas, é possível consultar o grupo de logs de destino diretamente no CloudWatch Logs Insights:

fields @timestamp, severity, finding_info.title, actor.user.uid, unmapped.guardrail_policy_type
| filter class_uid = 2004
| filter unmapped.guardrail_policy_type = "PromptAttack"
| stats count() as attack_count by actor.user.uid
| sort attack_count desc
| limit 10

Deploy multi-conta

Para organizações que executam o AWS Bedrock em múltiplas contas, o padrão recomendado é transformar localmente e centralizar a saída OCSF — em vez de replicar os logs brutos de invocação e transformar de forma centralizada. O pipeline de transformação é implantado em cada conta de workload onde o model invocation logging está habilitado. Cada conta produz registros OCSF em seu próprio grupo de logs de destino. Em seguida, a centralização de logs do CloudWatch replica automaticamente esses registros OCSF para uma conta central de logging.

A centralização se integra ao AWS Organizations e detecta novas contas automaticamente. A integração com AWS S3 Tables é criada uma única vez na conta central, permitindo consultas em toda a organização. Transformar em cada conta de workload mantém o parsing próximo da fonte e evita mover logs brutos de invocação — que podem conter texto de prompt e resposta — entre fronteiras de conta.

Limpeza dos recursos

Para evitar cobranças contínuas, destrua as stacks na ordem inversa de dependência:

cdk destroy MonitoringStack --force
cdk destroy TransformPipelineStack --force

Conclusão

A solução publicada pela AWS mostra como transformar eventos de intervenção do AWS Bedrock Guardrails em registros OCSF Detection Finding e ingeri-los no CloudWatch unified data store. Essa integração fornece às equipes de SOC telemetria estruturada de guardrail que se correlaciona com CloudTrail, VPC Flow Logs e outras fontes de segurança já disponíveis no CloudWatch.

Como as intervenções de guardrail são uma fonte customizada, seus campos OCSF são armazenados como JSON e lidos com funções json_extract do Athena — o que permite juntá-los com as fontes nativas OCSF que compartilham o mesmo catálogo. O pipeline filtra apenas eventos de intervenção, mantendo os custos baixos enquanto captura os sinais relevantes para segurança.

A implementação de referência está disponível para clone e adaptação conforme a configuração de guardrail de cada ambiente. O mesmo padrão de transformação pode ser estendido para traces de guardrail de agentes, que se mapeiam para a mesma classe OCSF Detection Finding.

Fonte

Transforming Bedrock Guardrails events into OCSF with CloudWatch (https://aws.amazon.com/blogs/security/transforming-bedrock-guardrails-events-into-ocsf-with-cloudwatch/)