「LSA（ローカル セキュリティ機関）保護」をオンにしたいけれど、CPU仮想化（Intel VT‑x / AMD‑V）をオフにしている・コア分離がオフのまま…という状態だと、「本当に守られているの？」「設定がおかしくない？」と不安になります。本記事では、LSA保護と仮想化、コア分離（メモリ整合性）やCredential Guardとの関係を整理し、安心して運用するための考え方とチェック方法を詳しく解説します。
LSA保護とは？LSASSとPPLの基本を押さえる
まず前提として、LSA保護が守っている対象である「LSASS」と、その動作モードである「PPL」について整理しておきます。
LSASS（Local Security Authority Subsystem Service） は、Windowsがユーザー認証やトークン発行、パスワード変更、Kerberos/NTLMなどの認証関連処理を行う中核プロセスです。ここには、ハッシュ化されたパスワードやチケットなど、攻撃者にとって非常に価値の高い情報が一時的に保持されます。
LSA保護 を有効にすると、この lsass.exe は Protected Process Light（PPL） として動作するようになります。PPLは、Windowsが用意している特別な保護プロセスモードであり、管理者権限のプロセスであっても、正当な署名を持たないコードからはLSASSのメモリ読み取りやコード注入をブロックできるのが特徴です。
この結果、代表的な資格情報窃取ツール（mimikatzなど）は、PPL化されたLSASSへのアクセスが「Access Denied」となり、簡単にはダンプできなくなります。
重要なのは、このPPLという仕組み自体は「カーネルと署名検証」による保護であり、VBS（仮想化ベースのセキュリティ）やハイパーバイザーを必須とはしていないという点です。後述するCredential Guardとは、守る対象が似ていても、実現手段のレイヤーが異なります。
結論：LSA保護の有効化にCPU仮想化は不要
この記事の核心となるポイントは次の一文に集約できます。
LSA保護（RunAsPPL）を有効にするのに、CPU仮想化（Intel VT‑x / AMD‑V）は 必要ありません。
Microsoftのコミュニティ回答でも「LSA protection does not require CPU virtualization to be enabled」と明示されており、LSASSをPPLとして保護する機能は、VBSとは別に動作することが確認されています。
したがって、次のような状況は仕様として正しい動作です。
- BIOS/UEFIでIntel VT‑x / AMD‑V / SVMを無効にしている
- 「コア分離」や「メモリ整合性」がオフのまま
- それでも「Windows セキュリティ」上では LSA保護がオン と表示されている
この状態は「LSA保護だけ有効・VBS系機能は無効」という構成であり、コア分離やCredential Guardがオフだからといって、LSA保護が壊れているとは限りません。
LSA保護とVBS系機能の違いを整理する
よく混同されるのが、次の3つの機能です。
- LSA保護（RunAsPPL）
- コア分離（メモリ整合性 / HVCI）
- Windows Defender Credential Guard
これらの違いをざっくり表にすると、以下のようになります。
| 機能 | 主な目的 | CPU仮想化の要否 | 設定場所の例 |
|---|---|---|---|
| LSA保護（RunAsPPL） | LSASSをPPLとして保護し、コード注入やメモリダンプを困難にする | 不要 | Windows セキュリティ「アカウントの保護」 / レジストリ（RunAsPPL） |
| コア分離（メモリ整合性 / HVCI） | カーネル・ドライバのコード整合性をVBSで強化する | 必要 （VT‑x / AMD‑V有効が前提） | Windows セキュリティ「デバイス セキュリティ > コア分離の詳細」 |
| Windows Defender Credential Guard | LSASSの認証情報をVBS上の隔離コンテナに保管し窃取を防止 | 必要 （VBS / ハイパーバイザーが前提） | グループポリシー / レジストリ / Intune 等 |
このように、LSA保護だけは「VBSを使わないOSレベルの保護」であり、コア分離・Credential Guardは「Hyper‑VベースのVBSを使う保護」だと理解しておくと混乱しにくくなります。
「コア分離がオフ＋LSA保護オン」はおかしくない
質問として多いのが、「CPU仮想化をオフにしているのにLSA保護だけオンになっている。コア分離まわりが壊れているのでは？」という不安です。
結論から言えば、その組み合わせ自体はまったく問題ありません。LSA保護はPPL機能を使うだけなので、VBSが無効でも動きます。一方、コア分離やCredential GuardはVBSを前提とした防御なので、CPU仮想化が無効であればそもそも使えません。
イメージとしては、次のような二段構えです。
- 第1段階：LSA保護
LSASSをPPL化し、「ユーザーモードからの素直なダンプ」を困難にする。 - 第2段階：Credential GuardなどVBS系機能
そもそも認証情報をVBS側に隔離し、OS側から直接触れないようにする。
第2段階を使いたい場合はCPU仮想化が必須ですが、第1段階だけであれば仮想化は不要、というわけです。
LSA保護が本当に効いているか確認する方法
ここからは、実際に「LSA保護が有効かどうか」を目で確認する手順を紹介します。レジストリの編集はリスクがあるため、基本的にはGUIと読み取りのみで確認するのがおすすめです。
Windows セキュリティから確認する
家庭用PCや通常のクライアント環境であれば、もっとも簡単な確認方法は「Windows セキュリティ」アプリです。
- [スタート] メニューから 「Windows セキュリティ」 を開く
- 左メニューまたはタイルから 「アカウントの保護」 を選択
- 「ローカル セキュリティ機関（LSA）保護」またはそれに相当する項目が 「オン」 または「この機能は有効です」のような表示になっていることを確認
Windows 11のビルドや更新状況によって表現が変わることがありますが、概ね「有効」「オン」といったステータスであれば、LSA保護は動作していると考えて問題ありません。
レジストリでRunAsPPLの値を確認する（読み取りのみ推奨）
より技術的に確認したい場合は、レジストリの該当キーを読み取ります。
- キー：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - 値名：
RunAsPPL（DWORD）
一般的に、RunAsPPL の値が 1 またはそれ以上の特定値であれば、LSASSがPPLとして動作するよう構成されています。
とはいえ、レジストリの誤編集は起動不能を含む重大なトラブルの原因になります。業務環境では必ずバックアップを取得し、可能な限り「GUIでの有効化＋監査ログ」で状態を把握することをおすすめします。
プロセスの保護レベルを確認する（上級者向け）
上級者であれば、Process Explorerなどのツールを用いて lsass.exe の保護レベルを確認することもできます。プロセスの属性として「Protected（PPL）」が表示されていれば、LSA保護が有効です。
また、LSA保護を有効化した際にはイベントログに記録されるため、セキュリティログやシステムログを監査することで、設定変更の履歴を追跡することも可能です。
仮想化を使う「コア分離」や「Credential Guard」も併用したい場合
LSA保護だけでも、攻撃者の難易度は大きく上がります。しかし、ゼロトラストや特権端末（PAW）などを真剣に設計するのであれば、VBSを使った防御も視野に入れるべきです。
ここでは、「LSA保護はすでにオンにした。さらにコア分離やCredential Guardも使いたい」というケースを想定し、ざっくりとした手順をまとめます。
BIOS/UEFIでCPU仮想化を有効にする
まず、マシンのファームウェア設定（BIOS/UEFI）で以下のような項目を有効化します。
- Intel CPUの場合：Intel Virtualization Technology（VT‑x） など
- AMD CPUの場合：SVM Mode / AMD‑V など
設定名称はマザーボードによって異なりますが、「Virtualization」「SVM」「VT‑x」といったキーワードが含まれていることが多いです。設定を有効にしたら保存して再起動します。
なお、仮想化を有効にすると、Hyper‑VやAndroidエミュレータ、WSL2などが使えるようになる一方で、一部の古い仮想化ソフトウェアやアンチチート機構を持つゲームと競合する場合もあるため、用途に合わせて判断が必要です。
Windows セキュリティでコア分離（メモリ整合性）をオンにする
CPU仮想化が有効であれば、Windows セキュリティからコア分離をオンにできます。
- 「Windows セキュリティ」を開く
- 「デバイス セキュリティ」 > 「コア分離の詳細」 をクリック
- 「メモリ整合性（Memory Integrity）」 をオンにする
- 再起動する
このメモリ整合性（HVCI）は、カーネルモードのコード整合性チェックをVBS上で行うことで、「怪しいドライバ」による攻撃を防ぐ役割を持ちます。
Credential Guardを利用する（企業向け）
Enterprise環境などでは、さらに一歩進んで Windows Defender Credential Guard を有効にすることも多いです。Credential Guardは、LSASSの認証情報をVBS上の隔離空間に格納し、OS側から直接メモリを参照できないようにすることで、パスザハッシュなどの横展開攻撃を強力に防ぎます。
この構成では、LSA保護（PPL）とCredential Guard（VBS隔離）の二重防御となり、LSASSのクレデンシャル窃取対策としては非常に強固な状態になります。
コア分離がオンにならない・消えてしまう場合の考え方
「仮想化を有効にしたのに、コア分離のメモリ整合性がオンにできない」「そもそも項目が表示されない」といったトラブルもよくあります。その多くは、次のような原因によるものです。
- 古いまたは互換性のないドライバがインストールされている（署名やHVCI非対応）
- 別のハイパーバイザー（古いVirtualBoxなど）やアンチチートドライバがVBSと競合している
- グループポリシーやレジストリで、VBS関連機能が明示的に無効化されている
このような場合は、まず デバイス マネージャーや「システム情報」 でドライバの状態や「仮想化ベースのセキュリティ」の有効/無効を確認し、問題のあるドライバがないかチェックします。また、企業環境ではIntuneやグループポリシーでVBSが制御されている可能性もあるため、ポリシー設定の確認も必要です。
なお、コア分離がうまくオンにできないからといって、LSA保護まで壊れているとは限りません。LSA保護はあくまで別枠の保護機能なので、前述の方法で個別に状態を確認してください。
LSA保護をめぐる「よくある誤解」
最後に、LSA保護とCPU仮想化、コア分離に関して、よくある誤解を整理しておきます。
誤解1：「LSA保護＝VBSなので仮想化必須」
実際には、LSA保護（RunAsPPL）はVBSとは別に実装された保護機構です。PPLは署名付きコードとカーネルレベルの制御で保護を実現しており、仮想化は要件ではありません。
「VBSを使ったLSASS保護」が欲しい場合は、Credential Guard側の話になります。
誤解2：「コア分離がオフならセキュリティ的に危険」
コア分離（メモリ整合性）は確かに強力な機能ですが、用途によってはあえてオフにしているケースもあります。例えば、古い業務アプリケーションが未署名ドライバに依存している場合や、別の仮想化ソフトウェアと競合するケースなどです。
そのような環境でも、まずはLSA保護をオンにしておくだけで、クレデンシャル窃取攻撃への耐性は大きく向上します。VBS系の機能は「使える範囲で段階的に導入する」というスタンスでも構いません。
誤解3：「LSA保護さえオンならLSASSは完全に無敵」
LSA保護は強力ですが、万能ではありません。カーネルモードの脆弱性を突いた攻撃や、悪意あるドライバのロードによって、PPL保護を迂回するテクニックも研究されています。
そのため、以下のような多層防御と組み合わせてこそ効果を最大化できます。
- 不要なドライバや古いソフトウェアの削除・更新
- 管理者権限の最小化（ローカル管理者の削減）
- アプリケーション制御（WDAC / AppLockerなど）
- 端末のハードニング（不要なサービスや機能の無効化）
実運用でのおすすめ構成と考え方
ここまでの内容を踏まえ、代表的なシナリオ別に「現実的にねらいやすい構成」をまとめます。
個人利用PC・ゲーミングPCなど
- CPU仮想化：用途に応じてオン/オフ（ゲームや一部ツールとの兼ね合い）
- LSA保護：できるだけオンにする（必須級）
- コア分離（メモリ整合性）：性能や互換性に問題がなければオンにする
- Credential Guard：通常は不要（Enterpriseエディションや高度な要件がある環境を除く）
CPU仮想化をオフのままでも、LSA保護がオンであれば「LSASSダンプ防止」という観点では大きなメリットがあります。
小規模オフィス・中小企業環境
- LSA保護：全端末でオン
- CPU仮想化：原則オン（Hyper‑VやWSL2も活用）
- コア分離（メモリ整合性）：検証環境でアプリ互換を確認のうえ段階的に導入
- Credential Guard：特権アカウントを扱う端末から優先的に導入
特にドメイン管理者やサーバー管理者がログオンする端末では、Credential GuardやPAW（Privileged Access Workstation）などと組み合わせて、LSASS関連のリスクを極力減らすことが重要です。
大規模エンタープライズ・ゼロトラスト指向の環境
- LSA保護＋Credential Guardを標準構成とする
- CPU仮想化・VBS・コア分離を前提とした端末基準（セキュアコアPCなど）の採用
- Intuneやグループポリシーで一元管理し、「監査モード→本番適用」の二段階ロールアウト
- LSASS関連のログとEDRを組み合わせた監視・検知
このレベルになると、「LSA保護が有効かどうか」だけでなく、「どのポリシーで・どのOU/デバイスグループに適用されているか」「例外端末がどこにあるか」まで把握することが求められます。
まとめ：LSA保護は仮想化なしでも心強い一枚盾
最後に、本記事の要点を整理します。
- LSA保護は、LSASSをPPLとして実行し、資格情報ダンプやコードインジェクションを困難にする機能です。
- LSA保護の有効化にCPU仮想化（Intel VT‑x / AMD‑V）は不要であり、「仮想化オフ＋LSA保護オン」という構成は正常です。
- 一方で、コア分離（メモリ整合性）やCredential GuardはVBS（ハイパーバイザー）を前提とした別カテゴリの防御であり、これらを使うにはCPU仮想化が必要です。
- コア分離がオフであっても、それだけで「LSA保護が壊れている」とは限りません。LSA保護の状態は Windows セキュリティ やレジストリ値で個別に確認できます。
- 可能であれば、LSA保護をベースラインとし、環境に応じてコア分離・Credential Guard・アプリケーション制御などを段階的に組み合わせることで、LSASS関連のリスクを大きく減らせます。
「LSA保護は仮想化なしでも正しく有効化できる」という前提を押さえておけば、コア分離やVBSの挙動に振り回されることなく、落ち着いて自分の環境に最適なセキュリティ構成を設計できるはずです。まずは、今使っているPCでLSA保護がオンになっているかどうかを確認し、そのうえで必要に応じてVBS系の機能を追加していきましょう。
コメント