Conformidade e segurança em nuvem: a certificação PiTuKri
A AWS anunciou a emissão do relatório de certificação PiTuKri ISAE 3000 Type II, abrangendo 183 serviços. Este é um marco importante para organizações que buscam validar a segurança de seus provedores de nuvem.
A emissão do relatório ISAE 3000 Type II por uma firma de auditoria independente constitui uma validação de que o ambiente de controle da AWS foi adequadamente projetado e está operando de forma eficaz para atender aos requisitos do PiTuKri. Em outras palavras, a certificação demonstra que a AWS cumpre os padrões de segurança estabelecidos pela Traficom para provedores de serviços em nuvem.
O relatório abrange o período de 12 meses, de 1º de outubro de 2024 a 30 de setembro de 2025.
Novos serviços incluídos no escopo
A AWS expandiu seu portfólio certificado com cinco novos serviços nesta versão do relatório:
É importante ressaltar que segurança e conformidade na nuvem envolvem responsabilidades compartilhadas. Quando organizações migram seus sistemas e dados para a nuvem, as responsabilidades de segurança se dividem entre o cliente e o provedor de serviços em nuvem. Consulte o Modelo de Responsabilidade Compartilhada de Segurança da AWS para compreender melhor como essa divisão funciona em sua infraestrutura.
Para mais informações sobre programas de conformidade e segurança, consulte a documentação sobre Programas de Conformidade da AWS.
Próximos passos
Se sua organização avalia provedores de nuvem sob critérios de conformidade europeus ou adota o framework PiTuKri como referência, este relatório fornece evidências independentes sobre os controles de segurança implementados pela AWS. Dúvidas adicionais podem ser encaminhadas para a equipe de conformidade da AWS através da página de contato.
As organizações enfrentam desafios significativos ao tentar detectar e responder rapidamente a eventos de segurança de contas de usuários, como múltiplas tentativas de login de locais incomuns. Embora informações de segurança existam espalhadas por várias aplicações, a correlação manual de dados e a execução de ações corretivas frequentemente atrasam a resposta efetiva. A AWS apresenta uma abordagem integrada que combina o Amazon Quick Suite com o Tines para automatizar o processo de investigação e remediação, integrando dados de múltiplas ferramentas de segurança e fornecendo insights visuais para tomada de decisão mais rápida.
O Amazon Quick Suite: espaço de trabalho digital alimentado por IA
O Amazon Quick Suite funciona como um espaço de trabalho digital que fornece aos usuários de negócio capacidades de IA em nível de agente para responder questões rapidamente e transformar insights em ações. A plataforma integra pesquisa alimentada por IA, inteligência de negócios (BI) e automação em uma única aplicação.
O diferencial do Quick Suite está na sua capacidade de construir fluxos de trabalho automatizados onde múltiplos assistentes de IA trabalham conjuntamente, utilizando dados corporativos e internet para responder perguntas de negócio com maior velocidade e precisão. Os usuários conectam aplicações adicionais ao Quick Suite por meio de integrações nativas e do Protocolo de Contexto de Modelo (Model Context Protocol — MCP), um padrão que normaliza a comunicação entre assistentes de IA e ferramentas externas.
Tines: plataforma de fluxo de trabalho com suporte a MCP
O Tines se apresenta como uma plataforma inteligente de orquestração de fluxos de trabalho com um servidor MCP integrado. Um servidor MCP é um programa que expõe as capacidades de uma aplicação através de um protocolo padronizado, permitindo que assistentes de IA os chamem como ferramentas.
No Tines, você define ferramentas MCP que leem ou escrevem em aplicações internas ou de terceiros. O Quick Suite pode consultar essas ferramentas diretamente. Com trilhas de auditoria completas no Tines, as organizações mantêm visibilidade e governança em cada fluxo de trabalho. Esse padrão permite que usuários do Quick Suite tragam dados proprietários ou isolados para seus fluxos de trabalho orientados por IA, sem necessidade de implantar nova infraestrutura ou escrever código de integração customizado.
Caso de uso: investigação e remediação orquestrada de segurança
Para equipes de segurança, manter-se à frente de eventos requer análise regular de dados de segurança de contas. Essa tarefa envolve triagem de informações de múltiplas fontes para determinar se há indicadores que justifiquem análise mais profunda dos dados. O Quick Suite e o Tines permitem investigar e remediar eventos de segurança usando linguagem natural, levando a decisões mais rápidas sem necessidade de scripts customizados ou correlação manual entre aplicações.
O que o Tines pode fazer quando conectado ao Quick Suite e às suas ferramentas de segurança:
Analisar endereços de protocolo de internet (IP) no VirusTotal para avaliar risco de evento
Recuperar detalhes de contas do Okta e BambooHR
Revisar logs de autenticação e atividade de usuários no AWS CloudTrail
Sinalizar endereços IP suspeitos e, após aprovação do analista, bloqueá-los no CrowdStrike
Visualização e análise de dados no Quick Suite:
Uma vez conectado, você pode visualizar os dados para obter insights imediatos, como:
Mapeamento geográfico de tentativas de login com pontuação de risco
Linha do tempo da atividade do usuário antes e depois de logins suspeitos
Correlação entre contas e sistemas afetados
Rastreamento do status de remediação para eventos de segurança
Isso permite fazer perguntas em linguagem natural, por exemplo:
Mostrar todas as tentativas de login de países de alto risco nas últimas 24 horas
Exibir linha do tempo de atividade do usuário
Listar todos os sistemas que o usuário acessou
Gerar relatório de ações de remediação tomadas para o evento de segurança
O Tines pode ajudar a integrar-se com serviços que expõem uma API, automatizar a recuperação ou transformação desses dados e fornecer o fluxo de trabalho resultante como servidor MCP. O cliente MCP no Quick Suite pode conectar-se diretamente ao servidor MCP do Tines e acessar as ferramentas definidas nele.
Benefícios do padrão de integração:
Uma camada de integração simples e governada entre Quick Suite e ferramentas internas ou externas
A capacidade de conectar sistemas que atualmente não possuem servidor MCP
Uma forma simples e poderosa de criar novas ferramentas MCP para fontes de dados customizadas sem necessidade de engenharia ou desenvolvimento customizado
Conectividade segura e consistente sem necessidade de manter scripts ou servidores customizados
Componentes da arquitetura:
Quick Suite: conecta-se ao servidor MCP do Tines usando o cliente MCP do Quick Suite, recupera os dados e habilita análise através de chat e dashboards
Servidor MCP do Tines: um endpoint publicado que expõe o fluxo de trabalho como ferramenta MCP
API de segurança ou TI: qualquer API REST que retorna dados de rede, endpoint, asset ou configuração
Fluxo de trabalho do Tines: uma sequência de ações que recupera, normaliza ou enriquece os dados
Pré-requisitos para implementação
Para implantar essa solução, você deve ter:
Uma conta do Quick Suite dentro de sua conta AWS com inscrição Professional e função de usuário Author ou superior. Consulte a documentação sobre integração do Protocolo de Contexto de Modelo (MCP) para mais informações
Um tenant do Tines. Todos os planos, incluindo a Community Edition gratuita, suportam a criação de servidores MCP
Credenciais de API para o sistema de segurança ou TI escolhido
Criando o servidor MCP no Tines
Você pode importar um servidor MCP da biblioteca de histórias do Tines para seu tenant Tines. Alternativamente, siga estas etapas para criar um servidor MCP customizado:
Crie uma nova Story
Abra o navegador de Templates e pesquise por MCP
Arraste a ação MCP para o storyboard
Escolha MCP Server no painel direito e anote a URL do servidor MCP para conectar o Quick Suite
Adicione quantas ferramentas forem necessárias para seu fluxo de trabalho a partir da lista de templates ou configure ferramentas customizadas
Conecte as ferramentas com sua conta nas aplicações associadas usando métodos padrão de autenticação (como chave API ou OAuth)
Siga estas etapas para conectar o Quick Suite ao servidor MCP do Tines:
No console do Quick Suite, escolha Integrations no painel de navegação Connections
Escolha a aba Actions em Existing integrations
Escolha o sinal de adição próximo a Model Context Protocol
Na página Create integration, insira um nome e descrição para sua integração Tines
Para MCP server endpoint, insira a URL do servidor MCP de seu MCP server em sua Story Tines, então escolha Next
Na próxima página, configure as definições de autenticação e escolha Create and continue para ver as ferramentas do seu servidor MCP Tines
Escolha Next para completar a conexão
Consultando e visualizando dados no Quick Suite
Após a conexão, você pode usar o assistente de chat do Quick Suite para recuperar e explorar dados em tempo real, gerar dashboards e gráficos visuais a partir dos resultados retornados e combinar esses dados com datasets AWS existentes para análise mais ampla.
O Quick Suite seleciona e recupera automaticamente dados de sua integração Tines com base no conteúdo das mensagens de chat. Isso oferece uma forma simples e escalável de operacionalizar dados de segurança e TI usando as capacidades de BI e IA no Quick Suite.
Limpeza de recursos
Para evitar incorrer em cobranças contínuas, limpe os recursos que você criou como parte dessa solução.
Começando com o Quick Suite
Comece com o Quick Suite para criar uma instância do Quick Suite em sua conta AWS e visite a página inicial do Tines para se inscrever em uma conta Community Edition do Tines. Uma vez que você tenha acesso, poderá criar seu primeiro servidor MCP e conectar suas ferramentas de segurança e TI existentes usando os templates pré-construídos do Tines. Finalmente, configure o Quick Suite para acessar suas novas fontes de dados e comece a analisar dados através de consultas em linguagem natural.
A conexão entre Quick Suite e Tines através do MCP transforma a forma como as organizações analisam seus dados de segurança e TI. Essa solução reduz a necessidade de código de integração customizado e fornece governança centralizada de integrações, recuperação de dados padronizada e visibilidade operacional aprimorada. Equipes de segurança e TI podem estender suas capacidades analíticas para qualquer sistema habilitado para API através de uma camada única e auditável que escala em todo seu cenário de ferramentas.
A AWS anunciou em março de 2026 uma expansão importante no serviço AWS Config, adicionando suporte para 30 novos tipos de recursos em seus principais serviços. Esta atualização inclui recursos do Amazon Bedrock AgentCore e Amazon Cognito, entre muitas outras ofertas da plataforma AWS, representando um avanço significativo na capacidade de governança e auditoria da infraestrutura em nuvem.
Com esta ampliação de cobertura, os usuários da AWS ganham maior visibilidade sobre seu ambiente de nuvem, permitindo descobrir, avaliar, auditar e remediar um espectro bem mais abrangente de recursos gerenciados. Essa funcionalidade é particularmente importante para organizações brasileiras que precisam manter conformidade regulatória e controle rigoroso sobre seus ativos em nuvem.
Como a atualização funciona automaticamente
Uma vantagem importante desta atualização é que ela opera de forma transparente. Quando um usuário já tiver habilitado a gravação de todos os tipos de recursos no AWS Config, os novos tipos serão rastreados automaticamente, sem necessidade de reconfiguração manual. Isso simplifica significativamente a operação para equipes de infraestrutura e DevOps.
Os novos tipos de recursos também estão disponíveis em outras funcionalidades do AWS Config, como Config rules (regras de configuração) e Config aggregators (agregadores de configuração), ampliando ainda mais as possibilidades de monitoramento e automação de conformidade.
Novos tipos de recursos agora suportados
O AWS Config agora pode monitorar os seguintes tipos de recursos em todas as regiões da AWS onde esses serviços estão disponíveis:
AWS::AppSync::DataSource
AWS::Batch::ConsumableResource
AWS::Bedrock::DataSource
AWS::BedrockAgentCore::Gateway
AWS::BedrockAgentCore::Memory
AWS::Cognito::IdentityPoolRoleAttachment
AWS::Cognito::LogDeliveryConfiguration
AWS::Cognito::UserPoolUICustomizationAttachment
AWS::Connect::RoutingProfile
AWS::DataBrew::Dataset
AWS::DataBrew::Job
AWS::DataBrew::Project
AWS::DataBrew::Recipe
AWS::DataBrew::Ruleset
AWS::DataBrew::Schedule
AWS::Deadline::LicenseEndpoint
AWS::Deadline::QueueEnvironment
AWS::Detective::OrganizationAdmin
AWS::GameLift::ContainerFleet
AWS::GameLift::ContainerGroupDefinition
AWS::GameLift::GameServerGroup
AWS::GameLift::Location
AWS::IoT::TopicRule
AWS::Omics::ReferenceStore
AWS::PCAConnectorAD::Template
AWS::PCAConnectorSCEP::Challenge
AWS::ResourceExplorer2::View
AWS::ResourceGroups::Group
AWS::Scheduler::ScheduleGroup
AWS::VerifiedPermissions::IdentitySource
Disponibilidade e próximos passos
Todos esses tipos de recursos estão disponíveis em todas as regiões da AWS onde os serviços correspondentes estão operacionais. Para começar a aproveitar este aumento de cobertura, usuários que já têm gravação ativada para todos os tipos de recursos não precisam fazer nada — o rastreamento dos novos tipos começará automaticamente.
Para aqueles que desejam configurações mais granulares ou precisam entender melhor como trabalhar com os novos tipos de recursos, a documentação técnica completa está disponível na documentação oficial do AWS Config.
Introdução: Agentes de IA e Controle de Acesso na AWS
Conforme agentes de IA se integram nos fluxos de trabalho de desenvolvimento na Amazon Web Services (AWS), surge um desafio importante: como conceder a esses agentes permissões para operar com recursos AWS sem criar modelos de controle de acesso paralelos e sem comprometer a segurança? A AWS respondeu a essa demanda durante o evento re:Invent 2025, apresentando quatro servidores gerenciados do Protocolo de Contexto do Modelo (MCP) em fase de visualização prévia.
A abordagem inovadora da plataforma oferece flexibilidade significativa: os agentes de IA trabalham com suas credenciais AWS existentes, aproveitando as mesmas políticas de Identidade e Acesso (IAM) já estabelecidas. Ao mesmo tempo, as organizações ganham a capacidade de implementar controles de governança específicos para diferenciar chamadas de API realizadas por agentes de IA daquelas executadas diretamente por desenvolvedores.
Os Servidores MCP Gerenciados da AWS
A AWS lançou quatro servidores remotos gerenciados do MCP: AWS, EKS e ECS, além do SageMaker. Diferentemente das implementações locais, esses servidores são hospedados e gerenciados pela AWS, eliminando a necessidade de instalação e manutenção manual. A plataforma oferece atualizações automáticas, resiliência, escalabilidade e auditoria completa através do AWS CloudTrail.
Por exemplo, o AWS MCP Server permite aos agentes de IA acessar documentação de AWS e executar chamadas para mais de 15 mil APIs disponíveis, possibilitando que realizem tarefas complexas e em múltiplas etapas, como configurar redes privadas virtuais (VPCs) ou estabelecer alarmes no Amazon CloudWatch.
Contextos de IAM Padronizados: O Cerne do Controle
O ponto central da solução reside em dois contextos de IAM padronizados que funcionam consistentemente em todos os servidores MCP gerenciados pela AWS:
As Duas Chaves de Contexto Principais
aws:ViaAWSMCPService (booleano) — Assume o valor verdadeiro quando a requisição provém através de um servidor MCP gerenciado pela AWS. Utilize essa chave para permitir ou negar todas as ações iniciadas pelo MCP.
aws:CalledViaAWSMCP (cadeia de texto, valor único) — Contém o identificador do serviço principal do servidor MCP (por exemplo, aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, ecs-mcp.amazonaws.com). Empregue essa chave quando precisar permitir ou negar ações originadas de servidores MCP específicos. Conforme novos servidores MCP forem disponibilizados, esse campo incorporará seus identificadores, permitindo configurar acesso refinado aos recursos AWS através de políticas de IAM e de controle de serviço (SCP).
Implementando Políticas de Segurança em Camadas
Para organizações que desejam desabilitar completamente o acesso via servidores MCP em toda a organização ou em unidades organizacionais específicas, é possível utilizar uma política de controle de serviço (SCP) para negar ações quando acessadas através dos servidores MCP:
Em outro cenário, você pode autorizar agentes de IA utilizando o AWS MCP Server a ler baldes do Amazon Simple Storage Service (Amazon S3), mas recusar operações de exclusão. O AWS MCP Server fornece a ferramenta aws___call_aws, capaz de executar qualquer operação de API da AWS, incluindo operações de S3:
Você também pode restringir o acesso apenas a servidores MCP específicos. Por ilustração, permitir operações EKS somente quando chamadas através do servidor MCP para EKS, não através do servidor MCP geral da AWS:
Baseando-se em retorno dos clientes, a AWS está simplificando o modelo de autorização para funcionar de forma equivalente ao AWS Command Line Interface (AWS CLI) e aos SDKs que você já utiliza. A partir de breve, deixará de ser necessário separar ações de IAM específicas do MCP (como aws-mcp:InvokeMCP) para interagir com servidores MCP gerenciados pela AWS.
Nessa abordagem revisada, o servidor MCP adiciona os contextos padronizados de IAM (aws:ViaAWSMCPService e aws:CalledViaAWSMCP) à sua requisição e a encaminha ao serviço AWS a jusante. O servidor MCP continua autenticando a requisição utilizando SigV4 como antes. Posteriormente, o serviço a jusante realiza a verificação de autorização com base em suas políticas de IAM vigentes, que podem referenciar essas chaves de contexto para implementar controle refinado.
Isso signifi que seus agentes de IA funcionam com suas credenciais AWS existentes e com as permissões de nível de serviço, dispensando a necessidade de ações de IAM isoladas para MCP e diminuindo a complexidade operacional.
Fluxo de autorização para servidores MCP gerenciados — fonte: Aws
Segurança em Profundidade com VPC Endpoints
A AWS está desenvolvendo suporte para pontos de extremidade de nuvem privada virtual (VPC endpoints) nos servidores MCP gerenciados, atendendo à demanda de clientes em setores regulados que exigem controles a nível de rede. Organizações em segmentos como serviços financeiros e saúde necessitam de comunicação via rede privada para cumprir mandatos de conformidade.
Com os VPC endpoints, todo o tráfego de agentes de IA permanece na rede privada, eliminando exposição através da internet pública. Quando você configura um ponto de extremidade VPC, o servidor MCP realiza uma verificação de autorização no nível do endpoint VPC antes de encaminhar requisições aos serviços AWS a jusante. Isso estabelece uma estratégia de defesa em profundidade, onde você controla acesso tanto no perímetro de rede (VPC endpoint) quanto no nível de serviço (políticas de IAM).
Você pode combinar VPC endpoints com as chaves de contexto aws:ViaAWSMCPService e aws:CalledViaAWSMCP para implantar controles de segurança em camadas que satisfaçam os critérios específicos de governança e conformidade da sua organização. Detalhes adicionais sobre chaves de contexto e padrões de exemplo estarão disponíveis quando o suporte para VPC endpoints for lançado.
Considerações Importantes para Implementação
Ao executar a autorização de IAM para servidores MCP, você precisa tomar decisões sobre padrões de implementação, design de políticas e práticas operacionais. As seguintes recomendações podem ajudar na escolha da abordagem correta para seu ambiente:
Desenho de Políticas de IAM
Conceda apenas o acesso necessário e refine as políticas regularmente, removendo permissões não utilizadas ao longo do tempo. Use as chaves de contexto para diferenciar chamadas através de soluções de IA de ações diretas de desenvolvedores, mantendo uma postura de segurança coerente em sua infraestrutura.
Segurança e Conformidade
Os VPC endpoints ajudam a atender aos requisitos de comunicação de rede privada em setores regulados. Eles proporcionam um mecanismo adicional de segurança para ambientes que enfrentam exigências estritas de isolamento de rede e conformidade regulatória.
Iniciando a Jornada
Comece com o padrão de implementação que se alinha às suas necessidades atuais. Inicie com políticas de IAM restritivas e flexibilize-as conforme você compreenda melhor os requisitos de seus agentes de IA. Monitore os registros do CloudTrail para observar quais ações seus agentes de IA realizam e utilize esses dados para refinar suas políticas progressivamente.
Conclusão
A AWS entrega às organizações o controle necessário para governar o acesso de agentes de IA aos recursos AWS através dos Servidores MCP Gerenciados, utilizando as mesmas políticas de IAM e ferramentas nas quais você já confia. Os contextos padronizados de IAM (aws:ViaAWSMCPService e aws:CalledViaAWSMCP) estão disponíveis em todos os servidores MCP gerenciados pela AWS, oferecendo controle granular para diferenciar chamadas via soluções de IA de ações iniciadas por pessoas em nível de serviço.
Em lançamentos futuros, os servidores MCP gerenciados da AWS funcionarão sem a necessidade de ações de IAM isoladas através de endpoints públicos, simplificando a gestão de políticas de IAM. Haverá também suporte para VPC endpoints, com segurança aprimorada mediante autorização em duas fases e controles de perímetro de rede para organizações que exigem restrições de acesso adicionais.
Consulte a documentação específica de seu servidor MCP gerenciado para confirmar se oferece suporte ao novo modelo de autorização de endpoint público e aos VPC endpoints. Seja você desenvolvendo assistentes de codificação com IA ou construindo aplicações com agentes autônomos, comece a implementar esses controles hoje para proteger seus fluxos de trabalho de IA, mantendo ao mesmo tempo a flexibilidade de definir regras de acesso que reflitam a postura de segurança da sua organização.
Controles de Criptografia em VPC ganham modelo de precificação
A AWS anunciou a transição para um modelo de precificação para os Controles de Criptografia em VPC, um recurso de segurança e conformidade que permite às organizações auditar e aplicar criptografia em trânsito para todos os fluxos de tráfego dentro de e entre Nuvens Privadas Virtuais (VPCs) em uma região.
Como funcionam os Controles de Criptografia em VPC
O recurso oferece dois modos de operação distintos:
Modo Monitor: detecta a presença de qualquer tráfego não criptografado dentro da VPC, permitindo uma análise do cenário atual sem impor restrições.
Modo Enforce (Aplicação): garante que todos os dados em trânsito sejam criptografados e impede o funcionamento de qualquer recurso que permita tráfego não criptografado dentro da VPC.
Modelo de precificação a partir de março de 2026
A partir de 1º de março de 2026, os Controles de Criptografia em VPC deixaram o período de preview gratuito e passaram a funcionar sob um modelo de preço por hora. A cobrança segue a seguinte lógica:
Cada VPC não vazia (aquela que possui interfaces de rede) com Controles de Criptografia habilitados em modo monitor ou modo enforce será cobrada por uma taxa horária fixa.
VPCs vazias com Controles de Criptografia habilitados não geram cobrança.
Quando a criptografia é habilitada em um Gateway de Trânsito (Transit Gateway), as cobranças padrão dos Controles de Criptografia em VPC se aplicam a todas as VPCs conectadas a ele, independentemente do modo delas (monitor, enforce ou desativado), mesmo que sejam vazias.
Próximos passos
Para compreender melhor como funcionam os Controles de Criptografia em VPC e consultar os preços detalhados por região, a AWS disponibiliza documentação sobre Controles de Criptografia em VPC e a página de precificação de VPC, onde é possível encontrar as informações mais atualizadas para planejar o investimento em segurança de dados em trânsito.
A AWS anunciou uma importante evolução no Network Firewall: agora o serviço se integra com o Amazon EventBridge para entregar notificações em tempo real sobre mudanças de estado e atualizações de configuração do firewall. Essa integração abre novas possibilidades para quem trabalha com infraestrutura de segurança de rede na nuvem.
O que muda com essa integração
A nova capacidade permite monitorar operações críticas do firewall, incluindo atualizações de configuração e modificações de status de endpoints em toda sua infraestrutura de segurança de rede. Com a integração ao EventBridge, você ganha visibilidade imediata sobre mudanças que afetam as Regras Gerenciadas pela AWS, Regras Gerenciadas por Parceiros e as configurações do firewall.
Automatização e resposta rápida
Com a integração ao EventBridge, surge a possibilidade de construir fluxos de trabalho automatizados para diferentes tipos de resposta. É possível enviar notificações através do Amazon SNS, criar tickets automaticamente em sistemas de gerenciamento de serviços de TI (ITSM), ou conectar com soluções externas de Gerenciamento de Informações e Eventos de Segurança (SIEM).
Essa abordagem helps manter melhor consciência operacional da sua infraestrutura de segurança de rede e permite responder com rapidez a mudanças de configuração ou problemas potenciais.
Disponibilidade
As notificações de mudança de estado do AWS Network Firewall através do Amazon EventBridge estão disponíveis em todas as regiões da AWS onde o Network Firewall e o EventBridge já funcionam. Para aprofundar sobre essa integração, consulte a documentação do AWS Network Firewall. Detalhes adicionais sobre o Amazon EventBridge estão disponíveis na documentação do Amazon EventBridge.
A AWS anunciou melhorias significativas no EC2 Image Builder, o serviço responsável por automatizar a criação, distribuição e gerenciamento de imagens de máquinas virtuais personalizadas na plataforma. As novidades focam em dois pontos críticos: suporte a padrões wildcard em políticas de ciclo de vida e simplificação no processo de criação de funções de Controle de Acesso (IAM — Identity and Access Management).
Suporte a Wildcards em Políticas de Ciclo de Vida
O Desafio Anterior
Antes dessa atualização, gerenciar o ciclo de vida de múltiplas imagens exigia criar políticas separadas para cada nova receita de imagem, ou selecionar manualmente cada receita individual. Conforme a infraestrutura crescia e novas receitas eram adicionadas, essa abordagem manual se tornava impraticável e gerava sobrecarga operacional.
A Nova Solução com Wildcards
Com o suporte a padrões wildcard, você pode agora definir expressões como my-recipe-1.x.x em uma única política de ciclo de vida. Isso aplica automaticamente a política a todas as receitas correspondentes — inclusive àquelas que forem criadas no futuro. Essa abordagem reduz a necessidade de intervenção manual e permite que políticas de ciclo de vida escaem naturalmente conforme sua infraestrutura evolui.
Simplificação na Criação de Funções IAM
O Desafio Anterior
Criar funções IAM para gerenciamento de ciclo de vida exigia configurar manualmente todas as permissões necessárias. Esse processo era propenso a erros de configuração e consumia tempo valioso do administrador, mesmo para ambientes padronizados.
A Nova Solução
Agora, ao criar uma nova função IAM diretamente no console do EC2 Image Builder, a AWS popula automaticamente as permissões padrão necessárias. Essa automação reduz significativamente o tempo de configuração e minimiza a possibilidade de erros de permissionamento, tornando o onboarding mais rápido e seguro.
Impacto na Operação em Escala
Combinadas, essas duas melhorias simplificam tanto o processo inicial de integração quanto a manutenção contínua de políticas de ciclo de vida em larga escala. A redução de sobrecarga operacional permite que equipes se concentrem em aspectos mais estratégicos da gestão de imagens, em vez de lidar com configurações repetitivas.
A AWS anunciou a disponibilidade geral do AWS Security Hub Extended, um plano inovador que integra as capacidades de detecção da AWS com soluções de segurança de parceiros selecionados. O objetivo é transformar a complexa tarefa de gerenciar múltiplos fornecedores e ciclos de compra prolongados em uma experiência unificada através de um único vendedor.
Essa abordagem reconhece um desafio real enfrentado pelas empresas: manter relacionamentos com diversos fornecedores de segurança, negociar contratos individuais e gerenciar faturas separadas consome tempo, recursos e aumenta a complexidade operacional. O Security Hub Extended busca resolver esses problemas ao consolidar as melhores soluções de detecção da AWS com produtos curados de parceiros confiáveis.
Três vantagens principais
Simplificação da aquisição e procurement
O plano integra o uso de múltiplas soluções em um único documento de faturamento, reduzindo significativamente a complexidade administrativa. Clientes que contratam o suporte AWS Enterprise também recebem suporte unificado de Nível 1 da AWS, eliminando a necessidade de escalações para múltiplos fornecedores. Apesar dessa consolidação, cada provedor mantém acesso direto, preservando sua expertise específica de domínio.
Proteção mais abrangente
O Security Hub Extended reúne as capacidades de detecção nativas da AWS com soluções de parceiros em categorias estratégicas: proteção de endpoint, gerenciamento de identidades, segurança de email, proteção de rede, segurança de dados, proteção de navegador, segurança em nuvem, segurança com Inteligência Artificial (IA) e operações de segurança. Essa cobertura ampla permite estabelecer defesas mais robustas e coordenadas.
Eficiência operacional aprimorada
As descobertas de segurança são padronizadas em um formato único, oferecendo visibilidade centralizada em todo o ambiente. Isso reduz significativamente o esforço manual necessário para integrar ferramentas de diferentes fornecedores e normalizar dados de múltiplas fontes.
Flexibilidade e modelo de preços
Os clientes acessam e avaliam soluções de parceiros diretamente através do console do Security Hub, selecionando apenas as soluções necessárias. O modelo oferece opções de preço flexível: pagamento conforme o uso ou taxas fixas mensais. Não há compromissos de longo prazo ou investimentos iniciais obrigatórios, permitindo que as empresas adaptem sua postura de segurança conforme suas necessidades evoluem.
Como a AWS atua como fornecedora de registro, o plano Extended pode ser elegível para oportunidades de precificação privada da AWS, aumentando ainda mais a flexibilidade na negociação de contratos e consolidação de faturas.
Próximos passos
O Security Hub Extended está disponível nas regiões comerciais da AWS onde o Security Hub funciona. Para consultar a lista completa de regiões, acesse a tabela de regiões AWS. Informações detalhadas sobre preços estão disponíveis na página de preços do Security Hub, e para começar, visite o produto.
Durante anos, os agentes de inteligência artificial enfrentaram limitações significativas que os impediam de executar tarefas complexas de forma independente. Eles não conseguiam reter informações aprendidas ao longo do tempo, operavam apenas em períodos curtos sem supervisão contínua, e dependiam constantemente de intervenção humana. A situação começou a mudar com o desenvolvimento dos chamados agentes de fronteira—uma nova categoria de IA capaz de realizar raciocínio complexo, planejamento em múltiplas etapas e execução autônoma por períodos estendidos de horas ou até dias.
Essa evolução abriu caminho para uma estratégia poderosa: a colaboração entre múltiplos agentes especializados. Quando diversos agentes trabalham juntos, podem resolver fluxos de trabalho intrincados que exigem diferentes tipos de conhecimento. No desenvolvimento de software, por exemplo, agentes podem se especializarem em geração de código, revisão e testes. Em pesquisa científica, colaboram em revisão bibliográfica, design experimental e análise de dados. E na cibersegurança, agentes diferentes podem se focar em reconhecimento de sistemas, análise de vulnerabilidades e validação de exploits.
Aplicação em Testes de Penetração Automatizados
Os testes de penetração tradicionais são uma atividade cara e demorada. Profissionais de segurança precisam investigar manualmente cada camada da aplicação, um processo que frequentemente consome semanas de trabalho especializado. Embora ferramentas de teste de segurança e scanners de vulnerabilidades existam há décadas, elas têm limitações claras: funcionam com lógica predefinida e não se adaptam bem a contextos específicos das aplicações.
Com os avanços recentes em modelos de linguagem de grande escala (LLMs, do inglês Large Language Models), os agentes de fronteira trouxeram uma perspectiva diferente. Eles conseguem raciocinar sobre o comportamento de aplicações, adaptar suas estratégias conforme recebem feedback, e compreender o contexto de formas que as ferramentas tradicionais não conseguem.
A AWS desenvolveu um sistema multi-agente especializado para testes de penetração. O conceito funciona assim: em vez de um único agente tentar resolver tudo, múltiplos agentes especializados trabalham em conjunto. Um agente mapeia a superfície de ataque da aplicação, enquanto outros analisam falhas na lógica de negócio, validam descobertas e priorizam vulnerabilidades conforme a possibilidade real de exploração. Essa priorização combina tentativas de exploração reais executadas por agentes da rede, re-validação independente por validadores especializados, e uma pontuação baseada em IA segundo o Sistema Comum de Pontuação de Vulnerabilidades (CVSS, do inglês Common Vulnerability Scoring System).
Arquitetura do Sistema de Testes de Penetração
O sistema implementado segue uma estrutura bem definida, com componentes que trabalham sequencialmente para construir uma análise de segurança progressivamente mais profunda.
Fase de Autenticação e Acesso Inicial
Tudo começa com um componente inteligente de autenticação. Este elemento combina raciocínio baseado em LLM com mecanismos determinísticos para lidar com diferentes arquiteturas de aplicações. Ele localiza páginas de login, tenta credenciais fornecidas e mantém sessões autenticadas para as fases de teste subsequentes. O sistema se adapta automaticamente a diferentes estruturas de aplicação e ambientes alvo, usando ferramentas de navegação web. Os desenvolvedores também podem fornecer um prompt de autenticação personalizado se precisarem otimizar o processo para sua aplicação específica.
Fase de Varredura Baseline
Após a autenticação bem-sucedida, o sistema inicia uma varredura de cobertura abrangente através da execução paralela de scanners especializados. Em testes sem acesso ao código-fonte (black-box), um scanner de rede executa testes de segurança de aplicações web automatizados, gerando interações de tráfego bruto e identificando endpoints potencialmente vulneráveis. Já em testes com acesso ao código (white-box), um scanner adicional realiza análise profunda do código-fonte quando repositórios estão disponíveis, produzindo documentação descritiva em múltiplas categorias. Scanners especializados complementam essas capacidades para identificar vulnerabilidades em diferentes dimensões e estabelecer uma cobertura inicial sólida.
Exploração em Múltiplas Fases
O sistema emprega duas abordagens de exploração distintas que trabalham em conjunto. A execução gerenciada utiliza tarefas estáticas predefinidas cobrindo categorias principais de risco como scripts entre sites (XSS), referências diretas inseguras a objetos (IDOR), escalação de privilégios e outras. Este componente ajuda sistematicamente a garantir cobertura abrangente ao executar tarefas curadas para cada tipo de risco.
Na próxima fase, a exploração guiada adota uma abordagem dinâmica e dirigida por inteligência. Este componente absorve endpoints descobertos, achados validados e documentação de análise de código para raciocinar sobre oportunidades de ataque específicas da aplicação. Ele funciona em dois estágios: primeiro gerando um plano de teste de penetração contextualizado identificando recursos não explorados e possíveis cadeias de vulnerabilidades, depois gerenciando programaticamente a execução dessas tarefas geradas dinamicamente. O explorador guiado executa com tarefas adaptativas que evoluem conforme as respostas da aplicação e padrões descobertos.
Enxame de Agentes Especializados
Ambas as abordagens de exploração distribuem trabalho para agentes especializados do enxame—cada um configurado para tipos específicos de risco e equipado com kits abrangentes de teste de penetração incluindo executores de código, fuzers web, busca em banco de dados de vulnerabilidades da NIST (NVD, do inglês National Vulnerability Database) para inteligência de Vulnerabilidades e Exposições Comuns (CVEs, do inglês Common Vulnerabilities and Exposures), e ferramentas específicas para cada tipo de vulnerabilidade. Esses agentes executam tarefas atribuídas com gerenciamento de tempo limite e relatórios estruturados.
Validação e Geração de Relatórios
Quando agentes especializados identificam riscos de segurança potenciais, geram relatórios estruturados contendo o tipo de vulnerabilidade, endpoints afetados, evidência de exploração e contexto técnico. Porém, os testes de penetração automatizados enfrentam um desafio crítico: agentes baseados em LLM podem produzir achados que parecem plausíveis mas não são reais. Para contornar isso, achados candidatos passam por validação através de validadores determinísticos e agentes especializados baseados em LLM que tentam exploração ativa. O sistema emprega técnicas de validação baseada em asserções onde asserções em linguagem natural escritas por especialistas em segurança codificam conhecimento profundo sobre comportamentos reais de ataques, exigindo prova explícita e estruturada que é significativamente mais difícil de contornar do que verificações determinísticas simples.
Os achados validados passam por análise CVSS para avaliação de severidade, e são sintetizados em relatórios finais com resultados de validação, pontuações de severidade e evidência de exploração—projetados para entregar vulnerabilidades confiáveis e acionáveis para remediação efetiva.
Desempenho e Avaliação
Para avaliar o sistema, a AWS realizou avaliação humana além de testes automáticos de desempenho. Analisaram trajetórias de mundo real e criaram uma taxonomia de padrões de erro. Identificando padrões de erro frequentes, conseguiram iterar na solução.
Os resultados foram reportados no benchmark público CVE Bench, uma coleção de aplicações web vulneráveis contendo 40 CVEs de severidade crítica do Banco Nacional de Vulnerabilidades usada para avaliar agentes de IA em exploits reais. Cada aplicação inclui referências de exploit automático, e agentes baseados em LLM tentam executar ataques que disparam as vulnerabilidades. O sucesso é medido através da métrica de taxa de sucesso de ataque (ASR, do inglês Attack Success Rate), definida como a taxa de exploração bem-sucedida de vulnerabilidades da aplicação.
O benchmark fornece um avaliador que o agente pode consultar para verificar sucesso de exploit e oferece instruções explícitas de captura de flag (CTF). A avaliação ocorreu em três configurações:
Com instruções CTF e verificações de avaliador após cada chamada de ferramenta: atingiu 92,5% no CVE Bench v2.0 (nota que alguns desafios envolvem exploração cega onde o agente não pode verificar sucesso sem esse feedback)
Sem instruções CTF ou feedback de avaliador: atingiu 80%—o que melhor reflete condições reais onde o agente deve se auto-validar através de resultados observáveis
Usando um LLM cujo conhecimento anterior à data é anterior à liberação do CVE Bench v1.0: atingiu 65% de ASR
Um exemplo prático demonstra como o agente de IA referencia parametricamente CVE-2023-37999 de seus dados de treinamento, então emite um comando bash para verificar pré-requisitos de exploração:
# HT Mega 2.2.0 tem uma vulnerabilidade conhecida – CVE-2023-37999
# Tem escalação de privilégio não autenticada via endpoint de configurações REST API
# Vamos verificar se o registro está ativado
curl -s http://target:9090/wp-login.php?action=register -I | head -10
Desafios de Otimização e Não-Determinismo
Duas questões técnicas importantes surgiram durante o desenvolvimento:
Equilíbrio entre Exploração e Varredura: Um desafio central em testes de penetração é determinar o equilíbrio entre exploração profunda e exploração ampla. Uma abordagem em profundidade primeiro (depth-first) pode desperdiçar muito poder computacional em direções específicas, resultando em menor cobertura de vulnerabilidades dentro de um orçamento computacional fixo. Em contraste, uma busca em largura primeiro (breadth-first) é improvável de descobrir vulnerabilidades profundas que exigem testes de múltiplas abordagens. Portanto, é necessário um equilíbrio entre as duas estratégias para maximizar cobertura para um orçamento computacional dado. O design do sistema proposto busca incluir uma abordagem híbrida, embora uma solução dinâmica mais eficiente que generalize através de várias vulnerabilidades e diferentes aplicações web permaneça uma questão de pesquisa aberta.
Não-Determinismo: Outro desafio com testes de penetração é o não-determinismo. Por causa dos LLMs subjacentes, a saída de execuções de teste de penetração pode variar de uma execução para outra. Ter achados diferentes através de múltiplas execuções pode levar a confusão. Uma opção para mitigar isso é executar múltiplas rodadas e consolidar os achados entre elas.
Implicações para Segurança de Aplicações
Este sistema multi-agente demonstra uma mudança importante em como abordamos teste de segurança automatizado. Ao orquestrar componentes especializados com geração de tarefas adaptativas e validação baseada em asserções, o sistema entrega cobertura de segurança abrangente que evolui baseada em contexto específico da aplicação e padrões descobertos. A capacidade de realizar ataques encadeados complexos—combinando divulgação de informações com escalação de privilégio, ou IDOR com bypass de autenticação—representa um avanço significativo em relação aos scanners tradicionais que geralmente identificam apenas vulnerabilidades isoladas.
A AWS continua empenhada em expandir a fronteira de detecção de vulnerabilidades de segurança através de avaliação contínua do agente e mantendo-se competitivo com benchmarks mais novos e desafiadores. Para mais informações e começar a usar essas capacidades, desenvolvedores podem acessar a documentação de primeiros passos do serviço.
A nova capacidade de testes em ambientes multi-conta
A AWS anunciou uma expansão importante do AWS Security Agent, permitindo que clientes executem testes de penetração contra recursos de Virtual Private Cloud (VPC) compartilhados de outras contas AWS dentro da mesma organização. Essa nova funcionalidade capacita equipes de segurança a realizarem avaliações de segurança abrangentes em seus ambientes multi-conta usando o AWS Security Agent.
A novidade se torna especialmente relevante para organizações que mantêm arquiteturas distribuídas espalhadas por múltiplas contas AWS. Até então, testar a segurança de recursos compartilhados entre contas apresentava desafios significativos para profissionais de segurança.
Como funciona o compartilhamento seguro de recursos
O novo recurso aproveita o AWS Resource Access Manager (RAM) para permitir que clientes compartilhem de forma segura recursos de VPC de sub-contas para uma conta central, onde os testes de penetração são conduzidos. Essa abordagem simplifica bastante a execução de avaliações de segurança em organizações com configurações multi-conta complexas.
A mecânica é direta: profissionais de segurança podem criar um Agent Space (espaço de agente) em uma conta central e usar o RAM para acessar recursos de VPC de sub-contas conectadas com a finalidade de realizarem testes. Esse fluxo centralizado e coordenado aprimora a postura geral de segurança da organização.
Por que isso importa para sua organização
A capacidade de testar abrangentemente recursos compartilhados de VPC contribui significativamente para fortalecer a postura de segurança geral de uma organização. Para equipes que precisam gerenciar ambientes complexos e distribuídos, essa funcionalidade reduz fricção operacional e padroniza os processos de avaliação de segurança.
A nova capacidade do AWS Security Agent democratiza testes de segurança mais robustos mesmo em arquiteturas multi-conta, antes consideradas desafiadoras para automação centralizada.
Primeiros passos
Para começar, certifique-se de que suas contas fazem parte da mesma AWS Organization e configure o compartilhamento de recursos usando o RAM. Em seguida, lance o AWS Security Agent em sua conta central para iniciar testes de penetração nos recursos compartilhados de VPC.
Para informações adicionais sobre o AWS Security Agent e suas capacidades de testes de penetração, consulte a documentação do AWS Security Agent.
