CISA e NIST publicaram orientações voltadas à proteção de sistemas federais de identidade em nuvem contra roubo, falsificação e uso indevido de tokens de autenticação. O comunicado está disponível na página de notícias da CISA. No momento da redação deste artigo, o feed de anúncios exibia apenas o título, sem resumo, de modo que este relatório se limita ao que o título enuncia e ao contexto publicamente documentado sobre o problema que ele aborda.

Três pontos ficam claros apenas pelo título. A publicação é conjunta entre CISA e NIST. Seu público são agências federais que operam sistemas de identidade em nuvem. E seu tema são os tokens: os artefatos assinados que permitem a um usuário, dispositivo ou carga de trabalho comprovar que já realizou a autenticação. Na prática, isso abrange tokens de acesso e de atualização OAuth, ID tokens OIDC, asserções SAML, primary refresh tokens e cookies de sessão.

Por que tokens merecem orientações próprias não é nenhum mistério para quem leu um relatório de incidente nos últimos anos. A maioria dos tokens é um instrumento ao portador, o que significa, de forma direta, que funcionam como dinheiro em espécie: quem os possui pode utilizá-los. Um token roubado contorna a senha, o prompt de MFA e frequentemente a verificação de dispositivo, pois as três etapas já ocorreram quando o token foi emitido. Kits de phishing que fazem proxy do login e capturam o cookie de sessão, malwares que varrem caches de tokens e abuso de consentimento OAuth exploram a mesma fragilidade.

A falsificação é a variante mais grave. A revisão do Cyber Safety Review Board sobre a intrusão Storm-0558 documentou como uma chave de assinatura da Microsoft foi roubada e usada para forjar tokens que concediam acesso a caixas de correio do Exchange Online, incluindo as de agências federais. Nenhum usuário foi vítima de phishing naquele caso. O atacante simplesmente imprimiu o próprio dinheiro. Esse episódio é a razão mais pública pela qual as orientações federais de identidade passaram a tratar chaves de assinatura e validação de tokens como controles de primeira ordem, e não como detalhes internos de fornecedores.

Ambas as agências possuem trabalhos anteriores relevantes. O projeto Secure Cloud Business Applications (SCuBA) da CISA publica linhas de base de configuração segura para Microsoft 365 e Google Workspace. A série NIST SP 800-63 abrange autenticação, gerenciamento de sessão e federação, incluindo como relying parties devem validar asserções. Se as novas diretrizes estendem esses documentos, substituem partes deles ou são independentes não está declarado no título do comunicado, e esta publicação não fará suposições a respeito.

O que ainda não se sabe a partir do material-fonte:

• Se as orientações são vinculantes para as agências ou consultivas, e se há algum prazo de implementação
• Quais provedores de identidade em nuvem e protocolos de federação são cobertos, e se alguma configuração específica de fornecedor é prescrita
• Quais requisitos de detecção ou registro são introduzidos para emissão e replay de tokens
• Se o escopo abrange apenas usuários humanos ou também contas de serviço e identidades de carga de trabalho

Profissionais da área devem ler o documento em si assim que o texto completo estiver disponível, em vez de depender de cobertura secundária, incluindo este artigo. O lado positivo é que a defesa de tokens é um problema resolvido em princípio. Tempos de vida curtos para tokens, avaliação contínua de acesso, tokens vinculados a dispositivos ou com restrição de remetente (DPoP para OAuth, proteção de token no Entra Conditional Access onde suportado), rotação rigorosa de chaves de assinatura e validação de audience e issuer em cada relying party já estão disponíveis hoje. A maioria das organizações já possui os controles. Simplesmente não os ativou todos, o que é menos uma lacuna tecnológica do que uma tarde de terça-feira que alguém continua reagendando.

No aspecto mais crítico, as agências federais são o público nominalmente indicado, mas os mesmos tokens, os mesmos protocolos e os mesmos atacantes aparecem em todos os ambientes comerciais. Tratar isso como tarefa de conformidade alheia seria uma escolha.

Equipes de identidade e segurança devem verificar três pontos agora. Revise os tempos de vida de tokens e sessões no seu provedor de identidade e confirme que aplicações de alto valor exigem reautenticação ou avaliação contínua, em vez de confiar em um cookie com um dia de existência. Faça um inventário de quem controla suas chaves de assinatura SAML e OIDC, como estão armazenadas, quando foram rotacionadas pela última vez e se cada relying party valida issuer, audience e assinatura em vez de apenas decodificar o payload. Por fim, confirme que seus logs de sign-in e emissão de tokens estão retidos e consultáveis, e construa ao menos uma detecção para um token utilizado a partir de um IP, dispositivo ou localização que não realizou a autenticação original.