MENU

Azure Files（Azure File Share）監査ログの取り方｜誰が作成・更新・削除したかを追跡する方法

Azure

Azure Files（Azure File Share）をAD認証で運用していると、オンプレのWindowsファイルサーバーのように「誰が・いつ・どのファイルを作成／更新／削除したか」を追いたくなります。本記事では、Azure Filesで実現できる監査ログの取り方と、限界を埋める設計パターンを具体的に整理します。

目次

結論：Azure Files単体の「Windows監査ログ」と同等のものはないが、目的別に2系統で実現できる

先に結論から言うと、Azure Files（SMB/NFSのクラウドファイル共有）には、オンプレのNTFS監査（SACL＋セキュリティイベントログ）のように「ファイル単位で、誰が、何を、したか」を完全に同じ粒度・同じ保証で残す仕組みは用意されていません。

ただし現在は、目的を分解すると次の2系統で「現実的に追える」ようになっています。

目的使うログ強いポイント弱いポイント
Azure Filesへのアクセス/操作を、クラウド側で横断的に追う（誰が・いつ・どのパスへ）Azure Monitor の Azure Storage logs（リソースログ） → Log Analytics（StorageFileLogs）SMB/HTTPSの要求を記録し、操作種別・URI・ユーザー情報で検索できるベストエフォート（必ず全リクエストが残る保証はない）。Windows監査ほどの「ファイルシステム監査」ではない
オンプレ同等の監査（SACL、イベントID、アクセス許可変更まで含めた厳密な証跡）Windows Server（Azure File Sync/ゲートウェイ）側の Windows監査ログ従来のファイルサーバー監査と同じ運用ができる（監査ポリシー、SACL、SIEM連携）Windows Serverを経由する構成・運用が必要（設計とコストが増える）

まず整理：Azureのログは「管理操作」と「ファイル操作」で置き場所が違う

Azureで「ログを見たのに目的の情報がない」というときは、だいたい制御プレーン（管理操作）とデータプレーン（実データ操作）の混同が原因です。

見たいこと代表例主に出るログ補足
管理操作（制御プレーン）ストレージアカウント作成、共有（share）作成/削除、設定変更、RBAC変更Azure アクティビティログ「誰がリソースを作った/消した/設定を変えたか」に強いが、ファイル単位の操作は基本対象外
ファイル操作（データプレーン）ファイル作成、書き込み、削除、一覧、読み取りAzure Storage logs（リソースログ）→ StorageFileLogs診断設定を作らないと保存されない。SMB/HTTPS（REST）要求を記録
ファイルサーバー監査（OS側）アクセス許可変更、オブジェクトアクセス、共有アクセス、失敗監査Windows Security イベントログAzure File SyncなどでWindows Serverを挟むと、従来の監査設計がそのまま使える

2020年当時の回答と、現在の「現実解」

当時（2020年前後）の文脈では、Azure Filesに「オンプレの監査ログのように、共有内のファイル操作を横断して追える機能はない」という回答が多く、代替としてはStorage Analytics（メトリック中心）という整理でした。実際、クラシックのStorage Analytics LoggingはBlob/Queue/Table向けで、Azure Filesは対象外と明記されています。

一方、現在はAzure MonitorのリソースログとしてAzure Storage logsを有効化でき、Azure Files（SMB/HTTPS）の操作要求をStorageFileLogsテーブルに蓄積して検索・分析できます。Microsoft LearnのFAQでも、Azure Filesの監査は「直接アクセスならAzure Storage logs」「Windows Server経由ならWindows監査」という2パターンが案内されています。

パターンA：クライアントがAzure Filesに直接アクセスする場合（Azure Storage logsで追う）

AD参加（Active Directory Domain Services / Azure AD DS / Entra ID Kerberos など）でSMBアクセスさせている場合でも、Azure側では「SMB要求」としてログが記録されます。ここでのポイントは、診断設定（Diagnostic settings）を作成して、StorageFileLogsに送ることです。作らない限り、ログは保存も検索もできません。

できること・できないこと（期待値を合わせる）

  • できる：誰が（RequesterUserName / RequesterUpn 等）、いつ（TimeGenerated）、どのパスへ（Uri）、どんな操作（Category / OperationName）をしたかを検索・集計する
  • できない：ファイルの中身がどう変わったか（差分）や、WindowsのイベントID体系そのままの監査
  • 注意：ログはベストエフォート。監査要件（法令/規制/内部統制）で「漏れが許されない」なら、後述のWindows Server監査を検討する

設定手順（Azure Portal）

画面は時期で変わりますが、考え方は固定です。対象リソースはストレージアカウント直下の「fileServices/default」に対する診断設定です。

手順やることポイント
1Azure portalで対象のストレージアカウントを開く共有（File share）ではなく、ストレージアカウントが入口
2「監視」→「診断設定」へ進む診断設定がないとログは残らない
3対象サービスで「File」を選び、診断設定を追加よくあるミス：ストレージアカウント（ルート）だけに設定してしまい、Filesのログが来ない
4ログカテゴリで「StorageRead」「StorageWrite」「StorageDelete」を選択コスト最適化したい場合、まずはWrite/Deleteのみで開始し、必要に応じてReadも追加
5送信先にLog Analyticsワークスペースを指定して保存同じストレージアカウントへは送れない（ループ回避）。保管先は別アカウント/Log Analytics推奨

StorageFileLogsで「誰が何をしたか」を読むための主要カラム

Log Analyticsに届くと、Azure FilesのログはStorageFileLogsテーブルに入ります。ここを読むコツは「ユーザー」「操作」「対象パス」「結果」を押さえることです。

観点カラム例用途メモ
誰がRequesterUserName / RequesterUpn / SmbPrimarySIDSMBならユーザー名、REST(OAuth)ならUPNで追うSMBは「RequesterUserName（SMBのユーザー名）」や「SmbPrimarySID（Kerberos認証のSID）」が鍵
いつTimeGenerated時系列追跡UTCで入るため、運用上はタイムゾーン変換を意識
何をCategory / OperationName / SmbCommandDetailRead/Write/Deleteや、より細かい操作種別を見るSMBは低レベルのコマンド名（Create/Write/SetInfo等）が見えることがある
どこへUri / AccountNameファイルパス（share/dir/file）で絞り込むURIはURLエンコードされる場合がある（日本語ファイル名など）
結果StatusCode / StatusText成功/失敗やエラー原因の把握失敗監査や権限不足の追跡に有効

すぐ使えるKQL例（「誰が削除した？」を最短で出す）

まずは「削除」だけに絞って一覧し、そこからファイル名・ユーザー名で追い込みます。

StorageFileLogs
| where TimeGenerated >= ago(7d)
| where Category == "StorageDelete"
| project TimeGenerated, Protocol, RequesterUserName, RequesterUpn, SmbPrimarySID, CallerIpAddress, OperationName, Uri, StatusText, StatusCode
| sort by TimeGenerated desc

特定の共有名（share）やフォルダ配下に限定したい場合は、Uriの条件を追加します。

// share名やパスで絞る（例：share=dept、フォルダ=Finance）
StorageFileLogs
| where TimeGenerated >= ago(30d)
| where Category in ("StorageWrite","StorageDelete")
| where Uri has "/dept/" and Uri has "/Finance/"
| project TimeGenerated, Category, OperationName, RequesterUserName, RequesterUpn, Uri
| sort by TimeGenerated desc

「ファイル名が分かっている」ケースでは、ファイル名で直接フィルターするのが最短です。

// 例：report.xlsx に触ったユーザーと時刻を追う
StorageFileLogs
| where TimeGenerated >= ago(30d)
| where Uri has "report.xlsx"
| project TimeGenerated, Category, OperationName, RequesterUserName, RequesterUpn, Uri, StatusText
| sort by TimeGenerated desc

運用で効く：大量削除・ランサムウェアの兆候をアラートにする

監査ログは「後追い」になりがちですが、Log Analyticsなら集計して異常検知のアラートにできます。例えば「同一ユーザーが短時間に大量削除した」を検知するクエリは次のイメージです。

// 5分間に20件以上の削除が発生したユーザーを抽出（閾値は環境に合わせて調整）
StorageFileLogs
| where TimeGenerated >= ago(1d)
| where Category == "StorageDelete"
| summarize DeleteCount=count() by bin(TimeGenerated, 5m), RequesterUserName, RequesterUpn
| where DeleteCount >= 20
| sort by TimeGenerated desc

このクエリをログアラート（Azure Monitor alert）として登録し、Teamsやメール、ITSMへ通知すれば「気づくまでの時間」を短縮できます。

コストと保持期間（現場で揉めやすいポイント）

  • ログ量＝コストです。特にStorageReadは量が増えやすいため、まずはWrite/Delete中心で始め、必要に応じてReadを追加すると失敗しにくいです。
  • Log Analytics側の保持期間は、ワークスペース/テーブル単位で設定できます。長期保管が必要なら、Event Hubs経由でSIEMへ送る、または別ストレージアカウントへアーカイブしてライフサイクル管理で保管する選択肢もあります。
  • 「ログが検索できない」原因の多くは、診断設定のスコープ違い（fileServicesでなくstorageAccountsに付けた）か、そもそも対象期間にアクセスがない（ログは要求がないと出ない）です。

パターンB：Windows Server経由でアクセスさせる場合（Windows監査で「誰が何をしたか」を確実に残す）

監査要件が厳しい（監査証跡の欠損が許されない、アクセス権変更も含めて追いたい、既存の運用がWindowsイベントログ前提）場合は、Microsoft Learnでも案内されている通り、Windows Server側で監査を取る設計が現実的です。

構成例

  • Azure File Sync：Windows ServerにFile Sync agentを入れ、サーバー上のパスを「サーバーエンドポイント」として同期。ユーザーはWindows Serverの共有にアクセス。
  • ゲートウェイ（再共有）：Windows ServerがAzure Filesをマウントし、そのパスを社内向けに共有する（アクセスの入口をWindowsに集約）。

Windows監査の要点（SACL＋監査ポリシー）

Windowsファイルサーバー監査は「監査ポリシーを有効化」した上で、「監査したいフォルダ/ファイルにSACLを付ける」ことで初めてイベントが出ます。逆に言うと、どちらかが欠けるとログは出ません。

設定例狙い
監査ポリシー監査: オブジェクトアクセス（File System / File Share）ファイルアクセス・共有アクセスを記録する土台
SACL対象フォルダに「成功/失敗」「書き込み/削除」などを指定どの操作をログに出すかを絞り込む（過剰ログを防ぐ）
ログ集約Windowsイベント転送 / SIEM（Microsoft Sentinelなど）サーバー単体に閉じず、検索・保管・相関分析を可能にする

代表的なイベントID（調査で頻出）

環境やポリシーで前後しますが、調査でよく使う代表例を挙げます。これらは「オンプレと同じ考え方で追える」ため、監査部門・セキュリティ部門が運用しやすいのが利点です。

イベントID意味（ざっくり）よく使う場面
4663オブジェクトへのアクセス（読み取り/書き込み等）「誰がそのファイルにアクセスしたか」を追う
4660オブジェクトの削除「誰が削除したか」の確定に近い
5140ネットワーク共有へのアクセス共有単位のアクセス追跡（入口の確認）
4670アクセス許可の変更権限変更を監査したいとき

Windows Server方式が向くケース

  • 監査要件が厳しく、ログ欠損が許されない
  • 「削除」だけでなく、アクセス拒否（失敗監査）や権限変更まで追いたい
  • 既存の監査基盤（SOC/SIEM/運用手順）がWindowsイベントログ前提

よくある落とし穴（現場でハマるポイントを先回り）

Azure アクティビティログに「ファイル削除」が出ない

アクティビティログは管理操作中心です。ファイル単位の操作は、Azure Storage logs（StorageFileLogs）側で追います。逆に、共有そのものを削除したなどの管理系はアクティビティログが強い、という棲み分けです。

診断設定を「Storage account（ルート）」にしか付けていない

ストレージアカウントには、Blob/Queue/Table/Fileなど複数サービスがぶら下がります。Filesの操作ログが欲しい場合、fileServices側の診断設定が必要です。ここが最重要のつまずきポイントです。

SMB削除が「StorageDelete」だけでは拾えないことがある

SMBはプロトコル上の振る舞い（Create/Close/SetInfoなど）として記録されることがあり、運用によっては「削除の実体」が別の操作名として見える場合があります。まずはCategoryで大きく絞り、次にOperationNameやSmbCommandDetailを見ながら、環境に合うフィルター条件を固めるのが近道です。

ユーザーが見えない（SAS/ストレージキー経由）

アプリやツールがSAS/ストレージキーでアクセスしている場合、「誰が」ではなく「どの資格情報が」になりやすいです。監査要件があるなら、SMBのAD認証やOAuth（Entra ID）など、個人に紐づく認証方式に寄せるほど追跡が容易になります。

まとめ：Azure Filesの監査は「要求ログで追う」か「Windowsで確実に残す」かを最初に決める

Azure Filesで「誰が作成／更新／削除したか」を追う方法は、今は実装できます。ただし、オンプレのWindows監査と同じ感覚で「完全なファイル監査がクラウドだけで完結する」と期待するとズレます。

  • まずはAzure Storage logs（StorageFileLogs）で「誰が・いつ・どのパスへ・どんな操作」を追える状態を作る（トラブルシュート/可視化/セキュリティ検知に強い）
  • 監査要件が厳しい場合は、Windows Server経由で従来通りの監査（SACL＋イベントログ）を取る

どちらを選んでも、最初に「監査で必要な粒度（ファイル単位か、共有単位か、権限変更までか）」と「欠損許容（ベストエフォートでよいか）」を言語化すると、設計がブレません。

Azure
SMB 監査ログ Azure Monitor Azure Files Log Analytics

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次