Category: Uncategorized

O que é o AWS Security Hub e por que fazer um POC?

O AWS Security Hub chegou à disponibilidade geral trazendo uma proposta bastante ambiciosa: centralizar e priorizar os problemas críticos de segurança de toda a sua infraestrutura AWS em um único lugar. O serviço agrega, correlaciona e enriquece sinais nativos de segurança da AWS, transformando-os em insights acionáveis que permitem respostas mais rápidas e eficientes.

Para times que ainda não conhecem o serviço na prática, a AWS oferece um período de teste gratuito que permite montar uma Prova de Conceito (POC) completa — sem grande investimento de tempo ou recursos logo de cara. Este guia percorre as etapas recomendadas para planejar e executar esse POC de forma estruturada.

Entendendo o valor do Security Hub

O Security Hub funciona como uma Plataforma de Proteção de Aplicações Nativas em Nuvem (CNAPP — Cloud-Native Application Protection Platform). Ele ingere sinais de múltiplos serviços AWS e soluções parceiras, consolidando tudo em uma visão única. As fontes de sinal incluem:

• Ameaças: findings do Amazon GuardDuty
• Vulnerabilidades: findings de vulnerabilidades do Amazon Inspector
• Controles: findings de Gerenciamento de Postura de Segurança em Nuvem (CSPM — Cloud Security Posture Management) do AWS Security Hub CSPM
• Configurações: inventário de recursos
• Exposições de rede: findings de acessibilidade de rede do Amazon Inspector
• Dados sensíveis: findings do Amazon Macie
• Plano Estendido: soluções parceiras curadas

Na prática, o serviço entrega quatro capacidades principais em uma solução unificada:

• Operações de segurança unificadas: todos os sinais de segurança em uma única visão consolidada, eliminando a necessidade de alternar entre múltiplas ferramentas. Isso inclui visibilidade sobre ambientes AWS, multi-cloud e on-premises.
• Priorização inteligente: o Security Hub correlaciona findings analisando relações entre recursos e sinais de diferentes serviços, ajudando a identificar riscos críticos que seriam difíceis de perceber isoladamente.
• Insights acionáveis: por meio de análise avançada, o serviço transforma findings correlacionados em insights claros e priorizados, permitindo entender rapidamente o impacto potencial e quais problemas representam maior risco.
• Resposta e automação simplificadas: integração com sistemas de gestão de incidentes como Jira Cloud e ServiceNow, permitindo investigar riscos críticos a partir de um único painel, monitorar tendências e automatizar respostas.

O papel do OCSF na integração de ferramentas

O Security Hub adota o Framework Aberto de Esquema de Cibersegurança (OCSF — Open Cybersecurity Schema Framework) para padronizar os dados de segurança. Essa padronização simplifica como os findings são estruturados e analisados, permitindo integração e troca de dados entre diferentes ferramentas de segurança com formatos normalizados e consistentes.

Ao planejar seu POC, é importante se familiarizar com as especificações OCSF que o Security Hub utiliza e confirmar que as ferramentas de análise ou sistemas de Informação de Segurança e Gerenciamento de Eventos (SIEM — Security Information and Event Management) que você pretende integrar suportam esse formato.

Definindo critérios de sucesso

Antes de habilitar qualquer serviço, é fundamental estabelecer critérios de sucesso que conectem os resultados do POC aos objetivos do negócio. Alguns exemplos de indicadores-chave de desempenho (KPI — Key Performance Indicator) recomendados:

• Consolidação de alertas: medir a redução do esforço de correlação de eventos de segurança, especialmente os processos realizados fora da AWS ou via SIEM.
• Melhoria no tempo de resposta: redução do Tempo Médio de Detecção (MTTD — Mean Time to Detect) e do Tempo Médio de Resposta (MTTR — Mean Time to Respond) para findings críticos, além de maior precisão na análise de caminhos de ataque.
• Capacidades de automação: avaliar quais partes dos playbooks de resposta a incidentes podem ser automatizadas, incluindo roteamento automático de findings para as equipes corretas via Jira Cloud, ServiceNow ou ferramentas de terceiros.
• Classificação de severidade e risco: reduzir o tempo para identificar recursos críticos e lacunas de cobertura afetados por novas vulnerabilidades, ameaças e configurações incorretas.

Após definir os critérios, avalie a maturidade atual do ambiente: quais serviços de segurança já estão habilitados, quais são as cargas de trabalho críticas, e se há restrições organizacionais que possam impactar a implementação.

Maximizando o valor do POC com os períodos de teste gratuito

Para aproveitar ao máximo a avaliação, a AWS recomenda ativar os serviços subjacentes de forma coordenada, sobrepondo os períodos de teste gratuito disponíveis:

• Security Hub: 30 dias de teste (capacidades do plano essencial)
• GuardDuty: 30 dias de teste (cobre a maioria dos planos de proteção, exceto o GuardDuty Malware Protection)
• Security Hub CSPM: 30 dias de teste
• Macie: 30 dias de teste
• Amazon Inspector: 15 dias de teste

A recomendação é habilitar todos esses serviços simultaneamente para garantir pelo menos duas semanas de cobertura sobreposta, permitindo avaliar as capacidades completas de correlação e priorização de riscos. Se houver limitações, é possível iniciar o POC habilitando apenas o Security Hub CSPM e o Amazon Inspector.

Dica importante: documente as datas de ativação e expiração dos testes. Crie lembretes no calendário e agende os marcos de avaliação do POC enquanto os serviços ainda estiverem ativos.

Configurando o Security Hub

Com os critérios de sucesso definidos, é hora de planejar a configuração. As principais decisões envolvem:

• Administrador delegado: a partir da conta de gerenciamento do AWS Organizations, é possível definir um administrador delegado para o Security Hub. A recomendação da Arquitetura de Referência de Segurança AWS (AWS SRA) é usar o mesmo administrador delegado em todos os serviços de segurança para uma governança consistente.
• Contas e regiões em escopo: definir quais contas e regiões AWS terão o Security Hub habilitado.
• Integrações com serviços AWS: além das capacidades principais de CSPM e gerenciamento de vulnerabilidades, o Security Hub integra sinais de GuardDuty e Macie.
• Integrações com terceiros: para gestão de tickets, o serviço integra com Jira Service Management Cloud e ServiceNow. Parceiros que já suportam ou pretendem suportar o esquema OCSF incluem Dynatrace, Netskope, Orca Security, SentinelOne, Sumo Logic, Tines, Wiz, entre outros como Arctic Wolf, CrowdStrike, DataBee, Datadog, Fortinet, IBM, Palo Alto Networks, Rapid7, Securonix, Sophos, Splunk, Trellix e Zscaler. Parceiros de serviços como Accenture, Caylent, Deloitte, IBM e Optiv também podem ajudar na adoção.
• Estimativa de custos: utilize a Ferramenta de Estimativa de Custos do Security Hub para obter uma estimativa pré-habilitação com base no gasto atual em Amazon Inspector, Security Hub CSPM e GuardDuty.

Preparando o deployment

Com a configuração definida, o próximo passo é preparar o projeto com um plano estruturado. A linha do tempo sugerida é:

• Antes da habilitação: validar a configuração dos serviços de segurança base (GuardDuty, Amazon Inspector, Security Hub CSPM e Macie) e obter as aprovações necessárias para o teste gratuito.
• Dia 0: habilitar o serviço, familiarizar-se com o layout do Security Hub e iniciar o treinamento da equipe de segurança.
• Semana 1: validar a cobertura desejada de detecção de ameaças, gerenciamento de vulnerabilidades e gerenciamento de postura em todas as contas e regiões.
• Semana 2: conectar às ferramentas de Gerenciamento de Serviços de TI (ITSM — IT Service Management) e iniciar a criação de automações para cargas de trabalho e recursos críticos.
• Semana 3: executar um exercício de simulação (tabletop exercise) em resposta a um finding de exposição selecionado.
• Semana 4: analisar tendências de ameaças e exposições desde o dia 1 até a semana 4.

Na parte de acessos e permissões, é recomendado configurar funções do AWS Identity and Access Management (IAM) alinhadas a uma matriz de Responsabilidade, Autoridade, Consulta e Informação (RACI), incluindo funções de gerenciamento de casos, escalonamento e acesso somente leitura usando Políticas Gerenciadas da AWS. Também é necessário configurar o acesso à conta de gerenciamento para delegação administrativa — veja os detalhes em Permissões necessárias para designar uma conta administradora delegada do Security Hub.

Habilitando o Security Hub

O Security Hub se integra ao AWS Organizations para facilitar o gerenciamento centralizado. O mínimo necessário para aproveitar as capacidades de correlação é habilitar o Security Hub CSPM e o Amazon Inspector. A combinação desses dois serviços fornece a telemetria necessária para o mecanismo de correlação do Security Hub e para os findings de exposição.

Para habilitar o Security Hub para sua organização, acesse a conta de gerenciamento. Se for definir um administrador delegado, consulte a documentação sobre como configurar uma conta administradora delegada no Security Hub e aplique a política adequada para controle granular por região e por conta membro.

O Security Hub oferece os planos Essentials, Threat Analytics e Extended. Após a habilitação, os findings de exposição são criados e analisados imediatamente — porém, pode levar até 6 horas para que um finding de exposição para um recurso específico seja gerado.

Validando o deployment

A etapa final é confirmar que o Security Hub está configurado corretamente e avaliar os resultados em relação aos critérios de sucesso definidos no início:

• Validar políticas: verificar se as permissões para gerenciar contas membro e as restrições regionais estão configuradas corretamente.
• Validar integrações: confirmar que os tickets no ServiceNow ou Jira Cloud estão sendo criados corretamente, verificando se há um ID de ticket associado aos findings no console do Security Hub.
• Avaliar critérios de sucesso: determinar se os objetivos definidos no início do projeto foram alcançados.

Conclusão

O AWS Security Hub oferece uma abordagem estruturada para unificar e priorizar operações de segurança em nuvem. Seguindo as fases descritas — definição de critérios de sucesso, configuração, preparação e validação — é possível realizar uma avaliação completa aproveitando os períodos de teste gratuito sem incorrer em custos significativos.

Durante o POC, vale manter o foco nos critérios predefinidos, mas também estar aberto a benefícios ou desafios inesperados que possam surgir. Para dúvidas técnicas, o time de conta AWS pode apoiar durante todo o processo.

Recursos adicionais

• Guia do Usuário do AWS Security Hub
• Como priorizar riscos de segurança usando o AWS Security Hub
• Como fazer onboarding no AWS Security Hub
• Simplifique a resposta de segurança em escala com a automação do AWS Security Hub

Fonte

Optimize security operations through an AWS Security Hub POC (https://aws.amazon.com/blogs/security/how-to-develop-an-aws-security-hub-poc/)

O que mudou no AWS KMS

A AWS anunciou uma melhoria importante no Serviço de Gerenciamento de Chaves (KMS): a partir de agora, o serviço registra automaticamente o último uso criptográfico de cada chave KMS. Isso elimina a necessidade de consultar e analisar logs manualmente para descobrir quando uma chave foi utilizada pela última vez.

Para equipes de segurança e conformidade, essa visibilidade é um ganho real no dia a dia. Antes, identificar se uma chave estava ativa ou abandonada exigia cruzar dados do AWS CloudTrail de forma manual — um processo trabalhoso e sujeito a erros.

O que é possível visualizar

Com o novo recurso, é possível consultar, diretamente pelo console de gerenciamento do AWS KMS ou via API, as seguintes informações sobre cada chave:

• O timestamp da última operação criptográfica realizada;
• O tipo de operação que foi executada;
• O ID do evento no AWS CloudTrail associado àquela operação.

Casos de uso práticos

A AWS destaca três aplicações diretas para esse novo recurso:

• Identificar chaves sem uso para limpeza e organização do ambiente;
• Confirmar que chaves críticas estão sendo usadas ativamente, o que é essencial para auditorias de conformidade;
• Rastrear como as chaves são utilizadas em conjunto com o AWS CloudTrail, facilitando investigações e revisões de segurança.

Proteção contra exclusão acidental

Além da visibilidade, a atualização traz uma nova condition key chamada kms:TrailingDaysWithoutKeyUsage. Ela permite criar políticas que protegem chaves usadas recentemente contra exclusão acidental — ou seja, é possível configurar uma regra que impeça a remoção de qualquer chave que tenha sido utilizada nos últimos N dias.

Esse tipo de proteção baseada em política reduz o risco operacional em ambientes onde múltiplas equipes gerenciam chaves, tornando o controle mais robusto sem depender apenas de processos manuais.

Disponibilidade

O recurso já está disponível em todas as regiões AWS onde o KMS opera, incluindo as regiões comerciais globais, as regiões AWS GovCloud (US) e as regiões AWS China. Para mais detalhes técnicos, a documentação oficial traz um guia completo sobre como determinar o uso passado de uma chave KMS no AWS KMS Developer Guide.

Fonte

AWS KMS now tracks last usage of all KMS keys (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-kms-tracks-last-usage-kms-keys/)

O que as políticas IAM realmente conseguem controlar?

Quem trabalha com segurança na AWS já se deparou com perguntas do tipo: “Consigo usar uma SCP do AWS Organizations para bloquear a criação de security groups que permitem tráfego de 0.0.0.0/0?” ou “Dá para impedir o upload de objetos no S3 que não estejam criptografados?” ou ainda “Posso bloquear funções Lambda com mais de 512 MB de memória alocada?”

Algumas dessas situações são perfeitamente controláveis via políticas Gerenciamento de Identidade e Acesso (IAM). Outras, simplesmente não são. A diferença está em um princípio fundamental da autorização na AWS: as políticas tomam decisões com base nas informações disponíveis no contexto de autorização no momento da chamada de API. Se a informação não estiver nesse contexto, a política não tem como avaliá-la.

A AWS publicou um post detalhado no blog de segurança explicando exatamente como usar o AWS Service Authorization Reference para descobrir o que é ou não controlável por políticas — e o que fazer quando as políticas não são suficientes.

Como funciona o contexto de autorização na AWS

Toda vez que uma requisição é feita à AWS — seja pelo console, pela Interface de Linha de Comando (AWS CLI) ou por um SDK — o serviço que recebe a requisição monta um contexto de requisição com as informações sobre aquela operação. É esse contexto que será usado para avaliar as políticas.

Esse contexto segue o modelo PARC, com quatro componentes:

• Principal: quem está fazendo a requisição, incluindo atributos como tags e contexto de sessão
• Action (Ação): a operação de API solicitada (por exemplo, s3:PutObject ou ec2:RunInstances)
• Resource (Recurso): o recurso AWS de destino, identificado pelo ARN (Nome de Recurso da Amazon)
• Condition (Condição): contexto adicional disponível no momento da requisição, como endereço IP, horário, parâmetros de criptografia, status de MFA (Autenticação Multifator) e atributos específicos do serviço

Para ilustrar, veja como seria o contexto de uma requisição de upload de objeto no Amazon S3:

Principal: AIDA123456789EXAMPLE
Action: s3:PutObject
Resource: arn:aws:s3:::my-bucket/documents/samplereport.pdf
Condition:
  aws:PrincipalTag/Department=Finance
  aws:RequestedRegion=us-east-1
  aws:SourceIp=x.x.x.x
  aws:MultiFactorAuthPresent=true
  s3:x-amz-server-side-encryption=AES256
  s3:x-amz-storage-class=STANDARD_IA

Repare que o contexto inclui o método de criptografia e a classe de armazenamento especificados — e isso significa que uma política pode avaliar esses atributos. Por outro lado, o conteúdo real do arquivo, o tamanho do objeto ou padrões de dados internos não fazem parte do contexto, portanto não podem ser avaliados por políticas IAM.

O Service Authorization Reference: a fonte definitiva

O Service Authorization Reference é a documentação oficial da AWS que lista, para cada serviço, quais ações podem ser controladas por políticas, quais tipos de recursos podem ser alvos dessas ações e — o mais importante — quais condition keys (chaves de condição) estão disponíveis para cada ação.

As chaves de condição se dividem em duas categorias:

• Chaves de condição globais: aplicáveis a qualquer serviço AWS (como aws:SourceIp, aws:PrincipalTag, etc.)
• Chaves de condição específicas de serviço: definidas para uso com um serviço específico (como s3:x-amz-server-side-encryption ou ec2:InstanceType)

A regra é simples: se a informação que você quer controlar não aparece como uma chave de condição nessa documentação, você não conseguirá controlá-la apenas com políticas IAM.

Como usar o Service Authorization Reference na prática

O processo para verificar se um requisito pode ser atendido por políticas IAM é direto:

• Acesse a página do serviço específico no Service Authorization Reference — por exemplo, ações, recursos e chaves de condição para o Amazon S3
• Localize a ação que você quer controlar (seja preciso, pois diferentes ações têm diferentes chaves disponíveis)
• Examine a coluna de chaves de condição para aquela ação
• Se a informação que você precisa não estiver listada como chave de condição, uma política IAM não será suficiente

Como exemplo, ao examinar a ação RunInstances do Amazon Elastic Compute Cloud (Amazon EC2) na seção do EC2 no Service Authorization Reference, é possível ver que diferentes tipos de recursos têm chaves de condição diferentes. Para o tipo de recurso instance*, estão disponíveis chaves como ec2:InstanceType, ec2:EbsOptimized e aws:RequestTag/. Para network-interface*, há chaves como ec2:Subnet, ec2:Vpc e ec2:AssociatePublicIpAddress. O reference completo lista dezenas de chaves de condição para os vários tipos de recursos afetados pelo RunInstances.

Acesso programático ao Service Authorization Reference

Além da documentação em formato legível, a AWS disponibiliza o Service Authorization Reference em formato JSON para automação de fluxos de trabalho de gerenciamento de políticas. Para detalhes sobre a estrutura JSON e definições dos campos, consulte a documentação sobre acesso programático às informações simplificadas de serviços AWS. Desenvolvedores também podem usar o IAM MCP Server para operações IAM com assistentes de IA, gerenciando usuários, funções, políticas e permissões seguindo boas práticas de segurança.

Exemplos práticos: o que é possível controlar com políticas IAM

Exemplo 1: Exigir criptografia AES-256 em uploads no S3

No Service Authorization Reference do Amazon S3, a chave de condição s3:x-amz-server-side-encryption está disponível para a ação s3:PutObject. Isso significa que é possível criar uma política que bloqueie uploads sem criptografia AES-256:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    }
  ]
}

Essa é uma política baseada em recurso que pode ser aplicada diretamente no bucket S3. Ela nega qualquer requisição PutObject que não especifique criptografia AES-256.

Exemplo 2: Restringir tipos de instância EC2 por centro de custo

No Service Authorization Reference do Amazon EC2, a chave ec2:InstanceType está disponível para a ação ec2:RunInstances. Combinando essa chave com a chave global aws:PrincipalTag/tag-key, é possível criar uma política baseada em identidade que aplica restrições diferentes dependendo do centro de custo do usuário:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDevInstanceTypes",
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/CostCenter": "Development"
        },
        "StringLike": {
          "ec2:InstanceType": "t3.*"
        }
      }
    },
    {
      "Sid": "AllowProdInstanceTypes",
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/CostCenter": "Production"
        },
        "StringLike": {
          "ec2:InstanceType": [
            "m5.*",
            "c5.*",
            "r5.*"
          ]
        }
      }
    }
  ]
}

Com essa política, usuários com a tag CostCenter=Development só podem lançar instâncias T3 (mais econômicas), enquanto usuários de produção têm acesso às famílias M5, C5 e R5. Essa abordagem permite controle de custos dinâmico com base na identidade do solicitante. Atenção: recursos adicionais são necessários na política IAM para lançar instâncias EC2 com sucesso — consulte a documentação de lançamento de instâncias para a lista completa.

Exemplo 3: Controle de acesso granular no DynamoDB por nome de usuário

O Service Authorization Reference do Amazon DynamoDB expõe valores de chave de partição no contexto de autorização para as ações GetItem, PutItem e UpdateItem. Isso permite criar uma política em que cada usuário só acessa os itens onde a chave de partição corresponde ao seu próprio nome de usuário:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/UserProfiles",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${aws:username}"]
        }
      }
    }
  ]
}

Com essa política, se a usuária alice tentar acessar um item com chave de partição bob, a requisição será negada automaticamente.

Cenários que exigem mais do que políticas IAM

Alguns requisitos de segurança simplesmente não podem ser atendidos apenas com políticas IAM — e o Service Authorization Reference é a ferramenta certa para descobrir isso antes de perder tempo tentando.

Cenário 1: Bloquear criação de regras de security group com 0.0.0.0/0 na porta 22

A ação responsável por adicionar regras de entrada em security groups é a ec2:AuthorizeSecurityGroupIngress. Ao consultar o Service Authorization Reference do Amazon EC2 e examinar as chaves de condição disponíveis para a ação AuthorizeSecurityGroupIngress, encontramos apenas:

• aws:ResourceTag/${TagKey}: filtra por tag do recurso
• ec2:ResourceTag/${TagKey}: filtra por tag do recurso EC2
• ec2:SecurityGroupID: filtra pelo ID do security group
• ec2:Vpc: filtra pela VPC

Não há nenhuma chave de condição para blocos CIDR, números de porta ou protocolos. O contexto de autorização simplesmente não inclui essas informações — portanto, políticas IAM não conseguem controlar esses atributos.

Solução alternativa: usar uma abordagem reativa com o AWS Config e a regra gerenciada INCOMING_SSH_DISABLED para detectar regras excessivamente permissivas. Também é possível combinar o Amazon EventBridge com Lambda para notificar a equipe de segurança ou reverter automaticamente a configuração não conforme. Para mais detalhes, a AWS publicou um guia sobre como reverter automaticamente e receber notificações sobre alterações em security groups da VPC.

Cenário 2: Impedir criação de funções Lambda com mais de 512 MB de memória

Seguindo a mesma metodologia, ao consultar o Service Authorization Reference do AWS Lambda e examinar as chaves de condição disponíveis para a ação CreateFunction com o tipo de recurso function*, encontramos apenas chaves como lambda:CodeSigningConfigArn, lambda:Layer e lambda:VpcIds. Não existe nenhuma chave de condição para alocação de memória, timeout, armazenamento efêmero ou seleção de runtime.

Soluções alternativas:

• Usar uma abordagem de política como código (PaC) com AWS CloudFormation Hooks — veja o guia prático introdução à política como código
• Usar o AWS Service Catalog para disponibilizar configurações pré-aprovadas de Lambda
• Aplicar a regra do AWS Config LAMBDA_FUNCTION_SETTINGS_CHECK para detectar funções não conformes

Princípios para trabalhar com políticas IAM de forma eficaz

Com base no que a AWS detalhou, vale reforçar alguns pontos fundamentais:

• Políticas controlam o que está no contexto de autorização, não todos os parâmetros visíveis na documentação de API
• O Service Authorization Reference é a fonte definitiva: se algo não está listado como chave de condição, não é controlável via políticas
• Ações diferentes têm contextos diferentes, mesmo dentro do mesmo serviço
• Abordagens alternativas existem: AWS Config, EventBridge e controles específicos de serviços cobrem o que as políticas não alcançam
• Segurança em camadas é essencial: combine controles preventivos, detectivos e responsivos para uma defesa em profundidade eficaz

Próximos passos recomendados

Para quem quer aprofundar o conhecimento em políticas IAM, a AWS sugere explorar o simulador de políticas IAM para testar e depurar políticas, ler sobre tipos de políticas IAM e quando usar cada uma, e assistir ao vídeo Entendendo a linguagem de políticas IAM da AWS: elementos, avaliação e boas práticas.

O ponto central é que as políticas IAM são ferramentas poderosas de prevenção, mas a segurança eficaz na AWS não depende de um único controle perfeito — ela vem da combinação inteligente de medidas preventivas, detectivas e responsivas.

Fonte

Can I do that with policy? Understanding the AWS Service Authorization Reference (https://aws.amazon.com/blogs/security/can-i-do-that-with-policy-understanding-the-aws-service-authorization-reference/)

O risco quântico que já exige ação hoje

Computadores quânticos suficientemente poderosos ainda não existem, mas a ameaça que eles representam para a criptografia convencional já é real — e precisa ser endereçada agora. O motivo é um vetor de ataque chamado coleta agora, decifra depois (HNDL — Harvest Now, Decrypt Later): adversários capturam tráfego cifrado hoje e guardam para decifrar no futuro, quando tiverem acesso a hardware quântico capaz de quebrar os algoritmos assimétricos tradicionais.

É dentro desse contexto que a AWS vem executando seu plano de migração para criptografia pós-quântica (PQC). Parte central desse plano é garantir que os clientes consigam atualizar o lado cliente de suas cargas de trabalho para suportar confidencialidade resistente a computadores quânticos — e a AWS reconhece que essa é uma responsabilidade compartilhada, descrita no modelo de responsabilidade compartilhada de PQC.

O que mudou no AWS Secrets Manager

O AWS Secrets Manager utiliza SSL/TLS para comunicação com recursos AWS, suportando TLS 1.2 e 1.3 em todas as regiões. A novidade é que o serviço agora habilita e prefere, por padrão, a troca de chaves híbrida pós-quântica nas conexões TLS iniciadas pelos clientes que suportam essa capacidade.

A abordagem híbrida pós-quântica combina criptografia tradicional (como X25519) com algoritmos pós-quânticos (ML-KEM) para estabelecer conexões TLS. Isso garante proteção tanto contra ataques clássicos atuais quanto contra ameaças futuras de computadores quânticos.

Vale destacar: os segredos em repouso já estavam protegidos por chaves gerenciadas pelo AWS Key Management Service (AWS KMS). A criptografia simétrica, quando bem implementada, é considerada resistente a computadores quânticos. A vulnerabilidade quântica recai sobre a criptografia assimétrica — exatamente o que é usado na troca de chaves TLS. Para aprofundar o tema, a AWS disponibilizou a sessão AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.

Quais clientes já suportam a troca de chaves híbrida por padrão

A AWS anunciou que os seguintes clientes do Secrets Manager já habilitam e preferem a troca de chaves pós-quântica ao iniciar conexões:

• Secrets Manager Agent (v2.0.0 ou superior)
• AWS Lambda extension (versão 19 ou superior)
• Secrets Manager CSI Driver (v2.0.0 ou superior)

Para clientes baseados em SDK, a troca de chaves híbrida pós-quântica está disponível nas versões listadas abaixo. Os requisitos variam por linguagem, versão e sistema operacional:

• AWS SDK for Rust: habilitado por padrão em versões lançadas após 29 de agosto de 2025
• AWS SDK for Go: habilitado por padrão no Go v1.24 ou superior
• AWS SDK for Node.js: habilitado por padrão no Node.js v22.20 e v24.9.0 ou superior
• AWS SDK for Kotlin: habilitado por padrão no Linux (v1.5.78 ou superior)
• AWS SDK for Python: depende do OpenSSL fornecido pelo sistema operacional — exige OpenSSL 3.5 ou superior instalado
• AWS SDK for Java v2: requer o cliente HTTP AWS CRT com a flag postQuantumTlsEnabled configurada como true

As bibliotecas de cache do Secrets Manager são construídas sobre os SDKs e herdam o comportamento de TLS deles. Para Java, tanto a flag do driver JDBC quanto a flag de cache Java precisam ser habilitadas para ativar a troca de chaves híbrida.

Quando o endpoint do serviço Secrets Manager detecta que o cliente anuncia suporte à troca de chaves pós-quântica durante o handshake TLS, ele a seleciona automaticamente. Atualizar para as versões listadas é a única ação necessária.

Como verificar se suas conexões estão usando a troca de chaves híbrida

Para a maioria dos clientes, não será necessário monitoramento contínuo após a atualização. No entanto, equipes de segurança e compliance podem querer confirmar que as chamadas de API do Secrets Manager estão de fato negociando a troca de chaves híbrida. A verificação pode ser feita tanto no lado servidor, via AWS CloudTrail, quanto no lado cliente, com ferramentas como Wireshark ou as ferramentas de desenvolvedor dos navegadores.

Fonte

Protecting your secrets from tomorrow’s quantum risks (https://aws.amazon.com/blogs/security/protecting-your-secrets-from-tomorrows-quantum-risks/)

O que foi anunciado

A AWS anunciou que o Amazon Bedrock AgentCore Gateway e o AgentCore Identity passam a oferecer suporte a egresso de Nuvem Privada Virtual (VPC). Com isso, aplicações baseadas em agentes de IA conseguem se comunicar de forma segura e controlada com recursos que estão rodando dentro da VPC do próprio cliente — sem precisar expor esses recursos à internet pública.

Como o egresso de VPC funciona no AgentCore

O suporte ao egresso de VPC está disponível em duas modalidades: gerenciada e autogerenciada. A maioria dos casos de uso é atendida pela configuração gerenciada, que a AWS provisiona e mantém automaticamente. Para cenários de rede mais complexos, os clientes têm a opção de configurar seus próprios recursos do VPC Lattice — o serviço de rede gerenciada da AWS para comunicação entre serviços.

Um exemplo prático: com esse suporte, é possível invocar diretamente, a partir do AgentCore Gateway, servidores MCP hospedados em clusters do Elastic Kubernetes Service (EKS) que estejam rodando dentro de uma VPC privada. Isso amplia bastante as possibilidades de integração em arquiteturas corporativas que priorizam isolamento de rede.

Novidades no AgentCore Identity

O AgentCore Identity também recebe suporte a egresso de VPC, com foco específico em conectividade com Provedores de Identidade (IdPs) que rodam dentro da VPC do cliente. Esse suporte habilita duas capacidades importantes:

• Validação de tokens de acesso de entrada: permite verificar tokens emitidos por um IdP privado antes de autorizar requisições recebidas pelo agente.
• Obtenção de tokens para autenticação de saída: permite que o agente busque tokens diretamente no IdP privado para autenticar requisições que ele mesmo faz a outros serviços.

Resolução de DNS privado

Outro ponto relevante desse lançamento é o suporte à resolução de DNS privado para recursos de egresso VPC gerenciado, tanto no Gateway quanto no Identity. Isso significa que os recursos internos podem ser acessados pelos seus nomes de domínio privados, sem depender de IPs fixos ou configurações manuais adicionais.

Disponibilidade por região

O suporte a egresso de VPC no AgentCore Gateway e Identity está disponível em 14 regiões da AWS:

• US East (Norte da Virgínia e Ohio)
• US West (Oregon)
• Canada (Central)
• Asia Pacific (Mumbai, Seul, Singapura, Sydney e Tóquio)
• Europe (Frankfurt, Irlanda, Londres, Paris e Estocolmo)

Saiba mais e comece a usar

Para quem quiser se aprofundar nas capacidades de egresso de VPC, a AWS disponibiliza a documentação do AgentCore Gateway e a documentação do AgentCore Identity. Para dar os primeiros passos de forma prática, o ponto de entrada recomendado é o AgentCore CLI.

Fonte

Amazon Bedrock AgentCore Gateway and Identity support VPC egress (https://aws.amazon.com/about-aws/whats-new/2024/04/agentcore-gateway-identity-vpc/)

O problema que o Security Hub Extended tenta resolver

Equipes de segurança modernas enfrentam um desafio que vai muito além das ameaças em si: o peso operacional de gerenciar dezenas de fornecedores ao mesmo tempo. Negociações de contrato, múltiplos ciclos de cobrança, integrações manuais entre ferramentas — tudo isso consome tempo que deveria estar sendo dedicado à gestão de riscos reais.

Além disso, o modelo tradicional de aquisição de soluções de segurança forçava as organizações a assinar contratos plurianuais baseados apenas em testes de prova de conceito (PoC) e estimativas de uso anual. Ou seja, era preciso comprometer orçamento antes de validar se a solução funcionaria em escala real no ambiente da empresa.

É exatamente esse cenário que a AWS busca transformar com o AWS Security Hub Extended: uma oferta de segurança empresarial completa que reúne serviços nativos da AWS com soluções de parceiros cuidadosamente selecionados, entregando procurement unificado, cobrança consolidada e operações integradas.

O que é o Security Hub Extended

O AWS Security Hub já consolidava análise de ameaças do Amazon GuardDuty, gestão de vulnerabilidades do Amazon Inspector e descoberta de dados sensíveis do Amazon Macie, correlacionando esses sinais com findings de exposição para determinar risco geral, alcançabilidade e assumibilidade de recursos.

O Security Hub Extended vai além: ele estende essas operações de segurança unificadas para toda a organização, incluindo ambientes multicloud, on-premises e endpoints, por meio de soluções de parceiros curados integradas diretamente na experiência do Security Hub. Não há console separado para gerenciar — tudo acontece no mesmo lugar onde você já administra a segurança da sua organização.

Os parceiros do lançamento inicial foram selecionados pelos próprios clientes com base em valor comprovado, e incluem: 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk, Upwind e Zscaler.

Como começar com o Security Hub Extended

Para quem ainda não usa o Security Hub, o processo de onboarding é direto: basta acessar o AWS Management Console, buscar por Security Hub e seguir o fluxo de configuração inicial. O primeiro passo é designar uma conta de administrador delegado (Delegated Administrator — DA) da organização AWS, o que permite habilitar e gerenciar o Security Hub de forma centralizada em todas as contas e regiões AWS da organização a partir de um único ponto. Para mais detalhes sobre esse processo, a AWS disponibiliza a Introdução ao AWS Security Hub.

A partir da interface centralizada de configuração, é possível habilitar capacidades de detecção e resposta para toda a organização, definir configurações granulares por unidade organizacional ou conta-membro, selecionar regiões específicas e ativar ou desativar funcionalidades individualmente.

Quem já usa o Security Hub pode navegar diretamente para a seção do plano Extended. Ela fica no painel de navegação à esquerda, em Management, dentro da conta do administrador delegado — e só fica visível a partir dessa conta.

Entendendo riscos por meio de caminhos de ataque

Um dos recursos centrais do Security Hub é o motor de correlação de riscos, que identifica exposições potenciais ao cruzar ameaças, vulnerabilidades e configurações incorretas, revelando como esses fatores se conectam e podem levar ao comprometimento de recursos críticos.

A visualização de caminhos de ataque (attack path) expõe causas-raiz e o raio de explosão (blast radius) — ou seja, o impacto potencial caso um agente malicioso explore uma vulnerabilidade. Em vez de tratar sintomas isolados, a equipe de segurança pode focar na causa original do problema. Por exemplo, atualizar a configuração de um único security group pode eliminar um caminho de ataque inteiro, cortando todas as exposições downstream associadas a ele.

Descobrindo e assinando soluções de parceiros

O plano Extended traz soluções de terceiros curadas diretamente para dentro da experiência do Security Hub. Para adotar uma solução de parceiro, basta selecionar View Product para iniciar um fluxo automatizado de onboarding. Dependendo da solução, o usuário é direcionado ao console do parceiro ou recebe orientações para que o parceiro conduza o processo de ativação conforme o ambiente específico.

A cobrança só começa após a ativação completa na solução do parceiro, e já entra automaticamente na fatura unificada da AWS — sem necessidade de nenhuma ação adicional. Para quem já usa alguma das soluções dos parceiros, a transição para o Security Hub Extended não interrompe os serviços em uso. A diferença é que, em vez de receber faturas separadas para cada parceiro além do Amazon Inspector, GuardDuty e Security Hub, tudo passa a aparecer em uma única fatura consolidada.

Precificação transparente e sem compromissos iniciais

Diferente dos modelos tradicionais que exigem negociações longas, acordos de preço privados e compromissos plurianuais, o Security Hub Extended adota um modelo de preços mensais no modelo pay-as-you-go, com total transparência. Cada solução de parceiro exibe seus valores de forma clara. Como referência, o Cloud Security da Upwind custa US$ 3,75 por recurso por mês, e o Identity Security da Okta custa US$ 20 por usuário por mês.

Todas as ofertas do Security Hub Extended são elegíveis para os descontos do Programa de Desconto Empresarial (Enterprise Discount Program — EDP) da AWS, que são aplicados automaticamente. Se a organização já possui um acordo de desconto empresarial com a AWS, esses descontos se estendem automaticamente às soluções do Extended, reduzindo ainda mais o custo efetivo.

Após validar que uma solução funciona em escala no ambiente real, a organização pode então alinhar sua estratégia com fornecedores e assinar compromissos de longo prazo para obter condições de preço ainda mais favoráveis — mas sem a pressão de fazer isso antes de ter certeza.

Operações unificadas com OCSF

O Security Hub Extended unifica as operações de segurança ao consolidar findings da AWS e das soluções de parceiros em um único fluxo. Todos os findings utilizam o Open Cybersecurity Schema Framework (OCSF) — uma estrutura de esquema aberto para cibersegurança — garantindo consistência sem a necessidade de processos complexos de normalização, transformação ou pipelines de Extração, Transformação e Carga (ETL).

Na prática, ao implantar soluções como CrowdStrike, Noma e Upwind junto com Splunk e 7AI por meio do Security Hub Extended, os findings de segurança fluem automaticamente para o Security Hub e são roteados diretamente para o Splunk e o 7AI, todos no formato OCSF. O resultado é que a equipe de segurança pode se concentrar em responder a ameaças — não em gerenciar pipelines de dados ou integrações manuais.

A visão de segurança full-stack

O Security Hub Extended representa uma mudança na forma como as organizações descobrem, adquirem e consturam programas de segurança abrangentes. Em vez de gerenciar dezenas de relacionamentos com fornecedores, negociar contratos separados e integrar ferramentas díspares manualmente, a proposta é simplificar tudo em cinco pilares:

• Um processo de procurement centralizado via AWS
• Uma fatura com preços competitivos e transparentes no modelo pay-as-you-go
• Um console para operações de segurança unificadas
• Um canal de suporte para clientes do AWS Enterprise Support
• Um esquema (OCSF) para todos os findings de segurança

O objetivo declarado é reduzir o risco de segurança, melhorar a produtividade das equipes e criar uma abordagem mais coesa para operações de segurança em toda a empresa — abrangendo endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA e operações de segurança.

Disponibilidade

O Security Hub Extended está disponível globalmente em todas as regiões comerciais da AWS onde o Security Hub está disponível. A AWS também publicou um vídeo de demonstração explicando como o Security Hub Extended funciona na prática. Feedbacks podem ser enviados pelo AWS re:Post na categoria de Segurança ou por meio dos canais de suporte da AWS.

Fonte

A technical walkthrough of multicloud full-stack security using AWS Security Hub Extended (https://aws.amazon.com/blogs/security/a-technical-walkthrough-of-multicloud-full-stack-security-using-aws-security-hub-extended/)

O que mudou no AWS Network Firewall

A AWS anunciou expansões importantes nas Regras Gerenciadas (Managed Rules) do AWS Network Firewall, disponibilizadas por parceiros do AWS Marketplace. A novidade traz otimizações nos grupos de regras que agora suportam até 10 milhões de indicadores de nomes de domínio e até 1 milhão de endereços IP por grupo — um salto significativo em capacidade de proteção para workloads na nuvem.

O que cada parceiro está entregando

Três parceiros lideram as expansões anunciadas:

• Infoblox: amplia os indicadores de nomes de domínio para proteger workloads contra domínios de risco crítico e alto.
• Lumen: introduz novos grupos de regras focados em bloquear ataques de comando e controle (command and control).
• ThreatSTOP: adiciona regras gerenciadas para conformidade com sanções do Escritório de Controle de Ativos Estrangeiros — OFAC (Office of Foreign Assets Control) — e expande a cobertura de conformidade global com novas regras para sanções da União Europeia, Japão e Nações Unidas.

Por que isso importa para equipes de segurança

Essas melhorias permitem que as equipes acessem inteligência de ameaças mais rica e abrangente diretamente dentro do AWS Network Firewall, sem precisar gerenciar feeds de ameaças manualmente. O resultado prático é uma proteção mais rápida e precisa contra ameaças emergentes — seja para bloquear domínios maliciosos em escala, defender a infraestrutura contra ataques de comando e controle ou aplicar políticas de conformidade baseadas em sanções internacionais.

As regras gerenciadas ficam prontas para implantação e são atualizadas continuamente pelos parceiros, reduzindo a carga operacional das equipes de segurança.

Parceiros disponíveis e expansão regional

Além de Infoblox, Lumen e ThreatSTOP, as regras gerenciadas para o AWS Network Firewall também estão disponíveis por meio de outros parceiros do AWS Marketplace: Check Point, Fortinet, Rapid7 e Trend Micro.

A AWS também expandiu a disponibilidade regional dos grupos de regras do Marketplace para 9 novas regiões:

• Ásia-Pacífico (Jacarta)
• Ásia-Pacífico (Hyderabad)
• Ásia-Pacífico (Melbourne)
• Ásia-Pacífico (Malásia)
• Canadá Oeste (Calgary)
• Europa (Zurique)
• Europa (Espanha)
• Israel (Tel Aviv)
• México (Central)

Como começar

Para explorar as regras disponíveis, o caminho é acessar o console do AWS Network Firewall ou navegar pelas opções no AWS Marketplace. Para mais detalhes técnicos, a AWS disponibiliza a página do produto AWS Network Firewall e a documentação oficial do serviço.

Fonte

Enhancements to AWS Network Firewall Managed Rules from AWS Marketplace Partners (https://aws.amazon.com/about-aws/whats-new/2026/04/marketplace-managed-rules-enhancements/)

O que mudou no Amazon EC2

A AWS anunciou uma novidade importante para quem trabalha com o Amazon EC2: agora é possível controlar se os recursos provisionados por ofertas de instâncias gerenciadas aparecem ou não nas visualizações do console do EC2 e nas operações de listagem via API.

O que são instâncias gerenciadas no EC2

As Instâncias Gerenciadas do Amazon EC2 (Amazon EC2 Managed Instances) são instâncias provisionadas e administradas por um provedor de serviço designado — como o Amazon EKS, o Amazon ECS, o AWS Lambda ou o Amazon Workspaces. Nesses casos, a própria AWS assume a responsabilidade pela configuração, aplicação de patches e monitoramento de saúde dessas instâncias, além de outros recursos associados, como volumes EBS, snapshots e Interfaces de Rede.

Qual era o problema antes dessa mudança

Até agora, por padrão, esses recursos gerenciados apareciam misturados com os recursos autogerenciados nas respostas de API e nos respectivos consoles. Isso gerava confusão, já que esses recursos são de responsabilidade da AWS — e não do time que opera a conta. Ver instâncias, volumes e snapshots que você não criou e não precisa gerenciar no meio da sua lista de recursos não é o ideal para quem quer ter clareza sobre o que está sob sua responsabilidade.

Como funciona a nova configuração de visibilidade

Com as novas configurações de visibilidade de recursos gerenciados (Managed resource visibility settings), qualquer novo recurso gerenciado passa a ficar oculto por padrão nas visualizações do console e nas respostas de APIs como o describe-instances. Essa mudança foi pensada para alinhar melhor a experiência do usuário ao modelo de responsabilidade compartilhada — afinal, se a AWS gerencia aquele recurso, faz sentido que ele não polua a visão de quem está gerenciando os próprios recursos.

A configuração pode ser feita diretamente pelo console do Amazon EC2 ou por meio da AWS CLI. Para saber mais sobre como configurar essa funcionalidade, a AWS disponibiliza o Guia do Usuário do Amazon EC2 com todos os detalhes sobre as configurações de visibilidade de recursos gerenciados.

Por que isso importa para o seu ambiente

Para equipes que utilizam serviços como EKS ou ECS em larga escala, a quantidade de recursos gerenciados automaticamente pela AWS pode ser expressiva. Ter esses recursos aparecendo lado a lado com os recursos autogerenciados dificulta auditorias, inventários e até a identificação de anomalias. Com essa novidade, a visão do console e das APIs fica mais limpa e representativa do que realmente está sob gestão do time.

Fonte

Amazon EC2 announces Managed resource visibility settings (https://aws.amazon.com/about-aws/whats-new/2026/04/ec2-managed-resource-visibility/)

O que mudou no SageMaker Unified Studio

A AWS anunciou uma expansão importante para o Amazon SageMaker Unified Studio: a plataforma agora suporta replicação multi-região a partir do Centro de Identidade IAM (IAM Identity Center — IdC). Na prática, isso significa que administradores podem implantar domínios do SageMaker Unified Studio em regiões diferentes daquela onde a instância do IdC está configurada.

Antes dessa novidade, a dependência entre a região do IdC e a região dos domínios do SageMaker limitava a flexibilidade de arquiteturas distribuídas. Agora, essa restrição foi removida.

Por que isso importa para empresas reguladas

Essa capacidade foi desenvolvida especialmente para atender clientes corporativos de setores regulados, como serviços financeiros e saúde. Nesses segmentos, é comum que existam exigências rígidas sobre onde os dados podem ser armazenados e processados — as chamadas regras de residência de dados e soberania de dados.

Com a replicação multi-região do IdC, as organizações conseguem endereçar cenários como:

• Manter o IdC em uma região enquanto processam dados sensíveis em regiões exigidas por regulamentações;
• Suportar operações globais com gerenciamento centralizado de identidade;
• Atender requisitos de soberania de dados sem abrir mão das capacidades de Logon Único (SSO — Single Sign-On).

Como funciona na prática

Como administrador do SageMaker Unified Studio, é possível implantar domínios do SageMaker mais próximos da equipe de trabalho, respeitando as necessidades de residência de dados, enquanto o acesso via SSO continua funcionando de forma transparente para os usuários finais. O gerenciamento centralizado de identidade permanece intacto, independentemente de em qual região o domínio foi criado.

Disponibilidade e regiões suportadas

A replicação multi-região do IdC já está disponível em todas as regiões AWS onde o SageMaker Unified Studio é suportado, incluindo:

• Ásia-Pacífico (Tóquio)
• Europa (Irlanda)
• Leste dos EUA (Norte da Virgínia)
• Leste dos EUA (Ohio)
• Oeste dos EUA (Oregon)
• Europa (Frankfurt)
• América do Sul (São Paulo)
• Ásia-Pacífico (Seul)
• Europa (Londres)
• Ásia-Pacífico (Singapura)
• Ásia-Pacífico (Sydney)
• Canadá (Central)
• Ásia-Pacífico (Mumbai)
• Europa (Paris)
• Europa (Estocolmo)

Vale destacar que a região de São Paulo já está na lista, o que é uma boa notícia para times brasileiros que precisam atender exigências da LGPD e outras regulamentações locais.

Como começar

Para quem quer explorar essa funcionalidade, a AWS disponibilizou os recursos de documentação necessários. É possível consultar a documentação do SageMaker Unified Studio para dar os primeiros passos, e o Guia do Usuário do IAM Identity Center para entender como configurar o suporte multi-região do IdC.

Fonte

Amazon SageMaker now supports multi-region replication from IAM Identity Center (https://aws.amazon.com/about-aws/whats-new/2026/04/smus-identity-center/)

O que foi anunciado

A Amazon Web Services (AWS) acaba de disponibilizar o relatório de Controles de Sistema e Organização (SOC) 1 referente ao ciclo Inverno 2025. O documento cobre um período de 12 meses — de 1º de janeiro a 31 de dezembro de 2025 — e contempla 184 serviços dentro do escopo de auditoria.

Essa cobertura anual é importante porque oferece às empresas clientes uma visão contínua e consolidada sobre os controles internos da AWS relacionados a relatórios financeiros, facilitando o processo de conformidade e auditorias externas.

Por que o SOC 1 importa para sua empresa

O relatório SOC 1 é um documento de auditoria independente que atesta a eficácia dos controles internos de um provedor de serviços em nuvem no que diz respeito ao impacto sobre os relatórios financeiros dos clientes. Para empresas brasileiras que operam em setores regulados — como financeiro, saúde e varejo — ter acesso a esse relatório é frequentemente um requisito de compliance ou de auditorias internas.

Com 184 serviços cobertos, a AWS demonstra um compromisso crescente em ampliar o escopo dos seus programas de conformidade, ajudando as organizações a atenderem tanto requisitos arquiteturais quanto regulatórios.

Como acessar o relatório

O relatório SOC 1 Inverno 2025 está disponível para download pelo AWS Artifact, o portal de autoatendimento da AWS para acesso sob demanda a documentos de conformidade. Para obtê-lo, basta acessar o AWS Artifact no Console de Gerenciamento da AWS. Caso ainda não conheça a ferramenta, a AWS disponibiliza um guia introdutório em Primeiros Passos com o AWS Artifact.

Serviços no escopo

A lista completa dos serviços cobertos pelos programas de conformidade da AWS pode ser consultada na página de Serviços no Escopo. A AWS atualiza essa lista continuamente à medida que novos serviços são incluídos nos programas de auditoria.

Dúvidas e suporte

Clientes que tiverem perguntas sobre o relatório SOC 1 ou sobre os programas de conformidade da AWS podem entrar em contato com a equipe de conta AWS. Para uma visão geral de todos os programas de conformidade disponíveis, a AWS mantém uma página dedicada em Programas de Conformidade da AWS. Feedbacks e dúvidas específicas sobre compliance também podem ser enviados diretamente pela página de Contato da equipe de conformidade.

Fonte

Winter 2025 SOC 1 report is now available with 184 services in scope (https://aws.amazon.com/blogs/security/winter-2025-soc-1-report-is-now-available-with-184-services-in-scope/)