Nunca as equipes de segurança tiveram tanto poder computacional à disposição — e nunca precisaram tanto dele. Os modelos de IA de fronteira já conseguem raciocinar sobre bases de código inteiras, rastrear a causa raiz de uma vulnerabilidade e propor correções em minutos. O problema é que essas mesmas capacidades estão disponíveis para os adversários também.
É por isso que a janela entre a divulgação de uma vulnerabilidade e sua exploração ativa continua encolhendo. Os defensores precisam navegar por bases de código extensas e pouco familiares, validar quais descobertas são reais, desenvolver patches que funcionem — e fazer tudo isso antes que o tempo acabe. O desafio não é mais encontrar problemas potenciais, mas confirmar quais são genuínos, corrigi-los e agir antes que a janela se feche.
A parceria: OpenAI e AWS no Amazon Bedrock
A AWS sempre operou com o princípio de que a segurança deve ser incorporada desde o início. O mesmo vale para IA: os clientes executam cargas de trabalho no Amazon Bedrock, desde inferência até agentes totalmente autônomos, sob a mesma infraestrutura, controles e governança que já utilizam em todo o ambiente AWS.
Agora, a AWS e a OpenAI estão estendendo essa base para a defesa cibernética. O Daybreak Red e o Daybreak Blue da OpenAI estão disponíveis no Amazon Bedrock para clientes elegíveis.
Daybreak Red oferece acesso ao GPT-5.6 Cyber, um modelo de cibersegurança treinado especificamente para essa finalidade.
Daybreak Blue oferece acesso ao GPT-5.6 Sol, com salvaguardas calibradas para trabalhos defensivos de cibersegurança.
Ambos fazem parte do Daybreak, a iniciativa de defesa cibernética da OpenAI que oferece aos defensores acesso governado à IA de fronteira — incluindo ferramentas agênticas, red teaming de aplicações e serviços que ajudam a avançar de descobertas até correções testadas.
Segundo a própria AWS, as equipes de segurança da empresa já utilizam ambos os modelos para analisar código-fonte, descobrir vulnerabilidades e conduzir pesquisas de red team. No Bedrock, esse trabalho roda sob os mesmos controles de infraestrutura aplicados a qualquer outra carga de trabalho crítica.
Modelos especializados para trabalhos avançados de segurança
O caminho entre descobrir uma vulnerabilidade e corrigi-la é longo: confirmar se ela é explorável, rastrear como o componente vulnerável é acessível, desenvolver uma correção que trate a causa raiz sem introduzir regressões, validar que a correção funciona em condições realistas e entregar o patch dentro da janela de divulgação. Os defensores precisam de modelos capazes de acelerar cada uma dessas etapas.
A cibersegurança é, por natureza, de uso dual. Uma solicitação para reproduzir uma vulnerabilidade ou fazer engenharia reversa de uma cadeia de exploit é idêntica independentemente da intenção — e modelos de uso geral resolvem essa ambiguidade simplesmente recusando a solicitação. O Daybreak Red e o Daybreak Blue resolvem isso pelo contexto: quem está usando o modelo, onde o trabalho ocorre e quais salvaguardas governam esse acesso.
Daybreak Blue: ponto de partida para a maioria das equipes
O Daybreak Blue é indicado para a maioria das equipes de segurança. Ele suporta descoberta de vulnerabilidades, engenharia de detecção e resposta a incidentes.
Daybreak Red: para tarefas avançadas
O Daybreak Red é projetado para tarefas avançadas como pesquisa de vulnerabilidades, reprodução de exploits e desenvolvimento de mitigações. Para essas atividades, um limiar de recusa mais baixo — combinado com verificação de identidade mais rigorosa, monitoramento e controles de acesso mais fortes — melhora a velocidade e a profundidade de uma investigação.
Como exemplo concreto, a OpenAI relata que pesquisadores de segurança utilizando o GPT-5.6 Cyber pelo Daybreak Red identificaram duas vulnerabilidades previamente desconhecidas no V8, o motor JavaScript utilizado pelo Chrome. Quando encadeadas, essas falhas poderiam permitir corrupção de memória e escape do heap sandbox. A vulnerabilidade inicial foi corrigida e registrada como CVE-2026-15903 — uma das apenas quatro entradas bem-sucedidas de zero-day no V8 CTF em 2026.
Rodando na infraestrutura em que você já confia
Uma carga de trabalho de cibersegurança alimenta o modelo com os seus insumos mais sensíveis: código-fonte proprietário, detalhes de vulnerabilidades ainda não corrigidas e telemetria ao vivo de sistemas em produção. Antes de qualquer coisa passar por um modelo, é preciso ter certeza sobre para onde vai e quem pode ver.
Ambos os modelos rodam no mecanismo de inferência de nova geração do Amazon Bedrock, construído para alta performance, segurança e confiabilidade. Os principais controles incluem:
Acesso zero por operadores (ZOA — Zero-Operator Access): aplicado no nível do chip, impedindo que até mesmo operadores da AWS acessem seus prompts e respostas durante a inferência.
Criptografia: tudo é criptografado em trânsito e em repouso com chaves gerenciadas pelo cliente via Serviço de Gerenciamento de Chaves da AWS (AWS KMS — Key Management Service).
Controle de acesso e auditoria: o acesso é governado pelas suas políticas de Gerenciamento de Identidade e Acesso da AWS (AWS IAM — Identity and Access Management), registrado no AWS CloudTrail e roteado por endpoints de Nuvem Privada Virtual (VPC — Virtual Private Cloud).
Perímetro de dados: é possível configurar políticas de perímetro de dados no nível organizacional para evitar exfiltração entre limites de conta e rede.
Os dados de inferência não são utilizados para treinamento dos modelos, e nenhum dos dois modelos exige que o cliente opte por compartilhar dados com a OpenAI. Para detecção automatizada de abuso, o tráfego sinalizado por classificadores é retido pela AWS por até 30 dias e processado de forma programática. Clientes podem solicitar retenção zero de dados por meio da equipe de contas AWS. Consulte a política de retenção de dados para mais detalhes.
Como começar
O Daybreak Red (GPT-5.6 Cyber) e o Daybreak Blue (GPT-5.6 Sol) estão disponíveis para clientes elegíveis no Amazon Bedrock na seguinte região AWS: US East (N. Virginia).
O acesso aos modelos requer inscrição no programa Trusted Access for Cyber da OpenAI. Para se inscrever, entre em contato com a OpenAI ou com a equipe de contas AWS para orientação sobre elegibilidade. Após a aprovação, trabalhe com sua equipe de contas para solicitar o acesso na AWS. Para saber mais, consulte a documentação oficial.
Quando uma empresa começa a distribuir o Claude Code e o Claude Desktop para dezenas ou centenas de desenvolvedores, surgem perguntas que não têm resposta fácil sem uma camada de controle dedicada: quem está usando qual modelo? Quanto cada time está gastando? Como revogar acesso imediatamente quando alguém sai da empresa? Como garantir que contratados não acessem modelos mais caros que o necessário?
O Claude Apps Gateway foi criado exatamente para isso. Trata-se de uma camada de governança self-hosted que fica entre essas aplicações e o Amazon Bedrock (ou o Claude Platform on AWS), centralizando autenticação, políticas de acesso, telemetria e controle de custos em um único ponto. A AWS publicou agora uma referência completa de implantação em produção, expandindo o post de lançamento inicial com arquitetura detalhada, padrões corporativos e recursos de implementação.
Computação e estado: cada tarefa do Fargate executa um container stateless do gateway. O Amazon Relational Database Service (Amazon RDS) para PostgreSQL armazena o estado de autenticação de curta duração — códigos de dispositivo, sessões, contadores de gasto por usuário e registros de auditoria. Como o estado vive no banco e não no container, qualquer tarefa pode atender qualquer requisição, sem necessidade de sessões fixas no balanceador.
Conectividade de serviços: endpoints de VPC mantêm o tráfego de serviços AWS no perímetro privado, enquanto um NAT gateway fornece o egresso externo necessário.
Credenciais upstream: o gateway se autentica no Amazon Bedrock usando a role do AWS Identity and Access Management (IAM) atribuída à tarefa. A chave de API do Claude Platform on AWS e outras credenciais estáticas ficam no AWS Secrets Manager. Nenhuma credencial upstream chega às máquinas dos desenvolvedores.
Nota operacional importante: o timeout de inatividade do load balancer deve ser configurado para superar o maior intervalo esperado sem dados. O padrão é 60 segundos — conexões ociosas além desse limite são encerradas. Vale verificar tanto respostas não-streaming com atraso quanto pausas entre chunks em respostas streaming.
O fluxo tem duas etapas distintas. No login (uma vez por sessão), o time de plataforma distribui configurações gerenciadas (managed settings) que apontam o Claude Code e o Claude Desktop para a URL privada do gateway. Quando o desenvolvedor executa /login, o cliente inicia o fluxo OAuth 2.0 de autorização de dispositivo e abre o navegador para autenticação via provedor de identidade OpenID Connect (OIDC). Após autenticação, o gateway emite um token de curta duração (válido por 1 hora por padrão), com renovação silenciosa em background.
Nas requisições de inferência, cada chamada carrega o bearer token. O gateway o valida, resolve identidade e grupos do desenvolvedor, aplica a política correspondente, avalia o limite de gasto e roteia a requisição para o Amazon Bedrock ou Claude Platform on AWS. A resposta retorna em streaming. As métricas de uso são encaminhadas via Protocolo OpenTelemetry (OTLP) para o coletor configurado, atribuídas à identidade autenticada.
O gateway delega a autenticação ao provedor de identidade OIDC da empresa. Os desenvolvedores fazem login uma única vez via SSO no navegador. Provedores compatíveis incluem Okta, Microsoft Entra ID, Auth0, Keycloak e Amazon Cognito.
O gateway não mantém diretório de usuários próprio — não há contas para pré-criar nem sincronização SCIM para configurar. Os grupos que o provedor de identidade atribui ao usuário são os mesmos usados para correspondência de políticas, sem camada de tradução. O desligamento de um colaborador é simplesmente removê-lo do provedor: a sessão expira dentro do tempo configurado (1 hora por padrão), sem necessidade de rotacionar credenciais.
Atenção: o Microsoft Entra ID não inclui claims de grupo ou role por padrão. Se as políticas usarem match: {groups: [...]} com roles do Entra, é necessário adicionar groups_claim: roles à configuração OIDC. Sem isso, o gateway não consegue resolver membros de grupo e todos os usuários correspondem apenas à política catch-all. Para instruções específicas por provedor, consulte o guia de configuração de provedores de identidade.
2. Políticas centralizadas de acesso a modelos
O gateway aplica o controle de acesso a modelos no lado do servidor e distribui permissões de ferramentas como configurações gerenciadas, com escopo por grupo do provedor de identidade. As políticas são avaliadas na ordem de declaração — a primeira correspondência é selecionada e mesclada com a política base match: {}. Sempre inclua uma política match: {} ao final como catch-all; sem ela, usuários sem correspondência recebem acesso irrestrito ao catálogo.
Managed:
policies:
# Contratados: apenas Haiku, sem acesso à web
- match: { groups: [contractors] }
cli:
availableModels: [claude-sonnet-5, claude-haiku-4-5]
enforceAvailableModels: true
permissions:
deny: ["WebFetch", "WebSearch"]
# Engenheiros: acesso completo com restrições
- match: { groups: [engineers] }
cli:
availableModels: [claude-opus-4-8, claude-sonnet-5, claude-haiku-4-5]
permissions:
allow: [Read, Grep, Bash, Edit]
deny: ["Read(./.env)", "Read(./secrets/**)"]
# Catch-all: todos os outros usuários autenticados. Deve ser o último.
- match: {}
cli:
availableModels: [claude-haiku-4-5, claude-sonnet-5]
O controle de modelos é aplicado no servidor. Um desenvolvedor cujo grupo permite apenas Claude Haiku não consegue contornar a restrição, mesmo com um cliente modificado. O seletor de modelos no Claude Code e no Claude Desktop exibe apenas os modelos permitidos. Alterações propagam para clientes conectados em até uma hora, sem ação necessária dos desenvolvedores.
Atenção: inclua desktop: {} em cada entrada de política para habilitar clientes Claude Desktop. Sem isso, o gateway rejeita requisições de inferência do Desktop para usuários que correspondem àquela política, mesmo que o login tenha sido bem-sucedido. Para o schema completo de políticas, consulte a referência de configuração.
3. Telemetria e atribuição por usuário
O cliente emite métricas de uso (claude_code.token.usage, claude_code.cost.usage e claude_code.active_time.total) atribuídas à identidade do desenvolvedor autenticado: ID de usuário, e-mail e grupos. O gateway repassa essa telemetria via Protocolo OpenTelemetry (OTLP) para o coletor configurado. Backends compatíveis incluem Datadog, Splunk, Grafana e Amazon CloudWatch via coletor AWS Distro for OpenTelemetry (ADOT).
Logs e traces são opt-in porque podem conter código-fonte e conteúdo de prompts. A maioria das implantações começa apenas com métricas, que fornecem breakdowns de custo e uso por usuário sem expor dados sensíveis. Mais detalhes na página de configuração do Claude Apps Gateway.
4. Roteamento com failover
O gateway roteia inferência para um ou mais upstreams na ordem declarada, com failover automático em caso de indisponibilidade, throttling ou timeout. É possível combinar Amazon Bedrock em múltiplas regiões e Claude Platform on AWS:
upstreams:
# Amazon Bedrock (usa a role da task ECS, sem chaves estáticas)
- name: bedrock-east
provider: bedrock
region: us-east-1
auth: {}
# Amazon Bedrock em segunda região para failover
- name: bedrock-west
provider: bedrock
region: us-west-2
auth: {}
# Claude Platform on AWS (fallback entre provedores)
- name: claude-platform
provider: anthropicAws
region: us-east-1
workspace_id: wrkspc_01ABCDEFGHIJKLMN
auth:
api_key: ${ANTHROPIC_AWS_API_KEY}
Atenção: failover entre provedores diferentes pode alterar os termos de serviço aplicáveis e a geografia de processamento de dados. Para o schema completo de upstreams, consulte a referência de upstreams.
5. Limites de gasto por usuário
Enquanto o AWS Budgets e o AWS Cost Explorer oferecem visibilidade no nível de conta com agregação periódica, o gateway complementa essas ferramentas com enforcement inline antes da inferência ocorrer. Os limites operam em três níveis: padrão organizacional, por grupo e por usuário (com precedência nessa ordem, do mais específico para o mais geral). Cada limite se aplica individualmente por desenvolvedor, não como pool compartilhado.
# Padrão organizacional: $500/mês por desenvolvedor (valores em centavos de USD)
curl -X POST https://<gateway>/v1/organizations/spend_limits \
-H "x-api-key: $ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"scope":{"type":"organization"},"amount":"50000","period":"monthly"}'
# Limite mais restritivo para um grupo: $10/dia para contratados
curl -X POST https://<gateway>/v1/organizations/spend_limits \
-H "x-api-key: $ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"scope":{"type":"rbac_group","rbac_group_id":"contractors"},"amount":"1000","period":"daily"}'
# Bloqueio imediato de um usuário: limite zerado
curl -X POST https://<gateway>/v1/organizations/spend_limits \
-H "x-api-key: $ADMIN_KEY" \
-H "Content-Type: application/json" \
-d '{"scope":{"type":"user","user_id":"<oidc-sub>"},"amount":"0","period":"daily"}'
Quando o desenvolvedor atinge o teto, o gateway retorna HTTP 429 imediatamente. Os contadores resetam automaticamente no início de cada período (diário, semanal ou mensal). Os limites de gasto são gerenciados exclusivamente via Admin API — não há interface gráfica. Times de plataforma tipicamente automatizam isso com um script que sincroniza limites de um arquivo de configuração versionado como parte do pipeline de deploy, ou via Terraform chamando a API.
Limitações importantes: o gasto é estimado com base em contagens de tokens pelo preço de tabela — é um circuit breaker em tempo real, não uma fatura. Descontos por uso comprometido e taxas negociadas não são refletidos. Se o banco de dados estiver indisponível, o enforcement falha aberto por padrão (inferência continua). Organizações que precisam de enforcement estrito podem configurar fail_closed_on_error: true para bloquear requisições. Para faturamento definitivo, reconcilie com os logs de invocação do Amazon Bedrock ou o AWS Cost and Usage Report. Detalhes completos na documentação de limites de gasto.
Padrões de implantação
A forma de implantar o gateway depende da estrutura da organização, dos padrões de tráfego e dos requisitos de governança. Não existe uma arquitetura única correta. A AWS descreve cinco padrões principais:
Padrão A: Time único, região única
Recomendado para times avaliando o gateway ou organizações com um único grupo de desenvolvimento em uma região. Implantação mínima: um upstream Amazon Bedrock em us-east-1, um limite de gasto diário organizacional e todos os desenvolvedores com o mesmo acesso a modelos. Ponto de partida ideal — adicione complexidade conforme o caso de uso exigir.
Padrão B: Multi-time com acesso diferenciado
Indicado para organizações com múltiplos times que precisam de níveis diferentes de acesso a modelos e limites de gasto. Os grupos do provedor de identidade direcionam políticas diferenciadas. Por exemplo: engenharia de plataforma com acesso a Opus + Sonnet + Haiku e $50/dia; desenvolvedores de aplicação com Sonnet + Haiku e $20/dia; contratados apenas com Haiku, $5/dia e ferramentas web bloqueadas. Os limites de grupo são herdados individualmente por cada desenvolvedor, não como orçamento compartilhado.
Padrão C: Amazon Bedrock + Claude Platform on AWS (híbrido)
Ideal para organizações que querem o Amazon Bedrock como upstream preferencial com o Claude Platform on AWS como capacidade de overflow. As requisições vão primeiro para o Bedrock; somente em caso de rate limit ou indisponibilidade o gateway faz fallback para o Claude Platform on AWS.
Padrão D: Gateway para ferramentas de desenvolvimento, Bedrock direto para aplicações
Recomendado para organizações onde as ferramentas de desenvolvimento precisam de governança (SSO, limites de gasto, telemetria), mas as aplicações de produção chamam o Amazon Bedrock diretamente com cotas isoladas e acesso a funcionalidades nativas como Amazon Bedrock Knowledge Bases, Agents e Flows — que o gateway não faz proxy.
Recomendado para organizações onde um time central de plataforma opera o gateway e unidades de negócio individuais possuem seu próprio acesso ao Amazon Bedrock em contas separadas. O faturamento cai na conta de cada time; o gateway roteia para o upstream correto com base na configuração de modelos.
Atenção: o gateway não assume nativamente uma role IAM diferente por upstream. O roteamento multi-conta requer credenciais explícitas na configuração de upstreams. Armazene essas credenciais no AWS Secrets Manager e rotacione-as periodicamente. Chaves de acesso de longa duração representam um tradeoff significativo de segurança. Considere um processo externo que atualize periodicamente credenciais de curta duração do AWS Security Token Service (AWS STS) no ambiente do gateway para reduzir a exposição.
O Claude Apps Gateway entrega cinco capacidades — autenticação SSO, políticas de modelos por grupo, telemetria por usuário, roteamento multi-região com failover e limites de gasto — em um único container e um arquivo YAML. Não há taxa por assento. Quando o Amazon Bedrock é o upstream, nenhum dado dos desenvolvedores sai da conta AWS. Os desenvolvedores continuam usando o mesmo binário claude que já conhecem; o gateway é invisível para eles após o login inicial.
Para começar, clone o repositório no GitHub e escolha uma de duas trilhas — ambas provisionam o mesmo deployment no Amazon ECS Fargate: um ALB interno, Amazon RDS para PostgreSQL, ECR, Secrets Manager, uma role IAM para a task e um coletor de telemetria ADOT. A escolha é entre o script idempotente setup.sh, para visibilidade total de cada chamada AWS, ou um stack do AWS Cloud Development Kit (AWS CDK) para um ciclo de vida gerenciado. Para detalhes de configuração, consulte a documentação do Claude Apps Gateway.
O que é o C5:2020 e por que isso importa para empresas na Europa
Organizações que operam na Alemanha e em outros países europeus enfrentam uma exigência crescente: precisam comprovar que seus ambientes de nuvem estão em conformidade com o Catálogo de Critérios de Conformidade para Computação em Nuvem (C5:2020), um padrão publicado pelo Escritório Federal de Segurança da Informação da Alemanha (BSI — Bundesamt für Sicherheit in der Informationstechnik). Trata-se de um dos marcos regulatórios mais rigorosos da Europa para uso de nuvem pública, e atender a ele exige esforço considerável de arquitetura, documentação e evidências técnicas.
É nesse contexto que a AWS fez um anúncio relevante: a disponibilização de um novo relatório de avaliação independente no AWS Artifact, que analisa como o Landing Zone Accelerator (LZA) cobre os requisitos do C5:2020 por meio da implementação de quase 200 controles de segurança nativos.
O que é o Landing Zone Accelerator (LZA)
O Landing Zone Accelerator (LZA) é uma solução da AWS que automatiza a criação de um ambiente de nuvem seguro e bem arquitetado desde o início. Ele define uma linha de base de arquitetura de segurança e provisiona automaticamente o ambiente AWS de forma que ele escale conforme a organização cresce.
O LZA pode ser utilizado em duas configurações: a configuração padrão com múltiplas contas (multi-account) ou como uma opção de implantação baseada em contêiner no AWS European Sovereign Cloud. Essa segunda opção é especialmente importante para clientes com requisitos de residência de dados, pois permite usar a mesma linha de base de configuração de segurança em um ambiente soberano europeu.
No ano passado, a AWS já havia introduzido suporte do LZA para soberania digital. Agora, o passo seguinte é a publicação desse relatório de avaliação independente voltado ao C5:2020.
O que traz o novo relatório de avaliação independente
O LZA pode ajudar a implementar 325 controles de segurança no total, distribuídos em oito áreas de controle do C5:2020.
O documento descreve o design da arquitetura do LZA, as melhores práticas de segurança e as considerações de escopo para avaliações C5:2020.
Este é o primeiro relatório C5 independente para o LZA — e está prevista uma atualização em 2027 para cobrir a revisão C5:2026, que ainda está pendente.
Como isso acelera a jornada de conformidade
É importante entender a diferença entre o que a AWS já oferecia e o que esse novo relatório acrescenta. A AWS já disponibiliza os relatórios de atestação C5 Tipo 2, que cobrem a “segurança da nuvem” — ou seja, a responsabilidade da própria AWS como provedora de infraestrutura. O novo relatório do LZA, por sua vez, oferece uma opinião independente sobre como a linha de base de segurança provisionada pelo LZA se alinha aos critérios de “segurança na nuvem” — a parte que é responsabilidade do cliente.
Essa distinção é fundamental dentro do modelo de responsabilidade compartilhada. O LZA assume parte dessa responsabilidade do lado do cliente, definindo uma arquitetura de segurança e automatizando o provisionamento do ambiente. Com o relatório em mãos, as organizações podem:
Implantar o LZA já com uma cobertura de controles documentada e avaliada de forma independente;
Usar o relatório para entender o escopo de cobertura existente e identificar o que ainda precisa ser customizado;
Utilizar o LZA Compliance Workbook para construir e adaptar a documentação de conformidade para os casos de uso específicos da organização.
O resultado prático é uma redução significativa no tempo gasto com design de arquitetura, coleta de evidências e preparação para avaliações C5:2020.
Recursos disponíveis: Workbook, repositório e agente de conformidade com IA
Além do relatório de avaliação, a AWS também disponibilizou no AWS Artifact o LZA Compliance Workbook gratuitamente. Esse documento mapeia os identificadores de requisitos do C5:2020 para declarações de implementação de segurança, oferecendo um ponto de partida para que as equipes possam customizar e aprimorar a documentação de conformidade após implantar o LZA.
Por que isso é relevante para o público brasileiro
Embora o C5:2020 seja um padrão alemão, ele é cada vez mais adotado como referência de conformidade em toda a Europa — e empresas brasileiras com operações no continente europeu ou que atendem clientes europeus precisam estar atentas a esse tipo de exigência regulatória. Além disso, a abordagem do LZA — automatizar uma linha de base de segurança documentada e avaliada de forma independente — é um modelo que pode inspirar práticas de conformidade em outros contextos regulatórios.
A disponibilização desse relatório no AWS Artifact representa um avanço concreto para reduzir a carga de trabalho de equipes de segurança e conformidade que precisam demonstrar aderência a padrões rigorosos sem partir do zero.
A AWS anunciou uma expansão importante na capacidade de rastreamento de custos do Amazon Bedrock: agora é possível alocar custos de inferência de modelos por principal do Gerenciamento de Identidade e Acesso (IAM), incluindo usuários e funções (roles) do IAM, para requisições feitas pelo endpoint bedrock-mantle.
Essa funcionalidade já existia para o endpoint bedrock-runtime e agora chega ao bedrock-mantle, completando a cobertura para equipes que utilizam os dois pontos de acesso do serviço.
Por que isso importa
Em ambientes corporativos, múltiplos times, projetos e aplicações costumam compartilhar a mesma conta AWS — e saber exatamente quem está gerando qual custo de inferência de IA é uma necessidade real de governança financeira. Com essa expansão, a AWS permite que as organizações atribuam os custos de inferência do bedrock-mantle a usuários, equipes, projetos e aplicações de forma granular.
Como funciona na prática
O mecanismo é baseado em tags de alocação de custos do IAM. O fluxo funciona da seguinte forma:
Adicione tags aos usuários e funções do IAM com atributos relevantes, como equipe, projeto ou centro de custo.
Ative essas tags como tags de alocação de custos no console de Faturamento e Gerenciamento de Custos da AWS.
Filtre ou agrupe os custos por essas tags no AWS Cost Explorer.
Alternativamente, crie uma exportação de dados no Relatório de Custo e Uso 2.0 (CUR 2.0) e selecione a opção Include caller identity (IAM principal) allocation data para obter os dados no nível de linha de item.
Disponibilidade
O recurso está disponível em todas as regiões da AWS onde o endpoint bedrock-mantle já está disponível.
Renovação da acreditação PASF para dados policiais no Reino Unido
A Amazon Web Services (AWS) concluiu com sucesso a renovação da sua acreditação junto ao programa Instalações Seguras Garantidas pela Polícia (PASF, do inglês Police-Assured Secure Facilities) para a região Europa (Londres). A confirmação foi emitida pelo Serviço Digital da Polícia (PDS, do inglês Police Digital Service) em 28 de maio de 2026.
Essa renovação mantém a continuidade de uma acreditação que a AWS sustenta desde 2017 nessa região, demonstrando um histórico consistente de conformidade com os requisitos de segurança exigidos pelo setor de segurança pública do Reino Unido.
O que é o PASF e por que ele importa
O PASF é um processo de auditoria consolidado, utilizado pelas forças policiais do Reino Unido para verificar se instalações como data centers e outros ambientes que processam ou armazenam dados policiais atendem a padrões elevados de segurança. Trata-se de um mecanismo voltado especificamente para dados classificados como Official-Sensitive, categoria que engloba informações sensíveis relacionadas à atividade policial.
Para ser acreditada, uma instalação precisa cumprir três etapas principais:
Atender a um conjunto de requisitos de controles de segurança;
Passar por uma inspeção presencial nas instalações;
Participar de uma entrevista de auditoria com representantes da instalação.
Com a renovação confirmada, as organizações de segurança pública e as forças policiais do Reino Unido que utilizam a AWS podem continuar operando suas aplicações na região Europa (Londres) com a segurança de que o ambiente está em conformidade com as exigências do PASF.
Como acessar a confirmação da acreditação
A carta de confirmação da renovação está disponível no AWS Artifact, o repositório central da AWS para documentos de conformidade e relatórios de auditoria. Além disso, as forças policiais e organizações de segurança pública do Reino Unido também podem obter informações sobre o status de conformidade da AWS diretamente por meio do Serviço Digital da Polícia.
Conformidade e programas de segurança da AWS
Para quem quiser entender mais sobre os programas de conformidade e segurança mantidos pela AWS, a empresa disponibiliza uma visão geral completa na página de Programas de Conformidade da AWS. Lá é possível consultar as diversas certificações e acreditações que a AWS mantém em diferentes regiões e setores regulados ao redor do mundo.
Essa renovação é um indicativo relevante para equipes de TI e compliance que atendem clientes ou projetos ligados à segurança pública britânica: a infraestrutura da AWS na região Europa (Londres) segue apta para hospedar cargas de trabalho que exigem o padrão PASF.
AWS conclui avaliação CyberVadis 2026 com pontuação máxima
A Amazon Web Services (AWS) concluiu sua avaliação anual de segurança pela CyberVadis e obteve a pontuação máxima — classificação Mature (Maduro) — em todas as áreas avaliadas. O relatório e o scorecard do AWS CyberVadis 2026 já estão disponíveis para que clientes possam utilizá-los em seus processos de due diligence de fornecedores terceiros.
Por que isso importa para clientes AWS?
Com a adoção crescente de serviços de nuvem em múltiplos setores e indústrias, a AWS passou a ser um componente crítico nos ambientes de terceiros de muitas organizações. Clientes em setores regulados — como o financeiro — precisam atender a padrões rigorosos impostos por reguladores e auditores no que diz respeito à due diligence efetiva sobre seus fornecedores e parceiros tecnológicos.
Para atender a essa demanda, muitas empresas recorrem a serviços de gestão de risco de terceiros, como o CyberVadis, a fim de gerenciar melhor os riscos do seu ecossistema de parceiros e aumentar a eficiência operacional. O relatório AWS CyberVadis 2026 reduz diretamente a carga de trabalho dessas equipes, eliminando a necessidade de solicitações manuais de acesso para avaliação anual da AWS.
O que é a avaliação CyberVadis?
O CyberVadis é um processo abrangente de avaliação de risco de terceiros que combina a velocidade e escalabilidade da automação com a validação realizada por analistas especializados. Essa abordagem dinâmica substitui as planilhas estáticas tradicionais, integrando as respostas da AWS com análises e modelos sofisticados de risco para entregar uma visão aprofundada da postura de segurança da organização avaliada.
A metodologia de avaliação do CyberVadis cobre 20 tópicos que abrangem todo o ciclo de vida da cibersegurança, distribuídos em quatro fases:
Identify (Identificar)
Protect (Proteger)
Detect (Detectar)
React (Reagir)
Entre os tópicos avaliados estão Privacidade de Dados, Gestão de Acesso e Segurança de Infraestrutura. Os critérios de avaliação são baseados em padrões internacionais de segurança da informação, incluindo ISO 2700x, NIST Cybersecurity Framework, Cybersecurity for ICS, PCI DSS, NIS2 e GDPR.
Como acessar o relatório?
Os clientes AWS podem utilizar os resultados do CyberVadis para mapear a avaliação da AWS em relação aos frameworks e padrões de mercado mais utilizados, obtendo visibilidade imediata sobre a cobertura de controles de segurança.
O relatório completo da Avaliação AWS 2026 pode ser obtido de duas formas:
A AWS anunciou que o Amazon Cognito está agora disponível como uma skill central — identificada como aws-auth — dentro do Agent Toolkit for AWS. Com essa integração, agentes de codificação baseados em Inteligência Artificial (IA) passam a ter capacidade nativa de configurar, proteger e depurar o Amazon Cognito seguindo fluxos de trabalho alinhados às boas práticas da AWS.
Na prática, isso significa que desenvolvedores podem implementar fluxos seguros de autenticação para usuários, agentes de IA e microsserviços com muito mais agilidade, delegando parte do trabalho repetitivo e técnico aos próprios agentes.
O que a skill aws-auth cobre
A skill aws-auth do Amazon Cognito abrange um conjunto abrangente de funcionalidades de autenticação e autorização, incluindo:
Configuração de user pools (grupos de usuários) e clientes de aplicação
Login gerenciado e fluxos OAuth 2.0
Gerenciamento de tokens e autorizadores JWT (JSON Web Token)
Cadastro de passkeys e WebAuthn
Proteção contra ameaças
Conexão de gatilhos Lambda
Configuração de identity pools (grupos de identidade)
É uma cobertura bastante ampla, indo desde o básico de autenticação até recursos mais avançados de segurança e federação de identidade.
Integração com o AWS MCP Server e uso standalone
Quando utilizada em conjunto com o AWS MCP Server, a skill permite que os agentes executem comandos da Interface de Linha de Comando (CLI) da AWS com guardrails baseados em IAM (Gerenciamento de Identidade e Acesso) e registro de auditoria via CloudTrail. Isso garante rastreabilidade e controle sobre as ações executadas pelos agentes.
Para quem prefere uma abordagem mais direta, a skill também funciona de forma independente, apenas via CLI da AWS, sem necessidade de integração com o servidor MCP.
Como começar
A skill aws-auth do Amazon Cognito já está disponível como parte do Agent Toolkit for AWS. Para quem quiser explorar o recurso, a AWS disponibiliza dois pontos de entrada:
Autenticação e autorização são etapas críticas em qualquer aplicação, e também são áreas onde erros de configuração costumam gerar vulnerabilidades sérias. Ao trazer o Cognito como uma skill nativa para agentes de IA, a AWS está apostando que parte dessas configurações pode ser feita de forma mais consistente e segura quando guiada por fluxos de trabalho pré-validados — reduzindo a margem de erro humano e acelerando o desenvolvimento.
Dez anos resolvendo um problema real de identidade
Em 2015, a AWS lançou o AWS Directory Service para Microsoft Active Directory, entregando o Active Directory (AD) da Microsoft como um serviço totalmente gerenciado na nuvem. A promessa era direta: as equipes deveriam gastar menos tempo administrando infraestrutura de diretório e mais tempo focadas em suas aplicações e negócios.
Uma década depois, o AWS Managed Microsoft AD se consolidou como a espinha dorsal de identidade de milhares de empresas ao redor do mundo. O que começou como uma solução para rodar workloads Windows na nuvem hoje sustenta autenticação no SQL Server, desktops virtuais com o Amazon WorkSpaces e compartilhamentos de arquivos com o Amazon FSx para Windows File Server em escala global.
O contexto do problema original era bem claro: ao migrar workloads Windows para a Amazon Web Services (AWS), as empresas dependiam do AD da Microsoft, que segundo algumas estimativas detinha 90% do mercado de serviços de diretório nas empresas Fortune 1000. Rodar SharePoint, SQL Server, aplicações .NET ou praticamente qualquer workload Windows significava rodar AD — e rodar AD bem exigia planejamento de capacidade, alta disponibilidade entre múltiplos sites, patching contínuo, backups, recuperação de desastres e expertise cada vez mais difícil de encontrar.
A resposta da AWS foi construir um serviço que entregasse o AD real da Microsoft — não uma alternativa compatível, mas o produto genuíno — como serviço gerenciado. A implantação dos domain controllers, a alta disponibilidade multi-AZ, os backups automatizados, o patching e o monitoramento passaram a ser responsabilidade da AWS. O cliente provisiona um diretório em 25 a 30 minutos e começa a usar imediatamente.
Uma década de evolução: os marcos principais
Ao longo de dez anos, o serviço evoluiu substancialmente em resposta ao feedback dos clientes. Veja os principais marcos:
2015: Lançamento do AWS Managed Microsoft AD (Enterprise Edition) em cinco regiões AWS, baseado no Windows Server 2012 R2. Suporte a trust relationships com AD on-premises, domain join para instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e integração com o Amazon WorkSpaces.
2017: Introdução da Standard Edition, otimizada para pequenas e médias empresas, com uma opção mais econômica para deployments de resource forest e workloads menores.
2018: Suporte a extensões de schema, permitindo que clientes estendam o schema do diretório para aplicações que precisam de atributos personalizados. Também foi adicionado suporte a Contas de Serviço Gerenciadas por Grupo (gMSA) para containers Windows.
2019: Lançamento da replicação multi-região para a Enterprise Edition, permitindo replicar o diretório automaticamente entre regiões AWS para melhor desempenho e recuperação de desastres. Adicionado também o compartilhamento de diretório entre contas AWS e integração com o AWS Organizations.
2020: Introdução de configurações granulares de diretório para segurança e conformidade, permitindo configurar canais seguros para protocolos e cifras. O serviço passou a ser elegível para HIPAA, incluído no escopo do PCI DSS e com autorização FedRAMP.
2022:Atualização para Windows Server 2019 disponível, com atualizações iniciadas pelo cliente e migração automática para todos os diretórios a partir de 2023.
2023: Lançamento do AWS Private CA Connector para Active Directory, permitindo substituir autoridades certificadoras corporativas autogerenciadas pelo AWS Private CA para enrollment automático de certificados em objetos ingressados no domínio, sem agentes locais ou servidores proxy.
2025: Disponibilidade geral do AWS Managed Microsoft AD (Hybrid Edition), permitindo estender um domínio AD existente para a AWS mantendo o controle administrativo. Introdução de upgrades de edição self-service via API UpdateDirectorySetup, eliminando a necessidade de abrir tickets de suporte ao escalar da Standard para a Enterprise Edition.
Identidade como base para mais de 20 serviços AWS
Ao longo da última década, mais de 20 serviços AWS adicionaram integração nativa com o AWS Managed Microsoft AD, tornando-o um componente fundamental para os workloads corporativos na nuvem.
Serviços de banco de dados
Para muitos clientes, a autenticação em banco de dados é um dos principais motivadores para adotar o AWS Managed Microsoft AD. Ao combinar o Amazon Relational Database Service (Amazon RDS) para SQL Server com o serviço de diretório gerenciado, as equipes ganham os benefícios de ambos os serviços totalmente gerenciados: desenvolvedores e DBAs usam suas credenciais AD existentes para acessar bancos de dados SQL Server, sem precisar gerenciar contas separadas. Além do SQL Server, a autenticação Windows está disponível para Amazon RDS para Oracle, PostgreSQL, MySQL e DB2, além de Amazon Aurora MySQL e Aurora PostgreSQL.
Serviços de armazenamento de arquivos
O Amazon FSx para Windows File Server oferece compartilhamentos de arquivos Windows totalmente gerenciados com integração nativa ao AWS Managed Microsoft AD. Clientes usam usuários e grupos do AD para controlar o acesso a file shares, aplicar ACLs do Windows e usar recursos como namespaces DFS, com a mesma experiência de gerenciamento que já conhecem on-premises.
O AWS Storage Gateway suporta autenticação AD para file shares SMB, habilitando arquiteturas de armazenamento híbrido. Já o AWS Transfer Family adicionou integração com AD em 2021, permitindo autenticar usuários SFTP, FTPS e FTP contra o AWS Managed Microsoft AD sem alterar as credenciais dos usuários finais.
Computação de usuário final
Os serviços de computação para usuário final foram dos primeiros a integrar com o AWS Managed Microsoft AD:
Amazon WorkSpaces: desktops virtuais provisionados e autenticados via AD
Amazon Workspaces Applications (anteriormente AppStream 2.0): streaming de aplicações com instâncias de frota ingressadas no domínio
Amazon WorkMail: e-mail corporativo vinculado às identidades do AD
Segurança e identidade
O AWS IAM Identity Center (anteriormente AWS Single Sign-On) usa o AWS Managed Microsoft AD como fonte de identidade, sincronizando usuários e grupos para fornecer acesso single sign-on em contas e aplicações AWS. O AWS Client VPN autentica usuários contra o AD, oferecendo acesso remoto seguro com credenciais corporativas. Além disso, o acesso ao Console de Gerenciamento AWS pode ser federado via AD, permitindo que usuários assumam funções do Gerenciamento de Identidade e Acesso AWS (IAM) com suas credenciais existentes.
Computação e containers
Instâncias do Amazon EC2 (Windows e Linux) suportam domain join automático na inicialização. Instâncias Windows podem ser gerenciadas por Group Policy, e instâncias Linux autenticam usuários via SSSD ou integração com Realm. O Amazon Elastic Container Service (Amazon ECS) suporta autenticação AD para containers Windows via gMSA, permitindo que aplicações containerizadas se autentiquem em recursos integrados ao AD.
Aplicações de negócios
O Amazon QuickSight oferece inteligência de negócios com provisionamento de usuários baseado em AD. O Amazon Connect usa o AD para autenticação de agentes de contact center.
Escolhendo a edição certa
Atualmente, o AWS Managed Microsoft AD está disponível em três edições, cada uma pensada para casos de uso específicos.
Standard Edition
Otimizada para pequenas e médias empresas, ou para empresas que implantam um modelo de resource forest em uma única região AWS. Com 1 GB de armazenamento de objetos de diretório, suporta até 30.000 objetos (aproximadamente 5.000 usuários). É uma boa opção para deployments de resource forest com trust para AD on-premises, ambientes de desenvolvimento e teste, e aplicações de região única.
Clientes que começam com a Standard Edition não ficam presos nela: com a nova funcionalidade de upgrade self-service (lançada em outubro de 2025), é possível migrar para a Enterprise Edition programaticamente via API UpdateDirectorySetup, sem tickets de suporte ou coordenação de janelas de manutenção.
Enterprise Edition
Projetada para organizações com populações de usuários maiores, deployments complexos ou presença global. Com 17 GB de armazenamento, suporta até 500.000 objetos de diretório. Os principais diferenciais incluem replicação multi-região automática (usuários e aplicações se conectam a domain controllers locais, reduzindo latência e garantindo recuperação de desastres), compartilhamento de diretório com até 500 contas AWS via AWS Organizations, e instâncias de domain controller maiores para workloads exigentes.
Hybrid Edition
Lançada em 2025, a Hybrid Edition adota uma abordagem fundamentalmente diferente: em vez de criar um novo domínio AD na AWS, ela estende o domínio AD existente do cliente para a nuvem. Os domain controllers gerenciados pela AWS ingressam no domínio existente — sem novo nome de domínio, sem trust relationships para configurar. Os administradores AD mantêm seus direitos administrativos completos e continuam usando as ferramentas que já conhecem, enquanto as mudanças replicam para a AWS em tempo real. Identidades de segurança, Group Policies e permissões são transferidas de forma transparente, sem necessidade de migração.
A Hybrid Edition é ideal para clientes que querem os benefícios operacionais da infraestrutura de domain controllers gerenciada pela AWS sem mudar a arquitetura do AD ou abrir mão do controle administrativo.
Resumo de escolha por caso de uso
Novo domínio AD para workloads AWS em região única: Standard Edition
Resource forest com trust para AD on-premises: Standard Edition
Replicação multi-região para deployments globais: Enterprise Edition
Suporte a mais de 30.000 objetos de diretório: Enterprise Edition
Estender domínio AD existente para AWS: Hybrid Edition
Manter controle administrativo total sobre o AD: Hybrid Edition
Decisões de design que resistiram ao tempo
Olhando para trás, algumas decisões tomadas em 2015 se mostraram fundamentais para o sucesso do serviço:
Alta disponibilidade por padrão: todo diretório AWS Managed Microsoft AD é implantado com no mínimo dois domain controllers em Zonas de Disponibilidade separadas. Os clientes não precisam projetar arquitetura de HA — ela já vem embutida.
AD real da Microsoft: a decisão de rodar o AD genuíno do Windows Server, e não uma alternativa compatível, significa que as ferramentas de administração padrão funcionam, scripts e automações existentes funcionam, e aplicações que dependem de comportamentos específicos do AD geralmente funcionam sem modificação.
Integração nativa com serviços AWS: ao construir integrações nativas entre o AWS Managed Microsoft AD e outros serviços AWS, tornou-se possível usar um único diretório em todo o ambiente AWS.
Cliente mantém o controle: enquanto a AWS gerencia a infraestrutura, o cliente gerencia o conteúdo do diretório — usuários, grupos, OUs e políticas — usando ferramentas familiares.
Espaço para crescer: o modelo de edições (e agora os upgrades self-service) permite que clientes comecem com o que precisam hoje e escalem conforme os requisitos evoluem.
O que vem pela frente
O lançamento da Hybrid Edition em 2025 representa uma expansão significativa do que é possível, dando aos clientes nova flexibilidade para arquitetar sua infraestrutura de identidade em ambientes híbridos e multi-cloud. A AWS sinaliza que o roadmap continua sendo moldado pelo feedback dos clientes que dependem do serviço diariamente, com novas capacidades em desenvolvimento.
Buckets do Amazon Simple Storage Service (Amazon S3) com configurações permissivas demais são um risco silencioso. Políticas de bucket ou Listas de Controle de Acesso (ACLs) muito abertas podem passar despercebidas por meses — até que um dado sensível seja exposto. A boa notícia é que a AWS documentou um fluxo de trabalho completo para identificar e remediar esse problema de forma estruturada.
O guia é voltado para engenheiros de segurança, arquitetos de nuvem e times de DevOps que gerenciam ambientes AWS com cargas de trabalho no S3 — tanto em conta única quanto em ambientes multi-account via AWS Organizations.
Visão geral da solução: cinco fases
A abordagem proposta pela AWS organiza o trabalho em cinco fases sequenciais:
Fase 1 – Configuração e pré-requisitos: preparar o ambiente, designar uma conta central de segurança, implantar o AWS Config em todas as contas e habilitar o AWS Security Hub com administrador centralizado.
Fase 2 – Detecção e identificação: implantar regras do AWS Config e uma função Lambda de auditoria que escaneia cada bucket verificando três pontos: configuração de bloqueio de acesso público, status da política do bucket e concessões via ACL.
Fase 3 – Remediação: aplicar políticas restritivas de bucket, automatizar correções via AWS Lambda ou distribuir configurações padronizadas com AWS CloudFormation StackSets.
Fase 4 – Monitoramento contínuo: agendar scans recorrentes via Amazon EventBridge, habilitar o IAM Access Analyzer para S3 e configurar alertas automáticos para novas violações.
Fase 5 – Limpeza de recursos: revisar e remover os recursos criados durante a auditoria que não são mais necessários.
O coração da solução é uma função Lambda escrita em Python usando a biblioteca Boto3. Ela percorre todos os buckets da conta e verifica três condições:
Bloqueio de acesso público: todos os quatro parâmetros do Public Access Block devem estar habilitados (BlockPublicAcls, BlockPublicPolicy, IgnorePublicAcls e RestrictPublicBuckets).
Status da política do bucket: se a política estiver marcada como pública, o bucket é sinalizado.
Concessões via ACL: se o ACL conceder acesso a AllUsers (acesso público anônimo) ou AuthenticatedUsers (qualquer conta AWS), o bucket é considerado de risco.
A AWS disponibiliza dois scripts de exemplo. O primeiro (Script v1) é ideal para alertas imediatos via SNS quando problemas são detectados:
import boto3
import json
def lambda_handler(event, context):
s3 = boto3.client('s3')
sns = boto3.client('sns')
risky_buckets = []
errors = []
try:
buckets = s3.list_buckets()['Buckets']
except Exception as e:
return {'statusCode': 500, 'body': f'Failed to list buckets: {str(e)}'}
for bucket in buckets:
bucket_name = bucket['Name']
issues = []
try:
# Check Public Access Block — all four settings should be enabled
try:
pab = s3.get_public_access_block(Bucket=bucket_name)
config = pab['PublicAccessBlockConfiguration']
if not all([
config.get('BlockPublicAcls'), # Block new public ACLs
config.get('BlockPublicPolicy'), # Block new public bucket policies
config.get('IgnorePublicAcls'), # Ignore existing public ACLs
config.get('RestrictPublicBuckets') # Restrict access to public buckets
]):
issues.append('Public Access Block not fully enabled')
except s3.exceptions.NoSuchPublicAccessBlockConfiguration:
issues.append('No Public Access Block configured')
# Check bucket policy — flag if policy status is public
try:
policy_status = s3.get_bucket_policy_status(Bucket=bucket_name)
if policy_status['PolicyStatus']['IsPublic']:
issues.append('Bucket policy allows public access')
except s3.exceptions.NoSuchBucketPolicy:
pass # No bucket policy is acceptable
# Check bucket ACL
acl = s3.get_bucket_acl(Bucket=bucket_name)
for grant in acl.get('Grants', []):
grantee = grant.get('Grantee', {})
uri = grantee.get('URI', '')
# 'AllUsers' = anonymous public access
# 'AuthenticatedUsers' = any AWS account (still overly permissive)
if grantee.get('Type') == 'Group' and ('AllUsers' in uri or 'AuthenticatedUsers' in uri):
issues.append('Bucket ACL grants public access')
break
if issues:
risky_buckets.append({'bucket': bucket_name, 'issues': issues})
except Exception as e:
errors.append(f'{bucket_name}: {str(e)}')
# Send alert if risky buckets found
if risky_buckets:
message = f'Found {len(risky_buckets)} buckets with public access:\n\n'
for item in risky_buckets:
message += f" {item['bucket']}: {', '.join(item['issues'])}\n"
sns.publish(
TopicArn='arn:aws:sns:<REGION>:<ACCOUNT_ID>:<TOPIC_NAME>',
Subject='S3 Public Access Alert',
Message=message
)
return {
'statusCode': 200,
'body': json.dumps({
'risky_buckets': risky_buckets,
'errors': errors,
'total_checked': len(buckets)
})
}
O segundo (Script v2) gera relatórios em CSV e JSON para análise histórica e integração com ferramentas de BI:
import boto3
import csv
import json
import os
def lambda_handler(event, context):
s3 = boto3.client('s3')
buckets = s3.list_buckets()['Buckets']
full_access_buckets = []
for bucket in buckets:
bucket_name = bucket['Name']
try:
bucket_policy = s3.get_bucket_policy(Bucket=bucket_name)['Policy']
policy = json.loads(bucket_policy)
for statement in policy['Statement']:
if (statement['Effect'] == 'Allow' and
statement['Principal'] == '*' and
'Action' in statement and
's3:*' in statement['Action']):
full_access_buckets.append({'BucketName': bucket_name})
break
except s3.exceptions.ClientError as e:
if e.response['Error']['Code'] != 'NoSuchBucketPolicy':
print(f'Error checking bucket policy for {bucket_name}: {e}')
# Output CSV
csv_output = os.path.join('/tmp', 'full_access_buckets.csv')
with open(csv_output, 'w', newline='') as csvfile:
writer = csv.DictWriter(csvfile, fieldnames=['BucketName'])
writer.writeheader()
writer.writerows(full_access_buckets)
# Output JSON
json_output = os.path.join('/tmp', 'full_access_buckets.json')
with open(json_output, 'w') as jsonfile:
json.dump(full_access_buckets, jsonfile, indent=2)
# Upload to Amazon S3
output_bucket = '<OUTPUT_BUCKET_NAME>'
s3.upload_file(csv_output, output_bucket, 'full_access_buckets.csv')
s3.upload_file(json_output, output_bucket, 'full_access_buckets.json')
return {
'statusCode': 200,
'body': json.dumps(f'CSV and JSON files uploaded to {output_bucket}')
}
Importante: esses scripts são exemplos de referência e não estão prontos para produção. Revise o tratamento de erros, logging e permissões antes de qualquer implantação.
Extensão para múltiplas contas
Os scripts acima escaneiam apenas a conta atual. Para cobrir contas-membro em uma organização, é necessário adicionar a lógica de AssumeRole. A função abaixo assume o papel IAM de auditoria em cada conta-membro e retorna um cliente S3 com credenciais temporárias:
import boto3
import os
def get_member_s3_clients():
"""
Assumes the cross-account audit role in each member account and returns
a list of (account_id, s3_client) tuples.
"""
sts = boto3.client('sts')
member_accounts = os.environ.get('<MEMBER_ACCOUNTS>', '').split(',')
cross_account_role_name = os.environ.get('<CROSS_ACCOUNT_ROLE_NAME>')
external_id = os.environ.get('<EXTERNAL_ID>')
clients = []
for account_id in member_accounts:
account_id = account_id.strip()
if not account_id:
continue
try:
assumed_role = sts.assume_role(
RoleArn=f'arn:aws:iam::{account_id}:role/{cross_account_role_name}',
RoleSessionName='S3AuditSession',
ExternalId=external_id
)
# Create S3 client with assumed credentials
s3_client = boto3.client(
's3',
aws_access_key_id=assumed_role['Credentials']['AccessKeyId'],
aws_secret_access_key=assumed_role['Credentials']['SecretAccessKey'],
aws_session_token=assumed_role['Credentials']['SessionToken']
)
clients.append((account_id, s3_client))
except Exception as e:
print(f'Failed to assume role in account {account_id}: {e}')
return clients
Para iterar sobre as contas-membro no handler principal, substitua a chamada s3.list_buckets() por um loop sobre os clientes retornados por get_member_s3_clients(). O papel de execução da Lambda na conta central de segurança precisa ter permissão sts:AssumeRole para os ARNs dos papéis cross-account.
Remediação: corrigindo o problema
Bloqueio de acesso público no nível da conta
Antes de ajustar políticas individuais de bucket, a AWS recomenda habilitar o bloqueio de acesso público no nível da conta. Isso impede que qualquer bucket da conta se torne público, independentemente de políticas ou ACLs individuais. O comando AWS CLI abaixo aplica essa configuração — substitua <ACCOUNT_ID> pelo ID da sua conta:
Em ambientes multi-account, essa configuração pode ser distribuída via CloudFormation StackSets ou por meio de Políticas de Controle de Serviço (SCPs) do AWS Organizations. Antes de habilitar, verifique se alguma carga de trabalho depende de acesso público ao bucket — como hospedagem de sites estáticos ou compartilhamento de datasets públicos.
Políticas de bucket restritivas
Para negar acesso público de leitura e escrita em um bucket específico, a AWS apresenta o seguinte exemplo de política — ajuste o ARN do recurso, as ações e as condições conforme sua necessidade:
Para restringir o acesso apenas a usuários e papéis IAM específicos, o exemplo a seguir demonstra como estruturar a política — substitua <ACCOUNT_ID>, <USERNAME> e <ROLE_NAME>:
Após aplicar as correções, a AWS recomenda um processo de verificação antes de partir para o monitoramento contínuo:
Re-executar a função Lambda de auditoria para confirmar que os buckets sinalizados não aparecem mais na lista de risco.
Verificar no Security Hub se o status de conformidade mudou de FAILED para PASSED nos controles relacionados ao S3.
Validar com o IAM Access Analyzer se as descobertas de acesso externo foram resolvidas.
Testar as aplicações para garantir que cargas de trabalho legítimas continuam funcionando corretamente.
Para monitoramento contínuo, a função Lambda de auditoria pode ser agendada via Amazon EventBridge com regras de agendamento — por exemplo, diariamente às 6h UTC ou semanalmente às segundas-feiras. Além disso, o IAM Access Analyzer pode ser habilitado para monitorar continuamente políticas de bucket, ACLs e pontos de acesso, identificando buckets acessíveis de fora da sua conta ou organização.
Considerações de custo
Os principais geradores de custo nessa solução são o AWS Config e o Security Hub, que escalam com o número de contas e recursos monitorados. Lambda, EventBridge, SNS e S3 tendem a adicionar custos mínimos para a maioria dos ambientes. A AWS recomenda começar com um piloto em uma ou duas contas para validar os custos antes de escalar. Consulte as páginas de preços dos serviços e use a Calculadora de Preços da AWS para estimar os valores no seu ambiente específico. Para o IAM Access Analyzer, verifique a página de preços do IAM Access Analyzer para entender quais funcionalidades têm custo associado.
Boas práticas para manter a postura de segurança
Comece pelos controles no nível da conta: habilite o S3 Block Public Access na conta. Em ambientes multi-account, aplique via SCPs do AWS Organizations.
Automatize a detecção: use o IAM Access Analyzer para detectar acesso externo e agende a Lambda de auditoria com EventBridge para capturar novos problemas regularmente. Compare os resultados com a linha de base anterior para identificar desvios.
Padronize entre contas: use CloudFormation StackSets para distribuir a mesma configuração segura para todas as contas da organização — papéis IAM, regras do AWS Config e configurações de bloqueio de acesso público.
Medidas adicionais: revise e rotacione periodicamente as credenciais de papéis IAM cross-account e os External IDs; implemente criptografia server-side (SSE-S3 ou SSE-KMS) para dados em repouso; habilite logs de acesso ao S3 e eventos de dados do AWS CloudTrail para trilhas de auditoria.
Limpeza de recursos
Ao concluir a auditoria, revise e remova os recursos criados que não são mais necessários: funções Lambda e papéis IAM, regras do EventBridge, tópicos e assinaturas do SNS, buckets S3 com arquivos de saída da auditoria, regras e gravadores do AWS Config (se não forem mais necessários para conformidade) e o Security Hub (se habilitado exclusivamente para essa auditoria). Antes de deletar, verifique se os recursos não são utilizados por outras cargas de trabalho e retenha os resultados necessários.
Para saber mais
A AWS disponibiliza documentação complementar para aprofundamento:
A AWS anunciou uma melhoria importante no IAM Identity Center: agora é possível habilitar o suporte multi-Region com apenas um clique ao criar uma nova instância de organização. Antes dessa mudança, o processo exigia várias etapas manuais — como criar uma chave KMS (Key Management Service) gerenciada pelo cliente, configurar políticas de chave e adicionar as Regiões uma a uma. Com a atualização, esse fluxo foi significativamente simplificado.
As três opções de configuração de instância
Ao criar uma nova instância do IAM Identity Center em Regiões compatíveis, a AWS agora oferece três opções de configuração:
Instância single-Region: configuração padrão, limitada a uma única Região.
Instância multi-Region: a opção de um clique. Ela cria automaticamente uma chave KMS multi-Region gerenciada pelo cliente na conta do usuário e replica a instância para uma Região adicional.
Instância customizada: permite configurar as definições de Região individualmente, incluindo a possibilidade de usar uma chave KMS gerenciada pelo cliente já existente na conta.
Por que isso importa: resiliência no acesso
O principal benefício da configuração multi-Region é a resiliência. Com essa opção habilitada, os colaboradores de uma organização continuam conseguindo acessar suas contas AWS mesmo que o IAM Identity Center enfrente alguma interrupção na Região primária. Ou seja, a continuidade do acesso a contas e aplicações fica muito mais garantida em cenários de falha regional.
Disponibilidade e custos
As opções de configuração de instância estão disponíveis em 17 Regiões AWS comerciais habilitadas por padrão para instâncias de organização do IAM Identity Center. Vale destacar que o próprio IAM Identity Center não tem custo adicional, mas as cobranças padrão do AWS KMS se aplicam à chave gerenciada pelo cliente criada pela opção multi-Region.
Como começar
Para quem quer explorar essa novidade, a AWS disponibiliza recursos de documentação para apoiar a jornada:
