Category: Uncategorized

Por que automatizar respostas de segurança?

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

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

Entendendo Automação de Resposta à Segurança

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

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

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

As cinco etapas do CSF

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

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

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

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

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

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

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

Como Funciona Automação de Resposta na AWS

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

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

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

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

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

Definindo Suas Automações de Resposta

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

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

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

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

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

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

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

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

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

Implantando a Automação

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

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

Testando a Automação

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

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

Componentes da Automação

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

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

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

Fase de Resposta com EventBridge e Lambda

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

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

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

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

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

Ações Customizadas e Respostas Manuais

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

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

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

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

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

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

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

Próximos Passos

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

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

Conclusão

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

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

Fonte

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

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

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

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

O que o novo recurso resolve

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

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

Como implementar

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

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

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

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

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

Fonte

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

Novo recurso de visibilidade para tráfego de IA generativa

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

Como funciona o controle por categorias web

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

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

Casos de uso e benefícios práticos

O novo recurso viabiliza diversos cenários operacionais:

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

Integração com inspeção TLS

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

Disponibilidade e primeiros passos

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

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

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

Fonte

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

Monitoramento de Integridade de Arquivos: Uma Abordagem Escalável

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

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

Vantagens desta Abordagem

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

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

Etapas de Implementação

Pré-requisitos

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

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

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

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

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

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

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

Etapa 2: Ativar Security Hub e Security Lake

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

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

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

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

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

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

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

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

/etc/paymentapp/

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

Etapa 4: Implementar a Função Lambda

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

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

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

import boto3, os, json, re
from datetime import datetime, UTC
from urllib.parse import unquote_plus
from helpers import is_critical, load_file_metadata, is_modified, extract_instance_id

s3 = boto3.client('s3')
securityhub = boto3.client('securityhub')

CRITICAL_FILE_PATTERNS = os.environ["CRITICAL_FILE_PATTERNS"].split(",")
SEVERITY_LABEL = os.environ["SEVERITY_LABEL"]

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

Configurar Variáveis de Ambiente

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

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

Definir Permissões

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

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

Adicionar Funções Auxiliares via Lambda Layer

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

#!/bin/bash
set -e

FUNCTION_NAME="fim-change-detector"
LAYER_NAME="fim-change-detector-layer"

mkdir -p python

cat > python/helpers.py << 'EOF'
import json, re, os
from dateutil.parser import parse as parse_dt
import boto3

s3 = boto3.client('s3')
CRITICAL_FILE_PATTERNS = os.environ.get("CRITICAL_FILE_PATTERNS", "").split(",")

def is_critical(path):
    return any(re.match(p.strip(), path) for p in CRITICAL_FILE_PATTERNS if p.strip())

def load_file_metadata(bucket, key, version_id):
    obj = s3.get_object(Bucket=bucket, Key=key, VersionId=version_id)
    data = {}
    for line in obj['Body'].read().decode().splitlines():
        if line.strip():
            i = json.loads(line)
            n, d, m = i.get("Name","").strip(), i.get("InstalledDir","").strip(), i.get("ModificationTime","").strip()
            if n and d and m:
                data[f"{d.rstrip('/')}/{n}"] = m
    return data

def is_modified(path, current, previous):
    try:
        return parse_dt(current[path]) != parse_dt(previous[path])
    except:
        return current[path] != previous[path]

def extract_instance_id(bucket, key, version_id):
    obj = s3.get_object(Bucket=bucket, Key=key, VersionId=version_id)
    for line in obj['Body'].read().decode().splitlines():
        if line.strip():
            r = json.loads(line)
            if "resourceId" in r:
                return r["resourceId"]
    return None
EOF

zip -r helpers_layer.zip python >/dev/null

LAYER_VERSION_ARN=$(aws lambda publish-layer-version \
  --layer-name "$LAYER_NAME" \
  --description "Helper functions for File Integrity Monitoring" \
  --zip-file fileb://helpers_layer.zip \
  --compatible-runtimes python3.13 \
  --query 'LayerVersionArn' \
  --output text)

aws lambda update-function-configuration \
  --function-name "$FUNCTION_NAME" \
  --layers "$LAYER_VERSION_ARN" >/dev/null

echo "Layer created and attached to the Lambda function."

Etapa 5: Configurar Notificações de Eventos S3

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

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

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

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

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

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

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

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

Análise e Visualização de Dados

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

Um exemplo de consulta:

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

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

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

Limpeza de Recursos

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

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

Considerações para Ambientes Produtivos

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

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

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

Conclusão

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

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

Fonte

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

Integração entre Transfer Family e FSx para NetApp ONTAP

A AWS anunciou em janeiro de 2026 que o Transfer Family passou a oferecer suporte nativo para o Amazon FSx para NetApp ONTAP. Essa integração permite que clientes da AWS acessem dados armazenados em sistemas de arquivos FSx for ONTAP utilizando protocolos padronizados como SFTP (Protocolo Seguro de Transferência de Arquivo), FTPS (FTP com Segurança de Camada de Transporte) e FTP (Protocolo de Transferência de Arquivo).

O Transfer Family, que já oferecia transferências de arquivos totalmente gerenciadas em protocolos como SFTP, FTP, FTPS, AS2 e interfaces baseadas em navegador, agora expande sua capacidade de alcance para incluir infraestruturas ONTAP. Essa adição representa uma evolução importante para organizações que utilizam sistemas de armazenamento NetApp e precisam modernizar seus fluxos de transferência de dados.

Como funciona a integração

Acesso através de S3 Access Points

O mecanismo que viabiliza essa integração envolve o uso de S3 Access Points do Transfer Family. Os usuários podem agora acessar sistemas de arquivos FSx para ONTAP pelos protocolos suportados do Transfer Family, enquanto mantêm simultaneamente o acesso através dos protocolos nativos de arquivo — NFS (Sistema de Arquivos de Rede) e SMB (Bloco de Mensagem do Servidor).

Essa abordagem híbrida permite que as organizações preservem seus fluxos de trabalho existentes enquanto adicionam camadas de segurança e acesso padronizado para parceiros externos e usuários internos que necessitam de protocolos industriais específicos.

Controle de segurança e conformidade

O acesso aos dados é gerenciado através de mecanismos padrão da AWS: Políticas IAM (Gestão de Identidade e Acesso) e configurações de S3 Access Points. Essa estrutura centralizada de controle oferece às organizações ferramentas robustas para atender requisitos de segurança de dados e conformidade regulatória, elementos críticos em ambientes corporativos.

Disponibilidade e próximos passos

O suporte do Transfer Family para FSx para ONTAP está disponível em regiões selecionadas da AWS. Para começar, os clientes podem acessar o console do Transfer Family ou utilizar ferramentas de programação como AWS CLI (Interface de Linha de Comando) e SDKs (Kits de Desenvolvimento de Software).

A documentação técnica completa encontra-se no Guia do Usuário do Transfer Family, que oferece instruções passo a passo para configurar a integração com FSx para ONTAP e aproveitar todo o potencial dessa nova funcionalidade.

Por que isso importa

Essa integração elimina fricções comuns em migrações para a nuvem: organizações que dependem de NetApp ONTAP podem modernizar seus processos de compartilhamento de arquivos sem abandonar investimentos em infraestrutura existente. O Transfer Family oferece a ponte entre ambientes legados e abordagens nativas de nuvem, tudo sob um único serviço gerenciado.

Fonte

AWS Transfer Family now supports Amazon FSx for NetApp ONTAP (https://aws.amazon.com/about-aws/whats-new/2026/01/aws-transfer-family-amazon-fsx-netapp-ontap)

O anúncio: suporte a IPv6 no IAM Identity Center

A AWS recomenda utilizar o IAM Identity Center para fornecer aos seus usuários acesso aos aplicativos gerenciados pela AWS — como o Amazon Q Developer — e às contas AWS. Recentemente, a AWS anunciou o suporte para IPv6 no IAM Identity Center, representando um avanço importante na conectividade de rede para organizações que adotam a pilha de protocolos IPv6.

Para compreender melhor os benefícios dessa tecnologia, você pode consultar a documentação sobre IPv6 disponibilizada pela AWS.

Como funciona o Identity Center atualmente

O IAM Identity Center oferece um portal de acesso que permite aos usuários da sua organização acessarem aplicativos AWS e contas através de dois caminhos: autenticando-se diretamente no portal ou utilizando um marcador para a URL da aplicação. Em ambos os casos, o portal gerencia a autenticação dos usuários antes de conceder acesso aos recursos solicitados.

O suporte simultâneo para IPv4 e IPv6 facilita uma experiência de conectividade contínua para navegadores, aplicativos e outros clientes, independentemente de suas configurações de rede.

Endpoints dual-stack: o que muda

O novo recurso introduz endpoints dual-stack que suportam tanto IPv4 quanto IPv6. Isso significa que os usuários podem se conectar utilizando clientes com suporte a IPv4, IPv6 ou ambos, simultaneamente. Os endpoints IPv4 atuais continuam funcionando normalmente — nenhuma ação imediata é necessária.

Essa capacidade dual-stack se estende aos aplicativos gerenciados pelo Identity Center. Quando usuários acessam o endpoint dual-stack da aplicação, o sistema roteia automaticamente para o endpoint dual-stack do Identity Center para autenticação.

Preparação necessária para clientes IPv6

Para utilizar o Identity Center a partir de clientes IPv6, sua organização precisará direcionar os usuários para os novos endpoints dual-stack e atualizar as configurações no seu provedor de identidade externo (IdP), caso utilize um.

Este guia demonstra como atualizar sua configuração para permitir que clientes IPv6 se conectem diretamente aos endpoints do IAM Identity Center sem necessidade de serviços de tradução de endereços de rede.

Visão geral da transição

A transição de IPv4 para IPv6 via endpoints dual-stack envolve três fases distintas:

• Estado inicial: clientes utilizam exclusivamente endpoints IPv4.
• Fase de transição: seus clientes utilizam uma combinação de endpoints IPv4 e endpoints dual-stack.
• Estado final: seus clientes se conectam aos endpoints dual-stack, utilizando IPv4 ou IPv6 conforme suas preferências.

Essa abordagem permite uma migração gradual, onde diferentes grupos de usuários podem fazer a transição em seus próprios prazos.

Pré-requisitos para habilitar IPv6

Para ativar o acesso IPv6 para usuários e administradores da sua organização, você precisa ter em vigor:

• Uma instância existente do IAM Identity Center;
• Firewalls e gateways atualizados para incluir os novos endpoints dual-stack;
• Clientes e redes com capacidade IPv6.

Recomenda-se trabalhar em conjunto com seus administradores de rede para atualizar as configurações de firewalls e gateways, além de verificar se seus dispositivos (laptops, desktops e outros) estão preparados para aceitar conectividade IPv6. Se sua organização já habilitou IPv6 para outros serviços AWS, você provavelmente já está familiarizado com essas alterações.

Etapa 1: Atualizar a configuração do seu provedor de identidade

Se sua organização não utiliza um IdP externo como fonte de identidade, você pode pular esta etapa.

Nesta fase, você precisa atualizar a URL do Serviço Consumidor de Asserção (ACS) da sua instância do IAM Identity Center nas configurações do seu IdP para autenticação única (single sign-on) e na configuração SCIM para provisionamento de usuários.

A capacidade do seu IdP determina como você atualiza essas URLs. Se o seu IdP suporta múltiplas URLs de ACS, configure tanto os URLs IPv4 quanto os dual-stack para possibilitar uma transição flexível. Com essa configuração, alguns usuários podem continuar usando endpoints somente IPv4 enquanto outros adotam endpoints dual-stack para IPv6.

Caso seu IdP suporte apenas um URL de ACS, você precisará atualizar para o novo URL dual-stack no IdP e fazer com que todos os usuários façam a transição para endpoints dual-stack simultaneamente.

Atualizando as configurações de autenticação SAML e provisionamento SCIM

Comece atualizando as configurações de autenticação única no seu IdP para utilizar as novas URLs dual-stack. Localize essas URLs no Console de Gerenciamento AWS para o IAM Identity Center, navegando até Settings no painel de navegação e depois selecionando Identity source.

Em seguida, escolha Actions e selecione Manage authentication. Sob Manage SAML 2.0 authentication, você encontrará os seguintes URLs nos metadados do provedor de serviço:

• URL de entrada do portal de acesso AWS;
• URL do Serviço Consumidor de Asserção (ACS) do IAM Identity Center;
• URL do emissor do IAM Identity Center.

Se seu IdP suporta múltiplas URLs de ACS, adicione o URL dual-stack à configuração do seu IdP mantendo o existente em IPv4. Dessa forma, você e seus usuários podem decidir quando iniciar o uso dos endpoints dual-stack sem necessidade de que toda a organização mude simultaneamente.

Caso seu IdP não suporte múltiplas URLs de ACS, você precisará substituir o URL IPv4 existente pelo novo URL dual-stack e fazer com que toda sua organização use apenas os endpoints dual-stack.

Agora, atualize o endpoint de provisionamento no seu IdP. Acesse novamente Settings no painel de navegação, e sob Identity source, escolha Actions e selecione Manage provisioning. Sob Automatic provisioning, copie o novo endpoint SCIM que termina em api.aws e atualize essa URL no seu IdP externo.

Etapa 2: Localizar e compartilhar os novos endpoints dual-stack

Sua organização precisará de dois tipos de URLs para habilitar a conectividade IPv6.

URL do portal de acesso dual-stack

O primeiro é o novo URL do portal de acesso dual-stack que seus usuários utilizarão para acessar seus aplicativos AWS e contas atribuídos. Esse URL está disponível no console do IAM Identity Center, listado como Dual-stack no resumo de Settings (você pode precisar expandir a seção de URLs do portal de acesso).

Esse URL dual-stack termina com app.aws como seu domínio de nível superior. Compartilhe esse URL com seus usuários e solicite que usem esse URL dual-stack para conectar via IPv6.

Como exemplo, se sua organização utiliza o portal de acesso para acessar contas AWS, os usuários precisarão autenticar-se através do novo URL do portal de acesso dual-stack ao usar conectividade IPv6. Alternativamente, se sua organização acessa a URL da aplicação, você precisará ativar a URL dual-stack da aplicação seguindo instruções específicas dessa aplicação. Para mais informações, consulte a lista de serviços AWS que suportam IPv6.

URLs de serviço para administradores

O segundo tipo de URL que sua organização precisa são aqueles que administradores usam para gerenciar o IAM Identity Center. Os novos endpoints de serviço dual-stack terminam em api.aws como seu domínio de nível superior e estão listados nos endpoints de serviço do Identity Center.

Administradores podem usar esses endpoints de serviço para gerenciar usuários e grupos no Identity Center, atualizar seu acesso a aplicativos e recursos, e executar outras operações de gerenciamento. Como exemplo, se um administrador utiliza identitystore.{region}.amazonaws.com para gerenciar usuários e grupos no Identity Center, agora deve usar a versão dual-stack do mesmo endpoint: identitystore.{region}.api.aws, permitindo conectar aos endpoints de serviço usando clientes e redes IPv6.

Se seus usuários ou administradores utilizam um SDK da AWS para acessar aplicativos e contas AWS ou gerenciar serviços, siga as diretrizes sobre endpoints dual-stack e FIPS para habilitar a conectividade aos endpoints dual-stack.

Monitorando o uso dos endpoints dual-stack

Você pode opcionalmente monitorar os registros do AWS CloudTrail para rastrear o uso dos endpoints dual-stack. A diferença fundamental entre o uso de endpoints somente IPv4 e endpoints dual-stack é o domínio de nível superior (TLD) e aparece no campo clientProvidedHostHeader.

A seguir está um exemplo comparativo entre esses eventos no CloudTrail para a chamada da API CreateTokenWithIAM:

Endpoints somente IPv4:

"CloudTrailEvent": {
  "eventName": "CreateToken",
  "tlsDetails": {
    "tlsVersion": "TLSv1.3",
    "cipherSuite": "TLS_AES_128_GCM_SHA256",
    "clientProvidedHostHeader": "oidc.us-east-1.amazonaws.com"
  }
}

Endpoints dual-stack:

"CloudTrailEvent": {
  "eventName": "CreateToken",
  "tlsDetails": {
    "tlsVersion": "TLSv1.3",
    "cipherSuite": "TLS_AES_128_GCM_SHA256",
    "clientProvidedHostHeader": "oidc.us-east-1.api.aws"
  }
}

Considerações finais

O IAM Identity Center agora permite que clientes se conectem via IPv6 nativamente, sem necessidade de infraestrutura de tradução de endereços de rede. Esta releitura apresentou como fazer a transição de sua organização para utilizar IPv6 com o Identity Center e suas aplicações integradas.

Lembre-se de que os endpoints IPv4 existentes continuarão funcionando, permitindo que você faça a transição no seu próprio ritmo. Nenhuma ação imediata é obrigatória, mas recomenda-se planejar a transição para aproveitar os benefícios do IPv6 e atender requisitos de conformidade.

Se você tiver dúvidas, comentários ou preocupações, entre em contato com o AWS Support ou abra um tópico no canal de discussão sobre IAM Identity Center.

Fonte

IAM Identity Center now supports IPv6 (https://aws.amazon.com/blogs/security/iam-identity-center-now-supports-ipv6/)

O que foi anunciado

A AWS expandiu a disponibilidade do Amazon Managed Grafana para as regiões AWS GovCloud (US-West) e AWS GovCloud (US-East). Essa expansão permite que órgãos governamentais e empresas de setores regulados visualizem e analisem seus dados operacionais de forma segura, atendendo aos rigorosos requisitos de conformidade exigidos pelo setor público norte-americano.

O Amazon Managed Grafana

O Amazon Managed Grafana é um serviço totalmente gerenciado baseado na plataforma de código aberto Grafana. Ele simplifica o processo de visualização e análise de dados operacionais em larga escala, permitindo que equipes de tecnologia monitorem infraestruturas complexas de forma centralizada e intuitiva.

O diferencial desse serviço é eliminar a necessidade de manutenção tradicional de software. Em vez de instalar, configurar e gerenciar instâncias do Grafana em seus próprios ambientes, as organizações podem contar com uma solução completamente administrada pela AWS.

Capacidades nas regiões GovCloud

Praticamente todas as funcionalidades do Amazon Managed Grafana estão disponíveis nas regiões AWS GovCloud (US). A única exceção diz respeito aos plugins Enterprise, que não são suportados nessas regiões específicas.

Essa disponibilidade é particularmente importante para organizações do setor público que precisam manter seus dados dentro de ambientes com conformidade rigorosa, garantindo que suas operações de monitoramento e análise atendam aos padrões federais de segurança e privacidade.

Como começar

Para começar a utilizar o Amazon Managed Grafana nas regiões GovCloud, os usuários podem acessar o Console da AWS e consultar o guia do usuário do Amazon Managed Grafana.

Para aprofundar o conhecimento sobre esse serviço, estão disponíveis a página do produto e a página de preços, onde é possível compreender melhor as funcionalidades oferecidas e analisar as opções de custeamento.

Relevância para o mercado regulado

Essa expansão de disponibilidade reflete a estratégia da AWS de oferecer seus serviços em ambientes que atendem a exigências rigorosas de conformidade. Para organizações que operam em setores regulados, como administração pública federal, defesa ou instituições financeiras altamente controladas, dispor de ferramentas de monitoramento nativas em regiões GovCloud reduz complexidades de arquitetura e facilita o atendimento a regulamentações específicas.

Fonte

Amazon Managed Grafana now available in the AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-managed-grafana-aws-govcloud-us-regions)

O que foi anunciado

A Amazon Web Services (AWS) anunciou a conclusão bem-sucedida da auditoria de conformidade com o padrão PCI PIN (Número de Identificação Pessoal da Indústria de Cartões de Pagamento) para o serviço AWS CloudHSM. A avaliação foi conduzida pela Coalfire, uma empresa qualificada como Avaliadora de Segurança Terceirizada (QSA), e o resultado foi zero constatações de não-conformidade.

Esse resultado abre novas possibilidades para organizações brasileiras e globais que operam com sistemas de pagamento regulados e precisam manter seus ambientes em conformidade com os rigorosos padrões PCI PIN.

O que é o CloudHSM e por que isso importa

O CloudHSM é um serviço gerenciado que fornece módulos de segurança de hardware (HSM) validados no nível 3 do FIPS 140-3. O diferencial é que você mantém o hardware sob seu controle exclusivo — são instâncias single-tenant rodando dentro da sua própria nuvem privada virtual (VPC).

Para operações de pagamento que envolvem tradução de PIN ou manipulação sensível desses dados, o CloudHSM oferece uma abordagem que reduz significativamente a complexidade de conformidade regulatória, já que você gerencia pessoalmente a segurança do hardware criptográfico.

Componentes do pacote de conformidade PCI PIN

A AWS disponibiliza dois documentos essenciais que formam o pacote de conformidade:

• Atestado de Conformidade (AOC) do PCI PIN — demonstra que o CloudHSM foi validado com sucesso contra o padrão PCI PIN, com resultado de zero achados
• Resumo de Responsabilidades do PCI PIN — fornece orientação clara sobre quais responsabilidades cabem aos clientes na hora de construir e operar um ambiente seguro para manipular transações baseadas em PIN

Ambos os documentos estão disponíveis através do AWS Artifact, a plataforma da AWS onde clientes acessam relatórios de conformidade, certificações e outros documentos de auditoria.

Alternativa para pagamentos: AWS Payment Cryptography

É importante observar que para operações de pagamento como tradução de PIN, a AWS recomenda também considerar a AWS Payment Cryptography, um serviço totalmente gerenciado que também atende aos requisitos de conformidade PCI PIN, oferecendo uma opção com overhead operacional ainda menor.

Como acessar os relatórios

Clientes que precisam dos relatórios de conformidade PCI PIN podem acessá-los diretamente no AWS Artifact. Para compreender melhor os programas de conformidade e segurança oferecidos pela AWS, recomenda-se consultar a página de Programas de Conformidade da AWS.

Dúvidas específicas sobre esta certificação ou sobre como integrar o CloudHSM em sua arquitetura de pagamentos podem ser direcionadas à equipe de conformidade da AWS ou ao suporte técnico da AWS.

Implicações práticas

Essa atualização é especialmente relevante para empresas de fintech, processadoras de pagamento e instituições financeiras que operam no Brasil e em outros mercados regulados. A certificação PCI PIN fornece a base de confiança necessária para que clientes corporativos implementem soluções criptográficas robustas sem abrir mão da flexibilidade da nuvem.

Fonte

Updated PCI PIN compliance package for AWS CloudHSM now available (https://aws.amazon.com/blogs/security/updated-pci-pin-compliance-package-for-aws-cloudhsm-now-available/)

Novas Camadas de Proteção para Grupos de Auto Scaling

A AWS anunciou em janeiro de 2026 a introdução de novos mecanismos de proteção para o EC2 Auto Scaling, focando na prevenção de exclusões acidentais. Essas funcionalidades reforçam a segurança operacional e ajudam a manter a disponibilidade das aplicações.

Chave de Condição IAM para Controle de Exclusão Forçada

O primeiro mecanismo é a nova chave de condição de política autoscaling:ForceDelete. Essa chave funciona em conjunto com a ação DeleteAutoScalingGroup e permite controlar se o parâmetro ForceDelete pode ser utilizado durante a exclusão. Em outras palavras, ela determina se um grupo de Auto Scaling (ASG) pode ser removido enquanto ainda possui instâncias em execução.

Por meio de políticas IAM (Identity and Access Management), é possível restringir as permissões de exclusão usando essa chave de condição. Isso funciona como uma medida de segurança importante, evitando que exclusões acidentais removam grupos de Auto Scaling que ainda contêm instâncias ativas.

Proteção a Nível de Grupo

Além da chave de condição IAM, o EC2 Auto Scaling agora oferece proteção contra exclusão diretamente no nível do grupo. A nova configuração de proteção contra exclusão pode ser estabelecida tanto no momento da criação do grupo quanto em atualizações posteriores.

Esse recurso permite definir controles aprimorados com base na criticidade da sua carga de trabalho, oferecendo múltiplos níveis de proteção. Assim, é possível salvaguardar grupos críticos contra exclusões acidentais e garantir a continuidade das aplicações.

Defesa em Camadas contra Exclusões Indesejadas

A combinação da chave de condição autoscaling:ForceDelete com a proteção a nível de grupo cria uma defesa em múltiplas camadas. Dessa forma, você pode tanto restringir permissões IAM para operações de exclusão forçada quanto estabelecer controles aprimorados de proteção diretamente nos grupos de Auto Scaling críticos.

Disponibilidade e Próximos Passos

Os novos mecanismos estão disponíveis em todas as regiões da AWS Regions e em todas as regiões AWS GovCloud (US).

Para começar, acesse o console do EC2 Auto Scaling ou consulte a documentação técnica para proteção contra exclusão e chaves de condição de política do Amazon EC2 Auto Scaling.

Fonte

EC2 Auto Scaling Introduces New Mechanisms for Group Deletion Protection (https://aws.amazon.com/about-aws/whats-new/2026/01/ec2-auto-scaling-new-mechanisms-group-deletion-protection)

Certificação PCI PIN para AWS Payment Cryptography

A Amazon Web Services (AWS) finalizou com sucesso o processo de auditoria de conformidade conforme o padrão PCI PIN (Número de Identificação Pessoal da Indústria de Cartões de Pagamento) para seu serviço Payment Cryptography. Essa conquista representa um passo importante para organizações brasileiras que precisam processar pagamentos com cartão de forma segura e em conformidade com os requisitos regulatórios internacionais.

O serviço AWS Payment Cryptography permite que aplicações de processamento de pagamento utilizem módulos de segurança por hardware (HSMs) certificados como PCI PIN Transaction Security (PTS), totalmente gerenciados pela AWS com gerenciamento de chaves em conformidade com PCI PIN. Essa abordagem oferece maior flexibilidade para quem precisa implantar cargas de trabalho reguladas, reduzindo significativamente o esforço administrativo relacionado à conformidade.

Componentes principais do pacote de conformidade

O pacote de conformidade PCI PIN para AWS Payment Cryptography é composto por dois elementos essenciais:

Certificado de Conformidade (AOC)

O Certificado de Conformidade (Attestation of Compliance — AOC) demonstra que o AWS Payment Cryptography passou por validação bem-sucedida contra o padrão PCI PIN, sem nenhuma constatação de não-conformidade. Este documento valida que a infraestrutura e os processos de segurança atendem integralmente aos requisitos estabelecidos.

Responsabilidades na implementação

O Resumo de Responsabilidades PCI PIN fornece orientações claras para ajudar clientes a compreender suas próprias responsabilidades ao desenvolver e operar um ambiente altamente seguro para processamento de transações baseadas em PIN. Este documento é fundamental para que cada organização implemente adequadamente seus próprios controles.

Processo de avaliação e acesso aos relatórios

A AWS foi avaliada pela Coalfire, uma empresa qualificada como Qualified Security Assessor (QSA) independente. Os clientes podem acessar tanto o Certificado de Conformidade PCI PIN quanto o Resumo de Responsabilidades por meio do AWS Artifact, portal centralizado que reúne todos os documentos de conformidade relevantes.

Para explorar mais detalhes sobre os programas de conformidade da AWS e outras iniciativas de segurança, a documentação completa está disponível na página de Programas de Conformidade da AWS. Organizações com dúvidas técnicas específicas podem contatar o time de conformidade da AWS através da página de Suporte de Conformidade, ou abrir uma solicitação com o Suporte da AWS.

O significado para o mercado brasileiro

Esta certificação é especialmente relevante para empresas brasileiras que operam em segmentos como fintech, varejo e serviços financeiros. A redução do overhead de conformidade permite que times de segurança dediquem seus esforços a iniciativas de inovação, em vez de gestar manualmente processos certificadores. Com a infraestrutura gerenciada e certificada pela AWS, as organizações podem focar em suas aplicações e processos de negócio, mantendo a segurança das transações financeiras como responsabilidade compartilhada claramente definida.

Fonte

Updated PCI PIN compliance package for AWS Payment Cryptography now available (https://aws.amazon.com/blogs/security/updated-pci-pin-compliance-package-for-aws-payment-cryptography-now-available/)