はじめに

セキュリティインシデントの調査やフォレンジックにおいて、イベントログは不可欠な情報源です。しかし、多くの現場で陥りがちなのが「何が重要かわからないため、とりあえずすべての監査を有効にする」という落とし穴です。

無計画な全監査の有効化は、ディスク容量の枯渇、SIEM（セキュリティ情報イベント管理）への転送・保管コストの爆発、そしてノイズログによる「肝心な攻撃痕跡の埋没」を引き起こします。

この記事では、イベントログ収集における高度な監査ポリシー（Advanced Audit Policy）の最適化基準として、「何を取得し、何を捨てるべきか」の設計指針を解説します。

前提条件

本記事は「高度な監査ポリシーの構成」（auditpolおよび対応するGPO配下）を前提とします。基本監査ポリシーとの併用は非推奨です（後述のセクション1参照）。
サブカテゴリ名とイベントIDの対応を誤ると、auditpolで意図したサブカテゴリを有効化しても目的のイベントが記録されません。本記事では特にKerberos関連の対応関係を正確に区別しています。

Linuxエンジニア向けの例え

監査ポリシーの取捨選択は、auditdのルールセット（audit.rules）をチューニングする作業そのものです。-a always,exit -F arch=b64 -S execveのように狙った対象だけを監査するのと同様に、Windowsでも「カテゴリ丸ごと」ではなく「サブカテゴリ単位」で必要なものだけを有効化することが、ノイズを抑える鍵になります。

特にファイルシステムやレジストリのオブジェクトアクセス監査を全有効化する行為は、auditdで/配下すべてに-w /のような広範なwatchルールを張るのに相当し、実運用ではまず現実的ではありません。

1. レガシーな監査ポリシーから「高度な監査ポリシー」への移行

Windowsには昔ながらの「基本的な監査ポリシー（9カテゴリ）」と、Windows Vista / Server 2008以降に導入された「高度な監査ポリシー（50以上のサブカテゴリ）」が存在します。

まずは、基本監査と詳細監査の競合を防ぎ、きめ細かい制御を強制するために以下のGPO設定を必ず有効化します。

パス: コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカルポリシー → セキュリティオプション

ポリシー名: 「監査: 監査ポリシーサブカテゴリの設定 (Windows Vista またはそれ以降) を強制して、監査ポリシーカテゴリの設定を上書きする」

設定: 「有効」

2. 何を取り、何を捨てるか：監査ポリシーの仕分け基準

監査ログは「成功（Success）」と「失敗（Failure）」を個別に制御できます。限られたストレージと分析リソースを最大限に生かすための推奨構成です。

必須で取得すべきカテゴリ（取るべきもの）

攻撃者の足取り、権限昇格、横展開（Lateral Movement）を捉えるための最重要ログです。

サブカテゴリ	設定	主なイベントID	取得すべき理由・監視目的
ログオンの監査	成功 / 失敗	4624, 4625	不正アクセス、パスワードスプレー、総当たり攻撃の検知。
プロセス作成の監査	成功	4688	不正なコマンド実行、LOLBinsの悪用、スクリプト起動の検知。
ユーザーアカウント管理の監査	成功 / 失敗	4720, 4738	不正なバックドアアカウントの作成・属性変更の検知。
セキュリティグループ管理の監査	成功	4727, 4728, 4732, 4737	Domain Adminsなど特権グループへの不正なメンバー追加の検知。
セキュリティシステム拡張機能の監査	成功 / 失敗	4697	不審なサービスの新規インストールの検知。
セキュリティ状態の変更の監査	成功 / 失敗	4616	システム時刻の変更（ログ偽装・タイムスタンプ改ざん）の検知。
資格情報の検証	成功 / 失敗	4776, 4777	NTLM認証によるパスワードスプレー・総当たり攻撃の検知。
Kerberos 認証サービスの監査	成功 / 失敗	4768, 4771	パスワードスプレー、事前認証無効アカウントを狙ったAS-REP Roastingの検知。
Kerberos サービスチケット操作の監査	成功	4769	Kerberoasting攻撃（サービスアカウントのハッシュをオフライン解析）の検知。

セキュリティシステム拡張機能とセキュリティ状態の変更、および資格情報の検証と2つのKerberos関連サブカテゴリは、名前が似ている・混同されがちですが、auditpol上は別々のサブカテゴリです。特にKerberoasting検知の要である4769は「資格情報の検証」ではなく「Kerberos サービスチケット操作」を有効化しないと記録されないため注意してください。

原則として無効化（または厳選）すべきカテゴリ（捨てるべきもの）

平常時でも秒間数百〜数千件のログが生成され、ログ領域を瞬時に埋め尽くす「高ノイズ」なカテゴリです。

サブカテゴリ	推奨設定	理由・リスク
ファイルシステム（オブジェクトアクセス）	無効（特定フォルダのみ）	全有効にすると、OSの内部ファイルアクセスだけで毎秒数万件のログ（EID 4663）が発生し、システムパフォーマンスが低下する。
レジストリ（オブジェクトアクセス）	無効（特定キーのみ）	OSや常駐ソフトがバックグラウンドで頻繁にレジストリを読み書きするため、ノイズの塊になる。
フィルタリングプラットフォーム接続	無効	Windowsファイアウォールを通過するパケット単位でEID 5156/5158が生成され、SIEMのライセンス上限を即座に突破してしまう。
プロセスの終了	無効	プロセスの終了（EID 4689）単体では攻撃の判別が難しく、プロセス生成（4688）だけで十分追跡可能なため。
詳細なファイル共有	無効	共有フォルダ内のファイルを開く・閉じるたびにログが記録され、ファイルサーバーが停止するリスクがある。

3. プロセス生成（EID 4688）における「コマンドライン引数」の必須設定

プロセス作成の監査（EID 4688）を有効にする際、最も重要な要塞化設定があります。既定では「どのプログラム（powershell.exeなど）が起動したか」しか記録されず、攻撃内容を特定できません。

完全な実行引数を記録させるため、以下のポリシーを必ず有効化します。

パス: コンピューターの構成 → 管理用テンプレート → システム → プロセス作成の監査

ポリシー名: 「プロセス作成イベントにコマンドラインを含める」

設定: 「有効」

これにより、難読化されたPowerShellコマンド（例: powershell -enc aQB1AHIA...）や、攻撃者が実行した不審なパラメータがイベントログ内に完全に記録されます。

4. auditpol コマンドによる現状確認とバックアップ

現在の設定状況の確認や、スクリプトによる一括適用・バックアップには標準コマンドauditpolを使用します。

# 1. 現在の高度な監査ポリシー設定を一覧表示
auditpol /get /category:*

# 2. 特定のサブカテゴリ（プロセス作成）の設定を確認
auditpol /get /subcategory:"プロセス作成"

# 3. コマンドラインから「ログオン」の成功・失敗監査を即時有効化
auditpol /set /subcategory:"ログオン" /success:enable /failure:enable

# 4. Kerberoasting検知に必須の「サービス チケット操作」を有効化
auditpol /set /subcategory:"Kerberos サービス チケット操作" /success:enable

# 5. 現在の監査設定をCSVファイルとしてバックアップ
auditpol /backup /file:"C:\AuditPolicy_Backup.csv"

5. オブジェクトアクセスを「外科手術」のようにピンポイントで取る方法

機密情報（役員給与フォルダや重要設定ファイル）のアクセスログを残したい場合、ポリシー全体で「ファイルシステム」を有効化してはいけません。

GPOで「ファイルシステムの監査（成功/失敗）」を有効にします。
対象となる特定のフォルダのみを右クリック → 「プロパティ」→「セキュリティ」タブ →「詳細設定」→「監査」タブを開きます。
監査対象とするプリンシパル（例: Everyone）と、監視したいアクセス権（例: 「削除」「アクセス許可の変更」など。※「読み取り」を含めると件数が跳ね上がるため注意）を厳選して登録します。

このように「ポリシーで枠組みを許可し、フォルダ単位で絞り込む」ことで、不要なノイズを完全に抑えながら重要ファイルのアクセス監査（EID 4663）を実現できます。

まとめ：ログ設計は「引き算」がセキュリティの質を決める

監査ログは「多ければ多いほど良い」というものではありません。過剰なログは監視担当者の目を曇らせ、本当に検知すべき攻撃の予兆を見失わせます。

認証関連（ログオン・資格情報・Kerberos）とアカウント管理は網羅的に取得する（ただしサブカテゴリの対応関係を正確に把握すること）
プロセス作成（4688）は必ず「コマンドライン引数」を含めて取得する
ファイルやパケット単位の膨大なオブジェクトアクセスは原則破棄し、機密資産のみピンポイントで監査する

自組織のSIEMの許容量や運用リソースに合わせ、「取るべきログ」と「捨てるべきログ」の境界線を明確に定義しましょう。

今すぐ実行すべき確認コマンド

# 1. サブカテゴリの強制上書き設定が有効か確認
auditpol /get /option:CrashOnAuditFail
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

# 2. 本記事で「取るべき」とした認証系サブカテゴリが有効か一括確認
foreach ($sub in "ログオン","プロセス作成","ユーザー アカウント管理","セキュリティ グループ管理","セキュリティ システムの拡張機能","セキュリティ状態の変更","資格情報の検証","Kerberos 認証サービス","Kerberos サービス チケット操作") {
    auditpol /get /subcategory:"$sub"
}

# 3. プロセス作成イベントにコマンドラインが含まれているか、直近のログで確認
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5 |
    Select-Object TimeCreated, Message