User's blog

Category: Uncategorized

  • Detectando e prevenindo crypto mining no seu ambiente AWS

    O problema do crypto mining não autorizado na nuvem

    Quando alguém obtém acesso indevido a recursos de nuvem para minerar criptomoedas, o impacto vai muito além do desperdício de processamento. A Amazon Web Services (AWS) detalha em um guia recente que organizações afetadas podem enfrentar aumentos de custo que vão de centenas a milhares de dólares, degradação de performance em workloads legítimas e, em casos mais graves, incidentes de segurança como exposição de dados ou implantação de ransomware.

    O que torna esse problema ainda mais preocupante é que as técnicas usadas pelos atacantes evoluem constantemente, dificultando a detecção. Muitas organizações só descobrem a invasão depois de receberem uma fatura inesperada ou quando a degradação de recursos começa a afetar as operações. E quando um atacante entra pela porta do crypto mining, ele pode instalar backdoors, comprometer credenciais e se mover lateralmente pela infraestrutura AWS.

    Sinais que indicam atividade de mineração

    A AWS aponta alguns indicadores que as equipes de segurança devem monitorar ativamente:

    • Conexões com endereços IP desconhecidos ou uso de portas associadas a pools de mineração, como a porta 3333
    • Uso elevado e sustentado de CPU ou GPU sem justificativa nas operações normais do negócio
    • Padrões de tráfego de rede incomuns, especialmente picos de saída para IPs não reconhecidos
    • Processos ou aplicações não autorizadas rodando nos recursos

    Como o Amazon GuardDuty detecta mineração de criptomoedas

    O Amazon GuardDuty é o serviço central para detecção desse tipo de ameaça. Ele usa algoritmos de aprendizado de máquina (Machine Learning) alimentados por dados globais de ameaças coletados pela AWS, detecção de anomalias baseada em linhas de base comportamentais e inteligência de ameaças integrada com parceiros de segurança.

    Tipos de alertas específicos para crypto mining

    As capacidades de detecção de crypto mining do GuardDuty incluem os seguintes tipos de findings:

    O GuardDuty também monitora os Flow Logs da Amazon Virtual Private Cloud (Amazon VPC) em busca de padrões suspeitos de rede, analisa consultas DNS para domínios relacionados à mineração e examina eventos do AWS CloudTrail para identificar chamadas de API suspeitas.

    Quando o recurso de Runtime Monitoring está ativado, o GuardDuty implanta agentes leves que oferecem visibilidade mais profunda sobre processos em execução e comportamento do sistema. Isso habilita findings como CryptoCurrency:Runtime/BitcoinTool.B e Impact:Runtime/CryptoMinerExecuted, que detectam software de mineração operando dentro dos workloads.

    A cobertura se estende a instâncias Amazon EC2, clusters do Amazon Elastic Container Service (Amazon ECS), ambientes Kubernetes e containers standalone. Para ambientes containerizados, findings do Amazon Elastic Kubernetes Service (Amazon EKS) podem indicar quando acessos não autorizados estão sendo usados para operações de mineração.

    Construindo uma proteção em múltiplas camadas

    A AWS reforça que a proteção contra crypto mining se beneficia de várias camadas de segurança — o GuardDuty é um componente importante, mas não o único. Veja o que a AWS recomenda para complementar as capacidades de detecção:

    • Ative o GuardDuty em todas as contas e regiões via AWS Organizations, habilitando também o Runtime Monitoring e a proteção para Amazon EKS.
    • Amazon CloudWatch: configure métricas de uso de recursos e alarmes para picos incomuns de CPU, rede ou GPU que possam indicar mineração.
    • AWS Config: implemente regras para verificar conformidade de configurações de segurança, garantindo que grupos de segurança não permitam acesso amplo à internet e que o IMDSv2 esteja aplicado.
    • AWS Network Firewall: habilite filtragem granular de tráfego de saída, permitindo apenas conectividade necessária e bloqueando acesso à infraestrutura de mineração.
    • AWS Systems Manager: mantenha visibilidade sobre configurações de instâncias. O recurso Inventory rastreia aplicações instaladas para detectar software de mineração; Run Command e State Manager aplicam políticas de segurança em toda a frota.
    • Automação de resposta: crie workflows automáticos usando Amazon EventBridge e Lambda para reagir imediatamente quando o GuardDuty detectar atividades de mineração.

    Boas práticas para proteção abrangente

    Gestão de acesso e autenticação

    A AWS recomenda implementar o princípio do menor privilégio com o Gerenciamento de Identidade e Acesso da AWS (IAM). Para casos de uso de software, use IAM roles dentro da AWS e IAM Roles Anywhere fora da AWS, em vez de chaves de acesso de longa duração. Para identidades humanas, centralize o gerenciamento de usuários pelo AWS IAM Identity Center com Autenticação Multifator (MFA) e controle de acesso baseado em atributos.

    Se não for possível eliminar o uso de chaves de acesso de longa duração, implemente políticas de rotação regular e aplique o menor privilégio em todas as políticas do IAM. Audite permissões regularmente para identificar e remover acessos excessivos.

    Manutenção de sistemas e configurações

    Use o Patch Manager, recurso do Systems Manager, para automatizar a aplicação de patches e manter as Imagens de Máquina da Amazon (AMIs) sempre atualizadas. Estabeleça um ciclo regular de patching, testando em ambientes de não-produção antes de implantar.

    Implemente regras rígidas de entrada em grupos de segurança, permitindo apenas o tráfego necessário. Use filtragem de saída para impedir conexões não autorizadas com pools de mineração e audite regularmente as configurações de grupos de segurança.

    Proteção de dados

    Use o Serviço de Gerenciamento de Chaves da AWS (AWS KMS) para habilitar criptografia de todos os dados em repouso e implemente TLS para dados em trânsito. O AWS KMS utiliza criptografia em envelope por padrão, protegendo as chaves de dados com chaves mestras. Rotacione as chaves de criptografia regularmente.

    Benefícios de uma proteção abrangente

    A AWS descreve os ganhos concretos que organizações podem obter ao implementar esse conjunto de medidas:

    • Redução do tempo de detecção: de dias ou semanas para minutos, permitindo contenção rápida antes que danos significativos ocorram.
    • Respostas automatizadas: workflows automáticos reduzem a necessidade de intervenção manual, liberando as equipes de segurança para iniciativas estratégicas.
    • Controle de custos: identificação e encerramento de consumo não autorizado de recursos, prevenindo aumentos inesperados na fatura.
    • Estabilidade de performance: processos de mineração deixam de monopolizar CPU, memória e rede, mantendo a performance das aplicações legítimas.
    • Visibilidade ampliada: a abordagem de monitoramento ajuda a identificar não só crypto mining, mas outras ameaças de segurança que poderiam passar despercebidas.
    • Confiança da equipe: monitoramento contínuo e alertas automatizados garantem que tentativas de mineração sejam detectadas e tratadas prontamente.

    Mineração de criptomoedas autorizada na AWS

    Um ponto importante destacado pela AWS: mineração de criptomoedas na plataforma requer aprovação prévia por escrito, conforme os Termos de Serviço da AWS (Seção 1.25). Essa exigência existe para proteger tanto os recursos dos clientes quanto a infraestrutura geral da AWS.

    Para solicitar aprovação, o AWS Trust & Safety avalia os pedidos para evitar que atividades de mineração afetem negativamente a performance ou a segurança dos serviços. A solicitação deve incluir:

    • Descrição do propósito da mineração e do caso de negócio
    • Planejamento de infraestrutura e abordagem de gestão de custos
    • Detalhamento das medidas de segurança para prevenir acessos não autorizados
    • Contatos de emergência para comunicação rápida em caso de problemas
    • Número de instâncias e tipo de mineração pretendida

    Operações aprovadas devem seguir diretrizes específicas. A AWS monitora as atividades para verificar que não geram relatórios de abuso, não afetam a performance dos serviços e não desviam da arquitetura e das práticas de segurança definidas. Vale lembrar: créditos AWS e recursos do Free Tier não podem ser usados para mineração.

    Conclusão

    A AWS recomenda uma abordagem abrangente que combine detecção avançada de ameaças com medidas preventivas proativas. O GuardDuty fornece a base de detecção, enquanto os serviços complementares formam um ecossistema robusto de segurança. A segurança é uma responsabilidade compartilhada: a AWS fornece as ferramentas, mas a implementação das práticas e controles de segurança por parte da organização é o que determina o nível real de proteção. Revisão regular das medidas de segurança e treinamento das equipes são essenciais para manter uma defesa eficaz contra crypto mining e outras ameaças no ambiente AWS.

    Fonte

    Detecting and preventing crypto mining in your AWS environment (https://aws.amazon.com/blogs/security/detecting-and-preventing-crypto-mining-in-your-aws-environment/)

  • Pacotes de Conformidade PCI PIN e P2PE já estão disponíveis para o AWS Payment Cryptography

    A AWS expande conformidade de pagamentos com PCI PIN e PCI P2PE

    A Amazon Web Services (AWS) anunciou a conclusão bem-sucedida das avaliações de conformidade com os padrões Número de Identificação Pessoal da Indústria de Cartões de Pagamento (PCI PIN) e Criptografia Ponto a Ponto da Indústria de Cartões de Pagamento (PCI P2PE) para o serviço AWS Payment Cryptography. Essa conquista representa um avanço significativo no portfólio de conformidade do serviço e traz implicações diretas para empresas brasileiras que processam pagamentos eletrônicos na nuvem.

    O que mudou no portfólio de conformidade

    Com essa nova validação, a AWS passa a ser reconhecida como provedora de componentes em três categorias distintas dentro do ecossistema PCI:

    • Gerenciamento de Chaves (KMCP — Key Management Component Provider)
    • Carregamento de Chaves (KLCP — Key Loading Component Provider)
    • Gerenciamento de Descriptografia (DMCP — Decryption Management Component Provider) — já existente anteriormente

    Além do escopo ampliado de categorias, a cobertura PCI PIN e PCI P2PE foi estendida para duas novas regiões: América do Sul (São Paulo) e Ásia-Pacífico (Sydney). Para o mercado brasileiro, isso é especialmente relevante: significa que workloads de pagamento podem ser operadas diretamente na região de São Paulo com respaldo formal de conformidade PCI.

    O que é o AWS Payment Cryptography

    O AWS Payment Cryptography é um serviço que permite que aplicações de processamento de pagamentos utilizem módulos de segurança de hardware (HSMs — Hardware Security Modules) para pagamentos. Esses HSMs são certificados pelo padrão Segurança de Transações HSM PTS (PCI PIN Transaction Security) e são totalmente gerenciados pela AWS, com gerenciamento de chaves em conformidade com PCI PIN e PCI P2PE.

    Na prática, isso significa que empresas que desenvolvem ou operam soluções de pagamento podem delegar à AWS a responsabilidade pela infraestrutura criptográfica regulada, reduzindo consideravelmente a carga operacional de manter essa conformidade internamente.

    Para quais casos de uso essas certificações são relevantes

    Cada certificação cobre um cenário específico dentro do ecossistema de pagamentos:

    • PCI P2PE — Componente de Descriptografia: permite que aplicações de pagamento utilizem a AWS para descriptografar transações de cartão de crédito provenientes de terminais de pagamento.
    • PCI PIN: obrigatório para aplicações que processam transações de débito baseadas em PIN (senha numérica do cartão).
    • PCI P2PE — Componentes de Gerenciamento e Carregamento de Chaves: habilitam o uso da AWS para troca física de chaves criptográficas e para casos de uso de gerenciamento de chaves, incluindo injeção de chaves.

    Para saber mais sobre o novo recurso de Troca Física de Chaves, a AWS publicou um anúncio no AWS What’s New com detalhes adicionais.

    Documentos incluídos nos pacotes de conformidade

    Os pacotes de conformidade PCI PIN e PCI P2PE para o AWS Payment Cryptography incluem um conjunto abrangente de documentos técnicos e regulatórios:

    • Atestado de Conformidade PCI PIN (AOC — Attestation of Compliance): demonstra que o AWS Payment Cryptography foi validado com êxito contra o padrão PCI PIN, sem nenhuma não-conformidade identificada.
    • Resumo de Responsabilidades PCI PIN: orienta os clientes da AWS sobre suas responsabilidades ao desenvolver e operar ambientes seguros para transações baseadas em PIN.
    • Atestado de Validação PCI P2PE DMCP (AOV — Attestation of Validation): comprova a validação do serviço como Sistema de Gerenciamento de Descriptografia PCI P2PE, sem não-conformidades.
    • Atestado de Validação PCI P2PE KMCP (AOV): comprova a validação como Provedor de Componente de Gerenciamento de Chaves PCI P2PE, sem não-conformidades.
    • Atestado de Validação PCI P2PE KLCP (AOV): comprova a validação como Provedor de Componente de Carregamento de Chaves PCI P2PE, sem não-conformidades.
    • Guia do Usuário do Componente P2PE e Relatório Anual do Componente: descreve o escopo de avaliação do serviço como Componente de Descriptografia, Componente de Carregamento de Chaves e Componente de Gerenciamento de Chaves PCI P2PE, além de ilustrar as responsabilidades de conformidade tanto do serviço quanto dos clientes que o utilizam para processamento de criptografia ponto a ponto.

    Como acessar os documentos de conformidade

    Todos os relatórios — incluindo o Atestado de Conformidade PCI PIN, o Resumo de Responsabilidades Compartilhadas PCI PIN, o Atestado de Validação PCI P2PE e o Guia do Usuário do Componente de Descriptografia P2PE — estão disponíveis para os clientes diretamente pelo AWS Artifact, o repositório centralizado de documentos de conformidade da AWS.

    A avaliação foi conduzida pela Coalfire, uma Avaliadora de Segurança Qualificada (QSA — Qualified Security Assessor) terceirizada e independente, o que reforça a credibilidade das validações obtidas.

    Contexto para equipes de conformidade e segurança

    Para profissionais que lidam com conformidade regulatória em ambientes de pagamento, essa expansão do portfólio PCI do AWS Payment Cryptography representa uma oportunidade concreta de reduzir a complexidade operacional. Ao utilizar componentes já validados pela AWS, as equipes podem concentrar esforços nas responsabilidades que permanecem sob seu controle, em vez de precisar manter e auditar toda a infraestrutura criptográfica de ponta a ponta.

    Para conhecer mais sobre os programas PCI e outros programas de conformidade e segurança disponíveis, a AWS disponibiliza informações na página de Programas de Conformidade da AWS. Dúvidas específicas sobre conformidade podem ser encaminhadas à equipe de Compliance da AWS pela página de Suporte de Conformidade, e questões técnicas podem ser tratadas diretamente pelo AWS Support.

    Fonte

    PCI PIN and P2PE compliance packages for AWS Payment Cryptography are now available (https://aws.amazon.com/blogs/security/pci-pin-and-p2pe-compliance-packages-for-aws-payment-cryptography-are-now-available/)

  • Segurança em agentes de IA: como AWS e Cisco AI Defense protegem implantações MCP e A2A em escala

    O crescimento acelerado dos agentes de IA criou lacunas sérias de segurança

    Desde novembro de 2024, a adoção do Protocolo de Contexto de Modelo (MCP) cresceu de forma expressiva. Empresas passaram a gerenciar dezenas — às vezes centenas — de servidores MCP: ferramentas que ampliam as capacidades de agentes de IA conectando-os a fontes de dados externas e APIs. Em abril de 2025, surgiu o Protocolo Agente-para-Agente (A2A), que permite que agentes autônomos se comuniquem diretamente entre si, sem intervenção humana. Mais recentemente, as Agent Skills (habilidades de agente) passaram a aparecer em toda a infraestrutura corporativa.

    Esse crescimento gerou três lacunas críticas de segurança:

    • As equipes não têm visibilidade sobre quais ferramentas e agentes estão em execução;
    • Revisões manuais de segurança não conseguem acompanhar o ritmo das implantações;
    • Frameworks de conformidade exigem trilhas de auditoria que simplesmente não existem para agentes de IA autônomos.

    Os riscos são concretos: acesso inadvertido a sistemas com dados sensíveis, violações de conformidade sob frameworks como SOX e GDPR — com potencial de penalidades regulatórias — e interrupções operacionais quando ferramentas vulneráveis ou agentes maliciosos são descobertos apenas após a implantação. Equipes de segurança relatam que processos de revisão manual podem adicionar várias semanas a cada implantação de aplicação de IA, criando um backlog que cresce conforme a adoção de IA acelera.

    A parceria entre AWS e Cisco AI Defense

    Para endereçar esses desafios, a AWS e a Cisco AI Defense firmaram uma colaboração estratégica que oferece varredura de segurança automatizada e abrangente para cada servidor MCP, agente de IA e Agent Skill no ambiente corporativo. O centro dessa solução é o AI Registry, projeto open-source apoiado pela AWS, que se integra ao Cisco AI Defense para resolver três problemas centrais.

    Visibilidade e controle do espalhamento de ferramentas

    Organizações que implantam servidores MCP e agentes de IA enfrentam um desafio fundamental de visibilidade. Equipes costumam adicionar servidores e agentes de forma ad-hoc em infraestruturas de nuvem e on-premises, tornando praticamente impossível para as equipes de segurança manter controle sobre o que está disponível, quais agentes se comunicam entre si, quem os utiliza e se representam riscos de segurança.

    O AI Registry resolve isso por meio de registro e descoberta unificados. Cada servidor MCP, agente de IA e Skill é registrado em um único plano de controle, proporcionando visibilidade completa. Além disso, a integração com o Cisco AI Defense adiciona uma camada de proteção ativa sobre essa visibilidade.

    Segurança da cadeia de suprimentos em escala

    Servidores MCP de terceiros e agentes A2A podem conter vulnerabilidades, código malicioso ou padrões inseguros que revisões manuais não conseguem detectar em escala. Quando um novo servidor ou agente é adicionado ao registro, a varredura de segurança acontece automaticamente, antes que o componente possa ser acessado.

    O scanner analisa cada ferramenta MCP, card de agente A2A e Agent Skill, gerando relatórios de segurança detalhados. Se problemas forem encontrados, o componente é automaticamente marcado como desabilitado com uma tag security-pending, exigindo revisão do administrador antes de liberar o acesso. Isso vale tanto para um servidor MCP que fornece acesso a banco de dados quanto para um agente A2A que orquestra fluxos de trabalho em múltiplas etapas pela infraestrutura.

    Eliminando gargalos de revisão de conformidade

    Revisões de segurança tradicionais criam gargalos no processo de implantação. A varredura automatizada — com revisão humana apenas nos casos em que vulnerabilidades são encontradas — viabiliza o onboarding self-service com guardrails de segurança embutidos. O processo que antes era lento e manual passa a ser automatizado, acelerando a incorporação de novos servidores MCP, agentes e Skills, ao mesmo tempo em que mantém o histórico completo de auditoria de segurança para requisitos regulatórios como SOX e GDPR.

    Como o processo de varredura funciona na prática

    O AI Registry atua como plano de controle central onde servidores MCP, agentes de IA e Skills são registrados e descobertos, oferecendo visibilidade completa da infraestrutura de IA. Ao registrar um servidor MCP, o Cisco AI Defense MCP Scanner realiza análise profunda das descrições de ferramentas e esquemas. Ao registrar agentes A2A, o Cisco AI Defense A2A Scanner analisa declarações de capacidade, definições de habilidades e padrões de comunicação. Capacidades similares existem para Agent Skills, por meio de um Skills Scanner que detecta injeção de prompt, exfiltração de dados e padrões de código malicioso.

    O diagrama abaixo ilustra o fluxo completo do processo de registro e varredura de segurança:

    Imagem original — fonte: Aws

    A varredura pode ser iniciada sob demanda para analisar servidores MCP e agentes individualmente, ou para varrer todo o Registry de uma vez. Organizações tipicamente configuram um job Cron independente que usa a API do Registry para varrer periodicamente todo o ambiente e rastrear vulnerabilidades pelos sistemas de gestão de tickets existentes. Os resultados ficam armazenados no datastore do Registry e podem ser visualizados pela interface do Registry ou recuperados via API.

    Múltiplas abordagens de varredura

    A postura de segurança de uma organização é reforçada por múltiplas abordagens de varredura que se aplicam uniformemente a MCP, agentes A2A e Skills:

    • YARA Analyzer: detecção rápida baseada em padrões para ameaças conhecidas como injeção SQL, injeção de comandos e credenciais hardcoded;
    • LLM Analyzer: análise semântica com IA usando modelos de fronteira disponíveis pelo Amazon Bedrock, que examina lógica de ferramentas, comportamento de agentes e declarações de capacidade para identificar ameaças sofisticadas e inéditas;
    • Scanners proprietários da Cisco AI Defense: incluindo o MCP Scanner, A2A Scanner e Skills Scanner, para detecção avançada de ameaças combinando inteligência de ameaças extensiva com análise profunda de código.

    O A2A Scanner analisa especificamente os metadados dos cards de agente para detectar ameaças de cadeia de suprimentos como falsificação de identidade, injeção de prompt em campos de metadados, credenciais hardcoded, endpoints de exfiltração de dados e padrões de SSRF (Server-Side Request Forgery). Ele também verifica violações de conformidade com a especificação A2A e mapeia os achados para níveis de severidade de BAIXO a CRÍTICO.

    Quando problemas são detectados, o sistema desabilita automaticamente os ativos vulneráveis com relatórios de segurança detalhados, exigindo revisão do administrador antes de liberar o acesso. A varredura se integra aos fluxos de desenvolvimento (Integração Contínua/Entrega Contínua — CI/CD) como parte do registro de novos servidores e agentes no AI Registry.

    Arquitetura aberta e integração com fluxos corporativos

    O AI Registry é construído sobre padrões e APIs abertas. Clientes da Cisco AI Defense e da AWS podem consultar o AI Registry via API REST para descobrir servidores MCP e agentes disponíveis, suportando detecção de ameaças programática em escala. O registro usa a mesma especificação de API REST do MCP Registry oficial da Anthropic, garantindo ampla compatibilidade entre ambientes MCP e suporte a federação com outras implantações MCP.

    A integração com fluxos de trabalho corporativos existentes também é suportada:

    • Criação automática de tickets no ServiceNow para servidores ou agentes com problemas;
    • Notificações em tempo real no Slack quando achados de alta severidade são detectados;
    • Encaminhamento de dados de incidentes para sistemas de Gerenciamento de Eventos e Informações de Segurança (SIEM) como Splunk ou Datadog;
    • Relatórios consolidados em dashboards de conformidade para prontidão de auditoria.

    Como começar

    Para clientes AWS

    Clientes AWS podem implantar o AI Registry e configurar a integração com o Cisco AI Defense MCP Scanner para adicionar varredura de segurança ao fluxo de onboarding de ativos de IA. O guia completo de configuração do Security Scanner está disponível no GitHub.

    Além da integração com o AI Registry open-source, é possível usar o Cisco AI Defense em fluxos CI/CD para avaliar ativos de IA antes de registrá-los no AWS Agent Registry — um serviço gerenciado de descoberta que fornece um catálogo centralizado para organizar, curar e descobrir recursos em toda a organização. Essa abordagem permite que equipes avaliem servidores MCP, ferramentas, agentes, agent skills e recursos customizados antes da publicação no registry. Um exemplo de código com a integração do Cisco AI Defense (versão OSS) com o AWS Agent Registry está disponível no repositório oficial do AWS Labs.

    Para clientes Cisco AI Defense

    Clientes da Cisco AI Defense podem configurar o MCP Scanner para apontar para o registry da organização, descobrir servidores MCP e agentes disponíveis pela API do registry, gerar relatórios de segurança abrangentes e integrar os achados aos fluxos de segurança existentes. Os scanners open-source estão disponíveis publicamente:

    Para as capacidades completas do produto, consulte a documentação do Cisco AI Defense.

    Conclusão

    A parceria entre AWS e Cisco AI Defense representa uma resposta concreta a um problema que cresce junto com a adoção de IA nas empresas: como manter visibilidade, segurança e conformidade quando dezenas ou centenas de agentes e servidores são implantados em ritmo acelerado. A combinação do AI Registry com os scanners automatizados da Cisco endereça os três pilares do problema — visibilidade centralizada, varredura de segurança em escala e trilhas de auditoria para conformidade regulatória — sem criar novos gargalos no processo de desenvolvimento.

    Fonte

    Securing AI agents: How AWS and Cisco AI Defense scale MCP and A2A deployments (https://aws.amazon.com/blogs/machine-learning/securing-ai-agents-how-aws-and-cisco-ai-defense-scale-mcp-and-a2a-deployments/)

  • AWS Security Agent agora suporta revisão de código em repositórios completos

    O que foi anunciado

    A AWS anunciou a disponibilidade da revisão de código em repositório completo, uma nova capacidade do AWS Security Agent. O recurso realiza uma análise de segurança profunda e sensível ao contexto de toda a base de código de uma aplicação — e representa uma mudança significativa em relação às abordagens tradicionais de análise estática.

    Por que isso é diferente das ferramentas tradicionais

    Ferramentas convencionais de análise estática funcionam comparando o código contra padrões conhecidos de vulnerabilidades. O novo recurso do AWS Security Agent vai além: ele raciocina sobre a arquitetura da aplicação, os limites de confiança e os fluxos de dados para identificar vulnerabilidades sistêmicas que ferramentas baseadas em padrões simplesmente não conseguem detectar.

    Em termos práticos, isso significa que o scanner consegue enxergar problemas que só aparecem quando se analisa o sistema como um todo — e não apenas trechos isolados de código.

    Correções vinculadas ao arquivo e à linha exata

    Quando uma vulnerabilidade é identificada, o AWS Security Agent não apenas aponta o problema: ele gera uma correção de código específica, vinculada ao arquivo e à linha exata onde o problema foi encontrado. Isso permite que as equipes identifiquem e corrijam vulnerabilidades de segurança com muito mais agilidade do que antes.

    Disponibilidade e custo durante o preview

    O recurso está disponível em todas as regiões da AWS onde o AWS Security Agent já opera. Durante o período de preview, ele está disponível sem custo adicional para clientes existentes do AWS Security Agent.

    A AWS destaca que está priorizando o acesso antecipado gratuito para clientes, com o objetivo de dar aos defensores a oportunidade de fortalecer suas bases de código e compartilhar aprendizados que beneficiem toda a indústria.

    O contexto mais amplo: IA e cibersegurança

    A própria AWS reconhece que as capacidades de cibersegurança baseadas em IA estão evoluindo rapidamente. O AWS Security Agent já é capaz de encontrar vulnerabilidades e construir exploits funcionais em uma escala e velocidade sem precedentes. Esse cenário reforça a importância de colocar essas ferramentas nas mãos dos defensores antes que agentes maliciosos as utilizem.

    Como começar

    Para habilitar a revisão de repositório completo e executar a primeira análise, basta acessar o console do AWS Security Agent. Para mais detalhes sobre o funcionamento do recurso, a documentação oficial do AWS Security Agent traz o passo a passo completo.

    Fonte

    AWS Security Agent now supports full repository code reviews (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-agent-full-repository-code-review/)

  • AWS Security Agent ganha varredura completa de repositório de código em prévia

    Análise de segurança que raciocina como um pesquisador humano

    A AWS anunciou a disponibilidade em prévia de uma nova capacidade do AWS Security Agent: a revisão completa de repositório de código. A funcionalidade realiza uma análise de segurança profunda e contextual de toda a base de código de uma aplicação, indo muito além do que as ferramentas tradicionais de Teste Estático de Segurança de Aplicação (SAST) conseguem fazer.

    O diferencial central está na abordagem: em vez de simplesmente comparar trechos de código contra uma lista de padrões conhecidos de vulnerabilidade, o sistema constrói um modelo de segurança da aplicação inteira — mapeando pontos de entrada, fronteiras de confiança, fluxos de dados e lógica de autorização — e raciocina sobre o comportamento real do sistema, da mesma forma que um pesquisador de segurança experiente faria, mas operando na velocidade de uma máquina.

    O problema que a ferramenta resolve

    Times de desenvolvimento enfrentam uma tensão constante: as ferramentas SAST tradicionais são rápidas e confiáveis para capturar padrões conhecidos — como uma injeção de SQL, uma saída sem escape ou uma credencial codificada diretamente no código. Mas aplicações modernas são sistemas complexos, compostos por serviços, APIs, fronteiras de confiança e lógica de autorização distribuída.

    As vulnerabilidades mais perigosas raramente são violações de uma única linha. Elas costumam ser lacunas sistêmicas: uma função de validação que cobre quatro de cinco casos, um endpoint que não tem a anotação de autorização que todos os seus vizinhos têm, ou uma codificação aplicada em um contexto mas esquecida em outro. Revisões manuais de segurança conseguem encontrar esses problemas, mas são caras, lentas e não acompanham o ritmo do desenvolvimento moderno.

    A revisão completa de repositório foi construída exatamente para fechar essa lacuna — funcionando como um pesquisador de segurança automatizado que lê e raciocina sobre todo o repositório, e não apenas sobre linhas ou arquivos isolados.

    Como funciona: quatro etapas de análise

    A funcionalidade opera em quatro estágios que espelham a forma como um engenheiro de segurança experiente conduz uma avaliação.

    1. Criação do perfil da aplicação

    O scanner começa lendo o repositório completo e construindo um modelo de segurança da aplicação. Esse modelo inclui pontos de entrada, fronteiras de confiança, fluxos de dados, invariantes de autorização e as defesas já existentes. Todos os arquivos-fonte são considerados, tornando as decisões de cobertura explícitas em vez de implícitas. O resultado é uma compreensão estruturada do que a aplicação faz e onde está sua superfície de ataque.

    2. Busca por vulnerabilidades

    Um orquestrador lê o perfil de segurança, raciocina sobre a superfície de ataque e despacha agentes especializados para os componentes de maior risco. Cada agente recebe uma missão com escopo definido — módulos específicos, contexto de ameaça e perguntas adversariais. Os agentes têm liberdade para seguir importações e chamadores além do escopo inicial quando uma pista os leva nessa direção.

    3. Triagem e deduplicação

    Os candidatos a vulnerabilidade são deduplicados (mesmo ponto de injeção, mesma causa raiz) e o ruído de baixa confiança é filtrado antes da fase de validação.

    4. Validação independente

    Para cada candidato, um validador independente relê o código-fonte e traça a cadeia de ataque completa. O validador argumenta nos dois sentidos: busca razões pelas quais o achado pode não ser uma vulnerabilidade (controles compensatórios, design intencional) e razões pelas quais é uma (caminhos alternativos de ataque, casos extremos). Um achado só é descartado quando as evidências contra ele são tão sólidas quanto as que o promoveram.

    Esse processo gera achados com seções estruturadas de Verificado e Não foi possível verificar, para que o time saiba exatamente o que o scanner confirmou no código e o que depende do ambiente de implantação.

    O que torna essa abordagem diferente

    A revisão completa de repositório se diferencia da análise estática tradicional em dois aspectos fundamentais: ela raciocina sobre o comportamento real da aplicação em vez de comparar padrões conhecidos, e apresenta os achados com evidências estruturadas que tornam a incerteza explícita — não escondida.

    Raciocínio contextual, não correspondência de padrões

    Como o scanner constrói um modelo de segurança antes de buscar vulnerabilidades, ele raciocina sobre o comportamento real da aplicação. Um exemplo concreto citado pela AWS ilustra bem isso: havia uma vulnerabilidade de injeção de SQL em uma stored procedure. Uma ferramenta SAST tradicional sinalizaria a chamada específica de EXECUTE IMMEDIATE. O scanner foi mais fundo — identificou que a função central de validação não bloqueia aspas simples em nenhum dos cinco perfis de regex, listou todos os cinco perfis pelo nome, explicou por que aspas simples importam para o banco de dados específico, e apontou que outra stored procedure ignora completamente a função de validação. Em vez de uma correção pontual em um único local, o achado levou a uma remediação abrangente da lacuna sistêmica.

    Em outro caso, o scanner encontrou uma vulnerabilidade de XSS (Cross-Site Scripting) onde um valor era adicionado a um campo sem codificação HTML. O mesmo valor era corretamente codificado com Encode.forHtml() em um contexto diferente dentro do mesmo arquivo. Ferramentas de correspondência de padrões não percebem isso porque a função de codificação está presente — mas a vulnerabilidade é a inconsistência, e detectá-la exige compreender o comportamento da aplicação em diferentes caminhos de código.

    Achados validados com incerteza transparente

    Cada achado é estruturado para facilitar a triagem pelo time de desenvolvimento:

    • Problema: O que o código faz de errado, com referências específicas de arquivo e linha.
    • Impacto: O que um atacante ganha, com detalhes sobre o contexto de implantação.
    • Verificado e não foi possível verificar: O que o scanner confirmou diretamente no código versus o que depende do ambiente (segmentação de rede, comportamento em tempo de execução).
    • Remediação: Sugestões concretas de correção com mudanças específicas de código, não orientações genéricas.
    • Severidade e confiança: Calibrados de forma independente. A severidade reflete o impacto se a vulnerabilidade for explorável; a confiança reflete quanto da cadeia de ataque foi verificada no código.

    Como se encaixa no fluxo de trabalho de segurança

    A revisão completa de repositório foi projetada para complementar — não substituir — as ferramentas de segurança já existentes. A AWS sugere três cenários de uso principais:

    • Antes de revisões de segurança: Executar a análise antes de agendar um teste de penetração ou revisão de segurança. Isso faz com que os problemas óbvios e semi-óbvios já sejam resolvidos, liberando o time de segurança para focar nas questões sutis de design que exigem julgamento humano.
    • Ao integrar código adquirido ou open source: A funcionalidade é especialmente valiosa quando o time herda código por meio de aquisições, dependências de fornecedores ou componentes open source. O scanner constrói um modelo de segurança do zero, sem precisar de conhecimento institucional da base de código.
    • Durante revisões de arquitetura: Como o scanner raciocina sobre fronteiras de confiança, fluxos de dados e invariantes de autorização, seus achados frequentemente revelam problemas arquiteturais — não apenas bugs de implementação. Revisar os resultados junto com os modelos de ameaça ajuda a validar suposições sobre como os componentes interagem.

    Para quem quiser começar, a AWS disponibilizou um guia de início rápido para configurar e executar a revisão completa de repositório com o AWS Security Agent.

    Disponibilidade e preço

    A revisão completa de repositório está disponível hoje em prévia, sem custo adicional para clientes do AWS Security Agent. Durante o período de prévia, a AWS está priorizando o acesso antecipado gratuito para que os times possam fortalecer suas bases de código e compartilhar aprendizados que beneficiem toda a indústria.

    Para habilitar a funcionalidade e executar a primeira varredura, acesse o console do AWS Security Agent. Mais detalhes técnicos estão disponíveis na documentação oficial do AWS Security Agent.

    Fonte

    AWS Security Agent full repository code scanning feature now available in preview (https://aws.amazon.com/blogs/security/aws-security-agent-full-repository-code-scanning-feature-now-available-in-preview/)

  • Treinamento virtual gratuito: pratique com os serviços de segurança da AWS

    Workshops gratuitos de segurança na AWS

    Para quem quer fortalecer a postura de segurança da organização na Amazon Web Services (AWS), mas não sabe por onde começar, a AWS disponibiliza os Security Activation Days — workshops virtuais gratuitos e práticos, pensados para que os participantes saiam de cada sessão com experiência real nos serviços de segurança da plataforma.

    O que esperar dos eventos

    Cada Security Activation Day é um workshop virtual com duração de 3 a 6 horas. Durante a sessão, os participantes trabalham diretamente com os serviços de segurança da AWS em cenários do mundo real. A dinâmica combina apresentações, demonstrações e atividades práticas guiadas por especialistas de segurança da AWS — seja no próprio ambiente do participante ou em um sandbox (ambiente isolado de testes) fornecido pela AWS.

    Os temas variam e cobrem o espectro completo de serviços de segurança, identidade e governança da AWS, incluindo:

    • Detecção de ameaças e resposta a incidentes
    • Gerenciamento de identidade e acesso
    • Proteção de rede e aplicações
    • Proteção de dados
    • Governança e conformidade

    O objetivo é que cada participante saia com conhecimento aplicável imediatamente às suas cargas de trabalho — não com uma lista de tarefas para pesquisar depois.

    Para quem é indicado

    Os Security Activation Days são voltados para quem constrói e opera ambientes na nuvem: engenheiros de segurança, arquitetos de nuvem e times de DevOps que querem se aprofundar em capacidades específicas de segurança da AWS. Tanto quem está avaliando um serviço pela primeira vez quanto quem já o implantou e quer operacionalizá-lo melhor encontra valor nessas sessões.

    O que os participantes dizem

    Com mais de 6.400 participantes em mais de 90 eventos realizados até agora em 2026, os Security Activation Days mantêm uma avaliação média de 4,8 em 5. O formato prático é o principal diferencial apontado pelos participantes: não há substituto para configurar um serviço de verdade e ver os resultados em tempo real.

    Como se inscrever

    Os eventos acontecem ao longo do ano, em todos os fusos horários, com novas sessões sendo adicionadas regularmente. Para encontrar uma sessão e começar a aprender na prática, acesse a página de inscrições e comece a construir hoje mesmo.

    Fonte

    Complimentary virtual training: Get hands-on with AWS Security Services (https://aws.amazon.com/blogs/security/complimentary-virtual-training-get-hands-on-with-aws-security-services/)

  • AWS Client VPN passa a suportar Ubuntu 26.04 LTS

    Suporte ao Ubuntu 26.04 LTS chega ao AWS Client VPN

    A AWS expandiu a compatibilidade do seu cliente de Rede Privada Virtual (VPN) para desktop: o AWS Client VPN agora oferece suporte ao Ubuntu 26.04 LTS, a versão mais recente com suporte de longo prazo (LTS — Long-Term Support) do Ubuntu Linux.

    Com essa atualização, equipes que utilizam Linux no dia a dia — especialmente em ambientes corporativos que adotam o Ubuntu como sistema padrão — podem conectar suas máquinas com a versão mais atual do sistema operacional diretamente às redes da AWS ou a redes locais (on-premises), sem precisar recorrer a versões mais antigas do Ubuntu.

    O que é o AWS Client VPN?

    Para quem ainda não conhece o serviço: o AWS Client VPN é um serviço gerenciado da AWS que permite conectar com segurança trabalhadores remotos tanto a recursos hospedados na AWS quanto a redes corporativas locais. É uma solução voltada para o acesso remoto seguro de equipes distribuídas.

    O cliente de desktop é gratuito e pode ser baixado diretamente pelo site da AWS.

    Quais sistemas operacionais são suportados?

    Com a inclusão do Ubuntu 26.04 LTS, o AWS Client VPN passa a cobrir um conjunto bastante amplo de plataformas. Veja o panorama atual de compatibilidade:

    • Linux (Ubuntu): versões 22.04 LTS, 24.04 LTS e agora 26.04 LTS
    • macOS: Sonoma 14.0, Sequoia 15.0 e Tahoe 26.0
    • Windows: Windows 11

    Vale destacar também que o cliente já oferece suporte à arquitetura ARM64 para macOS e Windows, o que é especialmente relevante para quem utiliza Macs com chip Apple Silicon.

    Disponibilidade e custos

    A nova versão do cliente com suporte ao Ubuntu 26.04 LTS está disponível em todas as regiões onde o AWS Client VPN já está em disponibilidade geral (generally available), sem qualquer custo adicional.

    Saiba mais

    Para quem quiser se aprofundar no serviço, a AWS disponibiliza recursos oficiais:

    Fonte

    AWS Client VPN now supports Ubuntu OS version 26.04 LTS (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-client-vpn-ubuntu-26/)

  • AWS conquista certificações SNI 27017, SNI 27018 e SNI 9001 na Região Ásia-Pacífico (Jacarta)

    AWS avança em conformidade na Indonésia com três novas certificações nacionais

    A Amazon Web Services (AWS) acaba de conquistar três certificações do Padrão Nacional Indonésio — o Standar Nasional Indonesia (SNI) — para a sua Região Ásia-Pacífico (Jacarta). As certificações obtidas são: SNI ISO/IEC 27017:2015, SNI ISO/IEC 27018:2019 e SNI ISO 9001:2015.

    O SNI é o framework de padrões nacionais da Indonésia, com aplicação ampla em diferentes setores da economia do país. Conquistar essas certificações significa que os serviços da AWS atendem a requisitos formalmente reconhecidos pelo governo indonésio.

    Como as certificações foram obtidas

    A avaliação foi conduzida por um auditor terceiro independente, credenciado pelo Komite Akreditasi Nasional (KAN) — o Comitê Nacional de Acreditação da Indonésia. O processo seguiu os requisitos regulatórios locais aplicáveis, o que oferece aos clientes uma validação confiável e reconhecida regionalmente para suas necessidades de conformidade.

    O que cada certificação significa na prática

    • SNI 27017: baseada na norma internacional ISO/IEC 27017, adiciona controles de segurança específicos para ambientes de nuvem, complementando a ISO/IEC 27001. Ajuda organizações a executar cargas de trabalho com mais segurança e reduz o esforço em avaliações de segurança.
    • SNI 27018: focada na proteção de Informações de Identificação Pessoal (PII) em nuvens públicas. Confirma que a AWS trata os dados dos clientes em conformidade com padrões internacionais de privacidade.
    • SNI 9001: estabelece sistemas de gestão da qualidade que garantem entrega consistente de serviços e melhoria contínua nas operações da AWS.

    AWS se torna a primeira provedora com as quatro certificações SNI

    Somadas à certificação SNI 27001, conquistada em 2023, a AWS se torna agora a primeira provedora de serviços de nuvem (CSP) a deter as quatro certificações SNI — SNI 27001, SNI 27017, SNI 27018 e SNI 9001. Esse conjunto demonstra alinhamento abrangente com os padrões nacionais da Indonésia em segurança da informação, segurança em nuvem, privacidade e gestão da qualidade, ajudando clientes a atender a uma ampla gama de exigências regulatórias e de gestão de riscos.

    Como acessar os certificados e verificar os serviços cobertos

    Os certificados correspondentes estão disponíveis pelo AWS Artifact, o portal de autoatendimento da AWS para acesso sob demanda à documentação de conformidade. Para consultar a lista completa de serviços cobertos pelas certificações SNI, acesse a página de serviços em escopo da AWS.

    A AWS segue expandindo o escopo de seus programas de conformidade para ajudar clientes a atenderem seus requisitos arquiteturais, de negócios e regulatórios. Para mais informações sobre essas certificações, o recomendado é entrar em contato com o time de contas AWS.

    Fonte

    AWS achieves SNI 27017, SNI 27018, and SNI 9001 certifications for the AWS Asia Pacific (Jakarta) Region (https://aws.amazon.com/blogs/security/aws-achieves-sni-27017-sni-27018-and-sni-9001-certifications-for-the-aws-asia-pacific-jakarta-region/)

  • Resumo de Segurança AWS: Tudo que Aconteceu em Abril de 2026

    Visão Geral do Mês

    Todo mês, o blog de segurança da AWS consolida os principais lançamentos, posts técnicos, amostras de código e boletins de vulnerabilidades em um único digest. Abril de 2026 foi especialmente movimentado: o tema central foi a segurança de sistemas de IA agêntica, mas o mês também trouxe avanços importantes em proteção de dados, resposta a incidentes e conformidade em escala organizacional. Veja abaixo o que foi publicado e o que merece atenção imediata no seu ambiente.

    Posts do Blog de Segurança AWS

    Os artigos de abril cobriram cinco grandes áreas: identidade e controle de acesso, segurança de IA, governança e conformidade, detecção e resposta a incidentes, e proteção de dados.

    Identidade e Controle de Acesso

    Dois posts exploraram o tema de políticas e controle de acesso com profundidade prática. O primeiro, Controle de acesso com session tags do IAM Identity Center, ensina a combinar permission sets do AWS IAM Identity Center com session tags provenientes do Microsoft Entra ID para implementar Controle de Acesso Baseado em Atributos (ABAC) de forma granular em múltiplas contas AWS.

    O segundo, Dá para fazer isso com uma policy? Entendendo a Referência de Autorização de Serviços da AWS, orienta como usar a AWS Service Authorization Reference para descobrir o que é possível alcançar com políticas IAM, identificar cenários que exigem abordagens alternativas e construir controles de segurança mais eficazes.

    Segurança de IA

    Este foi o bloco mais denso do mês, com cinco publicações dedicadas ao tema.

    O post Padrões de acesso seguro para agentes de IA em recursos AWS usando o Model Context Protocol apresenta três princípios fundamentais: privilégio mínimo, governança de papéis organizacionais e diferenciação entre ações iniciadas por IA e por humanos — tudo no contexto do protocolo MCP.

    Já Quatro princípios de segurança para sistemas de IA agêntica sistematiza as recomendações da AWS em resposta ao NIST: ciclo de vida de desenvolvimento seguro, controles tradicionais adaptados, aplicação determinística de regras externas e autonomia conquistada por meio de avaliação contínua.

    O artigo Projetando confiança e segurança em aplicações com Amazon Bedrock trata da integração de conceitos de IA responsável em aplicações baseadas no Amazon Bedrock, cobrindo detecção de abuso, monitoramento com Amazon CloudWatch, configuração do Bedrock Guardrails e o processo de resposta a abusos.

    O post de maior repercussão do mês foi Construindo defesas de IA em escala: antes das ameaças surgirem. Nele, o CISO da AWS anuncia o Project Glasswing em parceria com a Anthropic, apresentando o Claude Mythos Preview para pesquisa de vulnerabilidades, além da disponibilidade geral do AWS Security Agent para testes de penetração autônomos.

    Governança e Conformidade

    O post Conformidade de tags com Shift-Left usando AWS Organizations e Terraform mostra como validar conformidade de tags ainda durante o desenvolvimento, combinando políticas de tags do AWS Organizations, um módulo Terraform reutilizável e uma abordagem orientada a testes que valida dinamicamente contra políticas organizacionais ativas.

    Detecção e Resposta a Incidentes

    Três publicações cobriram esse domínio. O artigo O que a atualização do Catálogo de Técnicas de Ameaças de março de 2026 significa para seu ambiente AWS, produzido pela equipe CIRT da AWS, detalha três novas técnicas: abuso de refresh token do Amazon Cognito, exclusão de imagens AMI para comprometer a recuperação e modificações em trust policies para persistência e escalada de privilégios.

    Em Um framework para coletar artefatos forenses com segurança em buckets S3, a AWS descreve como realizar coleta forense segura no Amazon S3 usando credenciais temporárias com privilégio mínimo via AWS STS session policies e fluxos automatizados com AWS Step Functions.

    O terceiro post, Transformando logs de segurança para o formato OCSF com uma solução ETL orientada a configuração, apresenta uma solução do AWS ProServe que converte logs personalizados para o formato Open Cybersecurity Schema Framework (OCSF) usando AWS Step Functions, AWS Glue ou Amazon EMR Serverless, com integração ao Amazon Security Lake.

    Vale mencionar ainda o artigo Um guia técnico de segurança multicloud full-stack com AWS Security Hub Extended, que explica como essa extensão simplifica a aquisição e operação de segurança em ambientes multicloud por meio de soluções de parceiros curadas, faturamento unificado e consolidação de findings baseada em OCSF.

    Proteção de Dados

    Três posts abordaram proteção de dados com foco em criptografia avançada.

    O artigo Protegendo seus segredos dos riscos quânticos do futuro orienta como atualizar clientes do AWS Secrets Manager para usar TLS pós-quântico híbrido com ML-KEM, protegendo segredos contra ataques do tipo “harvest-now-decrypt-later” (capturar agora, descriptografar depois), com verificação de conexões via AWS CloudTrail.

    Em Como o AWS KMS e o AWS Encryption SDK superam os limites da criptografia simétrica, a AWS explica como o AWS Key Management Service e o SDK de criptografia usam métodos de chave derivada para gerenciar automaticamente os limites do AES-GCM, eliminando a necessidade de rotação manual de chaves.

    Por fim, Como clonar um cluster AWS CloudHSM entre regiões detalha o uso do comando CopyBackupToRegion para replicar clusters do AWS CloudHSM para outra região e sincronizar chaves — inclusive chaves não exportáveis — para fins de recuperação de desastres.

    Boletins de Segurança de Abril

    A AWS divulgou investigações de vulnerabilidades em vários produtos e serviços ao longo do mês. Abaixo estão os boletins publicados — verifique se algum deles afeta componentes do seu ambiente e aplique os patches recomendados:

    Amostras de Código AWS (AWS Samples)

    Abril trouxe 16 novos repositórios prontos para uso, cobrindo identidade, governança, conformidade, detecção e resposta, segurança de IA, proteção de dados e infraestrutura. Veja os destaques por categoria:

    Identidade

    Governança

    Conformidade

    • Compliance Lens — Solução serverless que analisa snapshots do AWS Config em toda uma organização AWS, compara com conjuntos de regras de conformidade e visualiza o posicionamento de conformidade via Amazon QuickSight.
    • Configuração Terraform para o AWS Security Agent — Provisionamento de recursos do AWS Security Agent usando o provider Terraform AWSCC, automatizando criação de espaço de agente, roles IAM, registro de domínio alvo e configuração de testes de penetração.

    Detecção e Resposta a Incidentes

    Proteção de Dados

    Infraestrutura e Segurança de IA

    O que Fica de Lição do Mês

    Abril de 2026 deixa claro que proteger cargas de trabalho de IA exige o mesmo rigor aplicado à infraestrutura tradicional — e, em alguns aspectos, ainda mais atenção. Os posts e amostras deste mês oferecem padrões concretos para aplicar privilégio mínimo em sistemas agênticos, automatizar governança em escala organizacional e preparar implementações criptográficas para os requisitos pós-quânticos que se aproximam.

    Os boletins de segurança cobrem vulnerabilidades em camadas de computação, rede e ferramentas de desenvolvimento — reforçando a necessidade de aplicar patches de forma consistente e sem atraso. Cada recurso listado aqui inclui etapas de implantação ou código executável para que você possa validar a abordagem no seu próprio ambiente antes de adotá-la em produção.

    Fonte

    ICYMI: April 2026 @AWS Security (https://aws.amazon.com/blogs/security/icymi-april-2026-aws-security/)

  • Amazon SageMaker Unified Studio ganha recursos de gerenciamento de identidade e usuários

    Mais controle para administradores no SageMaker Unified Studio

    A AWS anunciou novos recursos de administração no Amazon SageMaker Unified Studio que ampliam o controle sobre configuração de identidade e gerenciamento de usuários. As novidades atendem tanto domínios do tipo IAM quanto domínios do tipo Identity Center, tornando a gestão de times mais flexível e centralizada.

    O que muda nos domínios IAM do SageMaker

    Para quem utiliza domínios IAM no SageMaker Unified Studio, agora é possível integrar o AWS IAM Identity Center para permitir que usuários acessem a plataforma via single sign-on (autenticação única). Com essa configuração, os administradores podem adicionar como membros de projetos:

    • Funções IAM (IAM roles)
    • Usuários IAM (IAM users)
    • Usuários do IAM Identity Center
    • Grupos do IAM Identity Center

    Isso significa que equipes conseguem colaborar nos dados e recursos de um projeto mesmo que cada membro se autentique de uma forma diferente. A configuração da integração com o IAM Identity Center é feita diretamente pelo portal de administração do SageMaker Unified Studio.

    Outro recurso relevante para domínios IAM é a nova página de gerenciamento de usuários do domínio, que oferece uma visão consolidada de todos os usuários ativos. A partir dessa tela única, os administradores conseguem gerenciar acessos e atualizar permissões sem precisar navegar por múltiplas interfaces.

    O que muda nos domínios Identity Center do SageMaker

    Nos domínios Identity Center, a novidade é a possibilidade de usuários acessarem o portal do SageMaker Unified Studio por meio de federação via função IAM. A plataforma passa a criar uma sessão de usuário única para cada pessoa que acessa de forma federada — o que resolve um problema prático importante: quando múltiplos usuários compartilham a mesma função IAM, eles não sobrescrevem mais o trabalho uns dos outros.

    Além disso, os administradores agora conseguem auditar ações individuais mesmo em cenários onde vários usuários compartilham uma única função IAM, o que melhora significativamente a rastreabilidade e a governança.

    Flexibilidade para equipes com diferentes métodos de autenticação

    Com essas atualizações, as equipes podem utilizar tanto identidade IAM quanto identidade corporativa via IAM Identity Center nos dois tipos de domínio do SageMaker Unified Studio. O resultado prático é maior flexibilidade para colaboração, independentemente de como cada membro do time realiza sua autenticação.

    Disponibilidade regional

    Os novos recursos já estão disponíveis nas seguintes regiões AWS: Ásia-Pacífico (Mumbai, Seul, Singapura, Sydney e Tóquio), Canadá (Central), Europa (Frankfurt, Irlanda, Londres, Paris e Estocolmo), América do Sul (São Paulo), Leste dos EUA (Virgínia do Norte e Ohio) e Oeste dos EUA (Oregon).

    Para aprofundar o entendimento sobre as configurações disponíveis, a AWS disponibiliza a documentação oficial do SageMaker Unified Studio.

    Fonte

    Amazon SageMaker Unified Studio adds identity and user management features (https://aws.amazon.com/about-aws/whats-new/2026/05/smus-identity-user-management/)