A Amazon Web Services (AWS) anunciou a inclusão de dois serviços adicionais e uma nova região geográfica no escopo de sua certificação Payment Card Industry Data Security Standard (PCI DSS). Essa atualização oferece aos clientes mais opções para implementar cargas de trabalho reguladas enquanto mantêm conformidade com os rigorosos padrões de segurança de dados de cartões de pagamento.
Além dos serviços, a região Asia Pacific (Taipei) foi adicionada ao programa de certificação PCI DSS, ampliando as opções de localidade para organizações que precisam manter dados de cartão de pagamento em conformidade regulatória em diferentes regiões.
Componentes do Pacote de Conformidade
O pacote de conformidade PCI DSS da AWS é composto por dois elementos principais:
Attestation of Compliance (AOC): Documento que demonstra que a AWS foi validada com sucesso conforme os requisitos do padrão PCI DSS, avaliada por um avaliador qualificado independente.
AWS Responsibility Summary: Guia que orienta os clientes da AWS sobre suas responsabilidades específicas na implementação e operação de ambientes seguros para processamento de dados de cartão de pagamento.
A avaliação foi conduzida pela Coalfire, uma empresa qualificada como Qualified Security Assessor (QSA) terceirizada.
Inovação em Formatos de Conformidade
Um destaque importante dessa atualização é a disponibilidade dos relatórios de conformidade em formato Open Security Controls Assessment Language (OSCAL). Trata-se de um padrão aberto mantido pelo NIST, baseado em JSON estruturado para leitura por máquinas, permitindo automação de workflows e redução de processamento manual em auditorias de conformidade.
A AWS é a primeira provedora de nuvem a oferecer relatórios de conformidade neste formato, um avanço significativo rumo a processos de conformidade modernizados e automatizáveis.
Acesso e Implementação Prática
Os clientes podem acessar toda a documentação de certificação PCI DSS através do AWS Artifact, um portal de autoatendimento que oferece acesso sob demanda aos relatórios de conformidade da AWS. Esse recurso simplifica processos de auditoria e integração com fluxos de conformidade existentes.
Expansão do Amazon Inspector com novo suporte a Java Gradle
A AWS anunciou uma atualização significativa no Amazon Inspector, seu serviço automatizado de gerenciamento de vulnerabilidades. A novidade traz suporte específico para Java Gradle nas varreduras de funções Lambda e imagens no Elastic Container Registry (ECR), abrindo possibilidades para uma cobertura muito mais ampla de componentes e tecnologias.
Novos componentes e tecnologias cobertos
Com esta atualização, o Amazon Inspector agora consegue detectar vulnerabilidades não apenas em Java com Gradle, mas também em uma série de outros componentes frequentemente utilizados em ambientes cloud. A expansão inclui MySQL, MariaDB, PHP, Jenkins-core, 7zip (em Windows), Elasticsearch e Curl/LibCurl.
Como funciona o suporte a Java Gradle
O novo suporte a Java Gradle permite que o Inspector analise as dependências de projetos Java tomando como base o conteúdo do arquivo gradle.lockfile. Isso significa que aplicações Java podem agora receber avaliações abrangentes de vulnerabilidades diretamente nas suas dependências gerenciadas pelo Gradle.
Melhor detecção de pacotes fora dos gerenciadores de pacotes
Uma das grandes vantagens dessa expansão é a capacidade melhorada de identificar vulnerabilidades em pacotes instalados fora dos gerenciadores de pacotes tradicionais. Ao escanear funções Lambda e imagens ECR, você agora verá descobertas de vulnerabilidades também em instalações de MySQL, MariaDB, PHP, Jenkins-core, 7zip (Windows), Elasticsearch e Curl/LibCurl.
O que é o Amazon Inspector
O Amazon Inspector é um serviço de gerenciamento automatizado de vulnerabilidades que funciona continuamente, escaneando as cargas de trabalho da AWS em busca de vulnerabilidades de software e exposições não intencionais de rede. Seu objetivo é ajudar organizações a fortalecerem sua postura de segurança e atender requisitos de conformidade regulatória.
Benefícios práticos para sua infraestrutura
Essas melhorias representam um avanço significativo na segurança automatizada. Para organizações que utilizam estas tecnologias — particularmente aquelas com stacks Java baseados em Gradle — a cobertura expandida oferece tranquilidade maior e detecção mais precisa de riscos potenciais em suas aplicações.
Como começar
Os novos recursos estão disponíveis a partir de agora em todas as regiões da AWS onde o Amazon Inspector funciona. Para aprender mais sobre o Amazon Inspector e como ele pode ajudar a proteger suas cargas de trabalho na AWS, consulte a página do Amazon Inspector.
Para uma lista completa dos sistemas operacionais e linguagens de programação suportados pelo Amazon Inspector, confira o guia do usuário.
O Amazon Connect, serviço de contact center em nuvem da AWS, acaba de incorporar uma funcionalidade importante para quem trabalha com supervisão e qualidade de atendimento. A novidade permite que supervisores acompanhem o status das gravações de tela dos agentes praticamente em tempo real através do CloudWatch, utilizando o Amazon EventBridge como intermediário.
Essa evolução vem em resposta a uma necessidade real dos gestores de contact center: ter visibilidade completa sobre o que cada agente está fazendo durante o atendimento. Não basta mais escutar chamadas ou revisar transcrições de chat. Agora é possível visualizar as ações do agente na sua tela enquanto ele interage com o cliente — seja em uma chamada de voz, conversa por chat ou tarefa.
Capacidades de Rastreamento
Quando integrado ao Amazon EventBridge, o novo recurso oferece acesso a informações granulares sobre cada sessão de gravação de tela. Os supervisores conseguem visualizar dados como:
Status de sucesso ou falha de cada gravação
Códigos de erro detalhados, acompanhados de descrição
Versão do cliente de gravação instalada no computador do agente
Versão do navegador web utilizado pelo agente
Sistema operacional em que o agente está operando
Horários precisos de início e fim de cada gravação
Esses dados agregados no CloudWatch criam um panorama transparente das operações, facilitando a identificação de problemas técnicos, inconsistências de processo ou necessidades de treinamento específico.
Como Começar
A ativação da funcionalidade é direta. Os clientes da AWS precisam apenas se inscrever no tipo de evento Screen Recording Status Changed no barramento de eventos do Amazon EventBridge. Assim que configurado, o fluxo de dados para o CloudWatch começa automaticamente.
O recurso já está disponível em todas as regiões da AWS onde o Amazon Connect funciona, o que garante que organizações brasileiras utilizando este serviço possam adotá-lo sem restrições geográficas.
Caso de Uso Prático
Supervisores podem explorar os dados de gravação para identificar oportunidades de coaching com agentes. Por exemplo, se uma gravação falha repetidamente para um agente específico, pode-se investigar problemas de compatibilidade do cliente ou da infraestrutura local. Alternativamente, se todas as gravações de determinado período mostram padrões consistentes de não-conformidade com processos de negócio, há espaço para intervenção educativa ou revisão de procedimentos.
Esta atualização reforça o posicionamento do Amazon Connect como uma solução madura e orientada a conformidade, essencial para empresas que precisam manter altos padrões de qualidade e regulamentação em seus centros de contato.
Reconhecimento consecutivo em liderança europeia de nuvem soberana
Pela terceira vez consecutiva, a Amazon Web Services (AWS) foi designada como Líder no relatório Provider Lens™ do Grupo de Serviços de Informação (ISG – Information Services Group), divulgado em 9 de janeiro de 2026. Este relatório, que avalia especificamente Serviços de Infraestrutura em Nuvem Soberana no contexto europeu, reconhece os provedores que demonstram inovação robusta e estabilidade competitiva em um ambiente multicloud complexo.
O ISG é uma instituição de pesquisa, análise e consultoria tecnológica globalmente reconhecida, parceira de negócios de mais de 900 clientes em todo o mundo. Sua metodologia de avaliação examina como os provedores atendem aos desafios críticos enfrentados por empresas na União Europeia, particularmente no que se refere à governança, residência de dados e conformidade regulatória.
Metodologia de avaliação e critérios de excelência
O escopo desta edição incluiu a análise de 19 provedores de infraestrutura em nuvem soberana, oferecendo uma perspectiva abrangente do mercado europeu. O ISG estruturou sua avaliação em torno de dois eixos principais: força competitiva e atratividade do portfólio.
Força competitiva
A avaliação da força competitiva levou em consideração múltiplos fatores, incluindo grau de conhecimento do mercado, competências centrais da empresa e estratégia de entrada e comercialização dos serviços. Estes critérios refletem não apenas o que o provedor oferece, mas também como ele se posiciona estrategicamente no mercado europeu.
Atratividade do portfólio
O segundo pilar da avaliação examinou a amplitude e qualidade do portfólio de serviços, assim como a estratégia e visão do provedor para o futuro. Também foram consideradas as características específicas do atendimento local — um fator determinante para organizações que operem sob regulamentações regionais rigorosas. A AWS atingiu o mais alto índice nesta dimensão, destacando-se pela riqueza e relevância de suas ofertas para o contexto europeu.
O diferencial da arquitetura soberana por design
Segundo o relatório do ISG, a infraestrutura da AWS oferece resiliência e disponibilidade robustas, fundamentadas em uma arquitetura denominada “soberana por design”. Este conceito significa que a proteção da soberania de dados e a independência regional não são funcionalidades adicionadas posteriormente, mas sim princípios estruturais incorporados desde o desenho arquitetural.
Esta abordagem garante que os clientes europeus mantenham controle efetivo sobre seus dados, com garantia de residência em regiões especificadas e isolamento regional forte. A AWS combina este compromisso com bases profundas de engenharia no continente europeu e mais de uma década de experiência operando múltiplas nuvens independentes para cargas de trabalho críticas e altamente reguladas.
Compromisso com soberania digital e conformidade regulatória
O reconhecimento reflete o compromisso contínuo da AWS em atender aos requisitos específicos de soberania digital e resiliência de clientes e parceiros europeus. A empresa pauta seus esforços em uma Declaração de Soberania Digital e investe em um roteiro ambicioso de capacidades que contemplam:
Residência garantida de dados em regiões especificadas
Controle granular de acesso e permissões
Criptografia robusta e gerenciamento de chaves
Resiliência operacional e redundância regional
Estes investimentos demonstram que a AWS vai além de conformidade regulatória básica, oferecendo aos clientes europeus verdadeiro controle e escolha sem comprometer o acesso ao portfólio completo de serviços da plataforma.
Terceira indicação consecutiva: consolidação de liderança
O reconhecimento como Líder por três anos consecutivos representa mais que um prêmio pontual — reflete a consolidação de uma estratégia de longo prazo em torno de soberania digital. Este desempenho é construído sobre fundações sólidas: forte compromisso histórico com controle de dados pelo cliente, princípios arquiteturais de isolamento regional robusto, e enraizamento de operações na engenharia europeia.
Para organizações brasileiras e internacionais que operam na Europa ou precisam atender clientes europeus, este reconhecimento oferece uma perspectiva clara sobre qual provedor tem investido consistentemente em capacidades que atendem rigorosamente aos requisitos regulatórios e de soberania do continente.
Este relatório é particularmente valioso para equipes de arquitetura, conformidade e liderança que avaliam estratégias multicloud com requisitos específicos de residência de dados e governança regional.
A Velocidade como Fator Crítico na Defesa contra Ameaças
O cenário de segurança em nuvem enfrenta um desafio fundamental: a velocidade das ameaças supera significativamente a capacidade de resposta das defesas tradicionais. Cargas de trabalho com vulnerabilidades conhecidas são identificadas por atores maliciosos em aproximadamente 90 segundos, e as tentativas de exploração começam nos primeiros 3 minutos. Os cibercriminosos continuam evoluindo suas estratégias, criando constantemente novos tipos de malware, técnicas de exploração sofisticadas e táticas de evasão. Ao mesmo tempo, eles alternam sua infraestrutura — endereços IP, domínios e URLs mudam regularmente.
Essa dinâmica impõe um desafio claro: como traduzir dados de ameaças em medidas de proteção rapidamente, especialmente operando em escala de internet? A AWS propõe uma solução através de sua defesa ativa contra ameaças integrada ao AWS active threat defense para AWS Network Firewall.
Inteligência Contínua através da Rede MadPot
O núcleo dessa estratégia é MadPot, uma rede de sensores honeypot (armadilhas) que a Amazon mantém para monitorar ativamente padrões de ataque. Esses honeypots imitam servidores em nuvem, bancos de dados e aplicações web — completos com configurações inadequadas e falhas de segurança que os atacantes buscam ativamente.
Quando os criminosos caem nessa “isca” e lançam seus ataques, o MadPot captura todo o ciclo de ataque. A rede observa mais de 750 milhões de interações com potenciais ameaças diariamente. Novos sensores MadPot são descobertos pelos atacantes em menos de 90 segundos, revelando padrões que passariam despercebidos em outras circunstâncias.
A transformação dessa inteligência em proteção ocorre de forma otimizada: quando ameaças são detectadas, a defesa ativa traduz automaticamente essa inteligência em detecção de ameaças através do Amazon GuardDuty e proteção ativa através do AWS Network Firewall — tudo dentro de 30 minutos após receber a nova inteligência.
Visão geral da integração de defesa ativa contra ameaças — Fonte: Aws
Arquitetura em Camadas: O Modelo de Queijo Suíço
A defesa ativa adota o modelo de queijo suíço — um conceito que reconhece que nenhum controle de segurança é perfeito isoladamente, mas múltiplas camadas imperfeitas, quando empilhadas, criam uma proteção robusta.
Cada camada defensiva possui lacunas. Atacantes podem contornar filtros de DNS usando conexões diretas por IP. Tráfego criptografado pode contornar inspeção HTTP. Técnicas como domain fronting ou conexões apenas IP evitam análise de SNI (Indicação de Nome do Servidor – Server Name Indication).
A defesa ativa aplica indicadores de ameaça em múltiplos pontos de inspeção. Se um atacante conseguir contornar uma camada, outras ainda conseguem detectar e bloquear a ameaça. Quando MadPot identifica um domínio malicioso, o Network Firewall não apenas bloqueia o domínio — cria regras que negam consultas DNS, bloqueiam headers HTTP, impedem conexões TLS usando SNI e descartam conexões diretas para os endereços IP resolvidos. Como fatias de queijo suíço empilhadas, os buracos raramente se alinham.
Os ataques modernos dependem de comunicação em rede em praticamente todos os estágios — exatamente onde a defesa ativa cria suas múltiplas camadas. Examinar como a defesa ativa interrompe a cadeia de ataque revela a sofisticação dessa abordagem.
Etapa 0: Preparação de Infraestrutura
Antes de lançar ataques, criminosos precisam preparar sua infraestrutura operacional. Isso inclui configurar pontos de monitoramento de testes de aplicação fora de banda (OAST) — técnicas de reconhecimento usadas para verificar exploração bem-sucedida através de canais de comunicação separados. Também provisionam servidores de distribuição de malware e servidores de comando e controle (C2). Os honeypots MadPot detectam essa infraestrutura quando os criminosos a usam contra sistemas de engodo, alimentando esses indicadores nas regras de proteção.
Etapas 1-3: Identificação do Alvo, Confirmação de Vulnerabilidade e Callback OAST
Os atacantes compilam listas de vítimas potenciais através de varreduras automatizadas da internet ou comprando listas em mercados clandestinos. Procuram por cargas de trabalho executando software vulnerável, serviços expostos ou configurações comuns inadequadas.
Em seguida, tentam verificar uma vulnerabilidade no alvo, frequentemente incorporando um mecanismo OAST no payload da exploração. Isso pode ser uma URL maliciosa como http://malicious-callback[.]com/verify?target=victim injetada em formulários web, headers HTTP ou parâmetros de API.
Nos últimos 90 dias, MadPot observou tentativas de exploração contra 20 vulnerabilidades diferentes usando links OAST, incluindo CVE-2017-10271, CVE-2021-44228 e CVE-2022-26134.
Quando cargas de trabalho vulneráveis processam esses payloads maliciosos, tentam iniciar conexões de callback para os servidores OAST do atacante. Esses sinais normalmente forneceriam confirmação de exploração bem-sucedida. Mas a defesa ativa quebra a cadeia neste ponto: o Network Firewall bloqueia a conexão de saída para o endpoint OAST. O exploit pode ter sucesso, mas sem confirmação, o criminoso não sabe quais alvos perseguir — paralisando o ataque.
Etapa 4: Preparação para Entrega de Malware
Após identificar um alvo vulnerável, o atacante explora a vulnerabilidade para entregar malware que estabeleça acesso persistente. MadPot observou tentativas contra vulnerabilidades como CVE-2017-12149, CVE-2021-26084 e CVE-2021-44228.
Etapa 5: Download de Malware
O alvo comprometido tenta fazer download do payload de malware do servidor de distribuição do atacante. A defesa ativa intervém novamente: a infraestrutura que hospeda o malware — domínio, URL ou endereço IP — foi identificada por MadPot e bloqueada pelo Network Firewall.
Para malware entregue através de endpoints TLS, a defesa ativa usa inspeção de SNI durante o handshake TLS para identificar e bloquear domínios maliciosos sem descriptografar tráfego. Para aqueles que usam recursos como inspeção TLS do Network Firewall, as regras inspecionam URLs completas e headers HTTP, aplicando regras baseadas em conteúdo. Sem entrega bem-sucedida de malware, o atacante não consegue estabelecer controle.
Etapa 6: Conexão de Comando e Controle
Se o malware tivesse sido entregue, tentaria “fazer contato” conectando ao servidor C2 do atacante para receber instruções. Neste ponto, outra camada da defesa ativa se ativa.
No nível DNS, o Network Firewall bloqueia requisições de resolução para domínios C2 conhecidos. No nível TCP, bloqueia conexões diretas para endereços IP e portas C2. No nível TLS, usa inspeção SNI ou descriptografia completa quando habilitada. O Network Firewall bloqueia a conexão de saída para a infraestrutura C2 maliciosa, cortando a capacidade do criminoso de controlar o sistema infectado.
Registros de detecção de ameaças são criados no Amazon GuardDuty para tentativas de conexão, permitindo iniciar workflows de resposta a incidentes. Os últimos 90 dias revelaram que MadPot monitorou frameworks C2 como Cobalt Strike, Mythic, Empire e XorDDoS.
Etapa 7: Objetivos de Ataque Bloqueados
Sem conectividade C2, o atacante não consegue roubar dados ou exfiltrar credenciais. A abordagem em camadas significa que atacantes precisam ter sucesso em cada estágio, enquanto você só precisa bloquear um para parar a atividade. Essa defesa em profundidade reduz risco mesmo que algumas camadas tenham vulnerabilidades. É possível rastrear ações de defesa ativa no registro de alertas do Network Firewall.
O fluxo completo de ataque, mostrando cada etapa da cadeia — Fonte: Aws
Caso Real: Campanha de Exploração CVE-2025-48703
Em outubro de 2025, honeypots MadPot começaram detectando uma campanha de ataque contra o Control Web Panel (CWP) — uma plataforma de gerenciamento de servidores usada por provedores de hospedagem e administradores de sistemas. Os atacantes tentavam explorar CVE-2025-48703, uma vulnerabilidade de execução remota de código no CWP, para implantar o framework Mythic C2.
As tentativas de exploração originaram de um endereço IP exibindo características de nó de saída VPN. Para confirmar alvos vulneráveis, o atacante tentou executar comandos do sistema operacional explorando a vulnerabilidade do gerenciador de arquivos do CWP.
Após a identificação de sistemas vulneráveis, o ataque passou imediatamente para entrega de payload. MadPot capturou tentativas de infecção contra cargas de trabalho Linux e Windows. Para alvos Linux, o atacante usou curl e wget para baixar o malware. Para Windows, usou o utilitário certutil.exe da Microsoft.
MadPot identificou indicadores de ameaça em múltiplas camadas de análise: URLs de staging e endereços IP subjacentes hospedando malware, lógica contida nos scripts para detectar arquitetura do sistema e baixar o agente Mythic apropriado, e endpoints do framework Mythic C2 revelando infraestrutura de controle.
Dentro de 30 minutos da análise do MadPot, instâncias globais do Network Firewall implantaram regras de proteção atingindo cada camada dessa infraestrutura de ataque. Instalações vulneráveis do CWP permaneceram protegidas porque quando a exploração tentava executar comandos de download de malware, o Network Firewall bloqueava tanto a resolução do domínio quanto conexões para os endereços IP maliciosos. Mesmo se scripts de staging conseguissem alcançar um alvo através de vetores alternativos, falhariam ao tentar baixar binários do agente Mythic. Se um binário Mythic fosse entregue através de um vetor completamente diferente, ainda não conseguiria estabelecer comando e controle.
Para clientes com Amazon GuardDuty com instalações CWP sem patches, receberiam descobertas de detecção de ameaças para tentativas de comunicação com infraestrutura maliciosa. Para clientes usando defesa ativa com Network Firewall, cargas de trabalho CWP sem patches receberiam proteção automática contra essa campanha mesmo antes desta CVE ser adicionada à lista de Vulnerabilidades Exploradas Conhecidas da CISA em 4 de novembro.
Implementação e Próximos Passos
A defesa ativa contra ameaças para Network Firewall utiliza inteligência MadPot e proteção em camadas para interromper cadeias de ataque de criminosos e reduzir a carga operacional de equipes de segurança. Com implantação automatizada de regras, a defesa ativa cria defesas em camadas dentro de 30 minutos de novas ameaças serem detectadas pelo MadPot.
A AWS expandiu as capacidades de segurança do Amazon MQ, seu serviço gerenciado de message broker, anunciando suporte a autenticação baseada em certificados para brokers RabbitMQ. Esse recurso permite que os brokers autentiquem usuários utilizando certificados X.509 (Certificado de Cliente) em conjunto com TLS mútuo (mTLS).
A implementação utiliza o plugin auth_mechanism_ssl do RabbitMQ, que pode ser configurado em brokers executando a versão 4.2 ou superior. Essa abordagem oferece uma alternativa mais robusta aos mecanismos tradicionais de autenticação por nome de usuário e senha, alinhando-se com as melhores práticas de segurança em ambientes corporativos.
Como Funciona o TLS Mútuo
O Mecanismo de Autenticação
O TLS mútuo (mTLS) é um protocolo que estabelece autenticação bidirecional entre cliente e servidor. Ao contrário do TLS tradicional, onde apenas o servidor é autenticado, no mTLS ambas as partes precisam apresentar certificados válidos para estabelecer a conexão. Isso garante que apenas clientes autorizados consigam se conectar ao broker RabbitMQ.
O plugin auth_mechanism_ssl utiliza as informações contidas no certificado X.509 do cliente para determinar quem pode fazer login e quais permissões aquele cliente possui. Dessa forma, a identidade é verificada de forma criptográfica, eliminando a necessidade de transmitir senhas pela rede.
Primeiros Passos na AWS
Criando um Novo Broker com Autenticação por Certificado
Para começar a usar autenticação baseada em certificados no Amazon MQ, você precisa:
Selecionar a versão RabbitMQ 4.2 ou superior ao criar um novo broker
Utilizar o tipo de instância M7g
Editar o arquivo de configuração associado com os valores necessários para ativar o plugin
O processo de criação pode ser feito através de três interfaces: AWS Management Console, AWS CLI (Interface de Linha de Comando) ou AWS SDKs (Software Development Kits). Em qualquer um dos casos, o fluxo é semelhante: você configura os parâmetros do broker e depois ajusta o arquivo de configuração com as propriedades específicas do plugin.
Este novo recurso de autenticação por certificado está disponível em todas as regiões onde o Amazon MQ RabbitMQ 4 já funciona atualmente. Isso significa que você pode implementar essa camada de segurança independentemente do local geográfico escolhido para hospedar seus brokers.
Por Que Isso Importa para Sua Infraestrutura
A adição do suporte a mTLS no Amazon MQ representa um fortalecimento significativo na postura de segurança das aplicações que utilizam message brokers. Para organizações que trabalham com dados sensíveis ou que precisam cumprir regulamentações rigorosas de segurança, autenticação baseada em certificados oferece garantias criptográficas muito mais fortes do que autenticação por credenciais simples.
Além disso, a integração com infraestrutura de chave pública (PKI) existente permite que empresas apliquem políticas de rotação de certificados, auditoria de acesso e revogação de credenciais de forma centralizada e controlada.
O Desafio da Proteção de Dados Pessoais em Larga Escala
Organizações recebem constantemente volumes significativos de informações sensíveis dos clientes através de diferentes canais de comunicação. Proteger dados pessoalmente identificáveis (DPI) — como números de seguro social, habilitação e telefone — tornou-se essencial para cumprir regulamentações de privacidade e manter a confiança dos usuários.
O problema é que revisar e remover manualmente esses dados é demorado, propenso a erros e não se adapta bem quando os volumes crescem. Além disso, informações sensíveis aparecem em formatos variados: textos de emails, documentos em anexos, imagens digitalizadas. Soluções tradicionais exigem ferramentas separadas para cada tipo de conteúdo, criando inconsistências na redação e deixando brechas na segurança. Essa fragmentação aumenta a complexidade operacional e o risco de exposição acidental de dados.
Uma Solução Integrada para Redação Automatizada
A AWS apresentou uma abordagem que centraliza a detecção e remoção de dados pessoais em texto e imagens através de Amazon Bedrock Data Automation e Amazon Bedrock Guardrails. A solução foi demonstrada em um cenário prático: o processamento automatizado de emails e anexos em altos volumes.
Capacidades Principais da Solução
O sistema oferece três capacidades fundamentais:
Detecção e redação automatizadas: Processa simultaneamente o conteúdo de emails e arquivos anexados, garantindo que dados sensíveis sejam protegidos de forma consistente independentemente do formato.
Fluxos de trabalho mais seguros: As comunicações processadas são criptografadas, armazenadas com controles de acesso apropriados e acompanhadas por um registro de auditoria completo.
Interface para usuários autorizados: Uma aplicação baseada na web permite que o pessoal autorizado gerencie e revise as comunicações de forma mais segura, com recursos como categorização automática de emails e gerenciamento customizável de pastas.
Essa unificação ajuda as organizações a atender requisitos de conformidade com privacidade enquanto simplifica seus fluxos de trabalho de comunicação.
Como a Solução Funciona
Arquitetura Geral
A solução articula-se em torno de dois componentes principais: um fluxo de processamento de backend e uma interface de usuário frontend. AWS Lambda e Amazon EventBridge orquestram todo o processo.
Fluxo de Processamento Passo a Passo
O workflow segue esta sequência:
Um email é enviado para um servidor de email hospedado em Amazon Simple Email Service (SES). Como alternativa, os usuários podem fazer upload direto de emails e anexos para um bucket de armazenamento inicial no Amazon S3.
Uma notificação de evento do S3 dispara a função Lambda inicial de processamento, que gera um ID único de caso e cria um registro de rastreamento no Amazon DynamoDB.
Lambda extrai o corpo do email e os anexos, armazenando-os em um bucket de email bruto e invocando então o Bedrock Data Automation para extrair texto dos documentos e o Bedrock Guardrails para detectar e remover dados pessoais. O conteúdo reduzido é armazenado em outro bucket do S3.
Tabelas DynamoDB são atualizadas com metadados de mensagens, emails e regras de filtragem.
Um agendador do EventBridge executa uma função Lambda de “Motor de Regras” em intervalos periódicos, categorizando emails não processados em pastas conforme critérios de regras ativas.
Usuários acessam a interface web opcional através do Amazon API Gateway, que gerencia requisições e fornece a interface via hospedagem estática no S3.
Terminal/CLI (macOS Terminal, PowerShell, Windows Terminal, ou linha de comando Linux). AWS CloudShell também pode ser usado quando todo o código está dentro da conta.
Requisitos de Infraestrutura
Verifique que existe uma nuvem privada virtual (VPC) com três subnets privadas sem acesso à internet. Todos os stacks do AWS CloudFormation devem ser implantados na mesma conta AWS.
Stacks do CloudFormation
A solução contém três stacks (dois obrigatórios, um opcional):
S3Stack: Provisiona buckets do S3 para armazenamento bruto e reduzido com políticas de ciclo de vida automático, uma tabela DynamoDB para rastreamento de metadados com TTL e índices secundários globais, grupos de segurança VPC, e funções de Gerenciamento de Identidade e Acesso (IAM) com permissões abrangentes.
ConsumerStack: Provisiona projetos Bedrock Data Automation para extração de texto, Bedrock Guardrails para anonimizar dados pessoais, funções Lambda para processamento, tópicos Amazon Simple Notification Service (SNS) para notificações, e regras de recebimento Amazon SES.
PortalStack (opcional): Oferece interface web com API Gateway regional, tabelas DynamoDB, e buckets S3 para ativos estáticos.
A implantação inicial leva aproximadamente 10 minutos.
Testes e Validação
Teste com Amazon SES
Após a implantação, ative o conjunto de regras de recebimento do SES e envie um email para o endereço verificado. O progresso pode ser monitorado na tabela DynamoDB. Cada email recebe um ID de caso único. Após conclusão, o email reduzido estará em s3://<>/redacted/<>/<>/.
Teste sem Amazon SES
Alternativamente, faça upload direto de um arquivo de email para o bucket bruto usando a CLI do AWS. Um email de exemplo está disponível no repositório.
Interface Web (Opcional)
O portal é uma interface React que permite visualizar emails processados e seus anexos reduzidos. Requer TypeScript, Node v18, e NPM v9.8 ou superior.
Para implantar o portal, navegue até a raiz do diretório de infraestrutura e execute:
Crie um arquivo .env com as variáveis de ambiente necessárias (URL do API Gateway, caminhos base e de API), execute npm install e npm run build, e sincronize os arquivos gerados para o bucket S3 designado.
Limpeza de Recursos
Para evitar cobranças futuras, delete o conteúdo dos buckets S3, desative as regras do SES, remova os stacks CloudFormation na ordem inversa e limpe grupos de logs do CloudWatch. Se usar versionamento do S3, remova também versões antigas usando comandos CLI específicos.
Considerações Técnicas Importantes
Ao usar esta solução, observe que o Bedrock Data Automation possui restrições de processamento: suporta PDF, JPEG e PNG com tamanho máximo de 200 MB via console (500 MB via API) e documentos individuais não podem exceder 20 páginas sem divisão de documento habilitada.
Para produção, implemente controles de acesso apropriados ao portal via API Gateway.
Benefícios da Solução
A automatização centralizada oferece eficiência operacional reduzindo revisão manual, escalabilidade para lidar com volumes crescentes, conformidade regulatória aprimorada e segurança consistente. A modularidade da solução permite futura integração com serviços AWS adicionais, refinamento de regras de detecção e suporte a formatos e idiomas diferentes.
Próximos Passos
A CloudTroop recomenda explorar o repositório GitHub fornecido para compreender a implementação completa e adaptá-la às necessidades organizacionais. O código está disponível para que equipes construam uma solução robusta de proteção de dados alinhada com requisitos comerciais e regulatórios em evolução.
Configuração rápida do AWS Client VPN: simplificando o onboarding
A AWS anunciou uma experiência de integração simplificada para o AWS Client VPN, introduzindo um novo método de configuração rápida (Quickstart) que otimiza significativamente o processo de criação e configuração de endpoints de VPN. Este serviço permite que usuários remotos se conectem com segurança aos recursos da AWS e às redes locais de uma organização.
O novo fluxo de configuração rápida
A inovação principal está na redução drástica do número de etapas necessárias para configurar um endpoint de Client VPN. Com o novo método, é possível criar endpoints utilizando configurações padrão pré-definidas, exigindo apenas três informações essenciais:
Intervalo CIDR IPv4
Número de identificação (ARN) do certificado do servidor
Seleção da sub-rede
Essa simplificação beneficia especialmente equipes de desenvolvimento em grandes organizações que utilizam o Client VPN para acesso remoto aos recursos de rede virtual (VPC) e testagem rápida. Agora é possível criar endpoints de forma ágil, sem necessidade de configurações complexas.
Flexibilidade e compatibilidade com o fluxo existente
O novo método de configuração rápida está disponível em paralelo com a opção de configuração padrão já existente, proporcionando flexibilidade aos usuários. Cada organização pode escolher a abordagem que melhor se alinha com suas necessidades de implantação.
Além disso, quando um usuário cria uma nova VPC (rede virtual na nuvem), o fluxo de configuração rápida do Client VPN é automaticamente sugerido como próximo passo. Após a criação do endpoint, é possível baixar imediatamente o arquivo de configuração do cliente para se conectar através do seu aplicativo de VPN.
Aprimoramentos posteriores e evolução
Uma característica importante é a possibilidade de modificar e aprimorar a configuração do endpoint posteriormente, conforme os padrões de uso evoluem. Os usuários podem utilizar o console padrão do Client VPN ou as interfaces de programação (APIs) para realizar essas personalizações, sem necessidade de recriar o endpoint do zero.
Disponibilidade e custo
Este aprimoramento está disponível sem custo adicional em todas as regiões da AWS onde o AWS Client VPN é geralmente disponibilizado. Isso significa que toda base de usuários pode aproveitar essa simplificação imediatamente.
Como começar
Para saber mais sobre o AWS Client VPN e explorar essa nova funcionalidade, você pode:
Expansão do AWS Config: 21 novos tipos de recursos suportados
A AWS anunciou a inclusão de suporte a 21 tipos de recursos adicionais no AWS Config, seu serviço de monitoramento e conformidade. Esta expansão abrange serviços estratégicos como Amazon EC2, Amazon SageMaker e Amazon S3 Tables, proporcionando uma cobertura mais ampla e completa do ambiente de nuvem das organizações.
Com essa adição, clientes que já ativaram a gravação de todos os tipos de recursos no AWS Config receberão automaticamente o monitoramento desses novos tipos, sem necessidade de configurações manuais adicionais. Essa abordagem simplifica a gestão e garante que novos serviços sejam rastreados desde o momento em que são lançados ou atualizados.
Capacidades potencializadas
A expansão do AWS Config permite que os usuários executem tarefas críticas de governança de forma mais abrangente. Com suporte ampliado, torna-se possível descobrir recursos com maior eficiência, avaliar sua conformidade com políticas internas, auditar mudanças e aplicar ações corretivas em um espectro muito mais vasto de serviços.
Os novos tipos de recursos também estão disponíveis para uso com Config rules (regras de conformidade) e Config aggregators (agregadores de dados), oferecendo flexibilidade para criar políticas personalizadas e centralizar o monitoramento em múltiplas contas e regiões.
Novos tipos de recursos suportados
O AWS Config agora monitora os seguintes tipos de recursos em todas as regiões da AWS onde esses serviços estão disponíveis:
AWS::AppStream::AppBlockBuilder
AWS::IoT::ThingGroup
AWS::B2BI::Capability
AWS::IoTSiteWise::Asset
AWS::CleanRoomsML::TrainingDataset
AWS::Location::APIKey
AWS::CloudFront::KeyValueStore
AWS::MediaPackageV2::OriginEndpoint
AWS::Connect::SecurityProfile
AWS::PCAConnectorAD::Connector
AWS::Deadline::Monitor
AWS::Route53::DNSSEC
AWS::EC2::SubnetCidrBlock
AWS::S3Tables::TableBucketPolicy
AWS::ECR::ReplicationConfiguration
AWS::SageMaker::UserProfile
AWS::GameLift::Build
AWS::SecretsManager::ResourcePolicy
AWS::GuardDuty::MalwareProtectionPlan
AWS::SSMContacts::Contact
AWS::ImageBuilder::LifecyclePolicy
Implicações práticas
Essa expansão reflete o compromisso da AWS em oferecer visibilidade centralizada e controle contínuo sobre ambientes de nuvem em evolução. Para equipes de conformidade, segurança e operações, o suporte estendido significa menor complexidade na gestão de múltiplos pontos de monitoramento e maior confiança na auditoria completa da infraestrutura.
A disponibilidade automática em todas as regiões onde esses recursos existem reduz a barreira para adoção global consistente, permitindo que organizações com presença em múltiplos locais geográficos mantenham padrões de conformidade homogêneos.
Suporte expandido para tmpfs no Elastic Container Service
O Amazon Elastic Container Service (Amazon ECS) agora oferece suporte a montagens tmpfs (Temporary File System) para tarefas Linux executadas no AWS Fargate e em Amazon ECS Managed Instances. Até então, esse recurso estava limitado ao tipo de inicialização EC2, e sua expansão representa um avanço significativo para usuários que trabalham com containers em ambiente gerenciado.
O que é tmpfs e quando usar
As montagens tmpfs permitem a criação de sistemas de arquivos com suporte em memória RAM, sem necessidade de gravar os dados em armazenamento persistente. Os dados são armazenados exclusivamente na memória do container e expostos em um caminho que você escolhe.
Esse recurso é especialmente útil em dois cenários principais:
Workloads sensíveis ao desempenho: aplicações que precisam de acesso muito rápido a arquivos temporários, caches ou conjuntos de dados de trabalho.
Dados sensíveis à segurança: armazenamento de segredos de curta duração ou credenciais, já que os dados não persistem após a parada da tarefa.
Além disso, tmpfs permite manter o sistema de arquivos raiz do container como somente leitura (usando a configuração readonlyRootFilesystem), enquanto ainda permite que aplicações escrevam em diretórios específicos na memória.
Como implementar o recurso
Para começar a usar tmpfs, você precisa atualizar a definição de tarefa do seu container. Na configuração de definição de container, adicione um bloco linuxParameters com uma ou mais entradas de tmpfs.
Para cada montagem tmpfs, você deve especificar:
containerPath — o caminho onde o tmpfs será montado dentro do container
size — o tamanho em megabytes do sistema de arquivos
mountOptions — (opcional) opções de montagem adicionais
Você pode registrar ou atualizar definições de tarefa usando o console do Amazon ECS, AWS CLI (Interface de Linha de Comando da AWS), AWS CloudFormation ou AWS CDK (Kit de Desenvolvimento em Nuvem da AWS).
