FSx for Windows File Server のエンドユーザーアクセスログを取得する方法についてまとめてみた
こんにちは!クラウド事業本部のおつまみです。
FSx for Windows File Server を使っていますか?
今回、お客様から「エンドユーザーがどのファイルにアクセスしたかログを取りたい」というご相談をいただきました。
調査の結果、FSx の 「ファイルアクセス監査(File Access Auditing)」 機能を使えば実現できることがわかったので共有します。
3行まとめ
- FSx for Windows File Server のファイルアクセスログは CloudTrail では取得できません
- FSx の「ファイルアクセス監査(File Access Auditing)」機能を有効化することで取得できます
- 設定は FSx 側(監査の有効化)と OS 側(監視対象フォルダの設定)の 2 段階が必要です
前提:CloudTrail ではファイルアクセスログは取れない
「CloudTrail で確認できますか?」という質問もよくあるのですが、CloudTrail は AWS の API 操作を記録するものです。ファイルサーバー上でエンドユーザーがどのファイルを読み書きしたかは記録されません。
| ログの種類 | 使うもの |
|---|---|
| AWS の API 操作ログ | CloudTrail |
| エンドユーザーのファイルアクセスログ | FSx ファイルアクセス監査 |
エンドユーザーのファイル操作を記録するには、FSx が提供する「ファイルアクセス監査」機能を使う必要があります。
ファイルアクセス監査(File Access Auditing)とは
FSx for Windows File Server のファイルアクセス監査は、ファイルサーバー上のアクセスイベントを記録する機能です。以下のような情報を記録できます。
- 誰が(ユーザー情報)
- どのファイル・フォルダに(ファイルパス)
- どんな操作をしたか(読み取り・書き込み・削除など)
- アクセスが成功したか失敗したか
参考:ファイルアクセス監査 - Amazon FSx for Windows File Server
ログの送信先
取得したログは以下の 2 つに送信できます。
| 送信先 | 特徴 |
|---|---|
| CloudWatch Logs | リアルタイムの確認・アラート設定が容易 |
| Kinesis Data Firehose | S3 へのアーカイブや Lambda 連携が可能 |
設定の前提条件
ファイルアクセス監査を有効化するには、以下の前提条件を満たす必要があります。
- FSx のスループット容量が 32 MB/秒以上 であること
- ログ送信先の CloudWatch Logs または Kinesis Data Firehose が準備済みであること
- CloudWatch Logs のロググループ名は
/aws/fsx/で始める必要がある - Kinesis Data Firehose の配信ストリーム名は
aws-fsx-で始める必要がある
- CloudWatch Logs のロググループ名は
設定手順
設定は大きく 2 段階です。
- FSx 側でファイルアクセス監査を有効化する(ログの送信先設定)
- OS 側で監視対象のファイル・フォルダを設定する
手順1:FSx 側でファイルアクセス監査を有効化する
AWS マネジメントコンソールから設定します。
- FSx コンソールを開く
- 対象のファイルシステムを選択し、「更新」 をクリック
- 「監査ログの設定」 セクションを開く
- 「ファイルアクセスの監査ログ」を有効化し、送信先(CloudWatch Logs または Kinesis Data Firehose)を選択する
- 記録するイベントの種類を選択する
- ファイルアクセス(成功・失敗)
- ファイル共有アクセス(成功・失敗)

手順2:OS 側で監視対象のファイル・フォルダを設定する
FSx 側の設定だけでは不十分で、どのファイル・フォルダを監視するかは Windows OS 側で設定する必要があります。
対象のフォルダに対して、以下の手順で監査設定を行います。
- 対象のフォルダを右クリック →「プロパティ」
- 「セキュリティ」タブ →「詳細設定」をクリック
- 「監査」タブ を開く
- 「追加」→「プリンシパルを選択」で監視対象ユーザー(例:
Everyone)を指定 - 監視するアクセス種別(読み取り・書き込み・削除など)にチェックを入れる
- 「OK」で保存

CloudWatch Logs で確認できるログ
CloudWatch Logs に出力されたログは XML 形式です。以下のような情報を確認できます。
<Event>
<System>
<EventID>4663</EventID>
<TimeCreated SystemTime="2026-03-26T05:00:00.000Z"/>
</System>
<EventData>
<Data Name="SubjectUserName">taro.yamada</Data>
<Data Name="ObjectName">\\share\documents\report.xlsx</Data>
<Data Name="AccessMask">0x1</Data>
</EventData>
</Event>
主なイベント ID は以下のとおりです。
| イベント ID | 内容 |
|---|---|
| 4663 | ファイル・フォルダへのアクセス成功 |
| 4656 | ファイル・フォルダへのアクセス要求(失敗含む) |
| 4659 | ファイルの削除 |
| 5140 | ファイル共有へのアクセス |
不正アクセスを検知する場合のログ確認方法
ファイルアクセス監査を活用することで、不正なユーザーアクセスの痕跡を追うことができます。
アクセス失敗を絞り込む
不正アクセスの試みはイベント ID 4656(アクセス要求・失敗含む)で確認できます。
CloudWatch Logs Insights で以下のようなクエリを使うと、アクセス失敗のみを絞り込めます。
fields @timestamp, @message
| filter @message like /4656/
| sort @timestamp desc
| limit 50
特定ユーザーのアクセス履歴を追う
不審なユーザーを特定した場合、そのユーザー名で絞り込んで操作履歴を確認できます。
fields @timestamp, @message
| filter @message like /taro.yamada/
| sort @timestamp desc
| limit 100
ファイル削除イベントを監視する
イベント ID 4659(ファイル削除)を監視することで、意図しないファイル削除や大量削除を検知できます。
CloudWatch アラームと組み合わせることで、削除イベントが一定数を超えた際に通知する仕組みも構築できます。
ログから確認できる情報のまとめ
| 確認したいこと | 使うイベント ID |
|---|---|
| 不審なアクセス失敗 | 4656 |
| ファイルの読み取り・書き込み | 4663 |
| ファイルの削除 | 4659 |
| ファイル共有への接続 | 5140 |
注意点
ログ配信はベストエフォート
ログ配信はベストエフォートです。高負荷時などに稀にログが欠損する可能性があります。厳密な監査要件がある場合はご注意ください。
最大処理レートの制限
最大処理レートは 5,000 イベント/秒 です。大量のファイルアクセスが発生する環境ではこの上限を考慮してください。
同一アカウント・同一リージョンの制限
送信元の FSx と送信先(CloudWatch Logs / Kinesis Data Firehose)は同一アカウント・同一リージョンである必要があります。
まとめ
今回は FSx for Windows File Server でエンドユーザーのファイルアクセスログを取得する方法をご紹介しました。
手順をまとめると:
- FSx 側でファイルアクセス監査を有効化し、送信先(CloudWatch Logs など)を設定する
- OS 側で監視対象のファイル・フォルダに監査設定を行う
FSx 側だけ設定しても OS 側の設定がないとログは出力されない点が落とし穴です。両方の設定を忘れずに行ってください。
最後までお読みいただきありがとうございました。
どなたかのお役に立てれば幸いです。
以上、おつまみ(@AWS11077)でした!






