Category: Uncategorized

O trabalho que não aparece nas telas de cinema

A AWS publicou a terceira parte de sua série Cybersecurity Journeys, que acompanha 11 profissionais de segurança da empresa contando suas histórias reais. Nas partes anteriores — Parte 1: não planejei isso e Parte 2: afinal, o que é esse trabalho? — a série mostrou como essas pessoas chegaram à área e quais funções pouco conhecidas existem dentro dela. Nesta terceira parte, o foco é o cotidiano: o que realmente acontece no dia a dia de quem trabalha em segurança, longe dos cronômetros dramáticos e das cenas de digitação frenética que Hollywood inventou.

Três profissionais compartilham suas rotinas, e o que fica claro é que a maior parte do trabalho real é feita de conversas difíceis, leitura cuidadosa de código e a disciplina de saber quando parar. São habilidades que não rendem cenas de ação, mas são exatamente o que sustenta qualquer operação de segurança de verdade.

Brandon Caldwell: segurança de aplicações é, antes de tudo, gente

Brandon Caldwell, gerente de Engenharia de Segurança na AWS, trabalha com segurança de aplicações — a disciplina de revisar software enquanto ele ainda está sendo construído, para que as falhas nunca cheguem à produção. Se você imagina alguém invadindo sistemas em um terminal escuro, a rotina de Brandon é o oposto disso: ele passa os dias em conversa com os times que desenvolvem produtos, fazendo perguntas até entender o funcionamento de algo fundo o suficiente para enxergar onde ele pode quebrar.

A parte mais difícil do trabalho, segundo ele, não é técnica — é humana. A equipe de segurança precisa chegar para um desenvolvedor e dizer que o produto que ele construiu com cuidado tem problemas. Brandon usa uma frase direta com os profissionais que contrata:

“Nosso trabalho é chegar e dizer que o bebê da pessoa é feio. Uso essa frase porque ela desperta empatia. É a coisa que eles amam e dedicaram tempo, e você aparece no final dizendo que ela é feia. Claro que vão reagir.”

Aprender a entregar esse recado sem destruir a relação com quem está do outro lado da mesa é, na visão dele, o verdadeiro ofício da função. Engenheiros que entraram na área de tecnologia justamente para evitar lidar com pessoas tendem a ter dificuldades em segurança de aplicações.

Além das conversas, há muito texto envolvido: documentar uma descoberta de forma que o desenvolvedor consiga agir, escrever avisos que orientem clientes, redigir políticas que definam o padrão para todos que vierem depois. A capacidade de transformar algo técnico e confuso em poucas frases que o leitor consegue usar de verdade é, segundo Brandon, um dos grandes diferenciais de quem cresce na área.

A trajetória dele começa bem antes da cibersegurança existir como título de emprego: ainda criança, ele editava o código hexadecimal do jogo Doom para ter munição infinita. Depois vieram anos como administrador de TI e resposta a incidentes na Microsoft. O que o fez migrar para o lado da prevenção foi perceber que os mesmos tipos de falha — como injeção de SQL (Linguagem de Consulta Estruturada) e scripts entre sites, duas das formas mais comuns de exploração de sites mal construídos — apareciam repetidamente. Ele preferia ajudar os times a evitar o problema do que chegar depois para consertá-lo.

Para quem quer entrar na área, o conselho de Brandon é prático: pratique fazer perguntas e entrevistar pessoas, passe tempo real com desenvolvedores para entender como software é construído. Na hora de contratar, certificações são o último critério que ele olha — o que ele quer ver são resultados em competições de capture the flag (CTF — competições de hacking onde você resolve puzzles de segurança para acumular pontos) e projetos públicos no GitHub, porque esses provam que a pessoa realmente fez o trabalho.

Kurt Heath: a base antes da glamourização

Kurt Heath, Associado de Suporte de TI na AWS, trabalha com segurança ofensiva: testes de penetração (Pentest — a prática de invadir sistemas legalmente para provar onde eles são vulneráveis) e, eventualmente, red teaming. Mas ele é o primeiro a advertir que o cotidiano de quem está se tornando bom nisso não tem nada de cinematográfico.

São horas de prática em ambientes deliberadamente vulneráveis, leitura de técnicas seguida de tentativas repetidas até que funcionem, e a acumulação lenta das camadas que sustentam o trabalho: sistemas operacionais, redes, desenvolvimento de software e fundamentos de segurança, todos aplicados ao mesmo tempo. Kurt reconhece que testes de penetração são “a parte glamourosa” que aparece nos anúncios de vaga, e avisa que não deveria ser o ponto de partida de ninguém, exatamente porque há muito trabalho silencioso de base por baixo.

Uma parte significativa do seu dia atual envolve decidir como e quanto usar Inteligência Artificial (IA). Ele trata a IA como ferramenta, não como muleta: usa como assistente de código quando precisa trabalhar em uma linguagem que não domina, e para organizar grandes volumes de informação rapidamente. Mas não deixa a IA pensar por ele. Formulários como o questionário desta série, ele preenche à mão. E durante um engajamento de segurança, ele evita deixar a IA executar ações autonomamente — uma ferramenta excessivamente proativa pode agir em uma rede de formas não planejadas, causar danos operacionais ou sair do escopo definido e criar um problema legal.

Na visão de Kurt, segurança é fundamentalmente um problema humano. A automação melhora continuamente nas partes sistemáticas, mas pensar fora da caixa como um atacante real ainda é algo teimosamente humano.

A trajetória dele é em grande parte autodidática. Depois que um programa de faculdade comunitária não deu certo, ele aprendeu do zero: terminava turnos em uma fábrica de automóveis e passava as noites com YouTube e buscas na internet aprendendo como computadores e redes funcionam. O maior desafio foi a automotivação, e o que o sustentou foi uma combinação de determinação e, eventualmente, comunidade — amigos encontrados em servidores do Discord, podcasts de segurança e canais de interesse que ajudaram a transformar vontade bruta em foco real. Ele chegou a fazer uma tatuagem como lembrete de que não há plano B:

“Não existe outra opção. Não existe ‘e se’. É isso. É a vida agora, e vou descobrir um jeito, de alguma forma, não importa quanto tempo leve.”

Para quem quer seguir o mesmo caminho ofensivo, o conselho de Kurt é resistir à tentação de começar por aí. Construa a fundação primeiro — muitas vezes por meio de uma função em um Centro de Operações de Segurança (SOC) —, entre nas comunidades onde as pessoas aprendem em público, e deixe o trabalho mais chamativo vir depois que a base estiver sólida. O progresso nessa área, na experiência dele, é medido menos pelo cargo que você conquista do que por quanto você cresce e com quem você cresce.

Seth Jeacopello: saber quando parar é o verdadeiro ofício

Seth Jeacopello, Gerente de Engenharia de Segurança na AWS, também trabalha com segurança de aplicações — mas se o dia de Brandon é centrado em pessoas, o de Seth é centrado em código. Os dois juntos mostram como a mesma função pode ter aparências muito diferentes.

Quando Seth trava em um problema difícil, ele não força mais. Ele pega um cadeado. Um cadeado físico, de verdade, com pinos e molas, porque ele é um entusiasta sério de arrombamento de fechaduras. Ao longo dos anos, aprendeu que a melhor resposta quando bate em uma parede é largar o problema e pegar o que ele chama de “cadeado de conforto” — um que ele conhece bem e consegue abrir facilmente. Não é sobre o cadeado; é sobre dar ao cérebro uma pequena vitória para que ele possa voltar ao problema difícil com olhos frescos.

O cadeado de conforto existe porque o cotidiano de Seth é fácil de perder. Em segurança de aplicações, grande parte do trabalho é ler enormes volumes de código alheio em busca da única falha que importa. Como desenvolvedor de longa data, ele genuinamente ama ler código — e é exatamente isso que torna a tarefa uma armadilha. Você se convence de que a vulnerabilidade está logo atrás da próxima função, e da próxima, e de repente dois dias se foram. A habilidade que ele passou décadas afiando não é encontrar coisas, é saber quando “fundo o suficiente” é fundo o suficiente.

Depois de 26 anos na área, a meta-habilidade de gerenciar a própria atenção é tão parte do ofício quanto qualquer coisa técnica. A trajetória de Seth começou por volta de 1999, ainda adolescente, com um estágio em garantia de qualidade de software. Aos 17 anos já havia sido contratado como desenvolvedor, e foi se aproximando do trabalho com viés de segurança naturalmente, passando por ferramentas de segurança de rede, chegando a arquiteto-chefe e diretor de tecnologia ao longo do caminho.

O conselho dele para construir os instintos que o trabalho diário exige é concreto: configure uma máquina de prática deliberadamente vulnerável, invada-a, e então vá ler os logs que ela gerou. Assim você aprende não só como um ataque funciona, mas como ele parece do lado do defensor. Um único exercício que desenvolve tanto o músculo ofensivo quanto o investigativo — e é exatamente o tipo de prática paciente e repetível que a área recompensa.

O fio que conecta tudo

Existe uma versão da cibersegurança feita para televisão — acelerada, cheia de momentos de revelação. Esses momentos existem. Mas os três profissionais apresentados nesta parte da série vivem em uma versão diferente da área: construída sobre paciência, repetição e um cuidado obstinado que não fotografa bem.

Para Brandon, o trabalho real é a conversa humana e difícil de dizer a um desenvolvedor que seu trabalho tem falhas sem torná-lo um inimigo. Para Kurt, são as horas sem glamour de prática e a disciplina de usar IA como ferramenta sem deixar que ela pense por ele. Para Seth, é ler mais uma página de código e saber quando parar, com um cadeado de conforto na mesa para quando não conseguir.

Nada disso rende uma boa sequência de ação. Mas tudo isso é como uma carreira em segurança realmente parece — e a boa notícia para quem está começando é que são hábitos aprendíveis, não talentos inatos. Empatia, paciência, julgamento e autoconhecimento não são prêmio de consolação: são parte do trabalho.

Por onde começar

Para quem quer dar os primeiros passos práticos, os profissionais indicam alguns recursos:

• TryHackMe e Hack The Box permitem criar máquinas deliberadamente vulneráveis, invadi-las e estudar o que você acionou — exatamente o exercício que Seth recomenda.
• O OWASP Top 10 (Projeto Aberto de Segurança em Aplicações Web — lista das dez falhas mais comuns) explica as vulnerabilidades de aplicação mais frequentes, incluindo as que Brandon via se repetir.
• A OWASP Cheat Sheet Series transforma essas falhas em orientações práticas sobre como construir e revisar software com segurança.
• O podcast Darknet Diaries conta as histórias humanas por trás de incidentes reais de segurança — uma boa forma de sentir como o trabalho realmente é.
• Para quem quer desenvolver habilidades específicas em segurança na nuvem, a AWS disponibiliza o AWS Skill Builder, com mais de 1.000 cursos gratuitos em ritmo próprio, incluindo trilhas de aprendizado em segurança, e o AWS Builder Labs, que permite praticar em um console AWS real com laboratórios práticos de segurança.

A quarta e última parte da série trará os conselhos e lições que esses profissionais dariam para quem está começando agora.

Fonte

Part 3 – Cybersecurity journeys: The work behind the work (https://aws.amazon.com/blogs/security/part-3-cybersecurity-journeys-the-work-behind-the-work/)

O problema que essa novidade resolve

A maioria das cargas de trabalho na nuvem se conecta a destinos pelo nome de domínio — mas um firewall só consegue agir sobre o que enxerga no tráfego. Para conexões HTTP e HTTPS, o AWS Network Firewall conseguia fazer a correspondência pelo nome que o cliente colocava na requisição. Mas protocolos como SSH e SFTP (Protocolo de Transferência de Arquivos SSH) não carregam o nome do domínio na conexão: o cliente usa o nome apenas para a consulta DNS e depois conecta diretamente ao endereço IP retornado.

Isso criava um problema prático: regras de firewall para esses protocolos precisavam usar endereços IP, que mudam com o tempo. Além disso, o Network Firewall não tinha visibilidade sobre as respostas que o resolvedor DNS estava retornando — essa integração simplesmente não existia.

O que a AWS anunciou

Em 21 de outubro de 2026, a AWS lançou o Route 53 Resolved IP Validation para o AWS Network Firewall, sem custo adicional. Com esse recurso, o Amazon Route 53 Resolver passa a compartilhar os endereços IP que retorna para cada nome de domínio com o Network Firewall. A partir daí, o firewall verifica cada nova conexão de saída contra esse cache de IPs resolvidos.

Na prática, isso abre duas possibilidades importantes:

• Filtrar tráfego não-web (como SFTP, SSH, MySQL) por nome de domínio, sem precisar manter listas de IP
• Prevenir manipulação de SNI (Indicação de Nome do Servidor) em tráfego TLS sem precisar habilitar inspeção TLS

Como o recurso funciona

O Amazon Route 53 Resolver responde consultas DNS de recursos dentro da sua Nuvem Privada Virtual (VPC) e está disponível por padrão em toda VPC. Com esse novo recurso, ele mantém um cache de IPs resolvidos com os endereços retornados para cada domínio. Quando uma nova conexão de saída é iniciada, o Network Firewall verifica o endereço de destino contra esse cache.

O fluxo funciona assim: a carga de trabalho consulta o Route 53 Resolver pelo domínio desejado. O DNS Firewall verifica a consulta primeiro — pode bloquear ou alertar; um grupo de regras vazio deixa passar. O Resolver responde com o IP e registra a resposta no cache. Quando a conexão TCP/SFTP chega ao endpoint do Network Firewall, a política verifica o primeiro pacote: se o endereço está no cache, a conexão segue para a inspeção com estado (stateful). A regra stateful libera a conexão porque o Route 53 Resolver retornou aquele endereço para o domínio configurado.

O recurso é composto por três partes:

• Grupo de regras do Amazon Route 53 Resolver DNS Firewall — Define o escopo. As respostas retornadas em toda VPC associada a esse grupo vão para o cache de IPs resolvidos. O grupo pode estar vazio; adicionando regras, ele também filtra as próprias consultas DNS.
• Configuração da política do Network Firewall — No primeiro pacote de cada nova conexão, antes das regras stateful rodarem, o firewall verifica se o Route 53 Resolver retornou aquele endereço de destino para algum domínio. Se não retornou, aplica a ação configurada: Alert (alertar), Drop (descartar) ou Reject (rejeitar com reset TCP).
• Regras de domínio resolvido — Nos grupos de regras stateful, essas regras fazem a correspondência de uma conexão pelo nome de domínio para o qual o endereço de destino foi resolvido. Funcionam com qualquer protocolo.

Um detalhe importante: a verificação é por endereço. Quando qualquer cliente em uma VPC associada consulta um nome, os endereços retornados ficam válidos para todos os clientes no escopo da mesma Zona de Disponibilidade. Conexões para endereços IP fixos (hardcoded) falham na verificação — esses endereços precisam ser adicionados aos Bypass destination validation IP ranges antes de aplicar enforcement. Para mais detalhes, consulte a documentação de Resolved IP validation no AWS Network Firewall.

Pré-requisitos

• DNS via Amazon Route 53 Resolver — o firewall só consegue verificar respostas que o Resolver retornou. Consultas que chegam ao Resolver via endpoints ou regras de encaminhamento também contam.
• Um grupo de regras do Route 53 Resolver DNS Firewall associado às VPCs cujas respostas DNS o Network Firewall deve verificar.
• A configuração da política deve ser ativada antes de adicionar regras de domínio resolvido — regras que usam o filtro de domínio (keyword aws_route_53_resolved_domain) precisam que o Route 53 Resolved IP Validation esteja ativo na mesma política.
• Modelo de implantação suportado — funciona com implantações distribuídas (múltiplos endpoints de firewall, onde clientes atingem um endpoint na sua própria Zona de Disponibilidade) e com implantações centralizadas onde o firewall está conectado nativamente ao AWS Transit Gateway. Se o roteamento enviar um cliente para um endpoint em outra Zona de Disponibilidade, as conexões falham na verificação. Para migrar uma implantação centralizada para um firewall com conexão nativa ao Transit Gateway, veja o guia Why and how to migrate to a Transit Gateway attached AWS Network Firewall.

Como ativar em modo de alerta

A recomendação da AWS é começar sempre em modo de alerta, porque os clientes mantêm respostas DNS em cache. O Network Firewall reconhece apenas as respostas que o Route 53 Resolver retornar depois que o grupo de regras do DNS Firewall for associado à VPC e selecionado na política. Um cliente que ainda usa uma resposta em cache vai falhar na verificação até renovar a consulta DNS. O modo de alerta permite observar isso sem bloquear nada. Aguarde cerca de 24 horas em modo de alerta para que os clientes renovem seus caches.

Os passos são:

1. Crie um grupo de regras do DNS Firewall (pode estar vazio) e associe-o às VPCs desejadas. Veja como em Criando um grupo de regras e regras. Se já tiver um grupo, certifique-se de que está associado apenas às VPCs corretas.
2. No console da Amazon Virtual Private Cloud (Amazon VPC), em Network Firewall, acesse as políticas de firewall e escolha a política que seu firewall usa.
3. Na aba de inspeção de tráfego, na seção Route 53 Resolved IP Validation, clique em Editar e selecione Enable Route 53 Resolved IP validation.
4. Para Action, escolha Alert.
5. Para DNS Firewall rule group, selecione o grupo criado no passo 1.
6. Para DNS expiry exception policy, escolha o que acontece com uma conexão aberta quando sua entrada expira do cache: Continue mantém a conexão, Drop encerra silenciosamente, Reject encerra com reset TCP. A AWS recomenda Continue para não interromper sessões longas, como transferências de arquivos.
7. Em source IP ranges, liste os clientes a verificar. Se não configurar, o firewall verifica clientes na VPC do firewall e em VPCs adicionais anexadas a ele. Se seus clientes estão em outras VPCs (como VPCs spoke que enviam tráfego para um firewall no Transit Gateway), insira os intervalos CIDR delas.
8. Adicione destinos permitidos por IP aos Bypass destination validation IP ranges.
9. Salve.

Em modo de alerta, o Network Firewall não bloqueia conexões que falham na verificação. Ele registra o resultado nos flow logs, no campo route53_resolved_ip de cada conexão: true significa que o Resolver retornou aquele endereço para um domínio; false significa que não retornou — e que o enforcement bloquearia a conexão. A métrica DnsUnresolvedFlows no Amazon CloudWatch conta as conexões que falham na verificação. Antes de mudar para Drop ou Reject, confira se as conexões que falham são as esperadas e se os destinos permitidos por IP estão nos bypass ranges. Para as métricas e campos de log a monitorar, veja Monitoring and troubleshooting resolved IP validation.

Caso de uso 1: Filtrar tráfego não-web por nome de domínio

Antes desse lançamento, regras do Network Firewall para protocolos que não carregam nome de domínio — como SFTP — precisavam usar endereços IP. Agora é possível liberá-los por nome de domínio.

Exemplo: uma carga de trabalho envia arquivos via SFTP para um parceiro em files.partner.example.com na porta TCP 22, e o parceiro pode mudar os endereços desse nome a qualquer momento. A mesma abordagem funciona para SSH, MySQL e outros protocolos não-web.

Para criar a regra, acesse Network Firewall, escolha Network Firewall rule groups e crie um novo grupo stateful com regra stateful padrão. Adicione uma regra com protocolo TCP, porta de destino 22, filtro de domínio files.partner.example.com e ação Pass. Adicione o grupo à política de firewall.

Se você gerencia regras como código, a regra Suricata equivalente é:

pass tcp any any -> any 22 (alert; msg:"Allow TCP/22 to files.partner.example.com"; aws_route_53_resolved_domain:"files.partner.example.com"; sid:1;)

Quando o parceiro mover o servidor para um novo endereço, a próxima resposta DNS adiciona o novo IP ao cache resolvido. Não há lista de IPs para manter. O cache mantém respostas anteriores por mais tempo que o TTL DNS, então o endereço antigo ainda pode passar por um período.

Caso de uso 2: Prevenir spoofing de SNI sem inspeção TLS

No spoofing de SNI, um cliente apresenta um nome de domínio permitido na requisição TLS enquanto se conecta a um servidor diferente. Prevenir isso exigia inspeção TLS, que descriptografa o tráfego. O Route 53 Resolved IP Validation previne isso sem inspeção TLS.

Exemplo: uma carga de trabalho chama uma API de parceiro em api.partner.example.com via HTTPS. O tráfego TLS na porta 443 deve chegar apenas aos endereços que o Route 53 Resolver retornou para esse nome.

Crie uma regra pass em um grupo de regras stateful padrão, com ordem estrita. Adicione uma regra com protocolo TLS, porta de destino 443, filtro de domínio api.partner.example.com e ação Pass. Na política de firewall, use ordem estrita de regras e para as ações padrão stateful escolha Application drop established (server-directed only) e Application alert established (server-directed only). Para entender por que a AWS recomenda essas ações padrão, veja a configuração de política de firewall no guia de melhores práticas de segurança da AWS.

Se você gerencia regras como código, a regra Suricata equivalente é:

pass tls any any -> any 443 (aws_route_53_resolved_domain:"api.partner.example.com"; sid:2;)

A regra pass faz a correspondência pelo endereço de destino, não pelo nome na requisição TLS. O tráfego TLS na porta 443 passa apenas quando o Route 53 Resolver retornou o endereço de destino para api.partner.example.com. Se os endereços do parceiro também servem outros domínios (como atrás de uma CDN), esses nomes também passam.

Para exigir também o nome do parceiro na requisição TLS, adicione uma correspondência exata de SNI à mesma regra: tls.sni; content:"api.partner.example.com"; startswith; endswith; nocase;. Sem startswith e endswith, a correspondência aceita qualquer SNI que contenha o nome.

Boas práticas recomendadas

• Mantenha o DNS no Route 53 Resolver — Bloqueie UDP e TCP de saída na porta 53 para outros resolvedores (incluindo DNS over HTTPS e DNS over TLS) no Network Firewall, para que clientes não contornem a verificação. O Route 53 Resolved IP Validation por si só não faz isso.
• Mantenha regras do DNS Firewall nas VPCs — O Route 53 Resolved IP Validation verifica as conexões que seguem uma consulta DNS, não as consultas em si. O DNS Firewall bloqueia lookups de domínios de ameaças conhecidas com listas gerenciadas pela AWS e detecta dados saindo via consultas DNS (como DNS tunneling).
• Comece pequeno — Adicione filtros de domínio a poucas regras por vez, depois expanda quando os resultados estiverem limpos. Para padrões de allow list de domínio, veja Allow rules and domain allowlisting.
• Ative logging de flow e alert e monitoramento detalhado — Conexões que falham na verificação aparecem nos flow logs (route53_resolved_ip: false) e na métrica DnsUnresolvedFlows, não nos alert logs. Regras pass sem a keyword alert; não geram registros de alert log.

Disponibilidade e preços

O Route 53 Resolved IP Validation está disponível hoje em todas as regiões comerciais da AWS onde o AWS Network Firewall e o Amazon Route 53 Resolver DNS Firewall estão disponíveis (exceto as regiões AWS GovCloud (US) e as regiões da China), sem custo adicional. Veja a lista de regiões em AWS Capabilities by Region.

Um grupo de regras do DNS Firewall sem regras não gera cobranças do DNS Firewall. Os preços padrão do DNS Firewall se aplicam após adicionar regras. Consulte os preços do AWS Network Firewall e do Amazon Route 53.

Como começar

Para começar, ative o recurso em modo de alerta e revise os resultados antes de aplicar enforcement. Para o guia completo, acesse Getting started with resolved IP validation. Para saber mais, visite a página do produto AWS Network Firewall e a documentação do recurso. Em caso de dúvidas, entre em contato com o AWS Support.

Fonte

Introducing Route 53 Resolved IP Validation for AWS Network Firewall (https://aws.amazon.com/blogs/security/introducing-route-53-resolved-ip-validation-for-aws-network-firewall/)

O que foi anunciado

Em 22 de outubro de 2026, a AWS divulgou as atualizações trimestrais de segurança e correções críticas para as versões com Suporte de Longo Prazo (LTS — Long-Term Support) do Amazon Corretto, a distribuição gratuita e pronta para produção do OpenJDK mantida pela empresa.

Versões disponíveis

As seguintes versões foram liberadas para download a partir desta atualização:

• Corretto 27.0.1.0.10
• Corretto 25.0.5.0.9
• Corretto 21.0.13.0.10
• Corretto 17.0.21.0.10
• Corretto 11.0.33.0.9
• Corretto 8u512

Todas essas versões recebem patches de segurança e correções críticas como parte do ciclo trimestral de manutenção do Amazon Corretto.

O que é o Amazon Corretto

Para quem ainda não conhece, o Amazon Corretto é uma distribuição sem custo, multiplataforma e pronta para ambientes de produção do OpenJDK — a implementação de referência da linguagem Java. A proposta da AWS é oferecer uma alternativa confiável e com suporte de longo prazo para equipes que dependem do Java no dia a dia, sem custos de licenciamento.

Como obter as atualizações

Há duas formas principais de acessar as novas versões:

• Download direto: acesse a página oficial do Corretto e faça o download da versão desejada — Corretto 27, 25, 21, 17, 11 ou 8.
• Via gerenciador de pacotes no Linux: é possível receber as atualizações diretamente pelo sistema operacional configurando um repositório Apt, Yum ou Apk do Corretto, dependendo da distribuição Linux utilizada.

Feedback e contribuições

A AWS deixa aberto o canal de contribuições para a comunidade. Feedbacks sobre o Corretto são bem-vindos via GitHub, onde o projeto é mantido de forma transparente.

Por que isso importa para times brasileiros

Manter o ambiente Java atualizado é uma prática essencial de segurança. Atualizações trimestrais como essa corrigem vulnerabilidades conhecidas e garantem que as aplicações continuem operando com o nível de proteção mais recente. Se o seu time utiliza Amazon Corretto em produção, este é o momento de planejar a atualização para as versões mais recentes disponibilizadas neste ciclo.

Fonte

Amazon Corretto October 2026 Quarterly Updates (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-corretto-october-2026-quarterly-updates)

O desafio da IA no setor de saúde

Organizações de saúde querem da IA o mesmo que qualquer outro setor: respostas mais rápidas, menos trabalho manual e insights que cheguem a quem decide a tempo de agir. O que diferencia a saúde, no entanto, é que os dados são únicos em complexidade, profundamente contextuais e fortemente regulamentados.

Para entender o que está em jogo, vale começar pelos conceitos básicos. Informação de Saúde Protegida (PHI) é qualquer dado que identifique uma pessoa e esteja relacionado à sua saúde, tratamento ou pagamento por cuidados — como anotações clínicas, solicitações de reembolso ou números de identificação de planos. Quando um software lida com PHI, ele passa a estar sujeito à Lei de Portabilidade e Responsabilidade de Seguro de Saúde (HIPAA), a legislação federal americana que rege como esses dados são acessados, protegidos e auditados.

A IA agêntica muda o que significa um software “tocar PHI”. Uma ferramenta analítica tradicional lê dados e retorna uma resposta. Um workspace agêntico como o Amazon Quick pode ir além: seus agentes de chat operam tanto sobre conteúdo não estruturado (como notas clínicas e cartas de apelação) quanto sobre dados estruturados (como registros de sinistros e dados de beneficiários). Os agentes podem recuperar dados de múltiplas fontes, acionar outros sistemas por meio de conectores e executar tarefas em várias etapas em nome do usuário.

Os conectores são integrações pré-construídas que permitem ao Amazon Quick ler e agir em sistemas externos, como Slack, Microsoft Outlook, Salesforce, Atlassian Jira e Microsoft SharePoint. É possível também adicionar ferramentas personalizadas via Protocolo de Contexto de Modelo (MCP). Apenas conectores autorizados pela organização ficam visíveis.

Quando um agente de chat pode tanto ler quanto agir sobre PHI, é necessário governança sólida: controles determinísticos, trilha de auditoria comportamental e responsabilidade clara sobre ações executadas sem supervisão humana. Para isso, o Amazon Quick oferece recuperação com controle de acesso baseado em listas (ACLs), registro de conversas e feedbacks, e controles sobre o que cada agente pode fazer.

O Amazon Quick é um serviço elegível para HIPAA. Essa elegibilidade se aplica aos clientes web, desktop e mobile, sujeita ao modelo de responsabilidade compartilhada e à configuração do cliente.

HIPAA: quem está sujeito à lei

A HIPAA alcança muito além de hospitais e clínicas. A lei define duas categorias de organizações com obrigações:

Entidades cobertas (CEs)

• Planos de saúde — seguradoras, HMOs, planos patrocinados por empregadores, Medicare e Medicaid.
• Câmaras de compensação de saúde — organizações que processam informações de saúde em formatos eletrônicos padronizados.
• Prestadores de saúde — médicos, clínicas, hospitais, farmácias, casas de repouso e qualquer prestador que transmita informações de saúde eletronicamente.

Associados de negócios (BAs)

Um associado de negócios é qualquer pessoa ou entidade, fora da força de trabalho da entidade coberta, que cria, recebe, mantém ou transmite PHI em nome da entidade coberta. Exemplos comuns incluem provedores de nuvem, fornecedores de TI, empresas de faturamento, firmas de análise de dados, processadores de sinistros, escritórios de advocacia e consultorias.

Tanto entidades cobertas quanto associados de negócios devem assinar um Adendo de Associado de Negócios (BAA) antes de qualquer troca de PHI. Após aceitar o BAA da AWS pelo AWS Artifact, a AWS passa a ser seu associado de negócios para aquela conta específica — e apenas quando você usa serviços elegíveis para HIPAA, como o Amazon Quick, para processar PHI dentro dela.

Elegível para HIPAA ≠ em conformidade com HIPAA

Esta é uma distinção fundamental que a AWS deixa clara. Elegível para HIPAA é uma designação da AWS que indica que o serviço foi avaliado e permite processar, armazenar e transmitir PHI sob um BAA assinado. O Amazon Quick é elegível, e auditores terceiros o avaliam sob programas de conformidade como HIPAA, FedRAMP, PCI DSS, SOC e ISO.

Em conformidade com HIPAA, por outro lado, é uma propriedade do seu ambiente como um todo. Ter um serviço elegível é apenas um bloco de construção. Você ainda precisa assinar o BAA, classificar seus dados, configurar os controles corretamente e assumir as salvaguardas administrativas e físicas que a HIPAA exige — incluindo treinamento de equipe, análise de riscos e procedimentos de violação que a AWS não executa por você.

Em outras palavras: o Amazon Quick sendo elegível significa que você pode construir um fluxo de trabalho em conformidade sobre ele. Não significa que ativá-lo automaticamente te coloca em conformidade.

O que é o Amazon Quick

O Amazon Quick é frequentemente apresentado por seus agentes de chat, mas a elegibilidade HIPAA se aplica ao workspace inteiro, não a uma funcionalidade isolada. A plataforma é composta pelos seguintes blocos:

• Chat — interface principal onde o usuário faz perguntas em linguagem natural.
• Agentes de chat — processam cada requisição. Podem ser configurados com instruções, fundamentados em bases de conhecimento e equipados com ferramentas para agir.
• Spaces (Espaços) — organizam os recursos que um agente precisa: documentos, dashboards, datasets, bases de conhecimento e conectores de ação.
• Integrações — conectam o Amazon Quick ao seu ambiente via bases de conhecimento para conteúdo não estruturado (como Amazon S3, Microsoft SharePoint e Atlassian Confluence), conexões de dados estruturados, conectores de ação e extensões (Chrome, Slack, Microsoft Teams e Microsoft 365).

O PHI chega ao Amazon Quick por dois caminhos distintos, cada um com controles diferentes. O caminho não estruturado passa pelas bases de conhecimento, com ACLs em nível de documento avaliadas no momento da consulta. O caminho estruturado passa pelo Amazon Quick Sight lendo seus bancos de dados e data lakes, com segurança em nível de linha e coluna.

Nota sobre SPICE: o SPICE é o motor de consulta em memória do Amazon Quick Sight. Um dataset SPICE usa a chave gerenciada pelo cliente padrão da conta na criação. Para importar um dataset existente para uma nova chave padrão, é necessário realizar um refresh completo. Se seus dados incluem PHI, inclua o SPICE na sua estratégia de criptografia e nas decisões de minimização de dados.

O que o Amazon Quick oferece para ambientes regulamentados

Infraestrutura gerenciada e criptografia

O Amazon Quick é um serviço totalmente gerenciado. A AWS opera a infraestrutura subjacente conforme o Modelo de Responsabilidade Compartilhada da AWS. A criptografia em repouso está ativa por padrão com chaves gerenciadas pela AWS. Registrar uma chave gerenciada pelo cliente via AWS Key Management Service é opcional e não é um requisito da HIPAA — mas exige assinatura Enterprise. Para dados em trânsito, o Amazon Quick usa TLS. Para conexões de banco de dados, é necessário habilitar TLS/SSL explicitamente.

Atenção: feedbacks de usuários sobre respostas de chat, incluindo comentários em texto livre, não são criptografados com sua chave gerenciada pelo cliente. Trate o feedback como uma superfície potencial de PHI.

Seus dados não treinam os modelos

O Amazon Quick não usa dados do cliente para treinar ou melhorar os modelos de linguagem subjacentes.

Controle de acesso e federação de identidade

O Amazon Quick suporta controle de acesso baseado em funções (RBAC) e login único (SSO) via AWS IAM Identity Center, Microsoft Active Directory e provedores de identidade SAML 2.0. Para cargas de trabalho de BI, é possível complementar com segurança em nível de linha e coluna.

Auditoria e monitoramento

O Amazon Quick emite sinais de auditoria distintos que não são intercambiáveis:

• AWS CloudTrail — registra operações de API e eventos não-API suportados. Captura quem fez o quê e quando, mas não o conteúdo das mensagens de chat.
• Amazon CloudWatch — logs entregues pela AWS (vended logs) com cinco tipos: conversas de chat (CHAT_LOGS), feedback de usuários (FEEDBACK_LOGS), horas de agente e pesquisa (AGENT_HOURS_LOGS), uso de armazenamento de índice (INDEX_USAGE_LOGS) e sincronização de arquivos de base de conhecimento (KB_FILE_SYNC_LOGS). É aqui que ficam “o que o usuário perguntou e o que o Amazon Quick respondeu”.

Como logs de chat e feedback podem conter PHI, aplique mascaramento de dados do CloudWatch Logs e confirme que cada sinal cobre o evento que você pretende rastrear antes de usá-lo para fins de conformidade.

O que o Amazon Quick não faz

O Amazon Quick governa acesso, recuperação e interação. Ele não é uma plataforma de engenharia de dados. Em contextos HIPAA, algumas necessidades ficam fora do Amazon Quick e devem ser atendidas por outros serviços da AWS:

• Desidentificação e transformação: o Amazon Quick não desidentifica PHI. Use AWS Glue DataBrew para preparação visual e redação de dados, ou AWS Glue para pipelines de Extração, Transformação e Carga (ETL).
• Governança de data lake: para dados estruturados que o Amazon Quick Sight consulta via data lake, a governança em nível de coluna e linha é responsabilidade do AWS Lake Formation, não do Amazon Quick.
• Salvaguardas administrativas e físicas: treinamento de equipe, análise de riscos e procedimentos de violação continuam sendo responsabilidade sua, independentemente das ferramentas usadas.

Caso de uso: AnyCompany Health Plan

Para ilustrar a arquitetura recomendada, a AWS apresenta um plano de saúde fictício chamado AnyCompany. A organização quer duas coisas: permitir que sua equipe de gestão de cuidados faça perguntas sobre documentos de apólices e apelações em linguagem natural, e oferecer dashboards de autoatendimento sobre dados de sinistros para líderes operacionais. Ambos os casos tocam PHI.

O ambiente tem dois caminhos de dados:

• Caminho não estruturado (documentos de apólices e registros médicos): Amazon S3 → Base de conhecimento com ACLs em nível de documento → Amazon Quick
• Caminho estruturado (sinistros): Amazon S3 → AWS Glue ETL (curadoria) → AWS Glue DataBrew (desidentificação) → AWS Glue Data Catalog + AWS Lake Formation (permissões de linha/coluna) → Dataset do Amazon Quick Sight via Amazon Athena (segurança em nível de linha e coluna)

Os dois fluxos convergem em um agente de chat do Amazon Quick com SSO federado, espaço com privilégio mínimo, guardrails e logs do CloudWatch.

O administrador da AnyCompany segue esta sequência de implementação:

1. Assina o BAA e provisiona via AWS Management Console.
2. Define os controles irreversíveis no dia zero: registra a chave gerenciada pelo cliente antes de criar qualquer recurso de IA do Amazon Quick, e define o modelo de identidade no IAM Identity Center.
3. Prepara o caminho estruturado fora do Amazon Quick usando Glue, DataBrew e Lake Formation.
4. Cria uma base de conhecimento com ACLs habilitadas na criação (esse controle não pode ser ativado depois).
5. Cria um espaço dedicado e um agente de chat personalizado com escopo restrito, pesquisa web desabilitada e guardrails configurados.
6. Conecta os dashboards com segurança em nível de consulta.
7. Ativa os sinais de auditoria antes de integrar usuários.
8. Valida com fluxos sem PHI antes de expandir para trabalhos com PHI.

Boas práticas e decisões irreversíveis

Segurança para IA agêntica

A AWS publicou quatro princípios de segurança para IA agêntica em abril de 2026:

• Princípio 1: Adicione salvaguardas de agente sobre seu framework de segurança existente — não crie uma postura paralela.
• Princípio 2: Confie em controles determinísticos (políticas IAM, ACLs, guardrails configurados por admins) mais do que em instruções baseadas em prompts.
• Princípio 3: Aplique defesa em profundidade nas três camadas — Perceber (fontes de dados), Raciocinar (processamento LLM) e Agir (conectores e automações).
• Princípio 4: Expanda a autonomia progressivamente: comece em modo somente leitura com dados sem PHI e adicione capacidades uma a uma.

Três decisões que não podem ser desfeitas

• Registre sua chave KMS primeiro. A chave de dados é definida na primeira vez que dados de IA do Amazon Quick são criados na conta. Depois disso, não pode ser alterada. Se a chave for excluída, a única recuperação é cancelar e reativar a assinatura — o que remove permanentemente todos os dados do Amazon Quick. Importante: chaves gerenciadas pelo cliente desabilitam a memória de chat; contas configuradas com essa opção não suportam esse recurso.
• Escolha seu modelo de identidade com cuidado. As opções são IAM Identity Center, Active Directory, federação IAM e usuários locais do Quick. A detecção de usuários inativos funciona apenas com IAM Identity Center ou Active Directory. Trocar de provedor de identidade após o deployment exige reprovisionar todas as permissões.
• Crie bases de conhecimento com ACLs desde o início. Para fontes suportadas (Amazon S3, Google Drive, SharePoint, Confluence Cloud e OneDrive), a decisão de habilitar ACLs em nível de documento é permanente. Não é possível habilitá-las em uma base de conhecimento criada sem elas.

Auditoria, retenção e monitoramento

Nenhum dos sinais de auditoria flui por padrão — você precisa ativá-los. Configure um trail do CloudTrail, habilite a entrega de logs do CloudWatch (CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS), aplique mascaramento de dados para PHI, defina retenção mínima de seis anos, considere S3 Object Lock no arquivo de logs e integre alertas ao seu SIEM.

Limitações conhecidas

• Sem BAA nos planos Free ou Plus — é necessário provisionar pelo AWS Management Console.
• Sem replicação entre regiões — a recuperação de desastres fica limitada a uma única região.
• Guardrails são probabilísticos, não determinísticos — eles reduzem o risco, mas não o eliminam.
• Conectores de terceiros estendem suas obrigações de BAA — a responsabilidade de conformidade segue os dados.
• A memória de conversas pode conter PHI ecoado — defina políticas de retenção e aplique mascaramento.

Conclusão

O Amazon Quick oferece às organizações de saúde regulamentadas — e aos associados de negócios que as atendem — um workspace de IA gerenciado elegível para HIPAA em toda a sua gama de capacidades: IA agêntica, recuperação de conhecimento, business intelligence, automação e pesquisa.

O caminho para um deployment em conformidade segue uma sequência clara: entender a diferença entre elegível e em conformidade; assinar o BAA em uma conta provisionada pelo AWS Management Console; definir os controles irreversíveis primeiro; minimizar as superfícies de leitura e ação do agente; mascarar PHI nos logs; e validar com a equipe de segurança antes de escalar para fluxos com PHI.

As expectativas de conformidade evoluem tão rápido quanto a tecnologia. A AWS publicou seus quatro princípios de segurança para IA agêntica em abril de 2026 e o Well-Architected Agentic AI Lens em junho de 2026. Organizações que constroem sobre controles determinísticos em nível de infraestrutura hoje estarão bem posicionadas à medida que as expectativas regulatórias alcançarem o que a IA agêntica já é capaz de fazer.

Fonte

Deploy AI in a HIPAA-eligible environment with Amazon Quick (https://aws.amazon.com/blogs/machine-learning/deploy-ai-in-a-hipaa-eligible-environment-with-amazon-quick/)

O que é o AWS Continuum para Vulnerabilidades de Código

A AWS anunciou a disponibilidade geral do AWS Continuum for code vulnerabilities — uma ferramenta que descobre, valida, prioriza e corrige vulnerabilidades em código na velocidade das máquinas. Ou seja, sem depender de revisões manuais lentas para fechar cada ciclo de segurança.

Como o Serviço Funciona

O Continuum começa construindo um grafo de contexto a partir do ambiente AWS da organização. Esse grafo inclui a topologia dos recursos, os relacionamentos de identidade e a acessibilidade de rede. Com isso, o serviço entende quais recursos fazem parte de cada aplicação e quais descobertas de segurança representam um risco real para o negócio — não apenas alertas genéricos.

A partir daí, o fluxo de trabalho segue etapas bem definidas:

• Ingestão e escaneamento: o serviço absorve os resultados de vulnerabilidades já existentes e escaneia o código da aplicação.
• Validação em sandbox: confirma quais descobertas são de fato exploráveis, testando-as em um ambiente isolado.
• Priorização por impacto: as vulnerabilidades são ordenadas pelo impacto no negócio, não apenas pela severidade técnica.
• Remediação direta no fluxo do desenvolvedor: o serviço gera pull requests com as correções diretamente nos fluxos de trabalho dos times de desenvolvimento, acompanhados de prova de explorabilidade e avaliação do raio de explosão (blast radius assessment).

Escolha do Modelo de IA e Modos de Operação

O Continuum seleciona automaticamente o modelo de Inteligência Artificial (IA) mais adequado para cada tarefa do processo. Além disso, o serviço opera em dois modos distintos:

• Modo Learn (Aprendizado): o ponto de partida. Nesse modo, o Continuum propõe as correções para que a equipe aprove antes de qualquer ação.
• Modo Enforce (Aplicação): conforme a confiança na precisão do serviço aumenta, é possível migrar para esse modo, onde o Continuum age de forma autônoma dentro das regras definidas pela organização.

Essa progressão gradual — de proposta para autonomia — é um diferencial importante para equipes que precisam ganhar confiança na ferramenta antes de liberar ações automáticas em produção.

Integração com o Ecossistema de Segurança da AWS

O AWS Continuum não substitui as ferramentas de segurança existentes — ele trabalha ao lado delas. O serviço se integra com o Amazon GuardDuty e o AWS Security Hub, complementando o ecossistema de segurança já utilizado pelas equipes.

Para verificar em quais regiões o AWS Continuum já está disponível, consulte a tabela de regiões da AWS. Para saber mais sobre o serviço, acesse a página do produto AWS Continuum.

Fonte

AWS Continuum for code vulnerabilities is now generally available (https://aws.amazon.com/about-aws/whats-new/2026/10/aws-continuum-for-code-vulnerabilities-is-now-generally-available)

O que é o IAM Roles Anywhere e por que ele importa

Usar credenciais temporárias é uma boa prática de segurança amplamente recomendada para reduzir o risco de comprometimento de credenciais de longa duração. O AWS IAM Roles Anywhere estende esse modelo para workloads que rodam fora da Amazon Web Services (AWS), permitindo que eles obtenham credenciais temporárias do AWS Identity and Access Management (IAM) por meio de certificados digitais.

A base dessa integração é a Infraestrutura de Chave Pública (PKI), responsável pela geração, distribuição e verificação de certificados digitais usando criptografia assimétrica. A AWS publicou um guia detalhado de boas práticas sobre como integrar sua PKI com o IAM Roles Anywhere — e é exatamente isso que vamos explorar aqui.

Nota importante: A partir de julho de 2026, o AWS Certificate Manager (ACM) passa a suportar certificados públicos exportáveis para workloads fora da AWS, além do protocolo ACME para emissão e renovação automatizada de certificados em ambientes externos. Essas capacidades complementam o IAM Roles Anywhere em cenários híbridos.

Identidades de workload com certificados X.509

Em ambientes com múltiplos workloads, cada um deve ter uma identidade única e permissões bem definidas. Ferramentas de PKI como o Active Directory Certificate Services permitem gerenciar essas identidades centralmente. A recomendação da AWS é aplicar os mesmos princípios de segregação de workloads à PKI e ao IAM Roles Anywhere.

A prática recomendada é emitir um certificado X.509 distinto para cada workload, com atributos de identidade específicos assinados pela sua Autoridade Certificadora (CA). Isso garante que o Workload A tenha um escopo de acesso completamente diferente do Workload B ao acessar recursos AWS.

Como funcionam as credenciais temporárias

O fluxo de obtenção de credenciais temporárias começa quando o workload apresenta seu certificado X.509 ao IAM Roles Anywhere. O serviço realiza a validação da assinatura verificando o emissor e o subject do certificado antes de liberar as credenciais.

Para habilitar esse processo, é necessário configurar um modelo de confiança no IAM Roles Anywhere — seja fazendo upload do certificado digital da sua CA como um trust anchor (âncora de confiança), seja referenciando um certificado existente da AWS Private Certificate Authority (AWS Private CA).

A configuração do modelo de confiança segue três etapas, conforme descrito no artigo Extend AWS IAM Roles Anywhere to workloads outside of AWS:

• Criar um trust anchor.
• Configurar roles IAM com a trust policy do IAM Roles Anywhere, que serão assumidas pelos workloads externos.
• Configurar profiles com as roles IAM e anexar as session policies relevantes.

Atributos de certificado e o modelo de confiança

O modelo de confiança do IAM Roles Anywhere gira em torno dos atributos presentes nos certificados X.509. Os certificados são registros binários com pares chave/valor codificados. O IAM Roles Anywhere extrai valores dos campos Common Name (CN) do subject, do issuer e do Subject Alternative Name (SAN) do certificado autenticador, disponibilizando-os como tags de principal para avaliação de políticas.

Veja um exemplo de certificado PEM decodificado com ferramentas como o openssl:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e0:5d:b7:72:56:fa:75:e3
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: C=US, ST=CA, L=San Francisco, O=MyCompany Inc., OU=AC, CN=MyCompany CA
        Validity
            Not Before: Sep 15 00:09:17 2023 GMT
            Not After : Sep 18 00:09:17 2023 GMT
        Subject: C=US, O=MyCompany, OU=eCommerce, CN=WorkloadA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:3b:74:e1:68:06:fa:b0:3d:fe:f7:5f:74:80:05:
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:ecommerce.mycompany.com, DNS:*ecommerce.mycompany.com,
                URI:spiffe://mycompany.com/workload/ecommerce
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
    Signature Algorithm: ecdsa-with-SHA512
        30:64:02:30:19:a7:a0:33:49:ce:e1:cb:76:6e:c0:f3:c5:66:

A partir desse certificado, o IAM Roles Anywhere gera as seguintes tags de principal, usadas nas condições das políticas:

"aws:PrincipalTag/x509Subject/CN": "WorkloadA"
"aws:PrincipalTag/x509Issuer/CN": "MyCompany CA"
"aws:PrincipalTag/x509SAN/DNS": "ecommerce.mycompany.com"
"aws:PrincipalTag/x509SAN/URI": "spiffe://mycompany.com/workload/ecommerce"
"aws:PrincipalTag/x509SAN/Name/CN": "WorkloadA"

Atenção: Um Subject CN vazio no certificado não é suportado pelo IAM Roles Anywhere. Além disso, a AWS recomenda configurar períodos de validade curtos nos certificados emitidos para workloads — certificados de vida curta limitam a janela de exposição em caso de comprometimento e reduzem a necessidade de revogação ativa.

Trust policy e permissões efetivas das credenciais

Para que a chamada à API CreateSession seja autorizada, a trust policy da role IAM precisa confiar no service principal do IAM Roles Anywhere. Veja um exemplo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/x509Issuer/CN": "MyCompany CA",
          "aws:PrincipalTag/x509Subject/CN": "WorkloadA",
          "aws:PrincipalTag/x509SAN/Name/CN": "WorkloadA"
        },
        "ArnEquals": {
          "aws:SourceArn": [
            "arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID"
          ]
        }
      }
    }
  ]
}

Como boa prática de segurança, a AWS recomenda usar condições adicionais baseadas nas tags de PrincipalTag extraídas do certificado para restringir ainda mais a autorização. Se os workloads usam certificados efêmeros com Subject CN dinâmico, as tags de issuer ou SAN podem ser usadas nas condições da trust policy.

As permissões efetivas das credenciais temporárias resultam da interseção entre políticas baseadas em recurso, em identidade e de sessão. Ao configurar o trust anchor e o profile no IAM Roles Anywhere com session policies, é possível limitar as permissões de cada sessão com granularidade.

Posicionamento do trust anchor na hierarquia de certificados

Dependendo da plataforma de CA utilizada, é possível configurar uma ou mais CAs intermediárias na hierarquia de PKI. O nível em que o trust anchor é posicionado determina quais certificados de entidade final o IAM Roles Anywhere aceita — e, portanto, quais workloads estão autorizados a assumir uma role.

Para criar um trust anchor, exporte o bundle de certificados da CA emissora da sua plataforma de CA externa no formato PEM e faça o upload no console do trust anchor.

Credential helper: obtendo credenciais temporárias na prática

Para obter credenciais temporárias do IAM Roles Anywhere, a AWS disponibiliza o credential helper, compatível com o recurso credential_process dos SDKs AWS. Ele recebe a chave privada do workload e o certificado assinado pela CA como parâmetros principais.

Exemplo de uso:

$ ./aws_signing_helper credential-process \
    --certificate /path/to/certificate \
    --private-key /path/to/private-key \
    --trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID \
    --profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID \
    --role-arn arn:aws:iam::account:role/role-name-with-path

Quando usado com SDKs AWS, as credenciais temporárias ficam em memória e são renovadas automaticamente. Já a AWS Command Line Interface (AWS CLI) invoca o credential-process a cada comando, criando uma nova sessão e adicionando latência. Para evitar esse problema, a AWS recomenda usar o comando update, que grava as credenciais renovadas em um arquivo lido pela CLI sem invocar o credential-process novamente.

Contudo, como as credenciais escritas em arquivo podem ser lidas por qualquer usuário ou processo com acesso ao arquivo, a recomendação é usar o comando serve — que disponibiliza as credenciais temporárias via endpoint local usando as mesmas URIs e headers do Instance Metadata Service Version 2 (IMDSv2), sem necessidade de arquivos de configuração AWS.

A partir de dezembro de 2024, o credential helper (versão 1.4.0 e posterior) passou a suportar Trusted Platform Module (TPM) 2.0.

Certificados just-in-time versus certificados de vida curta

Para mitigar riscos de exposição de recursos críticos, a AWS recomenda o uso de certificados just-in-time ou de vida curta como identidade de workload.

Certificados just-in-time são emitidos pela CA para uso imediato em uma autenticação específica. A CA usa as roles e políticas definidas no IAM para determinar quando e sob quais condições o workload pode estabelecer uma sessão. Como as credenciais são recriadas a cada requisição, mudanças de role se aplicam em tempo real — sem necessidade de revogar acessos manualmente. Esse modelo requer suporte da sua CA, então é importante verificar a compatibilidade antes de implementar.

Para certificados de vida curta, a AWS recomenda calibrar os períodos de validade conforme os requisitos do negócio, o ciclo de vida do workload e a tolerância a risco da organização. A AWS Private Certificate Authority oferece um modo de CA para certificados de vida curta (validade abaixo de 7 dias), com preço de US$ 50/mês — bem abaixo dos US$ 400/mês do modo de CA de uso geral —, tornando-o atraente para identidades efêmeras como containers e funções serverless. Saiba mais em How to use AWS Private CA short-lived certificate mode. O uso de credenciais de vida curta também é um pilar da arquitetura de zero trust na AWS.

Boas práticas para armazenamento de chaves privadas

A chave privada é criada pelo proprietário do certificado no momento da solicitação via CSR (Certificate Signing Request — Requisição de Assinatura de Certificado). A CA não cria nem armazena a chave privada — e ninguém fora dos administradores deve ter acesso a esse material. Guardrails devem impedir que as chaves sejam armazenadas em repositórios online.

O credential helper do IAM Roles Anywhere suporta integração com módulos compatíveis com PKCS #11 (a partir da versão 1.1.0), permitindo usar chaves privadas armazenadas em módulos de segurança de hardware (HSMs) ou armazenamentos seguros baseados em software, sem gravá-las em disco. Veja os detalhes em How to implement cryptographic modules to secure private keys used with IAM Roles Anywhere.

Desde dezembro de 2024, o credential helper também suporta TPM 2.0, permitindo que as chaves privadas sejam geradas dentro do TPM e marcadas como não exportáveis. Com chaves protegidas por TPM, a chave privada não pode ser extraída mesmo que o host do workload seja comprometido — essa é a proteção mais robusta disponível para workloads on-premises e híbridos usando IAM Roles Anywhere.

Para organizações que não utilizam módulos PKCS #11, o IAM Roles Anywhere suporta a versão 1.0.5 do credential helper para certificados X.509 e chaves privadas armazenadas nos certificate stores do macOS e Windows. No Windows, tanto CryptoAPI quanto CNG (Cryptography API: Next Generation) são suportados; no macOS, o Keychain é suportado. Nesses ambientes, a chave privada nunca é lida diretamente — a operação de assinatura é delegada ao secure store.

Se você tiver múltiplos certificados, use a flag --cert-selector do credential helper para localizar um certificado específico pelo subject, issuer ou número de série. Exemplo via arquivo JSON:

[
  {
    "Key": "x509Subject",
    "Value": "CN=Subject"
  },
  {
    "Key": "x509Issuer",
    "Value": "CN=Issuer"
  },
  {
    "Key": "x509Serial",
    "Value": "15D19632234BF759A32802C0DA88F9E8AFC8702D"
  }
]

Se o arquivo acima for salvo como selector.json, ele pode ser referenciado com --cert-selector file://path/to/selector.json. O mesmo argumento também pode ser passado diretamente pela linha de comando:

--cert-selector Key=x509Subject,Value=CN=Subject Key=x509Issuer,Value=CN=Issuer Key=x509Serial,Value=15D19632

Monitoramento de expiração de certificados

Certificados expirados podem causar falhas de autenticação e deixar sistemas vulneráveis. O IAM Roles Anywhere permite receber notificações de expiração tanto para certificados de CA quanto para certificados de entidade final, por meio dos seguintes canais:

• Expiração de certificado de CA: CloudWatch, Amazon EventBridge e AWS Health — notificação padrão 45 dias antes da expiração.
• Expiração de certificado de entidade final: EventBridge e AWS Health — notificação padrão 45 dias antes da expiração.

Esses limites de notificação são configurações padrão e podem ser personalizados conforme as instruções em Customize notification settings in IAM Roles Anywhere.

Rotação de certificados do trust anchor

A AWS recomenda rotacionar os certificados do trust anchor usando deployments blue/green para garantir a disponibilidade do serviço durante a transição. A automação deve ser integrada ao pipeline de deployment blue/green para testar a rotação de certificados.

Nessa abordagem, dois trust anchors são criados — um para cada ambiente. Isso permite testar o processo de rotação em um ambiente de staging controlado antes de aplicá-lo em produção, reduzindo o risco de indisponibilidades relacionadas a certificados.

Template de solução para deploy

A AWS disponibiliza um template de solução no repositório IAM Roles Anywhere — External PKI Integration no GitHub. O template realiza as seguintes etapas principais via AWS CloudFormation:

• Cria uma role IAM distinta com políticas com escopo nos recursos que o workload necessita.
• Atribui um relacionamento de confiança a um principal do IAM Roles Anywhere.
• Cria um trust anchor usando um bundle de certificados de uma CA externa.
• Cria um profile com as roles IAM necessárias.

Os principais parâmetros do template são:

• TrustAnchorCertificateBody (obrigatório): certificado X.509 da sua CA em formato PEM.
• WorkloadSubjectCN (padrão: WorkloadA): Subject CN do certificado do workload, usado nas condições da trust policy.
• WorkloadIssuerCN (padrão: MyCompany CA): Issuer CN do certificado da CA, usado nas condições da trust policy.
• WorkloadSANCN (padrão: WorkloadA): SAN CN do certificado do workload.
• SessionDurationSeconds (padrão: 3600): duração máxima da sessão em segundos (900–43200).
• NotificationEmail (opcional): endereço de e-mail para notificações de expiração. Quando fornecido, cria um tópico do Amazon Simple Notification Service (Amazon SNS) e uma regra do EventBridge.

Importante: O valor de SessionDurationSeconds não pode exceder o MaxSessionDuration da role IAM, que por padrão é 3600 segundos. Se você solicitar uma sessão mais longa do que o permitido, a API CreateSession do IAM Roles Anywhere retornará erro. O template mantém ambos os valores sincronizados automaticamente.

O template também impõe três condições de atributos de certificado na trust policy IAM: Issuer CN, Subject CN e SAN CN devem corresponder aos valores configurados como parâmetros. Além disso, a trust policy restringe a assunção da role ao ARN (Amazon Resource Name — Nome de Recurso da Amazon) específico do trust anchor, impedindo que outros trust anchors na mesma conta assumam aquela role.

Conclusão

O AWS IAM Roles Anywhere, combinado com certificados X.509, oferece uma forma dinâmica e segura de gerenciar identidades de workloads externos e emitir credenciais de acesso temporárias. Entender o modelo de confiança, usar atributos de certificado nas políticas e implementar controle de acesso granular são os pilares para obter o máximo de segurança nessa integração.

A escolha entre certificados just-in-time e de vida curta depende dos requisitos específicos de cada organização. O armazenamento seguro das chaves privadas — seja via HSM, TPM ou certificate stores do SO — é essencial para manter a integridade da infraestrutura de segurança. E a rotação regular dos certificados do trust anchor garante a confiabilidade do sistema a longo prazo.

Para um guia completo de planejamento de deployment, incluindo arquitetura de rede, monitoramento e considerações operacionais, consulte Planning for your IAM Roles Anywhere deployment. Dúvidas podem ser enviadas ao AWS re:Post ou ao AWS Support.

Fonte

Best practices for integrating IAM Roles Anywhere with your PKI (https://aws.amazon.com/blogs/security/best-practices-for-integrating-iam-roles-anywhere-with-your-pki/)

O problema: dados sensíveis atrás do firewall corporativo

Quando os dados empresariais ficam dentro de um data center privado ou atrás de um firewall corporativo, surge um desafio clássico: como permitir que ferramentas de Inteligência Artificial (IA) e dashboards do Amazon Quick acessem essas informações sem expô-las à internet pública?

Para muitas empresas, rotear tráfego pela internet pública é simplesmente inaceitável. Frameworks regulatórios como HIPAA, FedRAMP e PCI-DSS exigem que dados sensíveis permaneçam dentro de perímetros de rede controlados. Mesmo quando conformidade não é o principal motivador, expor caminhos internos de dados amplia a superfície de ataque, complica trilhas de auditoria e introduz latência variável que degrada a experiência do usuário.

A AWS publicou um guia técnico detalhando como resolver exatamente esse problema: conectar fontes de dados on-premises ao Amazon Quick de forma totalmente privada, usando AWS PrivateLink.

Como o Amazon Quick acessa dados privados

O Amazon Quick é um workspace com IA que reúne pesquisa, análise, automação e conversação em uma única experiência. Para entender a arquitetura de conectividade privada, é importante distinguir dois caminhos de tráfego:

• Tráfego voltado ao usuário: Cobre o acesso ao console, chamadas de API, uso do Quick Desktop e dashboards embarcados. Todo esse tráfego é roteado por meio de VPC endpoints (Interface Endpoints via PrivateLink).
• Tráfego de busca de dados: Ocorre quando o próprio Quick precisa acessar suas fontes de dados para buscar informações. Esse caminho é gerenciado pelas VPC connections, que são Interfaces de Rede Elásticas (ENIs) inseridas diretamente na sua Nuvem Privada Virtual (VPC).

Esses dois caminhos exigem dois mecanismos distintos que trabalham em conjunto, e toda a arquitetura descrita no guia da AWS gira em torno dessa separação.

Quais componentes do Quick usam VPC connections?

• Amazon Quick Sight: Consulta bancos de dados on-premises (PostgreSQL, MySQL, SQL Server, Oracle, entre outros) diretamente via ENIs na sua VPC.
• Amazon Quick Flows e Amazon Quick Automate: Automatizam tarefas e orquestrações complexas, invocando conectores de ação, incluindo servidores MCP hospedados privadamente na sua VPC.
• Quick Agents: Sustentam interações conversacionais e podem invocar conectores de ação diretamente. Quando um agente chama uma API interna, o tráfego passa pela VPC connection.
• Amazon Quick Index: Constrói uma camada de busca unificada. Para fontes dentro da VPC ou on-premises, as VPC connections de knowledge base suportam atualmente apenas o Amazon Redshift. Fontes como Confluence, SharePoint, Box, Google Drive, OneDrive e Amazon S3 não suportam VPC connection hoje — consulte as fontes de dados VPC suportadas.
• Amazon Quick Research: Acessa fontes empresariais atrás do firewall usando a VPC connection para fontes privadas.

Configurando a conectividade privada: os quatro pilares

Pré-requisitos

Antes de configurar a conectividade privada, a AWS indica que os seguintes itens devem estar em ordem: uma conta AWS ativa com assinatura Enterprise do Amazon Quick (as VPC connections exigem essa edição), uma VPC existente na mesma região do Quick, uma conexão AWS Direct Connect ou VPN Site-to-Site já estabelecida entre a rede on-premises e a VPC, e permissões de Gerenciamento de Identidade e Acesso (IAM) para criar e gerenciar VPC endpoints, security groups e administração do Quick.

1. VPC endpoints para acesso de usuários e API

O Quick requer dois Interface VPC endpoints para acesso privado completo:

• Endpoint do website: Serviço com.amazonaws.<region>.quicksight-website. Lida com a maior parte do tráfego de usuários ao console. É necessário criar um registro A para <region>.quicksight.aws.amazon.com apontando para o DNS do VPC endpoint.
• Endpoint de API: Serviço com.amazonaws.<region>.quicksight. Lida com chamadas programáticas de API. Com o DNS privado habilitado, chamadas existentes para quicksight.<region>.amazonaws.com roteiam automaticamente pelo endpoint. Para conformidade com FIPS, usa-se com.amazonaws.<region>.quicksight-fips.

Um ponto importante destacado pela AWS: nem todas as APIs do Quick estão disponíveis pelo VPC endpoint de API. Treze APIs não são suportadas, incluindo as APIs de conectores de ação e as APIs de fluxo. Automações que gerenciam conectores ou fluxos programaticamente precisam de um caminho para o endpoint público de API — veja a documentação sobre Quick e Interface VPC endpoints.

Resolução de DNS para os endpoints

Para o endpoint do website, é necessário criar um registro A para <region>.quicksight.aws.amazon.com apontando para o DNS do VPC endpoint. Isso garante que usuários na rede corporativa resolvam a URL do Quick pelo caminho privado. Uma Zona Hospedada Privada (Private Hosted Zone) do Route 53 responde apenas a consultas de dentro das VPCs associadas, então os servidores DNS on-premises devem ser configurados para encaminhar consultas para um endpoint de entrada do Route 53 Resolver na VPC.

Políticas de VPC endpoint

As políticas de VPC endpoint restringem quais contas ou organizações podem usar o endpoint. Para o Quick, as políticas podem ser definidas por ID de conta AWS ou ID de organização. Uma limitação importante: para o endpoint do website, os campos Principal, Action e Resource devem ser todos definidos como *. Condições só podem ser especificadas com os atributos aws:PrincipalAccount ou aws:OrgId. Políticas mais restritivas ao nível de ação só são suportadas no endpoint de API.

Exemplo de política para o endpoint do website:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": ["012345678901"]
        }
      }
    }
  ]
}

Exemplo de política para o endpoint de API (restrita a ações específicas):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "quicksight:DescribeUser",
        "quicksight:ListUsers"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": ["012345678901"]
        }
      }
    }
  ]
}

2. VPC connections para acesso a fontes de dados

Enquanto os VPC endpoints lidam com o tráfego voltado ao usuário, as VPC connections lidam com o caminho do lado do servidor — ou seja, o Amazon Quick alcançando sua VPC para buscar dados em bancos de dados, fontes do Amazon Redshift e APIs internas.

Quando você cria uma VPC connection no Amazon Quick, ENIs são inseridas nas sub-redes da sua VPC. Essas ENIs permitem que o Quick troque tráfego de rede com recursos dentro da sua VPC e, por extensão, com tudo que seja alcançável a partir dela, incluindo sistemas on-premises conectados via Direct Connect ou VPN.

Antes de criar a VPC connection, é necessário criar uma Função de Execução (Execution Role) IAM dedicada. O Quick não cria essa role automaticamente. Ela precisa de uma política de permissões com as ações do Amazon EC2 que o Quick usa para gerenciar suas ENIs, e de uma política de confiança que permita ao quicksight.amazonaws.com assumir a role.

Política de permissões necessária:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DeleteNetworkInterface",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups"
      ],
      "Resource": "*"
    }
  ]
}

Política de confiança:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "quicksight.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Um detalhe técnico importante destacado pela AWS: para VPC connections criadas antes de 27 de abril de 2023, o security group associado à interface de rede do Quick não é stateful. É necessário adicionar uma regra de entrada que permita explicitamente o tráfego de retorno da fonte de dados em todas as portas (0–65535). Conexões criadas após essa data usam o comportamento stateful padrão — consulte as regras de entrada e saída de security groups.

3. VPC endpoints para serviços de dados da AWS

O Quick acessa outros serviços AWS (Amazon S3, Amazon Redshift, Amazon Athena, AWS Secrets Manager) ao recuperar dados para dashboards e análises. Para manter todo o tráfego privado, a AWS recomenda criar Interface ou Gateway VPC endpoints para cada um desses serviços na mesma VPC onde as ENIs do Quick estão alocadas:

• Amazon S3: Gateway endpoint — com.amazonaws.<region>.s3 (sem custo adicional)
• Amazon Redshift: Interface endpoint — com.amazonaws.<region>.redshift
• Amazon Athena: Interface endpoint — com.amazonaws.<region>.athena
• AWS Secrets Manager: Interface endpoint — com.amazonaws.<region>.secretsmanager
• AWS Glue: Interface endpoint — com.amazonaws.<region>.glue

4. Acesso a domínios externos obrigatórios

Mesmo com VPC endpoints configurados, os navegadores dos usuários ainda precisam alcançar alguns domínios para login, assets estáticos, métricas e integrações. Domínios sem suporte a VPC endpoint precisam de conectividade de saída, normalmente via proxy corporativo ou firewall. Entre os principais domínios sem suporte a VPC endpoint estão: *.cloudfront.net (assets estáticos como CSS e JavaScript), *.execute-api.<region>.amazonaws.com (métricas do lado do cliente) e *.kinesisvideo.amazonaws.com (streaming ao vivo de workflows de automação).

Restringindo o acesso exclusivamente ao VPC endpoint

Após configurar e testar os endpoints, é possível forçar que todo acesso à conta Quick passe obrigatoriamente pelo VPC endpoint, bloqueando completamente o acesso pela internet. O Quick oferece controles de restrição por IP e por VPC endpoint que limitam o acesso da conta a uma lista predefinida de intervalos de IP, IDs de VPC ou IDs de VPC endpoint.

Para configurar via CLI da AWS:

aws quicksight update-ip-restriction \
  --aws-account-id ACCOUNT_ID \
  --region REGION \
  --enabled \
  --vpc-endpoint-id-restriction-rule-map \
  vpce-001122def=CorporateVpcEndpoint

Alguns pontos críticos sobre esse recurso: as regras de IP e VPC endpoint se aplicam ao acesso web, embarcado e móvel do Quick, mas não restringem o acesso à API pública. Para restringir chamadas de API de fontes específicas, use políticas IAM com condições aws:SourceIp ou aws:SourceVpce. As regras podem levar até 10 minutos para entrar em vigor. Certifique-se de que seu próprio IP ou VPC endpoint esteja incluído nas regras antes de habilitá-las — caso contrário, você perderá o acesso à sua própria conta.

Controle de identidade e federação

A conectividade de rede privada mantém o tráfego fora da internet, mas não responde à pergunta de quem pode acessar o quê dentro do Quick. O Amazon Quick usa o AWS IAM Identity Center como ponto central para gerenciamento de identidade da força de trabalho, conectando-se ao provedor de identidade corporativo existente via SAML 2.0 para autenticação e SCIM 2.0 para provisionamento automático de usuários e grupos.

O Quick suporta três papéis base: Admin (acesso completo de gerenciamento), Author (criação e publicação de dashboards, agentes, fluxos e apps) e Reader (consumo de dashboards publicados e interação com agentes). Além disso, o Quick Sight suporta Segurança em Nível de Linha (RLS) e Segurança em Nível de Coluna (CLS) para controle granular de quais dados cada usuário ou grupo pode visualizar. As mesmas políticas de segurança que restringem visualizações tradicionais também restringem o que a IA pode referenciar ao gerar respostas.

Para configuração passo a passo do IAM Identity Center com seu provedor de identidade, a AWS disponibiliza o guia Introdução ao IAM Identity Center. Para configurações avançadas de RLS/CLS e federação de identidade, consulte a documentação do IAM Identity Center.

Atenção: Para contas Quick integradas ao IAM Identity Center, a autenticação via navegador requer acesso aos endpoints públicos de login da AWS e do IAM Identity Center. VPC endpoints não cobrem esse caminho de login. É necessário fornecer conectividade de saída via NAT gateway ou proxy — veja as considerações para acesso privado no IAM Identity Center.

Custos estimados

A AWS detalha o modelo de custo dos principais componentes desta arquitetura:

• Interface VPC endpoints: US$ 0,01/hora por Zona de Disponibilidade (AZ) + US$ 0,01/GB processado (~US$ 7,20/mês por endpoint por AZ)
• Gateway VPC endpoints (S3): Sem custo adicional
• VPC connections (ENIs do Quick): Incluídas no Quick Enterprise, sem custo adicional
• NAT gateway (para domínios externos): US$ 0,045/hora + US$ 0,045/GB processado (~US$ 32/mês fixo)
• VPC Flow Logs: Taxas de ingestão do CloudWatch Logs, variando com o volume de tráfego

Para otimizar custos, a AWS recomenda usar Gateway endpoints para S3 (gratuitos) em vez de Interface endpoints, habilitar VPC Flow Logs seletivamente apenas nas ENIs de endpoint (em vez de toda a VPC), e avaliar se todos os domínios externos precisam de NAT gateway ou se um proxy direcionado seria mais econômico.

Boas práticas de segurança

Nem o isolamento de rede nem os controles de identidade são suficientes sozinhos. A AWS enfatiza que a arquitetura depende de ambas as camadas trabalhando juntas:

• Aplique políticas de mínimo privilégio (least-privilege) nos endpoints: restrinja endpoints do website por aws:PrincipalAccount ou aws:OrgId, e no endpoint de API, limite as ações apenas às que sua automação realmente precisa.
• Use security groups em camadas: tanto nas ENIs dos VPC endpoints (tráfego de usuário) quanto nas ENIs das VPC connections (tráfego de dados).
• Habilite VPC Flow Logs em todas as ENIs de endpoint para capturar metadados de tráfego para monitoramento de segurança e auditoria de conformidade.
• Crie VPC connections separadas por ambiente (dev, staging, produção) para evitar acesso cruzado entre ambientes.
• Monitore com CloudWatch: configure alarmes para as métricas PacketsDropped e ActiveConnections.

Conclusão

A arquitetura descrita pela AWS estabelece quatro controles complementares: VPC endpoints mantêm o tráfego de usuários privado, VPC connections oferecem ao Quick um caminho privado para as fontes de dados, a federação de identidade determina quem pode acessar o quê, e as restrições de VPC endpoint tornam o caminho privado obrigatório. Com isso em vigor, Quick Agents podem consultar bancos de dados on-premises, Quick Research pode investigar fontes empresariais atrás do firewall, Quick Sight pode visualizar dados sensíveis e Quick Flows pode orquestrar sistemas internos — tudo sem que os dados atravessem a internet pública.

A AWS recomenda começar pelos VPC endpoints para acesso de usuários e API, validar o acesso antes de avançar para as VPC connections de fontes de dados, e habilitar as restrições de VPC endpoint apenas após confirmar que todos os padrões de acesso funcionam pelo caminho privado.

Fonte

Securing Quick access from corporate networks with AWS PrivateLink (https://aws.amazon.com/blogs/machine-learning/securing-quick-access-from-corporate-networks-with-aws-privatelink/)

Detecção antes do alarme: o que o caso PHP2Shell revela sobre o cenário atual de ameaças

A equipe de Inteligência de Ameaças da Amazon registrou algo preocupante: uma tentativa de exploração da vulnerabilidade conhecida como PHP2Shell já havia sido detectada em 17 de outubro de 2026 — quatro dias antes de as CVEs relacionadas (CVE-2026-109618 e CVE-2026-109619) serem divulgadas publicamente. A detecção ocorreu por meio da rede MadPot, sistema interno de honeypots (armadilhas digitais usadas para atrair e monitorar agentes maliciosos) da AWS.

A tentativa partiu de um endereço IP associado a uma rede comercial de anonimização. O fato de um honeypot ter sido alvo durante o período de embargo — quando a vulnerabilidade ainda estava sob sigilo — sugere fortemente que o ator por trás da ação obteve informações sobre o exploit antes da divulgação oficial. Como isso aconteceu ainda é incerto.

A linha do tempo da exploração

O embargo estava programado para ser encerrado em 21 de outubro de 2026, às 14h UTC. Mas antes mesmo disso, a Inteligência de Ameaças da Amazon já identificava provas de conceito (PoCs) circulando: a mais antiga registrada foi às 2h UTC do mesmo dia — ou seja, 12 horas antes da janela oficial de divulgação.

Entre 2h e 8h UTC de 21 de outubro, múltiplas tentativas de exploração do PHP2Shell foram detectadas contra os sensores MadPot, originadas de diferentes infraestruturas anonimizadas. A variação nos payloads e nas escolhas de infraestrutura indica que não se tratava de um único ator, mas de múltiplos grupos agindo de forma independente.

Após o levantamento oficial do embargo e a publicação do patch, novos exploits de prova de conceito surgiram em questão de horas, e foram usados contra os sensores quase imediatamente. Hoje, o PHP2Shell está sendo explorado ativamente em larga escala.

Vale destacar que a análise técnica ainda está em andamento, e não há confirmação se alguma dessas tentativas teria obtido sucesso em sistemas reais.

Duas lições que vão além do PHP2Shell

1. O embargo protege os defensores — mas não de todos

A divulgação coordenada de vulnerabilidades (Coordinated Disclosure) continua sendo o modelo correto. Ela garante que fornecedores tenham tempo para desenvolver e distribuir correções antes que o problema se torne público. No entanto, o caso PHP2Shell demonstra que o período de embargo não pode ser tratado como uma garantia de segurança absoluta.

Se um agente malicioso descobre a mesma vulnerabilidade de forma independente — ou obtém informações vazadas durante o período de sigilo —, a exploração pode começar antes da data oficial de divulgação. Isso significa que, ao investigar um possível comprometimento relacionado ao PHP2Shell, o ponto de partida deve ser pelo menos 17 de outubro, não 21 de outubro.

2. O tempo entre patch e exploit funcional está encolhendo

Historicamente, a maioria das explorações observadas ocorria após a publicação de uma prova de conceito pública. Um grupo pequeno de atores mais capacitados desenvolvia o exploit, e os demais aguardavam. Esse padrão está mudando.

A análise assistida por Inteligência Artificial (IA) tornou mais barato e rápido transformar o diff de um patch ou um advisory técnico em um exploit funcional. Com isso, um número maior de atores consegue agir em horas — ou até minutos — após a divulgação de detalhes técnicos de uma vulnerabilidade.

Para líderes de segurança, isso altera algumas premissas fundamentais:

• Para vulnerabilidades críticas em sistemas expostos à internet, meça os prazos de aplicação de patches e mitigações em horas. Um SLA de 7 ou 30 dias pressupõe uma janela de atraso que simplesmente não existe mais.
• Inicie investigações a partir da data mais antiga de exploração conhecida, não da data de divulgação. No caso do PHP2Shell, isso significa investigar a partir de 17 de outubro.
• Invista em detecções que não dependam de assinatura específica para uma CVE. A primeira exploração frequentemente chega antes de essas assinaturas existirem.

Como a AWS ajuda a proteger os clientes

A AWS opera múltiplas camadas de proteção para seus clientes. O sistema interno de inteligência de ameaças da empresa detectou e restringiu automaticamente tentativas maliciosas de varredura relacionadas a essa vulnerabilidade. A infraestrutura analisa mais de 200 bilhões de eventos por minuto e integra inteligência de ameaças da rede de honeypots MadPot para identificar e bloquear tentativas de exploração conhecidas em tempo real.

Ações recomendadas imediatamente

Para quem opera ambientes PHP, as recomendações são diretas:

• Atualize imediatamente para as versões corrigidas do PHP. A atualização é a única remediação completa para as duas CVEs. Não existem workarounds apenas de configuração que resolvam ambos os problemas de forma integral.
• Considere bloquear uploads de arquivos multipart em implantações PHP que não possam ser corrigidas imediatamente — mas avalie o impacto na aplicação antes de aplicar essa medida.
• Monitore requisições POST que contenham a string PHP_SESSION_UPLOAD_PROGRESS em uploads de formulários.
• Revise os logs do servidor web em busca de atividades suspeitas.
• Verifique execuções de processos inesperadas ou modificações de arquivos em servidores de aplicações web.

Indicadores de Comprometimento (IOCs)

A Inteligência de Ameaças da Amazon identificou os seguintes endereços IP associados à exploração do PHP2Shell:

• 103.216.220.92 — observado em 17/10/2026
• 31.223.184.166 — observado em 21/10/2026
• 37.19.200.5 — observado em 21/10/2026
• 134.209.159.64 — observado em 21/10/2026
• 103.114.163.188 — observado em 21/10/2026
• 95.217.98.37 — observado em 21/10/2026

Importante: os endereços identificados fazem parte de infraestruturas de anonimização compartilhadas e não são exclusivos dessa atividade maliciosa. A recomendação é investigar qualquer observação envolvendo esses IPs — e não simplesmente bloqueá-los de forma indiscriminada.

Mitigação com AWS WAF enquanto o patch não é aplicado

Para quem ainda não conseguiu aplicar o patch, a AWS publicou orientações específicas sobre como usar o Firewall de Aplicação Web (AWS WAF) para reduzir a exposição durante o período de transição. Confira o post: Como usar o AWS WAF para aplicar mitigações para as vulnerabilidades RCE do PHP2Shell (CVE-2026-109618 e CVE-2026-109619).

Dúvidas? A AWS recomenda abrir uma thread no AWS re:Post ou entrar em contato com o Suporte AWS.

Fonte

Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)

PHP2Shell: o que aconteceu

Em 21 de outubro de 2026, o projeto PHP divulgou correções emergenciais para duas vulnerabilidades críticas de execução remota de código (RCE — Remote Code Execution) no núcleo do PHP, identificadas como CVE-2026-109618 e CVE-2026-109619 — batizadas coletivamente de PHP2Shell. Ambas receberam nota 9.2 (Crítica) pelo CVSS v4.0 e permitem que um atacante não autenticado execute código arbitrário em servidores vulneráveis.

As versões corrigidas são: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A atualização do PHP é a única correção completa e deve ser a primeira prioridade de qualquer equipe afetada.

Dito isso, atualizar toda uma frota de servidores não acontece da noite para o dia — é preciso inventariar onde o PHP está em execução, agendar janelas de manutenção e testar as aplicações contra as novas versões. É justamente nesse intervalo que o AWS WAF (Firewall de Aplicação Web) entra como controle de defesa em profundidade.

Para entender como a inteligência de ameaças da Amazon detectou a exploração do PHP2Shell antes da divulgação pública, consulte o post Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. Para o status dos serviços AWS e a regra WAF recomendada pela AWS, veja o AWS Security Bulletin 2026-143-AWS.

Entendendo as vulnerabilidades

Ambas as falhas do PHP2Shell são problemas de RCE não autenticado enraizados na forma como o PHP processa requisições multipart/form-data — o formato utilizado por navegadores em uploads de arquivos — antes mesmo que o código da sua aplicação seja executado. Por isso, as regras de WAF descritas aqui focam em tráfego multipart, tamanho do corpo da requisição e no campo de progresso de upload de sessão.

• CVE-2026-109618 (corrupção por falta de memória): corrompe a memória quando o PHP fica sem memória no meio de uma requisição. Veja o advisory PHP GHSA-w8hw-w9fx-j79w.
• CVE-2026-109619 (estado global obsoleto): permite que uma requisição deixe dados obsoletos que uma requisição posterior, no mesmo processo worker, reutiliza. Veja o advisory PHP GHSA-6wmf-4rv5-p3rp.

Para análise completa das causas raiz, versões afetadas e orientações do próprio PHP, consulte o anúncio oficial de segurança do PHP, de 21 de outubro de 2026.

Onde o AWS WAF se encaixa na resposta

O AWS WAF é um controle de defesa em profundidade nessa situação — não um substituto para a atualização do PHP. Os advisories do PHP são explícitos: atualizar para uma versão corrigida é a única mitigação completa. Uma das duas vulnerabilidades está, em grande parte, fora do alcance de qualquer firewall de aplicação web.

Trate as regras descritas aqui como controles mitigadores que ajudam a reduzir a exposição enquanto você aplica o patch. Após a atualização, você pode removê-las ou mantê-las como controles de suporte.

O AWS WAF inspeciona requisições HTTP na borda. Ele não analisa a estrutura interna de um corpo multipart e não tem visibilidade sobre a memória dos workers PHP ou configurações do lado do servidor. A tabela abaixo mapeia cada elemento de ataque à cobertura possível pelo WAF:

• Campo de progresso de upload de sessão em um POST multipart (PHP_SESSION_UPLOAD_PROGRESS): Sim — uma regra direcionada pode bloquear requisições que contenham esse campo.
• Caminho de upload multipart (multipart/form-data): Sim, se a aplicação não tiver uploads legítimos. Bloqueie multipart/form-data.
• Condição de falta de memória por corpo muito grande: Parcial — limite o tamanho do corpo da requisição. Não captura amplificação de cabeçalhos que ficam abaixo do limite.
• Tentativas repetidas contra o mesmo worker: Sim — uma regra baseada em taxa reduz o volume necessário para exploração.
• Produtor fatal_error_backtraces (configuração do PHP 8.5): Não — é uma configuração de servidor (fatal_error_backtraces=0).
• Diagnósticos INI inválidos como consumidor: Não — esse caminho roda no lado do servidor, não via HTTP do cliente.

Implementando as regras no AWS WAF

As regras abaixo são escritas em JSON para o AWFv2 e devem ser implantadas na ACL Web (Web ACL — Lista de Controle de Acesso Web) associada à distribuição do Amazon CloudFront, ao Application Load Balancer ou ao estágio do Amazon API Gateway à frente das suas aplicações PHP.

Importante: antes de qualquer alteração, certifique-se de que o logging do WAFv2 está configurado. Inicie cada regra no modo Count (Contagem), confirme que ela não afeta tráfego legítimo e só então mude para Block (Bloqueio).

Limites de inspeção do corpo da requisição

O AWS WAF inspeciona uma porção limitada do corpo da requisição. No Application Load Balancer e no AWS AppSync, o limite fixo é de 8 KB. Para serviços como CloudFront e API Gateway, o padrão é 16 KB, podendo ser elevado para 32, 48 ou 64 KB via AssociationConfig da Web ACL:

aws wafv2 update-web-acl ... --association-config \
'RequestBody={CLOUDFRONT={DefaultSizeInspectionLimit=KB_16}}'

Regra principal: PHP2Shell

Essa regra bloqueia uma requisição somente quando as três condições do AndStatement são verdadeiras simultaneamente: o método é exatamente POST; um identificador de sessão PHP está presente (via cookie ou corpo da requisição); e o corpo contém PHP_SESSION_UPLOAD_PROGRESS. Combine essa regra com session.upload_progress.enabled=0 no servidor.

{
  "Name": "PHP2Shell",
  "Priority": 0,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "SearchString": "POST",
            "FieldToMatch": {
              "Method": {}
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "NONE"
              }
            ],
            "PositionalConstraint": "EXACTLY"
          }
        },
        {
          "OrStatement": {
            "Statements": [
              {
                "ByteMatchStatement": {
                  "SearchString": "PHPSESSID",
                  "FieldToMatch": {
                    "Cookies": {
                      "MatchPattern": {
                        "All": {}
                      },
                      "MatchScope": "KEY",
                      "OversizeHandling": "CONTINUE"
                    }
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ],
                  "PositionalConstraint": "EXACTLY"
                }
              },
              {
                "ByteMatchStatement": {
                  "SearchString": "PHPSESSID",
                  "FieldToMatch": {
                    "Body": {
                      "OversizeHandling": "CONTINUE"
                    }
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ],
                  "PositionalConstraint": "CONTAINS"
                }
              }
            ]
          }
        },
        {
          "ByteMatchStatement": {
            "SearchString": "PHP_SESSION_UPLOAD_PROGRESS",
            "FieldToMatch": {
              "Body": {
                "OversizeHandling": "CONTINUE"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "NONE"
              }
            ],
            "PositionalConstraint": "CONTAINS"
          }
        }
      ]
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "PHP2Shell"
  }
}

Regras adicionais recomendadas

Bloquear requisições multipart quando a aplicação não usa uploads

Atenção: se implementada no modo Block, essa regra vai quebrar aplicações que precisam de upload de arquivos. Se a sua aplicação não precisa de uploads, bloquear multipart/form-data remove o caminho de ataque de falta de memória para ambos os CVEs.

{
  "Name": "Block-Multipart-FormData",
  "Priority": 1,
  "Action": {
    "Count": {}
  },
  "Statement": {
    "ByteMatchStatement": {
      "FieldToMatch": {
        "SingleHeader": {
          "Name": "content-type"
        }
      },
      "PositionalConstraint": "CONTAINS",
      "SearchString": "multipart/form-data",
      "TextTransformations": [
        {
          "Priority": 0,
          "Type": "LOWERCASE"
        }
      ]
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "PHP2ShellBlockMultipart"
  }
}

Limitar o tamanho do corpo da requisição

Limitar o tamanho do corpo reduz a condição de falta de memória por trás do CVE-2026-109618. Use OversizeHandling: MATCH para que qualquer corpo maior que o limite seja bloqueado. Se a sua aplicação tem uploads legítimos grandes, aplique essa regra apenas em rotas específicas via AndStatement no caminho URI.

{
  "Name": "Block-Oversize-Body",
  "Priority": 3,
  "Action": {
    "Count": {}
  },
  "Statement": {
    "SizeConstraintStatement": {
      "FieldToMatch": {
        "Body": {
          "OversizeHandling": "MATCH"
        }
      },
      "ComparisonOperator": "GT",
      "Size": 8192,
      "TextTransformations": [
        {
          "Priority": 0,
          "Type": "NONE"
        }
      ]
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "PHP2ShellBlockOversizeBody"
  }
}

Nota: se você já utiliza o grupo de regras gerenciadas AWSManagedRulesCommonRuleSet, a regra SizeRestrictions_BODY já bloqueia corpos maiores que 8 KB por padrão.

Limitar a taxa de requisições POST repetidas

Uma regra baseada em taxa para requisições POST reduz o volume que um atacante consegue enviar. Essa regra complementa a configuração de servidor pm.max_requests=1, que recicla o worker a cada requisição.

{
  "Name": "RateLimit-Posts",
  "Priority": 4,
  "Action": {
    "Count": {}
  },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "EvaluationWindowSec": 60,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "FieldToMatch": {
            "Method": {}
          },
          "PositionalConstraint": "EXACTLY",
          "SearchString": "POST",
          "TextTransformations": [
            {
              "Priority": 0,
              "Type": "NONE"
            }
          ]
        }
      }
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "PHP2ShellRateLimitPosts"
  }
}

Mitigações no lado do servidor que complementam o AWS WAF

As mudanças abaixo endereçam partes do CVE-2026-109619 que ficam abaixo da camada HTTP inspecionada pelo WAF. Aplique-as em paralelo às regras de WAF:

• Atualize o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Esta é a única correção completa. O PHP 8.1 e anteriores não têm mais suporte upstream — verifique com seu fornecedor de distribuição ou suporte de longo prazo.
• Para o CVE-2026-109618: defina memory_limit=-1 para que aplicações não possam sobrescrever esse valor, e mantenha post_max_size baixo (8M onde não há uploads, 32M onde há). Aplique limites de memória via container ou cgroup — nunca via RLIMIT_AS ou RLIMIT_DATA, pois esses disparam o caminho vulnerável.
• Defina fatal_error_backtraces=0 no PHP 8.5 e reinicie todos os workers. Isso desabilita o armazenamento de estado de rastreamento de falhas entre requisições.
• Defina session.upload_progress.enabled=0 e reinicie todos os workers. Isso desativa o recurso de rastreamento de upload — e é prudente mantê-lo desativado mesmo após o patch.
• Prefira configurações via php.ini, pool FPM ou inicialização do servidor em vez de sobrescritas de INI por requisição (via .htaccess, php_value ou PHP_VALUE do FastCGI). Remova diretivas obsoletas para evitar avisos de diagnóstico.
• Elimine erros fatais e timeouts de execução em rotas acessíveis por atacantes — incluindo caminhos de upload, importação, página de erro, shutdown, serialização e extensões.
• Defina pm.max_requests=1 se a performance permitir. Isso recicla o processo worker após cada requisição, quebrando o vínculo entre a requisição que planta dados obsoletos e a que os reutilizaria.
• Ative o log de erros (log_errors=On, um error_log funcional, error_reporting=E_ALL) e monitore os logs do Apache, FPM ou proxy em busca de avisos repetidos, deprecações, erros fatais e timeouts em rotas controladas por atacantes. A ausência de erros não é prova de segurança.

Como começar

1. Faça o inventário de onde o PHP está em execução e quais versões e APIs de servidor (mod_php, FPM, FrankenPHP, LSAPI) estão em uso.
2. Identifique todos os endpoints públicos que aceitam corpo de requisição.
3. Decida quais aplicações utilizam uploads multipart — isso determina se você pode bloquear requisições multipart na borda.
4. Crie ou atualize a Web ACL à frente de cada workload PHP e adicione as regras aplicáveis no modo Count.
5. Eleve o limite de inspeção do corpo no CloudFront ou API Gateway se uma regra precisar disso.
6. Monitore as requisições amostradas e as métricas do Amazon CloudWatch para cada regra. Confirme que uploads legítimos e POSTs JSON grandes não estão sendo capturados.
7. Mude as regras para Block após as métricas estarem limpas. Ordene as prioridades para que as regras de progresso de upload de sessão e multipart rodem antes das regras de tamanho e taxa.
8. Teste com um POST multipart/form-data benigno, um corpo excessivamente grande e uma requisição contendo PHP_SESSION_UPLOAD_PROGRESS. Espere uma resposta 403 e a métrica da regra correspondente.
9. Em paralelo, aplique a atualização do PHP e as mitigações de configuração no servidor.
10. Remova ou mantenha as regras do AWS WAF como controles de suporte após a atualização de toda a frota.

Conclusão

As vulnerabilidades PHP2Shell — CVE-2026-109618 e CVE-2026-109619 — são falhas de RCE não autenticado que atingem o PHP antes mesmo que o código da sua aplicação seja executado. O AWS WAF oferece uma forma de reduzir a superfície de ataque durante a janela de patch: bloqueie o campo de progresso de upload de sessão, bloqueie requisições multipart onde não há uploads esperados, limite o tamanho do corpo e aplique controle de taxa em tentativas repetidas.

Esses controles mitigadores ajudam a reduzir a exposição, mas não fecham as vulnerabilidades. Atualize o PHP para uma versão corrigida, aplique as mudanças de configuração no servidor e trate as regras do AWS WAF como a camada de borda que suporta essas correções — não como a correção em si.

Para saber mais sobre os tipos de regras utilizados aqui, consulte a documentação do AWS WAF sobre limite de inspeção do corpo da Web ACL, tratamento de componentes de requisição com tamanho excessivo e como lidar com corpos HTTP excessivamente grandes. Para os detalhes das vulnerabilidades, consulte os advisories PHP GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp, além do manual de progresso de upload de sessão do PHP.

Fonte

Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619) (https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/)

Cognito MRR chega às Regiões GovCloud (US)

A AWS anunciou uma expansão relevante para o Amazon Cognito: a funcionalidade de replicação multi-Região — conhecida pela sigla MRR, do inglês Multi-Region Replication — agora está disponível nas Regiões AWS GovCloud (US). Com isso, cargas de trabalho que operam nessas Regiões governamentais também passam a contar com os benefícios de resiliência que o MRR já oferecia em outros ambientes.

O que é o MRR e como funciona

O MRR permite que dados de identidade — tanto de usuários quanto de máquinas — sejam sincronizados em tempo quase real para um user pool secundário em uma Região de espera definida pelo próprio time. Isso inclui credenciais, configurações do user pool e configurações de federação.

Com os dados replicados na Região de espera, é possível redirecionar o tráfego e manter a autenticação disponível caso ocorra alguma interrupção na Região primária. Trata-se de um mecanismo importante para garantir continuidade operacional em cenários de falha.

Expansão além das Regiões comerciais

Até então, o MRR estava disponível em 16 Regiões comerciais da AWS. Com este anúncio, o recurso passa a abranger também Regiões adicionais, incluindo as Regiões AWS GovCloud (US), ajudando equipes a atender requisitos de resiliência, residência de dados e conformidade regulatória nas Regiões que melhor se alinham às suas necessidades de negócio.

Requisitos e disponibilidade

O MRR está disponível como um complemento para user pools nos planos de funcionalidade Essentials ou Plus. Para utilizá-lo, é necessário ter uma chave gerenciada pelo cliente (CMK — Customer Managed Key) do AWS KMS (Key Management Service) configurada para múltiplas Regiões.

Para consultar a lista completa de Regiões onde o Amazon Cognito está disponível, a AWS disponibiliza a página de Capacidades da AWS por Região. Quem quiser começar a usar o recurso pode acessar o guia do desenvolvedor para instruções detalhadas, além da página de preços para entender os custos envolvidos.

Fonte

Amazon Cognito extends multi-Region replication to AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/10/cognito-multi-region-us-govcloud/)