Category: Uncategorized

  • Agente de Investigação do Amazon GuardDuty: avaliação de ameaças com IA sob demanda

    O que é o agente de investigação do GuardDuty

    A AWS anunciou a prévia pública do agente de investigação do Amazon GuardDuty, uma nova capacidade que usa inteligência artificial para investigar achados de segurança no ambiente Amazon Web Services (AWS) de forma automática e sob demanda. O objetivo declarado é reduzir o tempo de investigação de horas para minutos.

    O GuardDuty já é o serviço gerenciado de detecção de ameaças da AWS, monitorando continuamente contas e workloads em busca de atividades suspeitas. O agente de investigação chega como uma camada adicional: em vez de deixar o analista correlacionar dados manualmente em múltiplas ferramentas, ele automatiza essa correlação e entrega inteligência acionável diretamente no serviço.

    O acesso acontece via Console de Gerenciamento da AWS, Interface de Linha de Comando (AWS CLI), APIs ou SDKs da AWS.

    Principais capacidades

    Cada investigação concluída retorna um conjunto estruturado de informações:

    • Nível de risco: Info, Baixo, Médio, Alto ou Crítico
    • Confiança: Desconhecida, Baixa, Média ou Alta
    • Resumo: narrativa das observações e achados principais
    • Detalhes da investigação: contexto adicional sobre o incidente
    • Ações recomendadas: passos priorizados de remediação, incluindo comandos AWS CLI
    • Mapeamento MITRE ATT&CK®: técnicas de ataque e recursos AWS afetados

    O escopo da investigação pode ser definido para um achado específico, uma conta individual ou todas as contas da organização. Via AWS CLI e API, é possível usar um campo de texto livre de até 2.048 caracteres para descrever em linguagem natural o que deve ser investigado — permitindo indicar áreas de preocupação, causas raiz suspeitas ou prioridades de análise.

    As APIs do agente de investigação também estão disponíveis pelo servidor MCP da AWS, parte do Agent Toolkit for AWS, o que permite integrá-las em fluxos de trabalho com IA e nas cadeias de ferramentas de segurança já existentes.

    Como o agente analisa os achados

    Ao criar uma investigação, o agente usa inferência entre regiões (Cross-Region Inference) para processar os achados conforme o escopo definido. O serviço CRIS (Serviço de Inferência Entre Regiões) seleciona a região AWS mais adequada dentro da mesma geografia para processar a avaliação. Os dados permanecem armazenados apenas na região de origem da requisição, mas os dados e resultados da investigação podem ser processados fora dessa região. A transmissão ocorre de forma criptografada pela rede segura da Amazon. A tabela de roteamento de inferência pode ser consultada na seção de investigação do Guia do Usuário do Amazon GuardDuty.

    Pré-requisitos e permissões de Gerenciamento de Identidade e Acesso (IAM)

    Para usar o agente de investigação, é necessário ter o Amazon GuardDuty habilitado em uma conta em uma região suportada. Três novas permissões de IAM são exigidas:

    • guardduty:CreateInvestigation — para iniciar novas investigações
    • guardduty:GetInvestigation — para recuperar resultados
    • guardduty:ListInvestigations — para listar investigações de um detector

    Exemplo de política IAM:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "guardduty:CreateInvestigation",
            "guardduty:GetInvestigation",
            "guardduty:ListInvestigations"
          ],
          "Resource": "*"
        }
      ]
    }

    Modelo de autorização

    Contas administradoras podem criar investigações, recuperar resultados e listar investigações para si mesmas e para suas contas membros. Contas membros só podem recuperar resultados e listar investigações da própria conta — não podem criar investigações nem acessar investigações de outras contas ou da conta administradora. A especificação do ID de conta só é necessária ao investigar uma conta membro específica.

    Como habilitar e criar a primeira investigação

    Com as permissões IAM configuradas, o processo pelo console segue os passos abaixo:

    1. Acesse o Console de Gerenciamento da AWS na região suportada desejada e navegue até o Amazon GuardDuty.
    2. No painel de navegação, selecione Investigations.
    3. Se as investigações não estiverem habilitadas, acesse Go to Settings e ative a funcionalidade.
    4. Após habilitar, volte à página de investigações e selecione Initiate Investigation.
    5. Escolha o escopo: um Finding ID específico, um ID de conta AWS, ou todas as contas da organização.
    6. Clique em Initiate investigation e aguarde a conclusão — tipicamente 2 a 5 minutos para nível de conta e 10 a 12 minutos para achados específicos durante a prévia.

    Ao concluir, a investigação apresenta: informações gerais (ID, status, conta que disparou, timestamp), resumo narrativo, mapeamento de técnicas de ataque e recursos afetados, avaliação de ameaça com nível de risco e pontuação de confiança, e ações recomendadas priorizadas.

    Executando investigações via AWS CLI

    As investigações são assíncronas — o agente consulta múltiplas fontes de dados, correlaciona achados entre serviços e realiza análise com IA. Após criar uma investigação, é necessário verificar periodicamente o status até a conclusão.

    Passo 1: Localizar o ID do detector

    Cada implantação do GuardDuty tem um ID de detector único por conta e por região. Para encontrá-lo:

    aws guardduty list-detectors --region=us-east-1

    Resposta esperada:

    {
      "DetectorIds": [
        "12abc34d567e8fa901bc2d34eexample"
      ]
    }

    Para evitar repetição ao trabalhar sempre na mesma região, é possível definir uma variável de ambiente (exemplo no Linux):

    export AWS_DEFAULT_REGION=us-east-1

    Passo 2: Criar uma investigação

    Para investigar um achado específico:

    aws guardduty create-investigation us-east-1 \
      --detector-id 12abc34d567e8fa901bc2d34eexample \
      --trigger-prompt "Investigate this finding ID 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"

    Para investigar todos os achados de uma conta:

    aws guardduty create-investigation --region=us-east-1 \
      --detector-id 12abc34d567e8fa901bc2d34eexample \
      --trigger-prompt "Investigate findings in Account 123456789012"

    Para investigar toda a organização:

    aws guardduty create-investigation --region=us-east-1 \
      --detector-id 12abc34d567e8fa901bc2d34eexample \
      --trigger-prompt "Investigate findings across my AWS Organization"

    A resposta retorna o ID da investigação:

    {
      "InvestigationId":"a1b2c3d4-5678-90ab-cdef-ef1234567890"
    }

    Passo 3: Verificar o status da investigação

    aws guardduty get-investigation --region=us-east-1 \
      --detector-id 12abc34d567e8fa901bc2d34eexample \
      --investigation-id a1b2c3d4-5678-90ab-cdef-ef1234567890 \
      --query 'Investigation.Status'

    Repita o comando até o campo Status mostrar COMPLETED. Verificar a cada 30 segundos é suficiente. Os valores possíveis são: RUNNING, COMPLETED e FAILED. Em caso de falha, verifique a mensagem de erro e confirme se as permissões estão de acordo com o modelo de autorização.

    Para listar todas as investigações de um detector:

    aws guardduty list-investigations --region=us-east-1 \
      --detector-id 12abc34d567e8fa901bc2d34eexample \
      --max-results=10

    Os endpoints de API disponíveis são: CreateInvestigation, GetInvestigation e ListInvestigations.

    Integração em pipelines de segurança existentes

    O design orientado a API do agente de investigação resolve um padrão comum: equipes que já encaminham achados do GuardDuty para ferramentas de terceiros via Amazon EventBridge podem adicionar uma função AWS Lambda no pipeline. Essa função chama CreateInvestigation com o ID do achado, aguarda a conclusão e repassa os resultados enriquecidos — nível de risco, pontuação de confiança, mapeamento MITRE ATT&CK e ações recomendadas — para o Sistema de Informação e Gerenciamento de Eventos de Segurança (SIEM) junto ao achado original.

    Com isso, achados críticos vão diretamente para a fila de resposta a incidentes, enquanto achados de baixo risco com alta confiança podem ser fechados automaticamente ou agrupados para revisão semanal. O analista passa de correlação manual de logs para validação de avaliações e ação em ameaças confirmadas.

    O agente de investigação é especializado em achados do GuardDuty e é distinto de outros agentes da AWS, como o AWS Security Agent e o AWS DevOps Agent.

    Integração com o servidor MCP da AWS

    O Protocolo de Contexto de Modelo (MCP) é um padrão aberto que permite que assistentes de IA se conectem de forma segura a fontes de dados e ferramentas externas. Como o servidor MCP da AWS implementa esse padrão para serviços AWS, é possível invocar investigações do GuardDuty por linguagem natural em ferramentas como Kiro, Claude da Anthropic ou outros clientes compatíveis com MCP.

    Exemplos de prompts em linguagem natural que o agente suporta:

    • “Investigate the latest high-severity finding in my production account”
    • “Create an investigation for finding ID abc123 in account 987654321098 and summarize what happened”
    • “List investigations from the last 24 hours and flag those that need human review”

    Relação com o AWS Security Incident Response

    O agente de investigação do GuardDuty e o AWS Security Incident Response (AWS SIR) atuam em estágios diferentes do fluxo de segurança. O agente de investigação oferece avaliação sob demanda: quando a equipe precisa de contexto mais profundo sobre um achado específico, uma postura de segurança de conta ou da organização inteira. O resultado é uma avaliação estruturada com níveis de risco, pontuações de confiança, mapeamentos MITRE ATT&CK e recomendações acionáveis.

    Já o AWS SIR é voltado para eventos de segurança ativos, onde há necessidade de automação com IA e expertise humana para coordenar contenção e recuperação. Quando um caso com suporte da AWS é criado via SIR, um agente de investigação SIR é ativado em paralelo com os engenheiros de resposta a incidentes da AWS.

    As equipes de segurança podem usar as duas capacidades de forma complementar: usar o agente do GuardDuty para avaliar e priorizar achados, escalar problemas confirmados com evidências de suporte e criar ou atualizar um caso no AWS SIR quando for necessário envolvimento adicional da AWS.

    Disponibilidade e preços

    A prévia pública do agente de investigação do GuardDuty está disponível em 10 regiões AWS: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm) e Asia Pacific (Tokyo).

    Durante a prévia pública, o agente de investigação está disponível sem custo adicional. O uso é limitado a 10 investigações por conta por dia, com limite cumulativo de 100 investigações por conta durante o período de prévia. Investigações com falha não contam para essas cotas.

    Para saber mais

    Fonte

    Introducing the Amazon GuardDuty investigation agent: on-demand AI-powered threat assessment (https://aws.amazon.com/blogs/security/introducing-the-amazon-guardduty-investigation-agent-on-demand-ai-powered-threat-assessment/)

  • Amazon GameLift Streams passa a suportar credenciais de função IAM em sessões de streaming

    O que mudou no Amazon GameLift Streams

    A AWS anunciou uma atualização importante no Amazon GameLift Streams: o serviço agora suporta a atribuição de funções do IAM (Gerenciamento de Identidade e Acesso) diretamente a sessões de streaming. Com isso, aplicações em execução dentro de uma sessão de streaming passam a acessar recursos da conta AWS — como buckets do Amazon S3 e tabelas do DynamoDB — de forma segura e sem a necessidade de gerenciar credenciais manualmente.

    Como funciona na prática

    A partir dessa atualização, é possível passar um parâmetro RoleArn ao iniciar uma sessão de streaming. A partir daí, a aplicação recebe automaticamente credenciais AWS de curta duração e com renovação automática, por meio da cadeia padrão de resolução de credenciais do SDK da AWS — sem necessidade de alterar nenhuma linha de código da aplicação.

    O mecanismo utilizado é o mesmo provedor de credenciais em contêineres já consolidado e confiável que está por trás das funções de tarefa do Amazon ECS e do Pod Identity do Amazon EKS. Ou seja, a AWS está trazendo para o GameLift Streams um padrão de segurança já bem estabelecido em outros serviços gerenciados da plataforma.

    Por que isso importa: o problema que existia antes

    Antes dessa funcionalidade, equipes que precisavam que suas aplicações em streaming acessassem serviços da AWS enfrentavam um dilema operacional e de segurança: ou embutiam chaves de acesso de longa duração diretamente nos pacotes da aplicação, ou as passavam como variáveis de ambiente. Ambas as abordagens são problemáticas — aumentam a superfície de ataque e dificultam a rotação e o gerenciamento dessas credenciais.

    Com o suporte a funções IAM, esse risco é eliminado. As credenciais são temporárias, renovadas automaticamente e gerenciadas pelo próprio GameLift Streams, sem intervenção manual.

    Validação e configuração simplificada

    Outro ponto relevante do anúncio é a experiência de diagnóstico: erros de configuração na função IAM são detectados e sinalizados no momento do início da sessão, com mensagens de erro claras — em vez de falhar silenciosamente durante a execução da aplicação. Isso reduz o tempo de depuração e facilita a identificação de problemas de permissão.

    Para facilitar ainda mais a adoção, a AWS também disponibilizou a configuração de funções IAM diretamente no console do Amazon GameLift Streams, com um modelo de política de confiança pré-preenchido para simplificar o processo de criação da função.

    Disponibilidade

    O suporte a funções IAM em sessões de streaming está disponível em todas as regiões da AWS onde o Amazon GameLift Streams já está disponível.

    Para saber mais sobre como configurar credenciais de sessão, a AWS disponibiliza documentação detalhada: Configuração de Credenciais de Sessão no Guia do Desenvolvedor do Amazon GameLift Streams.

    Fonte

    Amazon GameLift Streams now supports IAM role credentials for stream sessions (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-gamelift-streams-iam/)

  • Amazon Managed Grafana obtém autorização FedRAMP High no AWS GovCloud (US)

    O que foi anunciado

    A AWS anunciou que o Amazon Managed Grafana alcançou a autorização FedRAMP High nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West). Essa é uma conquista relevante para organizações que operam em ambientes com exigências rigorosas de conformidade e segurança, especialmente no contexto do setor público norte-americano.

    O que é o FedRAMP e por que ele importa

    O Programa Federal de Gerenciamento de Risco e Autorização (FedRAMP — Federal Risk and Authorization Management Program) é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo de produtos e serviços em nuvem. Em termos práticos, ele funciona como um “selo de aprovação” que garante que determinado serviço de nuvem atende aos requisitos de segurança exigidos por agências federais americanas.

    A classificação High é o nível mais elevado dentro do FedRAMP, destinado a sistemas que lidam com informações altamente sensíveis. Conquistar essa autorização significa que o Amazon Managed Grafana passou por um processo rigoroso de auditoria e pode ser utilizado por organizações com as exigências de conformidade mais criteriosas.

    Quem se beneficia dessa novidade

    Com a autorização FedRAMP High em vigor, os seguintes perfis de organização passam a poder utilizar o Amazon Managed Grafana dentro dos requisitos de conformidade exigidos:

    • Agências federais dos Estados Unidos
    • Organizações do setor público com obrigações regulatórias específicas
    • Empresas privadas que precisam atender a requisitos FedRAMP High em seus contratos ou operações

    Todas essas organizações agora podem usar o serviço para visualizar, consultar e configurar alertas sobre métricas operacionais em seus ambientes AWS e híbridos, sem abrir mão das exigências de segurança e conformidade.

    O que é o Amazon Managed Grafana

    Para quem não conhece o serviço: o Amazon Managed Grafana é uma solução totalmente gerenciada baseada no popular projeto open-source Grafana. Ele foi desenvolvido para facilitar a visualização e análise de dados operacionais em escala, eliminando a necessidade de instalar, configurar e manter a infraestrutura do Grafana manualmente. A AWS cuida de toda a gestão do serviço, enquanto os times de engenharia e operações focam no que realmente importa: os dados e os dashboards.

    Como saber mais

    Para quem deseja aprofundar o entendimento sobre o Amazon Managed Grafana no contexto do GovCloud, a AWS disponibiliza a documentação oficial do Amazon Managed Grafana para GovCloud. Também é possível acessar a página do produto para informações gerais sobre o serviço, ou entrar em contato diretamente com o time de conta AWS para orientações específicas.

    Fonte

    Amazon Managed Grafana achieves FedRAMP High authorization in AWS GovCloud (US) (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-managed-grafana-fedramp-high/)

  • Amazon Cognito passa a suportar importação de usuários com hashes de senha

    O que mudou no Amazon Cognito

    A AWS anunciou uma atualização relevante para quem trabalha com migrações de sistemas de autenticação: o Amazon Cognito agora suporta a importação de usuários com hashes de senha diretamente em arquivos CSV. Essa novidade resolve um ponto de atrito bastante comum em projetos de migração de identidade.

    Como era antes

    Até então, quando uma equipe precisava importar uma base de usuários para o Amazon Cognito via arquivo CSV, os usuários chegavam sem senha válida no novo sistema. Isso significava que cada pessoa precisava redefinir sua senha no primeiro acesso — uma experiência ruim para o usuário final e um obstáculo operacional para as equipes responsáveis pela migração.

    O que muda na prática

    Com a nova funcionalidade, é possível incluir o hash da senha de cada usuário diretamente no arquivo CSV de importação. No momento de criação do processo de importação, a equipe especifica qual algoritmo de hash foi utilizado pelo sistema de origem. O Amazon Cognito então importa esses usuários e, no primeiro login, verifica a senha informada contra o hash importado — tudo de forma transparente para o usuário final.

    O resultado prático é direto: os usuários migrados conseguem acessar o sistema imediatamente com as mesmas credenciais que já utilizavam, sem nenhuma interrupção no fluxo de autenticação.

    Algoritmos de hash suportados

    A AWS incluiu suporte aos principais algoritmos modernos de hash de senha utilizados pelo mercado:

    • bcrypt
    • scrypt
    • Argon2id
    • PBKDF2 com SHA-256

    Vale destacar que todos os hashes importados recebem uma camada adicional de proteção criptográfica antes de serem armazenados no Cognito. Ou seja, a AWS não apenas aceita o hash existente — ela reforça a segurança desses dados na camada de armazenamento.

    Disponibilidade e como começar

    A funcionalidade de importação com hash de senha está disponível em todas as regiões da AWS onde o Amazon Cognito já está presente. Para utilizá-la, basta criar um processo de importação de usuários pelo Console de Gerenciamento da AWS, pela Interface de Linha de Comando (CLI) da AWS ou pelos Kits de Desenvolvimento de Software (SDKs) da AWS. Para instruções detalhadas, a AWS disponibiliza o guia do desenvolvedor com o passo a passo completo.

    Por que isso importa

    Migrações de base de usuários são momentos críticos em qualquer projeto. Forçar uma redefinição de senha em massa gera atrito, aumenta chamados de suporte e pode comprometer a adoção do novo sistema. Com essa atualização, o Amazon Cognito passa a oferecer uma rota de migração muito mais fluida — especialmente para equipes que estão consolidando sistemas legados ou migrando de provedores de identidade terceiros para a AWS.

    Fonte

    Amazon Cognito now supports importing users with password hashes (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-cognito-password-hash-import/)

  • Security Hub ganha proteção para cargas de trabalho de IA e suporte multicloud para Microsoft Azure

    O Security Hub dá dois passos importantes

    O AWS Security Hub sempre foi posicionado como a base de operações de segurança para quem roda na AWS — um ponto central onde os sinais de risco são coletados, priorizados e transformados em ação. Agora, a AWS anunciou duas expansões significativas que ampliam esse papel de forma concreta: proteção dedicada a cargas de trabalho de Inteligência Artificial (IA) e monitoramento de segurança para ambientes Microsoft Azure.

    Ambas as direções vieram de demandas reais dos clientes, e juntas representam um movimento claro da AWS em direção a uma plataforma de segurança full-stack — ou seja, que cobre toda a pilha de tecnologia de uma empresa, independentemente de onde ela roda.

    Gerenciamento de segurança multicloud para o Microsoft Azure

    Muitas organizações já operam em mais de uma nuvem há anos. O problema é que, até agora, o Security Hub era focado exclusivamente no ambiente AWS. Essa lacuna começa a ser fechada: o Security Hub passa a descobrir e monitorar recursos do Microsoft Azure, incluindo Máquinas Virtuais (VMs), imagens de contêiner, Function Apps e identidades.

    A avaliação cobre problemas de configuração incorreta, exposição à internet e vulnerabilidades de software, com verificações de postura baseadas no CIS Microsoft Azure Foundations Benchmark™ — um padrão amplamente reconhecido do setor para boas práticas de segurança no Azure.

    O que torna isso relevante do ponto de vista operacional é a integração: as descobertas do Azure são priorizadas lado a lado com as descobertas da AWS, usando o mesmo formato de alerta, as mesmas automações e os mesmos fluxos de resposta. O time de segurança passa a trabalhar com uma visão unificada de risco, sem precisar alternar entre ferramentas diferentes para cada ambiente.

    Em termos de preço, os recursos do Azure são cobrados nas mesmas tarifas dos recursos equivalentes na AWS, sem taxas adicionais, e há um período de teste gratuito independente de 30 dias. Para mais detalhes, a AWS publicou um post no What’s New.

    Vale destacar que essa não é a primeira iniciativa multicloud do Security Hub. Anteriormente, a AWS já havia lançado o Security Hub Extended, que integra soluções de parceiros especializados em nove categorias de segurança — cobrindo endpoints, identidades, e-mail, navegadores e dados em qualquer nuvem ou ambiente on-premises. O suporte nativo ao Azure complementa essa estratégia, ampliando o que as próprias capacidades da AWS conseguem cobrir.

    Proteção para cargas de trabalho de IA

    O outro grande movimento anunciado é a proteção dedicada a workloads de IA. Equipes de desenvolvimento estão colocando modelos em produção em ritmo acelerado — usando Amazon Bedrock, SageMaker e AgentCore — mas os times de segurança frequentemente não têm visibilidade sobre o que está rodando, quem está invocando modelos e quais agentes estão orquestrando fluxos de trabalho.

    Um exemplo citado pela própria AWS ilustra bem o problema: um líder de segurança só descobriu que uma conta de serviço comprometida estava invocando um modelo de fundação milhares de vezes porque o time financeiro questionou a fatura. O incidente de segurança foi identificado por uma revisão contábil — não por uma ferramenta de segurança. Essa lacuna de visibilidade é real e já está gerando custos.

    Para endereçar isso, a AWS anunciou três lançamentos relacionados à segurança de IA.

    GuardDuty AI Protection (disponível para todos)

    O Amazon GuardDuty AI Protection é uma capacidade de detecção de ameaças construída especificamente para Bedrock e SageMaker. Ele detecta invocações anômalas de modelos, ataques de “colheita de custos” — onde credenciais comprometidas são usadas para rodar inferências às custas da vítima — e tentativas de injeção de prompt, por meio da integração com o Bedrock Guardrails.

    O mecanismo de detecção analisa dados de eventos do CloudTrail, aprende o padrão normal de invocação em escala e sinaliza desvios que indicam comprometimento ou abuso. A AWS destaca que esse tipo de detecção só é possível na escala da AWS, onde é possível observar o comportamento de milhões de workloads para definir o que é “normal”. O GuardDuty AI Protection está disponível para todos os clientes do GuardDuty com um período de teste gratuito de 30 dias.

    Investigações com IA no GuardDuty (em prévia)

    As investigações com IA do GuardDuty automatizam boa parte do trabalho manual de investigação que consome o tempo dos times de segurança e contribui para a fadiga de alertas. A capacidade analisa automaticamente as descobertas do GuardDuty e o contexto das contas envolvidas, separando ameaças reais de atividades benignas.

    O processo examina o contexto de cada descoberta, atividades relacionadas dos últimos 90 dias, recursos afetados e indicadores de ameaça — usando grafos de conhecimento e inteligência de ameaças para concluir em minutos o que antes levava horas. Cada investigação retorna uma avaliação de disposição com pontuação de confiança, classificação pelo framework MITRE ATT&CK®, evidências de suporte e recomendações claras para suprimir, conter ou remediar o problema. A funcionalidade está disponível em prévia em 10 regiões da AWS.

    Inventário de IA no Security Hub (disponível para todos)

    O terceiro lançamento é o inventário de IA do Security Hub — uma visão continuamente atualizada de todos os ativos de IA da organização e sua postura de segurança.

    O inventário descobre e cataloga cargas de trabalho de IA de duas formas: para serviços gerenciados, ele mapeia recursos do AWS Config no Bedrock, SageMaker e AgentCore; para workloads auto-hospedados e externos, ele identifica modelos rodando em EC2, ECS e EKS por meio de análise em tempo de execução, além de identificar endpoints de modelos externos que suas aplicações consomem.

    Cada ativo é mapeado à infraestrutura subjacente — incluindo computação, rede, funções do IAM (Gerenciamento de Identidade e Acesso) e armazenamentos de dados — e correlacionado com sinais de segurança, como descobertas do GuardDuty. Quando o GuardDuty AI Protection sinaliza uma invocação anômala, o inventário de IA mostra imediatamente qual infraestrutura está envolvida, o que está conectado a ela e onde ela se encaixa na ordem de prioridades.

    Esse recurso está disponível no plano Security Hub Essentials sem custo adicional.

    Uma abordagem diferente para segurança full-stack

    O que une todos esses lançamentos é uma filosofia de integração: não é necessário adquirir proteção de IA como um produto separado, nem montar operações isoladas para o Azure. Tudo é adicionado ao Security Hub que a equipe já opera, aparecendo na mesma visão priorizada de risco.

    Essa mesma lógica se aplica ao Security Hub Extended, que agora conta com 21 parceiros curados em nove categorias: 7AI, Britive, CrowdStrike, Idira (CyberArk), Cyera, Island, LayerX, Native Security, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, SentinelOne, Splunk, Sublime, Upwind, Varonis, Zenity e Zscaler. São soluções de referência em endpoint, identidade, e-mail, rede, dados, navegador, nuvem, IA e operações de segurança.

    Nenhum desses parceiros está presente por padrão — cada um foi selecionado com base em critérios de qualidade e comprometimento com uma visão compartilhada de segurança empresarial. O benefício comercial do Extended já é tangível hoje: precificação pay-as-you-go, fatura única na AWS, elegibilidade para o EDP (Programa de Desconto Empresarial) e sem compromissos de longo prazo.

    Mas o que a AWS descreve como o trabalho mais importante vai além da parte comercial. As descobertas de cada solução parceira são emitidas no formato OCSF (Framework Aberto de Esquema de Cibersegurança) e agregadas no Security Hub. A direção é construir uma correlação única entre todos eles, para que um sinal de uma solução de endpoint, uma de identidade e uma de nuvem se combinem em uma única exposição e um único caminho de ataque — em vez de três alertas desconectados. Para saber mais, a AWS publicou um post no What’s New sobre o Extended.

    O que esperar a seguir

    O panorama geral está ficando mais claro: o Security Hub está se expandindo em três direções simultaneamente. Primeiro, em cobertura de provedores de nuvem — começando pelo Azure, com outros clouds previstos. Segundo, em tipos de workload — com proteção e inventário específicos para IA. Terceiro, em categorias de segurança — por meio do Extended e seus parceiros curados.

    O que começou como uma ferramenta para organizar descobertas de segurança na AWS está se tornando a forma como empresas cada vez maiores operam segurança em toda a sua infraestrutura. A base é detecção e visibilidade. O que a AWS está construindo em cima disso é uma experiência que conecta sinais de todas as fontes confiáveis e ajuda os times a responder mais rápido.

    Fonte

    Security Hub adds AI workload protection and multicloud support for Microsoft Azure (https://aws.amazon.com/blogs/security/security-hub-adds-ai-workload-protection-and-multicloud-support-for-microsoft-azure/)

  • Autentique tráfego legítimo de agentes de IA com o AWS WAF Bot Control

    O problema de identificar bots legítimos em escala

    À medida que agentes de Inteligência Artificial (IA) e ferramentas automatizadas passam a acessar aplicações web com mais frequência, distinguir tráfego legítimo de tentativas maliciosas tornou-se um dos desafios centrais de segurança na nuvem. As abordagens tradicionais — como filtros baseados em Protocolo de Internet (IP) e consultas reversas de Sistema de Nomes de Domínio (DNS) — simplesmente não funcionam bem em ambientes multi-tenant, como o Amazon Bedrock AgentCore, onde milhares de cargas de trabalho distintas compartilham o mesmo espaço de IPs.

    Nesse cenário, atacantes conseguem facilmente falsificar cabeçalhos de agente de usuário, e listas de permissão manuais não acompanham o crescimento da demanda. Para endereçar esse problema, a AWS introduziu a Autenticação Web de Bots (WBA — Web Bot Authentication) no AWS WAF Bot Control em novembro de 2025.

    Como funciona a Autenticação Web de Bots (WBA)

    A WBA utiliza criptografia assimétrica para verificar identidades de bots por meio de assinaturas de mensagens HTTP. O mecanismo se apoia em dois rascunhos ativos da Força-Tarefa de Engenharia da Internet (IETF — Internet Engineering Task Force): um rascunho de diretório para compartilhamento de chaves públicas e um rascunho de protocolo que define como as chaves associam a identidade do crawler às requisições HTTP.

    O fluxo de funcionamento é o seguinte:

    • Registro do bot: os operadores de bots publicam suas chaves públicas em um diretório de assinaturas. O AWS WAF consulta esses diretórios periodicamente e mantém um registro atualizado de chaves válidas.
    • Assinatura das requisições: cada requisição do operador de bot é assinada com sua chave privada, seguindo o padrão IETF de Assinaturas de Mensagens HTTP (RFC 9421).
    • Verificação: o AWS WAF valida as assinaturas contra as chaves públicas conhecidas associadas ao operador do bot e adiciona rótulos relacionados ao status de verificação.

    Uma requisição típica assinada com WBA inclui cabeçalhos como os seguintes:

    Signature-Agent: https://signature-agent.test
    Signature-Input: sig2=("@authority" "signature-agent") ;created=1735689600 ;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U" ;alg="ed25519" ;expires=1735693200 ;nonce="e8N7S2MFd/qrd6T2R3tdfA..." ;tag="web-bot-auth"
    Signature: sig2=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQ..

    O diagrama abaixo ilustra como o AWS WAF verifica as assinaturas dos bots e aplica rótulos para decisões de permissão ou bloqueio:

    Imagem original — fonte: Aws

    O fluxo representado no diagrama segue estas etapas: um bot envia uma requisição assinada ao Amazon CloudFront, que é inspecionada pelo AWS WAF Bot Control; o serviço recupera a chave pública do operador no diretório de assinaturas; verifica a assinatura ed25519; adiciona um rótulo de verificação (verified, invalid, expired ou unknown_bot); e, por fim, avalia as regras configuradas para permitir ou bloquear a requisição.

    Novas capacidades adicionadas ao AWS WAF

    Verificação criptográfica de bots

    Quando um bot envia uma requisição, ela inclui assinaturas de mensagens HTTP que o AWS WAF valida na borda usando o grupo de regras do AWS WAF Bot Control (versão 4.0 ou superior). Essa validação adiciona latência mínima às requisições e oferece certeza criptográfica sobre a identidade do bot. O padrão RFC 9421 é aberto e definido pela IETF — na prática, significa que o bot assina criptograficamente cabeçalhos e metadados específicos de cada requisição, e o receptor pode verificar essa assinatura usando a chave pública publicada pelo bot.

    Novos rótulos para controle granular

    O AWS WAF valida automaticamente as assinaturas e marca o tráfego verificado com sucesso. Esses rótulos podem ser usados em regras do WAF e políticas de gerenciamento de bots. Veja o significado de cada rótulo e a ação sugerida:

    • awswaf:managed:aws:bot-control:bot:web_bot_auth:verified — Verificação criptográfica bem-sucedida → Permitir
    • awswaf:managed:aws:bot-control:bot:web_bot_auth:invalid — Tentativa de verificação falhou → Bloquear ou limitar taxa
    • awswaf:managed:aws:bot-control:bot:web_bot_auth:expired — Chave expirada utilizada → Bloquear e alertar
    • awswaf:managed:aws:bot-control:bot:web_bot_auth:unknown_bot — Chave não reconhecida → Monitorar ou bloquear
    • awswaf:managed:aws:bot-control:bot:vendor:<vendor_name> — Fornecedor ou operador do bot → Usar em regras por fornecedor
    • awswaf:managed:aws:bot-control:bot:name:<rfc_name> — Nome do bot (token RFC da WBA) → Usar em regras por bot específico
    • awswaf:managed:aws:bot-control:bot:account:<hash> — Identificador de conta AWS (somente agentes Amazon Bedrock AgentCore) → Usar para controles por conta

    Permissão automática para tráfego verificado de agentes de IA

    O AWS WAF Bot Control passou a respeitar o status de verificação da WBA por padrão, permitindo automaticamente o tráfego de agentes de IA verificados. Isso trouxe duas mudanças de comportamento específicas:

    • Atualização da regra Category:AI: anteriormente, essa regra bloqueava bots não verificados. Agora, o Bot Control verifica o status WBA antes de aplicá-la.
    • Atualização da regra TGT_TokenAbsent: essa regra, que detecta requisições sem token do WAF, não mais corresponde a requisições que carreguem o rótulo web_bot_auth:verified.

    Benefícios para quem usa o AWS WAF

    A WBA integrada ao AWS WAF traz vantagens concretas para organizações que gerenciam tráfego automatizado em escala:

    • Maior visibilidade de bots: identificação clara de bots distintos operando em plataformas multi-tenant como o Amazon Bedrock AgentCore. O console do AWS WAF inclui um novo painel de atividade de IA com uma visão centralizada do tráfego de bots e agentes de IA em todos os recursos protegidos.
    • Segurança aprimorada: verificação criptográfica de identidades de bots usando mecanismos de assinatura baseados em padrões da indústria.
    • Redução de falsos positivos: distinção precisa entre tráfego automatizado legítimo e malicioso, especialmente em ambientes de IP compartilhado.
    • Alinhamento com a indústria: compatibilidade com padrões amplamente adotados e com os principais provedores de Rede de Distribuição de Conteúdo (CDN — Content Delivery Network) para autenticação consistente de bots entre plataformas.

    Casos de uso da WBA com AWS WAF

    A WBA se aplica a diferentes cenários onde agentes automatizados precisam de acesso seguro e controlado a aplicações web:

    • Agentes de suporte ao cliente verificados: autenticação de bots de chat e suporte com IA, permitindo que os sites os reconheçam como agentes aprovados e registrados, com trilhas de auditoria completas.
    • Crawling e indexação automatizados: crawlers de mecanismos de busca e indexadores de conteúdo podem acessar páginas com identidade clara e permissões definidas, reduzindo bloqueios por falsos positivos.
    • Integrações com parceiros: agentes de terceiros acessam portais de clientes e Interfaces de Programação de Aplicações (APIs) com consentimento explícito e controles de acesso granulares, facilitando integrações seguras entre empresas (B2B — Business-to-Business).
    • Automações e agentes corporativos: ferramentas de automação internas — incluindo sistemas de monitoramento, bots de Garantia de Qualidade (QA), pipelines de Integração e Entrega Contínua (CI/CD) e soluções de Automação Robótica de Processos (RPA) — obtêm acesso autenticado a aplicações web com princípios de menor privilégio e auditabilidade completa.

    Como começar: guia rápido para desenvolvedores

    Passo 1: Implantar o Bot Control com suporte a WBA

    Adicione o grupo de regras do AWS WAF Bot Control ao seu Web Controle de Acesso (ACL — Access Control List) associado ao CloudFront usando a versão estática Version_4.0 ou Version_5.0 — ambas incluem suporte à WBA para verificação criptográfica de bots. A versão 5.0 (lançada em fevereiro de 2026) cobre mais de 650 bots e agentes únicos em categorias como crawlers de mecanismos de busca com IA, coletores de dados com IA, assistentes de IA e crawlers de treinamento de Modelos de Linguagem de Grande Escala (LLM — Large Language Model).

    Importante: você deve selecionar explicitamente uma dessas versões estáticas. O trecho de Linguagem de Marcação YAML do CloudFormation abaixo exemplifica a configuração:

    # Bot Control rule group with WBA support
    ManagedRuleGroupStatement:
      VendorName: AWS
      Name: AWSManagedRulesBotControlRuleSet
      # Use Version_4.0 or higher for WBA support
      Version: Version_5.0
      ManagedRuleGroupConfigs:
        - AWSManagedRulesBotControlRuleSet:
            # COMMON level provides WBA verification
            # TARGETED level adds additional bot-specific protections
            InspectionLevel: COMMON

    Passo 2: Assinar requisições do seu bot

    Se o seu agente roda no Amazon Bedrock AgentCore Browser, a assinatura das requisições é feita automaticamente — nenhuma configuração adicional é necessária. Para agentes que rodam fora do AgentCore, há APIs de registro no roadmap que permitirão assinar requisições de forma independente:

    • Gerar um par de chaves ed25519
    • Hospedar sua chave pública em um diretório de assinaturas
    • Assinar as requisições HTTP de saída usando os cabeçalhos Signature-Input e Signature com a tag web-bot-auth

    Para implementações de assinatura em linguagens específicas, consulte o RFC de Assinaturas de Mensagens HTTP (RFC 9421) e a documentação do AWS WAF Bot Control.

    Passo 3: Escrever regras personalizadas com rótulos WBA

    Use os rótulos de verificação em regras personalizadas do WAF para controle granular do tráfego:

    • Permitir: awswaf:managed:aws:bot-control:bot:web_bot_auth:verified
    • Limitar taxa: awswaf:managed:aws:bot-control:bot:web_bot_auth:invalid
    • Alertar: awswaf:managed:aws:bot-control:bot:web_bot_auth:expired

    Passo 4: Monitorar o tráfego WBA

    Use as métricas e logs do AWS WAF para acompanhar o tráfego de bots autenticados:

    • Revise as métricas do Amazon CloudWatch para o Bot Control e configure alarmes para picos anômalos em tentativas de verificação inválidas ou expiradas.
    • Analise os logs do AWS WAF para identificar padrões nas tentativas de autenticação de bots, filtrando pelos rótulos web_bot_auth.
    • Use o Painel de Atividade de IA no console do AWS WAF para uma visão centralizada do tráfego de bots de IA, identificar os bots mais ativos e os caminhos mais visados, e filtrar por status de verificação para decidir quais bots permitir, limitar ou bloquear.

    Disponibilidade

    A WBA foi introduzida na versão Version_4.0 do grupo de regras do Bot Control (novembro de 2025) para distribuições do Amazon CloudFront. A partir da Version_6.0, a WBA está disponível para todos os tipos de recursos suportados pelo AWS WAF nas regiões comerciais padrão da AWS.

    Conclusão

    A WBA integrada ao AWS WAF representa uma mudança significativa na forma como o tráfego automatizado é gerenciado: saindo de listas de permissão baseadas em IP para verificação baseada em assinaturas criptográficas. Isso garante identificação precisa de bots mesmo em ambientes multi-tenant. No roadmap da AWS estão APIs de registro que permitirão aos proprietários de agentes verificar criptograficamente a identidade e a intenção dos seus bots, ajudando os donos de sites a distinguir rapidamente automação confiável de tráfego desconhecido.

    Para começar, consulte a documentação do AWS WAF Bot Control e o RFC de Assinaturas de Mensagens HTTP (RFC 9421).

    Fonte

    Authenticate legitimate AI agent traffic with AWS WAF Bot Control (https://aws.amazon.com/blogs/security/authenticate-legitimate-ai-agent-traffic-with-aws-waf-bot-control/)

  • Amazon GuardDuty AI Protection: detecção de ameaças para cargas de trabalho de IA na AWS

    O que foi anunciado

    A AWS anunciou o Amazon GuardDuty AI Protection, uma expansão do serviço Amazon GuardDuty que estende a detecção de ameaças para cargas de trabalho de inteligência artificial — com suporte inicial ao Amazon Bedrock e ao Amazon SageMaker.

    O movimento faz sentido: à medida que as organizações adotam IA em ritmo acelerado, as equipes de segurança frequentemente não têm visibilidade adequada sobre ameaças específicas a esses ambientes. O GuardDuty AI Protection chega para preencher exatamente essa lacuna.

    Quais ameaças ele detecta

    O serviço monitora continuamente as cargas de trabalho de IA e é capaz de identificar três categorias principais de atividade suspeita:

    • Padrões anômalos de invocação de modelos: comportamentos fora do normal no uso dos modelos de IA, que podem indicar acesso não autorizado ou uso indevido.
    • Ataques de consumo de recursos (cost harvesting): quando agentes maliciosos forçam os recursos de IA a consumir tempo excessivo de GPU e tokens, gerando custos elevados para a conta da vítima.
    • Tentativas de prompt injection: ataques que tentam manipular o comportamento dos modelos por meio de entradas maliciosas, detectados por meio da integração com o Amazon Bedrock Guardrails.

    Para isso, o GuardDuty AI Protection analisa eventos de gerenciamento e de dados do CloudTrail provenientes dos serviços de IA da AWS, sem exigir configuração manual ou ferramentas personalizadas por parte da equipe de segurança.

    Integração com o AWS Security Hub

    Os alertas gerados pelo GuardDuty AI Protection fluem diretamente para o AWS Security Hub, centralizando a visão dos ativos e ameaças de IA em um único painel. Isso facilita a priorização e a resposta a incidentes, sem que as equipes precisem alternar entre consoles diferentes.

    Como habilitar

    A ativação do recurso pode ser feita em poucos passos diretamente no console do GuardDuty ou do Security Hub. Para organizações que utilizam o AWS Organizations, é possível habilitar o GuardDuty AI Protection de forma centralizada para todas as contas da organização de uma só vez.

    Disponibilidade e preços

    O GuardDuty AI Protection está disponível para clientes do Amazon GuardDuty com um período de teste gratuito de 30 dias. Para consultar os detalhes de precificação após o período de teste, acesse a página de preços do Amazon GuardDuty.

    Para aprender mais sobre o serviço, a AWS disponibiliza o Guia do Usuário do Amazon GuardDuty e a página oficial do produto. A lista completa de regiões onde o recurso está disponível pode ser consultada na Lista de Serviços Regionais da AWS.

    Fonte

    Introducing Amazon GuardDuty AI Protection for AWS AI workloads (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-guardduty-ai-protection-aws/)

  • ICYMI: Resumo de Segurança AWS — Junho de 2026

    O que aconteceu em segurança AWS em junho de 2026

    A cada mês, a AWS consolida as principais publicações de segurança num post de resumo — ideal para quem não consegue acompanhar tudo em tempo real. O digest de junho de 2026 cobre identidade e gerenciamento de acesso, inteligência de ameaças, segurança de rede, ferramentas de segurança com IA e governança multi-conta. A seguir, a CloudTroop traz os destaques organizados por tema.

    Identidade e Controle de Acesso

    Segurança de agentes de IA multi-tenant com Amazon Bedrock AgentCore

    Um dos posts mais relevantes do mês aborda como usar políticas baseadas em recursos no Amazon Bedrock AgentCore para isolar tenants em plataformas compartilhadas de IA. O artigo Protegendo agentes de IA multi-tenant com políticas baseadas em recursos do Amazon Bedrock AgentCore mostra como conceder acesso entre contas para um tenant enquanto restringe outro ao tráfego exclusivo via Nuvem Privada Virtual (VPC) — um padrão essencial para quem opera plataformas de IA com múltiplos clientes.

    Novo trigger Lambda para login federado no Amazon Cognito

    O post Personalizando o login federado com o novo trigger Lambda do Amazon Cognito explica como usar o novo trigger de federação de entrada do AWS Lambda no Amazon Cognito para transformar, filtrar e enriquecer atributos de usuários vindos de provedores de identidade externos — tudo isso antes da criação do perfil no user pool.

    Nova infraestrutura do Amazon Cognito

    A AWS anunciou melhorias significativas no Cognito: alta performance de throughput, chaves gerenciadas pelo cliente para criptografia de dados em repouso e replicação multi-região para continuidade de negócios — tudo construído sobre uma nova infraestrutura de armazenamento migrada com zero downtime. O post Amazon Cognito libera capacidades avançadas com infraestrutura de nova geração detalha essas mudanças.

    Controle de acesso granular em aplicações B2C

    Para quem constrói aplicações Negócio para Consumidor (B2C), o post Construindo aplicações B2C seguras com controle de acesso granular usando Amazon Cognito e Amazon Verified Permissions mostra como combinar o Cognito para autenticação com o Amazon Verified Permissions e políticas Cedar para autorização — usando uma aplicação Streamlit como exemplo prático.

    Restringindo o acesso ao Console AWS a redes esperadas

    O post Restringindo o acesso ao AWS Management Console a redes esperadas com políticas baseadas em recursos de login e RCPs ensina a usar políticas baseadas em recursos de login e Políticas de Controle de Recursos (RCPs) para limitar o acesso ao Console AWS apenas a requisições originadas em redes autorizadas, como VPNs corporativas e endpoints do Amazon VPC.

    Segurança de Infraestrutura

    Visibilidade sobre ataques DDoS com flow logs no AWS Shield Advanced

    O artigo Ganhando visibilidade sobre ataques DDoS com flow logs no AWS Shield Advanced explica como configurar os logs de fluxo de ataque do AWS Shield Advanced para capturar metadados de tráfego durante eventos de Ataque Distribuído de Negação de Serviço (DDoS), identificar origens, verificar mitigações e alimentar pipelines de análise existentes.

    Subdomain takeover: como detectar e prevenir

    O post Destaque de tática de ameaça: Subdomain takeover aborda uma das táticas mais subestimadas: a tomada de subdomínios abandonados. A publicação mostra como usar regras personalizadas do AWS Config para identificar registros CNAME de DNS “pendurados” que apontam para recursos deletados em namespaces globais compartilhados.

    Prevenção de exfiltração de dados com controles de egresso

    Para equipes preocupadas com transferência não autorizada de dados, o artigo Prevenindo exfiltração de dados: controles de egresso AWS para cargas de trabalho na nuvem apresenta uma abordagem em camadas usando AWS Network Firewall, Amazon Route 53 Resolver DNS Firewall e perímetros de dados para reduzir o risco de transferência não autorizada.

    Detecção e Resposta a Incidentes

    Roteiro de maturidade para operacionalizar segurança AWS

    O post Operacionalizando a segurança AWS: um roteiro de maturidade apresenta um roteiro de seis fases para organizações que já habilitaram o AWS Security Hub e o Amazon GuardDuty. O conteúdo cobre ajustes finos, notificações, remediação automatizada e cadência operacional.

    AWS Continuum: segurança na velocidade das máquinas

    A AWS apresentou o AWS Continuum, uma plataforma nativa de IA para vulnerabilidades de código que cobre o ciclo completo — da descoberta e priorização até a validação e remediação — tudo em velocidade de máquina. O artigo Apresentando o AWS Continuum: segurança na velocidade das máquinas detalha como a plataforma funciona.

    Investigações de segurança com Kiro CLI

    O post Acelerando investigações de segurança com Kiro CLI mostra como usar o Kiro CLI para conduzir investigações seguindo o framework do Guia de Resposta a Incidentes de Segurança da AWS — desde a triagem de achados do Amazon GuardDuty até contenção e preservação de evidências.

    Atualização do Catálogo de Técnicas de Ameaça de junho de 2026

    O artigo O que a atualização de junho de 2026 do Catálogo de Técnicas de Ameaça significa para seu ambiente AWS detalha cinco novas entradas e três atualizações no catálogo, cobrindo segurança de containers, confiança em nível organizacional e padrões de sequestro de computação observados pelo Time de Resposta a Incidentes (CIRT) da AWS.

    Proteção de Dados

    Identificando chaves KMS não utilizadas e prevenindo exclusões acidentais

    O post Identificando chaves AWS KMS não utilizadas e prevenindo exclusões acidentais ensina a usar a nova API GetKeyLastUsage do AWS KMS para auditar atividade de chaves, identificar as que não estão em uso e aplicar controles de política que impedem a exclusão acidental de chaves recentemente utilizadas.

    Governança e Conformidade

    A jornada do Pinterest: de monolito para multi-conta

    Um caso real de transformação: o post De monolito para multi-conta: a jornada de transformação de AWS Organizations do Pinterest documenta como o Pinterest migrou de uma conta AWS monolítica para uma arquitetura multi-conta, incluindo separação da conta de gerenciamento, provisionamento automatizado de contas e rede centralizada.

    Dashboard de conformidade de patches multi-conta com Kiro Specs

    O artigo Construindo um dashboard de conformidade de patches multi-conta com Kiro Specs mostra como usar a abordagem de desenvolvimento orientado a especificações do Kiro para criar um dashboard serverless de conformidade de patches com o AWS Systems Manager Patch Manager e acesso privado via Session Manager.

    Transferindo contas entre AWS Organizations preservando permissões do Lake Formation

    O post Transferindo contas AWS entre AWS Organizations preservando permissões do AWS Lake Formation aborda como migrar contas membro entre AWS Organizations sem interromper permissões entre contas do AWS Lake Formation, usando compartilhamentos de ponte temporários com o novo parâmetro de retenção do AWS RAM.

    Boletins de Segurança de Junho

    A AWS publicou investigações sobre vulnerabilidades de segurança reportadas que afetam serviços, softwares e produtos Amazon e AWS. Abaixo, a lista dos boletins divulgados em junho:

    Amostras de Código AWS (AWS Samples)

    Junho trouxe 10 novos repositórios de amostras cobrindo segurança de IA, identidade, segurança de infraestrutura, governança e observabilidade. Todos disponíveis para que você implante e valide no seu próprio ambiente antes de adotar em produção.

    Segurança de IA

    Governança

    Conclusão

    Junho de 2026 foi um mês denso em conteúdo prático para segurança AWS em escala organizacional. Os destaques vão desde roteiros de maturidade e restrições de acesso ao console até registros de agentes de IA e plataformas de gerenciamento de postura. Os posts e amostras apresentam padrões para visibilidade sobre DDoS com flow logs, isolamento de agentes multi-tenant com políticas baseadas em recursos, controles de egresso para prevenção de exfiltração de dados e frameworks de governança para assistentes de codificação com IA. Cada recurso inclui passos de implantação ou código executável para que você possa validar no seu próprio ambiente antes de adotar.

    Para receber as publicações assim que saírem, assine o feed RSS do AWS Security Blog e volte mensalmente para o digest consolidado.

    Fonte

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

  • AWS IAM Identity Center obtém Certificação FedRAMP Classe C

    O que foi anunciado

    A AWS anunciou que o AWS IAM Identity Center agora está dentro do escopo da certificação FedRAMP Classe C. O serviço passou a atender a esse requisito nas seguintes regiões dos Estados Unidos: US East (Ohio), US East (N. Virginia), US West (N. California) e US West (Oregon).

    O que muda na prática

    Com essa certificação, organizações que precisam estar em conformidade com o FedRAMP Classe C podem utilizar o IAM Identity Center para gerenciar o acesso da força de trabalho a contas AWS e aplicações sujeitas a esse nível de compliance. Ou seja, o serviço agora é uma opção válida também para ambientes com exigências regulatórias mais rigorosas dentro do contexto do governo americano.

    Vale lembrar que o IAM Identity Center já é o serviço recomendado pela AWS para gerenciar o acesso de colaboradores a contas e aplicações AWS — e essa certificação reforça ainda mais seu uso em cenários regulados.

    O que é o FedRAMP

    O Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP) é um programa do governo dos Estados Unidos que estabelece uma abordagem padronizada para avaliação de segurança, certificação e monitoramento contínuo de produtos e serviços em nuvem. Em outras palavras, é o mecanismo que o governo americano usa para garantir que soluções de nuvem atendam a critérios rigorosos de segurança antes de serem adotadas por agências federais.

    Onde saber mais

    Para aprofundar o entendimento sobre o FedRAMP e como a AWS se posiciona dentro desse programa, a AWS disponibiliza a página de serviços em conformidade e a página de recursos de compliance da AWS. Quem quiser entender melhor o funcionamento do IAM Identity Center pode consultar o Guia do Usuário oficial do serviço.

    Fonte

    AWS IAM Identity Center achieves FedRAMP Class C Certification (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-identity-center-fedramp/)

  • Novo guia de conformidade HITRUST i1 na AWS disponível para organizações de saúde

    AWS publica guia de implementação para conformidade HITRUST i1

    A Amazon Web Services (AWS) acaba de publicar um novo material de orientação de conformidade: o HITRUST i1 Compliance on AWS: Customer Implementation Guidance with an Illustrative Healthcare Platform. O documento é voltado especialmente para organizações da área da saúde que utilizam a AWS como base de nuvem e precisam obter a certificação HITRUST i1.

    O que é o HITRUST i1 e por que ele importa?

    O HITRUST i1 é a certificação mais amplamente exigida no setor de saúde. A avaliação cobre 182 controles selecionados no nível de implementação (Implemented) e aparece com frequência em contratos com fornecedores, Acordos de Parceiro de Negócios (BAAs) e exigências de planos de saúde, sistemas hospitalares e associados de negócios como condição para estabelecer parcerias.

    Em outras palavras: para quem atua no ecossistema de saúde nos Estados Unidos — ou para empresas brasileiras que prestam serviços a clientes norte-americanos nesse setor — essa certificação pode ser um requisito contratual real.

    O que o guia cobre

    O material foi desenhado para preencher a lacuna entre entender o que o HITRUST i1 exige e saber como implementar esses requisitos na AWS. Ele conduz arquitetos de nuvem, engenheiros de segurança, responsáveis por conformidade e equipes de preparação para avaliação por todo o ciclo de um engajamento i1 — desde a definição do escopo da avaliação até a implementação de controles em cada domínio técnico.

    Os 11 domínios de controle técnico abordados no guia são:

    • Controle de acesso
    • Proteção de endpoints
    • Gerenciamento de configuração
    • Gerenciamento de vulnerabilidades
    • Proteção de rede
    • Proteção de transmissão
    • Gerenciamento de incidentes
    • Proteção de dados e privacidade
    • Registro de auditoria e monitoramento
    • Gerenciamento de senhas
    • Continuidade de negócios e recuperação de desastres

    Cenário ilustrativo com AWS Landing Zone Accelerator

    Para tornar os conceitos mais concretos, o guia utiliza um cenário fictício — mas realista — de uma plataforma de saúde conectada implantada no AWS Landing Zone Accelerator. Vale reforçar: o cenário existe para fins didáticos e não sugere que a mesma arquitetura ou as mesmas escolhas de controle se aplicam universalmente. O escopo do HITRUST i1 é, por natureza, específico para cada organização.

    O limite da avaliação, os controles aplicáveis e os requisitos de evidência são definidos pelo escopo de sistema de cada organização e gerenciados pelo portal HITRUST MyCSF. A recomendação é tratar o guia como ponto de partida e trabalhar com um Avaliador Externo Autorizado HITRUST para validar o que se aplica ao ambiente específico de cada empresa. O documento não constitui uma consultoria de certificação de conformidade.

    Como acessar o material

    O guia pode ser baixado diretamente: HITRUST i1 Compliance on AWS: A Customer Implementation Guidance with an Illustrative Healthcare Platform.

    A documentação de garantia HITRUST da AWS e a Matriz de Responsabilidade do Cliente estão disponíveis pelo AWS Artifact. Para suporte na preparação para avaliações, a AWS indica o AWS Security Assurance Services.

    Fonte

    New compliance guidance available: HITRUST i1 on AWS (https://aws.amazon.com/blogs/security/new-compliance-guidance-available-hitrust-i1-on-aws/)