Blog

Inteligência de Ameaças: Um Novo Panorama de Ciberataques Amplificados por IA

Os serviços comerciais de inteligência artificial estão transformando o cenário de ciberataques. A Amazon Threat Intelligence vem rastreando de perto uma tendência preocupante: atores de ameaça menos sofisticados agora conseguem executar operações em escala massiva com ajuda de ferramentas de IA generativa. Uma investigação recente ilustra essa mudança de forma alarmante.

Entre janeiro e fevereiro de 2026, a Amazon Threat Intelligence detectou um ator de ameaça falante de russo, financeiramente motivado, que utilizou múltiplos serviços comerciais de IA generativa para comprometer mais de 600 dispositivos FortiGate distribuídos em mais de 55 países. O aspecto crítico: nenhuma vulnerabilidade zero-day ou exploração avançada foi necessária. Em vez disso, o ataque explorou lacunas de segurança fundamental — portas de gerenciamento expostas à internet e credenciais fracas com autenticação de fator único — que a IA ajudou a explorar em escala industrial.

Este padrão de operação é notável porque revela algo importante: a IA funcionou como multiplicador de força, permitindo que um ator com capacidades técnicas limitadas alcançasse escala operacional que normalmente exigiria equipes maiores e mais especializadas. Vale ressaltar que a infraestrutura da AWS não foi envolvida nesta campanha.

A Democratização do Ataque Cibernético

Um Ator Financeiramente Motivado, Não uma Nação-Estado

A análise da Amazon Threat Intelligence aponta para um ator financeiramente motivado — provavelmente um indivíduo ou pequeno grupo — sem conexão conhecida com grupos de ameaça persistente avançada (Ameaças Persistentes Avançadas – APAs) com recursos patrocinados por estados. Apesar dessa limitação técnica baseline, o ator comprometeu múltiplos ambientes Active Directory, extraiu bases de dados completas de credenciais e direcionou infraestrutura de backup — tudo isso consistente com preparação para implantação de ransomware.

O padrão operacional revelou algo significativo: quando o ator enfrentava ambientes endurecidos ou defesas sofisticadas, simplesmente migrava para alvos mais fáceis, em vez de persistir. Isso demonstra que a vantagem reside na eficiência amplificada por IA e escala operacional, não em habilidade técnica profunda.

Qual Era a Metodologia?

A investigação ganhou visibilidade extraordinária porque o ator teve falhas graves de segurança operacional. A infraestrutura maliciosa deixou expostos planos de ataque gerados por IA, configurações de vítimas e código-fonte de ferramentas personalizadas — basicamente um arquivo de operações completo. Isso permitiu à Amazon Threat Intelligence documentar precisamente como o ator utilizava IA em cada fase.

Como o Ataque Começou: Acesso Inicial por Abuso de Credenciais

Varredura Sistemática e Credenciais Comuns

O vetor inicial de acesso foi baseado em credenciais — acesso direto às interfaces de gerenciamento de FortiGate expostas à internet. A análise das ferramentas do ator revelou varredura sistemática em portas 443, 8443, 10443 e 4443, seguida por tentativas de autenticação usando credenciais frequentemente reutilizadas.

Arquivos de configuração do FortiGate são alvos de alto valor porque contêm informações críticas: credenciais de usuário SSL-VPN com senhas recuperáveis, credenciais administrativas, topologia completa de rede e informações de roteamento, políticas de firewall que revelam arquitetura interna, e configurações de pares IPsec VPN.

Ferramentas Assistidas por IA para Extração de Dados

O ator desenvolveu scripts Python assistidos por IA para fazer parsing, descriptografar e organizar as configurações roubadas. A escala de distribuição foi oportunista em vez de setorial — consistente com varredura automatizada massiva. Porém, certos padrões sugerem comprometimento no nível organizacional, onde múltiplos dispositivos FortiGate pertencentes à mesma entidade foram acessados. Concentrações de dispositivos comprometidos foram observadas na Ásia do Sul, América Latina, Caribe, África Ocidental, Europa do Norte e Sudeste Asiático, entre outras regiões.

Ferramentas Personalizadas: Um Framework de Reconhecimento Gerado por IA

Sinais de Desenvolvimento Assistido por IA

Após acessar redes de vítimas via VPN, o ator implanta uma ferramenta de reconhecimento personalizada, com versões escritas tanto em Go quanto em Python. A análise do código-fonte revela indicadores claros de desenvolvimento assistido por IA: comentários redundantes que apenas reafirmam nomes de funções, arquitetura simplista com investimento desproporcional em formatação sobre funcionalidade, parsing JSON ingênuo via correspondência de string em vez de desserialização apropriada, e shims de compatibilidade para built-ins de linguagem com stubs vazios de documentação.

Embora funcional para o caso de uso específico do ator, as ferramentas carecem de robustez e falham em casos extremos — características típicas de código gerado por IA sem refinamento significativo.

Fluxo de Trabalho Automatizado do Ator

A ferramenta automatiza o fluxo de reconhecimento pós-VPN: ingere redes-alvo a partir de tabelas de roteamento VPN, classifica redes por tamanho, executa descoberta de serviço usando gogo (scanner de porta de código aberto), identifica automaticamente hosts SMB e controladores de domínio, e integra varredura de vulnerabilidades usando Nuclei (scanner de vulnerabilidades de código aberto) contra serviços HTTP descobertos para produzir listas de alvos priorizadas.

Pós-Exploração: Técnicas Bem Conhecidas com Escala Amplificada

Comprometimento de Domínio

Dentro das redes de vítimas, o ator segue uma abordagem padrão usando ferramentas ofensivas de código aberto conhecidas. A documentação operacional detalha o uso pretendido de Meterpreter (kit de pós-exploração de código aberto) com o módulo mimikatz para executar ataques DCSync contra controladores de domínio, permitindo extrair hashes de senha NTLM do Active Directory. Em comprometimentos confirmados, o ator obteve bases de dados de credenciais de domínio completas. Em pelo menos um caso, a conta de Administrador de Domínio usava uma senha em texto simples, extraída da configuração FortiGate por reutilização de credenciais ou era independentemente fraca.

Movimento Lateral e Backup Targeting

Após comprometimento de domínio, o ator tenta expandir acesso através de ataques pass-the-hash/pass-the-ticket contra infraestrutura adicional, ataques NTLM relay usando ferramentas padrão de envenenamento, e execução remota de comando em hosts Windows. Especificamente, o ator direcionou servidores Veeam Backup & Replication, implantando múltiplas ferramentas para extração de credenciais, incluindo scripts PowerShell, ferramentas compiladas de descriptografia e tentativas de exploração alavancando vulnerabilidades conhecidas de Veeam. Servidores de backup são alvos de alto valor porque tipicamente armazenam credenciais elevadas para operações de backup, e comprometer infraestrutura de backup posiciona um atacante para destruir capacidades de recuperação antes de implantar ransomware.

Falhas de Exploração: O Limite da Dependência de IA

As notas operacionais do ator referenciam múltiplas Vulnerabilidades e Exposições Comuns (CVEs) em vários alvos (CVE-2019-7192, CVE-2023-27532, CVE-2024-40711, entre outros). Um achado crítico é que o ator largamente falhou ao tentar explorar qualquer coisa além dos caminhos de ataque mais diretos e automatizados. Sua própria documentação registra falhas repetidas: serviços direcionados estavam corrigidos, portas necessárias estavam fechadas, vulnerabilidades não se aplicavam às versões do sistema operacional alvo. A avaliação operacional final para uma vítima confirmada reconheceu que infraestrutura-chave estava “bem protegida” com “nenhum vetor de exploração vulnerável”.

A IA Como Multiplicador de Força Operacional

Múltiplos Provedores de Modelos Usados Simultaneamente

A análise revelou que o ator utiliza pelo menos dois provedores de Modelo de Linguagem (Modelo de Linguagem – ML) comerciais distintos em todas as operações. A IA foi usada para gerar metodologias de ataque abrangentes com instruções de exploração passo a passo, taxas de sucesso esperadas, estimativas de tempo e árvores de tarefas priorizadas. Esses planos referenciam pesquisa acadêmica sobre agentes de IA ofensiva, sugerindo que o ator acompanha literatura emergente sobre testes de penetração assistidos por IA.

A IA produz sequências de comando tecnicamente precisas, mas o ator tem dificuldade em se adaptar quando as condições diferem do plano. Não consegue compilar exploits customizados, depurar tentativas de exploração falhadas ou fazer pivôs criativos quando abordagens padrão falham.

Fluxo de Trabalho Multi-Modelo

Um modelo serve como desenvolvedor de ferramentas primário, planejador de ataque e assistente operacional. Um segundo é usado como planejador de ataque suplementar quando o ator precisa ajuda fazendo pivô dentro de uma rede comprometida específica. Em uma instância observada, o ator submeteu a topologia interna completa de uma vítima ativa — endereços IP, nomes de host, credenciais confirmadas e serviços identificados — e solicitou um plano passo a passo para comprometer sistemas adicionais que não conseguiam acessar com ferramentas existentes.

Ferramentas Geradas por IA em Escala

Além do framework de reconhecimento, a infraestrutura do ator contém inúmeros scripts em múltiplas linguagens de programação com características de geração por IA, incluindo parsers de configuração, ferramentas de extração de credenciais, automação de conexão VPN, orquestração de varredura massiva e dashboards de agregação de resultados. O volume e variedade de ferramentas personalizadas normalmente indicariam uma equipe de desenvolvimento bem-recursos. Em vez disso, um ator único ou pequeno grupo gerou todo esse toolkit através de desenvolvimento assistido por IA.

Avaliação do Ator de Ameaça

Com base em análise abrangente, a Amazon Threat Intelligence avalia este ator de ameaça como: Motivação financeira presumida, baseada em direcionamento generalizado e indiscriminado com sofisticação baixa; Falante de russo, baseado em documentação operacional extensa em russo; Capacidade técnica baseline baixa a média, significativamente amplificada por IA — o ator pode executar ferramentas ofensivas padrão e automatizar tarefas rotineiras mas tem dificuldade com compilação de exploits, desenvolvimento customizado e resolução criativa de problemas durante operações ao vivo; Dependência extensiva de IA em todas as fases operacionais, incluindo desenvolvimento de ferramentas, planejamento de ataque, geração de comando e relatório operacional; Escala operacional ampla com dispositivos comprometidos em dezenas de países e evidência de operações sustentadas por período estendido; Profundidade de pós-exploração rasa com falhas repetidas contra alvos endurecidos ou não-padronizados e padrão de migração para alvos mais suaves quando abordagens automatizadas falham; Segurança operacional inadequada com planos operacionais detalhados, credenciais e dados de vítimas armazenados sem criptografia junto com ferramentas.

Resposta e Defesa Organizacional

Ações da Amazon Threat Intelligence

Ao descobrir esta campanha, a Amazon Threat Intelligence tomou ações específicas: compartilhou inteligência acionável, incluindo indicadores de comprometimento, com parceiros relevantes; colaborou com parceiros da indústria para ampliar visibilidade da campanha e apoiar esforços de defesa coordenada. Através desses esforços, a Amazon ajudou a reduzir a efetividade operacional do ator de ameaça e permitiu que organizações em múltiplos países tomassem passos para interromper a eficácia da campanha.

Auditoria de Dispositivos FortiGate

Organizações executando dispositivos FortiGate devem tomar ação imediata: garantir que interfaces de gerenciamento não sejam expostas à internet; se administração remota for necessária, restringir acesso a faixas de IP conhecidas e usar um host bastião ou rede de gerenciamento fora de banda; mudar todas as credenciais padrão e comuns em dispositivos FortiGate, incluindo contas administrativas e de usuário VPN; girar todas as credenciais de usuário SSL-VPN, particularmente para qualquer dispositivo cuja interface de gerenciamento foi ou pode ter sido acessível pela internet; implementar autenticação multifator para todos os acessos administrativos e VPN; revisar configurações de FortiGate para contas administrativas não autorizadas ou mudanças de política; auditar logs de conexão VPN para conexões de localizações geográficas inesperadas.

Higiene de Credenciais

Dada a extração de credenciais de configurações FortiGate: auditar reutilização de senha entre credenciais FortiGate VPN e contas de domínio Active Directory; implementar autenticação multifator para todos os acessos VPN; impor senhas únicas e complexas para todas as contas, particularmente contas de Administrador de Domínio; revisar e girar credenciais de conta de serviço, especialmente aquelas usadas em infraestrutura de backup.

Detecção de Pós-Exploração

Organizações que podem ter sido afetadas devem monitorar: operações DCSync inesperadas (ID de Evento 4662 com GUIDs relacionadas a replicação); novas tarefas agendadas nomeadas para imitar serviços Windows legítimos; conexões de gerenciamento remoto incomuns de pools de endereço VPN; artefatos de envenenamento LLMNR/NBT-NS no tráfego de rede; acesso não autorizado a armazenamentos de credencial de backup; novas contas com nomes projetados para se mesclar com contas de serviço legítimas.

Endurecimento de Infraestrutura de Backup

O foco do ator em infraestrutura de backup destaca a importância de: isolar servidores de backup do acesso de rede geral; fazer patch de software de backup contra vulnerabilidades conhecidas de extração de credenciais; monitorar carregamento não autorizado de módulo PowerShell em servidores de backup; implementar cópias de backup imutáveis que não possam ser modificadas mesmo com acesso administrativo.

Recomendações Específicas para AWS

Para organizações usando AWS: ativar Amazon GuardDuty para detecção de ameaça, incluindo monitoramento de chamadas API incomuns e padrões de uso de credenciais; usar Amazon Inspector para verificar automaticamente por vulnerabilidades de software e exposição de rede não intencional; usar AWS Security Hub para manter visibilidade contínua na postura de segurança; usar AWS Systems Manager Patch Manager para manter conformidade de patch em instâncias EC2 executando dispositivos de rede; revisar padrões de acesso IAM (Identity and Access Management – Gerenciamento de Identidade e Acesso) para sinais de replay de credenciais seguindo qualquer comprometimento suspeito de dispositivo de rede.

Indicadores de Comprometimento e Detecção

A dependência desta campanha em ferramentas ofensivas de código aberto legítimas — incluindo Impacket, gogo, Nuclei e outras — significa que detecção tradicional baseada em indicador tem efetividade limitada. Essas ferramentas são amplamente usadas por testadores de penetração e profissionais de segurança, e sua presença sozinha não é indicativa de comprometimento. Organizações devem investigar contexto ao redor de correspondências, priorizando detecção comportamental (padrões anormais de autenticação VPN, replicação Active Directory inesperada, movimento lateral de pools de endereço VPN) sobre abordagens baseadas em assinatura.

Conclusão: Fundamentos de Segurança Continuam Sendo a Defesa Mais Efetiva

Esta campanha obteve sucesso através de uma combinação de interfaces de gerenciamento expostas, credenciais fracas e autenticação de fator único — todas lacunas de segurança fundamentais que IA ajudou um ator sofisticado explorar em escala. Isso sublinha que fundamentos de segurança forte são defesas poderosas contra ameaças potencializadas por IA. À medida que esperamos que essa tendência continue em 2026, organizações devem antecipar que atividade de ameaça potencializada por IA continuará crescendo em volume tanto de adversários hábeis quanto não-hábeis. Gestão de patch para dispositivos perimetral, higiene de credenciais, segmentação de rede e detecção robusta para indicadores de pós-exploração permanecem as contramedidas mais efetivas.

Fonte

AI-augmented threat actor accesses FortiGate devices at scale (https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/)

Expansão do IAM Identity Center para Ásia-Pacífico

A AWS anunciou a disponibilidade do AWS IAM Identity Center na região Ásia-Pacífico (Nova Zelândia), ampliando sua cobertura global para 38 regiões AWS. Essa expansão oferece às organizações operando na região uma solução nativa para gerenciar o acesso de seus usuários aos aplicativos e serviços hospedados na nuvem.

O que é o IAM Identity Center

O IAM Identity Center (Centro de Identidade do AWS Identity and Access Management) é o serviço recomendado pela AWS para gerenciar o acesso da força de trabalho aos aplicativos AWS. Seu principal diferencial é a capacidade de conectar uma única vez a fonte de identidades corporativas já existente na organização com a plataforma AWS, eliminando a necessidade de manter múltiplos sistemas de autenticação.

Uma vez integrado, o serviço oferece aos usuários uma experiência de single sign-on unificada em todos os aplicativos AWS, reduzindo fricção e aumentando a produtividade. Os profissionais de TI, por sua vez, ganham um ponto centralizado para administração de identidades, simplificando operações em ambientes complexos.

Capacidades principais

Experiências personalizadas com Amazon Q

O IAM Identity Center alimenta experiências personalizadas oferecidas por aplicativos AWS como o Amazon Q. Graças à integração, o serviço compreende quem é cada usuário e pode adaptar o comportamento de aplicações de acordo com seu perfil e permissões.

Auditoria e controle de acesso consciente do usuário

O serviço permite definir e auditar o acesso de usuários específicos a dados em serviços como o Amazon Redshift. Essa granularidade é essencial para organizações que precisam manter conformidade com regulamentações e políticas internas rigorosas.

Gerenciamento centralizado de múltiplas contas AWS

Para empresas que operam com várias contas AWS, o IAM Identity Center oferece administração centralizada de acesso, evitando a necessidade de configurar identidades repetidamente em cada conta.

Disponibilidade e custos

O IAM Identity Center está disponível na nova região sem custos adicionais, mantendo o modelo de precificação compatível com demais regiões onde o serviço opera. Essa inclusão na região Ásia-Pacífico (Nova Zelândia) reforça o compromisso da AWS de oferecer cobertura global para seus serviços principais de segurança e identidade.

Próximos passos

Organizações interessadas em explorar o IAM Identity Center podem consultar a página de detalhes do produto para compreender melhor as capacidades e arquitetura recomendada. Para começar a usar o serviço de imediato, a documentação do IAM Identity Center oferece guias práticos de implementação e configuração.

Fonte

AWS IAM Identity Center is now available in the Asia Pacific (New Zealand) AWS Region (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-iam-identity-center-asia-pacific-new-zealand-region/)

Autenticação Simplificada para Aurora DSQL

A AWS expandiu o conjunto de ferramentas disponível para desenvolvedores que trabalham com Aurora DSQL (Distributed SQL). Em fevereiro de 2026, a empresa anunciou o lançamento de conectores específicos para as três linguagens mais populares na comunidade de desenvolvimento: Go, Python e Node.js. Esses conectores trazem uma abordagem inovadora para resolver um desafio comum em ambientes de nuvem: a autenticação segura e simplificada.

O grande diferencial dos novos conectores é que funcionam como camadas transparentes de autenticação. Isso significa que os desenvolvedores não precisam se preocupar com a geração manual de tokens de autenticação. O processo acontece automaticamente, eliminando linhas de código e reduzindo a superfície de ataque relacionada a credenciais.

Como Funcionam os Conectores

Os três conectores lançados seguem padrões bem estabelecidos no ecossistema de desenvolvimento:

• Go (pgx) – integração nativa com o driver pgx mais amplamente utilizado
• Python (asyncpg) – compatibilidade com o asyncpg, popular em aplicações assíncronas
• Node.js (Websocket para Postgres.js) – suporte ao protocolo WebSocket, essencial em ambientes onde conexões TCP tradicionais não estão disponíveis

O funcionamento é elegante: cada vez que uma conexão é estabelecida, os conectores geram automaticamente um novo token de autenticação usando credenciais de Identidade e Acesso (IAM). Tokens inválidos não persistem, pois são sempre renovados. Ao mesmo tempo, os conectores mantêm compatibilidade integral com todos os recursos dos drivers PostgreSQL padrão.

Segurança e Flexibilidade

Uma das preocupações tradicionais com autenticação em banco de dados é o gerenciamento de senhas. Os conectores da Aurora DSQL eliminam essa classe de riscos ao substituir senhas por tokens IAM temporários e gerenciados automaticamente. Não há segredos espalhados pelo código ou arquivos de configuração.

Para organizações com necessidades avançadas de gerenciamento de credenciais, todos os três conectores suportam provedores de credenciais IAM customizados. Isso oferece flexibilidade para integrar com sistemas corporativos de gerenciamento de identidade já existentes.

O conector Node.js adiciona um diferencial importante: suporte ao protocolo WebSocket. Em muitos ambientes em nuvem, especialmente em arquiteturas serverless ou em redes restritas, conexões TCP diretas podem não estar disponíveis. WebSocket resolve esse impedimento técnico.

Como Começar

Desenvolvedores interessados em usar os novos conectores têm acesso a documentação técnica completa. A documentação de Conectores para Aurora DSQL fornece guias de instalação e configuração. Além disso, repositórios no GitHub contêm exemplos práticos de código:

• pgx para Go
• asyncpg para Python
• Websocket para Postgres.js

Para quem deseja explorar sem custos iniciais, a AWS Free Tier disponibiliza créditos para experimentar Aurora DSQL. Mais informações sobre o serviço estão disponíveis na página oficial do Aurora DSQL.

Fonte

Aurora DSQL launches new Go, Python, and Node.js connectors that simplify IAM authentication (https://aws.amazon.com/about-aws/whats-new/2026/02/aurora-dsql-launches-go-python-nodejs-connectors)

O desafio da conexão segura com data warehouses

Empresas modernas enfrentam desafios significativos ao integrar plataformas de inteligência de negócios com data warehouses em nuvem, especialmente quando é necessário manter a automação sem comprometer a segurança. A autenticação baseada em senha introduz vulnerabilidades, cria atrito operacional e gera lacunas de conformidade — particularmente crítico considerando que o Snowflake está descontinuando o suporte a autenticação por nome de usuário e senha.

A AWS reconheceu esse cenário e implementou uma solução através do Amazon QuickSight (um componente do Amazon Quick Suite), agora oferecendo suporte a autenticação por chave pública para integrações com Snowflake. Esse novo recurso utiliza criptografia assimétrica, onde pares de chaves RSA substituem as tradicionais senhas. Com essa capacidade, usuários da Amazon Quick Suite podem estabelecer conexões seguras e sem senha com fontes de dados Snowflake usando pares de chaves RSA, proporcionando uma experiência de integração contínua e segura que atende aos padrões empresariais de segurança.

Por que essa mudança importa

A implementação de autenticação por chave pública representa um avanço transformador na segurança de conectividade entre Amazon QuickSight e Snowflake. Ao eliminar as vulnerabilidades associadas a senhas e adotar autenticação criptográfica, as organizações conseguem alcançar uma postura de segurança superior mantendo fluxos de trabalho automatizados e contínuos. Essa implementação atende a requisitos críticos de empresas, como melhor segurança através de criptografia assimétrica, gerenciamento simplificado de contas de serviço e conformidade com padrões de autenticação em evolução, especialmente diante da transição do Snowflake para longe dos métodos tradicionais de senha.

Pré-requisitos para configuração

Antes de configurar a autenticação por chave pública entre Amazon QuickSight e Snowflake, verifique se você tem os seguintes requisitos:

Conta ativa da Amazon Quick

Você precisa de uma conta Amazon Quick com permissões apropriadas. Isso requer acesso administrativo para criar e gerenciar fontes de dados, configurar parâmetros de autenticação e conceder permissões a usuários. Tipicamente, licenças Enterprise da Amazon Quick ou o papel de Author na Amazon Quick Enterprise Edition fornecem acesso suficiente.

Conta Snowflake com permissões elevadas

Uma conta Snowflake com papéis ACCOUNTADMIN, SECURITYADMIN ou USERADMIN é essencial. Essas permissões elevadas são necessárias para modificar contas de usuário, atribuir chaves públicas usando comandos ALTER USER e conceder permissões em warehouses e bancos de dados. Se você não tiver acesso a esses papéis, entre em contato com seu administrador Snowflake.

OpenSSL instalado

OpenSSL, um kit de ferramentas criptográficas, é necessário para gerar pares de chaves RSA no formato PKCS#8. A maioria dos sistemas Linux e macOS inclui OpenSSL pré-instalado. Usuários de Windows podem usar Windows Subsystem for Linux (WSL) ou baixar OpenSSL separadamente.

AWS Secrets Manager (opcional)

Para configurações baseadas em API, acesso a AWS Secrets Manager é necessário. Você precisará de permissões IAM (Identity and Access Management) para criar e gerenciar secrets, além de acesso à API do Amazon QuickSight para implantações automatizadas e implementações de infraestrutura como código (IaC).

Passo a passo: Configurando a autenticação por chave pública

Para estabelecer autenticação segura por chave pública entre Amazon QuickSight e Snowflake, você seguirá estas etapas essenciais:

Gerar o par de chaves RSA

Navegue até AWS CloudShell no AWS Management Console e execute o comando a seguir para gerar a chave privada RSA. Você será solicitado a inserir uma frase de criptografia. Escolha uma frase forte e armazene-a com segurança — você precisará dela posteriormente ao gerar a chave pública.

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8

Execute os comandos a seguir para criar o par de chaves públicas. Você será solicitado a inserir a frase que utilizou no passo anterior.

openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

Extraia o conteúdo da chave privada (incluindo cabeçalho e rodapé):

cat rsa_key.p8

Isso exibirá sua chave privada no formato:

-----BEGIN PRIVATE KEY-----[conteúdo da chave]-----END PRIVATE KEY-----

Importante: copie a saída inteira incluindo as linhas -----BEGIN PRIVATE KEY----- e -----END PRIVATE KEY-----. Você utilizará essa chave privada completa (com cabeçalhos e rodapés) ao criar sua conexão de fonte de dados Snowflake.

Formatar a chave pública

O Snowflake requer a chave pública em um formato específico sem cabeçalhos ou quebras de linha. Execute estes comandos para extrair e formatar a chave corretamente:

grep -v KEY rsa_key.pub | tr -d '\n' | awk '{print $1}' > pub.Key
cat pub.Key

Isso exibirá sua string de chave pública formatada. Copie essa saída — você a utilizará no próximo passo para configurar sua conta de usuário no Snowflake.

Atribuir a chave pública ao usuário Snowflake

Faça login no Snowflake e execute os seguintes comandos SQL para atribuir a chave pública ao seu usuário:

ALTER USER <username> SET RSA_PUBLIC_KEY='<public_key_content>';

Verifique a atribuição da chave procurando pela propriedade RSA_PUBLIC_KEY para confirmar se a chave pública foi configurada:

DESCRIBE USER <username>;

Estabelecendo a conexão através da interface do Amazon QuickSight

Navegue até Amazon QuickSight no AWS Management Console e selecione Datasets. Em seguida, selecione a aba Data sources e escolha Create data source. No painel Create data source, insira “snowflake” no campo Search datasets, selecione Snowflake e escolha Next.

No painel New Snowflake data source, insira o nome da fonte de dados e o tipo de conexão como Public Network ou uma Private VPC Connection. Se você precisar de uma conexão VPC, consulte a documentação para configurar a conexão VPC em QuickSight. Em seguida, insira o nome do host do servidor de banco de dados, o nome do banco de dados e o nome do warehouse.

Selecione Authentication Type como KeyPair e insira o nome do usuário Snowflake. No campo Private Key, cole a saída completa do comando cat rsa_key.p8 (incluindo os cabeçalhos BEGIN e END). Se você tiver configurado uma frase de criptografia durante a geração da chave, forneça-a no campo opcional Passphrase.

Após preencher todos os campos, selecione o botão Validate connection. Depois que a conexão for validada, selecione Create data source. Na lista de Data sources, localize a fonte de dados Snowflake que você criou. No menu Actions, selecione a opção Create dataset.

Estabelecendo a conexão através da API do Amazon QuickSight

Usando AWS CLI, você pode criar a conexão de fonte de dados do Amazon QuickSight com Snowflake executando o seguinte comando:

aws quicksight create-data-source \
  --aws-account-id 123456789 \
  --data-source-id awsclikeypairtest \
  --name "awsclikeypairtest" \
  --type SNOWFLAKE \
  --data-source-parameters '{
    "SnowflakeParameters": {
      "Host": "hostname.snowflakecomputing.com",
      "Database": "DB_NAME",
      "Warehouse": "WH_NAME",
      "AuthenticationType": "KEYPAIR"
    }
  }' \
  --credentials '{
    "KeyPairCredentials": {
      "KeyPairUsername": "SNOWFLAKE_USERNAME",
      "PrivateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----\nPRIVATE_KEY\n-----END ENCRYPTED PRIVATE KEY-----",
      "PrivateKeyPassphrase": "******"
    }
  }' \
  --permissions '[
    {
      "Principal": "arn:aws:quicksight:us-east-1:123456789:user/default/Admin/username",
      "Actions": [
        "quicksight:DescribeDataSource",
        "quicksight:DescribeDataSourcePermissions",
        "quicksight:PassDataSource",
        "quicksight:UpdateDataSource",
        "quicksight:DeleteDataSource",
        "quicksight:UpdateDataSourcePermissions"
      ]
    }
  ]' \
  --region us-east-1

Use o comando a seguir para verificar o status da criação:

aws quicksight describe-data-source --region us-east-1 --aws-account-id 123456789 --data-source-id awsclikeypairtest

Inicialmente, o status retornado pelo comando describe-data-source será CREATION_IN_PROGRESS. O status mudará para CREATION_SUCCESSFUL quando a nova fonte de dados estiver pronta para uso.

Alternativamente, ao criar a fonte de dados programaticamente através de CreateDataSource, você pode armazenar o nome de usuário, chave e frase no AWS Secrets Manager e referenciá-los usando o Secret ARN. Após a criação bem-sucedida da fonte de dados, você poderá navegar até o console do QuickSight. Na página Create a Dataset, você visualizará a conexão de fonte de dados recém-criada awsclikeypairtest na lista de data sources. Você poderá então prosseguir para criar os datasets.

Limpeza de recursos

Para limpar seus recursos e evitar incorrer em custos adicionais, siga estas etapas:

• Excluir o secret criado no AWS Secrets Manager Console.
• Excluir a conexão de fonte de dados criada no Amazon QuickSight.

Benefícios práticos dessa implementação

A adoção de autenticação por chave pública oferece flexibilidade sem comprometer a segurança, independentemente de você estar implantando através da interface intuitiva do Amazon QuickSight ou usando AWS CLI para implementações de Infraestrutura como Código. A integração com AWS Secrets Manager ajuda a proteger as chaves privadas, enquanto o processo de configuração direto permite implantação rápida em ambientes de desenvolvimento, staging e produção.

Conforme a segurança de dados continua evoluindo, a adoção de autenticação por chave pública posiciona sua organização na vanguarda das melhores práticas. Os times de inteligência de negócios agora podem se concentrar em extrair insights acionáveis dos dados do Snowflake, em vez de gerenciar complexidades de autenticação, acelerando assim o tempo para obtenção de insights e melhorando a eficiência operacional.

Próximas leituras

Para aprofundar seu conhecimento sobre esse tópico, consulte autenticação por chave pública no Snowflake.

Fonte

Amazon Quick now supports key pair authentication to Snowflake data source (https://aws.amazon.com/blogs/machine-learning/amazon-quick-suite-now-supports-key-pair-authentication-to-snowflake-data-source/)

Novo suporte para chaves gerenciadas pelo cliente

A AWS anunciou que o Amazon Managed Grafana agora suporta chaves gerenciadas pelo cliente (Customer Managed Keys – CMK) por meio do AWS Key Management Service (Serviço de Gerenciamento de Chaves da AWS – KMS). Este recurso possibilita que você criptografe os dados armazenados em seus workspaces do Amazon Managed Grafana utilizando suas próprias chaves de criptografia.

O que é Amazon Managed Grafana

Amazon Managed Grafana é um serviço totalmente gerenciado, baseado no Grafana de código aberto, que facilita a visualização e análise de dados operacionais em grande escala. O serviço já oferecia criptografia em repouso por padrão, utilizando chaves de propriedade da AWS.

Benefício da camada de segurança adicional

Com este lançamento, agora você tem a opção de utilizar uma chave gerenciada pelo cliente ao criar um workspace do Amazon Managed Grafana. Essa flexibilidade permite adicionar uma camada de segurança autogerenciada, auxiliando sua organização a atender requisitos específicos de conformidade e regulamentações.

Disponibilidade e próximos passos

O recurso está disponível em todas as regiões onde Amazon Managed Grafana é oferecido, com exceção das AWS GovCloud (US) Regions.

Para começar a usar Amazon Managed Grafana com chaves gerenciadas pelo cliente, consulte a documentação completa do serviço.

Para conhecer mais detalhes sobre a plataforma, visite a página do produto e a página de preços.

Fonte

Amazon Managed Grafana now supports AWS KMS customer managed keys (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-managed-grafana-customer-managed-keys)

Nova capacidade de federação de catálogos

A AWS Clean Rooms passou a oferecer suporte para federação de catálogos direcionada a catálogos Iceberg remotos. Esta novidade representa um avanço significativo na forma como as organizações podem colaborar e compartilhar insights sobre seus dados, sem necessidade de replicar metadados de tabelas ou construir infraestruturas complexas de integração de dados.

O diferencial dessa abordagem está na simplicidade: o Clean Rooms agora oferece acesso direto e seguro às tabelas Iceberg armazenadas no Amazon S3 e catalogadas em repositórios remotos. Isso elimina uma barreira técnica importante que existia anteriormente, reduzindo significativamente o esforço necessário para configurar ambientes de análise colaborativa.

Como a federação de catálogos funciona

Com o suporte à federação de catálogos, as organizações podem aproveitar o AWS Glue para fornecer acesso direto a seus catálogos Iceberg REST existentes em uma colaboração Clean Rooms. Essa integração permite que diferentes parceiros de negócios trabalhem juntos mantendo seus dados em seus próprios repositórios e sob seu próprio controle.

Caso de uso prático

Um cenário comum ilustra bem o potencial dessa funcionalidade: imagine uma empresa de mídia cujos dados estão catalogados no AWS Glue Data Catalog e um anunciante com dados catalogados em um catálogo Iceberg remoto. Ambos podem agora analisar seus conjuntos de dados combinados para avaliar gastos com publicidade — tudo sem construir pipelines ETL (Extração, Transformação e Carregamento) complexos e sem que um lado precise compartilhar seus dados brutos com o outro.

O propósito do AWS Clean Rooms

O AWS Clean Rooms foi desenvolvido para permitir que empresas e seus parceiros analisem e colaborem sobre conjuntos de dados compartilhados de forma segura, revelando apenas insights e conclusões — não os dados subjacentes. A adição do suporte a catálogos Iceberg remotos reforça essa proposta de valor, tornando possível colaborações mais eficientes e com menos complexidade operacional.

Disponibilidade regional

Para informações sobre as regiões onde o AWS Clean Rooms está disponível, consulte a tabela de regiões da AWS. Mais detalhes sobre como colaborar utilizando o AWS Clean Rooms podem ser encontrados na documentação oficial do serviço.

Fonte

AWS Clean Rooms announces support for remote Apache Iceberg REST catalogs (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-clean-rooms-remote-iceberg-catalogs)