Investigação de Incidentes de Segurança Mais Eficiente com Inteligência Artificial
Quem já passou horas vasculhando manualmente os registros do AWS CloudTrail, verificando permissões do AWS Identity and Access Management (IAM) e reconstruindo a cronologia de um evento de segurança, compreende bem o investimento de tempo que uma investigação de incidente exige. A AWS anunciou a adição de capacidades de investigação impulsionadas por inteligência artificial ao AWS Security Incident Response, automatizando o trabalho de coleta e análise de evidências que costumava ser realizado manualmente.
O serviço Security Incident Response da AWS foi projetado para ajudar organizações a se prepararem, responderem e recuperarem-se de eventos de segurança de forma mais rápida e eficaz. Ele combina monitoramento e triagem automatizados de descobertas de segurança, contenção e agora novas capacidades de investigação baseadas em IA, tudo integrado com acesso 24/7 à equipe especializada de resposta a incidentes da AWS.
O Desafio da Investigação Manual de Incidentes
Durante a investigação de uma chamada de API suspeita ou atividade de rede incomum, os analistas precisam consultar múltiplas fontes de dados, correlacionar timestamps, identificar eventos relacionados e construir uma visão completa do que ocorreu. Profissionais de centros de operações de segurança (SOC) dedicam uma quantidade significativa de tempo a cada investigação, com aproximadamente metade desse esforço consumido pela coleta manual e correlação de evidências de diversas ferramentas e logs complexos.
Esse trabalho manual frequentemente atrasa a análise e a resposta aos incidentes. Para resolver esse gargalo, a AWS introduz um agente investigador ao Security Incident Response, transformando esse paradigma e adicionando camadas de eficiência que reduzem drasticamente o tempo necessário para validar e responder a possíveis eventos de segurança.
O Agente Investigador: Como Funciona
Quando um caso de preocupação de segurança é criado — seja manualmente ou de forma proativa pelo Security Incident Response — o agente investigador faz perguntas de esclarecimento para garantir que compreende totalmente o contexto do possível evento de segurança. Em seguida, ele reúne automaticamente evidências de eventos do CloudTrail, configurações do IAM, detalhes de instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e até analisa padrões de uso de custos.
Em poucos minutos, o agente correlaciona as evidências, identifica padrões e apresenta um resumo claro e compreensível. Diferentemente da automação tradicional, o agente não oferece resultados genéricos — a investigação é adaptada especificamente à sua preocupação.
Fluxo de Operação na Prática
Imagine o seguinte cenário: você descobre que as credenciais de um usuário IAM em sua conta foram expostas em um repositório público do GitHub. Você precisa entender quais ações foram realizadas com essas credenciais e escopar adequadamente o possível evento de segurança, incluindo movimentos laterais e operações de reconhecimento. Você também precisa identificar mecanismos de persistência que possam ter sido criados e determinar as etapas de contenção apropriadas.
Para começar, você cria um caso no console do Security Incident Response e descreve a situação. É aqui que a abordagem do agente se diferencia: ele faz perguntas esclarecedoras primeiro. Quando as credenciais foram expostas pela primeira vez? Qual é o nome do usuário IAM? Você já rotacionou as credenciais? Qual conta da AWS foi afetada? Essa etapa interativa coleta os detalhes e metadados apropriados antes de iniciar a coleta de evidências.
Depois que o agente tem as informações necessárias, ele investiga. Busca eventos do CloudTrail para ver quais chamadas de API foram feitas usando as credenciais comprometidas, obtém detalhes do usuário e das funções do IAM para verificar quais permissões foram concedidas, identifica novos usuários ou funções do IAM que foram criados, verifica informações de instâncias do EC2 se recursos de computação foram iniciados e analisa padrões de custos e uso para consumo anômalo de recursos.
Em vez de você consultar cada serviço da AWS individualmente, o agente orquestra isso automaticamente. Em poucos minutos, você recebe um resumo contendo uma visão de alto nível, descobertas críticas, padrões de exposição de credenciais, atividades observadas e cronogramas, recursos afetados e fatores limitantes.
O resumo da investigação inclui várias abas com informações detalhadas, como descobertas técnicas com uma cronologia de eventos, fornecendo a você uma imagem de alta resolução do que aconteceu. Com essa transparência, você pode tomar decisões informadas sobre contenção, erradicação e recuperação.
Impacto Operacional para as Equipes de Segurança
O cenário de credenciais expostas demonstra o que o agente pode fazer para um incidente individual, mas o impacto maior está na transformação das operações diárias:
Menos tempo em coleta de evidências: O agente investigador automatiza a parte mais demorada das investigações — reunir e correlacionar evidências de múltiplas fontes. Em vez de gastar uma hora em análise manual de logs, você pode dedicar a maior parte desse tempo a decisões de contenção e prevenção de recorrências.
Investigação em linguagem natural: O agente investigador utiliza processamento de linguagem natural (NLP), permitindo descrever o que você está investigando em linguagem natural, como “chamadas de API incomuns do endereço IP X” ou “acesso a dados com credenciais de funcionário desligado”. O agente traduz essas descrições em consultas técnicas necessárias, eliminando a necessidade de ser um especialista em formatos de logs da AWS ou conhecer a sintaxe exata para consultar o CloudTrail.
Base sólida para investigações precisas: O agente investigador realiza a investigação inicial — reunindo evidências, identificando padrões e fornecendo um resumo abrangente. Se seu caso exigir análise mais profunda ou orientação em cenários complexos, você pode envolver a equipe especializada da AWS, que pode construir imediatamente sobre o trabalho que o agente já realizou, acelerando seu tempo de resposta. Eles veem as mesmas evidências e cronologia, podendo focar em análise avançada de ameaças e estratégias de contenção em vez de começar do zero.
Configuração e Primeiros Passos
Se você já tem o Security Incident Response habilitado, as capacidades de investigação com inteligência artificial estão disponíveis agora — nenhuma configuração adicional é necessária. Crie seu próximo caso de segurança e o agente começará a trabalhar automaticamente.
Se você é novo no Security Incident Response, aqui está como configurar:
Habilite o Security Incident Response através da sua conta de gerenciamento do AWS Organizations. Isso leva alguns minutos através do Console de Gerenciamento da AWS e fornece cobertura em todas as suas contas.
Crie um caso. Descreva o que você está investigando; você pode fazer isso através do console do Security Incident Response, uma API, ou configurar criação automática de casos a partir de alertas do Amazon GuardDuty ou AWS Security Hub.
Analise os resultados. O agente apresenta suas descobertas através do console do Security Incident Response, ou você pode acessá-las através de seus sistemas de tickets existentes, como Jira ou ServiceNow.
Considerações Técnicas e Segurança
O agente investigador utiliza a função ligada ao serviço de suporte da AWS para reunir informações de seus recursos. Essa função é criada automaticamente quando você configura sua conta da AWS e fornece o acesso necessário para ferramentas de suporte consultarem eventos do CloudTrail, configurações do IAM, detalhes do EC2 e dados de custos. Todas as ações realizadas pelo agente são registradas no CloudTrail para auditoria completa.
O agente investigador está incluído sem custo adicional com o Security Incident Response, que agora oferece preços medidos com um nível gratuito cobrindo seus primeiros 10 mil achados ingeridos por mês. Após esse limite, os achados são faturados em taxas que diminuem com volume. Com essa abordagem baseada em consumo, você pode escalar suas capacidades de resposta a incidentes de segurança conforme suas necessidades crescem.
Integração com Ferramentas Existentes
Casos do Security Incident Response podem ser criados por clientes ou proativamente pelo serviço. O agente investigador é acionado automaticamente quando um novo caso é criado, e os casos podem ser gerenciados através do console, API ou integrações do Amazon EventBridge. Você pode usar o EventBridge para construir fluxos de trabalho automatizados que roteiem eventos de segurança do GuardDuty, Security Hub e do próprio Security Incident Response para criar casos e iniciar planos de resposta, possibilitando pipelines completos de detecção para investigação.
Antes do agente investigador iniciar seu trabalho, o sistema de auto-triagem do serviço monitora e filtra achados de segurança do GuardDuty e ferramentas de segurança de terceiros através do Security Hub. Ele utiliza informações específicas do cliente, como endereços IP conhecidos e entidades do IAM, para filtrar achados com base no comportamento esperado, reduzindo o volume de alertas enquanto escalona alertas que exigem atenção imediata. Isso garante que o agente investigador se concentre em alertas que realmente necessitam investigação.
Conclusão
A adição do agente investigador ao AWS Security Incident Response automatiza a coleta e análise de evidências, reduzindo o tempo necessário para investigar eventos de segurança de horas para minutos. O agente faz perguntas esclarecedoras para compreender suas preocupações específicas, consulta automaticamente múltiplas fontes de dados da AWS, correlaciona evidências e apresenta uma cronologia e resumo abrangente, mantendo transparência e auditoria completas.
Com a adição do agente investigador, clientes do Security Incident Response agora recebem a velocidade e eficiência da automação impulsionada por IA, apoiadas pela expertise e supervisão de especialistas em segurança da AWS quando necessário. As capacidades de investigação com inteligência artificial estão disponíveis hoje em todas as regiões comerciais da AWS onde o Security Incident Response opera. Para saber mais sobre preços e recursos, ou para começar, visite a página do produto AWS Security Incident Response.
O que mudou: Apache Spark 4.0.1 no Amazon EMR Serverless
A AWS disponibilizou em preview o suporte ao Apache Spark 4.0.1 no Amazon EMR Serverless. Esta atualização traz melhorias significativas para a construção e manutenção de pipelines de dados, com foco em acessibilidade, conformidade e aplicações em tempo real. As novas capacidades permitem que as equipes reduzam débito técnico, iterem mais rapidamente e garantam precisão e consistência dos dados.
Principais capacidades do Spark 4.0.1
SQL ANSI padrão para pipelines acessíveis
Uma das grandes mudanças é a possibilidade de construir pipelines de dados utilizando SQL ANSI padrão, tornando a tecnologia acessível a um público muito maior. Desenvolvedores e analistas que não dominam linguagens de programação como Python ou Scala agora podem contribuir efetivamente no desenvolvimento de pipelines, democratizando o acesso a ferramentas de processamento de dados em larga escala.
Suporte nativo a dados semi-estruturados com VARIANT
O Spark 4.0.1 oferece suporte nativo a JSON e dados semi-estruturados através dos tipos de dados VARIANT. Isso proporciona maior flexibilidade para trabalhar com diversos formatos de dados, um requisito cada vez mais comum em ambientes heterogêneos de dados.
Conformidade e governança com Apache Iceberg v3
Outro destaque é a integração com Apache Iceberg v3 no formato de tabelas. O Iceberg oferece garantias de transação e rastreia como os dados mudam ao longo do tempo, criando trilhas de auditoria essenciais para atender a requisitos regulatórios. Com isso, organizações conseguem fortalecer seus frameworks de conformidade e governança de forma significativa.
Streaming em tempo real mais ágil
O Spark 4.0.1 introduz controles de streaming aprimorados que permitem gerenciar operações com estado complexo e monitorar jobs de streaming com facilidade. Essas melhorias habilitam casos de uso como detecção de fraude e personalização em tempo real, tecnologias críticas para negócios modernos.
Disponibilidade e próximos passos
O Apache Spark 4.0.1 está disponível em preview em todas as regiões onde o EMR Serverless opera, com exceção das regiões China e AWS GovCloud (US).
Quando a IA generativa se tornou mainstream, a AWS lançou a Matriz de Escopo de Segurança para IA Generativa para ajudar organizações a compreender e lidar com os desafios únicos de segurança em aplicações baseadas em modelos de fundação. Esse framework foi amplamente adotado não apenas por clientes da AWS, mas também referenciado por organizações como OWASP, CoSAI e outros órgãos de padronização da indústria, parceiros e integradores de sistemas.
Agora, conforme sistemas de IA agêntica com capacidades de chamadas de funções e tomada de decisão autônoma emergem, surge a necessidade de um framework complementar para lidar com um conjunto totalmente novo de desafios de segurança. Diferentemente dos modelos de fundação tradicionais que operam em padrões previsíveis de solicitação e resposta, os sistemas agênticos introduzem capacidades autônomas, memória persistente, orquestração de ferramentas, desafios de identidade e agência, além de integração com sistemas externos. Isso expande significativamente os riscos que as organizações precisam gerenciar.
Sistemas de IA agêntica podem executar tarefas multietapas de forma autônoma, tomar decisões e interagir com infraestrutura e dados. Essa transformação fundamental exige que as organizações se adaptem a uma realidade diferente daquela dos modelos de fundação convencionais. Após trabalhar com clientes que implementam esses sistemas, observou-se que os frameworks tradicionais de segurança em IA nem sempre se estendem adequadamente para o espaço agêntico. A natureza autônoma desses sistemas demanda abordagens de segurança fundamentalmente diferentes.
Para preencher essa lacuna, a AWS desenvolveu a Matriz de Escopo de Segurança para IA Agêntica: um modelo conceitual e um framework que categoriza quatro arquiteturas agênticas distintas com base em níveis de conectividade e autonomia, mapeando controles críticos de segurança em cada uma delas.
Distinção entre agência e autonomia
Os sistemas de IA generativa tradicional funcionam em um padrão bem compreendido e previsível: recebem uma instrução ou prompt, geram uma resposta e encerram a sessão. Controles de segurança e conformidade focam em medidas básicas como validação de entrada, filtragem de saída e guardrails de moderação de conteúdo. Esse modelo funciona porque as falhas de segurança têm escopo limitado — uma interação comprometida afeta apenas aquele request e response específico, sem persistir ou se propagar para outros sistemas ou usuários.
Sistemas agênticos transformam fundamentalmente esse modelo de segurança. Agentes iniciadores podem agir com base em objetivos e gatilhos ambientais que podem ou não exigir prompts humanos ou aprovação. Isso cria riscos de ações não autorizadas, processos descontrolados e decisões que extrapolam os limites pretendidos quando agentes interpretam incorretamente objetivos ou operam com instruções comprometidas.
Ao discutir IA agêntica, é essencial esclarecer a distinção entre dois conceitos relacionados mas distintos: agência e autonomia. Esses conceitos informam diretamente a estratégia de segurança.
Agência refere-se ao escopo de ações que um sistema de IA é autorizado e capaz de executar dentro do ambiente operacional, e quanto um humano delimita as ações ou capacidades do agente. Inclui quais sistemas ele pode interagir, quais operações pode realizar e quais recursos pode modificar. Agência é fundamentalmente sobre capacidades e permissões — o que o sistema está autorizado a fazer.
Autonomia, em contraste, refere-se ao grau de tomada de decisão e ação independente que o sistema pode exercer sem intervenção humana. Inclui quando opera, como escolhe entre ações disponíveis e se requer aprovação humana para execução. Autonomia é sobre independência na tomada de decisão e execução — com quanto liberalismo o sistema pode agir dentro de sua agência concedida.
Por exemplo, um agente de IA pode ter alta agência (capaz de executar muitas ações) mas baixa autonomia (exigindo aprovação humana para cada ação), ou vice-versa. Compreender essa distinção é fundamental para implementar controles de segurança apropriados. Agência requer sistemas de fronteiras e permissões, enquanto autonomia requer mecanismos de supervisão e controles comportamentais.
Capacidades centrais dos sistemas agênticos e seus riscos
Vários fatores chave diferenciam os sistemas agênticos dos modelos tradicionais e ampliam os desafios de segurança:
Execução autônoma e agência: Agentes podem iniciar ações com base em objetivos e gatilhos ambientais, criando riscos de ações não autorizadas e processos descontrolados quando agentes interpretam incorretamente objetivos ou operam com instruções comprometidas.
Memória persistente: Agentes frequentemente mantêm contexto e comportamentos aprendidos entre sessões, construindo bases de conhecimento que informam decisões futuras. Essa persistência de dados introduz requisitos adicionais de proteção de dados e novos vetores de risco, como ataques de envenenamento de memória, onde adversários injetam informações falsas que corrompem a tomada de decisão entre múltiplas interações e usuários.
Orquestração de ferramentas: Agentes se integram diretamente via funções com conexões a bancos de dados, APIs, serviços e potencialmente outros agentes. Essa superfície de ataque expandida cria riscos de compromissos em cascata, onde uma única falha em um agente pode se propagar através de sistemas conectados, workflows multiagente e serviços e armazenamentos de dados a jusante.
Conectividade externa: Agentes operam através de limites de rede, acessando recursos da internet, APIs de terceiros e sistemas empresariais. Essa conectividade expandida pode desbloquear novo valor comercial, mas deve ser projetada com controles de segurança que limitem riscos como exfiltração de dados, movimento lateral e manipulação externa.
Comportamento autodirecionado: Agentes avançados podem iniciar atividades com base no monitoramento ambiental, agendamento ou padrões aprendidos, sem instanciação ou revisão humana. Essa autodireção introduz riscos de operações descontroladas, explicabilidade limitada e auditabilidade reduzida, dificultando a manutenção de fronteiras de segurança previsíveis.
A Matriz de Escopo de Segurança para IA Agêntica
Trabalhando com clientes e a comunidade, a AWS identificou quatro escopos arquiteturais que representam a evolução dos sistemas de IA agêntica, baseados em duas dimensões críticas: o nível de supervisão humana comparado à autonomia e o nível de agência que o sistema de IA tem permissão para exercer. Cada escopo introduz novas capacidades — e requisitos de segurança correspondentes — que as organizações devem priorizar ao lidar com riscos agênticos.
Neste escopo mais básico, os sistemas operam com processos iniciados por humanos e nenhuma capacidade de mudança autônoma ou mesmo aprovada por humanos através do agente. Os agentes são, essencialmente, apenas leitura. Esses sistemas seguem caminhos de execução predefinidos e operam sob workflows rigorosamente acionados por humanos, geralmente predefinidos e com etapas discretas.
O foco de segurança é primariamente na integridade do processo e na aplicação de limites, ajudando operações a permanecerem dentro de limites predeterminados. Agentes são altamente controlados e proibidos de executar mudanças e ações sem limites.
Características principais: Agentes não podem executar mudanças diretas no ambiente, execução passo a passo seguindo caminhos predeterminados, componentes de IA generativa processam dados dentro de nós individuais de workflow, ramificação condicional apenas onde explicitamente projetada no workflow, nenhum comportamento de planejamento dinâmico ou busca autônoma de objetivos, persistência de estado limitada ao contexto de execução de workflow, acesso a ferramentas restrito a etapas específicas de workflow predefinidas.
Foco de segurança: Proteger integridade de dados dentro do ambiente e restringir agentes para não exceder limites, especialmente em relação à modificação de ambiente e dados. As preocupações primárias incluem asegurar transições de estado entre etapas, validar dados passados entre nós de workflow e prevenir componentes de IA de modificarem a lógica de orquestração ou escaparem de seus limites designados.
Exemplo: Imagine um agente projetado para ajudar na criação de convites de calendário. No Escopo 1, você instancia um agente através de um workflow para examinar seu calendário e o de um colega em busca de horários disponíveis. O agente executa uma busca contextual usando um servidor Model Context Protocol conectado à aplicação de calendário empresarial. Ele só tem permissão para consultar horários disponíveis, analisar os melhores momentos para encontro e fornecer uma resposta, que você então usa manualmente para agendar a reunião. Neste exemplo, o humano define workflows específicos (sem agência) e revisa e aprova ações (sem mudança autônoma).
Escopo 2: Agência prescrita
Movendo-se para cima em agência e risco, sistemas de Escopo 2 também são instanciados por um humano, mas agora têm potencial para executar ações — agência limitada — que poderiam alterar o ambiente. Contudo, todas as ações executadas por um agente requerem aprovação humana explícita para todas as ações de consequência, comumente referida como human-in-the-loop (HITL).
Esses sistemas podem coletar informações, analisar dados e preparar recomendações, mas não podem executar ações que modifiquem sistemas externos ou acessem recursos sensíveis sem autorização humana. Agentes também podem solicitar entrada humana para esclarecer ambiguidades, fornecer contexto faltante ou otimizar sua abordagem antes de apresentar recomendações.
Características principais: Agentes podem executar mudanças no ambiente com revisão e aprovação humana, supervisão humana em tempo real com workflows de aprovação, interação bidirecional humano-agente, ações autônomas limitadas a operações apenas leitura, solicitações iniciadas pelo agente para esclarecimento ou informação adicional, trilhas de auditoria de todas as decisões de aprovação humana.
Foco de segurança: Implementar workflows de aprovação robustos e prevenir agentes de contornarem controles de autorização humana. Preocupações chave incluem prevenir escalação de privilégios, aplicar contextos de identidade apropriados, asegurar o processo de aprovação, validar contexto fornecido por humano para prevenir ataques de injeção, e manter visibilidade em todas as recomendações de agente e seu raciocínio.
Exemplo: Um sistema agêntico de Escopo 2 é instanciado por um humano. O agente consulta disponibilidade do calendário das partes interessadas, realiza sua análise e retorna uma recomendação de horário para reunião ao usuário, perguntando se o usuário quer que o agente envie o convite em seu nome. O usuário revisa a resposta e recomendação do agente, valida se atende seus requisitos e então reconhece e aprova a solicitação do agente de modificar os calendários e enviar o convite. Neste exemplo, o humano orquestra um workflow estruturado, mas o agente agora pode instanciar mudança revisada por humano através de ações delimitadas (agência limitada e autonomia limitada).
Escopo 3: Agência supervisionada
No Escopo 3, expande-se a agência para permitir um grau maior de autonomia agêntica — agência alta — na execução. Esses são sistemas de IA que executam tarefas autônomas complexas iniciadas por humanos, com a capacidade de tomar decisões e executar ações em sistemas conectados sem aprovação ou mecanismos de HITL adicionais.
Humanos definem objetivos e disparam execução, mas agentes operam independentemente para alcançar objetivos através de planejamento dinâmico e uso de ferramentas. Durante execução, agentes podem solicitar orientação humana para otimizar trajetória ou lidar com casos extremos, embora possam continuar operando sem ela.
Características principais: Agentes podem executar mudanças no ambiente sem interação ou revisão humana adicional (ou opcionalmente), execução acionada por humano com conclusão autônoma de tarefa, planejamento dinâmico e tomada de decisão durante execução, pontos opcionais de intervenção humana para otimização de trajetória, capacidade humana de ajustar parâmetros ou fornecer contexto durante execução, acesso direto a APIs e sistemas externos para conclusão de tarefa, memória persistente entre sessões de execução estendida, seleção e orquestração autônoma de ferramentas dentro de limites definidos.
Foco de segurança: Implementar monitoramento abrangente de ações do agente durante fases de execução autônoma e estabelecer limites claros de agência para operações agentes. Preocupações críticas incluem asegurar o canal de intervenção humana para prevenir modificações não autorizadas, prevenir aumento de escopo durante execução de tarefa, implementar construtos de propagação de identidade confiável, monitorar anomalias comportamentais e validar que agentes permanecem alinhados com intenção humana original mesmo quando ajustes de trajetória são feitos.
Exemplo: Um sistema agêntico de Escopo 3 ainda é instanciado por um humano. O agente consulta disponibilidade do calendário das partes interessadas, realiza análise e retorna uma recomendação de horário para reunião ao usuário. Contudo, está dentro dos limites do agente atuar sobre sua própria recomendação em nome do usuário para automaticamente agendar o melhor slot disponível. O usuário não é solicitado ou se espera que dê permissão ao agente para isso antes de suas ações. O resultado é que todas as partes interessadas têm uma entrada de calendário adicionada em seu calendário no contexto do usuário chamador. Neste exemplo, o humano define um resultado mas com mais liberdade para o agente determinar como alcançar aquele objetivo, e o agente agora pode executar ação autônoma sem revisão humana (agência alta e autonomia alta).
Escopo 4: Agência completa
O Escopo 4 inclui sistemas de IA totalmente autônomos que podem iniciar suas próprias atividades com base no monitoramento ambiental, padrões aprendidos ou condições predefinidas, e executar tarefas complexas sem intervenção humana. Esses sistemas representam o mais alto nível de agência de IA, operando continuamente e tomando decisões independentes sobre quando e como agir.
É crucial notar que sistemas de IA dentro do Escopo 4 poderiam ter agência completa ao executar dentro de seus limites designados; portanto, é essencial que humanos mantenham supervisão de vigilância com capacidade de fornecer orientação estratégica, correções de curso ou intervenções quando necessário. Mecanismos contínuos de conformidade, auditoria e gerenciamento de ciclo de vida completo — tanto revisões humanas quanto automatizadas, potencialmente auxiliadas por IA — são críticos para asegurar e governar sistemas agênticos de Escopo 4 enquanto se limitam os riscos.
Características principais: Iniciação de atividades autodirecionadas com base em gatilhos ambientais, operação contínua com supervisão humana mínima durante execução, capacidade humana de injetar orientação estratégica sem interromper operações, altos a plenos graus de autonomia em definição de objetivo, planejamento e execução, interação dinâmica com múltiplos sistemas e agentes externos, capacidade para auto-melhoria recursiva e expansão de capacidade.
Foco de segurança: Implementar guardrails avançados para monitoramento comportamental, detecção de anomalias, controles de acesso a ferramentas baseados em escopo e mecanismos à prova de falha para prevenir operações descontroladas. Preocupações primárias incluem manter alinhamento com objetivos organizacionais, asegurar canais de intervenção humana contra manipulação adversarial, prevenir expansão de capacidade não autorizada, prevenir que mecanismos de supervisão humana sejam desabilitados pelo agente e permitir degradação graciosa quando agentes encontram situações inesperadas.
Exemplo: Considere como nosso exemplo de calendário poderia ser deployado em Escopo 4. Suponha que você tenha implementado um sumarizador de IA generativa para reunião. Esse agente é habilitado automaticamente quando você hospeda uma videoconferência. Ao fim da reunião, o agente sumarizador observa uma nova reunião que ocorreu e o agente de calendário vê isso. Ele examina itens de ação que foram sumarizados e determina que seis pessoas concordaram em uma sessão de whiteboarding na sexta. O agente de calendário poderia ter uma configuração de API estaticamente definida ou alavancar descoberta dinâmica em servidores MCP para ajudar com calendário. Ele então encontra disponibilidade para os seis recursos identificados e agenda o melhor slot. Usa então o contexto de identidade apropriado do usuário solicitando a reunião para agendar a reunião autonomamente. Em nenhum ponto um usuário instancia diretamente a solicitação de calendário; é totalmente automatizado e acionado por mudanças ambientais que o agente é instruído a buscar (agência completa e autonomia completa).
Dimensões críticas de segurança entre escopos
À medida que as organizações progridem pelos escopos, os requisitos de segurança aumentam em complexidade e escopo. Seis dimensões críticas de segurança devem ser consideradas:
Contexto de identidade (autenticação e autorização): Do Escopo 1 ao 4, evoluindo de autenticação básica de usuário para autenticação de serviço, delegação de identidade para ações autônomas, dinamicidade completa de ciclo de vida de identidade e autenticação federada.
Proteção de dados, memória e estado: Começando com permissões de recurso local e controle de acesso ao sistema de arquivos, progredindo para autorização baseada em função, elevação de privilégio just-in-time e finalmente para controles de autorização adaptativos e validação de autorização contínua.
Auditoria e logging: Evoluindo de logs de atividade local para trilhas de auditoria de decisão humana, captura de cadeia de raciocínio agente, logging comportamental contínuo e análise preditiva.
Controles de agente e modelo de fundação: Isolamento de processo em Escopo 1 progredindo para análise comportamental e detecção de anomalias em escopos posteriores, com contenção automatizada em Escopos 3 e 4.
Perímetros de agência e políticas: Limites de execução fixa em Escopo 1 evoluindo para ajuste de limite dinamicamente e adaptação autônoma em Escopos 3 e 4.
Orquestração: Orquestração simples de workflow em Escopo 1 progredindo para descoberta dinâmica de serviço e aprendizado entre sessões em Escopos 3 e 4.
Implementação de padrões arquiteturais bem-sucedidos
Deployments bem-sucedidos de sistemas agênticos compartilham padrões comuns que balanceiam autonomia com controle:
Deployment progressivo de autonomia: Iniciar com implementações de Escopo 1 ou 2 e gradualmente avançar pelos escopos conforme a confiança organizacional e capacidades de segurança amadurecem. Essa abordagem minimiza risco enquanto constrói experiência operacional. Seja cauteloso e seletivo ao analisar casos de uso e definir limites de controle para implementações de Escopo 4.
Arquitetura de segurança em camadas: Implementar defesa em profundidade com controles de segurança em múltiplos níveis — rede, aplicação, agente e camadas de dados. Esforce-se particularmente em endereçar preocupações de identidade e autorização para máquinas e humanos, prevenindo problemas como o problema do deputy confuso — quando um humano ou serviço com menores permissões consegue elevar permissões através de agentes que podem ter mais direitos.
Loops contínuos de validação: Estabelecer sistemas automatizados que continuamente verificam comportamento do agente contra padrões esperados, com procedimentos de escalação quando desvios são detectados. Auditabilidade e explicabilidade são requisitos chave para confirmar que agentes estão operando dentro dos limites pretendidos e para ajudar determinar efetividade de controle.
Integração de supervisão humana: Mesmo em sistemas altamente autônomos, manter supervisão humana significativa através de checkpoints estratégicos, relatórios comportamentais e capacidades de override manual. A supervisão humana não diminui de Escopo 1 para 4; ela simplesmente muda foco. Em Escopos 1 e 2, o requisito humano de instanciar, revisar e aprovar ações agentes é alto. Em Escopos 3 e 4 é menor, mas o requisito humano de auditar, avaliar, validar e implementar controles de segurança e operacionais mais complexos é muito maior.
Degradação graciosa: Desenhar sistemas para automaticamente reduzir níveis de autonomia quando eventos de segurança são detectados, permitindo operações continuarem seguramente enquanto operadores humanos investigam. Se agentes começarem a agir além dos limites pretendidos de seu design, comportamento anômalo é detectado, ou começam executar ações particularmente arriscadas ou sensíveis ao seu negócio, considere ter controles detetivos que automaticamente injetem restrições mais apertadas, como exigir mais HITL ou reduzir as ações que um agente pode executar.
Conclusão
A Matriz de Escopo de Segurança para IA Agêntica fornece um modelo mental estruturado e um framework para compreender e endereçar os desafios de segurança de sistemas autônomos agênticos de IA em quatro escopos distintos. Ao avaliar acuradamente seu escopo atual e implementar controles apropriados em todas as seis dimensões críticas de segurança, as organizações podem confidentemente deployar IA agêntica enquanto gerenciam a paisagem de riscos associados.
A progressão de agentes básicos e altamente constrangidos para agentes totalmente autônomos e até mesmo autodirecionados representa uma mudança fundamental em como abordamos segurança de IA. Cada escopo requer capacidades de segurança específicas, e as organizações devem construir essas capacidades sistematicamente para apoiar suas ambições agênticas de forma segura.
Próximos passos
Para implementar a Matriz de Escopo de Segurança para IA Agêntica em sua organização:
Avalie seus casos de uso agênticos atuais e maturidade em relação aos quatro escopos para compreender seus requisitos de segurança e riscos associados.
Integre a matriz em seus processos de procurement e SDLC.
Identifique lacunas de capacidade nas seis dimensões de segurança para seu escopo-alvo.
Desenvolva uma estratégia de deployment progressivo que constrói capacidades de segurança conforme você avança pelos escopos.
Implemente monitoramento contínuo e análise comportamental apropriada para seu nível de escopo.
Estabeleça processos de governança para progressão de escopo e validação de segurança.
Treine seus times nos desafios de segurança únicos de cada escopo.
À medida que as organizações ampliam a adoção de capacidades de inteligência artificial em seus aplicativos, surge um desafio crítico: como centralizar o gerenciamento, a segurança e o controle de custos do acesso a modelos de IA? Esse é um passo fundamental para escalar soluções de IA de forma consistente e controlada.
Para empresas que trabalham com IA generativa, o cenário se torna particularmente complexo. As equipes frequentemente precisam acessar diferentes modelos de IA de diversos provedores — Amazon Bedrock, Amazon SageMaker AI, OpenAI, Anthropic e outros — cada um com suas próprias APIs, métodos de autenticação e modelos de faturamento. Sem um ponto de acesso unificado, as organizações enfrentam dificuldades para implementar políticas de segurança consistentes, monitorar o uso e controlar custos em todos os serviços de IA.
Os Principais Obstáculos na Operação de IA em Larga Escala
Fragmentação de Provedores
A diversidade de fornecedores de modelos cria uma fragmentação operacional significativa. Cada provedor apresenta interfaces diferentes, mecanismos de autenticação distintos e estruturas de preço variadas. Essa pluralidade, embora ofereça flexibilidade, aumenta a complexidade operacional.
Governança Descentralizada
Sem uma interface central, é extremamente desafiador manter políticas de segurança uniformes, rastrear o uso de modelos e controlar gastos de forma centralizada. Cada equipe pode operar de forma isolada, dificultando a visibilidade global e o cumprimento de padrões corporativos.
Complexidade Operacional
Gerenciar múltiplos paradigmas de acesso — que variam desde funções de AWS Identity and Access Management até chaves de API, limites de taxa específicos de modelos e estratégias de failover — cria sobrecarga operacional e aumenta o risco de interrupções no serviço.
Controle de Custos
Compreender e controlar gastos com IA em múltiplos provedores e equipes se torna cada vez mais difícil à medida que o uso escala. Sem visibilidade centralizada, é fácil perder o controle do orçamento destinado a operações de IA.
Segurança e Conformidade
Implementar políticas de segurança consistentes e manter trilhas de auditoria em diferentes provedores de IA apresenta desafios significativos para a governança corporativa.
A Solução: Gateway de IA Multiprovedora
Para endereçar esses desafios comuns, a AWS ofereceu uma arquitetura de referência que fornece um gateway centralizado capaz de abstrair a complexidade de múltiplos provedores de IA atrás de uma interface única e gerenciada. Construída sobre serviços AWS e utilizando o projeto open source LiteLLM, essa solução permite que as organizações se integrem com diversos provedores de IA enquanto mantêm controle centralizado, segurança e observabilidade robustas.
A Generative AI Gateway on AWS é uma arquitetura de referência para empresas que desejam implementar soluções completas de IA generativa, com múltiplos modelos, respostas enriquecidas por dados e capacidades de agentes em formato auto-hospedado. Essa orientação combina o amplo acesso a modelos do Amazon Bedrock, a experiência unificada de desenvolvedor do Amazon SageMaker AI e os recursos robustos de gerenciamento do LiteLLM, tudo enquanto oferece suporte a acesso a modelos de provedores externos de forma mais segura e confiável.
Flexibilidade de Implantação na AWS
A solução oferece múltiplos padrões de implantação para atender às necessidades diversas das organizações.
Implantação em Amazon ECS
Para equipes que preferem aplicações containerizadas com infraestrutura gerenciada, a opção Amazon ECS oferece orquestração de containers sem servidor, com dimensionamento automático e balanceamento de carga integrado.
Implantação em Amazon EKS
Organizações com experiência existente em Kubernetes podem utilizar a opção Amazon EKS, que oferece controle total sobre a orquestração de containers enquanto se beneficia de um plano de controle Kubernetes gerenciado. É possível implantar um novo cluster ou aproveitar clusters existentes.
Vale notar que a arquitetura de referência fornecida está sujeita a testes de segurança adicionais baseados nos requisitos específicos da organização. É recomendável conduzir testes de segurança e revisão antes de implantar em produção.
Opções de Arquitetura de Rede
O gateway oferece múltiplas configurações de rede para diferentes cenários operacionais.
Implantação Pública Global
Para serviços de IA com base de usuários global, o gateway pode ser combinado com Amazon CloudFront e Amazon Route 53. Essa configuração fornece proteção aprimorada contra DDoS com AWS Shield, gerenciamento simplificado de HTTPS com certificados padrão do CloudFront, cache global em edge locations para reduzir latência e roteamento inteligente de tráfego entre regiões. Esta é a configuração recomendada para serviços de IA com alcance global.
Acesso Direto Regional
Para implantações em uma única região que priorizam baixa latência e otimização de custos, acesso direto ao Application Load Balancer (ALB) remove a camada de CloudFront mantendo segurança através de grupos de segurança e ACLs de rede adequadamente configurados.
Acesso Privado Interno
Organizações que exigem isolamento completo podem implantar o gateway dentro de uma VPC privada sem exposição à internet. Essa configuração garante que o acesso a modelos de IA permaneça dentro do perímetro de segurança, com grupos de segurança do ALB restringindo tráfego apenas aos CIDRs de sub-redes privadas autorizadas. O acesso pode ser restrito a redes confiáveis como VPN, Direct Connect, VPC peering ou AWS Transit Gateway.
Governança e Gerenciamento Abrangentes de IA
O gateway foi construído para habilitar padrões robustos de governança de IA através de uma interface administrativa simplificada. Além de gerenciamento de acesso e configuração baseada em políticas, usuários podem configurar capacidades avançadas como balanceamento de carga e cache de prompts.
Interface de Administração Centralizada
O Gateway de IA Generativa inclui uma interface administrativa baseada em web no LiteLLM que oferece suporte a gerenciamento abrangente do uso de LLMs em toda a organização. As capacidades principais incluem:
Gerenciamento de usuários e equipes: Configure controles de acesso em níveis granulares, de usuários individuais a equipes inteiras, com permissões baseadas em papéis que se alinham com a estrutura organizacional.
Gerenciamento de chaves de API: Gerencie centralmente e rotacione chaves de API para provedores de IA conectados mantendo trilhas de auditoria de uso e padrões de acesso.
Controles de orçamento e alertas: Configure limites de gastos por provedor, equipe e usuário individual com alertas automatizados quando limiares se aproximam ou são excedidos.
Controles de custo abrangentes: Os custos são influenciados pela infraestrutura AWS e provedores de LLM. Embora seja responsabilidade do cliente configurar a solução para atender seus requisitos de custo, as organizações podem revisar as configurações de custo existentes para orientação adicional.
Suporte a múltiplos provedores de modelos: Compatível com Boto3, OpenAI e LangGraph SDK, permitindo que clientes usem o melhor modelo para cada carga de trabalho independentemente do provedor.
Suporte a Amazon Bedrock Guardrails: Clientes podem aproveitar guardrails criados no Amazon Bedrock para suas cargas de trabalho de IA generativa, independentemente do provedor de modelo.
Roteamento Inteligente e Resiliência
Considerações comuns sobre implantação de modelos incluem resiliência de modelos e prompts. Esses fatores são importantes para determinar como falhas são tratadas ao responder a um prompt ou acessar armazenamentos de dados.
Balanceamento de Carga e Failover
O gateway implementa lógica sofisticada de roteamento que distribui requisições entre múltiplas implantações de modelos e automaticamente realiza failover para provedores de backup quando problemas são detectados.
Lógica de Retry
Mecanismos integrados de retry com backoff exponencial facilitam entrega de serviço confiável mesmo quando provedores individuais experimentam problemas transitórios.
Cache de Prompts
Cache inteligente reduz custos evitando requisições duplicadas a modelos de IA caros enquanto mantém precisão de respostas.
Gerenciamento Avançado de Políticas
A arquitetura de implantação de modelos pode variar do simples ao extremamente complexo. O Gateway de IA Multiprovedora oferece ferramentas avançadas de gerenciamento de políticas necessárias para manter postura forte de governança:
Rate limiting: Configure políticas sofisticadas de limitação de taxa que variam por usuário, chave de API, tipo de modelo ou hora do dia para facilitar alocação justa de recursos e ajudar a prevenir abusos.
Controles de acesso a modelos: Restrinja acesso a modelos de IA específicos baseado em papéis de usuário, garantindo que modelos sensíveis ou caros sejam acessíveis apenas a pessoal autorizado.
Regras de roteamento personalizadas: Implemente lógica de negócio que roteia requisições a provedores específicos baseado em critérios como tipo de requisição, localização do usuário ou requisitos de otimização de custo.
Monitoramento e Observabilidade
À medida que cargas de trabalho de IA crescem para incluir mais componentes, as necessidades de observabilidade também crescem. A arquitetura do Gateway de IA Multiprovedora se integra com Amazon CloudWatch. Essa integração permite que usuários configurem inúmeras soluções de monitoramento e observabilidade, incluindo ferramentas open source como Langfuse.
Logging e Análise Abrangentes
As interações do gateway são automaticamente registradas no CloudWatch, fornecendo insights detalhados sobre:
Padrões de requisição e tendências de uso entre provedores e equipes
Métricas de desempenho incluindo latência, taxas de erro e throughput
Alocação de custos e padrões de gastos por usuário, equipe e tipo de modelo
Eventos de segurança e padrões de acesso para relatórios de conformidade
Troubleshooting Integrado
A interface administrativa oferece capacidades de visualização de logs em tempo real, permitindo que administradores diagnostiquem e resolvam rapidamente problemas de uso sem necessidade de acessar CloudWatch diretamente.
Integração com Amazon SageMaker para Acesso Expandido a Modelos
O Amazon SageMaker AI amplia a orientação do Gateway de IA Multiprovedora ao fornecer um sistema completo de aprendizado de máquina que se integra perfeitamente à arquitetura do gateway. Ao utilizar a infraestrutura gerenciada do SageMaker para treinamento, implantação e hospedagem de modelos, as organizações podem desenvolver modelos de fundação customizados ou ajustar finos em modelos existentes que podem ser acessados através do gateway juntamente com modelos de outros provedores.
Essa integração elimina a necessidade de gerenciamento separado de infraestrutura enquanto facilita governança consistente entre modelos customizados e de terceiros. As capacidades de hospedagem de modelos do SageMaker AI expandem o acesso de modelos do gateway para incluir modelos auto-hospedados, bem como aqueles disponíveis no Amazon Bedrock, OpenAI e outros provedores.
Começando: Ferramentas e Recursos Disponíveis
A arquitetura de referência do Gateway de IA Multiprovedora está disponível através de um GitHub repository, completo com:
O repositório de código descreve várias opções de implantação flexíveis para começar.
Gateway Público com Distribuição Global CloudFront
Use CloudFront para fornecer um ponto de acesso distribuído globalmente e com baixa latência para seus serviços de IA generativa. Os edge locations do CloudFront entregam conteúdo rapidamente aos usuários em todo o mundo, enquanto o AWS Shield Standard ajuda a proteger contra ataques DDoS. Esta é a configuração recomendada para serviços de IA com acesso público e base de usuários global.
Domínio Customizado com CloudFront
Para uma experiência mais personalizada, configure o gateway para usar seu próprio nome de domínio customizado, aproveitando ainda os recursos de desempenho e segurança do CloudFront. Essa opção é ideal quando se deseja manter consistência com a presença online da empresa.
Acesso Direto via Application Load Balancer Público
Clientes que priorizam baixa latência sobre distribuição global podem optar por implantação direta ao ALB, sem a camada CloudFront. Essa arquitetura simplificada oferece economia de custos, embora exija consideração adicional para proteção com web application firewall.
Acesso Privado Exclusivo em VPC
Para alto nível de segurança, implante o gateway inteiramente dentro de uma VPC privada, isolado da internet pública. Essa configuração é apropriada para processamento de dados sensíveis ou implantação de serviços internos de IA generativa.
Explorando Casos de Uso Práticos
A AWS também publicou um exemplo que integra o gateway em uma aplicação prática de atendimento ao cliente com agentes de IA. O sistema de agentes é orquestrado usando LangGraph e implantado em Amazon Bedrock AgentCore. As chamadas a LLM são roteadas através do gateway, oferecendo flexibilidade para testar agentes com diferentes modelos — seja hospedados na AWS ou em outro provedor.
Uma Fundação Madura para IA Generativa
Essa orientação é apenas uma parte de uma fundação madura de IA generativa na AWS. Para leitura mais profunda sobre os componentes de um sistema de IA generativa na AWS, consulte a orientação sobre Architect a mature generative AI foundation on AWS, que descreve componentes adicionais de um sistema de IA generativa.
Conclusão
O Gateway de IA Multiprovedora representa uma abordagem significativa para simplificar operações de IA em ambientes corporativos. Ao centralizar o gerenciamento, segurança e observabilidade de múltiplos provedores de modelos, as organizações conquistam maior controle sobre custos, conformidade e experiência de desenvolvimento.
A solução oferece flexibilidade de implantação através de ECS ou EKS, múltiplas opções de arquitetura de rede, e integração robusta com serviços AWS como SageMaker e CloudWatch. Para equipes brasileiras que trabalham em escala com IA, essa orientação fornece um ponto de partida bem fundamentado para implementar soluções de IA generativa de forma governada e segura.
Novo Modelo de Segurança para Ambientes Regulamentados
A AWS anunciou a disponibilidade da mais recente linha de base de segurança do Landing Zone Accelerator on AWS (LZA): a Configuração Universal. Desenvolvida a partir de anos de experiência prática com clientes altamente regulamentados, incluindo órgãos governamentais de diversos países, e contando com a consulta de parceiros AWS e especialistas do setor, esta configuração foi construída especificamente para ajudar organizações a implementar segurança e conformidade em escala para cargas de trabalho reguladas.
Ao estabelecer um alto padrão com as mais recentes práticas de segurança da AWS, a Configuração Universal busca atender aos requisitos de controles técnicos de diferentes frameworks de conformidade, abrangendo várias regiões geográficas e verticais de indústria.
Arquitetura Multi-Conta e Preparação para o Futuro
A arquitetura de segurança multi-conta da Configuração Universal fornece uma fundação robusta para hospedar suas necessidades diversas de cargas de trabalho hoje, ao mesmo tempo em que oferece a possibilidade de explorar soluções de inteligência artificial generativa e IA agentic que moldarão o futuro da sua organização.
Um dos principais diferenciais é a capacidade de substituir meses de planejamento e design complexo. Ao implantar um ambiente abrangente orientado por segurança e conformidade, baseado nos princípios do AWS Well-Architected, o processo leva apenas horas. Essa velocidade de implementação é transformadora para organizações que precisam balancear inovação com rigor regulatório.
Conformidade Escalável em Qualquer Estágio
À medida que as organizações crescem, frequentemente precisam aderir a novas certificações de segurança e conformidade. O LZA e a Configuração Universal apoiam organizações de qualquer tamanho e fase em sua jornada de segurança e conformidade.
A velocidade de implantação, documentação passo a passo e recursos de conformidade podem reduzir cronogramas tradicionais de avaliação e autorização em meses, resultando em auditorias mais previsíveis e bem-sucedidas. Isso permite que as organizações direcionem recursos para crescimento empresarial, em vez de enfrentar dilemas entre segurança e conformidade.
Principais Benefícios da Configuração Universal
Automatiza a implantação de um ambiente AWS multi-conta seguro
Estabelece controles de segurança fundamentados nas melhores práticas do AWS Well-Architected
Aplica controles de segurança consistentes e previsíveis após a implantação
Integra-se nativamente com serviços de segurança, identidade e conformidade da AWS
Implementa controles em múltiplas camadas de sistema
Fornece arquitetura de segurança em nível organizacional
Inclui controles preventivos, proativos e detetivos em perímetro e recursos específicos
Suporta resiliência multi-região, recuperação de desastres e failover ativo
Estabelece fundações para prontidão em segurança e conformidade
Incorpora melhores práticas de segurança AWS com declarações de implementação técnica
Mapeia capacidades do LZA em frameworks de conformidade globais e específicos por indústria
Implanta centenas de controles em horas, não em meses
O Manuais de Conformidade do LZA
O mecanismo do LZA tem sido uma ferramenta confiável para implantar rapidamente ambientes AWS multi-conta seguros por mais de 4 anos. Além disso, é eficiente em termos de custo — você paga apenas pelos serviços AWS utilizados para operar seu ambiente.
A Configuração Universal é o primeiro modelo de configuração acompanhado pelo Manuais de Conformidade do LZA, disponível no AWS Artifact. Trata-se de um recurso inédito que apresenta mapeamentos detalhados de controles, demonstrando como a Configuração Universal pode atender a requisitos de diversos frameworks, incluindo NIST 800-53 Rev5, CMMC/NIST 800-171, ISO-27001, HIPAA, C5:2020, NATO D-32 (Apêndice B) e DoD CCI.
O Manuais de Conformidade é mantido regularmente para refletir a versão mais recente da linha de base da Configuração Universal, e incluirá mapeamentos de conformidade adicionais em futuros lançamentos. O documento contém descrições detalhadas de configuração de segurança baseadas nos arquivos de implantação da Configuração Universal, junto com mapeamentos de requisitos de controle e declarações de implementação que traduzem suas capacidades de segurança em um formato amigável à conformidade.
Ao combinar as melhores práticas de segurança da AWS com experiência global em conformidade, a Configuração Universal entrega resultados de segurança previsíveis, ao mesmo tempo em que ajuda a organização a atender requisitos regionais e específicos da indústria.
Como Começar
Para iniciar com a Configuração Universal do Landing Zone Accelerator on AWS, o Guia de Implementação do LZA orientará você através dos passos, casos de uso e considerações ao fazer a implantação com o LZA.
Você pode utilizar a ferramenta AWS Partner Finder e buscar por solução para Landing Zone Accelerator e descobrir as ofertas mais recentes de parceiros especializados em LZA.
A AWS Organizations Tag Policies anunciou o recurso Reporting for Required Tags, uma validação inovadora que garante proativamente que implantações de CloudFormation, Terraform e Pulumi incluam as tags obrigatórias essenciais para o negócio. Dessa forma, operações de infraestrutura como código (IaC) podem ser automaticamente validadas em relação às políticas de tags, garantindo consistência de tagging em toda a infraestrutura AWS.
Como funciona a validação em dois passos
O processo de conformidade para implantações de IaC agora simplificou-se em duas etapas práticas:
Definir sua política de tags conforme as necessidades organizacionais
Ativar a validação em cada ferramenta de infraestrutura como código
As Tag Policies da AWS permitem reforçar tagging consistente em contas AWS, oferecendo conformidade proativa, governança e controle. Com esse lançamento, é possível especificar chaves de tag obrigatórias nas políticas e estabelecer guardrails para implantações de IaC.
Exemplo prático de aplicação
Considere um cenário comum: sua organização deseja garantir que todas as instâncias EC2 em templates de IaC tenham tags específicas. Por meio dessa funcionalidade, você pode definir uma política de tags estabelecendo que toda instância EC2 deve conter obrigatoriamente as chaves “Environment”, “Owner” e “Application”.
Ativação em diferentes plataformas
A validação pode ser iniciada de formas distintas conforme a ferramenta utilizada:
CloudFormation: ativar o Hook AWS::TagPolicies::TaggingComplianceValidator
Terraform: adicionar lógica de validação no plano de execução
Pulumi: ativar o policy pack pré-construído aws-organizations-tag-policies
Após a configuração, todas as implantações de CloudFormation, Terraform e Pulumi na conta alvo são automaticamente validadas ou reforçadas em relação às políticas de tags. Isso garante que recursos como instâncias EC2 incluam as tags obrigatórias “Environment”, “Owner” e “Application”, conforme definido.
Acesso e disponibilidade
O recurso Reporting for Required Tags está disponível através de três canais principais:
Nova Camada de Segurança para o OpenSearch Serverless
A AWS anunciou o suporte a AWS PrivateLink para o console de gerenciamento do Amazon OpenSearch Serverless. Essa adição reforça o portfólio de segurança da plataforma, permitindo que organizações estabeleçam conexões privadas e seguras entre suas infraestruturas de nuvem virtual (VPC) e o serviço de busca sem precisar expor tráfego à internet pública.
Até agora, acessar o console de gerenciamento do OpenSearch Serverless exigia contar com endereços IP públicos ou depender exclusivamente de regras de firewall. A introdução do PrivateLink elimina essa dependência, oferecendo um caminho alternativo e mais seguro para gerenciar os recursos.
Como Funciona a Integração com PrivateLink
O PrivateLink permite criar uma conexão direta e privada entre sua VPC e o Amazon OpenSearch Serverless através de endpoints de VPC. Com esse mecanismo, operações de gerenciamento e também acesso aos dados podem ser feitos de forma segura, sem necessidade de roteamento pela internet pública.
É importante notar que, embora o PrivateLink agora cubra as operações de gerenciamento e dados, as operações de ingestão e consulta em coleções ainda dependem da configuração de endpoints VPC fornecida pelo OpenSearch Serverless, conforme descrito na documentação específica de VPC do OpenSearch Serverless.
Disponibilidade e Cobrança
A funcionalidade está disponível em todas as regiões AWS onde o Amazon OpenSearch Serverless é oferecido. Vale destacar que a criação de endpoints de VPC usando AWS PrivateLink gera custos adicionais. Para detalhes sobre preços, consulte a página de preços do AWS PrivateLink.
Como Começar
Para implementar essa solução, você pode criar um endpoint de interface VPC para o Amazon OpenSearch Serverless através de diversos meios:
Organizações empresariais frequentemente precisam consolidar dados de segurança, operações e conformidade provenientes de múltiplas partições da AWS para obter uma visão unificada dos seus ambientes. Embora essa consolidação seja crítica para manter operações e aplicações funcionando adequadamente, alcançá-la respeitando requisitos de conformidade representa um desafio significativo.
Historicamente, as empresas resolviam esse problema usando chaves de acesso de usuários IAM de longa duração. Porém, essa abordagem se tornou obsoleta. A AWS agora recomenda o uso de IAM Roles Anywhere como alternativa segura e em conformidade com os melhores práticas atuais de segurança.
Entendendo as partições e fronteiras de isolamento da AWS
O que são partições AWS?
As partições da AWS funcionam como fronteiras rígidas projetadas especificamente para atender requisitos de isolamento orientados por conformidade. Cada partição consiste em uma ou mais regiões e é controlada por uma instância independente do IAM. A AWS oferece múltiplas partições, cada uma identificada de forma única nos nomes de recursos Amazon (ARN):
A partição AWS Commercial utiliza o identificador aws
As regiões AWS GovCloud utilizam o identificador aws-us-gov
As regiões AWS China utilizam o identificador aws-cn
Os identificadores de contas AWS e as designações de região são reservados para garantir que existam apenas dentro de suas respectivas partições. Especificamente, cada instância do IAM em uma partição proíbe a criação de políticas de confiança que atravessem fronteiras de partição. Qualquer tentativa de construir uma política de confiança entre contas em duas partições diferentes resulta em erro CREATE_FAILED. Esse isolamento é intencional e representa um componente fundamental da estratégia de segurança oferecida pela AWS aos seus clientes.
Fluxo de dados e conformidade com FedRAMP
Para clientes sujeitos a regulamentações como FedRAMP, o entendimento claro de requisitos de conformidade e a construção de dashboards e fluxos de trabalho unificados na partição apropriada são absolutamente críticos. Por exemplo, dados devem fluir apenas da partição AWS Commercial para a partição AWS GovCloud, nunca na direção oposta. Isso está alinhado com a política de fronteira FedRAMP FRR211, que estabelece que informações sobre workloads no GovCloud não devem ser compartilhadas com a partição Commercial.
A prática recomendada para organizações neste cenário é construir dashboards unificados e automação operando integralmente na partição AWS GovCloud. Dessa forma centralizada, remediações automatizadas, notificações e escalações podem ser disparadas usando Amazon EventBridge contra dados coletados de recursos nas regiões Commercial e GovCloud. Esses fluxos automatizados podem integrar-se com sistemas de ticketing como Service Now ou Atlassian JIRA, plataformas de proteção nativa de aplicações em nuvem (CNAPP) como AWS Security Hub ou CrowdStrike, e sistemas de notificação empresarial como Slack, Microsoft Teams, ou email.
Isolamento de credenciais na prática
Além do isolamento de dados entre partições, uma melhor prática de conformidade com FedRAMP é garantir que as credenciais utilizadas para acessar regiões GovCloud existam apenas dentro dessas regiões. Da mesma forma, requisições de acesso a dados devem originar-se da partição GovCloud, puxando dados da partição menos restritiva (como a Commercial). Esse design ajuda a prevenir exposição de recursos do GovCloud à partição Commercial através de portas abertas, APIs, endpoints ou credenciais compartilhadas.
A abordagem legada: transferência com chaves de acesso IAM
No passado, empresas resolviam requisitos de transferência entre partições utilizando ferramentas como Data Sync, s3api, data transfer hub e outros métodos de SDK. A estratégia consistia em criar uma chave de acesso de usuário IAM na partição AWS Commercial e, em seguida, armazenar essa chave no AWS Secrets Manager da partição GovCloud.
Uma aplicação executando no GovCloud utilizaria então a chave de acesso do usuário IAM da partição Commercial para acessar e ler dados de um bucket Amazon S3 nessa partição, escrever os dados em um bucket S3 no GovCloud e processar os dados localmente. Embora funcional, essa arquitetura apresentava desvantagens significativas.
Essa solução legada exigia uma exceção de auditoria para permitir o uso de credenciais de usuário de longa duração. Usar credenciais de longa duração em workloads ou contas de serviço se afasta das melhores práticas de segurança da AWS e dos padrões NIST 800-53 IA2, pois essas credenciais podem ser comprometidas e são difíceis de rotacionar e substituir com frequência adequada.
A solução moderna: IAM Roles Anywhere com certificados X.509
Credenciais de curta duração com certificados
Para atender ao requisito de usar credenciais de curta duração e habilitar acesso entre partições AWS, a AWS oferece IAM Roles Anywhere, que elimina a necessidade de chaves de acesso ou segredos de longa duração. Esse serviço permite que organizações utilizem certificados X.509 existentes para autenticar workloads e aplicações.
O alinhamento com NIST 800-53 é estabelecido através do uso de certificados, que são padrão consolidado na indústria para estabelecer comunicações seguras com processos de aplicações em dispositivos remotos.
Duas caminhos: Autoridade de Certificação externa ou AWS Private CA
As organizações possuem flexibilidade para escolher como gerenciar a infraestrutura de chaves públicas (PKI):
Autoridade de Certificação externa: Se a empresa já possui uma autoridade de certificação interna, é possível registrá-la com IAM Roles Anywhere como uma âncora de confiança, estabelecendo confiança entre essa CA externa e o serviço.
AWS Private CA: Para organizações que não possuem infraestrutura de chaves públicas própria, a AWS Private Certificate Authority oferece uma solução gerenciada.
Arquitetura com Autoridade de Certificação externa
Quando a organização utiliza uma CA externa, a arquitetura típica envolve uma infraestrutura de chaves públicas com múltiplos níveis: uma CA raiz (frequentemente desconectada da internet para proteção máxima), uma ou mais CAs intermediárias e CAs emissoras que geram certificados finais.
Quando uma aplicação no GovCloud precisa se conectar à partição Commercial, ela gera uma solicitação de assinatura de certificado (CSR), mantendo a chave privada correspondente no AWS Secrets Manager. A CA externa da organização assina a CSR e fornece um certificado de entidade final junto com o pacote de CA (contendo as certificações da CA raiz, intermediária e emissora). Todos esses elementos são armazenados no Secrets Manager, permitindo que o workload interaja com recursos da partição Commercial.
Na partição Commercial, o IAM Roles Anywhere é configurado para usar a PKI da empresa como âncora de confiança. À medida que certificados são distribuídos para workloads em execução no GovCloud (e armazenados no Secrets Manager), uma função do Amazon Elastic Kubernetes Service (Amazon EKS) permite acesso a esses certificados. Na partição Commercial, uma função IAM é configurada para permitir acesso aos serviços necessários como Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS) e Amazon S3. O policy de confiança dessa função é configurada para permitir acesso via IAM Roles Anywhere.
Quando o pipeline EKS no GovCloud está pronto para se conectar, um credential helper fornece credenciais de segurança temporárias para a região Commercial, utilizando os certificados, a chave privada, os ARNs de função e âncora de confiança provisionados para a aplicação no GovCloud.
Simplificação com AWS Private CA
Para organizações que preferem não manter uma infraestrutura de chaves públicas própria, a AWS Private CA oferece uma alternativa gerenciada. Como serviço gerenciado, a AWS cuida de alta disponibilidade, escalabilidade, durabilidade, aplicação de patches e manutenção da plataforma. A integração nativa com serviços como AWS Elastic Load Balancing, Amazon CloudFront e Amazon API Gateway simplifica ainda mais a adoção. Além disso, AWS CloudTrail fornece auditoria completa de todas as ações realizadas, garantindo conformidade e transparência operacional.
A transferência segura e em conformidade de dados entre partições AWS requer compreensão clara dos requisitos de conformidade e design arquitetônico apropriado. Enquanto a abordagem legada com chaves de acesso de longa duração funcionava, ela se afastava das melhores práticas de segurança moderna.
IAM Roles Anywhere emerge como a solução recomendada para clientes e parceiros SaaS que precisam acessar recursos AWS entre partições sem sacrificar a segurança. Ao utilizar certificados X.509 e autoridades de certificação — sejam externas ou o serviço gerenciado AWS Private CA — as organizações ganham a capacidade de implementar transferência de dados com credenciais temporárias, alinhadas com NIST 800-53 e melhores práticas de conformidade FedRAMP.
Expansão do suporte de migração com inteligência artificial
A AWS anunciou uma importante expansão do Schema Conversion, um recurso gerenciado do Database Migration Service (DMS). A novidade permite que os usuários convertam bancos de dados SAP Adaptive Server Enterprise (ASE), anteriormente conhecido como Sybase, para Amazon RDS PostgreSQL e Amazon Aurora PostgreSQL.
O Schema Conversion é uma solução totalmente gerenciada que avalia e converte schemas de bancos de dados automaticamente, transformando-os em formatos compatíveis com os serviços de banco de dados suportados pela AWS. O diferencial desta atualização é a integração com capacidades de inteligência artificial generativa, que inteligentemente executa conversões de código complexas que tradicionalmente exigem esforço manual.
Automatização inteligente de conversões complexas
Um dos maiores desafios em projetos de migração de bancos de dados é a conversão de objetos complexos. O Schema Conversion agora utiliza IA para lidar automaticamente com elementos como stored procedures, functions e triggers. Essas estruturas de banco de dados frequentemente requerem reescrita significativa quando migradas entre plataformas diferentes, mas a inteligência artificial generativa inteligentemente mapeia e converte essas complexidades.
Os usuários que utilizam o Schema Conversion para converter objetos de banco de dados SAP (Sybase) ASE para Amazon RDS PostgreSQL ou Amazon Aurora PostgreSQL podem contar com automação inteligente para reduzir a quantidade de trabalho manual necessário durante o projeto de migração.
Relatórios detalhados para planejamento efetivo
Além da conversão automática, o Schema Conversion gera relatórios detalhados de avaliação. Esses relatórios são essenciais para que as equipes de TI possam planejar e executar migrações com efetividade, identificando possíveis desafios antes de iniciarem o processo de migração propriamente dito.
Os detalhes sobre a capacidade de inteligência artificial generativa estão disponíveis no User Guide, que fornece informações técnicas profundas sobre como a IA processa as conversões de código complexo.
É importante verificar a disponibilidade regional do recurso. A AWS fornece uma página com os regionais suportadas pelo AWS DMS Schema Conversion, permitindo que os usuários confirmem se o serviço está disponível em suas regiões de interesse.
A Amazon Web Services foi oficialmente designada como provedora crítica de terceiros (CTPP) pelas Autoridades Supervisoras Europeias (ESAs) sob a Regulação de Resiliência Operacional Digital (DORA) da União Europeia. Essa designação representa um marco importante na implementação da DORA, que entrou em vigor em janeiro de 2025 com o objetivo de fortalecer a resiliência operacional do setor financeiro europeu.
A regulação DORA estabelece um regime de supervisão especial para provedores de tecnologia da informação e comunicação (ICT) identificados como críticos para as operações de entidades financeiras na UE. Sob essa estrutura, empresas como a AWS ficam sujeitas à supervisão conjunta e direta de três autoridades regulatórias principais: a Autoridade Bancária Europeia (EBA), a Autoridade dos Mercados de Valores Mobiliários e Câmbios (ESMA) e a Autoridade Europeia dos Seguros e Pensões Ocupacionais (EIOPA).
Entendendo o significado prático da designação
Impacto para clientes financeiros
As instituições financeiras que utilizam serviços da AWS na União Europeia devem compreender que a plataforma agora está sujeita a uma relação de supervisão ativa com as ESAs. Essa mudança não significa perda de controle por parte dos clientes — pelo contrário, as instituições mantêm autonomia sobre seus ambientes em nuvem e sua jornada de conformidade regulatória. O que muda é que os clientes podem contar com a AWS mantendo seu compromisso com resiliência operacional como parte das atividades associadas à designação.
Os clientes financeiros têm à sua disposição diversos recursos de segurança, resiliência e conformidade da AWS, que continuam servindo como ferramentas para que as organizações mantenham controle total sobre suas operações e estratégias de conformidade.
Preparação da AWS para o processo de supervisão
A designação como CTPP é resultado de anos de engajamento da AWS com instituições europeias, autoridades competentes nacionais e a comunidade regulatória financeira mais ampla. Esse trabalho contínuo contribuiu para a construção de um sistema financeiro mais resiliente e seguro no continente.
A prontidão da AWS para este processo de supervisão é fundamentada na experiência demonstrada em atender a padrões operacionais e regulatórios rigorosos. A empresa tem realizado e continuará a realizar investimentos significativos em conformidade, gerenciamento de riscos, resiliência operacional e transparência — pilares críticos da regulação DORA.
Com a designação de CTPP, a AWS agora participará formalmente de um processo de supervisão estruturado. Esse processo deverá promover compreensão mais profunda sobre como a AWS e outras tecnologias de nuvem contribuem para melhorar a resiliência da indústria de serviços financeiros europeia.
Suporte aos clientes na implementação de DORA
Embora a AWS esteja agora sujeita à supervisão direta sob DORA, a empresa permanece igualmente focada em apoiar seus clientes de serviços financeiros que estão sujeitos à regulação. É importante notar que resiliência operacional não é apenas um requisito de conformidade — é também uma necessidade de negócios fundamental.
Os serviços da AWS foram projetados para auxiliar instituições financeiras a alcançar alta disponibilidade, durabilidade e escalabilidade, mantendo simultaneamente controles robustos e visibilidade clara sobre suas operações. Uma equipe dedicada de especialistas em segurança e conformidade está pronta para assistir organizações financeiras na compreensão de como os recursos de segurança e conformidade da AWS podem ajudá-las a cumprir suas obrigações sob DORA e de que forma os serviços da AWS apoiam suas estratégias de conformidade regulatória.
Para acessar mais informações sobre recursos de segurança e conformidade, os clientes podem consultar o Centro de Confiança da AWS. Além disso, é possível fazer download de certificações e atestações de terceiros através do AWS Artifact, ferramenta que consolida documentos de conformidade em um único local.
Perspectiva para o setor financeiro europeu
A designação da AWS como provedora crítica de terceiros reflete o papel central que os provedores de nuvem passaram a ocupar na infraestrutura tecnológica do setor financeiro europeu. À medida que instituições financeiras continuam sua jornada de transformação digital, a supervisão regulatória sobre seus principais provedores de serviços de nuvem torna-se elemento fundamental para garantir a estabilidade do sistema financeiro como um todo.
Esse cenário de supervisão mais rigorosa também representa oportunidade para demonstrar como a nuvem pode ser um fator de fortalecimento da resiliência financeira, quando implementada com os devidos controles e alinhamento regulatório.
