Category: Uncategorized

O que mudou no AWS Network Firewall

O AWS Network Firewall passou a suportar conexão nativa ao AWS Transit Gateway. Para quem já usa o Transit Gateway para rotear tráfego de redes do Amazon Virtual Private Cloud (Amazon VPC) até uma VPC de inspeção centralizada, essa novidade representa uma simplificação arquitetural significativa.

No modelo tradicional, era necessário manter uma VPC dedicada exclusivamente para hospedar os endpoints do firewall, além de gerenciar todas as tabelas de roteamento e sub-redes associadas. Com a conexão nativa, o Network Firewall se anexa diretamente ao Transit Gateway — a AWS provisiona e gerencia a VPC subjacente de forma transparente, e o firewall passa a aparecer como um anexo de função de rede (network function attachment) no Transit Gateway.

Por que migrar para o modelo com conexão nativa

A AWS aponta dois motivos principais para considerar essa migração:

• Alocação flexível de custos: com a conexão nativa, é possível usar as políticas de medição do Transit Gateway para repassar os custos de tráfego para cada conta proprietária. Esse recurso de alocação flexível de custos para tráfego do Network Firewall via Transit Gateway está disponível somente no modelo de conexão nativa. No modelo anterior, era possível alocar apenas os encargos de processamento de dados do Transit Gateway, mas não os do próprio Network Firewall.
• Redução da complexidade arquitetural: a VPC de inspeção dedicada deixa de existir, junto com suas tabelas de roteamento e sub-redes. Menos recursos para gerenciar significa menos superfície de erro e menor overhead operacional.

O que preparar antes de começar

Pré-requisitos

Antes de criar o novo firewall com conexão nativa ao Transit Gateway, é necessário reunir as seguintes informações:

• ID do Transit Gateway: o identificador da instância do Transit Gateway ao qual o firewall será anexado.
• Configuração de logs: crie uma nova configuração de logs (por exemplo, novos grupos de log no Amazon CloudWatch) exclusiva para o novo firewall. Durante a migração, os dois firewalls estarão ativos simultaneamente, e manter os logs separados facilita o monitoramento e a resolução de problemas em cada um.
• Política do firewall: crie uma nova política para o novo firewall em vez de reutilizar a existente. Com políticas separadas, é possível ajustar as regras do novo ambiente sem afetar o firewall em produção enquanto ambos operam em paralelo.

Considerações importantes

• Criptografia no Transit Gateway: verifique se o suporte a criptografia do Transit Gateway está habilitado. Se a criptografia for obrigatória para a sua postura de segurança, saiba que a conexão nativa ao Network Firewall ainda não suporta esse recurso — nesse caso, será necessário manter a configuração atual.
• IPs Elásticos do NAT Gateway: se for necessário manter os mesmos IPs públicos (por exemplo, para listas de permissão de parceiros), planeje isso com antecedência. O processo de preservação dos IPs Elásticos é detalhado na seção Preservando os IPs Elásticos do NAT Gateway durante a migração.
• Janela de manutenção: planeje a migração para uma janela de manutenção dedicada. Pequenas interrupções de rede ocorrerão em etapas específicas, como na troca de associações de tabelas de roteamento do Transit Gateway e na substituição de NAT Gateways.

Como realizar a migração

A recomendação é manter a configuração existente do Network Firewall intacta enquanto o novo firewall com conexão nativa é configurado em paralelo. Essa abordagem minimiza o tempo de inatividade e permite validar a nova configuração antes de migrar o tráfego de produção.

O processo varia de acordo com a arquitetura atual. A AWS descreve dois cenários mais comuns. Para o passo a passo detalhado usando Terraform, AWS CloudFormation ou manualmente pelo AWS Management Console, consulte o repositório do guia de migração.

Arquitetura 1: VPC de inspeção separada da VPC de saída

Nesse cenário, existe uma VPC dedicada para os endpoints do firewall e outra VPC dedicada exclusivamente para os NAT Gateways responsáveis pelo tráfego de saída.

O processo de migração em alto nível para essa arquitetura é:

1. Implante uma nova VPC de saída com um NAT Gateway temporário, mantendo a implantação existente inalterada.
2. Crie o novo firewall com conexão nativa ao Transit Gateway.
3. Configure três novas tabelas de roteamento do Transit Gateway: uma tabela de inspeção (associada ao novo firewall), uma tabela de saída (associada à nova VPC de saída) e uma tabela temporária para spoke VPCs em migração.
4. Teste o novo firewall movendo uma única spoke VPC para o novo caminho. Verifique a conectividade e confirme que o firewall está inspecionando o tráfego verificando os logs de alerta em busca de detalhes da camada 7 (camada de aplicação). A presença de informações de camada 7 nos logs indica que o firewall está vendo as duas direções do fluxo de tráfego — o que confirma que não há roteamento assimétrico.
5. Migre as spoke VPCs restantes de forma incremental ou, quando houver confiança na nova implantação, atualize a rota padrão na tabela de roteamento de spokes existente para apontar para o novo anexo de função de rede do Network Firewall.
6. Opcionalmente, preserve os IPs Elásticos originais do NAT Gateway redirecionando o tráfego de volta para a VPC de saída existente (veja Preservando os IPs Elásticos do NAT Gateway durante a migração).
7. Descomissione os recursos antigos após verificar que o tráfego está fluindo corretamente. Quais VPCs serão removidas depende de ter preservado ou não os IPs Elásticos originais (veja Preservando os IPs Elásticos do NAT Gateway durante a migração).

Para o guia completo dessa migração, acesse: guia de migração via Terraform, guia via CloudFormation ou guia manual pelo console.

Arquitetura 2: VPC combinada de inspeção e saída

Nesse cenário, uma única VPC concentra tanto os endpoints do Network Firewall quanto os NAT Gateways responsáveis pelo tráfego de saída.

O processo de migração segue as mesmas etapas em alto nível da Arquitetura 1:

1. Implante uma nova VPC de saída dedicada com um NAT Gateway temporário.
2. Crie o novo firewall com conexão nativa ao Transit Gateway.
3. Configure três novas tabelas de roteamento do Transit Gateway: tabela de inspeção, tabela de saída e tabela temporária para spokes em migração.
4. Teste o novo firewall movendo uma única spoke VPC para o novo caminho e verifique a presença de detalhes de camada 7 nos logs de alerta.
5. Migre as spoke VPCs restantes de forma incremental ou em bloco.
6. Opcionalmente, preserve os IPs Elásticos originais transferindo-os para a nova VPC de saída.
7. Descomissione a antiga VPC combinada após confirmar que o tráfego está fluindo corretamente.

Para o guia completo dessa migração, acesse: guia de migração via Terraform, guia via CloudFormation ou guia manual pelo console.

Diferenças entre as duas arquiteturas

Ambas as arquiteturas implantam os mesmos novos recursos e utilizam a mesma abordagem de migração em fases. As diferenças estão na estrutura inicial de roteamento do Transit Gateway (a Arquitetura 1 possui três tabelas de roteamento distribuídas em duas VPCs; a Arquitetura 2 possui duas tabelas em uma única VPC) e nos recursos a serem removidos ao final (duas VPCs antigas em vez de uma). Ambas convergem para o mesmo estado final. Para uma comparação detalhada, consulte o repositório do guia de migração.

Boas práticas para minimizar riscos

Independentemente da arquitetura de origem, a AWS recomenda seguir estas práticas para reduzir riscos durante a migração:

• Teste antes de migrar: crie o novo firewall com conexão nativa em paralelo com a configuração existente. Use uma VPC de teste para validar a nova configuração. Verifique se os logs estão funcionando corretamente e se os logs de alerta do firewall mostram detalhes de tráfego de camada 7 — isso confirma a ausência de roteamento assimétrico. Teste cenários de tráfego permitido e bloqueado antes de migrar o ambiente de produção. O repositório do guia de migração inclui templates de CloudFormation e Terraform para ambas as arquiteturas iniciais, permitindo praticar a migração completa em uma conta de desenvolvimento ou teste.
• Migre em fases: comece com uma única VPC de carga de trabalho não crítica. Atualize apenas as rotas dessa VPC para usar o novo anexo do firewall. Monitore o comportamento das aplicações antes de prosseguir. Ao planejar a ordem de migração, migre ao mesmo tempo as spoke VPCs que possuem tráfego leste-oeste entre si. Durante a migração em fases, spokes em caminhos de firewall diferentes terão seu tráfego leste-oeste atravessando dois firewalls stateful — e como cada firewall rastreia o estado de conexão de forma independente, tráfego que entra por um firewall e retorna por outro aparece como não rastreado, podendo ser descartado.
• Mantenha o firewall antigo ativo: não descomissione a configuração anterior até que todo o tráfego tenha sido migrado.
• Prepare um plano de rollback: documente as configurações atuais das tabelas de roteamento antes de fazer qualquer alteração. Se surgirem problemas, reverter as mudanças nas tabelas de roteamento restaura a configuração anterior.

Preservando os IPs Elásticos do NAT Gateway

Um ponto crítico durante a migração é manter os endereços IP Elásticos dos NAT Gateways existentes. Muitas organizações têm esses IPs em listas de permissão de parceiros externos, serviços de terceiros ou regras de firewall. Alterá-los exigiria coordenação com múltiplos stakeholders e poderia impactar operações.

Durante a migração, como os dois ambientes precisam operar simultaneamente, serão criados NAT Gateways temporários com IPs Elásticos temporários na nova VPC de saída. Após confirmar que o novo firewall está estável e o tráfego de produção foi migrado com sucesso, é possível restaurar os IPs originais.

O processo varia conforme a arquitetura:

• Arquitetura 1 (VPCs separadas): a VPC de saída existente e seus NAT Gateways são independentes da VPC de inspeção que será descomissionada. É possível mantê-los reassociando o anexo do Transit Gateway da VPC de saída existente à nova tabela de roteamento de saída. Essa é uma mudança de roteamento no Transit Gateway que leva segundos, não requer exclusão ou criação de NAT Gateways e não aumenta em complexidade com o número de Zonas de Disponibilidade.
• Arquitetura 2 (VPC combinada): como a VPC antiga contém tanto os endpoints do firewall quanto os NAT Gateways, o caminho mais direto é descomissioná-la e transferir os IPs Elásticos para a nova VPC de saída. Para isso, exclui-se os NAT Gateways antigos para liberar os IPs e, em seguida, criam-se novos NAT Gateways na nova VPC de saída com os IPs originais. Esse processo requer uma breve janela de manutenção e deve ser repetido para cada Zona de Disponibilidade.

Para o procedimento detalhado, consulte as etapas de preservação de IPs Elásticos no repositório do guia de migração.

Conclusão

A conexão nativa do Network Firewall ao Transit Gateway representa uma evolução relevante para quem opera arquiteturas de inspeção centralizada na AWS. A eliminação da VPC de inspeção reduz a complexidade operacional, e a alocação flexível de custos via políticas de medição do Transit Gateway abre novas possibilidades para ambientes multi-conta.

A abordagem de migração em fases — rodando os dois firewalls em paralelo, validando com uma única spoke VPC e migrando o restante quando houver confiança — oferece um caminho seguro para a transição. Para o guia completo com Terraform, CloudFormation ou console, acesse o repositório do guia de migração, que inclui templates de arquitetura inicial para praticar a migração completa em ambiente de teste antes de tocar na produção.

Fonte

Why and how to migrate to a Transit Gateway-attached AWS Network Firewall (https://aws.amazon.com/blogs/security/why-and-how-to-migrate-to-a-transit-gateway-attached-aws-network-firewall/)

Novas APIs de gerenciamento MQTT chegam ao AWS IoT Core

A AWS IoT Core acaba de ganhar duas novas interfaces de programação de aplicações (APIs) voltadas para o gerenciamento de conexões MQTT — o protocolo de mensageria amplamente utilizado em soluções de Internet das Coisas (IoT): GetConnection e ListSubscriptions. O objetivo é dar mais visibilidade e controle sobre o comportamento dos dispositivos conectados à plataforma.

O que cada API oferece

GetConnection

A API GetConnection permite consultar informações detalhadas sobre a conexão de um dispositivo IoT específico. Entre os dados retornados estão o status da conexão, detalhes da sessão MQTT e, opcionalmente, informações de nível de socket — como endereços IP de origem e destino, portas e o identificador do endpoint de VPC (Virtual Private Cloud — Nuvem Privada Virtual) do cliente. O acesso a esses dados é controlado por políticas granulares de IAM (Identity and Access Management — Gerenciamento de Identidade e Acesso), garantindo que apenas quem deve ver essas informações consiga acessá-las.

ListSubscriptions

Já a API ListSubscriptions complementa a anterior ao retornar todas as assinaturas de tópicos de uma sessão MQTT de um cliente, incluindo os níveis de QoS (Quality of Service — Qualidade de Serviço) configurados. Um ponto importante: ela funciona tanto para clientes conectados quanto para clientes offline que possuam sessões persistentes. Isso permite identificar assinaturas sobrepostas ou desnecessárias que podem estar impactando negativamente a performance da solução.

Uma experiência completa de gerenciamento MQTT

Combinadas com a API DeleteConnection, que já existia anteriormente, as duas novas APIs formam um conjunto completo para o gerenciamento do ciclo de vida das conexões MQTT no AWS IoT Core. Com esse trio, equipes de engenharia têm à disposição ferramentas para:

• Resolver problemas de conectividade com mais agilidade;
• Monitorar o comportamento dos clientes MQTT;
• Auditar padrões de conexão em toda a frota de dispositivos;
• Validar e otimizar assinaturas de tópicos.

Disponibilidade

As duas novas APIs já estão disponíveis em todas as regiões onde o AWS IoT Core é suportado. Para se aprofundar, a AWS disponibiliza a documentação oficial e o guia de referência da API do AWS IoT Core.

Fonte

AWS IoT Core adds APIs for MQTT connection management (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-iot-core-apis-mqtt/)

Nova geração do AWS Resilience Hub chega com IA generativa e visibilidade organizacional

A AWS anunciou a disponibilidade geral da próxima geração do AWS Resilience Hub, serviço centralizado no console da AWS que auxilia equipes de engenharia de plataforma e de confiabilidade de sites (SRE — Site Reliability Engineering) a avaliar e fortalecer a resiliência de cargas de trabalho críticas na nuvem.

O que há de novo

Esta atualização representa uma evolução significativa em relação à experiência anterior do Resilience Hub. Entre as principais novidades estão:

• Novo modelo de aplicação: as aplicações agora são modeladas em uma hierarquia de três níveis — sistemas, jornadas de usuário e serviços — refletindo diretamente como essas aplicações entregam valor ao negócio.
• Descoberta de dependências: avaliações automáticas mantêm visibilidade atualizada sobre os serviços da AWS, endpoints internos e endpoints de terceiros dos quais cada serviço depende.
• Análise de modos de falha com IA generativa: uma avaliação baseada em IA generativa analisa os serviços em relação às melhores práticas do AWS Well-Architected, ao AWS Resilience Analysis Framework e às políticas de resiliência da organização, gerando recomendações priorizadas e acionáveis.
• Políticas de resiliência modulares: permitem que as equipes centrais definam e apliquem padrões de resiliência de forma flexível.
• Relatórios em nível organizacional: a integração com o AWS Organizations permite que equipes centrais definam políticas de resiliência e monitorem a postura de resiliência em todas as contas e regiões a partir de um único painel.

Regiões disponíveis

A próxima geração do AWS Resilience Hub já está disponível nas seguintes regiões da AWS: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Paris), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul) e South America (São Paulo) — boa notícia para times brasileiros que operam nessa região.

E os clientes atuais?

Quem já utiliza o AWS Resilience Hub pode continuar usando a experiência atual normalmente. A migração para a nova geração é opcional e pode ser feita no próprio ritmo de cada equipe. Para quem quiser fazer essa transição, há um guia de migração disponível na documentação oficial.

Como começar

Para explorar a nova geração do serviço, acesse diretamente o console da AWS. Mais detalhes sobre funcionalidades e casos de uso estão disponíveis na página do produto e no AWS News Blog.

Fonte

AWS announces general availability of the next generation of AWS Resilience Hub (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-announces-next-gen-aws-resilience-hub/)

O que mudou no AWS Organizations

A AWS anunciou uma melhoria importante no AWS Organizations: a partir de agora, o serviço emite automaticamente eventos no Trilha de Auditoria em Nuvem (CloudTrail) sempre que contas entram ou saem de uma organização. Esses eventos são registrados diretamente na conta de gerenciamento, oferecendo às equipes de segurança e aos administradores de nuvem uma visibilidade muito mais precisa sobre as movimentações de membros na estrutura organizacional.

Antes dessa novidade, alterações no quadro de contas de uma organização podiam passar despercebidas, abrindo brechas para atividades não autorizadas ou incidentes de segurança difíceis de rastrear. Com os novos eventos, esse ponto cego passa a ser monitorado de forma nativa.

Os dois novos eventos

A AWS introduziu dois eventos específicos para cobrir os cenários de entrada e saída de contas:

• AccountJoinedOrganization: registrado sempre que uma conta passa a fazer parte da organização. O evento captura a forma como a conta ingressou — se foi criada diretamente (Created) ou convidada (Invited) — além do horário exato da adesão.
• AccountDepartedOrganization: registrado quando uma conta deixa a organização. O evento documenta o motivo da saída, que pode ser: saída voluntária (Left), remoção pela conta de gerenciamento (Removed) ou encerramento permanente da conta (Cleaned), junto com o horário da partida.

Esse nível de detalhe é especialmente valioso em investigações de incidentes, pois permite reconstruir com precisão o histórico de alterações na composição da organização.

Como aproveitar esses eventos na prática

Com os eventos disponíveis no CloudTrail, é possível integrá-los a outros serviços da AWS para criar fluxos de monitoramento em tempo real. A AWS destaca duas abordagens principais:

• Criação de alarmes no CloudWatch para notificações imediatas quando mudanças organizacionais ocorrerem.
• Configuração de regras no Amazon EventBridge para disparar respostas automáticas diante de alterações suspeitas.

Essas integrações permitem que as equipes respondam rapidamente a situações inesperadas, como uma conta sendo adicionada ou removida fora dos processos normais da empresa.

Casos de uso suportados

A AWS aponta que esse novo recurso atende a cenários críticos para organizações que operam em ambientes AWS de maior escala:

• Detecção de fraudes: identificar movimentações não autorizadas de contas que possam indicar comprometimento ou uso indevido.
• Auditoria de conformidade (compliance): manter registros detalhados de todas as alterações estruturais para atender a requisitos regulatórios.
• Monitoramento de segurança: acompanhar em tempo real qualquer mudança na composição da organização.
• Investigação de incidentes: dispor de trilha de auditoria completa para análise forense quando necessário.

Disponibilidade

Os novos eventos do CloudTrail para o AWS Organizations já estão disponíveis em todas as regiões comerciais da AWS, nas regiões AWS GovCloud (US) e também nas regiões da China. Para saber mais sobre como configurar e utilizar esse recurso, consulte a documentação oficial do AWS Organizations.

Fonte

AWS Organizations emits CloudTrail events for account membership changes (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-organizations-cloudtrail/)

O que mudou

A AWS anunciou que o Amazon EMR agora oferece suporte ao Apache Spark 4.0.2 em disponibilidade geral, contemplando os três modelos de implantação do serviço. A novidade traz um conjunto relevante de melhorias para quem trabalha com pipelines de dados, controle de acesso e aplicações em tempo real.

Principais capacidades do Spark 4.0.2 no EMR

Pipelines de dados com ANSI SQL

Uma das mudanças mais práticas é o suporte nativo ao ANSI SQL padrão, o que torna a engenharia de dados acessível a um público mais amplo. Com isso, não é mais necessário aprender a sintaxe específica do Spark para construir e manter pipelines — quem já conhece SQL consegue trabalhar de forma produtiva desde o início.

Suporte a dados semiestruturados com VARIANT

O Spark 4.0.2 introduz suporte nativo a JSON e outros dados semiestruturados por meio dos tipos de dados VARIANT. Isso oferece mais flexibilidade para lidar com formatos de dados variados, sem a necessidade de transformações complexas antes do processamento.

Controle de acesso granular (FGAC)

O Controle de Acesso Refinado (FGAC — Fine-Grained Access Control) agora pode ser aplicado tanto em operações de leitura quanto de escrita nas tabelas registradas no AWS Lake Formation, dentro dos jobs do Apache Spark. Isso permite definir permissões no nível de linha ou coluna, aumentando a precisão no controle de quem acessa o quê.

Apache Iceberg v3 para governança e conformidade

O suporte ao formato de tabela Apache Iceberg v3 complementa as capacidades de segurança ao oferecer garantias de transação mais robustas e rastreamento de linhagem de dados. O resultado são trilhas de auditoria adequadas para atender a exigências regulatórias e fortalecer os frameworks de conformidade e governança.

Streaming aprimorado para aplicações em tempo real

Os controles de streaming foram aprimorados para simplificar o gerenciamento de operações stateful complexas e melhorar o monitoramento. Isso permite colocar em produção aplicações em tempo real com mais agilidade — casos de uso como detecção de fraudes, personalização e outros cenários sensíveis ao tempo são diretamente beneficiados.

Disponibilidade e como começar

O Apache Spark 4.0.2 está disponível em todas as regiões onde o Amazon EMR já opera. Para quem está migrando a partir de uma versão anterior, a AWS disponibiliza o agente de atualização do Apache Spark, uma ferramenta que acelera o processo de upgrade de aplicações EMR existentes.

Para criar uma nova aplicação EMR com Spark 4.0.2, basta acessar o Console de Gerenciamento da AWS e seguir o fluxo padrão de criação.

Fonte

Amazon EMR now supports Apache Spark 4.0.2 in general availability (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-emr-apache-spark/)

O que mudou no Amazon VPC IPAM

A AWS expandiu as capacidades do Amazon VPC IPAM — Gerenciador de Endereços IP de Nuvem Privada Virtual (VPC) com uma novidade bastante aguardada por equipes de rede: agora é possível aplicar tags diretamente nas alocações de pools IPAM. Isso coloca o gerenciamento de endereços IP no mesmo nível de governança que outros recursos AWS já oferecem há anos.

Para quem ainda não conhece o serviço: o Amazon VPC IPAM é a solução da AWS para planejar, rastrear e monitorar endereços IP em ambientes AWS. Em cenários com múltiplas contas e regiões, controlar quem usa qual faixa de IP pode se tornar um verdadeiro desafio — e é exatamente aí que esse novo suporte a tags faz diferença.

O que é possível fazer agora

Com a atualização, as equipes passam a ter duas formas de trabalhar com tags nas alocações:

• Adicionar tags no momento da criação de uma nova alocação de pool IPAM.
• Incluir tags em alocações já existentes, sem precisar recriar nada.

Essas tags podem ser referenciadas diretamente em políticas do AWS IAM — Gerenciamento de Identidade e Acesso (IAM) e em SCPs — Políticas de Controle de Serviço (SCP), o que abre caminho para uma governança centralizada e em escala sobre o uso de endereços IP na organização.

Exemplo prático de uso

A AWS ilustra bem o potencial da funcionalidade com um cenário direto: um administrador de rede pode marcar as alocações por ambiente — produção, desenvolvimento, homologação — e, a partir daí, criar uma política IAM que restrinja cada equipe ao pool correspondente. Assim, apenas a role de rede de produção consegue alocar endereços do pool de produção, enquanto times de desenvolvimento ficam limitados aos pools de desenvolvimento. Simples, auditável e seguro.

Além do controle de acesso, as tags também facilitam a localização de faixas de IP específicas. É possível buscar e filtrar alocações por tag em todos os pools IPAM, o que acelera muito o trabalho em ambientes grandes com múltiplas contas.

Disponibilidade e custo

O suporte a tags em alocações de pools IPAM está disponível em todas as regiões AWS onde o IPAM já opera, sem nenhum custo adicional.

Para se aprofundar no tema, a AWS disponibiliza o Guia do Usuário do IPAM. Quem quiser colocar a mão na massa pode acessar diretamente o console do IPAM para começar.

Fonte

Amazon VPC IPAM now supports tags on IPAM pool allocations (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-vpc-ipam-tags/)

Ataques recentes à cadeia de suprimentos e por que isso importa

Desde setembro, diversos ataques notáveis à cadeia de suprimentos de software foram registrados no npm Registry: Shai-Hulud, Chalk/Debug, um abuso de tokens do tea.xyz e, mais recentemente, o axios. Graças a esforços da comunidade envolvendo a equipe do Amazon Inspector, a Open Source Security Foundation e outros colaboradores, os pacotes afetados foram rapidamente identificados, reduzindo o impacto desses incidentes.

Ataques como o Shai-Hulud exploram vulnerabilidades em duas frentes: contas de mantenedores comprometidas que publicam pacotes maliciosos e ambientes de consumidores que baixam e executam esses pacotes. O ataque Shai-Hulud teve sucesso porque credenciais de mantenedores foram comprometidas via phishing, permitindo que agentes de ameaça publicassem versões maliciosas de pacotes populares.

Incidentes como esses reforçam a necessidade de práticas de segurança robustas na cadeia de suprimentos de software. A defesa eficaz exige abordar ambos os lados: mantenedores de pacotes precisam de proteções que previnam comprometimento de contas e limitem a propagação quando credenciais são roubadas; consumidores de pacotes precisam de defesas em camadas que detectem pacotes maliciosos, impeçam sua implantação e limitem danos quando um comprometimento ocorre.

A AWS publicou um guia detalhado com boas práticas focadas em consumidores de pacotes, alinhadas ao AWS Well-Architected Framework – Pilar de Segurança. Vamos explorar essas práticas nesta releitura.

Usar credenciais temporárias e conceder privilégio mínimo

Quando o Shai-Hulud foi executado em ambientes de desenvolvimento e pipelines de Integração e Entrega Contínua (CI/CD), ele escaneou segredos como tokens npm, tokens GitHub e chaves de acesso do AWS Identity and Access Management (IAM). Credenciais de longa duração expostas dessa forma permitiram que agentes de ameaça propagassem o malware e acessassem recursos em nuvem.

Incidentes recentes mostraram organizações descobrindo múltiplos pares de credenciais IAM vazados, com preocupações sobre credenciais adicionais expostas e potencial comprometimento de pipelines CI/CD.

A remoção de credenciais de longa duração dos ambientes de desenvolvimento e pipelines CI/CD reduz o escopo de exposição caso um sistema seja comprometido. Para desenvolvedores trabalhando localmente, o novo comando de login da AWS CLI (aws login) simplifica a aquisição de credenciais CLI de curta duração e elimina a necessidade de armazenar credenciais de longa duração em arquivos de configuração. O AWS IAM Identity Center também oferece uma forma direta de adquirir credenciais temporárias que expiram automaticamente.

Para pipelines CI/CD, a federação via OpenID Connect (OIDC) com GitHub Actions, GitLab CI ou outras plataformas fornece credenciais temporárias para cada job sem armazenar tokens de longa duração. O IAM também pode federar identidades AWS para serviços externos, permitindo que workloads na AWS acessem serviços externos de forma segura sem credenciais de longo prazo.

Credenciais temporárias expiram automaticamente, limitando a janela de exposição caso um pipeline seja comprometido. Para serviços de terceiros que não suportam credenciais temporárias, a recomendação é armazenar as credenciais em um serviço centralizado como o AWS Secrets Manager ou o AWS Systems Manager Parameter Store, limitando o acesso a esses segredos, exigindo credenciais temporárias e aplicando rotação automática com registro de auditoria.

Resumo das recomendações para reduzir risco de exposição de credenciais

• Usar credenciais temporárias: Federar usuários de um provedor de identidade central para a AWS e usar IAM roles para acesso. SEC02-BP02: Usar credenciais temporárias.
• Conceder privilégio mínimo: Atribuir apenas as permissões mínimas necessárias e usar elevação temporária de permissões quando necessário. SEC03-BP02: Conceder acesso com privilégio mínimo.
• Auditar e rotacionar credenciais de longa duração quando necessárias para casos de uso específicos. SEC02-BP05: Auditar e rotacionar credenciais periodicamente.

Em caso de incidente de segurança onde credenciais possam ter sido expostas, a orientação é rotacionar imediatamente todas as credenciais de longa duração. Utilizar o Amazon GuardDuty e o AWS CloudTrail para detectar atividade IAM anômala e identificar quais credenciais podem ter sido comprometidas.

Implementar defesa em profundidade

Mesmo com credenciais temporárias e privilégio mínimo, uma única conta comprometida pode permitir que agentes de ameaça publiquem pacotes maliciosos ou acessem recursos sensíveis. A defesa em profundidade cria múltiplas camadas de proteção que trabalham juntas para prevenir a propagação após o comprometimento inicial.

O princípio-chave é garantir que, se uma credencial ou conta for comprometida, controles adicionais impeçam que esse comprometimento se espalhe pela organização. Isso inclui Autenticação Multifator (MFA) para acesso combinada com diferentes IAM roles para workloads sensíveis.

Para projetos open source de desenvolvedor único, o MFA se torna ainda mais crítico porque não há separação de funções através de múltiplos mantenedores. Em ambientes de equipe, exigir múltiplos aprovadores para liberar pacotes para produção cria separação de funções. A aprovação multi-parte deve ser implementada dentro do próprio pipeline para implantações sensíveis — garantindo que mesmo se credenciais de um desenvolvedor forem comprometidas e ele disparar um deploy, o pipeline exija aprovação adicional antes de liberar para produção.

Para consumidores de pacotes, fluxos de aprovação múltipla em pipelines de implantação ajudam a garantir que, se um pacote malicioso passar pela varredura inicial, a revisão humana possa identificar mudanças suspeitas antes da implantação em produção.

Assinatura de artefatos como parte da defesa em profundidade

A assinatura de artefatos fornece uma camada criptográfica complementar que funciona junto com os controles de processo. O ataque Shai-Hulud teve sucesso porque credenciais comprometidas de mantenedores permitiram publicar pacotes maliciosos diretamente no registro npm público. Para consumidores de pacotes, a defesa é garantir que pacotes obtidos de registros públicos não alcancem produção sem verificação.

Ao vincular criptograficamente um pacote ou imagem de contêiner à identidade que o produziu, a assinatura cria uma camada de verificação independente da credencial usada para disparar o build — significando que uma credencial de desenvolvedor comprometida sozinha não é suficiente para introduzir um artefato não verificado no pipeline de implantação.

O AWS Signer fornece assinatura criptográfica para pacotes, criando uma camada adicional de verificação. O modelo de autorização de assinatura separa responsabilidades: credenciais de desenvolvedor não devem ter permissões de assinatura. Apenas roles de pipeline CI/CD devem ter permissões de assinatura através da API signer:StartSigningJob. O Signer usa Módulos de Segurança de Hardware (HSMs) validados FIPS 140-3 Nível 3 para armazenar chaves de assinatura.

O fluxo de assinatura de imagens de contêiner funciona da seguinte forma:

• O desenvolvedor ou pipeline CI/CD constrói uma imagem de contêiner e envia para o Amazon Elastic Container Registry (Amazon ECR)
• Com a assinatura gerenciada do Amazon ECR (nova funcionalidade), o ECR dispara automaticamente a assinatura quando a imagem é enviada
• O Amazon ECR chama o Signer com o digest da imagem e o perfil de assinatura
• O Signer verifica as permissões do perfil e assina o digest usando chaves armazenadas em HSMs validados FIPS 140-3 Nível 3
• A assinatura é armazenada junto à imagem no Amazon ECR usando formato de artefato OCI (Open Container Initiative)
• No momento da implantação, controladores de admissão (Kyverno para Amazon EKS, lifecycle hooks para Amazon ECS) verificam assinaturas antes de permitir a implantação

Os benefícios do Signer em comparação com a construção de infraestrutura de assinatura personalizada incluem:

• Totalmente gerenciado: Sem necessidade de construir infraestrutura customizada ou gerenciar ciclo de vida de certificados
• Automatizado: A assinatura gerenciada do ECR acontece automaticamente no push da imagem sem etapas manuais
• Governança centralizada: Um único perfil de assinatura pode ser usado em múltiplas contas e pipelines
• Integração nativa: Integração com Notation e Kyverno para verificação de assinatura no Amazon EKS
• Conformidade FIPS 140-3 Nível 3: Atende requisitos regulatórios rigorosos para operações criptográficas

O registro de auditoria para todas as operações de assinatura permite detectar padrões incomuns, como assinatura a partir de novos endereços IP, horários incomuns ou sucessão rápida de jobs de assinatura.

Centralizar o gerenciamento de dependências

Ao centralizar o gerenciamento de pacotes e dependências, é possível validar e aprovar dependências antes de serem usadas em aplicações e auditar rapidamente dependências em caso de incidente de segurança na cadeia de suprimentos.

Na AWS, o AWS CodeArtifact permite hospedar e gerenciar os pacotes de software da organização. A configuração de grupos de pacotes permite definir uma lista aprovada de fontes upstream e bloquear acesso a todas as outras — um controle direto contra ataques de typosquatting, onde pacotes maliciosos são publicados com nomes que se assemelham a pacotes legítimos. Em vez de depender dos desenvolvedores para identificar nomes suspeitos na hora da instalação, a configuração de grupo de pacotes impõe a barreira no nível do repositório.

A centralização também permite fixar versões de dependências para evitar que atualizações automáticas puxem versões maliciosas, e remover rapidamente dependências comprometidas em todo o portfólio de software quando um incidente ocorre.

Para imagens de contêiner, o Amazon ECR fornece armazenamento centralizado de imagens com criptografia via AWS Key Management Service (AWS KMS) e políticas de ciclo de vida. Combinado com a varredura do Amazon Inspector, é possível validar continuamente a integridade das imagens. Para orientações adicionais: SEC11-BP05: Centralizar serviços para pacotes e dependências.

Atestação de proveniência do npm

Para pacotes npm especificamente, as atestações de proveniência fornecem um controle complementar no lado do consumidor. Disponíveis desde o npm 9.5, as atestações vinculam um pacote publicado ao repositório de código-fonte específico e ao fluxo CI/CD que o produziu, usando Sigstore como infraestrutura de assinatura subjacente. Quando um pacote é instalado, a CLI do npm pode verificar que o artefato publicado corresponde à proveniência de build atestada.

Mantenedores de pacotes publicando no npm podem habilitar a proveniência executando npm publish com a flag --provenance a partir de um ambiente CI/CD suportado como GitHub Actions. Para orientações adicionais: SEC11-BP06: Implantar software programaticamente e DL.CS.2: Assinar artefatos de código após cada build.

Escanear dependências ao longo do ciclo de vida de desenvolvimento

A AWS disponibiliza serviços para escanear dependências continuamente, do desenvolvimento à implantação:

• No desenvolvimento: O Kiro pode realizar análise de composição de software durante revisões de código para identificar código de terceiros vulnerável.
• Em repositórios de código e pipelines: O Amazon Inspector escaneia código próprio, dependências de terceiros e Infraestrutura como Código (IaC) em busca de vulnerabilidades.
• Para imagens de contêiner: O Amazon Inspector fornece varredura contínua de vulnerabilidades em imagens no Amazon ECR. Também pode ser integrado diretamente em pipelines CI/CD para escanear imagens antes de serem enviadas ao ECR ou implantadas.

Scanners de vulnerabilidade tradicionais focam em CVEs conhecidos — vulnerabilidades divulgadas publicamente com identificadores atribuídos. Ataques à cadeia de suprimentos como o Shai-Hulud envolvem pacotes maliciosos que funcionam como zero-days: são intencionalmente criados por agentes de ameaça e explorados ativamente antes de um CVE ser atribuído. Scanners tradicionais baseados em bancos de dados de CVE não detectarão esses pacotes até que sejam formalmente identificados e catalogados, o que pode levar dias ou semanas.

Detectar essas ameaças requer análise comportamental em escala e colaboração da comunidade, não apenas correspondência estática de assinaturas. A escala operacional da AWS — com inteligência de ameaças de fontes como MadPot e dados de resposta a incidentes de milhões de clientes — permite a detecção de comportamento suspeito de pacotes em múltiplos ambientes simultaneamente.

Quando um pacote recém-publicado exibe comportamento de coleta de credenciais em múltiplas contas de clientes em poucas horas após a publicação, esse sinal entre contas permite identificação rápida. Essas descobertas são contribuídas para bancos de dados mantidos pela comunidade como o OpenSSF Malicious Packages Repository, que atribui um identificador formal (MAL-ID) e o compartilha com a comunidade de segurança. Para a campanha de token farming do tea.xyz, o tempo médio entre submissão e identificação formal foi de aproximadamente 30 minutos.

Um modelo de ameaça relacionado importante é o pacote “dorminhoco” (sleeper package): um pacote que aparenta ser benigno na publicação e ativa comportamento malicioso apenas após um atraso ou condição de gatilho. A análise estática sozinha é insuficiente para capturar esses pacotes porque o payload malicioso não está presente ou ativo no momento da instalação. A análise comportamental do Amazon Inspector é projetada especificamente para detectar essa classe de ameaça.

Listas de Materiais de Software (SBOMs) nos formatos SPDX ou CycloneDX permitem avaliar rapidamente a exposição durante incidentes. No incidente Shai-Hulud, os pacotes comprometidos (MAL-2025-46974 e CVE-2025-59144) foram identificados precocemente, fornecendo achados acionáveis para remediação rápida. Para orientações adicionais: SEC11-BP02: Automatizar testes ao longo do ciclo de vida de desenvolvimento e lançamento.

Configurar logging e monitoramento

A visibilidade sobre atividades é essencial para detectar comportamento anômalo precocemente. As recomendações incluem:

• Habilitar logging de aplicações e serviços
• Centralizar e monitorar logs entre contas
• Usar o GuardDuty para monitorar continuamente atividade maliciosa e chamadas de API anômalas
• Agregar achados com o AWS Security Hub e impor boas práticas de configuração com o AWS Config

O logging do CloudTrail fornece trilhas de auditoria para acesso a credenciais e atividade de API. Ao responder a incidentes de cadeia de suprimentos, deve-se revisar logs do CloudTrail para eventos específicos que indicam comprometimento de credenciais ou atividade maliciosa:

• Chamadas sts:AssumeRole de endereços IP ou regiões inesperadas
• Chamadas secretsmanager:GetSecretValue ou ssm:GetParameter de fontes desconhecidas
• Chamadas ecr:PutImage de estações de trabalho de desenvolvedores, contornando pipelines CI/CD
• Chamadas lambda:UpdateFunctionCode fora de janelas normais de implantação
• Chamadas iam:CreateAccessKey seguidas de atividade imediata de API
• Chamadas codecommit:GitPush ou codebuild:StartBuild de endereços IP incomuns

Quando combinado com regras do Amazon EventBridge, é possível disparar respostas automatizadas quando o Amazon Inspector detecta pacotes maliciosos ou quando esses padrões incomuns de acesso a credenciais ocorrem. Para orientações adicionais: SEC04: Detecção.

Boas práticas adicionais

O Pilar de Segurança do Well-Architected Framework também fornece boas práticas organizacionais aplicáveis à melhoria de processos de segurança em todas as dimensões da organização. Práticas relevantes incluem: SEC11-BP01: Treinar para segurança de aplicações; SEC11-BP08: Construir um programa que incorpore ownership de segurança em equipes de workload; e SEC10: Resposta a Incidentes.

Conclusão

Incidentes recentes como Shai-Hulud, Chalk/Debug e tea.xyz refletem esforços contínuos de agentes de ameaça para atacar registros de pacotes, pipelines CI/CD e credenciais de desenvolvedores visando maior superfície de ataque e propagação. Uma única conta de mantenedor comprometida ou pacote malicioso pode se propagar simultaneamente em milhares de ambientes de consumidores.

Os controles descritos neste artigo foram projetados com esse modelo de ameaça em mente: credenciais temporárias limitam o valor de tokens roubados; gerenciamento centralizado de dependências e bloqueio de upstream reduzem a superfície de ataque no nível do registro; assinatura de artefatos garante que mesmo se um pipeline de build for comprometido, artefatos não assinados não alcancem produção; e varredura de dependências ao longo do ciclo de vida do software ajuda a identificar pacotes comprometidos precocemente. Cada camada estreita a janela de oportunidade para um agente de ameaça.

Para aprofundar

• Defending against supply chain attacks like Chalk/Debug and the Shai-Hulud worm
• Amazon Inspector detects over 150,000 malicious packages linked to token farming campaign
• What AWS Security learned from responding to recent npm supply chain threat campaigns
• Improve the security of your software supply chain with Amazon CodeArtifact package group configuration
• Hands-on Workshop: Enhancing Supply Chain Security

Fonte

Well-architected best practices for software supply chain security (https://aws.amazon.com/blogs/security/well-architected-best-practices-for-software-supply-chain-security/)

O que é o AWS CIRT?

A Amazon Web Services (AWS) mantém um time global especializado em resposta a incidentes de segurança chamado AWS CIRT — sigla para Customer Incident Response Team (Equipe de Resposta a Incidentes de Clientes). Esse time opera 24 horas por dia, 7 dias por semana, e é composto por engenheiros de segurança que atuam diretamente em eventos ativos nos ambientes dos clientes.

É importante entender o escopo de atuação do AWS CIRT dentro do Modelo de Responsabilidade Compartilhada da AWS: o time foca no lado do cliente — ou seja, na segurança dentro da nuvem, não na infraestrutura física gerenciada pela própria AWS. Quando um cliente enfrenta acesso não autorizado, exfiltração de dados ou ransomware em seu ambiente AWS, é exatamente aí que o CIRT entra em ação.

Como acionar o suporte em caso de incidente ativo

Se você está passando por um evento de segurança ativo agora, o caminho mais direto é abrir um chamado de suporte. Veja como fazer isso corretamente:

• Abra um chamado de suporte AWS a partir da conta afetada, acessando o Console do AWS Support Center.
• Selecione o serviço mais relacionado ao incidente — por exemplo, Amazon Elastic Compute Cloud (Amazon EC2), AWS Identity and Access Management (IAM) ou Amazon Simple Storage Service (Amazon S3).
• Deixe claro na descrição do chamado que se trata de um incidente de segurança urgente.

Abrir o chamado a partir da conta comprometida permite que a AWS confirme a titularidade da conta e gere um número de acompanhamento. Se você tiver um time de conta (TAM, Account Manager ou Solutions Architect), pode acionar essa equipe para iniciar uma escalada. E caso tenha perdido o acesso à sua conta, ainda é possível enviar uma solicitação de assistência por outro canal.

O que o AWS CIRT faz durante um engajamento

Durante um atendimento, o AWS CIRT concentra sua análise nos logs de serviços AWS e no plano de controle da nuvem. As principais fontes utilizadas são AWS CloudTrail, Amazon VPC Flow Logs e findings do Amazon GuardDuty. A partir dessas fontes, o time realiza triagem, análise e contenção do incidente, além de oferecer recomendações para evitar recorrências.

Vale destacar um ponto importante: para investigações que vão além do plano de controle AWS — como análise de sistema operacional, memória ou revisão de código de aplicação — a recomendação é complementar o suporte do CIRT com um parceiro especializado da AWS em forense digital e resposta a incidentes (DFIR).

Catálogo de Técnicas de Ameaças para AWS (TTC)

Um dos recursos mais valiosos desenvolvidos pelo AWS CIRT é o Threat Technique Catalog for AWS (TTC) — Catálogo de Técnicas de Ameaças para AWS. O TTC nasceu como uma referência interna: o time precisava registrar e compartilhar os padrões que se repetiam entre os engajamentos, evitando que a mesma análise fosse refeita do zero a cada novo caso. Com o tempo, ficou evidente que esse conhecimento seria valioso para todos os clientes, e o catálogo foi tornado público.

O TTC é baseado na MITRE ATT&CK Cloud Matrix e documenta táticas, técnicas e procedimentos (TTPs) de agentes de ameaça específicos para ambientes AWS, com orientações de detecção e mitigação para cada entrada. É possível filtrar por serviços AWS presentes no seu ambiente para focar no que é mais relevante para a sua realidade. As descobertas do TTC também alimentam a lógica de detecção de serviços como o Amazon GuardDuty, fortalecendo as proteções automatizadas dos clientes.

Ferramentas open source disponibilizadas pelo CIRT

Além do catálogo de ameaças, o AWS CIRT abriu o código de diversas ferramentas desenvolvidas internamente para resolver problemas recorrentes nos engajamentos. Essas ferramentas complementam — e não substituem — o conjunto de segurança já existente no seu ambiente. Para uma visão abrangente de como estruturar um programa de resposta a incidentes, o ponto de partida recomendado é o Guia de Resposta a Incidentes de Segurança da AWS.

• AWS Customer Playbook Framework: frameworks de resposta baseados nas lições aprendidas pelo CIRT em eventos reais de segurança.
• Assisted Log Enabler: ferramenta que auxilia na habilitação de logs essenciais, incluindo Amazon VPC Flow Logs, AWS CloudTrail, logs de auditoria do Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Route 53 Resolver Query Logs, logs de acesso do Amazon Simple Storage Service (Amazon S3) e logs do Elastic Load Balancing.
• AWS CloudSaga: ferramenta para testar controles e alertas de segurança no ambiente AWS, simulando eventos baseados em cenários reais observados pelo CIRT.
• Athena Security Analytics Bootstrap: solução para quem precisa configurar rapidamente o Amazon Athena e realizar investigações sobre logs de serviços AWS armazenados em buckets S3.

Workshops práticos abertos ao público

O AWS CIRT também mantém cinco workshops públicos, atualizados regularmente para simular eventos de segurança atuais. Os temas cobertos são: uso não autorizado de credenciais IAM, ransomware no Amazon S3, cryptomining, SSRF no IMDSv1 e ferramentas de preparação para resposta a incidentes.

Para participar, basta ter uma conta AWS e conexão com a internet. Os workshops são construídos com base nos mesmos cenários que o time usa internamente para treinamento — a ideia é tornar esse aprendizado acessível para qualquer profissional que queira se preparar melhor para resposta a incidentes na nuvem.

Como entrar em contato com o AWS CIRT

Qualquer cliente AWS pode acionar o CIRT por meio de um chamado de suporte, independentemente do plano contratado. Clientes que possuem um time de conta dedicado também podem iniciar uma escalada diretamente por esse canal. Para clientes com Enterprise Support ou Unified Operations, há ainda a opção de contratar o AWS Security Incident Response, um serviço gerenciado voltado para triagem e resposta a eventos de segurança.

Para feedbacks ou dúvidas, o CIRT pode ser contactado pelo e-mail aws-cirt@amazon.com. Por fim, recomenda-se também assinar os AWS Security Bulletins via feed RSS para receber notificações sobre eventos de segurança nos serviços AWS.

Fonte

Welcoming the AWS Customer Incident Response Team (https://aws.amazon.com/blogs/security/welcoming-the-aws-customer-incident-response-team/)

O que foi anunciado

A AWS anunciou a expansão do Amazon GuardDuty Malware Protection for AWS Backup com suporte a backups contínuos do Amazon S3. Com essa novidade, equipes de segurança e operações podem escanear backups contínuos do S3 em busca de malware e identificar, ao longo de toda a linha do tempo de backup, quais pontos estão limpos e seguros para uma eventual recuperação.

O que muda na prática

Antes dessa atualização, a proteção contra malware do GuardDuty para o AWS Backup não alcançava os backups contínuos do S3 — um tipo de backup que captura alterações de forma incremental e permite restaurar dados para qualquer ponto no tempo. Agora, essa lacuna foi preenchida.

Com o novo suporte, é possível:

• Habilitar varreduras completas ou incrementais de malware para backups contínuos do S3 diretamente dentro do plano de backup;
• Executar varreduras sob demanda até qualquer ponto de restauração disponível;
• Consultar o status da varredura em qualquer ponto da linha do tempo do backup contínuo por meio da nova API GetPITRMalwareScanResults — o que permite verificar se um determinado momento de recuperação está livre de ameaças antes de iniciar a restauração.

Por que isso importa

Backups contínuos são amplamente usados por equipes que precisam de baixa tolerância à perda de dados. O problema é que, sem verificação de integridade contra malware, um backup contínuo pode estar preservando arquivos comprometidos — e uma restauração a partir desse ponto poderia reintroduzir a ameaça no ambiente. Com essa integração, é possível garantir que o ponto de restauração escolhido é realmente seguro antes de acionar qualquer processo de recuperação.

Disponibilidade

O suporte a backups contínuos do S3 está disponível em todas as regiões da AWS onde o Amazon GuardDuty Malware Protection for AWS Backup já era suportado. Para começar a usar, basta acessar o console do AWS Backup, ou utilizar a API ou a Interface de Linha de Comando (CLI). Para mais detalhes técnicos, a AWS disponibiliza a documentação do AWS Backup e a documentação do Amazon GuardDuty Malware Protection.

Fonte

Amazon GuardDuty Malware Protection for AWS Backup supports Amazon S3 continuous backups (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-guardduty-aws-backup-s3-continuous/)

O que mudou no AWS Security Agent

A AWS anunciou uma atualização relevante para equipes de segurança: o AWS Security Agent agora gera automaticamente scripts de verificação para os achados de testes de penetração (pentest). A novidade simplifica um processo que, até então, exigia trabalho manual considerável.

Como era o processo antes

Anteriormente, quando um teste de penetração identificava uma vulnerabilidade, as equipes de segurança precisavam seguir manualmente os passos descritos nos detalhes do achado para conseguir reproduzir e validar o problema encontrado. Esse processo era demorado e suscetível a erros humanos, especialmente em ambientes com muitos achados para triar.

O que o AWS Security Agent oferece agora

Com a atualização, o serviço passa a gerar automaticamente scripts prontos para execução para cada achado confirmado durante o pentest. O fluxo de trabalho fica assim:

• A equipe faz o download do script gerado pelo serviço;
• Configura as variáveis de ambiente necessárias;
• Executa o script contra o sistema-alvo para verificar a vulnerabilidade.

Cada script gerado acompanha instruções de configuração, documentação das variáveis de ambiente utilizadas e valores sensíveis já redigidos (ocultados) para maior segurança no compartilhamento e na execução.

Por que isso importa para equipes de segurança

A geração automática de scripts de verificação traz dois ganhos práticos diretos: agiliza a triagem dos achados e acelera o processo de remediação. Em vez de interpretar e replicar manualmente cada passo de reprodução, a equipe pode validar a vulnerabilidade de forma padronizada e repetível, com muito menos atrito operacional.

Disponibilidade e como começar

O recurso está disponível em todas as regiões da AWS onde o AWS Security Agent já é suportado. Para utilizá-lo, basta executar um teste de penetração pelo serviço, navegar até os achados e expandir a seção Verification Script no achado desejado.

Para se aprofundar, a AWS disponibiliza documentação detalhada: Revisar achados de um teste de penetração no Guia do Usuário do AWS Security Agent.

Fonte

AWS Security Agent adds verification scripts for pentest findings (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-agent/)