ファイルサーバーのアクセスログを調査|共有フォルダの閲覧・変更・削除履歴

ファイルサーバーや共有フォルダの操作は、監査設定が有効で必要なログが残っていれば、使用されたアカウント、アクセス日時、接続元、共有名、対象ファイルやフォルダ、要求・実行されたアクセスの種類などを確認できる場合があります。

Windows Serverでは、Securityログのイベント5140・5145・4663などが調査対象になることがあります。5140はネットワーク共有へのアクセス、5145は共有内のファイルやフォルダへのアクセス試行、4663はSACL等の条件を満たしたオブジェクトに対して特定のアクセス権が実際に使用されたことを確認する手掛かりです。

ただし、ファイルサーバーに「アクセスログがある」だけで、次の事実をすべて同じように判断できるわけではありません。

  • 共有フォルダへ接続した
  • 特定のファイルへアクセスした
  • ファイルの内容を人が読んだ
  • ファイルを別の場所へコピーした
  • ファイルを削除した
  • 記録されたアカウントの名義人本人が操作した
  • その操作が不正行為だった

これらは、それぞれ別の事実です。

また、必要な監査が事前に有効になっていなかった場合や、古いログが上書きされている場合には、過去の操作をサーバー側だけから完全に遡れないこともあります。

この記事では、すでに共有ファイルの閲覧・変更・削除・情報持ち出し等が疑われている企業を想定し、ファイルサーバーやNASに残る記録から、何が分かり、何は別の証拠が必要なのかを整理します。

ファイルサーバーのアクセスログだけでなく、Wi-Fi、RDP、遠隔操作などサーバー・ネットワークに残る証拠全体を確認したい場合は、サーバー・ネットワークフォレンジックで、主な調査項目と確認方法をまとめています。

ファイルサーバーの操作履歴は後から確認できる?

確認できる場合がありますが、どこまで遡れるかは、当時の監査設定とログの保存状態によって変わります。

調査では、最初に「誰が何をしたか」を一括して探すのではなく、確認したい行為を分けます。

例えば、

  • 共有フォルダへ接続したのか
  • 特定のファイルへアクセスしたのか
  • 読み取り・書き込み・削除等の操作があったのか
  • どのアカウントが使用されたのか
  • どのIPアドレスや端末から接続したのか
  • PCへファイルをコピーした可能性があるのか

によって、確認するログや証拠は異なります。

Windows Serverでは、詳細なファイル共有監査を有効にすると、共有上のファイルやフォルダへのアクセスに関するイベントを記録できます。一方、通常のファイル共有監査は、クライアントと共有の接続について、より大きな単位で記録する仕組みです。Microsoftも両者を区別しています。

そのため、

「共有へ接続した記録がある」=「共有内の特定ファイルを開いた」

とは判断しません。

調べたいファイル、対象期間、対象アカウントを絞り、複数の記録を時系列で照合することが重要です。

監査ログが残っていなければ分からないこともある

ファイルアクセス監査は、問題が発覚してから有効にしても、過去の操作が遡って生成されるわけではありません。

Windowsのファイルシステム監査では、監査ポリシーだけでなく、対象オブジェクト側のSACL等の条件も関係します。4663も、対象オブジェクトのSACLに必要なACEが存在する場合に生成されるイベントです。

さらに、ログが以前は存在していても、

  • Securityログの最大サイズに達して古い記録が上書きされた
  • 保持期間を過ぎた
  • 対象フォルダが監査対象ではなかった
  • 必要な監査サブカテゴリが無効だった
  • 別のサーバーやNASに記録されている
  • 操作経路が想定していたものと異なる

といった可能性があります。

Windowsのイベントログは、設定によっては最大サイズに達した際に古いイベントを上書きします。したがって、調査時点で古いログが見つからないことがあります。

重要なのは、

「ログが見つからなかった」=「その操作は存在しなかった」

と置き換えないことです。

サーバー側のログが不足している場合は、対象PC、バックアップ、スナップショット、EDR・DLP等の周辺システムに調査範囲を広げます。

ファイルサーバー調査で確認する主な証拠

ファイルサーバーの操作履歴を調べる場合、一つのログだけで結論を出すのではなく、目的に応じて複数の証拠源を確認します。

Windows ServerのSecurityログ

Windows Serverでは、ファイルや共有へのアクセスに関する監査イベントがSecurityログに記録される場合があります。

代表的なものとして、

  • 4663
  • 4660
  • 5140
  • 5145

等があります。

ただし、イベントIDだけを検索して結論を出すのではなく、そのイベントが生成される監査条件と、イベント内の各フィールドを確認する必要があります。

ファイルアクセス監査と4663

イベント4663は、対象オブジェクトに対して特定のアクセス権が実際に使用されたことを示します。

対象がファイルの場合は、

  • アカウント
  • Object Name
  • Accesses
  • Access Mask
  • Process Information

等が調査材料になります。

ただし4663は、ファイルを人が画面上で読んだことを直接証明するイベントではありません。

例えば、ファイルへの読み取りアクセスが記録されていても、

  • アプリケーションによる処理
  • ウイルス対策ソフト
  • バックアップ
  • インデックス処理
  • プレビュー
  • その他のサービス

等によるアクセスも検討する必要があります。

4663の記録は「アクセス権が使用された」という事実として扱い、人の認知行為である「内容を読んだ」まで自動的に広げないことが重要です。

SMB共有の5140と5145

イベント5140は、ネットワーク共有オブジェクトへのアクセスに関する記録です。

Microsoftの資料では、5140は最初のアクセス試行時に、セッションごとに1回生成されると説明されています。したがって、5140があるだけで、その共有内にあるすべてのファイルを閲覧したとは判断できません。

一方、5145は詳細なファイル共有監査に関係し、

  • アカウント
  • 接続元IPアドレス
  • Share Name
  • Share Path
  • Relative Target Name
  • Accesses
  • Access Mask

等を確認できます。

この違いは、ファイルサーバー調査では重要です。

共有へ接続したことと、その中の特定ファイルへのアクセスは分けて評価します。

NAS側のログ

SynologyやQNAP等のNASにも、製品・OS・設定によってファイル操作やアクセスに関するログが残る場合があります。

ただし、

「NASだから同じログが必ずある」

とは考えません。

使用製品、DSM・QTS等のOS、利用プロトコル、監査設定、ログの保存先、保持期間を確認します。

クライアントPC側の証拠

サーバー側の記録だけで結論が出ない場合は、接続元PC側も調べます。

例えば、

  • LNK
  • Jump Lists
  • Recent Files
  • ShellBags
  • MFT
  • USNジャーナル
  • Windowsログオン履歴
  • RDP等の遠隔接続履歴
  • USB接続履歴
  • ブラウザ履歴
  • クラウド同期の痕跡

等が、サーバー側の記録を補強する材料になる場合があります。

ただし、各アーティファクトの存在を、そのままコピーや不正行為の証明には使用しません。

接続元PC側のLNK・Jump Lists、MFT・USN、USB、アプリ実行などを詳しく調べる場合は、Windows・PCフォレンジックに各調査方法をまとめています。

誰が共有フォルダへアクセスしたか分かる?

監査ログが適切に取得されていれば、共有へアクセスした際に使用されたアカウントや接続元を確認できる場合があります。

例えば5140では、共有へのアクセスに関係するアカウントやネットワーク情報を確認できます。

5145では、さらにRelative Target Name等から、共有内のどのファイル・フォルダに対するアクセスだったのかを検討できます。

ただし、

共有フォルダにアクセスした

ことと、

共有内の特定ファイルを閲覧した

ことは別です。

まず共有への接続を確認し、その後に5145やファイルシステム監査等から、個々の対象へのアクセスを絞り込みます。

誰がファイルを開いたか分かる?

ファイルへの読み取り等のアクセスを確認できる場合はありますが、「人が画面上で内容を読んだ」ことまで一つのログで確定できるとは限りません。

例えば、4663や5145で対象ファイルへの読み取りに関係するアクセスが記録されていても、それが、

  • Explorerから開いたものか
  • Office等のアプリで開いたものか
  • プレビューされたものか
  • 自動処理されたものか
  • バックアップ等によるアクセスか

を区別する必要があります。

そのため、必要に応じて、

  • Process Information
  • 対象PCのLNK
  • Jump Lists
  • 最近使ったファイル
  • Office等の利用痕跡
  • 同時間帯のログオン状況

等を照合します。

ファイルアクセス=人が本文を閲読した

と断定しないことが重要です。

誰がファイルを変更したか分かる?

監査対象になっていれば、書き込み等に使用されたアカウントや対象ファイルを確認できる場合があります。

Windowsのファイルアクセス監査では、4663のAccesses等から、対象オブジェクトにどのようなアクセス権が使用されたかを検討できます。

さらに、対象がNTFSの場合には、MFTやUSNジャーナルから、

  • 作成
  • データ変更
  • 名前変更
  • 移動
  • 削除

等のファイルシステム上の変化を検討できる場合があります。

ただし、

ファイルの更新時刻だけで、誰が変更したかを決めることはできません。

また、変更記録があっても、

変更した=不正に改ざんした

という意味ではありません。

業務上の編集、アプリによる更新、同期等も含め、アカウント、プロセス、時刻、業務内容を照合します。

過去のファイル内容を比較したい場合は、バックアップやVSS、NASのスナップショット、バージョン管理等が役立つ場合があります。

誰がファイルを削除したか分かる?

必要な監査ログが残っていれば、削除に使用されたアカウントや対象ファイルを絞り込める場合があります。

Windowsのファイルシステム監査には、オブジェクトの削除に関係する4660などのイベントがあります。また、4663や5145のアクセス情報も、前後関係を確認する材料になります。

調査では、

  • 対象ファイル名・パス
  • 削除に関係するイベント
  • アカウント
  • Logon ID
  • 接続元IP
  • 操作前後のイベント
  • クライアントPC側の痕跡
  • バックアップ・VSS・NASスナップショット

等を照合します。

ここでも、

削除に使われたアカウント=実際に操作した人物本人

ではありません。

また、

削除操作が確認できた=削除されたファイル本体を復元できる

という意味でもありません。

VSSはある時点のボリューム状態をシャドウコピーとして保持する仕組みであり、存在するスナップショットから過去状態を確認できる場合があります。一方、VSS自体が操作者を記録する仕組みではありません。

ファイルをコピーしたことまで分かる?

ファイルサーバー側で読み取りアクセスが確認できても、それだけで「ローカルPCへコピーした」とは断定できない場合があります。

ファイルをサーバーからPCへコピーする場合、サーバー側から見ると、元ファイルへの読み取り等が発生します。

しかし、読み取りは、

  • ファイルを通常どおり開いた
  • プレビューした
  • バックアップした
  • 検索・インデックス処理を行った
  • アプリが自動的に読み込んだ

場合にも起こり得ます。

したがって、コピーを確認したい場合は、サーバー側だけでなく、コピー先と考えられるPC側も確認します。

例えば、

サーバー側

  • 対象ファイルへの読み取り
  • SMBアクセス
  • 対象アカウント
  • 接続元
  • 時刻

クライアントPC側

  • コピー先候補の実ファイル
  • MFT
  • USNジャーナル
  • LNK
  • Jump Lists
  • Recent Files
  • USB接続履歴
  • クラウド同期履歴

等を時系列で照合します。

つまり、

「読み取った」≠「コピーした」

です。

コピー元とコピー先の両方を確認し、必要に応じてファイル内容やハッシュ値も比較します。

共有フォルダへの大量アクセスは情報持ち出しの証拠になる?

短時間に大量のファイルへアクセスした記録は重要な手掛かりになりますが、それだけで大量持ち出しとは断定できません。

大量アクセスは、

  • バックアップ
  • ウイルススキャン
  • インデックス作成
  • 全文検索
  • 同期ソフト
  • 業務アプリ
  • バッチ処理

等によっても発生する可能性があります。

調査では、

  • 対象アカウント
  • 接続元PC
  • アクセス対象
  • 件数
  • 時間帯
  • 使用プロセス
  • 通常業務との違い
  • その後のUSB・クラウド・メール等の操作

を確認します。

例えば、退職前の短時間に大量の機密ファイルへの読み取りが集中していても、その事実だけでは「持ち出した」とは言いません。

一方、その直後にPC側で大量のファイル生成や圧縮、USB利用、クラウドへのアップロード等の記録が整合すれば、評価できる事実の範囲が広がります。

ユーザー名が分かれば操作した人物まで特定できる?

ログにアカウント名が記録されていても、その名義人本人が実際に操作したとは自動的に確定しません。

例えば、

DOMAIN\UserA

というアカウントが記録されていた場合に分かるのは、まず、

その操作でUserAの資格情報・セキュリティコンテキストが使用された

ということです。

実際の人物を評価する場合は、

  • 共有アカウントではないか
  • 認証情報が他人に知られていないか
  • RDP等で遠隔利用されていないか
  • AnyDesk・TeamViewer等の遠隔操作がないか
  • サービスアカウントやバッチではないか
  • 管理者による代理操作ではないか

等も検討します。

5145にはLogon IDが含まれ、Microsoftも4624等のログオンイベントと関連付ける手掛かりになると説明しています。接続元IP等と合わせて、ログオン履歴や遠隔接続履歴を照合できます。

必要に応じて、

  • Windowsログオン履歴
  • RDP接続履歴
  • 接続元IP
  • EDR
  • VPN
  • 勤怠
  • 入退室記録

等も確認します。

アカウントの特定と人物の特定は、分けて考える必要があります。

サーバー側ログがない場合はPC側の痕跡を確認する

サーバー側に必要なログが残っていなくても、対象PC側に関連する痕跡が残っている場合があります。

代表的な確認対象は次のとおりです。

PC側の証拠確認できる可能性があること単独では言えないこと
LNKファイル・保存場所の利用に関する手掛かりコピーの確定
Jump Listsアプリとファイルの利用関係本文を人が読んだこと
Recent Files等最近利用されたファイルの手掛かり不正利用
ShellBagsフォルダ参照・ナビゲーションの手掛かり個々のファイルを読んだこと
MFT・USNPC上のファイル作成・変更等コピー元の自動確定
USB関連記録外部媒体が接続された手掛かりファイルをコピーしたこと
Windowsログオンアカウントセッション名義人本人の操作
RDP・遠隔操作痕跡遠隔利用の手掛かり個々のファイル操作の全内容

例えば、

\\server\share\folder\file.xlsx

のようなUNCパスに関係する履歴がPC側で確認できる場合があります。

しかし、

UNCパスが残っている=そのファイルをPCへコピーした

とは判断しません。

サーバー上のアクセス時刻とPC側のファイル利用・生成記録を対応付けることで、一つの証拠だけでは判断できなかった操作を検討します。

Synology・QNAP等のNASでも操作履歴は確認できる?

NASでも確認できる場合がありますが、記録内容は製品・OS・利用サービス・設定によって大きく異なります。

Synology

Synologyは、DSMのLog CenterでSMB等のファイル転送ログを利用する方法を案内しています。

公式資料では、ファイル転送ログは通常は初期状態で無効であり、利用するプロトコル側で有効にする必要があるとされています。

DSMのSMB Transfer Logでは、有効化しただけの場合は削除のみが記録対象となり、Move・Delete・Rename等、必要な操作をLog Settingsで選択できます。ログには時刻、IPアドレス、ユーザー、イベント、ファイル名等が含まれます。

したがって、

「Synologyを使っていた=過去の全ファイル操作ログがある」

とは判断できません。

QNAP

QNAPのQuLog Centerでもアクセスログを設定できます。

QNAP公式資料では、アクセスログを有効にするにはログの保存先を設定し、記録する接続タイプ等を指定する仕組みが説明されています。また、保持時間も設定対象です。

NASを調査する場合は、

  • 製品名
  • モデル
  • OS・バージョン
  • SMB等の利用方式
  • ログ設定
  • 保存先
  • ローテーション・保持期間
  • スナップショット
  • ごみ箱機能

を確認します。

製品名だけから、存在するログや保持期間を決めつけないことが重要です。

ファイルサーバーのログで分かること・分からないこと

ファイルサーバー調査では、それぞれの記録が支える範囲を区別します。

記録・証拠比較的言いやすいことそれだけでは言えないこと
5140ネットワーク共有へのアクセス共有内の特定ファイルを読んだ
5145共有内の対象ファイル・フォルダへのアクセス試行や要求された権利人が内容を読んだ、PCへコピーした
4663対象オブジェクトで特定のアクセス権が使用された名義人本人の操作、操作目的
4660等オブジェクト削除に関係する記録不正な削除、削除者本人の確定
アカウント名使用されたアカウント名義人本人
接続元IP通信元を絞る手掛かり実際の人物本人
NASファイル操作ログ設定対象となった操作・ユーザー・時刻等NAS上の過去全操作
MFT・USNファイルの作成・変更・削除等の手掛かりファイルを読んだ人物やコピー先
LNK・Jump Lists等ファイル・保存場所の利用に関する手掛かりコピーの確定
VSS・スナップショット過去時点のファイル内容を確認できる可能性操作した人物
ログが存在しない調査時点で該当記録を確認できなかった操作が存在しなかった

特に重要なのは、

「記録があるか」ではなく、「その記録が何を証明できるか」

です。

一つのログを強く読み過ぎず、複数の証拠が同じ時系列・対象・アカウントを支えているかを確認します。

調査前に保存するもの・避けたい操作

社内不正、情報持ち出し、懲戒、訴訟等で後から証拠として説明する可能性がある場合は、原因確認のための操作そのものが既存の記録を変えないよう注意が必要です。

状況に応じて保存を検討するものには、

  • Windows Event Logs
  • NASのアクセスログ・操作ログ
  • 現在の監査設定
  • ログ保持設定
  • 対象ファイル・フォルダ
  • バックアップ
  • VSS・NASスナップショット
  • 対象クライアントPC
  • ディスクイメージ
  • 取得日時
  • 取得者
  • 取得方法
  • 必要なハッシュ値

等があります。

一方、事情を確認しないまま、

  • ログを削除する
  • NASを初期化する
  • サーバーを再構築する
  • 対象PCを初期化する
  • 復元ソフトを対象媒体へインストールする
  • 大きな設定変更を行う

と、既存状態が変わる可能性があります。

特に「過去のログがないから、今すぐ監査を有効化して試す」という操作は、将来の記録には役立っても、過去の証拠を新たに作るものではありません。

インシデントが継続中で、被害拡大を止める必要がある場合は、証拠保全を理由に被害を放置するのではなく、アクセス停止等の対応内容、実施者、日時を記録したうえで対応します。

自社確認で足りる場合とフォレンジック調査を検討する目安

すべてのファイルサーバーの問題で専門的なフォレンジック調査が必要なわけではありません。

目的と残っている証拠によって判断します。

状況自社確認で対応しやすい専門調査を検討
最近の共有アクセスを確認したい○必須ではない
監査ログが十分残っている○~△必要に応じて
特定ファイルの削除アカウントを確認したい△条件による
ログが上書き・欠落している△○
PC側との突合が必要△○
ファイルコピー・情報持ち出しまで確認したい△○
複数PC・複数サーバー・NASが関係する△○
アカウントではなく実際の人物が争点△○
懲戒・訴訟等で第三者への説明が必要△○

例えば、管理者が「昨日、誰がこの共有へ接続したか」を確認するだけで、必要なログが残っている場合は、自社で確認できることがあります。

一方、

  • サーバー側ログとPC側の証拠を照合したい
  • コピー・情報持ち出しまで調べたい
  • 削除されたデータも確認したい
  • 複数の証拠を時系列化したい
  • アカウントと実際の人物を区別したい
  • 後から調査手順を説明できる形で保全したい

といった場合は、フォレンジック調査を検討する意味があります。

デジタルフォレンジックPROでは、ファイルサーバー・NAS監査ログ、Windowsのファイルアクセス監査、MFT・USN、LNK・Jump Lists等を、社内不正調査で利用する主要なアーティファクトとして公表しています。実際の案件では、単独の記録から断定するのではなく、調査目的に応じて必要な証拠を組み合わせます。

まとめ

ファイルサーバーや共有フォルダの操作履歴は、監査設定やログの保持状況によって、使用されたアカウント、接続元、対象ファイル、アクセスの種類等を確認できる場合があります。

ただし、次の事実は分けて評価する必要があります。

  • 共有へ接続したことと、特定ファイルへアクセスしたことは別
  • ファイルアクセスと、人が内容を読んだことは別
  • 読み取りと、PCへのコピーは別
  • 削除操作と、削除ファイルの復元は別
  • アカウントと、実際の人物本人は別
  • 大量アクセスと、情報持ち出しは別
  • ログが見つからないことと、操作が存在しなかったことは別

Windows Serverでは5140・5145・4663等が重要な手掛かりになりますが、必要な監査が事前に設定され、調査時点まで記録が残っていることが前提です。

SynologyやQNAP等のNASについても、製品・OS・プロトコル・設定・保持期間によって取得できる記録が変わります。

サーバー側だけで結論が出ない場合は、対象PCのLNK、Jump Lists、MFT、USN、ログオン履歴、USB、クラウド等を照合します。

不正や情報持ち出しが疑われ、後から証拠として使用する可能性がある場合は、ログや端末を不用意に変更する前に、必要な保全範囲を検討することが重要です。

参考資料

技術資料確認日:2026年9月13日

  • Microsoft Learn「高度な監査ポリシーの構成設定」
  • Microsoft Learn「4663(S): An attempt was made to access an object.」
  • Microsoft Learn「5140(S, F): A network share object was accessed.」
  • Microsoft Learn「5145(S, F): A network share object was checked to see whether client can be granted desired access.」
  • Microsoft Learn「Audit File System」
  • Microsoft Learn「ファイル アクセスの監査の計画」
  • Microsoft Learn「ボリューム シャドウ コピー サービス(VSS)」
  • Synology Knowledge Center「How to use file transfer logs in Log Center to monitor file modifications」
  • QNAP「アクセスログ設定の構成」
  • 株式会社赤井事務所「デジタルフォレンジックPRO」