A AWS anunciou uma expansão significativa na disponibilidade do modelo Pegasus 1.2, desenvolvido pela TwelveLabs, através do Amazon Bedrock. Com a introdução de inferência global entre regiões, o modelo agora está acessível em 23 novas regiões, complementando as sete regiões onde já estava disponível anteriormente. Além disso, o Bedrock passou a oferecer acesso ao modelo em todas as regiões da União Europeia utilizando inferência geográfica entre regiões.
Diferenças nas Estratégias de Inferência
A AWS disponibiliza duas estratégias distintas de processamento para esse modelo. A inferência geográfica entre regiões é ideal para cargas de trabalho que apresentam requisitos específicos de residência de dados ou conformidade regulatória dentro de limites geográficos definidos. Por outro lado, a inferência global entre regiões é recomendada para aplicações que priorizam disponibilidade e performance em múltiplas geografias, permitindo que o processamento aconteça onde houver melhor desempenho.
Capacidades do Modelo Pegasus 1.2
O Pegasus 1.2 é um modelo de linguagem orientado para processamento de vídeos que consegue gerar texto baseado no conteúdo visual, áudio e textual dentro de vídeos. Desenvolvido especificamente para vídeos de longa duração, o modelo se destaca na geração de texto a partir de vídeos e na compreensão temporal, permitindo análises sofisticadas de conteúdo videográfico.
Benefícios da Maior Disponibilidade Regional
Com a expansão do Pegasus 1.2 para essas regiões adicionais, desenvolvedores podem construir aplicações de inteligência em vídeo mais próximas aos seus dados e usuários finais. Essa proximidade reduz a latência das requisições e simplifica a arquitetura geral das soluções, permitindo processamento mais rápido e eficiente.
Próximos Passos
Para obter a lista completa de perfis de inferência suportados e regiões disponíveis para o Pegasus 1.2, consulte a documentação de inferência entre regiões. Para começar a trabalhar com o Pegasus 1.2, acesse o console do Amazon Bedrock. Mais detalhes técnicos e informações adicionais estão disponíveis na página do produto e na documentação do Amazon Bedrock.
Proteção aprimorada contra ataques DDoS na camada de aplicação
Nos primeiros meses deste ano, a AWS implementou novas camadas de proteção para aplicações, respondendo ao crescimento de ataques de negação de serviço distribuído (DDoS) de curta duração e alto volume na camada 7 (L7). Essas proteções são oferecidas através do grupo de regras gerenciadas Anti-DDoS AMR (Regras Gerenciadas Anti-DDoS da AWS). Embora a configuração padrão seja eficaz para a maioria dos cenários, você pode personalizar a resposta para se adequar à tolerância ao risco da sua aplicação.
Neste artigo, exploraremos como o Anti-DDoS AMR funciona internamente e como você pode ajustar seu comportamento utilizando rótulos e regras adicionais do AWS WAF. Você acompanhará três cenários práticos, cada um demonstrando uma técnica diferente de personalização.
Como o Anti-DDoS AMR funciona
Detecção de anomalias e aplicação de rótulos
O Anti-DDoS AMR estabelece uma linha de base do seu tráfego e a utiliza para detectar anomalias em questão de segundos. Quando um ataque DDoS é identificado, o serviço adiciona metadados às requisições — aquilo que o AWS WAF chama de rótulos. Especificamente, todas as requisições recebem o rótulo event-detected, enquanto as requisições suspeitas de contribuir para o ataque recebem o rótulo ddos-request.
Além disso, rótulos adicionais baseados em confiança são aplicados, como high-suspicion-ddos-request, quando existe alta suspeita de que a requisição faz parte do ataque. Em termos técnicos, um rótulo é um metadado adicionado a uma requisição por uma regra quando ela é correspondida. Após ser adicionado, o rótulo fica disponível para as regras subsequentes, que podem utilizá-lo para enriquecer sua lógica de avaliação.
As mitigações padrão combinam dois tipos de ação: bloqueio direto e desafio JavaScript. O desafio funciona apenas com clientes que esperam conteúdo HTML. Por esse motivo, você precisa excluir requisições que não podem ser desafiadas — como chamadas de API — nas configurações do Anti-DDoS AMR. O serviço aplica o rótulo challengeable-request às requisições que não correspondem às exclusões configuradas.
As regras de mitigação padrão são avaliadas na seguinte sequência:
ChallengeAllDuringEvent: Equivalente à lógica: SE event-detected E challengeable-request, ENTÃO desafiar. Esta regra ativa desafios para todas as requisições elegíveis durante um evento detectado.
ChallengeDDoSRequests: Equivalente à lógica: SE (high-suspicion-ddos-request OU medium-suspicion-ddos-request OU low-suspicion-ddos-request) E challengeable-request, ENTÃO desafiar. A sensibilidade pode ser ajustada para desafiar apenas requisições de média e alta suspeita.
DDoSRequests: Equivalente à lógica: SE high-suspicion-ddos-request, ENTÃO bloquear. A sensibilidade pode ser aumentada para bloquear também requisições de média suspeita, por exemplo.
Personalizando sua resposta aos ataques DDoS
Duas abordagens de personalização
Existem dois caminhos principais para personalizar como você responde a ataques DDoS na camada 7. Na primeira abordagem, você configura o Anti-DDoS AMR para a ação desejada e, em seguida, adiciona regras subsequentes para enrijecer ainda mais sua resposta sob condições específicas. Na segunda abordagem, você converte algumas ou todas as regras do Anti-DDoS AMR para modo de contagem e cria regras adicionais que definem sua resposta personalizada.
Em ambas as abordagens, as regras subsequentes são configuradas utilizando condições que você define, combinadas com condições baseadas em rótulos aplicados pelo Anti-DDoS AMR. Para configurar regras com lógica complexa, você precisará usar o editor JSON do AWS WAF ou ferramentas de infraestrutura como código, como AWS CloudFormation ou Terraform.
Exemplo 1: Mitigação mais sensível fora de países principais
Suponha que sua operação ocorra principalmente em dois países: Emirados Árabes Unidos e Arábia Saudita. Você está satisfeito com o comportamento padrão do Anti-DDoS AMR nesses países, mas deseja bloquear mais agressivamente fora deles. Você pode implementar isso com as seguintes regras:
Anti-DDoS AMR com configurações padrão
Uma regra customizada que bloqueia se: a requisição vier de fora dos Emirados Árabes Unidos ou Arábia Saudita E a requisição tiver os rótulos high-suspicion-ddos-request ou medium-suspicion-ddos-request
Após adicionar o Anti-DDoS AMR com configuração padrão, crie uma regra customizada subsequente com a seguinte definição JSON:
De forma similar, durante um ataque, você pode mitigar de forma mais agressiva requisições de fontes incomuns, como aquelas identificadas pelo grupo de regras gerenciadas de reputação de IP como provenientes de provedores de hospedagem e nuvem.
Exemplo 2: Redução de limites de taxa durante ataques DDoS
Imaginemos que sua aplicação possui URLs sensíveis que são computacionalmente intensivas. Para proteger a disponibilidade, você aplicou uma regra de limitação de taxa configurada com um limite de 100 requisições a cada 2 minutos. Você pode enrijecer essa resposta durante um ataque DDoS aplicando um limite mais agressivo. Você pode implementar isso com:
Anti-DDoS AMR com configurações padrão
Uma regra de limitação de taxa, restrita às URLs sensíveis, configurada com limite de 100 requisições em janela de 2 minutos
Uma segunda regra de limitação de taxa, restrita às URLs sensíveis E ao rótulo event-detected, configurada com limite de 10 requisições em janela de 10 minutos
Após adicionar o Anti-DDoS AMR com configuração padrão e sua regra de limitação de taxa para URLs sensíveis, crie uma nova regra de limitação com a seguinte definição JSON:
Exemplo 3: Resposta adaptativa conforme escalabilidade da aplicação
Considere uma aplicação legada que pode escalar com segurança até um certo limite de volume de tráfego, além do qual degrada. Se o volume total de tráfego, incluindo ataque DDoS, estiver abaixo desse limite, você decide não desafiar todas as requisições durante um ataque para evitar impactar a experiência do usuário. Neste cenário, você depende apenas da ação de bloqueio padrão para requisições de alta suspeita. Porém, se o volume total exceder o limite seguro, você ativa a mitigação equivalente a ChallengeDDoSRequests.
Você pode implementar isso com:
Anti-DDoS AMR com as regras ChallengeAllDuringEvent e ChallengeDDoSRequests configuradas em modo de contagem
Uma regra de limitação de taxa que conta seu tráfego, configurada com um limite correspondente à capacidade da sua aplicação, que aplica um rótulo customizado — como CapacityExceeded — quando o limite é atingido
Uma regra que replica ChallengeDDoSRequests, mas apenas quando o rótulo CapacityExceeded está presente: desafiar se os rótulos ddos-request, CapacityExceeded e challengeable-request estão todos presentes
Primeiro, atualize seu Anti-DDoS AMR alterando as ações Challenge para Count.
Em seguida, crie a regra de detecção de capacidade excedida em modo de contagem, usando a seguinte definição JSON:
Ao combinar as proteções integradas do Anti-DDoS AMR com lógica customizada, você consegue adaptar suas defesas para corresponder ao seu perfil de risco único, padrões de tráfego e escalabilidade da aplicação. Os exemplos apresentados ilustram como você pode ajustar a sensibilidade, aplicar mitigações mais fortes sob condições específicas e até construir defesas adaptativas que respondem dinamicamente à capacidade do seu sistema.
O sistema dinâmico de rótulos no AWS WAF permite implementar essas personalizações de forma granular. Você pode também utilizar rótulos do AWS WAF para excluir o registro custoso de tráfego de ataque DDoS, otimizando sua observabilidade sem sacrificar a segurança.
Nova Camada de Armazenamento Aquecido para Kinesis Video Streams
A AWS ampliou as capacidades de armazenamento do Amazon Kinesis Video Streams com a introdução de uma nova camada de armazenamento econômica, designada como “warm tier”. Essa novidade oferece aos desenvolvedores uma opção mais eficiente em custos para manter vídeos e mídia por períodos prolongados, sem sacrificar a performance.
Entendendo as Duas Camadas de Armazenamento
Anteriormente, o Amazon Kinesis Video Streams operava com uma única camada de armazenamento, agora renomeada como “hot tier”. Essa camada permanece otimizada para acesso em tempo real e armazenamento de curta duração, mantendo todas as suas características de baixa latência.
A nova camada “warm” foi projetada especificamente para cenários que exigem retenção de longa duração de mídia. O diferencial está na manutenção de acesso em sub-segundo — mesmo com custos de armazenamento significativamente reduzidos — tornando-a ideal para aplicações que precisam preservar dados históricos sem manter infraestrutura de acesso instantâneo.
Casos de Uso Práticos
A solução beneficia especialmente dois segmentos:
Segurança residencial: Desenvolvedoras de soluções de monitoramento residencial podem agora oferecer retenção estendida de vídeo, armazenando semanas ou meses de gravações com custos operacionais reduzidos.
Monitoramento empresarial: Organizações com múltiplas câmeras de vigilância conseguem manter históricos longos para auditoria, conformidade regulatória e análise de incidentes, equilibrando retenção com custos.
Maior Flexibilidade na Configuração
Além das duas camadas de armazenamento, a AWS adicionou controle granular sobre o tamanho dos fragmentos de dados. Desenvolvedores podem agora escolher entre:
Fragmentos menores: Para casos de uso que exigem latência ultra-baixa e responsividade imediata.
Fragmentos maiores: Para reduzir custos de ingestão, ideal quando a prioridade é economia de processamento em vez de latência extrema.
Integração com Serviços de IA e Análise
Ambas as camadas (hot e warm) funcionam nativamente com os serviços de visão computacional da AWS. A integração com Amazon Rekognition Video e Amazon SageMaker permite que desenvolvedores construam pipelines contínuos de processamento de vídeo e análise, independente de qual camada de armazenamento estejam utilizando.
Disponibilidade Global
A nova camada warm do Amazon Kinesis Video Streams está disponível em todas as regiões onde o serviço já opera, com a exceção das AWS GovCloud (US) Regions.
A AWS anunciou o suporte a cinco novas versões secundárias do PostgreSQL no Amazon Aurora PostgreSQL-Compatible Edition: versões 17.6, 16.10, 15.14, 14.19 e 13.22. Essas atualizações incorporam as correções de bugs e melhorias de produtos da comunidade PostgreSQL, além de incluir aprimoramentos específicos do Aurora.
Segurança elevada com Mascaramento Dinâmico de Dados
Um dos destaques desta liberação é o Mascaramento Dinâmico de Dados (DDM — Dynamic Data Masking), disponível nas versões 16.10 e 17.6. Esse recurso de segurança em nível de banco de dados oferece proteção para dados sensíveis, como informações de identificação pessoal, ao mascarar valores de coluna dinamicamente durante a execução de consultas. O aspecto mais importante: o mascaramento ocorre em tempo de consulta, com base em políticas de função de acesso, sem alterar os dados armazenados de fato.
Outras melhorias implementadas
Além da segurança, esta versão traz aprimoramentos significativos em desempenho e confiabilidade. A introdução de um compartilhamento de plano de cache melhora a eficiência das operações. Também houve melhoria no objetivo de tempo de recuperação (RTO — Recovery Time Objective), reduzindo o tempo necessário para retomar as operações após uma falha. Para ambientes multi-região, a troca de banco de dados global (Global Database switchovers) agora funciona de forma otimizada.
Como começar com as novas versões
Para utilizar as versões mais recentes, você pode criar um novo banco de dados Aurora PostgreSQL-compatible diretamente pelo Console de Gerenciamento do Amazon RDS em poucos cliques. Caso já possua um banco de dados existente, também é possível fazer uma atualização. A AWS recomenda consultar a documentação do Aurora para compreender melhor o processo de upgrade.
Planejamento de atualizações
Para decidir com qual frequência atualizar e como planejar seu processo de upgrade, consulte a política de versão do Aurora. Esse documento fornece orientações sobre ciclos de suporte e estratégias de migração.
Disponibilidade global
Essas novas versões estão disponíveis em todas as regiões comerciais da AWS, assim como nas regiões do AWS GovCloud (US).
Sobre o Amazon Aurora
O Amazon Aurora é projetado para oferecer desempenho e disponibilidade sem precedentes em escala global, com compatibilidade completa com MySQL e PostgreSQL. A plataforma oferece segurança integrada, backups contínuos, computação serverless, até 15 réplicas de leitura, replicação automatizada entre regiões e integração com outros serviços da AWS. Para dar seus primeiros passos, consulte a página de primeiros passos.
O desafio da infraestrutura de chaves públicas em escala
A Infraestrutura de Chaves Públicas (PKI) é fundamental para garantir a segurança e estabelecer confiança nas comunicações digitais. À medida que as organizações expandem suas operações digitais, precisam emitir e revogar certificados continuamente. A revogação de certificados é especialmente importante quando funcionários se desligam, durante migrações para novas hierarquias de autoridades certificadoras, para atender requisitos de conformidade ou em resposta a incidentes de segurança.
Porém, empresas que enfrentam crescimento significativo encontram limitações ao usar CRLs completas para emitir e revogar mais de 1 milhão de certificados. Simplesmente aumentar o tamanho do arquivo CRL não é uma solução viável, pois muitas aplicações não conseguem processar arquivos CRL grandes — algumas exigem um máximo de 1 MB. Além disso, soluções alternativas como OCSP podem ser rejeitadas por grandes repositórios de confiança e fornecedores de navegadores devido a preocupações com privacidade e requisitos de conformidade. Essas restrições impactam significativamente a capacidade das organizações de escalar sua infraestrutura de PKI de forma eficiente, mantendo segurança e conformidade.
A solução: CRLs particionadas
A AWS Private CA agora oferece CRLs particionadas como resposta a esses desafios. Essa funcionalidade permite a emissão e revogação de até 100 milhões de certificados por CA, distribuindo as informações de revogação em múltiplas partições de CRL menores e gerenciáveis, cada uma mantendo um tamanho máximo de 1 MB para melhor compatibilidade com aplicações.
No momento da emissão, os certificados são automaticamente vinculados a partições CRL específicas através de uma extensão crítica de Ponto de Distribuição do Emissor (IDP), que contém uma URI única identificando a partição. A validação funciona comparando a URI de CRL na extensão de Ponto de Distribuição de CRL (CDP) do certificado contra a extensão IDP da CRL, proporcionando validação precisa.
Capacidades principais da nova funcionalidade
As CRLs particionadas oferecem diversos benefícios operacionais:
Escalabilidade automática do limite de emissão de certificados: de 1 milhão para 100 milhões de certificados por CA
Suporte tanto para novas quanto para autoridades certificadoras existentes
Opções de configuração flexível para nomes e caminhos de CRL
Compatibilidade reversa, preservando a funcionalidade completa de CRL existente enquanto oferece CRL particionada como recurso opcional
Conformidade com padrões da indústria, como o RFC5280, mantendo eficiência operacional e segurança
Configurando CRLs particionadas na AWS Private CA
A configuração de CRLs particionadas em autoridades certificadoras existentes segue um processo estruturado através do console da AWS:
Passos de configuração
Para ativar CRLs particionadas, acesse sua autoridade certificadora privada no console da AWS Private CA. Primeiro, selecione a CA desejada e navegue até a aba de configuração de revogação. Se a distribuição de CRL estiver desabilitada, você precisará ativá-la nos próximos passos.
Ao editar as configurações, marque a opção para ativar distribuição de CRL e selecione um bucket do Amazon S3 existente para armazenar os arquivos de CRL. É importante verificar que o recurso de Bloqueio de Acesso Público está desabilitado para sua conta e para o bucket. Se necessário, você pode consultar a documentação sobre criar uma CA privada na AWS Private CA para obter instruções detalhadas sobre políticas de acesso. Para configurações de segurança mais específicas, consulte o guia sobre políticas de acesso para CRLs no Amazon S3 e aprenda como adicionar uma política de bucket usando o console do Amazon S3.
Na seção de configurações de CRL, marque a caixa para ativar o particionamento. Isso habilitará o uso de CRL particionada. Se você não ativar o particionamento, uma CRL completa será criada e sua CA ficará sujeita ao limite de 1 milhão de certificados emitidos ou revogados. Para informações sobre limites de capacidade, consulte as cotas da AWS Private CA.
Após salvar as alterações, a distribuição de CRL aparecerá como habilitada com CRLs particionadas, e o limite de 1 milhão será automaticamente atualizado para 100 milhões por CA.
Benefícios para segurança, operações e conformidade
As CRLs particionadas da AWS Private CA oferecem benefícios substanciais em múltiplas dimensões organizacionais.
Perspectiva de segurança
A funcionalidade mantém a validação de certificados enquanto suporta capacidades abrangentes de revogação para até 100 milhões de certificados por CA. Isso permite que as organizações respondam efetivamente a incidentes de segurança ou comprometimento de chaves.
Perspectiva operacional
Operacionalmente, o recurso reduz a necessidade de rotação de autoridades certificadoras, diminuindo a sobrecarga administrativa e simplificando o gerenciamento de PKI. Manter os tamanhos de partição de CRL em 1 MB oferece compatibilidade ampla com aplicações, enquanto suporta gerenciamento automático de partições.
Perspectiva de conformidade
Para conformidade regulatória, a solução permite que as organizações atendam a múltiplos requisitos da indústria:
Alinhamento com requisitos de repositórios de confiança de navegadores para suporte tanto a CRL quanto a OCSP
Flexibilidade para padrões emergentes, como Matter
Custo e disponibilidade
Um ponto importante é que você pode maximizar o valor de suas autoridades certificadoras de propósito geral ou vida curta ativando CRL particionada sem custos adicionais, além da AWS Private CA e do Amazon Simple Storage Service (Amazon S3). Todos os certificados continuam sendo revogáveis, proporcionando uma solução completa e econômica para gestão de PKI em escala.
Próximos passos
Organizações interessadas em começar podem criar sua autoridade certificadora através do console de gerenciamento da AWS Private CA. A nova funcionalidade está disponível para configuração imediata em autoridades certificadoras existentes ou novas.
A AWS anunciou um novo provedor para o Secrets Store CSI Driver destinado ao Amazon EKS (Elastic Kubernetes Service), que funciona como um add-on gerenciado para a plataforma. Esse novo componente permite que as equipes de desenvolvimento recuperem secrets do AWS Secrets Manager e parâmetros do AWS Systems Manager Parameter Store, montando-os como arquivos nos pods do Kubernetes. A solução é clara em sua proposta: oferecer uma forma segura, confiável e gerenciada de acessar credenciais dentro de ambientes containerizados.
O novo add-on simplifica significativamente o processo de instalação e configuração, funciona tanto em instâncias de Amazon Elastic Compute Cloud (EC2) quanto em nós híbridos, e é mantido com as correções de segurança e atualizações mais recentes. Para equipes brasileiras que trabalham com Kubernetes em ambientes AWS, isso representa uma redução considerável no tempo necessário para implementar práticas seguras de gestão de credenciais.
Por que isso importa para a segurança
Historicamente, um dos maiores desafios em ambientes Kubernetes é evitar o uso de credenciais hardcoded no código-fonte das aplicações. O Secrets Manager já resolve essa questão no contexto geral da AWS, mas integrá-lo nativamente com Kubernetes exigia passos complexos de instalação e manutenção.
O novo provedor funciona como um DaemonSet do Kubernetes de código aberto, trabalhando em conjunto com o Secrets Store CSI Driver mantido pela comunidade Kubernetes. Essa arquitetura permite que o driver de armazenamento de secrets funcione de forma nativa no cluster, sem necessidade de integração customizada.
Benefícios do add-on gerenciado
Os add-ons do EKS da AWS proporcionam instalação e gerenciamento de um conjunto curado de componentes para clusters EKS. Em vez de depender de métodos legados como Helm ou kubectl, o novo add-on reduz significativamente o tempo de setup e aumenta a estabilidade geral dos clusters. Além disso, o gerenciamento centralizado pela AWS garante que patches de segurança e correções de bugs sejam aplicados de forma automática e consistente.
Considerações de segurança
Como em qualquer solução que envolve gestão de credenciais, a segurança é uma preocupação central. A AWS recomenda armazenar secrets em cache na memória quando possível, reduzindo a frequência de acesso ao Secrets Manager. Para equipes que preferem uma experiência totalmente nativa do Kubernetes, o AWS Secrets Manager Agent oferece uma alternativa complementar.
Do ponto de vista de controle de acesso, qualquer entidade IAM (Identity and Access Management) que precise acessar os secrets deve ter permissões explícitas no Secrets Manager. Se usar Parameter Store, também precisa de permissões específicas para ler parâmetros. As políticas de recurso funcionam como mecanismo adicional de controle de acesso, e é especialmente importante quando se acessa secrets de contas AWS diferentes.
O add-on inclui suporte a endpoints FIPS, alinhando-se com exigências de conformidade em ambientes altamente regulados. A AWS fornece uma política IAM gerenciada chamada AWSSecretsManagerClientReadOnlyAccess, que é a recomendação padrão para uso com esse add-on. Para implementar o princípio do menor privilégio, é possível criar políticas customizadas direcionadas apenas aos secrets específicos que cada aplicação precisa acessar.
Guia prático de implementação
Para equipes que desejam começar, a AWS disponibiliza um fluxo de trabalho completo desde a criação do cluster até a recuperação efetiva de um secret. Abaixo, apresentamos um resumo dos passos principais.
Pré-requisitos
Antes de iniciar, certifique-se de ter:
Credenciais AWS configuradas no seu ambiente para permitir chamadas à API
Um arquivo de deployment Kubernetes disponível no repositório do provedor
Criando o cluster EKS
Comece criando uma variável de shell com o nome do seu cluster:
CLUSTER_NAME="my-test-cluster"
Depois, crie o cluster:
eksctl create cluster $CLUSTER_NAME
O eksctl usará automaticamente uma versão recente do Kubernetes e criará todos os recursos necessários para o funcionamento do cluster. Esse comando geralmente leva cerca de 15 minutos.
Criando um secret de teste
Crie um secret chamado addon_secret no Secrets Manager:
A SecretProviderClass é um arquivo YAML que define quais secrets e parâmetros devem ser montados como arquivos no seu cluster. Crie um arquivo chamado spc.yaml com o seguinte conteúdo:
Embora o add-on gerenciado seja a forma recomendada, a AWS também oferece opções alternativas de instalação usando AWS CloudFormation, AWS Command Line Interface (AWS CLI), console de gerenciamento ou a própria API do EKS.
Conclusão
O novo add-on do Secrets Store CSI Driver para EKS representa um avanço significativo na forma como as equipes podem gerenciar credenciais em ambientes Kubernetes hospedados na AWS. Ao oferecer instalação simplificada, gerenciamento centralizado, atualizações de segurança automáticas e integração estreita com o EKS, a solução reduz tanto a complexidade operacional quanto o risco de segurança associado ao armazenamento inadequado de secrets.
Para organizações brasileiras que trabalham com Kubernetes em escala, esse add-on se posiciona como uma alternativa muito mais prática do que métodos legados de instalação, mantendo a flexibilidade e a conformidade com padrões de segurança internacionais. A documentação técnica completa está disponível para equipes que desejam explorar cenários mais avançados e configurações específicas.
As empresas estão adotando agentes de IA em ritmo acelerado para automatizar fluxos de trabalho e aumentar produtividade. No entanto, esse crescimento traz um problema crítico de segurança: como garantir que centenas de agentes autônomos acessem apenas as ferramentas que lhes são permitidas quando milhares de ferramentas estão distribuídas entre diferentes times e unidades de negócio?
Diferentemente de arquiteturas tradicionais com alguns agentes chamando poucas APIs, as plataformas de IA modernas envolvem cenários muito mais complexos. Uma organização pode ter centenas de agentes, aplicações de IA para consumidores e fluxos de trabalho automatizados precisando acessar milhares de ferramentas através do Protocolo de Contexto de Modelo (MCP). Cada acesso precisa ser validado não apenas pela identidade do agente, mas também pela identidade do usuário, contexto de execução, canal de acesso e permissões que podem mudar dinamicamente.
Apresentando os Interceptadores do Gateway AgentCore
Para resolver esses desafios de segurança e governança em escala, a AWS lançou um novo recurso: interceptadores de gateway para o Amazon Bedrock AgentCore Gateway. Trata-se de uma capacidade poderosa que fornece segurança refinada, controle de acesso dinâmico e gerenciamento flexível de esquemas.
Os interceptadores funcionam como pontos programáveis onde você pode injetar lógica de segurança personalizada, permitindo transformar requisições e respostas sem modificar as ferramentas subjacentes ou os servidores MCP.
Dois Pontos de Interceptação
O gateway oferece interceptação em dois momentos críticos do ciclo de requisição-resposta:
Interceptador de requisição do gateway: Processa requisições recebidas antes de atingirem as ferramentas alvo, permitindo controle de acesso refinado, validação de credenciais, criação de trilhas de auditoria e tradução de esquemas.
Interceptador de resposta do gateway: Processa respostas de saída antes de retornarem ao agente chamador, possibilitando filtragem de ferramentas, criação de trilhas de auditoria e tradução de esquemas com base em permissões do usuário.
Organizações já implantam milhares de ferramentas MCP através de um gateway unificado. O desafio é garantir que cada principal chamador — seja um agente, usuário ou aplicação — acesse apenas as ferramentas autorizadas, baseando-se em múltiplos fatores dinâmicos como identidade do agente, identidade do usuário e contexto de execução.
Os interceptadores de requisição garantem que a chamada de uma ferramenta seja bloqueada se o usuário não tiver permissão específica. Isso é feito através da extração e validação do token JWT (Token Web JSON), verificação do escopo do usuário e bloqueio de invocações não autorizadas com um erro MCP estruturado — tudo antes que a ferramenta seja executada.
Filtragem Dinâmica de Ferramentas
Agentes descobrem ferramentas disponíveis através de buscas semânticas e operações padrão de listagem. Sem controles apropriados, os servidores MCP retornariam a lista completa de ferramentas independentemente do nível de autorização do agente ou usuário, criando vulnerabilidades de segurança.
Os interceptadores de resposta resolvem isso filtrando a lista de ferramentas antes que retorne ao agente. Para cada ferramenta na lista, o interceptador avalia se o usuário tem autorização com base nos escopos do JWT, removendo as ferramentas não autorizadas antes de enviar a resposta.
Empresas enfrentam desafios complexos ao gerenciar contratos entre agentes de IA e APIs downstream. É necessário mapear dinamicamente esquemas de requisição MCP para esquemas de API correspondentes, possibilitando proteção crítica de dados como redação ou remoção de informações pessoalmente identificáveis (PII) que usuários possam enviar em prompts.
O desacoplamento entre o esquema MCP e as implementações downstream permite que times de backend modifiquem suas APIs, alterem nomes de campos, reestruturem payloads ou atualizem requisitos de autenticação sem quebrar contratos de agentes ou forçando retreinamento de modelos.
Propagação de Headers Customizados e Gerenciamento de Contexto de Identidade
Quando agentes interagem com múltiplos serviços downstream, manter a identidade do usuário através de limites de serviços torna-se crítico para segurança, conformidade e trilhas de auditoria. Os interceptadores de requisição extraem informações de identidade dos headers de requisição recebida, transformam-nas no formato esperado pelos serviços downstream e enriquecem requisições antes que alcancem os serviços alvo.
Abordagens de Autorização: Representação versus Agindo em Nome de
Uma decisão fundamental em como a identidade flui através de fluxos de trabalho multi-hop é escolher entre representação (impersonation) ou agindo em nome de (act-on-behalf).
Abordagem de Representação (Não Recomendada)
Na representação, o token JWT original do usuário é passado inalterado por cada etapa da cadeia de chamadas. Embora mais simples de implementar, cria riscos de segurança significativos:
Serviços downstream recebem tokens com privilégios mais amplos do que necessário
Risco aumentado de escalação de privilégio se qualquer componente for comprometido
Escopo do token não pode ser limitado a alvos downstream específicos
Vulnerável a ataques de deputy confuso, onde serviços comprometidos abusam tokens excessivamente privilegiados
Abordagem Agindo em Nome de (Recomendada)
Na abordagem agindo em nome de, cada etapa do fluxo de trabalho recebe um token separado e limitado especificamente emitido para aquele alvo downstream, enquanto JWT é usado para propagar contexto de execução. Isso implementa o princípio do menor privilégio e oferece benefícios significativos:
Cada serviço recebe apenas as permissões necessárias para acessar APIs específicas downstream
Raio de explosão reduzido — tokens comprometidos têm escopo limitado e não podem ser reutilizados
Auditoria melhorada — cadeia clara de custódia mostrando qual serviço agiu em nome do usuário
Prevenção de deputy confuso — tokens de escopo limitado impedem serviços de serem enganados
O controle de acesso refinado usa valores de escopo JWT emitidos pelo Amazon Cognito ou outro provedor OAuth 2. A convenção segue um padrão simples: usuários recebem acesso completo a um alvo MCP (por exemplo, mcp-target-123) ou acesso em nível de ferramenta (por exemplo, mcp-target-123:getOrder).
O interceptador de requisição valida permissões em tempo de execução através de etapas simples:
Extrai e decodifica o JWT para recuperar a solicitação de escopo
Identifica qual ferramenta está sendo invocada
Bloqueia a requisição se o usuário não tiver acesso completo ao alvo ou permissão específica da ferramenta
Retorna um erro MCP estruturado para invocações não autorizadas
Este modelo é facilmente extensível com claims adicionais (como tenantId e workspaceId) para arquiteturas multi-tenant.
Modelos de Autorização Flexível: Sem Autenticação e OAuth
Muitas empresas necessitam de modelos de autorização flexíveis que equilibrem descoberta com segurança. Um cenário comum é permitir que agentes e aplicações descubram e busquem ferramentas MCP disponíveis sem autenticação, facilitando exploração perfeita do catálogo de ferramentas. Porém, ao invocar ferramentas, é necessária autorização OAuth rigorosa.
O gateway agora suporta isso através de um tipo de autorização “Sem Autenticação” (No Auth) em nível de gateway para todas as chamadas recebidas. Quando configurado, torna todos os alvo e ferramentas acessíveis sem autenticação para fins de descoberta.
Para aplicar autorização OAuth em nível de método (ListTools versus CallTools) ou implementar políticas de autorização por ferramenta, você usa interceptadores de gateway para examinar o JWT recebido, validá-lo contra requisitos de RFC 6749 usando a URL de descoberta do servidor de autorização, e programaticamente permitir ou negar acesso a métodos ou chamadas de ferramentas específicas.
A observabilidade abrangente fornecida pelo AgentCore Observability é crítica para monitorar, depurar e auditar fluxos de trabalho de agentes de IA. Os interceptadores de gateway aplicam autorização, transformam requisições e filtram dados antes que serviços downstream executem, tornando a camada de observabilidade um limite crítico de segurança.
Os interceptadores integram-se automaticamente com AgentCore Observability, fornecendo:
Monitoramento em tempo real de decisões de autorização
Identificação de gargalos de desempenho através de métricas de duração e invocação
Rastreabilidade ponta a ponta através de fluxos de trabalho de agentes multi-hop
Atributos de identidade e contexto para validar comportamento de autorização em ambientes multi-tenant
O AgentCore Gateway transforma APIs e funções AWS Lambda existentes em ferramentas compatíveis com agentes, conecta-se a servidores MCP existentes e fornece integração perfeita com ferramentas e serviços de negócio essenciais de terceiros como Jira, Asana e Zendesk. Este ponto de acesso unificado habilita integração segura entre sistemas corporativos.
Com o lançamento dos interceptadores de gateway, as organizações podem implementar controle de acesso refinado e gerenciamento de credenciais através de funções Lambda customizadas nos dois pontos críticos do ciclo de requisição-resposta.
Conclusão
Os interceptadores de gateway do AgentCore resolvem os desafios fundamentais de segurança que organizações enfrentam ao implantar sistemas de IA em escala. Fornecendo pontos de interceptação programáveis para requisições e respostas, as organizações implementam controle de acesso refinado sem modificar implementações de ferramentas subjacentes ou arquiteturas de servidores MCP.
À medida que organizações escalam para centenas de agentes e milhares de ferramentas, os interceptadores de gateway oferecem a flexibilidade e controle necessários para manter segurança, conformidade e visibilidade operacional através de implantações complexas de IA, alinhando-se com padrões de integração empresarial e práticas recomendadas de segurança.
A AWS anunciou uma importante expansão do Block Public Access (Bloqueio de Acesso Público) para o Amazon S3. O serviço agora permite gerenciamento centralizado através do AWS Organizations, possibilitando que organizações padronizem e enforcem configurações de acesso público em todos os accounts de sua estrutura por meio de uma única configuração de política.
Como funciona o Block Public Access em nível organizacional
Propagação automática de políticas
O Block Public Access em nível organizacional opera através de uma configuração única que controla todas as definições de acesso público em todos os accounts dentro da organização. Quando você anexa a política no root ou em uma Unidade Organizacional (OU, do inglês Organizational Unit) da sua organização, ela se propaga automaticamente para todos os sub-accounts dentro desse escopo. Contas-membro novas herdam a política de forma automática, eliminando a necessidade de configuração manual individual.
Flexibilidade de aplicação
Além da abordagem centralizada, você também tem a opção de aplicar a política a accounts específicos quando precisa de um controle mais granular. Essa flexibilidade permite que organizações balanceiem a uniformidade de segurança com necessidades específicas de diferentes times ou departamentos.
Como começar
Configuração através do console
Para iniciar, acesse o console do AWS Organizations e utilize o checkbox “Bloquear todo acesso público” ou use o editor JSON para configurações mais avançadas. A interface permite que você customize exatamente quais tipos de acesso público devem ser bloqueados em toda a sua organização.
Monitoramento e auditoria
A AWS CloudTrail pode ser utilizada para auditar e acompanhar a anexação de políticas, bem como monitorar o enforcement da política em todas as contas-membro. Isso oferece visibilidade completa sobre como as configurações de segurança estão sendo aplicadas e mantidas em toda a organização.
Disponibilidade e acesso
Esse recurso está disponível no console do AWS Organizations, bem como através da AWS CLI (Interface de Linha de Comando, do inglês Command Line Interface) e SDKs (Kits de Desenvolvimento de Software, do inglês Software Development Kits), em todas as regiões AWS onde AWS Organizations e Amazon S3 são suportados. Importante destacar que não há custos adicionais para usar esse recurso.
Controle granular sobre o agendamento de cargas de trabalho
A AWS anunciou um novo recurso no Amazon SageMaker HyperPod que oferece suporte a labels (etiquetas) e taints (repugnâncias) personalizados do Kubernetes. Essa funcionalidade permite aos clientes exercer controle preciso sobre o posicionamento de pods e garantir integração tranquila com infraestruturas Kubernetes já existentes.
Para equipes que implantam cargas de trabalho de inteligência artificial em clusters HyperPod orquestrados com EKS (Elastic Kubernetes Service), esse é um recurso particularmente valioso. A capacidade de controlar exatamente onde cada pod é executado ajuda a evitar que recursos caros, como GPUs, sejam consumidos por pods de sistema ou cargas de trabalho não relacionadas a inteligência artificial, enquanto mantém compatibilidade com plugins de dispositivo personalizados, como o EFA (Elastic Fabric Adapter) e operadores NVIDIA GPU.
Eliminando a sobrecarga operacional
O desafio anterior
Antes deste anúncio, clientes precisavam aplicar manualmente labels e taints usando kubectl, tendo que reaplicá-los após cada substituição de nó, operação de escalonamento ou patch do sistema. Esse processo manual gerava sobrecarga operacional significativa e aumentava o risco de inconsistências.
A solução implementada
O novo recurso permite configurar labels e taints no nível do grupo de instâncias através das APIs CreateCluster e UpdateCluster, oferecendo uma abordagem gerenciada para definir e manter políticas de agendamento ao longo de todo o ciclo de vida dos nós.
Capacidades técnicas
Utilizando o novo parâmetro KubernetesConfig, é possível especificar até 50 labels e 50 taints por grupo de instâncias. As labels habilitam organização de recursos e direcionamento de pods através de seletores de nó, enquanto taints repelem pods que não possuem tolerâncias correspondentes, protegendo nós especializados.
Casos de uso práticos
Um exemplo concreto é aplicar taints do tipo NoSchedule em grupos de instâncias com GPUs, garantindo que apenas trabalhos de treinamento de inteligência artificial com tolerâncias explícitas consumam esses recursos de alto custo. Outra aplicação é adicionar labels personalizados que permitam aos pods de plugins de dispositivo agendar corretamente no ambiente.
Operação simplificada
O HyperPod aplica automaticamente essas configurações durante a criação de nós e as mantém durante substituição, escalonamento e operações de patch. Isso elimina a necessidade de intervenção manual e reduz significativamente a sobrecarga operacional que as equipes enfrentavam anteriormente.
O recurso está disponível em todas as regiões da AWS onde o Amazon SageMaker HyperPod é oferecido. Para aprofundar seus conhecimentos sobre labels e taints personalizados, consulte a documentação técnica completa.
Transição do Amazon Lookout for Vision para SageMaker
Em outubro de 2024, a AWS anunciou a descontinuação do Amazon Lookout for Vision, com previsão de encerramento em 31 de outubro de 2025. Como parte de sua estratégia de transição, a empresa recomenda que clientes interessados em soluções de inteligência artificial e aprendizado de máquina para visão computacional utilizem as ferramentas do Amazon SageMaker AI.
A boa notícia é que a AWS disponibilizou no AWS Marketplace os modelos subjacentes que alimentavam o serviço descontinuado. Esses modelos podem ser ajustados usando o Amazon SageMaker para casos de uso específicos, oferecendo flexibilidade total de integração com infraestruturas existentes de hardware e software. Quando executados na nuvem, os custos envolvem apenas a infraestrutura necessária para treinamento ou inferência.
Fluxo end-to-end: da aquisição de imagens até a inferência em dispositivos edge — Fonte: Aws
Vantagens da Migração para SageMaker
A transição proporciona ganhos significativos em flexibilidade e controle. Com o SageMaker, é possível treinar modelos em instâncias maiores para reduzir o tempo de processamento. Além disso, usuários podem ajustar hiperparâmetros que antes não eram disponíveis no console do Lookout for Vision. Por exemplo, é possível desabilitar a cabeça do classificador binário em modelos de segmentação semântica, tornando a solução mais tolerante a variações de iluminação e fundo.
Outro destaque é o controle sobre o tempo máximo de treinamento, que no Lookout for Vision era limitado a 24 horas. Agora, organizações podem customizar esse parâmetro conforme suas necessidades.
Recursos e Modelos Disponíveis
A AWS coloca à disposição dois tipos principais de modelos:
Classificação binária: para categorizar imagens como normais ou anômalas
Segmentação semântica: para identificar regiões específicas com defeitos em uma imagem
Ambos podem ser treinados nas contas próprias da AWS para implantação na nuvem ou em dispositivos edge. O repositório GitHub do Amazon Lookout for Vision foi atualizado com um Jupyter Notebook que facilita o treinamento de datasets com esses dois tipos de modelos e seu empacotamento.
Para rotular dados além do conjunto amostral, é possível usar o Amazon SageMaker Ground Truth para crowdsourcing ou permitir que equipes privadas façam a anotação. Alternativas incluem soluções de parceiros como Edge Impulse, Roboflow e SuperbAI.
Pré-Requisitos
Antes de começar, certifique-se de ter em lugar:
Amazon SageMaker Studio ou Amazon SageMaker Unified Studio para desenvolvimento integrado
Função Controle de Identidade e Acesso (IAM) com permissões apropriadas, incluindo acesso ao Amazon S3, operações no SageMaker e subscrição ao AWS Marketplace
Conhecimento básico de criar instâncias Jupyter no SageMaker e executar notebooks
Configuração do Processo de Etiquetagem
O primeiro passo da jornada envolve preparar os dados para treinamento. A AWS oferece o Ground Truth, que possibilita criar equipes privadas de anotadores e organizar o trabalho de rotulação.
No console do SageMaker AI, navegue até Ground Truth e selecione a opção de criar uma equipe privada. Após definir nome e configurações iniciais, você pode convidar membros da sua equipe por e-mail, enviando automaticamente convites com credenciais de acesso.
Etiquetagem com SageMaker Ground Truth — Fonte: Aws
Preparação e Etiquetagem de Datasets
Uma vez que a equipe está pronta, o próximo passo é preparar o dataset. Faça upload das imagens para um bucket Amazon S3 e organize-as em uma estrutura única de diretório, combinando imagens normais e anômalas.
Para automatizar esse processo, você pode usar um script no AWS CloudShell:
#!/bin/bash
# Clone o repositório
git clone https://github.com/aws-samples/amazon-lookout-for-vision.git
cd amazon-lookout-for-vision/aliens-dataset
# Remove diretório anterior se existir
rm -rf all
# Cria novo diretório
mkdir -p all
# Copia imagens normais
cp normal/*.png all/
# Copia imagens anômalas com sufixo
cd "$(dirname "$0")/amazon-lookout-for-vision/aliens-dataset"
for file in anomaly/*.png; do
if [ -f "$file" ]; then
filename=$(basename "$file")
cp "$file" "all/${filename}.anomaly.png"
fi
done
# Verifica contagem
echo "Imagens normais: $(find normal -name "*.png" | wc -l)"
echo "Imagens anômalas: $(find anomaly -name "*.png" | wc -l)"
echo "Total no diretório all: $(find all -type f | wc -l)"
# Upload para S3
aws s3 cp all/ s3://<BUCKET_NAME>/aliens-dataset-all/ --recursive
# Limpeza
cd ../..
rm -rf amazon-lookout-for-vision
Alternativamente, com a CLI da AWS configurada, você pode usar comandos manuais. Depois de fazer upload, acesse o console do SageMaker, navigate para Ground Truth e crie um novo job de etiquetagem. Configure a localização dos dados no S3, escolha “Configuração Automática de Dados” e selecione “Imagem” como tipo de dados.
Para o tipo de tarefa, escolha “Classificação de Imagem (Rótulo Único)” para classificação binária ou “Segmentação Semântica” conforme sua necessidade. Crie dois rótulos: “normal” e “anomalia”. Uma vez que o job é iniciado, trabalhadores acesso o portal de etiquetagem e rotulam cada imagem conforme as instruções fornecidas.
Treinamento do Modelo
Após concluir a etiquetagem, use os dados rotulados para treinar o modelo de detecção de defeitos. Primeiro, subscrevam-se ao modelo no AWS Marketplace. Copie o ARN (Identificador de Recurso da Amazon) do modelo para referência posterior.
Em seguida, crie uma instância Jupyter do SageMaker. Para essa tarefa, uma instância do tipo m5.2xl é adequada, com volume de 128 GB (o padrão de 5 GB é insuficiente). GPU não é obrigatória na instância do notebook, pois o SageMaker ativa automaticamente instâncias habilitadas com GPU durante o treinamento.
Clone o repositório GitHub dentro da instância Jupyter e localize a pasta relevante. No notebook, defina o ARN do modelo que você subscreveu:
# TODO: altere para usar o algoritmo SageMaker subscrito
algorithm_name = "<Especificar nome do algoritmo após subscrição>"
# Inicializa a sessão SageMaker e obtém a função de execução
sagemaker_session = sagemaker.Session()
region = sagemaker_session.boto_region_name
role = get_execution_role()
# Nome do projeto para identificar no S3
project = "ComputerVisionDefectDetection"
