【Windows Server上級 第10回】セキュリティの硬化。AppLockerと監査ログによる要塞化

「管理者権限」を渡した瞬間、そのサーバーはもうあなたのものではない。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、AD FSによるID連携とシングルサインオン（SSO）について学びました。
ID管理で「入り口」は守られましたが、一度侵入を許したらどうなるでしょうか？

Linuxエンジニアの皆さん、サーバーのセキュリティ対策と言えば何をしますか？
iptables (firewalld) でポートを閉じる、SELinux をEnforcingにする、sudo で権限を絞る、そして auditd でログを取る。
これらは基本中の基本ですよね。
しかし、Windows Serverになった途端、「Windows Defenderが入ってるからヨシ！」で終わらせていませんか？

本記事では、AppLockerによるアプリケーション実行制御、高度な監査ポリシーによるログ追跡、そしてJEAによる最小権限運用の実装までを徹底解説します。

---

第1章：AppLockerとは？ ホワイトリストで封殺する

従来のセキュリティソフトは「悪いものを検知して止める（ブラックリスト）」方式でした。
しかし、毎日数万の新種が生まれるマルウェアを全て検知するのは不可能です。
そこで登場するのが、「許可したもの以外はすべて止める（ホワイトリスト）」方式のAppLockerです。

制御できるもの

• 実行ファイル (.exe, .com): 最も基本的な制御対象。
• Windowsインストーラー (.msi, .msp): 勝手なソフトのインストールを防ぐ。
• スクリプト (.ps1, .bat, .vbs): PowerShellなどの悪用を防ぐ。
• パッケージ化されたアプリ (.appx): Microsoft Storeアプリ。
• DLL (.dll, .ocx): 高度な設定（※パフォーマンスへの影響大）。

許可ルールの条件

1. パスの規則: C:\Program Files\* 配下ならOKなど。簡単だが、書き込み権限のあるフォルダを許可すると危険（ユーザーがそこにマルウェアを置いて実行できてしまうため）。
2. 発行元の規則: 「Microsoftが署名したもの」「Adobeが署名したもの」ならOK。最も推奨される安全な方法。
3. ファイルハッシュの規則: 特定のファイルのハッシュ値で許可。アップデートのたびにハッシュが変わるので運用が大変。

---

第2章：実践！AppLockerの導入ステップ

AppLockerはいきなり「有効化」してはいけません。
必要なシステムファイルまでブロックしてしまい、OSが起動しなくなる（いわゆる「自爆」）リスクがあるからです。

Step 1: Application Identityサービスの開始

AppLockerの実体はこのサービスです。GPOで「自動起動」にしておきます。

Step 2: デフォルトルールの作成

グループポリシー管理エディタを開き、以下のパスへ移動します。
コンピューターの構成 > ポリシー > Windowsの設定 > セキュリティの設定 > アプリケーション制御ポリシー > AppLocker

「実行可能ファイルの規則」を右クリックし、「既定の規則の作成」を実行します。
これにより、以下の3つの安全なルールが自動生成されます。

• All files located in the Program Files folder（Program Files以下は許可）
• All files located in the Windows folder（Windowsフォルダ以下は許可）
• All files（Administratorsグループのみ許可）

重要： これにより、一般ユーザーは C:\Users\User\Downloads やデスクトップ等の「書き込み可能な場所」にあるEXEを実行できなくなります。

Step 3: 監査モードでの運用

AppLockerのプロパティを開き、各ルールの状態を「規則の適用」ではなく「監査のみ (Audit Only)」に設定します。
この状態なら、ブロックはされず、「もし有効化していたらブロックされていた」というログ（イベントID 8003）だけがイベントビューアに残ります。
1週間ほど運用し、業務に必要なアプリがブロックされていないかログを確認します。

Step 4: 強制モードへ切り替え

問題なければ、「規則の適用」に変更します。
これで、ランサムウェアがメール添付で送られてきても、ユーザーが間違ってダブルクリックしても、絶対に実行されなくなります。

---

第3章：犯人は誰だ？「高度な監査ポリシー」の活用

「誰かが勝手に設定を変えた」「怪しいコマンドが実行された」。
デフォルトのWindowsログ設定では、これらの追跡は不可能です。
「高度な監査ポリシー構成 (Advanced Audit Policy Configuration)」を有効にする必要があります。

従来の監査ポリシーとの違い

昔の「監査ポリシー」は9つの大項目しかありませんでした。
「高度な監査ポリシー」はそれをさらに細分化し、50以上の項目でOn/Offを制御できます。
これにより、「必要なログだけを取り、ディスク容量の無駄を防ぐ」ことができます。

必須の設定項目（GPO）

コンピューターの構成 > ポリシー > Windowsの設定 > セキュリティの設定 > 高度な監査ポリシー構成

カテゴリ	サブカテゴリ	設定	目的
ログオン/ログオフ	ログオン	成功/失敗	誰がいつログインしたか (ID: 4624)
オブジェクトアクセス	ファイルシステム	失敗	権限のないファイルを見ようとした行為を検知 (ID: 4663)
特権使用	機密特権の使用	成功/失敗	管理者権限の行使を記録
詳細な追跡	プロセスの作成	成功	どんなプログラムが起動したか (ID: 4688)

コマンドライン引数の記録

デフォルトでは「powershell.exe が起動した」ことしか分かりません。
「powershell.exe -Command "Remove-Item C:\Data -Recurse" を実行した」という引数の中身まで記録するには、もう一つ設定が必要です。

管理用テンプレート > システム > プロセス作成の監査 > 「プロセス作成イベントにコマンドラインを含める」を有効化。

これで、イベントID 4688 のログに、実行されたコマンドの全貌が記録されます。
Linuxの auditd や history コマンドのような追跡が可能になります。

---

第4章：JEA (Just Enough Administration)。Windows版sudo

「DNSのレコード修正だけをしたいオペレーター」に、Domain Admins権限を渡していませんか？
それはあまりに危険です。
Linuxの sudo のように、「特定のコマンドだけを管理者権限で実行させる」仕組みが、PowerShellの JEA (Just Enough Administration) です。

JEAの仕組み

JEAは、PowerShell Remoting（WinRM）の機能を利用します。
ユーザーがJEAエンドポイントに接続すると、そのセッション内では一時的に「仮想管理者アカウント」として振る舞いますが、実行できるコマンドは事前に定義されたものだけに制限されます。

構築ステップ

1. Role Capability ファイル (.psrc) の作成
「何ができるか」を定義します。

New-PSRoleCapabilityFile -Path .\DnsOps.psrc
# ファイルを編集し、VisibleCmdlets に許可したいコマンドを記述
# 例: VisibleCmdlets = @('Get-DnsServerResourceRecord', 'Add-DnsServerResourceRecordA')

2. Session Configuration ファイル (.pssc) の作成
「誰にどのRoleを割り当てるか」を定義します。

New-PSSessionConfigurationFile -Path .\DnsEndpoint.pssc -SessionType RestrictedRemoteServer -RoleDefinitions @{
    'CORP\DnsOperators' = @{ RoleCapabilities = 'DnsOps' }
}

3. エンドポイントの登録

Register-PSSessionConfiguration -Name DnsAdmin -Path .\DnsEndpoint.pssc

これで、CORP\DnsOperators グループのメンバーは、以下のコマンドで接続した時だけ、DNS管理コマンドを実行できます（それ以外のコマンドや、Cドライブへのアクセスなどは一切できません）。

Enter-PSSession -ComputerName Server01 -ConfigurationName DnsAdmin

---

第5章：プロの「要塞化」チェックリスト

最後に、サーバー構築時に必ず実施すべき「Hardening（堅牢化）」のチェックリストを紹介します。

1. SMBv1の完全撤廃

WannaCryなどのランサムウェアが拡散する原因となった古いプロトコルです。
現代の環境では百害あって一利なしです。

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

2. RDPのセキュリティ強化

リモートデスクトップは攻撃の入り口になりやすい箇所です。

• NLA (ネットワークレベル認証) を強制する: ログイン画面が出る前に認証を完了させる。
• RDPポートの変更は無意味: スキャンされればすぐバレます。それよりRD Gatewayを使いましょう（第5回参照）。
• アカウントロックアウトポリシーの設定: 総当たり攻撃（ブルートフォース）対策。

3. NTLMの無効化（Kerberos強制）

NTLM認証はハッシュを盗まれると「Pass-the-Hash」攻撃に使われます。
可能な限りKerberos認証を強制し、NTLMの使用を監査・ブロックします。
セキュリティ設定 > ローカルポリシー > セキュリティオプション > ネットワークセキュリティ: NTLMを制限する

---

まとめ：セキュリティは「設定」ではなく「運用」である

お疲れ様でした！
上級編第10回は、AppLockerと監査ログによるサーバー要塞化について解説しました。

今回の重要ポイント：

• AppLockerでホワイトリスト運用をすれば、未知のマルウェアも怖くない。
• 高度な監査ポリシーで「プロセス作成」と「コマンドライン」を記録せよ。
• JEAを使えば、管理者権限を渡さずに作業を委任できる（Windows版sudo）。
• SMBv1無効化など、既知の脆弱性を潰す「Hardening」を徹底する。

さて、オンプレミスのセキュリティは固まりました。
しかし、世の中はクラウドファースト。「サーバーはAzureやAWSにある」のが当たり前になりつつあります。
「オンプレミスのWindows Serverも、Azure上のVMも、同じ画面で管理したい」。
そんな夢を叶えるのが、ハイブリッドクラウド管理技術です。

次回、第11回は「ハイブリッドクラウド管理。Azure Arcによるオンプレミスサーバーのクラウド化」です。
社内にある物理サーバーをAzureの管理ポータルに投影し、クラウドからポリシー適用や監視を行う、最新の管理手法について解説します。お楽しみに！