Auditoria comunitária reforça conformidade na nuvem
A Amazon Web Services (AWS) finalizou sua segunda auditoria comunitária junto à GDV (Associação Alemã de Seguros), contando com a participação de 36 membros do setor segurador alemão. Esses participantes representam cobertura superior a 63% do mercado segurador nacional em termos de prêmios de seguro. As auditorias comunitárias funcionam como um mecanismo eficiente para oferecer garantias adicionais a grupos de clientes quanto à segurança da computação em nuvem, complementando o Modelo de Responsabilidade Compartilhada da AWS, os Programas de Conformidade da AWS e recursos disponibilizados através do AWS Artifact.
Por que a segurança em nuvem importa para o setor financeiro
Para a AWS, a segurança representa a prioridade máxima. À medida que clientes adotam a escalabilidade e flexibilidade da plataforma, a empresa se dedica a transformar segurança e conformidade em facilitadores de negócios. O foco está em conquistar e manter a confiança de clientes do setor financeiro e suas autoridades regulatórias, garantindo que existem controles adequados para proteger materiais sensíveis e cargas de trabalho reguladas.
A transformação digital crescente no setor financeiro, com a computação em nuvem como tecnologia habilitadora chave, intensificou o escrutínio regulatório. O engajamento da AWS com membros da GDV exemplifica como a empresa apoia esforços de gestão de risco e conformidade regulatória de seus clientes.
Estrutura e escopo da auditoria
Sobre a GDV e seus participantes
A GDV é a associação das seguradoras privadas na Alemanha, representando aproximadamente 470 membros do setor e um ator relevante nas indústrias financeiras alemã e europeia. Os membros participantes desta auditoria comunitária acionaram seus direitos de auditoria conforme disposições da Lei de Resiliência Operacional Digital (DORA), requisitos da BaFin e diretrizes da EIOPA sobre terceirização para provedores de serviços em nuvem.
Preparação e definição de escopo
Neste segundo ciclo, uma única empresa de auditoria externa foi contratada em nome dos 36 membros participantes do setor segurador alemão. O escopo foi delimitado com referência ao framework C5 do BSI (Escritório Federal Alemão para Segurança da Informação), incluindo domínios-chave e áreas de controle. A avaliação enfatizou serviços AWS como Amazon Elastic Compute Cloud (Amazon EC2) e a região relevante para participantes — Europa (Frankfurt) — designada como eu-central-1.
Processo de auditoria
Fase de trabalho de campo
Após discussão inicial em Berlim, a auditoria adotou metodologia remota, utilizando videoconferência e portal seguro de auditoria para inspeção de evidências. Os auditores realizaram avaliação detalhada de políticas, procedimentos e controles da AWS através de análise de documentação, sessões profundas com especialistas em assuntos técnicos e perguntas de esclarecimento sobre as evidências apresentadas.
Resultados obtidos
A auditoria foi executada e concluída conforme modelo de engajamento mutuamente acordado entre AWS, membros participantes e auditores externos, durante o qual os participantes exerceram seus direitos de auditoria em conformidade com condições contratuais. Após revisão pela AWS para confirmação da precisão factual do conteúdo, os auditores finalizaram o relatório.
Os resultados da auditoria comunitária da GDV estão disponíveis exclusivamente aos membros participantes e suas autoridades regulatórias. A auditoria ofereceu aos membros da GDV garantias quanto ao ambiente de controles da AWS, possibilitando a remoção de obstáculos de conformidade, aceleração da adoção de serviços AWS e maior confiança nos controles de segurança da plataforma.
Perspectiva das seguradoras participantes
Do ponto de vista das companhias de seguros participantes, a segunda auditoria conjunta na AWS foi percebida como eficiente e benéfica ao reduzir encargos individuais de auditoria enquanto entregava resultados confiáveis de garantia. Simultaneamente, o planejamento abrangente e coordenação necessária demandou esforço substancial.
A coordenação com a GDV e o engajamento com a DCSO Deutsche Cybersicherheitsorganisation GmbH como fornecedor profissional externo de auditoria ajudou a simplificar a comunicação com a AWS e assegurou abordagem consistente entre todos os participantes. A cooperação entre seguradoras da GDV, auditores da DCSO e AWS manteve-se profissional e construtiva durante todo o processo.
Destacou-se a presença, pela primeira vez, de dois representantes de companhias de seguros nas entrevistas técnicas, proporcionando impressão ainda melhor sobre a qualidade do processo de auditoria.
Próximos passos e referências
Para aprofundamento em programas de conformidade e segurança, consulte os Programas de Conformidade da AWS. Clientes e organizações que desejam dialogar com a equipe de conformidade da AWS podem utilizar a página de contato disponibilizada.
A AWS anunciou, em março de 2026, o suporte a ingestão de logs através de protocolo HTTP no CloudWatch Logs. Essa funcionalidade oferece uma alternativa importante para cenários onde a integração nativa com o SDK da AWS não é possível — como acontece frequentemente com softwares de terceiros e aplicações empacotadas.
A novidade suporta múltiplos formatos e padrões de envio de logs, cada um adequado a diferentes casos de uso e padrões de integração:
Formatos e endpoints disponíveis
HTTP Log Collector (HLC)
O endpoint https://logs.<region>.amazonaws.com/services/collector/event foi desenvolvido para processar eventos JSON. Essa opção é ideal para organizações que já possuem pipelines de logs estabelecidos e desejam migrá-los para o CloudWatch sem redesenhar a infraestrutura.
ND-JSON (newline-delimited JSON)
Disponível em https://logs.<region>.amazonaws.com/ingest/bulk, esse formato é otimizado para cenários de alto volume. Cada linha representa um evento de log independente, tornando-o especialmente adequado para ingestão em lote (bulk) e streaming contínuo de dados.
Structured JSON
Por meio do endpoint https://logs.<region>.amazonaws.com/ingest/json, é possível enviar um único objeto JSON ou um array de objetos. Essa flexibilidade permite adaptar diferentes estruturas de dados de log.
OpenTelemetry (OTEL)
O endpoint https://logs.<region>.amazonaws.com/v1/logs aceita logs no formato OTLP, em codificação JSON ou Protobuf. Essa integração reforça o suporte da AWS ao padrão aberto de observabilidade.
Segurança e configuração
Para ativar o endpoint HTTP Log Collector, os usuários devem acessar as configurações do CloudWatch no console da AWS e gerar uma chave de API. O CloudWatch cria automaticamente um usuário IAM com credenciais específicas do serviço e permissões apropriadas.
As chaves de API podem ser configuradas com períodos de expiração de 1, 5, 30, 90 ou 365 dias, permitindo flexibilidade na estratégia de rotação de credenciais. Além disso, antes que um grupo de logs possa receber eventos via HTTP, é necessário habilitar explicitamente a autenticação por bearer token — uma medida de proteção que evita ingestão não intencional de dados.
Para maior controle, os administradores podem utilizar Service Control Policies para bloquear a criação de credenciais específicas do serviço, reforçando os controles de segurança em nível organizacional.
Disponibilidade regional
No lançamento inicial, esses endpoints estão disponíveis nas seguintes regiões da AWS: US East (N. Virginia), US West (N. California), US West (Oregon) e US East (Ohio).
Próximos passos
Para explorar detalhes técnicos sobre o endpoint HLC e as melhores práticas de segurança, consulte a documentação do CloudWatch Logs.
O Amazon Neptune anunciou uma novidade relevante para quem trabalha com análise de grafos em nuvem. A partir de agora, é possível ler dados armazenados no Amazon S3 diretamente através de consultas openCypher, sem necessidade de carregar os dados previamente na base do Neptune.
O recurso funciona através de um novo procedimento chamado neptune.read(), que oferece uma alternativa prática à abordagem tradicional de federação com dados externos. Para organizações que utilizam Neptune em análise de grafos, isso representa uma flexibilidade adicional: a possibilidade de incorporar dinamicamente dados armazenados em S3 sem seguir o fluxo de trabalho convencional em várias etapas.
Aplicações Práticas
Existem diferentes cenários em que essa nova funcionalidade se torna útil. A análise de grafos em tempo real que combine dados do S3 com estruturas gráficas já existentes é um deles. Também é possível criar dinamicamente nós e arestas a partir de conjuntos de dados externos, bem como executar consultas gráficas complexas que necessitam referenciar dados armazenados fora do Neptune.
Segurança e Compatibilidade de Dados
O procedimento suporta uma gama abrangente de tipos de dados, incluindo formatos padrão e específicos do Neptune, como geometria e datetime. A segurança é mantida através das credenciais de Identidade e Acesso da Conta (IAM) de quem está realizando a consulta, garantindo que apenas usuários autorizados possam acessar os dados.
A funcionalidade está disponível em todas as regiões onde o Amazon Neptune Database é atualmente oferecido.
Para Saber Mais
Quem deseja aprofundar-se nos detalhes técnicos e nas melhores práticas de implementação pode consultar a documentação do Neptune Database, onde encontrará guias completos e exemplos de uso.
Replicação de Identidades Corporativas em Múltiplas Regiões
O IAM Identity Center, serviço da AWS para gerenciamento de acesso corporativo, recebeu uma expansão significativa: agora suporta replicação em múltiplas regiões geográficas. Anteriormente, o portal de acesso da AWS estava disponível apenas em uma região. Com essa novidade, as organizações podem configurar regiões adicionais, garantindo que mesmo em caso de problemas na região primária, os usuários continuem tendo acesso através de um endpoint de portal alternativo.
Essa capacidade de replicação abre novas possibilidades para empresas que precisam atender usuários distribuídos globalmente ou que têm requisitos rigorosos de soberania de dados. Ao implantar o Identity Center em regiões mais próximas aos seus usuários, as organizações reduzem a latência nas operações de autenticação e autorização. Além disso, mantêm a administração centralizada: todas as configurações de nível de instância continuam sendo gerenciadas pela região primária.
Alinhamento com Aplicações Gerenciadas da AWS
A replicação multi-região também habilita a implantação de aplicações gerenciadas da AWS em regiões adicionais. Serviços como o AWS Deadline Cloud agora podem ser configurados em regiões secundárias com suporte completo ao Identity Center local. Essa aproximação reduz a latência nas operações e facilita o cumprimento de regulamentações regionais de conformidade.
Pré-Requisitos e Limitações Importantes
Antes de Começar
Antes de habilitar o suporte multi-região, algumas confirmações são necessárias. Primeiro, as aplicações gerenciadas já implantadas devem suportar o Identity Center configurado com chave KMS gerenciada pelo cliente. Além disso, todas as futuras aplicações que serão implantadas em regiões adicionais devem também oferecer esse suporte.
O portal de acesso em regiões adicionais não oferece suporte a alias customizado, ou seja, subdomínios escolhidos pela organização. O acesso a contas AWS através de regiões adicionais funciona apenas com permissões já provisionadas; novas atribuições de permission sets e filiações de grupos devem ser gerenciadas exclusivamente na região primária e são replicadas automaticamente.
Configuração Prática da Replicação Multi-Região
Criação de Chaves KMS Multi-Região
O processo começa com a configuração de chaves KMS gerenciadas pelo cliente que funcionem em múltiplas regiões. O Identity Center utiliza essas chaves para criptografar dados de identidade, como atributos de usuários. Como o mesmo material de chave precisa estar disponível em cada região, é necessário criar uma chave multi-região a partir da conta de gerenciamento da AWS Organizations.
Cada chave AWS KMS tem custo associado de uso e armazenamento. Consulte a página de preços do AWS KMS para detalhes sobre a estrutura de custos. Após criar a chave na região primária, replique-a para cada região adicional onde o Identity Center será replicado. As chaves de réplica herdam automaticamente a política de chave da chave primária, mas modificações futuras à política devem ser aplicadas manualmente a cada réplica.
Adição de Regiões Adicionais
Uma vez que a replicação de chaves esteja completa, o próximo passo é adicionar regiões adicionais através do console do Identity Center. Navegue até a seção de Configurações, escolha a opção de adicionar região e selecione a região desejada a partir da lista. O console exibe apenas regiões comerciais habilitadas por padrão onde a chave KMS foi previamente replicada.
Após adicionar uma região, o Identity Center exibe um status de “Replicando” enquanto sincroniza identidades de força de trabalho, configurações e metadados para o novo local. Esse processo inicial leva entre 15 e 30 minutos, dependendo do tamanho da instância. Mudanças subsequentes são replicadas em segundos.
Quando a replicação se completa, o status muda para “Replicado” e os endpoints do Identity Center na região adicional ficam ativos. Isso significa que os usuários podem acessar contas AWS através dos portais de acesso de ambas as regiões.
Atualização da Configuração do Provedor de Identidade
Sincronização de Endpoints SAML
Com o Identity Center replicado para regiões adicionais, é necessário atualizar a configuração do provedor de identidade externo. O Identity Center oferece suporte a dois fluxos de autenticação: aquele em que o usuário inicia a autenticação a partir do portal de acesso ou de uma aplicação gerenciada (inicializado pelo provedor de serviços), e aquele em que o usuário começa no portal do provedor de identidade (inicializado pelo IdP).
Na autenticação inicializada pelo provedor de serviços, quando um usuário tenta se autenticar, o Identity Center o redireciona para a página de autenticação do seu provedor de identidade. Após autenticação bem-sucedida, a resposta é enviada para o endpoint regional de serviço de consumidor de asserções SAML do Identity Center. O endpoint em cada região possui uma URL diferente.
Para que a autenticação seja bem-sucedida em regiões adicionais, é necessário adicionar o novo endpoint regional à configuração do provedor de identidade. Na aplicação Identity Center dentro do IdP externo, adicione a URL ACS da região adicional para que a aplicação contenha as URLs ACS de ambas as regiões. Mantenha a URL existente como a primeira da lista, pois o provedor de identidade a utiliza como destino de redirecionamento padrão para autenticações iniciadas pelo IdP.
Aplicações de Bookmark para Portais Regionais
Como usuários agora precisam acessar portais específicos de região, recomenda-se criar uma aplicação de bookmark no provedor de identidade. Embora os usuários possam fazer bookmark direto da URL no navegador, oferecer uma aplicação de bookmark torna a região adicional descoberta no portal do IdP sem exigir que cada usuário salve manualmente uma URL.
Essa aplicação de bookmark funciona como um atalho de navegador e contém apenas a URL do portal de acesso da região adicional. Os usuários podem acessar a aplicação pelo portal do IdP para alcançar o portal de acesso específico de sua região. Após criar a aplicação, conceda aos grupos e usuários permissão para acessá-la no IdP externo.
Testes da Configuração Multi-Região
Acesso a Contas AWS pela Região Adicional
As atribuições de permission sets que existem na região primária são replicadas automaticamente para regiões adicionais. Isso significa que, em caso de problemas com o Identity Center na região primária, a organização pode usar a região adicional para continuar acessando contas AWS através do portal de acesso.
Para validar o acesso, navegue até o console do Identity Center, vá para Configurações e escolha visualizar as URLs do portal de acesso. Selecione a URL da região adicional, que abrirá o portal em uma nova aba. Confirme que pode visualizar os permission sets atribuídos e acessar as contas AWS desejadas.
Acesso Pela Interface de Linha de Comando
A Interface de Linha de Comando da AWS se conecta a uma região específica do Identity Center para autenticar usuários e obter credenciais. Para clientes utilizando replicação multi-região, recomenda-se criar múltiplos perfis regionais de CLI—um para a região primária e outro para cada região adicional. Perfis separados permitem alternar rapidamente entre regiões durante uma interrupção sem reconfigurações.
Configure dois perfis de CLI adicionando as seguintes configurações ao arquivo ~/.aws/config:
Após configurar os perfis, autentique-se em cada endpoint regional do Identity Center independentemente utilizando os comandos aws sso login --profile ReadOnly para a região primária e aws sso login --profile ReadOnly-additional para a região adicional. Cada comando abre uma janela do navegador para o portal de acesso correspondente, onde você completa o fluxo de autenticação.
Implantação de Aplicações Gerenciadas
Para testar a implantação de aplicações em regiões adicionais, navegue até o console da aplicação gerenciada desejada—como AWS Deadline Cloud—e alterne para a região adicional. Siga o assistente de configuração. O Identity Center da região adicional é automaticamente selecionado pelo assistente de configuração da aplicação.
Durante a configuração, selecione os grupos que terão acesso à aplicação, verificando se você é membro de algum deles. Esses grupos foram sincronizados automaticamente a partir do seu provedor de identidade para o Identity Center. Após completar a implantação da aplicação, ela estará configurada para usar as APIs do Identity Center locais da região para autenticação de usuários e acesso a identidades corporativas.
Resiliência e Roteamento Automático
O Identity Center fornece endpoints regionais para o portal de acesso quando a replicação multi-região está habilitada. As organizações podem acessar essas instâncias regionais diretamente ou construir um sistema de redirecionamento que roteia inteligentemente usuários para o endpoint de portal mais próximo disponível, com capacidades de failover automático.
Para uma implementação serverless de failover automático, é possível combinar diversos serviços da AWS: Route 53 para gerenciar roteamento DNS com verificações de integridade, Application Recovery Controller para orquestrar lógica de failover, e Application Load Balancer para realizar redirecionamentos HTTP para os endpoints regionais apropriados do portal de acesso.
Controle de Administração por Região
A região primária funciona como centro de gerenciamento centralizado para configurações em nível de instância, enquanto regiões adicionais oferecem capacidades de gerenciamento de aplicações locais e acesso resiliente a contas AWS. O gerenciamento de aplicações ocorre sempre na região onde a aplicação foi configurada.
O gerenciamento de identidades de força de trabalho, revogação de sessões de usuário e configuração de nível de instância são realizados na região primária. As regiões adicionais oferecem acesso somente leitura para esses aspectos. Atribuições de usuários a aplicações específicas de região, implantação de aplicações SAML e OAuth2 customizadas, e acesso a contas AWS podem ser gerenciados em ambas as regiões, porém de forma independente.
Conclusão
A capacidade de replicar o IAM Identity Center através de múltiplas regiões representa uma evolução importante na estratégia de gerenciamento de identidades da AWS. Organizações que dependem do Identity Center para acesso corporativo agora podem estender essa proteção e funcionalidade a múltiplas regiões geográficas, garantindo resiliência, baixa latência e conformidade com requisitos regionais.
A implementação exige atenção a pré-requisitos técnicos, como a disponibilidade de chaves KMS multi-região e compatibilidade de aplicações. Com essas bases estabelecidas, as organizações ganham a flexibilidade de operações distribuídas mantendo controle centralizado sobre políticas de acesso e configurações de segurança. Para explorar a gama completa de capacidades do Identity Center multi-região, consulte a documentação sobre o uso do IAM Identity Center em múltiplas regiões AWS.
Implantar agentes de inteligência artificial com segurança em indústrias reguladas representa um dos maiores desafios da computação moderna. Sem limites bem definidos, um agente capaz de acessar dados sensíveis ou executar transações financeiras se torna um vetor de risco significativo.
O que torna os agentes de IA tão poderosos é justamente aquilo que os torna arriscados: sua autonomia. Diferentemente de software tradicional que segue um fluxo predeterminado, um agente de IA seleciona ações para atingir um objetivo, invocando ferramentas, acessando dados e adaptando seu raciocínio com base em informações do ambiente e do usuário. Essa flexibilidade é essencial para sua efetividade, mas exige controles de segurança rigorosos.
Um modelo mental útil para compreender a segurança de agentes é imaginar “muros” ao seu redor que definem exatamente o que o agente pode acessar, com o que pode interagir e que efeitos pode ter no mundo externo. Sem esses muros bem definidos, um agente autorizado a enviar emails, consultar bancos de dados, executar código ou disparar transações financeiras representa um risco real de exfiltração de dados, acesso não intencional a infraestrutura ou ataques de injeção de prompts.
Por Que Agentes Precisam de Enforcement Externo de Políticas
Proteger agentes de IA é mais complexo que proteger software tradicional. As características que os tornam poderosos — raciocínio aberto, uso flexível de ferramentas e adaptabilidade a novas situações — também criam comportamentos imprevisíveis e difíceis de controlar com segurança.
Agentes dependem de inferência com Grandes Modelos de Linguagem (LLM), que podem alucinar e carecem de separação clara entre instruções confiáveis e texto incidental. Isso os torna vulneráveis a ataques adversariais como injeção de prompts, que exploram essas fraquezas para contornar salvaguardas.
Historicamente, essas vulnerabilidades são gerenciadas através de restrições programadas no código da aplicação. Esse método funciona, mas com custos ocultos: o comportamento seguro depende da corretude do código wrapper, que se torna uma fronteira de segurança implícita. Auditar se as políticas corretas estão em lugar requer análise cuidadosa de potencialmente grande base de código. Equipes de segurança precisam revisar código de aplicação em vez de ter uma definição de política clara e auditável.
A AWS introduziu uma abordagem diferente: movendo a política completamente para fora do agente. Agora o enforcement ocorre antes da invocação da ferramenta, através do AgentCore Gateway. Isso significa que a política é enforçada independentemente do que o agente faz, como é manipulado ou que bugs possam existir no código do agente. Com essa separação, equipes podem focar em capacidade sem tratar cada linha de código como uma fronteira de segurança.
Cedar: Linguagem para Enforcement Determinístico de Políticas
Para tornar o enforcement externo de política prático, é necessária uma linguagem que seja simultaneamente eficiente para máquinas e auditável para humanos. Cedar é a linguagem de autorização utilizada no Policy do Amazon Bedrock AgentCore, projetada especificamente para ser tanto uma linguagem de autorização prática quanto um alvo para análise matemática automatizada.
Cada política Cedar especifica um principal (quem), uma ação (o que) e um recurso (onde), com condições opcionais na cláusula when. Um exemplo simples mostra como permitir que apenas Alice visualize uma foto:
Além de atributos em principals, recursos e ações, Cedar permite passar um objeto de contexto com atributos que podem ser referenciados em políticas para condicionar decisões a informações de tempo de execução. Isso permite criar políticas sofisticadas que combinam identidade, função, contexto e dados da requisição.
A semântica de Cedar — incluindo negação como padrão, “forbid vence permit” e avaliação independente de ordem — torna razoável raciocinar sobre políticas de forma composicional. A latência de avaliação é mínima graças à estrutura sem loops. Politicas Cedar não têm efeitos colaterais como acesso a sistema de arquivos ou chamadas de rede, permitindo avaliação segura sem sandboxing mesmo quando escritas por autores não confiáveis.
Policy no Amazon Bedrock AgentCore
O Policy no Amazon Bedrock AgentCore fornece o mecanismo concreto que avalia cada requisição agente-para-ferramenta contra políticas Cedar explicitamente definidas. Um motor de política é uma coleção de políticas expressas em Cedar.
Para tornar a autoria de políticas acessível, elas podem ser criadas de duas maneiras: authored diretamente como Cedar para controle programático fino-granular, ou geradas a partir de enunciados em linguagem natural que são automaticamente formalizados em Cedar. A partir de linguagem natural, o serviço gera código Cedar sintaticamente correto, valida contra o schema do gateway e analisa para identificar políticas excessivamente permissivas, restritivas ou problemáticas antes da aplicação.
Uma vez definidas, as políticas no Policy no AgentCore interceptam tráfego do agente através dos Gateways do Amazon Bedrock AgentCore, avaliando cada requisição agente-para-ferramenta contra as políticas do motor antes de conceder ou negar acesso à ferramenta.
Caso de Uso: Agente de Agendamento de Consultas em Saúde
Para concretizar esses conceitos, consideremos um agente de agendamento de consultas que funciona em um ambiente de saúde. Este sistema de IA ajuda a verificar status de imunização, consulta slots disponíveis e agenda consultas. O objetivo é proteger o sistema usando Policy para prevenir acesso não autorizado a registros de pacientes, exposição inadvertida de informações de saúde protegidas (PHI) ou cancelamento de consultas por pacientes não autorizados.
O Policy no Amazon Bedrock AgentCore adota postura de negação por padrão: se nenhuma política de permissão coincide com uma requisição, ela é bloqueada. Combinado com o princípio de que “forbid vence permit”, essas duas semânticas estabelecem uma base sólida para construir um conjunto coeso de regras Cedar legíveis e auditáveis que melhorem a segurança do agente em produção.
Ferramentas do Agente de Saúde
O agente de agendamento possui as seguintes ferramentas:
getPatient: GET /get_patient_emr — Obtém um registro de paciente pelo parâmetro de query obrigatório patient_id (string)
searchImmunization: POST /search_immunization_emr — Procura registros de imunização com parâmetro obrigatório search_value (string; ID do paciente)
bookAppointment: POST /book_appointment — Agenda uma consulta fornecendo date_string (string; formato “YYYY-MM-DD HH:MM”)
getSlots: GET /get_available_slots — Obtém slots disponíveis pelo parâmetro de query obrigatório date_string (string; “YYYY-MM-DD”)
Políticas Baseadas em Identidade
Uma regra fundamental em um agente de saúde é que pacientes devem conseguir agir apenas em seus próprios registros. Criar uma política que permita um paciente ler seus próprios registros de paciente e imunização requer que o parâmetro da ferramenta (patient_id para getPatient, search_value para searchImmunization) coincida com o ID autenticado do usuário.
Separação de Leitura e Escrita
Um padrão comum em sistemas de saúde é permitir acesso amplo de leitura enquanto restringe firmemente operações de escrita. Uma exemplo de política seria permitir leituras apenas para usuários autenticados com escopo apropriado (por exemplo, fhir:read) e manter escritas sob controle separado. Similar, um escopo appointment:write pode ser usado para controlar acesso a operações de escrita.
Controles de Risco em Agendamento
Além de controle de acesso, Policy pode enforçar regras de negócio ou padrões perigosos que ajudam a prevenir abuso. Ao usar “forbid” explícitos para barrar padrões de entrada perigosos nas ferramentas, é possível proteger a aplicação mesmo que o agente seja comprometido.
Por exemplo, criar uma política que bloqueie a exibição de slots de consulta fora de horários limitados. Uma declaração em linguagem natural como “Permitir que usuários vejam slots apenas entre 9h e 21h UTC” pode ser convertida em uma política Cedar que garante isso automaticamente.
git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/02-use-cases/healthcare-appointment-agent
A partir daí, siga as instruções de configuração e implantação no README para configurar seu ambiente AWS, implantar a stack de exemplo e invocar o agente end-to-end.
Pré-requisitos
Para usar Policy no Amazon Bedrock AgentCore com sua aplicação de agentes, verifique se atende aos seguintes pré-requisitos:
Uma conta AWS ativa
Confirmação das regiões AWS onde Policy no AgentCore está disponível
Permissões IAM apropriadas para criar, testar e anexar motor de política ao seu AgentCore Gateway
Para produção, limpe os ARNs de recurso para IDs específicos de motor de política e gateway em vez de usar wildcards. Para o conjunto completo de permissões incluindo configuração do execution role do Gateway, consulte as permissões IAM do AgentCore Gateway e Policy.
Testando Enforcement de Políticas
Dois casos de teste ilustram como políticas de acesso escopo-identidade funcionam quando o agente invoca a ferramenta getPatient em nome de um usuário. Em ambos os casos, o usuário autenticado é patient adult-patient-001.
Caso 1: PERMITIR — Paciente acessando seu próprio registro
O agente envia uma requisição tools/call ao gateway para invocar getPatient com o parâmetro patient_id definido como adult-patient-001. Como o patient_id na entrada da ferramenta coincide com o patient_id autenticado do usuário, a política Cedar permite a requisição:
Prompt: "Get my patient information for patient ID adult-patient-001"
Policy decision: ALLOW
Result: Patient record returned successfully
Caso 2: NEGAR — Paciente tentando acessar registro de outro paciente
Agora o agente envia a mesma requisição tools/call para getPatient, mas com patient_id definido como pediatric-patient-001. A política Cedar compara a entrada contra o patient_id autenticado do usuário, encontra uma desconexão e nega a requisição porque não há política de permissão coincidente:
Prompt: "Get patient information for patient ID pediatric-patient-001"
Policy decision: DENY
Result: Tool execution denied by policy enforcement
O mesmo código do agente, o mesmo modelo e a mesma ferramenta são usados em ambos os casos. A única diferença é a avaliação de política na fronteira do gateway. A ferramenta é protegida da requisição negada porque o gateway intercepta antes da execução.
Um segundo padrão de enforcement demonstra uma regra “forbid” que bloqueia operações de agendamento fora de horários permitidos. Se o agente fizer a mesma requisição mas às 3h UTC, a regra “forbid” coincide porque a hora está abaixo de nove, e como “forbid vence permit” em Cedar, a requisição é bloqueada independentemente de outras políticas de permissão:
Prompt: "Show me available appointment slots for 2025-08-15" (requested at 03:00 UTC)
Policy decision: DENY
Result: Tool execution denied by policy enforcement
Próximos Passos
Pronto para adicionar enforcement determinístico de política aos seus próprios agentes? Estes recursos ajudarão você a começar rapidamente:
O Policy Developer Guide cobre autoria de política Cedar, formalização de linguagem natural para Cedar, criptografia com AWS KMS e construtos CDK para implantações Infrastructure as Code (IaC)
O workshop Getting Started do AgentCore guia você através da construção e proteção de um agente end-to-end, incluindo integração de Policy com AgentCore Gateway
Dúvidas sobre implementar essas políticas em seu caso de uso específico? Compartilhe seus pensamentos na comunidade de fóruns AWS
Conclusão
Agentes de IA são tão confiáveis quanto os limites que os contêm. Esses limites devem ser enforçados de forma determinística, não deixados à mercê do raciocínio interno do modelo. O Policy no Amazon Bedrock AgentCore oferece um caminho principiado para definir esses limites e enforçá-los na camada de gateway em cada requisição agente-para-ferramenta. Essas políticas são enforçadas independentemente do raciocínio do agente e são auditáveis por qualquer membro da equipe de segurança.
Para empresas implantando agentes em indústrias reguladas, essa separação entre capacidade e enforcement é o fundamento que torna possível sistemas agentic de nível produção. Ao combinar flexibilidade de IA com controles determinísticos, organizações podem inovar com confiança.
A AWS anunciou a disponibilidade geral do CDK Mixins, um novo recurso do Kit de Desenvolvimento em Nuvem (AWS CDK – Cloud Development Kit) que oferece uma forma inovadora de trabalhar com construtos de infraestrutura. Esse recurso permite que você adicione abstrações compostas e reutilizáveis a qualquer construto AWS—sejam construtos de nível 1 (L1), nível 2 (L2) ou construtos personalizados—sem necessidade de reconstruir seu código de infraestrutura existente.
O CDK Mixins fica disponível através do pacote aws-cdk-lib e funciona de forma compatível com todos os tipos de construtos, oferecendo a flexibilidade de aplicar as abstrações corretas exatamente onde e quando você precisa delas.
Por que CDK Mixins resolve um problema real
Historicamente, as equipes de infraestrutura enfrentavam uma escolha difícil: utilizar construtos L1 para ter acesso imediato aos novos recursos da AWS, ou optar pela conveniência das abstrações de nível mais alto oferecidas pelos construtos L2. Essa decisão frequentemente resultava em trabalho significativo para atender a requisitos de segurança, conformidade ou operacionais.
O CDK Mixins simplifica a manutenção de bibliotecas de construtos personalizadas, eliminando essa falsa dicotomia.
Capacidades práticas do CDK Mixins
O novo recurso permite aplicar funcionalidades como exclusão automática, criptografia de buckets, versionamento e bloqueio de acesso público diretamente aos construtos usando uma sintaxe simples de .with(). Você também pode combinar múltiplos Mixins em construtos L2 customizados e aplicar políticas de conformidade em um escopo inteiro de infraestrutura.
Para casos mais avançados, desenvolvedores podem usar Mixins.of() para realizar filtragem sofisticada por tipo de recurso ou padrão de caminho.
Benefícios para equipes corporativas
Equipes empresariais agora conseguem implementar e aplicar políticas de segurança e conformidade reutilizáveis em toda a sua infraestrutura, mantendo simultaneamente acesso ao dia um com novos recursos da AWS. Essa combinação oferece maior flexibilidade operacional sem comprometer a segurança ou os padrões regulatórios exigidos pelas organizações.
Disponibilidade e próximos passos
O CDK Mixins está disponível em todas as regiões da AWS onde o AWS CloudFormation é suportado. Para começar a usar o CDK Mixins, você pode consultar a documentação da AWS completa com exemplos e guias de implementação.
A AWS anunciou um novo recurso no Amazon OpenSearch Service que facilita significativamente o trabalho com dados distribuídos em múltiplas contas: o suporte nativo para acesso entre contas. Esse recurso permite que os usuários acessem domínios OpenSearch hospedados em diferentes contas AWS diretamente de uma única interface de aplicação, sem necessidade de trocar de endpoint ou replicar dados.
Como funciona o acesso entre contas
Com essa funcionalidade, é possível executar consultas e construir dashboards utilizando dados provenientes de domínios OpenSearch espalhados por diferentes contas na mesma região geográfica. Tudo isso permanecendo dentro do mesmo aplicativo OpenSearch UI, o que simplifica bastante o fluxo de trabalho.
Configurações suportadas
O recurso de acesso entre contas funciona tanto em domínios OpenSearch hospedados em configurações públicas quanto em Virtual Private Cloud (VPC), oferecendo flexibilidade para diferentes arquiteturas de segurança.
Benefícios para equipes e organizações
Antes desse recurso, equipes precisavam consolidar todos os dados em uma única conta ou manter pipelines de dados custosos e complexos para viabilizar análises unificadas que cruzassem fronteiras organizacionais. Agora, com o acesso entre contas, os dados permanecem exatamente onde estão, cada conta mantendo seu próprio controle de acesso, enquanto análises centralizadas tornam-se possíveis.
Casos de uso principais
Esse recurso é especialmente valioso para implementar fluxos de trabalho centralizados de observabilidade, busca e análise de segurança que abrangem múltiplas contas AWS, mantendo a segurança e a governança de dados intactas em cada uma delas.
Autenticação e acesso
O acesso entre contas no OpenSearch suporta dois mecanismos de autenticação para usuários finais: IAM (incluindo SAML via federação IAM) e IAM Identity Center (IdC). Isso garante que as organizações possam manter seus modelos de autenticação e governança existentes.
Disponibilidade
O recurso de acesso entre contas para domínios OpenSearch está disponível em todas as regiões AWS onde o OpenSearch UI é oferecido. Para informações técnicas detalhadas e instruções de configuração, consulte a documentação disponível em acesso entre contas para domínios OpenSearch no guia de desenvolvimento do Amazon OpenSearch Service.
A AWS anunciou em março de 2026 uma atualização significativa no seu AWS Private CA Connector para SCEP: suporte a AWS PrivateLink. Essa expansão permite que os clientes solicitem certificados a partir de dentro de sua Amazon Virtual Private Cloud (VPC) sem precisar atravessar a internet pública.
Com esse novo recurso, é possível criar endpoints de VPC para conectar-se ao conector SCEP de forma privada, mantendo todo o tráfego dentro da rede AWS. Essa abordagem elimina a necessidade de internet gateways, dispositivos NAT ou conexões VPN para acessar os endpoints do conector SCEP.
O que é o AWS Private CA Connector para SCEP?
O AWS Private CA Connector para SCEP é um conector gerenciado que permite usar o Simple Certificate Enrollment Protocol (SCEP) para emitir certificados a partir da AWS Private Certificate Authority (CA).
O SCEP é amplamente adotado para automação de inscrição e renovação de certificados em diversos tipos de dispositivos, incluindo:
Dispositivos móveis
Equipamentos de rede
Dispositivos IoT (Internet das Coisas)
Benefícios da Integração com PrivateLink
O suporte a AWS PrivateLink traz vantagens significativas para organizações que precisam gerenciar certificados em ambientes altamente seguros:
Simplificação da conectividade de rede: elimina a necessidade de configurações complexas com internet gateways, NAT ou VPN
Conformidade regulatória: atende requisitos que mandatam conectividade privada para gerenciamento de certificados
Redução de superfície de ataque: mantém todo o tráfego dentro da rede AWS, sem exposição à internet pública
Facilidade operacional: simplifica a arquitetura de rede para ambientes complexos
Disponibilidade Geográfica
O suporte a AWS PrivateLink para AWS Private CA Connector para SCEP está disponível em todas as regiões AWS onde o conector está presente. Para verificar a disponibilidade regional específica, consulte a AWS Region Table.
Conforme as organizações expandem suas infraestruturas na nuvem, o gerenciamento adequado do ciclo de vida das Amazon Machine Images (AMIs) torna-se um componente crítico para segurança e gestão de riscos. As AMIs fornecem informações essenciais para lançar instâncias do Amazon Elastic Compute Cloud (Amazon EC2), mas apresentam desafios significativos de segurança e conformidade quando não são rastreadas e gerenciadas adequadamente ao longo de seu ciclo de vida.
O principal desafio reside em manter visibilidade sobre as vulnerabilidades potenciais distribuídas pelas AMIs em todo o ambiente AWS. Sem uma forma clara de rastrear a origem e as derivações das imagens, as equipes de segurança enfrentam dificuldades para responder perguntas críticas: qual é o impacto de uma vulnerabilidade específica? Quais instâncias precisam de atualização urgente? As AMIs em uso são provenientes de fontes aprovadas?
O anúncio do suporte a linhagem de AMIs
No final de 2024, a AWS anunciou suporte a rastreamento de linhagem para Amazon EC2, disponibilizando detalhes sobre a origem das AMIs. Com essa informação de linhagem, é possível rastrear AMIs copiadas ou derivadas até sua fonte original.
Os dados de origem estão disponíveis para AMIs criadas usando comandos API específicos como CreateImage, CopyImage e CreateRestoreImageTask. Porém, quando uma AMI é criada através de um comando API diferente, o ID e a região AWS da AMI de origem não aparecem, criando lacunas de visibilidade que podem impactar os esforços de segurança e conformidade.
Uma solução integrada de governança
Para preencher essas lacunas e oferecer governança abrangente de AMIs, as organizações precisam construir capacidades adicionais. Uma solução bem projetada deve rastrear a origem das AMIs, validar que recursos implantados provêm de imagens douradas aprovadas, responder a investigações de auditoria com uma cadeia de custódia clara, e fazer cumprir padrões aprovados de criação de AMIs em todas as contas e regiões da AWS.
A solução apresentada utiliza Amazon Neptune, um banco de dados em grafo de alta performance, juntamente com serviços de segurança nativos da AWS para manter uma visão abrangente das relações entre AMIs e permitir monitoramento proativo de segurança. Com essa solução, é possível implementar controles sobre a origem de AMIs, validar imagens do marketplace por meio de políticas de controle de serviço, e manter conformidade com requisitos organizacionais e regulatórios.
Componentes principais da arquitetura
A solução de governança de AMI Lineage integra serviços essenciais da AWS em uma arquitetura de múltiplas contas. O Neptune funciona como banco de dados em grafo especializado, armazenando e gerenciando os dados de relacionamentos entre AMIs de forma segura.
Funções do AWS Lambda atuam como motor de processamento, captando eventos do ciclo de vida das AMIs (como CreateImage, CopyImage e DeregisterImage), avaliando-os contra regras de conformidade e atualizando o banco de dados em grafo. Essas funções são configuradas com permissões de AWS Identity and Access Management (IAM) com privilégios mínimos para aumentar a segurança.
O Amazon API Gateway oferece endpoints REST seguros para consultas de linhagem e avaliações de segurança. A autenticação combina chaves de API e papéis de IAM para garantir que apenas usuários e sistemas autorizados possam acessar os dados.
A solução segue as melhores práticas de segurança da AWS com uma arquitetura de múltiplas contas dividida em três tipos principais: conta de gerenciamento da organização, conta centralizada de ferramentas de segurança e múltiplas contas membros.
A abordagem trabalha da seguinte forma: a AWS Organizations é usada para fazer cumprir políticas de controle de serviço que previnem ações não conformes em AMIs. Quando um evento de ciclo de vida de AMI ocorre em uma conta membro, uma regra local do Amazon EventBridge o captura e encaminha com segurança para o EventBridge central na conta de ferramentas de segurança.
Uma função Lambda na conta de ferramentas de segurança processa o evento, analisa conformidade e atualiza o banco de dados em grafo do Neptune. O AWS Security Hub e o Amazon GuardDuty recebem e analisam descobertas de todas as contas. As equipes de segurança consultam os dados através de um endpoint seguro do API Gateway para visualizar hierarquias de AMI, investigar descobertas de segurança e avaliar o impacto de uma AMI específica.
Capacidades de monitoramento e conformidade
A solução oferece validação abrangente de origem de AMI, garantindo que as imagens provenham de fontes aprovadas, incluindo validação de AMIs do AWS Marketplace em relação a uma lista de fornecedores confiáveis. Capacidades de gerenciamento de ciclo de vida fazem cumprir políticas de retenção de AMIs e processos de descontinuação.
O monitoramento contínuo rastreia conformidade com requisitos organizacionais e regulatórios. Uma trilha de auditoria detalhada mantém um histórico completo de criação, modificação e padrões de uso de AMIs. Quando vulnerabilidades são descobertas, a solução permite avaliação rápida do escopo de impacto, identificando quais recursos foram afetados.
Integrando segurança em toda a solução
O IAM gerencia controle de acesso com privilégios mínimos em todos os componentes. O AWS CloudTrail registra atividades de API para trilhas de auditoria e relatórios de conformidade. O Security Hub centraliza descobertas de segurança e status de conformidade em todo o patrimônio de AMIs. O GuardDuty oferece detecção de ameaças para atividades relacionadas a AMIs.
Políticas de controle de serviço fazem cumprir controles em nível organizacional sobre criação e uso de AMIs. O AWS Config rastreia mudanças de configuração de AMIs e avalia regras de conformidade contínuas.
Preparação para implementação
Antes de implementar a solução, é necessário estabelecer a base apropriada de segurança e governança. A conta de gerenciamento das AWS Organizations requer permissões administrativas e deve estar habilitada com todos os recursos para suportar as políticas utilizadas.
Uma conta dedicada de ferramentas de segurança é necessária para hospedar os componentes principais da solução, com papéis de IAM de múltiplas contas configurados para permitir acesso seguro. Serviços essenciais de segurança devem ser configurados no nível organizacional, incluindo Security Hub, trilhas CloudTrail organizacionais para registros de auditoria, e chaves de criptografia usando o AWS Key Management Service (AWS KMS) para proteção de dados.
O processo de implantação segue uma abordagem de cinco fases que constrói capacidades de segurança e conformidade progressivamente.
Fase 1 – Estabelecimento de fundações de segurança: Configurar os serviços de segurança do AWS Organizations, habilitando Security Hub com a conta de ferramentas de segurança como administrador delegado, habilitando GuardDuty com a conta de ferramentas de segurança como administrador delegado, e habilitando uma trilha CloudTrail em nível organizacional.
Fase 2 – Controles de segurança: Implantar controles de segurança base através de políticas de controle de serviço em nível organizacional que fazem cumprir controles de governança de AMI.
Fase 3 – Regras de EventBridge: Implantar regras de EventBridge em nível organizacional da conta de gerenciamento para capturar eventos de AMI em contas membros e encaminhá-los à conta de ferramentas de segurança.
Fase 4 – Infraestrutura central: Implantar componentes de processamento e armazenamento na conta de ferramentas de segurança, seguindo as melhores práticas de segurança centralizando operações sensíveis em uma conta dedicada.
Fase 5 – Conformidade e monitoramento: Estabelecer capacidades abrangentes de conformidade e monitoramento em contas membros, com regras do AWS Config para monitoramento contínuo de conformidade de AMIs.
A solução completa está disponível como código aberto no repositório de exemplos da AWS. É possível clonar o repositório e seguir as instruções de implantação, que incluem templates do AWS CloudFormation, funções Lambda e scripts de implantação.
Operando a solução de AMI Lineage
Quando implantada, a solução oferece capacidades de operações de segurança e monitoramento de conformidade através de sua API hospedada na conta de ferramentas de segurança. As equipes de segurança podem consultar e receber relacionamentos completos de segurança de AMIs para entender o contexto total das imagens no ambiente.
Durante investigações, a solução fornece contexto de segurança detalhado incluindo informações de validação de origem confirmando se as AMIs provêm de fontes do marketplace ou contas confiáveis, status de conformidade mostrando níveis de patch e conformidade com políticas, status de vulnerabilidade com descobertas de CVE (Vulnerabilidades e Exposições Comuns) e resultados de verificação, e dados completos de linhagem mostrando a cadeia completa de relacionamentos e histórico de aprovação.
Para avaliações de impacto de segurança, quando novas CVEs são descobertas, a solução permite que equipes de segurança determinem rapidamente cada recurso afetado em toda a organização que se originou de uma AMI comprometida ou vulnerável. Com essa informação, é possível compreender o escopo total da exposição e iniciar a remediação.
Monitoramento contínuo e automação
O monitoramento de conformidade opera continuamente através de capacidades automatizadas de avaliação que avaliam o patrimônio de AMIs em relação às políticas organizacionais e requisitos regulatórios. As equipes podem gerar relatórios completos de conformidade mostrando aderência aos padrões de segurança em toda a infraestrutura.
A solução oferece capacidades robustas de automação de políticas que operam continuamente para manter segurança e conformidade. O sistema garante que apenas AMIs aprovadas com histórico de linhagem verificado possam ser usadas para lançar novas instâncias, bloqueando automaticamente tentativas de usar imagens não conformes. Quando violações de políticas são detectadas, o sistema pode disparar respostas automatizadas a eventos de segurança.
O Security Hub, operando em modo de administrador delegado, pode ser configurado para responder automaticamente a descobertas parando instâncias usando AMIs com vulnerabilidades críticas, colocando em quarentena instâncias lançadas de fontes não aprovadas, e enviando notificações imediatas para descobertas de alta severidade.
Visualização, relatórios e auditoria
As capacidades de visualização e relatórios de segurança, centralizadas na conta de ferramentas de segurança, oferecem dashboards em tempo real mostrando status de conformidade em toda a organização, visualização de escopo para tomada rápida de decisões, status do fluxo de trabalho de aprovação de AMI para monitoramento de processo, métricas de conformidade de patch para manutenção de postura de segurança, e logs de atividades de remediação automatizadas para fins de auditoria.
Para investigações de segurança e fins de auditoria, a solução mantém uma trilha de auditoria consultável oferecendo histórico completo de AMIs incluindo eventos de criação e modificação, resultados de verificação de segurança e descobertas, histórico de fluxo de trabalho de aprovação, e mudanças de status de conformidade ao longo do tempo.
Considerações finais
A solução de AMI Lineage transforma a governança de AMI de um processo manual e propenso a erros em uma capacidade de segurança automatizada e abrangente que escala com o crescimento organizacional. Implementando essa solução, as organizações ganham visibilidade, controle e capacidades de resposta automatizadas necessários para manter uma postura de segurança forte, enquanto permitem implantação rápida e segura de infraestrutura em todo o ambiente AWS.
É importante considerar os aspectos operacionais e de custo da solução. Os componentes principais, particularmente o Neptune, têm custos associados que escalarão com o tamanho do patrimônio de AMIs da organização. Recomenda-se implementar monitoramento e alertas de custo como parte da implantação. Além disso, como a solução é orientada por eventos, deve-se planejar um processo único de preenchimento retrospectivo para ingerir o histórico de AMIs existente da organização no banco de dados em grafo. Para organizações que exigem esse nível de controle granular e visibilidade, essas considerações operacionais são compensadas pelos ganhos significativos na postura de segurança e automação de conformidade.
A AWS anunciou uma importante adição ao recurso de Aprovação Multiparte (MPA — Multi-Party Approval): agora os administradores podem executar testes de aprovação para verificar se sua equipe está configurada corretamente. Essa funcionalidade permite que os responsáveis pela administração da MPA confirmem que os aprovadores estão ativos e acessíveis antes de depender desse fluxo para operações sensíveis.
Por Que Isso Importa para Sua Organização
Equipes de aprovação podem se tornar inativas por diversos motivos: rotatividade de pessoal, configurações incorretas de aprovadores ou simplesmente falta de engajamento. Sem uma forma de validar regularmente a saúde da equipe, sua organização corre o risco de descobrir problemas críticos apenas quando uma aprovação urgente é necessária — e aí é tarde demais.
Com esse novo recurso, os administradores e equipes de segurança podem avaliar proativamente suas configurações de aprovação. Isso significa identificar problemas antes que eles impactem operações críticas.
Recursos Principais da Validação
A funcionalidade de validação base (baselining) oferece várias capacidades importantes:
Verificação manual de testes: Permite iniciar sessões de teste de aprovação diretamente pelo console do AWS Organizations
Validação de disponibilidade: Confirma que os aprovadores conseguem realmente responder quando necessário
Identificação de membros inativos: Detecta membros da equipe que não estão mais participando do fluxo
Conformidade interna: Ajuda a manter a equipe alinhada com os requisitos de governança interna
Casos de Uso Recomendados
A AWS recomenda usar a validação de equipes em três cenários principais:
Verificação Regular de Responsividade
A validação deve ser executada regularmente — a AWS recomenda a cada 90 dias — utilizando o Console de MPA. Esse ciclo garante que sua equipe de aprovação continue funcional e responsiva ao longo do tempo.
Validação de Novas Configurações
Quando você implementa uma nova configuração de aprovação, execute testes antes de colocá-la em produção. Isso reduz significativamente o risco de falhas quando aprovações reais forem necessárias.
Verificações de Saúde Operacional
Utilize a validação para garantir que os fluxos de aprovação funcionem conforme esperado em momentos críticos. Identificar problemas durante testes é muito mais seguro do que descobri-los durante uma operação sensível real.
Disponibilidade
Esse recurso está disponível em todas as regiões comerciais da AWS. Para aprender como implementar testes de validação em seus fluxos de aprovação multiparte, consulte a documentação de aprovação multiparte.
