Category: Uncategorized

O desafio de levar agentes de IA para produção em ambientes SaaS

Provedores de Software como Serviço (SaaS) que desenvolvem aplicações agênticas com múltiplos inquilinos (multi-tenant) enfrentam desafios arquiteturais que vão muito além das preocupações habituais de segurança e governança. Isolamento entre tenants, gerenciamento de identidade, observabilidade, atribuição de custos e mitigação do problema de “vizinho barulhento” são apenas alguns dos obstáculos que separam uma demonstração funcional de um ambiente de produção robusto.

Para endereçar esse cenário, a AWS anunciou o Amazon Bedrock AgentCore, um serviço gerenciado e serverless para construir, implantar e operar com segurança aplicações agênticas na AWS. O serviço oferece primitivos para deploy de agentes, hospedagem de servidores MCP (Model Context Protocol), além de suporte nativo a gerenciamento de identidade, memória, observabilidade e avaliações — tudo projetado para tornar arquiteturas multi-tenant mais simples de construir.

Dez componentes de design para agentes multi-tenant

A AWS detalhou dez componentes arquiteturais que precisam ser considerados ao projetar agentes multi-tenant com o AgentCore. Cada um exige decisões que equilibram isolamento, eficiência operacional e otimização de custos.

Os padrões de isolamento que permeiam todas essas decisões são três: Silo, Pool e Bridge. A escolha entre eles depende da estratégia de tiers do produto SaaS.

1. Runtime do agente: dedicado ou compartilhado

A decisão mais fundamental é como o runtime do agente é provisionado em relação aos tenants. Um runtime dedicado por tenant (padrão Silo) oferece a maior proteção contra o problema do vizinho barulhento e facilita auditorias de conformidade. Um runtime compartilhado reduz custos e overhead operacional, mas exige propagação rigorosa do contexto do tenant dentro do processo.

O AgentCore Runtime resolve essa tensão com computação baseada em microVMs isoladas por sessão. Cada sessão recebe seu próprio sistema de arquivos persistente, permitindo que os agentes mantenham estado entre etapas de uma interação sem risco de vazamento entre sessões. O contexto do tenant é injetado no ambiente de execução via cabeçalhos HTTP customizados — incluindo identificador do tenant, tier, preferências regionais, feature flags e entitlements.

2. Modelos: compartilhados, por tier ou fine-tuned

Modelos de fundação (FM — Foundation Models) compartilhados são o ponto de partida recomendado para a maioria dos deployments multi-tenant. Para casos que exigem terminologia específica, conformidade regulatória ou SLAs de performance, modelos fine-tuned por tenant se tornam necessários, embora introduzam maior complexidade operacional.

A AWS oferece, via Amazon Bedrock, uma seleção de grandes modelos de linguagem (LLM — Large Language Models) de diferentes provedores, além de suporte a fine-tuning com datasets próprios e importação de modelos customizados via Amazon Bedrock Custom Model Import.

3. Workflows: padrões Silo, Pool e Bridge

Workflows podem ser implementados como ferramentas MCP, endpoints de API ou habilidades do agente. O padrão Silo usa habilidades dedicadas por tenant, com toda a lógica de negócio isolada — máxima customização, mas manutenção separada por tenant. O padrão Pool usa habilidades compartilhadas. O padrão Bridge combina os dois: etapas comuns (autenticação, logging, tratamento de erros) ficam em habilidades compartilhadas, que invocam habilidades específicas do tenant em runtime para a lógica crítica de negócio.

4. RAG multi-tenant

Sistemas de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) exigem decisões de isolamento de dados. O padrão Silo usa bancos de dados vetoriais dedicados por tenant — recomendado para indústrias reguladas. O padrão Pool usa bancos vetoriais compartilhados com filtragem por metadados e controle de acesso por namespace, mais eficiente em custo para plataformas com muitos tenants pequenos e médios.

O Amazon Bedrock Knowledge Bases oferece capacidades gerenciadas de RAG com suporte a múltiplos bancos vetoriais e possibilidade de criar bases de conhecimento isoladas ou compartilhadas. Para orientações detalhadas, a AWS publicou referências sobre RAG multi-tenant com Amazon Bedrock Knowledge Bases e sobre multi-tenancy em aplicações RAG com filtragem de metadados.

5. Contexto do tenant, padrão act-on-behalf e propagação de tokens

Diferentemente de APIs determinísticas, agentes de IA são não-determinísticos e potencialmente autônomos. Um agente comprometido poderia fazer chamadas não autorizadas a serviços downstream, levando a roubo de credenciais, escalada de privilégios e o problema do “Confused Deputy”.

A AWS recomenda o padrão de delegação (Act-on-Behalf), em vez de impersonação completa. Nesse modelo, os tokens são transformados em cada fronteira de serviço com credenciais de escopo limitado e uma claim act (conforme o RFC 8693 do OAuth 2.0) que identifica o agente. O AgentCore Identity suporta a troca de token On-behalf-of, permitindo que agentes e servidores MCP troquem um token de acesso do usuário por um novo token com escopo restrito para um recurso downstream específico.

O contexto do tenant deve ser codificado em Tokens Web JSON (JWT — JSON Web Tokens) capturando três dimensões: Contexto de Segurança (claims padrão: iss, sub, exp, aud), Contexto do Tenant (tenant_id e escopos específicos) e Contexto da Requisição (atributos de domínio para lógica de negócio).

6. Controle de acesso granular para ferramentas MCP e APIs

Aplicações agênticas multi-tenant precisam restringir o acesso a servidores MCP por meio de políticas avaliadas em runtime — considerando cotas do tenant, permissões por tier e limites de uso. O AgentCore Policy intercepta e avalia todas as requisições dos agentes antes de permitir acesso a ferramentas, com políticas escritas em linguagem natural ou diretamente em Cedar.

Na camada de invocação, servidores MCP filtram as ferramentas disponíveis com base no tier do tenant, feature flags e limites de quota. O AgentCore Gateway permite que agentes acessem ferramentas de forma segura, transformando APIs e funções AWS Lambda em ferramentas compatíveis com agentes, com suporte a Amazon API Gateway, schemas OpenAPI, modelos Smithy, funções Lambda e servidores MCP.

Na camada de acesso a dados, políticas de Controle de Acesso Baseado em Atributos (ABAC — Attribute-Based Access Control) reforçam o isolamento usando condições do AWS Identity and Access Management (IAM — Identity and Access Management) para restringir o acesso a dados com base em tags e atributos do principal.

7. Memória: isolamento por namespace hierárquico

O gerenciamento de memória multi-tenant deve implementar cinco níveis lógicos: Global (conhecimento compartilhado entre tenants), Estratégia (padrões específicos por tipo de agente), Tenant (histórico e preferências do tenant), Usuário (contexto individual dentro do tenant) e Sessão (memória de curto prazo para conversas ativas).

O AgentCore Memory oferece isolamento por namespace hierárquico em todos esses níveis, com suporte a políticas baseadas em recursos e controle de acesso baseado em atributos para acesso granular. A implementação envolve construir identificadores compostos a partir de informações do tenant e do usuário (por exemplo, tenant_123:user_456) e prefixar todas as operações de memória com o caminho de namespace apropriado.

8. Identidade, confiança e descoberta de agentes

Conforme agentes interagem com outros agentes além das fronteiras organizacionais, três preocupações fundamentais emergem: identidade (quem é este agente e ele pode provar isso?), confiança (devo confiar neste agente?) e descoberta (como encontro o agente certo?).

O AgentCore Identity implementa identidades de agente como workload identities, com cada agente recebendo uma identidade verificável criptograficamente ancorada na conta AWS e na infraestrutura IAM da organização. Para confiança, a indústria ainda está trabalhando no problema — o Agent Naming Service (ANS) v2, atualmente um Internet-Draft da IETF (trabalho em andamento), ancora cada identidade de agente a um nome de domínio DNS, com três níveis de verificação: Bronze (PKI), Silver (PKI + DANE) e Gold (PKI + DANE + Transparency Log).

Para descoberta, o AWS Agent Registry, disponível via Amazon Bedrock AgentCore, oferece um catálogo centralizado para descobrir agentes, habilidades, servidores MCP e recursos customizados em uma organização, com busca por linguagem natural ou estruturada.

9. Rastreamento de custos por tenant e observabilidade

A atribuição precisa de custos em ambientes multi-tenant requer instrumentação a nível de aplicação que emita métricas tagueadas por tenant para cada invocação do agente, capturando tokens de entrada/saída, invocações de ferramentas e duração de execução. O AgentCore Observability oferece visibilidade em tempo real dos workflows dos agentes com integração compatível com OpenTelemetry, alimentada pelo Amazon CloudWatch.

10. Guardrails: segurança de conteúdo

Guardrails multi-tenant atuam em três pontos: pré-processamento (validação do input antes do processamento pelo agente, bloqueando prompt injections e sanitizando PII conforme requisitos de conformidade como HIPAA e PCI-DSS), pós-processamento (validação das respostas para precisão factual, detecção de alucinações e varredura por vazamento de dados sensíveis) e configurações por tenant ou tier.

O Amazon Bedrock Guardrails oferece filtragem de conteúdo e controles de segurança com políticas configuráveis para tópicos negados, filtros de conteúdo, filtros de palavras e redação de informações sensíveis.

Implementando os três padrões com o AgentCore

Padrão Silo

No modelo Silo, cada tenant opera dentro de uma stack totalmente isolada, com seu próprio AgentCore Runtime, AgentCore Gateway e AgentCore Memory, todos delimitados por fronteiras IAM separadas. O fluxo começa com a autenticação do usuário no provedor de identidade, que emite um JWT com o contexto do tenant. Um proxy da aplicação SaaS roteia a requisição para o agente correto com base nesse contexto, e o AgentCore Runtime valida o JWT, cria uma sessão microVM isolada e inicia o raciocínio do agente. Quando o agente precisa invocar ferramentas, chama o Gateway dedicado ao tenant, que valida o JWT, extrai o contexto e integra com os recursos backend específicos daquele tenant.

O trade-off é o maior overhead operacional, já que cada cliente executa recursos dedicados. Mas para workflows críticos de segurança e conformidade, o escopo limitado de impacto potencial justifica a escolha.

Padrão Pool

No modelo Pool, os recursos são compartilhados entre múltiplos tenants para maximizar a utilização e a eficiência operacional. O AgentCore Runtime e a lógica do agente são compartilhados, com o contexto do tenant extraído do JWT em cada execução. O AgentCore Memory é particionado com base no contexto do tenant usando namespace (por exemplo, actor_id: "tenant-a:user-123"). O Gateway centralizado roteia chamadas de ferramentas para recursos backend compartilhados, aplicando isolamento via credenciais e configurações com escopo por tenant.

O modelo Pool é altamente eficiente e pode ser a única opção viável quando há um grande número de tenants pequenos. O trade-off é a necessidade de maior rigor nos testes de controle de acesso granular e mais instrumentação para atribuição de custos por tenant.

Padrão Bridge

O modelo Bridge representa um meio-termo estratégico, combinando a eficiência de custo da infraestrutura compartilhada com os benefícios de segurança de recursos isolados. A ideia é poder escolher o nível de isolamento em cada camada e componente individualmente, em vez de estar preso a um padrão único. Por exemplo, é possível ter um AgentCore Runtime e Gateway siloed para tenants premium e um Runtime e Gateway pooled para tenants do tier padrão. Outra variação possível é um Runtime siloed com Gateway e ferramentas pooled.

Próximos passos

Este artigo cobre os conceitos fundamentais para construção de agentes multi-tenant. A AWS indicou que publicará posts subsequentes com implementações end-to-end dos modelos Pool e Silo, incorporando os componentes detalhados nas considerações de design. Para quem quiser colocar a mão na massa desde já, a AWS disponibilizou um workshop de agentes multi-tenant com experiência prática usando o Amazon Bedrock AgentCore.

Fonte

Building multi-tenant agents with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/building-multi-tenant-agents-with-amazon-bedrock-agentcore/)

O que é o KY3P e por que isso importa

A Amazon Web Services (AWS) concluiu a avaliação de segurança do Conheça Seu Terceiro (KY3P), conduzida pela S&P Global. Com isso, os clientes da AWS passam a ter acesso a um relatório padronizado que pode simplificar bastante o processo de due diligence de fornecedores — especialmente para empresas de setores regulados, como o financeiro.

O KY3P, também conhecido como S&P Global Comprehensive Assessment (anteriormente chamado de TruSight), é uma avaliação validada e baseada em evidências. Seu propósito é apoiar a conformidade regulatória e facilitar a troca padronizada de dados de risco entre a AWS e seus clientes. O diferencial da metodologia é que ela vai além de políticas e declarações: ela valida a implementação e operação real dos controles de segurança.

O que a avaliação cobre

A metodologia de avaliação de risco do KY3P contempla mais de 200 controles distribuídos em 26 categorias e nove domínios de risco. Entre os temas abordados estão:

• Privacidade
• Gerenciamento de Redes
• Gerenciamento de Acesso Lógico
• Segurança Física e Ambiental

Os critérios de avaliação foram desenvolvidos por um consórcio de instituições financeiras líderes no mercado global. Isso confere ao KY3P um alto nível de reconhecimento e credibilidade junto a reguladores e auditores.

Como isso beneficia os clientes da AWS

Com a adoção da nuvem crescendo em ritmo acelerado em diferentes setores, a AWS se tornou um componente crítico nos ambientes de terceiros de muitas organizações. Clientes em setores regulados — como o financeiro — precisam cumprir exigências rigorosas de due diligence sobre seus fornecedores, e isso inclui provedores de nuvem.

O relatório KY3P permite que esses clientes mapeiem os controles da AWS em relação a frameworks e padrões amplamente utilizados, como:

• Estrutura de Cibersegurança do NIST versão 2 (NIST CSF v2)
• Padrão de Segurança de Dados da Indústria de Cartões de Pagamento versão 4.0 (PCI DSS 4.0)
• ISO 27001:2022

Isso significa que, em vez de conduzir avaliações independentes e repetitivas, as empresas podem usar os resultados do KY3P para obter visibilidade imediata sobre a cobertura de controles da AWS — reduzindo esforço operacional e acelerando processos de conformidade.

Como acessar o relatório

Para saber como obter acesso ao relatório, a AWS disponibiliza uma página dedicada. Mais informações estão disponíveis na página de avaliação AWS KY3P. Quem quiser explorar outros programas de conformidade da AWS também pode consultar os Programas de Conformidade da AWS.

Fonte

AWS KY3P report now available for third-party supplier due diligence (https://aws.amazon.com/blogs/security/aws-ky3p-report-now-available-for-third-party-supplier-due-diligence/)

O que foi anunciado

A AWS anunciou uma expansão significativa no Amazon CloudWatch Logs Insights: a linguagem de consulta do serviço passou a suportar 13 novos comandos e funções, ampliando consideravelmente as possibilidades de análise de logs diretamente na plataforma.

Para quem trabalha no dia a dia com observabilidade e monitoramento na AWS, essa atualização resolve uma série de limitações práticas que antes exigiam processamento externo ou gambiarras nas queries.

Quais são as novidades

Os novos recursos foram organizados em três categorias principais:

Funções de string e numéricas

• round — arredondamento de valores numéricos
• startswith — filtra registros cujo campo começa com determinado prefixo
• endswith — filtra registros cujo campo termina com determinado sufixo
• case — lógica condicional dentro da query
• regex_replace — substituição de padrões via expressão regular
• haversine — cálculo de distância geográfica entre coordenadas

Funções de codificação e decodificação

• urlencode e urldecode — codificação e decodificação de URLs
• base64encode e base64decode — codificação e decodificação de payloads em Base64 diretamente na query

Novos comandos de parsing e análise

• parse logfmt — faz o parsing de logs estruturados no formato logfmt, convertendo-os em campos individuais
• expand — expande arrays JSON aninhados em registros individuais
• relevantfields — identifica e exibe automaticamente os campos mais relevantes em grupos de logs com alta cardinalidade

Por que isso importa na prática

Quem analisa logs no CloudWatch Logs Insights frequentemente se deparava com situações como: precisar manipular strings diretamente na query, decodificar valores em Base64 sem sair da interface, fazer parsing de logs que não estavam em formato JSON, ou ainda calcular distâncias geográficas a partir de coordenadas registradas nos logs.

Com esses 13 novos recursos, a AWS reduz a necessidade de pré-processar ou transformar logs antes de consultá-los, tornando o fluxo de análise mais ágil e centralizado.

Disponibilidade

Todos os novos comandos e funções já estão disponíveis em todas as regiões comerciais da AWS. Para explorar os detalhes de uso e sintaxe de cada função, a AWS disponibiliza a documentação oficial do Amazon CloudWatch Logs.

Fonte

Amazon CloudWatch Logs Insights adds new query commands and functions (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cloudwatch-logs-insights/)

O que foi anunciado

A AWS anunciou a disponibilidade geral do Amazon Aurora MySQL 8.4, versão compatível com o MySQL 8.4 da comunidade — uma versão de Suporte de Longo Prazo (LTS) do MySQL. A novidade traz compatibilidade com o MySQL 8.4.7 da comunidade e uma mudança importante na forma como as versões são numeradas.

Versionamento alinhado com a comunidade

A partir do Aurora MySQL 8.4, o número de versão que aparece no seu cluster passa a corresponder diretamente à versão do MySQL da comunidade com a qual ele é compatível. Isso simplifica bastante o entendimento de qual base de código está sendo executada. Além disso, a AWS continua gerenciando os patches subjacentes automaticamente, reduzindo o trabalho operacional do dia a dia.

A AWS também definiu metas públicas de atualização: versões principais serão lançadas em até 12 meses após o lançamento de uma versão LTS da comunidade, versões menores em até 3 meses, e uma versão LTS menor do Aurora em até 12 meses após cada versão principal. Para acompanhar os objetivos de lançamento por engine, a AWS disponibilizou a agenda de lançamentos open source do Aurora e RDS.

Segurança reforçada por padrão

O Aurora MySQL 8.4 chega com configurações de segurança mais rígidas para novos clusters. Os destaques são:

• TLS obrigatório por padrão, com suporte apenas a TLS 1.2 e 1.3
• Novas contas utilizam o plugin de autenticação caching_sha2_password
• Políticas de validação de senha configuráveis via grupos de parâmetros do cluster de banco de dados

Verificações automáticas antes do upgrade

Antes de o cluster ficar offline durante uma atualização, verificações automatizadas de pré-upgrade identificam possíveis problemas de compatibilidade. Isso dá mais confiança para quem precisa migrar de versões anteriores. Para entender melhor a experiência completa do cliente com essa versão, a AWS publicou o blog de lançamento do Aurora MySQL 8.4.

Como fazer o upgrade ou a migração

Existem três caminhos para atualizar um banco de dados existente para o Aurora MySQL 8.4:

• Amazon RDS Blue/Green Deployments
• Upgrade in-place
• Restauração a partir de um snapshot

Para detalhes sobre como realizar upgrades de versão principal, o Guia do Usuário do Amazon Aurora é o ponto de partida recomendado.

Para quem está migrando de fontes MySQL externas, as opções disponíveis são o AWS Database Migration Service ou o Percona XtraBackup.

Disponibilidade

O Aurora MySQL 8.4 já está disponível em todas as regiões da AWS onde o Aurora MySQL é suportado. Para começar a usar, a AWS disponibiliza uma página de introdução ao Amazon Aurora.

Fonte

Amazon Aurora MySQL 8.4 is now generally available (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-aurora-mysql/8-4/)

Visibilidade de identidade agora dentro do Security Hub

A AWS anunciou uma atualização relevante para equipes de segurança: o AWS Security Hub agora é capaz de identificar riscos de identidade originados por acessos não utilizados. Permissões, funções (roles) e credenciais do Gerenciamento de Identidade e Acesso (IAM) que estão ociosas passam a ser detectadas diretamente no mesmo console centralizado onde as equipes já acompanham ameaças, exposições e achados de postura de segurança.

Antes dessa mudança, gerenciar riscos de identidade em centenas de contas AWS exigia alternar entre múltiplas ferramentas, sem uma visão unificada que conectasse permissões não utilizadas à exposição real de recursos. Agora, esses riscos de identidade aparecem lado a lado com os demais achados de segurança, permitindo que as equipes priorizem a remediação com base no risco organizacional real.

Como funciona na prática

Ao habilitar o Security Hub para a organização, um IAM Access Analyzer vinculado ao serviço é criado automaticamente em cada conta membro — sem nenhuma configuração adicional necessária. A partir daí, o Security Hub:

• Avalia os principais do IAM com base em 90 dias de atividade de acesso real;
• Detecta acessos não utilizados nesse período;
• Correlaciona os achados de identidade com o contexto de exposição, ajudando as equipes a focar nos riscos que realmente importam.

Além disso, o serviço oferece a geração sob demanda de políticas de menor privilégio recomendadas, baseadas nos padrões de uso real. Isso ajuda as equipes a refinarem as permissões do IAM e a reduzirem a superfície de ataque da organização.

Parte de uma evolução maior

A AWS posiciona essas capacidades como um passo fundamental em direção a um gerenciamento mais amplo de direitos de infraestrutura em nuvem dentro do Security Hub. Tudo isso entregue com os mesmos fluxos de trabalho, regras de automação e integrações downstream já existentes na plataforma — sem quebrar o que as equipes já usam.

Disponibilidade e custo

Essas funcionalidades estão incluídas no Security Hub Essentials sem custo adicional. Para saber mais sobre como os achados de acesso não utilizado funcionam, a AWS disponibiliza documentação detalhada no Guia do Usuário do AWS Security Hub e na página do produto AWS Security Hub. A lista completa de regiões onde o serviço está disponível pode ser consultada na Lista de Serviços Regionais da AWS.

Fonte

AWS Security Hub now uncovers identity risks from unused access (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-hub-unused-access/)

O que mudou no Security Hub Extended

A AWS anunciou a expansão do plano Security Hub Extended, que passa a contar com 21 soluções parceiras curadas organizadas em 9 categorias de segurança. Sete novos fornecedores foram incorporados nesta rodada de atualizações:

• SentinelOne — segurança de endpoint
• CyberArk — segurança de identidade
• Sublime — segurança de e-mail
• Varonis — segurança de dados
• LayerX — segurança de navegador
• Native Security — segurança em nuvem
• Zenity — segurança de Inteligência Artificial (IA)

Com essa ampliação, as equipes de segurança ganham mais flexibilidade para montar uma stack que realmente se encaixe nas necessidades da sua organização, podendo escolher entre líderes consolidados de mercado e fornecedores em ascensão dentro de cada domínio.

O que é o Security Hub Extended

O Security Hub Extended é um plano do AWS Security Hub desenhado para simplificar a forma como empresas adquirem, implantam e integram uma solução de segurança corporativa de pilha completa. Ele cobre as seguintes camadas:

• Endpoint
• Identidade
• E-mail
• Rede
• Dados
• Navegador
• Nuvem
• Inteligência Artificial (IA)
• Operações de segurança

A proposta é reunir soluções da própria AWS e de parceiros em um único ponto de controle, facilitando a identificação e a resposta a riscos que atravessam diferentes fronteiras tecnológicas.

Como os dados das soluções parceiras chegam ao Security Hub

Um ponto técnico importante: todas as soluções participantes emitem seus alertas e descobertas de segurança no padrão Esquema Aberto de Segurança Cibernética (OCSF — Open Cybersecurity Schema Framework). Isso significa que os dados chegam automaticamente agregados dentro do AWS Security Hub, sem necessidade de integrações manuais ou transformações de formato.

Modelo comercial: sem amarras de longo prazo

Do ponto de vista comercial, a AWS estruturou o plano com algumas características que tendem a facilitar a adoção em ambientes corporativos:

• Precificação pay-as-you-go publicada e transparente para todas as soluções
• Fatura única consolidada na AWS
• Elegibilidade automática ao Programa de Desconto Empresarial (EDP — Enterprise Discount Program)
• Suporte unificado de Nível 1 para clientes do AWS Enterprise Support
• Sem compromissos de longo prazo

Disponibilidade

As sete novas soluções parceiras já estão disponíveis em todas as regiões comerciais da AWS onde o Security Hub opera. Para verificar quais regiões são suportadas, consulte a tabela de regiões da AWS.

Para detalhes sobre preços, acesse a página de preços do AWS Security Hub. Para começar a explorar o plano, o acesso pode ser feito pelo console do AWS Security Hub ou pela página do produto.

Fonte

Security Hub Extended expands to 21 curated partner solutions across 9 categories (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-hub-extended/)

O problema central: LLMs não são atores confiáveis

Agentes de IA têm uma característica fundamental que os diferencia de sistemas tradicionais: eles se adaptam. Encontram múltiplos caminhos para resolver um problema, tomam decisões em tempo real e operam com autonomia. Essa flexibilidade é justamente o que os torna úteis — mas também é o que cria um desafio sério de segurança.

O Modelo de Linguagem Grande (LLM) no coração de um agente é não determinístico. Suas decisões não podem ser previstas ou garantidas antecipadamente. Ele pode alucinar ações prejudiciais com total confiança. É vulnerável a ataques de injeção de prompt, nos quais adversários inserem comandos maliciosos por meio de respostas de ferramentas ou entradas do usuário. Para um LLM, comandos e dados são a mesma coisa — apenas tokens.

Por isso, do ponto de vista de segurança, a abordagem correta é tratar o LLM como um ator não confiável. Isso não é pessimismo; é defesa em profundidade.

A boa notícia é que o LLM não age diretamente sobre o mundo externo. Ele precisa passar por um orquestrador que invoca ferramentas com base em sua saída. É exatamente nesse ponto de passagem que os controles precisam ser aplicados. O que se precisa nessa fronteira é de autorização: uma decisão sobre se cada invocação de ferramenta deve ser permitida e sob quais condições.

Por que as abordagens comuns não são suficientes

Dois caminhos costumam ser adotados para lidar com esse problema, mas ambos têm limitações importantes:

• Fluxos de trabalho hard-coded: eliminam a incerteza, mas também eliminam o propósito de usar um LLM como cérebro do agente. Você acaba construindo uma aplicação tradicional com uma interface de LLM. Além disso, mesmo com essa restrição, usar saídas de LLM em qualquer etapa reabre os mesmos riscos.
• Humano no loop (human-in-the-loop): oferece uma rede de segurança para operações críticas e sempre terá seu papel. Mas depender disso como mecanismo principal de controle sacrifica a autonomia e pode gerar fadiga de aprovação.

O que se precisa é de uma camada de aplicação auditável e determinística que fique fora do agente e das ferramentas. Por quê fora? Porque o plano do LLM é exatamente a coisa que não se pode confiar — ele não pode ser responsável por aplicar suas próprias restrições. Controles na camada do LLM, como prompts de sistema e alinhamento em tempo de treinamento, podem ser contornados por injeção de prompt ou alucinação. Verificações hard-coded no código do agente ou das ferramentas são mais robustas, mas tornam-se difíceis de auditar e gerenciar em escala, especialmente quando a lógica de segurança está espalhada por muitas ferramentas e serviços.

Centralizar a autorização fora de ambos fornece um único ponto de verificação que o LLM não pode contornar — auditável e verificável independentemente do código da aplicação.

Onde entram as Políticas do AgentCore

O Amazon Bedrock AgentCore Gateway fica entre o agente e as ferramentas remotas que ele acessa. Quando uma Política do AgentCore é associada a um Gateway, tudo é bloqueado por padrão. As políticas abrem seletivamente essa fronteira, especificando quais invocações de ferramentas são permitidas e sob quais condições. Essa aplicação vale para todo o tráfego de ferramentas roteado pelo Gateway.

O Amazon Bedrock AgentCore oferece a infraestrutura para implantar e gerenciar agentes em escala. Ele inclui o AgentCore Runtime para hospedar agentes, o AgentCore Gateway para gerenciar como os agentes se conectam a ferramentas usando o Protocolo de Contexto de Modelo (MCP), e a Policy no AgentCore. A Policy intercepta todo o tráfego do agente pelos gateways e avalia cada requisição contra as políticas definidas antes de permitir o acesso à ferramenta.

Para que essa abordagem escale, as políticas precisam ser mais simples de entender do que o comportamento do agente. E é aí que entra o Cedar.

O que é o Cedar e por que foi escolhido

Cedar é uma linguagem de políticas de autorização de código aberto desenvolvida pela AWS que recentemente ingressou na Cloud Native Computing Foundation (CNCF). Ele foi projetado com propriedades específicas: é construído exclusivamente para autorização, legível por humanos e analisável por máquinas usando raciocínio automatizado.

Linguagem natural é ambígua demais para infraestrutura crítica de segurança. Linguagens de programação de uso geral, como Python, são muito expressivas, mas difíceis de analisar — podem ter efeitos colaterais não intencionais, problemas de terminação e são difíceis de entender. O Cedar evita esses problemas excluindo loops e operações com estado, então a avaliação de políticas termina em tempo O(n) nos casos comuns. Esse tempo de execução limitado significa que os agentes podem tomar decisões de autorização sem prejudicar a experiência do usuário.

Como o Cedar é usado pelo AgentCore

A AgentCore Policy usa o Cedar e suas capacidades de análise matemática em vários pontos do fluxo de trabalho do AgentCore Gateway: o motor de autorização Cedar é usado na avaliação de políticas, e o Cedar Analysis é usado durante a criação de políticas e no plano de controle.

Criação de políticas com IA neuro-simbólica

Desenvolvedores podem escrever políticas Cedar diretamente ou usar linguagem natural que é traduzida para Cedar por meio de um loop de feedback de IA neuro-simbólica. Essa abordagem combina a flexibilidade do aprendizado de máquina com a exatidão provável do raciocínio automatizado: um LLM gera políticas a partir da linguagem natural, enquanto o Cedar Analysis as valida usando raciocínio simbólico e matemático.

O fluxo funciona assim: um administrador especifica — em linguagem natural — quais ferramentas MCP o agente pode chamar e sob quais condições. O loop neuro-simbólico formaliza essa descrição em políticas Cedar. Primeiro, o LLM traduz a linguagem natural em políticas Cedar. Em seguida, essas políticas passam por dois estágios de verificação.

No primeiro estágio, a AgentCore Policy usa um gerador de schema que recebe as descrições das ferramentas MCP e produz um schema Cedar. O Cedar valida as políticas contra esse schema, ajudando a garantir que elas referenciem ferramentas e parâmetros válidos e eliminando classes inteiras de erros em tempo de execução. Se a validação passar, o segundo estágio executa o Cedar Analysis, que codifica cada política como uma fórmula matemática e detecta problemas como políticas que concedem ou negam tudo, ou que contêm condições impossíveis.

Plano de controle

Ao associar políticas a um AgentCore Gateway, o Cedar Analysis realiza uma análise holística de todo o conjunto de políticas. Em vez de analisar políticas isoladamente, ele examina como elas interagem e qual é o efeito combinado. Essa análise identifica possíveis erros lógicos — como políticas conflitantes ou redundantes — e detecta se o conjunto de políticas produz resultados de autorização não intencionais.

Aplicação na invocação de ferramentas MCP

Cada requisição de ferramenta feita ao gateway do AgentCore é avaliada contra as políticas Cedar, que determinam se a invocação da ferramenta MCP com os argumentos fornecidos deve ser permitida. Isso cria o envelope de segurança enquanto permite as pontes necessárias para que o agente realize seu trabalho.

Filtragem de ferramentas MCP

O Cedar habilita uma camada adicional de proteção que opera antes de qualquer invocação de ferramenta. Quando um agente emite um comando de listagem de ferramentas, o AgentCore Gateway usa a capacidade de avaliação parcial do Cedar para determinar quais ações sempre seriam negadas sob o conjunto de políticas atual. Essas ações são omitidas da resposta de listagem de ferramentas. O agente e o LLM subjacente nunca veem essas ações de ferramentas, eliminando uma classe inteira de risco: o agente não pode tentar invocar uma ferramenta que não sabe que existe.

Legibilidade: políticas que auditores entendem

Conformidade regulatória e auditorias de segurança exigem políticas que humanos possam entender e verificar. As políticas Cedar se leem como linguagem natural estruturada, tornando-as acessíveis a equipes de segurança, responsáveis por conformidade e partes interessadas do negócio. Veja um exemplo do artigo original:

// Only allow bulk discounts for premium customers with sufficient quantity
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ApplyBulkDiscount",
  resource
) when {
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Platinum" &&
  context.input.orderQuantity >= 50
} unless {
  context.input
    .productTypes
    .containsAny (
      ["limited_edition", "seasonal_specials"]
    )
};

Auditores sem formação técnica conseguem entender essa política: “Permitir descontos em volume para clientes Platinum que pedem pelo menos 50 itens, exceto para produtos de edição limitada ou especiais de temporada.” A cláusula unless torna a exceção clara, que é como as regras de negócio são tipicamente expressas em linguagem natural.

Vale notar que essa única política restringe duas fontes de dados diferentes. O nível do cliente vem de uma declaração de Token Web JSON (JWT) — não pode ser alucinado ou manipulado pelo LLM. As entradas da ferramenta, como quantidade do pedido e tipos de produto, porém, originam-se da chamada de ferramenta do LLM. As políticas Cedar restringem essas entradas apenas a valores permitidos, garantindo que mesmo se o LLM produzir argumentos inesperados, a camada de aplicação de políticas os rejeite deterministicamente.

Análise formal para verificação de políticas

As políticas Cedar podem ser codificadas como fórmulas matemáticas e analisadas usando técnicas de raciocínio automatizado por meio de um codificador simbólico. A análise de políticas, incluindo comparação de políticas, está disponível como uma ferramenta CLI de código aberto.

Detectando erros lógicos

O Cedar Analysis pode detectar quando políticas contêm erros lógicos. Por exemplo, o artigo original mostra uma política com restrições contraditórias — o nível do cliente não pode ser simultaneamente “Gold” e “Platinum”. A intenção era usar || em vez de &&, um erro que tanto humanos quanto sistemas de IA podem cometer ao criar políticas. O Cedar Analysis também detecta políticas que sempre permitem uma determinada ação, geralmente uma indicação de política excessivamente permissiva.

// This policy cannot allow any requests due to logical errors
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
) when {
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Gold" &&
  principal.getTag("customer_tier") == "Platinum"
} unless {
  context.input.refundAmount > 1000
};

Detectando conflitos entre políticas

O Cedar Analysis também analisa o conjunto completo de políticas para detectar inconsistências entre políticas individuais diferentes. O artigo original apresenta um exemplo onde uma política permit permite que clientes Gold processem reembolsos abaixo de $100, enquanto uma política forbid bloqueia clientes Gold (e Platinum) de processar reembolsos abaixo de $500. Como forbid tem precedência sobre permit no Cedar, a política forbid bloquearia todos os reembolsos de clientes Gold apesar da política permit.

Comparando mudanças de políticas

Ao atualizar políticas, o Cedar Analysis pode determinar o impacto exato de uma mudança. O artigo original mostra um exemplo onde uma modificação na cláusula unless — aparentemente mais restritiva à primeira vista — na verdade torna a política mais permissiva. O Cedar Analysis detecta isso automaticamente e gera uma tabela mostrando a diferença em permissividade entre o conjunto original e o atualizado:

Principal type    Action              Resource type    Status
OAuthUser         ProcessRefund       Gateway          Equivalent
OAuthUser         ApplyBulkDiscount   Gateway          More permissive

Essa capacidade de verificação formal é essencial quando agentes operam autonomamente e podem afetar o mundo real. Organizações precisam de certeza matemática de que suas políticas se comportarão conforme o esperado.

Comportamento determinístico para governança confiável

Ao contrário dos modelos probabilísticos de IA, a segurança empresarial exige garantias determinísticas. As políticas Cedar sempre produzem a mesma decisão de autorização para requisições idênticas, independentemente da ordem de avaliação ou do estado do sistema. A semântica padrão do Cedar — negar por padrão, forbid vence, sem ordenação — ajuda a garantir comportamento previsível.

De políticas para produção

O Raciocínio automatizado já provou seu valor em toda a AWS, desde o AWS IAM Access Analyzer verificando políticas de acesso até segurança comprovável para configurações de rede. Aplicar essas mesmas técnicas à IA agêntica é uma extensão natural: à medida que os agentes assumem mais responsabilidades, a necessidade de garantias matematicamente fundamentadas só cresce.

A abordagem neuro-simbólica descrita — combinando a flexibilidade do LLM com o rigor do raciocínio automatizado — aponta para um futuro onde agentes podem ser ao mesmo tempo mais autônomos e mais confiáveis, porque a verificação acompanha a autonomia.

A Policy já está disponível como parte do Amazon Bedrock AgentCore Gateway. Para saber mais sobre o Cedar e suas capacidades, visite o site do Cedar, experimente o Cedar playground ou participe da comunidade Cedar no Slack da CNCF. Para mais informações sobre a Policy no Amazon Bedrock AgentCore Gateway, consulte a documentação da AWS ou explore o console do AgentCore Gateway.

Fonte

Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows (https://aws.amazon.com/blogs/security/why-policy-in-amazon-bedrock-agentcore-chose-cedar-for-securing-agentic-workflows/)

Uma nova forma de adotar segurança enterprise

A AWS publicou o terceiro artigo da série sobre o Security Hub Extended, e desta vez o foco não é técnico — é filosófico. O texto explica por que a solução foi construída da forma que foi, e defende que o modelo tradicional de aquisição de produtos de segurança enterprise está pronto para uma transformação fundamental.

Se você acompanhou os posts anteriores da série, já sabe o que é o Security Hub Extended: na primeira publicação, a AWS apresentou o produto como uma expansão significativa do Security Hub que reúne soluções de parceiros curados em uma experiência unificada. Na segunda publicação, o foco foi técnico — fluxo de integração, modelo de preços e a camada de operações unificada baseada no Open Cybersecurity Schema Framework (OCSF). Agora, o texto dá um passo atrás para discutir a motivação por trás de tudo isso.

O problema com o modelo atual de aquisição

Quem já tentou avaliar um novo produto de segurança enterprise conhece bem o processo: solicitar uma demonstração, esperar, assistir à demo, pedir uma Prova de Conceito (PoC), aguardar a equipe de serviços profissionais configurar tudo, negociar preços que não estão publicados em lugar nenhum, envolver o setor de compras e, por fim, assinar um contrato de múltiplos anos. Meses depois, você finalmente descobre se o produto resolve ou não o seu problema no seu ambiente específico.

Enquanto isso, um engenheiro de segurança mais ágil da sua equipe já instalou uma ferramenta de código aberto, conectou dados reais e, em duas horas, sabe se a solução funciona para os casos de uso da empresa. Ele não precisou de apresentação de slides. Precisou de algo que pudesse colocar as mãos.

A AWS ilustra esse ponto com um relato emblemático: um CISO de uma empresa Fortune 500 afirmou ter levado 9 meses para contratar uma solução de segurança — e que ela ainda não funcionava da forma como foi demonstrada. Essa frustração, segundo a AWS, não é exceção. É a norma.

O artigo é cuidadoso ao não demonizar o modelo de vendas tradicional. Vendas assistidas evoluíram por boas razões: procurement enterprise é complexo, produtos precisam de customização e clientes precisam de suporte. O ponto central é outro: as ameaças evoluem constantemente, e os times de defesa precisam de flexibilidade para descobrir e implantar novas soluções na mesma velocidade em que o cenário muda.

O que duas décadas de AWS ensinaram sobre adoção em escala

A AWS argumenta que passou vinte anos aprendendo como permitir que clientes adotem tecnologia enterprise complexa nos seus próprios termos e em escala massiva. Computação, armazenamento, bancos de dados, Inteligência Artificial e Aprendizado de Máquina (IA/ML), redes e segurança — tudo adotado via console, no ritmo de cada cliente, escalado quando estavam prontos.

Serviços como Amazon GuardDuty, Amazon Inspector, AWS Shield e AWS Security Hub estão disponíveis no Console de Gerenciamento da AWS, todos com modelo de pagamento por uso (pay-as-you-go) e ativados com um clique. Dezenas de milhares de clientes — de startups de duas pessoas a grandes instituições financeiras — adotam esses serviços da mesma forma: experimentam, percebem o valor, expandem e aprofundam o uso.

Segundo a AWS, chegar a esse ponto exigiu um mindset de produto diferente: o tempo para obter valor (time-to-value) se torna a métrica mais importante, a fricção no processo de integração (onboarding) vira o maior inimigo e a transparência de preços passa a ser inegociável. Não foi um caminho sem erros — o texto é honesto sobre isso —, mas os resultados são claros: quando clientes adotam com base na experiência e não no compromisso, eles não apenas ficam, como expandem o uso e se tornam defensores do produto.

A lógica por trás do Security Hub Extended

Com essa base estabelecida, a AWS se fez a pergunta que originou o Security Hub Extended: por que não construir uma abordagem similar para soluções de parceiros líderes de mercado? Por que empresas como CrowdStrike, Splunk, Zscaler e inovadores emergentes como Cyera, Noma e 7AI não poderiam chegar até os clientes com a mesma experiência sem fricção que os serviços nativos da AWS têm?

O argumento é que esses parceiros construíram produtos incríveis, mas nem sempre tiveram um canal para colocar esses produtos diretamente nas mãos dos clientes que mais precisam deles, no momento certo, em escala, de forma tão natural quanto ativar um serviço da AWS.

É exatamente isso que o Security Hub Extended propõe ser: não uma substituição da forma como os parceiros constroem ou vendem, mas uma infraestrutura que permite que seus produtos falem por si mesmos.

Como funciona na prática

Para equipes que já utilizam o Security Hub, as soluções de parceiros curados ficam disponíveis para descoberta diretamente ao lado dos serviços de segurança da AWS. O modelo é:

• Um clique para avaliar, um clique para implantar
• Preços pay-as-you-go na fatura existente da AWS, com descontos do Programa de Desconto Enterprise (EDP) aplicados automaticamente
• Sem ciclo de procurement separado e sem compromissos de longo prazo obrigatórios
• Possibilidade de começar rápido, validar em escala e, quando estiver pronto, assumir compromissos para descontos maiores

Mas o Security Hub Extended não é apenas uma forma mais simples de comprar produtos de segurança. É também uma solução unificada. Quando um cliente habilita uma solução pelo Extended, a AWS trabalha para que a experiência seja integrada de ponta a ponta:

• Sensores implantados automaticamente em workloads do Amazon EC2, Amazon EKS e AWS Fargate, usando o mesmo mecanismo do GuardDuty Runtime Monitoring
• Funções do IAM (Identity and Access Management — Gerenciamento de Identidade e Acesso) provisionadas em toda a Organização com um clique
• Inventário de recursos automatizado desde o primeiro dia — buckets S3, bancos de dados, workloads de IA — sem trabalho manual
• Soluções emitem findings no formato OCSF, automaticamente agregados no Security Hub ao lado de findings do GuardDuty, Inspector e demais serviços de segurança da AWS

O Security Hub aplica pontuação de risco e análise correlacionada em todos eles — findings nativos da AWS e de terceiros juntos, ponderados e priorizados em uma visão única da postura de segurança.

Correlação que nenhuma solução isolada consegue

Um dos pontos mais relevantes do artigo é a capacidade de correlação entre soluções. Um exemplo citado: uma detecção de endpoint pelo CrowdStrike, correlacionada com um roubo de credencial identificado pelo GuardDuty e um evento de acesso a dados detectado pelo Cyera, produz um caminho de ataque (attack path) que nenhuma dessas soluções conseguiria gerar sozinha.

Essa correlação usa o contexto nativo da AWS — topologia do IAM, exposição de VPC (Virtual Private Cloud — Nuvem Privada Virtual), criticidade dos recursos — para enriquecer o contexto de cada caminho de ataque para os analistas de segurança. Habilitar uma solução pelo Security Hub Extended não adiciona mais um painel isolado. Aprofunda a inteligência do painel que você já tem.

A AWS também menciona que está desenvolvendo resposta automatizada: os clientes poderão optar por playbooks pré-construídos que tomam ações via serviços nativos da AWS quando uma ameaça é detectada — como isolar recursos comprometidos, revogar credenciais ou conter ameaças ativas. O objetivo declarado é chegar a uma resposta em segundos, não nas horas que leva hoje para alternar entre cinco consoles e dois sistemas de tickets.

Onde o produto está hoje e para onde vai

A AWS é transparente sobre o estágio atual: ainda é o “primeiro inning”, ou o famoso “Dia 1” da cultura Amazon. O produto foi lançado em fevereiro de 2026 com 14 parceiros e já conta com 21, cobrindo endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA e operações de segurança.

O feedback mais recorrente dos clientes, segundo o artigo, é que a simplificação do procurement e a flexibilidade do pay-as-you-go com preços públicos — mesmo antes de considerar os benefícios de operações unificadas e normalização de dados — já representam um diferencial significativo.

Para quem quiser explorar, o Security Hub Extended já está disponível. Basta acessar o Security Hub, buscar pelo plano Security Hub Extended ou visitar a página de preços do Security Hub Extended. O modelo é pay-as-you-go, sem compromisso. A recomendação da AWS é começar pelo que resolve o problema mais urgente — a equipe saberá se está funcionando em dias, não em meses.

Para compartilhar feedback, a AWS indica o AWS re:Post para o Security Hub ou o suporte da AWS.

Por que isso importa para equipes de segurança brasileiras

O Security Hub Extended representa uma mudança de paradigma relevante para qualquer equipe de segurança que opera na AWS. A proposta de consolidar soluções de parceiros líderes de mercado dentro do mesmo fluxo operacional dos serviços nativos — com preços transparentes, sem procurement demorado e com correlação automática de dados — resolve uma dor real e conhecida por qualquer profissional de segurança que já passou por um processo de avaliação enterprise tradicional.

O produto ainda está em evolução, e a própria AWS reconhece isso com transparência. Mas a direção é clara, e os sinais iniciais de adoção descritos no artigo indicam que a aposta está ressoando com o mercado.

Fonte

AWS Security Hub Extended: Why enterprise security products should sell themselves (https://aws.amazon.com/blogs/security/aws-security-hub-extended-why-enterprise-security-products-should-sell-themselves/)

O problema que política como código resolve

Manter requisitos de segurança e conformidade aplicados de forma consistente em toda a infraestrutura de nuvem é um desafio real para a maioria das organizações. Um workload pode acabar sendo implantado em uma Região da AWS que nunca foi aprovada para aquela classe de dado. Em outro ambiente, um security group pode permitir acesso mais amplo do que o pretendido. Tags obrigatórias podem estar faltando. Criptografia pode ser assumida, mas não configurada.

Esses gaps criam risco, aumentam o esforço de revisão e tornam auditorias mais difíceis do que precisam ser. Revisão manual ajuda, mas não escala quando a entrega acelera e mais times provisionam infraestrutura diretamente.

É aqui que política como código entra. Ela transforma a intenção de controle em verificações preventivas que rodam no fluxo de entrega. Um modelo baseado em padrões torna essas verificações mais simples de revisar, manter e explicar.

Organizando políticas em torno de padrões recorrentes

Times às vezes constroem regras serviço a serviço, o que pode tornar as bibliotecas de política como código difíceis de revisar e expandir à medida que crescem. Uma abordagem baseada em padrões organiza as políticas em torno da intenção de controle recorrente, e não em verificações específicas por serviço. Isso facilita a cobertura, a explicação e a evolução das políticas conforme a infraestrutura muda.

O conjunto prático de padrões inclui:

• Metadados obrigatórios — para tags e outros campos usados para identificar propriedade, suporte, alocação de custos e automação.
• Configuração permitida — para Regiões aprovadas, limites de implantação aceitos e outras configurações autorizadas.
• Restrição de exposição — para configurações que tornam a infraestrutura mais acessível do que o pretendido, como ingresso público ou recursos voltados para a internet no ambiente errado.
• Aplicação de proteção — para salvaguardas de linha de base como criptografia, logging ou proteção contra exclusão.
• Restrição de privilégio — para definições do Gerenciamento de Identidade e Acesso da AWS (IAM) e padrões de acesso que precisam de validação mais rigorosa.

Um engenheiro de conformidade pode descrever um requisito como “metadados obrigatórios”. Um engenheiro de nuvem pode descrever o mesmo requisito como “padrão de tagging”. A estrutura de padrões ajuda os dois times a falarem sobre a mesma coisa.

Onde o OPA se encaixa em um modelo de governança em camadas

O Open Policy Agent (OPA) atua na camada preventiva — ele valida que as mudanças de infraestrutura estão alinhadas com as expectativas antes do deploy. O OPA avalia entradas estruturadas (o JSON do plano do HashiCorp Terraform) contra a lógica de política.

Ele não substitui os serviços de governança da AWS que fornecem guardrails organizacionais, monitoramento contínuo e aplicação em nível de recurso após os recursos existirem. A divisão de responsabilidades funciona assim:

• OPA — verifica as mudanças propostas antes do deploy.
• AWS Organizations e AWS Control Tower — estabelecem guardrails organizacionais.
• AWS Config e AWS Security Hub — fornecem visibilidade e monitoramento após os recursos existirem.
• Proteções em nível de serviço — aplicam configurações na fronteira do recurso.

Como integrar a validação de política no pipeline de CI/CD

O fluxo de implementação segue uma sequência clara dentro do pipeline:

1. Enviar uma mudança via pull request ou merge request.
2. Executar validações iniciais: formatação, validação de sintaxe e verificações de dependência.
3. Gerar um plano do Terraform e convertê-lo para o formato JSON.
4. Avaliar o plano (em formato JSON) contra a biblioteca compartilhada de políticas OPA.
5. Publicar o relatório de validação como um artefato.
6. Executar verificações adicionais de qualidade automatizadas conforme necessário.
7. Usar o artefato de validação nas decisões de aprovação para ambientes de maior risco.
8. Implantar as mudanças aprovadas.
9. Continuar o monitoramento pós-deploy pelos serviços nativos de governança da AWS.

Os quality gates fornecem resultados automatizados de aprovação ou reprovação com base em critérios definidos. Os approval gates controlam se uma mudança avança para um ambiente protegido. Essa separação importa — a aprovação manual não é o primeiro lugar onde alguém percebe tags faltando, uma Região AWS não permitida ou ingresso público. As verificações automatizadas identificam esses problemas mais cedo. O OPA pertence à camada de gate automatizado, e sua saída também alimenta o processo de aprovação.

Estrutura da biblioteca de políticas

Uma estrutura de biblioteca baseada em padrões mantém o modelo de política mais próximo de como os times falam sobre controles. O exemplo de estrutura de diretórios abaixo ilustra essa organização:

opa-policies/
├── patterns/
│   ├── baseline/     # Segurança fundamental
│   ├── tagging/      # Tags obrigatórias
│   ├── networking/   # Controles de rede
│   ├── logging/      # Habilitação de logging
│   ├── encryption/   # Criptografia em repouso e em trânsito
│   └── iam/          # Boas práticas de IAM
├── shared/
│   ├── helpers.rego
│   └── messages.rego
├── tests/
├── fixtures/
└── docs/

Exemplos práticos de políticas OPA

Exemplo 1: Aplicar transporte seguro para o Amazon S3

Este exemplo implementa o padrão de aplicação de proteção para o Amazon Simple Storage Service (Amazon S3). O objetivo é verificar se o acesso ao bucket S3 está protegido em trânsito, exigindo uma política de bucket que negue requisições quando aws:SecureTransport estiver definido como false. A política verifica duas coisas: se a política do bucket S3 inclui uma instrução de negação que bloqueia requisições não criptografadas, e se o bucket S3 tem alguma política de bucket correspondente. A regra avalia tanto ações de criação quanto de atualização no JSON do plano do Terraform.

package compliance.amazon_s3.ssl

import future.keywords.in
import future.keywords.contains
import future.keywords.if

# Deny: S3 bucket policy missing SecureTransport deny statement
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket_policy"
    is_create_or_update(resource.change.actions)
    policy_value := resource.change.after.policy
    policy := json.unmarshal(policy_value)
    not has_secure_transport_deny(policy)
    msg := sprintf(
        "[S3-OPA-1] Resource '%s' does not enforce SSL/TLS. Bucket policy must include a Deny statement with Condition Bool aws:SecureTransport set to \"false\".",
        [resource.address]
    )
}

# Deny: S3 bucket created without any corresponding bucket policy
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket"
    is_create_or_update(resource.change.actions)
    bucket_name := resource.change.after.bucket
    not has_bucket_policy(bucket_name)
    msg := sprintf(
        "[S3-OPA-1] Resource '%s' (bucket '%s') has no bucket policy. A bucket policy with a Deny statement for aws:SecureTransport \"false\" is required.",
        [resource.address, bucket_name]
    )
}

is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }

has_bucket_policy(bucket_name) if {
    bp := input.resource_changes[_]
    bp.type == "aws_s3_bucket_policy"
    is_create_or_update(bp.change.actions)
    bp.change.after.bucket == bucket_name
}

has_secure_transport_deny(policy) if {
    stmt := policy.Statement[_]
    stmt.Effect == "Deny"
    stmt.Condition.Bool["aws:SecureTransport"] == "false"
    stmt.Principal == "*"
    action := stmt.Action
    action == "s3:*"
}

Exemplo 2: Restringir ingresso público em portas sensíveis

Este exemplo implementa o padrão de restrição de exposição. O objetivo é identificar configurações de security group do Amazon Virtual Private Cloud (Amazon VPC) que permitem ingresso público em portas sensíveis antes que essas regras sejam implantadas. A política avalia tanto recursos aws_security_group com regras de ingresso inline quanto recursos aws_security_group_rule independentes, pois repositórios de clientes frequentemente usam os dois estilos.

package compliance.amazon_vpc.ingress

import future.keywords.in
import future.keywords.contains
import future.keywords.if

# Sensitive ports that must not be open to the internet
sensitive_ports := {22, 3389, 5432}

# Deny: aws_security_group with inline ingress open to 0.0.0.0/0 on sensitive ports
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_security_group"
    is_create_or_update(resource.change.actions)
    ingress := resource.change.after.ingress[_]
    ingress.cidr_blocks[_] == "0.0.0.0/0"
    port := sensitive_ports[_]
    ingress.from_port <= port
    ingress.to_port >= port
    msg := sprintf(
        "[VPC-OPA-1] Resource '%s' allows ingress from 0.0.0.0/0 on port %d. Restrict access to specific CIDR ranges.",
        [resource.address, port]
    )
}

# Deny: aws_security_group_rule with type "ingress" open to 0.0.0.0/0 on sensitive ports
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_security_group_rule"
    is_create_or_update(resource.change.actions)
    resource.change.after.type == "ingress"
    resource.change.after.cidr_blocks[_] == "0.0.0.0/0"
    port := sensitive_ports[_]
    resource.change.after.from_port <= port
    resource.change.after.to_port >= port
    msg := sprintf(
        "[VPC-OPA-1] Resource '%s' allows ingress from 0.0.0.0/0 on port %d. Restrict access to specific CIDR ranges.",
        [resource.address, port]
    )
}

is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }

Exemplo 3: Aplicar política de confiança de menor privilégio para roles IAM

Este exemplo implementa o padrão de restrição de privilégio para políticas de confiança de roles IAM. O objetivo é identificar relacionamentos de confiança que permitem que principals excessivamente amplos assumam um role. A política inspeciona o documento assume_role_policy para recursos aws_iam_role e procura por principals com wildcard em três representações válidas.

package compliance.amazon_iam.trust

import future.keywords.in
import future.keywords.contains
import future.keywords.if

# Deny: IAM role with wildcard principal in trust policy
deny contains msg if {
    resource := input.resource_changes[_]
    resource.type == "aws_iam_role"
    is_create_or_update(resource.change.actions)
    policy_value := resource.change.after.assume_role_policy
    policy := json.unmarshal(policy_value)
    stmt := policy.Statement[_]
    stmt.Effect == "Allow"
    has_wildcard_principal(stmt)
    msg := sprintf(
        "[IAM-OPA-2] Resource '%s' has a wildcard principal in its trust policy. Specify explicit account ARNs, service principals, or federated providers instead of \"*\".",
        [resource.address]
    )
}

# Principal is directly "*"
has_wildcard_principal(stmt) if { stmt.Principal == "*" }

# Principal.AWS is "*"
has_wildcard_principal(stmt) if { stmt.Principal.AWS == "*" }

# Principal.AWS is an array containing "*"
has_wildcard_principal(stmt) if { stmt.Principal.AWS[_] == "*" }

is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }

Vale mencionar que a AWS Labs disponibiliza o IAM Policy Autopilot, uma ferramenta open-source de linha de comando e servidor MCP que ajuda a gerar políticas IAM de linha de base a partir do código da aplicação. Essa ferramenta é complementar ao padrão mostrado acima — o IAM Policy Autopilot auxilia na geração de políticas, enquanto o exemplo acima foca em validar se as políticas de confiança de roles IAM estão adequadamente escopadas nas mudanças de infraestrutura.

Exemplos de implementação em CI/CD

Os exemplos a seguir mostram o mesmo modelo operacional em dois sistemas de CI/CD comuns. A sintaxe muda, mas a sequência é a mesma: validar, planejar, avaliar política, reter o artefato e usar o resultado durante promoção e aprovação. Esses exemplos assumem que o OPA está instalado no ambiente de CI/CD, que o diretório opa-policies contém a biblioteca de políticas, e que o Terraform está configurado com credenciais apropriadas.

GitLab CI

stages:
  - validate
  - plan
  - policy_check

variables:
  TF_IN_AUTOMATION: "true"

terraform_validate:
  stage: validate
  script:
    - terraform fmt -check
    - terraform init
    - terraform validate

terraform_plan:
  stage: plan
  script:
    - terraform plan -out=tfplan
    - terraform show -json tfplan > tfplan.json
  artifacts:
    paths:
      - tfplan.json

opa_policy_check:
  stage: policy_check
  script:
    - opa eval --format pretty --data opa-policies --input tfplan.json "data.terraform.deny"
    - opa eval --format json --data opa-policies --input tfplan.json "data.terraform.deny" > policy-report.json
  artifacts:
    paths:
      - policy-report.json

GitHub Actions

name: Terraform Policy Check

on:
  pull_request:

jobs:
  policy-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - name: Terraform Format Check
        run: terraform fmt -check
      - name: Terraform Init
        run: terraform init
      - name: Terraform Validate
        run: terraform validate
      - name: Terraform Plan
        run: terraform plan -out=tfplan
      - name: Convert Plan to JSON
        run: terraform show -json tfplan > tfplan.json
      - name: Run OPA Policy Check
        run: |
          opa eval --format pretty --data opa-policies --input tfplan.json "data.terraform.deny"
          opa eval --format json --data opa-policies --input tfplan.json "data.terraform.deny" > policy-report.json
      - name: Upload Validation Artifact
        uses: actions/upload-artifact@v4
        with:
          name: policy-report
          path: policy-report.json

Retendo artefatos de validação para revisão e auditoria

Em fluxos de entrega maduros, os resultados de política não desaparecem nos logs do pipeline — eles são retidos como artefatos de validação. Esses artefatos ajudam os revisores a decidir se uma mudança está pronta para aprovação, suportam o tratamento de exceções mostrando quais controles falharam e por quê, e podem permanecer junto ao registro da mudança para discussões de auditoria posteriores.

No mínimo, o artefato identifica: a mudança ou execução do pipeline, o escopo avaliado, o pacote ou versão de política, as verificações executadas, e os resultados de aprovação ou reprovação.

Testando o modelo de política como software

As primeiras regras costumam ser diretas. O trabalho real começa quando a biblioteca cresce e múltiplos times dependem dela. Os testes devem incluir:

• Casos de teste positivos e negativos — cada política tem casos que mostram entrada válida e casos que mostram falhas esperadas.
• Cobertura de regressão — helpers compartilhados precisam de cobertura de regressão.
• Fixtures realistas — fixtures de plano do Terraform devem se parecer com mudanças reais, não com amostras pequenas inventadas.
• Análise de impacto — quando uma regra muda, os times conseguem identificar rapidamente o que mais pode ser afetado.

Se os desenvolvedores pararem de confiar nos resultados, eles param de tratar a política como um mecanismo útil.

Uma abordagem em fases para implementar as verificações

Não é necessário ter cobertura ampla desde o primeiro dia. Uma implantação em fases funciona melhor do que uma abordagem de aplicação imediata em tudo de uma vez.

Fase 1: Avaliar e pilotar

Comece no modo consultivo para que os times possam ver os resultados sem serem bloqueados. Identifique dois ou três padrões de alta confiança, como metadados obrigatórios, Regiões aprovadas ou restrições de exposição pública. Execute o OPA nos pipelines existentes e revise a saída para verificar a precisão.

Fase 2: Iniciar a aplicação

Aplique o pequeno conjunto de padrões de alta confiança após a saída estar estável e as falhas serem úteis. Integre os artefatos de validação ao fluxo de aprovação. Estabeleça processos de propriedade e tratamento de exceções para pacotes compartilhados.

Fase 3: Operacionalizar e expandir

Formalize o versionamento para pacotes de política compartilhados. Expanda a cobertura de padrões com base no feedback dos times e nas prioridades organizacionais. Conecte a validação pré-deploy com o monitoramento pós-deploy por meio do AWS Config, AWS Security Hub e AWS Organizations.

Conclusão

Política como código ajuda a reduzir a distância entre o que uma organização diz que espera e o que seu sistema de entrega verifica. Ao implementar esses padrões OPA nos pipelines de CI/CD, é possível construir uma camada preventiva que avalia as mudanças de infraestrutura antes do deploy. Com uma biblioteca baseada em padrões, artefatos de validação e propriedade clara, política como código se torna uma forma repetível de traduzir a intenção de controle na entrega do dia a dia — enquanto os serviços de governança da AWS continuam fornecendo visibilidade e monitoramento após os recursos existirem.

Para se aprofundar no tema, a AWS disponibiliza recursos como a documentação oficial do Open Policy Agent, o Guia do Usuário do AWS Security Hub, o Pilar de Segurança do AWS Well-Architected Framework e o Guia do Desenvolvedor do AWS Config. Quem precisar de suporte especializado pode entrar em contato com o AWS Security Assurance Services.

Fonte

Governing infrastructure as code using pattern-based policy as code (https://aws.amazon.com/blogs/security/governing-infrastructure-as-code-using-pattern-based-policy-as-code/)

Expansão do Amazon Inspector para Taipei

A AWS anunciou a disponibilidade do Amazon Inspector na região AWS Ásia-Pacífico (Taipei). A expansão amplia a cobertura de segurança do serviço para mais uma região global, permitindo que clientes que operam nessa localidade utilizem o gerenciamento automatizado de vulnerabilidades diretamente em seus ambientes.

O que é o Amazon Inspector?

O Amazon Inspector é um serviço de gerenciamento de vulnerabilidades totalmente automatizado. Ele realiza varreduras contínuas em cargas de trabalho AWS, cobrindo instâncias do Amazon EC2 (Elastic Compute Cloud), imagens de contêiner e funções do AWS Lambda — tudo isso em busca de vulnerabilidades de software e exposições de rede não intencionais. O serviço opera em nível organizacional, o que significa que pode ser aplicado de forma centralizada em múltiplas contas dentro de uma AWS Organization.

O que muda com essa expansão?

Com a chegada do Amazon Inspector à região de Taipei, os clientes que utilizam essa localidade passam a contar com os mesmos recursos já disponíveis em outras regiões. Entre os principais benefícios destacados pela AWS estão:

• Descoberta automática de workloads: o serviço identifica automaticamente instâncias EC2 recém-lançadas, funções Lambda e imagens de contêiner elegíveis enviadas ao Amazon ECR (Elastic Container Registry).
• Avaliações contínuas de vulnerabilidades: as varreduras acontecem de forma ininterrupta, sem necessidade de configuração manual a cada novo recurso provisionado.
• Resultados de segurança acionáveis: os achados são apresentados de forma clara, facilitando a priorização e a resposta das equipes de segurança.

Avaliação gratuita de 15 dias

Assim como nas demais regiões, todas as contas que utilizarem o Amazon Inspector pela primeira vez têm direito a um período de avaliação gratuita de 15 dias. Durante esse período, todas as instâncias EC2, funções Lambda e imagens de contêiner enviadas ao Amazon ECR elegíveis são escaneadas continuamente sem custo algum. Após o encerramento do período de teste, a cobrança passa a seguir os valores da tabela de preços pública do Amazon Inspector.

Como começar

Para equipes que ainda não utilizam o Amazon Inspector, esse é um bom momento para avaliar o serviço sem compromisso financeiro. A AWS disponibiliza documentação oficial e a opção de iniciar o período de avaliação gratuita diretamente pelo console.

Fonte

Amazon Inspector is now available in the AWS Asia Pacific (Taipei) Region (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-inspector-taipei/)