境界防御の終焉と「実行の完全制御」：AppLockerが示すセキュリティの真髄
現代のセキュリティにおいて、ペリメータ（境界）はもはや存在しないに等しい。VPNゲートウェイやファイアウォールを突破した攻撃者は、エンドポイントのメモリ空間を蹂躙し、永続化（Persistence）を狙う。この泥沼の戦場において、我々アーキテクトが唯一信頼できる聖域は「何が実行を許可されるか」という極めて単純かつ強固なルールセットだ。
本稿では、公開鍵暗号による署名の整合性を起点とした、Windows AppLockerによる実行制御の深層を解剖する。
—
署名済みバイナリの背後にある信頼の暗号学
AppLockerのホワイトリスト運用において、肝となるのは「デジタル署名の検証」だ。ここで使われるRSAや楕円曲線暗号（ECC）は、単なる暗号化技術ではない。バイナリのハッシュ値が改ざんされていないこと、そして発行元が信頼できる認証局（CA）と結びついていることを証明する「身元証明」である。
しかし、攻撃者はこのロジックの隙を突く。例えば、信頼された署名を持つバイナリを悪用する「Living off the Land (LotL) バイナリ」攻撃だ。特定の正規ツールが持つ「スクリプト実行機能」や「外部DLL読み込み機能」を悪用すれば、AppLockerのホワイトリストをすり抜けて任意のコードを実行できる。
攻撃者が狙う「盲点」
1. DLL Hijacking: 署名済みアプリが、特定パスから悪意あるDLLをロードするように誘導する。
2. スクリプト・インタプリタの悪用: powershell.exe や wscript.exe へのアクセスを制限していても、署名された別の管理ツールが内部的に実行エンジンを呼び出すケース。
—
AppLocker：静的なルールから動的な防御へ
AppLockerの真価は、単なるexeの実行制限ではなく、「Publisher（発行元）」単位での厳密な信頼モデルの構築にある。
以下は、PowerShellを用いたPublisherルールの定義例だ。これは、特定のベンダー（Microsoft等）の署名以外を一切認めないという、堅牢なベースラインを構築する。
# Microsoftが署名したバイナリのみを実行許可するルールの定義
# 'Publisher' ルールは、証明書の階層と製品名を統合して検証する
New-AppLockerPolicy -RuleType Publisher -User Everyone -Action Allow -PublisherName "O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" -ProductName "WINDOWS OPERATING SYSTEM" -FilePath "*" -Description "Microsoft署名済みバイナリの許可"現場で陥る「設定の罠」
多くの現場で失敗するのは、「デフォルトルールの安易な継承」だ。C:\Windows 配下をすべて許可する設定は、書き込み権限のあるサブディレクトリ（例えば C:\Windows\Tasks や C:\Windows\Temp）を介したバイナリ配置攻撃に対して脆弱である。
鉄則：
- パスベースのルールではなく、必ず Publisherルール を優先せよ。
System32内であっても、不要なバイナリの実行はブロックする（必要最小限の特権）。
—
耐量子暗号（PQC）を見据えたアーキテクチャ設計
現在、RSAやECCをベースとした署名検証は、将来的な量子コンピュータの脅威（Shorのアルゴリズム）に直面している。AppLockerの運用においても、将来を見据えた「署名の更新性」を考慮しなければならない。
現在のホワイトリスト運用を将来の耐量子時代へ橋渡しするには、以下の戦略が不可欠だ。
1. 暗号アジリティ（Crypto-Agility）: 署名アルゴリズムをハードコードせず、証明書チェーンの更新だけで最新の署名スキームに対応できる運用体制を整えること。
2. メモリ保護の強化: AppLockerがコードの実行を許可した後、攻撃者はメモリ内にコードを注入する。これを防ぐためには、Code Integrity (CI) ポリシーと連動させ、署名のないメモリ領域の実行をカーネルレベルで遮断する「HVCI (Hypervisor-Protected Code Integrity)」が必須となる。
—
監査とインシデントハンドリング：泥臭い現実
最高峰の防御とは、「攻撃を防ぐこと」ではなく、「攻撃者が動いた瞬間にアラートが上がり、コンテキストを即座に特定できること」だ。
AppLockerのログ（Microsoft-Windows-AppLocker/EXE and DLL）をSIEMに流し込み、以下の事象を監視せよ。
- Event ID 8004: ルールによってブロックされた実行試行。これが頻発する場合、それは攻撃者の探索行動（Reconnaissance）である可能性が高い。
- Event ID 8002: 許可されたが、不審なパスから実行されたバイナリ。
もし読者がテックリードであれば、開発環境から本番環境まで、このルールをCI/CDパイプラインに組み込むことを推奨する。「設定変更」をインフラ構成管理（TerraformやAnsible）に含め、手動変更を排除すること。人間が手で触れるセキュリティ設定は、いずれ必ず形骸化する。
最後に
セキュリティとは、テクノロジーと人間の執念のせめぎ合いだ。どれほど強固なアルゴリズムを用いようとも、それを運用する人間が「利便性」のためにバックドアを作れば、すべては水泡に帰す。
AppLockerは単なるツールではない。組織の「実行可能なロジック」を定義する、強固な憲法である。この憲法をいかに厳格に守り抜くか。それが、我々エンジニアに課せられた、終わりのない戦いなのだ。
コメント