Author: Make.com Service User

  • Simplifique Operações de Modelo com Modelos Baseados em Amazon S3 no SageMaker AI Projects

    O desafio das operações de modelo em escala

    Gerenciar fluxos de trabalho de ModelOps (operações de modelos de machine learning) sempre foi uma tarefa complexa e demorada. Equipes que tentaram configurar templates de projeto para seus times de ciência de dados enfrentaram um cenário desafiador: a abordagem anterior exigia o uso do AWS Service Catalog, que demandava configuração de portfolios, produtos e permissões complexas—adicionando sobrecarga administrativa significativa antes do time conseguir construir seus primeiros pipelines de ML.

    Esse gargalo administrativo afastava cientistas de dados de suas atividades principais, enquanto que arquitetos e administradores gastavam horas configurando infraestrutura em vez de resolver problemas de negócio.

    O caminho simplificado: templates baseados em Amazon S3

    A AWS agora oferece uma alternativa mais direta: o Amazon SageMaker AI Projects suporta templates baseados em Amazon S3. Com essa nova capacidade, administradores podem armazenar templates AWS CloudFormation diretamente no Amazon Simple Storage Service (Amazon S3) e gerenciar todo o ciclo de vida usando recursos familiares do S3: versionamento, políticas de ciclo de vida e replicação entre regiões do S3.

    Isso significa fornecer ao time de ciência de dados templates de projeto automatizados, com controle de versão e seguros—com uma sobrecarga administrativa significativamente menor.

    O que é Amazon SageMaker AI Projects?

    O Amazon SageMaker AI Projects permite que times criem, compartilhem e gerenciem projetos de ModelOps completamente configurados. Dentro desse ambiente estruturado, você organiza código, dados e experimentos—facilitando colaboração e reprodutibilidade. Cada projeto pode incluir pipelines de integração e entrega contínua (CI/CD), registros de modelo, configurações de deployment e outros componentes de ModelOps, todos gerenciados dentro do SageMaker AI.

    Templates reutilizáveis padronizam práticas de ModelOps ao codificar as melhores práticas para processamento de dados, desenvolvimento de modelos, treinamento, deployment e monitoramento.

    Casos de uso principais

    Você pode orquestrar diversos cenários usando SageMaker AI Projects:

    • Automatizar fluxos de ML: Configure pipelines CI/CD que compilam, testam e deployam modelos automaticamente
    • Impor governança e conformidade: Garanta que seus projetos sigam padrões organizacionais para segurança, rede e marcação de recursos
    • Acelerar time-to-value: Forneça ambientes pré-configurados para que cientistas de dados se concentrem em problemas de ML, não em infraestrutura
    • Melhorar colaboração: Estabeleça estruturas de projeto consistentes para compartilhamento e reutilização de código

    Nova funcionalidade: templates de projeto em Amazon S3

    A atualização mais recente do SageMaker AI Projects permite que administradores armazenem e gerenciem templates de projeto de ML diretamente no Amazon S3. Esses templates baseados em S3 são uma alternativa menos complicada e mais flexível em relação ao Service Catalog anterior.

    Com esse aprimoramento, templates de AWS CloudFormation podem ser versionados, protegidos e compartilhados eficientemente entre times usando os controles de acesso ricos, gerenciamento de ciclo de vida e recursos de replicação fornecidos pelo S3.

    Disponibilidade regional e acesso entre contas

    Quando você armazena templates no Amazon S3, eles ficam disponíveis em todas as regiões AWS onde SageMaker AI Projects é suportado. Para compartilhar templates entre contas AWS, você pode usar políticas de bucket S3 e controles de acesso entre contas.

    Versionamento e auditoria completa

    A possibilidade de ativar versionamento no S3 fornece um histórico completo de alterações de template, facilitando auditorias e reversões, além de registrar a evolução do template do projeto de forma imutável.

    Migração do Service Catalog

    Se seus times atualmente usam templates baseados em Service Catalog, a abordagem baseada em S3 oferece um caminho de migração direto. Ao migrar, as considerações principais envolvem: provisionar novas funções SageMaker para substituir funções específicas do Service Catalog, atualizar referências de template, enviar templates para S3 com marcação adequada e configurar tags no nível do domínio apontando para o bucket de templates.

    Para organizações com repositórios de templates centralizados, você deve estabelecer políticas de bucket S3 entre contas para permitir descoberta de templates a partir de contas consumidoras, com cada domínio SageMaker de cada conta consumidora marcado para referenciar o bucket central.

    Tanto templates baseados em S3 quanto baseados em Service Catalog aparecem em abas separadas na interface de criação do SageMaker AI Projects, permitindo que organizações introduzam templates em S3 gradualmente sem interromper fluxos de trabalho existentes durante a migração.

    Requisitos técnicos para configuração

    SageMaker AI Projects com templates em S3 suporta templates CloudFormation personalizados que você cria para o seu caso de uso de ML organizacional. Os templates fornecidos pela AWS (como os templates de projeto ModelOps integrados) continuam disponíveis exclusivamente através do Service Catalog.

    Seus templates personalizados devem ser arquivos CloudFormation válidos em formato YAML.

    Para começar a usar templates baseados em S3 com SageMaker AI Projects, seu domínio SageMaker deve incluir a tag sagemaker:projectS3TemplatesLocation com o valor s3://<bucket-name>/<prefix>/.

    Cada arquivo de template enviado para S3 deve ser marcado com sagemaker:studio-visibility=true para aparecer no console SageMaker AI Studio Projects.

    Você precisará conceder acesso de leitura a funções de execução SageMaker na política de bucket S3 e ativar configuração CORS no bucket S3 para permitir ao SageMaker AI Projects acessar os templates S3.

    Como integração de templates em S3 funciona na prática

    A configuração opera em dois fluxos de trabalho separados: configuração única por administradores e lançamento de projeto por engenheiros de ML e cientistas de dados.

    Quando engenheiros de ML e cientistas de dados lançam um novo projeto de ModelOps no SageMaker AI, o SageMaker lança uma pilha (stack) AWS CloudFormation para provisionar os recursos definidos no template. Assim que o processo é concluído, você acessa todos os recursos especificados e os pipelines CI/CD configurados em seu projeto.

    Gerenciamento do ciclo de vida de projetos

    O gerenciamento do ciclo de vida de projetos lançados pode ser realizado através do console SageMaker Studio, onde usuários navegam para S3 Templates, selecionam um projeto e usam o menu Actions para atualizar ou deletar projetos.

    Atualizações de projeto podem ser usadas para modificar parâmetros de template existentes ou a própria URL do template, acionando atualizações de stack CloudFormation que são validadas antes da execução. A exclusão de projeto remove todos os recursos e configurações associadas do CloudFormation.

    Essas operações de ciclo de vida também podem ser executadas programaticamente usando as APIs do SageMaker.

    Caso de uso: template MLOps integrado com GitHub para times corporativos

    Muitas organizações usam GitHub como seu sistema principal de controle de versão e desejam usar GitHub Actions para CI/CD enquanto usam SageMaker para cargas de trabalho de ML. No entanto, configurar essa integração requer a configuração de múltiplos serviços AWS, estabelecer conexões seguras e implementar fluxos de aprovação apropriados—uma tarefa complexa que consome tempo se feita manualmente.

    Solução com template baseado em S3

    O template baseado em S3 resolve esse desafio ao provisionar um pipeline de ModelOps completo que inclui orquestração CI/CD, componentes de SageMaker Pipelines e automação acionada por eventos.

    Esse exemplo de projeto ModelOps com templates baseados em S3 habilita fluxos de trabalho de ModelOps totalmente automatizados e governados. Cada projeto de ModelOps inclui um repositório GitHub pré-configurado com fluxos de Actions e AWS CodeConnections seguras para integração perfeita.

    Após commits de código, uma pipeline SageMaker é acionada para orquestrar um processo padronizado envolvendo pré-processamento de dados, treinamento de modelo, avaliação e registro. Para deployment, o sistema suporta staging automatizado na aprovação do modelo, com verificações robustas de validação, uma porta de aprovação manual para promover modelos à produção, e uma arquitetura segura e orientada por eventos usando AWS Lambda e Amazon EventBridge.

    Governança e conformidade no fluxo

    Em todo o fluxo de trabalho, a governança é suportada pelo SageMaker Model Registry para rastreamento de versões de modelo e linhagem, etapas de aprovação bem-definidas, gerenciamento seguro de credenciais usando AWS Secrets Manager, e padrões consistentes de marcação e nomenclatura para todos os recursos.

    Quando cientistas de dados selecionam esse template no SageMaker Studio, eles provisionam um ambiente de ModelOps totalmente funcional através de um processo simplificado. Eles enviam seu código de ML para GitHub usando funcionalidade Git integrada no IDE do Studio, e o pipeline automaticamente lida com treinamento de modelo, avaliação e deployment progressivo através de staging até produção—tudo mantendo requisitos de segurança e conformidade corporativos.

    Começando com o template

    Instruções de configuração completas e código para esse template de ModelOps estão disponíveis em um repositório GitHub. Após seguir as instruções no repositório, você encontra o template mlops-github-actions na seção SageMaker AI Projects no console SageMaker AI Studio escolhendo Projects no painel de navegação e selecionando a aba Organization templates, depois clicando em Next.

    Para lançar o projeto ModelOps, você deve inserir detalhes específicos do projeto, incluindo o campo Role ARN, que deve conter o ARN da função AmazonSageMakerProjectsLaunchRole criada durante a configuração.

    Segurança com Launch Roles

    Como prática recomendada de segurança, use o Amazon Resource Name (ARN) da função AmazonSageMakerProjectsLaunchRole, não sua função de execução SageMaker. A AmazonSageMakerProjectsLaunchRole é uma função de provisionamento que atua como intermediária durante a criação de projeto ModelOps. Essa função contém todas as permissões necessárias para criar infraestrutura do seu projeto, incluindo funções AWS Identity and Access Management (IAM), buckets S3, AWS CodePipeline e outros recursos AWS.

    Ao usar essa launch role dedicada, engenheiros de ML e cientistas de dados podem criar projetos de ModelOps sem exigir permissões mais amplas em suas contas. Sua função de execução SageMaker pessoal permanece limitada em escopo—eles precisam apenas de permissão para assumir a launch role. Essa separação de responsabilidades é importante para manter segurança.

    Sem launch roles, cada profissional de ML precisaria de permissões IAM extensas para criar pipelines de código, projetos AWS CodeBuild, buckets S3 e outros recursos AWS diretamente. Com launch roles, precisam apenas de permissão para assumir uma função pré-configurada que lida com o provisionamento em seu nome, mantendo suas permissões pessoais mínimas e seguras.

    Após inserir seus detalhes desejados de configuração de projeto e clicar em Next, o template cria dois fluxos de trabalho automatizados de ModelOps—um para construção de modelo e outro para deployment de modelo—que trabalham juntos para fornecer CI/CD para seus modelos de ML. O exemplo completo de ModelOps pode ser encontrado no repositório mlops-github-actions.

    Limpeza de recursos

    Após deployment, você incorrerá em custos pelos recursos deployados. Se não tenciona continuar usando a configuração, delete os recursos do projeto ModelOps para evitar cobranças desnecessárias.

    Para destruir o projeto, abra o SageMaker Studio, clique em More no painel de navegação e selecione Projects. Escolha o projeto que deseja deletar, clique nas reticências acima do canto superior direito da lista de projetos e escolha Delete. Revise as informações na caixa de diálogo Delete project e selecione Yes, delete the project para confirmar. Após a exclusão, verifique que seu projeto não aparece mais na lista.

    Além de deletar um projeto, que remove e desprovisiona o SageMaker AI Project, você também precisa deletar manualmente os seguintes componentes se não forem mais necessários: repositórios Git, pipelines, grupos de modelo e endpoints.

    Impacto estratégico e conclusão

    O provisionamento de templates baseado em Amazon S3 para Amazon SageMaker AI Projects transforma como organizações padronizam operações de ML. Conforme demonstrado neste artigo, um único template AWS CloudFormation pode provisionar um fluxo de trabalho CI/CD completo integrando seu repositório Git (GitHub, Bitbucket ou GitLab), SageMaker Pipelines e SageMaker Model Registry—fornecendo times de ciência de dados com fluxos de trabalho automatizados enquanto mantém controles de governança e segurança corporativos.

    Para mais informações sobre SageMaker AI Projects e templates baseados em S3, consulte ModelOps Automation With SageMaker Projects.

    Ao usar templates baseados em S3 no SageMaker AI Projects, administradores podem definir e governar a infraestrutura de ML, enquanto engenheiros de ML e cientistas de dados ganham acesso a ambientes de ML pré-configurados através de provisionamento em autoatendimento. Explore o repositório de exemplos GitHub para templates populares de ModelOps e comece hoje seguindo as instruções fornecidas. Você também pode criar templates personalizados adaptados aos requisitos específicos da sua organização, políticas de segurança e frameworks de ML preferidos.

    Fonte

    Simplify ModelOps with Amazon SageMaker AI Projects using Amazon S3-based templates (https://aws.amazon.com/blogs/machine-learning/simplify-modelops-with-amazon-sagemaker-ai-projects-using-amazon-s3-based-templates/)

  • Avaliação de Modelos de IA Generativa com Amazon Nova LLM-as-a-Judge no Amazon SageMaker AI

    Além das Métricas Tradicionais

    Avaliar o desempenho de modelos de linguagem grandes vai além de simples métricas estatísticas como perplexidade ou scores BLEU (Bilingual Evaluation Understudy). Na maioria dos cenários reais de IA generativa, o que realmente importa é entender se um modelo produz resultados melhores que uma versão anterior ou uma linha de base. Isso é particularmente crítico em aplicações como sumarização, geração de conteúdo ou agentes inteligentes, onde julgamentos subjetivos e correção contextual são essenciais.

    As organizações que aprofundam a implantação desses modelos em produção enfrentam um desafio crescente: como avaliar sistematicamente a qualidade além dos métodos tradicionais? Abordagens convencionais como medidas de acurácia e avaliações baseadas em regras, embora úteis, não conseguem capturar completamente as necessidades de avaliação nuanceadas, especialmente quando as tarefas exigem julgamentos subjetivos, compreensão contextual ou alinhamento com requisitos comerciais específicos.

    A Abordagem LLM-as-a-Judge

    Para preencher essa lacuna, emergiu a abordagem conhecida como LLM-as-a-Judge (Modelo de Linguagem como Juiz), que aproveita as capacidades de raciocínio de modelos de linguagem para avaliar outros modelos de forma mais flexível e em larga escala.

    A Amazon Nova agora oferece o recurso LLM-as-a-Judge integrado ao Amazon SageMaker AI, um serviço gerenciado da Amazon Web Services (AWS) para construir, treinar e implantar modelos de aprendizado de máquina em escala. O Amazon Nova LLM-as-a-Judge foi projetado para entregar avaliações robustas e imparciais dos resultados de IA generativa em diferentes famílias de modelos.

    O recurso está disponível como workflows otimizados no SageMaker AI, permitindo começar a avaliar o desempenho de modelos contra seus casos de uso específicos em minutos. Ao contrário de muitos avaliadores que apresentam vieses arquiteturais, o Amazon Nova LLM-as-a-Judge foi rigorosamente validado para manter imparcialidade e alcançou desempenho líder em benchmarks importantes de juízes, refletindo de perto as preferências humanas.

    Treinamento e Validação do Nova LLM-as-a-Judge

    O Amazon Nova LLM-as-a-Judge foi construído através de um processo de treinamento em múltiplas etapas, combinando treinamento supervisionado e estágios de aprendizado por reforço que utilizaram datasets públicos anotados com preferências humanas.

    Para o componente proprietário, múltiplos anotadores avaliaram independentemente milhares de exemplos, comparando pares de respostas de diferentes modelos de linguagem para o mesmo prompt. Todas as anotações passaram por verificações rigorosas de qualidade, com julgamentos finais calibrados para refletir consenso amplo de humanos, em vez de um ponto de vista individual. Os dados de treinamento foram projetados para serem diversos e representativos, abrangendo categorias que incluem conhecimento do mundo real, criatividade, codificação, matemática, domínios especializados e toxicidade. Os dados incluem informações de mais de 90 idiomas, sendo principalmente compostos por inglês, russo, chinês, alemão, japonês e italiano.

    Um estudo interno de viés, avaliando mais de 10 mil julgamentos de preferência humana contra 75 modelos de terceiros, confirmou que o Amazon Nova LLM-as-a-Judge apresenta apenas 3% de viés agregado em relação às anotações humanas — um resultado significativo na redução de viés sistemático. Mesmo com esse desempenho, a AWS recomenda verificações ocasionais para validar comparações críticas.

    Gráfico de viés do Nova LLM-as-a-Judge em relação a preferências humanas
    Fonte: Aws

    O Amazon Nova LLM-as-a-Judge alcança desempenho avançado entre modelos de avaliação, demonstrando forte alinhamento com julgamentos humanos em uma gama de tarefas. Por exemplo, atinge 45% de acurácia no JudgeBench (comparado a 42% do Meta J1 8B) e 68% no PPE (versus 60% do Meta J1 8B). Esses resultados destacam a força do Amazon Nova LLM-as-a-Judge em avaliações relacionadas a chatbots.

    Fluxo de Trabalho de Avaliação

    O processo de avaliação começa preparando um dataset no qual cada exemplo inclui um prompt e duas respostas alternativas de modelos. O formato JSONL segue este padrão:

    { "prompt":"Explain photosynthesis.", "response_A":"Answer A...", "response_B":"Answer B..." }
    { "prompt":"Summarize the article.", "response_A":"Answer A...", "response_B":"Answer B..." }

    Após preparar esse dataset, utiliza-se uma receita de avaliação do SageMaker que configura a estratégia de avaliação, especifica qual modelo será usado como juiz e define as configurações de inferência, como temperatura e top_p. A avaliação é executada dentro de um job de treinamento do SageMaker usando contêineres pré-construídos do Amazon Nova. O SageMaker AI provisiona recursos de computação, orquestra a avaliação e escreve as métricas de saída e visualizações no Amazon Simple Storage Service (S3). Quando concluído, é possível baixar e analisar os resultados, que incluem distribuições de preferência, taxas de vitória e intervalos de confiança.

    Método de Avaliação Binária

    O Amazon Nova LLM-as-a-Judge utiliza um método de avaliação chamado binary overall preference judge (juiz de preferência geral binária). Esse método compara dois resultados lado a lado e escolhe o melhor ou declara um empate. Para cada exemplo, produz uma preferência clara. Quando essas avaliações são agregadas em muitas amostras, geram métricas como taxa de vitória e intervalos de confiança.

    Esta abordagem usa o raciocínio do próprio modelo para avaliar qualidades como relevância e clareza de forma direta e consistente. O modelo de juiz fornece preferências gerais de baixa latência em situações onde feedback granular não é necessário. A saída é uma de [[A>B]] ou [[B>A]].

    Interpretando as Métricas de Avaliação

    Ao usar o framework do Amazon Nova LLM-as-a-Judge para comparar resultados de dois modelos de linguagem, o SageMaker AI produz um conjunto abrangente de métricas quantitativas. Os resultados se dividem em três categorias principais: métricas de preferência central, métricas de confiança estatística e métricas de erro padrão.

    Métricas de preferência central: O a_scores conta quantos exemplos favoreceram o Modelo A, enquanto b_scores conta casos em que o Modelo B foi escolhido como melhor. O campo ties captura instâncias onde o modelo juiz classificou ambas as respostas igualmente ou não conseguiu identificar uma preferência clara. O inference_error conta casos em que o juiz não conseguiu gerar um julgamento válido.

    Métricas de confiança estatística: O winrate reporta a proporção de todas as comparações válidas em que o Modelo B foi preferido. Os campos lower_rate e upper_rate definem os limites inferior e superior do intervalo de confiança de 95% para essa taxa de vitória. Por exemplo, um winrate de 0,75 com intervalo de confiança entre 0,60 e 0,85 sugere que, mesmo contabilizando incerteza, o Modelo B é consistentemente favorecido.

    Métricas de erro padrão: Incluem a_scores_stderr, b_scores_stderr, ties_stderr, inference_error_stderr e score_stderr. Valores menores indicam resultados mais confiáveis; valores maiores podem apontar para a necessidade de dados de avaliação adicionais.

    Interpretar essas métricas requer atenção tanto às preferências observadas quanto aos intervalos de confiança: se o winrate está substancialmente acima de 0,5 e o intervalo de confiança não inclui 0,5, o Modelo B é estatisticamente favorecido. Inversamente, se o winrate está abaixo de 0,5 e o intervalo está completamente abaixo de 0,5, o Modelo A é preferido. Quando o intervalo de confiança sobrepõe 0,5, os resultados são inconclusivos.

    Implementação Prática

    Para demonstrar a implementação, a AWS oferece um notebook que guia pelo fluxo completo de trabalho. O código primeiro prepara um dataset amostrando questões do SQuAD (Stanford Question Answering Dataset) e gerando respostas candidatas. Os resultados são salvos em um arquivo JSONL contendo o prompt e ambas as respostas.

    Um estimador PyTorch lança um job de avaliação usando uma receita do Amazon Nova LLM-as-a-Judge, executando em instâncias GPU como ml.g5.12xlarge e produzindo métricas de avaliação, incluindo taxas de vitória, intervalos de confiança e contagens de preferência. Os resultados são salvos no S3 para análise.

    Uma função de visualização renderiza gráficos e tabelas, resumindo qual modelo foi preferido, quão forte foi a preferência e quão confiáveis são as estimativas. Através dessa abordagem de ponta a ponta, é possível avaliar melhorias, rastrear regressões e tomar decisões baseadas em dados sobre qual modelo generativo implantar — tudo sem anotação manual.

    Visualização dos resultados da avaliação com o Nova LLM-as-a-Judge
    Fonte: Aws

    Casos de Uso

    O framework do Amazon Nova LLM-as-a-Judge oferece uma forma confiável e repetível de comparar dois modelos de linguagem com seus próprios dados. Pode ser integrado em pipelines de seleção de modelo para decidir qual versão apresenta melhor desempenho, ou agendado como parte de uma avaliação contínua para detectar regressões ao longo do tempo. Para equipes construindo sistemas específicos de domínio ou baseados em agentes, essa abordagem fornece insights mais ricos do que métricas automatizadas isoladamente. Como todo o processo é executado em jobs de treinamento do SageMaker, escala rapidamente e produz relatórios visuais claros que podem ser compartilhados com stakeholders.

    Próximos Passos

    Para começar a jornada de avaliação de modelos de linguagem, recomenda-se explorar a documentação oficial do Amazon Nova e exemplos práticos. A comunidade AWS de IA/ML oferece recursos extensos, incluindo workshops e orientação técnica, para apoiar sua jornada de implementação.

    Fonte

    Evaluating generative AI models with Amazon Nova LLM-as-a-Judge on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/evaluating-generative-ai-models-with-amazon-nova-llm-as-a-judge-on-amazon-sagemaker-ai/)

  • Amazon Bedrock expande suporte a ferramentas customizadas no lado do servidor com a Responses API

    Novas capacidades para ferramentas customizadas no servidor

    A Amazon Bedrock anunciou a disponibilidade de suporte a ferramentas customizadas no lado do servidor por meio da Responses API (Interface de Programação de Aplicações de Respostas). Essa expansão permite que aplicações de inteligência artificial realizem ações multi-etapas em tempo real, diretamente nos servidores, sem necessidade de intermediação de clientes.

    Como funcionam as ferramentas do lado do servidor

    O Amazon Bedrock já oferecia suporte a uso de ferramentas no lado do cliente através das APIs Converse, Chat Completions e Responses. Agora, com o lançamento do suporte a ferramentas no lado do servidor para a Responses API, a AWS chama as ferramentas diretamente, sem passagem através de um cliente.

    Isso habilita suas aplicações de IA a executarem ações em tempo real e sequenciadas, como busca na web, execução de código e atualização de bancos de dados, mantendo tudo dentro dos limites organizacionais, de governança, conformidade e segurança de suas contas AWS.

    Opções de implementação

    Você tem duas alternativas para configurar ferramentas no lado do servidor:

    • Funções Lambda customizadas: Submeta sua própria função AWS Lambda para executar ferramentas personalizadas de acordo com as necessidades específicas da sua organização.
    • Ferramentas fornecidas pela AWS: Utilize ferramentas pré-construídas pela Amazon, como serviços de anotações e gerenciamento de tarefas, sem necessidade de desenvolvimento adicional.

    Disponibilidade regional e compatibilidade de modelos

    O suporte a ferramentas no lado do servidor utilizando a Responses API está disponível a partir de hoje com os modelos GPT OSS 20B e 120B da OpenAI em diversos Regiões AWS:

    • US East (N. Virginia)
    • US East (Ohio)
    • US West (Oregon)
    • Asia Pacific (Tokyo)
    • Asia Pacific (Mumbai)
    • South America (São Paulo)
    • Europe (Ireland)
    • Europe (London)
    • Europe (Milan)

    A AWS informa que suporte para regiões adicionais e outros modelos será disponibilizado em breve.

    Próximos passos

    Para começar a utilizar essa funcionalidade, acesse a documentação de ferramentas do Bedrock, onde você encontrará guias detalhados, exemplos de implementação e melhores práticas para integrar ferramentas customizadas no lado do servidor em suas aplicações de IA.

    Fonte

    Amazon Bedrock now supports server-side custom tools using the Responses API (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-server-side-custom-tools-responses-api)

  • Automação de Resposta à Segurança na AWS: Um Guia Prático para Arquitetos de Nuvem

    Por que automatizar respostas de segurança?

    A automação não é apenas para implementação de workloads. A AWS recomenda que as organizações também a utilizem para detectar e responder rapidamente a eventos de segurança dentro de seus ambientes. Quando você automatiza respostas, consegue não apenas aumentar a velocidade de detecção e resposta, mas também escalar suas operações de segurança proporcionalmente ao crescimento das suas cargas de trabalho.

    Por essa razão, a automação de segurança está incluída como princípio-chave em documentos importantes como o Well-Architected Framework, o AWS Cloud Adoption Framework, e o AWS Security Incident Response Guide. Quando você implementa automação de resposta a eventos de segurança, consegue responder a ameaças em minutos ou até segundos, algo que seria impossível para um engenheiro de plantão.

    Entendendo Automação de Resposta à Segurança

    Automação de resposta à segurança refere-se a uma ação planejada e programada que busca atingir um estado desejado para uma aplicação ou recurso, baseada em uma condição ou evento específico. Ao implementar essa automação, é recomendado adotar uma abordagem que se baseia em frameworks de segurança estabelecidos.

    A solução descrita neste guia utiliza o Framework de Cibersegurança (CSF) do NIST, que ajuda organizações a avaliar e aprimorar sua capacidade de prevenir, detectar e responder a eventos de segurança. Embora automação não seja um requisito do CSF, automatizar respostas a eventos que sabidamente não deveriam ocorrer oferece uma vantagem significativa: a automação consegue agir em segundos, enquanto processos manuais levariam muito mais tempo.

    O CSF define cinco etapas principais: identificar, proteger, detectar, responder e recuperar. Para fins deste guia, expandimos as etapas de “detectar” e “responder” para incluir atividades de automação e investigação.

    Imagem original — fonte: Aws

    As cinco etapas do CSF

    Identificar: Reconhecer e catalogar os recursos, aplicações e dados que existem em seu ambiente AWS.

    Proteger: Desenvolver e implementar controles e salvaguardas adequadas para garantir a entrega segura de serviços.

    Detectar: Implementar atividades e monitoramento para identificar quando um evento de segurança ocorre.

    Automatizar: Criar e programar ações que alcançarão um estado desejado para recursos ou aplicações, baseadas em condições ou eventos.

    Investigar: Analisar sistematicamente eventos de segurança para determinar sua causa raiz.

    Responder: Tomar ações automáticas ou manuais apropriadas em relação a eventos de segurança detectados.

    Recuperar: Manter planos de resiliência e restaurar capacidades que foram afetadas por eventos de segurança.

    Como Funciona Automação de Resposta na AWS

    A AWS oferece um conjunto de serviços que trabalham juntos para criar fluxos de automação de resposta. O AWS CloudTrail e o AWS Config registram continuamente detalhes sobre usuários, entidades de identidade, recursos com os quais interagiram e mudanças de configuração na sua conta. Quando combinados com o Amazon EventBridge, esses logs podem disparar automações baseadas em eventos, permitindo detecção automática de mudanças e reação a desvios do estado desejado.

    Um fluxo de remediação automática na AWS ocorre em três estágios:

    Monitorar: Ferramentas de monitoramento automatizado coletam informações sobre recursos e aplicações. Isso pode incluir dados do CloudTrail sobre atividades na conta, métricas de Amazon EC2, ou registros de fluxo sobre tráfego em interfaces de rede da Amazon Virtual Private Cloud (VPC).

    Detectar: Quando uma ferramenta de monitoramento detecta uma condição predefinida — como um limite excedido, atividade anômala ou desvio de configuração — um alerta é disparado. Isso pode vir de uma detecção do Amazon GuardDuty, uma violação de regra do AWS Config, ou um alto número de requisições bloqueadas em um grupo de segurança VPC.

    Responder: Quando uma condição é detectada, uma resposta automática é acionada para executar uma ação pré-definida. Exemplos incluem modificar um grupo de segurança VPC, fazer patch em uma instância EC2, rotacionar credenciais ou adicionar um endereço IP a uma lista de bloqueio.

    Definindo Suas Automações de Resposta

    Para começar, identifique requisitos de segurança em seu ambiente que você deseja implementar através de automação. Esses requisitos podem vir de melhores práticas gerais ou de frameworks de conformidade específicos para seu negócio.

    Uma abordagem prática é começar pelos run-books que você já usa em seu Lifecycle de Resposta a Incidentes. Run-books simples, como responder a uma credencial exposta (desabilitá-la e notificar a equipe), podem rapidamente ser transformados em automações. Você também pode considerar automações baseadas em recursos — por exemplo, quando uma nova VPC é criada, dispará automação para implantar a configuração padrão de coleta de flow logs.

    Seus objetivos devem ser quantitativos, não qualitativos. Por exemplo:

    • Acesso administrativo remoto a servidores deve ser limitado.
    • Volumes de armazenamento de servidores devem estar criptografados.
    • Logins no console AWS devem ser protegidos por autenticação multifator.

    Uma técnica útil é expandir esses objetivos em user stories, que descrevem de forma informal a funcionalidade desejada. Por exemplo: “Acesso administrativo remoto deve ser limitado apenas a redes internas confiáveis. Se portas de acesso remoto (SSH porta 22 e RDP porta 3389) forem detectadas e acessíveis a recursos externos, elas devem ser automaticamente fechadas e o proprietário será notificado.”

    User stories devem ser armazenadas em um local com controle de versão e devem referenciar o código de automação associado. Também é essencial considerar cuidadosamente o impacto de suas ações de remediação, pois ações como encerramento de instâncias, revogação de credenciais ou modificação de grupos de segurança podem afetar a disponibilidade de aplicações.

    Exemplo Prático: Automação para CloudTrail Desabilitado

    Para ilustrar esses conceitos, considere este cenário: detectar quando o CloudTrail é desabilitado (uma ação que atores maliciosos realizam para evitar auditoria) e reabilitá-lo automaticamente, notificando a equipe de segurança.

    A user story seria: “CloudTrail deve estar habilitado em todas as contas e regiões AWS. Se CloudTrail for desabilitado, será automaticamente reabilitado e a equipe de operações de segurança será notificada.”

    Implantando a Automação

    Para este exemplo, você usará Amazon GuardDuty e AWS Security Hub — ambos oferecem avaliação gratuita de 30 dias. Quando CloudTrail é desabilitado, GuardDuty gera uma detecção denominada Stealth:IAMUser/CloudTrailLoggingDisabled, que é coletada pelo Security Hub.

    A solução utiliza um template CloudFormation que contém uma regra do EventBridge, uma função AWS Lambda e as permissões necessárias. Quando o Security Hub detecta essa situação, publisha um evento no barramento padrão do EventBridge. A regra do EventBridge captura esse evento e invoca uma função Lambda que reabilita o CloudTrail e envia uma notificação via Amazon SNS (Serviço de Notificação Simples da Amazon).

    Testando a Automação

    Após implantar a solução, você pode testá-la criando um CloudTrail de teste, desabilitando-o propositalmente, e observando a automação reagir. Dentro de alguns segundos, o EventBridge detectará a ação, invocará a função Lambda, que reabilitará o CloudTrail automaticamente e enviará um email para o contato de segurança.

    Enquanto isso, GuardDuty realiza uma investigação mais profunda, coletando dados adicionais sobre o endereço IP que executou a ação (verificando, por exemplo, se vem de uma lista de ameaças ou de uma rede incomum). Essa informação é importada no Security Hub, onde pode ser visualizada e correlacionada com outros eventos para análise mais profunda.

    Componentes da Automação

    O exemplo incorpora dois fluxos de resposta: um em tempo quase real e outro investigativo.

    Imagem original — fonte: Aws

    Fluxo em Tempo Quase Real: O Amazon EventBridge monitora atividades indesejadas. Quando um trail do CloudTrail é parado, o CloudTrail publica um evento no barramento do EventBridge. Uma regra do EventBridge detecta esse evento e invoca uma função Lambda para reabilitá-lo e notificar o contato de segurança via SNS.

    Fluxo Investigativo: Os logs do CloudTrail são monitorados para atividades indesejadas. GuardDuty detecta quando um trail foi parado e recupera dados adicionais sobre o endereço IP que executou a ação. O Security Hub importa essa informação e a agrega com outras detecções para análise do analista. O Security Hub também publica seus achados no EventBridge, permitindo que outras ferramentas de orquestração de segurança, sistemas SIEM (Gerenciamento de Informações e Eventos de Segurança) e sistemas de ticketing recebam as informações.

    Fase de Resposta com EventBridge e Lambda

    O Amazon EventBridge é um serviço que fornece acesso em tempo real a mudanças em dados através de serviços AWS, aplicações próprias e aplicações de Software-as-a-Service (SaaS), sem necessidade de escrever código complexo. Neste exemplo, o EventBridge identifica um achado do Security Hub que requer ação e invoca uma função Lambda que realiza a remediação.

    Quando o Security Hub publica um achado no EventBridge, a informação vem em formato JSON com detalhes completos. A função Lambda extrai campos relevantes desse JSON — como o ARN (Amazon Resource Name) do trail do CloudTrail — e realiza duas ações: notifica o operador de segurança via SNS e reinicia o CloudTrail para reabilitar o logging.

    Um snippet do padrão de evento que o EventBridge procura é:

    EventPattern:
      source:
        - aws.securityhub
      detail-type:
        - "Security Hub Findings - Imported"
      detail:
        findings:
          Types:
            - "TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled"

    A função Lambda então extrai informações do achado e executa as ações de remediação. O código Python faz parsing dos campos JSON, notifica a equipe e reinicia o trail do CloudTrail usando a SDK boto3.

    Ações Customizadas e Respostas Manuais

    Se você preferir não automatizar completamente certas respostas, o Security Hub oferece ações customizadas. Uma ação customizada é um mecanismo do Security Hub para enviar achados específicos ao EventBridge, que pode então ser relacionada a uma regra do EventBridge para executar uma ação específica.

    Você pode criar até 50 ações customizadas. Isso permite, por exemplo, que um analista de segurança visualize um achado no console do Security Hub e, com um clique, dispare uma função Lambda para investigação ou remediação manual.

    Solução Pronta para Uso: Automated Security Response (ASR)

    Para muitas organizações, construir automações de remediação do zero é uma tarefa complexa. Muitos times de operações não possuem recursos ou expertise em scripting e automação. Para isso, a AWS oferece a solução Automated Security Response (ASR) on AWS, que permite que clientes do Security Hub remediassem achados com um clique, utilizando um conjunto de ações predefinidas de resposta e remediação chamadas Playbooks.

    As remediações são implementadas como documentos de automação do AWS Systems Manager. A solução inclui remediações para problemas comuns como chaves de acesso não utilizadas, grupos de segurança abertos, políticas de senha fracas em contas, configurações de VPC Flow Logging e buckets S3 públicos.

    Os Playbooks incluem remediações para controles de segurança definidos em padrões como AWS Foundational Security Best Practices, Center for Internet Security (CIS) AWS Foundations Benchmark, Payment Card Industry (PCI) Data Security Standard, e NIST Special Publication 800-53.

    Imagem original — fonte: Aws

    A solução pode ser implementada e usada sem custos adicionais, porém há custos associados aos serviços AWS que ela utiliza. A biblioteca da solução inclui instruções sobre como criar novas automações em um Playbook existente.

    Próximos Passos

    Após compreender os conceitos fundamentais de automação de resposta à segurança, você está pronto para começar a construir suas próprias automações customizadas. É recomendável aprofundar-se no AWS Security Incident Response Guide, no NIST Cybersecurity Framework e no AWS Cloud Adoption Framework Security Perspective para entender melhor como estruturar sua estratégia de resposta.

    Adicionalmente, a AWS oferece uma biblioteca de soluções com casos de uso e remediações prontas para implantação. O código utilizado neste exemplo também está disponível no GitHub.

    Conclusão

    Automação de resposta à segurança é um elemento crítico para escalar operações de segurança efetivamente. Ao combinar serviços como CloudTrail, EventBridge, GuardDuty, Security Hub e Lambda, as organizações podem criar fluxos de resposta que reagêm em segundos a eventos indesejados — algo que seria impossível com processos manuais.

    O caminho para implementação pode começar com cenários simples baseados em run-books existentes, e evoluir para automações mais complexas conforme sua organização ganha experiência. O importante é começar, testar em ambientes não-produção, e expandir gradualmente o escopo de automações conforme for ganhar confiança.

    Fonte

    How to get started with security response automation on AWS (https://aws.amazon.com/blogs/security/how-get-started-security-response-automation-aws/)

  • Amazon Cognito apresenta Lambda triggers para federação de entrada

    Novo recurso de Lambda triggers para federação no Cognito

    A AWS anunciou a introdução de Lambda triggers para federação de entrada (inbound federation) no Amazon Cognito. Este novo recurso permite transformar e personalizar atributos de usuários federados durante o processo de autenticação. Isso significa que você agora consegue modificar respostas provenientes de provedores SAML e OIDC externos antes que essas informações sejam armazenadas em seu pool de usuários.

    A grande vantagem é oferecer controle programático completo sobre o fluxo de federação sem a necessidade de fazer alterações na configuração do provedor de identidade externo.

    O que o novo recurso resolve

    O Lambda trigger para federação de entrada aborda limitações significativas que existiam em fluxos de autenticação federada. Um dos principais problemas é o limite de tamanho de atributos que o Cognito suporta: até 2.048 caracteres por atributo. Quando provedores SAML ou OIDC externos enviam atributos de grupo grandes que ultrapassam esse limite, o fluxo de autenticação pode ser bloqueado.

    Com essa nova capacidade, você consegue adicionar, sobrescrever ou suprimir valores de atributos conforme necessário. Por exemplo, é possível modificar atributos de grupo que são particularmente grandes antes de criar novos usuários federados ou atualizar perfis de usuários federados existentes no Cognito. Isso oferece flexibilidade para trabalhar com dados de provedores externos sem que eles causem problemas de compatibilidade.

    Como implementar

    O novo Lambda trigger para federação de entrada está disponível através da interface de usuário hospedada (versão clássica) e do managed login em todas as regiões da AWS onde o Amazon Cognito opera.

    Para começar a usar o recurso, você pode configurar o trigger através de diferentes ferramentas:

    • AWS Management Console
    • AWS Command Line Interface (Interface de Linha de Comando — CLI)
    • AWS Software Development Kits (Kits de Desenvolvimento de Software — SDKs)
    • Cloud Development Kit (Kit de Desenvolvimento em Nuvem — CDK)
    • AWS CloudFormation

    A configuração é feita adicionando o novo parâmetro à configuração de Lambda do seu pool de usuários (User Pool LambdaConfig).

    Para obter exemplos práticos de implementação e as melhores práticas, consulte a documentação do Amazon Cognito onde você encontrará informações detalhadas sobre como usar esse novo recurso.

    Fonte

    Amazon Cognito introduces inbound federation Lambda triggers (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-cognito-inbound-federation-lambda-trigger/)

  • Escalando operações de revisão de conteúdo com fluxos de trabalho multi-agente

    O desafio crescente da gestão de conteúdo empresarial

    Organizações enfrentam um desafio crescente ao gerenciar volumes cada vez maiores de conteúdo corporativo. Catálogos de produtos, artigos de suporte, bases de conhecimento e documentação técnica precisam permanecer precisos, relevantes e alinhados com as realidades do negócio em constante evolução. Quando esses processos dependem exclusivamente de revisão manual, o resultado é operações lentas, custosas e incapazes de acompanhar as mudanças nos requisitos empresariais.

    Pesquisa da McKinsey indica que organizações que adotam IA generativa em atividades de conhecimento, incluindo revisão de conteúdo e garantia de qualidade, conseguem aumentar a produtividade em até 30-50%, reduzindo significativamente o tempo gasto em tarefas repetitivas de verificação. Estudos do Deloitte complementam essa perspectiva, mostrando que operações de conteúdo impulsionadas por IA não apenas ganham eficiência, mas também ajudam as organizações a manter maior precisão de conteúdo e reduzir riscos operacionais.

    Uma abordagem baseada em agentes de IA

    A AWS, através do Amazon Bedrock AgentCore — uma infraestrutura propositalmente construída para implantar e operar agentes de IA em escala — combinou essa capacidade com Strands Agents, um SDK de código aberto para construir agentes de IA. Essa combinação permite que organizações automatizem fluxos de trabalho abrangentes de revisão de conteúdo.

    O enfoque baseado em agentes capacita empresas a avaliar conteúdo quanto à precisão, verificar informações contra fontes autorizadas e gerar recomendações acionáveis de melhoria. Quando agentes especializados trabalham em conjunto de forma autônoma, experts humanos conseguem concentrar-se em tarefas estratégicas de revisão enquanto o sistema de agentes de IA lida com a validação em larga escala.

    Esse padrão é aplicável a qualquer tipo de conteúdo empresarial: desde documentação de produtos e bases de conhecimento até materiais de marketing e especificações técnicas. Para ilustrar os conceitos na prática, a solução apresenta um exemplo concreto de revisão de conteúdo de blog focado em precisão técnica. Os padrões e técnicas podem ser adaptados para diferentes necessidades de revisão ajustando as configurações dos agentes, ferramentas e fontes de verificação.

    Estrutura da solução multi-agente

    A solução implementa um padrão de fluxo de trabalho multi-agente, onde três agentes de IA especializados, construídos com Strands Agents e implantados no Amazon Bedrock AgentCore, trabalham em um pipeline coordenado. Cada agente recebe a saída do agente anterior, processa-a de acordo com sua função especializada e passa informações enriquecidas para o próximo agente da sequência. Isso cria um processo de refinamento progressivo:

    • Agente scanner de conteúdo: analisa conteúdo bruto e extrai informações relevantes
    • Agente de verificação de conteúdo: valida os elementos extraídos contra fontes autorizadas
    • Agente de recomendações: transforma achados da verificação em atualizações de conteúdo acionáveis

    A manutenção de conteúdo técnico requer múltiplos agentes especializados porque varrer manualmente, verificar e atualizar documentação é ineficiente e propenso a erros. Cada agente tem um papel focado: o scanner identifica elementos sensíveis ao tempo, o verificador valida a precisão atual e o agente de recomendações elabora atualizações precisas. O design modular do sistema, com interfaces e responsabilidades claras, facilita a adição de novos agentes ou expansão de capacidades conforme a complexidade do conteúdo cresce.

    Exemplo prático: revisão de conteúdo técnico

    Para demonstrar como esse sistema de revisão baseado em agentes funciona na prática, a solução apresenta uma implementação que revisa posts técnicos de blog quanto à precisão. Empresas de tecnologia frequentemente publicam posts detalhando novos recursos, atualizações e boas práticas. Contudo, o ritmo rápido de inovação significa que alguns recursos podem ficar obsoletos ou ser atualizados, tornando desafiador manter informações atualizadas em centenas ou milhares de posts publicados.

    Embora o padrão seja demonstrado com conteúdo de blog, a arquitetura é agnóstica quanto ao tipo de conteúdo e oferece suporte a qualquer tipo configurando os agentes com prompts, ferramentas e fontes de dados apropriadas.

    Arquitetura do fluxo de trabalho

    O fluxo de trabalho inicia quando uma URL de blog é fornecida ao agente scanner de blog, que recupera o conteúdo usando a ferramenta http_request do Strands e extrai reivindicações técnicas-chave que requerem verificação. O agente de verificação então consulta o servidor MCP de documentação da AWS para buscar a documentação mais recente e validar as reivindicações técnicas contra a documentação atual. Finalmente, o agente de recomendações sintetiza os achados e gera um relatório de revisão abrangente com recomendações acionáveis para o time de blog. O código é de código aberto e hospedado no GitHub.

    Agente scanner de conteúdo: extração inteligente para detecção de obsolescência

    O agente scanner de conteúdo funciona como o ponto de entrada do fluxo de trabalho multi-agente. É responsável por identificar informações técnicas potencialmente obsoletas, especificamente direcionando elementos que tendem a se tornar desatualizados com o tempo. O agente analisa o conteúdo e produz uma saída estruturada que categoriza cada elemento técnico por tipo, localização no blog e sensibilidade temporal. Esse formato estruturado permite que o agente de verificação receba dados bem organizados que consiga processar eficientemente.

    Agente de verificação de conteúdo: validação baseada em evidências

    O agente de verificação de conteúdo recebe os elementos técnicos estruturados do agente scanner e realiza validação contra fontes autorizadas. O agente de verificação usa o servidor MCP de documentação da AWS para acessar documentação técnica atual. Para cada elemento técnico recebido do agente scanner, ele segue um processo de verificação sistemático orientado por prompts específicos que focam em critérios objetivos e mensuráveis.

    O agente verifica:

    • Informações específicas de versão: o número de versão, endpoint de API ou parâmetro de configuração mencionado ainda existe?
    • Disponibilidade de recursos: o recurso de serviço descrito ainda está disponível nas regiões ou camadas especificadas?
    • Precisão de sintaxe: exemplos de código, comandos CLI ou snippets de configuração correspondem à documentação atual?
    • Validade de pré-requisitos: os requisitos, dependências ou passos de configuração listados ainda são precisos?
    • Preços e limites: custos mencionados, cotas ou limites de serviço se alinham com informações atuais publicadas?

    Para cada elemento técnico recebido do agente scanner, o agente realiza os seguintes passos: gera consultas de busca direcionadas com base no tipo de elemento e conteúdo, consulta o servidor de documentação para informações atuais, compara a reivindicação original contra fontes autorizadas usando os critérios acima, classifica o resultado da verificação como CURRENT, PARTIALLY_OBSOLETE ou FULLY_OBSOLETE, e documenta discrepâncias específicas com evidências.

    Um exemplo de verificação em ação: quando o agente scanner identifica a reivindicação “Amazon Bedrock está disponível apenas nas regiões us-east-1 e us-west-2”, o agente de verificação gera a consulta de busca “Amazon Bedrock regiões disponíveis” e recupera a disponibilidade regional atual da documentação da AWS. Ao descobrir que Bedrock agora está disponível em 8+ regiões incluindo eu-west-1 e ap-southeast-1, ele classifica isso como PARTIALLY_OBSOLETE com a evidência: “A reivindicação original lista 2 regiões, mas a documentação atual mostra disponibilidade em us-east-1, us-west-2, eu-west-1, ap-southeast-1 e 4 regiões adicionais a partir da data de verificação.”

    A saída do agente de verificação mantém a estrutura de elemento do agente scanner enquanto adiciona esses detalhes de verificação e classificações baseadas em evidências.

    Agente de recomendações: geração de atualizações acionáveis

    O agente de recomendações representa o estágio final no fluxo de trabalho multi-agente, transformando achados de verificação em atualizações de conteúdo prontas para implementação. Esse agente recebe os resultados de verificação e gera recomendações específicas que mantêm o estilo do conteúdo original enquanto corrigem imprecisões técnicas.

    Adaptando o padrão para diferentes casos de uso

    O padrão de fluxo de trabalho multi-agente pode ser rapidamente adaptado para qualquer cenário de revisão de conteúdo sem mudanças arquiteturais. Seja revisando documentação de produtos, materiais de marketing ou documentos de conformidade regulatória, o mesmo fluxo sequencial de três agentes se aplica. Os prompts do sistema precisam ser modificados para cada agente focando em elementos específicos do domínio e potencialmente alternando ferramentas ou fontes de conhecimento.

    Por exemplo, enquanto o exemplo de revisão de blog usa uma ferramenta http_request para buscar o conteúdo do blog e o servidor MCP de documentação da AWS para verificação, um sistema de revisão de catálogo de produtos poderia usar uma ferramenta de conector de banco de dados para recuperar informações de produtos e consultar APIs de gerenciamento de inventário para verificação. Similarmente, um sistema de revisão de conformidade ajustaria o prompt do agente scanner para identificar declarações regulatórias em vez de reivindicações técnicas, conectaria o agente de verificação a bancos de dados legais em vez de documentação técnica, e configuraria o agente de recomendações para gerar relatórios prontos para auditoria em vez de atualizações de conteúdo.

    Os passos sequenciais centrais — extração, verificação e recomendação — permanecem constantes em todos esses cenários, fornecendo um padrão comprovado que escala desde blogs técnicos para qualquer tipo de conteúdo empresarial.

    Personalizando a solução

    As seguintes mudanças são recomendadas para personalizar a solução para outros tipos de conteúdo. Substitua os valores das variáveis CONTENT_SCANNER_PROMPT, CONTENT_VERIFICATION_PROMPT e RECOMMENDATION_PROMPT com suas instruções de prompt personalizadas:

    CONTENT_SCANNER_PROMPT = """<replace with your prompt instructions>"""
    CONTENT_VERIFICATION_PROMPT = """<replace with your prompt instructions>"""
    RECOMMENDATION_PROMPT = """<replace with your prompt instructions>"""

    Atualize o servidor MCP de documentação oficial para o agente de verificação de conteúdo:

    product_db_mcp_client = MCPClient(
        lambda: stdio_client(StdioServerParameters(
            command="uvx",
            args=["<replace with your official documentation MCP server>"]
        ))
    )

    Adicione ferramentas apropriadas de acesso a conteúdo como database_query_tool e cms_api_tool para o agente scanner de conteúdo quando a ferramenta http_request for insuficiente:

    scanner_agent = Agent(
        model="us.anthropic.claude-3-7-sonnet-20250219-v1:0",
        system_prompt=CONTENT_SCANNER_PROMPT,
        tools=[database_query_tool, cms_api_tool]  # Replace http_request
    )

    Essas modificações direcionadas permitem que o mesmo padrão arquitetural lide com qualquer tipo de conteúdo mantendo a estrutura de fluxo de trabalho de três agentes comprovada, garantindo confiabilidade e consistência em diferentes domínios de conteúdo sem exigir mudanças na lógica de orquestração central.

    Próximos passos e conclusão

    A solução apresentada demonstra como arquitetar um sistema de revisão de conteúdo impulsionado por agentes de IA usando o Amazon Bedrock AgentCore e Strands Agents. O padrão de fluxo de trabalho multi-agente, onde agentes especializados trabalham em conjunto para varrer conteúdo, verificar precisão técnica contra fontes autorizadas e gerar recomendações acionáveis, oferece uma abordagem escalável e modular.

    É recomendado testar o código de exemplo disponível no GitHub em sua própria conta para ganhar experiência prática com a solução. Como próximos passos, considere começar com um projeto piloto em um subconjunto do seu conteúdo, personalizar os prompts dos agentes para seu domínio específico e integrar fontes de verificação apropriadas para seu caso de uso. A natureza modular dessa arquitetura permite refinar iterativamente as capacidades de cada agente conforme você expande o sistema para lidar com as necessidades completas de revisão de conteúdo da sua organização.

    Fonte

    Scaling content review operations with multi-agent workflow (https://aws.amazon.com/blogs/machine-learning/scaling-content-review-operations-with-multi-agent-workflow/)

  • Alterar o tipo de criptografia de objetos no Amazon S3

    Nova capacidade de alteração de criptografia no S3

    A AWS anunciou um novo recurso que simplifica significativamente a gestão da criptografia de dados armazenados no Amazon S3. Agora é possível alterar o tipo de criptografia de objetos já existentes sem necessidade de movimentação de dados, uma funcionalidade particularmente valiosa para organizações que precisam atualizar suas estratégias de segurança sem causar impacto operacional.

    Como funciona o UpdateObjectEncryption API

    O novo recurso utiliza a API UpdateObjectEncryption para realizar mudanças de criptografia de forma atômica, independentemente do tamanho do objeto ou da classe de armazenamento utilizada. Isso significa que a operação ocorre de forma consistente e confiável, sem riscos de corrupção ou inconsistência de dados.

    Para cenários em larga escala, a AWS integrou essa capacidade ao S3 Batch Operations, permitindo que organizações padronizem o tipo de criptografia em buckets inteiros de objetos. Uma vantagem importante é que a operação preserva as propriedades dos objetos e mantém a elegibilidade para políticas de S3 Lifecycle, evitando reprocessamento desnecessário.

    Conformidade e requisitos regulatórios

    As organizações em diversos setores enfrentam demandas crescentes e complexas no que diz respeito à segurança e privacidade de dados. Um requisito comum nos frameworks de conformidade é a implementação de padrões de criptografia mais rigorosos para dados em repouso, muitas vezes exigindo que os dados sejam criptografados utilizando um serviço de gerenciamento de chaves dedicado.

    O novo UpdateObjectEncryption API resolve esse cenário de forma prática. Organizações que utilizam a criptografia gerenciada pela própria AWS (SSE-S3 — Criptografia no lado do servidor com chaves gerenciadas pelo S3) agora podem migrar facilmente para a criptografia no lado do servidor com chaves gerenciadas pelo AWS KMS (SSE-KMS — Criptografia no lado do servidor com AWS Key Management Service).

    Flexibilidade na gestão de chaves

    Além da migração entre tipos de criptografia, o recurso oferece flexibilidade para trocar a chave gerenciada pelo KMS utilizada na criptografia dos dados, permitindo que organizações se adequem a padrões personalizados de rotação de chaves. O recurso também possibilita habilitar S3 Bucket Keys, reduzindo o volume de solicitações ao AWS KMS e, consequentemente, otimizando custos de operação.

    Disponibilidade e como começar

    O Amazon S3 UpdateObjectEncryption API está disponível em todas as regiões AWS. Para iniciar, as organizações podem utilizar o AWS Management Console ou os SDKs AWS mais recentes para atualizar o tipo de criptografia de seus objetos. Para informações técnicas detalhadas, recomenda-se consultar a documentação técnica.

    Fonte

    Change the server-side encryption type of Amazon S3 objects (https://aws.amazon.com/about-aws/whats-new/2026/01/change-the-server-side-encryption-type-of-s3-objects)

  • Solução Inteligente de Gestão de Contratos com Amazon Quick Suite e Bedrock AgentCore

    Desafios na gestão moderna de contratos

    Organizações que gerenciam centenas de contratos anualmente enfrentam desafios operacionais significativos. Sistemas fragmentados e fluxos de trabalho complexos obrigam equipes jurídicas e de procurement a gastar horas em ciclos de revisão. Esses processos manuais não apenas consomem recursos valiosos, mas também aumentam o risco de inconsistências e erros.

    Para resolver esses problemas, a AWS apresenta uma abordagem inovadora baseada em colaboração multiagente. Agentes de IA especializados trabalham simultaneamente em diferentes aspectos da análise contratual, reduzindo ciclos de processamento enquanto mantêm precisão e supervisão adequada.

    A combinação estratégica: Quick Suite e Bedrock AgentCore

    A solução integra dois serviços principais da AWS. O Amazon Quick Suite funciona como espaço de trabalho agentico, oferecendo uma interface unificada para chat, pesquisa, inteligência de negócios e automação. Ele facilita a transição de obter respostas para tomar ações, automatizando tarefas que variam de atividades rotineiras até processos complexos como análise e processamento de contratos.

    O Amazon Bedrock AgentCore complementa essa arquitetura fornecendo capacidades avançadas de colaboração multiagente. Ao usar AgentCore com Quick Suite, as organizações conseguem encapsular lógica de negócio em agentes de IA altamente capazes, operando em escala e com segurança aprimorada. Os serviços do AgentCore funcionam com múltiplos frameworks, incluindo Strands Agents, além de modelos fundamentais disponíveis dentro ou fora do Amazon Bedrock.

    Visão geral da solução

    O sistema de gestão de contratos inteligente utiliza o Quick Suite como interface de usuário e base de conhecimento, enquanto o Bedrock AgentCore oferece funcionalidade de colaboração multiagente. Agentes especializados analisam contratos, avaliam riscos, verificam conformidade e fornecem insights estruturados através de uma arquitetura simplificada.

    Componentes da arquitetura

    A solução é construída sobre diversos componentes integrados:

    Componentes Quick Suite:

    • Spaces para organizar fluxos de trabalho de gestão de contratos
    • Agentes de chat para interações conversacionais sobre contratos
    • Bases de conhecimento para integrar documentos legais armazenados em Amazon S3
    • Topics para integrar dados estruturados de contratos
    • Actions para conectar agentes customizados desenvolvidos com Bedrock AgentCore
    • Flows para processos de revisão de documentos semicondutuais e recorrentes
    • Automate para tarefas de automação de contratos diária e mensal

    Sistema multiagente com AgentCore:

    • Agente de colaboração contratual: orquestrador central que coordena o fluxo de trabalho
    • Agente legal: analisa termos legais e extrai obrigações-chave
    • Agente de risco: avalia riscos financeiros e operacionais
    • Agente de conformidade: avalia conformidade regulatória

    Infraestrutura de suporte:

    Fluxo de trabalho de gestão de contratos

    A solução implementa um fluxo de trabalho otimizado que reduz significativamente o tempo de processamento e melhora a precisão. O sistema processa contratos através de agentes de IA coordenados, normalmente completando análise em minutos comparado a dias de revisão manual.

    Os agentes trabalham de forma coordenada em etapas bem definidas:

    • O agente de colaboração contratual identifica o documento e define quais análises (legal, risco, conformidade) são necessárias
    • O agente legal extrai informações das partes, termos de pagamento e obrigações principais
    • O agente de risco identifica exposição financeira e pontos de alavancagem para negociação
    • O agente de conformidade avalia requisitos regulatórios e sinaliza potenciais problemas
    • O agente de colaboração consolida os achados em um relatório abrangente

    Preparação e pré-requisitos

    Antes de configurar o Quick Suite, é necessário ter:

    Implementação prática: Parte 1 – Configuração do Quick Suite

    Habilitação do Quick Suite

    O administrador AWS pode habilitar Quick Suite seguindo estes passos:

    • Fazer login no AWS Management Console
    • Navegar até Quick Suite no console
    • Assinar o serviço Quick Suite para a organização
    • Configurar gerenciamento de identidade e acesso conforme necessário

    Após a habilitação, navegue até a interface web do Amazon Quick Suite e faça login com suas credenciais.

    Criação do espaço de gestão de contratos

    No Quick Suite, crie um novo espaço chamado Contract Management para organizar fluxos de trabalho e recursos relacionados a contratos. Este espaço permitirá usar o assistente para fazer consultas sobre os recursos contidos nele.

    Configuração de base de conhecimento para dados não estruturados

    Para integrar documentos contratuais armazenados em Amazon S3:

    • Navegue até Knowledge bases na seção Integrations
    • Selecione Amazon S3 como fonte de dados
    • Configure o bucket S3 que armazenará seus documentos de contrato
    • Após criar a base de conhecimento, adicione-a ao espaço Contract Management

    Configuração de base de conhecimento para dados estruturados

    Para integrar dados estruturados de contratos:

    • Na seção Datasets, configure seu data warehouse de contratos (Amazon Redshift) para dados contratuais estruturados. Siga as instruções em Criando um dataset a partir de um banco de dados e aguarde a configuração ser concluída
    • Na seção Topics, integre fontes de dados de contratos estruturados como: bancos de dados de contratos, sistemas de informação de fornecedores e sistemas de rastreamento de conformidade
    • Para adicionar topics no Quick Suite, consulte Adicionando datasets a um topic no Amazon Quick Sight
    • Adicione os topics relevantes ao seu espaço Contract Management

    Implementação prática: Parte 2 – Implantação do Bedrock AgentCore

    O Bedrock AgentCore oferece infraestrutura de nível empresarial para implantar agentes de IA com isolamento de sessão. Cada sessão executa com recursos isolados de CPU, memória e sistema de arquivos, criando separação entre sessões de usuários e ajudando a proteger processos de raciocínio stateful dos agentes.

    O código necessário está disponível em um repositório GitHub. Navegue até a pasta legal-contract-solution/deployment.

    A solução inclui um script de deploy_agents.py que automatiza completamente a implantação dos agentes de IA na AWS usando builds centrados em nuvem. As instruções requerem Python>=3.10.

    pip3 install -r requirements.txt
    python3 deploy_agents.py

    O que o script de implantação executa

    O processo de implantação é totalmente automatizado e gerencia:

    • Gerenciamento de dependências: instala automaticamente o bedrock-agentcore-starter-toolkit se necessário e verifica pacotes Python obrigatórios
    • Configuração de infraestrutura AWS: cria papéis IAM com permissões necessárias para execução de agentes, configura repositório Amazon ECR (Registro de Container) para imagens de container e configura logs de Amazon CloudWatch para monitoramento
    • Implantação de agentes: implanta quatro agentes especializados e usa AWS CodeBuild para builds de container ARM64 centrados em nuvem, sem necessidade de Docker local
    • Gerenciamento de configuração: configura automaticamente protocolos de comunicação entre agentes, estabelece limites de segurança e configura monitoramento e observabilidade

    Após implantação, os agentes podem ser visualizados no console do Amazon Bedrock AgentCore.

    Implementação prática: Parte 3 – Integração do Bedrock AgentCore com Quick Suite

    O Quick Suite pode conectar-se a soluções empresariais e agentes através de integrações de actions, tornando ferramentas disponíveis para agentes de chat e fluxos de automação.

    Implantação de API Gateway e Lambda

    Na pasta legal-contract-solution/deployment, execute:

    python3 deploy_quicksuite_integration.py

    Isto fornecerá Amazon Cognito com um user pool para permissionar acesso ao endpoint do API Gateway. A configuração do Quick Suite referencia os detalhes OAuth deste user pool.

    Após implantação bem-sucedida, dois arquivos serão gerados para integração com Quick Suite: quicksuite_integration_config.json (configuração completa) e quicksuite_openapi_schema.json (esquema OpenAPI para importar no Quick Suite).

    Configuração de integração de actions no Quick Suite

    Na seção Actions, prepare os pontos de integração que conectarão aos agentes implantados pelo AgentCore:

    • Obtenha o arquivo de especificação OpenAPI quicksuite_openapi_schema.json da pasta de trabalho
    • Na seção Integrations/Actions, acesse OpenAPI Specification
    • Crie uma nova integração OpenAPI fazendo upload do arquivo api_gateway_openapi_schema.json e insira as informações solicitadas
    • Utilize o endpoint com a URL usando informações do arquivo quicksuite_integration_config.json
    • Para os agentes, use Name: “Legal Contract Analyzer” e Description: “Analyze a legal contract using AI agents for clause extraction, risk assessment, and compliance checking”

    Definição de agente de chat

    Na seção Chat agents, configure um novo agente com os seguintes detalhes:

    • Name: Legal Contract AI Analyzer
    • Description: Um sistema alimentado por IA que analisa contratos legais e realiza avaliações abrangentes de risco usando capacidades avançadas de machine learning para identificar potenciais problemas, lacunas de conformidade e riscos contratuais
    • Agent identity: Você é um sistema especializado de análise de contratos legais alimentado por capacidades avançadas de IA generativa. Seu propósito é fornecer serviços abrangentes de revisão contratual e avaliação de risco
    • Persona instructions: Use o analisador de contratos legais quando possível. Sempre categorize riscos por severidade (Alto, Médio, Baixo). Destaque cláusulas não-padrão, provisões faltantes e potenciais problemas de conformidade. Forneça recomendações específicas para melhorias de contrato. Ao analisar cláusulas de responsabilidade, preste atenção especial a disposições de indenização, limitações de responsabilidade e provisões de força maior. Sinalize qualquer condição de rescisão incomum ou preocupações com propriedade intelectual
    • Communication style: Profissional, preciso e analítico com terminologia jurídica clara
    • Response format: Forneça análise estruturada com categorização clara de risco, níveis de severidade e recomendações acionáveis. Use bullet points para achados-chave e listas numeradas para recomendações priorizadas
    • Length: Análise abrangente cobrindo todos os aspectos críticos mantendo clareza e foco em insights acionáveis
    • Welcome message: Bem-vindo ao Legal Contract AI Analyzer. Faça upload de contratos para análise inteligente e avaliação de risco
    • Suggested prompts: “Analyze this contract for potential legal risks and compliance issues”, “Review the liability clauses in this agreement for red flags”, “Assess the termination conditions and notice requirements in this contract”

    Testando a solução de gestão de contratos

    Com a infraestrutura implantada e Quick Suite configurado, teste a solução selecionando o espaço Contract Management. Você pode usar a interface do agente para fazer perguntas sobre a base de conhecimento e instruir agentes a revisar documentos.

    Limpeza de recursos

    Há custos de infraestrutura associados à solução implantada. Quando não precisar mais dela em sua conta AWS, navegue até a pasta legal-contract-solution/deployment e execute:

    python3 cleanup.py

    Considerações finais

    A combinação de Quick Suite e Bedrock AgentCore oferece aos times de procurement e legal benefícios operacionais imediatos enquanto os posiciona para avanços futuros em IA. A colaboração multiagente da AWS permite construir e gerenciar múltiplos agentes especializados que trabalham juntos para resolver fluxos de trabalho comerciais cada vez mais complexos.

    Ao implementar essa solução de gestão de contratos inteligente, as organizações podem transformar seus processos de procurement, reduzir ciclos de contrato e permitir que seus times se concentrem em decisões estratégicas em vez de tarefas administrativas. A arquitetura extensível da solução permite começar com funções centrais de gestão de contratos e expandir gradualmente para casos de uso mais complexos conforme as necessidades da organização evoluem.

    Para começar, a AWS oferece documentação completa sobre o Amazon Quick Suite e o Amazon Bedrock AgentCore.

    Fonte

    Build an intelligent contract management solution with Amazon Quick Suite and Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-an-intelligent-contract-management-solution-with-amazon-quick-suite-and-bedrock-agentcore/)

  • AWS Network Firewall agora oferece visibilidade e controle de tráfego com IA Generativa através de filtros por categoria web

    Novo recurso de visibilidade para tráfego de IA generativa

    A AWS anunciou uma expansão significativa do AWS Network Firewall, incorporando a capacidade de identificar e controlar tráfego de aplicações que usam inteligência artificial generativa (IA generativa). O novo recurso funciona por meio de filtros baseados em categorias web, permitindo que as organizações visualizem e gerenciem o acesso a serviços de IA generativa, plataformas de mídia social, sites de streaming e outras categorias de conteúdo diretamente nas regras do firewall.

    Como funciona o controle por categorias web

    A abordagem implementada pela AWS utiliza categorias de URL pré-definidas para inspeção de tráfego. Isso significa que, em vez de necessário identificar manualmente cada domínio individual a ser bloqueado ou permitido, os administradores podem agrupar serviços por categoria e aplicar políticas de segurança de forma consolidada.

    Este modelo simplifica significativamente a governança de segurança, especialmente para equipes que lidam com conformidade regulatória. Os times de segurança e compliance conseguem estabelecer políticas consistentes em todos os ambientes AWS, ao mesmo tempo que ganham visibilidade sobre o uso de tecnologias emergentes como IA generativa.

    Casos de uso e benefícios práticos

    O novo recurso viabiliza diversos cenários operacionais:

    • Bloqueio seletivo de domínios — As organizações podem restringir acesso a domínios considerados inadequados ou de alto risco para seu contexto operacional
    • Governança de ferramentas de IA — É possível limitar o uso de ferramentas de IA generativa apenas aos serviços previamente aprovados pela empresa
    • Atendimento a requisitos regulatórios — O controle granular auxilia no cumprimento de normas e regulamentações específicas do setor
    • Redução de overhead operacional — Comparado com abordagens manuais, a administração centralizada de categorias reduz a carga administrativa

    Integração com inspeção TLS

    Quando combinado com o recurso de inspeção TLS (Transport Layer Security) do AWS Network Firewall, o novo filtro oferece controle ainda mais granular. Isso permite que os administradores inspecionem o caminho completo da URL e apliquem regras de categoria de forma mais precisa, identificando não apenas o domínio, mas o contexto específico da requisição.

    Disponibilidade e primeiros passos

    O recurso está disponível em todas as regiões comerciais da AWS onde o AWS Network Firewall é suportado. Para começar, os administradores podem atualizar seus grupos de regras com estado (stateful rule groups) através de diferentes interfaces:

    • Console de Gerenciamento da AWS
    • AWS CLI (Interface de Linha de Comando)
    • AWS SDKs (Kits de Desenvolvimento de Software)

    Para informações técnicas detalhadas e orientações de implementação, a AWS oferece documentação específica sobre filtragem por categoria de URL no produto AWS Network Firewall e na documentação técnica do serviço.

    Fonte

    AWS Network Firewall now supports GenAI traffic visibility and enforcement with Web category-based filtering (https://aws.amazon.com/about-aws/whats-new/2026/01/aws-network-firewall-web-category-based-filtering)

  • Monitoramento de Integridade de Arquivos com AWS Systems Manager e Amazon Security Lake

    Monitoramento de Integridade de Arquivos: Uma Abordagem Escalável

    As organizações enfrentam o desafio constante de rastrear mudanças em seus ambientes de nuvem. Isso inclui monitorar arquivos, softwares instalados e configurações em várias instâncias. Detectar alterações não autorizadas é crítico para a segurança, especialmente quando essas mudanças precisam ser integradas aos fluxos de trabalho existentes.

    A AWS oferece uma solução altamente escalável e serverless para esse problema. O conceito apresentado utiliza o AWS Systems Manager Inventory para coletar metadados de arquivos em instâncias Amazon EC2, envia esses dados por meio do recurso de sincronização do Systems Manager para um bucket Amazon S3 com versionamento, e implementa uma função AWS Lambda que compara versões de inventário para detectar mudanças. Quando alterações são identificadas, a função cria achados no AWS Security Hub, que são posteriormente ingeridos pelo Amazon Security Lake em formato padronizado.

    Fluxo de monitoramento de integridade de arquivos — fonte: Aws

    Vantagens desta Abordagem

    Esta solução oferece uma alternativa ao padrão de integração entre AWS Config e Security Hub, que se baseia em dados limitados sem incluir, por exemplo, timestamps de modificação de arquivos. A abordagem aqui apresentada fornece flexibilidade e controle para implementar lógica personalizada de detecção adaptada às necessidades operacionais específicas de cada organização.

    Além disso, o modelo é extensível. O AWS Systems Manager Inventory pode coletar não apenas metadados de arquivos, mas também dados sobre aplicativos instalados, configurações de rede ou entradas do Windows Registry, permitindo criar lógica de detecção customizada para uma ampla gama de casos de uso operacionais e de segurança.

    Etapas de Implementação

    Pré-requisitos

    Antes de começar, você precisará de uma conta AWS com permissões para criar e gerenciar recursos como Amazon EC2, AWS Systems Manager, Amazon S3 e Lambda.

    Etapa 1: Configuração da Instância EC2

    O primeiro passo é iniciar uma instância EC2 e criar um arquivo de configuração que será modificado posteriormente para simular uma alteração não autorizada.

    Você precisará criar um papel AWS Identity and Access Management (IAM) para permitir que a instância EC2 se comunique com o Systems Manager. No console do IAM, crie um novo papel, selecione EC2 como caso de uso e anexe a política gerenciada AmazonSSMManagedInstanceCore. Nomeie esse papel como SSMAccessRole.

    Em seguida, inicie uma instância EC2, mantendo a imagem Linux padrão e uma classe de instância como t3.micro. Nos detalhes avançados, atribua o papel SSMAccessRole que foi criado anteriormente. Para criar um arquivo de configuração de aplicativo durante a inicialização, use o script fornecido na seção User Data:

    #!/bin/bash
    mkdir -p /etc/paymentapp
    echo "db_password=initial123" > /etc/paymentapp/config.yaml

    Este script cria um diretório e um arquivo de configuração que será monitorado. Você pode deixar as demais configurações com seus valores padrão e prosseguir sem um key pair, já que o acesso será feito via Session Manager.

    Etapa 2: Ativar Security Hub e Security Lake

    Caso esses serviços já estejam ativados em sua conta, pule para a próxima etapa. Caso contrário, comece ativando o AWS Security Hub CSPM, que coleta e agrega achados de segurança e adiciona monitoramento contínuo.

    No console do Security Hub, acesse a opção CSPM e selecione ativar. Para esta demonstração, você não necessita das opções de padrões de segurança, portanto, pode desmarcá-las.

    A próxima etapa é ativar o Amazon Security Lake para começar a coletar achados do Security Hub. No console do Security Lake, selecione “Começar”, escolha ingerir fontes AWS específicas e selecione Security Hub como fonte de log e eventos. Escolha a região específica onde você está trabalhando, use a opção padrão para criar um novo papel de serviço e conclua a configuração.

    Etapa 3: Configurar Systems Manager Inventory e Sincronização com S3

    Com Security Hub e Security Lake ativados, o próximo passo é configurar o Systems Manager Inventory para coletar metadados de arquivos e exportar esses dados para S3.

    Crie um bucket S3 seguindo as orientações da documentação AWS para sincronização de dados de recursos. Após criar o bucket, ative o versionamento em suas propriedades. O versionamento garante que cada novo snapshot de inventário seja salvo como uma versão separada, permitindo rastrear mudanças ao longo do tempo.

    Em produção, recomenda-se ativar logging de acesso ao S3, forçar acesso apenas por HTTPS e ativar eventos de dados do CloudTrail para auditoria completa.

    No console do Systems Manager, acesse Fleet Manager e configure o inventário, selecionando apenas o tipo de dados “File”. Defina o caminho para a coleta limitada aos arquivos relevantes, neste caso:

    /etc/paymentapp/

    Em seguida, create a sincronização de dados de recursos no Fleet Manager, fornecendo um nome para a sincronização e o nome do bucket S3 versionado criado anteriormente.

    Etapa 4: Implementar a Função Lambda

    Para completar a solução, você precisa criar uma função Lambda que detecte mudanças quando novos dados de inventário chegarem ao S3. Cada vez que o Systems Manager escreve um novo objeto no S3, uma Amazon S3 Event Notification acionará a função Lambda, que comparará as versões mais recentes e anteriores do objeto.

    Se forem encontrados arquivos criados, modificados ou deletados, a função cria um achado de segurança em formato ASFF (AWS Security Finding Format) no Security Hub.

    Crie a função Lambda no console com o nome fim-change-detector, selecione Python como runtime e copie o código principal da função:

    import boto3, os, json, re
    from datetime import datetime, UTC
    from urllib.parse import unquote_plus
    from helpers import is_critical, load_file_metadata, is_modified, extract_instance_id
    
    s3 = boto3.client('s3')
    securityhub = boto3.client('securityhub')
    
    CRITICAL_FILE_PATTERNS = os.environ["CRITICAL_FILE_PATTERNS"].split(",")
    SEVERITY_LABEL = os.environ["SEVERITY_LABEL"]
    
    def lambda_handler(event, context):
        # Safe event handling
        if "Records" not in event or not event["Records"]:
            return
        
        # Extract S3 event
        record = event['Records'][0]
        bucket = record['s3']['bucket']['name']
        key = unquote_plus(record['s3']['object']['key'])
        current_version = record['s3']['object'].get('versionId')
        
        if not current_version:
            return
        
        # Fetching the region name
        account_id = context.invoked_function_arn.split(":")[4]
        region = boto3.session.Session().region_name
        
        # Get object versions (latest first)
        versions = s3.list_object_versions(Bucket=bucket, Prefix=key).get('Versions', [])
        versions = sorted(versions, key=lambda v: v['LastModified'], reverse=True)
        
        # Find previous version
        idx = next((i for i,v in enumerate(versions) if v["VersionId"] == current_version), None)
        if idx is None or idx + 1 >= len(versions):
            return
        
        prev_version = versions[idx+1]["VersionId"]
        
        # Load both versions
        current = load_file_metadata(bucket, key, current_version)
        previous = load_file_metadata(bucket, key, prev_version)
        
        # Compare
        created = {p for p in set(current) - set(previous) if is_critical(p)}
        deleted = {p for p in set(previous) - set(current) if is_critical(p)}
        modified = {p for p in set(current) & set(previous) if is_critical(p) and is_modified(p, current, previous)}
        
        # Report if changes were found
        if created or deleted or modified:
            instance_id = extract_instance_id(bucket, key, current_version)
            now = datetime.now(UTC).isoformat(timespec='milliseconds').replace('+00:00', 'Z')
            
            finding = {
                "SchemaVersion": "2018-10-08",
                "Id": f"fim-{instance_id}-{now}",
                "ProductArn": f"arn:aws:securityhub:{region}:{account_id}:product/{account_id}/default",
                "AwsAccountId": account_id,
                "GeneratorId": "ssm-inventory-fim",
                "CreatedAt": now,
                "UpdatedAt": now,
                "Types": ["Software and Configuration Checks/File Integrity Monitoring"],
                "Severity": {"Label": SEVERITY_LABEL},
                "Title": "File changes detected via SSM Inventory",
                "Description": (
                    f"{len(created)} created, {len(modified)} modified, "
                    f"{len(deleted)} deleted file(s) on instance {instance_id}"
                ),
                "Resources": [{"Type": "AwsEc2Instance", "Id": instance_id}]
            }
            
            securityhub.batch_import_findings(Findings=[finding])
        
        # No change – delete older S3 version
        else:
            if prev_version != current_version:
                try:
                    s3.delete_object(Bucket=bucket, Key=key, VersionId=prev_version)
                except Exception as e:
                    print(f"Delete previous S3 object version failed: {e}")

    Configurar Variáveis de Ambiente

    A função Lambda requer duas variáveis de ambiente. No console Lambda, acesse a aba Configuração e defina:

    • CRITICAL_FILE_PATTERNS: ^/etc/paymentapp/config.*$
    • SEVERITY_LABEL: MEDIUM

    Definir Permissões

    A função Lambda precisa de permissões específicas. Crie uma política inline no papel de execução da função com as seguintes permissões (substitua <bucket-name>, <region> e <account-id> pelos seus valores):

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "securityhub:BatchImportFindings",
          "Resource": "arn:aws:securityhub:::product//default"
        },
        {
          "Effect": "Allow",
          "Action": [
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:ListBucketVersions",
            "s3:DeleteObjectVersion"
          ],
          "Resource": [
            "arn:aws:s3:::",
            "arn:aws:s3:::/*"
          ]
        }
      ]
    }

    Adicionar Funções Auxiliares via Lambda Layer

    Para melhor modularidade, crie um Lambda layer contendo funções auxiliares. Abra o AWS CloudShell e execute o seguinte script:

    #!/bin/bash
    set -e
    
    FUNCTION_NAME="fim-change-detector"
    LAYER_NAME="fim-change-detector-layer"
    
    mkdir -p python
    
    cat > python/helpers.py << 'EOF'
    import json, re, os
    from dateutil.parser import parse as parse_dt
    import boto3
    
    s3 = boto3.client('s3')
    CRITICAL_FILE_PATTERNS = os.environ.get("CRITICAL_FILE_PATTERNS", "").split(",")
    
    def is_critical(path):
        return any(re.match(p.strip(), path) for p in CRITICAL_FILE_PATTERNS if p.strip())
    
    def load_file_metadata(bucket, key, version_id):
        obj = s3.get_object(Bucket=bucket, Key=key, VersionId=version_id)
        data = {}
        for line in obj['Body'].read().decode().splitlines():
            if line.strip():
                i = json.loads(line)
                n, d, m = i.get("Name","").strip(), i.get("InstalledDir","").strip(), i.get("ModificationTime","").strip()
                if n and d and m:
                    data[f"{d.rstrip('/')}/{n}"] = m
        return data
    
    def is_modified(path, current, previous):
        try:
            return parse_dt(current[path]) != parse_dt(previous[path])
        except:
            return current[path] != previous[path]
    
    def extract_instance_id(bucket, key, version_id):
        obj = s3.get_object(Bucket=bucket, Key=key, VersionId=version_id)
        for line in obj['Body'].read().decode().splitlines():
            if line.strip():
                r = json.loads(line)
                if "resourceId" in r:
                    return r["resourceId"]
        return None
    EOF
    
    zip -r helpers_layer.zip python >/dev/null
    
    LAYER_VERSION_ARN=$(aws lambda publish-layer-version \
      --layer-name "$LAYER_NAME" \
      --description "Helper functions for File Integrity Monitoring" \
      --zip-file fileb://helpers_layer.zip \
      --compatible-runtimes python3.13 \
      --query 'LayerVersionArn' \
      --output text)
    
    aws lambda update-function-configuration \
      --function-name "$FUNCTION_NAME" \
      --layers "$LAYER_VERSION_ARN" >/dev/null
    
    echo "Layer created and attached to the Lambda function."

    Etapa 5: Configurar Notificações de Eventos S3

    Configure as S3 Event Notifications para acionar a função Lambda quando novos dados de inventário chegarem. No console S3, abra o bucket de inventário, acesse propriedades e crie uma notificação de evento com o seguinte configuração:

    • No prefixo, defina AWS%3AFile/ para limitar os acionadores apenas aos objetos de inventário de arquivos
    • Selecione o tipo de evento “Put”
    • Aponte para a função Lambda recém-criada

    A coleta de inventário é executada a cada 30 minutos por padrão, mas pode ser ajustada conforme os requisitos de segurança da organização.

    Etapa 6: Testar a Detecção de Mudanças

    Com a instância EC2 em execução e o arquivo de configuração inicializado, você está pronto para simular uma alteração não autorizada.

    Use o Session Manager para conectar à instância e modificar o arquivo:

    echo "db_password=hacked456" | sudo tee /etc/paymentapp/config.yaml

    Para acelerar o teste, force uma execução imediata do inventário através do State Manager no console do Systems Manager. Após a conclusão bem-sucedida, verifique o bucket S3 e o console do Security Hub. Você deve ver um novo achado relatando a mudança detectada no arquivo.

    Análise e Visualização de Dados

    Enquanto o Security Hub oferece uma visão centralizada de achados, é possível aprofundar a análise utilizando o Amazon Athena para executar consultas SQL diretamente nos dados normalizados do Security Lake armazenados em S3, que seguem o padrão Open Cybersecurity Schema Framework (OCSF).

    Um exemplo de consulta:

    SELECT finding_info.desc AS description, class_uid AS class_id, severity AS severity_label, type_name AS finding_type, time_dt AS event_time, region, accountid
    FROM amazon_security_lake_table_us_east_1_sh_findings_2_0

    Ajuste a cláusula FROM conforme a região utilizada. O Security Lake processa os achados antes deles aparecerem no Athena, portanto, espere um pequeno atraso.

    Para exploração visual e insights em tempo real, integre o Security Lake com o Amazon OpenSearch Service e Amazon QuickSight, ambos com suporte amplo a IA generativa. Consulte a documentação para um guia detalhado sobre visualização de achados.

    Limpeza de Recursos

    Após testar a solução, remova os recursos criados para evitar custos contínuos:

    • Termine a instância EC2
    • Delete a sincronização de dados de recursos e a associação de inventário
    • Remova a função Lambda
    • Desative o Security Lake e Security Hub CSPM
    • Delete os papéis IAM criados
    • Delete os buckets S3 utilizados para sincronização de dados e Security Lake

    Considerações para Ambientes Produtivos

    Em produção, considere as seguintes práticas recomendadas para a função Lambda:

    • Configure concorrência reservada para evitar escalabilidade sem limite
    • Configure uma fila de letra morta para capturar invocações que falharam
    • Opcionalmente, anexe a função a uma Amazon VPC para isolamento de rede

    Além disso, o Security Lake suporta coleta de dados em múltiplas contas e regiões utilizando o AWS Organizations. Um Systems Manager resource data sync também pode ser configurado para enviar dados de inventário a um bucket S3 centralizado, simplificando a gestão em ambientes de múltiplas contas.

    Conclusão

    A solução apresentada demonstra como combinar o Systems Manager Inventory, Security Hub e Security Lake para criar um sistema robusto de monitoramento de integridade de arquivos. A abordagem oferece flexibilidade, controle e escalabilidade para organizações que buscam aprofundar a visibilidade sobre mudanças em seus ambientes AWS.

    O código completo da solução está disponível no AWS Samples repository. Para uma visão mais ampla sobre implementações em múltiplas contas e regiões, consulte a documentação sobre Getting Started with Amazon Security Lake and Systems Manager Inventory.

    Fonte

    File integrity monitoring with AWS Systems Manager and Amazon Security Lake (https://aws.amazon.com/blogs/security/file-integrity-monitoring-with-aws-systems-manager-and-amazon-security-lake/)