VBS(仮想化ベースのセキュリティ)とコア分離は同じものですか？

厳密には別物です。VBSはハイパーバイザーで隔離環境を作る土台の技術で、Windowsセキュリティアプリの「コア分離」は、VBSの上に成り立つ複数の保護機能をまとめた画面の名前です。その代表が「メモリ整合性」で、これはHVCI(ハイパーバイザーで保護されたコード整合性)を指します。個々のサービスの動作状態は、画面表示ではなくWin32_DeviceGuardの照会で確認します。

VTL1のメモリは、管理者権限でもカーネルドライバーでも本当に読めないのですか？

読めません。VTLごとのメモリアクセス保護はハイパーバイザーがパーティションの物理アドレス空間に対して管理しており、パーティション内で動くソフトウェアからは変更できないためです。カーネル(リング0)で動くコードであっても、VTL0からVTL1のメモリへのアクセスは許可されません。

メモリ整合性(HVCI)を有効にするとドライバーが動かなくなることがあるのはなぜですか？

HVCI環境では、カーネルのページは整合性検証に合格して初めて実行可能になり、実行可能ページへの書き込みは許可されません。署名のないドライバーや、実行可能メモリを書き換える古い設計のドライバーはこの制約に適合できず、読み込みがブロックされます。ブロックの記録はCodeIntegrity運用ログ(イベントID 3087など)で確認できます。

Credential Guardは何を守り、何を守らないのですか？

ドメイン資格情報のNTLMパスワードハッシュ、KerberosのTGT、アプリがドメイン資格情報として保存したものを隔離環境で保護します。一方、Kerberosのサービスチケット、ローカルアカウントやMicrosoftアカウントの資格情報、キーロガーによる入力の窃取、物理攻撃は保護の対象外です。

VBSが動いているかどうかはどこで確認できますか？

msinfo32の「仮想化ベースのセキュリティ」欄、またはPowerShellでroot/Microsoft/Windows/DeviceGuard名前空間のWin32_DeviceGuardクラスを照会します。SecurityServicesRunningに1が含まれればCredential Guard、2が含まれればメモリ整合性(HVCI)が動作中です。

Windows仮想化の深層(第2回) ── カーネルからも見えないメモリ:VBS・HVCI・Credential Guardの仕組み

2026年08月22日 03:00 · 小村豪 · Windows, 仮想化, セキュリティ, VBS, HVCI, Credential Guard

かつて、Windowsの攻撃者にとって管理者権限は「ゴール」でした。管理者としてカーネルドライバーを読み込み、LSASSプロセスのメモリをダンプすれば、パスワードハッシュやKerberosチケットが手に入る。そこから先は、盗んだハッシュで別のマシンへ渡り歩くだけです。

Credential Guardが動作している現在のWindows 11──Enterprise・Educationなどのライセンス要件とハードウェア要件を満たすデバイスでは22H2以降、既定でこの状態です──では、この定石が通用しません。カーネルを完全に掌握した攻撃者がメモリをいくら探しても、保護対象のドメイン資格情報のハッシュの実体が「そのOSの中」に見つからないのです。動作していなければ従来どおり危険なので、後述の確認方法とあわせて読んでください。

では、どこにあるのでしょうか。答えは「同じPCの中に作られた、もう1つの世界」です。第1回で見たとおり、ホストのWindowsはハイパーバイザーの上のルートパーティションで動いています(「あなたのWindowsはどこで動いているのか」)。本記事はその続きとして、ハイパーバイザーが同じパーティションの内側に引く、もう1本の境界線を追います。

第2回が答える疑問は、ただ1つです。

管理者権限でもカーネルでも読めない秘密を、Windowsはどこに置いているのか。

対象読者は、コア分離・メモリ整合性・Credential Guardといった言葉を設定画面やトラブル対応で見かけ、その実体を仕組みから理解したい開発者・運用担当者です。前提環境はx64のWindows 10/11または現行のWindows Serverです(第1回と同じく、リングやSLATの説明はx64を前提とし、Arm64は例外レベルなど別の仕組みを使います)。前提知識は第1回で扱ったパーティションとSLATの概念です。難易度は中級です。セキュリティ機能の設定手順書ではなく、構造の解説を目的とします。

1. まず結論

WindowsはVTL(仮想信頼レベル)という特権の軸を追加し、秘密をVTL1に置いた。VTL0で動く通常のカーネルからVTL1のメモリは読めない。境界を守っているのはカーネル自身ではなく、SLATの変換表を握るハイパーバイザーである。

これが仮想化ベースのセキュリティ(VBS)の骨格です。VBSはハイパーバイザーを使って隔離された環境を作り、そこにセキュリティ機能を収容します。カーネルが侵害されても隔離環境は守られる、という前提で設計されています。¹

flowchart TB
    accTitle: VBSが作る2つの世界
    accDescr: 同じパーティションの中にVTL0とVTL1があり、VTL0には通常のカーネルとアプリ、VTL1にはセキュアカーネルと隔離されたセキュリティ機能が入り、境界はハイパーバイザーが守る
    subgraph vtl0 ["VTL0（通常の世界）"]
        apps["アプリ（リング3）"]
        ntk["NTカーネルとドライバー（リング0）"]
    end
    subgraph vtl1 ["VTL1（隔離された世界）"]
        ium["隔離されたセキュリティ機能"]
        sk["セキュアカーネル"]
    end
    hv["ハイパーバイザー（SLATで境界を強制）"] --- vtl0
    hv --- vtl1
    ntk -.->|読み取り不可| ium

図1: 1つのWindowsの中に2つの世界があり、VTL0のカーネルからVTL1のメモリへはアクセスできない。

「もう1つのVMを立てている」わけではない点が重要です。VTL0とVTL1は同じパーティション、同じWindowsの内側にあります。この分割がどう実現されているのかを、順に見ていきます。

この記事の知識マップ

VBSはWindowsハイパーバイザーで隔離環境を作り、カーネルが侵害され得る前提でセキュリティ機能を収容する。隔離は仮想セキュアモードが提供する仮想信頼レベルで実現され、その境界はSLATのメモリアクセス保護が支える。HVCI(メモリ整合性)はコード整合性検証をVBSの隔離環境で実行してカーネルへのコード注入を防ぐが、要件に適合しないドライバーの読み込みブロックの原因になることがあり、その記録はCodeIntegrity運用ログで確認できる。VTL1ではセキュアカーネルの上の分離ユーザーモードでトラストレットが動き、システムコールの多くはVTL0のNTカーネルへ依頼される。Credential GuardはVBSを使い、ドメイン資格情報のNTハッシュやTGTを分離LSAプロセスに保管し、保護対象のドメイン資格情報に対するPass-the-Hash攻撃を防ぐ。VBSと各サービスの動作状態はWin32_DeviceGuardクラスで確認できる。

flowchart LR
    accTitle: VBS・HVCI・Credential Guardの知識マップ
    accDescr: VBSがハイパーバイザーと仮想信頼レベルとSLATで隔離を作り、HVCIがカーネルへのコード注入を防ぎつつドライバーブロックの原因にもなり、Credential Guardが分離LSAプロセスで秘密を守る関係図
    vbs["仮想化ベースのセキュリティ"]
    virtual_trust_level["仮想信頼レベル"]
    hvci["メモリ整合性"]
    credential_guard["Credential Guard"]
    windows_hypervisor["Windowsハイパーバイザー"]
    virtual_secure_mode["仮想セキュアモード"]
    slat["SLAT"]
    kernel_code_injection["カーネルへのコード注入"]
    hvci_driver_block["HVCIによるドライバー読み込みブロック"]
    codeintegrity_log["CodeIntegrity - Operationalログ"]
    lsaiso["分離LSAプロセス"]
    pass_the_hash["Pass-the-Hash"]
    win32_deviceguard["Win32_DeviceGuardクラス"]
    secure_kernel["セキュアカーネル"]
    isolated_user_mode["分離ユーザーモード"]
    trustlet["トラストレット"]
    nt_kernel["NTカーネル"]
    tgt["TGT(チケット許可チケット)"]
    nt_hash["NTハッシュ"]
    msinfo32["msinfo32(システム情報)"]
    hvci_compatible_driver["HVCI対応ドライバー"]
    lateral_movement["横展開(ラテラルムーブメント)"]
    vbs -->|"利用する"| windows_hypervisor
    virtual_secure_mode -->|"利用する"| virtual_trust_level
    virtual_trust_level -->|"利用する"| slat
    hvci -->|"利用する"| vbs
    hvci -->|"防止する"| kernel_code_injection
    hvci -.->|"原因になり得る"| hvci_driver_block
    hvci_driver_block -->|"で確認できる"| codeintegrity_log
    credential_guard -->|"利用する"| vbs
    credential_guard -->|"利用する"| lsaiso
    credential_guard -.->|"防止する"| pass_the_hash
    vbs -->|"で確認できる"| win32_deviceguard
    vbs -->|"利用する"| virtual_secure_mode
    secure_kernel -->|"利用する"| virtual_trust_level
    isolated_user_mode -->|"利用する"| secure_kernel
    lsaiso -->|"利用する"| isolated_user_mode
    trustlet -->|"利用する"| nt_kernel
    tgt -.->|"に保存される"| lsaiso
    nt_hash -.->|"に保存される"| lsaiso
    vbs -->|"で確認できる"| msinfo32
    windows_hypervisor -->|"実装を担う"| virtual_secure_mode
    hvci_compatible_driver -->|"推奨される対応"| hvci_driver_block
    pass_the_hash -->|"原因になり得る"| lateral_movement

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. リングモデルの限界 ── 守る側と守られる側が同じ高さにいる

従来のWindowsのセキュリティは、リング(特権レベル)の階段の上に組み立てられていました。ユーザーモード(リング3)は、カーネルモード(リング0)が守る。ではリング0は誰が守るのか──誰も守れません。リング0が最高特権だからです。

この構造には、構造的な弱点が2つあります。

カーネルは一枚岩ではない。 リング0では、Windows本体だけでなく多数のサードパーティ製ドライバーが動きます。どれか1つに脆弱性があれば、攻撃者はリング0のコード実行を手に入れられます。
リング0からは全てが見える。 LSASSのようなユーザーモードプロセスがどれだけ自衛しても、カーネルを掌握した攻撃者からメモリは読み放題です。保護属性もページテーブルも、カーネル自身が管理しているからです。

flowchart TB
    accTitle: 従来のリングモデルにおける資格情報窃取の経路
    accDescr: 脆弱なドライバー経由でリング0を掌握した攻撃者は、カーネルの全権限でLSASSプロセスのメモリを読み、パスワードハッシュを取得できてしまう
    mal["攻撃者のコード"] -->|脆弱なドライバーを悪用| r0["リング0を掌握"]
    r0 --> readall["全物理メモリを読める"]
    readall --> lsass["LSASSのメモリからハッシュを取得"]
    lsass --> lateral["別マシンへの横展開に悪用"]

図2: 守る側(カーネル)と守られる側(秘密)が同じ高さにいるため、リング0が落ちれば全てが落ちることが根本の弱点。

つまり必要なのは、「リング0より高い場所」です。第1回で、その場所はすでに登場しています。ハイパーバイザーは、カーネルよりも高い特権で動き、CPUのメモリアクセス許可の制御(SLAT)を早期に独占します。ハイパーバイザーが守る隔離領域は、リング0の(スーパーバイザーモードの)OSソフトウェアからのアクセスに対しても保護されます。²

3. VSMとVTL ── 特権にもう1本の軸を足す

3.1. 仮想信頼レベル(VTL)

この隔離を提供するハイパーバイザーの機能群を、VSM(仮想セキュアモード)と呼びます。VSMはDevice Guard、Credential Guard、仮想TPMなどの土台です。²

VSMの中心概念がVTL(Virtual Trust Level:仮想信頼レベル)です。要点は次のとおりです。²

VTLは階層的で、番号が大きいほど特権が高い。VTL0が最下位で、VTL1はVTL0より特権が高い。
アーキテクチャ上は16レベルまで定義されているが、現在実装されているのはVTL0とVTL1の2つ。
VTLごとに独立したメモリアクセス保護を持つ。この保護はハイパーバイザーがパーティションの物理アドレス空間に対して管理するため、パーティション内のシステムソフトウェアからは変更できない。
仮想プロセッサはVTLごとに別々のレジスタ状態と割り込み機構を持ち、低いVTLから高いVTLの状態は覗けない。

flowchart TB
    accTitle: VTL分離を構成する3つの独立
    accDescr: VTLごとにメモリアクセス保護、仮想プロセッサのレジスタ状態、割り込みの仕組みが独立しており、低いVTLからは高いVTLのどれにも触れられない
    vtl["VTLごとに独立するもの"] --> m1["メモリアクセス保護"]
    vtl --> m2["仮想プロセッサのレジスタ状態"]
    vtl --> m3["割り込みの仕組み"]
    m1 -.-> rule["低いVTLからは高いVTLに触れられない"]
    m2 -.-> rule
    m3 -.-> rule

図3: メモリだけでなくCPUの状態も割り込みも別世界にするのが、覗き穴を残さないための三点セット。

リング(0と3)が「OSとアプリ」を分ける軸だとすれば、VTLは「通常世界と隔離世界」を分ける第2の軸です。2つの軸は直交していて、VTL1の中にもカーネルモードとユーザーモードがあります。

flowchart TB
    accTitle: リングとVTLの2軸が作る4つの領域
    accDescr: リングの軸はカーネルモードとユーザーモードを分け、VTLの軸は通常世界と隔離世界を分け、組み合わせで通常アプリ、NTカーネル、IUMのトラストレット、セキュアカーネルの4領域ができる
    subgraph ax0 ["VTL0（通常世界）"]
        a0["リング3:通常のアプリ"]
        k0["リング0:NTカーネルとドライバー"]
    end
    subgraph ax1 ["VTL1（隔離世界）"]
        a1["リング3:IUM（トラストレット）"]
        k1["リング0:セキュアカーネル"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

図4: 特権の軸は2本になり、「カーネルかどうか」と「隔離世界かどうか」は別の問いになった。

3.2. 境界の実体はSLAT

第1回で、ゲスト物理アドレス(GPA)を実際のRAM(SPA)へ対応付ける二段目の変換表──SLAT──はハイパーバイザーが握っている、と述べました。VSMはまさにこの性質を使います。VTLの隔離は、Hyper-VハイパーバイザーとSLATを利用して作られています。³

VTL1が「このメモリはVTL0に見せない」と宣言すると、ハイパーバイザーはVTL0用の変換表からそのページへのアクセス許可を落とします。以後、VTL0のカーネルがそのアドレスに触れようとしても、CPUのアドレス変換の段階で拒否されます。カーネルが自分のページテーブルをどう書き換えても無駄です。ページテーブル(GVA→GPA)はカーネルの持ち物でも、その先の変換(GPA→SPA)と最終的なアクセス許可はハイパーバイザーの持ち物だからです。

flowchart TB
    accTitle: VTL0からVTL1のメモリへのアクセスが拒否される流れ
    accDescr: VTL0のカーネルがVTL1のメモリを読もうとすると、自分のページテーブルは通過できてもSLATのアクセス保護で拒否され、ハイパーバイザーに制御が移る
    try["VTL0のカーネルがVTL1のページを読もうとする"] --> pt["カーネル自身のページテーブルは通過"]
    pt --> slat{"SLATのアクセス保護は許可している?"}
    slat -->|許可なし| deny["ハイパーバイザーが介入しアクセス拒否"]
    slat -->|許可あり| ok["通常のメモリアクセス"]
    deny -.-> point["カーネルに変更できない層で守られる"]

図5: 防壁はカーネルの外にあり、SLATの保護はパーティション内のソフトウェアから変更できない。

メモリ連載第1回では「VADとPTEと保護属性がアクセスの可否を決める」と書きました。VBS環境では、その全てに合格した後、さらにSLATの検問が待っている──と整理できます。

3.3. セキュアカーネルとIUM

VTL1の中で動くのは、通常のNTカーネルではなく、セキュアカーネルと呼ばれる小さなカーネルです。VTL1のユーザーモードはIUM(Isolated User Mode:分離ユーザーモード)と呼ばれ、そこで動くプログラムはトラストレット(信頼されたプロセス)と呼ばれます。³

トラストレットは、通常のプロセスのように何でもできるわけではありません。システムコールの多くはVTL0側のNTカーネルへマーシャリングして処理を依頼します。³ VTL1は「何でもできる上位世界」ではなく、秘密を保持する金庫室として、意図的に小さく作られています。庫内に持ち込めるコードが少ないほど、攻撃面も小さくなるからです。

flowchart TB
    accTitle: トラストレットのシステムコールの流れ
    accDescr: VTL1のトラストレットはシステムコールの多くを自前で処理せず、VTL0のNTカーネルへマーシャリングして依頼し、結果だけを受け取ることでVTL1を小さく保つ
    tl["トラストレット（VTL1のIUM）"] --> sc{"システムコールが必要"}
    sc -->|多くの場合| mar["VTL0のNTカーネルへ依頼"]
    mar --> res["結果だけ受け取る"]
    res -.-> small["VTL1側は小さく保たれ攻撃面が減る"]

図6: 金庫室は自前の設備を持たず、雑務は外へ依頼して秘密だけを守り続ける。

4. HVCI ── カーネルのコード整合性を金庫室で検証する

4.1. 何を検証しているのか

VBSの上に載る代表的な機能の1つ目が、メモリ整合性──HVCI(ハイパーバイザーで保護されたコード整合性)です。Windowsには、カーネルモードのドライバーやバイナリを起動前に検査し、未署名・信頼されないものを読み込ませないコード整合性の仕組みがあります。HVCIはこの検証をVBSの隔離環境の中で実行します。¹

検証ロジック自体をVTL1へ移す理由は、第2節の弱点そのものです。検証コードがVTL0のカーネル内にあれば、カーネルを掌握した攻撃者は検証をすり替えられます。VTL1にあれば、すり替えの手が届きません。

flowchart TB
    accTitle: 検証コードの置き場所による違い
    accDescr: 検証コードがVTL0のカーネル内にあるとカーネル掌握で無効化されるが、VTL1にあればカーネルを掌握した攻撃者にも手が届かず検証が守られる
    atk["カーネルを掌握した攻撃者"] --> q{"コード整合性の検証はどこにある?"}
    q -->|"VTL0のカーネル内（従来）"| bad["検証ロジックをすり替えられる"]
    q -->|"VTL1の隔離環境（HVCI）"| good["すり替えの手が届かない"]
    bad --> res1["未署名コードがカーネルで実行され得る"]
    good --> res2["検証はカーネル侵害後も機能し続ける"]

図7: 検問所を破られる可能性のある側の内側に置かない、という検証ロジックの引っ越しがHVCIの本質である。

4.2. 実行可能ページのルール

HVCIの効果は「起動時の検査」に留まりません。カーネルメモリの割り当てにも制約をかけます。⁴

カーネルのページは、コード整合性の検証に合格して初めて実行可能になる。
実行可能なページは書き込み可能にならない(いわゆるW^X)。

この2つが揃うと、たとえバッファオーバーフローなどの脆弱性でカーネルメモリを書き換えられても、書き換えた内容を実行に移せません。実行可能ページは書き換えられず、書き換えられるページは実行できないからです。⁴ 実行許可の最終的な裏付けはSLAT側の実行権限にあり、これはVTL0のカーネルには操作できません。

flowchart TB
    accTitle: HVCI環境でカーネルページが実行可能になるまで
    accDescr: ドライバーの読み込み要求はVBSの隔離環境でコード整合性検証を受け、合格すれば実行可能かつ書き込み不可のページとして許可され、不合格ならブロックされてCodeIntegrityログに記録される
    load["カーネルコードの読み込み・実行要求"] --> verify{"隔離環境でのコード整合性検証"}
    verify -->|合格| exec["実行可能ページとして許可（書き込みは不可）"]
    verify -->|不合格| block["読み込みブロック"]
    block --> log["CodeIntegrity運用ログに記録（イベントID 3087）"]
    exec -.-> wx["書き込み可能なページは実行不可のまま"]

図8: 実行と書き込みを両立させない規則の検証はVTL1側で行われ、VTL0のカーネルには覆せない。

攻撃者の視点でなぞると、この規則の効き方がよく分かります。

flowchart TB
    accTitle: HVCI環境でコード注入が失敗する流れ
    accDescr: 脆弱性でカーネルメモリを書き換えても、書き込みできたページは実行不可であり、実行可能ページはそもそも書き換えられないため、注入したコードを実行に移せない
    inj["脆弱性でカーネルメモリに細工を試みる"] --> which{"狙うページはどちら?"}
    which -->|書き込み可能なページ| wok["書き換えは成功する"]
    which -->|実行可能なページ| xfail["書き換え自体ができない"]
    wok --> nx["しかしそのページは実行不可"]
    nx --> dead["注入コードを実行へ移せない"]
    xfail --> dead

図9: どちらの入口から入っても行き止まりになるところに、書けるページと走れるページを交差させない意味がある。

4.3. ドライバー互換性という代償

このルールは、古い設計のドライバーと衝突します。自分のコードを実行時に書き換える、署名がない、実行可能かつ書き込み可能なメモリを要求する──そのようなドライバーはHVCI環境で読み込めません。ブロックの事実は、イベントビューアーのApplications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational(イベントID 3087が代表)で確認できます。⁵

「メモリ整合性を有効にすると周辺機器が動かない」というトラブルの正体は、多くの場合これです。対処の本筋はHVCI対応版ドライバーへの更新であり、メモリ整合性の無効化は保護を丸ごと手放す最終手段と考えるべきです。ドライバー開発の立場からこの検証に関わる場合は、フィルタードライバーの記事(「Windowsのミニフィルタードライバー」)も参考にしてください。

flowchart TB
    accTitle: メモリ整合性で周辺機器が動かないときの切り分け
    accDescr: CodeIntegrity運用ログでブロックされたドライバーを特定し、本筋はHVCI対応版への更新で対応し、対応版がない場合はベンダーへ要請し、無効化は恒久設定にしない最終手段とする
    sym["メモリ整合性を有効にしたら機器が動かない"] --> log2["CodeIntegrityログでブロック元を特定"]
    log2 --> upd{"HVCI対応版ドライバーはある?"}
    upd -->|ある| fix2["更新して有効のまま解決"]
    upd -->|ない| ask2["ベンダーへ対応版を要請"]
    ask2 -.-> temp["無効化は恒久設定にしない最終手段"]

図10: 最初に見るのは設定画面ではなくログで、ブロックの犯人はイベントID 3087が知っている。

5. Credential Guard ── ハッシュはLSAIsoの中

5.1. LSASSとLSAIso

VBSの上に載る代表機能の2つ目が、冒頭の謎の答え、Credential Guardです。

従来のWindowsは、NTLMハッシュやKerberosのチケット類をLSAプロセス(lsass.exe)のメモリに保持していました。Credential Guardが有効になると、このうちドメイン資格情報のNTLMハッシュやKerberosのTGT(チケット供与チケット)といった保護対象の秘密の保管は、LSAIso.exe──VTL1のIUMで動くトラストレット──へ移ります。⁶

lsass.exe(VTL0)は、これまでどおり認証処理の窓口として動く。
秘密の実体はLSAIso.exe(VTL1)が保持し、VTL0からはアクセスできない。
両者はRPC(リモートプロシージャコール)で通信する。
LSAIsoはデバイスドライバーを一切ホストせず、必要最小限の署名済みバイナリだけを収容する。署名はVBSが信頼する証明書で検証される。⁶

flowchart TB
    accTitle: Credential Guard有効時の資格情報の配置
    accDescr: VTL0のlsassは認証の窓口としてRPCでVTL1のLSAIsoと通信し、保護対象のドメイン資格情報のハッシュやTGTの実体はLSAIsoが保持するため、VTL0で管理者権限を得た攻撃者がlsassをダンプしても保護対象の実体は得られない
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe（認証の窓口）"]
        att["攻撃者（管理者権限）"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe（秘密の保管庫）"]
    end
    lsassP <-->|RPC| iso
    att -->|メモリダンプ| lsassP
    att -.->|届かない| iso

図11: 窓口と金庫を分離したため、lsassをダンプしても保護対象のドメイン資格情報のハッシュの実体はもうない。

Windows 11バージョン22H2以降、ライセンス要件(Enterprise E3/E5・Education A3/A5)とハードウェア要件を満たすデバイスでは、VBSとCredential Guardが既定で有効になります。ProなどのエディションではCredential Guardは自動では有効になりません(過去に対象ライセンスで有効だった端末の格下げ時など例外はあります)。⁷ 冒頭の「定石が通用しない」は、特別な追加製品の話ではなく、対象エディションの現行Windowsの標準状態です。

flowchart TB
    accTitle: サインインから認証までの資格情報の流れ
    accDescr: サインイン後、秘密の実体はVTL1のLSAIsoに保管され、認証が必要になるたびにVTL0のlsassがRPCで演算を依頼し、保護対象の長期秘密そのものは返らないまま認証処理の結果だけがVTL0へ返る
    signin["ユーザーがサインイン"] --> front["lsassが窓口として処理"]
    front --> store["秘密の実体はLSAIsoへ保管"]
    auth["その後の認証要求"] --> front
    front -->|RPCで演算を依頼| store
    store -->|処理結果を返す（秘密は返さない）| front

図12: 保護対象の長期秘密そのものは金庫から出ず、VTL0へ返るのはチケットなど認証処理の結果である。

5.2. 守られないものを正確に知る

Credential Guardは万能の盾ではありません。保護されるのは、ドメイン資格情報のNTLMハッシュ、KerberosのTGT(チケット供与チケット)、ドメイン資格情報として保存されたものです。次のようなものは対象外です。⁸

Kerberosのサービスチケット(TGTは保護される)
ローカルアカウントとMicrosoftアカウントの資格情報
キーロガーによる入力時の窃取、物理攻撃
NTLMv1・MS-CHAPv2・Digest・CredSSPを使う経路の資格情報
資格情報を独自に管理するサードパーティ製ソフトの内部

また、Credential Guard有効時はNTLMv1やKerberosの無制約委任などが使えなくなるため、レガシー認証に依存する業務システムでは互換性の確認が必要です。⁸ 「有効化して終わり」ではなく、守備範囲の内外を把握して残りを別の対策で埋める──これが実務での正しい使い方です。

flowchart TB
    accTitle: Credential Guardの守備範囲
    accDescr: ドメインのNTLMハッシュとTGT、保存されたドメイン資格情報は保護される一方、サービスチケット、ローカルアカウント、キーロガー、物理攻撃、アプリ独自保存の資格情報は保護の対象外
    scope{"その秘密は守備範囲のどちら側?"} --> inA["ドメインのNTLMハッシュ・TGT"]
    scope --> outA["サービスチケットやローカルアカウント"]
    inA --> prot["LSAIsoで保護される"]
    outA --> unprot["保護されない（別の対策が必要）"]
    unprot -.-> outB["キー入力・物理攻撃・アプリ独自保存も対象外"]

図13: 守備範囲は明確に線引きされており、線の外側は多要素認証やアプリ側の設計で埋める。

6. 自分の目で確かめる

VBSと各機能の動作状態は、手元で確認できます。

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

見方は次のとおりです。⁹

VirtualizationBasedSecurityStatusが2なら、VBSが有効かつ動作中。
SecurityServicesRunningに1が含まれればCredential Guard、2が含まれればメモリ整合性(HVCI)が動作中。

GUIで動作状態を確認するなら、msinfo32の「仮想化ベースのセキュリティ」欄を見ます(実行中のサービスとして「ハイパーバイザーによって強制されるコードの整合性」等が列挙されます)。Windowsセキュリティアプリの「デバイスセキュリティ > コア分離」にある「メモリ整合性」のトグルは設定を映す画面で、有効化直後の再起動待ちや起動時の互換性問題でHVCIが実際には動いていない間もオンに見えることがあるため、動作中かどうかの判定はmsinfo32かWin32_DeviceGuardのSecurityServicesRunningで行います。⁵

タスクマネージャーの詳細タブにも痕跡があります。VBSが動くマシンには「セキュアシステム」(Secure System)というプロセスが見えます。LsaIso.exeは分離LSAのサービスがVTL1でホストされているときに現れるプロセスで、HVCIのみ有効な構成では通常現れません。ただしプロセスの有無はあくまで痕跡なので、Credential Guardが動作しているかどうかの判定は前述のSecurityServicesRunning(1を含むか)で行います。どちらもVTL1側の世界に対応する、VTL0から見える窓です。

flowchart TB
    accTitle: VBS関連機能の動作確認の手順
    accDescr: Win32_DeviceGuardの照会でVBSの動作を確認し、SecurityServicesRunningの値からCredential GuardとHVCIの動作を判定し、ドライバー問題はCodeIntegrityログを見る流れ
    q0["Win32_DeviceGuardを照会"] --> q1{"VBSのStatusは2?"}
    q1 -->|いいえ| off["VBS未動作（要件と設定を確認）"]
    q1 -->|はい| q2{"SecurityServicesRunningの値は?"}
    q2 -->|1を含む| cg["Credential Guard動作中"]
    q2 -->|2を含む| hvciR["メモリ整合性（HVCI）動作中"]
    hvciR -.-> ev["ドライバー問題はCodeIntegrityログ（3087）を確認"]

図14: 状態確認はVBS本体、その上の各サービス、問題発生時のログの3段階で進める。

7. 実務で避けたい3つの誤読

7.1. 「管理者権限を守れば十分。VBSはサーバー向けの話」

Credential Guardが防ぐのは、管理者権限を奪われた後の被害拡大(ハッシュの持ち出しと横展開)です。つまりVBSは、侵害を前提とした多層防御の一枚であり、クライアントPCでこそ効きます。要件を満たすWindows 11では既定有効が標準なのですから、「うちには関係ない」ではなく「既に動いている前提で互換性を管理する」が正しい姿勢です。

flowchart TB
    accTitle: 侵害の段階とVBSが効く場所
    accDescr: 初期侵入は多要素認証や教育など別の対策が受け持ち、権限昇格の先にあるカーネルへのコード注入はHVCIが阻み、保護対象のドメイン秘密の窃取と横展開はCredential Guardが阻むが、保護対象外の秘密には及ばない
    s1["初期侵入（フィッシングなど）"] --> s2["権限昇格"]
    s2 --> s3["カーネルへのコード注入"]
    s3 --> s4["保護対象のドメイン秘密の窃取と横展開"]
    s1 -.-> d1["MFA・教育・EDRが受け持つ"]
    s3 -.-> d2["HVCIがここを阻む"]
    s4 -.-> d3["Credential Guardが阻む（保護対象のみ）"]

図15: VBSは「侵入させない」技術ではなく、守る段階が違う「侵入後に勝たせない」技術である。

7.2. 「メモリ整合性で問題が出たら無効にすればいい」

無効化すれば当面は動きますが、カーネルへのコード注入に対する防壁を丸ごと外すことになります。まずCodeIntegrityログでブロックされたドライバーを特定し、ベンダーの更新版を適用するのが本筋です。検証用に一時的へ無効化する場合も、恒久設定にしない運用を推奨します。

7.3. 「Credential Guardがあればパスワードは盗まれない」

守備範囲を混同した過信です。サービスチケット、ローカルアカウント、キー入力そのもの、アプリ独自保存の資格情報は対象外です。⁸ フィッシングやキーロガーには別の対策(多要素認証、Windows Hello、アプリ側の資格情報管理の見直し)が必要です。

8. まとめ

VBSはハイパーバイザーで隔離環境を作り、カーネル侵害を前提にセキュリティ機能を守ります。¹
隔離の単位はVTLで、現在はVTL0(通常世界)とVTL1(セキュアカーネルとIUM)の2レベルが実装されています。²
境界の実体はSLATのメモリアクセス保護であり、パーティション内のソフトウェア──カーネルを含む──には変更できません。²
HVCIはコード整合性検証を隔離環境で行い、「検証合格まで実行不可」「実行可能ページは書き込み不可」を強制します。⁴ 代償としてドライバー互換性の管理が必要です。⁵
Credential Guardはドメイン資格情報のNTLMハッシュとTGTをVTL1のLSAIsoへ隔離します。Windows 11 22H2以降、ライセンス要件(Enterprise・Education)とハードウェア要件を満たすデバイスでは既定で有効です(動作状態の確認とあわせて使います)。⁶⁷
動作状態はWin32_DeviceGuardのSecurityServicesRunning(1=Credential Guard、2=HVCI)で確認できます。⁹

続きは第3回「数秒で起動する仮想マシン ── WSL2・Windows Sandbox・コンテナー」です。

ここまでは仮想化を「隔離の強さ」の側から見てきました。最終回は逆に「軽さ」の側から、フルVMの重さを捨てた軽量VMたちがどこで手を抜いているのかを追います。

参考リンク

Microsoft Learn, Virtualization-based Security (VBS). VBSがハードウェア仮想化とWindowsハイパーバイザーで隔離環境を作り、カーネルが侵害され得る前提でOSの信頼の起点とすること、メモリ整合性がその隔離環境内でカーネルモードのコード整合性検証を実行すること、SLATがVBSの必須要件であることについて。 ↩ ↩² ↩³
Microsoft Learn, Virtual Secure Mode. VSMがDevice Guard・Credential Guard・仮想TPMなどの土台であること、隔離領域へのアクセスがハイパーバイザーのみを通じて制御され、リング0のOSソフトウェアからも保護されること、VTLが階層的で最大16レベル中2レベルが実装されていること、VTLごとのメモリアクセス保護はパーティション内のシステムソフトウェアから変更できないことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Isolated User Mode (IUM) Processes. VSMがHyper-VハイパーバイザーとSLATを利用してVTLを作ること、VTL1でセキュアカーネルとIUMが動くこと、トラストレットがシステムコールをVTL0のカーネルへマーシャリングすること、LSAIsoがVTL1で動きRPCでlsassと通信することについて。 ↩ ↩² ↩³
Microsoft Learn, Memory integrity and virtualization-based security. メモリ整合性(HVCI)がコード整合性検証を隔離環境で実行すること、カーネルメモリページが検証合格後にのみ実行可能となり、実行可能ページが書き込み可能にならないことについて。 ↩ ↩² ↩³
Microsoft Learn, Memory integrity and VBS enablement. Windows 11のクリーンインストールで互換ハードウェアならメモリ整合性が既定で有効になること、msinfo32やWindowsセキュリティアプリでの状態確認、CodeIntegrity運用ログのイベントID 3087でブロックされたドライバーを確認できることについて。 ↩ ↩² ↩³
Microsoft Learn, How Credential Guard works. Credential Guard有効時にLSAが分離LSAプロセス(LSAIso.exe)と通信して秘密を保管すること、保管データがVBSで保護されOSの他の部分からアクセスできないこと、分離LSAプロセスがデバイスドライバーをホストせず署名検証済みの最小限のバイナリのみを収容することについて。 ↩ ↩² ↩³
Microsoft Learn, Credential Guard overview. Windows 11バージョン22H2以降、ライセンス要件とハードウェア・ソフトウェア要件を満たし明示的に無効化されていないデバイスでCredential Guardが既定で有効になること、対応エディション/ライセンスがEnterprise(E3/E5)とEducation(A3/A5)でProは対象外なこと、およびProでも過去に対象ライセンスで有効だった端末は格下げ後も既定有効の対象になり得ることについて。 ↩ ↩²
Microsoft Learn, Credential Guard protection limits. サービスチケット・ローカルアカウント・キーロガー・物理攻撃などがCredential Guardの保護対象外であること、TGTは保護されるがサービスチケットは保護されないこと、有効時にNTLMv1や無制約委任が使えなくなることについて。 ↩ ↩² ↩³
Microsoft Learn, Enable virtualization-based protection of code integrity. Win32_DeviceGuardクラスによるVBSとメモリ整合性の状態確認方法、SecurityServicesRunningの値の意味(1がCredential Guard、2がメモリ整合性)について。 ↩ ↩²

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

VBS(仮想化ベースのセキュリティ)とコア分離は同じものですか？: 厳密には別物です。VBSはハイパーバイザーで隔離環境を作る土台の技術で、Windowsセキュリティアプリの「コア分離」は、VBSの上に成り立つ複数の保護機能をまとめた画面の名前です。その代表が「メモリ整合性」で、これはHVCI(ハイパーバイザーで保護されたコード整合性)を指します。個々のサービスの動作状態は、画面表示ではなくWin32_DeviceGuardの照会で確認します。
VTL1のメモリは、管理者権限でもカーネルドライバーでも本当に読めないのですか？: 読めません。VTLごとのメモリアクセス保護はハイパーバイザーがパーティションの物理アドレス空間に対して管理しており、パーティション内で動くソフトウェアからは変更できないためです。カーネル(リング0)で動くコードであっても、VTL0からVTL1のメモリへのアクセスは許可されません。
メモリ整合性(HVCI)を有効にするとドライバーが動かなくなることがあるのはなぜですか？: HVCI環境では、カーネルのページは整合性検証に合格して初めて実行可能になり、実行可能ページへの書き込みは許可されません。署名のないドライバーや、実行可能メモリを書き換える古い設計のドライバーはこの制約に適合できず、読み込みがブロックされます。ブロックの記録はCodeIntegrity運用ログ(イベントID 3087など)で確認できます。
Credential Guardは何を守り、何を守らないのですか？: ドメイン資格情報のNTLMパスワードハッシュ、KerberosのTGT、アプリがドメイン資格情報として保存したものを隔離環境で保護します。一方、Kerberosのサービスチケット、ローカルアカウントやMicrosoftアカウントの資格情報、キーロガーによる入力の窃取、物理攻撃は保護の対象外です。
VBSが動いているかどうかはどこで確認できますか？: msinfo32の「仮想化ベースのセキュリティ」欄、またはPowerShellでroot/Microsoft/Windows/DeviceGuard名前空間のWin32_DeviceGuardクラスを照会します。SecurityServicesRunningに1が含まれればCredential Guard、2が含まれればメモリ整合性(HVCI)が動作中です。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る

Windows仮想化の深層(第2回) ── カーネルからも見えないメモリ:VBS・HVCI・Credential Guardの仕組み

1. まず結論

この記事の知識マップ

2. リングモデルの限界 ── 守る側と守られる側が同じ高さにいる

3. VSMとVTL ── 特権にもう1本の軸を足す

3.1. 仮想信頼レベル(VTL)

3.2. 境界の実体はSLAT

3.3. セキュアカーネルとIUM

4. HVCI ── カーネルのコード整合性を金庫室で検証する

4.1. 何を検証しているのか

4.2. 実行可能ページのルール

4.3. ドライバー互換性という代償

5. Credential Guard ── ハッシュはLSAIsoの中

5.1. LSASSとLSAIso

5.2. 守られないものを正確に知る

6. 自分の目で確かめる

7. 実務で避けたい3つの誤読

7.1. 「管理者権限を守れば十分。VBSはサーバー向けの話」

7.2. 「メモリ整合性で問題が出たら無効にすればいい」

7.3. 「Credential Guardがあればパスワードは盗まれない」

8. まとめ

関連記事

関連する相談領域

参考リンク

Windows仮想化の深層(第3回) ── 数秒で起動する仮想マシン:WSL2・Windows Sandbox・コンテナーの軽さの正体

Windows仮想化の深層(第1回) ── あなたのWindowsはどこで動いているのか:ハイパーバイザーとパーティション

名前付きパイプの実務 ── Windowsプロセス間通信の定番を設計からセキュリティまで

Windowsサービスのアカウント選定 ── LocalSystem・仮想アカウント・gMSAの使い分け

Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる

関連トピック

Windows技術トピック

このテーマがつながるサービス

Windowsアプリ開発

よくある質問

著者プロフィール

小村豪

1. まず結論

この記事の知識マップ

2. リングモデルの限界 ── 守る側と守られる側が同じ高さにいる

3. VSMとVTL ── 特権にもう1本の軸を足す

3.1. 仮想信頼レベル(VTL)

3.2. 境界の実体はSLAT

3.3. セキュアカーネルとIUM

4. HVCI ── カーネルのコード整合性を金庫室で検証する

4.1. 何を検証しているのか

4.2. 実行可能ページのルール

4.3. ドライバー互換性という代償

5. Credential Guard ── ハッシュはLSAIsoの中

5.1. LSASSとLSAIso

5.2. 守られないものを正確に知る

6. 自分の目で確かめる

7. 実務で避けたい3つの誤読

7.1. 「管理者権限を守れば十分。VBSはサーバー向けの話」

7.2. 「メモリ整合性で問題が出たら無効にすればいい」

7.3. 「Credential Guardがあればパスワードは盗まれない」

8. まとめ

関連記事

関連する相談領域

参考リンク

関連する記事

Windows仮想化の深層(第3回) ── 数秒で起動する仮想マシン:WSL2・Windows Sandbox・コンテナーの軽さの正体

Windows仮想化の深層(第1回) ── あなたのWindowsはどこで動いているのか:ハイパーバイザーとパーティション

名前付きパイプの実務 ── Windowsプロセス間通信の定番を設計からセキュリティまで

Windowsサービスのアカウント選定 ── LocalSystem・仮想アカウント・gMSAの使い分け

Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる

関連トピック

Windows技術トピック

このテーマがつながるサービス

Windowsアプリ開発

よくある質問

著者プロフィール

小村 豪

小村豪