Category: Uncategorized

Conformidade FIPS em Amazon ECS Managed Instances

A partir de março de 2026, a AWS disponibilizou suporte para workloads compatíveis com FIPS (Padrão Federal de Processamento de Informações) em Amazon ECS Managed Instances nas regiões AWS GovCloud (US). Este recurso permite que clientes com requisitos de conformidade federal executem cargas de trabalho utilizando módulos criptográficos validados por FIPS em um amplo espectro de tipos de instâncias.

O que é FIPS e por que importa

FIPS é um padrão de segurança conjunto entre Estados Unidos e Canadá que especifica os requisitos de segurança para módulos criptográficos que protegem informações sensíveis. Para organizações que trabalham com dados governamentais ou operações que exigem conformidade com regulamentações federais, a certificação FIPS é essencial.

Como funciona a conformidade nas regiões GovCloud

Nas regiões AWS GovCloud (US), Amazon ECS Managed Instances habilita automaticamente a conformidade FIPS por padrão. O mecanismo de funcionamento envolve:

• Comunicação através de endpoints compatíveis com FIPS
• Utilização de módulos criptográficos apropriadamente configurados
• Inicialização do kernel subjacente em modo FIPS

Tipos de instâncias suportadas

Clientes com requisitos de conformidade federal podem executar workloads com módulos criptográficos validados por FIPS em uma variedade de tipos de instância, incluindo:

• Instâncias baseadas em Graviton
• Instâncias aceleradas por GPU
• Instâncias otimizadas para rede
• Instâncias de desempenho variável (burstable performance)

Como começar

Para iniciar o uso de ECS Managed Instances, é possível utilizar diversos caminhos:

• AWS Console (interface web)
• Amazon ECS MCP Server
• ECS Express Mode
• Ferramentas de infraestrutura como código (IaC) de sua preferência

Você pode habilitar o recurso em um novo cluster Amazon ECS ou em um cluster existente. Vale observar que será cobrado o gerenciamento da computação provisionada, além dos custos regulares de Amazon EC2.

Próximas etapas

Para aprender mais sobre FIPS, consulte os materiais disponibilizados pela AWS sobre FIPS na AWS e conformidade FIPS para AWS Fargate. Para informações completas sobre ECS Managed Instances, você pode acessar a página do recurso, a documentação técnica e o blog de lançamento da AWS.

Fonte

Amazon ECS Managed Instances now supports FIPS-certified workloads on Graviton and GPU accelerated instances in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ecs-mi-supports-fips-graviron-gpu/)

Novos recursos de segurança e conformidade no AgentCore

A AWS anunciou expansões significativas no Amazon Bedrock AgentCore, seu serviço para executar agentes de IA autônomos. A empresa adicionou suporte a políticas do Chrome Enterprise e certificados customizados de Autoridade Certificadora (AC), recursos essenciais para organizações com requisitos rigorosos de segurança e infraestrutura interna complexa.

Políticas do Chrome para controle granular

O novo suporte a políticas do Chrome Enterprise no AgentCore Browser oferece controle sobre mais de 100 políticas configuráveis. Essas políticas abrangem múltiplas dimensões de segurança: comportamento do navegador, filtragem de URLs, configurações de conteúdo e outras funcionalidades.

Alguns exemplos práticos de uso incluem:

• Restringir agentes a URLs específicas para operações em modo quiosque
• Desabilitar gerenciadores de senha e downloads em tarefas de entrada de dados
• Implementar listas de bloqueio de URLs para atender conformidade regulatória

Essa abordagem permite que as organizações forçem requisitos de conformidade específicos enquanto permitem que agentes de IA operem autonomamente dentro de limites bem definidos.

Suporte a Autoridades Certificadoras customizadas

O novo suporte a certificados de AC customizados resolve um desafio comum em ambientes corporativos: a integração com serviços internos que utilizam certificados SSL assinados pela Autoridade Certificadora interna da organização.

Com esse recurso, agentes de IA podem se conectar perfeitamente a serviços internos como Artifactory, Jira e portais financeiros, além de trabalhar com proxies corporativos que realizam interceptação TLS. Essa capacidade é fundamental para manter a segurança sem fragmentar a operação de agentes autônomos em ambientes corporativos complexos.

Disponibilidade global

Os novos recursos estão disponíveis em todas as 14 regiões da AWS onde o Amazon Bedrock AgentCore Browser e Code Interpreter operam:

• US East (N. Virginia), US East (Ohio), US West (Oregon)
• Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm)
• Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul)
• Canada (Central)

Próximos passos

Organizações interessadas em implementar essas funcionalidades podem consultar a documentação do AgentCore Browser para detalhes técnicos de configuração e casos de uso específicos.

Fonte

Amazon Bedrock AgentCore adds support for Chrome policies and custom root CA (https://aws.amazon.com/about-aws/whats-new/2026/03/agentcore-browser-policies-root-ca/)

Firewall Manager agora disponível na Nova Zelândia

A AWS anunciou a disponibilidade do Firewall Manager na região Asia Pacific (Nova Zelândia). Essa expansão reforça o compromisso da empresa em oferecer soluções de segurança robustas em diferentes geografias, permitindo que mais organizações acessem ferramentas centralizadas de gerenciamento de segurança.

O que é o Firewall Manager

O Firewall Manager é uma solução projetada para auxiliar administradores de segurança em nuvem e engenheiros de confiabilidade de site (SRE) a proteger suas aplicações. Seu principal diferencial é reduzir significativamente a sobrecarga operacional associada à configuração manual e ao gerenciamento de regras de segurança. Em vez de implementar políticas individualmente em cada recurso, os profissionais de segurança podem criar e manter políticas centralizadas.

Capacidades e benefícios

Ao trabalhar com o Firewall Manager, os clientes conseguem implementar políticas de defesa em profundidade que cobrem toda a gama de serviços de segurança disponíveis na AWS. Isso é especialmente valioso para organizações que hospedam suas aplicações e cargas de trabalho em regiões como a de Taipei e agora também em Nova Zelândia.

Uma das aplicações mais comuns do Firewall Manager é a criação e manutenção de políticas de segurança integradas com o AWS WAF (Web Application Firewall). Dessa forma, os clientes podem estabelecer ativos protegidos de forma padronizada e escalável.

Como começar

Para organizações interessadas em implementar o Firewall Manager em Nova Zelândia, a AWS oferece documentação técnica detalhada. Consulte a documentação do Firewall Manager para entender melhor como a ferramenta funciona e os passos necessários para implementação.

Também é recomendado verificar a tabela de regiões da AWS para visualizar a lista completa de regiões onde o Firewall Manager está disponível atualmente, facilitando o planejamento de arquiteturas multi-região.

Para conhecer em detalhes os recursos, funcionalidades avançadas e modelos de preço do Firewall Manager, acesse o site do Firewall Manager.

Fonte

AWS Firewall Manager launches in AWS Asia Pacific (New Zealand) Region (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-firewall-manager-launches-ap-nz/)

Entendendo os tipos de políticas de IAM

O controle de acesso na AWS é baseado na criação e anexação de políticas a entidades do AWS Identity and Access Management (IAM) — como funções (roles), usuários ou grupos de usuários — ou diretamente aos recursos. A AWS avalia essas políticas quando um principal do IAM faz uma requisição, como enviar um objeto para um bucket do Amazon S3. As permissões definidas determinam se a requisição é permitida ou negada.

Embora o IAM funcione principalmente no nível de uma conta AWS individual, organizações com múltiplas contas podem estender esses controles através do AWS Organizations, que oferece tipos de políticas adicionais para aplicar padrões de governança e segurança em toda a estrutura organizacional. Isso permite agrupar contas em unidades organizacionais (OUs) e aplicar controles baseados em políticas.

Compreender qual tipo de política usar — e quem na sua organização deve possuir e gerenciar cada uma — é essencial para evitar gargalos centralizados e manter um modelo de segurança flexível mas controlado.

Os principais tipos de políticas

Políticas de Controle de Serviço (SCPs)

As Políticas de Controle de Serviço (SCPs) são um recurso do AWS Organizations. Elas especificam as permissões máximas para uma organização, unidade organizacional ou conta individual, funcionando como guardrails de segurança em escala ampla.

As SCPs não concedem acesso diretamente; em vez disso, limitam o que pode ser feito. Sua principal função é impor invariantes de segurança — objetivos ou configurações de controle que você aplica a múltiplas contas ou a toda a organização. Por exemplo, você pode usar uma SCP para impedir que contas membros saiam da organização ou garantir que recursos AWS sejam implantados apenas em regiões específicas.

As SCPs são ideais para aplicar controles amplos que atravessam toda a sua infraestrutura de nuvem, sendo gerenciadas por equipes centrais de segurança e governança.

Políticas de Controle de Recursos (RCPs)

As Políticas de Controle de Recursos (RCPs) são outro recurso do AWS Organizations que permite gerenciar permissões de forma centralizada, mas com foco nos recursos. As RCPs estabelecem as permissões máximas disponíveis para recursos em sua organização, ajudando a garantir que os recursos nas suas contas permaneçam dentro das diretrizes de controle de acesso da sua organização.

As RCPs são tipicamente utilizadas para implementar controles de perímetro de dados, prevenindo compartilhamento acidental fora da organização, e para controlar padrões de acesso entre contas. Elas também adicionam uma camada de proteção extra para recursos sensíveis, como buckets S3 que armazenam dados confidenciais.

Uma diferença importante: enquanto as SCPs são focadas no principal (qual usuário ou função pode fazer algo), as RCPs são focadas no recurso (quem pode acessar este recurso e sob quais condições). Para explorar melhor essas distinções, veja casos de uso gerais para SCPs e RCPs.

Limites de Permissões

Os Limites de Permissões são um recurso avançado do IAM que define o máximo que uma política baseada em identidade pode conceder a um principal. Quando você estabelece um limite para um principal, ele pode realizar apenas as ações permitidas tanto pela sua política baseada em identidade quanto pelo limite.

Como as SCPs, os limites de permissões não concedem acesso diretamente — eles atuam como guardrails. São frequentemente usados para delegar a criação de principais do IAM, permitindo que outras equipes criem novos usuários e funções, mas limitando quais permissões podem ser concedidas a esses novos principais.

Políticas Baseadas em Identidade

As Políticas Baseadas em Identidade são documentos de política anexados a um principal (funções, usuários e grupos) para controlar quais ações podem ser executadas, em quais recursos e sob quais condições. Elas se dividem em três categorias:

• Políticas gerenciadas pela AWS: políticas reutilizáveis criadas e mantidas pela AWS, que servem como ponto de partida para políticas específicas da sua organização.
• Políticas gerenciadas pelo cliente: políticas reutilizáveis criadas por você que podem ser anexadas a múltiplas identidades, úteis quando vários principals têm os mesmos requisitos de acesso.
• Políticas inline: políticas anexadas a um único principal, ideais quando você quer criar permissões com privilégio mínimo específicas para um principal em particular.

Políticas Baseadas em Recursos

As Políticas Baseadas em Recursos são anexadas a um recurso como um bucket S3. Elas concedem permissão a um principal específico para executar ações específicas naquele recurso e definem sob quais condições isso se aplica. Ao contrário de muitos outros tipos de política, as baseadas em recursos são sempre inline.

Embora sejam opcionais para muitas cargas de trabalho que não abrangem múltiplas contas, existem exceções importantes. O AWS Key Management Service (AWS KMS) e as políticas de confiança de funções do IAM exigem políticas baseadas em recursos mesmo quando o principal e o recurso estão na mesma conta, como camada extra de proteção.

As políticas baseadas em recursos são mais comumente usadas para conceder acesso entre contas, para permitir que serviços AWS acessem seus recursos (como quando o AWS CloudTrail precisa de permissão explícita para escrever em um bucket S3), e para adicionar camadas de proteção extra em recursos com dados sensíveis.

Implementando diferentes tipos de políticas: um exemplo prático

Para ilustrar como esses tipos de políticas trabalham juntos, consideremos uma empresa fictícia chamada Example Corp que utiliza uma estratégia multi-conta, com cada aplicação rodando em sua própria conta AWS. A aplicação está em execução em um Amazon EC2 e precisa ler e escrever em um bucket S3 na mesma conta, além de ler arquivos de um bucket em uma conta diferente.

Três equipes participam deste exemplo: a Equipe Central de Nuvem (responsável pela segurança geral), a Equipe de Aplicação (que constrói e executa a aplicação) e a Equipe de Data Lake (que gerencia a conta de data lake). Cada equipe possui responsabilidades claras sobre qual tipo de política gerencia.

Exemplo 1: Políticas de Controle de Serviço (SCP)

A Equipe Central de Nuvem implementa SCPs na raiz da organização para aplicar dois requisitos de segurança em todas as contas: todas as chamadas de API devem ser criptografadas em trânsito e nenhuma conta pode deixar a organização por conta própria. Essas SCPs atuam como guardrails organizacionais que evitam desvios de segurança em qualquer ponto da infraestrutura.

Exemplo 2: Políticas de Controle de Recursos (RCP)

A Equipe Central de Nuvem também aplica RCPs para impor três controles adicionais em recursos S3: exigir TLS versão 1.2 ou superior, usar criptografia de objetos com AWS KMS, e negar acesso de contas fora da organização. Essas políticas implementam um perímetro de dados em toda a organização, protegendo dados sensíveis de compartilhamento acidental.

Exemplo 3: Limites de Permissões

A Equipe de Aplicação implanta através de um pipeline de integração contínua/implantação contínua (CI/CD). Para evitar que a Equipe Central fique sobrecarregada de requisições, o pipeline recebe permissões amplas para criar recursos, mas as funções do IAM que cria devem ter um limite de permissões anexado. Esse limite restringe quais ações essas novas funções podem executar, mesmo que o pipeline tentasse dar permissões muito amplas.

O limite típico permite ações de acesso a dados em Amazon SQS, S3 e logs, mas não permite ações de modificação de infraestrutura. Quando a Example Corp adota novos serviços AWS, a Equipe Central atualiza centralmente esse limite de permissões.

Exemplo 4: Políticas Baseadas em Identidade

A Equipe Central de Nuvem cria três funções baseline na conta de aplicação: uma para o pipeline CI/CD (com acesso amplo para criar recursos), uma para a própria Equipe Central (com acesso somente leitura a todos os recursos, com um processo de elevação temporária quando necessário), e uma para desenvolvedores da Equipe de Aplicação (com acesso somente leitura limitado a EC2, S3, SQS, CloudFormation e CloudWatch).

A função do pipeline CI/CD tem permissões para criar novas funções do IAM dentro de caminhos específicos, e pode anexar políticas específicas a essas funções, mas apenas políticas dentro de caminhos aprovados. Isso impede que o pipeline modifique funções mais privilegiadas ou se auto-escalone.

A Equipe de Aplicação cria suas próprias políticas baseadas em identidade para a função que roda na instância EC2, respeitando o limite de permissões. Se a política tentasse incluir ações não permitidas pelo limite, essas ações seriam negadas.

Exemplo 5: Políticas Baseadas em Recursos

O único recurso que requer uma política baseada em recurso neste exemplo é o bucket S3 na conta external (conta de data lake). Essa política, gerenciada pela Equipe de Data Lake, especifica explicitamente qual função em qual conta externa pode fazer quê. Isso garante que a Equipe de Data Lake mantém total controle sobre quem acessa seus dados, mesmo que a Equipe de Aplicação tivesse permissões mais amplas.

Em cenários de acesso entre contas, tanto a política baseada em identidade quanto a política baseada em recurso precisam permitir a ação para que o acesso seja concedido. O bucket na conta de aplicação não precisa de uma política baseada em recurso, pois o acesso é concedido pela política baseada em identidade.

Estrutura de propriedade de políticas

Um aspecto crítico da implementação bem-sucedida é deixar claro quem é responsável por cada tipo de política. Na Example Corp, a distribuição é:

• SCPs e RCPs: Equipe Central de Nuvem (aplicadas na raiz da organização)
• Limites de Permissões: Equipe Central de Nuvem (aplicados ao pipeline)
• Políticas Baseadas em Identidade para acesso de equipes: Equipe Central de Nuvem
• Políticas Baseadas em Identidade para aplicações: Equipe de Aplicação (dentro dos limites)
• Políticas Baseadas em Recursos: Equipe proprietária do recurso (Equipe de Data Lake)

Essa distribuição evita que a Equipe Central se torne um gargalo, ao mesmo tempo em que mantém guardrails de segurança centralizados.

Validação e boas práticas

Ao implementar políticas de IAM, a AWS oferece ferramentas para garantir qualidade. A validação de políticas no AWS IAM Access Analyzer permite validar suas políticas contra a gramática do IAM e melhores práticas, evitando configurações que possam causar problemas de segurança ou acesso.

Para explorar mais detalhes sobre implementações como essa, consulte o repositório how-and-when-to-use-aws-iam-policy-blog-samples, que demonstra uma implementação de exemplo usando AWS CodePipeline.

Conclusão

A segurança robusta em ambientes AWS multi-conta requer uma abordagem em camadas, usando diferentes tipos de políticas em conjunto. As SCPs e RCPs fornecem guardrails organizacionais, os limites de permissões delegam autoridade sem perder controle, e as políticas baseadas em identidade e recurso permitem acesso fino e controlado.

Nem todas as organizações precisam usar todos esses tipos de políticas, e os requisitos podem variar entre ambientes de produção e sandbox. O importante é compreender quando cada tipo é apropriado e estruturar claramente a propriedade das políticas. Com essa abordagem, você consegue um modelo de segurança que é ao mesmo tempo flexível e seguro, permitindo que equipes se movam rapidamente dentro de guardrails bem definidos.

Para mais informações, consulte o tópico AWS Identity and Access Management re:Post ou entre em contato com o AWS Support.

Fonte

IAM policy types: How and when to use them (https://aws.amazon.com/blogs/security/iam-policy-types-how-and-when-to-use-them/)

Gerenciamento de Credenciais Simplificado no AWS DataSync

A AWS anunciou uma expansão significativa no AWS DataSync: agora o serviço oferece suporte completo ao AWS Secrets Manager para gerenciamento de credenciais em todos os tipos de locais. Até então, essa integração era limitada a apenas um subconjunto de tipos de local, o que obrigava os usuários a fornecer credenciais diretamente pela API ou console do DataSync.

Com essa evolução, tornou-se possível centralizar o gerenciamento de credenciais de todas as transferências de dados em um único lugar — o Secrets Manager — proporcionando uma abordagem consistente e unificada.

Cobertura Expandida de Tipos de Local

A novidade cobre todos os principais sistemas de armazenamento distribuído e de arquivos suportados pelo DataSync, entre eles:

• HDFS (Hadoop Distributed File System)
• Amazon FSx for Windows File Server
• Amazon FSx for NetApp ONTAP

Segurança e Governança Aprimoradas

Um dos diferenciais dessa atualização é a possibilidade de criptografar credenciais com chaves AWS KMS personalizadas, em vez de depender apenas da chave padrão de propriedade da AWS. Isso permite que as organizações atendessem melhor aos seus requisitos de segurança e às políticas de governança interna.

Todos os segredos são armazenados na sua própria conta, o que garante autonomia total para atualizar credenciais conforme necessário, independentemente do serviço DataSync.

Duas Abordagens de Gerenciamento

A AWS oferece flexibilidade ao disponibilizar dois modelos de gerenciamento de credenciais:

• Controle manual: forneça um ARN de segredo referenciando credenciais que você gerencia no Secrets Manager, mantendo controle total sobre rotação, auditoria e políticas de acesso.
• Gerenciamento automático: o DataSync pode criar e gerenciar automaticamente os segredos em seu nome, simplificando o processo.

Disponibilidade e Próximos Passos

Essa capacidade está disponível na maioria das regiões AWS onde o DataSync é oferecido. Para consultar a lista completa de regiões suportadas, visite a ferramenta de Capacidades da AWS no Builder Center.

Para começar a usar esse recurso, acesse o console do AWS DataSync. Detalhes técnicos adicionais estão disponíveis na documentação sobre gerenciamento de credenciais com AWS Secrets Manager.

Fonte

AWS DataSync now supports AWS Secrets Manager for all location types (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-datasync-secrets-manager/)

Permissões federadas do Redshift com alcance regional

A AWS anunciou uma expansão importante no Redshift: agora é possível utilizar permissões federadas com o IAM Identity Center (Centro de Identidade IAM) em múltiplas regiões AWS. Esta capacidade permite que organizações estendam o IdC da região primária para regiões adicionais, garantindo melhor desempenho através da proximidade com usuários e aumentando a confiabilidade operacional.

Simplificação da administração em novas regiões

Quando uma nova região é adicionada no IdC, é possível criar aplicações Redshift e Lake Formation Identity Center naquela região sem necessidade de replicar identidades da região primária. Este é um ponto importante: a arquitetura permite que você aproveite as identidades corporativas já existentes no IdC para consultar dados em warehouses localizados na nova região, eliminando redundâncias administrativas.

Controles de acesso granulares e automatizados

Um dos principais diferenciais desta solução é a aplicação automática de controles de acesso em diferentes níveis. Independentemente de qual warehouse seja utilizado para executar consultas, os controles de:

• Nível de linha
• Nível de coluna
• Mascaramento de dados

…são aplicados automaticamente em todas as operações, garantindo conformidade com políticas de acesso granular definidas centralmente. Isto significa que a segurança e governança de dados são mantidas consistentes entre regiões, sem depender de configurações repetidas.

Integração com ferramentas de consulta e BI

A AWS também expandiu as opções de autenticação. Você pode acessar o Amazon Redshift com single sign-on (SSO) nestas novas regiões através de:

• Amazon QuickSight
• Amazon Redshift Query Editor
• Ferramentas SQL de terceiros

Esta integração oferece uma experiência de usuário unificada, onde a autenticação corporativa via IdC funciona consistentemente em diferentes interfaces de acesso.

Como começar

Para iniciar a implementação de permissões federadas no Redshift utilizando IdC, a AWS disponibiliza recursos técnicos incluindo um artigo detalhado sobre como escalar permissões granulares entre warehouses e a documentação técnica do Redshift sobre este recurso.

Para estender o suporte do IdC em múltiplas regiões, consulte também a documentação do Identity Center, a documentação completa do Redshift sobre controle de acesso, a documentação do Lake Formation para casos de integração com este serviço, e verifique a disponibilidade regional do recurso em sua zona geográfica.

Fonte

Amazon Redshift supports federated permissions with IAM Identity Center in multiple AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/03/redshift-federated-permissions-idc-mrr/)

Conformidade com Residência de Dados em Ambientes Globais

Organizações distribuídas em múltiplas geografias enfrentam desafios significativos para manter seus dados dentro de limites específicos. Regulamentações como a Lei Geral de Proteção de Dados (LGPD) no Brasil, o Regulamento Geral de Proteção de Dados (GDPR) na Europa, leis de soberania de dados específicas de cada país e políticas de conformidade internas criam um cenário complexo que exige soluções técnicas robustas.

A Amazon Quick com extensões do Microsoft 365 oferece suporte a roteamento regional, permitindo que organizações mantenham dados em seus locais geográficos apropriados. A plataforma suporta implantações em múltiplas regiões da AWS, direcionando usuários automaticamente para recursos do Amazon Quick específicos de cada região — como agentes de chat, fluxos automatizados, bases de conhecimento e outros componentes.

Setores altamente regulados, como serviços financeiros, saúde, energia e telecomunicações, adotam esse padrão com frequência para garantir que informações sensíveis permaneçam dentro de fronteiras geográficas específicas. A integração com o Microsoft Teams oferece uma experiência contínua para usuários corporativos que já trabalham dentro do ecossistema Microsoft 365.

Visão Geral da Solução

Quando o Amazon Quick é integrado a aplicações Microsoft 365, como o Microsoft Teams, os usuários precisam se autenticar e conectar aos recursos regionais apropriados do Amazon Quick. Este processo garante que cada usuário acesse apenas os agentes de chat e recursos construídos na região AWS designada para sua localização geográfica.

A solução apresentada aqui utiliza um exemplo prático: uma organização global fictícia (MyCompany) com matriz europeia acessando o Amazon Quick na região Europa (Irlanda) e uma filial nos EUA usando a região Leste dos EUA (N. Virgínia). Uma única conta do Amazon Quick mantém agentes de chat específicos por região, cada um contendo informações corporativas localizadas.

Para implementar o roteamento regional, é necessário configurar o AWS IAM Identity Center com um emissor de token confiável para autenticação entre sistemas. Esta solução utiliza o Microsoft Entra ID para controle de acesso baseado em grupos, demonstrando como organizações podem rotear automaticamente usuários para suas regiões AWS apropriadas. A extensão do Amazon Quick para Microsoft Teams é o ponto de integração principal neste cenário.

A arquitetura integra o Microsoft Entra ID com o IAM Identity Center, automatizando o roteamento de usuários entre múltiplas regiões AWS. Ao usar a associação de grupos do Microsoft Entra ID para direcionar usuários a suas implantações regionais designadas do Amazon Quick, organizações mantêm a residência de dados dentro de limites geográficos específicos enquanto oferecem uma experiência consistente a sua força de trabalho global.

Processo de Implementação

A implementação segue uma abordagem faseada que começa com configuração no AWS Management Console e culmina na implantação de complementos regionais para os usuários. O processo envolve uma configuração única de identidade e confiança, seguida por um conjunto pequeno de etapas regionais repetidas para cada região AWS ativa.

As etapas gerais do fluxo de trabalho incluem:

• Iniciar a configuração no console do Amazon Quick e selecionar a região AWS a configurar
• Configurar a integração regional da extensão Microsoft Teams, incluindo uma função AWS Identity and Access Management (IAM) e um segredo do AWS Secrets Manager para aquela região AWS, e confiar no IAM Identity Center como um emissor de token
• Ativar a extensão no Amazon Quick para gerar o arquivo de manifesto regional
• Registrar os retornos de chamada da extensão na aplicação Microsoft Entra ID e completar o retorno de chamada de ativação para a aplicação em todas as regiões AWS
• Implantar o complemento Microsoft Teams para grupos de usuários regionais através do Microsoft Entra ID
• Mapear o complemento regional para seu agente de conhecimento designado, concedendo aos usuários acesso a dados localizados

Pré-requisitos e Configuração

Antes de começar a implementação, o ambiente AWS deve atender a requisitos específicos. Para os serviços AWS, é necessário ter uma conta do Amazon Quick ativa, o IAM Identity Center configurado e gerenciando identidades de usuários com integração SAML com Microsoft Entra ID, Secrets Manager disponível em ambas as regiões AWS alvo, e acesso IAM para criar funções e políticas.

Para o Microsoft 365, os requisitos incluem funções de Administrador Global ou Administrador de Aplicações no Microsoft Entra ID, acesso ao Centro de Administração do Microsoft 365 para implantação de aplicações, e permissões para criar e configurar aplicações corporativas no Microsoft Entra ID.

Criar Aplicação no Microsoft Entra ID

O primeiro passo estabelece a base de identidade compartilhada usada por todas as regiões AWS. Cria-se uma aplicação no Microsoft Entra ID que as extensões Microsoft 365 utilizarão para autenticar usuários contra o Amazon Quick através do IAM Identity Center.

O processo começa selecionando Registros de Aplicação e criando um novo registro com suporte apenas para contas no diretório organizacional. Após o registro, configura-se a guia de Autenticação para adicionar URLs de redirecionamento. A solução utiliza dois URLs de redirecionamento seguindo o padrão https://qbs-cell001.dp.appintegrations.[AWS_REGION].prod.plato.ai.aws.dev/auth/idc-tti/callback:

• https://qbs-cell001.dp.appintegrations.eu-west-1.prod.plato.ai.aws.dev/auth/idc-tti/callback
• https://qbs-cell001.dp.appintegrations.us-east-1.prod.plato.ai.aws.dev/auth/idc-tti/callback

O Microsoft Entra ID usa esses URLs de retorno para devolver a resposta de login do usuário ao IAM Identity Center para a região AWS correta. É essencial usar esses URLs exatos — eles são os valores reais necessários para implantações do Amazon Quick. A aplicação deve receber permissão do Microsoft Graph para User.Read, permitindo que ela faça login de usuários e leia suas informações básicas de perfil.

Criar Emissores de Token Confiáveis no IAM Identity Center

Nesta etapa, configuram-se emissores de token confiáveis no IAM Identity Center. Um emissor de token confiável é uma configuração que valida tokens emitidos pelo Microsoft Entra ID, permitindo autenticação entre sistemas para que usuários se movimentem entre Microsoft 365 e AWS sem logins repetidos.

Na configuração do emissor de token confiável, define-se a URL do emissor no formato https://login.microsoftonline.com/[SEU_ID_LOCATARIO]/v2.0 e um nome descritivo para referência organizacional. Esta configuração é aplicada a cada região AWS onde as extensões serão implantadas.

Configurar Permissões IAM e Entradas no Secrets Manager

Para cada região AWS, é necessário criar um segredo no Secrets Manager seguindo a convenção de nomenclatura [NOME_EMPRESA]/MS365/Extensions/[AWS_REGION] contendo as credenciais:

{ "client_id":"[SEU_CLIENT_ID]", "client_secret":"[SEU_CLIENT_SECRET]"}

Cria-se uma política IAM que concede acesso para ler esses segredos:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecretManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "[ARN_SECRET_EU_WEST_1]", "[ARN_SECRET_US_EAST_1]" ] }, { "Sid": "TokenIssuerPermissions", "Effect": "Allow", "Action": [ "sso:DescribeTrustedTokenIssuer" ], "Resource": "[ARN_SEU_TTI]" } ] }

A relação de confiança da função deve permitir que os principais de serviço regionais específicos do Amazon Quick assumam a função:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "eu-west-1.prod.appintegrations.plato.aws.internal", "us-east-1.prod.appintegrations.plato.aws.internal" ] }, "Action": "sts:AssumeRole", "Condition": {} } ] }

Cada vez que uma nova região AWS é ativada, é necessário criar um novo segredo no Secrets Manager e adicionar seu ARN à lista de recursos da política IAM, além de adicionar a nova região ao campo de Principal de Serviço na relação de confiança da função.

Configurar Extensões no Amazon Quick

No console do Amazon Quick, para cada região AWS, realiza-se a seguinte sequência:

Seleciona-se a região desejada (por exemplo, EU – Irlanda) e acessa-se Gerenciar Quick. Em Permissões na navegação, escolhe-se Acesso de Extensão e adiciona-se um novo acesso de extensão. Configura-se o emissor de token confiável informando seu ARN e o ID do cliente como a alegação de Audiência, que funciona como um identificador de segurança validando que o token de autenticação é utilizado apenas pela aplicação específica para a qual foi destinado.

Seleciona-se Microsoft Teams entre os tipos de extensão disponíveis e configuração com o ID de locatário Microsoft 365, atributos de segurança e configurações de autenticação. Insere-se um nome descritivo, o ID de locatário Microsoft, o ARN da função Secrets Manager e o ARN do segredo específico da região.

Ao retornar ao console do Amazon Quick, cria-se uma extensão Microsoft Teams. Ao acessar o menu de opções da extensão (três pontos), escolhe-se Instalar. Este processo cria uma aplicação corporativa no Microsoft Entra ID com URLs únicos e instruções que o Microsoft 365 Teams precisa para comunicar com os ativos AWS regionais específicos.

Repetem-se esses passos para criar uma extensão e instalar a aplicação na região us-east-1, seguindo a mesma convenção de nomenclatura com o sufixo da região AWS e usando o ARN do segredo apropriado para aquela região.

Criar Agentes de Chat Regionais

Após as aplicações regionais serem implantadas, criam-se os agentes específicos de cada região AWS que cada complemento acessará. Cada região AWS mantém seu próprio agente com bases de conhecimento localizadas.

No console do Amazon Quick de eu-west-1, na navegação, escolhe-se Agentes de Chat e Criar Agente de Chat. Cria-se um agente de chat regional em eu-west-1 com conhecimento corporativo europeu, seguindo a convenção de nomenclatura [NOME_EMPRESA]-Knowledge-Agent-eu-west-1 para facilitar gerenciamento entre múltiplas regiões.

Repete-se o processo para criar um agente de chat em us-east-1 com informações corporativas específicas dos EUA, denominado [NOME_EMPRESA]-Knowledge-Agent-us-east-1.

Implantar Aplicações Microsoft Teams

A etapa final envolve atribuir cada aplicação Microsoft Teams a seus respectivos grupos regionais. No Microsoft Teams Admin Center, acessa-se Aplicativos de Equipe, escolhe-se Gerenciar Aplicativos e filtra-se pela Amazon Quick. Seleciona-se a primeira aplicação (da região eu-west-1) e edita-se sua Disponibilidade.

É fundamental atribuir a extensão a grupos de usuários regionais específicos em vez de toda a organização. Essa implantação baseada em grupos roteia automaticamente os usuários para seus recursos corretos de conta do Amazon Quick regional.

Repete-se o mesmo processo com a aplicação Microsoft Teams da região us-east-1.

Verificar a Implementação

Após a implantação se propagar, valida-se que usuários são roteados automaticamente para o agente regional correto. Usuários europeus podem utilizar o agente MyCompany-Teams-eu-west-1, embora o complemento selecione Meu Assistente como agente de chat padrão, sendo necessário acessar as configurações (ícone de engrenagem) e escolher o agente de chat MyCompany-Knowledge-Agent-eu-west-1.

Usuários nos EUA podem utilizar o agente MyCompany-Knowledge-Agent-us-east-1, demonstrando roteamento regional bem-sucedido sem configuração manual.

Resolução de Problemas Comuns

Durante a configuração, podem surgir desafios específicos:

• Extensão do Quick não aparece no Microsoft Teams: Aguardar 24-48 horas para propagação de implantação do Microsoft 365, verificar se o usuário está no grupo Microsoft Entra ID correto e limpar o cache de complementos do Microsoft Office antes de reiniciar Teams
• Problemas com autenticação na extensão do Amazon Quick: Verificar se os URLs de redirecionamento correspondem exatamente no Microsoft Entra ID, confirmar a configuração do emissor de token confiável e validar que a relação de confiança da função IAM inclui o principal de serviço correto
• Agente incorreto listado na extensão do Amazon Quick: Verificar a associação ao grupo de usuários (deve estar apenas em um grupo regional), consultar a atribuição de manifesto para grupo no Microsoft 365 Admin Center e solicitar que o usuário faça logout e login novamente
• Lista de agentes vazia na extensão do Amazon Quick: Validar que o agente está compartilhado com usuários no console do Amazon Quick, verificar se o agente existe na mesma região AWS que a extensão e confirmar que as permissões do agente estão configuradas pelo menos como Nível de Usuário

Limpeza de Recursos

Para evitar custos contínuos, recomenda-se remover os recursos criados durante a implementação se eles não forem mais necessários.

Conclusão

A solução de extensões do Amazon Quick em múltiplas regiões para Microsoft 365 oferece capacidades de inteligência artificial em conformidade com leis regionais para força de trabalho global. A arquitetura e os passos de implementação apresentados demonstram como integrar IA corporativa com ferramentas de produtividade mantendo limites de residência de dados e conformidade. Para mais detalhes sobre assistentes com tecnologia de IA que aumentam produtividade sem troca de aplicações, consulte Acesso de Extensão. Para iniciar o uso do Amazon Quick, consulte Primeiros Passos com Amazon Quick.

Fonte

Enforce data residency with Amazon Quick extensions for Microsoft Teams (https://aws.amazon.com/blogs/machine-learning/enforce-data-residency-with-amazon-quick-extensions-for-microsoft-teams/)

Descoberta de uma Campanha de Ransomware com Zero-Day

As equipes de inteligência de ameaças da AWS identificaram uma campanha ativa do ransomware Interlock que explorra a CVE-2026-20131, uma vulnerabilidade crítica no software do Centro de Gerenciamento de Firewall Seguro Cisco (FMC). Esta vulnerabilidade permite que um atacante não autenticado execute código Java arbitrário com privilégios de root em um dispositivo afetado. A vulnerabilidade foi divulgada publicamente pela Cisco em 4 de março de 2026.

O que torna este caso particularmente preocupante é o cronograma: a pesquisa revelou que o grupo Interlock estava explorando esta vulnerabilidade desde 26 de janeiro de 2026 — 36 dias antes do conhecimento público. Em outras palavras, o grupo possuía um zero-day em mãos, tendo uma semana de vantagem para comprometer organizações antes que os defensores soubessem que deveriam investigar.

Após descobrir essa atividade, a AWS compartilhou seus achados com a Cisco para apoiar a investigação e proteger os clientes. Um erro operacional crítico — um servidor de infraestrutura mal configurado — expôs o arsenal completo do grupo Interlock. Este acidente raro forneceu aos times de segurança da AWS visibilidade sobre a cadeia de ataque multi-estágio do grupo ransomware, incluindo trojans de acesso remoto customizados, scripts de reconhecimento automatizados e técnicas sofisticadas de evasão.

É importante notar que a infraestrutura da AWS e as cargas de trabalho de clientes não foram observadas como envolvidas nesta campanha.

Cronologia da Descoberta e Investigação

A equipes de inteligência de ameaças da AWS começou a identificar atividade potencialmente relacionada à CVE-2026-20131 em 26 de janeiro de 2026, antecedendo a divulgação pública. A atividade observada envolvia requisições HTTP para um caminho específico no software afetado, com corpos contendo tentativas de execução de código Java e duas URLs incorporadas: uma para entregar dados de configuração e outra para confirmar a exploração bem-sucedida.

Para avançar na investigação e obter inteligência de ameaças adicional, os analistas simularam a resposta esperada — fingindo ser um sistema compromitido com sucesso. Esta ação acionou corretamente o grupo Interlock a prosseguir para a próxima fase, emitindo comandos para buscar e executar um binário ELF malicioso (arquivo executável Linux) de um servidor remoto. Quando os analistas recuperaram o binário, descobriram que o mesmo host era usado para distribuir todo o arsenal operacional do Interlock.

A infraestrutura exposta estava organizada com artefatos em caminhos separados correspondendo a alvos individuais — os mesmos caminhos utilizados tanto para baixar ferramentas para hosts compromitidos quanto para fazer upload de artefatos operacionais de volta ao servidor de staging.

Atribuição ao Ransomware Interlock

O binário ELF e artefatos associados foram atribuídos à família de ransomware Interlock através de indicadores técnicos e operacionais convergentes. A nota de resgate incorporada e o portal de negociação TOR são consistentes com a marca estabelecida do Interlock e sua infraestrutura. A nota invoca múltiplas regulações de proteção de dados — uma prática documentada do Interlock de citar exposição regulatória para pressionar vítimas, essencialmente ameaçando organizações não apenas com criptografia de dados, mas com multas regulatórias e violações de conformidade.

O identificador de organização específico da campanha incorporado na nota se alinha com o modelo de rastreamento por vítima do Interlock. Historicamente, o grupo tem direcionado setores específicos onde a interrupção operacional cria pressão máxima para pagamento: educação representa a maior parte de sua atividade, seguida por firmas de engenharia, arquitetura e construção, organizações de manufatura e industriais, provedores de saúde, e entidades de governo e setor público.

A análise temporal de timestamps revelou que os atores provavelmente operam na zona UTC+3 com confiança de 75–80%. A análise sistemática mostrou que UTC+3 produziu o melhor ajuste: primeira atividade por volta de 08:30, pico de atividade entre 12:00 e 18:00, e uma provável janela de descanso de 00:30–08:30.

Análise Técnica: O Arsenal Operacional do Interlock

Script de Reconhecimento Pós-Comprometimento

Uma vez que o Interlock obtém acesso inicial, utiliza diversas ferramentas prioritárias para completar seu ataque. Os times de inteligência de ameaças da AWS recuperaram um script PowerShell projetado para enumeração sistemática do ambiente Windows. O script coleta detalhes do sistema operacional e hardware, serviços em execução, software instalado, configuração de armazenamento, inventário de máquinas virtuais Hyper-V, listagens de arquivos de usuários através de Desktop, Documents e Downloads, artefatos de navegadores (Chrome, Edge, Firefox, Internet Explorer e 360 browser, incluindo histórico, bookmarks, credenciais armazenadas e extensões), conexões de rede ativas correlacionadas com processos responsáveis, tabelas ARP, dados de sessões iSCSI e eventos de autenticação RDP a partir dos logs de eventos do Windows.

O script encena resultados em um compartilhamento de rede centralizado usando o nome de host totalmente qualificado de cada sistema para criar diretórios dedicados — essencialmente criando uma pasta para cada computador compromitido. Após coleta, comprime dados em arquivos ZIP nomeados após cada hostname e remove os dados brutos originais. Este formato de saída estruturado por host indica que o script opera entre múltiplas máquinas dentro de uma rede — uma característica de cadeias de intrusão ransomware que se preparam para criptografia em toda a organização.

Trojans de Acesso Remoto Customizados

Trojans de acesso remoto (RATs) são programas maliciosos que fornecem aos atacantes controle persistente sobre sistemas compromitidos, funcionando como software de desktop remoto não autorizado.

Implant JavaScript: Os times de inteligência da AWS recuperaram um trojan de acesso remoto JavaScript ofuscado que suprime saída de debug sobrescrevendo métodos de console do navegador. Na execução, perfila o host infectado usando PowerShell e Windows Management Instrumentation (WMI), coletando identidade do sistema, associação de domínio, nome de usuário, versão do SO e contexto de privilégio antes de transmitir estes dados durante um handshake de inicialização criptografado. A comunicação com comando e controle ocorre sobre conexões WebSocket persistentes com mensagens criptografadas em RC4 usando chaves aleatórias de 16 bytes por mensagem incorporadas em cabeçalhos de pacotes — essencialmente, cada mensagem usa uma chave de criptografia diferente, tornando a interceptação mais difícil. O implant cicla através de múltiplos hostnames e endereços IP controlados pelo operador em ordem aleatória com backoff exponencial entre tentativas de reconexão. O implant fornece acesso interativo a shell, execução arbitrária de comando, transferência de arquivo bidirecional e capacidade de proxy SOCKS5 para tunelamento de tráfego TCP.

Implant Java: Um cliente funcionalmente equivalente implementado em Java fornece capacidades idênticas de comando e controle. Construído sobre bibliotecas do ecossistema GlassFish, utiliza Grizzly para transporte de I/O não-bloqueante e Tyrus para comunicação de protocolo WebSocket. Em termos mais simples, o Interlock construiu a mesma porta de fundos em duas linguagens de programação diferentes, garantindo que mantenha acesso mesmo se defensores detectem uma versão.

Script de Lavagem de Infraestrutura

Atores sofisticados não atacam a partir de sua própria infraestrutura — eles constroem redes relay descartáveis para esconder seus rastros. Os times de inteligência da AWS identificaram um script Bash que configura servidores Linux como proxies reversos HTTP (servidores intermediários que encaminham tráfego para esconder a localização real do atacante). O script executa atualizações de sistema, instala fail2ban com proteção contra força bruta SSH, e compila HAProxy 3.1.2 a partir do código-fonte. A instância HAProxy escuta na porta 80 e encaminha todo tráfego HTTP inbound para um IP alvo codificado, com systemd garantindo persistência através de reinicializações. Um componente notável é uma rotina de apagamento de logs executada como cron job a cada cinco minutos. A rotina trunca todos os arquivos *.log sob /var/log e suprime o histórico de shell alterando a variável HISTFILE. Esta destruição agressiva de evidências, limpando logs a cada cinco minutos, combinada com o propósito específico de proxy de encaminhamento HTTP, indica que o script estabelece nós relay descartáveis de lavagem de tráfego. Estes nós obscurecem a origem do tráfego de exploração, retransmitem comunicações de comando e controle, ou fazem proxy de exfiltração de dados, tornando praticamente impossível rastrear ataques de volta à sua fonte.

Webshell Residente em Memória

Os times de inteligência da AWS observaram um arquivo classe Java entregue como alternativa ao drop de binário ELF. Quando carregado pela Máquina Virtual Java (JVM), seu inicializador estático registra um ServletRequestListener com o StandardContext do servidor, essencialmente instalando uma porta de fundos persistente residente em memória que intercepta requisições HTTP sem escrever arquivos em disco. Esta abordagem “sem arquivos” elude a varredura tradicional de antivírus que busca por arquivos maliciosos. O listener inspeciona requisições recebidas procurando por parâmetros especialmente crafted contendo payloads de comando criptografados. Os payloads são descriptografados usando AES-128 com chave derivada do hash MD5 de um seed codificado. Os payloads descriptografados são tratados como bytecode Java compilado, dinamicamente carregados na JVM, e executados — uma técnica projetada para eludir detecção baseada em arquivo executando código malicioso inteiramente em memória.

Ferramenta de Verificação de Conectividade

Os times de inteligência da AWS recuperaram arquivos classe Java implementando um servidor TCP básico escutando em uma porta codificada para obscurecer o número da porta da análise estática. O servidor aceita conexões, registra endereços IP de conexão, envia uma mensagem de saudação, e imediatamente fecha conexões. Este perfil operacional é consistente com um beacon de rede leve — essencialmente uma ferramenta “phone home” utilizada para verificar execução bem-sucedida de código ou confirmar alcançabilidade de porta de rede após exploração inicial.

Abuso de Ferramentas Legítimas

O Interlock implantou ConnectWise ScreenConnect, uma ferramenta comercial legítima de desktop remoto, ao lado de implants customizados. Quando operadores de ransomware implantam ferramentas de acesso remoto legítimas ao lado de seu malware customizado, estão comprando seguro — se defensores encontram e removem uma porta de fundos, ainda possuem outro caminho de entrada. Isto indica múltiplos mecanismos de acesso remoto redundantes — um padrão consistente com operadores de ransomware buscando manter acesso mesmo se pontos de apoio individuais forem removidos. A pegada de rede legítima da ferramenta ajuda a se misturar com tráfego de administração remota autorizada, tornando a detecção mais desafiadora.

Os times de inteligência da AWS também recuperaram Volatility, um framework open-source de análise forense de memória tipicamente utilizado por respondentes de incidentes — a mesma ferramenta que defensores usam para investigar ataques. Enquanto nenhum artefato indicava uso automatizado, sua presença ao lado de implants customizados e scripts de reconhecimento é consistente com operações avançadas de ameaças. Tanto grupos de ransomware quanto atores de nível estatal foram observados implantando Volatility durante intrusões. O foco da ferramenta em parsear dumps de memória fornece acesso a dados sensíveis como credenciais armazenadas em RAM, que podem capacitar movimento lateral e comprometimento mais profundo do ambiente em apoio a operações de resgate ou objetivos de espionagem.

O Interlock também utilizou Certify, uma ferramenta ofensiva de segurança open-source projetada para explorar misconfigurations em Active Directory Certificate Services (AD CS). Para operadores de ransomware, Certify fornece um caminho para identificar templates de certificado vulneráveis e permissões de inscrição que permitem requisição de certificados com capacidade de autenticação. Estes certificados podem ser utilizados para impersonar usuários, escalar privilégios, ou manter acesso persistente. Estas capacidades apoiam diretamente ambos objetivos de comprometimento inicial e objetivos de persistência de longo prazo em operações de ransomware.

Indicadores de Comprometimento (IoCs)

Os seguintes indicadores apóiam medidas defensivas por organizações que possam ser afetadas. Devido ao uso de técnicas de variação de conteúdo pelo Interlock, a maioria dos hashes de arquivo não está incluída como indicadores confiáveis. O ator de ameaça modificou a maioria dos artefatos como scripts e binários baixados para diferentes alvos, resultando em diferentes hashes de arquivo para ferramentas funcionalmente idênticas. A customização permitiu que cada ataque eludisse detecção baseada em assinatura que busca por correspondências exatas de arquivo.

Endereços IP:

• 206.251.239[.]164 — IP fonte de exploração (ativo jan 2026)
• 199.217.98[.]153 — IP fonte de exploração (ativo mar 2026)
• 89.46.237[.]33 — IP fonte de exploração (ativo mar 2026)
• 144.172.94[.]59 — IP fallback C2 (ativo mar 2026)
• 199.217.99[.]121 — IP fallback C2 (ativo mar 2026)
• 188.245.41[.]78 — IP fallback C2 (ativo mar 2026)
• 144.172.110[.]106 — IP backend C2 (ativo mar 2026)
• 95.217.22[.]175 — IP backend C2 (ativo mar 2026)
• 37.27.244[.]222 — IP host de staging (ativo mar 2026)

Identificadores de Rede:

• Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0 — User-Agent HTTP de exploração (observado jan e mar 2026)
• b885946e72ad51dca6c70abc2f773506 — TLS JA3 de exploração (observado jan e mar 2026)
• f80d3d09f61892c5846c854dd84ac403 — TLS JA3 de exploração (observado mar 2026)
• t13i1811h1_85036bcba153_b26ce05bbdd6 — TLS JA4 de exploração (observado jan e mar 2026)
• t13i4311h1_c7886603b240_b26ce05bbdd6 — TLS JA4 de exploração (observado mar 2026)

Domínios e URLs:

• hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php — Portal de negociação de resgate (ativo mar 2026)
• cherryberry[.]click — Domínio de suporte de exploração (ativo jan 2026)
• ms-server-default[.]com — Domínio de suporte de exploração (ativo mar 2026)
• initialize-configs[.]com — Domínio de suporte de exploração (ativo mar 2026)
• ms-global.first-update-server[.]com — Domínio de suporte de exploração (ativo mar 2026)
• ms-sql-auth[.]com — Domínio de suporte de exploração (ativo mar 2026)
• kolonialeru[.]com — Domínio de suporte de exploração (ativo mar 2026)
• sclair.it[.]com — Domínio de suporte de exploração (ativo mar 2026)
• browser-updater[.]com — Domínio C2 (ativo mar 2026)
• browser-updater[.]live — Domínio C2 (ativo mar 2026)
• os-update-server[.]com — Domínio C2 (ativo mar 2026)
• os-update-server[.]org — Domínio C2 (ativo mar 2026)
• os-update-server[.]live — Domínio C2 (ativo mar 2026)
• os-update-server[.]top — Domínio C2 (ativo mar 2026)

Hashes de Artefatos:

• d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be — Ferramenta de segurança ofensiva (Certify) observada mar 2026
• 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f — Screen locker observado mar 2026

Recomendações Defensivas

As organizações devem executar as seguintes ações para se proteger contra operações de ransomware Interlock.

Ações Imediatas

• Aplicar patches de segurança da Cisco para o Centro de Gerenciamento de Firewall Seguro Cisco
• Revisar logs em busca dos indicadores de comprometimento listados acima
• Conduzir avaliações de segurança para identificar comprometimento potencial
• Revisar implantações de ScreenConnect em busca de instalações não autorizadas

Oportunidades de Detecção

• Monitorar scripts PowerShell encenando dados em compartilhamentos de rede com estruturas de diretório baseadas em hostname
• Detectar registros de ServletRequestListener em contextos de aplicações web Java (modificações incomuns em aplicações web Java)
• Identificar instalações de HAProxy com agressivos cron jobs de exclusão de logs (servidores proxy que apagam seus próprios logs a cada cinco minutos)
• Monitorar conexões TCP para portas numeradas incomuns

Medidas de Longo Prazo

• Implementar estratégias de defesa em profundidade com múltiplas camadas de controles de segurança
• Manter capacidades contínuas de monitoramento e busca de ameaças
• Garantir logging abrangente com armazenamento de logs centralizado e seguro (armazenado separadamente de sistemas que podem ser comprometidos)
• Testar regularmente procedimentos de resposta a incidentes para cenários de ransomware
• Educar times de segurança sobre táticas, técnicas e procedimentos do Interlock

Entendendo o Contexto Maior

A história real aqui não é apenas sobre uma vulnerabilidade ou um grupo de ransomware — é sobre o desafio fundamental que exploits zero-day colocam em todos os modelos de segurança. Quando atacantes exploram vulnerabilidades antes que patches existam, mesmo programas de patching diligentes não podem proteger naquele período crítico. É precisamente por isso que a defesa em profundidade é essencial — controles de segurança em camadas fornecem proteção quando qualquer controle individual falha ou ainda não foi implantado. Patching rápido permanece fundamental em gerenciamento de vulnerabilidades, mas defesa em profundidade ajuda organizações a não ficarem indefesas durante a janela entre exploit e patch.

Os times de Inteligência de Ameaças da AWS continuam monitorando operações do ransomware Interlock e fornecerão atualizações conforme informações adicionais se tornem disponíveis. A inteligência coletada desta campanha está sendo integrada aos serviços de segurança da AWS para proteger proativamente os clientes.

Fonte

Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-teams-identify-interlock-ransomware-campaign-targeting-enterprise-firewalls/)

Expansão regional do Access Grants para Amazon S3

A AWS anunciou, em março de 2026, a disponibilidade do Amazon S3 Access Grants na região AWS Ásia-Pacífico (Nova Zelândia). Essa expansão amplia as opções de localização geográfica para organizações que precisam gerenciar o acesso a dados armazenados no Amazon S3 (Simple Storage Service) de forma segura e escalável.

Como funciona o S3 Access Grants

O Amazon S3 Access Grants atua como um mecanismo de mapeamento entre identidades corporativas e conjuntos de dados armazenados no S3. Ele estabelece uma ponte entre sistemas de identidade, como o Microsoft Entra ID (antigo Azure AD) ou os principals do AWS IAM (Identity and Access Management), e os recursos específicos no S3.

Essa funcionalidade resolve um desafio importante para empresas: em vez de gerenciar permissões de acesso manualmente para cada usuário ou aplicação, o S3 Access Grants automatiza esse processo. O sistema reconhece a identidade corporativa de um usuário e concede acesso apropriado aos dados no S3 com base nas políticas pré-configuradas da organização.

Benefícios para a gestão de dados em escala

Uma das principais vantagens do S3 Access Grants é sua capacidade de simplificar a administração de permissões. Para organizações com centenas ou milhares de usuários, configurar e manter regras de acesso granulares pode se tornar complexo e propenso a erros. O Access Grants reduz essa complexidade ao centralizar a política de acesso e aplicá-la de forma consistente.

Ao integrar-se com sistemas de diretório corporativo existentes, como o Microsoft Entra ID, o S3 Access Grants aproveita a infraestrutura de identidade que muitas empresas já possuem. Isso significa que decisões sobre quem tem acesso a qual dado podem ser sincronizadas com a estrutura organizacional real, tornando a governança de dados mais alinhada com a realidade operacional.

Próximos passos

Organizações que operam ou planejam expandir suas operações na região Ásia-Pacífico (Nova Zelândia) agora podem utilizar o S3 Access Grants como parte de sua estratégia de segurança e governança de dados. Para verificar a disponibilidade completa em outras regiões e explorar todas as capacidades do serviço, consulte a tabela de regiões da AWS.

Para aprofundar o conhecimento sobre como implementar o Amazon S3 Access Grants em sua infraestrutura, visite a página de detalhes do serviço.

Fonte

Amazon S3 Access Grants are now available in the AWS Asia Pacific (New Zealand) Region (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-access-grants-new-zealand/)

Integração do ECR com o registro do Chainguard

A Amazon anunciou que o Registro Elástico de Contêineres (ECR) agora suporta o cache de puxada com o registro do Chainguard como fonte a montante. Essa integração permite que clientes da AWS usufruam da segurança e disponibilidade do ECR para imagens privadas do Chainguard.

Sincronização simplificada de imagens

A medida que os clientes expandem o uso de imagens do Chainguard em seus ambientes, manter essas imagens sincronizadas com o registro do Chainguard torna-se cada vez mais crítico. O recurso de cache de puxada do ECR oferece uma solução integrada: os clientes podem manter imagens do Chainguard atualizadas sem precisar de fluxos de trabalho adicionais ou ferramentas de gerenciamento externas.

O cache de puxada do ECR suporta sincronizações frequentes de registro, garantindo que as imagens de contêineres obtidas do Chainguard permaneçam sempre atualizadas. Essa abordagem elimina a complexidade operacional de gerenciar sincronizações manuais ou processos separados.

Recursos avançados para imagens cacheadas

Após o cache das imagens do Chainguard no ECR, os clientes podem aplicar funcionalidades importantes do ECR, como varredura de imagens e políticas de ciclo de vida. Essas capacidades oferecem maior controle sobre segurança e conformidade das imagens armazenadas.

Disponibilidade e próximos passos

O cache de puxada para Chainguard está disponível em todas as regiões da AWS onde o cache de puxada do ECR já é suportado. Para começar, os clientes devem consultar a documentação oficial que contém instruções detalhadas sobre como configurar e usar esse novo recurso.

Fonte

Amazon ECR now supports pull through cache for Chainguard (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ecr-pull-through-cache-chainguard/)