Category: Uncategorized

  • Relatório OSPAR 2026 já está disponível com 167 serviços AWS no escopo

    AWS conclui avaliação OSPAR 2026 com 167 serviços certificados

    A Amazon Web Services (AWS) confirmou a conclusão bem-sucedida de sua avaliação anual do Relatório de Auditoria de Provedores de Serviços Terceirizados (OSPAR), realizada em 29 de julho de 2026, seguindo o framework OSPAR versão 2.0.

    O que é o OSPAR e por que ele importa

    O OSPAR é um padrão de conformidade criado pela Associação de Bancos de Singapura (ABS), por meio das Diretrizes sobre Objetivos de Controle e Procedimentos para Provedores de Serviços Terceirizados. O objetivo é estabelecer critérios mínimos de controle para provedores que operam no mercado financeiro de Singapura.

    As diretrizes cobrem áreas como higiene cibernética, gestão de risco tecnológico, continuidade de negócios, segurança de dados, criptografia e desenvolvimento de aplicações de software — tudo isso alinhado às orientações regulatórias da Autoridade Monetária de Singapura (MAS).

    Para os clientes da AWS que atuam no setor financeiro de Singapura, a certificação OSPAR simplifica os processos de due diligence em auditorias de conformidade, já que parte do trabalho de verificação é coberto pelo próprio relatório da AWS.

    Novidades deste ciclo: cinco novos serviços no escopo

    O ciclo de certificação de 2026 amplia o escopo para 167 serviços AWS disponíveis na região Ásia-Pacífico (Singapura). Em relação ao ano anterior, cinco serviços foram adicionados:

    Como acessar o relatório OSPAR

    O relatório OSPAR mais recente está disponível para download pelo AWS Artifact, portal de autoatendimento da AWS para acesso sob demanda a relatórios de conformidade. Para acessá-lo, basta fazer login no AWS Artifact pelo Console de Gerenciamento da AWS. Caso ainda não conheça a ferramenta, a AWS disponibiliza um guia de Primeiros Passos com o AWS Artifact.

    A lista completa de serviços no escopo do OSPAR também está disponível na página Serviços AWS por Programa de Conformidade.

    Fonte

    OSPAR 2026 report now available with 167 services in scope (https://aws.amazon.com/blogs/security/ospar-2026-report-now-available-with-167-services-in-scope/)

  • Guia de Resposta a Incidentes com AWS CloudTrail – Parte 2: Ataque em Múltiplos Estágios ao Amazon Bedrock

    Continuando a investigação: ataques encadeados no ambiente AWS

    Na primeira parte deste guia, a equipe de segurança da AWS explorou dois cenários clássicos de incidentes: exclusão de dados no Amazon Simple Storage Service (S3) com implicações de ransomware, e mineração de criptomoedas implantada via AWS CloudFormation com credenciais expostas. Nesta segunda parte, o foco muda para um ataque mais sofisticado e encadeado, que começa com uma falha em uma aplicação web e termina no uso indevido de serviços de Inteligência Artificial (IA) em múltiplas regiões AWS.

    Cenário 3: SSRF, coleta de credenciais via IMDSv1 e abuso do Amazon Bedrock

    Este cenário demonstra como uma vulnerabilidade de Falsificação de Requisição do Lado do Servidor (SSRF — Server-Side Request Forgery) pode se transformar em um incidente de grande escala. A equipe de segurança recebeu múltiplos alertas aparentemente desconexos: operações falhas do AWS Identity and Access Management (IAM) na região us-east-1, logins bem-sucedidos no console sem Autenticação Multifator (MFA), e chamadas suspeitas ao Amazon Bedrock vindas de us-east-2. O que parecia uma série de eventos isolados era, na verdade, uma cadeia de ataque cuidadosamente orquestrada.

    Arquitetura do ataque e progressão em cinco estágios

    O ataque explorou a relação de confiança entre instâncias do Amazon Elastic Compute Cloud (EC2) e os serviços AWS. Uma instância EC2 executava uma aplicação web com uma role IAM chamada webdev associada. O agente malicioso identificou a vulnerabilidade SSRF nessa aplicação e a usou para alcançar o endpoint do Serviço de Metadados da Instância versão 1 (IMDSv1), coletando as credenciais temporárias da role sem precisar de nenhuma autenticação adicional — uma característica arquitetural do IMDSv1 que o torna especialmente perigoso em cenários de SSRF.

    O ataque se desdobrou em cinco estágios sequenciais:

    • Acesso inicial: exploração da vulnerabilidade SSRF na aplicação web para fazer requisições em nome da instância.
    • Coleta de credenciais: essas requisições alcançaram o endpoint IMDSv1 e retornaram as credenciais temporárias da role webdev.
    • Teste de permissões: com as credenciais em mãos, o agente malicioso tentou operações IAM para mapear o que a role podia fazer.
    • Pivotamento de serviço: ao ser bloqueado nas ações IAM, o agente redirecionou o foco para o Amazon Bedrock, um serviço que a role conseguia acessar.
    • Mudança de região: as operações foram migradas de us-east-1 para us-east-2, provavelmente para contornar controles de monitoramento específicos de região.

    Evidências no CloudTrail: quatro eventos que contam a história completa

    Evento 1 — Teste de permissões (15:53:49 UTC)

    A primeira atividade suspeita foi uma chamada CreateUser com falha na região us-east-1. O log do AWS CloudTrail registra uma sessão de AssumedRole tentando criar um usuário IAM chamado adm1n — note o número “1” no lugar da letra “i”, uma técnica de typosquatting para imitar nomes administrativos legítimos. A chamada foi bloqueada com AccessDenied.

    Os campos mais relevantes neste evento são:

    • userName: "webdev" — confirma que a role EC2 comprometida está em uso.
    • ec2RoleDelivery: "1.0" — prova que as credenciais foram obtidas via IMDSv1, confirmando o vetor SSRF.
    • eventName: "CreateUser" — indica tentativa de criar persistência via backdoor IAM.
    • errorCode: "AccessDenied" — o princípio de menor privilégio funcionou e bloqueou a ação.
    {
      "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0",
        "sessionContext": {
          "sessionIssuer": { "type": "Role", "userName": "webdev" },
          "attributes": { "mfaAuthenticated": "false" }
        },
        "ec2RoleDelivery": "1.0"
      },
      "eventTime": "2025-09-22T15:53:49Z",
      "eventSource": "iam.amazonaws.com",
      "eventName": "CreateUser",
      "readOnly": false,
      "userAgent": "aws-cli/2.17.48 ua/2.0 os/windows#10 ...",
      "errorCode": "AccessDenied",
      "errorMessage": "User: ...assumed-role/webdev/... is not authorized to perform: iam:CreateUser on resource: .../user/adm1n..."
    }

    Evento 2 — Acesso ao console (15:59:29 UTC)

    Seis minutos depois, o agente malicioso fez login com sucesso no console AWS usando as mesmas credenciais coletadas. O evento ConsoleLogin registra que o MFA não foi utilizado (MFAUsed: No) e que o acesso veio de um navegador Chrome no Windows 10. Este é o pivotamento do acesso programático para o acesso visual interativo.

    • ConsoleLogin: "Success" — login bem-sucedido com credenciais sequestradas.
    • MFAUsed: "No" — ausência de MFA foi a brecha que permitiu este pivotamento.
    • sourceIPAddress: "75.3.231.105" — dado de atribuição para correlação com outros logs.
    {
      "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0",
        "sessionContext": { "attributes": { "mfaAuthenticated": "false" } }
      },
      "eventTime": "2025-09-22T15:59:29Z",
      "eventSource": "signin.amazonaws.com",
      "eventName": "ConsoleLogin",
      "awsRegion": "us-east-1",
      "sourceIPAddress": "75.3.231.105",
      "responseElements": { "ConsoleLogin": "Success" },
      "additionalEventData": { "MobileVersion": "No", "MFAUsed": "No" },
      "eventType": "AwsConsoleSignIn"
    }

    Evento 3 — Reconhecimento no Amazon Bedrock (17:20:00 UTC)

    Quase duas horas depois, o agente malicioso pivotou para o Amazon Bedrock, fazendo uma chamada ListFoundationModels na região us-east-2. Este evento evidencia a mudança de região como técnica de evasão de defesas, a transição de serviços IAM para serviços de IA, e o campo sessionCredentialFromConsole: "true", que conecta esta chamada à sessão de console estabelecida no Evento 2.

    • eventSource: "bedrock.amazonaws.com" — pivotamento para serviços de IA gerenciados.
    • eventName: "ListFoundationModels" — reconhecimento para enumerar modelos disponíveis.
    • awsRegion: "us-east-2" — mudança de região deliberada para evasão de detecção.
    {
      "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0"
      },
      "eventTime": "2025-09-22T17:20:00Z",
      "eventSource": "bedrock.amazonaws.com",
      "eventName": "ListFoundationModels",
      "awsRegion": "us-east-2",
      "sourceIPAddress": "75.3.231.105",
      "readOnly": true,
      "tlsDetails": { "clientProvidedHostHeader": "bedrock.us-east-2.amazonaws.com" },
      "sessionCredentialFromConsole": "true"
    }

    Evento 4 — Exploração ativa do modelo (17:25:48 UTC)

    Cinco minutos após o reconhecimento, o agente malicioso passou da enumeração para a exploração ativa, invocando o modelo Amazon Nova Pro via API Converse em us-east-2. O campo additionalEventData quantifica o uso não autorizado: 944 tokens de entrada e 126 de saída — confirmando que o modelo foi efetivamente consultado e respondeu.

    • eventName: "Converse" — transição do reconhecimento para exploração ativa.
    • modelId: "amazon.nova-pro-v1:0" — identifica o modelo específico sendo utilizado indevidamente.
    • inputTokens: 944, outputTokens: 126 — quantifica o uso não autorizado (custo financeiro e risco de exfiltração de dados).
    {
      "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0"
      },
      "eventTime": "2025-09-22T17:25:48Z",
      "eventSource": "bedrock.amazonaws.com",
      "eventName": "Converse",
      "awsRegion": "us-east-2",
      "requestParameters": {
        "modelId": "amazon.nova-pro-v1:0",
        "inferenceConfig": { "maxTokens": 1024 }
      },
      "additionalEventData": { "inputTokens": 944, "outputTokens": 126 }
    }

    Campos-chave para investigação

    Ao analisar esses eventos, alguns campos do CloudTrail carregam a maior parte do trabalho investigativo:

    • userIdentity: ponto de partida para atribuição. Neste cenário, carrega o ID da instância EC2 como nome de sessão, permitindo rastrear as credenciais coletadas até a instância comprometida específica.
    • readOnly: revela a intenção da ação. Valor true indica reconhecimento; false indica tentativa de modificação ou uso.
    • awsRegion: expôs a estratégia de evasão do agente malicioso. A mudança de us-east-1 para us-east-2 foi deliberada, aproveitando controles de monitoramento inconsistentes entre regiões.
    • userIdentity.invokedBy: identifica quando um serviço AWS fez a requisição em nome de um usuário. A ausência deste campo nos eventos confirma que as chamadas vieram diretamente das credenciais coletadas, não de um fluxo legítimo orientado por serviço.

    Checklist de resposta ao incidente

    Conter e remediar o ponto de entrada

    • Identificar a funcionalidade da aplicação web que permitiu a requisição externa (buscadores de URLs, callbacks de webhook, renderizadores de PDF ou imagem, geradores de preview de links são os candidatos mais comuns) e confirmar se ela consegue alcançar http://169.254.169.254.
    • Auditar o restante da aplicação em busca do mesmo padrão, pois um parâmetro de URL não validado geralmente indica que outros existem.
    • Aplicar IMDSv2 na instância afetada e em toda a frota com o comando: aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1. O parâmetro --http-tokens required garante que credenciais só sejam retornadas quando o solicitante apresentar um token de sessão obtido via requisição PUT — algo que um SSRF básico não consegue fazer. O limite de hop em 1 mantém a resposta de metadados na própria instância.

    Mapear o uso do Bedrock

    • Listar os modelos que a role webdev poderia acessar revisando sua política IAM e políticas baseadas em recurso.
    • Determinar o que foi enviado e recebido pelo modelo. O CloudTrail registra a chamada Converse e a contagem de tokens, mas apenas o log de invocação de modelos do Amazon Bedrock captura os prompts e respostas completos. Se estava habilitado, extrair os registros da sessão; se não estava, habilitar agora e registrar que o conteúdo não pode ser recuperado retroativamente.
    • Avaliar exposição de conformidade com base no que esses prompts e respostas continham. Processamento não autorizado de dados regulados (como Informações Pessoais Identificáveis, Informações de Saúde Protegidas ou dados de titulares de cartão) pode gerar obrigações de notificação.

    Verificar comprometimento mais amplo e persistência

    • Consultar o CloudTrail em todas as regiões e serviços para cada evento vinculado à sessão da role webdev.
    • Correlacionar os timestamps do CloudTrail com VPC Flow Logs e logs da aplicação para o IP de origem 75.3.231.105.
    • Buscar eventos IAM de escrita na sessão (CreateUser, CreateRole, CreateAccessKey, AttachRolePolicy) que indiquem tentativas de persistência além das credenciais temporárias.

    Monitorar impacto contínuo ou oculto

    • Revisar o uso do Amazon Bedrock no CloudWatch e nos dados de faturamento para identificar picos de invocação ou consumo inesperado de tokens.
    • Inspecionar os logs de invocação em busca de sinais de dados sensíveis sendo processados ou extraídos pelo modelo.
    • Verificar também tentativas de injeção de prompt, onde o input tenta sobrescrever as instruções do modelo ou extrair prompts do sistema.

    Principais aprendizados e medidas de proteção

    Menor privilégio para roles de workload

    A role webdev não tinha nenhuma justificativa de negócio para acessar o Amazon Bedrock em múltiplas regiões. Aplique o princípio de menor privilégio às roles de instâncias EC2, limitando permissões apenas aos serviços e ações que a aplicação realmente precisa. Use o AWS IAM Access Analyzer para identificar permissões não utilizadas e ajustar políticas proativamente.

    IMDSv1 versus IMDSv2

    O campo ec2RoleDelivery: "1.0" nos logs confirma explicitamente o uso do IMDSv1, que permite a recuperação de credenciais sem token de autenticação. Essa fraqueza arquitetural torna o roubo de credenciais via SSRF trivial. A migração para IMDSv2 teria interrompido este ataque já no primeiro estágio, pois exige tokens de sessão locais baseados em PUT — algo que um SSRF básico não consegue fornecer.

    Mudança de região como sinal de operador experiente

    A migração de us-east-1 para us-east-2 não foi acidental. Agentes maliciosos se movem entre regiões porque monitoramento, alertas e controles de acesso frequentemente são configurados de forma inconsistente. Esse tipo de movimento cross-region é um marcador de consciência operacional e deve elevar a prioridade de uma investigação. A cobertura de detecção consistente em todas as regiões — inclusive as que não são usadas ativamente — deve ser tratada como requisito básico.

    Serviços de IA precisam de visibilidade além do CloudTrail

    O CloudTrail registra quem chamou o Amazon Bedrock e se a chamada foi bem-sucedida, mas não captura o que foi perguntado ou respondido. Habilite o log de invocação de modelos do Amazon Bedrock para capturar prompts e respostas completos para auditoria de conformidade. Para workloads baseados em agentes, o Amazon Bedrock AgentCore Observability fornece rastreamentos em nível de sessão mostrando ordem de execução de ferramentas e latência. Considere também habilitar o Amazon GuardDuty AI Protection, que analisa a atividade do CloudTrail relacionada ao Amazon Bedrock para detectar invocações anômalas, harvesting de custos e tentativas de injeção de prompt. Para orientações de implementação, consulte Monitoramento e Auditoria de Workloads de IA na AWS.

    Técnicas avançadas de evasão para ficar atento

    Além dos padrões específicos deste cenário, a equipe de resposta a incidentes da AWS destaca três técnicas de evasão que observa com frequência:

    • Usuário root real versus usuário IAM chamado “root”: a diferença fica visível no campo type do elemento userIdentity no log do CloudTrail.
    • Imitação de nomes de roles e usuários: agentes maliciosos criam nomes que imitam os reservados pela AWS — por exemplo, AWSServiceRoIeforSupport com “I” maiúsculo no lugar do “l” minúsculo, para fazer parecer que ações foram executadas pelo AWS Support.
    • Usuários chamados HIDDEN_DUE_TO_SECURITY_REASONS: o campo userName recebe essa string quando um login falha por nome de usuário incorreto. Porém, agentes maliciosos já criaram usuários com exatamente esse nome para enganar investigadores que poderiam pensar que o nome foi ocultado por razões de segurança.

    Recursos adicionais

    Fonte

    Incident response guide for AWS CloudTrail investigations – Part 2 (https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-2/)

  • Guia de Resposta a Incidentes com AWS CloudTrail: Análise Forense em Cenários Reais – Parte 1

    Por que o CloudTrail é o ponto de partida de qualquer investigação na AWS

    O AWS CloudTrail registra praticamente tudo que acontece em um ambiente AWS: quem fez o quê, quando, de onde e com qual resultado. Mas ter os logs não é suficiente — saber quais campos observar e como interpretar os padrões é o que separa uma análise superficial de uma investigação completa.

    A AWS publicou um guia de resposta a incidentes baseado em cenários reais utilizados pela equipe interna de resposta a incidentes de segurança (SIRT — Security Incident Response Team). O objetivo é compartilhar as técnicas investigativas aplicadas no dia a dia, com metodologias práticas que qualquer time pode adaptar ao próprio ambiente.

    Nesta primeira parte, dois cenários são explorados em profundidade: exclusão de dados entre contas com implicações de ransomware, e mineração de criptomoedas via CloudFormation usando credenciais de console sem MFA.

    Glossário de termos de resposta a incidentes

    Antes de entrar nos cenários, o guia define os principais termos usados ao longo da investigação. Vale ter esses conceitos claros:

    • Reconhecimento (Reconnaissance): fase inicial em que o agente de ameaça coleta informações sobre o ambiente — por exemplo, listando buckets do Amazon Simple Storage Service (Amazon S3) para entender o que está disponível antes de agir.
    • Enumeração (Enumeration): catalogação sistemática de recursos, usuários ou configurações para identificar alvos ou caminhos de acesso.
    • Movimento lateral (Lateral movement): quando o agente de ameaça se move de um recurso para outro dentro do mesmo ambiente.
    • Escalada de privilégios (Privilege escalation): tentativa de obter permissões mais elevadas do que as obtidas inicialmente, como criar usuários administradores ou modificar políticas do AWS Identity and Access Management (IAM).
    • Evasão de defesa (Defense evasion): técnicas para evitar detecção, como operar em uma Região AWS onde o monitoramento é menos robusto.
    • Persistência (Persistence): estabelecimento de acesso contínuo ao ambiente, por exemplo criando novos usuários IAM ou chaves de acesso.
    • Coleta de credenciais (Credential harvesting): roubo de credenciais de autenticação para se passar por usuários ou funções legítimas.
    • Falsificação de requisição do lado do servidor (SSRF — Server-Side Request Forgery): técnica em que um usuário não autorizado engana um servidor para fazer requisições em seu nome, frequentemente usada para acessar serviços internos como o endpoint do Serviço de Metadados de Instância (IMDS). Veja mais em Entendendo SSRF.
    • IMDSv1 — Serviço de Metadados de Instância versão 1: fornece credenciais temporárias a aplicações rodando em instâncias Amazon Elastic Compute Cloud (Amazon EC2). O IMDSv1 em si não é inseguro, mas quando uma aplicação vulnerável a SSRF roda na instância, o agente de ameaça pode usá-la para acessar o endpoint de metadados e recuperar credenciais. O IMDSv2 mitiga esse risco exigindo tokens de autenticação baseados em sessão.
    • Indicadores de comprometimento (IOCs — Indicators of Compromise): artefatos observáveis (endereços IP, user agents, nomes de sessão, nomes de recursos) que sugerem atividade não autorizada.
    • Exfiltração (Exfiltration): transferência não autorizada de dados para fora do ambiente.
    • Cadeia de eventos (Event chain): sequência de passos seguidos pelo agente de ameaça desde o acesso inicial até o objetivo final.
    • Pivô (Pivot): mudança de técnica, serviço ou Região durante um incidente, frequentemente após uma abordagem inicial ser bloqueada ou para evitar detecção.

    Cenário 1: Exclusão de dados entre contas com implicações de ransomware

    O acesso entre contas é comum em ambientes AWS corporativos, mas uma configuração inadequada cria riscos sérios. Neste cenário, o centro de operações de segurança recebe um alerta automático informando que múltiplos objetos foram deletados do bucket S3 customer-important-data. A investigação inicial parece simples: verificar os logs do CloudTrail, identificar quem deletou os objetos e determinar se foi autorizado. Mas ao aprofundar a análise, o que parecia uma exclusão não autorizada simples revelou-se um incidente entre contas com implicações de ransomware.

    Fase de reconhecimento

    A investigação começa nos logs do CloudTrail, onde a atividade não autorizada se inicia com algo que muitos analistas poderiam descartar como rotina: uma chamada de API ListBuckets feita por meio de uma função assumida às 14:31:22 UTC.

    O registro do CloudTrail contém uma sessão chamada dev-migration-script usando a função CrossAccountS3Access. Embora o acesso entre contas seja comum em ambientes corporativos, os nomes de sessão normalmente refletem unidades de negócio legítimas. Agentes de ameaça frequentemente usam técnicas de mascaramento — nomeando suas sessões como tarefas comuns de desenvolvedor ou scripts de automação — para se misturar ao ruído operacional diário. A correlação desse nome de sessão com o IP de origem externo e os registros históricos de implantação confirmou que nenhum projeto de migração estava autorizado, sinalizando uma tentativa clara de evasão e o primeiro indício de acesso não autorizado.

    Três segundos depois, os logs mostram uma requisição GET para listar objetos no bucket — comportamento clássico de reconhecimento. O agente de ameaça estava catalogando alvos disponíveis usando a mesma função assumida e o mesmo endereço IP.

    {
      "eventVersion": "1.08",
      "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAEXAMPLE123456789:threat-actor-session",
        "arn": "arn:aws:sts::111122223333:assumed-role/CrossAccountS3Access/threat-actor-session"
      },
      "eventTime": "2025-01-20T14:31:22Z",
      "eventSource": "s3.amazonaws.com",
      "eventName": "ListBuckets",
      "sourceIPAddress": "203.0.113.47",
      "recipientAccountId": "444455556666"
    }

    Pontos forenses a observar nesse log:

    • arn com CrossAccountS3Access: função entre contas foi assumida; o acesso veio de outra conta.
    • Nome de sessão threat-actor-session: nome personalizado atribuído no momento da assunção da função.
    • eventName ListBuckets: enumeração de todos os buckets S3 da conta — reconhecimento claro.
    • sourceIPAddress 203.0.113.47: origem da chamada de API.
    • recipientAccountId 444455556666: conta AWS que recebeu a requisição.

    Exclusão sistemática

    Após completar o reconhecimento às 14:31:25 UTC, o agente de ameaça ficou em silêncio por 14 minutos antes da primeira exclusão às 14:45:12 UTC. Durante essa janela, provavelmente revisou o inventário de objetos enumerados, selecionou os alvos de maior valor (dados financeiros, informações pessoalmente identificáveis — PII, e backups de banco de dados) e preparou um script automatizado de exclusão.

    Dentro de 13 segundos (14:45:12–14:45:25 UTC), o agente deletou três arquivos do bucket: um relatório financeiro (q4-2024.xlsx), um banco de dados de PII de clientes (pii-database.csv) e um backup de banco de dados de produção (prod-database-backup.sql). Cada exclusão retornou o código HTTP 204 (sucesso). Os logs de acesso do Amazon S3 confirmam essas operações DELETE bem-sucedidas, todas originadas da mesma sessão.

    Os logs de acesso também revelam que, antes das exclusões, houve operações REST.COPY.OBJECT — os dados financeiros e o banco de PII foram copiados antes de serem destruídos. Esse padrão “copiar e depois destruir” é característico de operações com implicações de ransomware: o agente exfiltra os dados antes de apagá-los, aumentando o poder de coerção.

    Análise de padrões de tempo e acesso

    A janela de exclusão de 13 segundos não foi arbitrária. A string de user-agent mostrou uso da Interface de Linha de Comando da AWS (AWS CLI) no Linux, e o timing preciso indicou execução por script, não operações manuais. O IP de origem consistente em todos os eventos permitiu buscar outras atividades suspeitas da mesma origem e correlacionar com feeds de inteligência de ameaças.

    As amplas permissões de S3 da função CrossAccountS3Access levantam questões sobre implementação do princípio do menor privilégio, revisões regulares de acesso e a justificativa de negócio para permissões tão extensas entre contas.

    Prioridades de investigação e checklist de resposta

    Com a confirmação do abuso de acesso entre contas configurado incorretamente, as prioridades de investigação se concentram em três fatores: se o agente ainda tem acesso ativo (urgência de contenção), se dados sensíveis foram expostos ou exfiltrados (impacto regulatório e de negócio), e se o ataque pode se espalhar para outros recursos ou contas (raio de impacto).

    Perguntas-chave a responder:

    • Como o agente de ameaça obteve acesso à função CrossAccountS3Access?
    • Os arquivos foram copiados antes da exclusão?
    • Qual é a relevância específica dos objetos deletados?

    Checklist de resposta:

    • Determinar se o propósito de negócio do acesso entre contas é legítimo
    • Identificar os eventos de autenticação correspondentes que mostram como a função foi assumida
    • Identificar outros recursos AWS que essa função pode acessar além do S3
    • Verificar tentativas falhas ou atividades de reconhecimento que precederam o evento bem-sucedido
    • Determinar quando essa relação de confiança entre contas foi criada
    • Verificar quando foi feita a última revisão de acesso dessa função
    • Localizar cópias de backup dos dados deletados
    • Definir regras de detecção para capturar atividades similares no futuro

    Cenário 2: Mineração de criptomoedas via CloudFormation com credenciais de console

    Neste cenário, o time financeiro percebe um pico inesperado nos custos AWS, especialmente em cobranças de computação EC2 na Região us-east-1. Durante a investigação, examina-se como agentes de ameaça usam acesso legítimo ao console para implantar operações de mineração de criptomoedas via AWS CloudFormation e como investigadores podem descobrir o escopo de eventos de sequestro de recursos.

    Uma stack CloudFormation chamada CRYPTO é descoberta sem nenhum registro de criação autorizada. A stack contém instâncias EC2 rodando na Amazon Virtual Private Cloud (Amazon VPC) de produção, consumindo recursos computacionais significativos.

    Análise do evento CloudTrail de criação da stack

    O registro do evento CloudTrail para a ação não autorizada CreateStack revela informações críticas:

    {
      "eventVersion": "1.11",
      "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAFINDANEXAMPLE:Participant",
        "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/WSParticipantRole/Participant",
        "sessionContext": {
          "sessionIssuer": {
            "type": "Role",
            "userName": "WSParticipantRole"
          },
          "attributes": {
            "mfaAuthenticated": "false"
          }
        }
      },
      "eventTime": "2025-09-23T18:07:12Z",
      "eventSource": "cloudformation.amazonaws.com",
      "eventName": "CreateStack",
      "awsRegion": "us-east-1",
      "userAgent": "aws-cli/2.30.0 ... exec-env/CloudShell",
      "requestParameters": {
        "stackName": "CRYPTO",
        "parameters": [
          { "parameterKey": "VpcId" },
          { "parameterKey": "SubnetIds" }
        ]
      },
      "responseElements": {
        "stackId": "arn:aws:cloudformation:us-east-1:...:stack/CRYPTO/2102e190..."
      },
      "sessionCredentialFromConsole": "true"
    }

    Pontos forenses essenciais:

    • stackName: "CRYPTO": indicador direto de atividade de mineração de criptomoedas.
    • VpcId + SubnetIds: o agente de ameaça tinha conhecimento prévio da rede — reconhecimento confirmado.
    • mfaAuthenticated: "false": a sessão não tinha Autenticação Multifator (MFA) — lacuna crítica de controle de segurança.
    • sessionCredentialFromConsole: "true": acesso via portal web do console AWS, não por API externa.
    • exec-env/CloudShell: comandos executados via AWS CloudShell baseado em navegador.

    Insight forense avançado: o pivô pelo CloudShell

    O campo sessionCredentialFromConsole: true indica que o acesso se originou do console AWS, não de chaves de API programáticas externas. Mas o campo userAgent revela que o ambiente de execução foi o exec-env/CloudShell — ou seja, o agente de ameaça não clicou manualmente pela interface do CloudFormation. Em vez disso, abriu o CloudShell logo após o login para executar um script de implantação pré-preparado. Isso permitiu velocidade automatizada enquanto evitava o monitoramento tradicional de chaves de API estáticas.

    A sessão teve início às 18:06:22Z e a stack foi criada às 18:07:12Z — apenas 50 segundos depois. Essa velocidade indica que o agente chegou preparado com um script, não explorando o ambiente manualmente.

    Prioridades de investigação e checklist de resposta

    A investigação se organiza em três fases:

    • Reconstruir a linha do tempo da sessão no console: filtrar o CloudTrail pelo mesmo token de sessão para identificar se houve reconhecimento antes da implantação da stack, se outros serviços ou Regiões foram acessados, e se houve tentativas de estabelecer persistência (como criação de usuários IAM ou chaves de acesso).
    • Examinar o que a stack realmente implantou: inspecionar o template do CloudFormation para entender os tipos de instâncias EC2 criadas, as regras de grupos de segurança, scripts de user data que possam ter instalado software de mineração na inicialização, e se a stack criou funções IAM próprias com permissões para movimento lateral.
    • Calcular o impacto de negócio e o raio de impacto: quantificar o custo computacional, verificar se as instâncias de mineração tinham caminhos de rede para bancos de dados de produção ou serviços internos, examinar logs de tráfego de saída para conexões com pools de mineração conhecidos, e buscar stacks similares em outras Regiões e contas.

    Checklist de resposta:

    • Determinar por que o MFA não era obrigatório para essa operação sensível
    • Investigar como o agente obteve credenciais válidas de console
    • Verificar tentativas de login malsucedidas antes desse acesso bem-sucedido
    • Verificar outras atividades ocorridas durante essa sessão de console
    • Identificar recursos criados pela stack CloudFormation
    • Determinar há quanto tempo esses recursos estão rodando e consumindo custos
    • Buscar outras stacks com nomes similares ou suspeitos no ambiente
    • Verificar que acesso de rede essas instâncias têm a recursos internos
    • Determinar quais conexões de saída essas instâncias estão fazendo
    • Verificar conexões com pools de mineração de criptomoedas
    • Verificar se usuários ou funções IAM foram criados
    • Verificar se chaves de acesso adicionais foram geradas
    • Determinar se o agente modificou permissões ou políticas existentes

    Lições aprendidas dos dois cenários

    Os dois cenários reforçam princípios que se aplicam amplamente a investigações de incidentes na AWS:

    • Nomes de sessão incomuns revelam intenção: agentes de ameaça frequentemente usam nomes que imitam processos legítimos. Sempre cruze com registros históricos de projetos autorizados.
    • Timing preciso indica automação: janelas de execução de segundos sugerem scripts preparados previamente, o que exige estratégias de resposta diferentes de intrusões manuais.
    • Acesso entre contas precisa de escrutínio extra: relações de confiança se tornam vetores de acesso não autorizado quando credenciais são expostas.
    • MFA é inegociável para acesso ao console em ambientes de produção: a ausência de MFA foi o que viabilizou toda a sequência do Cenário 2.
    • Monitoramento de custos é monitoramento de segurança: picos inesperados de faturamento podem ser os primeiros indicadores de sequestro de recursos.
    • O campo sessionCredentialFromConsole é seu ponto de partida para distinguir entre acesso via console e acesso programático.
    • Nomeação de recursos pode ser um indicador: o nome óbvio CRYPTO sugere confiança excessiva do agente ou má segurança operacional — ambos preocupantes por razões diferentes.

    O que vem na Parte 2

    Na Parte 2 do guia, a AWS examina como uma vulnerabilidade em aplicação web pode se transformar em um incidente multi-Região afetando serviços de inteligência artificial, encadeando SSRF, coleta de credenciais via IMDSv1 e pivô entre Regiões para acessar o Amazon Bedrock. A segunda parte também cobre técnicas investigativas críticas: a diferença entre usuário root e um usuário IAM nomeado “root”, táticas de imitação de nomes de funções, e o truque do nome de usuário HIDDEN_DUE_TO_SECURITY_REASONS — além de passos de hardening e recursos adicionais para fortalecer capacidades forenses na nuvem.

    Fonte

    Incident response guide for AWS CloudTrail investigations – Part 1 (https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-1/)

  • Migrando a fonte de identidade no AWS IAM Identity Center: guia completo do Active Directory para Okta

    Por que trocar a fonte de identidade é um momento crítico

    O AWS IAM Identity Center é o serviço central de gerenciamento de acesso da AWS para contas AWS e aplicações integradas. Uma das decisões mais impactantes que uma organização pode tomar nesse contexto é mudar a fonte de identidade — ou seja, o sistema que define quem são os usuários e grupos que têm acesso ao ambiente AWS.

    Essa mudança costuma acontecer quando a empresa troca de provedor de identidade (IdP), consolida sua infraestrutura de identidade, adota novas capacidades de Single Sign-On (Logon Único) ou migra de sistemas legados on-premises. O problema é que uma transição sem planejamento adequado pode resultar em perda temporária de acesso a contas e aplicações AWS até que as permissões sejam restauradas.

    A AWS publicou um guia técnico detalhado que explica como fazer essa transição com segurança, incluindo um runbook passo a passo para migrar do Active Directory para o Okta como IdP externo via SAML 2.0 (Linguagem de Marcação para Asserções de Segurança). O material também disponibiliza scripts de automação no repositório aws-samples no GitHub.

    As três fontes de identidade disponíveis no IAM Identity Center

    Cada instância do IAM Identity Center se conecta a uma única fonte de identidade por vez. A AWS suporta três opções:

    • Identity Center Directory: o armazenamento de identidade padrão. Usuários e grupos são criados e gerenciados diretamente no IAM Identity Center, sem dependência de um provedor externo. Indicado para organizações sem um diretório corporativo existente ou que preferem uma configuração que use apenas serviços AWS.
    • Active Directory: integração com um Microsoft Active Directory on-premises ou com o AWS Managed Microsoft AD via AWS Directory Service. Permite reutilizar identidades, associações a grupos e políticas de acesso já existentes no AD.
    • IdP Externo: integração com provedores terceiros que suportam SAML 2.0, como Okta Universal Directory, Microsoft Entra ID (antigo Azure AD), Ping Identity, entre outros.

    O que é destruído na troca de fonte de identidade

    Esse é o ponto mais crítico do guia: transições que envolvem o Active Directory são destrutivas. Ao confirmar a troca da fonte de identidade do AD para um IdP externo, o IAM Identity Center imediatamente exclui todos os usuários, grupos e suas respectivas atribuições — tanto de contas quanto de aplicações.

    Já a transição entre um IdP externo e o diretório local do Identity Center preserva usuários, grupos e atribuições. A tabela abaixo resume o comportamento:

    • Troca do AD para IdP externo: usuários, grupos, atribuições de contas e atribuições de aplicações são excluídos e precisam ser recriados.
    • Troca de IdP externo para o diretório local: tudo é preservado.

    Um ponto de atenção adicional: aplicações gerenciadas pela AWS que mantêm sua própria referência à fonte de identidade — como o Amazon SageMaker Studio e o Amazon OpenSearch Service — podem não ter o acesso totalmente restaurado apenas pela API CreateApplicationAssignments. Essas aplicações têm dependências do ID da fonte de identidade original e precisam ser tratadas caso a caso. Para mais detalhes sobre considerações ao trocar a fonte de identidade, a AWS mantém documentação específica sobre o tema.

    O processo em cinco etapas

    O guia da AWS estrutura a migração em cinco etapas fundamentais, que se aplicam a qualquer transição de fonte de identidade no IAM Identity Center:

    • Etapa 1 — Backup: antes de qualquer mudança, exporte todos os dados de identidade: usuários, grupos e atribuições. O script de precheck gera arquivos CSV com todas as atribuições e principais do Identity Center.
    • Etapa 2 — Preparar e validar usuários na nova fonte: confirme que os usuários e grupos existem na nova fonte de identidade antes de fazer a troca. Divergências em campos como UserName ou DisplayName podem impedir que os usuários se conectem após a migração.
    • Etapa 3 — Trocar a fonte de identidade: atualize o IAM Identity Center para apontar para a nova fonte. Para IdPs externos, isso envolve fazer upload dos metadados SAML e configurar o SCIM (Sistema de Gerenciamento de Identidade entre Domínios) para provisionamento automatizado. Atenção: ao confirmar essa mudança, todas as atribuições do AD são imediatamente excluídas.
    • Etapa 4 — Restaurar atribuições: após o provisionamento dos usuários e grupos na nova fonte, restaure todas as atribuições de contas usando o script de restauração. Um comando adicional verifica se há atribuições faltando ou em excesso.
    • Etapa 5 — Validar o acesso: teste o acesso para uma amostra representativa de usuários com diferentes perfis e níveis de permissão antes de declarar a migração concluída.

    Os scripts e detalhes estão disponíveis no GitHub. Bugs e solicitações de funcionalidades podem ser reportados via GitHub Issues. Clientes com Enterprise Support podem contatar seu Gerente Técnico de Contas (TAM) para dúvidas adicionais.

    Runbook detalhado: do Active Directory para o Okta

    O guia apresenta um runbook com sete fases para a migração do AD para o Okta como IdP SAML 2.0. Abaixo, um resumo de cada fase:

    Fase 1: Planejamento pré-migração

    Envolve quatro componentes: engajamento dos stakeholders (responsável pelo AD, administrador AWS, administrador Okta), inventário do estado atual com o script de precheck, definição da janela de cutover em período de baixo uso, e confirmação dos acessos necessários.

    python -m idc_migration_tool precheck --output-dir ./export

    Esse comando gera dois arquivos: assignments.csv (uma linha por conta, permission set e atribuição de principal) e principals.csv (todos os usuários e grupos do identity store).

    Fase 2: Validação pré-cutover

    Validar que os arquivos de backup estão presentes e não vazios, comunicar o impacto aos usuários (incluindo o novo fluxo de login pelo Okta), e realizar testes em ambiente sandbox com um usuário de teste para confirmar o provisionamento SCIM e o fluxo de autenticação de ponta a ponta.

    Fase 3: Execução do cutover

    Esta fase inclui a configuração do aplicativo Okta (obtendo o arquivo de metadados SAML), a troca da fonte de identidade no console do IAM Identity Center (com upload do XML de metadados e do certificado de assinatura SAML), a habilitação do provisionamento automático via SCIM, a configuração da integração SCIM no Okta com as URLs de endpoint e token gerados, e a configuração das URLs de ACS (Serviço de Asserção ao Consumidor) e Issuer no Okta.

    Atenção: o downtime começa no momento em que a troca da fonte de identidade é confirmada. Usuários perdem acesso imediatamente e só recuperam após a conclusão da Fase 4.

    Fase 4: Reconstrução das atribuições

    Verificar que todos os usuários e grupos do Okta foram sincronizados via SCIM no IAM Identity Center, e então executar o script de restauração:

    python -m idc_migration_tool cutover --csv ./export/assignments.csv

    O script faz o match dos nomes de principais na nova fonte de identidade, cria as atribuições e reporta sucesso ou falha para cada uma. Aguarde de 5 a 10 minutos para a propagação das permissões antes de iniciar os testes.

    Fase 5: Validação pós-migração

    Teste o acesso de ponta a ponta com um usuário Okta de teste, validando login no dashboard, acesso ao portal AWS, assunção de role e navegação no console. Faça spot-check com usuários de diferentes perfis (Administrador, Desenvolvedor, Somente Leitura). Use o script de validação para detectar atribuições faltando ou em excesso:

    python -m idc_migration_tool validate --csv ./export/assignments.csv --output-dir ./export

    Se houver divergências, o script gera um arquivo drift_report.csv com entradas MISSING e EXTRA.

    Fase 6: Limpeza e monitoramento pós-migração

    Remova recursos obsoletos (roles IAM sincronizadas pelo AD que não foram limpas automaticamente), monitore o SCIM nos dias seguintes, revise os logs do IAM Identity Center e do AWS CloudTrail para tentativas de login com falha, e atualize toda a documentação interna (SOPs, guias de onboarding, mapeamentos de grupos para permission sets). O comando abaixo identifica usuários desativados, grupos vazios e permission sets sem atribuição:

    # Apenas relatório
    python -m idc_migration_tool cleanup
    
    # Relatório com prompt para exclusão
    python -m idc_migration_tool cleanup --delete

    Importante: não descomissione os domain controllers do Active Directory até ter certeza de que a migração está estável e que o rollback não será mais necessário.

    Fase 7: Rollback (se necessário)

    O IAM Identity Center não retém usuários, grupos ou atribuições do AD após a troca de fonte de identidade. Um rollback exige trocar manualmente a fonte de identidade de volta para o Active Directory e reconstruir todas as atribuições a partir dos arquivos de backup. Não há desfazer automático.

    O processo envolve: navegar até as configurações do IAM Identity Center, selecionar Active Directory como fonte de identidade, confirmar que o AD ainda está acessível, aguardar a ressincronização dos usuários e grupos, e então executar novamente o script de restauração:

    python -m idc_migration_tool cutover --csv ./export/assignments.csv

    Para dicas de troubleshooting, a AWS mantém documentação sobre resolução de problemas no IAM Identity Center.

    Conclusão

    A migração de fonte de identidade no IAM Identity Center é uma operação de alto impacto que exige planejamento cuidadoso. O guia publicado pela AWS oferece uma estrutura completa — desde o backup inicial até o rollback de emergência — para que times de identidade e segurança executem essa transição com previsibilidade e controle.

    Os scripts de backup e restauração estão disponíveis no repositório aws-samples no GitHub. Para aprofundar o conhecimento sobre configuração do IAM Identity Center e gerenciamento de permission sets, a AWS recomenda o AWS Security Blog e a documentação oficial do AWS IAM Identity Center.

    Fonte

    Managing identity source transition for AWS IAM Identity Center (https://aws.amazon.com/blogs/security/managing-identity-source-transition-for-aws-iam-identity-center/)

  • Segurança Agêntica: Detecção e Resposta na Velocidade das Máquinas

    O Maior Salto de Postura de Segurança Desde a Migração para a Nuvem

    Conversas com líderes de segurança corporativa ao longo do último ano apontam para um consenso claro: a ascensão dos agentes de IA autônomos representa a mudança mais significativa em postura de segurança desde a adoção da nuvem. Organizações de todos os setores já estão implantando agentes de IA que autenticam em nome de usuários, executam fluxos de trabalho com múltiplas etapas e tomam decisões sobre infraestrutura — frequentemente sem aguardar aprovação humana.

    Diante desse cenário, a AWS colaborou com o SANS Institute para produzir um capítulo inédito no eBook Cloud Security Exchange 2026, apresentando um framework prático para proteger cargas de trabalho agênticas em escala empresarial.

    O Desafio: Ameaças que Operam na Velocidade das Máquinas

    A segurança tradicional foi construída para sistemas determinísticos, com entradas e saídas previsíveis. Os workloads agênticos quebram essas premissas de forma fundamental. O mesmo prompt pode gerar uma resposta dentro das políticas em uma requisição e uma resposta que viola essas mesmas políticas na seguinte. Agentes adaptam seu comportamento ao longo do tempo conforme interagem com usuários, dados e ferramentas, operando com autonomia real: conectando-se a APIs, encadeando ações e tomando decisões independentes.

    Essas características tornam os controles de segurança baseados em avaliações pontuais insuficientes. A detecção e a resposta precisam operar de forma contínua e na mesma velocidade em que os agentes atuam.

    O que torna o cenário ainda mais urgente é o abismo entre a velocidade de adoção e a maturidade de governança: 80% das organizações já adotaram IA, mas apenas 10% a governam de forma estruturada. Agentes estão sendo desenvolvidos por um número crescente de profissionais — incluindo quem usa ferramentas low-code — criando desafios de governança que os programas de segurança existentes precisam urgentemente endereçar.

    Estendendo o que Já Funciona

    A boa notícia é que a segurança agêntica não começa do zero. Ela se apoia nos mesmos princípios que os times de segurança já aplicam: governança de identidade, privilégio mínimo, defesa em profundidade e recuperação de desastres. O que muda é a forma como esses princípios são implementados quando as cargas de trabalho são autônomas e probabilísticas.

    O framework apresentado no eBook organiza quatro áreas fundamentais:

    1. Identidade e Governança de Agentes

    Cada agente precisa de sua própria identidade, com credenciais temporárias e com escopo definido — em vez de acessos persistentes e amplos. Isso estende os princípios de zero trust para agentes de IA, onde cada requisição é autenticada e autorizada de forma independente, e cada ação possui uma cadeia de autorização rastreável.

    Quando um único agente combina acesso a dados sensíveis, capacidade de comunicação externa e exposição a conteúdo não confiável, o perfil de risco muda de forma significativa. Padrões de design que impedem qualquer componente individual de reunir essas três capacidades ao mesmo tempo reduzem esse risco de forma substancial.

    2. Detecção Evoluída para Cargas de Trabalho Agênticas

    A detecção estática baseada em regras, projetada para padrões de atividade humana, não consegue acompanhar o comportamento dos agentes. As organizações precisam de monitoramento comportamental contínuo, baselines dinâmicos que se adaptam conforme os agentes evoluem, e instrumentação de observabilidade que identifique anomalias em tempo real.

    O Amazon GuardDuty entrega essa capacidade hoje, analisando sinais de segurança de forma contínua para detectar ameaças à medida que surgem.

    3. Resposta que Equilibra Velocidade e Precisão

    Quando as ameaças se movem na velocidade das máquinas, a resposta precisa ser automatizada e estruturada em camadas: alguns comportamentos de agentes devem ser contidos imediatamente, enquanto outros exigem julgamento humano. O framework distingue entre ações que podem ser automatizadas com segurança e aquelas que precisam de escalonamento para revisão humana.

    4. De Agentes Individuais a Ecossistemas Multiagentes

    Os agentes já estão se organizando em equipes, delegando subtarefas, negociando acessos e coordenando ações além das fronteiras organizacionais. Cada estágio dessa evolução herda todos os requisitos de segurança das etapas anteriores — o que significa que as organizações que protegem hoje seus agentes básicos de chat já estão construindo a base para os ecossistemas multiagentes de amanhã.

    Segurança como Habilitadora da Adoção de IA Agêntica

    Os líderes de segurança com quem a AWS tem dialogado não estão questionando se vão adotar agentes de IA. A pergunta é como fazer isso de forma responsável, com agilidade e sem frear o negócio.

    A abordagem da AWS para esse desafio é construir segurança na plataforma em todas as camadas. Workloads agênticos desenvolvidos sobre a AWS herdam quase duas décadas de experiência em segurança de cargas de trabalho críticas. O Amazon GuardDuty, o Amazon Inspector e o AWS Security Hub trabalham em conjunto para fornecer detecção contínua de ameaças, gerenciamento de vulnerabilidades e operações de segurança unificadas — todos adaptados às características únicas dos workloads agênticos.

    Não se trata de construir uma nova segurança do zero, mas de estender as bases de segurança já consolidadas para um ambiente onde a IA opera com autonomia crescente.

    Acesse o Framework Completo

    O capítulo da AWS no eBook aprofunda cada uma dessas áreas, com padrões arquiteturais específicos, orientações de implementação e frameworks para times de segurança em todos os estágios de maturidade com IA agêntica — seja avaliando, em fase piloto ou operando em escala.

    Leia o capítulo completo: Segurança Agêntica: Detecção e Resposta na Velocidade das Máquinas.

    Para saber mais sobre os serviços de segurança da AWS, acesse a página de Segurança na Nuvem AWS ou explore o Framework de Segurança para IA da AWS, que apresenta uma visão abrangente de como a AWS protege workloads de IA com os controles certos, nas camadas certas e nas fases certas.

    Fonte

    Agentic security: Detection and response at machine speed (https://aws.amazon.com/blogs/security/agentic-security-detection-and-response-at-machine-speed/)

  • Amazon Kinesis Data Streams agora suporta dry run para validar requisições de API

    O que mudou no Kinesis Data Streams

    A AWS anunciou uma novidade importante para quem trabalha com o Amazon Kinesis Data Streams: o serviço agora conta com suporte ao recurso de dry run (execução simulada), que permite validar requisições de API sem que a operação seja de fato executada.

    Como funciona o dry run

    A mecânica é simples e direta. O desenvolvedor passa o novo parâmetro opcional DryRun com o valor true na chamada de API. Com isso, o serviço realiza todas as verificações necessárias — incluindo permissões — sem interagir de verdade com o stream em produção.

    Se tudo estiver correto, a API retorna uma exceção chamada DryRunOperationException. Esse retorno é, na prática, uma confirmação positiva: significa que a requisição teria sido bem-sucedida caso o parâmetro DryRun não estivesse presente.

    Por que isso resolve um problema real

    Antes dessa funcionalidade, não havia uma forma segura de testar se uma aplicação possuía as permissões corretas para acessar um stream. A solução mais comum era engenhosa, mas frágil: enviar uma requisição deliberadamente falha após a verificação de permissões. Um exemplo clássico era usar o PutRecord com um payload propositalmente maior do que o tamanho máximo suportado pelo serviço.

    O problema dessa abordagem é que ela dependia dos limites vigentes do serviço. Se esses limites fossem alterados em algum momento, a requisição poderia ser processada com sucesso — gravando registros não intencionais no stream de produção e em todos os consumidores downstream. Era um risco silencioso e difícil de prever.

    Com o dry run, esse risco deixa de existir. A validação passa a ser explícita, controlada e segura.

    Quais APIs são compatíveis

    O recurso de dry run está disponível para cinco APIs do Kinesis Data Streams:

    • PutRecord
    • PutRecords
    • GetRecords
    • GetShardIterator
    • SubscribeToShard

    A funcionalidade está disponível em todas as regiões da AWS onde o Amazon Kinesis Data Streams opera.

    Onde encontrar mais informações

    Para entender em detalhes como utilizar o dry run no seu ambiente, a AWS disponibiliza a documentação oficial: Teste suas permissões e entradas de requisição com dry run no Guia do Desenvolvedor do Amazon Kinesis Data Streams. Para consultar os parâmetros e estruturas de chamada, acesse a Referência de API do Amazon Kinesis Data Streams.

    Fonte

    Amazon Kinesis Data Streams now supports a dry run feature to validate API requests (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-kinesis-data-streams-api/)

  • Segurança no Amazon QuickSight do POC à produção: Agentes, Flows e Spaces

    O problema clássico: do piloto à produção

    Um padrão recorrente em projetos de análise de dados na nuvem é o seguinte: a prova de conceito (POC) funciona muito bem com um time pequeno, mas trava quando as equipes de segurança e conformidade analisam o plano de produção. Um modelo de permissões que funciona para dez usuários piloto costuma quebrar quando cinco departamentos inteiros entram na equação. Agentes podem retornar dados fora do escopo pretendido, e equipes de auditoria têm dificuldade para rastrear como datasets, agentes e Spaces se conectam.

    Foi justamente para endereçar esse problema que a AWS publicou um guia técnico detalhado sobre como estruturar o Amazon QuickSight — dashboards, Chat Agents, Flows e Spaces com bases de conhecimento — de forma que a segurança se sustente à medida que usuários e departamentos são adicionados.

    O cenário de referência: AnyCompany

    O guia usa como base uma empresa fictícia chamada AnyCompany: 5.000 funcionários, 5 departamentos e 5 localidades. Três perfis de usuário precisam acessar os mesmos dados, mas em níveis diferentes:

    • Liderança de RH: acesso completo, incluindo salários e risco de saída voluntária (attrition).
    • Gestores de departamento: apenas métricas operacionais da própria equipe.
    • Todos os funcionários: políticas da empresa e tendências agregadas e anonimizadas.

    Expor um único dataset a todos os três perfis e depender exclusivamente de permissões para controlar o acesso cria uma superfície de risco considerável. Uma única configuração incorreta pode expor dados salariais para toda a empresa.

    A solução: segurança na arquitetura dos dados

    A abordagem proposta pela AWS modela um dataset de origem em três visões alinhadas com os níveis de autorização de cada perfil. Cada visão se conecta a um agente dedicado, que por sua vez alimenta um dashboard específico para aquele público. Ações externas são controladas por um Flow com revisão humana obrigatória.

    A lógica central é simples e poderosa: remover os dados antes que cheguem ao usuário, em vez de depender de configurações de permissão para bloquear o acesso. Se a coluna de salário não existe no dataset do gestor, nenhum erro de configuração pode expô-la.

    Os quatro padrões validados

    1. Modelagem de datasets (Dataset Shaping)

    O primeiro passo é criar três datasets a partir da mesma fonte de dados:

    • anycompany-employees-full: todas as 30 colunas, para a liderança de RH.
    • anycompany-employees-manager: 4 colunas sensíveis removidas (salário anual, percentual de bônus, data e motivo de desligamento), para gestores de departamento.
    • anycompany-employees-aggregated: apenas resumos por departamento e localidade (25 linhas no total), para todos os funcionários.

    Remover colunas no nível do dataset é estruturalmente mais seguro do que ocultá-las via permissões. O dado simplesmente não existe nos datasets downstream — nenhuma configuração incorreta pode expor o que não está lá.

    2. Segurança em nível de linha — Row-Level Security (RLS)

    A Segurança em Nível de Linha (RLS) do Amazon QuickSight restringe quais linhas cada usuário pode ver, com base na identidade. A configuração é feita no nível do dataset, por meio de um dataset de mapeamento que associa usuários ou grupos a valores de coluna específicos — e essa restrição se propaga automaticamente para todas as análises e dashboards vinculados.

    Para o dataset de gestores, cria-se um arquivo CSV de regras com duas colunas: UserName e Department. Cada gestor recebe uma linha correspondendo ao seu departamento. O administrador de RH recebe cinco linhas para acesso completo. Um ponto de atenção importante: qualquer divergência no nome de usuário — mesmo um único caractere — faz com que a consulta retorne zero linhas. O guia recomenda usar o campo calculado username() em uma análise para confirmar o formato exato.

    3. Isolamento de agentes (Agent Isolation)

    Cada Chat Agent deve se conectar a exatamente um dataset, dimensionado para o seu público. O guia descreve três agentes:

    • Executive Insights Agent: conectado ao dataset completo, compartilhado apenas com o grupo hr-leadership.
    • Manager Assistant Agent: conectado ao dataset de gestores com RLS aplicado, compartilhado apenas com dept-managers.
    • Employee Self-Service Agent: conectado ao dataset agregado e à base de conhecimento com documentos de políticas, compartilhado com todos os funcionários.

    Antes de declarar qualquer agente pronto para produção, a AWS recomenda testes com consultas adversariais — perguntas que tentam extrair dados fora do escopo pretendido. Por exemplo: pedir o salário de um funcionário específico ao agente de todos os funcionários deve resultar em recusa, porque esse dado simplesmente não existe no dataset conectado.

    4. Classificação de documentos e Spaces

    Um Space organiza documentos e fornece respostas fundamentadas em uma base de conhecimento. O princípio de segurança aqui é o mesmo: excluir documentos sensíveis em vez de depender de permissões para bloqueá-los. Todos os documentos em uma base de conhecimento são consultáveis por qualquer pessoa com acesso de Visualizador — portanto, a única forma de impedir o acesso a conteúdo sensível é mantê-lo fora da base desde o início.

    O guia exemplifica com um arquivo de feedback individual de funcionários (employee_feedback_full_dataset.pdf) que é deliberadamente excluído do Space compartilhado. Se a liderança de RH precisar desses dados, a recomendação é criar um Space separado, compartilhado exclusivamente com esse grupo.

    Os Spaces usam um modelo de dois níveis de acesso: Proprietários (podem visualizar, consultar e fazer upload) e Visualizadores (podem visualizar e consultar, sem upload). Usuários não adicionados não têm acesso algum.

    Flows com revisão humana obrigatória

    Flows encadeiam múltiplas etapas e podem pausar para revisão humana antes de continuar. O guia descreve a criação de um Flow chamado Weekly Attrition Risk Alert, com quatro etapas:

    • Etapa 1: Consulta o dataset e filtra funcionários com alto risco de saída voluntária.
    • Etapa 2: Processa os resultados filtrados (aproximadamente 300 funcionários, com base na taxa de ~25% no dataset sintético).
    • Etapa 3: Pausa a execução até que um aprovador designado revise e aprove explicitamente.
    • Etapa 4: Após aprovação, envia alertas para o grupo de gestores de departamento.

    O Flow só avança para a notificação externa após aprovação humana explícita — nenhuma ação sai do sistema sem revisão. Credenciais de sistemas externos devem ser armazenadas no AWS Secrets Manager, nunca embutidas na definição do Flow.

    Auditoria com AWS CloudTrail

    O AWS CloudTrail registra automaticamente os eventos de gerenciamento do Amazon QuickSight (chamadas de API) sem configuração adicional. Com um trail ativo na conta, é possível verificar consultas de agentes, acessos a datasets, execuções de Flows e alterações de permissões no histórico de eventos, filtrando pela origem quicksight.amazonaws.com. Cada evento registra a identidade do usuário, o timestamp, o nome do evento e o ARN do recurso.

    Como a segurança escala com a adoção

    O modelo baseado em grupos permite adicionar novos funcionários com uma simples mudança de associação de grupo — sem reconfigurar acessos. Novos datasets ou Spaces só precisam ser criados quando surge uma fronteira de confidencialidade genuinamente nova. Na fase piloto, um dataset e um agente por público é suficiente. Ao escalar para 50 ou mais equipes, a estrutura se mantém.

    Framework de governança

    O guia propõe um framework de governança com proprietários e revisores definidos para cada tipo de ativo:

    • Datasets: proprietário = responsável pelos dados; revisor = equipe de segurança; cadência trimestral.
    • Dashboards: proprietário = líder de analytics; revisor = grupo consumidor; cadência trimestral.
    • Chat Agents: proprietário = construtor do agente; revisor = responsável pelos dados + segurança; cadência mensal.
    • Bases de conhecimento: proprietário = dono do conteúdo; revisor = responsável pelos dados; cadência mensal.
    • Flows: proprietário = dono do processo; revisor = equipe de segurança; revisão a cada mudança.
    • Spaces: proprietário = administrador do Space; revisor = responsável pelos dados; cadência trimestral.

    Roteiro de implantação em fases

    • Semanas 1–2 (POC com guardrails): um dataset por público, RLS desde o primeiro dia, testes adversariais.
    • Semanas 3–4 (expansão piloto): Space e base de conhecimento, separação de permissões, Flows com portões de aprovação.
    • Semanas 5–8 (hardening para produção): todos os departamentos, revisões adversariais trimestrais.
    • Escala enterprise (contínuo): logs de auditoria, checklist antes de cada novo ativo, revisões periódicas de acesso.

    Checklist de prontidão para produção

    O guia inclui um checklist de verificações booleanas que qualquer membro da equipe pode executar antes de colocar um novo ativo em produção:

    Datasets: dataset dimensionado para um único público; colunas sensíveis removidas (não apenas ocultadas); RLS aplicado e testado com pelo menos duas contas; permissões atribuídas a grupos, não a indivíduos.

    Chat Agents: agente conectado a exatamente um dataset; tópicos excluem colunas que não devem ser consultáveis; agente recusa consultas sobre registros individuais quando o dataset não os contém; agente recusa consultas sobre colunas excluídas.

    Spaces e bases de conhecimento: cada documento classificado antes do upload; nenhum documento contém Informações de Identificação Pessoal (PII) a menos que necessário para o público; permissões de visualização, consulta e upload configuradas separadamente; upload restrito a proprietários de conteúdo.

    Flows: Flow usa dataset protegido por RLS e com colunas removidas; etapa de aprovação humana existe antes de qualquer ação externa; credenciais externas armazenadas no AWS Secrets Manager; AWS CloudTrail ativo e capturando eventos do Flow.

    Recursos adicionais

    Para aprofundar o tema, a AWS disponibiliza documentação complementar: Segurança em nível de linha no Amazon QuickSight, Gerenciamento de grupos, Guia do usuário do AWS CloudTrail, Guia do usuário do AWS Secrets Manager, Amazon Bedrock Guardrails para controles de segurança em IA, e um post sobre monitoramento centralizado para administração do Amazon QuickSight com dashboards baseados em AWS CloudTrail. O repositório de código com scripts e datasets sintéticos está disponível no repositório GitHub de referência.

    Fonte

    Securing Amazon Quick from POC to production: Agents, Flows, and Spaces (https://aws.amazon.com/blogs/machine-learning/securing-amazon-quick-from-poc-to-production-agents-flows-and-spaces/)

  • Amazon Redshift passa a suportar autenticação via AWS IAM Identity Center com roteamento VPC aprimorado

    O que foi anunciado

    A AWS anunciou que o Amazon Redshift passou a suportar autenticação via AWS IAM Identity Center em clusters provisionados e grupos de trabalho serverless configurados com Roteamento VPC Aprimorado (EVR — Enhanced VPC Routing). A novidade permite que usuários acessem o Redshift por meio de login único (SSO — Single Sign-On) utilizando suas credenciais corporativas, com todo o tráfego passando pela Nuvem Privada Virtual da Amazon (VPC — Amazon Virtual Private Cloud) e permanecendo dentro da rede AWS.

    Por que isso importa

    Para equipes que lidam com requisitos regulatórios, residência de dados ou isolamento de rede, essa combinação é especialmente relevante: com o EVR ativo, nenhum tráfego entre o warehouse do Redshift e outros serviços AWS sai pela internet pública. Todo o fluxo passa pela VPC, onde é possível governá-lo com grupos de segurança, listas de controle de acesso de rede (ACLs) e políticas de endpoint, além de monitorá-lo via VPC Flow Logs.

    Como funciona a autenticação com IAM Identity Center e EVR

    Com esse lançamento, o Redshift passa a validar e trocar tokens do IAM Identity Center por meio de endpoints de interface VPC via AWS PrivateLink, diretamente de dentro da VPC. Isso significa que o processo de autenticação e autorização segue o mesmo caminho de rede controlado que já era aplicado ao restante do tráfego do Redshift — sem exceções ou desvios pela internet.

    Suporte a replicação multi-região

    O recurso também contempla a replicação multi-região do IAM Identity Center, atendendo clientes que executam o Redshift em uma região diferente da instância primária do Identity Center. Essa flexibilidade é importante para arquiteturas distribuídas geograficamente que precisam manter a governança centralizada de identidade.

    Disponibilidade

    A funcionalidade está disponível em todas as regiões AWS onde tanto o Amazon Redshift quanto o IAM Identity Center estão presentes.

    Saiba mais

    Para quem quiser se aprofundar, a AWS disponibiliza a documentação oficial sobre o roteamento VPC aprimorado do Amazon Redshift e um post detalhado no blog da AWS explicando a integração entre o Redshift e o IAM Identity Center com EVR.

    Fonte

    Amazon Redshift now supports AWS IAM Identity Center authentication with enhanced VPC routing (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-redshift-supports-idc-evr)

  • A AWS convidou um concorrente direto para o Security Hub Extended — e explica o porquê

    Quando o cliente aponta para o concorrente

    Existe um momento delicador para qualquer empresa de tecnologia: quando os próprios clientes recomendam uma solução que compete diretamente com algo que você já oferece. A AWS passou por isso com a Upwind — e, em vez de ignorar o sinal, decidiu trazer a empresa para dentro do AWS Security Hub Extended.

    A lógica é direta: o Security Hub Extended foi criado porque os clientes disseram o que funcionava para eles em segurança corporativa e pediram que a AWS simplificasse a adoção e a integração dessas ferramentas. A Upwind era um dos nomes que aparecia repetidamente nessas conversas. Então a AWS a trouxe para o programa.

    O que é o Security Hub Extended

    O Security Hub Extended é uma camada do AWS Security Hub que reúne soluções de segurança de terceiros dentro da mesma experiência comercial e operacional que os clientes já usam na AWS. A proposta é eliminar a fricção de compra, integração e operação: uma única fatura, suporte unificado e sem necessidade de construir integrações customizadas.

    Dentro do programa, os parceiros precisam ir além de um simples acordo — precisam comprometer engenharia, equipe comercial e modelo de precificação. A Upwind fez exatamente isso: trouxe todo o seu portfólio de soluções ao Extended com precificação pay-as-you-go desde o primeiro dia e alinhou sua equipe de vendas para atuar em negócios conjuntos com a AWS.

    Quem é a Upwind e o que a diferencia

    A Upwind é uma empresa de segurança de nuvem usada por companhias como Siemens, Peloton, Roku, Wix, Nextdoor e Nubank. A Fast Company a elegeu uma das empresas mais inovadoras de 2026.

    O diferencial técnico da Upwind está no conceito de proteção baseada em runtime. A maioria das soluções de segurança em nuvem analisa configurações periodicamente e reporta o que poderia ser um risco — uma abordagem estática de postura. A Upwind funciona de forma diferente: ela implanta um sensor baseado em eBPF diretamente no kernel Linux, que observa em tempo real o que as cargas de trabalho estão fazendo — comportamento de processos, conexões de rede, chamadas de API e interações entre contêineres.

    Isso significa que a Upwind não apenas aponta o que poderia ser explorado teoricamente, mas identifica o que está ativamente em risco agora. Essa distinção reduz drasticamente o volume de alertas e permite que as equipes de segurança foquem no que realmente importa.

    Escolha do cliente, não da AWS

    A AWS deixa claro que o princípio central do programa é a escolha do cliente:

    • Quem prefere gerenciamento de postura de segurança em nuvem e varredura de vulnerabilidades pode optar pelo Security Hub Essentials.
    • Quem prioriza proteção baseada em runtime pode escolher a Upwind.
    • Quem quiser os dois ao mesmo tempo pode combinar as soluções e obter resultados ainda mais robustos.

    A decisão é do cliente — não da AWS. Esse princípio vale para todos os parceiros do Security Hub Extended.

    Melhor juntos: o ecossistema integrado

    Uma das propostas mais interessantes do Security Hub Extended é a integração entre os próprios parceiros do programa. Um cliente que já usa outras soluções do Extended pode combiná-las sem precisar construir integrações manualmente.

    Um exemplo concreto mencionado pela AWS: um cliente que usa Chainguard para segurança da cadeia de suprimentos de software, Upwind para proteção em runtime e Splunk para operações de segurança obtém uma experiência conectada. A Chainguard garante dependências limpas e resistentes a malware na fase de build. A Upwind valida o comportamento das cargas de trabalho em tempo de execução e enriquece os achados com contexto em tempo real. Tudo flui para o Splunk via Security Hub para triagem unificada — uma fatura, sem trabalho de integração customizada.

    O mesmo padrão se aplica com o 7AI, onde automação baseada em IA pode fazer triagem e investigação de eventos de runtime da Upwind junto com sinais de endpoint, identidade e rede, sem trabalho manual de pipeline.

    Os achados fluem pelo Security Hub no formato OCSF (Open Cybersecurity Schema Framework — Estrutura de Esquema Aberto para Cibersegurança), são correlacionados e priorizados em conjunto, e roteados para as ferramentas que a equipe já utiliza.

    Como funciona comercialmente

    A AWS destaca que não se trata de uma parceria apenas no papel. Negócios de múltiplos milhões de dólares já foram fechados por meio do Security Hub Extended com a Upwind.

    Um caso mencionado: uma empresa enterprise substituiu sua solução anterior de CNAPP (Plataforma de Proteção de Aplicações Nativas de Nuvem) pela Upwind por meio de uma Private Offer do Security Hub Extended. Os fatores decisivos foram a visibilidade em runtime que a solução anterior não entregava e um modelo comercial previsível que substituiu a precificação complexa por módulo de múltiplos fornecedores.

    A Upwind está disponível no Security Hub Extended com:

    • Precificação pay-as-you-go
    • Cobrança unificada na fatura AWS
    • Sem compromisso de longo prazo obrigatório
    • Opção de Private Offers para empresas que preferem contratos com preços comprometidos e descontos maiores, com possibilidade de agregar gastos entre parceiros

    O que a Upwind está construindo a seguir

    A AWS também compartilhou o roadmap de expansão da Upwind dentro do programa:

    • Proteção de cargas de trabalho de IA: monitoramento do comportamento de modelos e chamadas de ferramentas de agentes em tempo de execução.
    • Cobertura de VMs Windows Server na AWS, Azure e GCP.
    • Integração mais profunda com o mecanismo de correlação do Security Hub, para que o contexto de runtime enriqueça automaticamente a inteligência de caminhos de ataque.

    O que isso significa na prática

    Para quem já usa o Security Hub para gerenciamento de postura e varredura de vulnerabilidades, adicionar a Upwind significa ganhar visibilidade em runtime sem precisar configurar novas ferramentas ou aprender novos fluxos de trabalho. A solução aparece na visão priorizada de riscos que o time já conhece.

    A Upwind pode ser habilitada diretamente pelo console do AWS Security Hub, com precificação pay-as-you-go e sem compromisso inicial. Para entender como consolidar o stack de segurança com o Security Hub Extended, a recomendação é conversar com o time de conta AWS.

    Fonte

    We invited a direct competitor into Security Hub Extended. Here’s why. (https://aws.amazon.com/blogs/security/we-invited-a-direct-competitor-into-security-hub-extended-heres-why/)

  • Automatize a governança do IAM Identity Center com descoberta contínua e relatórios

    O desafio de governar identidades em escala na AWS

    O AWS IAM Identity Center é o ponto central de autenticação e autorização para recursos AWS dentro de uma organização. Ele se integra ao provedor de identidade externo (IdP) da empresa e ao AWS Organizations, além de suportar um número crescente de serviços AWS com integração nativa.

    À medida que a organização cresce, manter visibilidade sobre quem acessa o quê — e garantir que as políticas de governança sejam aplicadas de forma consistente em todas as contas e regiões — se torna progressivamente mais complexo. O Identity Center centraliza autenticação e autorização, mas rastrear atribuições de acesso e fazer cumprir políticas de segurança em escala é um desafio próprio.

    A AWS publicou uma solução de exemplo que automatiza a descoberta e o reporte dessas atribuições, ajudando equipes de segurança e governança a responder perguntas como:

    • Quais usuários ou grupos têm acesso a quais aplicações AWS?
    • Quem acessou determinada aplicação pela última vez e quando?
    • Quais usuários e grupos estão atribuídos a aplicações do Identity Center em toda a organização e regiões?
    • Como gerar relatórios rapidamente para auditorias de conformidade ou revisões de segurança?

    Planejando a governança de identidades para atribuições de aplicações

    Antes de implementar qualquer automação, a AWS recomenda alinhar quatro áreas fundamentais, envolvendo equipes de segurança, governança, aplicações e negócios:

    • Quem pode provisionar aplicações gerenciadas: As restrições de criação de recursos AWS nas contas da organização devem ser implementadas via políticas de identidade IAM, Políticas de Controle de Serviço (SCP), Políticas de Controle de Recursos (RCP) ou ferramentas de avaliação de políticas como Open Policy Agent (OPA) ou Checkov.
    • Quem gerencia atribuições de usuários e grupos: O administrador da aplicação gerenciada cuida da autorização dentro de uma conta AWS. É recomendado definir claramente papéis e responsabilidades ao longo do fluxo de trabalho.
    • Como o fluxo de autenticação ocorre do IdP aos recursos AWS: Usuários se autenticam no Identity Center, são autorizados a acessar aplicações gerenciadas e, a partir daí, acessam os serviços e recursos AWS associados.
    • Mapeamento de identidades do IdP ao acesso em recursos AWS: É preciso estabelecer a ligação entre usuários e grupos no IdP, as aplicações gerenciadas no Identity Center e os recursos e permissões downstream. A Propagação de Identidade Confiável (TIP) é um recurso adicional do Identity Center que fornece rastreabilidade completa da identidade até o serviço downstream.

    Criando e gerenciando o ciclo de vida de atribuições de aplicações

    Como boa prática de segurança, a AWS recomenda habilitar a administração delegada ao gerenciar o Identity Center em instâncias de organização AWS. Após configurar o IAM Identity Center em uma instância de organização, as contas-membro podem criar recursos AWS associados. Para isso, os principais IAM que provisionam recursos precisam de dois tipos de permissões IAM específicas:

    • Permissões específicas do serviço AWS: Por exemplo, para criar um domínio do Amazon SageMaker AI, são necessárias as permissões habituais de criação do domínio e dos recursos downstream que o SageMaker AI utiliza.
    • Permissões específicas do IAM Identity Center: O principal IAM usado para criar o recurso também precisa de permissões para gerenciar aplicações dentro da instância do Identity Center.

    Um exemplo de política IAM para criação e gerenciamento de aplicações no Identity Center:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "sso:CreateManagedApplicationInstance",
            "sso:GetManagedApplicationInstance",
            "sso:DeleteManagedApplicationInstance",
            "sso:DescribeRegisteredRegions"
          ],
          "Resource": "*"
        },
        {
          "Effect": "Allow",
          "Action": [
            "sso:CreateApplication",
            "sso:DescribeApplication",
            "sso:DeleteApplication",
            "sso:PutApplicationGrant",
            "sso:PutApplicationAuthenticationMethod",
            "sso:PutApplicationAccessScope"
          ],
          "Resource": [
            "arn:aws:sso::<INSERT-ACCOUNT-ID>:application/ssoins-<INSERT-INSTANCE-ID>/apl-*"
          ]
        }
      ]
    }

    Um ponto importante: os Nomes de Recurso Amazon (ARN) de aplicações do Identity Center usam identificadores únicos (GUIDs) gerados no momento da criação, diferente de recursos como buckets do Amazon Simple Storage Service (Amazon S3), cujo nome aparece diretamente no ARN.

    Gerenciando acesso a uma aplicação do Identity Center

    Após criar a aplicação, é necessário gerenciar o acesso a ela. Dois tipos de permissões IAM são necessários:

    1. Permissões para listar usuários e grupos do Identity Center:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "ListIdentityCenterUsers",
          "Effect": "Allow",
          "Action": [
            "identitystore:ListUsers",
            "identitystore:DescribeUser",
            "identitystore:ListGroups",
            "identitystore:DescribeGroup",
            "identitystore:ListGroupMemberships"
          ],
          "Resource": "*"
        }
      ]
    }

    Vale notar que as ações de listagem exigem acesso a AllUsers ou AllGroups, o que significa que uma política IAM restritiva não pode impedir que um principal veja um subconjunto de usuários ou grupos no identity store.

    2. Permissões para criar e gerenciar atribuições de aplicações:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "ManageApplicationAssignments",
          "Effect": "Allow",
          "Action": [
            "sso:CreateApplicationAssignment",
            "sso:DeleteApplicationAssignment",
            "sso:ListApplicationAssignments",
            "sso:PutApplicationAssignmentConfiguration"
          ],
          "Resource": [
            "arn:aws:sso::<INSERT-ACCOUNT-ID>:application/ssoins-<INSERT-INSTANCE-ID>/apl-*"
          ]
        }
      ]
    }

    Como o ARN da aplicação do Identity Center usa um ID único gerado na criação, não é recomendado implementar políticas IAM que restrinjam principais autorizados a gerenciar aplicações específicas do Identity Center por ARN. Em vez disso, a recomendação é limitar o gerenciamento de aplicações e atribuições a um número reduzido de principais IAM autorizados, complementado por capacidades de detecção e resposta.

    Planejando convenções de nomenclatura e estratégia de automação

    O IAM Identity Center disponibiliza diversas APIs para capturar informações sobre instâncias, aplicações e atribuições na organização. Antes de implementar automação ou guardrails, é importante definir uma abordagem metódica. A AWS sugere:

    • Convenção para grupos no IdP: Ex.: AWS_<ACCT#>_<AWS_Service>_<LOB>_<ENV>_<AppName>AWS_123412341234_SageMaker_Data_PROD_GTLabel
    • Convenção para recursos AWS integrados ao Identity Center: Ex.: <AWS_Service>_<LOB>_<AppName>SageMaker_Data_GTLabel
    • Convenção para nomes de aplicações no Identity Center: Ex.: <AWS_Service>_<LOB>_<ENV>_<AppName>SageMaker_Data_PROD_GTLabel

    Também é importante decidir quais partes do fluxo serão centralizadas — criação de aplicações, atribuições ou remediação de problemas. Centralizar demais pode criar gargalos; descentralizar demais aumenta o risco de atribuições fora dos padrões de segurança corporativos. O equilíbrio certo depende do contexto de cada organização.

    Para localizar o ARN de uma aplicação do Identity Center a partir de um recurso AWS específico (como um domínio SageMaker AI), uma busca reversa é necessária, pois os serviços AWS criam aplicações Identity Center com ARNs baseados em GUID que não são facilmente descobertos. Veja o exemplo em shell:

    #!/bin/bash
    DOMAIN_ID="d-xxxxxxxxxxxx"
    REGION="xx-xxxx-x"
    
    # Step 1: Get SageMaker domain details
    echo "=== SageMaker Domain Details ==="
    DOMAIN_INFO=$(aws sagemaker describe-domain \
      --region $REGION \
      --domain-id $DOMAIN_ID)
    
    # Step 2: Extract Identity Center application ARN
    SSO_APP_ARN=$(echo $DOMAIN_INFO | jq -r '.SingleSignOnApplicationArn')
    echo "Identity Center App ARN: $SSO_APP_ARN"

    A solução de automação: descoberta e relatórios

    A solução de exemplo sample-iam-idc-application-discovery-reporting, disponível no GitHub, é composta por duas stacks separadas do AWS Cloud Development Kit (AWS CDK):

    • Stack de relatórios de governança (/identity-center-reporting): fornece descoberta automatizada e geração de relatórios em CSV.
    • Stack de remediação (/identity-center-remediation): fornece aplicação de políticas em tempo real e notificações.

    A recomendação é implantar primeiro a stack de relatórios para estabelecer visibilidade de baseline, e depois a stack de remediação para aplicação de políticas.

    Recursos implantados pela stack de relatórios

    • Amazon EventBridge: regra que invoca o fluxo de descoberta diariamente às 2h UTC (configurável).
    • AWS Step Functions: orquestra o fluxo de descoberta em múltiplos estágios — instâncias, aplicações e atribuições.
    • AWS Lambda: realiza a descoberta de instâncias do Identity Center, enumera aplicações e mapeia usuários e grupos a aplicações, resolvendo nomes amigáveis do Identity Store.
    • Amazon DynamoDB: armazena instâncias, aplicações e atribuições descobertas, criptografadas com chave gerenciada pelo cliente via AWS Key Management Service (AWS KMS).
    • Amazon API Gateway: fornece uma API REST autenticada via IAM para geração e exportação de relatórios como arquivos CSV.
    • Amazon S3: armazena as exportações CSV criptografadas, com políticas de ciclo de vida e URLs pré-assinadas com tempo limitado para download.

    Pré-requisitos e implantação da stack de relatórios

    Para implantar a solução, são necessários:

    • Uma organização AWS com instância do IAM Identity Center e administração delegada configurada.
    • IAM Identity Center configurado com ao menos uma instância.
    • Interface de Linha de Comando AWS (AWS CLI) configurada com credenciais adequadas.
    • Python 3.12 e Node.js 18 ou superior instalados para o deploy com CDK.

    Comandos para implantação:

    git clone https://github.com/aws-samples/sample-iam-idc-application-discovery-reporting
    cd identity-center-reporting
    
    python3.12 -m venv .venv && source .venv/bin/activate
    pip install -r requirements.txt
    
    cdk bootstrap aws://<INSERT-ACCOUNT-ID>/<INSERT-REGION>
    
    export IDC_EXTERNAL_ID="$(uuidgen)"
    cdk deploy --parameters AllowedIpRange=10.0.0.0/8 --parameters CrossAccountExternalId="$IDC_EXTERNAL_ID"

    O parâmetro AllowedIPRange é opcional, mas recomendado como boa prática de segurança — ele adiciona uma restrição de rede ao download da URL pré-assinada do Amazon S3. Para descoberta de instâncias Identity Center em nível de conta AWS, é necessária uma função IAM entre contas:

    python scripts/deploy-cross-account-roles.py --external-id "$IDC_EXTERNAL_ID"

    Após o deploy, a automação roda em agendamento diário. A primeira execução de descoberta ocorre imediatamente após a implantação. É possível monitorar o histórico de execuções pelo console do AWS Step Functions, revisar logs detalhados no Amazon CloudWatch Logs e consultar instâncias, aplicações e atribuições descobertas diretamente no console do DynamoDB.

    Gerando relatórios de atribuições

    Para gerar relatórios sob demanda como arquivos CSV via API REST:

    export AWS_REGION="<REPLACE-REGION>"
    export API_ID="<REPLACE-API-ID>"
    eval "$(aws configure export-credentials --profile "<YOUR-PROFILE>" --format env)"
    
    # Exportar aplicações
    curl -sS --fail-with-body \
      --aws-sigv4 "aws:amz:${AWS_REGION}:execute-api" \
      --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
      --header "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
      "https://${API_ID}.execute-api.${AWS_REGION}.amazonaws.com/prod/export/applications" \
      -o applications.json
    
    # Exportar atribuições com nomes de usuários e grupos
    curl -sS --fail-with-body \
      --aws-sigv4 "aws:amz:${AWS_REGION}:execute-api" \
      --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
      --header "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
      "https://${API_ID}.execute-api.${AWS_REGION}.amazonaws.com/prod/export/assignments" \
      -o assignments.json

    A API retorna um JSON com uma URL pré-assinada do Amazon S3 válida por 15 minutos. Os arquivos CSV gerados incluem dados enriquecidos com nomes amigáveis, como ARN da instância, ID da conta, nome da aplicação, tipo de principal, nome do principal e status. Com esses dados, é possível identificar anomalias ou atribuições não conformes — por exemplo, uma aplicação de produção que deveria ter apenas atribuições de grupo, mas possui um usuário individual atribuído.

    Stack de remediação: monitoramento e resposta em tempo real

    A stack de remediação complementa os relatórios com aplicação de políticas em tempo real. Os recursos implantados incluem:

    • Amazon EventBridge: captura eventos de atribuição e perfil do IAM Identity Center via CloudTrail (sso.amazonaws.com) para ações como CreateApplicationAssignment, DeleteApplicationAssignment, PutApplicationAssignmentConfiguration, AssociateProfile, DisassociateProfile, CreateProfile, UpdateProfile e DeleteProfile.
    • AWS Lambda: resolve nomes de aplicações e grupos, valida a atribuição contra a convenção de nomenclatura e notifica ou remedia conforme o modo configurado.
    • Amazon Simple Notification Service (Amazon SNS): publica alertas de atribuições não conformes para assinantes (como e-mail).
    • Amazon Simple Queue Service (Amazon SQS): captura eventos que a função Lambda não conseguiu processar para inspeção posterior.
    • AWS KMS: chave gerenciada pelo cliente para criptografar variáveis de ambiente do Lambda, logs do CloudWatch, tópico SNS e fila de mensagens mortas.
    • Amazon CloudWatch: grupo de logs armazena os logs estruturados e criptografados da função como trilha de auditoria.

    As políticas de nomenclatura suportam correspondência por expressões regulares (regex) para requisitos organizacionais específicos.

    Implantação da stack de remediação

    git clone https://github.com/aws-samples/sample-iam-idc-application-discovery-reporting
    cd identity-center-remediation
    cdk deploy --context enableAutoDeletion=false --parameters IdentityCenterInstanceArn=arn:aws:sso:::instance/ssoins-<INSERT-ORG-INSTANCE-ID> --parameters ManagementAccountId=<INSERT-MANAGEMENT-ACCOUNT>

    Por padrão, a solução verifica se o nome do grupo aparece como palavra completa no nome da aplicação (sem distinção entre maiúsculas e minúsculas, separando por -, _ e espaços). Assim, ReadOnly corresponde a sagemaker_readonly, mas read não corresponde. Para casos de uso diferentes, o parâmetro GroupNameRegex pode ser passado durante o deploy.

    Testando atribuições conformes e não conformes

    Para obter as informações necessárias do ambiente:

    INSTANCE_ARN=$(aws sso-admin list-instances --region <REPLACE-REGION> --query "Instances[0].InstanceArn" --output text)
    echo "$INSTANCE_ARN"
    
    IDENTITY_STORE_ID=$(aws sso-admin list-instances --region <REPLACE-REGION> --query "Instances[0].IdentityStoreId" --output text)
    echo "$IDENTITY_STORE_ID"
    
    aws identitystore list-groups --identity-store-id $IDENTITY_STORE_ID --query "Groups[].{Name:DisplayName,Id:GroupId}" --output table
    
    aws sso-admin list-applications --instance-arn $INSTANCE_ARN --query "Applications[?Status=='ENABLED'].{Name:Name,ARN:ApplicationArn}" --output table

    Definindo variáveis para os grupos e aplicação de teste:

    export GRP_READONLY=abc12345-1234-1234-1234-abcdef123456
    export GRP_DEVELOPER=abc12345-1234-1234-1234-abcdef123457
    export APP_READONLY="arn:aws:sso::<INSERT-ACCOUNT-ID>:application/<INSERT-INSTANCE-ARN>/<INSERT-APPLICATION-ARN>"

    Atribuição conforme — adicionando o grupo ReadOnly à aplicação sagemaker_readonly:

    aws sso-admin create-application-assignment --application-arn $APP_READONLY --principal-id $GRP_READONLY --principal-type GROUP

    O log da função Lambda mostrará:

    ✓ COMPLIANT - Group name found in application name applicationName="sagemaker_readonly" groupName="ReadOnly"
    Remediation action determined: NONE

    Atribuição não conforme — tentando adicionar o grupo Developer à aplicação sagemaker_readonly:

    aws sso-admin create-application-assignment --application-arn $APP_READONLY --principal-id $GRP_DEVELOPER --principal-type GROUP

    O log mostrará:

    ✗ NON-COMPLIANT - Group name not found in application name applicationName="sagemaker_readonly" groupName="Developer"
    Remediation action determined: NOTIFICATION_ONLY
    SNS notification sent successfully

    Com enableAutoDeletion=false, a solução apenas notifica. Para que a atribuição seja removida automaticamente, o valor deve ser alterado para enableAutoDeletion=true. A mensagem SNS enviada inclui detalhes como tipo de evento, nome da aplicação, nome do grupo, ação tomada, ARN da aplicação e quem iniciou a ação.

    Governança IAM em escala: um framework de alto nível

    A AWS sugere os seguintes passos de alto nível para estruturar a governança do Identity Center com essas soluções:

    • Implantar a automação com um principal IAM que tenha acesso na conta de administrador delegado.
    • Estabelecer uma baseline executando a primeira descoberta e revisando os relatórios gerados.
    • Configurar políticas de nomenclatura alinhadas às convenções de segurança da organização.
    • Implantar o monitoramento orientado a eventos para habilitar aplicação de políticas em tempo real.
    • Começar no modo de notificação para validar as políticas antes de habilitar a auto-remediação.
    • Integrar com ferramentas de governança conectando os endpoints da API a dashboards de conformidade ou ferramentas de ITSM.
    • Migrar para auto-remediação após validar que as políticas estão funcionando conforme esperado.

    Os relatórios agendados fornecem visibilidade de baseline sobre as aplicações gerenciadas pelo IAM Identity Center. O monitoramento orientado a eventos entrega notificações ou aplicação de políticas em tempo quase real. Juntas, essas soluções ajudam a alinhar e escalar o Identity Center com os padrões de governança e segurança da organização — por meio de análise histórica e resposta imediata.

    Limpeza do ambiente

    Para remover as stacks implantadas, execute os seguintes comandos nas respectivas contas AWS:

    # Remover a stack de remediação
    cd sample-iam-idc-application-discovery-reporting/identity-center-remediation
    cdk destroy
    
    # Remover a stack de relatórios
    cd sample-iam-idc-application-discovery-reporting/identity-center-reporting
    cdk destroy

    Fonte

    Automate IAM Identity Center governance with continuous discovery and reporting (https://aws.amazon.com/blogs/security/automate-iam-identity-center-governance-with-continuous-discovery-and-reporting/)