境界防御の終焉と、WDACがもたらす「カーネルレベルの拒絶」
かつて我々は「ファイアウォール」という名の城壁に安寧を求めた。しかし、現代の脅威アクターは、パケットヘッダの微細な正規化の差異を突き、プロトコルスタックの実装欠陥を突いてくる。境界防御はもはや「遅延装置」でしかない。
特に、攻撃者が最終到達点として狙うのは、OSの心臓部であるカーネルだ。メモリ保護違反（CVE-2024-XXXX等のエクスプロイト）を突いて任意のコードを実行し、特権を昇格させる。この「実行の自由」を封じ込めない限り、どんな強固なパスワードポリシーも無意味だ。ここで語るべきは、AppLockerという過去の遺物から脱却し、Windows Defender Application Control (WDAC) を用いてカーネルレベルで「許可なき者は存在させない」という鉄の規律を敷くことだ。
AppLockerとWDACの決定的な「断絶」
現場のエンジニアが陥りやすい罠がある。AppLockerはユーザーモードのフックに過ぎない。攻撃者がカーネルのメモリ空間を直接操作するような高度なエクスプロイトに対しては、無力だ。
一方、WDACはコードインテグリティ（CI）ポリシーをカーネルレベルのメモリ管理と密接に統合する。これは単なる「許可リスト」ではない。OSが実行ファイルをメモリにロードしようとした瞬間、その署名とポリシーをカーネルが直接評価し、検証が通らなければ、そのコードをメモリ空間にマッピングすることすら許さない。
WDACポリシー設計の勘所：信頼の連鎖をどう定義するか
WDACの導入で最も泥臭い作業は、「何をもって信頼とするか」の定義だ。単純なファイルハッシュは、更新のたびにポリシーを書き換える地獄を招く。我々が推奨するのは、Publisher（発行元）とFilePublisher（発行元＋ファイル名）、そしてWHQL（Windowsハードウェア品質ラボ）署名の組み合わせによる階層的な信頼の構築だ。
以下は、信頼された発行元のみを許可する最小構成のポリシー定義（XML）の一部である。
<!-- WDACポリシーの断片：署名者ベースの信頼設定 -->
<Signer ID="AutoGeneratedSigner" Name="Microsoft Corporation">
<CertRoot Type="WellKnown" Value="MicrosoftWindowsProductionPCA"/>
<CertPublisher Value="Microsoft Corporation"/>
<!-- Microsoftの署名のみを信頼する（攻撃者のバイパスを防ぐ） -->
</Signer>
<FileRule ID="ID_ALLOW_MS_SIGNED" Name="Allow Microsoft Signed" SignerId="AutoGeneratedSigner" Action="Allow"/>アーキテクチャ設計：カーネル保護を突破させないための多層防御
WDACを導入しても、構成の不備を突かれるケースはある。特に、ポリシーファイルそのものを改ざんする権限を持たせないことが肝要だ。
1. ポリシーの署名（Policy Signing）： ポリシーファイルをバイナリ形式に変換し、それをデジタル署名で保護する。これにより、たとえローカル管理者であっても、ポリシーを書き換えてバックドアを仕込むことが不可能になる。
2. ハイパーバイザー保護コードインテグリティ (HVCI) の併用： WDACとHVCIを組み合わせることで、カーネルモードのメモリページをW^X（Write XOR Execute）に保つ。これは、コードが書き込み可能なら実行不可、実行可能なら書き込み不可という、メモリ破壊系脆弱性に対する最強の防壁だ。
実践：ポリシーのデプロイと監査モードの活用
いきなり「強制モード（Enforcement Mode）」で導入すれば、業務は即座に停止する。まずは「監査モード（Audit Mode）」でログを収集し、何が実行され、何がブロックされるべきかを徹底的に分析する必要がある。
# 監査モードでポリシーを適用する際の手順（管理者権限が必要）
$PolicyPath = "C:\WDAC\MyPolicy.xml"
$BinaryPath = "C:\WDAC\MyPolicy.bin"
# XMLをバイナリに変換
ConvertFrom-CIPolicy -XmlFilePath $PolicyPath -BinaryFilePath $BinaryPath
# 監査モードとして強制適用（再起動後に有効化）
Set-CIPolicy -FilePath $BinaryPath -Level FilePublisher -Auditこのログは、Event ViewerのApplications and Services Logs > Microsoft > Windows > CodeIntegrityに記録される。ここでEvent ID 3077（カーネルモードのブロック）や3076（監査モードでのブロックイベント）を監視するSIEMアラートを構築することこそ、チーフホワイトハッカーとしての務めだ。
結び：防御は「信頼の静的分析」から始まる
耐量子暗号化が進む今後の世界においても、攻撃の「入り口」を制限する概念は変わらない。AIが生成するプロンプトインジェクションや高度なファイルレス攻撃も、最終的にはOSレベルのAPIを叩き、メモリ空間を確保しようとする。
WDACによる制御は、いわば「OSに対する厳格な身元調査」だ。信頼できないコードに１バイトのメモリも与えない。この執拗なまでの拒絶こそが、侵害されたシステムから「完全な陥落」を防ぐ最後の防波堤になる。
技術は日々進化するが、防御の核となるのは常に「誰を信頼し、何を実行させるか」という単純かつ過酷な問いに対する答えだ。君たちの環境で、今この瞬間に実行されているプロセスは、本当に信頼できるものか？ その問いに胸を張って答えられるようになるまで、ポリシーのチューニングを止めてはならない。
コメント