Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる

「昨夜からあるアカウントがロックアウトを繰り返している。原因を調べてほしい」「退職者のアカウントで誰かがサインインを試みていないか確認したい」「このサーバー、いつ誰が何を実行したか分かる？」── 中小企業の情シス担当者や、客先にシステムを納めている開発者が、ある日突然受け取る依頼です。そして頼みの綱になるのが、WindowsのSecurityイベントログです。

ところが実際にイベントビューアーを開くと、そこには2つの現実が待っています。見たいイベントが記録されていない(監査ポリシーが有効になっていない)か、大量のイベントに埋もれて読めない(ノイズだらけで肥大化している)かです。セキュリティ監査は「有効にすれば録れる」ものですが、何をどこまで録るかを設計しないと、いざというとき役に立ちません。

この記事では、監査ポリシーの仕組み(基本と詳細の2系統)、中小規模環境で最低限有効化すべきサブカテゴリ、4624/4625/4740/4688といった定番イベントIDの読み方、Securityログの容量設計、そしてPowerShellでの調べ方までを、2026年8月時点の一次情報にもとづいて整理します。当サイトで扱ってきたNTLM監査・SMB署名・BitLocker・ファイアウォールの各記事が「守りを固める」話だとすれば、本記事は「何が起きたかを後から確かめられるようにする」話であり、それらを束ねる続編です。

1. まず結論

• 監査ポリシーには「基本」と「詳細(Advanced Audit Policy)」の2系統があり、混ぜてはいけません。両方を使うと監査結果が予期しない状態になるとMicrosoftが明記しています。詳細側(40以上のサブカテゴリ)で統一します。¹
• 現状確認は auditpol /get /category:* です。GPO・ローカルどちら由来かに関係なく、いま効いている監査設定が一覧できます。²
• 「全部有効」はやってはいけません。大量のイベントを生むサブカテゴリを有効にすると、肝心のイベントがノイズに埋もれ、性能にも影響します。Microsoftのベースライン推奨を出発点に、必要なものだけ足します。³⁴
• サインインの成功は4624、失敗は4625です。4624はログオンタイプ(2=対話、3=ネットワーク、10=リモートデスクトップなど)で「どんなサインインか」を読み分けます。⁵
• 4625はStatus/Sub Statusコードで失敗理由が分かります。0xC0000064=存在しないユーザー名、0xC000006A=パスワード誤り、0xC0000072=無効化済みアカウント、0xC0000234=ロックアウト中、が定番です。⁶
• イベントは「どのマシンに記録されるか」が決まっています。4624/4625はアクセスされた側のマシン、資格情報の検証(4776)やKerberos事前認証失敗(4771)はドメインコントローラーです。見るマシンを間違えると「ログがない」と誤診します。⁶⁷⁸
• Securityログは器の設計(最大サイズと保持)が半分です。保持が上書きモードなら古いイベントから消えていきます。Get-WinEvent -ListLog Security で最大サイズと件数を確認し、必要な保持日数から逆算して拡張します。⁹¹⁰
• プロセス作成(4688)のコマンドライン記録は強力ですが、機密がログに平文で載るリスクと引き換えです。有効化前にスクリプト類の点検を。¹¹¹²

2. 監査ポリシーの基礎 ── 「基本」と「詳細」を混ぜない

Windowsの監査ポリシーは2系統あります。¹

• 基本の監査ポリシー: 「ローカルポリシー > 監査ポリシー」にある9個のカテゴリ設定。Windows Vistaより前からある古い系統です。
• 詳細な監査ポリシー(Advanced Audit Policy Configuration): 「セキュリティの設定 > 監査ポリシーの詳細な構成」にある40以上のサブカテゴリ設定。基本の1カテゴリを複数のサブカテゴリに分解したもので、たとえば基本の「アカウントログオンイベントの監査」1つに対して、詳細側には4つのサブカテゴリがあります。基本側で1カテゴリを有効にすることは、対応するサブカテゴリを全部有効にするのと同じであり、興味のないイベントまで大量に記録されます。¹

重要なのは、この2系統は互換ではないことです。Microsoftは「基本と詳細の両方を使うな。監査結果が予期しない状態になる」と明記しています。グループポリシーで詳細な監査ポリシーを適用すると、そのコンピューターの既存の監査設定はいったんクリアされたうえで詳細側の設定が適用され、以後は詳細側でしか確実に制御できません。詳細側を使う環境では、セキュリティオプション「監査: 監査ポリシーサブカテゴリの設定を強制する」を有効にして、基本側の設定が上書きしてこないようにしておきます(スタンドアロン機では既定で有効です)。¹⁴

現状の確認はコマンド1本です。管理者のコマンドプロンプトで実行します。²

rem いま効いている監査設定をサブカテゴリ単位で一覧表示
auditpol /get /category:*

rem 変更前のバックアップ(CSV)と復元
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

auditpol の出力は、GPO由来かローカル設定由来かに関係なく「結果として効いているポリシー」です。GPOで配っているはずの設定が反映されていないときの突き合わせにも使えます。なお、監査設定自体が変更されるとイベント4719が記録されるので、「いつの間にか監査が無効になっていた」も後から追えます。¹²

3. 最低限有効化すべきサブカテゴリの判断表

「とりあえず全部有効」が悪手である理由は明確です。たとえば特権使用系のサブカテゴリを成功まで監査すると、イベント量が膨大になって他のエントリを探すのが困難になり、性能への影響も出るとMicrosoftが警告しています。⁴ ログの器(5章)は有限なので、ノイズを録るほど本当に必要なイベントの保持日数が削られます。監査設計とは「何を録らないか」を決めることです。

Microsoftはワークステーション/サーバー別にベースライン推奨と強化推奨を公開しており、これが出発点になります。³ そのうえで、中小規模環境の「インシデント時に最低限これが読みたい」という観点で整理したのが次の表です。

逆に、ファイルシステムやレジストリのオブジェクトアクセス監査、特権使用、パケットフィルター系(5152など)は既定では手を出さないのが無難です。これらは対象を絞ったSACL設定や切り分け期間限定でこそ役立つもので、常時全開にするとログを食い潰します。⁴

4. 定番イベントIDの読み方

4.1. 4624 ── サインイン成功はログオンタイプで読み分ける

4624は「アカウントが正常にログオンしました」で、ログオンセッションが作られたマシン(アクセスされた側)に記録されます。⁵ 大量に記録されるイベントなので、読むときはログオンタイプでまず仕分けます。⁵

あわせて見るフィールドは、「新しいログオン」のアカウント名、「ネットワーク情報」の送信元アドレス、「認証パッケージ」(NTLMかKerberosか)、そして「昇格されたトークン」(管理者特権セッションか)です。管理者特権のサインインだけを追いたいなら、同じログオンIDで記録される4672(特殊な特権の割り当て)も使えます。⁵

4.2. 4625 ── 失敗理由はStatus/Sub Statusコードで確定する

4625は「アカウントがログオンに失敗しました」で、ログオンが試行されたマシンに記録されます。⁶ 「失敗の理由」欄の文言よりも、Status/Sub Statusの16進コードで読むのが確実です。定番は次のとおりです。⁶

• 0xC0000064: 存在しないユーザー名。短時間に連続していたらアカウント列挙攻撃の兆候
• 0xC000006A: パスワード誤り。特定アカウントに連続していたらパスワード推測攻撃の兆候
• 0xC000006D: ユーザー名または認証情報が不正
• 0xC000006F: 許可された時間帯の外
• 0xC0000070: 許可されていないワークステーションから
• 0xC0000072: 管理者によって無効化されたアカウント(退職者アカウントへの試行はここに出る)
• 0xC000015B: このマシンで要求されたログオンタイプが許可されていない
• 0xC0000193: 期限切れアカウント
• 0xC0000234: ロックアウト中

「誰が・どこから・なぜ失敗したか」は、対象アカウント+送信元(ワークステーション名/IPアドレス)+このコードの3点セットで確定します。6章でこの3点を一括抽出するPowerShellを載せます。

4.3. 4740 ── ロックアウトの発生源は「呼び出し元コンピューター名」

4740は「ユーザーアカウントがロックアウトされました」です(サブカテゴリはユーザーアカウントの管理)。このイベントの主役は「呼び出し元コンピューター名(Caller Computer Name)」フィールドで、ロックアウトの引き金になったログオン試行がどのコンピューターから来たかが記録されています。¹⁶ ここで発生源の端末を特定し、その端末に残っている古い資格情報を洗う、が定石です。原因はパスワード変更後も古い資格情報を使い続ける何か(保存済み資格情報、切断されたままのRDPセッション、古いパスワードのサービスやタスク)であることがほとんどです。

注意点がひとつあります。4625が記録されるのはログオン試行を受け付けた側のコンピューターです。発生源端末からファイルサーバー等へのネットワークログオンが原因の場合、発生源端末自身のSecurityログには4625が残らず、アクセス先サーバーの4625や、ドメインアカウントならDC側の4776(NTLM)/4771(Kerberos事前認証失敗)に証跡が残ります。⁷⁸ 「発生源端末のログに何もない」ときは、受け付けた側を見に行ってください。

4.4. 4720系 ── アカウントの作成・変更・グループ追加

アカウント管理系は番号が並んでいます。4720(ユーザーアカウントの作成)¹⁷、4726(削除)、4738(変更)、そしてグループ側のメンバー追加/削除です。グループのメンバー変更はグループの種類でイベントIDが分かれる点に注意してください。ローカルグループが4732/4733、グローバルグループが4728/4729、ユニバーサルグループが4756/4757です。¹⁴ Domain Adminsはグローバルグループなので、そこへの追加は4728に記録されます ── 4732だけをアラート条件にすると、いちばん見たい事象を取りこぼします。日常的にはヘルプデスク作業の記録ですが、「標準ユーザーが管理者グループに突然追加された」「誰も知らないアカウントが作られた」は単発でも即調査対象です。Microsoftも、特権グループへの予期しないメンバー追加を単発アラートの例に挙げています。³

4.5. 4688 ── プロセス作成。コマンドライン記録は別スイッチ

4688は「新しいプロセスが作成されました」で、プロセス作成のたびに、作成したアカウント、新しいプロセスの実行ファイルパス、親プロセス、トークン昇格タイプが記録されます。¹¹ 「このサーバーで誰が何を実行したか」に答えられる、調査価値の高いイベントです。

ただし既定ではコマンドライン引数は記録されません。「プロセス作成イベントにコマンドラインを含める」というグループポリシー(管理用テンプレート > システム > プロセス作成の監査)を別途有効にして初めて、4688の「プロセスのコマンドライン」フィールドに引数が入ります。¹¹¹² powershell -EncodedCommand ... のような不審な起動を追うには事実上必須の設定ですが、7章で述べる機密混入のリスクを理解してから有効化してください。

4.6. 4698 ── スケジュールされたタスクの作成

4698は「スケジュールされたタスクが作成されました」で、タスク名とタスク定義のXML全文(実行コマンドを含む)が記録されます。マルウェアが再起動後も生き残るための常套手段がタスク登録であるため、Microsoftはタスク作成イベントの監視を推奨しています。¹⁵ 業務でタスクを多用する環境でも、作成は日常的に起きるものではないので、ノイズは小さめです。

もう1つ覚えておきたいのが1102「監査ログが消去されました」です。Securityログのクリアは必ずこのイベントを残すので、「ログが空になっている」ときに事故か操作かを切り分けられます。¹⁸

5. ログの器の設計 ── 最大サイズと保持

監査ポリシーを増やす前に、受け皿を確認します。Securityログには最大サイズと保持モードがあり、上書きモード(既定的な構成)では、最大サイズに達すると新しいイベントが最も古いイベントを上書きします。逆に保持モード(上書きしない)では、ログが満杯になると新しいイベントのほうが破棄されます。¹⁰ どちらの挙動も「気づいたらログがない」の原因になるため、現状把握が先です。

# Securityログの器を確認: 保持モード・最大サイズ・現在の件数
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# いま実際に何日分残っているか(最古イベントの日時)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog はログの構成と件数をまとめて返します。⁹ 「最古イベントの日時」と現在の差が実際の保持日数で、これが自社の要件(インシデント調査で遡りたい日数)に足りなければ最大サイズを広げます。設定は wevtutil sl Security /ms:<バイト数> またはグループポリシーで配布できます。¹⁰

なお、セキュリティオプションには「監査: セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする」(いわゆるCrashOnAuditFail)という設定があります。有効時に監査を記録できなくなると、STOPエラー C0000244 でシステムが停止します。監査証跡を絶対に落とせない認証要件のための設定で、既定は無効です。攻撃者が大量のイベントを発生させて意図的にサーバーを止めるDoSに転化しうるとMicrosoft自身が注意しており、一般的な中小規模環境で安易に有効化すべきものではありません。¹⁹

6. 調べ方の実務 ── フィルター、Get-WinEvent、エクスポート

6.1. イベントビューアーでの絞り込み

単発の調査ならイベントビューアーで十分です。Securityログを開き、「現在のログをフィルター」でイベントID(例: 4625)と期間を指定します。繰り返し見る条件は「カスタムビューの作成」で保存しておくと、次回から1クリックです。イベントIDだけでなく特定アカウントなどで絞りたい場合は、フィルターダイアログのXMLタブでXPathクエリを直接編集できます。

6.2. Get-WinEventでの抽出

件数が多い調査・複数条件・定期実行は、PowerShellの Get-WinEvent に切り替えます。ポイントはフィルターをサーバー側で効かせる -FilterHashtable を使うことです。⁹

# 直近24時間のサインイン失敗(4625)を取得
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# 「誰が・どこから・なぜ」を表に整形する
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

イベントのXML表現からEventDataを引き抜くこの型を1つ持っておくと、4624でも4688でも同じ要領で使い回せます。Get-WinEvent の絞り込み設計(FilterHashtableとXPathの使い分け、遅いクエリの直し方)は「Get-WinEventでイベントログを実務的に調べる」で詳しく扱っています。

6.3. wevtutilでのエクスポート

調査対象マシンのログは、上書きで消える前にまずエクスポートして確保するのが原則です。¹⁰

rem Securityログを丸ごとevtxで保全
wevtutil epl Security C:\logs\security-20260801.evtx

rem 4625だけをXPathで絞ってエクスポート
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

エクスポートした .evtx は、別マシンで Get-WinEvent -Path C:\logs\security-20260801.evtx として同じように解析できます。⁹ 保全してから解析する習慣は、クラッシュ調査で「まずダンプを確保する」のと同じ発想です(「Windowsクラッシュダンプ収集入門」参照)。

7. 落とし穴 ── 現場で踏みやすい4つ

(1) 4688のコマンドラインに機密が乗る。 コマンドライン記録を有効にすると、すべてのプロセスの引数がSecurityログに平文で入ります。Microsoftは「セキュリティイベントの読み取りアクセス権を持つ全ユーザーが、あらゆるプロセスのコマンドライン引数を読める。引数にはパスワード等の機密が含まれうる」と明記しています。¹² myapp.exe /user:admin /password:P@ssw0rd のような起動をしている業務アプリ・スクリプトが1つでもあれば、それはログ閲覧者全員への機密公開です。有効化の前に、機密を引数渡ししている箇所を洗い出して直すこと。ログの保全・転送先でも同じ扱いレベルが必要になります。

(2) ログ満杯時の挙動を知らずに運用している。 上書きモードなら古い証跡が黙って消え、上書きしない設定なら新しいイベントが破棄され、CrashOnAuditFail有効ならシステムごと止まります(5章)。¹⁰¹⁹ どの挙動を選んでいるかを把握し、「消える前に集める」仕組み(定期エクスポートやログ収集基盤)を用意するのが本筋です。

(3) ドメインコントローラーと端末で見るべきログが違う。 4624/4625はアクセスされたマシンに記録されます。⁵⁶ 一方、ドメインアカウントの資格情報の検証(NTLMの4776)は資格情報に対して権威を持つマシン、つまりドメインアカウントならDCに記録され⁷、Kerberosの事前認証失敗(4771)はDCにしか記録されません。⁸ 「ファイルサーバーに4625がない=攻撃がなかった」ではなく、DC側の4776/4771も突き合わせて初めて全体像になります。どの認証プロトコルがどう流れるかは「図解でわかるNTLMとKerberos」を参照してください。

(4) 時刻同期がずれていると突合できない。 複数マシンのログを並べて「この4740の直前にどの端末で4625が出たか」を追う作業は、各マシンの時計が合っていることが前提です。ドメイン環境ではKerberos自体がクロックのずれに上限(既定5分)を設けており、それを超えると認証そのものが失敗し始めます。²⁰ 調査の観点では5分どころか数秒のずれでも前後関係を誤読させるので、w32timeの同期状態の確認を調査手順の最初に入れておくこと。また、イベントの記録時刻はUTCで保存され、表示は閲覧マシンのタイムゾーンに従うため、海外拠点やUTC設定のサーバーから持ってきたevtxを読むときはタイムゾーンの読み替えを忘れないでください。

8. まとめ

• 監査ポリシーは「基本」と「詳細」の2系統があり、混ぜると予期しない結果になります。詳細側で統一し、auditpol /get /category:* で現状を確認してから設計します。
• 「全部有効」はノイズと肥大化で調査を殺します。Microsoftのベースライン推奨を出発点に、ログオン・アカウント管理・プロセス作成を軸とした3章の判断表から始めてください。
• 4624はログオンタイプ、4625はStatus/Sub Statusコード、4740は呼び出し元コンピューター名、4688は親プロセスとコマンドライン ── 各イベントには「ここを見る」という急所があります。
• ログの器(最大サイズ・保持モード)は監査設計の半分です。実際に残っている日数を確認し、要件から逆算してサイズを決め、消える前にエクスポートまたは集約します。
• 4688のコマンドライン記録は機密混入のリスクを点検してから。マシンごとの記録場所の違いと時刻同期は、突合調査の前提条件です。
• 調査はイベントビューアーのフィルターで始め、繰り返すなら Get-WinEvent -FilterHashtable、保全は wevtutil epl。「まず保全、それから解析」の順番を崩さないこと。

関連記事

• Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める
• NTLM廃止で業務アプリは止まるか ── 監査ログの取り方と、依存を潰す順番
• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• SMB署名とLDAPチャネルバインディング ── NTLM対策の「残り半分」を実務で締める
• Windowsイベントログ・ETW入門 ── 業務アプリのログをOS標準の仕組みに乗せる
• Windowsクラッシュダンプ収集入門 - WER/ProcDump/WinDbg

関連する相談領域

合同会社小村ソフトでは、Windows環境の監査ポリシー・ログ設計の相談、イベントログにもとづく「いつ・誰が・何をしたか」の調査、業務アプリが認証・監査まわりで起こすトラブルの原因解析を扱っています。「ログを見てくれと言われたが、どこから手を付けるべきか」の段階からで構いません。

• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

監査ポリシーを何も設定していないのに、Securityログに4624や4625が記録されているのはなぜですか？

Windowsには既定で有効な監査サブカテゴリがあるためです。たとえば「ログオン」サブカテゴリは、Windows 10 バージョン1809以降では成功・失敗の両方が既定で有効なので、何も設定しなくても4624(成功)と4625(失敗)は記録されます。ただし既定のままでは、資格情報の検証(4776)やプロセス作成(4688)など、調査で欲しくなるイベントの多くは記録されません。自分の環境で何が有効かは auditpol /get /category:* で確認できます。そのうえで、足りないサブカテゴリを詳細な監査ポリシー側で明示的に有効化するのが実務の型です。

サインイン失敗を調べたいのに、対象サーバーのSecurityログに4625が見当たりません。どこを見ればよいですか？

まず、4625は「ログオンが試行されたコンピューター」に記録されるという原則を確認してください。ユーザーの端末でのサインイン失敗なら端末側、ファイルサーバーへのアクセス失敗ならファイルサーバー側です。次に auditpol /get /category:* で「ログオン」サブカテゴリの失敗の監査が有効かを確認します。ドメインアカウントの場合は、ドメインコントローラー側の資格情報の検証(4776)やKerberos事前認証失敗(4771)に記録が残っていることも多く、端末を特定できないときはむしろDC側から調べるほうが早道です。それでも見つからなければ、ログの上書きで過去分が消えていないか(ログの最大サイズと最古イベントの日時)を確認してください。

プロセス作成(4688)のコマンドライン記録は有効化すべきですか？

調査価値は非常に高い一方、リスクを理解してから有効化すべき設定です。有効化すると、すべてのプロセスのコマンドライン引数がSecurityログに平文で記録されます。コマンドラインにパスワードやAPIキーを渡すスクリプトや業務アプリが1つでもあると、その機密はSecurityログを読める全員に見える状態になります。Microsoft自身がこの注意点を明記しています。まず自社のスクリプト類が機密をコマンドライン引数で渡していないかを点検し、渡している箇所を直してから有効化する、という順番をお勧めします。

Securityログの最大サイズはどのくらいにすべきですか？

「何日分を手元に残したいか」から逆算するのが正攻法で、万能の数値はありません。現在の設定と実績は Get-WinEvent -ListLog Security で確認でき、最古イベントの日時と現在の日時の差が「いま実際に残っている日数」です。監査サブカテゴリを増やすとイベント量も増えるので、設定変更後に必ずこの実残存日数を再確認してください。インシデント対応では数週間〜数か月前のログが必要になることが珍しくないため、上書きで消える前に定期的にエクスポートするか、ログ収集の仕組みで別マシンに集約しておくと安心です。

アカウントロックアウト(4740)の原因はどうやって調べますか？

4740イベントの「呼び出し元コンピューター名(Caller Computer Name)」フィールドが最初の手がかりです。ここに、ロックアウトの引き金になった失敗ログオンの発生元コンピューターが記録されています。ただし、失敗の記録そのもの(4625)は発生源ではなくログオン試行を受け付けた側に残る点に注意してください。ネットワークログオン由来なら、アクセス先サーバーの4625や、ドメインアカウントならドメインコントローラーの4776/4771を時刻順に追います。そのうえで発生源として特定した端末側では、パスワード変更後も古い資格情報を持ち続けているもの、つまり保存済み資格情報、切断されたままのリモートデスクトップセッション、古いパスワードで構成されたサービスやスケジュールされたタスクを洗います。ロックアウトが繰り返される場合は、時刻同期がずれていないかも合わせて確認してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。