Novas Camadas de Proteção para Grupos de Auto Scaling
A AWS anunciou em janeiro de 2026 a introdução de novos mecanismos de proteção para o EC2 Auto Scaling, focando na prevenção de exclusões acidentais. Essas funcionalidades reforçam a segurança operacional e ajudam a manter a disponibilidade das aplicações.
Chave de Condição IAM para Controle de Exclusão Forçada
O primeiro mecanismo é a nova chave de condição de política autoscaling:ForceDelete. Essa chave funciona em conjunto com a ação DeleteAutoScalingGroup e permite controlar se o parâmetro ForceDelete pode ser utilizado durante a exclusão. Em outras palavras, ela determina se um grupo de Auto Scaling (ASG) pode ser removido enquanto ainda possui instâncias em execução.
Por meio de políticas IAM (Identity and Access Management), é possível restringir as permissões de exclusão usando essa chave de condição. Isso funciona como uma medida de segurança importante, evitando que exclusões acidentais removam grupos de Auto Scaling que ainda contêm instâncias ativas.
Proteção a Nível de Grupo
Além da chave de condição IAM, o EC2 Auto Scaling agora oferece proteção contra exclusão diretamente no nível do grupo. A nova configuração de proteção contra exclusão pode ser estabelecida tanto no momento da criação do grupo quanto em atualizações posteriores.
Esse recurso permite definir controles aprimorados com base na criticidade da sua carga de trabalho, oferecendo múltiplos níveis de proteção. Assim, é possível salvaguardar grupos críticos contra exclusões acidentais e garantir a continuidade das aplicações.
Defesa em Camadas contra Exclusões Indesejadas
A combinação da chave de condição autoscaling:ForceDelete com a proteção a nível de grupo cria uma defesa em múltiplas camadas. Dessa forma, você pode tanto restringir permissões IAM para operações de exclusão forçada quanto estabelecer controles aprimorados de proteção diretamente nos grupos de Auto Scaling críticos.
Disponibilidade e Próximos Passos
Os novos mecanismos estão disponíveis em todas as regiões da AWS Regions e em todas as regiões AWS GovCloud (US).
Certificação PCI PIN para AWS Payment Cryptography
A Amazon Web Services (AWS) finalizou com sucesso o processo de auditoria de conformidade conforme o padrão PCI PIN (Número de Identificação Pessoal da Indústria de Cartões de Pagamento) para seu serviço Payment Cryptography. Essa conquista representa um passo importante para organizações brasileiras que precisam processar pagamentos com cartão de forma segura e em conformidade com os requisitos regulatórios internacionais.
O serviço AWS Payment Cryptography permite que aplicações de processamento de pagamento utilizem módulos de segurança por hardware (HSMs) certificados como PCI PIN Transaction Security (PTS), totalmente gerenciados pela AWS com gerenciamento de chaves em conformidade com PCI PIN. Essa abordagem oferece maior flexibilidade para quem precisa implantar cargas de trabalho reguladas, reduzindo significativamente o esforço administrativo relacionado à conformidade.
Componentes principais do pacote de conformidade
O pacote de conformidade PCI PIN para AWS Payment Cryptography é composto por dois elementos essenciais:
Certificado de Conformidade (AOC)
O Certificado de Conformidade (Attestation of Compliance — AOC) demonstra que o AWS Payment Cryptography passou por validação bem-sucedida contra o padrão PCI PIN, sem nenhuma constatação de não-conformidade. Este documento valida que a infraestrutura e os processos de segurança atendem integralmente aos requisitos estabelecidos.
Responsabilidades na implementação
O Resumo de Responsabilidades PCI PIN fornece orientações claras para ajudar clientes a compreender suas próprias responsabilidades ao desenvolver e operar um ambiente altamente seguro para processamento de transações baseadas em PIN. Este documento é fundamental para que cada organização implemente adequadamente seus próprios controles.
Processo de avaliação e acesso aos relatórios
A AWS foi avaliada pela Coalfire, uma empresa qualificada como Qualified Security Assessor (QSA) independente. Os clientes podem acessar tanto o Certificado de Conformidade PCI PIN quanto o Resumo de Responsabilidades por meio do AWS Artifact, portal centralizado que reúne todos os documentos de conformidade relevantes.
Esta certificação é especialmente relevante para empresas brasileiras que operam em segmentos como fintech, varejo e serviços financeiros. A redução do overhead de conformidade permite que times de segurança dediquem seus esforços a iniciativas de inovação, em vez de gestar manualmente processos certificadores. Com a infraestrutura gerenciada e certificada pela AWS, as organizações podem focar em suas aplicações e processos de negócio, mantendo a segurança das transações financeiras como responsabilidade compartilhada claramente definida.
Escolhendo a Estratégia Certa para Gerenciar Segredos
Uma das perguntas mais comuns entre organizações que trabalham com a AWS diz respeito à centralização de segredos. Embora o debate frequentemente se concentre apenas no armazenamento centralizado, existem quatro dimensões importantes a considerar: criação, armazenamento, rotação e monitoramento de segredos. Cada uma dessas dimensões pode ser tratada de forma centralizada ou descentralizada, e a escolha tem implicações diretas na segurança, operação e escalabilidade da infraestrutura.
Não existe uma solução única que funcione para todas as organizações. A melhor estratégia depende da estrutura operacional, requisitos de segurança e capacidades técnicas de cada empresa. Neste artigo, exploramos os benefícios e desvantagens de cada abordagem.
Criação Centralizada de Segredos
Quando uma organização opta pela criação centralizada de segredos, o foco geralmente está em implementar práticas modernas de DevOps que automatizam e padronizam a implantação. Muitas empresas têm investido em plataformas internas de desenvolvedor, que utilizam o conceito de “caminhos de ouro” (golden paths) para permitir que desenvolvedores façam implantação em modelo de autoatendimento através de infraestrutura como código (IaC).
Essas plataformas oferecem templates pré-aprovados que implementam as melhores práticas da organização. Uma equipe de engenharia de plataforma central mantém esses caminhos, garantindo conformidade com padrões corporativos. Ferramentas como o AWS Service Catalog e projetos de código aberto como Backstage.io são exemplos de tecnologias que facilitam essa abordagem.
Um exemplo prático seria um caminho de ouro que padroniza a implantação de um microsserviço que acessa um banco de dados. Esse caminho poderia determinar que o serviço deve ser construído com o AWS Cloud Development Kit (AWS CDK), executado no Amazon Elastic Container Service (Amazon ECS), e que as credenciais de banco de dados sejam obtidas através do AWS Secrets Manager. A equipe de plataforma também pode incluir verificações automatizadas para garantir que a política de recurso do segredo apenas permite acesso ao papel (role) correto e que a criptografia utiliza chaves gerenciadas pelo cliente.
Nomenclatura e controle de acesso consistentes: Segredos criados centralmente podem seguir convenções de nomenclatura padronizadas baseadas em conta, workload, serviço ou classificação de dados. Isso facilita a implementação de padrões escaláveis como controle de acesso baseado em atributos (ABAC).
Verificações de privilégio mínimo em pipelines CI/CD: A criação de segredos dentro de pipelines IaC permite o uso de ferramentas como a AWS IAM Access Analyzer com a API check-no-new-access. Os pipelines podem ser templizados, permitindo que equipes individuais se beneficiem dos padrões organizacionais.
Colaboração entre engenharia de plataforma e segurança: Essa transição permite que equipes de segurança trabalhem em conjunto com engenharia de plataforma para incorporar segurança por padrão nos caminhos de ouro, em vez de implementá-la posteriormente.
Desvantagens da Criação Centralizada
Requer investimento significativo em tempo e recursos para construir e manter plataformas de desenvolvedor dedicadas.
É necessário manter bibliotecas de caminhos de ouro apropriados para os casos de uso da organização, o que pode ser inviável dependendo do tamanho.
Os caminhos de ouro precisam acompanhar novas features dos serviços subjacentes. Se um serviço recebe uma atualização importante, os desenvolvedores precisam esperar pela inclusão dessa feature nos templates existentes.
Criação Descentralizada de Segredos
Em um modelo descentralizado, as equipes de aplicação são donas dos templates IaC e mecanismos de implantação em suas próprias contas. Cada equipe opera de forma independente, o que pode dificultar a aplicação de padrões padronizados como código.
Velocidade: Desenvolvedores conseguem se mover rapidamente com maior autonomia, já que não dependem de uma função central para criar novos segredos.
Flexibilidade: As equipes ainda podem utilizar recursos como a API check-no-new-access, mas fica a critério delas implementar essas verificações em seus pipelines.
Desvantagens da Criação Descentralizada
Falta de padronização: Sem mecanismos centrais de criação templizada, fica mais difícil aplicar convenções consistentes de nomenclatura e tagging.
Inconsistência em controles de acesso: Políticas de recurso e controles de acesso podem variar significativamente entre equipes.
Maior carga nos desenvolvedores: Equipes precisam gerenciar uma maior parte da infraestrutura e dos pipelines de implantação por conta própria.
Armazenamento Centralizado de Segredos
Algumas organizações optam por manter todos os segredos em uma conta central, enquanto outras preferem armazenar segredos nas mesmas contas onde os workloads operam. A escolha dessa estratégia depende dos tradeoffs operacionais e de segurança envolvidos.
Monitoramento e observabilidade simplificados: Manter todos os segredos em uma única conta facilita o monitoramento centralizado, com uma equipe dedicada controlando o acesso a esses recursos sensíveis.
Desvantagens do Armazenamento Centralizado
Overhead operacional adicional: Ao compartilhar segredos entre contas, é necessário configurar políticas de recurso em cada segredo que será compartilhado.
Custo adicional do AWS KMS: Para compartilhar segredos entre contas, é obrigatório usar chaves gerenciadas pelo cliente do AWS Key Management Service (AWS KMS). Embora isso forneça um nível adicional de controle de acesso, isso aumentará os custos segundo a precificação do AWS KMS, além de exigir políticas adicionais de manutenção.
Concentração elevada de dados sensíveis: Centralizar segredos aumenta o potencial de impacto em caso de acesso indevido ou erro de configuração.
Limites de quota: Antes de optar por centralizar segredos, é importante revisar as quotas de serviço da AWS para garantir que a organização não atingirá limites em produção.
Segredos gerenciados por serviços: Serviços como o Amazon Relational Database Service (Amazon RDS) e Amazon Redshift gerenciam segredos automaticamente, armazenando-os na mesma conta do recurso. Para manter uma estratégia centralizada usando esses segredos gerenciados, seria necessário centralizar também os recursos.
Muitas organizações já utilizam serviços nativos da AWS como AWS Security Hub, IAM Access Analyzer, AWS Config e Amazon CloudWatch para obter observabilidade centralizada em ambientes multi-conta, sem necessidade de manter todos os segredos em um único local.
Armazenamento Descentralizado de Segredos
Na abordagem descentralizada, os segredos vivem nas mesmas contas que os workloads que precisam acessá-los, criando uma separação natural entre diferentes aplicações e equipes.
Limites de conta como segmentação natural: As contas AWS fornecem isolamento por padrão. Acessar segredos de outra conta não é possível automaticamente, exigindo aprovação explícita tanto da política de recurso na conta de origem quanto da política IAM na conta de destino. Políticas de controle de recurso podem impedir completamente o compartilhamento de segredos entre contas.
Flexibilidade na escolha de chaves KMS: Se segredos não são compartilhados entre contas, as organizações podem optar entre usar chaves gerenciadas pelo cliente ou chaves gerenciadas pela AWS para criptografia.
Delegação de gerenciamento de permissões: Quando segredos estão na mesma conta das aplicações que os consomem, os donos das aplicações podem definir permissões granulares nas políticas de recurso dos segredos.
Desvantagens do Armazenamento Descentralizado
Auditoria e monitoramento complexos: Ferramentas de monitoramento precisam operar entre múltiplas contas para apresentar uma visão consolidada de conformidade.
Workflows de remediação automática mais complexos: Controles de detecção podem alertar sobre misconfigurations ou riscos relacionados a segredos, como quando um segredo é compartilhado fora dos limites organizacionais. Esses workflows são mais complexos em ambientes multi-conta, embora a AWS ofereça soluções como Automated Security Response on AWS.
Rotação Centralizada de Segredos
Quando a rotação é centralizada, uma equipe central gerencia e mantém as funções do AWS Lambda responsáveis pela rotação de segredos, oferecendo bibliotecas reutilizáveis para diferentes cenários.
Reutilização de funções de rotação: Equipes de aplicação podem reutilizar funções comuns desenvolvidas pela equipe central para diferentes tipos de banco de dados e aplicações SaaS, sem precisar desenvolver suas próprias soluções customizadas.
Logs gerenciados centralmente: Os logs das funções de rotação podem ser armazenados e acessados a partir de um local único, facilitando investigações e auditorias.
Desvantagens da Rotação Centralizada
Cenários adicionais de acesso entre contas: Funções Lambda na conta central precisam de permissões para criar, atualizar, deletar e ler segredos nas contas das aplicações, aumentando o overhead operacional.
Limites de quota: Ao centralizar essa função em escala, é importante verificar as quotas de serviço do Lambda para evitar gargalos em produção.
Rotação Descentralizada de Segredos
A rotação descentralizada é a abordagem mais comum, onde as funções de rotação vivem na mesma conta que o segredo que gerenciam.
Templização com customização: Desenvolvedores podem reutilizar templates de rotação, mas adaptá-los conforme necessário para seus casos de uso específicos.
Sem acesso entre contas: A rotação acontece integralmente dentro de uma única conta, eliminando complexidades de acesso cross-account.
Desvantagens da Rotação Descentralizada
Acesso centralizado aos logs: É necessário fornecer acesso centralizado ou federado aos logs das funções de rotação distribuídas em diferentes contas. Por padrão, Lambda envia automaticamente logs para CloudWatch Logs, que oferece diferentes formas de centralizar logs, cada uma com seus tradeoffs específicos.
Auditoria e Monitoramento Centralizados
Independentemente do modelo escolhido para criação, armazenamento e rotação, é altamente recomendado centralizar auditoria e monitoramento em ambientes multi-conta. A AWS oferece capacidades robustas para isso através da AWS Security Hub, que se integra com AWS Organizations para centralizar:
Descobertas das melhores práticas de segurança fundamentais relacionadas ao Secrets Manager
Descobertas do IAM Access Analyzer sobre acesso externo aos secrets
Descobertas do AWS Config sobre configurações de Secrets Manager
Descobertas de comportamento anômalo do Amazon GuardDuty
Nesse modelo, funções centralizadas ganham visibilidade organizacional, enquanto equipes individuais conseguem visualizar sua própria postura em nível de conta sem precisar ver a organização inteira. Além disso, usar trilhas organizacionais do AWS CloudTrail permite enviar todas as chamadas de API do Secrets Manager para uma conta de administração delegada centralizada.
Para organizações que não requerem auditoria centralizada, é possível configurar o acesso de forma que equipes individuais determinem quais logs coletar, alertas configurar e verificações implementar relacionadas aos seus segredos.
Vantagens da Abordagem Descentralizada
Flexibilidade: Equipes de desenvolvimento têm liberdade para escolher ferramentas de monitoramento, auditoria e logging que melhor se ajustem às suas necessidades.
Menos dependências: Equipes não precisam depender de funções centralizadas para implementar alertas e monitoramento.
Desvantagens da Abordagem Descentralizada
Overhead operacional: Diferentes equipes podem acabar implementando soluções similares de forma redundante.
Dificuldade em investigações multi-conta: Quando logs e monitoramento estão descentralizados, investigações que afetam múltiplas contas se tornam mais complexas.
Combinando Abordagens: O Caso do Serviço Financeiro
A maioria das organizações, na prática, escolhe uma combinação dessas abordagens para atender suas necessidades específicas. Um exemplo seria uma empresa de serviços financeiros com uma equipe central de segurança operando centenas de contas AWS, com centenas de aplicações isoladas em nível de conta:
Centraliza a criação de segredos, aplicando padrões corporativos de nomenclatura, tagging e controle de acesso
Descentraliza o armazenamento, usando contas AWS como limite natural de acesso e delegando controle aos donos das aplicações
Descentraliza o gerenciamento de ciclo de vida, permitindo que donos das aplicações gerenciem suas próprias funções de rotação
Centraliza a auditoria, utilizando AWS Config, Security Hub e IAM Access Analyzer para dar visibilidade à equipe central de segurança enquanto mantém controle descentralizado
Conclusão
Não existe uma estratégia única de gestão de segredos que funcione para todas as organizações. A arquitetura ideal depende dos requisitos específicos de segurança, modelo operacional e capacidades técnicas de cada empresa.
Os pontos principais a considerar são:
Escolha sua arquitetura baseado nos requisitos específicos de sua organização
Use automação e infraestrutura como código para reforçar controles de segurança, independentemente da abordagem escolhida
Implemente capacidades robustas de monitoramento e auditoria através dos serviços AWS para manter visibilidade em seu ambiente
Para aprofundar seus conhecimentos sobre o AWS Secrets Manager, considere explorar os recursos adicionais disponibilizados pela AWS, incluindo guias de migração, melhores práticas e templates de referência que facilitam a implementação de soluções seguras e bem-estruturadas.
A AWS reafirma conformidade com os padrões europeus de segurança C5
A AWS completou com sucesso o ciclo de auditoria de 2025 do Catálogo de Critérios de Conformidade em Computação em Nuvem (C5), com 183 serviços cobertos pelo escopo de conformidade. Este resultado reforça o alinhamento contínuo da empresa com os requisitos de segurança estabelecidos para provedores de nuvem, oferecendo aos clientes europeus maior confiança ao executar aplicações em suas regiões.
O programa C5 é um esquema de certificação respaldado pelo governo alemão, desenvolvido pelo C5. Desde sua introdução em 2016, a AWS tem mantido conformidade com seus requisitos. O C5 auxilia organizações a demonstrar segurança operacional contra ameaças cibernéticas comuns ao utilizar serviços em nuvem.
Escopo da auditoria e novos serviços incorporados
Auditores independentes de terceiros avaliaram a AWS no período entre 1º de outubro de 2024 e 30 de setembro de 2025. O relatório de conformidade C5 detalha o status de alinhamento tanto para critérios básicos quanto adicionais do programa.
Cinco novos serviços foram adicionados ao escopo C5 da AWS neste ciclo:
O relatório de 2025 abrange as seguintes regiões da AWS: Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Milão), Europa (Paris), Europa (Estocolmo), Europa (Espanha), Europa (Zurique) e Ásia-Pacífico (Singapura).
Acessando o relatório de conformidade
Os clientes podem fazer download do relatório C5 completo através do AWS Artifact no Console de Gerenciamento da AWS, um portal de autoatendimento que oferece acesso sob demanda a relatórios de conformidade. Para quem está começando, a AWS disponibiliza um guia de início com AWS Artifact.
A segurança e conformidade na nuvem funcionam sob um modelo de responsabilidade compartilhada entre a AWS e seus clientes. Quando organizações transferem seus sistemas e dados para a nuvem, as responsabilidades de segurança são divididas entre o cliente e o provedor de nuvem. Compreender este modelo é essencial para implementar estratégias eficazes de proteção. Mais detalhes estão disponíveis no Modelo de Responsabilidade Compartilhada de Segurança da AWS.
Clientes com dúvidas ou feedback sobre o relatório C5 podem entrar em contato com seu time de contas da AWS. A equipe de conformidade da AWS também está disponível através da página de contato para consultas adicionais.
A Amazon Web Services (AWS) expandiu sua certificação GSMA Scheme de Acreditação de Segurança para Gerenciamento de Assinaturas (SAS-SM) para quatro novas regiões globais. Simultaneamente, duas regiões que já possuíam essa certificação passaram pelo processo de renovação.
As quatro regiões que receberam a certificação GSMA SAS-SM pela primeira vez são: US West (Oregon), Europe (Frankfurt), Asia Pacific (Tokyo) e Asia Pacific (Singapore). Além disso, a AWS renovou as certificações das regiões US East (Ohio) e Europe (Paris). Todas essas certificações têm escopo em Operações e Gerenciamento de Data Center (DCOM) e foram validadas por auditores independentes selecionados pela GSM Association (GSMA), com validade até outubro de 2026.
O Significado da Certificação SAS-SM para o Mercado
Rastreabilidade e Conformidade
A certificação GSMA SAS-SM representa um marco importante na conformidade de segurança para provedores de nuvem. O escopo DCOM (Operações e Gerenciamento de Data Center) garante que os ambientes foram avaliados segundo critérios rigorosos de segurança estabelecidos globalmente. O certificado de conformidade, que comprova que a AWS atende aos padrões GSMA, está disponível nos sites tanto da GSMA quanto da AWS.
Herança de Controles para ISVs
Desde que o US East (Ohio) obteve a certificação GSMA em setembro de 2021 e o Europe (Paris) em outubro de 2021, diversos fornecedores independentes de software (ISVs) têm se beneficiado da herança dos controles de conformidade SAS-SM DCOM da AWS. Isso permite que essas empresas construam serviços de gerenciamento de assinaturas ou eSIM (módulo de identidade de assinante incorporado) compatíveis com GSMA.
Para líderes de mercado consolidados, essa abordagem reduz a dívida técnica enquanto mantém a escalabilidade e o desempenho esperados pelos clientes. Para startups que inovam com soluções de eSIM, a oportunidade é ainda mais valiosa: podem acelerar seu tempo de entrada no mercado em vários meses em comparação com modelos de implantação locais.
A Revolução do eSIM no Mercado de Telecomunicações
Evolução Tecnológica
Até 2023, a transição de módulos de identidade de assinante físicos (SIMs) para eSIMs (módulos incorporados) era impulsionada principalmente por fabricantes de automóveis, wearables conectados à rede celular e dispositivos complementares como tablets. No entanto, o cenário está mudando rapidamente.
A GSMA promove as especificações SGP.31 e SGP.32, que padronizam protocolos e garantem compatibilidade e experiência de usuário consistente em todos os dispositivos eSIM. Com essas especificações, o escopo de aplicação do eSIM agora abrange smartphones, Internet das Coisas (IoT), casas inteligentes, IoT industrial e muito mais.
Demanda por Plataformas em Nuvem
Conforme mais fabricantes de dispositivos lançam modelos exclusivamente com eSIM, os clientes da AWS demandam soluções robustas e centradas em nuvem para gerenciamento de eSIM. Atualmente, mais de 400 operadoras de telecomunicações em todo o mundo oferecem suporte a serviços de eSIM para seus assinantes.
Hospedar plataformas de eSIM na nuvem permite que essas operadoras se integrem de forma eficiente com seus novos sistemas de suporte operacional (OSS) e sistemas de suporte comercial (BSS) baseados em nuvem. Essa integração é fundamental para modelos de operação modernos.
Cobertura Global e Resiliência
A expansão da AWS para certificar quatro novas regiões GSMA em novembro de 2025 demonstra seu compromisso contínuo com as expectativas elevadas estabelecidas para provedores de serviços em nuvem. Essa expansão também estende significativamente a cobertura global de infraestrutura certificada GSMA.
Com duas regiões certificadas GSMA em cada uma das três áreas geográficas principais — Estados Unidos, União Europeia e Ásia — os clientes podem agora construir soluções de eSIM com redundância geográfica. Essa abordagem melhora tanto a recuperação de desastres quanto a postura geral de resiliência dos sistemas.
A AWS mantém um canal aberto com sua comunidade de clientes e parceiros. Dúvidas técnicas ou feedback sobre conformidade GSMA podem ser direcionadas à equipe de conformidade por meio da página de contato.
A AWS anunciou o lançamento de 13 novas regras gerenciadas para o serviço AWS Config, ampliando as capacidades de conformidade e governança para ambientes em nuvem. Essas regras cobrem diferentes cenários de uso, desde validação de segurança até verificações operacionais e de durabilidade dos recursos.
Com essa expansão, os usuários agora conseguem pesquisar, descobrir, ativar e gerenciar essas novas regras diretamente pela interface do AWS Config. O grande diferencial é a possibilidade de implantar esses controles em toda a conta ou até mesmo em múltiplas contas da organização, facilitando a governança centralizada.
Principais capacidades das novas regras
Validação de conformidade em diferentes serviços
As 13 novas regras permitem avaliar a postura de segurança em diversos recursos AWS. Alguns exemplos incluem validações em Amazon Cognito User Pools, Amazon EBS Snapshots, AWS CloudFormation Stacks e outros serviços críticos da plataforma.
Cada regra foi desenhada para verificar configurações específicas que impactam a segurança, a disponibilidade e a conformidade regulatória dos ambientes.
Governança com Conformance Packs
Uma vantagem importante é a possibilidade de usar Conformance Packs — agrupamentos de regras que podem ser implantados em conta única ou em múltiplas contas da organização. Isso simplifica significativamente a governança multi-conta, permitindo padronização de políticas em toda a estrutura organizacional.
Lista de regras lançadas
As 13 novas regras gerenciadas disponibilizadas são:
Maior controle sobre criptografia em ambientes de análise de dados
A Amazon EMR Serverless recebeu uma atualização importante em suas capacidades de segurança. O serviço agora oferece suporte a chaves gerenciadas pelo cliente do Serviço de Gerenciamento de Chaves da AWS (AWS KMS – Key Management Service) para criptografar discos locais. Essa mudança é particularmente significativa para organizações que enfrentam requisitos regulatórios e de conformidade rigorosos, pois amplia as opções de encriptação além das chaves padrão pertencentes à AWS.
O que é o EMR Serverless
O Amazon EMR Serverless é uma modalidade de implantação dentro do Amazon EMR que simplifica o trabalho de engenheiros de dados e cientistas de dados. Com essa abordagem, é possível executar frameworks de análise de dados de código aberto sem precisar configurar, gerenciar ou dimensionar clusters e servidores manualmente. A solução abstrai grande parte da complexidade operacional, permitindo que os profissionais concentrem-se na análise em si.
Criptografia padrão e novas possibilidades
Anteriormente, os discos locais nos workers do EMR Serverless eram criptografados por padrão utilizando chaves de propriedade da AWS. Com esse novo recurso, clientes com necessidades estritas de regulamentação e conformidade podem agora criptografar discos locais com suas próprias chaves gerenciadas pelo KMS. Essas chaves podem residir na mesma conta ou em conta diferente da organização.
Flexibilidade na aplicação das chaves
A integração oferece dois níveis de granularidade para especificação da chave KMS gerenciada pelo cliente:
Nível de aplicação: você pode definir a chave no nível da aplicação EMR Serverless, onde ela se aplica a todas as cargas de trabalho submetidas naquela aplicação
Nível de execução: alternativamente, é possível especificar a chave para uma execução de job específica ou sessão interativa individual
Esse design flexível permite que organizações adaptem sua estratégia de criptografia conforme necessário, equilibrando centralização e controle granular.
Disponibilidade e compatibilidade
O novo recurso está disponível em todas as versões de EMR suportadas e em todas as regiões da AWS onde o Amazon EMR Serverless opera, incluindo AWS GovCloud (US) e regiões da China. Funciona tanto em aplicações EMR Serverless novas quanto em aplicações existentes, oferecendo compatibilidade retroativa.
Próximos passos
Para quem deseja implementar esse recurso, a AWS disponibiliza documentação específica sobre Criptografia de Discos Locais com Chaves KMS do Cliente no Guia do Usuário do Amazon EMR Serverless. A documentação contém detalhes técnicos, exemplos de configuração e orientações para diferentes cenários de uso.
A AWS anunciou a adição de duas capacidades importantes ao SageMaker Unified Studio: suporte a subscrições entre regiões e acesso baseado em funções IAM (Gerenciamento de Identidade e Acesso). Essas funcionalidades reforçam a proposta da plataforma de facilitar acesso a dados e melhorar a governança entre equipes distribuídas.
Subscrições entre Regiões
O SageMaker Unified Studio agora permite que você se inscreva em tabelas e visões do AWS Glue e Amazon Redshift publicadas em uma região diferente daquela onde seu projeto está localizado. Essa funcionalidade é especialmente valiosa para organizações com infraestrutura distribuída em múltiplas regiões da AWS.
A principal vantagem dessa capacidade é a quebra de silos de dados. Equipes espalhadas geograficamente ou divididas por linha de negócio conseguem acessar ativos de dados curados sem precisar replicar informações manualmente. Isso acelera fluxos de análise e reduz redundância operacional.
Subscrições Baseadas em Funções IAM
A segunda novidade elimina um intermediário importante no fluxo de acesso a dados. Você pode agora descobrir e solicitar acesso a dados através de subscrições baseadas em funções IAM, sem necessidade de um projeto do SageMaker Unified Studio. Isso simplifica o processo removendo uma camada administrativa e permitindo acesso direto aos dados através de papéis (roles) IAM.
Essa abordagem oferece maior flexibilidade: colaboradores conseguem solicitar acesso aos dados que precisam sem depender de estrutura de projeto, tornando o processo mais ágil e alinhado com práticas modernas de governança de identidade.
Como Começar
Para utilizar subscrições entre regiões, você pode acessar o SageMaker Unified Studio diretamente ou usar a Amazon DataZone API, SDK ou AWS CLI (Interface de Linha de Comando). As subscrições baseadas em funções IAM estão disponíveis via Amazon DataZone API e SDK.
Essas atualizações reforçam a abordagem da AWS em facilitar colaboração intra-organizacional mantendo controle granular de acesso. Organizações brasileiras que trabalham com múltiplas equipes em diferentes regiões encontram nessas funcionalidades uma forma de centralizar ativos de dados sem sacrificar autonomia de acesso.
A Amazon Web Services (AWS) disponibilizou os relatórios de Controles e Conformidade do Sistema e da Organização (SOC) 1, 2 e 3 referentes ao período Fall 2025. Esses relatórios cobrem 185 serviços diferentes ao longo de um período de 12 meses, compreendendo o intervalo de 1º de outubro de 2024 a 30 de setembro de 2025, oferecendo aos clientes um ano completo de garantia de conformidade.
A publicação desses relatórios reafirma o compromisso contínuo da AWS em atender às expectativas cada vez mais rigorosas impostas aos provedores de serviços em nuvem. Para as organizações brasileiras que utilizam plataforma, isso significa ter acesso a documentação técnica que atesta o cumprimento de padrões internacionais de segurança e governança.
Como Acessar os Relatórios
Relatórios SOC 1 e 2
Os relatórios SOC 1 e 2 do Fall 2025 podem ser baixados através do AWS Artifact no AWS Management Console. O AWS Artifact funciona como um portal de autoatendimento que oferece acesso sob demanda aos relatórios de conformidade da AWS. Para aprofundar-se no uso dessa ferramenta, você pode consultar o guia de introdução ao AWS Artifact.
Relatório SOC 3
O relatório SOC 3 encontra-se disponível na página de conformidade SOC da AWS. Diferentemente dos relatórios SOC 1 e 2, que são restritos, o SOC 3 é um relatório público que pode ser compartilhado amplamente dentro de uma organização.
Expansão Contínua de Serviços em Conformidade
A AWS mantém um esforço constante para incorporar novos serviços ao escopo de seus programas de conformidade, facilitando que os clientes atendam aos seus requisitos arquiteturais e regulatórios. É possível consultar a lista atualizada de todos os serviços cobertos pelos relatórios na página de serviços em conformidade.
Suporte e Recursos Adicionais
Clientes da AWS que possuam dúvidas ou feedback relacionados à conformidade SOC podem entrar em contato com seu time de contas AWS. Para explorar mais sobre os programas de conformidade e segurança oferecidos pela plataforma, recomenda-se consultar a seção dedicada aos programas de conformidade da AWS.
A AWS valoriza feedback e questões da comunidade. Dúvidas adicionais podem ser direcionadas à equipe de conformidade através da página de contato.
Cargas de trabalho envolvendo inteligência artificial generativa e aprendizado de máquina geram volumes massivos de dados. Para organizações brasileiras e globais, gerenciar esse crescimento exponencial enquanto mantém conformidade regulatória é um desafio complexo e cada vez mais urgente.
Embora o conceito de governança de dados não seja novo, pesquisas recentes revelam uma lacuna preocupante. Um estudo da Gartner com 300 executivos de TI mostrou que apenas 60% das organizações implementaram uma estratégia formal de governança de dados, deixando 40% ainda em fase de planejamento ou incertos por onde começar. Complementando esse cenário, uma pesquisa do MIT CDOIQ de 2024 com 250 diretores de dados revelou que apenas 45% identificam governança de dados como prioridade máxima.
Mesmo que a maioria das empresas reconheça a importância de estratégias de governança de dados, revisões regulares são essenciais para garantir que essas estratégias evoluam conforme as necessidades empresariais mudam, novos requisitos regulatórios surgem e tecnologias emergentes se consolidam.
Uma abordagem prática e automatizada
A Amazon Web Services (AWS) apresenta uma perspectiva estratégica e pragmática para implementar governança de dados, seja você começando do zero ou aprimorando uma estrutura existente. Este guia funciona em duas partes: a primeira (que você está lendo agora) aborda estratégia, framework de classificação e governança de marcação. A segunda parte explora arquitetura técnica e padrões de implementação com exemplos conceituais de código.
A abordagem da AWS se alinha em torno de três benefícios principais de governança de dados:
Classificar dados consistentemente e automatizar controles para melhorar qualidade
Conceder às equipes acesso seguro aos dados que realmente precisam
Monitorar conformidade automaticamente e identificar problemas rapidamente
Se você ainda não possui uma estratégia de governança estruturada, este artigo oferece um panorama dos serviços e ferramentas disponibilizados pela AWS para começar. Se já tem uma estratégia implementada, o conteúdo ajuda a avaliar sua efetividade e entender como a governança evolui com novas tecnologias.
Fundações necessárias antes de começar
Alicerces técnicos
Implementar governança de dados exige uma base técnica robusta. Comece com uma estrutura bem organizada do AWS Organizations para gerenciamento centralizado. Certifique-se de que o AWS CloudTrail e o AWS Config estão habilitados em todas as contas—você vai precisar deles para monitoramento e auditoria. Seu framework de AWS Identity and Access Management (IAM) deve já definir claramente funções e permissões.
Além desses serviços fundamentais, diversos serviços específicos da AWS suportam automação e imposição de controles, que serão explorados detalhadamente ao longo deste guia.
Prontidão organizacional
A implementação bem-sucedida de governança de dados vai além da tecnologia. Requer alinhamento claro e preparação organizacional em múltiplas dimensões:
Defina papéis e responsabilidades. Proprietários de dados classificam dados e aprovam solicitações de acesso. Equipes de plataforma gerenciam infraestrutura AWS e constroem automações, enquanto equipes de segurança estabelecem controles e monitoram conformidade. Equipes de aplicação então implementam esses padrões em seus fluxos diários.
Documente requisitos de conformidade. Liste as regulamentações que sua organização deve seguir—GDPR, PCI-DSS, SOX, HIPAA ou outras. Crie um framework de classificação de dados que se alinhe com riscos empresariais. Documente seus padrões de marcação e convenções de nomenclatura para que todos trabalhem de forma consistente.
Planeje a gestão de mudanças. Obtenha apoio executivo de líderes que entendem por que governança importa. Comece com projetos piloto para demonstrar valor antes de expandir para toda a organização. Invista em treinamento baseado em papéis e mantenha playbooks de governança atualizados. Estabeleça mecanismos de feedback para que equipes reportem problemas e sugiram melhorias.
Indicadores-chave de desempenho para monitorar
Para medir a efetividade de sua implementação de governança de dados, acompanhe as seguintes métricas essenciais:
Conformidade de marcação de recursos: Meta de 95%, medida por regras do AWS Config com monitoramento semanal, focando em recursos críticos e dados sensíveis
Tempo médio de resposta para problemas de conformidade: Menos de 24 horas para questões críticas, rastreado com métricas do CloudWatch e alertas automatizados
Redução de tarefas manuais de governança: Meta de 40% de redução no primeiro ano, medida pela adoção de workflows automatizados
Otimização de custos de armazenamento por classificação: Redução de 15–20% através de camadas inteligentes e políticas de ciclo de vida, monitoradas mensalmente
Fundação: Framework de classificação de dados
A classificação de dados é um passo fundamental na gestão de riscos de cibersegurança e em estratégias de governança. As organizações devem usar classificação de dados para determinar quais salvaguardas são apropriadas com base nos requisitos de proteção de cada categoria de informação.
Impacto Alto: Efeito adverso severo ou catastrófico nas operações, ativos ou indivíduos da organização
Impacto Moderado: Efeito adverso sério nas operações, ativos ou indivíduos da organização
Impacto Baixo: Efeito adverso limitado nas operações, ativos ou indivíduos da organização
Antes de implementar controles, estabelecer um framework claro de classificação é essencial. Esse framework funciona como a espinha dorsal de seus controles de segurança, políticas de acesso e estratégias de automação. Como exemplo prático, considere como uma empresa sujeita ao Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI-DSS) poderia classificar dados:
Nível 1 – Dados mais sensíveis: Registros de transações financeiras, dados PCI de clientes, propriedade intelectual. Controles: Criptografia em repouso e em trânsito, controles de acesso rigorosos, auditoria abrangente
Nível 2 – Dados para uso interno: Documentação interna, informações de negócios proprietárias, código de desenvolvimento. Controles: Criptografia padrão, controle de acesso baseado em papéis
Nível 3 – Dados públicos: Materiais de marketing, documentação pública, comunicados de imprensa. Controles: Verificações de integridade, controle de versão
Estruturando uma estratégia de marcação eficaz
Para auxiliar com classificação de dados e marcação, a AWS oferece o AWS Resource Groups, um serviço que permite organizar recursos AWS em grupos usando critérios que você define como tags. Se sua organização usa múltiplas contas AWS, o AWS Organizations suporta políticas de tags, que padronizam as marcas vinculadas aos recursos da organização.
Uma estratégia de marcação bem-projetada é fundamental para governança automatizada. Tags não apenas organizam recursos, mas também habilitam controles de segurança automatizados, alocação de custos e monitoramento de conformidade. A estratégia a seguir estrutura a automação:
Embora as políticas de tags do AWS Organizations forneçam uma base para marcação consistente, governança abrangente exige mecanismos adicionais de imposição, que serão explorados em detalhes na Parte 2.
Fluxo de trabalho de governança com tags
O processo de governança de tags segue um fluxo estruturado: a AWS valida tags quando você cria recursos. Recursos não conformes acionam remediação automática, enquanto recursos conformes são implantados normalmente. O monitoramento contínuo identifica variações em relação às suas políticas.
AWS CloudTrail: Registra cada chamada de API feita em suas contas AWS, criando um rastro completo de auditoria de quem fez o quê, quando e de onde
AWS Config: Monitora continuamente configurações de recursos e as avalia contra regras que você define. Quando encontra recursos não conformes, os marca para correção manual ou automática
Amazon CloudWatch: Agrega métricas, logs e eventos de todo o AWS para monitoramento em tempo real, dashboards e alertas automatizados em não conformidades
Automação e imposição
Amazon EventBridge: Sistema central de notificações que observa eventos específicos no ambiente AWS (como criação de um bucket S3) e dispara ações em resposta (como executar uma função Lambda para validar tags). Funciona como um mecanismo de automação “se isto acontecer, então faça aquilo”
AWS Lambda: Executa código de governança (validação de tags, controles de segurança, remediação) em resposta a eventos sem necessidade de gerenciar servidores
AWS Systems Manager: Automatiza tarefas operacionais em seus recursos AWS. Na governança, é usado primariamente para corrigir automaticamente recursos não conformes—por exemplo, se o AWS Config detecta um banco de dados não criptografado, o Systems Manager pode executar um script pré-definido para habilitar criptografia sem intervenção manual
Proteção de dados
Amazon Macie: Usa aprendizado de máquina para descobrir, classificar e proteger automaticamente dados sensíveis como informações de identificação pessoal (PII) em seus buckets S3
AWS Key Management Service (AWS KMS): Gerencia chaves de criptografia para proteger dados em repouso, essencial para classificações de dados com alto impacto
Análise e insights
Amazon Athena: Serviço de query serverless que analisa dados no Amazon S3 usando SQL—perfeito para consultar logs do CloudTrail e entender padrões de acesso
Padronização e ML
AWS Service Catalog: Cria catálogos de recursos pré-aprovados e conformes com governança que equipes podem implantar por autoatendimento
Amazon SageMaker: Oferece ferramentas especializadas para governança de operações de aprendizado de máquina, incluindo monitoramento de modelo, documentação e controle de acesso
Próximas etapas
Este primeiro artigo da série em duas partes estabeleceu os elementos fundacionais para implementar governança de dados na AWS, cobrindo frameworks de classificação de dados, estratégias efetivas de marcação e requisitos de alinhamento organizacional. Esses fundamentos servem como blocos construtivos para abordagens de governança escaláveis e automatizadas.
A Parte 2 focará em implementação técnica e padrões arquiteturais, incluindo fundações de monitoramento, controles preventivos e remediação automatizada. A discussão se estende a controles de segurança baseados em tags, automação de monitoramento de conformidade e integração de governança com estratégias de recuperação de desastres. Tópicos adicionais incluem controles de soberania de dados e governança de modelos de aprendizado de máquina com o Amazon SageMaker, suportados por exemplos de implementação da AWS.
