実行許可リストの深淵：AppLockerによる「信頼の境界線」の再定義
現場で数々のインシデントハンドリングを行ってきた私が断言できるのは、今日の標的型攻撃やランサムウェアにおいて、シグネチャベースの「検知」はもはや敗北を認めるための儀式に過ぎないということです。攻撃者は、Living-off-the-Land（自給自足型攻撃）を駆使し、OS標準のバイナリ（LOLBins）を悪用して検知の網をすり抜けます。
ここで我々が立ち返るべきは、「何が悪いか」を定義するブラックリストではなく、「何が正しいか」を定義するホワイトリスト（実行許可リスト）の設計です。Windows ServerにおけるAppLockerは、単なる管理ツールではありません。それは、プロセスの生成プロセスそのものに介入し、OSの実行空間を「信頼の聖域」へと変貌させるための、最後にして最強の防衛線です。
—
1. AppLockerのメカニズム：カーネルレベルでの実行阻止
AppLockerの本質を理解するには、Windowsのプロセス生成シーケンスに踏み込む必要があります。AppLockerはユーザーモードの単なる監視ソフトではなく、AppId.sys というカーネルモードドライバを中核として動作します。
プロセスが起動しようとする際、カーネルは CreateProcess 呼び出しをインターセプトし、Application Identity サービスを通じて、実行ファイルが定義されたポリシーに適合するかを照合します。ここで重要なのは、ハッシュ値、パス、あるいはデジタル署名のいずれかで検証が行われる点です。
特に、メモリ空間を汚染する「ファイルレス攻撃」や、ntdll.dll を直接叩くような低レイヤの攻撃に対抗するためには、単なる .exe の制限だけでは不十分です。DLL（動的リンクライブラリ）の読み込み制限まで踏み込む必要があります。
—
2. 戦略的なポリシー設計：運用性と堅牢性のトレードオフ
AppLockerの導入で多くのテックリードが陥る罠は、厳格すぎるパスルールによる運用の破綻です。プロフェッショナルなアーキテクトであれば、以下の3つの階層でルールを設計すべきです。
A. 出版者（Publisher）ルール：信頼の基盤
可能な限り、デジタル署名に基づいたルールを採用します。これにより、バージョンアップのたびにハッシュ値を更新する手間が省けます。
- 対象: Microsoft純正バイナリ、セキュリティ製品、社内標準ツール
- 利点: ファイルパスの変更やマイナーアップデートに強い。
B. パス（Path）ルール：限定的な例外
署名のない古いレガシーアプリや、特定のディレクトリでのみ動作を許可する場合に使用します。
- 注意点:
C:\Windows\TempやC:\Users\...\AppDataのような、ユーザー権限で書き込み可能な場所を許可してはなりません。これは攻撃者に「どうぞここから実行してください」と言っているようなものです。
C. ファイルハッシュ（File Hash）ルール：最終手段
署名がなく、かつパスが固定できない場合にのみ使用します。
- 欠点: 1バイトでもバイナリが変われば実行不能になるため、保守コストが極めて高い。
—
3. 実践：PowerShellによるAppLockerポリシーの生成と適用
GUIでの操作はミスを誘発します。CI/CDパイプラインや構成管理に組み込むため、PowerShellを用いた宣言的な管理が不可欠です。以下に、標準的なサーバーOSの要塞化に向けたベースラインポリシーの生成例を示します。
# AppLockerモジュールのインポート
Import-Module AppLocker
# 1. 現在のシステム状態（クリーンインストール直後が理想）から一時的なポリシーを生成
# -Optimize を指定することで、重複するパスルールを統合する
Get-AppLockerFileInformation -Directory "C:\Windows", "C:\Program Files" -Recurse |
New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize > C:\Temp\BaselinePolicy.xml
# 2. DLLルールの有効化（これを忘れるとDLLサイドローディング攻撃を防げない）
# ※注意：DLLルールの有効化はシステムパフォーマンスに影響を与えるため、事前テストが必須
$policy = Get-Content C:\Temp\BaselinePolicy.xml
# XML内でDLLの強制モードを書き換えるロジックをここに挟む（手動またはスクリプト）
# 3. ポリシーのインポートと強制適用（まずは AuditOnly で様子を見るのが鉄則）
Set-AppLockerPolicy -XmlPolicy C:\Temp\BaselinePolicy.xml -Merge—
4. 攻撃者の視点：AppLocker Bypassをどう封じ込めるか
ホワイトハッカーとして警告しておかなければならないのは、AppLockerは「設定して終わり」ではないということです。攻撃者は、AppLockerのデフォルトルール（C:\Windows\* を許可する設定など）を悪用します。
LOLBinsの悪用（mshta.exe, regsvr32.exe）
例えば、regsvr32.exe はMicrosoftの署名があるため、デフォルトの「出版者ルール」では実行が許可されています。しかし、攻撃者はこれを使ってリモートから悪意のあるスクリプト（.sct）を読み込ませ、メモリ上でコードを実行します。
対策:
AppLockerのポリシー内で、これらの「危険な標準バイナリ」を明示的に拒否（Deny）するか、あるいはWDAC（Windows Defender Application Control）と併用して、スクリプトホストの実行権限を厳格に管理するアーキテクチャが必要です。
—
5. 監査と継続的モニタリング：SIEMへの統合
AppLockerを導入して最も価値があるのは、実は「ブロックした瞬間」のログです。これは侵害の予兆（IoC）そのものです。
Windowsイベントログの Applications and Services Logs\Microsoft\Windows\AppLocker を監視し、以下のイベントIDをSIEM（Splunk, Azure Sentinel等）でリアルタイムアラートに設定してください。
- Event ID 8004: 実行がブロックされた（強制モード時）
- Event ID 8003: 実行が許可されたが、監査モードであればブロックされていた（導入フェーズで重要）
// SIEM側での検知ロジック例 (KQL - Azure Sentinel)
AppLockerEvent
| where EventID == 8004
| extend BlockedProcess = tostring(parse_xml(EventData).UserData.RuleAndFileLabels.FilePath)
| summarize count() by BlockedProcess, Computer, User
| order by count_ desc—
結論：アイデンティティとしてのバイナリ管理
AppLockerによる実行許可リストの管理は、単なる「制限」ではなく、システムの「アイデンティティ」を定義する作業です。どのバイナリが動くべきで、どの通信が許されるのか。その境界を曖昧にしたまま、AIや耐量子暗号を語ることは砂上の楼閣に過ぎません。
インフラ・ネットワークのテックリードには、OSの深層部で何が起きているかを常に凝視し、攻撃者が利用する「信頼の隙間」を一つずつ埋めていく、泥臭くも崇高なエンジニアリングを期待します。次世代の防御層は、常にこの「許可されたもの以外は存在しない」というゼロトラストの原則から始まります。
コメント