盗まれた署名鍵で6万通流出、NISTがトークン防御を最終化

米国立標準技術研究所（NIST）と米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は2026年9月15日、SSO、連携認証、APIなどで使うトークンを偽造、窃取、悪用から守るNIST IR 8587を最終化した。NISTの最終版発表 が示した背景事例では、盗まれた単一の商用署名鍵から偽造トークンが作られ、検証の不備も重なって政府機関のメール6万通超が盗まれた。

最終版の中心は、署名鍵を保管するだけでなく、トークンを受け取る側が発行者、宛先、有効期間、権限、署名に使われた鍵を確認し、侵害時には失効情報を接続先まで伝え、利用状況を継続監視することだ。2025年12月の草案から、鍵の保護方法は成果重視へ改められ、ワークロードID、失効とリスク信号、AIエージェント、耐量子暗号への移行に関する説明も加わった。

草案から変わった四つの重点

NIST IR 8587の最終報告書 は、連邦政府機関とクラウドサービス提供者を主な対象とし、非対称暗号で署名されたトークンやアサーションを扱う。SSO、連携認証、API、ワークロードアクセスが範囲に入り、APIキーや対称暗号だけに基づく方式は原則として対象外だ。

第一の変更は、署名鍵の保護を特定の保管方式に固定せず、安全な保存と安全な利用を分けて評価する点である。鍵の生成、配布、隔離、利用、ローテーション、失効、破棄を通じて、盗難や誤用を防げるかが問われる。鍵の有効期間も、配備モデルだけで決める考え方から、システムの区分と取引の機微性を重視する形へ変わった。

第二は、静的な秘密情報に頼らず、短命なトークンを使うワークロードIDへの対応である。第三は、失効状態やリスク変化を連携先へ伝えるための規格参照を増やしたこと。第四は、AIエージェントと耐量子暗号を新たな設計課題として明記したことで、どちらも包括的な実装標準を示したわけではない。

提供者、利用組織、共同責任を切り分ける

最終版は、クラウドのトークン防御を共有責任として整理している。SaaSの例では、基盤、主要IAMサービス、トークンの発行と署名、秘密情報保管庫やHSM、基盤レベルのログと監視は主に提供者側の領域となる。利用組織は、IAMポリシー、アプリケーションと利用者のアクセス制御、アプリケーション秘密情報、利用者認証、セッション、アプリケーションログを管理する。

インシデント対応、継続監視、トークン失効は共同責任である。提供者が失効用のインターフェースを用意しても、利用組織のアプリケーションが信号を受け取らず、既存セッションを終了しなければ遮断は完了しない。反対に、利用組織だけでは、発行基盤で起きた鍵の侵害や全テナントに及ぶ異常を把握できない場合がある。

責任境界はサービスモデル、契約、提供される技術機能によって変わる。このため、契約と運用手順では、侵害の通知経路、対象となるトークンとセッション、失効情報の伝播方法、提供されるログ、障害時の代替策を同じ境界図に落とし込む必要がある。

SSOとAPIで外せない五つの防御

実装確認は製品単位ではなく、人のSSO、組織間連携、API、サービス間通信など、トークンが発行されてから利用されるまでの経路ごとに行う。最終版の要点は次の五項目に集約できる。

• 署名鍵：鍵の生成から破棄までを追跡し、用途、環境、セキュリティー領域を越えて同じ鍵が信頼されないよう制限する。鍵へのアクセスと署名処理は監査可能にする。
• 検証：署名が成立することだけでなく、正しい鍵で署名されたか、発行者、宛先、発行時刻、有効期間、識別子、スコープが対象リソースの方針に合うかを確認する。宛先が欠落または不一致なら拒否し、警告へつなげる。
• 寿命と更新：アクセス・トークンと更新トークンの有効期間をリスクに合わせ、更新時のローテーションや再利用検知を組み合わせる。ワークロードでは静的な認証情報より短命なトークンを優先する。
• 失効：アカウントや鍵の侵害後、新規発行を止めるだけでなく、失効状態を接続先へ伝え、関連する有効セッションを終了できるようにする。
• 監視：発行者、宛先、スコープ、利用主体などを記録し、地域、端末、利用速度の異常や複数サービスでの操作を関連付ける。ただし、トークン本体をログ、CI/CDパイプライン、ビルド成果物へ残してはならない。

失効の成否は、機能の名称ではなく伝播の結果で判断する。OpenID Foundationの解説 によると、IR 8587はShared Signals Framework（SSF）とContinuous Access Evaluation Profile（CAEP）を具体的に推奨している。SSFは関係組織間でセキュリティーイベントを交換し、CAEPはセッションやリスク状態の変化を伝えて、サインイン後もアクセス判断を更新できるようにする。

AIと耐量子対応は範囲と限界を明記

AIエージェントが署名済みトークンを使ってシステム、データ、ツール、APIへ接続する場合も、IR 8587の基本原則が適用される。ただし文書は、委任された権限の連鎖や自律的な処理を含むAI固有のIAMリスクを包括的に扱っていない。現段階では、エージェントを例外扱いせず、発行者、宛先、権限、寿命、停止手段を管理するための土台と位置付けるのが正確だ。

耐量子暗号についても、既存トークンを直ちに一斉交換する指示ではない。新しい方式では公開鍵、署名、暗号文が現在の方式より大きくなる場合があり、JWT、Cookie、HTTPヘッダー、証明書、メタデータ、HSMに影響する。発行側だけでなく、検証するリソースサーバー、ゲートウェイ、クライアントまで移行対象になるため、利用中の公開鍵暗号と対応できない旧式の連携認証基盤を把握しておく必要がある。

IR 8587への適合は、別の政策や契約で義務付けられない限り任意であり、日本企業に直接適用される新規制ではない。一方、NISTは政府以外の組織にも参考になるとしている。クラウド提供者と利用組織に残された課題は、鍵保護、検証、失効、監視の各機能を備えているかだけでなく、責任境界を越えたときにも防御が途切れないことを実装と契約の両方で確かめることにある。