はじめに：なぜIT監査でWindowsイベントログが重要なのか

IT監査の現場で「証跡を見せてください」と言われたとき、あなたは自信を持って対応できますか？

Windows Event Viewer（イベントビューアー）は、Windowsに標準搭載されているログ管理ツールです。追加コストゼロで、システムの動作記録、セキュリティイベント、アプリケーションエラーなど、膨大な情報を確認できます。しかし、多くのIT担当者がその読み方を十分に理解しておらず、監査対応で苦労しているのが現実です。

本記事では、IT監査の実務で本当に使えるイベントログの読み方を、具体的なイベントID番号や実践的なフィルタリング手法とともに解説します。内部監査、外部監査、J-SOX対応など、さまざまな場面で活用できる知識を身につけましょう。

背景：IT監査におけるログ証跡の位置づけ

IT監査とログの関係性

IT監査では、「いつ」「誰が」「何をしたか」を証明することが求められます。これを実現するための最も基本的な証跡がシステムログです。

監査法人やIT監査人が確認する主な観点は以下の通りです：

• アクセス管理の妥当性：権限のある人だけがシステムにアクセスしているか
• 変更管理の適切性：システム変更が承認プロセスを経ているか
• 操作ログの完全性：重要な操作が記録され、改ざんされていないか
• インシデント対応の適時性：問題発生時に迅速に検知・対応しているか

Windows Event Viewerは、これらすべての観点に対する証跡を提供できる強力なツールなのです。

法的・規制要件との関連

日本のIT環境では、以下の規制やフレームワークがログ管理を要求しています：

これらの要件を満たすため、Windowsイベントログは最低限の基盤として機能します。

Windows Event Viewerの基本構造

イベントビューアーの起動方法

イベントビューアーを起動する方法は複数あります。実務では状況に応じて使い分けましょう。

方法1：検索バーから
Windowsキー → 「イベントビューアー」と入力 → Enter

方法2：ファイル名を指定して実行
Windowsキー + R → 「eventvwr.msc」と入力 → Enter

方法3：コマンドプロンプトから
eventvwr.exe

方法4：リモート接続
eventvwr.exe /s:リモートサーバー名

特に方法4のリモート接続は、複数サーバーの監査で重宝します。ただし、適切な権限（イベントログリーダー権限以上）が必要です。

主要なログカテゴリ

イベントビューアーを開くと、左ペインに複数のログカテゴリが表示されます。IT監査で特に重要なのは以下の4つです。

1. セキュリティログ（Security）

最も重要なログです。ログオン/ログオフ、特権使用、オブジェクトアクセス、アカウント管理など、セキュリティに関するイベントが記録されます。

• デフォルト最大サイズ：20MB（Windows Server 2019以降）
• 保存場所：%SystemRoot%\System32\Winevt\Logs\Security.evtx
• 閲覧権限：Administrators グループまたは Event Log Readers グループ

2. システムログ（System）

OSのコンポーネント、ドライバー、サービスに関するイベントが記録されます。システム停止、サービス起動失敗、ハードウェアエラーなどを追跡できます。

3. アプリケーションログ（Application）

アプリケーションプログラムが生成するイベントです。データベースエラー、アプリケーションクラッシュなどを確認できます。

4. セットアップログ（Setup）

Windowsのインストールやアップデートに関するイベントです。パッチ適用状況の監査で使用します。

イベントの構成要素

各イベントは以下の要素で構成されています：

【イベントの基本構造】
- 日時：イベント発生時刻（UTC または ローカル時刻）
- ソース：イベントを生成したコンポーネント名
- イベントID：イベントの種類を示す数値（1〜65535）
- タスクカテゴリ：イベントの分類
- レベル：重要度（情報、警告、エラー、重大、監査成功、監査失敗）
- ユーザー：関連するユーザーアカウント
- コンピューター：イベントが発生したマシン名
- 説明：イベントの詳細情報（テキスト形式）
- 詳細（XML）：構造化された詳細データ

IT監査で必ず押さえるべき重要イベントID

要点1：ログオン/ログオフイベント（Event ID 4624, 4625, 4634）

アクセス管理の監査で最も頻繁に確認するイベントです。

Event ID 4624（ログオン成功）

【重要なフィールド】
- TargetUserName：ログオンしたユーザー名
- TargetDomainName：ドメイン名
- LogonType：ログオンの種類（後述）
- IpAddress：接続元IPアドレス
- WorkstationName：接続元マシン名

ログオンタイプの意味（監査で特に重要）：

実務ポイント：本番サーバーへのログオンタイプ2または10が発生している場合、それが承認された作業かどうかを確認しましょう。

Event ID 4625（ログオン失敗）

【監査で注目すべきパターン】
- 同一アカウントで短時間に複数回の失敗 → パスワード総当たり攻撃の疑い
- 存在しないアカウントへの試行 → アカウント列挙攻撃の疑い
- 業務時間外の失敗 → 不正アクセス試行の疑い

失敗理由コード（Status/SubStatus）の例：

要点2：アカウント管理イベント（Event ID 4720, 4722, 4726, 4738）

特権アカウント管理の監査で重要なイベントです。

【主要なイベントID】
4720：ユーザーアカウント作成
4722：ユーザーアカウント有効化
4723：パスワード変更試行（本人による）
4724：パスワードリセット（管理者による）
4725：ユーザーアカウント無効化
4726：ユーザーアカウント削除
4738：ユーザーアカウント変更
4732：ローカルグループへのメンバー追加
4756：ユニバーサルグループへのメンバー追加

監査チェックポイント：

1. Administrators グループへの追加（Event ID 4732 + TargetUserName = Administrators）

   • 承認された変更管理チケットが存在するか
   • 作業者と承認者が分離されているか

2. 退職者アカウントの処理

   • 退職日付近で Event ID 4725（無効化）または 4726（削除）が発生しているか
   • 人事データとの突合が可能か

要点3：特権使用イベント（Event ID 4672, 4673）

管理者権限の使用状況を追跡するイベントです。

Event ID 4672（特別な特権の割り当て）

ユーザーがログオンした際に、そのユーザーに割り当てられた特権が記録されます。

【注目すべき特権】
SeSecurityPrivilege：監査ログの管理
SeBackupPrivilege：バックアップ権限（全ファイル読取可能）
SeRestorePrivilege：復元権限（全ファイル書込可能）
SeTakeOwnershipPrivilege：所有権の取得
SeDebugPrivilege：他プロセスのデバッグ（メモリダンプ取得可能）
SeImpersonatePrivilege：偽装（別ユーザーとして行動可能）

実務ポイント：本番環境で SeDebugPrivilege や SeBackupPrivilege が頻繁に使用されている場合、データ持ち出しリスクがないか確認しましょう。

要点4：監査ポリシー変更イベント（Event ID 4719, 4904, 4905）

監査設定自体の変更を追跡します。これらのイベントが不正に発生していないかは、ログの完全性を担保するうえで極めて重要です。

4719：システム監査ポリシーの変更
4902：ユーザーごとの監査ポリシーテーブルの作成
4904：セキュリティイベントソースの登録試行
4905：セキュリティイベントソースの登録解除試行

レッドフラグ（要注意パターン）：

• 業務時間外の監査ポリシー変更
• 変更管理プロセスを経ていない変更
• 監査設定の無効化

要点5：プロセス実行イベント（Event ID 4688）

プロセス（アプリケーション）の起動を追跡します。マルウェア検出やスクリプト実行の監視に有効です。

【重要なフィールド】
- NewProcessName：起動したプロセスのフルパス
- CommandLine：コマンドライン引数（要有効化）
- ParentProcessName：親プロセスのフルパス
- TokenElevationType：権限昇格の種類

実務で確認すべき不審なパターン：

- cmd.exe や powershell.exe がサーバー上で頻繁に起動
- 一時フォルダ（C:\Users\*\AppData\Local\Temp）からのEXE実行
- wscript.exe / cscript.exe による VBS スクリプト実行
- certutil.exe / bitsadmin.exe の使用（Living off the Land攻撃）

設定の有効化：コマンドライン引数のログ記録はデフォルトで無効です。以下のグループポリシーで有効化します。

コンピューターの構成 
→ 管理用テンプレート 
→ システム 
→ プロセス作成の監査 
→ プロセス作成イベントにコマンドラインを含める：有効

要点6：オブジェクトアクセスイベント（Event ID 4663, 4656）

ファイルやフォルダへのアクセスを追跡します。機密データへの不正アクセス検出に使用します。

4656：オブジェクトへのハンドル要求（アクセス試行）
4663：オブジェクトへのアクセス試行（実際のアクセス）
4660：オブジェクトの削除
4670：オブジェクトのアクセス許可の変更

設定のポイント：

オブジェクトアクセスの監査を機能させるには、2段階の設定が必要です。

1. 監査ポリシーの有効化（グループポリシー）

コンピューターの構成 
→ Windowsの設定 
→ セキュリティの設定 
→ 監査ポリシーの詳細な構成 
→ オブジェクトアクセス 
→ ファイルシステム：成功、失敗を有効化

2. 対象フォルダの監査設定（SACL）

対象フォルダを右クリック 
→ プロパティ 
→ セキュリティタブ 
→ 詳細設定 
→ 監査タブ 
→ 監査エントリを追加

注意：全ファイルへの監査設定はログ量が膨大になります。機密フォルダに絞って設定しましょう。

要点7：セキュリティログのクリアイベント（Event ID 1102）

セキュリティログがクリアされたことを示すイベントです。このイベント自体は新しいログに記録されるため、クリア操作を追跡できます。

【確認すべき内容】
- Subject\Security ID：クリアを実行したユーザー
- 発生日時：いつクリアされたか

監査上の重要性：ログのクリアは証跡隠滅の可能性があります。正当な理由（ログサイズ管理のための定期的なアーカイブなど）がない限り、重大なインシデントとして扱う必要があります。

要点8：サービスインストールイベント（Event ID 7045）

新しいサービスがインストールされたことを示すイベントです（システムログに記録）。

【重要なフィールド】
- ServiceName：サービス名
- ImagePath：サービス実行ファイルのパス
- ServiceType：サービスの種類
- StartType：起動の種類
- AccountName：サービスアカウント

監査チェックポイント：

• 本番サーバーへの新サービスインストールは変更管理対象
• 不審なサービス名やパスは要確認（マルウェアの永続化手法）

実践的なログ分析テクニック

フィルタリングの活用

大量のイベントから必要な情報を抽出するには、フィルタリングが不可欠です。

基本的なフィルター設定

【操作手順】
1. 対象のログを右クリック
2. 「現在のログをフィルター」を選択
3. 条件を設定

よく使うフィルター条件：

XMLフィルターによる高度な抽出

XMLクエリを使用すると、イベント内のフィールド値でフィルタリングできます。

例：Administratorsグループへの追加のみを抽出

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4732)]]
      and
      *[EventData[Data[@Name='TargetUserName']='Administrators']]
    </Select>
  </Query>
</QueryList>

例：特定IPアドレスからのRDP接続を抽出

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4624)]]
      and
      *[EventData[Data[@Name='LogonType']='10']]
      and
      *[EventData[Data[@Name='IpAddress']='192.168.1.100']]
    </Select>
  </Query>
</QueryList>

PowerShellによる効率的なログ収集

大量のログを処理する場合、PowerShellの使用が効率的です。

基本的なイベントログ取得

# 過去24時間のセキュリティイベントを取得
$startTime = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    StartTime = $startTime
} | Select-Object TimeCreated, Id, Message

# 特定のイベントIDでフィルタリング
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4624,4625
    StartTime = (Get-Date).AddDays(-7)
} | Export-Csv -Path "LogonEvents.csv" -Encoding UTF8

ログオン失敗の集計（ブルートフォース検出）

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        Time = $_.TimeCreated
        TargetUser = ($xml.Event.EventData.Data | 
            Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
        SourceIP = ($xml.Event.EventData.Data | 
            Where-Object {$_.Name -eq 'IpAddress'}).'#text'
        Status = ($xml.Event.EventData.Data | 
            Where-Object {$_.Name -eq 'Status'}).'#text'
    }
} | Group-Object TargetUser | 
    Select-Object Name, Count | 
    Sort-Object Count -Descending

複数サーバーからのログ収集

$servers = @("Server01", "Server02", "Server03")
$results = foreach ($server in $servers) {
    try {
        Get-WinEvent -ComputerName $server -FilterHashtable @{
            LogName = 'Security'
            Id = 4720  # ユーザー作成
            StartTime = (Get-Date).AddDays(-30)
        } -ErrorAction Stop | ForEach-Object {
            $xml = [xml]$_.ToXml()
            [PSCustomObject]@{
                Server = $server
                Time = $_.TimeCreated
                NewUser = ($xml.Event.EventData.Data | 
                    Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
                CreatedBy = ($xml.Event.EventData.Data | 
                    Where-Object {$_.Name -eq 'SubjectUserName'}).'#text'
            }
        }
    } catch {
        Write-Warning "Failed to connect: $server"
    }
}
$results | Export-Csv "UserCreation_Report.csv" -Encoding UTF8

監査対応のための実務ポイント

監査ポリシーの推奨設定

効果的な監査を行うには、適切な監査ポリシーの設定が必要です。以下は、CIS Benchmark や Microsoft のセキュリティベースラインを参考にした推奨設定です。

ログの保存期間とアーカイブ

法的要件に基づく保存期間の目安：

ログサイズの見積もり（参考値）：

• ドメインコントローラー（1000ユーザー環境）：1日あたり約500MB〜2GB
• ファイルサーバー（オブジェクトアクセス監査有効）：1日あたり約1〜5GB
• 一般的なメンバーサーバー：1日あたり約50〜200MB

定期的な監査レポートの作成

IT監査では、定期的なレビュー証跡が求められることがあります。以下のようなレポートを月次で作成しておくと、監査対応がスムーズになります。

月次レポート例：

1. アカウント変更サマリー

   • 新規作成アカウント一覧
   • 削除/無効化アカウント一覧
   • 特権グループメンバーシップ変更一覧

2. ログオン状況レポート

   • ログオン失敗Top10アカウント
   • 業務時間外ログオン一覧
   • 初回ログオンアカウント一覧

3. 特権使用レポート

   • 管理者アカウント使用状況
   • サービスアカウント動作確認

よくある質問（FAQ）

Q1：イベントログが「監査失敗」で溢れています。どう対処すべきですか？

A1：まず、大量の監査失敗イベントの原因を特定することが重要です。

よくある原因と対処法：

1. サービスアカウントのパスワード有効期限切れ

   • Event ID 4625 で同一アカウントが大量に記録
   • 対処：サービスアカウントのパスワードを更新し、関連サービスを再起動

2. 古い資格情報のキャッシュ

   • ユーザーが過去のパスワードでアクセスを試行
   • 対処：ユーザーに再ログオンを依頼、資格情報マネージャーをクリア

3. スキャン/攻撃試行

   • 異なるアカウント名での連続失敗
   • 対処：送信元IPをファイアウォールでブロック、アカウントロックポリシーの確認

4. アプリケーションの認証設定ミス

   • 特定アプリケーションからの定期的な失敗
   • 対処：アプリケーション設定の確認と修正

実務ポイント：大量のノイズを放置すると、本当の攻撃を見逃すリスクがあります。原因を特定して解消することが、効果的な監査の第一歩です。

Q2：リモートサーバーのイベントログを一元管理するにはどうすればよいですか？

A2：Windowsには「イベントサブスクリプション」という機能があり、複数サーバーのログを1台のコレクターサーバーに集約できます。

基本的な設定手順：

1. コレクターサーバーでの設定

# Windowsリモート管理サービスの有効化
winrm quickconfig

# イベントコレクターサービスの有効化
wecutil qc

2. ソースサーバー（ログ送信元）での設定

# Windowsリモート管理サービスの有効化
winrm quickconfig

# コレクターサーバーのマシンアカウントを
# Event Log Readers グループに追加
net localgroup "Event Log Readers" DOMAIN\CollectorServer$ /add

3. サブスクリプションの作成

• コレクターサーバーでイベントビューアーを開く
• 「サブスクリプション」を右クリック → 「サブスクリプションの作成」
• 収集するイベントとソースコンピューターを指定

代替手段：

大規模環境では、以下のSIEM製品やログ管理ツールの使用を検討しましょう。

• Splunk
• Elastic Stack（ELK）
• Microsoft Sentinel
• Graylog