Blog

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)

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

PrivateLink para SAP HANA: segurança de ponta a ponta

A AWS expandiu as funcionalidades do AWS Backup ao introduzir suporte a PrivateLink (Link Privado) para sistemas SAP HANA em execução na Amazon EC2. Essa nova capacidade permite que as organizações direcionem todo o tráfego de backup através de conexões de rede privada, evitando completamente a passagem pela internet pública. Para muitas empresas que operam em setores regulados, esse é um requisito fundamental de conformidade e segurança.

O desafio anterior: tráfego dividido

Anteriormente, havia uma limitação importante: enquanto as cargas de trabalho de aplicação SAP HANA podiam utilizar o PrivateLink para estabelecer comunicação segura e privada com os serviços da AWS, o tráfego de backup precisava obrigatoriamente passar por endpoints públicos. Essa divisão criava um cenário onde a proteção de dados não era completamente privada de ponta a ponta, exigindo concessões em termos de segurança.

Conformidade regulatória simplificada

Organizações em setores altamente regulados — como serviços financeiros, saúde e agências governamentais — frequentemente enfrentam exigências estritas quanto à privacidade e localidade de dados. Com essa atualização, a AWS permite que empresas sujeitas a regulamentações como HIPAA (Lei de Portabilidade e Responsabilidade de Seguros de Saúde), Privacy Shield (EU/US) e PCI DSS (Padrão de Segurança de Dados para Indústria de Cartões de Pagamento) implementem estratégias de proteção de dados totalmente privadas. Isso significa que tanto o tráfego de aplicação quanto os dados de backup permanem dentro de redes privadas controladas pela organização.

Como funciona e próximos passos

Essa capacidade agora está disponível em todas as regiões da AWS onde o AWS Backup oferece suporte a bancos de dados SAP HANA em EC2. Para começar a utilizar o PrivateLink com backups de SAP HANA, os clientes precisam realizar duas ações principais:

• Atualizar o agente Backint
• Adicionar o endpoint de conexão privada (VPCE) de backup-storage à sua VPC

Essas configurações garantem que a infraestrutura de backup seja integrada completamente à rede privada da organização, eliminando qualquer ponto de exposição à internet pública.

Impacto para empresas brasileiras

Para organizações brasileiras que operam com SAP HANA e estão em setores regulados (instituições financeiras, plataformas de saúde, órgãos governamentais), essa novidade representa um avanço significativo na capacidade de atender exigências de conformidade de forma prática. O recurso simplifica a implementação de arquiteturas de nuvem verdadeiramente privadas, reduzindo a complexidade operacional e os riscos associados à exposição desnecessária de tráfego de dados.

Fonte

AWS Backup announces PrivateLink support for SAP HANA on AWS (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-backup-announces-privatelink-sap-hana-aws/)