イベントID5145は、ネットワーク共有内のファイル・フォルダーへのアクセス権をチェックした記録です。ユーザーの操作回数や、ファイルを実際に変更した回数を直接数えるログではありません。同じ共有名の記録が続いても、件数だけで正常・異常やSMB Multichannelの影響を決めず、対象・権限・結果を確認します。
イベントID5145とは？成功・失敗で分かる範囲
Microsoftの5145の定義では、クライアントに要求したアクセスを許可できるかを確認したイベントとされています。監査カテゴリは「詳細なファイル共有の監査」（Audit Detailed File Share）です。共有を提供するサーバーのSecurityログで、成功／失敗を含めて確認します。
- 成功：共有側のアクセスチェックが許可された記録。要求されたWriteDataやDELETEがあっても、これだけで書き込み・削除の完了を確定しません。
- 失敗：共有レベルで拒否された場合の記録。Microsoftの定義上、NTFSレベルで拒否された場合の失敗5145は生成されません。
- 5145が見つからない：該当監査の成功・失敗設定、対象サーバー、時間帯、ログの保存範囲も確認します。「イベントがない＝アクセスがなかった」とは限りません。
Access Deniedの原因を調べるときは、共有権限とNTFS権限を分けます。5145の失敗がないことだけで、NTFS権限に問題がないと判断しないでください。
大量発生を調べる：同じ表示と同じイベントを区別する
フォルダー内の複数対象へのアクセスや、アプリが行う追加のアクセスチェックを含めれば、画面上の一操作とイベント数は一致しません。ただし、似た記録が並ぶことだけでは、特定のアプリ・バックグラウンド処理・通信方式が原因とは断定できません。
- まず送信元サーバーのSecurityログと、WEF／SIEM等の収集先を比較します。収集先だけで同じ原イベントが複数表示されていないか確認します。
- 元イベントのComputer・Channel・EventRecordID・時刻を比較します。原ログで異なるRecordIDなら別の記録です。収集先の表示用IDではなく、元イベントの情報を使います。
- 別の記録同士を、アカウント・SubjectLogonId・IPアドレス・共有名・RelativeTargetName・AccessMask・結果で比較します。共有名だけ同じでも、対象ファイルや要求権限が違うことがあります。
- 通常時と問題発生時を同じ時間幅で比較します。失敗の増加、想定外のIPやアカウント、重要ファイルへのアクセスを優先して調べます。
同じComputer・Channel・EventRecordID等の原情報が繰り返し届くなら、収集経路の重複を調べる手掛かりになります。ただしRecordIDは全サーバー・全期間で共通の識別子ではないため、ログのクリアや再作成をまたぐ比較では保存時期と原データも照合します。
IpPortの違いは送信元ポートの違いを示すだけで、SMB Multichannelが有効なことや、特定処理が重複したことの証明ではありません。件数を減らす目的だけでMultichannelを無効化したり、保護ソフトの例外を増やしたりせず、まず元ログと再現条件を保存します。
5145のXMLで確認する項目
イベントビューアーで記録を開き、「詳細」→「XML表示」を確認します。画面の訳語とXMLの名前を混同せず、次の組み合わせで追います。
| XMLの項目 | 確認すること |
|---|---|
| SubjectUserName／SubjectDomainName／SubjectLogonId | アクセスしたアカウントとログオンの関連付け |
| IpAddress／IpPort | クライアントのアドレスと送信元ポート |
| ShareName／ShareLocalPath／RelativeTargetName | 共有・サーバー内のパス・共有内の対象。ShareNameのサーバー部分は\\*形式であり、Computerも併用する |
| AccessMask／AccessList／AccessReason | 要求権限の数値・表示名と、許可／拒否の理由 |
| System内のTimeCreated／Computer／Channel／EventRecordID | 時刻・記録元と、原イベントの照合 |
同じアカウント名でもログオンが異なる場合があります。SubjectLogonIdを他のログオン関連イベントと合わせて追い、時刻のタイムゾーンやSIEMの変換もそろえます。対象パスやユーザー名を含むログは、管理者指定の経路で必要な範囲を共有してください。
5140・5145・4663・4660の違い
| イベント | 示すもの | 判断上の注意 |
|---|---|---|
| 5140 | ネットワーク共有へのアクセス | セッション内の最初のアクセス試行で一度記録される。ファイルごとの操作一覧にはならない |
| 5145 | 共有内の対象に対するアクセスチェック | 要求権限と共有側の許可／拒否を読む。実変更完了とは別 |
| 4663 | オブジェクトに対して権限を使用した操作 | 対応する監査ポリシーとSACLが必要。4663自体には失敗イベントがない |
| 4660 | オブジェクトが実際に削除された記録 | 対象名は含まれず、Handle ID等で周辺イベントと関連付ける |
5140の記録タイミングは、セッション内の最初の共有アクセス試行です。「セッション確立ログ」「一ファイルに一件」と読み替えないでください。
4663の定義は権限が使用されたことを示しますが、DELETEが表示される場合でも名前変更等があり、実際の削除の確定には使えない場合があります。4660の定義では実削除を扱い、ファイル名がないためHandle IDと周辺のファイル監査を照合する必要があります。
「誰がどのファイルを変更・削除したか」が目的なら、5145だけを操作履歴へ変換せず、必要なファイルシステム監査と対象のSACLを設計します。フォルダーへの継承・対象ユーザー・必要な権限・成功／失敗の設定を検証用環境で確認し、収集するイベントに不足がないか試します。
イベントビューアーのフィルター：まず5145を抽出する
SecurityログのフィルターでイベントIDを5145に絞るか、カスタムビューのXMLに次の基本クエリを使います。これは表示対象の絞り込みで、監査ポリシーや原ログは変更しません。
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=5145]]</Select>
</Query>
</QueryList>WindowsイベントログのXPathはXPath 1.0の一部に限定されます。通常のXPathで使うcontains()をAccessMaskの文字列検索に流用しないでください。また、文字列の部分一致では権限ビットを判定できません。たとえば0x10002は0x2のビットを含みますが、「0x2」という文字列は含みません。
PowerShellでAccessMaskのビットを判定する例
次は、直近30分の5145を取得し、WriteData/AddFile（0x2）またはDELETE（0x10000）が要求されたチェックだけを表示する読み取り用の例です。Get-WinEventで時間とイベントIDを絞り、XMLのAccessMaskを整数に変換してビット演算の-band／-borで判定します。
# 共有を提供するサーバー上で、Securityログを読む権限で実行
# 直近30分の5145のうち、新しいものから最大1000件を取得
$start = (Get-Date).AddMinutes(-30)
$events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 5145
StartTime = $start
} -MaxEvents 1000 -ErrorAction Stop
# 例：WriteData/AddFile または DELETE が要求されたチェックだけを表示
# 他の変更権限や失敗イベントを網羅するフィルターではない
[uint32]$wanted = 0x2 -bor 0x10000
foreach ($event in $events) {
[xml]$xml = $event.ToXml()
$data = @{}
foreach ($item in $xml.Event.EventData.Data) {
$data[[string]$item.Name] = [string]$item.'#text'
}
$hex = $data['AccessMask'] -replace '^0x', ''
[uint32]$mask = [Convert]::ToUInt32($hex, 16)
if (($mask -band $wanted) -ne 0) {
[pscustomobject]@{
Time = $event.TimeCreated
Computer = $event.MachineName
RecordId = $event.RecordId
User = $data['SubjectUserName']
IpAddress = $data['IpAddress']
IpPort = $data['IpPort']
ShareName = $data['ShareName']
RelativeTargetName = $data['RelativeTargetName']
AccessMask = $data['AccessMask']
AccessReason = $data['AccessReason']
}
}
}取得上限は新しいものから1000件で、30分間の全件取得や件数統計を保証しません。イベント量が多い場合は検証区間を短くするか、保存したログを対象に計画して集計します。該当イベントがない場合やSecurityログを読む権限がない場合のエラーは、それぞれ期間・監査設定・権限を確認してください。
この例は「要求された権限」の一部を表示するだけです。AppendData、DeleteChild、WriteAttributes、権限変更等を含むすべての変更権限を網羅せず、成功・失敗も自動判別しません。出力と原イベントの監査結果を合わせて読み、表示されない記録を原ログや収集設定から一括削除する条件にしないでください。
ログ量を抑える前に監査の目的を確認する
詳細なファイル共有監査の公式説明では、ファイルサーバーやSYSVOLへのアクセスがあるドメインコントローラーでイベント量が多いとされています。この監査には共有フォルダーごとのSACLがなく、有効にするとシステム上の共有ファイル・フォルダー全体が対象になります。
特定フォルダーだけの監査が必要なら、File System監査と対象ファイル／フォルダーのSACLを検討します。ただし5145と同じ情報がそのまま得られるわけではなく、クライアントIP等の情報差があります。目的の証跡を定義してから方式を選びます。
- 元ログを保存し、調査用ビューや通知で対象共有・アカウント・IP・権限・結果を絞ります。読み取りも情報アクセスの調査には必要な場合があります。
- 短時間の同一アカウント・パスの記録を集約して表示する場合、原イベントの件数と参照情報を残します。数秒内の集約件数を「ユーザー操作一回」と断定しません。
- 成功監査を停止すると成功アクセスの証跡が失われます。失敗だけで足りるか、組織の監査目的と保存要件を確認してから設定を見直します。
- 設定変更の前後で、必要な成功・失敗のケースが収集先まで届くか、保存期間内にログが上書きされないかを確認します。
検証結果を残して原因と改善を判断する
検証では、許可された検証用の共有とアカウントで開始・終了時刻を控え、何も操作していない時間、フォルダーを開いた時間、検証用ファイルを保存した時間を分けて比較します。5145の件数だけで保存回数を数えず、対象パス・要求権限・結果と、必要なファイル監査を照合してください。
問題を管理者へ渡すときは、Windows Serverの版・ビルド、実際に適用された監査設定、検証の時刻・対象・手順、成功／失敗別の元ログ件数と収集先の件数を添えます。「同じ5145が多い」という表示だけより、どの段階で記録が増えたかを説明できます。
コメント