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.
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.
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.
Este artigo complementa a primeira parte sobre governança de dados na AWS, que abordou fundações estratégicas, frameworks de classificação e abordagens de marcação. Agora, veremos como implementar tecnicamente um framework de governança robusto através de padrões arquiteturais bem estabelecidos.
A governança de dados efetiva exige múltiplas camadas de controle trabalhando em conjunto. O processo começa com monitoramento, evolui para controles preventivos, passa por remediação automatizada e culmina em recursos avançados que garantem conformidade em ambientes complexos.
Os quatro pilares da implementação
A AWS apresenta uma abordagem progressiva que permite implementação incremental. Cada nível constrói sobre o anterior, permitindo validação contínua:
Fundação de monitoramento
O primeiro passo consiste em estabelecer uma linha de base sólida. Use AWS Config para rastrear conformidade de marcações em seus recursos, e configure painéis do Amazon CloudWatch para visibilidade em tempo real de sua postura de governança. Essa fundação permite compreender seu estado atual antes de implementar controles de força maior.
Controles preventivos
Depois da visibilidade inicial, implemente aplicação proativa. Implante funções AWS Lambda que validam marcações no momento da criação de recursos. Configure regras do Amazon EventBridge para disparar ações de conformidade em tempo real e estabeleça políticas de controle de serviço (Service Control Policies — SCPs) que criam barreiras de proteção em toda a organização, prevenindo implantação de recursos não conformes.
Remediação automatizada
Reduza intervenção manual configurando documentos de automação do AWS Systems Manager que respondem a violações de conformidade. Implante respostas automatizadas que corrigem problemas comuns como marcações faltantes ou criptografia inadequada. Estabeleça controles de segurança baseados em classificação que aplicam proteções apropriadas automaticamente conforme a sensibilidade dos dados.
Recursos avançados
Estenda o framework com recursos sofisticados. Implante controles de soberania de dados para garantir conformidade regulatória entre regiões, implemente gerenciamento de ciclo de vida inteligente para otimizar custos mantendo conformidade, e estabeleça sistemas abrangentes de monitoramento e relatório que ofereçam visibilidade clara aos stakeholders sobre a efetividade da governança.
Familiaridade com AWS CloudFormation ou Terraform, pois os exemplos usarão CloudFormation
Implementação de controles de marcação
Controles preventivos com funções Lambda
A validação de marcações no momento da criação de recursos previne implantação de recursos não conformes. Funções Lambda disparadas por eventos do AWS CloudTrail verificam marcações antes que recursos sejam criados:
def enforce_resource_tags(event, context):
required_tags = ['DataClassification', 'DataOwner', 'Environment']
# Extract resource details from the event
resource_tags = event['detail']['requestParameters'].get('Tags', {})
# Validate required tags are present
missing_tags = [tag for tag in required_tags if tag not in resource_tags]
if missing_tags:
# Send alert to security team
# Log non-compliance for compliance reporting
raise Exception(f"Missing required tags: {missing_tags}")
return {'status': 'compliant'}
As políticas de marcação do AWS Organizations estabelecem a base para consistência. Essas políticas definem formatos e valores padrão, garantindo consistência entre contas:
O controle de acesso baseado em marcações permite permissões detalhadas usando controle de acesso baseado em atributos (ABAC — Attribute-Based Access Control). Essa abordagem define permissões conforme atributos de recursos em vez de criar políticas IAM individuais:
Enquanto a implementação de governança em uma única conta é direta, a maioria das organizações opera em ambientes multi-conta. Implementar governança consistente em toda a organização exige controles adicionais:
Muitas organizações mantêm frameworks de governança para infraestrutura local. Estender esses frameworks para a AWS exige integração cuidadosa. Use o AWS Service Catalog para criar um portfólio de recursos que se alinhem com seus padrões de governança existentes, mantendo convenções de nomenclatura e controles compatíveis.
Automação de controles de segurança baseada em classificação
Após classificar dados, use essas classificações para automatizar controles de segurança. Use AWS Config para rastrear e validar que recursos estejam devidamente marcados através de regras definidas que avaliam configurações de recursos AWS. Para recursos não conformes, use AWS Systems Manager para automatizar o processo de remediação.
Com marcação adequada, implemente controles de segurança automatizados usando EventBridge e Lambda. Essa combinação cria infraestrutura eficiente em custos e escalável para aplicação de políticas de segurança baseadas em classificação de dados:
Requisitos de soberania e residência de dados ajudam na conformidade com regulações como GDPR. Implemente controles que restrinjam armazenamento e processamento de dados a regiões específicas da AWS:
AWSConfig:
ConfigRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: s3-bucket-region-check
Description: Checks if S3 buckets are in allowed regions
Source:
Owner: AWS
SourceIdentifier: S3_BUCKET_REGION
InputParameters:
allowedRegions:
- eu-west-1
- eu-central-1
Combine AWS Config para conformidade de recursos, CloudWatch para métricas e alertas, e Amazon Macie para descoberta de dados sensíveis, criando um framework robusto que detecta e responde automaticamente a questões de conformidade:
Figura 1: Arquitetura de monitoramento de conformidade — Imagem original — fonte: Aws
Essa arquitetura demonstra como os serviços da AWS trabalham em conjunto para monitoramento de conformidade. O AWS Config, CloudTrail e Macie monitoram recursos, o CloudWatch agrega dados de monitoramento, e alertas e painéis oferecem visibilidade em tempo real.
Implementação com CloudFormation
O seguinte template CloudFormation implementa esses controles:
Estratégias modernas de governança frequentemente utilizam data lakes para controle centralizado. A AWS oferece solução abrangente através do Modern Data Architecture Accelerator (MDAA), que permite implantar rapidamente arquiteturas de plataforma de dados com controles de segurança e governança integrados.
Figura 2: Arquitetura de referência do MDAA — Imagem original — fonte: Aws
Compreender e gerenciar padrões de acesso é essencial para governança efetiva. Use CloudTrail e Amazon Athena para analisar padrões de acesso:
SELECT useridentity.arn, eventname, requestparameters.bucketname,
requestparameters.key, COUNT(*) as access_count
FROM cloudtrail_logs
WHERE eventname IN ('GetObject', 'PutObject')
GROUP BY 1, 2, 3, 4
ORDER BY access_count DESC
LIMIT 100;
Essa consulta identifica dados acessados com frequência e padrões incomuns de comportamento, permitindo otimizar camadas de armazenamento, refinar estratégias de recuperação de desastres, identificar riscos de segurança e ajustar políticas de ciclo de vida conforme padrões de uso.
Governança de modelos de aprendizado de máquina
Conforme organizações avançam sua jornada de governança, muitas implantam modelos de machine learning em produção, necessitando frameworks que se estendam a operações de ML. O Amazon SageMaker oferece ferramentas avançadas para manter governança sobre ativos de ML sem impedir inovação.
As ferramentas de governança do SageMaker trabalham juntas fornecendo supervisão completa de ML: o Role Manager oferece controle de acesso detalhado, Model Cards centralizam documentação e linhagem, o Model Dashboard oferece visibilidade em toda a organização, e o Model Monitor automatiza detecção de desvio e controle de qualidade.
# Basic/High-level ML governance setup with role and monitoring
SageMakerRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Effect: Allow
Principal:
Service: sagemaker.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonSageMakerFullAccess
ModelMonitor:
Type: AWS::SageMaker::MonitoringSchedule
Properties:
MonitoringScheduleName: hourly-model-monitor
ScheduleConfig:
ScheduleExpression: 'cron(0 * * * ? *)'
Otimização de custos através de gerenciamento de ciclo de vida automatizado
Governança de dados efetiva não trata apenas de segurança — também gerencia custos. Implemente gerenciamento inteligente de ciclo de vida de dados baseado em classificação e padrões de uso:
Implementação bem-sucedida de governança de dados na AWS exige abordagem estruturada e adesão a melhores práticas:
Comece com escopo focado e expanda gradualmente. Inicie com projeto piloto que aborde casos de uso de alto impacto e baixa complexidade, demonstrando ganhos rápidos enquanto constrói experiência.
Faça automação sua fundação. Aplique serviços como EventBridge para respostas dirigidas por eventos, implemente remediação automatizada e crie capacidades de auto-atendimento que equilibrem eficiência e conformidade.
Mantenha visibilidade e melhoria contínuas. Monitoramento regular, verificações de conformidade e atualizações de framework são essenciais. Use feedback de suas operações para refinar políticas conforme necessidades da organização evoluem.
Desafios comuns a considerar
Resistência inicial de equipes acostumadas a processos manuais
Complexidade ao lidar com sistemas e dados legados
Equilíbrio entre controles de segurança e eficiência operacional
Manutenção de governança consistente em múltiplas contas e regiões AWS
Recursos adicionais
Para mais informações, suporte de implementação e orientação, consulte:
Construir um framework de governança de dados robusto e escalável na AWS que cresça com sua organização enquanto mantém segurança, conformidade e operações de dados eficientes é totalmente viável. O caminho começa com monitoramento fundamental, progride através de controles preventivos, passa por automação de remediação e culmina em recursos avançados que garantem conformidade em ambientes complexos.
Ao seguir essa abordagem progressiva, validando continuamente e permanecendo atento aos desafios potenciais, sua organização pode implementar governança que não apenas atende aos requisitos regulatórios, mas também habilita inovação e otimização de custos.
Novidade: Parâmetros em Templates PySpark no AWS Clean Rooms
A AWS anunciou o suporte a parâmetros em templates de análise PySpark, ampliando as possibilidades de colaboração segura entre organizações e seus parceiros. Com este lançamento, torna-se possível criar um único template PySpark que aceita diferentes valores fornecidos pelo colaborador no momento da execução, eliminando a necessidade de modificar o código do template.
Como Funciona: Fluxo de Parâmetros
O processo segue uma lógica clara: o autor do código prepara um template PySpark com suporte a parâmetros, e após aprovação para execução, quem rodar o job pode enviar os valores diretamente para a tarefa PySpark. Essa abordagem cria um cenário onde o mesmo template reutilizável funciona para múltiplos cenários e análises, sem precisar duplicar ou ajustar manualmente o código para cada situação.
Aplicação Prática: Campanha de Publicidade
Um exemplo tangível é a atuação de empresas de medição no setor de publicidade: com os parâmetros dinâmicos, elas podem inserir períodos de tempo e regiões geográficas diferentes diretamente durante o envio do job. Essa flexibilidade acelera a geração de insights sobre atribuição de campanhas publicitárias, permitindo otimizações de campanha e planejamento de mídia em prazos muito mais curtos.
O Escopo Maior do Clean Rooms
O AWS Clean Rooms oferece a capacidade de criar salas de dados seguras em poucos minutos e colaborar com qualquer empresa na AWS ou Snowflake. Esse ambiente permite gerar insights únicos sobre campanhas publicitárias, decisões de investimento e pesquisa e desenvolvimento, mantendo a privacidade dos dados durante todo o processo colaborativo.
Disponibilidade e Próximos Passos
Para conhecer em quais regiões da AWS o Clean Rooms está disponível, consulte a tabela de regiões oficial. Mais informações sobre como colaborar usando o AWS Clean Rooms estão disponíveis na documentação do serviço.
A AWS anunciou a disponibilidade do Amazon S3 em Outposts nos racks de segunda geração do AWS Outposts. Essa atualização abre novas possibilidades para organizações que precisam manter seus dados dentro de suas próprias instalações, seja em data centers, espaços de colocação ou infraestruturas locais, enquanto aproveitam os recursos do S3 que já conhecem.
Flexibilidade de capacidade de armazenamento
O S3 em Outposts nos racks de segunda geração oferece três níveis de armazenamento para atender diferentes necessidades:
196 TB — ideal para ambientes com requisitos iniciais ou moderados
490 TB — adequado para cargas de trabalho de produção de médio porte
786 TB — para operações com demanda substancial de armazenamento
Essa flexibilidade permite que as organizações escolham a tier que melhor se alinha ao seu cenário de uso, seja para executar workloads de produção, manter backups locais ou armazenar dados para fins de arquivo.
Experiência familiar e consistente
Um dos principais benefícios dessa solução é que as equipes podem trabalhar com as mesmas APIs (Interfaces de Programação de Aplicações) e funcionalidades do S3. Não é necessário aprender novas ferramentas ou padrões — basta usar interfaces conhecidas para armazenar, proteger, recuperar e controlar o acesso aos dados localmente.
O que é AWS Outposts?
O AWS Outposts é um serviço completamente gerenciado pela AWS que leva a infraestrutura, serviços e ferramentas do AWS para praticamente qualquer local: um data center, espaço de colocação ou instalação on-premises. A proposta é oferecer uma experiência híbrida consistente, permitindo que as organizações tenham a mesma abordagem na nuvem e no local.
Disponibilidade e próximos passos
O S3 em Outposts nos racks de segunda geração está disponível em todas as regiões AWS e países/territórios onde esses racks já operam. Para conhecer mais detalhes sobre como implementar essa solução, as organizações podem consultar a página dedicada ao S3 em Outposts ou acessar a documentação técnica completa.
Casos de uso principais
Essa solução é particularmente relevante para cenários onde a residência de dados é crítica, a latência deve ser minimizada ou o processamento precisa ocorrer localmente. Empresas que enfrentam restrições regulatórias de soberania de dados, setores que exigem acesso ultrarrápido aos dados ou operações híbridas complexas encontram no S3 em Outposts uma alternativa poderosa.
Organizações que buscam automatizar processos através de agentes de IA ou potencializar a produtividade de seus colaboradores com assistentes baseados em chat enfrentam um desafio significativo: implementar salvaguardas abrangentes e controles de auditoria para garantir o uso responsável de IA e o processamento seguro de dados sensíveis pelos modelos de linguagem grandes (LLMs).
Muitas empresas desenvolveram gateways de IA generativa personalizados ou adotaram soluções prontas, como LiteLLM ou Kong AI Gateway, para fornecer aos seus desenvolvedores acesso a LLMs de diferentes provedores. No entanto, manter políticas consistentes de segurança de prompts e proteção de dados sensíveis em um portfólio crescente de modelos de múltiplos fornecedores em escala representa um obstáculo considerável.
Solução Centralizada com Guardrails
A AWS apresenta uma abordagem para esse desafio através do Amazon Bedrock Guardrails. Essa ferramenta oferece um conjunto de funcionalidades de segurança que permitem às organizações construir aplicações de IA generativa responsáveis em escala. A solução integra a API ApplyGuardrail do Amazon Bedrock a um gateway de IA generativa multi-provider personalizado, possibilitando a aplicação de políticas consistentes de segurança de prompts e proteção de dados sensíveis tanto para modelos do Amazon Bedrock quanto de provedores terceirizados, como Azure OpenAI.
A solução proposta oferece benefícios adicionais: logging e monitoramento centralizados, análise de padrões de uso e um mecanismo de chargeback para atribuição de custos.
Arquitetura e Componentes Principais
O fluxo da solução começa quando usuários autenticados enviam requisições HTTPS para o gateway de IA generativa, uma aplicação centralizada executada no Amazon Elastic Container Service (Amazon ECS) que funciona como interface principal para as interações com LLMs. Dentro da lógica da aplicação, cada requisição recebida é primeiro encaminhada para a API ApplyGuardrail do Amazon Bedrock para triagem de conteúdo.
O gateway avalia o conteúdo contra configurações predefinidas, tomando decisões críticas para bloquear integralmente a requisição, mascarar informações sensíveis ou permitir que prossiga sem modificações. Para requisições aprovadas, a lógica do gateway determina o provedor de LLM apropriado — seja Amazon Bedrock ou um serviço terceirizado — com base nas especificações do usuário. O conteúdo filtrado é então encaminhado ao LLM selecionado, e o gateway retorna a resposta ao usuário.
Capacidades de Segurança e Guardrails Centralizados
O gateway centralizado implementa controles de segurança abrangentes através do Amazon Bedrock Guardrails, oferecendo quatro funcionalidades de segurança principais:
Filtragem de conteúdo — triagem de conteúdo inadequado ou prejudicial
Tópicos negados — prevenção de discussões sobre assuntos específicos
Filtros de palavras — bloqueio de termos ou frases específicas
Detecção de informações sensíveis — proteção de dados pessoais e confidenciais
As organizações podem implementar esses controles em três níveis de intensidade configuráveis — baixo, médio e alto — permitindo que diferentes unidades de negócio alinhem sua postura de segurança com sua tolerância a risco e requisitos de conformidade. Por exemplo, um time de marketing pode operar com guardrails de intensidade baixa para geração criativa de conteúdo, enquanto divisões financeiras ou de saúde podem exigir guardrails de intensidade alta para lidar com dados sensíveis de clientes.
Além dessas proteções básicas, o Amazon Bedrock Guardrails inclui funcionalidades avançadas como grounding contextual e verificações de raciocínio automatizado, que ajudam a detectar e prevenir alucinações de IA — instâncias onde modelos geram informações falsas ou enganosas.
Integração Multi-Provider e Acesso Centralizado
O gateway é agnóstico quanto ao provedor de LLM e modelo, permitindo integração perfeita com múltiplos fornecedores. Os usuários podem especificar seu modelo de LLM preferido diretamente no payload da requisição, permitindo que o gateway direcione requisições ao endpoint apropriado. O AWS Secrets Manager armazena tokens de acesso do gateway e de LLMs terceirizados, como Azure OpenAI.
Observabilidade, Monitoramento e Conformidade
Uma vantagem fundamental da implementação de um gateway de IA generativa é sua abordagem centralizada para logging e monitoramento. Cada interação — requisições de usuários, prompts, respostas do LLM e contexto do usuário — é capturada e armazenada em formato e local padronizados. Isso facilita análise, resolução de problemas e extração de insights.
A observabilidade é ativada através de: Amazon CloudWatch para capturar logs de container e aplicação, permitindo criar métricas personalizadas e alarmes proativos; Amazon Simple Notification Service (Amazon SNS) para notificações; Amazon Kinesis Data Streams e Data Firehose para streaming de dados de requisição e resposta até Amazon S3; AWS Glue Crawler API e Amazon Athena para expor tabelas SQL de metadados de transações para análise e chargeback.
Implantação e Primeiros Passos
O código-fonte completo está disponível no repositório no GitHub. Para implantar a solução, são necessários: conta AWS, função AWS Identity and Access Management (IAM) com permissões apropriadas para S3, Secrets Manager, CloudWatch, Bedrock e Guardrails.
O processo de implantação envolve: clonar o repositório GitHub, executar ./deploy.sh para configurar automaticamente o bucket de estado do Terraform, criar política IAM e provisionar infraestrutura, invocar ./verify.sh para verificar a implantação e gerar tokens de autorização para consumidores.
Exemplos de Funcionalidade
O primeiro exemplo demonstra a eficácia do mecanismo de segurança no bloqueio de tópicos negados. Uma solicitação com guardrail de intensidade alta contendo uma pergunta sobre investimentos em ações resulta em intervenção do guardrail, retornando uma mensagem de conteúdo bloqueado conforme configurado.
O segundo exemplo testa a proteção de informações pessoalmente identificáveis (PII). Uma consulta de usuário contendo nome, SSN e email é processada, com o guardrail intervindo e mascarando os dados PII antes de enviar a consulta ao LLM, evidenciado pelo campo guardrail_action indicando a aplicação de política de informações sensíveis.
Análise de Custos
A implementação dessa solução envolve várias categorias de custo: custos de provedor de LLM (input/output tokens, modelo e volume de uso); custos de infraestrutura AWS (computação Fargate, balanceamento, armazenamento, monitoramento, processamento de dados, segurança); e custos específicos do Amazon Bedrock Guardrails.
Uma estimativa de cenário moderado — cerca de 50 a 200 queries por dia, comprimento médio de input de 500 tokens e output de 250 tokens — indica custos entre $170 e $260 mensais para infraestrutura base e processamento de IA combinados. Esses valores podem variar significativamente baseado em volume de chamadas, comprimento de conversas, seleção de modelos e quantidade de chamadas por requisição.
Conclusão
A solução de guardrails centralizados integrada a um gateway de IA generativa multi-provider customizado oferece uma abordagem robusta e escalável para empresas utilizarem LLMs com segurança, mantendo padrões rigorosos de conformidade. Através da implementação da API ApplyGuardrail do Amazon Bedrock Guardrails, a solução oferece aplicação consistente de políticas de segurança de prompts e proteção de dados sensíveis em provedores Amazon Bedrock e terceirizados.
Os principais benefícios dessa arquitetura incluem: guardrails centralizados com níveis de segurança configuráveis, capacidades de integração multi-provider de LLM, recursos abrangentes de logging e monitoramento, escalabilidade de nível produção através de containerização e capacidades built-in de conformidade e auditoria. Organizações em indústrias altamente reguladas podem adotar essa arquitetura para escalar suas implementações de IA generativa mantendo controle sobre proteção de dados e conformidade com regulações de segurança de IA.
Gerenciamento centralizado de IPs para mais recursos
A AWS anunciou a expansão das políticas do Amazon Virtual Private Cloud (VPC) IP Address Manager (IPAM) para oferecer suporte a instâncias do Amazon Relational Database Service (RDS) e Application Load Balancers (ALB). Com essa atualização, administradores de IP conseguem configurar e executar centralizadamente estratégias de alocação de endereços IP para esses recursos, elevando o padrão operacional e simplificando significativamente a gestão de redes e segurança.
Como funcionam as políticas IPAM
Por meio das políticas IPAM, os administradores de IP podem definir centralmente regras de alocação de endereços IP públicos para diversos recursos da AWS, incluindo instâncias RDS, Application Load Balancers, NAT Gateways (quando utilizados em modo de disponibilidade regional) e Elastic IP addresses. O diferencial está na impossibilidade de as equipes de aplicação sobrescreverem as políticas de alocação de IP configuradas centralmente, assegurando conformidade contínua e eliminando desvios.
Benefícios para arquitetura e compliance
Anteriormente, administradores de IP precisavam comunicar e educar constantemente administradores de banco de dados e desenvolvedores de aplicações sobre os requisitos de alocação de IP para RDS e ALB, dependendo da adesão manual às melhores práticas. Agora, é possível adicionar filtros baseados em IP para o tráfego de RDS e ALB em construtos de rede e segurança, como listas de controle de acesso, tabelas de roteamento, grupos de segurança e firewalls, com segurança de que os endereços IPv4 públicos atribuídos a esses recursos sempre provenham de pools IPAM específicos.
Disponibilidade e níveis de suporte
O recurso está disponível em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US), funcionando tanto na camada Free Tier quanto na Advanced Tier do VPC IPAM. Quando utilizado com a Advanced Tier do VPC IPAM, os clientes conseguem definir políticas entre contas e regiões AWS.
Inferência Distribuída em Escala: O Desafio da Segurança
A adoção de IA generativa vem acelerando significativamente. Organizações enfrentam agora o desafio de construir aplicações de IA operacionais em produção, em larga escala, mantendo a eficiência e a confiabilidade. O Amazon Bedrock introduz uma funcionalidade estratégica para esse cenário: os perfis de inferência distribuída (CRIS), que permitem distribuir o processamento de inferência de forma contínua por múltiplas Regiões AWS. Esse mecanismo oferece maior throughput e mantém as aplicações responsivas, mesmo sob carga intensa.
Porém, escalar globalmente exige compreensão profunda dos controles de segurança envolvidos. Este artigo examina as práticas e considerações de segurança para implementar perfis de inferência distribuída do Bedrock, orientando organizações que precisam atender requisitos regionais de conformidade ou que desejam otimizar recursos em escala global.
Entendendo a Arquitetura de Inferência Distribuída
Como Funciona o Roteamento de Requisições
Os perfis de inferência distribuída operam sobre dois conceitos-chave. A Região de Origem é aquela de onde a chamada de API é feita. A Região de Destino é uma Região para onde o Amazon Bedrock roteia a requisição de processamento.
Quando você invoca um perfil de inferência distribuída, a requisição segue um caminho de roteamento inteligente. Ela origina-se na Região de origem e é automaticamente direcionada para uma das Regiões de destino definidas no perfil. Todo esse fluxo ocorre pela Rede Global da AWS, gerenciada pelo Amazon Bedrock, com criptografia de ponta a ponta para dados em trânsito.
Um detalhe crítico: a inferência distribuída não altera o local onde seus dados são armazenados. Nenhum dado do cliente é persistido em Regiões de destino. Logs gerenciados pelo cliente, bases de conhecimento e configurações armazenadas permanecem exclusivamente na Região de origem. As respostas retornam criptografadas para sua aplicação na Região de origem.
Dois Modelos de Operação: Geográfico e Global
O Bedrock oferece dois tipos de perfis de inferência distribuída, cada um atendendo diferentes necessidades de conformidade e otimização.
Inferência Distribuída Geográfica: O Amazon Bedrock seleciona automaticamente a Região ótima dentro de uma geografia definida (EUA, União Europeia, Austrália, Japão) para processar sua requisição. Este modelo mantém o processamento dentro de limites geográficos específicos, atendendo requisitos de residência de dados regional. É ideal para organizações com regulamentações rigorosas de conformidade regional.
Inferência Distribuída Global: Este modelo amplifica as capacidades da inferência distribuída, roteando requisições para Regiões comerciais da AWS em todo o mundo, otimizando recursos disponíveis e habilitando maior throughput de modelo. Roteia requisições sem restrições geográficas. Adequado para organizações que desejam cobertura mais ampla e custo-benefício em throughput.
Se sua organização possui requisitos rigorosos de residência de dados ou conformidade, é essencial avaliar cuidadosamente se a inferência distribuída alinha-se com suas políticas e regulamentações, pois os dados de inferência podem ser processados em múltiplas Regiões pré-configuradas.
Controles de Acesso e Conformidade Regulatória
Permissões IAM e Políticas de Controle de Serviço
Por padrão, usuários e funções dentro de sua conta AWS não possuem permissão para criar, modificar ou usar recursos do Amazon Bedrock. O acesso é controlado através de dois mecanismos principais: políticas AWS Identity and Access Management (IAM) para permissões granulares de usuário e função, e Políticas de Controle de Serviço (SCPs) para guardrails e restrições em toda a organização.
Para usar inferência distribuída no Bedrock, os usuários devem possuir permissões IAM específicas. Se SCPs estão anexadas à sua conta, elas também devem permitir as ações necessárias. A complexidade aumenta porque os requisitos diferem entre os dois tipos de perfil.
Diferenças de Requisitos: Geográfico vs. Global
Para inferência distribuída geográfica, as políticas IAM devem permitir acesso aos seguintes recursos:
O perfil de inferência distribuída específico da geografia (com prefixos como “us”, “au”, “jp”, “eu”)
O modelo de fundação na Região de origem
O modelo de fundação em TODAS as Regiões de destino listadas no perfil
As Políticas de Controle de Serviço devem ser atualizadas para incluir condições específicas de Região, permitindo TODAS as Regiões de destino listadas no perfil geográfico.
Para inferência distribuída global, as políticas IAM devem permitir:
O perfil de inferência distribuída global na Região de origem (com prefixo “global” no ID)
O modelo de fundação na Região de origem
O modelo de fundação global usando a condição aws:RequestedRegion com valor “unspecified”
As Políticas de Controle de Serviço globais devem garantir que aws:RequestedRegion: "unspecified" não esteja incluído em listas de Regiões negadas, pois as requisições de inferência distribuída global usam este valor.
Implementação Prática de Políticas IAM
Para inferência distribuída geográfica, um exemplo de política permite que um usuário IAM invoque um perfil de inferência distribuída do Claude Sonnet 4.5 para o EUA, originário de us-east-1 com destinos em us-east-1, us-east-2 e us-west-2:
A primeira declaração concede acesso à invocação do perfil de inferência distribuída. A segunda declaração concede acesso aos modelos de fundação em todas as Regiões (origem e destinos), mas apenas quando a chamada é feita através do perfil especificado.
Para inferência distribuída global, a política é ligeiramente diferente:
Nesta política, a primeira declaração concede permissão para invocar o perfil na Região de origem. A segunda permite invocar o modelo na Região de origem, mas apenas através do perfil especificado. A terceira permite invocar o modelo global em qualquer Região comercial suportada, restringindo através da condição aws:RequestedRegion: "unspecified".
Governança: Desabilitando Inferência Distribuída
Organizações com requisitos rigorosos de residência de dados podem precisar desabilitar completamente a inferência distribuída. Para isso, existem duas abordagens complementares.
Para restringir inferência distribuída geográfica, implemente uma Política de Controle de Serviço de negação que bloqueie todas as invocações de perfis de inferência distribuída que não usem prefixos específicos:
Todas as chamadas de inferência distribuída são registradas na Região de origem. As entradas do AWS CloudTrail incluem um campo adicional additionalEventData para rastreamento. Este campo especifica a Região real onde a inferência foi processada, permitindo auditoria completa do fluxo de dados.
Um exemplo típico mostra uma chamada InvokeModel com inferência distribuída global, originária de ap-southeast-2, sendo processada em ap-southeast-4, com o CloudTrail registrando essa Região de processamento para fins de conformidade e auditoria.
Integração com AWS Control Tower
Para organizações que usam AWS Control Tower, o gerenciamento de inferência distribuída requer ajustes nas Políticas de Controle de Serviço. A recomendação é usar Customizações para AWS Control Tower em vez de editar manualmente as SCPs, evitando desvios de configuração.
Para habilitar inferência distribuída global em ambientes Control Tower, é necessário modificar as SCPs criadas automaticamente para incluir “unspecified” na lista de Regiões permitidas especificamente para ações do Amazon Bedrock, mantendo restrições regionais para outros serviços.
Considerações Sobre Regiões AWS
O Amazon Bedrock utiliza perfis de inferência para rotear requisições através de todas as Regiões listadas no perfil, sejam Regiões ativadas por padrão ou que requeiram ativação manual na sua conta AWS. A abordagem simplifica a operação ao eliminar a necessidade de ativar múltiplas Regiões manualmente.
Existem dois tipos de Regiões Regiões comerciais da AWS. Regiões ativadas por padrão (como N. Virginia, Irlanda e Sydney) e Regiões que requerem ativação manual (como Melbourne, Emirados Árabes e Hyderabad). As Regiões ativadas manualmente são mais recentes, introduzidas após 20 de março de 2019.
Conclusão: Segurança em Escala
A inferência distribuída no Amazon Bedrock oferece capacidades poderosas para construir aplicações de IA generativa escaláveis e resilientes. Compreender as interações fundamentais entre inferência distribuída e controles de segurança permite que organizações desbloqueiem essa funcionalidade de forma segura, mantendo sua postura de segurança.
Implementando políticas IAM precisas, Políticas de Controle de Serviço bem estruturadas e monitoramento robusto via CloudTrail, sua organização consegue inovar com inferência distribuída sem comprometer conformidade ou governança.
A evolução da gestão centralizada de segurança na nuvem
A AWS lançou uma versão melhorada do AWS Security Hub, oferecendo novas formas para organizações gerenciarem e responderem a achados de segurança. O Security Hub aprimorado auxilia na melhoria da postura de segurança organizacional e simplifica operações de segurança em nuvem ao centralizar a gestão de segurança em todo o ambiente da Amazon Web Services (AWS).
O Security Hub transformou a maneira como as organizações tratam achados de segurança através de capacidades avançadas de automação, incluindo análise de risco em tempo real, correlação automática e contexto enriquecido. Essas funcionalidades permitem que as equipes priorizem problemas críticos e reduzam tempos de resposta.
Visibilidade centralizada e priorização baseada em risco
O Security Hub oferece visibilidade centralizada através de múltiplos serviços de segurança da AWS, proporcionando uma visão unificada do ambiente em nuvem. Isso inclui visualizações de priorização baseada em risco, visualização de caminhos de ataque e análise de tendências que ajudam a compreender padrões de segurança ao longo do tempo.
Este é o terceiro artigo de uma série sobre as novas capacidades do Security Hub. Para contexto: a série anterior discutiu como o Security Hub unifica achados entre serviços da AWS para simplificar a gestão de risco, e também apresentou as etapas para realizar uma Prova de Conceito bem-sucedida.
Por que automação importa em segurança em nuvem
As organizações frequentemente operam em centenas de contas da AWS, múltiplas regiões e diversos serviços, cada um gerando achados que precisam ser triados, investigados e processados. Sem automação, equipes de segurança enfrentam alto volume de alertas, duplicação de esforço e risco de respostas atrasadas a questões críticas.
Processos manuais não conseguem acompanhar operações em nuvem. A automação transforma as operações de segurança de três formas fundamentais:
Filtragem e priorização: A automação filtra e prioriza achados conforme seus critérios, mostrando à equipe apenas alertas relevantes.
Resposta imediata: Quando problemas são detectados, respostas automatizadas disparam instantaneamente, sem necessidade de intervenção manual.
Consistência em escala: Ao gerenciar múltiplas contas da AWS, a automação aplica políticas e fluxos de trabalho consistentes através do seu ambiente, transferindo a equipe de segurança de “apagar incêndios” para gerenciamento proativo de risco.
Desenhando estratégias de roteamento para achados de segurança
Com o Security Hub configurado, é hora de desenhar uma estratégia de roteamento para seus achados e notificações. Ao projetar essa estratégia, questione se sua configuração atual do Security Hub atende seus requisitos de segurança. Considere se as automações do Security Hub podem ajudá-lo a atender frameworks de conformidade como NIST 800-53 e identifique KPIs e métricas para mensurar se sua estratégia de roteamento funciona.
As automações e respostas automáticas do Security Hub podem ajudar a cumprir esses requisitos, mas é crucial compreender como suas equipes de conformidade, respondentes de incidentes, pessoal de operações de segurança e demais stakeholders operam diariamente. Por exemplo: suas equipes usam o Console de Gerenciamento da AWS para o Security Hub regularmente? Ou você precisa enviar a maioria dos achados para ferramentas de gerenciamento de sistemas de TI (ITSM), como Jira ou ServiceNow, ou plataformas terceirizadas de orquestração, automação e resposta de segurança (SOAR)?
Em seguida, crie e mantenha um inventário de aplicações críticas. Isso ajuda a ajustar a severidade de achados baseado em contexto empresarial e seus playbooks de resposta a incidentes. Considere um cenário onde o Security Hub identifica uma vulnerabilidade de severidade média em uma instância de Elastic Compute Cloud. Isoladamente, isso pode não disparar ação imediata. Ao adicionar contexto empresarial — como objetivos estratégicos ou criticidade para o negócio — você pode descobrir que essa instância hospeda uma aplicação crítica de processamento de pagamentos, revelando o risco real. Implementando regras de automação do Security Hub com contexto enriquecido, esse achado pode ser elevado para severidade crítica e automaticamente roteado para ServiceNow para rastreamento imediato.
Além disso, usando automação do Security Hub com Amazon EventBridge, você pode disparar um documento de automação do AWS Systems Manager Automation para isolar a instância EC2 para trabalho forense de segurança.
Como o Security Hub oferece formato e esquema OCSF, você pode utilizar os extensos elementos de esquema que o OCSF oferece para direcionar achados para automação e ajudar sua organização a atender requisitos de estratégia de segurança.
Casos de uso em automação de segurança
As automações do Security Hub suportam diversos casos de uso. Converse com suas equipes para entender quais se aplicam às suas necessidades e objetivos de segurança:
Remediação automática de achados
Use remediação automática de achados para corrigir automaticamente problemas de segurança conforme são detectados. Padrões de suporte incluem remediação direta (disparar funções AWS Lambda para corrigir configurações incorretas), marcação de recursos (adicionar tags em recursos não conformes), correção de configuração (atualizar configurações de recursos para corresponder políticas de segurança) e ajuste de permissões (modificar políticas do AWS Identity and Access Management (IAM) para remover permissões excessivas).
Exemplo:
IF finding.type = "Software and Configuration Checks/Industry and Regulatory Standards/CIS AWS Foundations Benchmark"
AND finding.title CONTAINS "S3 buckets should have server-side encryption enabled"
THEN invoke Lambda function "enable-s3-encryption"
Integração de achados em fluxo de trabalho
Integre achados em seus fluxos de trabalho roteando-os para as equipes e sistemas apropriados. Padrões de suporte incluem criação de tickets (gerar tickets em Jira ou ServiceNow para revisão manual), atribuição de equipes (rotear achados para equipes específicas baseado em propriedade de recursos) e roteamento baseado em severidade (direcionar achados críticos para resposta a incidentes, outros para filas regulares).
Exemplo:
IF finding.severity = "CRITICAL" AND finding.productName = "Amazon GuardDuty"
THEN send to SNS topic "security-incident-response-team"
ELSE IF finding.productFields.resourceOwner = "payments-team"
THEN send to SNS topic "payments-security-review"
Enriquecimento automático de achados
Use enriquecimento de achados para adicionar contexto que melhore eficiência de triagem. Padrões incluem adição de contexto de recursos (adicionar contexto empresarial, informações de proprietário e classificação de dados), análise histórica (adicionar informações sobre achados similares anteriores), pontuação de risco personalizada (calcular scores de risco customizados baseado em valor do ativo e contexto de ameaça) e correlação de vulnerabilidades (ligar achados a CVEs conhecidas ou inteligência de ameaças).
Controles de segurança customizados
Use controles de segurança customizados para atender requisitos específicos da organização. Padrões incluem imposição de política customizada (verificar conformidade com padrões internos), regras específicas do negócio (aplicar regras baseado em unidade de negócio ou tipo de aplicação), controles compensatórios (implementar alternativas quando controles primários não podem ser aplicados) e exceções temporárias (lidar com desvios aprovados de padrões de segurança).
Relatório de conformidade e coleta de evidência
Agilize documentação de conformidade e coleta de evidência. Padrões incluem captura de evidência (armazenar evidência de conformidade em buckets S3 designados), criação de trilha de auditoria (documentar ações de remediação para auditores), dashboard de conformidade (atualizar métricas de status de conformidade) e mapeamento regulatório (rotular achados com frameworks de conformidade relevantes).
Configurando automação no Security Hub
Passo 1: Ative o Security Hub e serviços integrados
Após o Security Hub coletar achados, você pode criar regras de automação para atualizar e rotear os achados para as equipes apropriadas. Os passos para criar regras de automação no Security Hub que atualizam detalhes de achados ou configurar integrações terceirizadas como Jira ou ServiceNow podem ser encontrados na documentação específica.
Com essas regras de automação, o Security Hub avalia achados contra a regra definida e então executa a atualização apropriada ou chama APIs para enviar achados a Jira ou ServiceNow. O Security Hub envia uma cópia de cada achado para o Amazon EventBridge, permitindo que você implemente suas próprias respostas automatizadas se necessário, para casos de uso fora do escopo das regras de automação do Security Hub.
Além de enviar cópias de cada achado para EventBridge, o Security Hub classifica e enriquece achados de segurança conforme contexto empresarial, entregando-os aos serviços downstream apropriados (como ferramentas ITSM) para resposta rápida.
Melhores práticas para automação de segurança
As regras de automação do Security Hub oferecem capacidades para atualização automática de achados e integração com outras ferramentas. Ao implementar regras de automação, siga estas melhores práticas:
Gestão centralizada: Apenas a conta administradora do Security Hub pode criar, editar, deletar e visualizar regras de automação. Garanta controle de acesso e gestão apropriados dessa conta.
Implantação regional: Regras de automação podem ser criadas em uma região da AWS e aplicadas através de regiões configuradas. Ao usar agregação de região, você pode apenas criar regras na região inicial.
Critérios específicos: Defina claramente os critérios que achados devem corresponder para a regra de automação aplicar. Isso pode incluir atributos de achados, níveis de severidade, tipos de recurso ou IDs de conta membro.
Entenda a ordem de regras: A ordem importa quando múltiplas regras aplicam ao mesmo achado ou campo de achado. O Security Hub aplica regras com valor numérico menor primeiro. Para mais informações, consulte a documentação sobre atualização da ordem de regras no Security Hub.
Descrições claras: Inclua descrição de regra detalhada para fornecer contexto aos respondentes e proprietários de recursos, explicando o propósito e ações esperadas da regra.
Use automação para eficiência: Use regras de automação para atualizar automaticamente campos de achados (como severidade e status de fluxo de trabalho), suprimir achados de baixa prioridade, ou criar tickets em ferramentas terceirizadas como Jira ou ServiceNow para achados correspondentes a atributos específicos.
Considere EventBridge para ações externas: Enquanto regras de automação lidam com atualizações internas de achados do Security Hub, use regras EventBridge para disparar ações fora do Security Hub, como invocar funções AWS Lambda ou enviar notificações para tópicos Amazon Simple Notification Service (Amazon SNS) baseado em achados específicos. As regras de automação têm efeito antes das regras EventBridge serem aplicadas. Para mais informações, consulte regras de automação em EventBridge.
Gerencie limites de regras: Existe um limite máximo de 100 regras de automação por conta administradora. Planeje sua criação de regras estrategicamente para permanecer dentro desse limite.
Revise e refine regularmente: Periodicamente revise regras de automação, especialmente regras de supressão, para garantir que permaneçam relevantes e efetivas, ajustando-as conforme sua postura de segurança evolui.
Consolidando operações de segurança em escala
As automações do Security Hub permitem triar, rotear e responder a achados mais rapidamente através de uma solução unificada de segurança em nuvem com gestão centralizada. Através da abordagem intuitiva e flexível de automação que o Security Hub oferece, suas equipes de segurança podem tomar decisões confiantes, baseadas em dados, sobre achados do Security Hub que se alinhem com a estratégia de segurança geral da organização.
Com as capacidades de automação do Security Hub, você pode gerenciar segurança centralmente através de centenas de contas enquanto suas equipes focam em problemas críticos que mais importam para seu negócio. Implementando as capacidades de automação descritas neste artigo, você consegue simplificar tempos de resposta em escala, reduzir esforço manual e melhorar sua postura de segurança geral através de fluxos de trabalho consistentes e automatizados.
