AD FS権限昇格CVE、SSO基盤を守る鍵は証明書管理

今回取り上げるのはAD FS（Active Directory Federation Services、Windows Server上でSSO・フェデレーション認証を提供する機能）のDKM（Distributed Key Manager）コンテナに見つかった権限昇格の脆弱性、CVE-2026-56155だ。影響を受けるのは、AD FSを社内外の複数アプリケーションと連携するSSOのハブとして運用しているID管理者・インフラ運用担当者である。2026年7月14日のPatch Tuesdayでこの脆弱性が修正されると同時に、CISAは同日、実際の悪用が確認された脆弱性としてKEV（Known Exploited Vulnerabilities Catalog、悪用が確認された脆弱性をCISAが公開するカタログ）に追加した[1][2]。連邦機関には2026年7月28日までの対応期限が課されている[2]。この脆弱性が重大なのは、単体サーバーの侵害にとどまらない点にある。DKMコンテナのアクセス権限が緩いと、そこで守られているトークン署名証明書（SSOでユーザー認証を裏付ける電子的な証明書）まで奪われ、AD FSを信頼するすべてのアプリへ被害が波及しうる。本稿では脆弱性の技術的な内容、攻撃がSSO基盤全体に波及する経路、マイクロソフトが用意した段階的なハードニング計画、そしてパッチ適用後に必要なACL点検の手順まで整理する。

予備知識

• AD FS（Active Directory Federation Services）: Windows Server上でSSO・フェデレーション認証を提供する機能。社内外の複数アプリケーションへの認証を一元化するハブとして使われる
• DKM（Distributed Key Manager）: AD FSがトークン署名鍵・トークン暗号化鍵などの秘密鍵情報を暗号化し、複数のAD FSサーバー間で共有管理する仕組み。Active Directory上のコンテナオブジェクトとして保存される
• トークン署名証明書: SSOでユーザー認証の正当性を裏付ける電子的な証明書。この秘密鍵が漏洩すると、任意のユーザーになりすました認証トークンを偽造できてしまう
• ACL（アクセス制御リスト）: 誰がどのリソースに対してどのような操作を行えるかを定義する権限設定。DKMコンテナのACLが緩いことが今回の根本原因にあたる

セキュリティ

Langflow認証バイパスが示すAI Agent基盤の権限盲点

AIエージェント構築ツール「Langflow」は、LLM（大規模言語モデル）やRAG（検索拡張生成）の処理をノードとしてつなぎ、コードを書かずにAIエージェントを組み立てられるオープンソースのアプリケーション層プラットフォームである[…]

AD FSのDKMコンテナに見つかった脆弱性の中身

CVE-2026-56155は、AD FSがDKMコンテナに設定するACLが過度に緩いことに起因する権限昇格の脆弱性である。CWE-1220（アクセス制御の粒度不足）に分類され、CVSS 3.1ベーススコアは7.8、深刻度は「重要（Important）」に位置づけられている[1][3]。ローカルに認証済みでアクセスできる攻撃者（authorized local attacker）がDKMコンテナへの読み取り権限を持っていた場合、そこに格納されたトークン署名証明書・トークン暗号化証明書の秘密鍵を保護する鍵材料を読み取り、復号できてしまう[1]。リモートから認証なしで直接突かれる脆弱性ではないが、フィッシングや別の初期侵害で足場を得た攻撃者にとっては、次の一手として狙いやすい経路になる。

セキュリティ

SBOMが「任意」から「義務」へ、EU CRAが迫る棚卸しの実務

ソフトウェアサプライチェーン管理とコンプライアンスの領域で、EU向けにソフトウェアを提供する企業の実務判断が変わりつつある。欧州連合サイバーセキュリティ機関ENISAは2026年6月、SBOM（Software Bill of Ma[…]

攻撃はどのように連鎖してSSO全体に波及するのか

このセクションでは、ローカルの権限昇格が最終的にSSO基盤全体の侵害へつながる攻撃連鎖を整理する。起点は、攻撃者がAD FSサーバーへのローカル認証済みアクセスを何らかの形で確保することだ。フィッシングで奪った低権限アカウントや、既存の侵害で得た足場が典型例になる。そこからDKMコンテナのACL不備を悪用して鍵材料を読み取り、トークン署名証明書とトークン暗号化証明書の秘密鍵を復号する[1]。秘密鍵を手にした攻撃者は、AD FSが発行する認証トークンを自由に偽造できるようになる。これは特定ユーザーのパスワードを盗む攻撃とは質が異なる。AD FSを信頼して認証を委ねているすべてのアプリケーション、すなわちクラウドサービスからオンプレミスの業務システムまで、任意のユーザーになりすました有効なトークンで侵入できてしまう。しかも偽造トークンは正規の認証フローを通過するため、個別アプリのログだけでは異常として検知しづらい。

Patch Tuesdayの段階的ハードニング計画を理解する

このセクションでは、マイクロソフトが今回採用した段階的なハードニング計画の中身を確認する。マイクロソフトはDKMコンテナのACLを即座に一斉修正するのではなく、監査モードから強制モードへ移行する二段階の計画を採った[1][3]。2026年7月14日のKB5121391適用後、AD FSサービスはサービス起動のたびに加え24時間ごとにDKMコンテナのACLを監査するようになる[1]。ACLが過度に緩いと判定された場合、AD FSの管理イベントログにEvent ID 1132が記録され、管理者に是正が必要であることを知らせる[1]。この監査モードの期間中、ACLそのものは自動修正されない。マイクロソフトは2026年10月13日のセキュリティ更新プログラムから、Windows Server 2016以降を対象に強制モードへ移行し、レジストリキー（RemediateDkmAcl）を明示的に0へ設定して自動修正をオプトアウトしない限り、緩いACLを自動的に是正する計画だ[1][3]。

パッチ適用後に必須のDKMコンテナACL点検

このセクションでは、パッチ適用だけでは足りない理由と、管理者が実際に何を確認すべきかを整理する。KB5121391の適用は監査モードを有効にするだけで、既に緩んでいるACLそのものを即座には是正しない。強制モードが始まる10月13日まで、脆弱なACLが放置されるおそれがある。組織のリスク許容度によっては、それを待たずに能動的な点検を行う価値がある。

具体的な手順として、まず全AD FSサーバーの管理イベントログでEvent ID 1132の有無を確認する。検出された場合は強制モードを待たず、DKMコンテナのACLを手動で是正する。加えて、パッチ適用前の期間に不審なローカルアクセスの痕跡がなかったかを併せて確認し、疑わしい場合はトークン署名証明書のロールバック（再発行）も選択肢に入れておきたい。

よくある質問（FAQ）

Q1. CVE-2026-56155は誰が影響を受けますか？
AD FSをSSO・フェデレーション認証のハブとして運用している組織のID管理者・インフラ運用担当者が直接の対象だ。攻撃が成立した場合、AD FSを信頼して認証を委ねているすべての連携アプリの利用者にも被害が波及しうる。

Q2. パッチを適用すればそれだけで安全ですか？
いいえ。KB5121391の適用はDKMコンテナのACLを監査するモードを有効にするだけで、既に緩んでいるACLを即座には修正しない。Event ID 1132の確認と手動是正、または2026年10月13日の強制モード移行を待つかの判断が別途必要になる[1]。

Q3. リモートから直接悪用される脆弱性ですか？
いいえ。攻撃にはローカルに認証済みでアクセスできる状態（authorized local attacker）が前提となる[1]。ただしフィッシングなど別の初期侵害と組み合わされた場合、SSO基盤全体への波及につながりうる点は軽視できない。

まとめ

CVE-2026-56155の核心は、DKMコンテナのACLという一見地味な権限設定が、SSO基盤全体の信頼を支えるトークン署名証明書の安全性に直結していた点にある。パッチ適用は監査モードを有効にするための必須の第一歩だが、それだけでは既存の緩いACLは是正されない。管理者が取るべき行動は明確だ。まずKB5121391を全AD FSサーバーに適用し、次に管理イベントログでEvent ID 1132の有無を確認する。検出された場合は10月13日の強制モードを待たず、DKMコンテナのACLを能動的に是正する。SSOのように信頼を一点に集約する基盤ほど、その一点を守る権限設定の点検を運用ルーチンに組み込む価値がある。

出典