SharePointでは、必要な監査ログが残っていれば、どのアカウントで、いつ、どのファイルにダウンロード関連の操作が記録されたかを確認できる場合があります。

代表的なのが、Microsoft 365監査ログのFileDownloadedです。また、OneDrive同期アプリを介した取得ではFileSyncDownloadedFullが記録される場合があります。Microsoftは、この2つを別の監査イベントとして定義しています。

ただし、監査イベントだけで、

• PCのどのフォルダへ保存されたか
• USBメモリへコピーされたか
• アカウント名義人本人が操作したか
• 不正な情報持ち出しだったか

まで確定できるわけではありません。

さらに注意したいのが、FileDownloadedが記録されていても、必ずしも利用者が「ダウンロード」ボタンを押してPCへ保存したとは限らないことです。日本マイクロソフトのSharePointサポート情報では、SharePoint Online上でPDFをプレビューした場合、内部的にダウンロードAPIが呼び出されるため、端末に保存されていなくてもFileDownloadedが記録される場合があると説明されています。

したがって、情報持ち出し調査では、

SharePointで取得に関係するイベントを確認する

↓

PC上にファイルが保存・同期された痕跡を確認する

↓

圧縮・USBコピー・メール送信・他クラウドへの移動等を確認する

というように、証拠を段階的につなげて評価することが重要です。

SharePointのダウンロード履歴だけでなく、Microsoft 365の監査ログ、Teams、Google Workspaceなどクラウド側の証拠全体を確認したい場合は、クラウドフォレンジックで、主な調査項目と確認方法をまとめています。

SharePointのダウンロード履歴は確認できる？

条件を満たして監査ログが残っていれば、SharePoint上のファイルに関するダウンロード履歴を確認できる場合があります。 ただし、確認できるのはSharePoint／Microsoft 365側で記録された操作であり、監査ログだけでPC保存や情報持ち出し全体まで確認できるわけではありません。

Microsoft 365の監査ログには、SharePointやOneDriveに関する複数のファイルイベントが記録されます。FileDownloadedのほか、アクセスを示すFileAccessed、プレビューに関係するFilePreviewed、OneDrive同期アプリによる取得を示すFileSyncDownloadedFullなどがあります。

調査では、まず次の4段階を分けます。

1. 何が記録されたか
   どのOperationが、どのアカウント・日時・ファイルについて記録されたか。
2. そこから何が言えるか
   SharePoint側で、どの種類のファイル操作が記録されたか。
3. そこからは何が言えないか
   PC保存先、USBコピー、実際の操作者、目的など。
4. 次に何を確認するか
   ブラウザ、OneDrive同期、Windowsファイルシステム、USB、メール等。

Microsoft 365全体の監査ログ、保持期間、ライセンス等については、Microsoft 365監査ログのフォレンジック調査に関する親記事で扱い、本記事ではSharePointのファイル取得に絞ります。

SharePointのダウンロード調査で確認する主な監査イベント

SharePointのファイル取得を調べる場合、イベント名を一つだけ検索するのではなく、取得・アクセス・プレビュー・同期を分けて確認することが重要です。

監査イベント	主に示すこと	主な注意点
FileDownloaded	サイトからドキュメントをダウンロードしたとして記録されたイベント	PDFプレビュー等でも記録される場合があり、手動保存と直結させない
FileSyncDownloadedFull	OneDrive同期アプリを使い、SharePointライブラリ等からコンピューターへファイルを取得	Webブラウザでの手動ダウンロードとは分けて扱う
FileAccessed	ユーザーまたはシステムアカウントがファイルへアクセス	人が内容を読んだことやダウンロードしたことまでは示さない
FilePreviewed	SharePoint／OneDrive上でファイルのプレビューに関係するイベント	ブラウザのプリフェッチ等で、実際に画面へ表示されたことまで保証しない

MicrosoftはFileAccessedについて、同じユーザー・ファイルに対するイベントを一定時間再記録しない仕組みを説明しています。またFilePreviewedについても、イベントの区別が利用者の意図を保証するものではないとしています。したがって、監査イベント数をそのまま人間のクリック回数として扱うことも適切ではありません。

FileDownloadedから何が分かる？

FileDownloadedが残っていれば、SharePoint側で対象ファイルについてダウンロードに分類される処理が記録されたことを確認できます。 一方、それだけで「利用者がダウンロードボタンを押してPCへ保存した」とまでは断定できません。

Microsoftの監査仕様では、FileDownloadedは「ユーザーがサイトからドキュメントをダウンロードした」イベントとして定義されています。

調査では、FileDownloadedに関連する監査レコードから、

• CreationTime
• UserId
• Operation
• ObjectId
• SiteUrl
• SourceRelativeUrl
• SourceFileName
• ClientIP
• UserAgent

などを確認し、対象期間・ユーザー・ファイルを絞り込みます。

ただし、イベント名を証拠の結論そのものに置き換えないことが重要です。

FileDownloadedがあっても「ダウンロードボタンを押した」とは限らない

SharePoint Online上のPDFについて、日本マイクロソフトのSharePointサポート情報では、プレビュー時に内部的なダウンロードAPIが呼び出され、端末にファイルを保存していなくてもFileDownloadedが記録される場合があると説明されています。

このため、

FileDownloadedがある

↓

SharePoint側でダウンロードに分類される処理が記録された

までは確認できますが、

利用者が明示的に保存操作をした

↓

特定のPCフォルダにファイルが残った

までをイベント単独で確定することは避けるべきです。

FileDownloadedだけではUSBコピーまで分からない

仮にSharePointからファイルが実際にPCへ保存されていても、その後、

• USBメモリへコピーした
• 個人メールへ添付した
• 別のクラウドストレージへアップロードした
• ZIP等へ圧縮した

という操作は別の事実です。

SharePoint側のログは重要な入口ですが、「SharePointから取得された」と「社外へ持ち出された」は同じ証拠ではありません。

OneDrive同期によるFileSyncDownloadedFullはどう読む？

FileSyncDownloadedFullは、OneDrive同期アプリを使用してSharePointドキュメントライブラリまたはOneDriveからコンピューターへファイルを取得したことに関係するイベントです。 通常のFileDownloadedとは分けて分析します。

MicrosoftはFileSyncDownloadedFullについて、OneDrive同期アプリ（OneDrive.exe）を使ってSharePointドキュメントライブラリまたはOneDriveからコンピューターへファイルをダウンロードしたイベントと定義しています。

たとえば、退職前の社員について大量の取得イベントが見つかった場合でも、

Web画面から大量ファイルを意図的に一つずつ取得した

ケースと、

業務で利用していたSharePointライブラリをOneDriveで同期した結果、ローカル側へデータが取得された

ケースでは意味が異なります。

そのため大量ダウンロード調査では、少なくとも、

• FileDownloaded
• FileSyncDownloadedFull
• 対象サイト
• 対象ユーザー
• 対象時間帯

を分けて集計します。

FileSyncDownloadedFullが大量に存在するという理由だけで、「社員が意図的に大量持ち出しを行った」と判断するのは適切ではありません。業務上の同期、端末変更、同期設定など、通常利用の可能性も確認します。

一方、退職直前など特定の時期に、それまで使っていなかったライブラリから多数のファイルが取得され、さらにPC上で圧縮や外部媒体へのコピーが確認される場合には、複数の証拠を組み合わせて事実関係を詳しく検討できます。

FileAccessed・FilePreviewedとダウンロードは何が違う？

FileAccessedはファイルへのアクセス、FilePreviewedはプレビューに関係するイベントであり、どちらもFileDownloadedと同じ意味ではありません。

Microsoftの現行資料では、FileAccessedはユーザーまたはシステムアカウントによるファイルアクセス、FilePreviewedはSharePointまたはOneDrive上でのファイルプレビューとして定義されています。

ただし、ここでもイベント名だけから人の行動を強く断定しないことが重要です。

MicrosoftはFilePreviewedについて、ブラウザのプリフェッチによってイベントが発生する場合があり、イベントが記録されたからといって、そのプレビューが利用者のデバイス画面へ実際に表示されたことまで意味するとは限らないと説明しています。また、FileAccessedではシステム側のワークフローによって生成されるケースも示しています。

したがって、

FileAccessed
≠
本人がファイル本文を読んだ

FilePreviewed
≠
本人が画面上で内容を確認したことまで確定

FilePreviewed／FileAccessed
≠
ローカルPCへ保存した

と整理します。

誰が・いつ・どのファイルを取得したか、どこまで分かる？

監査レコードから、アカウント、UTC時刻、Operation、対象ファイルのパス、ClientIP、UserAgent等を確認できる場合があります。ただし、「記録されたアカウント＝実際に操作した人物」とは限りません。

調査上、特に重要なのは次の項目です。

項目	調査での主な意味	解釈上の注意点
CreationTime	監査レコードが生成されたUTC日時	日本時間やPC側時刻と照合する際はタイムゾーンを統一する
Operation	FileDownloaded等の操作名	イベント名だけで利用者の具体的な意図を断定しない
UserId	イベントに記録されたアクター	システムアカウントやapp@sharepoint等も存在する
ObjectId	SharePointではアクセス対象ファイル・フォルダの完全URLパス	ファイル内容やPC保存先そのものではない
SiteUrl	対象が置かれているサイトURL	サイトが分かることと実際の保存先PCが分かることは別
SourceRelativeUrl	対象ファイルを含むフォルダのURL	SourceFileName等と組み合わせて対象を絞る
SourceFileName	対象ファイル／フォルダ名	同名ファイルの存在等も考慮する
ClientIP	イベントに記録されたIP	常に利用者PCのIPを直接表すとは限らない
UserAgent	ブラウザ等から提供されるクライアント情報	一意の端末識別情報とは扱わない

Microsoftによれば、CreationTimeは監査レコードが生成されたUTC日時です。また、SharePointのObjectIdはアクセスしたファイルまたはフォルダの完全URLパス、SiteUrl・SourceRelativeUrl・SourceFileNameは対象場所の把握に利用できます。

UserIdに社員のメールアドレスがあれば本人操作と言えるか

それだけでは本人操作を確定できません。

Microsoftの仕様上、監査レコードにはシステムアカウントやapp@sharepoint等が記録される場合があります。さらに人のアカウントが記録されている場合でも、それはまず「そのアカウントに関連付けられた操作」として評価します。

実際の人物まで確認する必要がある場合は、

• PCの使用者割当
• Entra ID等の認証記録
• 端末情報
• 周辺のログオン・操作履歴
• 勤怠や入退室等、必要な周辺記録

と照合します。

ClientIPだけで操作PCを特定できるか

常に特定できるわけではありません。

Microsoftは、サービスによってはClientIPに、利用者端末ではなく、利用者に代わってサービスを呼び出した信頼済みアプリケーションのIPが表示される場合があると説明しています。

したがって、

ClientIP＝必ず社員PCのグローバルIP

とは扱わず、UserAgent、認証ログ、ネットワーク側記録等と合わせて判断します。

大量ダウンロードはどのように調べる？

大量ダウンロードは、監査イベントの総件数だけでは判断せず、対象期間・アカウント・ファイル・サイト・イベント種別を分けて集計します。 また、大量取得が確認されても、それだけで不正とは判断しません。

まず、調査対象期間を定めます。

たとえば退職者であれば、

• 退職・異動の通知前
• 通知後
• 最終出社日前後
• 引継ぎ期間
• アカウント停止前後

など、業務上意味のある時期を分けます。

その上で、最低限次を確認します。

• 対象アカウント
• 対象サイト・ライブラリ
• FileDownloaded件数
• FileSyncDownloadedFull件数
• 対象ファイル
• 時間帯
• 通常時の利用状況
• 退職・異動等との時間関係

イベント件数とユニークファイル数を分ける

たとえば監査ログに1,000件のFileDownloadedがあっても、

1,000件＝異なる1,000ファイルを持ち出した

とは直ちに言えません。

同じ対象について複数イベントが存在する可能性があるほか、前述したPDFプレビューのように、利用者が一般にイメージする「保存」と異なる処理でもFileDownloadedが記録される場合があります。

そのため、

イベント総数

と

対象ファイルを整理した件数

は別に集計します。

大量取得＝不正でもない

業務上のライブラリ同期、PC交換、オフライン作業の準備等によって、多数のファイル取得が発生することがあります。

調査で意味が出るのは、

大量だったこと

だけではなく、

誰のアカウントで、いつ、どの範囲のファイルが、どの取得方式で記録され、その前後に何が起きていたか

です。

特に通常利用との差が大きい場合は、PC側で保存・圧縮・外部コピー等が続いていないかを確認します。

外部共有されたファイルが実際に取得されたか分かる？

共有リンクを作成した記録だけでは、第三者が実際にアクセス・取得したとは言えません。共有、利用、アクセス、ダウンロードを段階別に確認します。

Microsoftの共有監査では、たとえば次のようなイベントが定義されています。

共有設定・リンク作成

↓

SharingInvitationCreated
AnonymousLinkCreated
SecureLinkCreated
AddedToSecureLink

↓

リンク利用・アクセス

↓

SharingInvitationAccepted
AnonymousLinkUsed
FileAccessed

↓

ファイル取得に関係するイベント

↓

FileDownloaded等

MicrosoftはSharingInvitationCreatedについて、招待を送信した時点ではリソースへのアクセスを許可しないケースを明示しています。匿名リンクではAnonymousLinkUsed、特定ユーザー向けリンクでは外部ユーザーによるアクセス時にFileAccessedが記録される仕組みも説明されています。

したがって、

リンクを作った
≠
相手が使った

相手がアクセスした
≠
ファイルをダウンロードした

と分けて評価します。

外部共有による漏えいを調べる場合は、共有イベントと対象ファイルのアクセス・ダウンロードイベントを時系列で並べることが重要です。

SharePointの監査ログとPC側の証拠をどう突き合わせる？

SharePoint側では「クラウド上で何が記録されたか」を確定し、その後、PC側で保存・利用・圧縮・外部コピー等が確認できるかを時系列で照合します。

SharePoint監査ログから、まず、

• UserId
• CreationTime
• Operation
• ObjectId
• SourceFileName
• ClientIP
• UserAgent

等を整理します。

その時間帯を起点として、PC側では調査目的に応じて、

• ブラウザのダウンロード履歴
• ダウンロードフォルダ
• OneDrive同期フォルダ
• OneDriveクライアント関連情報
• $MFT
• $UsnJrnl
• LNK
• Jump Lists
• ZIP・7z等の圧縮ファイル
• USB接続記録
• 外部媒体上のファイル
• メール
• 他クラウドサービス

等を確認します。

ブラウザ側のダウンロード記録については、ブラウザ履歴はフォレンジックでどこまで分かる？Chrome・Edgeを調査、Windows上のファイル生成・変更についてはMFT・USNジャーナルで何が分かる？で詳しく解説しています。

複数証拠をつなぐ考え方

たとえば、これは実案件の紹介ではなく説明用の仮例ですが、次のような流れを考えます。

10:00　SharePoint
A.xlsxについてFileDownloaded

↓

10:01前後　PC
A.xlsxに対応するファイル作成・ダウンロード記録

↓

10:08　PC
対象ファイルを含むZIPファイルが作成

↓

10:10　Windows
USB外部媒体の接続記録

↓

その後　USB
対象ファイル、または内容の同一性を確認できるファイルを検出

ここまで複数の記録が整合すれば、SharePointのFileDownloaded一件だけの場合より、ファイルの移動経路を具体的に評価できます。

Windowsでコピーを調べる場合も、万能な「コピー履歴」が常に残るわけではありません。MFT・USN、USB、LNK・Jump Lists、コピー先媒体等を組み合わせて評価します。詳しくはWindowsでファイルコピー履歴は分かる？USBへのコピー痕跡と調査方法をご参照ください。

メール送信が疑われる場合は、メールフォレンジックとは？送受信・削除・添付ファイルの証拠のように、メール本体・クラウド側記録・PC側ファイルを別々の証拠として照合します。

重要なのは、

取得した
→
PCへ存在した
→
圧縮した
→
外部媒体等へコピーした
→
第三者へ移動した

を一つのログからまとめて断定しないことです。

ダウンロード履歴が見つからなければ、取得されていないと言える？

原則として、監査ログが見つからないことだけから「ファイルは取得されていない」と断定することはできません。

最初に確認するのは、

• 調査対象期間が正しいか
• 対象ユーザーが正しいか
• FileDownloadedだけでなく同期イベント等も確認したか
• 検索条件が狭すぎないか
• 当時、必要な監査データが収集されていたか
• 保持期間内か
• ライセンス・保持ポリシーがどうなっていたか
• 過去にCSVやSIEM等へ別途保存していないか

です。

Microsoftの現行資料では、Audit（Standard）の監査ログは原則180日保持されます。Audit（Premium）では、ライセンス条件を満たすユーザーのSharePoint・OneDrive等について1年間の既定保持があり、さらに保持ポリシーを利用できる構成があります。保持条件はライセンスやポリシー等によって変わるため、対象テナントの実際の状態を確認する必要があります。

またMicrosoftは、Microsoft 365組織では一般に監査が有効ですが、Business Basic、Business Standard、Business Premium等のSMBライセンスでは既定で有効にならない点を案内しています。過去ログを調べる場合は、現在の画面だけでなく、対象時点の監査状態も確認してください。

Microsoft 365全体の保持・監査条件については、親記事へ役割を委譲し、本記事では「ログが見つからない＝操作がなかった、とはしない」という判断を重視します。

SharePointの情報持ち出しを疑ったときの初動

情報持ち出しが疑われる場合は、SharePointの監査ログと対象PCの双方について、失われる可能性がある証拠を先に整理します。ただし、不正アクセスや漏えいが現在も進行している場合は、証拠保全だけを理由に被害停止を遅らせてはいけません。

まず、Microsoft 365側では、

• 対象ユーザー
• 対象期間
• 対象サイト・ライブラリ
• 対象ファイル
• 検索したOperation
• 検索条件
• 検索・取得日時
• エクスポートした監査データ

を記録します。

分析用に日本時間へ変換する場合も、元のUTC値を残しておくとPC・ネットワーク・メール等との再照合がしやすくなります。

PC側では、具体的な持ち出し疑いがある場合、初期化・再配布・復元ソフトの導入等を進める前に保全の要否を判断します。特に退職者PCについては、退職者PCは初期化してよい？保全の判断基準と残すべき証拠で初動を詳しく整理しています。

証拠として第三者へ説明する可能性がある場合は、監査ログのCSVだけでなく、取得条件、取得時点、原データ、解析用データを区別して管理することも重要です。証拠保全の基本についてはデジタルフォレンジックの証拠保全とは？をご参照ください。

被害停止と証拠保全を分けて考える

現在も不正アクセスが続いている場合には、

• アカウント停止
• セッション失効
• 権限変更
• 端末隔離

等の封じ込めが必要になることがあります。

一方で、過去の情報持ち出しを調べる目的で、緊急性がないにもかかわらずPCを初期化したり、必要なログを削除したりすると、後の確認範囲が狭くなる可能性があります。

アクセスを止めることと、証拠を消すことは別です。

実施した対応内容と時刻を記録しながら進めます。

自社確認で対応しやすい例

次のような確認は、必要な権限と知識があれば社内で対応しやすいケースです。

• 特定アカウントの最近のダウンロード履歴を確認したい
• 対象ファイルと期間が明確
• 懲戒・訴訟等での証拠利用を予定していない
• Microsoft 365側の監査ログ確認だけで目的が達成できる
• PCや外部媒体まで追跡する必要がない

専門的なフォレンジック調査を検討する例

次のような場合は、SharePoint監査ログだけでは必要な結論まで届かない可能性があります。

• 退職前の大量取得が疑われる
• PCへ実際に保存されたか確認したい
• ZIP等への圧縮を確認したい
• USBへのコピーを確認したい
• メール・他クラウドへの移動を確認したい
• ログの欠落や削除が疑われる
• アカウント名義人本人の操作か検討する必要がある
• 複数アカウント・複数端末が関係する
• 懲戒・損害賠償・刑事対応等を想定している
• 第三者へ調査根拠を説明する必要がある

株式会社赤井事務所／デジタルフォレンジックPROでは、PCだけでなく、Microsoft 365等のクラウド側記録、メール、外部媒体等を調査目的に応じて組み合わせるデジタルフォレンジック調査に対応しています。

まとめ

SharePointでは、必要なMicrosoft 365監査ログが残っていれば、どのアカウントで、いつ、どのファイルにダウンロード関連の操作が記録されたかを確認できる場合があります。

ただし、最も重要なのはイベント名をそのまま最終結論にしないことです。

FileDownloadedは重要な証拠ですが、PDFのプレビューでも記録される場合があるため、必ずしも利用者が明示的にファイルを保存したことを意味しません。FileSyncDownloadedFullはOneDrive同期による取得として分けて評価します。FileAccessedやFilePreviewedもダウンロードとは別のイベントであり、利用者が内容を読んだことまで自動的に確定するものではありません。

また、UserIdに社員のアカウントが記録されていても、直ちに社員本人の操作と断定せず、ClientIPも常に操作PCそのもののIPを示すとは限らない点に注意が必要です。

大量ダウンロードを調べる場合は、イベント総数だけでなく、対象期間、ユーザー、サイト、ファイル、Web取得と同期取得を分け、通常時との違いや退職・異動等との時間関係を確認します。

そしてSharePoint監査ログだけでは、

PCの保存先

USBへのコピー

圧縮

メール送信

他クラウドへの移動

まで確定できません。

情報持ち出しを確認するには、SharePoint側の記録を起点として、ブラウザ、OneDrive同期、MFT・USN、LNK・Jump Lists、USB、メール、外部媒体等を時系列で照合することが重要です。

単純な監査履歴の確認であれば自社で対応できる場合があります。一方、実際の保存・外部コピー・操作者まで確認する必要がある場合や、懲戒・紛争等で第三者へ説明できる証拠が必要な場合は、対象PCやログを不用意に変更する前に保全とフォレンジック調査を検討してください。

参考資料

• Microsoft Learn「監査ログ アクティビティ」
  Microsoft Learnで確認
• Microsoft Learn「Office 365 Management Activity API のスキーマ」
  Microsoft Learnで確認
• Microsoft Learn「監査ログの詳細なアクティビティ プロパティ」
  Microsoft Learnで確認
• Microsoft Learn「監査ログで共有監査を使用する」
  Microsoft Learnで確認
• Microsoft Learn「Microsoft Purviewの監査ソリューションについて」
  Microsoft Learnで確認
• Microsoft Learn「監査ログ保持ポリシーを管理する」
  Microsoft Learnで確認
• Japan SharePoint Support Blog「PDFを閲覧する際の監査ログ記録について」
  日本マイクロソフトSharePointサポート情報を確認