Blog

  • Autenticação por chave pública agora é suportada entre Amazon QuickSight e Snowflake

    O desafio da conexão segura com data warehouses

    Empresas modernas enfrentam desafios significativos ao integrar plataformas de inteligência de negócios com data warehouses em nuvem, especialmente quando é necessário manter a automação sem comprometer a segurança. A autenticação baseada em senha introduz vulnerabilidades, cria atrito operacional e gera lacunas de conformidade — particularmente crítico considerando que o Snowflake está descontinuando o suporte a autenticação por nome de usuário e senha.

    A AWS reconheceu esse cenário e implementou uma solução através do Amazon QuickSight (um componente do Amazon Quick Suite), agora oferecendo suporte a autenticação por chave pública para integrações com Snowflake. Esse novo recurso utiliza criptografia assimétrica, onde pares de chaves RSA substituem as tradicionais senhas. Com essa capacidade, usuários da Amazon Quick Suite podem estabelecer conexões seguras e sem senha com fontes de dados Snowflake usando pares de chaves RSA, proporcionando uma experiência de integração contínua e segura que atende aos padrões empresariais de segurança.

    Por que essa mudança importa

    A implementação de autenticação por chave pública representa um avanço transformador na segurança de conectividade entre Amazon QuickSight e Snowflake. Ao eliminar as vulnerabilidades associadas a senhas e adotar autenticação criptográfica, as organizações conseguem alcançar uma postura de segurança superior mantendo fluxos de trabalho automatizados e contínuos. Essa implementação atende a requisitos críticos de empresas, como melhor segurança através de criptografia assimétrica, gerenciamento simplificado de contas de serviço e conformidade com padrões de autenticação em evolução, especialmente diante da transição do Snowflake para longe dos métodos tradicionais de senha.

    Pré-requisitos para configuração

    Antes de configurar a autenticação por chave pública entre Amazon QuickSight e Snowflake, verifique se você tem os seguintes requisitos:

    Conta ativa da Amazon Quick

    Você precisa de uma conta Amazon Quick com permissões apropriadas. Isso requer acesso administrativo para criar e gerenciar fontes de dados, configurar parâmetros de autenticação e conceder permissões a usuários. Tipicamente, licenças Enterprise da Amazon Quick ou o papel de Author na Amazon Quick Enterprise Edition fornecem acesso suficiente.

    Conta Snowflake com permissões elevadas

    Uma conta Snowflake com papéis ACCOUNTADMIN, SECURITYADMIN ou USERADMIN é essencial. Essas permissões elevadas são necessárias para modificar contas de usuário, atribuir chaves públicas usando comandos ALTER USER e conceder permissões em warehouses e bancos de dados. Se você não tiver acesso a esses papéis, entre em contato com seu administrador Snowflake.

    OpenSSL instalado

    OpenSSL, um kit de ferramentas criptográficas, é necessário para gerar pares de chaves RSA no formato PKCS#8. A maioria dos sistemas Linux e macOS inclui OpenSSL pré-instalado. Usuários de Windows podem usar Windows Subsystem for Linux (WSL) ou baixar OpenSSL separadamente.

    AWS Secrets Manager (opcional)

    Para configurações baseadas em API, acesso a AWS Secrets Manager é necessário. Você precisará de permissões IAM (Identity and Access Management) para criar e gerenciar secrets, além de acesso à API do Amazon QuickSight para implantações automatizadas e implementações de infraestrutura como código (IaC).

    Passo a passo: Configurando a autenticação por chave pública

    Para estabelecer autenticação segura por chave pública entre Amazon QuickSight e Snowflake, você seguirá estas etapas essenciais:

    Gerar o par de chaves RSA

    Navegue até AWS CloudShell no AWS Management Console e execute o comando a seguir para gerar a chave privada RSA. Você será solicitado a inserir uma frase de criptografia. Escolha uma frase forte e armazene-a com segurança — você precisará dela posteriormente ao gerar a chave pública.

    openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8

    Execute os comandos a seguir para criar o par de chaves públicas. Você será solicitado a inserir a frase que utilizou no passo anterior.

    openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

    Extraia o conteúdo da chave privada (incluindo cabeçalho e rodapé):

    cat rsa_key.p8

    Isso exibirá sua chave privada no formato:

    -----BEGIN PRIVATE KEY-----[conteúdo da chave]-----END PRIVATE KEY-----

    Importante: copie a saída inteira incluindo as linhas -----BEGIN PRIVATE KEY----- e -----END PRIVATE KEY-----. Você utilizará essa chave privada completa (com cabeçalhos e rodapés) ao criar sua conexão de fonte de dados Snowflake.

    Formatar a chave pública

    O Snowflake requer a chave pública em um formato específico sem cabeçalhos ou quebras de linha. Execute estes comandos para extrair e formatar a chave corretamente:

    grep -v KEY rsa_key.pub | tr -d '\n' | awk '{print $1}' > pub.Key
    cat pub.Key

    Isso exibirá sua string de chave pública formatada. Copie essa saída — você a utilizará no próximo passo para configurar sua conta de usuário no Snowflake.

    Atribuir a chave pública ao usuário Snowflake

    Faça login no Snowflake e execute os seguintes comandos SQL para atribuir a chave pública ao seu usuário:

    ALTER USER <username> SET RSA_PUBLIC_KEY='<public_key_content>';

    Verifique a atribuição da chave procurando pela propriedade RSA_PUBLIC_KEY para confirmar se a chave pública foi configurada:

    DESCRIBE USER <username>;

    Estabelecendo a conexão através da interface do Amazon QuickSight

    Navegue até Amazon QuickSight no AWS Management Console e selecione Datasets. Em seguida, selecione a aba Data sources e escolha Create data source. No painel Create data source, insira “snowflake” no campo Search datasets, selecione Snowflake e escolha Next.

    No painel New Snowflake data source, insira o nome da fonte de dados e o tipo de conexão como Public Network ou uma Private VPC Connection. Se você precisar de uma conexão VPC, consulte a documentação para configurar a conexão VPC em QuickSight. Em seguida, insira o nome do host do servidor de banco de dados, o nome do banco de dados e o nome do warehouse.

    Selecione Authentication Type como KeyPair e insira o nome do usuário Snowflake. No campo Private Key, cole a saída completa do comando cat rsa_key.p8 (incluindo os cabeçalhos BEGIN e END). Se você tiver configurado uma frase de criptografia durante a geração da chave, forneça-a no campo opcional Passphrase.

    Após preencher todos os campos, selecione o botão Validate connection. Depois que a conexão for validada, selecione Create data source. Na lista de Data sources, localize a fonte de dados Snowflake que você criou. No menu Actions, selecione a opção Create dataset.

    Estabelecendo a conexão através da API do Amazon QuickSight

    Usando AWS CLI, você pode criar a conexão de fonte de dados do Amazon QuickSight com Snowflake executando o seguinte comando:

    aws quicksight create-data-source \
      --aws-account-id 123456789 \
      --data-source-id awsclikeypairtest \
      --name "awsclikeypairtest" \
      --type SNOWFLAKE \
      --data-source-parameters '{
        "SnowflakeParameters": {
          "Host": "hostname.snowflakecomputing.com",
          "Database": "DB_NAME",
          "Warehouse": "WH_NAME",
          "AuthenticationType": "KEYPAIR"
        }
      }' \
      --credentials '{
        "KeyPairCredentials": {
          "KeyPairUsername": "SNOWFLAKE_USERNAME",
          "PrivateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----\nPRIVATE_KEY\n-----END ENCRYPTED PRIVATE KEY-----",
          "PrivateKeyPassphrase": "******"
        }
      }' \
      --permissions '[
        {
          "Principal": "arn:aws:quicksight:us-east-1:123456789:user/default/Admin/username",
          "Actions": [
            "quicksight:DescribeDataSource",
            "quicksight:DescribeDataSourcePermissions",
            "quicksight:PassDataSource",
            "quicksight:UpdateDataSource",
            "quicksight:DeleteDataSource",
            "quicksight:UpdateDataSourcePermissions"
          ]
        }
      ]' \
      --region us-east-1

    Use o comando a seguir para verificar o status da criação:

    aws quicksight describe-data-source --region us-east-1 --aws-account-id 123456789 --data-source-id awsclikeypairtest

    Inicialmente, o status retornado pelo comando describe-data-source será CREATION_IN_PROGRESS. O status mudará para CREATION_SUCCESSFUL quando a nova fonte de dados estiver pronta para uso.

    Alternativamente, ao criar a fonte de dados programaticamente através de CreateDataSource, você pode armazenar o nome de usuário, chave e frase no AWS Secrets Manager e referenciá-los usando o Secret ARN. Após a criação bem-sucedida da fonte de dados, você poderá navegar até o console do QuickSight. Na página Create a Dataset, você visualizará a conexão de fonte de dados recém-criada awsclikeypairtest na lista de data sources. Você poderá então prosseguir para criar os datasets.

    Limpeza de recursos

    Para limpar seus recursos e evitar incorrer em custos adicionais, siga estas etapas:

    Benefícios práticos dessa implementação

    A adoção de autenticação por chave pública oferece flexibilidade sem comprometer a segurança, independentemente de você estar implantando através da interface intuitiva do Amazon QuickSight ou usando AWS CLI para implementações de Infraestrutura como Código. A integração com AWS Secrets Manager ajuda a proteger as chaves privadas, enquanto o processo de configuração direto permite implantação rápida em ambientes de desenvolvimento, staging e produção.

    Conforme a segurança de dados continua evoluindo, a adoção de autenticação por chave pública posiciona sua organização na vanguarda das melhores práticas. Os times de inteligência de negócios agora podem se concentrar em extrair insights acionáveis dos dados do Snowflake, em vez de gerenciar complexidades de autenticação, acelerando assim o tempo para obtenção de insights e melhorando a eficiência operacional.

    Próximas leituras

    Para aprofundar seu conhecimento sobre esse tópico, consulte autenticação por chave pública no Snowflake.

    Fonte

    Amazon Quick now supports key pair authentication to Snowflake data source (https://aws.amazon.com/blogs/machine-learning/amazon-quick-suite-now-supports-key-pair-authentication-to-snowflake-data-source/)

  • Amazon Managed Grafana agora suporta chaves criptográficas gerenciadas pelo cliente

    Novo suporte para chaves gerenciadas pelo cliente

    A AWS anunciou que o Amazon Managed Grafana agora suporta chaves gerenciadas pelo cliente (Customer Managed Keys – CMK) por meio do AWS Key Management Service (Serviço de Gerenciamento de Chaves da AWS – KMS). Este recurso possibilita que você criptografe os dados armazenados em seus workspaces do Amazon Managed Grafana utilizando suas próprias chaves de criptografia.

    O que é Amazon Managed Grafana

    Amazon Managed Grafana é um serviço totalmente gerenciado, baseado no Grafana de código aberto, que facilita a visualização e análise de dados operacionais em grande escala. O serviço já oferecia criptografia em repouso por padrão, utilizando chaves de propriedade da AWS.

    Benefício da camada de segurança adicional

    Com este lançamento, agora você tem a opção de utilizar uma chave gerenciada pelo cliente ao criar um workspace do Amazon Managed Grafana. Essa flexibilidade permite adicionar uma camada de segurança autogerenciada, auxiliando sua organização a atender requisitos específicos de conformidade e regulamentações.

    Disponibilidade e próximos passos

    O recurso está disponível em todas as regiões onde Amazon Managed Grafana é oferecido, com exceção das AWS GovCloud (US) Regions.

    Para começar a usar Amazon Managed Grafana com chaves gerenciadas pelo cliente, consulte a documentação completa do serviço.

    Para conhecer mais detalhes sobre a plataforma, visite a página do produto e a página de preços.

    Fonte

    Amazon Managed Grafana now supports AWS KMS customer managed keys (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-managed-grafana-customer-managed-keys)

  • Amazon Aurora DSQL integra-se com poderes Kiro e habilidades de agentes de IA

    Nova Integração do Aurora DSQL com Poderes Kiro

    A AWS anunciou a integração do Amazon Aurora DSQL com os poderes Kiro e habilidades de agentes de IA, uma evolução importante para desenvolvedores que desejam construir aplicações baseadas em Aurora DSQL de forma mais ágil. Essa integração combina o servidor de Protocolo de Contexto de Modelo (MCP) do Aurora DSQL com as melhores práticas de desenvolvimento, permitindo que agentes de IA auxiliem diretamente em tarefas como design de esquema, otimização de desempenho e operações de banco de dados, tudo pronto para uso imediato.

    Entendendo os Poderes Kiro

    Os poderes Kiro funcionam como um registro organizado de servidores MCP pré-configurados, arquivos de direcionamento e ganchos de agentes, acelerando processos especializados de desenvolvimento e implantação de software. Com o poder dedicado ao Aurora DSQL, os agentes ganham acesso instantâneo a conhecimento especializado, permitindo que desenvolvedores trabalhem com confiança mesmo sem experiência prévia, reduzindo significativamente ciclos de desenvolvimento baseados em tentativa e erro.

    O poder está disponível dentro da Kiro IDE com instalação em um clique, tornando o acesso simples e direto.

    Extensão das Capacidades com Habilidades de Agentes

    A habilidade de agente do Aurora DSQL amplia essas mesmas funcionalidades para uma variedade maior de agentes de codificação de IA, acessível através da Skills CLI. Desenvolvedores conseguem instalar a habilidade com um único comando, selecionando seus agentes preferidos entre opções como Kiro CLI, Claude Code, Gemini, Codex, Cursor, Copilot, Cline, Windsurf, Roo, OpenCode, entre outros.

    Carregamento Dinâmico de Orientações Especializadas

    Quando desenvolvedores trabalham em tarefas relacionadas a bancos de dados, o agente carrega dinamicamente as orientações de habilidades relevantes. Isso inclui padrões SQL compatíveis com Postgres do Aurora DSQL, design de banco de dados distribuído e autenticação de Gerenciamento de Identidades e Acesso (IAM), eliminando a necessidade de fornecer repetidamente o mesmo contexto ao longo de diferentes conversas.

    Conforme o Aurora DSQL recebe novas funcionalidades, futuras versões da habilidade incluirão padrões e orientações atualizadas, assegurando que os agentes sempre tenham acesso às práticas mais atuais e recomendadas.

    Começando com Aurora DSQL

    Para mais informações sobre o poder Kiro e habilidades de agentes do Aurora DSQL, consulte a documentação de direcionamento do Aurora DSQL e a página no GitHub. Desenvolvedores podem começar a usar o Aurora DSQL gratuitamente através da AWS Free Tier.

    Fonte

    Amazon Aurora DSQL now integrates with Kiro powers and AI agent skills (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-aurora-dsql-integrates-with-kiro-powers-and-agent-skills)

  • AWS Clean Rooms anuncia suporte para catálogos remotos Apache Iceberg

    Nova capacidade de federação de catálogos

    A AWS Clean Rooms passou a oferecer suporte para federação de catálogos direcionada a catálogos Iceberg remotos. Esta novidade representa um avanço significativo na forma como as organizações podem colaborar e compartilhar insights sobre seus dados, sem necessidade de replicar metadados de tabelas ou construir infraestruturas complexas de integração de dados.

    O diferencial dessa abordagem está na simplicidade: o Clean Rooms agora oferece acesso direto e seguro às tabelas Iceberg armazenadas no Amazon S3 e catalogadas em repositórios remotos. Isso elimina uma barreira técnica importante que existia anteriormente, reduzindo significativamente o esforço necessário para configurar ambientes de análise colaborativa.

    Como a federação de catálogos funciona

    Com o suporte à federação de catálogos, as organizações podem aproveitar o AWS Glue para fornecer acesso direto a seus catálogos Iceberg REST existentes em uma colaboração Clean Rooms. Essa integração permite que diferentes parceiros de negócios trabalhem juntos mantendo seus dados em seus próprios repositórios e sob seu próprio controle.

    Caso de uso prático

    Um cenário comum ilustra bem o potencial dessa funcionalidade: imagine uma empresa de mídia cujos dados estão catalogados no AWS Glue Data Catalog e um anunciante com dados catalogados em um catálogo Iceberg remoto. Ambos podem agora analisar seus conjuntos de dados combinados para avaliar gastos com publicidade — tudo sem construir pipelines ETL (Extração, Transformação e Carregamento) complexos e sem que um lado precise compartilhar seus dados brutos com o outro.

    O propósito do AWS Clean Rooms

    O AWS Clean Rooms foi desenvolvido para permitir que empresas e seus parceiros analisem e colaborem sobre conjuntos de dados compartilhados de forma segura, revelando apenas insights e conclusões — não os dados subjacentes. A adição do suporte a catálogos Iceberg remotos reforça essa proposta de valor, tornando possível colaborações mais eficientes e com menos complexidade operacional.

    Disponibilidade regional

    Para informações sobre as regiões onde o AWS Clean Rooms está disponível, consulte a tabela de regiões da AWS. Mais detalhes sobre como colaborar utilizando o AWS Clean Rooms podem ser encontrados na documentação oficial do serviço.

    Fonte

    AWS Clean Rooms announces support for remote Apache Iceberg REST catalogs (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-clean-rooms-remote-iceberg-catalogs)

  • Amazon Bedrock expande ajuste fine-tuning por reforço para modelos abertos com APIs compatíveis com OpenAI

    Suporte ampliado para modelos abertos no Amazon Bedrock

    A AWS anunciou uma expansão significativa das capacidades de ajuste fine-tuning por reforço (RFT) no Amazon Bedrock. A plataforma agora oferece suporte a modelos abertos populares, incluindo OpenAI GPT-OSS e modelos Qwen, além de introduzir APIs de ajuste fine-tuning compatíveis com OpenAI. Essa evolução torna mais acessível para desenvolvedores melhorar a precisão de modelos abertos sem necessidade de expertise profunda em aprendizado de máquina ou grandes conjuntos de dados rotulados.

    Como funciona o ajuste por reforço

    O ajuste fine-tuning por reforço no Amazon Bedrock automatiza todo o fluxo de customização de modelos. Em vez de depender de grandes volumes de dados de treinamento, ele permite que modelos aprendam com feedback sobre múltiplas respostas possíveis utilizando apenas um pequeno conjunto de prompts. Essa abordagem possibilita às organizações trabalhar com variantes de modelos menores, mais rápidos e mais econômicos, mantendo alta qualidade nas respostas.

    Resolvendo o dilema da customização

    Muitas empresas enfrentam um desafio comum: modelos genéricos oferecem desempenho limitado, enquanto pipelines de customização complexos exigem infraestrutura especializada e equipes experientes. O Amazon Bedrock simplifica esse cenário ao fornecer uma experiência de ajuste fine-tuning totalmente gerenciada e segura.

    Os clientes definem funções de recompensa utilizando avaliadores baseados em regras verificáveis ou juízes alimentados por inteligência artificial. A AWS oferece templates prontos para tarefas objetivas — como geração de código e raciocínio matemático — e subjetivas, como seguimento de instruções ou qualidade conversacional.

    Recursos de customização e controle

    Durante o treinamento, os clientes podem utilizar funções AWS Lambda para lógica de avaliação personalizada e acessar checkpoints intermediários do modelo. Isso permite avaliar, depurar e selecionar o melhor modelo, acelerando o ciclo de iteração e melhorando a eficiência do treinamento. Todos os dados proprietários permanecem em um ambiente seguro e governado dentro da AWS durante todo o processo de customização.

    Modelos e APIs suportados

    Neste lançamento, a AWS oferece suporte aos modelos qwen.qwen3-32b e openai.gpt-oss-20b. Após a conclusão do ajuste fine-tuning, os clientes podem utilizar imediatamente o modelo customizado para inferência sob demanda através das APIs compatíveis com OpenAI do Amazon Bedrock — incluindo as APIs Responses e Chat Completions — sem necessidade de etapas adicionais de implantação.

    Próximos passos

    Para explorar essa funcionalidade em detalhes, consulte a documentação do Amazon Bedrock.

    Fonte

    Amazon Bedrock reinforcement fine-tuning adds support for open-weight models with OpenAI-compatible APIs (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-reinforcement-fine-tuning-openai)

  • AWS Glue 5.1 agora disponível em 18 regiões adicionais

    Expansão Global do AWS Glue 5.1

    A AWS anunciou a disponibilidade do AWS Glue 5.1 em dezoito regiões adicionais, ampliando significativamente o alcance desse serviço de integração de dados. A expansão abrange continentes e oferece cobertura em localidades estratégicas: África (Cidade do Cabo), Ásia Pacífico (Hyderabad, Jakarta, Melbourne, Osaka, Seul, Taipei), Canadá (Calgary, Central), Europa (Londres, Milão, Paris, Zurique), Israel (Tel Aviv), México (Central), Oriente Médio (Bahrein, Emirados Árabes Unidos) e US West (Califórnia do Norte). Com essa adição, o serviço chega a trinta e três regiões no total.

    O que é AWS Glue

    AWS Glue é um serviço serverless e escalável de integração de dados que simplifica as tarefas de descoberta, preparação, movimentação e integração de dados originários de múltiplas fontes. Ele elimina a necessidade de gerenciar infraestrutura, permitindo que equipes se concentrem na lógica de transformação e integração de dados.

    Principais Melhorias na Versão 5.1

    Atualização de Motores e Componentes

    A versão 5.1 traz atualizações importantes nos motores núcleo: Apache Spark 3.5.6, Python 3.11 e Scala 2.12.18. Essas atualizações contribuem para melhorias significativas de performance e segurança em operações de integração de dados.

    Suporte a Formatos Abertos de Tabelas

    O AWS Glue 5.1 estende o suporte para bibliotecas de formatos abertos de tabelas, incluindo Apache Hudi 1.0.2, Apache Iceberg 1.10.0 e Delta Lake 3.3.2. Essa compatibilidade oferece flexibilidade ao trabalhar com diferentes padrões da comunidade open source.

    Iceberg Format Version 3.0

    A versão 5.1 introduz suporte para Apache Iceberg format version 3.0, adicionando funcionalidades como valores padrão de coluna, deletion vectors para tabelas de merge-on-read, transformações multi-argumento e rastreamento de linhagem de linhas. Essas capacidades avançadas facilitam operações complexas de transformação e auditoria de dados.

    Controle de Acesso e Segurança

    Expansão do Lake Formation

    Uma das melhorias mais significativas é a extensão do AWS Lake Formation com controle de acesso granular para operações de escrita (tanto DML quanto DDL) em DataFrames Spark e Spark SQL. Anteriormente, essa funcionalidade estava limitada apenas a operações de leitura, representando um avanço importante em governança de dados.

    Controle de Acesso em Tabelas

    O AWS Glue 5.1 também adiciona controle de acesso em nível de tabela completa no Apache Spark para tabelas Apache Hudi e Delta Lake, proporcionando opções de segurança mais abrangentes para proteção de dados sensíveis.

    Como Começar

    Você pode iniciar com AWS Glue 5.1 através de diversas interfaces: APIs do AWS Glue, Interface de Linha de Comando (CLI) da AWS, Kit de Desenvolvimento de Software (SDK) da AWS, AWS Glue Studio ou Amazon SageMaker Unified Studio. Para aprofundar seu conhecimento, visite a página do produto e consulte a documentação oficial.

    Fonte

    AWS Glue 5.1 is now available in 18 additional regions (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-glue-5-1-eighteen-additional-regions)

  • Arquitetura de Segurança em Camadas com IA para Microsserviços Serverless

    O Desafio Crescente da Segurança em Ambientes Serverless

    As organizações enfrentam um cenário de segurança sem precedentes. Atacantes sofisticados utilizam inteligência artificial para identificar vulnerabilidades, automatizar ataques e contornar sistemas de detecção em velocidade de máquina. Os modelos tradicionais de segurança baseados apenas em perímetro não são mais suficientes quando adversários conseguem analisar milhões de vetores de ataque em segundos e explorar vulnerabilidades zero-day antes mesmo que correções estejam disponíveis.

    Arquiteturas serverless com microsserviços amplificam esse desafio. Embora ofereçam agilidade e escalabilidade, expandem significativamente a superfície de ataque: cada endpoint de API, invocação de função e armazenamento de dados se torna um possível ponto de entrada. Um único componente mal configurado pode fornecer aos atacantes o apoio necessário para movimento lateral dentro da infraestrutura.

    Simultaneamente, as organizações precisam navegar por ambientes regulatórios complexos. Frameworks de conformidade como GDPR, HIPAA, PCI-DSS e SOC 2 demandam controles de segurança robustos e trilhas de auditoria abrangentes. A velocidade do desenvolvimento de software cria tensão entre segurança e inovação, exigindo arquiteturas que sejam simultaneamente compreensivas e automatizadas para permitir implantação segura sem sacrificar a velocidade.

    Os Desafios Técnicos Específicos

    Implementar segurança efetiva em microsserviços serverless envolve várias dimensões de risco:

    • Superfície de ataque expandida: Múltiplos pontos de entrada em serviços distribuídos exigem proteção contra ataques distribuído de negação de serviço (DDoS), vulnerabilidades de injeção e acesso não autorizado
    • Complexidade de identidade e acesso: Gerenciar autenticação e autorização entre numerosos microsserviços e comunicações serviço-a-serviço
    • Proteção de dados: Criptografar dados sensíveis em trânsito e em repouso, além de armazenar e rotacionar credenciais com segurança
    • Conformidade e proteção de dados: Atender requisitos regulatórios através de trilhas de auditoria abrangentes e monitoramento contínuo em ambientes distribuídos
    • Isolamento de rede: Implementar caminhos de comunicação controlados sem expor recursos à internet pública
    • Ameaças alimentadas por IA: Defender contra atacantes que usam IA para automatizar reconhecimento, adaptar ataques em tempo real e identificar vulnerabilidades em velocidade de máquina

    Defesa em Profundidade: A Solução em Camadas

    A resposta efetiva a esses desafios reside em defesa em profundidade – uma abordagem de segurança em camadas onde múltiplos controles independentes trabalham em conjunto para proteger a aplicação. Nenhum único ponto de falha compromete toda a infraestrutura. Se uma camada é comprometida, controles adicionais ajudam a limitar o impacto e conter o incidente.

    A AWS oferece uma arquitetura abrangente que integra serviços de IA e aprendizado de máquina em sete camadas distintas, com monitoramento contínuo e detecção de ameaças alimentadas por IA em toda a infraestrutura. Vamos percorrer como uma requisição de usuário atravessa cada camada de segurança:

    Camada 1: Proteção de Borda

    Antes que requisições atinjam sua aplicação, elas percorrem a internet pública onde atacantes lançam ataques volumétricos de DDoS, SQL injection, cross-site scripting (XSS) e outras explorações web. A AWS observou e mitigou milhares de ataques DDoS em 2024, com um deles ultrapassando 2,3 terabits por segundo.

    AWS Shield fornece proteção gerenciada contra DDoS para aplicações na AWS, habilitada sem custo para todos os clientes. AWS Shield Advanced oferece detecção aprimorada, acesso contínuo à equipe de resposta a DDoS da AWS, proteção de custo durante ataques e diagnósticos avançados para aplicações empresariais.

    AWS WAF (Firewall de Aplicação Web) protege contra ataques de camada 7 através de grupos de regras gerenciadas que cobrem as dez principais vulnerabilidades OWASP, incluindo SQL injection, XSS e inclusão de arquivo remoto. Regras baseadas em taxa bloqueiam automaticamente endereços IP que excedem limites de requisição, protegendo contra DDoS de camada de aplicação e ataques de força bruta. Recursos de bloqueio geográfico restringem acesso baseado em localização, enquanto Controle de Bots usa aprendizado de máquina para identificar e bloquear bots maliciosos permitindo tráfego legítimo.

    Amazon GuardDuty utiliza IA generativa para aprimorar serviços de segurança nativos, implementando capacidades de IA para melhorar detecção de ameaças, investigação e resposta através de análise automatizada. Organizações podem construir agentes autônomos de segurança com IA usando Amazon Bedrock para analisar logs do AWS WAF, raciocinar sobre dados de ataque e automatizar resposta a incidentes. Esses agentes detectam padrões de ataque novos que sistemas baseados em assinatura perdem, geram resumos em linguagem natural de incidentes de segurança, recomendam automaticamente atualizações de regras do AWS WAF baseadas em ameaças emergentes, correlacionam indicadores de ataque em serviços distribuídos para identificar campanhas coordenadas e acionam ações de remediação apropriadas baseadas em contexto de ameaça.

    Camada 2: Verificação de Identidade

    Após passar proteção de borda, você deve verificar identidade do usuário e determinar acesso a recursos. Autenticação tradicional baseada em usuário/senha é vulnerável a credential stuffing, phishing e ataques de força bruta, exigindo gerenciamento robusto de identidade que suporte múltiplos métodos de autenticação e segurança adaptativa respondendo a sinais de risco em tempo real.

    Amazon Cognito fornece gerenciamento abrangente de identidade e acesso para aplicações web e mobile através de dois componentes: pools de usuários oferecem um diretório de usuários totalmente gerenciado tratando registro, login, autenticação multifator (MFA), políticas de senha, integração com provedores de identidade social, federação SAML e OpenID Connect para provedores de identidade empresariais, e recursos avançados de segurança incluindo autenticação adaptativa e detecção de credenciais comprometidas. Pools de identidade concedem credenciais AWS temporárias com privilégios limitados aos usuários para acesso seguro direto aos serviços AWS sem expor credenciais de longo prazo.

    Autenticação adaptativa do Amazon Cognito usa aprendizado de máquina para detectar tentativas de login suspeitas analisando impressão digital de dispositivo, reputação de endereço IP, anomalias geográficas e padrões de velocidade de login. Baseado na avaliação de risco, permite login, requer verificação MFA adicional ou bloqueia tentativas. Detecção de credenciais comprometidas automaticamente verifica credenciais contra bancos de dados de senhas comprometidas e bloqueia logins usando credenciais conhecidas como comprometidas. MFA suporta tanto métodos baseados em SMS quanto senhas descartáveis baseadas em tempo (TOTP), reduzindo significativamente risco de takeover de conta. Para análise comportamental avançada, organizações podem usar Amazon Bedrock para analisar padrões em períodos estendidos, detectando tentativas de takeover de conta através de anomalias geográficas, mudanças em impressão digital de dispositivo, desvios em padrões de acesso e anomalias de hora do dia.

    Camada 3: Porta de Entrada da Aplicação

    Amazon API Gateway funciona como ponto de entrada da aplicação. Deve lidar com roteamento de requisição, limitação de taxa, gerenciamento de chaves de API, criptografia e integrar perfeitamente com sua camada de autenticação, fornecendo logs detalhados para auditoria de segurança mantendo alta performance e baixa latência.

    O API Gateway é um serviço totalmente gerenciado para criar, publicar e proteger APIs em escala, fornecendo capacidades críticas de segurança incluindo criptografia SSL/TLS com AWS Certificate Manager (ACM) que automaticamente trata provisionamento, renovação e implantação de certificados. Limitação de requisição e gerenciamento de cotas protegem serviços backend através de limites de rajada e taxa configuráveis com cotas de uso por chave de API ou cliente para prevenir abuso, enquanto gerenciamento de chaves de API controla acesso de sistemas parceiros e integrações de terceiros. Validação de requisição/resposta usa JSON Schema para validar dados antes de atingir AWS Lambda, prevenindo requisições malformadas de consumir recursos de computação. Integração perfeita com Amazon Cognito valida JSON Web Tokens (JWTs) e impõe requisitos de autenticação antes de requisições atingirem lógica de aplicação.

    GuardDuty fornece detecção inteligente de ameaças alimentada por IA analisando padrões de invocação de API e identificando atividades suspeitas incluindo exfiltração de credenciais usando aprendizado de máquina. Para análise avançada, Amazon Bedrock analisa métricas do API Gateway e logs do Amazon CloudWatch para identificar picos incomuns de erros HTTP 4XX (por exemplo, 403 Proibido) que podem indicar tentativas de scanning ou probing, anomalias de distribuição geográfica, desvios em padrões de acesso a endpoint, anomalias em série temporal de volume de requisição ou padrões suspeitos de user agent.

    Camada 4: Isolamento de Rede

    Lógica de aplicação e dados devem ser isolados de acesso direto à internet. Segmentação de rede é desenhada para limitar movimento lateral se ocorre um incidente de segurança, ajudando a prevenir componentes comprometidos de facilmente acessar recursos sensíveis.

    Amazon Virtual Private Cloud (Amazon VPC) fornece ambientes de rede isolados implementando arquitetura multi-tier com subnets públicas para gateways NAT e load balancers de aplicação com rotas de internet gateway, subnets privadas para funções Lambda e componentes de aplicação acessando internet através de Gateways NAT para conexões de saída, e subnets de dados com controles de acesso mais restritivos. Funções Lambda executam em subnets privadas para prevenir acesso direto à internet. VPC flow logs capturam tráfego de rede para análise de segurança. Grupos de segurança fornecem firewalls com estado seguindo princípios de menor privilégio. ACLs de rede adicionam firewalls stateless em nível de subnet com regras de negação explícita. VPC endpoints habilitam conectividade privada para Amazon DynamoDB, AWS Secrets Manager e Amazon S3 sem tráfego deixar a rede AWS.

    GuardDuty fornece detecção de ameaças de rede alimentada por IA continuamente monitorando VPC flow logs, logs CloudTrail e logs DNS usando aprendizado de máquina para identificar padrões de rede incomuns, tentativas de acesso não autorizado, instâncias comprometidas e atividades de reconhecimento. Agora inclui capacidades de IA generativa para análise automatizada e consultas de segurança em linguagem natural.

    Camada 5: Segurança de Computação

    Funções Lambda executando seu código de aplicação frequentemente requerem acesso a recursos sensíveis e credenciais devendo ser protegidas contra injeção de código, invocações não autorizadas e escalação de privilégio. Adicionalmente, funções devem ser monitoradas para comportamento incomum que pode indicar comprometimento.

    Lambda fornece recursos de segurança integrados incluindo funções de execução AWS Identity and Access Management (IAM) que definem acesso preciso a recursos e ações seguindo princípios de menor privilégio. Políticas baseadas em recurso controlam quais serviços e contas podem invocar funções prevenindo invocações não autorizadas. Criptografia de variável de ambiente usando AWS Key Management Services (AWS KMS) para variáveis em repouso enquanto dados sensíveis devem usar Secrets Manager. Isolamento de função desenhado para que cada execução rode em ambientes isolados prevenindo acesso de dados entre invocações. Integração VPC habilitando funções a se beneficiarem de isolamento de rede e controles de grupo de segurança. Segurança de runtime com runtimes gerenciados automaticamente patcheados e atualizados. Assinatura de código com AWS Signer assinando digitalmente pacotes de implantação para integridade de código e verificação criptográfica contra modificações não autorizadas.

    Amazon CodeGuru Security combina aprendizado de máquina e raciocínio automatizado para identificar vulnerabilidades incluindo os 10 principais problemas OWASP e 25 principais do CWE, injeção de log, segredos e uso inseguro de API AWS. Usando análise semântica profunda treinada em milhões de linhas de código Amazon, emprega mineração de regras e modelos de ML supervisionados combinando regressão logística e redes neurais para altas taxas de verdadeiros positivos. Amazon Inspector fornece gerenciamento automatizado de vulnerabilidade, continuamente scanning funções Lambda para vulnerabilidades de software e exposição de rede, usando aprendizado de máquina para priorizar achados e fornecer orientação detalhada de remediação.

    Camada 6: Proteção de Credenciais

    Aplicações requerem acesso a credenciais sensíveis incluindo senhas de banco de dados, chaves de API e chaves de criptografia. Hardcoding de segredos em código ou armazená-los em variáveis de ambiente cria vulnerabilidades de segurança, exigindo armazenamento seguro, rotação regular, acesso apenas autorizado e auditoria abrangente para conformidade.

    AWS Secrets Manager protege acesso a aplicações, serviços e recursos de TI sem gerenciar módulos de segurança de hardware (HSMs). Fornece armazenamento centralizado de segredos para credenciais de banco de dados, chaves de API e tokens OAuth em repositório criptografado usando criptografia AWS KMS em repouso. Rotação automática de segredos configura rotação para credenciais de banco de dados, automaticamente atualizando tanto o armazenamento de segredos quanto banco de dados alvo sem tempo de inatividade de aplicação. Controle de acesso refinado usa políticas IAM para controlar quais usuários e serviços acessam segredos específicos, implementando acesso de menor privilégio. Trilhas de auditoria registram acesso a segredos no AWS CloudTrail para investigações de conformidade e segurança. Suporte a VPC endpoint desenhado para que tráfego de recuperação de segredos não deixe a rede AWS. Integração Lambda habilita funções a recuperarem segredos programaticamente em runtime, desenhado para que segredos não sejam armazenados em código ou arquivos de configuração e possam ser rotacionados sem reimplantação.

    GuardDuty fornece monitoramento alimentado por IA, detectando padrões de comportamento anômalo que podem indicar comprometimento de credencial ou acesso não autorizado.

    Camada 7: Proteção de Dados

    A camada de dados armazena informações sensíveis de negócio e dados de cliente exigindo proteção tanto em repouso quanto em trânsito. Dados devem ser criptografados, acesso rigidamente controlado e operações auditadas, mantendo resiliência contra ataques de disponibilidade e alta performance.

    Amazon DynamoDB é um banco de dados NoSQL totalmente gerenciado fornecendo recursos de segurança integrados incluindo criptografia em repouso (usando chaves de propriedade AWS, gerenciadas AWS ou gerenciadas pelo cliente com AWS KMS). Criptografia em trânsito (TLS 1.2 ou superior). Controle de acesso refinado através de políticas IAM com permissões em nível de item e atributo. VPC endpoints para conectividade privada. Recuperação point-in-time para backups contínuos. Streams para trilhas de auditoria. Capacidades de backup e recuperação de desastre. Global Tables para replicação multi-região multi-ativa na AWS fornecendo alta disponibilidade e acesso global de baixa latência.

    GuardDuty e Amazon Bedrock fornecem proteção de dados alimentada por IA: GuardDuty monitora atividade de API do DynamoDB através de logs CloudTrail usando aprendizado de máquina para detectar padrões anômalo de acesso a dados incluindo volumes de query incomuns, acesso de localizações geográficas inesperadas e tentativas de exfiltração de dados. Amazon Bedrock analisa DynamoDB Streams e logs CloudTrail para identificar padrões de acesso suspeitos, correlacionar anomalias através de múltiplas tabelas e períodos de tempo, gerar resumos em linguagem natural de incidentes de acesso a dados para equipes de segurança e recomendar ajustes de política de controle de acesso baseados em padrões de uso real versus permissões configuradas. Isso ajuda transformar proteção de dados de monitoramento reativo para threat hunting proativo que pode detectar credenciais comprometidas e ameaças internas.

    Monitoramento Contínuo

    Mesmo com controles de segurança abrangentes em cada camada, monitoramento contínuo é essencial para detectar ameaças que contornam defesas. Segurança requer visibilidade em tempo real contínua, detecção inteligente de ameaças e capacidades rápidas de resposta em vez de implementação única.

    GuardDuty protege suas contas AWS, workloads e dados com detecção inteligente de ameaças. Amazon CloudWatch fornece monitoramento e observabilidade abrangentes, coletando métricas, monitorando arquivos de log, configurando alarmes e automaticamente reagindo a mudanças em recursos AWS. AWS CloudTrail fornece governança, conformidade e auditoria operacional registrando todas as chamadas de API em sua conta AWS, criando trilhas de auditoria abrangentes para análise de segurança e relatórios de conformidade.

    Aprimoramento alimentado por IA com Amazon Bedrock fornece análise automatizada de ameaças; gerando resumos em linguagem natural de achados de GuardDuty e logs CloudWatch, reconhecimento de padrão identificando ataques coordenados através de múltiplos sinais de segurança, recomendações de resposta a incidentes baseadas em sua arquitetura e requisitos de conformidade, avaliação de postura de segurança com recomendações de melhoria e resposta automatizada através de Lambda e Amazon EventBridge que isola recursos comprometidos, revoga credenciais suspeitas ou notifica equipes de segurança através do Amazon SNS quando ameaças são detectadas.

    Conclusão

    Proteger microsserviços serverless apresenta desafios significativos, mas como demonstrado, usar serviços AWS ao lado de capacidades alimentadas por IA cria uma arquitetura resiliente de defesa em profundidade que protege contra ameaças atuais e emergentes, comprovando que segurança e agilidade não são mutuamente exclusivas. Segurança é um processo contínuo—continuamente monitore seu ambiente, regularmente revise controles de segurança, mantenha-se informado sobre ameaças emergentes e melhores práticas, e trate segurança como um princípio arquitetural fundamental ao invés de pensamento posterior.

    Leitura Complementar

    Fonte

    Building an AI-powered defense-in-depth security architecture for serverless microservices (https://aws.amazon.com/blogs/security/building-an-ai-powered-defense-in-depth-security-architecture-for-serverless-microservices/)

  • AWS Backup anuncia suporte a PrivateLink para SAP HANA na AWS

    PrivateLink para SAP HANA: segurança de ponta a ponta

    A AWS expandiu as funcionalidades do AWS Backup ao introduzir suporte a PrivateLink (Link Privado) para sistemas SAP HANA em execução na Amazon EC2. Essa nova capacidade permite que as organizações direcionem todo o tráfego de backup através de conexões de rede privada, evitando completamente a passagem pela internet pública. Para muitas empresas que operam em setores regulados, esse é um requisito fundamental de conformidade e segurança.

    O desafio anterior: tráfego dividido

    Anteriormente, havia uma limitação importante: enquanto as cargas de trabalho de aplicação SAP HANA podiam utilizar o PrivateLink para estabelecer comunicação segura e privada com os serviços da AWS, o tráfego de backup precisava obrigatoriamente passar por endpoints públicos. Essa divisão criava um cenário onde a proteção de dados não era completamente privada de ponta a ponta, exigindo concessões em termos de segurança.

    Conformidade regulatória simplificada

    Organizações em setores altamente regulados — como serviços financeiros, saúde e agências governamentais — frequentemente enfrentam exigências estritas quanto à privacidade e localidade de dados. Com essa atualização, a AWS permite que empresas sujeitas a regulamentações como HIPAA (Lei de Portabilidade e Responsabilidade de Seguros de Saúde), Privacy Shield (EU/US) e PCI DSS (Padrão de Segurança de Dados para Indústria de Cartões de Pagamento) implementem estratégias de proteção de dados totalmente privadas. Isso significa que tanto o tráfego de aplicação quanto os dados de backup permanem dentro de redes privadas controladas pela organização.

    Como funciona e próximos passos

    Essa capacidade agora está disponível em todas as regiões da AWS onde o AWS Backup oferece suporte a bancos de dados SAP HANA em EC2. Para começar a utilizar o PrivateLink com backups de SAP HANA, os clientes precisam realizar duas ações principais:

    Essas configurações garantem que a infraestrutura de backup seja integrada completamente à rede privada da organização, eliminando qualquer ponto de exposição à internet pública.

    Impacto para empresas brasileiras

    Para organizações brasileiras que operam com SAP HANA e estão em setores regulados (instituições financeiras, plataformas de saúde, órgãos governamentais), essa novidade representa um avanço significativo na capacidade de atender exigências de conformidade de forma prática. O recurso simplifica a implementação de arquiteturas de nuvem verdadeiramente privadas, reduzindo a complexidade operacional e os riscos associados à exposição desnecessária de tráfego de dados.

    Fonte

    AWS Backup announces PrivateLink support for SAP HANA on AWS (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-backup-announces-privatelink-sap-hana-aws/)

  • Personalize a navegação de agentes de IA com proxies, perfis e extensões no Amazon Bedrock AgentCore Browser

    Agentes de IA com capacidades avançadas de navegação na web

    Agentes que navegam na web não funcionam bem apenas com navegação básica de páginas. Empresas que usam a AWS para construir soluções com inteligência artificial relatam necessidades específicas: agentes que mantêm contexto de sessão entre interações, tráfego roteado através de infraestrutura de proxy corporativo, e comportamentos customizados em tempo de execução.

    O AgentCore Browser oferece um ambiente de navegação seguro e isolado para agentes interagirem com aplicações web. Até agora, cada sessão começava do zero com configurações padrão e acesso direto à internet, limitando as capacidades de agentes em ambientes corporativos reais.

    A AWS anunciou três novas capacidades que mudam esse cenário: configuração de proxy, perfis de navegador, e extensões de navegador. Juntas, essas funcionalidades oferecem controle fino sobre como agentes de IA interagem com a web.

    Entendendo as três novas capacidades

    Essas capacidades funcionam de forma complementar, oferecendo controle granular sobre como sessões do AgentCore Browser se conectam à internet, que estado retêm e como se comportam:

    • Configuração de proxy: Roteia tráfego do navegador através de servidores proxy próprios, garantindo estabilidade de IP e integração com infraestrutura de rede corporativa.
    • Perfis de navegador: Persistem cookies e armazenamento local entre sessões, permitindo que agentes retomem fluxos de trabalho autenticados sem repetir login.
    • Extensões de navegador: Carregam extensões Chrome em sessões para customizar comportamento do navegador conforme a necessidade — desde bloqueio de anúncios até autenticação auxiliar.

    Perfis de navegador persistentes para agentes operacionais

    Equipes construindo agentes para testes de e-commerce, fluxos de trabalho autenticados e jornadas multipassos precisam de sessões que “lembram” do estado anterior. Sem perfis persistentes, agentes precisam se reautenticar e reconstruir contexto a cada início de sessão, adicionando latência e fragilidade.

    Perfis de navegador resolvem esse problema salvando e restaurando cookies e armazenamento local entre sessões. Um agente que fez login em um portal ontem pode continuar exatamente de onde parou hoje.

    Estabilidade de IP é outro requisito comum. Portais de saúde e financeiros validam sessões baseando-se em endereço IP de origem. Endereços IP rotativos da AWS causam ciclos frequentes de reautenticação que quebram fluxos de trabalho de longa duração. Suporte a proxy permite rotear tráfego através de servidores com IPs de saída estáveis, mantendo continuidade de sessão e satisfazendo requisitos de IP allowlisting.

    Organizações que rotam tráfego através de proxies corporativos precisam estender essa prática para agentes de IA em sessões de navegador. Configuração de proxy habilita acesso a páginas internas e recursos que requerem conectividade baseada em proxy.

    Extensões de navegador permitem customizações como bloqueio de anúncios, auxiliares de autenticação ou outras personalizações em nível de navegador. Quando combinadas com logging de proxy, essas capacidades ajudam a fornecer controle de acesso e evidência de auditoria que podem suportar programas de conformidade como FedRAMP, HITRUST e PCI.

    Configuração de proxy para roteamento de tráfego

    O AgentCore Browser agora suporta rotear tráfego do navegador através de servidores proxy externos próprios. Ao criar uma sessão de navegador com configuração de proxy, o AgentCore configura o navegador para rotear tráfego HTTP e HTTPS através dos servidores proxy especificados.

    Como funciona

    Você chama StartBrowserSession com proxyConfiguration especificando seu servidor proxy. Se usar autenticação, o AgentCore recupera credenciais de proxy do AWS Secrets Manager. A sessão de navegador inicia com sua configuração de proxy aplicada, e tráfego do navegador roteia através de seu servidor proxy baseado em regras de roteamento por domínio.

    Começando com proxies

    Complete os pré-requisitos antes de prosseguir.

    Passo 1: Criar um segredo de credenciais (se seu proxy requer autenticação)

    import boto3
    import json
    
    client = boto3.client('secretsmanager')
    client.create_secret(
        Name='my-proxy-credentials',
        SecretString=json.dumps({
            'username': '',
            'password': ''
        })
    )

    Passo 2: Criar uma sessão de navegador com configuração de proxy

    session_client = boto3.client('bedrock-agentcore', region_name='')
    response = session_client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="my-proxy-session",
        proxyConfiguration={
            "proxies": [{
                "externalProxy": {
                    "server": "",
                    "port": 8080,
                    "credentials": {
                        "basicAuth": {
                            "secretArn": "arn:aws:secretsmanager:::secret:"
                        }
                    }
                }
            }]
        }
    )
    print(f"Session ID: {response['sessionId']}")

    O campo credentials é opcional para proxies sem autenticação.

    Roteamento baseado em domínio

    Use domainPatterns para rotear domínios específicos através de proxies designados, e bypass.domainPatterns para domínios que devem conectar diretamente:

    proxyConfiguration={
        "proxies": [
            {
                "externalProxy": {
                    "server": "corp-proxy.example.com",
                    "port": 8080,
                    "domainPatterns": [".company.com", ".internal.corp"]
                }
            },
            {
                "externalProxy": {
                    "server": "general-proxy.example.com",
                    "port": 8080
                }
            }
        ],
        "bypass": {
            "domainPatterns": [".amazonaws.com"]
        }
    }

    Com essa configuração, requisições para *.company.com e *.internal.corp rotiam através do proxy corporativo, requisições para *.amazonaws.com contornam todos os proxies, e todo o resto roteia através do proxy geral.

    Precedência de roteamento

    Quando o AgentCore Browser processa uma requisição de saída, percorre três níveis de regras de roteamento para decidir onde enviar o tráfego. Primeiro verifica a lista de bypass. Se o domínio de destino corresponder a uma entrada em bypass.domainPatterns, a requisição conecta diretamente à internet sem usar proxy algum.

    Se o domínio não corresponder a uma regra de bypass, o AgentCore verifica cada domainPatterns de proxy em ordem e roteia a requisição através do primeiro proxy cuja regra corresponde. Se nenhuma regra de proxy corresponder, a requisição cai no proxy padrão — a entrada de proxy que não possui domainPatterns definida.

    Teste a nova funcionalidade de proxy com este exemplo de código.

    Perfis de navegador para persistência de estado

    Perfis de navegador permitem persistir e reutilizar dados de sessão entre múltiplas sessões de navegador, incluindo cookies e armazenamento local. Um agente que se autentica com um portal web em uma sessão pode restaurar esse estado em uma sessão posterior sem fazer login novamente.

    Isso é útil para fluxos de trabalho autenticados onde re-login adiciona latência, testes de e-commerce onde carrinhos de compras e dados de formulários precisam sobreviver entre sessões, e jornadas de usuário multipassos que abrangem múltiplas invocações de navegador.

    Ciclo de vida do perfil

    O ciclo de vida do perfil possui quatro estágios. Você começa chamando create_browser_profile() para criar um perfil nomeado. No final de uma sessão, você chama save_browser_session_profile() para capturar cookies e armazenamento local atuais naquele perfil. Ao iniciar uma nova sessão, você passa o identificador do perfil no parâmetro profileConfiguration de start_browser_session(), que restaura o estado salvo no novo navegador. Quando não precisar mais do perfil, você chama delete_browser_profile() para limpá-lo.

    O exemplo a seguir mostra um agente que adiciona itens a um carrinho de compras em uma sessão e verifica se persistem em uma sessão subsequente. Complete os pré-requisitos antes de prosseguir.

    import boto3
    
    control_client = boto3.client('bedrock-agentcore-control', region_name='')
    session_client = boto3.client('bedrock-agentcore', region_name='')
    
    # Create a browser profile
    profile = control_client.create_browser_profile(name="ecommerce_profile")
    profile_id = profile['profileId']
    
    # Session 1: Add items to cart
    session1 = session_client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="shopping-session-1"
    )
    # ... agent navigates and adds items to cart ...
    
    # Save session state to profile
    session_client.save_browser_session_profile(
        sessionId=session1['sessionId'],
        browserIdentifier="aws.browser.v1",
        profileIdentifier=profile_id
    )
    session_client.stop_browser_session(sessionId=session1['sessionId'], browserIdentifier="aws.browser.v1")
    
    # Session 2: Resume with saved profile
    session2 = session_client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="shopping-session-2",
        profileConfiguration={"profileIdentifier": profile_id}
    )
    # Cart items from Session 1 are now available

    Teste a nova funcionalidade de perfil com este exemplo de código.

    Extensões de navegador para customização

    Extensões de navegador permitem carregar extensões Chrome em sessões do AgentCore Browser para customizar como o navegador se comporta. Você empacota extensões como arquivos ZIP, carrega-as no Amazon Simple Storage Service (Amazon S3), e referencia-as ao iniciar uma sessão de navegador.

    Isso oferece acesso a funcionalidades disponíveis através da API de extensão Chrome, de roteamento de proxy e bloqueio de anúncios até auxiliares de autenticação e modificação de conteúdo. Por exemplo, você pode injetar tokens de autenticação para aplicações internas, remover anúncios e rastrear scripts que interferem com navegação de agente, ou modificar conteúdo de página para melhorar como agentes interagem com um site.

    Configurando extensões

    Sua extensão deve seguir o formato padrão de extensão Chromium e aderir às diretrizes de extensão Chromium. Complete os pré-requisitos antes de prosseguir.

    Fazer upload da extensão para Amazon S3:

    import boto3
    
    s3 = boto3.client('s3')
    s3.upload_file(
        'my-extension.zip',
        'amzn-s3-demo-bucket-extensions',
        'extensions/my-extension.zip'
    )

    Iniciar uma sessão com a extensão:

    import boto3
    
    region = ""
    client = boto3.client('bedrock-agentcore', region_name=region)
    response = client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="my-session-with-extensions",
        sessionTimeoutSeconds=1800,
        viewPort={
            'height': 1080,
            'width': 1920
        },
        extensions=[
            {
                "location": {
                    "s3": {
                        "bucket": "amzn-s3-demo-bucket-extensions",
                        "prefix": "extensions/my-extension.zip"
                    }
                }
            },
            {
                "location": {
                    "s3": {
                        "bucket": "amzn-s3-demo-bucket-extensions",
                        "prefix": "extensions/another-extension.zip",
                        "versionId": "abc123"
                    }
                }
            }
        ]
    )
    print(f"Session ID: {response['sessionId']}")
    print(f"Status: {response['status']}")
    print(f"Automation Stream: {response['streams']['automationStream']['streamEndpoint']}")

    Teste a nova funcionalidade de extensões com este exemplo de código.

    Reunindo tudo: casos de uso práticos

    Essas três capacidades — configuração de proxy, perfis de navegador e extensões — permitem casos de uso que antes eram impossíveis:

    • Fluxos de trabalho autenticados: Agentes que precisam permanecer autenticados em portais corporativos internos podem usar perfis para manter sessão e proxies para acessar redes restritas.
    • Testes de e-commerce: Agentes podem manter carrinhos de compras, preferências e histórico de busca entre sessões, simulando comportamento real de usuários.
    • Jornadas complexas: Fluxos que envolvem múltiplas etapas, autenticação e verificação podem agora se completar sem começar do zero.
    • Conformidade e auditoria: Proxy logging combinado com extensões oferece visibilidade e controle necessários para programas de conformidade corporativa.

    Próximos passos

    Para começar, consulte os tutoriais no repositório Amazon Bedrock AgentCore samples e a documentação do AgentCore Browser. Para mais informações sobre preços, visite Amazon Bedrock AgentCore Pricing.

    Essas três capacidades — configuração de proxy, perfis de navegador e extensões — oferecem ao AgentCore Browser o roteamento de proxy, persistência de sessão e controles de extensibilidade que empresas precisam para implantar agentes de IA que navegam na web em produção. Você pode rotear tráfego através de infraestrutura de proxy corporativo, manter continuidade de sessão entre interações, e customizar comportamento de navegador com extensões, tudo mantendo credenciais seguras no AWS Secrets Manager.

    Fonte

    Customize AI agent browsing with proxies, profiles, and extensions in Amazon Bedrock AgentCore Browser (https://aws.amazon.com/blogs/machine-learning/customize-ai-agent-browsing-with-proxies-profiles-and-extensions-in-amazon-bedrock-agentcore-browser/)

  • Amazon Connect agora oferece resumos em tempo real com IA e recomenda as próximas ações para Tarefas

    O que mudou no Amazon Connect

    A Amazon Connect acaba de receber uma atualização importante que traz inteligência artificial para acelerar o trabalho dos agentes. O serviço agora fornece resumos de tarefas gerados por IA com sugestões de próximas ações, permitindo que os agentes entendam os trabalhos pendentes mais rapidamente e os resolvam com maior eficiência.

    Como funciona na prática

    Imagine um agente recebendo uma tarefa para processar uma solicitação de reembolso enviada através de um formulário online. Em vez de ter que revisar manualmente todos os passos anteriores, a IA do Amazon Connect faz um resumo automático das atividades realizadas — como verificação de detalhes do pedido, confirmação de elegibilidade para devolução e validação do método de pagamento — e então apresenta os próximos passos recomendados para completar o reembolso.

    Essa abordagem reduz significativamente o tempo que o agente gasta entendendo o contexto da tarefa e o coloca imediatamente em condição de avançar com a resolução.

    Como ativar o recurso

    Para aproveitar essa funcionalidade, é necessário adicionar o bloco de fluxo do assistente Connect aos seus fluxos antes de uma tarefa ser atribuída ao agente. Além disso, é possível orientar as recomendações do assistente de tarefas alimentado por IA através da adição de bases de conhecimento, personalizando as sugestões conforme a realidade do seu negócio.

    Disponibilidade

    Este novo recurso está disponível em todas as regiões da AWS onde o Amazon Connect oferece assistência em tempo real para agentes. Para começar a implementação, consulte a documentação de ajuda, explore a página de preços ou visite o site do Amazon Connect para obter informações completas.

    O impacto para centros de contato

    Essa integração de IA representa um passo significativo na automação de processos dentro de centros de contato. Ao reduzir o tempo de compreensão de cada tarefa, os agentes podem aumentar sua produtividade e oferecer um atendimento mais rápido aos clientes. A sugestão de próximas ações também ajuda a padronizar os processos, garantindo que os fluxos corretos sejam seguidos independentemente da experiência do agente.

    Fonte

    Amazon Connect now provides real time AI-powered overviews and recommended next actions for Tasks (https://aws.amazon.com/about-aws/whats-new/2026/02/connect-tasks-ai-assistance)