Category: Uncategorized

Aurora DSQL expande compatibilidade com ferramentas de desenvolvimento

A AWS anunciou, em fevereiro de 2026, o lançamento de integrações do Aurora DSQL com ferramentas populares de Object-Relational Mapping (ORM) e migração de banco de dados. O anúncio inclui um adaptador para Tortoise (ORM em Python), um dialeto para Flyway (ferramenta de gerenciamento de schema), e ferramentas de linha de comando para Prisma (ORM em Node.js). Essas integrações foram desenvolvidas para facilitar a utilização do Aurora DSQL por desenvolvedores que já utilizam esses frameworks em seus projetos.

Adaptador para Tortoise: simplificando desenvolvimento em Python

O Adaptador Aurora DSQL para Tortoise possibilita que desenvolvedores Python construam aplicações utilizando Tortoise sem necessidade de escrever código customizado para autenticação. O adaptador oferece suporte tanto para drivers asyncpg quanto psycopg, integra-se ao Aurora DSQL Connector para Python para geração automática de tokens de autenticação (IAM), e inclui patches de compatibilidade para migrações avançadas.

Dialeto Flyway: compatibilidade com arquitetura distribuída

O dialeto Flyway foi adaptado especificamente para a arquitetura distribuída do Aurora DSQL. Essa integração gerencia automaticamente comportamentos específicos do Aurora DSQL, como autenticação baseada em Identidade e Acesso (IAM), permitindo que a ferramenta trabalhe perfeitamente com o serviço da AWS sem configurações adicionais complexas.

Ferramentas CLI Prisma: validação e migração

As ferramentas de linha de comando Prisma para Aurora DSQL auxiliam desenvolvedores Node.js na validação de seus schemas Prisma para compatibilidade com o Aurora DSQL e na geração de migrações compatíveis com o serviço. Esse conjunto de ferramentas simplifica significativamente o caminho desde o desenvolvimento até a produção.

Próximos passos e recursos disponíveis

Para começar, a AWS disponibilizou repositórios GitHub para cada uma das integrações: Tortoise ORM, Flyway, e Prisma. Desenvolvedores podem começar a explorar Aurora DSQL gratuitamente através da camada gratuita da AWS. Para aprender mais sobre o Aurora DSQL, visite a página oficial do serviço.

Fonte

Aurora DSQL launches new support for Tortoise, Flyway, and Prisma (https://aws.amazon.com/about-aws/whats-new/2026/02/aurora-dsql-launches-tortoise-flyway-prisma/)

Novas integrações para simplificar o acesso ao Aurora DSQL

A AWS anunciou o lançamento de duas integrações importantes para o Aurora DSQL: o Driver Aurora DSQL para SQLTools e o Plugin Aurora DSQL para DBeaver Community Edition. Essas integrações abrem novas possibilidades para profissionais que trabalham com banco de dados, permitindo usar ferramentas populares e consolidadas em seus fluxos de trabalho.

O que essas integrações oferecem

As duas novas integrações permitem aos usuários do Aurora DSQL aproveitar ferramentas robustas de banco de dados para executar consultas contra clusters do Aurora DSQL, explorar esquemas de banco de dados e gerenciar seus dados de forma intuitiva. A proposta é tornar o acesso ao banco de dados mais direto e prático, eliminando as complexidades técnicas tradicionais.

Autenticação simplificada e segura

Um dos principais benefícios dessas integrações é a simplificação da autenticação. Ambas eliminam a necessidade de escrever código para geração de tokens ou fornecer manualmente tokens IAM (Gerenciamento de Identidade e Acesso). O sistema automaticamente trata a autenticação IAM e gerencia transparentemente os tokens de acesso, o que significa menos linhas de código e menos pontos de falha na sua infraestrutura.

Isso também elimina os riscos de segurança associados às tradicionais senhas geradas por usuários. Com as duas integrações, é possível usar credenciais AWS IAM para autenticação segura e sem necessidade de senha.

Integração com Visual Studio Code e editores compatíveis

O driver SQLTools integra o Aurora DSQL com Visual Studio Code e está também disponível no Open VSX Registry para uso em editores compatíveis com VS Code, como Cursor e Kiro. Isso oferece flexibilidade para desenvolvedores que preferem diferentes ambientes de desenvolvimento.

Plugin DBeaver baseado no conector JDBC

O plugin para DBeaver é construído com base no Aurora DSQL Connector para JDBC (Conectividade de Banco de Dados Java), aproveitando uma arquitetura consolidada na comunidade de desenvolvimento Java.

Como começar

Para começar a usar essas integrações, você pode consultar a documentação oficial do Aurora DSQL. A AWS oferece guias específicos para configurar o Visual Studio Code e integrar com o DBeaver.

Se deseja experimentar o Aurora DSQL sem custos, é possível começar gratuitamente através da camada gratuita da AWS. Para mais informações sobre o Aurora DSQL e suas capacidades, consulte a página oficial do serviço.

Fonte

Aurora DSQL launches new integrations for Visual Studio Code SQLTools and DBeaver (https://aws.amazon.com/about-aws/whats-new/2026/02/aurora-dsql-visual-studio-code-sqltools-dbeaver/)

Nova integração simplifica a criação de políticas IAM

A AWS anunciou a disponibilidade do AWS IAM Policy Autopilot como um Kiro Power. Esta ferramenta de análise estática de código aberto foi lançada durante o re:Invent 2025 e agora oferece aos desenvolvedores uma forma mais eficiente de integrar expertise em políticas de segurança ao desenvolvimento de aplicações com IA agentic.

O que é o AWS IAM Policy Autopilot

O AWS IAM Policy Autopilot é uma solução que auxilia desenvolvedores na criação rápida de políticas baseline de Controle de Acesso por Identidade e Acesso (IAM — Identity and Access Management) da AWS. Essas políticas podem ser refinadas conforme as aplicações evoluem, eliminando a necessidade de criação manual de políticas IAM — um processo que tradicionalmente consome tempo e requer conhecimento profundo de segurança na nuvem.

Benefícios da integração como Kiro Power

A transformação dessa ferramenta em um Kiro Power traz melhorias significativas ao fluxo de trabalho dos desenvolvedores:

Instalação simplificada

O grande diferencial é a instalação com um único clique, disponível diretamente pela interface do Kiro IDE e pela interface web. Isso elimina completamente a necessidade de configuração manual do MCP (Model Context Protocol) server, processo que antes era necessário para integrar a ferramenta.

Integração perfeita com ambientes de desenvolvimento

O fluxo de trabalho streamlined permite que os desenvolvedores gerem políticas IAM sem abandonar seu ambiente de codificação, integrando-se perfeitamente em ambientes de desenvolvimento assistido por IA. Isso significa velocidade na criação de políticas e produtividade aumentada.

Casos de uso principais

A AWS destaca três cenários onde o AWS IAM Policy Autopilot como Kiro Power oferece maior valor:

• Prototipagem rápida: Para projetos que exigem políticas IAM da AWS em fases iniciais de desenvolvimento
• Baseline para novos projetos: Criação de políticas iniciais sólidas para novas aplicações da AWS
• Produtividade em IDE: Geração de políticas diretamente no ambiente de codificação, sem interrupções no fluxo de desenvolvimento

Próximos passos

Desenvolvedores interessados em explorar essa ferramenta podem acessar o repositório do AWS IAM Policy Autopilot no GitHub para documentação técnica completa e orientações de implementação. Para informações adicionais sobre Kiro Powers e outras integrações disponíveis, consulte a página de Kiro Powers.

Fonte

AWS IAM Policy Autopilot is now available as a Kiro Power (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-iam-policy-autopilot-kiro-power/)

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/)

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/)

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)

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)

O Desafio Crescente da Segurança em Ambientes Serverless

As organizações enfrentam um cenário de segurança sem precedentes. Atacantes sofisticados utilizam inteligência artificial para identificar vulnerabilidades, automatizar ataques e contornar sistemas de detecção em velocidade de máquina. Os modelos tradicionais de segurança baseados apenas em perímetro não são mais suficientes quando adversários conseguem analisar milhões de vetores de ataque em segundos e explorar vulnerabilidades zero-day antes mesmo que correções estejam disponíveis.

Arquiteturas serverless com microsserviços amplificam esse desafio. Embora ofereçam agilidade e escalabilidade, expandem significativamente a superfície de ataque: cada endpoint de API, invocação de função e armazenamento de dados se torna um possível ponto de entrada. Um único componente mal configurado pode fornecer aos atacantes o apoio necessário para movimento lateral dentro da infraestrutura.

Simultaneamente, as organizações precisam navegar por ambientes regulatórios complexos. Frameworks de conformidade como GDPR, HIPAA, PCI-DSS e SOC 2 demandam controles de segurança robustos e trilhas de auditoria abrangentes. A velocidade do desenvolvimento de software cria tensão entre segurança e inovação, exigindo arquiteturas que sejam simultaneamente compreensivas e automatizadas para permitir implantação segura sem sacrificar a velocidade.

Os Desafios Técnicos Específicos

Implementar segurança efetiva em microsserviços serverless envolve várias dimensões de risco:

• Superfície de ataque expandida: Múltiplos pontos de entrada em serviços distribuídos exigem proteção contra ataques distribuído de negação de serviço (DDoS), vulnerabilidades de injeção e acesso não autorizado
• Complexidade de identidade e acesso: Gerenciar autenticação e autorização entre numerosos microsserviços e comunicações serviço-a-serviço
• Proteção de dados: Criptografar dados sensíveis em trânsito e em repouso, além de armazenar e rotacionar credenciais com segurança
• Conformidade e proteção de dados: Atender requisitos regulatórios através de trilhas de auditoria abrangentes e monitoramento contínuo em ambientes distribuídos
• Isolamento de rede: Implementar caminhos de comunicação controlados sem expor recursos à internet pública
• Ameaças alimentadas por IA: Defender contra atacantes que usam IA para automatizar reconhecimento, adaptar ataques em tempo real e identificar vulnerabilidades em velocidade de máquina

Defesa em Profundidade: A Solução em Camadas

A resposta efetiva a esses desafios reside em defesa em profundidade – uma abordagem de segurança em camadas onde múltiplos controles independentes trabalham em conjunto para proteger a aplicação. Nenhum único ponto de falha compromete toda a infraestrutura. Se uma camada é comprometida, controles adicionais ajudam a limitar o impacto e conter o incidente.

A AWS oferece uma arquitetura abrangente que integra serviços de IA e aprendizado de máquina em sete camadas distintas, com monitoramento contínuo e detecção de ameaças alimentadas por IA em toda a infraestrutura. Vamos percorrer como uma requisição de usuário atravessa cada camada de segurança:

Camada 1: Proteção de Borda

Antes que requisições atinjam sua aplicação, elas percorrem a internet pública onde atacantes lançam ataques volumétricos de DDoS, SQL injection, cross-site scripting (XSS) e outras explorações web. A AWS observou e mitigou milhares de ataques DDoS em 2024, com um deles ultrapassando 2,3 terabits por segundo.

AWS Shield fornece proteção gerenciada contra DDoS para aplicações na AWS, habilitada sem custo para todos os clientes. AWS Shield Advanced oferece detecção aprimorada, acesso contínuo à equipe de resposta a DDoS da AWS, proteção de custo durante ataques e diagnósticos avançados para aplicações empresariais.

AWS WAF (Firewall de Aplicação Web) protege contra ataques de camada 7 através de grupos de regras gerenciadas que cobrem as dez principais vulnerabilidades OWASP, incluindo SQL injection, XSS e inclusão de arquivo remoto. Regras baseadas em taxa bloqueiam automaticamente endereços IP que excedem limites de requisição, protegendo contra DDoS de camada de aplicação e ataques de força bruta. Recursos de bloqueio geográfico restringem acesso baseado em localização, enquanto Controle de Bots usa aprendizado de máquina para identificar e bloquear bots maliciosos permitindo tráfego legítimo.

Amazon GuardDuty utiliza IA generativa para aprimorar serviços de segurança nativos, implementando capacidades de IA para melhorar detecção de ameaças, investigação e resposta através de análise automatizada. Organizações podem construir agentes autônomos de segurança com IA usando Amazon Bedrock para analisar logs do AWS WAF, raciocinar sobre dados de ataque e automatizar resposta a incidentes. Esses agentes detectam padrões de ataque novos que sistemas baseados em assinatura perdem, geram resumos em linguagem natural de incidentes de segurança, recomendam automaticamente atualizações de regras do AWS WAF baseadas em ameaças emergentes, correlacionam indicadores de ataque em serviços distribuídos para identificar campanhas coordenadas e acionam ações de remediação apropriadas baseadas em contexto de ameaça.

Camada 2: Verificação de Identidade

Após passar proteção de borda, você deve verificar identidade do usuário e determinar acesso a recursos. Autenticação tradicional baseada em usuário/senha é vulnerável a credential stuffing, phishing e ataques de força bruta, exigindo gerenciamento robusto de identidade que suporte múltiplos métodos de autenticação e segurança adaptativa respondendo a sinais de risco em tempo real.

Amazon Cognito fornece gerenciamento abrangente de identidade e acesso para aplicações web e mobile através de dois componentes: pools de usuários oferecem um diretório de usuários totalmente gerenciado tratando registro, login, autenticação multifator (MFA), políticas de senha, integração com provedores de identidade social, federação SAML e OpenID Connect para provedores de identidade empresariais, e recursos avançados de segurança incluindo autenticação adaptativa e detecção de credenciais comprometidas. Pools de identidade concedem credenciais AWS temporárias com privilégios limitados aos usuários para acesso seguro direto aos serviços AWS sem expor credenciais de longo prazo.

Autenticação adaptativa do Amazon Cognito usa aprendizado de máquina para detectar tentativas de login suspeitas analisando impressão digital de dispositivo, reputação de endereço IP, anomalias geográficas e padrões de velocidade de login. Baseado na avaliação de risco, permite login, requer verificação MFA adicional ou bloqueia tentativas. Detecção de credenciais comprometidas automaticamente verifica credenciais contra bancos de dados de senhas comprometidas e bloqueia logins usando credenciais conhecidas como comprometidas. MFA suporta tanto métodos baseados em SMS quanto senhas descartáveis baseadas em tempo (TOTP), reduzindo significativamente risco de takeover de conta. Para análise comportamental avançada, organizações podem usar Amazon Bedrock para analisar padrões em períodos estendidos, detectando tentativas de takeover de conta através de anomalias geográficas, mudanças em impressão digital de dispositivo, desvios em padrões de acesso e anomalias de hora do dia.

Camada 3: Porta de Entrada da Aplicação

Amazon API Gateway funciona como ponto de entrada da aplicação. Deve lidar com roteamento de requisição, limitação de taxa, gerenciamento de chaves de API, criptografia e integrar perfeitamente com sua camada de autenticação, fornecendo logs detalhados para auditoria de segurança mantendo alta performance e baixa latência.

O API Gateway é um serviço totalmente gerenciado para criar, publicar e proteger APIs em escala, fornecendo capacidades críticas de segurança incluindo criptografia SSL/TLS com AWS Certificate Manager (ACM) que automaticamente trata provisionamento, renovação e implantação de certificados. Limitação de requisição e gerenciamento de cotas protegem serviços backend através de limites de rajada e taxa configuráveis com cotas de uso por chave de API ou cliente para prevenir abuso, enquanto gerenciamento de chaves de API controla acesso de sistemas parceiros e integrações de terceiros. Validação de requisição/resposta usa JSON Schema para validar dados antes de atingir AWS Lambda, prevenindo requisições malformadas de consumir recursos de computação. Integração perfeita com Amazon Cognito valida JSON Web Tokens (JWTs) e impõe requisitos de autenticação antes de requisições atingirem lógica de aplicação.

GuardDuty fornece detecção inteligente de ameaças alimentada por IA analisando padrões de invocação de API e identificando atividades suspeitas incluindo exfiltração de credenciais usando aprendizado de máquina. Para análise avançada, Amazon Bedrock analisa métricas do API Gateway e logs do Amazon CloudWatch para identificar picos incomuns de erros HTTP 4XX (por exemplo, 403 Proibido) que podem indicar tentativas de scanning ou probing, anomalias de distribuição geográfica, desvios em padrões de acesso a endpoint, anomalias em série temporal de volume de requisição ou padrões suspeitos de user agent.

Camada 4: Isolamento de Rede

Lógica de aplicação e dados devem ser isolados de acesso direto à internet. Segmentação de rede é desenhada para limitar movimento lateral se ocorre um incidente de segurança, ajudando a prevenir componentes comprometidos de facilmente acessar recursos sensíveis.

Amazon Virtual Private Cloud (Amazon VPC) fornece ambientes de rede isolados implementando arquitetura multi-tier com subnets públicas para gateways NAT e load balancers de aplicação com rotas de internet gateway, subnets privadas para funções Lambda e componentes de aplicação acessando internet através de Gateways NAT para conexões de saída, e subnets de dados com controles de acesso mais restritivos. Funções Lambda executam em subnets privadas para prevenir acesso direto à internet. VPC flow logs capturam tráfego de rede para análise de segurança. Grupos de segurança fornecem firewalls com estado seguindo princípios de menor privilégio. ACLs de rede adicionam firewalls stateless em nível de subnet com regras de negação explícita. VPC endpoints habilitam conectividade privada para Amazon DynamoDB, AWS Secrets Manager e Amazon S3 sem tráfego deixar a rede AWS.

GuardDuty fornece detecção de ameaças de rede alimentada por IA continuamente monitorando VPC flow logs, logs CloudTrail e logs DNS usando aprendizado de máquina para identificar padrões de rede incomuns, tentativas de acesso não autorizado, instâncias comprometidas e atividades de reconhecimento. Agora inclui capacidades de IA generativa para análise automatizada e consultas de segurança em linguagem natural.

Camada 5: Segurança de Computação

Funções Lambda executando seu código de aplicação frequentemente requerem acesso a recursos sensíveis e credenciais devendo ser protegidas contra injeção de código, invocações não autorizadas e escalação de privilégio. Adicionalmente, funções devem ser monitoradas para comportamento incomum que pode indicar comprometimento.

Lambda fornece recursos de segurança integrados incluindo funções de execução AWS Identity and Access Management (IAM) que definem acesso preciso a recursos e ações seguindo princípios de menor privilégio. Políticas baseadas em recurso controlam quais serviços e contas podem invocar funções prevenindo invocações não autorizadas. Criptografia de variável de ambiente usando AWS Key Management Services (AWS KMS) para variáveis em repouso enquanto dados sensíveis devem usar Secrets Manager. Isolamento de função desenhado para que cada execução rode em ambientes isolados prevenindo acesso de dados entre invocações. Integração VPC habilitando funções a se beneficiarem de isolamento de rede e controles de grupo de segurança. Segurança de runtime com runtimes gerenciados automaticamente patcheados e atualizados. Assinatura de código com AWS Signer assinando digitalmente pacotes de implantação para integridade de código e verificação criptográfica contra modificações não autorizadas.

Amazon CodeGuru Security combina aprendizado de máquina e raciocínio automatizado para identificar vulnerabilidades incluindo os 10 principais problemas OWASP e 25 principais do CWE, injeção de log, segredos e uso inseguro de API AWS. Usando análise semântica profunda treinada em milhões de linhas de código Amazon, emprega mineração de regras e modelos de ML supervisionados combinando regressão logística e redes neurais para altas taxas de verdadeiros positivos. Amazon Inspector fornece gerenciamento automatizado de vulnerabilidade, continuamente scanning funções Lambda para vulnerabilidades de software e exposição de rede, usando aprendizado de máquina para priorizar achados e fornecer orientação detalhada de remediação.

Camada 6: Proteção de Credenciais

Aplicações requerem acesso a credenciais sensíveis incluindo senhas de banco de dados, chaves de API e chaves de criptografia. Hardcoding de segredos em código ou armazená-los em variáveis de ambiente cria vulnerabilidades de segurança, exigindo armazenamento seguro, rotação regular, acesso apenas autorizado e auditoria abrangente para conformidade.

AWS Secrets Manager protege acesso a aplicações, serviços e recursos de TI sem gerenciar módulos de segurança de hardware (HSMs). Fornece armazenamento centralizado de segredos para credenciais de banco de dados, chaves de API e tokens OAuth em repositório criptografado usando criptografia AWS KMS em repouso. Rotação automática de segredos configura rotação para credenciais de banco de dados, automaticamente atualizando tanto o armazenamento de segredos quanto banco de dados alvo sem tempo de inatividade de aplicação. Controle de acesso refinado usa políticas IAM para controlar quais usuários e serviços acessam segredos específicos, implementando acesso de menor privilégio. Trilhas de auditoria registram acesso a segredos no AWS CloudTrail para investigações de conformidade e segurança. Suporte a VPC endpoint desenhado para que tráfego de recuperação de segredos não deixe a rede AWS. Integração Lambda habilita funções a recuperarem segredos programaticamente em runtime, desenhado para que segredos não sejam armazenados em código ou arquivos de configuração e possam ser rotacionados sem reimplantação.

GuardDuty fornece monitoramento alimentado por IA, detectando padrões de comportamento anômalo que podem indicar comprometimento de credencial ou acesso não autorizado.

Camada 7: Proteção de Dados

A camada de dados armazena informações sensíveis de negócio e dados de cliente exigindo proteção tanto em repouso quanto em trânsito. Dados devem ser criptografados, acesso rigidamente controlado e operações auditadas, mantendo resiliência contra ataques de disponibilidade e alta performance.

Amazon DynamoDB é um banco de dados NoSQL totalmente gerenciado fornecendo recursos de segurança integrados incluindo criptografia em repouso (usando chaves de propriedade AWS, gerenciadas AWS ou gerenciadas pelo cliente com AWS KMS). Criptografia em trânsito (TLS 1.2 ou superior). Controle de acesso refinado através de políticas IAM com permissões em nível de item e atributo. VPC endpoints para conectividade privada. Recuperação point-in-time para backups contínuos. Streams para trilhas de auditoria. Capacidades de backup e recuperação de desastre. Global Tables para replicação multi-região multi-ativa na AWS fornecendo alta disponibilidade e acesso global de baixa latência.

GuardDuty e Amazon Bedrock fornecem proteção de dados alimentada por IA: GuardDuty monitora atividade de API do DynamoDB através de logs CloudTrail usando aprendizado de máquina para detectar padrões anômalo de acesso a dados incluindo volumes de query incomuns, acesso de localizações geográficas inesperadas e tentativas de exfiltração de dados. Amazon Bedrock analisa DynamoDB Streams e logs CloudTrail para identificar padrões de acesso suspeitos, correlacionar anomalias através de múltiplas tabelas e períodos de tempo, gerar resumos em linguagem natural de incidentes de acesso a dados para equipes de segurança e recomendar ajustes de política de controle de acesso baseados em padrões de uso real versus permissões configuradas. Isso ajuda transformar proteção de dados de monitoramento reativo para threat hunting proativo que pode detectar credenciais comprometidas e ameaças internas.

Monitoramento Contínuo

Mesmo com controles de segurança abrangentes em cada camada, monitoramento contínuo é essencial para detectar ameaças que contornam defesas. Segurança requer visibilidade em tempo real contínua, detecção inteligente de ameaças e capacidades rápidas de resposta em vez de implementação única.

GuardDuty protege suas contas AWS, workloads e dados com detecção inteligente de ameaças. Amazon CloudWatch fornece monitoramento e observabilidade abrangentes, coletando métricas, monitorando arquivos de log, configurando alarmes e automaticamente reagindo a mudanças em recursos AWS. AWS CloudTrail fornece governança, conformidade e auditoria operacional registrando todas as chamadas de API em sua conta AWS, criando trilhas de auditoria abrangentes para análise de segurança e relatórios de conformidade.

Aprimoramento alimentado por IA com Amazon Bedrock fornece análise automatizada de ameaças; gerando resumos em linguagem natural de achados de GuardDuty e logs CloudWatch, reconhecimento de padrão identificando ataques coordenados através de múltiplos sinais de segurança, recomendações de resposta a incidentes baseadas em sua arquitetura e requisitos de conformidade, avaliação de postura de segurança com recomendações de melhoria e resposta automatizada através de Lambda e Amazon EventBridge que isola recursos comprometidos, revoga credenciais suspeitas ou notifica equipes de segurança através do Amazon SNS quando ameaças são detectadas.

Conclusão

Proteger microsserviços serverless apresenta desafios significativos, mas como demonstrado, usar serviços AWS ao lado de capacidades alimentadas por IA cria uma arquitetura resiliente de defesa em profundidade que protege contra ameaças atuais e emergentes, comprovando que segurança e agilidade não são mutuamente exclusivas. Segurança é um processo contínuo—continuamente monitore seu ambiente, regularmente revise controles de segurança, mantenha-se informado sobre ameaças emergentes e melhores práticas, e trate segurança como um princípio arquitetural fundamental ao invés de pensamento posterior.

Leitura Complementar

• Melhores práticas para implementar Zero Trust com sucesso
• IA/ML para segurança – Orientação Prescritiva AWS
• Automatizar avaliação de vulnerabilidade de segurança em nuvem e alertas usando Amazon Bedrock
• Proteção de infraestrutura – Serverless Applications Lens

Fonte

Building an AI-powered defense-in-depth security architecture for serverless microservices (https://aws.amazon.com/blogs/security/building-an-ai-powered-defense-in-depth-security-architecture-for-serverless-microservices/)