侵入されても「何も動かせない」最強の要塞：AppLockerによるアプリケーション制御の真髄
インシデント対応の現場に立つと、いつも思うことがある。「なぜ、サーバー上で誰も使わないはずのツールが動いているんだ？」と。
攻撃者は、OS標準のコマンドや、ユーザーがうっかり実行してしまったダウンロードファイルを足掛かりに、横展開（ラテラルムーブメント）を図ります。アンチウイルスソフトをすり抜けるランサムウェアや、高度な標的型攻撃の多くは、最終的に「サーバー上で悪意あるバイナリを実行する」というステップを踏む。この出口を物理的に塞ぐのが、Windows Serverにおける AppLocker です。
今回は、教科書的な説明は抜きにして、「現場でどう設計し、どう管理するか」という泥臭いエンジニアリングの核心に迫ります。
—
1. なぜ「許可リスト」が必要なのか：攻撃者の視点
攻撃者は、あなたが「許可した覚えのないもの」を動かす天才です。
例えば、攻撃者がよく使う手口として Living off the Land (LotL) があります。powershell.exe や certutil.exe 、さらには mshta.exe といった、Windowsに標準搭載されている正規ツールを悪用する手法です。これらはアンチウイルスソフトの検知を回避しやすく、非常に厄介です。
AppLockerは、これら「実行可能なもの」のリストを厳格に定義することで、たとえ攻撃者がマルウェアをサーバー上にアップロードしても、実行権限がないためただのゴミデータになるという状態を作ります。
—
2. 実践：AppLockerポリシーの設計と実装
AppLockerには「ハッシュ値」「パス」「パブリッシャー（署名）」という3つのルールがありますが、運用負荷とセキュリティのバランスを考えると、「パブリッシャー（署名）」をベースにしつつ、特定のパスを例外とするのが最も現実的です。
設定の勘所：監査モードから始める
いきなり「強制モード」で有効化すると、翌朝の会議室は阿鼻叫喚になります。まずは「監査モード」でログを収集し、何が動いているかを正確に把握してください。
# 管理者権限のPowerShellでAppLockerの実行ポリシーを確認
Get-AppLockerPolicy -Local -Xml | Out-File C:\temp\CurrentPolicy.xml
# 監査モードの設定（強制はせず、ログだけ取る）
Set-AppLockerPolicy -XmlPolicy C:\temp\CurrentPolicy.xml -Merge推奨のポリシー設定（XMLエクスポート例）
すべてのバイナリを禁止し、必要な署名のみを通すための設定指針です。以下は、Microsoftの署名済みバイナリと、特定の管理用ディレクトリのみを許可する概念的なXML構造の一部です。
<!-- AppLocker ポリシーの定義抜粋 -->
<RuleCollection Type="Exe" EnforcementMode="Enabled">
<!-- デフォルトルール：Windows配下は許可（署名検証） -->
<FilePathRule Id="... " Name="Windows系実行ファイル" Action="Allow" UserOrGroupSid="S-1-1-0">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\Windows\*" />
</Conditions>
</FilePathRule>
<!-- 開発者が配置するアプリのディレクトリを許可 -->
<FilePathRule Id="... " Name="App-Deployment" Action="Allow" UserOrGroupSid="S-1-1-0">
<Conditions>
<FilePathCondition Path="D:\App\Bin\*" />
</Conditions>
</FilePathRule>
</RuleCollection>—
3. 盲点：AppLockerを回避させないための鉄則
AppLockerを導入しても、構成が甘ければ簡単に突破されます。現場でよく見る「死ぬポイント」は以下の通りです。
1. Application Identity サービスの無効化:
このサービスが止まるとAppLockerは無力化されます。グループポリシー（GPO）で、このサービスが「自動起動」かつ「停止不可能」であることを強制してください。
2. 書き込み権限の放置:
「許可されたパス」に、一般ユーザーがファイルを書き込める状態になっていませんか？AppLockerを導入する際は、必ずファイルシステム側のNTFSアクセス権限（ACL）とセットで設計してください。
3. PowerShellの制限:
powershell.exeを許可しつつ、スクリプト実行を制御するには Constrained Language Mode (CLM) を併用する必要があります。
PowerShellのCLM強制（環境変数で設定）
システム全体でPowerShellを制限する設定です。これはAppLockerと合わせて導入すべき必須の防御策です。
# 環境変数に __PSLockdownPolicy を追加してCLMを強制する
[Environment]::SetEnvironmentVariable('__PSLockdownPolicy', '4', 'Machine')—
4. 最後に：セキュリティは「設定」ではなく「文化」
AppLockerは強力ですが、運用を止めないためのメンテナンスコストも発生します。新しいソフトウェアを導入するたびにポリシーを更新する手順を、CI/CDパイプラインに組み込むことが重要です。
例えば、ビルド後のバイナリに正当なコード署名を付与し、その署名情報に基づいてAppLockerの許可リストを自動生成する。ここまでやって初めて、本当の意味での「要塞」が完成します。
セキュリティとは、境界線を引くだけではありません。その境界線が正しく機能し続けているかを監視し、更新し続けることそのものです。今日から監査モードでログを眺め、サーバー上で「無駄に動いているもの」を洗い出すところから始めてみてください。それが、最強の防御への第一歩です。
コメント