Blog

A Responsabilidade Compartilhada pela Segurança Digital na Europa

As tecnologias digitais transformaram profundamente a sociedade, governos, empresas e vida cotidiana ao longo das últimas décadas. Porém, essa crescente dependência da tecnologia carrega consigo uma responsabilidade ampla: garantir que a segurança permaneça robusta e inabalável, independentemente do caso de uso. A AWS reconhece essa responsabilidade como um princípio fundamental, onde cada colaborador contribui para que a segurança seja integrada em todas as dimensões do negócio.

Esse compromisso posiciona a AWS de forma estratégica enquanto o cenário regulatório de cibersegurança continua evoluindo na Europa. Um exemplo expressivo dessa evolução é a Diretiva sobre Medidas para um Nível Comum Elevado de Cibersegurança em toda a União (Diretiva NIS 2), formalmente adotada pelo Parlamento Europeu e Conselho da UE como Diretiva (UE) 2022/2555 e aplicável desde outubro de 2024.

Até dezembro de 2025, a maioria dos Estados-Membros da UE transpôs a NIS 2 para legislação nacional, embora os cronogramas de implementação completa se estendam até 2025–2026 em várias jurisdições. Os requisitos e prazos de transposição variam entre os países europeus, com o objetivo comum de fortalecer a postura de cibersegurança em todo o continente.

Conformidade com a Diretiva NIS 2

A NIS 2 busca garantir que as entidades mitiguem os riscos impostos por ameaças cibernéticas, minimizem o impacto de incidentes e protejam a continuidade de serviços essenciais e importantes na UE. A diretiva estabelece um marco fortalecido em nível europeu, impondo obrigações proporcionais e baseadas em risco para entidades essenciais e importantes em setores críticos.

O escopo de implementação é amplo: a NIS 2 obriga a adoção de medidas abrangentes, incluindo governança, gerenciamento de incidentes, continuidade de negócios, segurança da cadeia de suprimentos, controles de acesso e criptografia. Essas medidas devem cobrir todo o ciclo de vida da cibersegurança — identificação, proteção, detecção, resposta, recuperação e comunicação — com requisitos para testes regulares, gerenciamento de riscos da cadeia de suprimentos e comunicação de incidentes significativos às autoridades nacionais.

Infraestrutura Crítica e Certificações Regionais

Em vários países europeus, os serviços da AWS já fazem parte da infraestrutura crítica nacional. Na Alemanha, por exemplo, o Amazon EC2 e o Amazon CloudFront estão no escopo da regulação KRITIS (Kritische Infrastruktur — Infraestrutura Crítica). Por vários anos, a AWS vem cumprindo suas obrigações de segurança, conduzindo auditorias relacionadas à infraestrutura crítica nacional e mantendo canais estabelecidos de troca de informações de segurança com o BSI (Bundesamt für Sicherheit in der Informationstechnik — Escritório Federal Alemão de Segurança da Informação).

A empresa também participa da iniciativa UP KRITIS, um esforço cooperativo entre indústria e governo alemão para estabelecer padrões do setor. Essa colaboração demonstra o compromisso em trabalhar com autoridades locais para elevar o padrão de segurança.

Além da infraestrutura crítica, a AWS conquistou múltiplas certificações regionais que validam seu desempenho em segurança:

• C5 – na Alemanha, oferece um marco de controle abrangente para estabelecer e evidenciar a segurança de operações em nuvem
• ENS High – na Espanha, compreende princípios para proteção adequada aplicáveis a agências governamentais e organizações públicas
• HDS – na França, demonstra um marco adequado de medidas técnicas e de governança para proteger dados de saúde pessoal
• Pinakes – na Espanha, oferece um marco de avaliação para gerenciar e monitorar controles de cibersegurança de provedores de serviços

Modelo de Responsabilidade Compartilhada e Conformidade

A AWS oferece mais de 150 certificações e atestados de conformidade independentemente auditadas em segurança, incluindo ISO 27001, ISO 22301, ISO 20000, ISO 27017 e SOC 2 (Controles de Sistemas e Organizações). Essas certificações reforçam que a segurança e conformidade são responsabilidades compartilhadas entre a plataforma e os clientes.

A AWS garante que a infraestrutura de nuvem esteja em conformidade com requisitos regulatórios aplicáveis e boas práticas de provedores de nuvem. Os clientes, por sua vez, mantêm responsabilidade por construir workloads conformes na nuvem. O Modelo de Responsabilidade Compartilhada da AWS detalha essa divisão clara de obrigações.

Segurança por Design e Frameworks de Arquitetura

Para a segurança na nuvem, é crucial que os clientes façam da segurança por design e segurança por padrão os pilares centrais do desenvolvimento de produtos. A AWS disponibiliza o AWS Well-Architected Framework para ajudar a construir infraestrutura segura, de alto desempenho, resiliente e eficiente para diversas aplicações e workloads.

Clientes que utilizam o AWS Cloud Adoption Framework (AWS CAF) podem melhorar a prontidão para nuvem identificando e priorizando oportunidades de transformação. Esses recursos fundamentais apoiam a segurança de workloads regulados.

Ferramentas de Gestão de Riscos e Conformidade

No que diz respeito às medidas de gerenciamento de riscos de cibersegurança e obrigações de comunicação que a NIS 2 estabelece, ofertas de serviços existentes da AWS podem ajudar clientes a cumprir sua parte do modelo de responsabilidade compartilhada.

Monitoramento, Auditoria e Avaliação

• AWS CloudTrail fornece registro de auditoria centralizado de todas as ações na plataforma
• Amazon CloudWatch oferece métricas, alarmes e análise de logs de aplicação em tempo real
• AWS Config permite que clientes avaliem, auditem e avaliem continuamente as configurações e relacionamentos de recursos selecionados na AWS, localmente e em outras nuvens
• AWS Security Hub oferece uma visão abrangente do estado de segurança na AWS e ajuda a avaliar ambientes contra padrões do setor e boas práticas

Automação de Evidências e Resiliência

• AWS Audit Manager automatiza a coleta de evidências para demonstração de conformidade
• AWS Resilience Hub realiza avaliações de resiliência para garantir continuidade operacional

A AWS disponibiliza ainda AWS Whitepapers abrangentes, como o Guia de Resposta a Incidentes de Segurança da AWS, para que clientes entendam, implementem e gerenciem conceitos fundamentais de segurança em suas arquiteturas em nuvem.

Guia Atualizado de Considerações NIS 2

O guia atualizado de Considerações NIS 2 para Clientes da AWS (dezembro de 2025) apresenta uma tabela de mapeamento que conecta os requisitos do Anexo da diretiva a capacidades específicas da AWS, permitindo que entidades interpretem obrigações e implementem controles proporcionais de forma eficiente.

Treinamento e Conscientização em Cibersegurança

A NIS 2 determina o desenvolvimento e implementação de programas abrangentes de conscientização em cibersegurança para corpos diretivos e funcionários. A AWS oferece diversos programas de treinamento sem custo ao público para aumentar a conscientização sobre segurança cibernética, como o AWS Security Learning Hub, que inclui simulações de phishing, fundamentos de segurança em nuvem e módulos baseados em função.

Clientes podem entregar treinamento em toda a organização utilizando módulos do AWS Skill Builder sobre phishing, higiene cibernética e práticas seguras em nuvem, atribuindo caminhos específicos por função e rastreando conclusão em múltiplas contas através do AWS Organizations.

Cooperação com Autoridades e Agências de Segurança

A Amazon se esforça por ser a empresa mais centrada no cliente do mundo. Para a AWS Security Assurance, isso significa manter equipes que se envolvem continuamente com autoridades para compreender e superar obrigações regulatórias e de clientes. Essa abordagem representa uma forma de elevar o padrão de segurança na Europa.

A AWS coopera com agências de cibersegurança globais, reconhecendo a importância de seu papel em manter o mundo seguro. Para isso, desenvolveu o AWS Global Cloud Security Program (GCSP) para fornecer às agências uma linha direta e consistente de comunicação com o time de segurança da AWS.

Parcerias Regionais Estratégicas

Dois exemplos de membros do GCSP incluem:

• O Dutch National Cyber Security Centrum (NCSC-NL), com quem a AWS assinou acordo de cooperação em maio de 2023
• A Agência Nacional de Cibersegurança Italiana (ACN)

Na Espanha, a AWS assinou um acordo de colaboração estratégica (MoU) com o Centro Nacional de Inteligência e Centro Nacional de Criptologia (CNI-CCN) em agosto de 2023 para promover cibersegurança e inovação no setor público através da tecnologia AWS Cloud. Como resultado, o CCN aderiu ao GCSP e a parceria produziu oito guias STIC (Série 887) sobre tópicos como endurecimento, resposta a incidentes e monitoramento para ambientes multi-nuvem e híbridos.

A parceria também gerou o template ENS Landing Zone (CCN-STIC-887 Anexo A), que clientes podem baixar do site do CCN para implantar ambientes em nuvem conformes com ENS. Além da acreditação ENS High, mais de 25 serviços de nuvem da AWS foram acreditados pelo CCN sob o Catálogo de Segurança de Produtos e Serviços para processar workloads sensíveis e classificadas na Espanha.

Contribuição em Contextos de Crise

Com a guerra na Ucrânia, a importância dessa colaboração se tornou evidente. A AWS desempenhou papel importante em ajudar o governo da Ucrânia a manter continuidade e fornecer serviços críticos aos cidadãos desde o início do conflito.

Próximos Passos para Organizações Europeia

A AWS continua fornecendo aos principais stakeholders maior clareza sobre como auxilia clientes a enfrentar seus desafios de cibersegurança mais complexos, oferecendo oportunidades para análises profundas sobre soluções em desenvolvimento.

O guia atualizado de Considerações NIS 2 para Clientes da AWS (dezembro de 2025) e o AWS Compliance Center servem como hubs centrais para recursos mais recentes, incluindo mapeamentos para Diretrizes Técnicas de Implementação da ENISA (26 de junho de 2025), whitepapers e documentação pronta para auditoria.

Entidades podem começar com AWS Control Tower ou Landing Zone Accelerator para estabelecer baselines de segurança, depois aplicar o Well-Architected Framework (Pilares de Segurança e Confiabilidade) para projetar arquiteturas auditáveis e resilientes.

Para organizações que buscam expertise externa, parceiros do AWS Marketplace oferecem suporte especializado em análise de lacunas, testes de resiliência e implementação de mapeamentos ENISA.

Fonte

Embracing our broad responsibility for securing digital infrastructure in the European Union (https://aws.amazon.com/blogs/security/embracing-our-broad-responsibility-for-securing-digital-infrastructure-in-the-european-union/)

O Desafio da Informação Fragmentada nas Empresas

Dentro das organizações modernas, os colaboradores enfrentam um problema recorrente: informações espalhadas por múltiplos sistemas, tornando difícil encontrar respostas rápidas e confiáveis. Ao invés de tomar decisões ágeis, equipes desperdiçam tempo precioso procurando dados relevantes em diferentes plataformas. A AWS Quick Suite propõe uma solução através de agentes de chat alimentados por inteligência artificial, capazes de consolidar e contextualizar essas informações de forma acessível.

A inovação apresentada não se limita a simplesmente conectar um chatbot genérico aos dados corporativos. A abordagem vai além: demonstra como transformar esses agentes em assistentes especializados que guiam usuários através de descoberta de recursos, análise de impacto e recomendações personalizadas — tudo mantendo segurança e conformidade empresarial.

Democratizando a Criação de Assistentes Inteligentes

Um dos principais benefícios dos agentes de chat do Quick Suite é a acessibilidade. Representantes de vendas, analistas e especialistas de domínio podem criar assistentes sofisticados sem necessidade de conhecimento profundo em machine learning ou infraestrutura em nuvem. A plataforma torna essas capacidades avançadas de IA disponíveis para usuários não técnicos de negócios.

O Quick Suite vem equipado com um agente de chat padrão do sistema chamado My Assistant. Administradores podem habilitar a capacidade de criar agentes de chat personalizados para os usuários. Muitos começam explorando o My Assistant, descobrindo suas capacidades através de experimentação prática.

Os usuários podem melhorar suas interações configurando contexto: apontando o agente para Spaces específicos para filtrar o escopo da conversa, garantindo que as respostas saiam de fontes organizacionais relevantes. Também é possível fazer upload de templates de resposta ou documentos de processo diretamente nas sessões de chat para modificar como o agente estrutura suas saídas.

Embora essas abordagens ofereçam valor imediato para tarefas isoladas, cada conversa requer configuração manual — seleção de Spaces corretos, upload de templates relevantes e instrução de contexto específico. Com agentes personalizados, essas práticas bem-sucedidas podem ser capturadas em soluções permanentes e compartilháveis. O conhecimento contextual e diretrizes comportamentais são preservados na persona do agente e empacotados em assistentes consistentes e reutilizáveis que equipes podem deployar em escala.

Os Três Pilares: Identidade, Instruções e Conhecimento

Agentes de chat eficazes são construídos sobre três componentes essenciais que trabalham em conjunto para criar assistentes de IA consistentes e confiáveis:

• Identidade — Define quem é o agente e qual papel ele serve
• Instruções — Especifica como o agente deve pensar e responder
• Conhecimento — Fornece a informação que o agente pode acessar para buscar respostas e geração de conteúdo

Compreender essas três camadas é crucial porque determinam o comportamento do agente, incluindo seu estilo de comunicação e as informações que consegue recuperar.

Identidade: Definindo o Papel do Agente

A identidade define quem o agente é e qual papel ele desempenha, moldando como ele responde a cada solicitação. Essa configuração é realizada através do campo de configuração de identidade do agente. Um agente bem definido em sua identidade comunica com autoridade apropriada e mantém coerência em suas respostas.

Instruções: Controle Granular Comportamental

As instruções funcionam como diretrizes comportamentais que fornecem controle granular sobre a geração de respostas do agente. Especificidade e consistência são cruciais para efetividade. Habilidades eficazes de prompt engineering tornam-se essenciais ao elaborar identidade e instruções, porque a precisão e clareza desses elementos impactam diretamente a capacidade do agente de entender contexto, seguir diretrizes comportamentais e manter respostas consistentes e orientadas por persona.

A configuração de instruções de persona, estilo de comunicação e documentos de referência permite definir o comportamento específico esperado. Documentos de referência referem-se a instruções mais específicas ou detalhadas, ou informações anexadas como arquivos que o agente deve sempre ter e seguir exatamente, como templates e documentos de processo.

Conhecimento: Fornecendo Contexto aos Modelos

Modelos de linguagem grandes (LLMs) alimentam os agentes. O agente de chat personalizado fornece contexto necessário aos LLMs através de dois meios distintos: instruções conforme discutido na seção anterior e conhecimento pesquisável. Quick Spaces fornece a capacidade de consolidar conhecimento pesquisável para o agente de chat em diferentes formas:

• Uploads diretos de arquivos (conhecimento indexado)
• Dashboards e tópicos do Amazon Quick Sight
• Bases de conhecimento criadas de integrações de acesso a dados (conhecimento indexado)
• Conectores de ação para executar ações em ferramentas terceirizadas integradas

Spaces funcionam como repositórios de conhecimento dinâmicos e pesquisáveis que facilitam acesso em tempo real às informações das equipes em forma estruturada ou não estruturada, mantendo limites de segurança e suportando fluxos colaborativos.

Caso Prático: O Quick Suite Product Specialist

Para ilustrar como esses princípios funcionam na prática, a AWS apresenta um exemplo: um agente personalizado que ajuda usuários a identificar as funcionalidades corretas do Quick Suite para suas necessidades específicas. O My Assistant pode responder questões gerais sobre Quick Suite; este agente especialista toma uma abordagem consultiva.

O agente está configurado para seguir uma metodologia em três fases: descoberta, análise e recomendações de solução. Isso demonstra como agentes de IA modernos devem equilibrar conhecimento abrangente de plataforma com sabedoria prática sobre dimensionamento de soluções.

A Estrutura de Três Fases

Descoberta: O agente inicia analisando os detalhes iniciais do caso de uso, depois faz perguntas esclarecedoras antes de qualquer recomendação. Busca entender escala, experiência do usuário com IA generativa, número potencial de usuários beneficiados, métricas disponíveis sobre o desafio e nível de prontidão técnica da equipe.

Análise: Com as informações coletadas, avalia potencial de impacto considerando o tamanho de usuários afetados e economia de tempo/esforço. Diferencia entre impacto baixo — onde soluções simples com prompts otimizados são apropriadas — e alto impacto, onde capacidades dedicadas e escaláveis se justificam.

Recomendações de Solução: Apresenta capacidades apropriadas do Quick Suite alinhadas com o tamanho de solução adequado ao impacto, incluindo análise custo-benefício e projeções de ROI em termos de economia de tempo multiplicada pelo número de usuários.

Implementação Prática

Pré-requisitos

Para construir um agente de chat personalizado no Quick Suite, são necessários:

• Uma instância ativa de Quick Suite
• Uma subscrição do Quick Suite para as capacidades requeridas: Professional — criar, configurar e compartilhar spaces e agentes de chat personalizados; ou Enterprise (inclui capacidades Professional) — criar bases de conhecimento

Para mais informações sobre os níveis de subscrição, consulte Amazon Quick Suite pricing.

Preparando o Conhecimento

O primeiro passo é configurar um Quick Space como componente contextual da fundação de três camadas. Este Space contém uma base de conhecimento pesquisável. A AWS oferece duas opções: usar um arquivo estático com documentação oficial do Quick Suite (que requer atualizações ocasionais) ou estabelecer uma base de conhecimento rastreada por web que mantém conexão direta com a documentação, refrescando automaticamente em cronograma padrão.

Configurando o Agente

Após criar o Space, o próximo passo é criar o agente personalizado. O processo envolve:

Definir identidade clara — quem é o agente e qual expertise possui. Para o exemplo do Product Specialist, a identidade descreve um especialista experiente em Quick Suite, evangelista de IA generativa e engenheiro de prompts proficiente, especializado em descoberta de casos de uso, análise de desafios e design de soluções.

Configurar instruções de persona detalhadas que guiem o comportamento do agente através das três fases. Estas instruções especificam exatamente como o agente deve abordar cada situação, quais informações coletar antes de recomendar, como analisar impacto e como estruturar recomendações.

Determinar tom e formato de resposta. O tom executivo, consultivo e entusiasmado sobre potencial de IA, combinado com um formato prescritivo durante fase de recomendações, garante que o agente comunique com clareza apropriada para diferentes públicos.

Vincular o Space contendo a base de conhecimento, permitindo que o agente verifique recomendações contra documentação atual do produto.

Opcionalmente, integrar conectores de ação para ferramentas de colaboração empresarial como Slack ou Teams, permitindo que o agente compartilhe recomendações diretamente com equipes.

Testando e Refinando o Agente

Após configuração e lançamento, o agente pode ser testado com solicitações reais. Por exemplo, pedindo ajuda com formatação de emails de status semanais, o agente responderia com um questionário de descoberta detalhado ao invés de pular direto para recomendações. As respostas podem variar entre execuções, refletindo a natureza dinâmica dos modelos de linguagem.

O usuário responde o questionário e recebe uma resposta abrangente incluindo avaliação de impacto, múltiplas recomendações com raciocínio fundamentado e opções de pathway implementação de alto nível. Iteração contínua com o agente fornece orientação detalhada.

Princípios Fundamentais Demonstrados

A exemplo do Quick Suite Product Specialist ilustra vários princípios críticos:

Especificidade impulsiona consistência. Ao invés de confiar que o LLM determinará a abordagem correta, é possível fornecer definições explícitas de identidade, restrições comportamentais, estruturas de decisão e formatos de saída, transformando IA genérica em assistentes confiáveis e especializados.

Estrutura previne falhas comuns. A metodologia de três fases — descoberta, análise, recomendações — demonstra como abordagens sistemáticas guiam usuários a dimensionar soluções adequadamente apenas após compreender profundamente o problema.

Conhecimento dinâmico mantém relevância. Vinculando documentação ao vivo e Spaces conscientes de permissões, assegura-se que agentes validem recomendações contra informações atuais enquanto respeitam limites organizacionais de segurança.

Conclusão

Agentes de chat personalizados no Quick Suite transformam como equipes acessam e utilizam conhecimento empresarial. Aplicando o framework de três camadas — identidade, instruções e conhecimento — é possível criar assistentes de IA que entregam respostas instantâneas e precisas enquanto mantêm segurança e conformidade corporativa.

A recomendação prática é começar com um caso de uso focado que demonstre ROI claro, então expandir conforme adoção cresce. Agentes personalizados entregam ganhos mensuráveis de produtividade, ajudando equipes encontrar informações mais rapidamente, automatizar fluxos repetitivos ou fornecer orientação de especialistas em escala.

Para aprender mais sobre criação e deployment de agentes de chat do Quick Suite, consulte Create, customize, and deploy AI-powered chat agents in Amazon Quick Suite.

Fonte

Create AI-powered chat assistants for your enterprise with Amazon Quick Suite (https://aws.amazon.com/blogs/machine-learning/create-ai-powered-chat-assistants-for-your-enterprise-with-amazon-quick-suite/)

Exploração Ativa em Poucas Horas

A descoberta de uma vulnerabilidade crítica no React Server Components gerou movimento rápido entre grupos de ciberameaças estado-patrocinados. Dentro de poucas horas após a divulgação pública da CVE-2025-55182 (React2Shell) em 3 de dezembro de 2025, as equipes de inteligência de ameaças da AWS identificaram tentativas de exploração ativa conduzidas por múltiplos grupos de ameaças de origem chinesa, incluindo Earth Lamia e Jackpot Panda.

Esta vulnerabilidade crítica em componentes React apresenta uma pontuação máxima no Sistema Comum de Pontuação de Vulnerabilidade (Commond Vulnerability Scoring System – CVSS) de 10.0, afetando React versões 19.x e Next.js versões 15.x e 16.x quando utilizam App Router. Embora esta vulnerabilidade não afete os serviços gerenciados da AWS, a empresa compartilhou esta inteligência de ameaças para auxiliar clientes que executam aplicações React ou Next.js em seus próprios ambientes a tomar ação imediata.

O Contexto das Ameaças Chinesas

A China permanece como a fonte mais prolífica de atividade de ciberameaça patrocinada por Estado. Os atores de ameaça rotineiramente operacionalizam exploits públicos dentro de horas ou dias após a divulgação, demonstrando uma capacidade organizacional impressionante.

Através do monitoramento realizado na infraestrutura de honeypot MadPot da AWS, as equipes de inteligência de ameaças identificaram tanto grupos conhecidos quanto clusters de ameaças previamente não rastreados tentando explorar a CVE-2025-55182. A AWS implementou múltiplas camadas de proteção automatizada, incluindo defesa ativa Sonaris, regras gerenciadas de Firewall de Aplicação Web (Web Application Firewall – AWS WAF) e controles de segurança de perímetro. Contudo, estas proteções não são substitutos para aplicação de patches.

Clientes que utilizam serviços AWS gerenciados não são afetados e nenhuma ação é necessária. Clientes que executam React ou Next.js em seus próprios ambientes (Amazon Elastic Compute Cloud, containers, etc.) devem atualizar as aplicações vulneráveis imediatamente.

Entendendo a CVE-2025-55182 (React2Shell)

Descoberta por Lachlan Davidson e divulgada responsavelmente ao React Team em 29 de novembro de 2025, a CVE-2025-55182 é uma vulnerabilidade de desserialização insegura em React Server Components. A vulnerabilidade recebeu o nome React2Shell da comunidade de pesquisadores de segurança.

Características Técnicas Principais

• Pontuação CVSS: 10.0 (severidade máxima)
• Vetor de ataque: Execução remota de código não autenticada
• Componentes afetados: React Server Components em React 19.x e Next.js 15.x/16.x com App Router
• Detalhe crítico: Aplicações estão vulneráveis mesmo que não utilizem explicitamente funções de servidor, desde que suportem React Server Components

A vulnerabilidade foi divulgada responsavelmente pela Vercel à Meta e aos principais provedores de nuvem, incluindo a AWS, possibilitando coordenação de patches e implantação de proteções antes da divulgação pública da vulnerabilidade.

Quem está Explorando a CVE-2025-55182?

A análise de tentativas de exploração na infraestrutura de honeypot AWS MadPot identificou atividade de exploração proveniente de endereços IP e infraestrutura historicamente associados a atores de ameaça conhecidos de origem chinesa. Devido à infraestrutura de anonimização compartilhada entre grupos de ameaça chineses, atribuição definitiva é desafiadora.

Earth Lamia

Este ator de ciberameaça de origem chinesa é conhecido por explorar vulnerabilidades de aplicação web visando organizações em América Latina, Oriente Médio e Sudeste Asiático. O grupo historicamente direcionou setores que incluem serviços financeiros, logística, varejo, empresas de TI, universidades e organizações governamentais.

Jackpot Panda

Este ator de ciberameaça de origem chinesa visa principalmente entidades no Leste e Sudeste Asiático. A atividade provavelmente se alinha com prioridades de coleta relacionadas a preocupações de segurança doméstica e corrupção.

Infraestrutura de Anonimização Compartilhada

Redes de anonimização em larga escala tornaram-se uma característica definidora das operações de ciberameaça chinesas, habilitando reconhecimento, exploração e atividades de comando-e-controle enquanto obscurecem atribuição. Estas redes são utilizadas simultaneamente por múltiplos grupos de ameaça, dificultando a atribuição de atividades específicas a atores individuais. Além disso, muitos grupos de ameaça não atribuídos compartilham característica com atividade de ciberameaça de origem chinesa. A maioria dos Números de Sistema Autônomo (Autonomous System Numbers – ASNs) observados para atividade não atribuída estão associados à infraestrutura chinesa, confirmando adicionalmente que a maioria da atividade de exploração origina-se daquela região.

A velocidade com a qual estes grupos operacionalizaram exploits públicos de prova-de-conceito destaca uma realidade crítica: quando provas-de-conceito atingem a internet, atores de ameaça sofisticados são rápidos em weaponizá-las.

Ferramentas e Técnicas de Exploração

Atores de ameaça estão utilizando tanto ferramentas automatizadas de varredura quanto exploits individuais de prova-de-conceito. Algumas ferramentas automatizadas observadas possuem capacidades para inibir detecção, como aleatorização de user agent. Estes grupos não estão limitando suas atividades à CVE-2025-55182.

As equipes de inteligência de ameaças da AWS observaram estes atores simultaneamente explorando outras vulnerabilidades recentes do tipo N-day, incluindo CVE-2025-1338. Isto demonstra uma abordagem sistemática: atores de ameaça monitoram novas divulgações de vulnerabilidades, integram rapidamente exploits públicos em sua infraestrutura de varredura, e conduzem campanhas amplas através de múltiplas Vulnerabilidades e Exposições Comuns (Common Vulnerabilities and Exposures – CVEs) simultaneamente para maximizar suas chances de encontrar alvos vulneráveis.

A Realidade das Provas-de-Conceito Públicas: Quantidade Sobre Qualidade

Uma observação notável da investigação é que muitos atores de ameaça estão tentando utilizar provas-de-conceito públicas que na verdade não funcionam em cenários do mundo real. A comunidade de segurança do GitHub identificou múltiplas provas-de-conceito que demonstram compreensões fundamentais incorretas da vulnerabilidade:

• Algumas aplicações de exemplo explicitamente registram módulos perigosos (fs, child_process, vm) no manifesto do servidor, algo que aplicações reais nunca deveriam fazer
• Vários repositórios contêm código que permaneceria vulnerável mesmo após aplicação de patches para versões seguras

Apesar da inadequação técnica de muitas provas-de-conceito públicas, atores de ameaça continuam tentando utilizá-las. Isto demonstra padrões importantes:

• Velocidade sobre precisão: Atores de ameaça priorizam operacionalização rápida sobre testes minuciosos, tentando explorar alvos com qualquer ferramenta disponível
• Abordagem baseada em volume: Varrendo amplamente com múltiplas provas-de-conceito (mesmo não-funcionais), atores esperam encontrar o pequeno percentual de configurações vulneráveis
• Barreira baixa para entrada: A disponibilidade de exploits públicos, mesmo falhos, habilita atores menos sofisticados a participar em campanhas de exploração
• Geração de ruído: Tentativas de exploração falhadas criam ruído significativo em logs, potencialmente mascarando ataques mais sofisticados

Padrões de Ataque Persistentes e Metódicos

A análise de dados do MadPot revela a natureza persistente destas tentativas de exploração. Em um exemplo notável, um cluster de ameaça não atribuído associado ao endereço IP 183.6.80.214 gastou aproximadamente uma hora (das 2:30:17 até 3:22:48 AM UTC em 4 de dezembro de 2025) sistematicamente depurando tentativas de exploração:

• 116 requisições totais através de 52 minutos
• Tentou múltiplos payloads de exploração
• Tentou executar comandos Linux (whoami, id)
• Tentou escrever arquivo em /tmp/pwned.txt
• Tentou ler /etc/passwd

Este comportamento demonstra que atores de ameaça não estão apenas executando varreduras automatizadas, mas estão ativamente depurando e refinando suas técnicas de exploração contra alvos vivos.

Como a AWS Auxilia na Proteção de Clientes

A AWS implementou múltiplas camadas de proteção para auxiliar na salvaguarda de clientes:

Defesa Ativa Sonaris

O sistema de inteligência de ameaças Sonaris automaticamente detectou e restringiu tentativas de varredura maliciosa visando esta vulnerabilidade. Sonaris analisa mais de 200 bilhões de eventos por minuto e integra inteligência de ameaças da rede de honeypot MadPot para identificar e bloquear tentativas de exploração em tempo real.

Regras Gerenciadas de AWS WAF

A versão padrão (1.24 ou superior) do AWSManagedRulesKnownBadInputsRuleSet versão 1.24 agora inclui regras atualizadas para CVE-2025-55182, fornecendo proteção automática para clientes utilizando AWS WAF com conjuntos de regras gerenciadas.

Inteligência MadPot

O sistema global de honeypot forneceu detecção antecipada de tentativas de exploração, habilitando resposta rápida e análise de ameaças.

Inteligência de Ameaças Amazon

As equipes de inteligência de ameaças Amazon estão investigando ativamente tentativas de exploração da CVE-2025-55182 para proteger infraestrutura AWS. Se identificarmos sinais de que sua infraestrutura foi comprometida, notificaremos você através do Suporte AWS. Contudo, vulnerabilidades de camada de aplicação são difíceis de detectar abrangentemente somente através de telemetria de rede. Não aguarde notificação da AWS.

Importante: Estas proteções não são substitutos para aplicação de patches. Clientes que executam React ou Next.js em seus próprios ambientes (EC2, containers, etc.) devem atualizar as aplicações vulneráveis imediatamente.

Ações Recomendadas Imediatas

• Atualizar aplicações React/Next.js vulneráveis. Consulte o Boletim de Segurança AWS (https://aws.amazon.com/security/security-bulletins/AWS-2025-030/) para versões afetadas e com patches aplicados
• Implantar regra customizada de AWS WAF como proteção interim (regra fornecida no boletim de segurança)
• Revisar logs de aplicação e servidor web para atividade suspeita. Procure por requisições POST com headers next-action ou rsc-action-id
• Verificar execução de processo inesperada ou modificações de arquivo em servidores de aplicação
• Se suspeitar comprometimento: Abra um caso de Suporte AWS imediatamente para assistência com resposta a incidentes

Nota: Clientes utilizando serviços AWS gerenciados não são afetados e não requerem ação.

Indicadores de Comprometimento

Indicadores de Rede

• Requisições HTTP POST para endpoints de aplicação com headers next-action ou rsc-action-id
• Corpos de requisição contendo padrões $@
• Corpos de requisição contendo padrões “status”:”resolved_model”

Indicadores Baseados em Host

• Execução inesperada de comandos de reconhecimento (whoami, id, uname)
• Tentativas de ler /etc/passwd
• Escritas suspeitas de arquivo em diretório /tmp/ (por exemplo, pwned.txt)
• Novos processos originados por processos de aplicação Node.js/React

Infraestrutura de Ator de Ameaça

• 206.237.3.150 — 4 de dezembro de 2025 — Earth Lamia
• 45.77.33.136 — 4 de dezembro de 2025 — Jackpot Panda
• 143.198.92.82 — 4 de dezembro de 2025 — Rede de Anonimização
• 183.6.80.214 — 4 de dezembro de 2025 — Cluster de ameaça não atribuído

Recursos Adicionais

• Boletim de Segurança AWS: CVE-2025-55182 (https://aws.amazon.com/security/security-bulletins/AWS-2025-030/)
• Documentação de AWS WAF (https://docs.aws.amazon.com/waf/)
• Aviso de Segurança React Team (https://react.dev/blog/2025/12/03/react-server-components-security-advisory)

Fonte

China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182) (https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/)

O que é IAM Policy Autopilot

A AWS tornou público o IAM Policy Autopilot, uma ferramenta de análise estática disponível em código aberto. Seu propósito principal é auxiliar assistentes de IA na criação rápida de políticas de acesso (Controle de Identidade e Acesso — IAM) que servem como ponto de partida sólido, permitindo que desenvolvedores revisem e ajustem as permissões conforme suas aplicações evoluem.

A ferramenta funciona de duas formas: como comando de linha (CLI) e como servidor de protocolo de contexto de modelo (MCP). Ao analisar o código da aplicação localmente, gera políticas baseadas em identidade que controlam o acesso para as funções da aplicação. Com essa abordagem, desenvolvedores conseguem focar na escrita do código da aplicação, acelerando o desenvolvimento na AWS e economizando tempo que seria gasto com configuração de políticas de acesso e resolução de problemas de permissão.

O contexto do problema

Profissionais que desenvolvem na AWS enfrentam três desafios relacionados às permissões de IAM. Primeiro, muitos preferem dedicar tempo à construção da aplicação em vez de estudar documentações complexas sobre permissões, escrever políticas ou diagnosticar erros de acesso. Segundo, assistentes de IA para codificação — como Kiro, Claude Code, Cursor e Cline — são excelentes em gerar código de aplicação, mas enfrentam dificuldades com as nuances do IAM e necessitam de ferramentas que garantam políticas confiáveis com requisitos complexos entre múltiplos serviços. Terceiro, tanto desenvolvedores quanto seus assistentes de IA precisam manter-se atualizados com os requisitos e padrões de integração mais recentes sem precisar consultar manualmente toda a documentação da AWS.

Como o IAM Policy Autopilot responde aos desafios

A ferramenta enderça esses três pontos de forma integrada. Primeiro, executa análise determinística do código da aplicação, gerando as políticas de acesso baseadas em identidade necessárias a partir das chamadas reais do AWS SDK presentes no código. Isso agiliza a criação inicial da política e reduz o tempo de diagnóstico de problemas. Segundo, oferece aos assistentes de IA configurações confiáveis e precisas através do MCP, impedindo alucinações que frequentemente geram erros nas políticas e garantindo que as políticas geradas sejam sintaticamente corretas. Terceiro, mantém-se atualizada com o catálogo expandido de serviços da AWS, atualizando regularmente sua expertise com novos serviços, permissões e padrões de integração, garantindo que desenvolvedores e seus assistentes tenham acesso a requisitos atualizados sem pesquisa manual.

Como funciona internamente

Análise de código e geração de políticas

O IAM Policy Autopilot analisa o código da aplicação e gera políticas de acesso baseadas em identidade conforme os SDK calls da AWS detectados no código. A capacidade essencial da ferramenta reside na análise determinística que produz resultados consistentes e confiáveis. Além de mapeamentos diretos entre SDK e IAM, o Autopilot compreende relacionamentos complexos de dependência entre serviços da AWS.

Por exemplo, ao identificar uma chamada para s3.putObject(), a ferramenta não gera apenas a permissão do Amazon S3 (s3:PutObject), mas também inclui permissões do AWS KMS (kms:GenerateDataKey) que podem ser necessárias em cenários de criptografia. Ao compreender dependências entre serviços e padrões de uso comum, o Autopilot intencionalmente adiciona essas permissões relacionadas à API PutObject em sua primeira análise, garantindo que a aplicação funcione corretamente independentemente da configuração de criptografia desde a primeira implantação.

Resolução de erros de acesso negado

Após as permissões serem criadas, se ainda assim surgirem erros de Acesso Negado durante testes, o IAM Policy Autopilot os detecta e oferece diagnóstico imediato. Quando habilitado, o assistente de IA invoca o Autopilot para analisar a negação e propor correções direcionadas. Após revisão e aprovação da análise e mudanças sugeridas, o Autopilot atualiza as permissões.

Suporte a MCP e CLI

A ferramenta opera em dois modos para se adequar a diferentes fluxos de desenvolvimento. Como servidor MCP, integra-se com assistentes compatíveis, incluindo Kiro, Amazon Q Developer, Cursor, Cline e Claude Code. Também está disponível como ferramenta CLI autônoma para gerar políticas ou corrigir permissões faltantes. Ambas as abordagens oferecem as mesmas capacidades de criação e resolução de problemas.

Demonstração prática: criando uma função segura de upload de arquivos

Cenário: aplicação com Lambda e S3 criptografado

Imagine um desenvolvedor que precisa criar uma função AWS Lambda para upload de documentos em S3 com criptografia do lado do servidor usando uma chave KMS gerenciada pelo cliente. O fluxo aconteceria assim:

Passo 1: O desenvolvedor descreve os requisitos

O desenvolvedor comunica ao assistente Cline: “Preciso criar uma função Lambda para fazer upload de arquivos para S3. Os arquivos devem ser criptografados usando uma chave KMS gerenciada pelo cliente. Pode ajudar?”

Passo 2: O assistente planeja a solução

O Cline responde descrevendo o plano: criar a função Lambda, configurar integração com S3 com criptografia KMS gerenciada pelo cliente, criar as permissões IAM necessárias e construir a infraestrutura usando CDK.

Passo 3: O assistente escreve o código Lambda

O Cline gera o arquivo uploadHandler.js:

const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3');
const s3Client = new S3Client({ region: 'us-west-2' });

exports.handler = async (event) => {
  const { fileName, fileContent } = JSON.parse(event.body);
  const putObjectParams = {
    Bucket: process.env.BUCKET_NAME,
    Key: fileName,
    Body: fileContent,
    ServerSideEncryption: 'aws:kms',
    SSEKMSKeyId: process.env.KMS_KEY_ID
  };

  try {
    await s3Client.send(new PutObjectCommand(putObjectParams));
    return {
      statusCode: 200,
      body: JSON.stringify({ message: 'File uploaded successfully' })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: error.message })
    };
  }
};

Passo 4: O assistente descobre o IAM Policy Autopilot

O Cline reconhece que precisa criar a função IAM com as permissões corretas e descobre que tem acesso ao MCP server do IAM Policy Autopilot. Invoca a ferramenta solicitando análise do código para gerar políticas.

Passo 5: A ferramenta analisa e gera a política

O IAM Policy Autopilot escaneia o código, identifica a chamada PutObjectCommand (API do S3) e, baseado em padrões típicos de uso dos clientes AWS, também sugere permissões de criptografia e permissões de CloudWatch Logs. Gera a seguinte política de acesso:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::*/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:us-west-2:123456789012:key/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-west-2:123456789012:*"
    }
  ]
}

Passo 6: O assistente cria a infraestrutura completa

Com as permissões geradas, o Cline procede à criação do template CloudFormation com a política fornecida pelo Autopilot. O desenvolvedor recebe uma solução completa pronta para implantação.

Uso direto via CLI: geração simplificada

Para quem prefere interação direta com linha de comando, a ferramenta oferece as mesmas capacidades de análise sem necessidade de assistente de IA. Com o arquivo uploadHandler.js existente, basta executar:

$ iam-policy-autopilot generate-policy --region us-west-2 --account 123456789012 --pretty Users/user/workspace/uploadHandler.js

O comando produz a mesma política JSON anterior, que pode ser copiada diretamente para templates CloudFormation, AWS CDK ou configurações Terraform. Essa abordagem CLI integra-se naturalmente em fluxos de linha de comando e pipelines de implantação automatizados.

Boas práticas e considerações importantes

Comece com as políticas geradas e refine

O IAM Policy Autopilot gera políticas que priorizam funcionalidade sobre permissões mínimas, assegurando que as aplicações executem com sucesso desde a primeira implantação. Essas políticas representam um ponto de partida sólido que pode ser refinado conforme a aplicação amadurece. Recomenda-se revisar as políticas geradas para garantir alinhamento com requisitos de segurança antes da implantação em produção.

Compreender o escopo de análise

O Autopilot destaca-se na identificação de chamadas diretas ao AWS SDK, fornecendo cobertura abrangente de políticas para a maioria dos cenários de desenvolvimento. Porém, há limitações. Se o código chama s3.getObject(bucketName) onde o bucketName é determinado em tempo de execução, o Autopilot atualmente não prevê qual bucket será acessado. Para aplicações usando bibliotecas terceirizadas que envolvem SDKs da AWS, pode ser necessário complementar a análise com revisão manual.

Atualmente, o IAM Policy Autopilot foca em políticas baseadas em identidade para funções e usuários IAM, mas não cria políticas baseadas em recursos, como políticas de bucket S3 ou políticas de chave KMS.

Integrar com fluxos IAM existentes

O Autopilot funciona melhor como parte de uma estratégia IAM abrangente. Use-o para gerar políticas funcionais rapidamente, depois empregue outras ferramentas da AWS para refinamento contínuo. Por exemplo, o AWS IAM Access Analyzer ajuda a identificar permissões não utilizadas ao longo do tempo. Essa combinação cria um fluxo desde implantação rápida até otimização com privilégio mínimo.

Entender a divisão entre ferramenta e assistente

O IAM Policy Autopilot gera políticas com ações específicas baseadas em análise determinística. Quando integrado como servidor MCP com um assistente de IA, o assistente recebe essa política e pode modificá-la ao criar templates de infraestrutura como código. Essas mudanças vêm da interpretação do assistente sobre o contexto mais amplo do código, não da análise estática fornecida pelo Autopilot. Sempre revise o conteúdo gerado pelo assistente antes da implantação para verificar conformidade com requisitos de segurança.

Escolher a abordagem de integração correta

Use a integração servidor MCP ao trabalhar com assistentes de IA para criação contínua e natural de políticas. A ferramenta CLI funciona bem para processamento em lote ou quando há preferência por interação direta. Ambas oferecem as mesmas capacidades analíticas — a escolha depende das preferências do fluxo de desenvolvimento.

Conclusão

O IAM Policy Autopilot transforma o gerenciamento de políticas de acesso de um desafio de desenvolvimento em uma capacidade automatizada que funciona perfeitamente nos fluxos existentes. Ao utilizar análise determinística de código e capacidades de criação de políticas, desenvolvedores conseguem focar na construção de aplicações confiando que possuem as permissões necessárias para executar com sucesso na AWS.

Seja através da integração servidor MCP com assistentes de IA ou pela abordagem direta de CLI, o Autopilot identifica dependências comuns entre serviços (como operações S3 com criptografia KMS), gera políticas sintaticamente corretas e permanece atualizado conforme o catálogo de serviços da AWS se expande. O resultado prático: ciclos de implantação mais rápidos, menos falhas relacionadas a permissões e maior tempo dedicado à criação de valor ao negócio em vez de depuração de problemas de acesso.

A ferramenta está disponível agora, sem custo adicional. Para começar, faça o download do repositório GitHub e experimente como a criação automatizada de políticas pode acelerar o desenvolvimento na AWS.

Fonte

IAM Policy Autopilot: An open-source tool that brings IAM policy expertise to builders and AI coding assistants (https://aws.amazon.com/blogs/security/iam-policy-autopilot-an-open-source-tool-that-brings-iam-policy-expertise-to-builders-and-ai-coding-assistants/)

Segurança aprimorada no Amazon SES com VPC endpoints

A Amazon Web Services anunciou uma novidade importante para o Simple Email Service (SES): o suporte para acessar endpoints de API através de Virtual Private Cloud (VPC) endpoints. Essa funcionalidade permite que clientes da AWS trabalhem com as APIs do SES de forma mais segura, mantendo o tráfego isolado dentro de suas redes privadas.

O que muda na prática

Até agora, empresas que executavam suas aplicações dentro de uma VPC precisavam configurar um Internet Gateway para acessar o SES. Essa abordagem funcionava, mas criava um potencial risco de segurança: o tráfego da VPC era exposto à internet para atingir os endpoints públicos do serviço de email.

Com os VPC endpoints, esse cenário muda significativamente. As organizações agora conseguem acessar as APIs do SES — utilizadas para enviar emails e gerenciar configurações de recursos — sem necessidade de um Internet Gateway. Isso reduz drasticamente as chances de exposição de atividades da VPC à internet pública.

Recursos disponíveis e alcance

Os VPC endpoints para o SES funcionam tanto para operações de envio de emails quanto para gerenciamento de configurações do serviço. A AWS disponibilizou este recurso em todos os AWS Regions onde o SES opera, garantindo consistência global.

Para equipes interessadas em implementar essa solução em suas infraestruturas, a AWS fornece documentação técnica completa. Mais detalhes sobre como configurar os VPC endpoints com Amazon SES estão disponíveis na documentação oficial.

Impacto para o setor

Essa adição reforça o compromisso da AWS em oferecer opções de segurança mais robustas para empresas que utilizam seus serviços. Para organizações em setores regulados ou com requisitos rigorosos de conformidade, a capacidade de manter tráfego sensível isolado dentro de redes privadas é um passo importante na redução de vetores de ataque e exposição potencial de dados.

Fonte

Amazon SES adds VPC support for API endpoints (https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-ses-vpc-api-endpoints/)