Category: Uncategorized

Integração que traz visibilidade em tempo real

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.

Fonte

AWS Network Firewall now supports firewall state change notifications through Amazon EventBridge (https://aws.amazon.com/about-aws/whats-new/2026/02/firewall-state-change-notifications/)

O que mudou no EC2 Image Builder

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.

As Políticas de Ciclo de Vida estão disponíveis em todas as regiões comerciais da AWS. Para aprofundar seus conhecimentos, consulte a documentação completa sobre gerenciamento de ciclo de vida de imagens.

Fonte

EC2 Image Builder enhances lifecycle policies with wildcard support and simplified IAM (https://aws.amazon.com/about-aws/whats-new/2026/02/ec2-image-builder-lifecycle-enhancements/)

Um novo modelo de segurança simplificado

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.

Fonte

AWS Security Hub launches Extended plan for pay-as-you-go partner solutions (https://aws.amazon.com/about-aws/whats-new/2026/02/sec-hub-extended/)

Entendendo os Agentes de IA de Última Geração

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.

Fonte

Inside AWS Security Agent: A multi-agent architecture for automated penetration testing (https://aws.amazon.com/blogs/security/inside-aws-security-agent-a-multi-agent-architecture-for-automated-penetration-testing/)

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.

Fonte

AWS Security Agent adds support for penetration tests on shared VPCs across AWS accounts (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-security-agent-adds-penetration-tests-shared/)

Aurora DSQL expande compatibilidade com ferramentas de desenvolvimento

A AWS anunciou, em fevereiro de 2026, o lançamento de integrações do Aurora DSQL com ferramentas populares de Object-Relational Mapping (ORM) e migração de banco de dados. O anúncio inclui um adaptador para Tortoise (ORM em Python), um dialeto para Flyway (ferramenta de gerenciamento de schema), e ferramentas de linha de comando para Prisma (ORM em Node.js). Essas integrações foram desenvolvidas para facilitar a utilização do Aurora DSQL por desenvolvedores que já utilizam esses frameworks em seus projetos.

Adaptador para Tortoise: simplificando desenvolvimento em Python

O Adaptador Aurora DSQL para Tortoise possibilita que desenvolvedores Python construam aplicações utilizando Tortoise sem necessidade de escrever código customizado para autenticação. O adaptador oferece suporte tanto para drivers asyncpg quanto psycopg, integra-se ao Aurora DSQL Connector para Python para geração automática de tokens de autenticação (IAM), e inclui patches de compatibilidade para migrações avançadas.

Dialeto Flyway: compatibilidade com arquitetura distribuída

O dialeto Flyway foi adaptado especificamente para a arquitetura distribuída do Aurora DSQL. Essa integração gerencia automaticamente comportamentos específicos do Aurora DSQL, como autenticação baseada em Identidade e Acesso (IAM), permitindo que a ferramenta trabalhe perfeitamente com o serviço da AWS sem configurações adicionais complexas.

Ferramentas CLI Prisma: validação e migração

As ferramentas de linha de comando Prisma para Aurora DSQL auxiliam desenvolvedores Node.js na validação de seus schemas Prisma para compatibilidade com o Aurora DSQL e na geração de migrações compatíveis com o serviço. Esse conjunto de ferramentas simplifica significativamente o caminho desde o desenvolvimento até a produção.

Próximos passos e recursos disponíveis

Para começar, a AWS disponibilizou repositórios GitHub para cada uma das integrações: Tortoise ORM, Flyway, e Prisma. Desenvolvedores podem começar a explorar Aurora DSQL gratuitamente através da camada gratuita da AWS. Para aprender mais sobre o Aurora DSQL, visite a página oficial do serviço.

Fonte

Aurora DSQL launches new support for Tortoise, Flyway, and Prisma (https://aws.amazon.com/about-aws/whats-new/2026/02/aurora-dsql-launches-tortoise-flyway-prisma/)

Novas integrações para simplificar o acesso ao Aurora DSQL

A AWS anunciou o lançamento de duas integrações importantes para o Aurora DSQL: o Driver Aurora DSQL para SQLTools e o Plugin Aurora DSQL para DBeaver Community Edition. Essas integrações abrem novas possibilidades para profissionais que trabalham com banco de dados, permitindo usar ferramentas populares e consolidadas em seus fluxos de trabalho.

O que essas integrações oferecem

As duas novas integrações permitem aos usuários do Aurora DSQL aproveitar ferramentas robustas de banco de dados para executar consultas contra clusters do Aurora DSQL, explorar esquemas de banco de dados e gerenciar seus dados de forma intuitiva. A proposta é tornar o acesso ao banco de dados mais direto e prático, eliminando as complexidades técnicas tradicionais.

Autenticação simplificada e segura

Um dos principais benefícios dessas integrações é a simplificação da autenticação. Ambas eliminam a necessidade de escrever código para geração de tokens ou fornecer manualmente tokens IAM (Gerenciamento de Identidade e Acesso). O sistema automaticamente trata a autenticação IAM e gerencia transparentemente os tokens de acesso, o que significa menos linhas de código e menos pontos de falha na sua infraestrutura.

Isso também elimina os riscos de segurança associados às tradicionais senhas geradas por usuários. Com as duas integrações, é possível usar credenciais AWS IAM para autenticação segura e sem necessidade de senha.

Integração com Visual Studio Code e editores compatíveis

O driver SQLTools integra o Aurora DSQL com Visual Studio Code e está também disponível no Open VSX Registry para uso em editores compatíveis com VS Code, como Cursor e Kiro. Isso oferece flexibilidade para desenvolvedores que preferem diferentes ambientes de desenvolvimento.

Plugin DBeaver baseado no conector JDBC

O plugin para DBeaver é construído com base no Aurora DSQL Connector para JDBC (Conectividade de Banco de Dados Java), aproveitando uma arquitetura consolidada na comunidade de desenvolvimento Java.

Como começar

Para começar a usar essas integrações, você pode consultar a documentação oficial do Aurora DSQL. A AWS oferece guias específicos para configurar o Visual Studio Code e integrar com o DBeaver.

Se deseja experimentar o Aurora DSQL sem custos, é possível começar gratuitamente através da camada gratuita da AWS. Para mais informações sobre o Aurora DSQL e suas capacidades, consulte a página oficial do serviço.

Fonte

Aurora DSQL launches new integrations for Visual Studio Code SQLTools and DBeaver (https://aws.amazon.com/about-aws/whats-new/2026/02/aurora-dsql-visual-studio-code-sqltools-dbeaver/)

Nova integração simplifica a criação de políticas IAM

A AWS anunciou a disponibilidade do AWS IAM Policy Autopilot como um Kiro Power. Esta ferramenta de análise estática de código aberto foi lançada durante o re:Invent 2025 e agora oferece aos desenvolvedores uma forma mais eficiente de integrar expertise em políticas de segurança ao desenvolvimento de aplicações com IA agentic.

O que é o AWS IAM Policy Autopilot

O AWS IAM Policy Autopilot é uma solução que auxilia desenvolvedores na criação rápida de políticas baseline de Controle de Acesso por Identidade e Acesso (IAM — Identity and Access Management) da AWS. Essas políticas podem ser refinadas conforme as aplicações evoluem, eliminando a necessidade de criação manual de políticas IAM — um processo que tradicionalmente consome tempo e requer conhecimento profundo de segurança na nuvem.

Benefícios da integração como Kiro Power

A transformação dessa ferramenta em um Kiro Power traz melhorias significativas ao fluxo de trabalho dos desenvolvedores:

Instalação simplificada

O grande diferencial é a instalação com um único clique, disponível diretamente pela interface do Kiro IDE e pela interface web. Isso elimina completamente a necessidade de configuração manual do MCP (Model Context Protocol) server, processo que antes era necessário para integrar a ferramenta.

Integração perfeita com ambientes de desenvolvimento

O fluxo de trabalho streamlined permite que os desenvolvedores gerem políticas IAM sem abandonar seu ambiente de codificação, integrando-se perfeitamente em ambientes de desenvolvimento assistido por IA. Isso significa velocidade na criação de políticas e produtividade aumentada.

Casos de uso principais

A AWS destaca três cenários onde o AWS IAM Policy Autopilot como Kiro Power oferece maior valor:

• Prototipagem rápida: Para projetos que exigem políticas IAM da AWS em fases iniciais de desenvolvimento
• Baseline para novos projetos: Criação de políticas iniciais sólidas para novas aplicações da AWS
• Produtividade em IDE: Geração de políticas diretamente no ambiente de codificação, sem interrupções no fluxo de desenvolvimento

Próximos passos

Desenvolvedores interessados em explorar essa ferramenta podem acessar o repositório do AWS IAM Policy Autopilot no GitHub para documentação técnica completa e orientações de implementação. Para informações adicionais sobre Kiro Powers e outras integrações disponíveis, consulte a página de Kiro Powers.

Fonte

AWS IAM Policy Autopilot is now available as a Kiro Power (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-iam-policy-autopilot-kiro-power/)

Inteligência de Ameaças: Um Novo Panorama de Ciberataques Amplificados por IA

Os serviços comerciais de inteligência artificial estão transformando o cenário de ciberataques. A Amazon Threat Intelligence vem rastreando de perto uma tendência preocupante: atores de ameaça menos sofisticados agora conseguem executar operações em escala massiva com ajuda de ferramentas de IA generativa. Uma investigação recente ilustra essa mudança de forma alarmante.

Entre janeiro e fevereiro de 2026, a Amazon Threat Intelligence detectou um ator de ameaça falante de russo, financeiramente motivado, que utilizou múltiplos serviços comerciais de IA generativa para comprometer mais de 600 dispositivos FortiGate distribuídos em mais de 55 países. O aspecto crítico: nenhuma vulnerabilidade zero-day ou exploração avançada foi necessária. Em vez disso, o ataque explorou lacunas de segurança fundamental — portas de gerenciamento expostas à internet e credenciais fracas com autenticação de fator único — que a IA ajudou a explorar em escala industrial.

Este padrão de operação é notável porque revela algo importante: a IA funcionou como multiplicador de força, permitindo que um ator com capacidades técnicas limitadas alcançasse escala operacional que normalmente exigiria equipes maiores e mais especializadas. Vale ressaltar que a infraestrutura da AWS não foi envolvida nesta campanha.

A Democratização do Ataque Cibernético

Um Ator Financeiramente Motivado, Não uma Nação-Estado

A análise da Amazon Threat Intelligence aponta para um ator financeiramente motivado — provavelmente um indivíduo ou pequeno grupo — sem conexão conhecida com grupos de ameaça persistente avançada (Ameaças Persistentes Avançadas – APAs) com recursos patrocinados por estados. Apesar dessa limitação técnica baseline, o ator comprometeu múltiplos ambientes Active Directory, extraiu bases de dados completas de credenciais e direcionou infraestrutura de backup — tudo isso consistente com preparação para implantação de ransomware.

O padrão operacional revelou algo significativo: quando o ator enfrentava ambientes endurecidos ou defesas sofisticadas, simplesmente migrava para alvos mais fáceis, em vez de persistir. Isso demonstra que a vantagem reside na eficiência amplificada por IA e escala operacional, não em habilidade técnica profunda.

Qual Era a Metodologia?

A investigação ganhou visibilidade extraordinária porque o ator teve falhas graves de segurança operacional. A infraestrutura maliciosa deixou expostos planos de ataque gerados por IA, configurações de vítimas e código-fonte de ferramentas personalizadas — basicamente um arquivo de operações completo. Isso permitiu à Amazon Threat Intelligence documentar precisamente como o ator utilizava IA em cada fase.

Como o Ataque Começou: Acesso Inicial por Abuso de Credenciais

Varredura Sistemática e Credenciais Comuns

O vetor inicial de acesso foi baseado em credenciais — acesso direto às interfaces de gerenciamento de FortiGate expostas à internet. A análise das ferramentas do ator revelou varredura sistemática em portas 443, 8443, 10443 e 4443, seguida por tentativas de autenticação usando credenciais frequentemente reutilizadas.

Arquivos de configuração do FortiGate são alvos de alto valor porque contêm informações críticas: credenciais de usuário SSL-VPN com senhas recuperáveis, credenciais administrativas, topologia completa de rede e informações de roteamento, políticas de firewall que revelam arquitetura interna, e configurações de pares IPsec VPN.

Ferramentas Assistidas por IA para Extração de Dados

O ator desenvolveu scripts Python assistidos por IA para fazer parsing, descriptografar e organizar as configurações roubadas. A escala de distribuição foi oportunista em vez de setorial — consistente com varredura automatizada massiva. Porém, certos padrões sugerem comprometimento no nível organizacional, onde múltiplos dispositivos FortiGate pertencentes à mesma entidade foram acessados. Concentrações de dispositivos comprometidos foram observadas na Ásia do Sul, América Latina, Caribe, África Ocidental, Europa do Norte e Sudeste Asiático, entre outras regiões.

Ferramentas Personalizadas: Um Framework de Reconhecimento Gerado por IA

Sinais de Desenvolvimento Assistido por IA

Após acessar redes de vítimas via VPN, o ator implanta uma ferramenta de reconhecimento personalizada, com versões escritas tanto em Go quanto em Python. A análise do código-fonte revela indicadores claros de desenvolvimento assistido por IA: comentários redundantes que apenas reafirmam nomes de funções, arquitetura simplista com investimento desproporcional em formatação sobre funcionalidade, parsing JSON ingênuo via correspondência de string em vez de desserialização apropriada, e shims de compatibilidade para built-ins de linguagem com stubs vazios de documentação.

Embora funcional para o caso de uso específico do ator, as ferramentas carecem de robustez e falham em casos extremos — características típicas de código gerado por IA sem refinamento significativo.

Fluxo de Trabalho Automatizado do Ator

A ferramenta automatiza o fluxo de reconhecimento pós-VPN: ingere redes-alvo a partir de tabelas de roteamento VPN, classifica redes por tamanho, executa descoberta de serviço usando gogo (scanner de porta de código aberto), identifica automaticamente hosts SMB e controladores de domínio, e integra varredura de vulnerabilidades usando Nuclei (scanner de vulnerabilidades de código aberto) contra serviços HTTP descobertos para produzir listas de alvos priorizadas.

Pós-Exploração: Técnicas Bem Conhecidas com Escala Amplificada

Comprometimento de Domínio

Dentro das redes de vítimas, o ator segue uma abordagem padrão usando ferramentas ofensivas de código aberto conhecidas. A documentação operacional detalha o uso pretendido de Meterpreter (kit de pós-exploração de código aberto) com o módulo mimikatz para executar ataques DCSync contra controladores de domínio, permitindo extrair hashes de senha NTLM do Active Directory. Em comprometimentos confirmados, o ator obteve bases de dados de credenciais de domínio completas. Em pelo menos um caso, a conta de Administrador de Domínio usava uma senha em texto simples, extraída da configuração FortiGate por reutilização de credenciais ou era independentemente fraca.

Movimento Lateral e Backup Targeting

Após comprometimento de domínio, o ator tenta expandir acesso através de ataques pass-the-hash/pass-the-ticket contra infraestrutura adicional, ataques NTLM relay usando ferramentas padrão de envenenamento, e execução remota de comando em hosts Windows. Especificamente, o ator direcionou servidores Veeam Backup & Replication, implantando múltiplas ferramentas para extração de credenciais, incluindo scripts PowerShell, ferramentas compiladas de descriptografia e tentativas de exploração alavancando vulnerabilidades conhecidas de Veeam. Servidores de backup são alvos de alto valor porque tipicamente armazenam credenciais elevadas para operações de backup, e comprometer infraestrutura de backup posiciona um atacante para destruir capacidades de recuperação antes de implantar ransomware.

Falhas de Exploração: O Limite da Dependência de IA

As notas operacionais do ator referenciam múltiplas Vulnerabilidades e Exposições Comuns (CVEs) em vários alvos (CVE-2019-7192, CVE-2023-27532, CVE-2024-40711, entre outros). Um achado crítico é que o ator largamente falhou ao tentar explorar qualquer coisa além dos caminhos de ataque mais diretos e automatizados. Sua própria documentação registra falhas repetidas: serviços direcionados estavam corrigidos, portas necessárias estavam fechadas, vulnerabilidades não se aplicavam às versões do sistema operacional alvo. A avaliação operacional final para uma vítima confirmada reconheceu que infraestrutura-chave estava “bem protegida” com “nenhum vetor de exploração vulnerável”.

A IA Como Multiplicador de Força Operacional

Múltiplos Provedores de Modelos Usados Simultaneamente

A análise revelou que o ator utiliza pelo menos dois provedores de Modelo de Linguagem (Modelo de Linguagem – ML) comerciais distintos em todas as operações. A IA foi usada para gerar metodologias de ataque abrangentes com instruções de exploração passo a passo, taxas de sucesso esperadas, estimativas de tempo e árvores de tarefas priorizadas. Esses planos referenciam pesquisa acadêmica sobre agentes de IA ofensiva, sugerindo que o ator acompanha literatura emergente sobre testes de penetração assistidos por IA.

A IA produz sequências de comando tecnicamente precisas, mas o ator tem dificuldade em se adaptar quando as condições diferem do plano. Não consegue compilar exploits customizados, depurar tentativas de exploração falhadas ou fazer pivôs criativos quando abordagens padrão falham.

Fluxo de Trabalho Multi-Modelo

Um modelo serve como desenvolvedor de ferramentas primário, planejador de ataque e assistente operacional. Um segundo é usado como planejador de ataque suplementar quando o ator precisa ajuda fazendo pivô dentro de uma rede comprometida específica. Em uma instância observada, o ator submeteu a topologia interna completa de uma vítima ativa — endereços IP, nomes de host, credenciais confirmadas e serviços identificados — e solicitou um plano passo a passo para comprometer sistemas adicionais que não conseguiam acessar com ferramentas existentes.

Ferramentas Geradas por IA em Escala

Além do framework de reconhecimento, a infraestrutura do ator contém inúmeros scripts em múltiplas linguagens de programação com características de geração por IA, incluindo parsers de configuração, ferramentas de extração de credenciais, automação de conexão VPN, orquestração de varredura massiva e dashboards de agregação de resultados. O volume e variedade de ferramentas personalizadas normalmente indicariam uma equipe de desenvolvimento bem-recursos. Em vez disso, um ator único ou pequeno grupo gerou todo esse toolkit através de desenvolvimento assistido por IA.

Avaliação do Ator de Ameaça

Com base em análise abrangente, a Amazon Threat Intelligence avalia este ator de ameaça como: Motivação financeira presumida, baseada em direcionamento generalizado e indiscriminado com sofisticação baixa; Falante de russo, baseado em documentação operacional extensa em russo; Capacidade técnica baseline baixa a média, significativamente amplificada por IA — o ator pode executar ferramentas ofensivas padrão e automatizar tarefas rotineiras mas tem dificuldade com compilação de exploits, desenvolvimento customizado e resolução criativa de problemas durante operações ao vivo; Dependência extensiva de IA em todas as fases operacionais, incluindo desenvolvimento de ferramentas, planejamento de ataque, geração de comando e relatório operacional; Escala operacional ampla com dispositivos comprometidos em dezenas de países e evidência de operações sustentadas por período estendido; Profundidade de pós-exploração rasa com falhas repetidas contra alvos endurecidos ou não-padronizados e padrão de migração para alvos mais suaves quando abordagens automatizadas falham; Segurança operacional inadequada com planos operacionais detalhados, credenciais e dados de vítimas armazenados sem criptografia junto com ferramentas.

Resposta e Defesa Organizacional

Ações da Amazon Threat Intelligence

Ao descobrir esta campanha, a Amazon Threat Intelligence tomou ações específicas: compartilhou inteligência acionável, incluindo indicadores de comprometimento, com parceiros relevantes; colaborou com parceiros da indústria para ampliar visibilidade da campanha e apoiar esforços de defesa coordenada. Através desses esforços, a Amazon ajudou a reduzir a efetividade operacional do ator de ameaça e permitiu que organizações em múltiplos países tomassem passos para interromper a eficácia da campanha.

Auditoria de Dispositivos FortiGate

Organizações executando dispositivos FortiGate devem tomar ação imediata: garantir que interfaces de gerenciamento não sejam expostas à internet; se administração remota for necessária, restringir acesso a faixas de IP conhecidas e usar um host bastião ou rede de gerenciamento fora de banda; mudar todas as credenciais padrão e comuns em dispositivos FortiGate, incluindo contas administrativas e de usuário VPN; girar todas as credenciais de usuário SSL-VPN, particularmente para qualquer dispositivo cuja interface de gerenciamento foi ou pode ter sido acessível pela internet; implementar autenticação multifator para todos os acessos administrativos e VPN; revisar configurações de FortiGate para contas administrativas não autorizadas ou mudanças de política; auditar logs de conexão VPN para conexões de localizações geográficas inesperadas.

Higiene de Credenciais

Dada a extração de credenciais de configurações FortiGate: auditar reutilização de senha entre credenciais FortiGate VPN e contas de domínio Active Directory; implementar autenticação multifator para todos os acessos VPN; impor senhas únicas e complexas para todas as contas, particularmente contas de Administrador de Domínio; revisar e girar credenciais de conta de serviço, especialmente aquelas usadas em infraestrutura de backup.

Detecção de Pós-Exploração

Organizações que podem ter sido afetadas devem monitorar: operações DCSync inesperadas (ID de Evento 4662 com GUIDs relacionadas a replicação); novas tarefas agendadas nomeadas para imitar serviços Windows legítimos; conexões de gerenciamento remoto incomuns de pools de endereço VPN; artefatos de envenenamento LLMNR/NBT-NS no tráfego de rede; acesso não autorizado a armazenamentos de credencial de backup; novas contas com nomes projetados para se mesclar com contas de serviço legítimas.

Endurecimento de Infraestrutura de Backup

O foco do ator em infraestrutura de backup destaca a importância de: isolar servidores de backup do acesso de rede geral; fazer patch de software de backup contra vulnerabilidades conhecidas de extração de credenciais; monitorar carregamento não autorizado de módulo PowerShell em servidores de backup; implementar cópias de backup imutáveis que não possam ser modificadas mesmo com acesso administrativo.

Recomendações Específicas para AWS

Para organizações usando AWS: ativar Amazon GuardDuty para detecção de ameaça, incluindo monitoramento de chamadas API incomuns e padrões de uso de credenciais; usar Amazon Inspector para verificar automaticamente por vulnerabilidades de software e exposição de rede não intencional; usar AWS Security Hub para manter visibilidade contínua na postura de segurança; usar AWS Systems Manager Patch Manager para manter conformidade de patch em instâncias EC2 executando dispositivos de rede; revisar padrões de acesso IAM (Identity and Access Management – Gerenciamento de Identidade e Acesso) para sinais de replay de credenciais seguindo qualquer comprometimento suspeito de dispositivo de rede.

Indicadores de Comprometimento e Detecção

A dependência desta campanha em ferramentas ofensivas de código aberto legítimas — incluindo Impacket, gogo, Nuclei e outras — significa que detecção tradicional baseada em indicador tem efetividade limitada. Essas ferramentas são amplamente usadas por testadores de penetração e profissionais de segurança, e sua presença sozinha não é indicativa de comprometimento. Organizações devem investigar contexto ao redor de correspondências, priorizando detecção comportamental (padrões anormais de autenticação VPN, replicação Active Directory inesperada, movimento lateral de pools de endereço VPN) sobre abordagens baseadas em assinatura.

Conclusão: Fundamentos de Segurança Continuam Sendo a Defesa Mais Efetiva

Esta campanha obteve sucesso através de uma combinação de interfaces de gerenciamento expostas, credenciais fracas e autenticação de fator único — todas lacunas de segurança fundamentais que IA ajudou um ator sofisticado explorar em escala. Isso sublinha que fundamentos de segurança forte são defesas poderosas contra ameaças potencializadas por IA. À medida que esperamos que essa tendência continue em 2026, organizações devem antecipar que atividade de ameaça potencializada por IA continuará crescendo em volume tanto de adversários hábeis quanto não-hábeis. Gestão de patch para dispositivos perimetral, higiene de credenciais, segmentação de rede e detecção robusta para indicadores de pós-exploração permanecem as contramedidas mais efetivas.

Fonte

AI-augmented threat actor accesses FortiGate devices at scale (https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/)

Expansão do IAM Identity Center para Ásia-Pacífico

A AWS anunciou a disponibilidade do AWS IAM Identity Center na região Ásia-Pacífico (Nova Zelândia), ampliando sua cobertura global para 38 regiões AWS. Essa expansão oferece às organizações operando na região uma solução nativa para gerenciar o acesso de seus usuários aos aplicativos e serviços hospedados na nuvem.

O que é o IAM Identity Center

O IAM Identity Center (Centro de Identidade do AWS Identity and Access Management) é o serviço recomendado pela AWS para gerenciar o acesso da força de trabalho aos aplicativos AWS. Seu principal diferencial é a capacidade de conectar uma única vez a fonte de identidades corporativas já existente na organização com a plataforma AWS, eliminando a necessidade de manter múltiplos sistemas de autenticação.

Uma vez integrado, o serviço oferece aos usuários uma experiência de single sign-on unificada em todos os aplicativos AWS, reduzindo fricção e aumentando a produtividade. Os profissionais de TI, por sua vez, ganham um ponto centralizado para administração de identidades, simplificando operações em ambientes complexos.

Capacidades principais

Experiências personalizadas com Amazon Q

O IAM Identity Center alimenta experiências personalizadas oferecidas por aplicativos AWS como o Amazon Q. Graças à integração, o serviço compreende quem é cada usuário e pode adaptar o comportamento de aplicações de acordo com seu perfil e permissões.

Auditoria e controle de acesso consciente do usuário

O serviço permite definir e auditar o acesso de usuários específicos a dados em serviços como o Amazon Redshift. Essa granularidade é essencial para organizações que precisam manter conformidade com regulamentações e políticas internas rigorosas.

Gerenciamento centralizado de múltiplas contas AWS

Para empresas que operam com várias contas AWS, o IAM Identity Center oferece administração centralizada de acesso, evitando a necessidade de configurar identidades repetidamente em cada conta.

Disponibilidade e custos

O IAM Identity Center está disponível na nova região sem custos adicionais, mantendo o modelo de precificação compatível com demais regiões onde o serviço opera. Essa inclusão na região Ásia-Pacífico (Nova Zelândia) reforça o compromisso da AWS de oferecer cobertura global para seus serviços principais de segurança e identidade.

Próximos passos

Organizações interessadas em explorar o IAM Identity Center podem consultar a página de detalhes do produto para compreender melhor as capacidades e arquitetura recomendada. Para começar a usar o serviço de imediato, a documentação do IAM Identity Center oferece guias práticos de implementação e configuração.

Fonte

AWS IAM Identity Center is now available in the Asia Pacific (New Zealand) AWS Region (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-iam-identity-center-asia-pacific-new-zealand-region/)