Author: Make.com Service User

  • AWS Transform Custom agora oferece suporte a PrivateLink e expande para Europa

    AWS Transform Custom: novas regiões e segurança aprimorada

    A AWS anunciou duas melhorias importantes para o serviço AWS Transform Custom: suporte a PrivateLink (Conexão Privada) e disponibilidade em uma nova região geográfica. Além da região existente US East (N. Virginia), o serviço agora está disponível em Europe (Frankfurt), expandindo as opções para organizações que necessitam de infraestrutura mais próxima aos usuários europeus.

    O que é AWS Transform Custom?

    O AWS Transform Custom é uma ferramenta desenhada para ajudar as organizações a reduzir débito técnico — aquele acúmulo de código desatualizado e processos manuais que compromete a produtividade. O serviço automatiza tarefas repetitivas de transformação de código, como:

    • Atualizações de versão de linguagens de programação
    • Migrações de APIs
    • Atualizações de frameworks

    A solução é voltada especialmente para equipes de desenvolvimento empresariais e parceiros de consultoria que precisam executar transformações de código consistentes e repetíveis em grandes repositórios de código.

    Como funciona a transformação de código?

    O AWS Transform Custom permite que as equipes criem definições de transformação personalizadas usando linguagem natural, documentação e exemplos de código. Alternativamente, a AWS oferece transformações gerenciadas já pronta para cenários comuns, incluindo:

    • Atualizações de versão de Java
    • Atualizações de versão de Python
    • Atualizações de versão de Node.js

    Um diferencial importante é que o serviço funciona com aprendizado contínuo: a qualidade das transformações melhora com cada execução ao longo do tempo, tornando o processo progressivamente mais eficiente e preciso.

    Segurança com PrivateLink

    A adição de suporte a AWS PrivateLink (Conexão Privada) é uma mudança significativa para organizações com requisitos rigorosos de segurança. Com essa funcionalidade, os clientes conseguem acessar o AWS Transform Custom diretamente de suas Amazon VPCs (Nuvens Privadas Virtuais) sem rotear tráfego pela internet pública.

    Essa abordagem ajuda as organizações a:

    • Atender requisitos de conformidade regulatória mais rigorosos
    • Reduzir a exposição a riscos de segurança
    • Manter o tráfego de rede isolado em uma rede privada

    Próximos passos

    Para conhecer mais detalhes sobre o AWS Transform Custom, a AWS disponibiliza a página do produto e o guia do usuário com informações completas sobre como começar a usar o serviço.

    Fonte

    AWS Transform custom adds AWS PrivateLink support and expands to Europe (Frankfurt) Region (https://aws.amazon.com/about-aws/whats-new/2026/01/aws-transform-custom-privatelink-europe-frankfurt-region/)

  • Segurança na Inferência Distribuída do Amazon Bedrock: Estratégias Geográficas e Globais

    Inferência Distribuída em Escala: O Desafio da Segurança

    A adoção de IA generativa vem acelerando significativamente. Organizações enfrentam agora o desafio de construir aplicações de IA operacionais em produção, em larga escala, mantendo a eficiência e a confiabilidade. O Amazon Bedrock introduz uma funcionalidade estratégica para esse cenário: os perfis de inferência distribuída (CRIS), que permitem distribuir o processamento de inferência de forma contínua por múltiplas Regiões AWS. Esse mecanismo oferece maior throughput e mantém as aplicações responsivas, mesmo sob carga intensa.

    Porém, escalar globalmente exige compreensão profunda dos controles de segurança envolvidos. Este artigo examina as práticas e considerações de segurança para implementar perfis de inferência distribuída do Bedrock, orientando organizações que precisam atender requisitos regionais de conformidade ou que desejam otimizar recursos em escala global.

    Entendendo a Arquitetura de Inferência Distribuída

    Como Funciona o Roteamento de Requisições

    Os perfis de inferência distribuída operam sobre dois conceitos-chave. A Região de Origem é aquela de onde a chamada de API é feita. A Região de Destino é uma Região para onde o Amazon Bedrock roteia a requisição de processamento.

    Quando você invoca um perfil de inferência distribuída, a requisição segue um caminho de roteamento inteligente. Ela origina-se na Região de origem e é automaticamente direcionada para uma das Regiões de destino definidas no perfil. Todo esse fluxo ocorre pela Rede Global da AWS, gerenciada pelo Amazon Bedrock, com criptografia de ponta a ponta para dados em trânsito.

    Um detalhe crítico: a inferência distribuída não altera o local onde seus dados são armazenados. Nenhum dado do cliente é persistido em Regiões de destino. Logs gerenciados pelo cliente, bases de conhecimento e configurações armazenadas permanecem exclusivamente na Região de origem. As respostas retornam criptografadas para sua aplicação na Região de origem.

    Dois Modelos de Operação: Geográfico e Global

    O Bedrock oferece dois tipos de perfis de inferência distribuída, cada um atendendo diferentes necessidades de conformidade e otimização.

    Inferência Distribuída Geográfica: O Amazon Bedrock seleciona automaticamente a Região ótima dentro de uma geografia definida (EUA, União Europeia, Austrália, Japão) para processar sua requisição. Este modelo mantém o processamento dentro de limites geográficos específicos, atendendo requisitos de residência de dados regional. É ideal para organizações com regulamentações rigorosas de conformidade regional.

    Inferência Distribuída Global: Este modelo amplifica as capacidades da inferência distribuída, roteando requisições para Regiões comerciais da AWS em todo o mundo, otimizando recursos disponíveis e habilitando maior throughput de modelo. Roteia requisições sem restrições geográficas. Adequado para organizações que desejam cobertura mais ampla e custo-benefício em throughput.

    Se sua organização possui requisitos rigorosos de residência de dados ou conformidade, é essencial avaliar cuidadosamente se a inferência distribuída alinha-se com suas políticas e regulamentações, pois os dados de inferência podem ser processados em múltiplas Regiões pré-configuradas.

    Controles de Acesso e Conformidade Regulatória

    Permissões IAM e Políticas de Controle de Serviço

    Por padrão, usuários e funções dentro de sua conta AWS não possuem permissão para criar, modificar ou usar recursos do Amazon Bedrock. O acesso é controlado através de dois mecanismos principais: políticas AWS Identity and Access Management (IAM) para permissões granulares de usuário e função, e Políticas de Controle de Serviço (SCPs) para guardrails e restrições em toda a organização.

    Para usar inferência distribuída no Bedrock, os usuários devem possuir permissões IAM específicas. Se SCPs estão anexadas à sua conta, elas também devem permitir as ações necessárias. A complexidade aumenta porque os requisitos diferem entre os dois tipos de perfil.

    Diferenças de Requisitos: Geográfico vs. Global

    Para inferência distribuída geográfica, as políticas IAM devem permitir acesso aos seguintes recursos:

    • O perfil de inferência distribuída específico da geografia (com prefixos como “us”, “au”, “jp”, “eu”)
    • O modelo de fundação na Região de origem
    • O modelo de fundação em TODAS as Regiões de destino listadas no perfil

    As Políticas de Controle de Serviço devem ser atualizadas para incluir condições específicas de Região, permitindo TODAS as Regiões de destino listadas no perfil geográfico.

    Para inferência distribuída global, as políticas IAM devem permitir:

    • O perfil de inferência distribuída global na Região de origem (com prefixo “global” no ID)
    • O modelo de fundação na Região de origem
    • O modelo de fundação global usando a condição aws:RequestedRegion com valor “unspecified”

    As Políticas de Controle de Serviço globais devem garantir que aws:RequestedRegion: "unspecified" não esteja incluído em listas de Regiões negadas, pois as requisições de inferência distribuída global usam este valor.

    Implementação Prática de Políticas IAM

    Para inferência distribuída geográfica, um exemplo de política permite que um usuário IAM invoque um perfil de inferência distribuída do Claude Sonnet 4.5 para o EUA, originário de us-east-1 com destinos em us-east-1, us-east-2 e us-west-2:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "GrantGeoCrisInferenceProfileAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
          ]
        },
        {
          "Sid": "GrantGeoCrisModelAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
            "arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
            "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
          ],
          "Condition": {
            "StringEquals": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
            }
          }
        }
      ]
    }

    A primeira declaração concede acesso à invocação do perfil de inferência distribuída. A segunda declaração concede acesso aos modelos de fundação em todas as Regiões (origem e destinos), mas apenas quando a chamada é feita através do perfil especificado.

    Para inferência distribuída global, a política é ligeiramente diferente:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
          ]
        },
        {
          "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
          ],
          "Condition": {
            "StringEquals": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
            }
          }
        },
        {
          "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
          "Effect": "Allow",
          "Action": "bedrock:InvokeModel",
          "Resource": [
            "arn:aws:bedrock:::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
          ],
          "Condition": {
            "StringEquals": {
              "aws:RequestedRegion": "unspecified",
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0"
            }
          }
        }
      ]
    }

    Nesta política, a primeira declaração concede permissão para invocar o perfil na Região de origem. A segunda permite invocar o modelo na Região de origem, mas apenas através do perfil especificado. A terceira permite invocar o modelo global em qualquer Região comercial suportada, restringindo através da condição aws:RequestedRegion: "unspecified".

    Governança: Desabilitando Inferência Distribuída

    Organizações com requisitos rigorosos de residência de dados podem precisar desabilitar completamente a inferência distribuída. Para isso, existem duas abordagens complementares.

    Para restringir inferência distribuída geográfica, implemente uma Política de Controle de Serviço de negação que bloqueie todas as invocações de perfis de inferência distribuída que não usem prefixos específicos:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyNonUSGeographicCRIS",
          "Effect": "Deny",
          "Action": "bedrock:*",
          "Resource": "*",
          "Condition": {
            "Null": {
              "bedrock:InferenceProfileArn": "false"
            },
            "ArnNotLike": {
              "bedrock:InferenceProfileArn": [
                "arn:aws:bedrock:*:*:inference-profile/us.*"
              ]
            }
          }
        }
      ]
    }

    Para desabilitar inferência distribuída global, implemente uma política que negue requisições com aws:RequestedRegion: "unspecified":

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Deny",
          "Action": "bedrock:*",
          "Resource": "*",
          "Condition": {
            "StringLike": {
              "aws:RequestedRegion": [
                "unspecified"
              ]
            },
            "ArnLike": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*"
            }
          }
        }
      ]
    }

    Monitoramento e Auditoria

    Todas as chamadas de inferência distribuída são registradas na Região de origem. As entradas do AWS CloudTrail incluem um campo adicional additionalEventData para rastreamento. Este campo especifica a Região real onde a inferência foi processada, permitindo auditoria completa do fluxo de dados.

    Um exemplo típico mostra uma chamada InvokeModel com inferência distribuída global, originária de ap-southeast-2, sendo processada em ap-southeast-4, com o CloudTrail registrando essa Região de processamento para fins de conformidade e auditoria.

    Integração com AWS Control Tower

    Para organizações que usam AWS Control Tower, o gerenciamento de inferência distribuída requer ajustes nas Políticas de Controle de Serviço. A recomendação é usar Customizações para AWS Control Tower em vez de editar manualmente as SCPs, evitando desvios de configuração.

    Para habilitar inferência distribuída global em ambientes Control Tower, é necessário modificar as SCPs criadas automaticamente para incluir “unspecified” na lista de Regiões permitidas especificamente para ações do Amazon Bedrock, mantendo restrições regionais para outros serviços.

    Considerações Sobre Regiões AWS

    O Amazon Bedrock utiliza perfis de inferência para rotear requisições através de todas as Regiões listadas no perfil, sejam Regiões ativadas por padrão ou que requeiram ativação manual na sua conta AWS. A abordagem simplifica a operação ao eliminar a necessidade de ativar múltiplas Regiões manualmente.

    Existem dois tipos de Regiões Regiões comerciais da AWS. Regiões ativadas por padrão (como N. Virginia, Irlanda e Sydney) e Regiões que requerem ativação manual (como Melbourne, Emirados Árabes e Hyderabad). As Regiões ativadas manualmente são mais recentes, introduzidas após 20 de março de 2019.

    Conclusão: Segurança em Escala

    A inferência distribuída no Amazon Bedrock oferece capacidades poderosas para construir aplicações de IA generativa escaláveis e resilientes. Compreender as interações fundamentais entre inferência distribuída e controles de segurança permite que organizações desbloqueiem essa funcionalidade de forma segura, mantendo sua postura de segurança.

    Implementando políticas IAM precisas, Políticas de Controle de Serviço bem estruturadas e monitoramento robusto via CloudTrail, sua organização consegue inovar com inferência distribuída sem comprometer conformidade ou governança.

    Fonte

    Securing Amazon Bedrock cross-Region inference: Geographic and global (https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-cross-region-inference-geographic-and-global/)

  • Amazon Lex aprimora modelos de reconhecimento de voz para inglês

    Reconhecimento de voz neural no Amazon Lex

    A AWS anunciou a disponibilização de um modelo de Reconhecimento Automático de Fala Neural (ASR neural) no Amazon Lex dedicado ao idioma inglês. Essa atualização representa um avanço significativo na capacidade das aplicações em reconhecer e processar comandos de voz com maior precisão e naturalidade.

    Capacidades do novo modelo

    O modelo neural foi treinado utilizando dados de múltiplas variantes de inglês, permitindo que sistemas de bots de voz identifiquem com maior acurácia padrões de fala conversacional em diferentes contextos. Uma característica importante é sua capacidade de lidar com sotaques regionais e de falantes que utilizam inglês como segundo idioma.

    Essa melhoria na compreensão de fala reduz a necessidade de clientes finais repetirem comandos, o que aumenta as taxas de sucesso em interações de autoatendimento. Para sistemas que dependem fortemente de automação por voz, essa é uma evolução particularmente relevante.

    Como ativar o recurso

    A configuração é direta: para aproveitar o novo modelo neural, basta selecionar a opção “Neural” nas configurações de reconhecimento de voz no painel de localização do seu bot. O processo não requer alterações complexas na infraestrutura existente.

    Disponibilidade

    O recurso está disponível em todas as regiões comerciais AWS onde os serviços Amazon Connect e Lex operacionalizam suas funcionalidades. Para mais informações técnicas e detalhes de implementação, a AWS oferece documentação completa do Amazon Lex e também mantém informações adicionais no site do Amazon Connect sobre como integrar esses serviços para entregar experiências de autoatendimento mais eficientes.

    Impacto para arquiteturas de voz e atendimento

    Para empresas que constroem soluções de autoatendimento por voz, essa atualização contribui para reduzir fricções na experiência do usuário final. O melhor reconhecimento de padrões de fala conversacional impacta diretamente na redução de transferências para atendimento humano e melhora indicadores de satisfação em sistemas automatizados.

    Fonte

    Amazon Lex launches improved speech recognition models for English (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-lex-improved-speech-recognition-models-english)

  • Automatize sua resposta de segurança em escala com o AWS Security Hub

    A evolução da gestão centralizada de segurança na nuvem

    A AWS lançou uma versão melhorada do AWS Security Hub, oferecendo novas formas para organizações gerenciarem e responderem a achados de segurança. O Security Hub aprimorado auxilia na melhoria da postura de segurança organizacional e simplifica operações de segurança em nuvem ao centralizar a gestão de segurança em todo o ambiente da Amazon Web Services (AWS).

    O Security Hub transformou a maneira como as organizações tratam achados de segurança através de capacidades avançadas de automação, incluindo análise de risco em tempo real, correlação automática e contexto enriquecido. Essas funcionalidades permitem que as equipes priorizem problemas críticos e reduzam tempos de resposta.

    A automação também garante que procedimentos de resposta sejam consistentes e que requisitos de conformidade sejam atendidos. O AWS Security Hub CSPM (Gerenciamento de Postura de Segurança em Nuvem) agora é parte integral dos mecanismos de detecção do Security Hub.

    Visibilidade centralizada e priorização baseada em risco

    O Security Hub oferece visibilidade centralizada através de múltiplos serviços de segurança da AWS, proporcionando uma visão unificada do ambiente em nuvem. Isso inclui visualizações de priorização baseada em risco, visualização de caminhos de ataque e análise de tendências que ajudam a compreender padrões de segurança ao longo do tempo.

    Este é o terceiro artigo de uma série sobre as novas capacidades do Security Hub. Para contexto: a série anterior discutiu como o Security Hub unifica achados entre serviços da AWS para simplificar a gestão de risco, e também apresentou as etapas para realizar uma Prova de Conceito bem-sucedida.

    Por que automação importa em segurança em nuvem

    As organizações frequentemente operam em centenas de contas da AWS, múltiplas regiões e diversos serviços, cada um gerando achados que precisam ser triados, investigados e processados. Sem automação, equipes de segurança enfrentam alto volume de alertas, duplicação de esforço e risco de respostas atrasadas a questões críticas.

    Processos manuais não conseguem acompanhar operações em nuvem. A automação transforma as operações de segurança de três formas fundamentais:

    • Filtragem e priorização: A automação filtra e prioriza achados conforme seus critérios, mostrando à equipe apenas alertas relevantes.
    • Resposta imediata: Quando problemas são detectados, respostas automatizadas disparam instantaneamente, sem necessidade de intervenção manual.
    • Consistência em escala: Ao gerenciar múltiplas contas da AWS, a automação aplica políticas e fluxos de trabalho consistentes através do seu ambiente, transferindo a equipe de segurança de “apagar incêndios” para gerenciamento proativo de risco.

    Desenhando estratégias de roteamento para achados de segurança

    Com o Security Hub configurado, é hora de desenhar uma estratégia de roteamento para seus achados e notificações. Ao projetar essa estratégia, questione se sua configuração atual do Security Hub atende seus requisitos de segurança. Considere se as automações do Security Hub podem ajudá-lo a atender frameworks de conformidade como NIST 800-53 e identifique KPIs e métricas para mensurar se sua estratégia de roteamento funciona.

    As automações e respostas automáticas do Security Hub podem ajudar a cumprir esses requisitos, mas é crucial compreender como suas equipes de conformidade, respondentes de incidentes, pessoal de operações de segurança e demais stakeholders operam diariamente. Por exemplo: suas equipes usam o Console de Gerenciamento da AWS para o Security Hub regularmente? Ou você precisa enviar a maioria dos achados para ferramentas de gerenciamento de sistemas de TI (ITSM), como Jira ou ServiceNow, ou plataformas terceirizadas de orquestração, automação e resposta de segurança (SOAR)?

    Em seguida, crie e mantenha um inventário de aplicações críticas. Isso ajuda a ajustar a severidade de achados baseado em contexto empresarial e seus playbooks de resposta a incidentes. Considere um cenário onde o Security Hub identifica uma vulnerabilidade de severidade média em uma instância de Elastic Compute Cloud. Isoladamente, isso pode não disparar ação imediata. Ao adicionar contexto empresarial — como objetivos estratégicos ou criticidade para o negócio — você pode descobrir que essa instância hospeda uma aplicação crítica de processamento de pagamentos, revelando o risco real. Implementando regras de automação do Security Hub com contexto enriquecido, esse achado pode ser elevado para severidade crítica e automaticamente roteado para ServiceNow para rastreamento imediato.

    Além disso, usando automação do Security Hub com Amazon EventBridge, você pode disparar um documento de automação do AWS Systems Manager Automation para isolar a instância EC2 para trabalho forense de segurança.

    Como o Security Hub oferece formato e esquema OCSF, você pode utilizar os extensos elementos de esquema que o OCSF oferece para direcionar achados para automação e ajudar sua organização a atender requisitos de estratégia de segurança.

    Casos de uso em automação de segurança

    As automações do Security Hub suportam diversos casos de uso. Converse com suas equipes para entender quais se aplicam às suas necessidades e objetivos de segurança:

    Remediação automática de achados

    Use remediação automática de achados para corrigir automaticamente problemas de segurança conforme são detectados. Padrões de suporte incluem remediação direta (disparar funções AWS Lambda para corrigir configurações incorretas), marcação de recursos (adicionar tags em recursos não conformes), correção de configuração (atualizar configurações de recursos para corresponder políticas de segurança) e ajuste de permissões (modificar políticas do AWS Identity and Access Management (IAM) para remover permissões excessivas).

    Exemplo:

    IF finding.type = "Software and Configuration Checks/Industry and Regulatory Standards/CIS AWS Foundations Benchmark"
    AND finding.title CONTAINS "S3 buckets should have server-side encryption enabled"
    THEN invoke Lambda function "enable-s3-encryption"

    Integração de achados em fluxo de trabalho

    Integre achados em seus fluxos de trabalho roteando-os para as equipes e sistemas apropriados. Padrões de suporte incluem criação de tickets (gerar tickets em Jira ou ServiceNow para revisão manual), atribuição de equipes (rotear achados para equipes específicas baseado em propriedade de recursos) e roteamento baseado em severidade (direcionar achados críticos para resposta a incidentes, outros para filas regulares).

    Exemplo:

    IF finding.severity = "CRITICAL" AND finding.productName = "Amazon GuardDuty"
    THEN send to SNS topic "security-incident-response-team"
    ELSE IF finding.productFields.resourceOwner = "payments-team"
    THEN send to SNS topic "payments-security-review"

    Enriquecimento automático de achados

    Use enriquecimento de achados para adicionar contexto que melhore eficiência de triagem. Padrões incluem adição de contexto de recursos (adicionar contexto empresarial, informações de proprietário e classificação de dados), análise histórica (adicionar informações sobre achados similares anteriores), pontuação de risco personalizada (calcular scores de risco customizados baseado em valor do ativo e contexto de ameaça) e correlação de vulnerabilidades (ligar achados a CVEs conhecidas ou inteligência de ameaças).

    Controles de segurança customizados

    Use controles de segurança customizados para atender requisitos específicos da organização. Padrões incluem imposição de política customizada (verificar conformidade com padrões internos), regras específicas do negócio (aplicar regras baseado em unidade de negócio ou tipo de aplicação), controles compensatórios (implementar alternativas quando controles primários não podem ser aplicados) e exceções temporárias (lidar com desvios aprovados de padrões de segurança).

    Relatório de conformidade e coleta de evidência

    Agilize documentação de conformidade e coleta de evidência. Padrões incluem captura de evidência (armazenar evidência de conformidade em buckets S3 designados), criação de trilha de auditoria (documentar ações de remediação para auditores), dashboard de conformidade (atualizar métricas de status de conformidade) e mapeamento regulatório (rotular achados com frameworks de conformidade relevantes).

    Configurando automação no Security Hub

    Passo 1: Ative o Security Hub e serviços integrados

    Como primeiro passo, siga as instruções para ativar o Security Hub. Nota importante: o Security Hub é potencializado por Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM e Amazon Macie. Esses serviços também precisam ser habilitados para obter valor completo do Security Hub.

    Passo 2: Crie regras de automação

    Após o Security Hub coletar achados, você pode criar regras de automação para atualizar e rotear os achados para as equipes apropriadas. Os passos para criar regras de automação no Security Hub que atualizam detalhes de achados ou configurar integrações terceirizadas como Jira ou ServiceNow podem ser encontrados na documentação específica.

    Com essas regras de automação, o Security Hub avalia achados contra a regra definida e então executa a atualização apropriada ou chama APIs para enviar achados a Jira ou ServiceNow. O Security Hub envia uma cópia de cada achado para o Amazon EventBridge, permitindo que você implemente suas próprias respostas automatizadas se necessário, para casos de uso fora do escopo das regras de automação do Security Hub.

    Além de enviar cópias de cada achado para EventBridge, o Security Hub classifica e enriquece achados de segurança conforme contexto empresarial, entregando-os aos serviços downstream apropriados (como ferramentas ITSM) para resposta rápida.

    Melhores práticas para automação de segurança

    As regras de automação do Security Hub oferecem capacidades para atualização automática de achados e integração com outras ferramentas. Ao implementar regras de automação, siga estas melhores práticas:

    • Gestão centralizada: Apenas a conta administradora do Security Hub pode criar, editar, deletar e visualizar regras de automação. Garanta controle de acesso e gestão apropriados dessa conta.
    • Implantação regional: Regras de automação podem ser criadas em uma região da AWS e aplicadas através de regiões configuradas. Ao usar agregação de região, você pode apenas criar regras na região inicial.
    • Critérios específicos: Defina claramente os critérios que achados devem corresponder para a regra de automação aplicar. Isso pode incluir atributos de achados, níveis de severidade, tipos de recurso ou IDs de conta membro.
    • Entenda a ordem de regras: A ordem importa quando múltiplas regras aplicam ao mesmo achado ou campo de achado. O Security Hub aplica regras com valor numérico menor primeiro. Para mais informações, consulte a documentação sobre atualização da ordem de regras no Security Hub.
    • Descrições claras: Inclua descrição de regra detalhada para fornecer contexto aos respondentes e proprietários de recursos, explicando o propósito e ações esperadas da regra.
    • Use automação para eficiência: Use regras de automação para atualizar automaticamente campos de achados (como severidade e status de fluxo de trabalho), suprimir achados de baixa prioridade, ou criar tickets em ferramentas terceirizadas como Jira ou ServiceNow para achados correspondentes a atributos específicos.
    • Considere EventBridge para ações externas: Enquanto regras de automação lidam com atualizações internas de achados do Security Hub, use regras EventBridge para disparar ações fora do Security Hub, como invocar funções AWS Lambda ou enviar notificações para tópicos Amazon Simple Notification Service (Amazon SNS) baseado em achados específicos. As regras de automação têm efeito antes das regras EventBridge serem aplicadas. Para mais informações, consulte regras de automação em EventBridge.
    • Gerencie limites de regras: Existe um limite máximo de 100 regras de automação por conta administradora. Planeje sua criação de regras estrategicamente para permanecer dentro desse limite.
    • Revise e refine regularmente: Periodicamente revise regras de automação, especialmente regras de supressão, para garantir que permaneçam relevantes e efetivas, ajustando-as conforme sua postura de segurança evolui.

    Consolidando operações de segurança em escala

    As automações do Security Hub permitem triar, rotear e responder a achados mais rapidamente através de uma solução unificada de segurança em nuvem com gestão centralizada. Através da abordagem intuitiva e flexível de automação que o Security Hub oferece, suas equipes de segurança podem tomar decisões confiantes, baseadas em dados, sobre achados do Security Hub que se alinhem com a estratégia de segurança geral da organização.

    Com as capacidades de automação do Security Hub, você pode gerenciar segurança centralmente através de centenas de contas enquanto suas equipes focam em problemas críticos que mais importam para seu negócio. Implementando as capacidades de automação descritas neste artigo, você consegue simplificar tempos de resposta em escala, reduzir esforço manual e melhorar sua postura de segurança geral através de fluxos de trabalho consistentes e automatizados.

    Fonte

    Streamline security response at scale with AWS Security Hub automation (https://aws.amazon.com/blogs/security/streamline-security-response-at-scale-with-aws-security-hub-automation/)

  • Pacote de Conformidade PCI DSS Outono 2025 está disponível

    Novidades na Certificação PCI DSS

    A Amazon Web Services (AWS) anunciou a inclusão de dois serviços adicionais e uma nova região geográfica no escopo de sua certificação Payment Card Industry Data Security Standard (PCI DSS). Essa atualização oferece aos clientes mais opções para implementar cargas de trabalho reguladas enquanto mantêm conformidade com os rigorosos padrões de segurança de dados de cartões de pagamento.

    Serviços Recém-Adicionados

    Os dois novos serviços agora certificados são:

    Expansão Geográfica

    Além dos serviços, a região Asia Pacific (Taipei) foi adicionada ao programa de certificação PCI DSS, ampliando as opções de localidade para organizações que precisam manter dados de cartão de pagamento em conformidade regulatória em diferentes regiões.

    Componentes do Pacote de Conformidade

    O pacote de conformidade PCI DSS da AWS é composto por dois elementos principais:

    • Attestation of Compliance (AOC): Documento que demonstra que a AWS foi validada com sucesso conforme os requisitos do padrão PCI DSS, avaliada por um avaliador qualificado independente.
    • AWS Responsibility Summary: Guia que orienta os clientes da AWS sobre suas responsabilidades específicas na implementação e operação de ambientes seguros para processamento de dados de cartão de pagamento.

    A avaliação foi conduzida pela Coalfire, uma empresa qualificada como Qualified Security Assessor (QSA) terceirizada.

    Inovação em Formatos de Conformidade

    Um destaque importante dessa atualização é a disponibilidade dos relatórios de conformidade em formato Open Security Controls Assessment Language (OSCAL). Trata-se de um padrão aberto mantido pelo NIST, baseado em JSON estruturado para leitura por máquinas, permitindo automação de workflows e redução de processamento manual em auditorias de conformidade.

    A AWS é a primeira provedora de nuvem a oferecer relatórios de conformidade neste formato, um avanço significativo rumo a processos de conformidade modernizados e automatizáveis.

    Acesso e Implementação Prática

    Os clientes podem acessar toda a documentação de certificação PCI DSS através do AWS Artifact, um portal de autoatendimento que oferece acesso sob demanda aos relatórios de conformidade da AWS. Esse recurso simplifica processos de auditoria e integração com fluxos de conformidade existentes.

    A lista completa de serviços em escopo de conformidade pode ser consultada na página AWS Services in Scope by Compliance Program.

    Próximas Etapas

    Para conhecer mais sobre os programas de conformidade e segurança da AWS, consulte a AWS Compliance Programs page. Dúvidas sobre implementação ou aspectos específicos de conformidade podem ser direcionadas à equipe de Compliance Support ou ao AWS Support.

    Fonte

    Fall 2025 PCI DSS compliance package available now (https://aws.amazon.com/blogs/security/fall-2025-pci-dss-compliance-package-available-now/)

  • SageMaker HyperPod agora valida quotas de serviço antes de criar clusters

    Validação de Quotas no SageMaker HyperPod

    A AWS anunciou uma melhoria significativa no console do SageMaker HyperPod: a plataforma agora valida automaticamente as quotas de serviço da sua conta antes de iniciar o processo de criação de clusters. Essa validação prévia permite que você confirme a disponibilidade suficiente de recursos antes que o provisionamento realmente comece, evitando falhas desnecessárias e economizando tempo.

    O Desafio de Provisionar Clusters de IA/ML em Larga Escala

    O SageMaker HyperPod é o serviço da AWS projetado para provisionar clusters resilientes destinados à execução de cargas de trabalho de IA e Aprendizado de Máquina (IA/ML), incluindo o desenvolvimento de modelos de ponta como Modelos de Linguagem Grande (LLMs), modelos de difusão e modelos de fundação (FMs).

    Quando você cria clusters de IA/ML em larga escala, é essencial garantir que sua conta possua quotas suficientes para instâncias, armazenamento e recursos de rede. Anteriormente, essa validação de quotas exigia verificações manuais em vários serviços da AWS, o que frequentemente resultava em tentativas de criação de cluster falharem e consumiam tempo significativo caso você não solicitasse aumentos de limites de quotas com antecedência.

    Como a Validação Automática Funciona

    A nova capacidade de validação de quotas no console do SageMaker HyperPod verifica automaticamente as quotas em nível de conta contra a configuração do seu cluster. Esse processo inclui a validação de:

    • Limites de tipo de instância
    • Tamanhos de volume do EBS (Elastic Block Store)
    • Quotas relacionadas à VPC (Virtual Private Cloud)

    O resultado da validação é apresentado em uma tabela clara que exibe a utilização esperada, os valores de quota aplicados e o status de conformidade para cada quota. Quando há risco de exceder alguma quota, você recebe um alerta de aviso com links diretos para o console de Quotas de Serviço, facilitando a solicitação de aumentos quando necessário.

    Disponibilidade e Próximos Passos

    Esse recurso está disponível em todas as regiões da AWS que oferecem suporte ao Amazon SageMaker HyperPod. Para consultar a lista completa das verificações de validação de quota executadas, consulte a documentação técnica do SageMaker HyperPod.

    Fonte

    Amazon SageMaker HyperPod now validates service quotas before creating clusters on console (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-sagemaker-hyperpod-validates-service-quotas/)

  • Amazon Lex lança detecção de atividade de voz com sensibilidade configurável

    Nova Funcionalidade de Sensibilidade Configurável

    A AWS expandiu as capacidades do Amazon Lex com a introdução de três níveis de sensibilidade para detecção de atividade de voz (VAD — Voice Activity Detection). Essa adição permite que os desenvolvedores personalizem o comportamento dos bots de conversação de acordo com as características acústicas do ambiente onde serão deployados.

    A detecção de atividade de voz é um componente essencial em sistemas de conversação por voz. Ela funciona identificando quando um usuário começa e termina de falar, filtrando ruídos de fundo e garantindo que o bot processe apenas as falas reais. Com a nova funcionalidade, essa detecção pode ser ajustada de maneira mais granular.

    Os Três Níveis de Sensibilidade

    Padrão (Default)

    O modo Padrão é recomendado para a maioria dos cenários. Ele foi calibrado para ambientes com níveis típicos de ruído de fundo, equilibrando sensibilidade e precisão sem requerir configurações especiais. Para empresas iniciando com bots conversacionais, este é o ponto de partida mais seguro.

    Alta (High)

    O nível Alto foi projetado para espaços com ruído consistente e moderado — escritórios movimentados, áreas de varejo ou lojas são exemplos típicos. Este modo oferece maior tolerância ao ruído mantendo a capacidade de capturar intenções de fala claras, sendo útil em ambientes corporativos ou comerciais dinâmicos.

    Máxima (Maximum)

    O nível Máximo fornece a maior tolerância a ruído ambiental e é indicado para cenários de alta perturbação sonora — pisos de manufatura, canteiros de obra, ou ambientes externos com ruído significativo. Este é o modo mais robusto para situações desafiadoras acusticamente.

    Como Configurar

    A configuração da sensibilidade do VAD é realizada diretamente no designer de IA Conversacional do Amazon Connect. Os desenvolvedores podem estabelecer o nível de sensibilidade ao criar uma nova localidade de bot ou ao atualizar uma localidade existente, oferecendo flexibilidade para ajustes contínuos conforme o bot é refinado em produção.

    Disponibilidade

    Este recurso está disponível em todas as regiões comerciais da AWS onde o Amazon Connect e o Lex operam. Para mais detalhes técnicos sobre implementação e boas práticas, consulte a documentação do Amazon Lex. Você também pode explorar o site do Amazon Connect para entender como estas duas soluções trabalham em conjunto na criação de experiências de autoatendimento para clientes finais.

    Fonte

    Amazon Lex launches configurable voice activity detection sensitivity (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-lex-configurable-voice-activity-detection-sensitivity/)

  • Amazon Inspector ganha suporte a Java Gradle e expande cobertura de ecossistemas

    Expansão do Amazon Inspector com novo suporte a Java Gradle

    A AWS anunciou uma atualização significativa no Amazon Inspector, seu serviço automatizado de gerenciamento de vulnerabilidades. A novidade traz suporte específico para Java Gradle nas varreduras de funções Lambda e imagens no Elastic Container Registry (ECR), abrindo possibilidades para uma cobertura muito mais ampla de componentes e tecnologias.

    Novos componentes e tecnologias cobertos

    Com esta atualização, o Amazon Inspector agora consegue detectar vulnerabilidades não apenas em Java com Gradle, mas também em uma série de outros componentes frequentemente utilizados em ambientes cloud. A expansão inclui MySQL, MariaDB, PHP, Jenkins-core, 7zip (em Windows), Elasticsearch e Curl/LibCurl.

    Como funciona o suporte a Java Gradle

    O novo suporte a Java Gradle permite que o Inspector analise as dependências de projetos Java tomando como base o conteúdo do arquivo gradle.lockfile. Isso significa que aplicações Java podem agora receber avaliações abrangentes de vulnerabilidades diretamente nas suas dependências gerenciadas pelo Gradle.

    Melhor detecção de pacotes fora dos gerenciadores de pacotes

    Uma das grandes vantagens dessa expansão é a capacidade melhorada de identificar vulnerabilidades em pacotes instalados fora dos gerenciadores de pacotes tradicionais. Ao escanear funções Lambda e imagens ECR, você agora verá descobertas de vulnerabilidades também em instalações de MySQL, MariaDB, PHP, Jenkins-core, 7zip (Windows), Elasticsearch e Curl/LibCurl.

    O que é o Amazon Inspector

    O Amazon Inspector é um serviço de gerenciamento automatizado de vulnerabilidades que funciona continuamente, escaneando as cargas de trabalho da AWS em busca de vulnerabilidades de software e exposições não intencionais de rede. Seu objetivo é ajudar organizações a fortalecerem sua postura de segurança e atender requisitos de conformidade regulatória.

    Benefícios práticos para sua infraestrutura

    Essas melhorias representam um avanço significativo na segurança automatizada. Para organizações que utilizam estas tecnologias — particularmente aquelas com stacks Java baseados em Gradle — a cobertura expandida oferece tranquilidade maior e detecção mais precisa de riscos potenciais em suas aplicações.

    Como começar

    Os novos recursos estão disponíveis a partir de agora em todas as regiões da AWS onde o Amazon Inspector funciona. Para aprender mais sobre o Amazon Inspector e como ele pode ajudar a proteger suas cargas de trabalho na AWS, consulte a página do Amazon Inspector.

    Para uma lista completa dos sistemas operacionais e linguagens de programação suportados pelo Amazon Inspector, confira o guia do usuário.

    Fonte

    Amazon Inspector adds Java Gradle support and expands ecosystem coverage (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-inspector-java-gradle-ecosystem/)

  • Amazon Connect agora oferece rastreamento em tempo real do status de gravação de tela de agentes

    Monitoramento de Gravações de Tela em Tempo Real

    O Amazon Connect, serviço de contact center em nuvem da AWS, acaba de incorporar uma funcionalidade importante para quem trabalha com supervisão e qualidade de atendimento. A novidade permite que supervisores acompanhem o status das gravações de tela dos agentes praticamente em tempo real através do CloudWatch, utilizando o Amazon EventBridge como intermediário.

    Essa evolução vem em resposta a uma necessidade real dos gestores de contact center: ter visibilidade completa sobre o que cada agente está fazendo durante o atendimento. Não basta mais escutar chamadas ou revisar transcrições de chat. Agora é possível visualizar as ações do agente na sua tela enquanto ele interage com o cliente — seja em uma chamada de voz, conversa por chat ou tarefa.

    Capacidades de Rastreamento

    Quando integrado ao Amazon EventBridge, o novo recurso oferece acesso a informações granulares sobre cada sessão de gravação de tela. Os supervisores conseguem visualizar dados como:

    • Status de sucesso ou falha de cada gravação
    • Códigos de erro detalhados, acompanhados de descrição
    • Versão do cliente de gravação instalada no computador do agente
    • Versão do navegador web utilizado pelo agente
    • Sistema operacional em que o agente está operando
    • Horários precisos de início e fim de cada gravação

    Esses dados agregados no CloudWatch criam um panorama transparente das operações, facilitando a identificação de problemas técnicos, inconsistências de processo ou necessidades de treinamento específico.

    Como Começar

    A ativação da funcionalidade é direta. Os clientes da AWS precisam apenas se inscrever no tipo de evento Screen Recording Status Changed no barramento de eventos do Amazon EventBridge. Assim que configurado, o fluxo de dados para o CloudWatch começa automaticamente.

    O recurso já está disponível em todas as regiões da AWS onde o Amazon Connect funciona, o que garante que organizações brasileiras utilizando este serviço possam adotá-lo sem restrições geográficas.

    Caso de Uso Prático

    Supervisores podem explorar os dados de gravação para identificar oportunidades de coaching com agentes. Por exemplo, se uma gravação falha repetidamente para um agente específico, pode-se investigar problemas de compatibilidade do cliente ou da infraestrutura local. Alternativamente, se todas as gravações de determinado período mostram padrões consistentes de não-conformidade com processos de negócio, há espaço para intervenção educativa ou revisão de procedimentos.

    Recursos Adicionais e Precificação

    Para compreender melhor a implementação técnica deste recurso de gravação de tela, a AWS disponibiliza documentação detalhada e conteúdo complementar. Informações sobre custos associados ao uso dessa funcionalidade podem ser encontradas na página de precificação do Amazon Connect.

    Esta atualização reforça o posicionamento do Amazon Connect como uma solução madura e orientada a conformidade, essencial para empresas que precisam manter altos padrões de qualidade e regulamentação em seus centros de contato.

    Fonte

    Amazon Connect now provides agent screen recording status tracking (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-connect-agent-screen-recording-status-tracking)

  • AWS reconhecida como Líder no relatório ISG 2025 para Serviços de Infraestrutura em Nuvem Soberana (EU)

    Reconhecimento consecutivo em liderança europeia de nuvem soberana

    Pela terceira vez consecutiva, a Amazon Web Services (AWS) foi designada como Líder no relatório Provider Lens™ do Grupo de Serviços de Informação (ISG – Information Services Group), divulgado em 9 de janeiro de 2026. Este relatório, que avalia especificamente Serviços de Infraestrutura em Nuvem Soberana no contexto europeu, reconhece os provedores que demonstram inovação robusta e estabilidade competitiva em um ambiente multicloud complexo.

    O ISG é uma instituição de pesquisa, análise e consultoria tecnológica globalmente reconhecida, parceira de negócios de mais de 900 clientes em todo o mundo. Sua metodologia de avaliação examina como os provedores atendem aos desafios críticos enfrentados por empresas na União Europeia, particularmente no que se refere à governança, residência de dados e conformidade regulatória.

    Metodologia de avaliação e critérios de excelência

    O escopo desta edição incluiu a análise de 19 provedores de infraestrutura em nuvem soberana, oferecendo uma perspectiva abrangente do mercado europeu. O ISG estruturou sua avaliação em torno de dois eixos principais: força competitiva e atratividade do portfólio.

    Força competitiva

    A avaliação da força competitiva levou em consideração múltiplos fatores, incluindo grau de conhecimento do mercado, competências centrais da empresa e estratégia de entrada e comercialização dos serviços. Estes critérios refletem não apenas o que o provedor oferece, mas também como ele se posiciona estrategicamente no mercado europeu.

    Atratividade do portfólio

    O segundo pilar da avaliação examinou a amplitude e qualidade do portfólio de serviços, assim como a estratégia e visão do provedor para o futuro. Também foram consideradas as características específicas do atendimento local — um fator determinante para organizações que operem sob regulamentações regionais rigorosas. A AWS atingiu o mais alto índice nesta dimensão, destacando-se pela riqueza e relevância de suas ofertas para o contexto europeu.

    O diferencial da arquitetura soberana por design

    Segundo o relatório do ISG, a infraestrutura da AWS oferece resiliência e disponibilidade robustas, fundamentadas em uma arquitetura denominada “soberana por design”. Este conceito significa que a proteção da soberania de dados e a independência regional não são funcionalidades adicionadas posteriormente, mas sim princípios estruturais incorporados desde o desenho arquitetural.

    Esta abordagem garante que os clientes europeus mantenham controle efetivo sobre seus dados, com garantia de residência em regiões especificadas e isolamento regional forte. A AWS combina este compromisso com bases profundas de engenharia no continente europeu e mais de uma década de experiência operando múltiplas nuvens independentes para cargas de trabalho críticas e altamente reguladas.

    Compromisso com soberania digital e conformidade regulatória

    O reconhecimento reflete o compromisso contínuo da AWS em atender aos requisitos específicos de soberania digital e resiliência de clientes e parceiros europeus. A empresa pauta seus esforços em uma Declaração de Soberania Digital e investe em um roteiro ambicioso de capacidades que contemplam:

    • Residência garantida de dados em regiões especificadas
    • Controle granular de acesso e permissões
    • Criptografia robusta e gerenciamento de chaves
    • Resiliência operacional e redundância regional

    Estes investimentos demonstram que a AWS vai além de conformidade regulatória básica, oferecendo aos clientes europeus verdadeiro controle e escolha sem comprometer o acesso ao portfólio completo de serviços da plataforma.

    Terceira indicação consecutiva: consolidação de liderança

    O reconhecimento como Líder por três anos consecutivos representa mais que um prêmio pontual — reflete a consolidação de uma estratégia de longo prazo em torno de soberania digital. Este desempenho é construído sobre fundações sólidas: forte compromisso histórico com controle de dados pelo cliente, princípios arquiteturais de isolamento regional robusto, e enraizamento de operações na engenharia europeia.

    Para organizações brasileiras e internacionais que operam na Europa ou precisam atender clientes europeus, este reconhecimento oferece uma perspectiva clara sobre qual provedor tem investido consistentemente em capacidades que atendem rigorosamente aos requisitos regulatórios e de soberania do continente.

    Próximos passos e recursos disponíveis

    Organizações interessadas em aprofundar o entendimento sobre a arquitetura soberana da AWS e suas vantagens competitivas podem consultar o relatório completo Provider Lens 2025 do ISG para Serviços de Infraestrutura em Nuvem Soberana (EU). O documento oferece análises detalhadas, comparativas de portfólio e insights sobre como a nuvem soberana continua evoluindo no contexto europeu.

    Este relatório é particularmente valioso para equipes de arquitetura, conformidade e liderança que avaliam estratégias multicloud com requisitos específicos de residência de dados e governança regional.

    Fonte

    AWS named Leader in the 2025 ISG report for Sovereign Cloud Infrastructure Services (EU) (https://aws.amazon.com/blogs/security/aws-named-leader-in-the-2025-isg-report-for-sovereign-cloud-infrastructure-services-eu/)