Category: Uncategorized

  • Amazon S3 agora disponível em racks AWS Outposts de segunda geração

    S3 em Outposts: Agora em segunda geração

    A AWS anunciou a disponibilidade do Amazon S3 em Outposts nos racks de segunda geração do AWS Outposts. Essa atualização abre novas possibilidades para organizações que precisam manter seus dados dentro de suas próprias instalações, seja em data centers, espaços de colocação ou infraestruturas locais, enquanto aproveitam os recursos do S3 que já conhecem.

    Flexibilidade de capacidade de armazenamento

    O S3 em Outposts nos racks de segunda geração oferece três níveis de armazenamento para atender diferentes necessidades:

    • 196 TB — ideal para ambientes com requisitos iniciais ou moderados
    • 490 TB — adequado para cargas de trabalho de produção de médio porte
    • 786 TB — para operações com demanda substancial de armazenamento

    Essa flexibilidade permite que as organizações escolham a tier que melhor se alinha ao seu cenário de uso, seja para executar workloads de produção, manter backups locais ou armazenar dados para fins de arquivo.

    Experiência familiar e consistente

    Um dos principais benefícios dessa solução é que as equipes podem trabalhar com as mesmas APIs (Interfaces de Programação de Aplicações) e funcionalidades do S3. Não é necessário aprender novas ferramentas ou padrões — basta usar interfaces conhecidas para armazenar, proteger, recuperar e controlar o acesso aos dados localmente.

    O que é AWS Outposts?

    O AWS Outposts é um serviço completamente gerenciado pela AWS que leva a infraestrutura, serviços e ferramentas do AWS para praticamente qualquer local: um data center, espaço de colocação ou instalação on-premises. A proposta é oferecer uma experiência híbrida consistente, permitindo que as organizações tenham a mesma abordagem na nuvem e no local.

    Disponibilidade e próximos passos

    O S3 em Outposts nos racks de segunda geração está disponível em todas as regiões AWS e países/territórios onde esses racks já operam. Para conhecer mais detalhes sobre como implementar essa solução, as organizações podem consultar a página dedicada ao S3 em Outposts ou acessar a documentação técnica completa.

    Casos de uso principais

    Essa solução é particularmente relevante para cenários onde a residência de dados é crítica, a latência deve ser minimizada ou o processamento precisa ocorrer localmente. Empresas que enfrentam restrições regulatórias de soberania de dados, setores que exigem acesso ultrarrápido aos dados ou operações híbridas complexas encontram no S3 em Outposts uma alternativa poderosa.

    Fonte

    Amazon S3 on Outposts is now available on second-generation AWS Outposts racks (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-s3-second-generation-aws-outposts-racks)

  • Proteja Aplicações de IA Generativa com Amazon Bedrock Guardrails

    Desafios na Governança de IA Generativa

    Organizações que buscam automatizar processos através de agentes de IA ou potencializar a produtividade de seus colaboradores com assistentes baseados em chat enfrentam um desafio significativo: implementar salvaguardas abrangentes e controles de auditoria para garantir o uso responsável de IA e o processamento seguro de dados sensíveis pelos modelos de linguagem grandes (LLMs).

    Muitas empresas desenvolveram gateways de IA generativa personalizados ou adotaram soluções prontas, como LiteLLM ou Kong AI Gateway, para fornecer aos seus desenvolvedores acesso a LLMs de diferentes provedores. No entanto, manter políticas consistentes de segurança de prompts e proteção de dados sensíveis em um portfólio crescente de modelos de múltiplos fornecedores em escala representa um obstáculo considerável.

    Solução Centralizada com Guardrails

    A AWS apresenta uma abordagem para esse desafio através do Amazon Bedrock Guardrails. Essa ferramenta oferece um conjunto de funcionalidades de segurança que permitem às organizações construir aplicações de IA generativa responsáveis em escala. A solução integra a API ApplyGuardrail do Amazon Bedrock a um gateway de IA generativa multi-provider personalizado, possibilitando a aplicação de políticas consistentes de segurança de prompts e proteção de dados sensíveis tanto para modelos do Amazon Bedrock quanto de provedores terceirizados, como Azure OpenAI.

    A solução proposta oferece benefícios adicionais: logging e monitoramento centralizados, análise de padrões de uso e um mecanismo de chargeback para atribuição de custos.

    Arquitetura e Componentes Principais

    O fluxo da solução começa quando usuários autenticados enviam requisições HTTPS para o gateway de IA generativa, uma aplicação centralizada executada no Amazon Elastic Container Service (Amazon ECS) que funciona como interface principal para as interações com LLMs. Dentro da lógica da aplicação, cada requisição recebida é primeiro encaminhada para a API ApplyGuardrail do Amazon Bedrock para triagem de conteúdo.

    Imagem original — fonte: Aws

    O gateway avalia o conteúdo contra configurações predefinidas, tomando decisões críticas para bloquear integralmente a requisição, mascarar informações sensíveis ou permitir que prossiga sem modificações. Para requisições aprovadas, a lógica do gateway determina o provedor de LLM apropriado — seja Amazon Bedrock ou um serviço terceirizado — com base nas especificações do usuário. O conteúdo filtrado é então encaminhado ao LLM selecionado, e o gateway retorna a resposta ao usuário.

    Stack Tecnológico

    A aplicação do gateway é hospedada no AWS Fargate e construída usando FastAPI. A aplicação interage com diversos serviços da Amazon Web Services: Amazon Simple Storage Service (Amazon S3), Amazon Bedrock, Amazon Kinesis e Amazon Data Firehose.

    Para escalabilidade, a solução utiliza: nginx para balanceamento de carga e estabilidade; Gunicorn, servidor HTTP WSGI de alto desempenho; Uvicorn para processamento assíncrono de requisições; cluster Amazon ECS Fargate com Amazon Elastic Container Registry (Amazon ECR); Elastic Load Balancing (ELB) e Application Load Balancer; e HashiCorp Terraform para provisionamento de infraestrutura como código.

    Capacidades de Segurança e Guardrails Centralizados

    O gateway centralizado implementa controles de segurança abrangentes através do Amazon Bedrock Guardrails, oferecendo quatro funcionalidades de segurança principais:

    • Filtragem de conteúdo — triagem de conteúdo inadequado ou prejudicial
    • Tópicos negados — prevenção de discussões sobre assuntos específicos
    • Filtros de palavras — bloqueio de termos ou frases específicas
    • Detecção de informações sensíveis — proteção de dados pessoais e confidenciais

    As organizações podem implementar esses controles em três níveis de intensidade configuráveis — baixo, médio e alto — permitindo que diferentes unidades de negócio alinhem sua postura de segurança com sua tolerância a risco e requisitos de conformidade. Por exemplo, um time de marketing pode operar com guardrails de intensidade baixa para geração criativa de conteúdo, enquanto divisões financeiras ou de saúde podem exigir guardrails de intensidade alta para lidar com dados sensíveis de clientes.

    Além dessas proteções básicas, o Amazon Bedrock Guardrails inclui funcionalidades avançadas como grounding contextual e verificações de raciocínio automatizado, que ajudam a detectar e prevenir alucinações de IA — instâncias onde modelos geram informações falsas ou enganosas.

    Integração Multi-Provider e Acesso Centralizado

    O gateway é agnóstico quanto ao provedor de LLM e modelo, permitindo integração perfeita com múltiplos fornecedores. Os usuários podem especificar seu modelo de LLM preferido diretamente no payload da requisição, permitindo que o gateway direcione requisições ao endpoint apropriado. O AWS Secrets Manager armazena tokens de acesso do gateway e de LLMs terceirizados, como Azure OpenAI.

    Observabilidade, Monitoramento e Conformidade

    Uma vantagem fundamental da implementação de um gateway de IA generativa é sua abordagem centralizada para logging e monitoramento. Cada interação — requisições de usuários, prompts, respostas do LLM e contexto do usuário — é capturada e armazenada em formato e local padronizados. Isso facilita análise, resolução de problemas e extração de insights.

    A observabilidade é ativada através de: Amazon CloudWatch para capturar logs de container e aplicação, permitindo criar métricas personalizadas e alarmes proativos; Amazon Simple Notification Service (Amazon SNS) para notificações; Amazon Kinesis Data Streams e Data Firehose para streaming de dados de requisição e resposta até Amazon S3; AWS Glue Crawler API e Amazon Athena para expor tabelas SQL de metadados de transações para análise e chargeback.

    Implantação e Primeiros Passos

    O código-fonte completo está disponível no repositório no GitHub. Para implantar a solução, são necessários: conta AWS, função AWS Identity and Access Management (IAM) com permissões apropriadas para S3, Secrets Manager, CloudWatch, Bedrock e Guardrails.

    O processo de implantação envolve: clonar o repositório GitHub, executar ./deploy.sh para configurar automaticamente o bucket de estado do Terraform, criar política IAM e provisionar infraestrutura, invocar ./verify.sh para verificar a implantação e gerar tokens de autorização para consumidores.

    Exemplos de Funcionalidade

    O primeiro exemplo demonstra a eficácia do mecanismo de segurança no bloqueio de tópicos negados. Uma solicitação com guardrail de intensidade alta contendo uma pergunta sobre investimentos em ações resulta em intervenção do guardrail, retornando uma mensagem de conteúdo bloqueado conforme configurado.

    O segundo exemplo testa a proteção de informações pessoalmente identificáveis (PII). Uma consulta de usuário contendo nome, SSN e email é processada, com o guardrail intervindo e mascarando os dados PII antes de enviar a consulta ao LLM, evidenciado pelo campo guardrail_action indicando a aplicação de política de informações sensíveis.

    Análise de Custos

    A implementação dessa solução envolve várias categorias de custo: custos de provedor de LLM (input/output tokens, modelo e volume de uso); custos de infraestrutura AWS (computação Fargate, balanceamento, armazenamento, monitoramento, processamento de dados, segurança); e custos específicos do Amazon Bedrock Guardrails.

    Uma estimativa de cenário moderado — cerca de 50 a 200 queries por dia, comprimento médio de input de 500 tokens e output de 250 tokens — indica custos entre $170 e $260 mensais para infraestrutura base e processamento de IA combinados. Esses valores podem variar significativamente baseado em volume de chamadas, comprimento de conversas, seleção de modelos e quantidade de chamadas por requisição.

    Conclusão

    A solução de guardrails centralizados integrada a um gateway de IA generativa multi-provider customizado oferece uma abordagem robusta e escalável para empresas utilizarem LLMs com segurança, mantendo padrões rigorosos de conformidade. Através da implementação da API ApplyGuardrail do Amazon Bedrock Guardrails, a solução oferece aplicação consistente de políticas de segurança de prompts e proteção de dados sensíveis em provedores Amazon Bedrock e terceirizados.

    Os principais benefícios dessa arquitetura incluem: guardrails centralizados com níveis de segurança configuráveis, capacidades de integração multi-provider de LLM, recursos abrangentes de logging e monitoramento, escalabilidade de nível produção através de containerização e capacidades built-in de conformidade e auditoria. Organizações em indústrias altamente reguladas podem adotar essa arquitetura para escalar suas implementações de IA generativa mantendo controle sobre proteção de dados e conformidade com regulações de segurança de IA.

    Fonte

    Safeguard generative AI applications with Amazon Bedrock Guardrails (https://aws.amazon.com/blogs/machine-learning/safeguard-generative-ai-applications-with-amazon-bedrock-guardrails/)

  • Políticas IPAM da Amazon VPC agora funcionam com RDS e Application Load Balancers

    Gerenciamento centralizado de IPs para mais recursos

    A AWS anunciou a expansão das políticas do Amazon Virtual Private Cloud (VPC) IP Address Manager (IPAM) para oferecer suporte a instâncias do Amazon Relational Database Service (RDS) e Application Load Balancers (ALB). Com essa atualização, administradores de IP conseguem configurar e executar centralizadamente estratégias de alocação de endereços IP para esses recursos, elevando o padrão operacional e simplificando significativamente a gestão de redes e segurança.

    Como funcionam as políticas IPAM

    Por meio das políticas IPAM, os administradores de IP podem definir centralmente regras de alocação de endereços IP públicos para diversos recursos da AWS, incluindo instâncias RDS, Application Load Balancers, NAT Gateways (quando utilizados em modo de disponibilidade regional) e Elastic IP addresses. O diferencial está na impossibilidade de as equipes de aplicação sobrescreverem as políticas de alocação de IP configuradas centralmente, assegurando conformidade contínua e eliminando desvios.

    Benefícios para arquitetura e compliance

    Anteriormente, administradores de IP precisavam comunicar e educar constantemente administradores de banco de dados e desenvolvedores de aplicações sobre os requisitos de alocação de IP para RDS e ALB, dependendo da adesão manual às melhores práticas. Agora, é possível adicionar filtros baseados em IP para o tráfego de RDS e ALB em construtos de rede e segurança, como listas de controle de acesso, tabelas de roteamento, grupos de segurança e firewalls, com segurança de que os endereços IPv4 públicos atribuídos a esses recursos sempre provenham de pools IPAM específicos.

    Disponibilidade e níveis de suporte

    O recurso está disponível em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US), funcionando tanto na camada Free Tier quanto na Advanced Tier do VPC IPAM. Quando utilizado com a Advanced Tier do VPC IPAM, os clientes conseguem definir políticas entre contas e regiões AWS.

    Próximos passos

    Para começar, consulte a documentação de políticas IPAM. Para aprender mais sobre o IPAM, visite a documentação completa do IPAM. Detalhes sobre precificação estão disponíveis na página de precificação do Amazon VPC.

    Fonte

    Amazon VPC IPAM policies now support RDS and Application Load Balancers (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-vpc-ipam-policies-rds-alb/)

  • Segurança na Inferência Distribuída do Amazon Bedrock: Estratégias Geográficas e Globais

    Inferência Distribuída em Escala: O Desafio da Segurança

    A adoção de IA generativa vem acelerando significativamente. Organizações enfrentam agora o desafio de construir aplicações de IA operacionais em produção, em larga escala, mantendo a eficiência e a confiabilidade. O Amazon Bedrock introduz uma funcionalidade estratégica para esse cenário: os perfis de inferência distribuída (CRIS), que permitem distribuir o processamento de inferência de forma contínua por múltiplas Regiões AWS. Esse mecanismo oferece maior throughput e mantém as aplicações responsivas, mesmo sob carga intensa.

    Porém, escalar globalmente exige compreensão profunda dos controles de segurança envolvidos. Este artigo examina as práticas e considerações de segurança para implementar perfis de inferência distribuída do Bedrock, orientando organizações que precisam atender requisitos regionais de conformidade ou que desejam otimizar recursos em escala global.

    Entendendo a Arquitetura de Inferência Distribuída

    Como Funciona o Roteamento de Requisições

    Os perfis de inferência distribuída operam sobre dois conceitos-chave. A Região de Origem é aquela de onde a chamada de API é feita. A Região de Destino é uma Região para onde o Amazon Bedrock roteia a requisição de processamento.

    Quando você invoca um perfil de inferência distribuída, a requisição segue um caminho de roteamento inteligente. Ela origina-se na Região de origem e é automaticamente direcionada para uma das Regiões de destino definidas no perfil. Todo esse fluxo ocorre pela Rede Global da AWS, gerenciada pelo Amazon Bedrock, com criptografia de ponta a ponta para dados em trânsito.

    Um detalhe crítico: a inferência distribuída não altera o local onde seus dados são armazenados. Nenhum dado do cliente é persistido em Regiões de destino. Logs gerenciados pelo cliente, bases de conhecimento e configurações armazenadas permanecem exclusivamente na Região de origem. As respostas retornam criptografadas para sua aplicação na Região de origem.

    Dois Modelos de Operação: Geográfico e Global

    O Bedrock oferece dois tipos de perfis de inferência distribuída, cada um atendendo diferentes necessidades de conformidade e otimização.

    Inferência Distribuída Geográfica: O Amazon Bedrock seleciona automaticamente a Região ótima dentro de uma geografia definida (EUA, União Europeia, Austrália, Japão) para processar sua requisição. Este modelo mantém o processamento dentro de limites geográficos específicos, atendendo requisitos de residência de dados regional. É ideal para organizações com regulamentações rigorosas de conformidade regional.

    Inferência Distribuída Global: Este modelo amplifica as capacidades da inferência distribuída, roteando requisições para Regiões comerciais da AWS em todo o mundo, otimizando recursos disponíveis e habilitando maior throughput de modelo. Roteia requisições sem restrições geográficas. Adequado para organizações que desejam cobertura mais ampla e custo-benefício em throughput.

    Se sua organização possui requisitos rigorosos de residência de dados ou conformidade, é essencial avaliar cuidadosamente se a inferência distribuída alinha-se com suas políticas e regulamentações, pois os dados de inferência podem ser processados em múltiplas Regiões pré-configuradas.

    Controles de Acesso e Conformidade Regulatória

    Permissões IAM e Políticas de Controle de Serviço

    Por padrão, usuários e funções dentro de sua conta AWS não possuem permissão para criar, modificar ou usar recursos do Amazon Bedrock. O acesso é controlado através de dois mecanismos principais: políticas AWS Identity and Access Management (IAM) para permissões granulares de usuário e função, e Políticas de Controle de Serviço (SCPs) para guardrails e restrições em toda a organização.

    Para usar inferência distribuída no Bedrock, os usuários devem possuir permissões IAM específicas. Se SCPs estão anexadas à sua conta, elas também devem permitir as ações necessárias. A complexidade aumenta porque os requisitos diferem entre os dois tipos de perfil.

    Diferenças de Requisitos: Geográfico vs. Global

    Para inferência distribuída geográfica, as políticas IAM devem permitir acesso aos seguintes recursos:

    • O perfil de inferência distribuída específico da geografia (com prefixos como “us”, “au”, “jp”, “eu”)
    • O modelo de fundação na Região de origem
    • O modelo de fundação em TODAS as Regiões de destino listadas no perfil

    As Políticas de Controle de Serviço devem ser atualizadas para incluir condições específicas de Região, permitindo TODAS as Regiões de destino listadas no perfil geográfico.

    Para inferência distribuída global, as políticas IAM devem permitir:

    • O perfil de inferência distribuída global na Região de origem (com prefixo “global” no ID)
    • O modelo de fundação na Região de origem
    • O modelo de fundação global usando a condição aws:RequestedRegion com valor “unspecified”

    As Políticas de Controle de Serviço globais devem garantir que aws:RequestedRegion: "unspecified" não esteja incluído em listas de Regiões negadas, pois as requisições de inferência distribuída global usam este valor.

    Implementação Prática de Políticas IAM

    Para inferência distribuída geográfica, um exemplo de política permite que um usuário IAM invoque um perfil de inferência distribuída do Claude Sonnet 4.5 para o EUA, originário de us-east-1 com destinos em us-east-1, us-east-2 e us-west-2:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "GrantGeoCrisInferenceProfileAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
          ]
        },
        {
          "Sid": "GrantGeoCrisModelAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
            "arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
            "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
          ],
          "Condition": {
            "StringEquals": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
            }
          }
        }
      ]
    }

    A primeira declaração concede acesso à invocação do perfil de inferência distribuída. A segunda declaração concede acesso aos modelos de fundação em todas as Regiões (origem e destinos), mas apenas quando a chamada é feita através do perfil especificado.

    Para inferência distribuída global, a política é ligeiramente diferente:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
          ]
        },
        {
          "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
          ],
          "Condition": {
            "StringEquals": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
            }
          }
        },
        {
          "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
          ],
          "Condition": {
            "StringEquals": {
              "aws:RequestedRegion": "unspecified",
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
            }
          }
        }
      ]
    }

    Nesta política, a primeira declaração concede permissão para invocar o perfil na Região de origem. A segunda permite invocar o modelo na Região de origem, mas apenas através do perfil especificado. A terceira permite invocar o modelo global em qualquer Região comercial suportada, restringindo através da condição aws:RequestedRegion: "unspecified".

    Governança: Desabilitando Inferência Distribuída

    Organizações com requisitos rigorosos de residência de dados podem precisar desabilitar completamente a inferência distribuída. Para isso, existem duas abordagens complementares.

    Para restringir inferência distribuída geográfica, implemente uma Política de Controle de Serviço de negação que bloqueie todas as invocações de perfis de inferência distribuída que não usem prefixos específicos:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyNonUSGeographicCRIS",
          "Effect": "Deny",
          "Action": "bedrock:*",
          "Resource": "*",
          "Condition": {
            "Null": {
              "bedrock:InferenceProfileArn": "false"
            },
            "ArnNotLike": {
              "bedrock:InferenceProfileArn": [
                "arn:aws:bedrock:*:*:inference-profile/us.*"
              ]
            }
          }
        }
      ]
    }

    Para desabilitar inferência distribuída global, implemente uma política que negue requisições com aws:RequestedRegion: "unspecified":

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Deny",
          "Action": "bedrock:*",
          "Resource": "*",
          "Condition": {
            "StringLike": {
              "aws:RequestedRegion": [
                "unspecified"
              ]
            },
            "ArnLike": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*"
            }
          }
        }
      ]
    }

    Monitoramento e Auditoria

    Todas as chamadas de inferência distribuída são registradas na Região de origem. As entradas do AWS CloudTrail incluem um campo adicional additionalEventData para rastreamento. Este campo especifica a Região real onde a inferência foi processada, permitindo auditoria completa do fluxo de dados.

    Um exemplo típico mostra uma chamada InvokeModel com inferência distribuída global, originária de ap-southeast-2, sendo processada em ap-southeast-4, com o CloudTrail registrando essa Região de processamento para fins de conformidade e auditoria.

    Integração com AWS Control Tower

    Para organizações que usam AWS Control Tower, o gerenciamento de inferência distribuída requer ajustes nas Políticas de Controle de Serviço. A recomendação é usar Customizações para AWS Control Tower em vez de editar manualmente as SCPs, evitando desvios de configuração.

    Para habilitar inferência distribuída global em ambientes Control Tower, é necessário modificar as SCPs criadas automaticamente para incluir “unspecified” na lista de Regiões permitidas especificamente para ações do Amazon Bedrock, mantendo restrições regionais para outros serviços.

    Considerações Sobre Regiões AWS

    O Amazon Bedrock utiliza perfis de inferência para rotear requisições através de todas as Regiões listadas no perfil, sejam Regiões ativadas por padrão ou que requeiram ativação manual na sua conta AWS. A abordagem simplifica a operação ao eliminar a necessidade de ativar múltiplas Regiões manualmente.

    Existem dois tipos de Regiões Regiões comerciais da AWS. Regiões ativadas por padrão (como N. Virginia, Irlanda e Sydney) e Regiões que requerem ativação manual (como Melbourne, Emirados Árabes e Hyderabad). As Regiões ativadas manualmente são mais recentes, introduzidas após 20 de março de 2019.

    Conclusão: Segurança em Escala

    A inferência distribuída no Amazon Bedrock oferece capacidades poderosas para construir aplicações de IA generativa escaláveis e resilientes. Compreender as interações fundamentais entre inferência distribuída e controles de segurança permite que organizações desbloqueiem essa funcionalidade de forma segura, mantendo sua postura de segurança.

    Implementando políticas IAM precisas, Políticas de Controle de Serviço bem estruturadas e monitoramento robusto via CloudTrail, sua organização consegue inovar com inferência distribuída sem comprometer conformidade ou governança.

    Fonte

    Securing Amazon Bedrock cross-Region inference: Geographic and global (https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-cross-region-inference-geographic-and-global/)

  • Automatize sua resposta de segurança em escala com o AWS Security Hub

    A evolução da gestão centralizada de segurança na nuvem

    A AWS lançou uma versão melhorada do AWS Security Hub, oferecendo novas formas para organizações gerenciarem e responderem a achados de segurança. O Security Hub aprimorado auxilia na melhoria da postura de segurança organizacional e simplifica operações de segurança em nuvem ao centralizar a gestão de segurança em todo o ambiente da Amazon Web Services (AWS).

    O Security Hub transformou a maneira como as organizações tratam achados de segurança através de capacidades avançadas de automação, incluindo análise de risco em tempo real, correlação automática e contexto enriquecido. Essas funcionalidades permitem que as equipes priorizem problemas críticos e reduzam tempos de resposta.

    A automação também garante que procedimentos de resposta sejam consistentes e que requisitos de conformidade sejam atendidos. O AWS Security Hub CSPM (Gerenciamento de Postura de Segurança em Nuvem) agora é parte integral dos mecanismos de detecção do Security Hub.

    Visibilidade centralizada e priorização baseada em risco

    O Security Hub oferece visibilidade centralizada através de múltiplos serviços de segurança da AWS, proporcionando uma visão unificada do ambiente em nuvem. Isso inclui visualizações de priorização baseada em risco, visualização de caminhos de ataque e análise de tendências que ajudam a compreender padrões de segurança ao longo do tempo.

    Este é o terceiro artigo de uma série sobre as novas capacidades do Security Hub. Para contexto: a série anterior discutiu como o Security Hub unifica achados entre serviços da AWS para simplificar a gestão de risco, e também apresentou as etapas para realizar uma Prova de Conceito bem-sucedida.

    Por que automação importa em segurança em nuvem

    As organizações frequentemente operam em centenas de contas da AWS, múltiplas regiões e diversos serviços, cada um gerando achados que precisam ser triados, investigados e processados. Sem automação, equipes de segurança enfrentam alto volume de alertas, duplicação de esforço e risco de respostas atrasadas a questões críticas.

    Processos manuais não conseguem acompanhar operações em nuvem. A automação transforma as operações de segurança de três formas fundamentais:

    • Filtragem e priorização: A automação filtra e prioriza achados conforme seus critérios, mostrando à equipe apenas alertas relevantes.
    • Resposta imediata: Quando problemas são detectados, respostas automatizadas disparam instantaneamente, sem necessidade de intervenção manual.
    • Consistência em escala: Ao gerenciar múltiplas contas da AWS, a automação aplica políticas e fluxos de trabalho consistentes através do seu ambiente, transferindo a equipe de segurança de “apagar incêndios” para gerenciamento proativo de risco.

    Desenhando estratégias de roteamento para achados de segurança

    Com o Security Hub configurado, é hora de desenhar uma estratégia de roteamento para seus achados e notificações. Ao projetar essa estratégia, questione se sua configuração atual do Security Hub atende seus requisitos de segurança. Considere se as automações do Security Hub podem ajudá-lo a atender frameworks de conformidade como NIST 800-53 e identifique KPIs e métricas para mensurar se sua estratégia de roteamento funciona.

    As automações e respostas automáticas do Security Hub podem ajudar a cumprir esses requisitos, mas é crucial compreender como suas equipes de conformidade, respondentes de incidentes, pessoal de operações de segurança e demais stakeholders operam diariamente. Por exemplo: suas equipes usam o Console de Gerenciamento da AWS para o Security Hub regularmente? Ou você precisa enviar a maioria dos achados para ferramentas de gerenciamento de sistemas de TI (ITSM), como Jira ou ServiceNow, ou plataformas terceirizadas de orquestração, automação e resposta de segurança (SOAR)?

    Em seguida, crie e mantenha um inventário de aplicações críticas. Isso ajuda a ajustar a severidade de achados baseado em contexto empresarial e seus playbooks de resposta a incidentes. Considere um cenário onde o Security Hub identifica uma vulnerabilidade de severidade média em uma instância de Elastic Compute Cloud. Isoladamente, isso pode não disparar ação imediata. Ao adicionar contexto empresarial — como objetivos estratégicos ou criticidade para o negócio — você pode descobrir que essa instância hospeda uma aplicação crítica de processamento de pagamentos, revelando o risco real. Implementando regras de automação do Security Hub com contexto enriquecido, esse achado pode ser elevado para severidade crítica e automaticamente roteado para ServiceNow para rastreamento imediato.

    Além disso, usando automação do Security Hub com Amazon EventBridge, você pode disparar um documento de automação do AWS Systems Manager Automation para isolar a instância EC2 para trabalho forense de segurança.

    Como o Security Hub oferece formato e esquema OCSF, você pode utilizar os extensos elementos de esquema que o OCSF oferece para direcionar achados para automação e ajudar sua organização a atender requisitos de estratégia de segurança.

    Casos de uso em automação de segurança

    As automações do Security Hub suportam diversos casos de uso. Converse com suas equipes para entender quais se aplicam às suas necessidades e objetivos de segurança:

    Remediação automática de achados

    Use remediação automática de achados para corrigir automaticamente problemas de segurança conforme são detectados. Padrões de suporte incluem remediação direta (disparar funções AWS Lambda para corrigir configurações incorretas), marcação de recursos (adicionar tags em recursos não conformes), correção de configuração (atualizar configurações de recursos para corresponder políticas de segurança) e ajuste de permissões (modificar políticas do AWS Identity and Access Management (IAM) para remover permissões excessivas).

    Exemplo:

    IF finding.type = "Software and Configuration Checks/Industry and Regulatory Standards/CIS AWS Foundations Benchmark"
    AND finding.title CONTAINS "S3 buckets should have server-side encryption enabled"
    THEN invoke Lambda function "enable-s3-encryption"

    Integração de achados em fluxo de trabalho

    Integre achados em seus fluxos de trabalho roteando-os para as equipes e sistemas apropriados. Padrões de suporte incluem criação de tickets (gerar tickets em Jira ou ServiceNow para revisão manual), atribuição de equipes (rotear achados para equipes específicas baseado em propriedade de recursos) e roteamento baseado em severidade (direcionar achados críticos para resposta a incidentes, outros para filas regulares).

    Exemplo:

    IF finding.severity = "CRITICAL" AND finding.productName = "Amazon GuardDuty"
    THEN send to SNS topic "security-incident-response-team"
    ELSE IF finding.productFields.resourceOwner = "payments-team"
    THEN send to SNS topic "payments-security-review"

    Enriquecimento automático de achados

    Use enriquecimento de achados para adicionar contexto que melhore eficiência de triagem. Padrões incluem adição de contexto de recursos (adicionar contexto empresarial, informações de proprietário e classificação de dados), análise histórica (adicionar informações sobre achados similares anteriores), pontuação de risco personalizada (calcular scores de risco customizados baseado em valor do ativo e contexto de ameaça) e correlação de vulnerabilidades (ligar achados a CVEs conhecidas ou inteligência de ameaças).

    Controles de segurança customizados

    Use controles de segurança customizados para atender requisitos específicos da organização. Padrões incluem imposição de política customizada (verificar conformidade com padrões internos), regras específicas do negócio (aplicar regras baseado em unidade de negócio ou tipo de aplicação), controles compensatórios (implementar alternativas quando controles primários não podem ser aplicados) e exceções temporárias (lidar com desvios aprovados de padrões de segurança).

    Relatório de conformidade e coleta de evidência

    Agilize documentação de conformidade e coleta de evidência. Padrões incluem captura de evidência (armazenar evidência de conformidade em buckets S3 designados), criação de trilha de auditoria (documentar ações de remediação para auditores), dashboard de conformidade (atualizar métricas de status de conformidade) e mapeamento regulatório (rotular achados com frameworks de conformidade relevantes).

    Configurando automação no Security Hub

    Passo 1: Ative o Security Hub e serviços integrados

    Como primeiro passo, siga as instruções para ativar o Security Hub. Nota importante: o Security Hub é potencializado por Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM e Amazon Macie. Esses serviços também precisam ser habilitados para obter valor completo do Security Hub.

    Passo 2: Crie regras de automação

    Após o Security Hub coletar achados, você pode criar regras de automação para atualizar e rotear os achados para as equipes apropriadas. Os passos para criar regras de automação no Security Hub que atualizam detalhes de achados ou configurar integrações terceirizadas como Jira ou ServiceNow podem ser encontrados na documentação específica.

    Com essas regras de automação, o Security Hub avalia achados contra a regra definida e então executa a atualização apropriada ou chama APIs para enviar achados a Jira ou ServiceNow. O Security Hub envia uma cópia de cada achado para o Amazon EventBridge, permitindo que você implemente suas próprias respostas automatizadas se necessário, para casos de uso fora do escopo das regras de automação do Security Hub.

    Além de enviar cópias de cada achado para EventBridge, o Security Hub classifica e enriquece achados de segurança conforme contexto empresarial, entregando-os aos serviços downstream apropriados (como ferramentas ITSM) para resposta rápida.

    Melhores práticas para automação de segurança

    As regras de automação do Security Hub oferecem capacidades para atualização automática de achados e integração com outras ferramentas. Ao implementar regras de automação, siga estas melhores práticas:

    • Gestão centralizada: Apenas a conta administradora do Security Hub pode criar, editar, deletar e visualizar regras de automação. Garanta controle de acesso e gestão apropriados dessa conta.
    • Implantação regional: Regras de automação podem ser criadas em uma região da AWS e aplicadas através de regiões configuradas. Ao usar agregação de região, você pode apenas criar regras na região inicial.
    • Critérios específicos: Defina claramente os critérios que achados devem corresponder para a regra de automação aplicar. Isso pode incluir atributos de achados, níveis de severidade, tipos de recurso ou IDs de conta membro.
    • Entenda a ordem de regras: A ordem importa quando múltiplas regras aplicam ao mesmo achado ou campo de achado. O Security Hub aplica regras com valor numérico menor primeiro. Para mais informações, consulte a documentação sobre atualização da ordem de regras no Security Hub.
    • Descrições claras: Inclua descrição de regra detalhada para fornecer contexto aos respondentes e proprietários de recursos, explicando o propósito e ações esperadas da regra.
    • Use automação para eficiência: Use regras de automação para atualizar automaticamente campos de achados (como severidade e status de fluxo de trabalho), suprimir achados de baixa prioridade, ou criar tickets em ferramentas terceirizadas como Jira ou ServiceNow para achados correspondentes a atributos específicos.
    • Considere EventBridge para ações externas: Enquanto regras de automação lidam com atualizações internas de achados do Security Hub, use regras EventBridge para disparar ações fora do Security Hub, como invocar funções AWS Lambda ou enviar notificações para tópicos Amazon Simple Notification Service (Amazon SNS) baseado em achados específicos. As regras de automação têm efeito antes das regras EventBridge serem aplicadas. Para mais informações, consulte regras de automação em EventBridge.
    • Gerencie limites de regras: Existe um limite máximo de 100 regras de automação por conta administradora. Planeje sua criação de regras estrategicamente para permanecer dentro desse limite.
    • Revise e refine regularmente: Periodicamente revise regras de automação, especialmente regras de supressão, para garantir que permaneçam relevantes e efetivas, ajustando-as conforme sua postura de segurança evolui.

    Consolidando operações de segurança em escala

    As automações do Security Hub permitem triar, rotear e responder a achados mais rapidamente através de uma solução unificada de segurança em nuvem com gestão centralizada. Através da abordagem intuitiva e flexível de automação que o Security Hub oferece, suas equipes de segurança podem tomar decisões confiantes, baseadas em dados, sobre achados do Security Hub que se alinhem com a estratégia de segurança geral da organização.

    Com as capacidades de automação do Security Hub, você pode gerenciar segurança centralmente através de centenas de contas enquanto suas equipes focam em problemas críticos que mais importam para seu negócio. Implementando as capacidades de automação descritas neste artigo, você consegue simplificar tempos de resposta em escala, reduzir esforço manual e melhorar sua postura de segurança geral através de fluxos de trabalho consistentes e automatizados.

    Fonte

    Streamline security response at scale with AWS Security Hub automation (https://aws.amazon.com/blogs/security/streamline-security-response-at-scale-with-aws-security-hub-automation/)

  • Pacote de Conformidade PCI DSS Outono 2025 está disponível

    Novidades na Certificação PCI DSS

    A Amazon Web Services (AWS) anunciou a inclusão de dois serviços adicionais e uma nova região geográfica no escopo de sua certificação Payment Card Industry Data Security Standard (PCI DSS). Essa atualização oferece aos clientes mais opções para implementar cargas de trabalho reguladas enquanto mantêm conformidade com os rigorosos padrões de segurança de dados de cartões de pagamento.

    Serviços Recém-Adicionados

    Os dois novos serviços agora certificados são:

    Expansão Geográfica

    Além dos serviços, a região Asia Pacific (Taipei) foi adicionada ao programa de certificação PCI DSS, ampliando as opções de localidade para organizações que precisam manter dados de cartão de pagamento em conformidade regulatória em diferentes regiões.

    Componentes do Pacote de Conformidade

    O pacote de conformidade PCI DSS da AWS é composto por dois elementos principais:

    • Attestation of Compliance (AOC): Documento que demonstra que a AWS foi validada com sucesso conforme os requisitos do padrão PCI DSS, avaliada por um avaliador qualificado independente.
    • AWS Responsibility Summary: Guia que orienta os clientes da AWS sobre suas responsabilidades específicas na implementação e operação de ambientes seguros para processamento de dados de cartão de pagamento.

    A avaliação foi conduzida pela Coalfire, uma empresa qualificada como Qualified Security Assessor (QSA) terceirizada.

    Inovação em Formatos de Conformidade

    Um destaque importante dessa atualização é a disponibilidade dos relatórios de conformidade em formato Open Security Controls Assessment Language (OSCAL). Trata-se de um padrão aberto mantido pelo NIST, baseado em JSON estruturado para leitura por máquinas, permitindo automação de workflows e redução de processamento manual em auditorias de conformidade.

    A AWS é a primeira provedora de nuvem a oferecer relatórios de conformidade neste formato, um avanço significativo rumo a processos de conformidade modernizados e automatizáveis.

    Acesso e Implementação Prática

    Os clientes podem acessar toda a documentação de certificação PCI DSS através do AWS Artifact, um portal de autoatendimento que oferece acesso sob demanda aos relatórios de conformidade da AWS. Esse recurso simplifica processos de auditoria e integração com fluxos de conformidade existentes.

    A lista completa de serviços em escopo de conformidade pode ser consultada na página AWS Services in Scope by Compliance Program.

    Próximas Etapas

    Para conhecer mais sobre os programas de conformidade e segurança da AWS, consulte a AWS Compliance Programs page. Dúvidas sobre implementação ou aspectos específicos de conformidade podem ser direcionadas à equipe de Compliance Support ou ao AWS Support.

    Fonte

    Fall 2025 PCI DSS compliance package available now (https://aws.amazon.com/blogs/security/fall-2025-pci-dss-compliance-package-available-now/)

  • Amazon Inspector ganha suporte a Java Gradle e expande cobertura de ecossistemas

    Expansão do Amazon Inspector com novo suporte a Java Gradle

    A AWS anunciou uma atualização significativa no Amazon Inspector, seu serviço automatizado de gerenciamento de vulnerabilidades. A novidade traz suporte específico para Java Gradle nas varreduras de funções Lambda e imagens no Elastic Container Registry (ECR), abrindo possibilidades para uma cobertura muito mais ampla de componentes e tecnologias.

    Novos componentes e tecnologias cobertos

    Com esta atualização, o Amazon Inspector agora consegue detectar vulnerabilidades não apenas em Java com Gradle, mas também em uma série de outros componentes frequentemente utilizados em ambientes cloud. A expansão inclui MySQL, MariaDB, PHP, Jenkins-core, 7zip (em Windows), Elasticsearch e Curl/LibCurl.

    Como funciona o suporte a Java Gradle

    O novo suporte a Java Gradle permite que o Inspector analise as dependências de projetos Java tomando como base o conteúdo do arquivo gradle.lockfile. Isso significa que aplicações Java podem agora receber avaliações abrangentes de vulnerabilidades diretamente nas suas dependências gerenciadas pelo Gradle.

    Melhor detecção de pacotes fora dos gerenciadores de pacotes

    Uma das grandes vantagens dessa expansão é a capacidade melhorada de identificar vulnerabilidades em pacotes instalados fora dos gerenciadores de pacotes tradicionais. Ao escanear funções Lambda e imagens ECR, você agora verá descobertas de vulnerabilidades também em instalações de MySQL, MariaDB, PHP, Jenkins-core, 7zip (Windows), Elasticsearch e Curl/LibCurl.

    O que é o Amazon Inspector

    O Amazon Inspector é um serviço de gerenciamento automatizado de vulnerabilidades que funciona continuamente, escaneando as cargas de trabalho da AWS em busca de vulnerabilidades de software e exposições não intencionais de rede. Seu objetivo é ajudar organizações a fortalecerem sua postura de segurança e atender requisitos de conformidade regulatória.

    Benefícios práticos para sua infraestrutura

    Essas melhorias representam um avanço significativo na segurança automatizada. Para organizações que utilizam estas tecnologias — particularmente aquelas com stacks Java baseados em Gradle — a cobertura expandida oferece tranquilidade maior e detecção mais precisa de riscos potenciais em suas aplicações.

    Como começar

    Os novos recursos estão disponíveis a partir de agora em todas as regiões da AWS onde o Amazon Inspector funciona. Para aprender mais sobre o Amazon Inspector e como ele pode ajudar a proteger suas cargas de trabalho na AWS, consulte a página do Amazon Inspector.

    Para uma lista completa dos sistemas operacionais e linguagens de programação suportados pelo Amazon Inspector, confira o guia do usuário.

    Fonte

    Amazon Inspector adds Java Gradle support and expands ecosystem coverage (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-inspector-java-gradle-ecosystem/)

  • Amazon Connect agora oferece rastreamento em tempo real do status de gravação de tela de agentes

    Monitoramento de Gravações de Tela em Tempo Real

    O Amazon Connect, serviço de contact center em nuvem da AWS, acaba de incorporar uma funcionalidade importante para quem trabalha com supervisão e qualidade de atendimento. A novidade permite que supervisores acompanhem o status das gravações de tela dos agentes praticamente em tempo real através do CloudWatch, utilizando o Amazon EventBridge como intermediário.

    Essa evolução vem em resposta a uma necessidade real dos gestores de contact center: ter visibilidade completa sobre o que cada agente está fazendo durante o atendimento. Não basta mais escutar chamadas ou revisar transcrições de chat. Agora é possível visualizar as ações do agente na sua tela enquanto ele interage com o cliente — seja em uma chamada de voz, conversa por chat ou tarefa.

    Capacidades de Rastreamento

    Quando integrado ao Amazon EventBridge, o novo recurso oferece acesso a informações granulares sobre cada sessão de gravação de tela. Os supervisores conseguem visualizar dados como:

    • Status de sucesso ou falha de cada gravação
    • Códigos de erro detalhados, acompanhados de descrição
    • Versão do cliente de gravação instalada no computador do agente
    • Versão do navegador web utilizado pelo agente
    • Sistema operacional em que o agente está operando
    • Horários precisos de início e fim de cada gravação

    Esses dados agregados no CloudWatch criam um panorama transparente das operações, facilitando a identificação de problemas técnicos, inconsistências de processo ou necessidades de treinamento específico.

    Como Começar

    A ativação da funcionalidade é direta. Os clientes da AWS precisam apenas se inscrever no tipo de evento Screen Recording Status Changed no barramento de eventos do Amazon EventBridge. Assim que configurado, o fluxo de dados para o CloudWatch começa automaticamente.

    O recurso já está disponível em todas as regiões da AWS onde o Amazon Connect funciona, o que garante que organizações brasileiras utilizando este serviço possam adotá-lo sem restrições geográficas.

    Caso de Uso Prático

    Supervisores podem explorar os dados de gravação para identificar oportunidades de coaching com agentes. Por exemplo, se uma gravação falha repetidamente para um agente específico, pode-se investigar problemas de compatibilidade do cliente ou da infraestrutura local. Alternativamente, se todas as gravações de determinado período mostram padrões consistentes de não-conformidade com processos de negócio, há espaço para intervenção educativa ou revisão de procedimentos.

    Recursos Adicionais e Precificação

    Para compreender melhor a implementação técnica deste recurso de gravação de tela, a AWS disponibiliza documentação detalhada e conteúdo complementar. Informações sobre custos associados ao uso dessa funcionalidade podem ser encontradas na página de precificação do Amazon Connect.

    Esta atualização reforça o posicionamento do Amazon Connect como uma solução madura e orientada a conformidade, essencial para empresas que precisam manter altos padrões de qualidade e regulamentação em seus centros de contato.

    Fonte

    Amazon Connect now provides agent screen recording status tracking (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-connect-agent-screen-recording-status-tracking)

  • AWS reconhecida como Líder no relatório ISG 2025 para Serviços de Infraestrutura em Nuvem Soberana (EU)

    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.

    Próximos passos e recursos disponíveis

    Organizações interessadas em aprofundar o entendimento sobre a arquitetura soberana da AWS e suas vantagens competitivas podem consultar o relatório completo Provider Lens 2025 do ISG para Serviços de Infraestrutura em Nuvem Soberana (EU). O documento oferece análises detalhadas, comparativas de portfólio e insights sobre como a nuvem soberana continua evoluindo no contexto europeu.

    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.

    Fonte

    AWS named Leader in the 2025 ISG report for Sovereign Cloud Infrastructure Services (EU) (https://aws.amazon.com/blogs/security/aws-named-leader-in-the-2025-isg-report-for-sovereign-cloud-infrastructure-services-eu/)

  • Defesa em Tempo Real contra Malware: Como a AWS Network Firewall Protege suas Cargas de Trabalho

    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.

    O modelo de defesa em camadas — Fonte: Aws

    Interrupção da Cadeia de Ataque em Sete Etapas

    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.

    Para começar, consulte Melhore sua postura de segurança usando inteligência de ameaças da Amazon no AWS Network Firewall.

    Fonte

    Real-time malware defense: Leveraging AWS Network Firewall active threat defense (https://aws.amazon.com/blogs/security/real-time-malware-defense-leveraging-aws-network-firewall-active-threat-defense/)