数千人規模でEntra ID（Microsoftのクラウド型ID基盤）やOkta（米Okta社のID基盤）に数十のSaaSをSSO（一度のログインで複数サービスを使える仕組み）でつなぐ企業では、トークンの寿命や失効をどこまで自社で決められるかが曖昧になりがちだ。本稿は、そうした企業のID基盤・セキュリティ統制担当で、年次監査に説明責任を負う人に向けて書く。
2026年9月15日、NIST（米国立標準技術研究所）はCISA（米サイバーセキュリティ・インフラセキュリティ庁）と共同で、NIST IR 8587の最終版を公開した[1]。対象はトークンとアサーション（認証結果を伝える署名付きデータ）の偽造・窃取・悪用の防止で、2025年12月22日のドラフトの確定版だ[1][3]。層でいえば、IdPとそれを信頼するSaaSの間の話になる。
背景には、クラウド事業者の署名鍵が露出し、偽造トークンで政府機関のメールが読まれた事件がある[2]。IRは責任分担と数値目安を示した[2]。結論を先に書くと、トークンの寿命は自社設定で詰められるが、署名鍵の管理は契約と事業者への確認でしか担保できない。
予備知識
- IdP：Identity Provider。利用者を認証し、SaaSへ渡すトークンを発行するサービス
- アクセストークン／IDトークン：認証済みであることや権限を示す署名付きデータ。受け取った側が署名を検証して信頼する
- リフレッシュトークン：期限切れのトークンを再ログインなしで取り直すための長めの鍵
- 署名鍵：IdPがトークンに署名する秘密鍵。漏れると本物と区別できないトークンを作られる
アクセストークンやリフレッシュトークンの仕組みと攻撃パターンを基礎から整理でき、IRの推奨を自社のSaaS連携に当てはめる際の土台になる
NIST IR 8587とは何か：署名鍵とトークンを守る実装ガイド
NIST IR 8587は、SP 800-53（米連邦政府のセキュリティ管理策カタログ）の管理策IA-13を実装するための推奨をまとめた文書だ[2]。IA-13は2023年11月のRelease 5.1.1で、トークン関連の重大事故を受けて追加された[2]。
IRは事故の例を2つ挙げる。1つは2020年12月発覚のサプライチェーン侵害で、AD FS（オンプレの認証連携サーバー）の署名証明書が奪われ、偽造SAMLで多要素認証が迂回された[2]。もう1つは、事業者の一般消費者向けの署名鍵が露出し、その鍵で作ったトークンが企業・政府向け環境でも受理された事件で、1機関から6万通超のメールが持ち出された[2][3]。IRがこの事件の出典に挙げるのは、MicrosoftによるStorm-0558（攻撃グループの呼称）の分析だ[2]。
法的な位置づけは控えめに読む必要がある。IRは米連邦環境が対象で、準拠は任意、OMBの方針や契約で求められた場合に拘束力を持つと明記している[2]。日本企業にとっては規制ではなく、事業者に質問するための物差しだ。
クラウド時代のID管理を内部統制や情報セキュリティとの関係から整理しており、IdP契約の確認項目を社内規程に落とし込む際の参考になる
トークンの有効期限と失効はどこまで自社設定で決められるか
トークンの寿命とセッション管理は、IRの責任分担表でも利用側の担当に置かれており、自社設定で詰められる領域だ[2]。IRはアクセストークンとIDトークンの有効期間を1時間以内とするよう推奨している[2]。
Entra IDの既定値はこの推奨に近い。アクセストークンは60〜90分（平均75分）、IDトークンとSAMLトークンは1時間が既定だ[4]。AccessTokenLifetimeで10分から1日の範囲で変えられるが、設定はMicrosoft GraphかPowerShellに限られる[4]。
注意点はリフレッシュトークンだ。Entra IDでは2021年1月30日以降、リフレッシュトークンの寿命はポリシーで変えられず、未使用90日で失効し、使い続ける限り失効しない既定値が固定されている[4]。IRは対話利用のリフレッシュトークンを再認証の間隔より長くしないよう求めており、Entra IDでは条件付きアクセスのサインイン頻度で再認証を強制するのが対応手段になる[2][4]。Oktaでは認可サーバーのアクセスポリシーで両トークンの寿命を選ぶ[5]。
失効について、IRは受け取り側が発行元へ問い合わせない方式では即時の一斉失効が難しいと認める[2]。そのうえで、失効をSaaSへ伝えるSSFとCAEP（セッション失効などのリスク信号を送る標準）の実装を推奨する[2]。Entra IDのCAE（継続的アクセス評価）は、寿命を最長28時間に延ばす代わりにアカウント無効化などでほぼ即時に失効させる[4]。
| 項目 | IR 8587の推奨 | 担うのは |
|---|---|---|
| アクセス・IDトークンの寿命 | 1時間以内（SHOULD） | 利用側の設定 |
| 対話利用のリフレッシュトークン | 再認証間隔を超えない（SHOULD NOT） | 利用側の設定 |
| 失効方法と範囲の開示 | 事業者が利用側へ伝える（MUST） | 事業者 |
| 失効信号の伝達（SSF/CAEP） | 実装を推奨（SHOULD） | 双方 |
数千人規模の従業員を抱え、SharePoint Server（Microsoft 365ではなくオンプレミス環境で運用する社内ポータル基盤）を人事・稟議・ナレッジ共有の窓口として使い、年1回の内部監査を受ける企業のIT基盤担当者に、いま最[…]
署名鍵の保管とローテーションはなぜ契約でしか担保できないか
署名鍵の管理はIRの責任分担表で事業者側に置かれ、利用側は設定で触れられない[2]。担保の手段は調達時の質問と契約条項になる。
IRの要求は具体的だ。影響度が中以上のシステムでは署名鍵をHSM（鍵を取り出せない専用ハードウェア）などの隔離された保管先に置くこと、高影響では署名処理自体も隔離環境で行うことを必須（MUST）としている[2]。鍵の使用期間は高影響で90日以内、中・低影響でも1年未満が推奨（SHOULD）だ[2]。鍵をテナント単位など最小の範囲に限定することも必須だ[2]。
SaaS調達時の質問票には次の項目を入れたい。
| 確認項目 | IR 8587の根拠 | 事業者に求める回答 |
|---|---|---|
| 署名鍵の保管方式 | 中以上はハードウェア等で隔離（MUST） | HSM等の利用有無 |
| 鍵の使用期間 | 高影響90日以内（SHOULD） | ローテーション周期 |
| 鍵の適用範囲 | 最小範囲に限定（MUST） | テナント単位かどうか |
| audience検証 | 欠落・不一致は拒否（MUST） | 検証の実装有無 |
| ログ | トークン関連ログの記録と利用者への提供（MUST） | 取得可能な項目と保存期間 |
ログについてIRは、トークン自体や個人データの記録を禁じつつ、発行・更新・受理・失効の記録と、SIEM（ログ分析基盤）で扱える形式での提供を求める[2]。
主要システムをAzureのWest US（米国西部）リージョン単一に集約し、複数リージョンへの分散やDR（災害復旧）計画をまだ具体化していない企業のインフラ担当者は、この障害の技術的経緯を無視できない。2026年7月23日14時44分（U[…]
IdPとSaaSの契約見直しを日本企業の稟議と監査にどう組み込むか
署名鍵が事業者側にある構造は、日本企業がSaaSを使う場合も変わらない。違うのは、事業者に質問を届ける経路と、回答を統制に組み込む手続きだ。
| 観点 | 米連邦機関（IRの想定） | 日本企業 |
|---|---|---|
| 準拠の根拠 | OMB方針や契約で求められれば拘束 | 任意。社内規程に取り込めば統制になる |
| 事業者との関係 | 直接契約が中心 | SIerや販売代理店を介する契約が多い |
| 確認の場 | FedRAMP等の評価 | 年次監査、委託先管理の評価 |
| 変更の手続き | 機関ごとのリスク評価 | 稟議と承認フロー |
代理店経由の契約では、事業者へ質問が届くまでに時間がかかる。答えが得られない項目は、残存リスクとして監査資料に明記する運用が現実的だ。
- IT部門の判断：寿命と再認証の設定は今期中に見直し、鍵管理は質問票で確認する
- 決裁側の判断：契約更新時に、回答のない事業者をリスク受容するか代替を検討するかを決める
MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]
まとめ
NIST IR 8587の要点は、トークン事故の対策を事業者と利用側に分け、数値目安を示した点にある。トークンの寿命と再認証は自社設定で、署名鍵の保管・周期・適用範囲は契約と確認で担保する。
- IT部門担当者の次の一手：SSO連携中のSaaSを棚卸しし、Entra IDならトークン寿命と条件付きアクセスのサインイン頻度を1時間の推奨と照らして検証する。
- 決裁側の判断材料：費用は設定変更と質問票・契約交渉の工数が中心になる。ただしサインイン頻度などの条件付きアクセスにはEntra ID P1が必要なので、ライセンスの現状は別途確認する。そのうえで、次の契約更新時期に鍵管理の開示を条件に入れるかどうかがリスク判断の分かれ目になる。
IRは米連邦向けの任意のガイドだが、事業者に何を尋ねるかの物差しとして日本企業でも使える。
よくある質問（FAQ）
NIST IR 8587に従わないと違反になりますか
なりません。IR自身が準拠は任意で、方針や契約で求められた場合に拘束力を持つと書いています[2]。
トークンの有効期限を短くすれば窃取は防げますか
防げません。悪用できる時間が縮むだけです。IRはDPoPやmTLS（トークンを端末に結びつける方式）と利用監視の併用を推奨しています[2]。
ドラフト版と最終版で大きな違いはありますか
一次情報では差分の一覧を確認できませんでした。ドラフトは2025年12月22日、最終版は2026年9月15日に公開されています[1]。
出典
- https://csrc.nist.gov/pubs/ir/8587/final
- https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8587.pdf
- https://www.helpnetsecurity.com/2026/09/16/nist-cisa-cloud-token-security-guidance/
- https://learn.microsoft.com/en-us/entra/identity-platform/configurable-token-lifetimes
- https://help.okta.com/en-us/content/topics/security/api-config-access-policies.htm
