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.
Os mecanismos de busca convencionais enfrentam limitações significativas quando precisam lidar com diferentes tipos de conteúdo. Abordagens tradicionais dependem de buscas por palavras-chave, de embeddings textuais para processamento de linguagem natural, ou de buscas híbridas, mas nenhuma consegue processar efetivamente consultas visuais. Essa fragmentação cria uma lacuna considerável entre o que o usuário quer encontrar e o que o sistema consegue recuperar.
O problema é estrutural: arquiteturas típicas separam o processamento de conteúdo visual do textual, perdendo contexto no processo. Quando um usuário faz uma busca por texto, o sistema procura nas descrições de produtos usando correspondência de palavras-chave ou embeddings textuais. Quando tenta buscar por imagens, recorre a pipelines de visão computacional separados com integração limitada ao conteúdo textual. Essa separação complexifica toda a arquitetura e degrada a experiência do usuário.
Além disso, usar múltiplos modelos de embedding exige ciclos distintos de manutenção e otimização. Consultas que envolvem diferentes modalidades não conseguem ser processadas nativamente em um único sistema. Os escores de similaridade entre conteúdo visual e textual operam em espaços matemáticos diferentes, dificultando classificações consistentes entre tipos de conteúdo. Essa separação força mapeamentos complexos que frequentemente não funcionam bem, levando as organizações a manter sistemas de embedding isolados que criam silos de dados e limitam funcionalidades.
Em e-commerce, o desafio é ainda maior. Páginas de produtos combinam imagens, descrições, especificações e às vezes vídeos de demonstração, criando um cenário de conteúdo complexo que os buscadores tradicionais não conseguem integrar adequadamente.
O conceito de embeddings multimodais
Embeddings multimodais mapeiam texto, imagens, áudio e vídeo para um espaço vetorial compartilhado onde conteúdo semanticamente similar se agrupa naturalmente. Por exemplo, quando um modelo processa a consulta textual “vestido vermelho de verão” junto com uma imagem de um vestido vermelho, ambas as entradas geram vetores próximos um do outro no espaço de embedding, refletindo sua similaridade semântica e desbloqueando recuperação de conteúdo através de diferentes modalidades.
Utilizando embeddings multimodais, é possível buscar entre diferentes tipos de conteúdo sem precisar manter sistemas separados para cada modalidade. Isso resolve o problema dos sistemas multimodais segmentados, onde organizações gerenciam múltiplos modelos de embedding que são praticamente impossíveis de integrar efetivamente porque embeddings de diferentes modalidades simplesmente não são compatíveis entre si.
Uma arquitetura de modelo único garante que a geração de embeddings seja consistente em todos os tipos de conteúdo. Conteúdo relacionado, como imagens de produtos, vídeos e suas descrições, gera embeddings similares graças aos objetivos de treinamento conjunto. As aplicações conseguem gerar embeddings para todos os tipos de conteúdo usando pontos de extremidade idênticos da API e mesmas dimensões vetoriais, reduzindo significativamente a complexidade do sistema.
Caso de uso: buscas em e-commerce
Imagine um cliente que vê uma camiseta em um programa de TV e deseja encontrar itens similares para comprar. Ele pode fotografar o item com seu telefone ou tentar descrever o que viu em texto e usar isso para buscar um produto. Os mecanismos tradicionais lidam razoavelmente bem com buscas em texto que referenciam metadados, mas não conseguem executar quando clientes desejam usar imagens para buscar ou descrever atributos visuais de um item.
Essa experiência de “da TV para o carrinho de compras” demonstra como buscas visuais e textuais trabalham juntas. O cliente envia uma foto, e o sistema a compara contra catálogos de produtos que contêm tanto imagens quanto descrições. O fluxo de trabalho multimodal em e-commerce funciona através de etapas bem definidas: o usuário inicia com uma consulta (texto, imagem ou ambas), essa entrada é transformada em um embedding através de um modelo unificado, a similaridade é calculada contra o catálogo pré-indexado, e resultados são ranqueados pela relevância.
Amazon Nova Multimodal Embeddings processa texto, documentos, imagens, vídeos e áudio através de uma única arquitetura de modelo. Disponível através de Amazon Bedrock, o modelo converte diferentes modalidades de entrada em embeddings numéricos dentro do mesmo espaço vetorial, permitindo cálculos diretos de similaridade independentemente do tipo de conteúdo.
O Amazon Nova lida com diferentes tipos de consultas de busca através do mesmo modelo, criando tanto novas capacidades de busca quanto vantagens técnicas. Independentemente de o usuário enviar imagens, inserir descrições em texto, ou combinar ambas as abordagens, o processo funciona da mesma maneira.
Capacidades de busca multimodal
Quando clientes enviam imagens, o sistema as converte em embeddings e busca contra o catálogo de produtos usando similaridade de cosseno. O resultado são produtos com características visuais similares, independentemente de como são descritos em texto. Consultas textuais funcionam da mesma forma — clientes conseguem descrever o que desejam e encontrar produtos visualmente similares, mesmo quando as descrições de produtos usam palavras diferentes.
Se o cliente envia uma imagem com uma descrição em texto, o sistema processa ambas as entradas através do mesmo modelo de embedding para escoring de similaridade unificado. O sistema também extrai atributos de produtos de imagens automaticamente através de marcação automática de produtos, suportando geração de tags semânticas que vai além da categorização manual.
Vantagens técnicas
A arquitetura unificada oferece vários benefícios sobre embeddings de texto e imagem separados. O design de modelo único e espaço semântico compartilhado desbloqueiam casos de uso novos que não são alcançáveis gerenciando múltiplos sistemas de embedding. Aplicações geram embeddings para todos os tipos de conteúdo usando os mesmos pontos de extremidade da API e dimensões vetoriais.
Um modelo único lida com todas as cinco modalidades, então conteúdo relacionado, como imagens de produtos e suas descrições, produz embeddings similares. É possível calcular distâncias entre qualquer combinação de texto, imagens, áudio e vídeo para medir o quão similares eles são.
O modelo Matryoshka representation learning oferece suporte a múltiplas dimensões de embedding: 3072, 1024, 384 e 256. O aprendizado de embedding Matryoshka armazena as informações mais importantes nas primeiras dimensões e detalhes menos críticos em dimensões posteriores. É possível truncar a partir do final para reduzir espaço de armazenamento mantendo precisão para o caso de uso específico.
Três componentes principais são necessários para construir essa abordagem: geração de embeddings, armazenamento vetorial e busca por similaridade. Catálogos de produtos passam por pré-processamento para gerar embeddings para todos os tipos de conteúdo. O processamento de consultas converte entradas do usuário em embeddings usando o mesmo modelo. A busca por similaridade compara embeddings de consultas contra embeddings de produtos armazenados.
Sistemas de armazenamento vetorial precisam suportar as dimensões de embedding escolhidas e fornecer operações eficientes de busca por similaridade. As opções incluem bancos de dados vetoriais específicos para esse propósito, bancos de dados tradicionais com extensões vetoriais, ou serviços vetoriais centrados em nuvem como Amazon S3 Vectors, um recurso de Amazon S3 que oferece suporte nativo para armazenar e consultar embeddings vetoriais diretamente dentro de S3.
Para usar a funcionalidade efetivamente, alguns aspectos-chave são necessários para essa implementação. Uma conta AWS com permissões de acesso ao Amazon Bedrock para o modelo Amazon Nova Multimodal Embeddings. Os serviços adicionais necessários incluem S3 Vectors. Um notebook está disponível no repositório de exemplos do Amazon Nova para seguir passo a passo.
Configuração de bucket e índice vetorial
O primeiro passo é criar a infraestrutura de armazenamento vetorial para embeddings. S3 Vectors é um serviço gerenciado para armazenar e consultar vetores de alta dimensionalidade em escala. O bucket atua como contêiner para os dados vetoriais, enquanto o índice define a estrutura e características de busca. O índice é configurado com métrica de distância de cosseno, que mede similaridade baseada na direção do vetor em vez de sua magnitude, tornando-o ideal para embeddings normalizados de modelos fornecidos por serviços como Amazon Nova Multimodal Embeddings.
O próximo passo é gerar embeddings. Tanto imagens de produtos quanto descrições textuais requerem geração e armazenamento de embeddings com metadados apropriados para recuperação. A API Amazon Nova Embeddings processa cada modalidade independentemente, convertendo descrições de produtos e imagens de produtos em vetores de 1024 dimensões. Esses vetores vivem em um espaço semântico unificado, o que significa que um embedding de texto e um embedding de imagem do mesmo produto estarão geometricamente próximos um do outro.
O código a seguir gera os embeddings e envia os dados para o armazenamento vetorial:
# Gerar embeddings e fazer upload para Amazon S3 Vectors
def get_product_text(product):
name = product.get('item_name', [{}])[0].get('value', '') if isinstance(product.get('item_name'), list) else str(product.get('item_name', ''))
brand = product.get('brand', [{}])[0].get('value', '') if product.get('brand') else ''
return f"{name}. {brand}".strip()
vectors_to_upload = []
batch_size = 10
catalog = []
for product in tqdm(sampled_products, desc="Processing products"):
img_path = get_image_path(product)
text = get_product_text(product)
product_id = product.get('item_id', str(len(catalog)))
with open(img_path, 'rb') as f:
img_bytes = f.read()
# Gerar embeddings
text_emb = embeddings.embed_text(text)
image_emb = embeddings.embed_image(img_bytes)
# Armazenar no catálogo local
catalog.append({
'text': text,
'image_path': str(img_path),
'text_emb': text_emb,
'image_emb': image_emb,
'product_id': product_id
})
# Preparar vetores para upload em S3
vectors_to_upload.extend([
{
"key": f"text-{product_id}",
"data": {"float32": text_emb},
"metadata": {"product_id": product_id, "text": text, "image_path": str(img_path), "type": "text"}
},
{
"key": f"image-{product_id}",
"data": {"float32": image_emb},
"metadata": {"product_id": product_id, "text": text, "image_path": str(img_path), "type": "image"}
},
{
"key": f"combined-{product_id}",
"data": {"float32": np.mean([text_emb, image_emb], axis=0).tolist()},
"metadata": {"product_id": product_id, "text": text, "image_path": str(img_path), "type": "combined"}
}
])
# Upload em lotes
if len(vectors_to_upload) >= batch_size * 3:
s3vectors.put_vectors(vectorBucketName=s3vector_bucket, indexName=s3vector_index, vectors=vectors_to_upload)
vectors_to_upload = []
# Upload dos vetores restantes
if vectors_to_upload:
s3vectors.put_vectors(vectorBucketName=s3vector_bucket, indexName=s3vector_index, vectors=vectors_to_upload)
Processamento de consultas
Esse código lida com entrada do cliente através da API. Consultas de texto, uploads de imagens, ou combinações se convertem no mesmo formato vetorial usado para o catálogo de produtos. Para consultas multimodais que combinam texto e imagem, é aplicada fusão por média para criar um vetor de consulta único que captura informações de ambas as modalidades.
def search_s3(query=None, query_image=None, query_type='text', search_mode='combined', top_k=5):
"""
Buscar usando S3 Vectors
query_type: 'text', 'image', ou 'both'
search_mode: 'text', 'image', ou 'combined'
"""
# Obter embedding de consulta
if query_type == 'both':
text_emb = embeddings.embed_text(query)
with open(query_image, 'rb') as f:
image_emb = embeddings.embed_image(f.read())
query_emb = np.mean([text_emb, image_emb], axis=0).tolist()
query_image_path = query_image
elif query_type == 'text':
query_emb = embeddings.embed_text(query)
query_image_path = None
else:
with open(query_image, 'rb') as f:
query_emb = embeddings.embed_image(f.read())
query_image_path = query_image
Busca por similaridade vetorial
O próximo passo é adicionar recuperação multimodal usando a API de consulta S3 Vectors. O sistema encontra a correspondência de embedding mais próxima à consulta, independentemente se foi texto ou imagem. É usado cosseno como métrica de distância, que mede o ângulo entre vetores em vez de sua distância absoluta. Essa abordagem funciona bem para embeddings normalizados e é eficiente em recursos, tornando-a adequada para catálogos grandes quando associada a algoritmos de vizinho aproximado mais próximo.
Os escores de similaridade computados por S3 Vectors fornecem o mecanismo de classificação. A similaridade de cosseno entre embeddings de consulta e catálogo determina a ordem de resultados, com escores mais altos indicando correspondências melhores. Em sistemas de produção, normalmente seria coletado dados de cliques e julgamentos de relevância para validar que a classificação se correlaciona com comportamento real do usuário. S3 Vectors retorna valores de distância que são convertidos em escores de similaridade (1 – distância) para interpretação intuitiva onde valores mais altos indicam correspondências mais próximas.
# Extrair e classificar resultados por similaridade
ranked_results = []
for result in response['vectors']:
metadata = result['metadata']
distance = result.get('distance', 0)
similarity = 1 - distance # Converter distância em escore de similaridade
ranked_results.append({
'product_id': metadata['product_id'],
'text': metadata['text'],
'image_path': metadata['image_path'],
'similarity': similarity,
'distance': distance
})
# Resultados são classificados por S3 Vectors (melhores correspondências primeiro)
return ranked_results
Por que isso importa
Amazon Nova Multimodal Embeddings resolve o problema central de busca multimodal usando um único modelo em vez de gerenciar sistemas separados. É possível usar o Amazon Nova Multimodal Embeddings para construir buscas que funcionam independentemente de clientes enviarem imagens, inserirem descrições em texto, ou combinarem ambas as abordagens.
A implementação é direta usando as APIs do Amazon Bedrock, e as dimensões de embedding Matryoshka permitem otimizar para requisitos específicos de precisão e custo. As dimensões de embedding Matryoshka mantêm qualidade de embedding em diferentes dimensões com degradação de desempenho previsível, permitindo que aplicações se otimizem para casos de uso específicos.
Próximos passos
Amazon Nova Multimodal Embeddings está disponível em Amazon Bedrock. Consulte Usando Nova Embeddings para referências de API, exemplos de código e padrões de integração para arquiteturas comuns. O repositório de exemplos AWS contém exemplos de implementação para embeddings multimodais.
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 anunciou a expansão do Amazon Quick, sua plataforma de workspace alimentada por inteligência artificial que funciona como um colega de trabalho baseado em agentes. O serviço foi desenvolvido para ajudar organizações a obter respostas a partir de seus dados empresariais e a passar rapidamente de insights para ações concretas.
O desafio da fragmentação de ferramentas
À medida que as organizações adotam agentes de IA e trabalham com ferramentas empresariais tradicionais — como sistemas de CRM, suporte ao cliente, ferramentas de colaboração e outras — os usuários enfrentam uma realidade fragmentada. Precisam alternar constantemente entre diferentes interfaces, repetir informações de contexto e, muitas vezes, compilar manualmente resultados de diversos sistemas. Tudo isso gera perda de tempo e sobrecarga cognitiva.
O Amazon Quick foi construído justamente para resolver esse problema, permitindo que os usuários trabalhem com agentes de terceiros e ferramentas empresariais a partir de uma única interface unificada.
Novos agentes de terceiros disponíveis
Na nova expansão, o Amazon Quick agora permite invocar agentes especializados de três principais fornecedores: Box, Canva e PagerDuty. Isso abre possibilidades para automação e consulta de dados que antes exigiam mudanças de contexto. Por exemplo, um usuário pode extrair insights sobre incidentes diretamente do PagerDuty, gerar uma apresentação usando a Canva e consultar documentos armazenados no Box — tudo dentro da mesma sessão no Quick.
Expansão da biblioteca de ações integradas
Além dos agentes de terceiros, o Amazon Quick expandiu significativamente suas ações integradas. O serviço agora inclui integrações nativas com GitHub, Notion, Canva, Box, Linear, Hugging Face, Monday.com, HubSpot, Intercom e outras plataformas. Essa expansão permite que usuários executem tarefas como criar issues no GitHub, resumir notas de reuniões no Notion, gerenciar seu CRM e muito mais — sem sair do Quick.
Conectando aplicações além das integrações prontas
Para cenários que vão além das integrações pré-configuradas, o Amazon Quick oferece aos clientes a capacidade de aproveitar conectores customizados baseados no Model Context Protocol (Protocolo de Contexto de Modelo — MCP) e OpenAPI. Esses padrões abertos permitem conectar o Quick a milhares de aplicações adicionais, oferecendo flexibilidade para ambientes corporativos complexos.
Disponibilidade
Todos esses recursos estão disponíveis em todos os Regiões da AWS onde o Amazon Quick já opera. Para explorar as opções de integração em detalhes, o serviço oferece documentação técnica abrangente.
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).
A AWS anunciou que o Amazon MQ agora suporta autenticação baseada em HTTP (Protocolo de Transferência de Hipertexto) para brokers RabbitMQ. Essa funcionalidade permite que os brokers realizem validações de identidade (autenticação) e controle de permissões (autorização) através de requisições diretas a um servidor HTTP.
Como funciona a autenticação HTTP
O novo plugin de autenticação pode ser configurado em brokers que executam RabbitMQ 4.2 ou versões superiores no Amazon MQ. A habilitação dessa funcionalidade é feita mediante alterações no arquivo de configuração associado ao broker, permitindo maior flexibilidade no gerenciamento de credenciais e permissões de acesso.
Como implementar
Para começar a utilizar autenticação e autorização baseadas em HTTP no Amazon MQ, basta seguir alguns passos simples:
Selecionar RabbitMQ 4.2 ao criar um novo broker
Utilizar o tipo de instância m7g
Realizar a criação através do console de gerenciamento da AWS, AWS CLI (Interface de Linha de Comando) ou AWS SDKs (Kits de Desenvolvimento)
Editar o arquivo de configuração associado para habilitar o plugin
Documentação e recursos
Para aprofundar o conhecimento sobre essa funcionalidade, a AWS disponibiliza informações técnicas detalhadas. Consulte as notas de lançamento do Amazon MQ e o guia de desenvolvedor do Amazon MQ para obter instruções completas sobre como configurar e utilizar o plugin.
Disponibilidade
Esse recurso está disponível em todas as regiões onde o Amazon MQ com RabbitMQ 4 atualmente funciona. Isso significa que desenvolvimentos brasileiros e em qualquer outra localidade geográfica onde a AWS opera podem aproveitar essa capacidade para fortalecer seu sistema de autenticação e autorização.
