IIS の本番ディレクトリからファイルが消えた――この“よくあるけれど致命的”なトラブルに、Windows Server 2019 標準機能だけでどう向き合うか。この記事は、過去の削除は追跡できるのかという現実的な問いに答えつつ、明日から確実に「誰が」「どのプロセスで」「どのパスを」削除したのかを特定できるよう、監査の設計・実装・運用までを具体的に解説します。
目次
前提と質問の整理
対象は Windows Server 2019（IIS 運用）の「本番ディレクトリ」。以下の2点が関心事です。
- 削除したユーザーを特定できるか？
- 監査ポリシーを設定する前に発生した削除について、後からログを取得できるか？
結論（最速理解）
| 結論 | 詳細 |
|---|---|
| 過去の削除は特定できない | 監査ポリシーを有効化する前に起きた操作は記録されていません。Windows 標準では、既定でファイル削除は監査対象外のため、後追い取得は不可です。 |
| 今後は監査を有効化すれば特定可能 | 監査をセットアップすれば、削除操作ごとに イベント ID 4663（File System / DELETE）が「セキュリティ」ログへ記録され、ユーザー名・プロセス名・対象パスなどが確認できます。 |
なぜ「過去」は追えないのか（仕組みの理解）
Windows のファイル監査は「事前に有効化された SACL（監査用 ACL）」と「詳細監査ポリシー」の両方が整って初めてイベントに残ります。どちらか一方でも欠けていれば、当該操作はログ化されません。ゆえに、ポリシー未設定期間の削除は、OS 標準の仕組みでは後から復元できません（バックアップやシャドウコピーに残っているのは“データ”であって“操作ログ”ではないため）。
削除特定に関係する主なイベント ID
| イベント ID | 意味 | 有効化が必要なポリシー（代表例） | 活用ポイント |
|---|---|---|---|
| 4663 | オブジェクトへのアクセスが試行/実行された（Accesses: DELETE 等） | 詳細監査ポリシー「オブジェクト アクセス → ファイル システム（成功）」＋対象フォルダの SACL | 削除対象パス・ユーザー・プロセス名を最短で把握。実務の主役。 |
| 4660 | オブジェクトが削除された | 同上＋「ハンドル操作（成功）」 | 「本当に消えた」確証を補強。4663 とセットで見ると堅い。 |
| 4656/4658 | ハンドル要求／クローズ | ハンドル操作 | 一連の操作の時系列把握に有効。 |
| 4624 | サインイン成功 | ログオン/ログオフ | 4663 の「ログオン ID」と突合し、元端末や IPを追跡。 |
| 4688 | プロセス作成 | 詳細追跡 → プロセス作成（＋可能なら“コマンドラインの記録”） | robocopy や powershell.exe など削除に関与したコマンドを特定。 |
| 5145 | SMB のアクセス検査（詳細ファイル共有） | オブジェクト アクセス → 詳細ファイル共有（成功） | 共有越しの削除でクライアント側情報を補完。 |
| 1102 | 監査ログがクリアされた | — | 隠蔽の兆候を検知。運用監視に。 |
監査設定の手順（最短で確実に動かす）
手順 1. 監査ポリシーを有効化
単体サーバーでは gpedit.msc、ドメイン配下では GPMC（グループ ポリシー管理）を使います。
- パス（共通）: コンピューターの構成 → Windows の設定 → セキュリティの設定 → 詳細監査ポリシーの構成 → オブジェクト アクセス
- 有効化するサブカテゴリ:
- ファイル システム（成功） … 削除などのファイル操作を 4663 で記録
- ハンドル操作（成功） … 実削除の 4660 を補足（任意だが推奨）
- 詳細ファイル共有（成功） … SMB 経由の操作を 5145 で補足（共有で編集される場合に推奨）
- プロセス作成（成功）（詳細追跡）… 4688 を取得。可能なら「プロセス作成イベントにコマンドラインを含める」を有効化
設定後は gpupdate /force で即時適用します。CLI 派は以下でも可。
auditpol /set /subcategory:"File System" /success:enable
auditpol /set /subcategory:"Handle Manipulation" /success:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /get /category:"Object Access"
手順 2. 対象フォルダーに監査エントリ（SACL）を追加
GUI での操作：
- フォルダーを右クリック → [プロパティ] → [セキュリティ] → [詳細設定] → [監査]
- [追加] → 監査する主体（例：Everyone もしくは該当グループ）を指定
- [詳細アクセス許可] で Delete と Delete subfolders and files のみにチェック（成功）
- [適用先] を「このフォルダー、サブフォルダー、ファイル」に設定 → [OK]
PowerShell で一気に設定する例：
$path = 'C:\inetpub\wwwroot\Production'
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
'Everyone',
'Delete, DeleteSubdirectoriesAndFiles',
'ContainerInherit, ObjectInherit',
'None',
'Success'
)
$acl.AddAuditRule($rule)
Set-Acl $path $acl
ポイントは“Delete 系だけ”を監査すること。これによりノイズ（書き込みや読み取り）を極小化できます。
手順 3. 動作確認（テスト削除 → 4663 を確認）
- 対象フォルダにテストファイルを作成 → 削除
- イベント ビューアー → [Windows ログ] → [セキュリティ]
- ID 4663（タスクのカテゴリ：File System）を開き、以下のような内容を確認
オブジェクト名 : C:\inetpub\wwwroot\Production\index.html
アクセス : DELETE
アカウント名 : <削除を実行したユーザーまたはサービスアカウント>
プロセス名 : C:\Windows\explorer.exe（例）/ C:\Windows\System32\inetsrv\w3wp.exe など
ログオン ID : 0x3e7...
手順 4. 調査を速くするフィルタ（カスタムビュー & PowerShell）
イベント ビューアーのカスタムビュー（XML）例。4663 のうち DELETE が含まれるイベントだけに絞ります。
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4663)]] and
*[EventData[Data[@Name='Accesses'] and (contains(., 'DELETE'))]]
</Select>
</Query>
</QueryList>
PowerShell 派のワンライナー（直近1日の削除ログを一覧表示）：
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=(Get-Date).AddDays(-1)} |
Where-Object { $_.Message -match 'Accesses:\s+DELETE' } |
Select-Object TimeCreated, Id, ProviderName, MachineName, Message
「誰が消したのか」を突き止める実戦フロー
- 4663（DELETE）を起点に、オブジェクト名（パス）・アカウント名・プロセス名を確認。
- 「アカウント名」が
IIS AppPool\<アプリ名>やサービスアカウントの場合、4688（プロセス作成）を併読し、実行ファイルやコマンドラインからジョブ/デプロイ/スクリプトの関与を特定。 - 「ログオン ID」をコピーし、4624（サインイン）を同一 ID で検索。ログオンの種類やソース ネットワーク アドレス（IP）により、実行元端末を割り出す。
- 共有越しの削除が疑われる場合は、5145（詳細ファイル共有）で共有名とクライアント情報を確認。
- 確証を高めたい場合は、4660（オブジェクト削除）の発生有無を確認。発生していれば“消えた”事実がより堅くなります。
この 1→2→3→4→5 の流れをテンプレ化しておけば、トラブルシューティングの初動が劇的に速くなります。
IIS 運用ならではの注意点（本番ディレクトリ特有の落とし穴）
- アプリケーション プールの ID（既定は ApplicationPoolIdentity）。ログ上の「ユーザー」に
IIS APPPOOL\<プール名>が出るのは正常です。背後に本当の操作者がいる場合は、4624 や 4688 と突合して絞り込みます。 - デプロイ方式（例：
robocopy /MIR、CI/CD、WebDeploy、タスク スケジューラ）。ミラーリングやクリーンデプロイは「削除」を伴うため、プロセス名とコマンドラインが決定的な手がかりになります。 - ウイルス対策やバックアップエージェントが検疫・ローテーションでファイルを削除するケースがあります。
MsMpEng.exeなど、“意図的に正しい”削除を誤検知しないよう、運用でラベル付け（コメントや CMDB）を。 - 共有越しの編集が混在していると、削除の発生はサーバー側に記録されます。詳細ファイル共有（5145）の併用を検討してください。
運用設計（ノイズを抑え、証跡を守る）
| テーマ | 推奨設定/運用 | 狙い |
|---|---|---|
| 監査範囲 | 監査エントリは Delete / Delete subfolders and files のみ | ログ量とオーバーヘッドを最小化 |
| ログ保管 | セキュリティログ容量を十分に（例：1GB〜）。Windows Event Forwardingや SIEM で中央収集 | 長期保全・検索性・改ざん耐性 |
| 改ざん検知 | 1102（ログ消去）アラート。管理者権限の分離（監査・運用の職務分掌） | 証跡の信頼性維持 |
| 相関強化 | 4688（コマンドライン含む）と 4624 を併用 | プロセス/端末/操作者の特定精度を上げる |
| バックアップ | 定期バックアップ＋シャドウコピー（Previous Versions）の併用 | 復旧時間短縮（RTO）と証跡調査の両立 |
復旧の観点（消えた後にできること）
- データ復元はバックアップ/シャドウコピーの出番。証跡とは別レイヤーです。監査を整えたうえで、復元→原因究明の順序で対処を。
- “消した犯人”の推測をデータからは行えません。監査ポリシーを整えた後に再発した場合は、4663/4660 と相関して特定してください。
調査の品質を上げる読み方（実例ベース）
ケース：本番ディレクトリ
C:\inetpub\wwwroot\Productionの画像が消えた。共有越し編集も一部あり。
- 4663 で オブジェクト名が該当パス、アクセスが
DELETEのレコードを抽出。 - アカウント名が
IIS APPPOOL\ProductionSiteの場合、4688 を同時刻近傍で参照し、w3wp.exe以外のrobocopy.exeやpowershell.exeの起動を確認。 - ログオン IDを 4624 に照合し、ソース ネットワーク アドレスから運用端末を確定。
- 共有越しが疑わしければ 5145 で共有名とアクセス要求をチェック。
- 最後に 4660 が存在すれば、削除が成立した確度が上がる。
よくあるミスと対処
- 「4663 が出ない」 → 監査ポリシーは有効か？かつ、対象フォルダに SACL は入っているか？ どちらが欠けてもログは出ません。
- 「ログが多すぎて埋もれる」 → 監査は Delete 系のみに限定。加えてカスタムビューや PowerShell で DELETE を含むものだけを抽出。
- 「誰の操作か分からない」 → 4663 の「ログオン ID」を 4624 と突合。アプリ プール ID の背後にいる操作者は 4688 や 5145 と合わせて浮かび上がります。
- 「共有で消えたっぽい」 → 詳細ファイル共有（5145）を有効化。クライアントのマシン名や IP を補完。
- 「監査を切りたくなった」 → 問題解決後に停止する場合も、証跡保持のため最低限の期間は継続を。再発時の原因究明が困難になります。
セキュリティログの保全テクニック
- サイズ拡張：セキュリティログは十分に確保（例：1GB〜）。上書きよりも「必要に応じて上書き」設定の見直しを。
- 中央転送：Windows Event Forwarding（サブスクリプション）で収集サーバーへ転送。改ざんや消去の影響を受けにくくなります。
- 定期エクスポート：
wevtutil epl Security "D:\Logs\Security_%date:~0,10%.evtx"などでローテーション。 - ロール分離：「セキュリティ ログの管理」を運用者から切り離し、内部不正やヒューマンエラーのリスクを下げる。
監査の拡張：必要に応じて有効化したい項目
- プロセス作成（4688）にコマンドライン：削除を起こしたスクリプトの引数まで追えると、一発で原因にたどり着けます。
- アカウント管理/権限変更：普段触らないはずの運用アカウントが急に権限を得ている…といった異常の早期検知に。
チェックリスト（導入から運用まで）
| 項目 | 状態 | メモ |
|---|---|---|
| 詳細監査ポリシー：ファイル システム（成功） | ✅/❌ | GPO かローカルで有効化 |
| 詳細監査ポリシー：ハンドル操作（成功） | ✅/❌ | 4660 補足用（任意だが推奨） |
| 詳細監査ポリシー：詳細ファイル共有（成功） | ✅/❌ | SMB 越しの追跡に |
| 対象フォルダの SACL（Delete 系のみ） | ✅/❌ | 「このフォルダー、サブフォルダー、ファイル」に適用 |
| テスト削除で 4663（DELETE）が出る | ✅/❌ | 初期セットアップの最重要確認 |
| セキュリティログ容量・転送 | ✅/❌ | 長期保管と検索性を確保 |
| 4688（コマンドライン）・4624 の有効化 | ✅/❌ | 原因究明を強化 |
トラブル事例で学ぶ（パターン別の読み解き）
デプロイジョブが消していた
- 4663：Accesses = DELETE、ProcessName = robocopy.exe、Account = <ビルド/デプロイ用サービスアカウント>
- 4688：
robocopy /MIRのコマンドラインが記録。ミラーリングによる削除が確定。 - 対処：除外パスや発行手順の見直し。必要なら “/PURGE” や “/MIR” の扱いを再検討。
共有での手作業削除
- 4663：Subject に一般ユーザー、ProcessName = explorer.exe
- 5145：共有名、アクセス元クライアントのホスト名/IP を確認
- 対処：共有の書き込み権限再点検、承認フロー導入、教育。
IIS アプリが生成ファイルをクリーンアップ
- 4663：Account = IIS APPPOOL\<サイト名>、ProcessName = w3wp.exe
- 4688：バックグラウンドジョブの
powershell.exeなどが見える場合あり - 対処：アプリ側のジョブ設定・ライフサイクルの見直し。ログ連携で相関を容易に。
コマンド & スニペット集（現場で使える最小セット）
詳細監査の有効化（CLI）：
auditpol /set /subcategory:"File System" /success:enable
auditpol /set /subcategory:"Handle Manipulation" /success:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable
auditpol /get /category:"Object Access"
Delete だけを拾う PowerShell（直近 24 時間）：
$start = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=$start} |
Where-Object { $_.Message -match 'Accesses:\s+DELETE' } |
Select-Object TimeCreated,
@{n='User';e={($_.Message -split "Account Name:\s+")[1] -split "\r\n" | Select-Object -First 1}},
@{n='Process';e={($_.Message -split "Process Name:\s+")[1] -split "\r\n" | Select-Object -First 1}},
@{n='Path';e={($_.Message -split "Object Name:\s+")[1] -split "\r\n" | Select-Object -First 1}}
補足：サードパーティや代替手段
- 標準機能だけで要件は満たせます。が、GUI レポートやアラート配信を強化したい場合は、ログ可視化ツールや SIEM の導入を検討してください。
- 高度なファイル監視（リアルタイム・詳細属性）や長期の動的相関が必要なら、専用のファイル監査製品や補助ドライバ系の監視も選択肢です。ただしまずは標準監査＋中央収集で十分な結果が得られるケースが大半です。
まとめ（ここだけ読めば十分）
- 過去の削除は特定不可能。ログは事前の監査設定なしには残りません。
- 未来は変えられる。「詳細監査ポリシー（ファイル システム / 必要に応じてハンドル操作・詳細ファイル共有）」＋「対象フォルダの SACL（Delete 系のみ）」で、ID 4663 を確実に記録。
- 実調査は 4663 → 4688 → 4624 →（必要に応じ 5145/4660） の順で。プロセス名・ログオン ID・IP を突合すれば、「誰が、どこから、何で消したか」に到達できます。
- ログの保全（容量/転送/改ざん検知）とバックアップ/シャドウコピーの二本立てで、原因究明と早期復旧を両立させましょう。
参考：最小構成のクイックスタート（貼って動く）
- 詳細監査ポリシーで「ファイル システム（成功）」を有効化（必要に応じて「ハンドル操作（成功）」「詳細ファイル共有（成功）」も）。
- 本番ディレクトリに SACL を追加（Everyone に Delete / Delete subfolders and files、適用先は このフォルダー、サブフォルダー、ファイル）。
- テストファイルを作成→削除し、セキュリティログに 4663（DELETE）が出ることを確認。
- カスタムビューまたは PowerShell で DELETE を含むイベントだけを抽出できるようにする。
- ログ容量の拡張・中央転送・1102 の監視を設定。
要するに：過去はあきらめ、未来は仕込む。詳細監査ポリシー＋フォルダー SACL による 4663（DELETE） の取得こそ、「誰がファイルを削除したか」を特定する最短ルートです。
コメント