Tokens de identidade na nuvem viram alvo estratégico: CISA e NIST elevam o padrão de proteção

Tokens de identidade e de acesso estão no centro de SSO, federação, APIs, workloads e aplicações em nuvem. Quando roubados ou falsificados, podem transformar um invasor em uma identidade aparentemente legítima. A publicação final do NIST IR 8587, desenvolvida em coordenação com a CISA, consolida uma mudança importante de segurança: proteger credenciais já não basta; é necessário proteger todo o ciclo de vida dos tokens, das chaves de assinatura à revogação.

O token virou uma das credenciais mais valiosas da arquitetura moderna

Durante anos, boa parte das estratégias de segurança de identidade concentrou atenção em senhas, autenticação multifator e proteção de contas privilegiadas. Esses controles continuam essenciais, mas a expansão de ambientes cloud, federação e APIs aumentou o valor de outro ativo: o token que representa uma identidade ou uma autorização já concedida.

Em fluxos modernos de autenticação, o usuário pode provar sua identidade uma única vez e, a partir disso, receber tokens ou assertions utilizados por aplicações e serviços para confiar naquela autenticação. Esse desenho melhora experiência e interoperabilidade, mas cria um ponto crítico: se um atacante rouba um token válido, ele pode reutilizar uma autorização já emitida sem precisar conhecer a senha original e, em determinados cenários, sem repetir o MFA.

É esse problema que o NIST IR 8587 — Protecting Tokens and Assertions from Forgery, Theft, and Misuse procura enfrentar. Publicado em versão final em 15 de setembro de 2026, o documento foi desenvolvido pelo NIST em coordenação com a CISA e apresenta recomendações para órgãos públicos e provedores de serviços cloud, embora o próprio NIST destaque que as orientações podem beneficiar qualquer organização que dependa de tokens de identidade, tokens de acesso ou assertions.

Por que tokens roubados conseguem contornar controles tradicionais

Um token não é apenas uma sequência aleatória. Em muitos ambientes, ele carrega ou representa informações sobre quem é a entidade autenticada, para qual recurso o acesso foi concedido, quais permissões foram autorizadas e até quando aquela autorização permanece válida.

Em OAuth 2.0, por exemplo, um access token pode permitir que uma aplicação consuma uma API em nome de um usuário ou workload. Em OpenID Connect, um ID token transporta informações sobre a autenticação. Em federação SAML, uma assertion pode informar a um serviço que a autenticação foi realizada por um provedor de identidade confiável.

O problema surge quando o sistema receptor confia no token correto pelos motivos errados. Assinatura válida, por si só, não é suficiente. O serviço precisa verificar emissor, audiência, validade, escopo, integridade e contexto de uso. Um token destinado a uma aplicação não deveria ser aceito por outra. Um token expirado não deveria permanecer utilizável. E uma chave comprometida não deveria continuar produzindo artefatos aceitos por todo o ecossistema.

O NIST IR 8587 coloca o ciclo de vida completo sob controle

A nova orientação organiza a proteção em torno de um princípio simples: tokens e assertions precisam ser protegidos desde a criação até a expiração ou revogação. Isso inclui a infraestrutura responsável por emitir os tokens, as chaves criptográficas usadas para assiná-los, os consumidores que validam esses artefatos e os mecanismos de monitoramento capazes de detectar uso anômalo.

Entre as recomendações centrais estão a proteção das chaves privadas de assinatura de forma proporcional à criticidade do sistema, a automação da rotação dessas chaves, o uso de períodos de validade reduzidos, a validação explícita da audiência e a existência de mecanismos confiáveis de revogação e distribuição de sinais de risco.

O documento também reforça a necessidade de configurações seguras por padrão. Para organizações usuárias de serviços cloud, isso significa evitar arquiteturas em que a segurança do token dependa de ajustes manuais pouco compreendidos ou de combinações frágeis de parâmetros entre diferentes provedores.

Tokens de longa duração ampliam o tempo disponível para o invasor

Quanto maior a validade de um token, maior a janela de reutilização depois de um vazamento. Essa relação é especialmente importante em acessos privilegiados, workloads e integrações entre sistemas.

O NIST recomenda que tokens de acesso e identidade não permaneçam válidos por períodos excessivos e reforça o uso de credenciais de curta duração para workloads. O objetivo é reduzir o valor de um artefato capturado: mesmo que um atacante consiga obtê-lo, o tempo para utilizá-lo deve ser limitado.

Esse princípio também reduz a dependência de segredos estáticos. Em vez de armazenar chaves de API permanentes, aplicações podem receber credenciais temporárias emitidas de acordo com a identidade e o contexto do workload. O resultado é uma arquitetura em que o comprometimento de uma credencial isolada tende a ter menor duração e menor alcance.

Chaves de assinatura comprometidas transformam confiança em vetor de ataque

Há uma diferença importante entre roubar um token e roubar a chave usada para assinar tokens. No primeiro caso, o invasor pode reutilizar uma autorização específica. No segundo, ele pode ganhar a capacidade de criar novos tokens ou assertions que parecem legítimos para sistemas consumidores.

Por isso, o NIST IR 8587 dá atenção especial ao armazenamento e ao uso de chaves privadas de assinatura. Sistemas mais críticos devem utilizar mecanismos de proteção compatíveis com o impacto de uma possível violação, incluindo isolamento criptográfico, controles de acesso rigorosos, rotação automatizada e monitoramento de operações de assinatura.

A recomendação é relevante para arquiteturas de SSO e federação porque a confiança se propaga. Um provedor de identidade comprometido pode afetar dezenas ou centenas de aplicações que aceitam seus tokens. A segurança da chave deixa de ser um assunto local do IdP e passa a ser um risco sistêmico.

Audiência, escopo e contexto precisam ser validados em cada uso

Uma das falhas mais perigosas ocorre quando um token legítimo é aceito fora do contexto para o qual foi emitido. Por isso, a validação da audience é tratada como requisito importante: o sistema receptor precisa confirmar que aquele token foi realmente destinado a ele.

O mesmo vale para escopos e permissões. Um token emitido para leitura de dados não deveria autorizar alteração. Um token de usuário não deveria automaticamente permitir ações administrativas. Uma identidade de workload não deveria herdar privilégios incompatíveis com sua função apenas porque pertence ao mesmo ambiente cloud.

Na prática, esse desenho aproxima a segurança de tokens dos princípios de Zero Trust: cada solicitação precisa ser avaliada explicitamente, sem assumir que um artefato previamente emitido pode ser usado em qualquer contexto.

Revogação e monitoramento precisam acompanhar a velocidade da nuvem

Expiração curta reduz risco, mas não substitui revogação. Se um token é suspeito de comprometimento, a organização precisa ter uma forma de impedir seu uso antes do fim natural de sua validade. O NIST IR 8587 destaca mecanismos de revogação e compartilhamento de sinais de risco como elementos importantes da arquitetura.

Esse ponto é particularmente relevante em ecossistemas federados. Um provedor de identidade pode detectar uma conta comprometida, mas essa informação precisa chegar rapidamente às aplicações que confiaram nos tokens emitidos anteriormente. Caso contrário, a identidade pode ser bloqueada em um componente e continuar ativa em outros.

Logs também têm papel central. Emissão de tokens, falhas de validação, mudanças de chaves, revogações e usos anômalos precisam ser observáveis. Ao mesmo tempo, o próprio token não deve ser gravado integralmente em logs, porque isso transforma sistemas de observabilidade em novas fontes de vazamento.

O risco já aparece em incidentes e pesquisas acompanhados pelo Blog

O problema descrito pelo NIST não é abstrato. Em setembro, o Minuto da Segurança acompanhou a campanha GhostCode, que abusou do OAuth Device Code Flow para obter tokens válidos do Microsoft 365 depois que a própria vítima concluiu o MFA em uma página legítima. O caso demonstrou que um token obtido por engenharia social pode oferecer ao atacante acesso pós-autenticação sem repetir o processo original.

Outro exemplo aparece na análise da CVE-2026-89049 no AWS SSM Agent, em que o abuso de SSRF poderia alcançar o serviço de metadados e expor credenciais IAM temporárias. Mesmo sendo temporárias, essas credenciais podem produzir impacto significativo quando associadas a permissões excessivas.

Na matéria Ataque de identidade no Kubernetes expõe limite de confiança do SPIFFE/SPIRE, o foco foi a possibilidade de um invasor com controle de um nó manipular evidências de workload attestation e obter identidades válidas de outros workloads. O elo comum entre os casos é claro: quando o atacante consegue assumir ou reproduzir uma identidade confiável, controles baseados apenas na origem da autenticação deixam de ser suficientes.

O tema também complementa o artigo Gestão de Identidade no Mundo Moderno, que discute identidade de pessoas, APIs, serviços, cloud e agentes de IA. O NIST IR 8587 aprofunda justamente uma das camadas técnicas dessa arquitetura: como proteger os artefatos criptográficos que transportam confiança entre essas identidades.

Agentes de IA aumentam a importância de tokens limitados e rastreáveis

A edição final do NIST IR 8587 também introduz considerações de alto nível sobre agentes de inteligência artificial. Isso é relevante porque agentes com acesso a ferramentas, APIs, documentos e sistemas corporativos precisam receber alguma forma de autorização para agir.

Se um agente utiliza o mesmo token amplo e duradouro do usuário que o acionou, qualquer erro, abuso de ferramenta ou comprometimento do agente pode herdar todo o alcance daquela identidade. A arquitetura mais segura separa a identidade do agente, limita permissões à tarefa necessária, utiliza tokens de curta duração e mantém rastreabilidade entre o usuário, o agente e a ação executada.

Essa discussão conecta identidade, cloud e governança de IA. O desafio não é apenas provar que o agente é legítimo, mas definir com precisão o que ele pode fazer, por quanto tempo e em nome de quem.

Medidas prioritárias para reduzir o risco

A adoção das recomendações do NIST pode começar por um inventário dos fluxos de autenticação e autorização. A organização precisa saber quais aplicações utilizam OAuth, OpenID Connect ou SAML, quais serviços emitem tokens, quais workloads dependem de credenciais temporárias e onde existem segredos ou tokens de longa duração.

Depois desse mapeamento, a prioridade deve ser reduzir duração e privilégio. Tokens precisam ter validade compatível com o risco, escopos mínimos e audiência explícita. Workloads devem preferir federação e identidades nativas da plataforma em lugar de chaves estáticas. Chaves de assinatura precisam ser isoladas, rotacionadas e monitoradas.

Também é necessário testar os consumidores de tokens. APIs e aplicações devem rejeitar tokens com emissor incorreto, audiência incompatível, assinatura inválida, escopos insuficientes ou validade expirada. Em ambientes de maior criticidade, mecanismos de proof-of-possession podem reduzir a utilidade de tokens roubados ao vincular seu uso a uma chave que o atacante também precisaria possuir.

Por fim, a resposta a incidentes de identidade precisa incluir tokens e chaves. Revogar sessões, invalidar tokens, rotacionar chaves e distribuir sinais de comprometimento entre sistemas federados deve fazer parte dos playbooks, da mesma forma que a troca de senhas já faz parte da resposta tradicional.

Conclusão

O NIST IR 8587 mostra que a segurança de identidade entrou em uma fase mais granular. Não basta autenticar corretamente um usuário ou workload: é necessário proteger os artefatos que carregam essa confiança entre sistemas.

Tokens curtos, escopos mínimos, validação de audiência, chaves protegidas, rotação automatizada, revogação eficiente e monitoramento contínuo reduzem a probabilidade de que um artefato roubado seja transformado em acesso legítimo por um atacante.

Para empresas que aceleram a adoção de cloud, APIs, SSO, automação e agentes de IA, a pergunta prática passa a ser direta: se um token ou uma chave de assinatura for comprometido hoje, a organização consegue limitar o alcance, detectar o abuso e revogar a confiança antes que o invasor a reutilize? A resposta a essa pergunta revela o nível real de maturidade da arquitetura de identidade.

Referências

Infosecurity Magazine — CISA and NIST Issue Cloud Identity Token Security Guidance

NIST — IR 8587: Protecting Tokens and Assertions from Forgery, Theft, and Misuse

NIST CSRC — Protecting Tokens and Assertions | NIST IR 8587