Blog

O Desafio de Segurança em Agentes de IA

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:

permit(
  principal == User::"alice",
  action == Action::"view",
  resource == Photo::"VacationPhoto94.jpg"
);

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.

Começando a Usar

Para experimentar esse exemplo, comece clonando o repositório de amostras do Amazon Bedrock AgentCore e navegando até a pasta do agente de consultas médicas:

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.

Fonte

Secure AI agents with Policy in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/secure-ai-agents-with-policy-in-amazon-bedrock-agentcore/)

O que é CDK Mixins

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.

Fonte

AWS CDK Mixins is now generally available (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-cdk-mixins/)

Novo recurso de acesso entre contas no OpenSearch

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.

Fonte

OpenSearch UI supports Cross Account Data Access to OpenSearch domains (https://aws.amazon.com/about-aws/whats-new/2026/03/opensearch-ui-cross-account-data-access-domains/)

Conectividade Privada para Certificados via SCEP

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.

Próximos Passos

Para começar a utilizar essa nova funcionalidade, os usuários podem acessar a documentação do AWS Private CA Connector para SCEP com instruções detalhadas de implementação. Informações adicionais sobre PrivateLink podem ser encontradas na documentação do AWS PrivateLink.

Fonte

AWS Private CA Connector for SCEP now supports AWS PrivateLink (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-private-ca-connector-scep-privatelink/)

O desafio do gerenciamento de AMIs em escala

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.

Arquitetura multi-conta e fluxo de trabalho

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.

Tecnicamente, é necessário ter Python 3.8 ou posterior instalado e a AWS Command Line Interface (AWS CLI) versão 2 configurada com credenciais de segurança apropriadas. Um bucket do Amazon Simple Storage Service (Amazon S3) é necessário para artefatos de implantação, criptografado usando SSE-KMS com uma chave gerenciada pelo cliente.

Fases de implementação

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.

Fonte

How to manage the lifecycle of Amazon Machine Images using AMI Lineage for AWS (https://aws.amazon.com/blogs/security/how-to-manage-the-lifecycle-of-amazon-machine-images-using-ami-lineage-for-aws/)

Renovação da Certificação DESC 2026

A Amazon Web Services (AWS) concluiu com sucesso sua auditoria anual de certificação junto ao Dubai Electronic Security Centre (DESC) para continuar operando como provedor de serviços em nuvem (Provedor de Serviços em Nuvem – CSP) Tier 1 na região do Oriente Médio (EAU). Esta certificação reafirma o compromisso contínuo da plataforma em atender aos rigorosos requisitos de segurança e conformidade esperados de provedores de nuvem de alto nível.

Para clientes governamentais que utilizam a AWS, esta certificação representa uma garantia importante: seus aplicativos podem ser executados com confiança em regiões de nuvem certificadas pelo DESC. A conformidade foi validada de forma independente pela BSI, uma auditoria terceirizada antes da emissão do certificado renovado pelo DESC. O certificado atualizado permanecerá válido por um ano, até 22 de janeiro de 2027.

Ampliação do Escopo de Serviços Certificados

Um destaque importante desta certificação é a expansão significativa de serviços incluídos no escopo de conformidade. A AWS adicionou dez novos serviços ao programa, aumentando de 98 para 108 o total de serviços certificados na região do Oriente Médio (EAU) — um crescimento de 10%.

Os serviços recém-adicionados ao escopo de certificação DESC incluem:

• AWS Elastic Beanstalk
• AWS Managed Services
• AWS Resource Explorer
• Amazon Application Recovery Controller
• Amazon Bedrock (excluindo Amazon Bedrock Marketplace)
• Amazon Inspector
• Amazon Managed Service for Prometheus
• Amazon Quick Suite (anteriormente Amazon QuickSight)
• Amazon Simple Email Service (Amazon SES)
• Amazon Verified Permissions

Acesso à Documentação de Conformidade

A certificação renovada está disponível através do AWS Artifact, um portal de autoatendimento que fornece acesso sob demanda a relatórios de conformidade da AWS. Usuários podem acessar o AWS Artifact no Console de Gerenciamento da AWS ou consultar a documentação sobre como começar com o AWS Artifact para obter mais detalhes sobre seu funcionamento.

Estratégia de Expansão Contínua

Esta expansão reflete a estratégia da AWS de incorporar continuamente novos serviços ao escopo de seus programas de conformidade. O objetivo é ajudar clientes a atender suas necessidades arquiteturais e regulatórias específicas, especialmente em regiões com requisitos rigorosos de segurança.

Organizações interessadas podem consultar a página de serviços no escopo de conformidade para visualizar a lista completa de serviços certificados. Clientes com dúvidas sobre conformidade DESC podem entrar em contato com sua equipe de conta AWS ou utilizar os canais de suporte disponibilizados.

Para aprofundar o entendimento sobre todos os programas de conformidade da AWS, consulte a página Programas de Conformidade da AWS. A plataforma permanece aberta a feedback e questões através da página de contato dedicada à conformidade.

Fonte

AWS completes the 2026 annual Dubai Electronic Security Centre (DESC) certification audit (https://aws.amazon.com/blogs/security/aws-completes-the-2026-annual-dubai-electronic-security-centre-desc-certification-audit/)