共有フォルダーの「今の利用状況」は、コンピューターの管理にある共有フォルダー、またはGet-SmbSession／Get-SmbOpenFileで確認できます。ただし画面は連続監視ではなく、その時点のセッションと開いているファイルのスナップショットです。誰が過去に閲覧・変更・削除したかを追う用途はファイルシステム監査とログ保管が必要です。目的を分けると、過剰な監視や誤った切断を避けられます。
オープンファイルを強制的に閉じると、利用者の未保存データを失う可能性があります。確認だけなら読み取りコマンドに留め、切断は利用者・業務責任者と合意してから実施します。
管理コンソールで現在の状況を見る
- ファイルサーバーへ権限を持つ管理者として接続し、「コンピューターの管理」を開きます。
- ローカルサーバーを見る場合は「共有フォルダー」を展開します。別サーバーを管理する場合は「別のコンピューターへ接続」で対象名を明示します。
- 「共有」で共有名、パス、クライアント接続数を確認します。
- 「セッション」で接続ユーザー、接続元、開いているファイル数、接続時間などを確認します。
- 「開いているファイル」でパス、ユーザー、ロック状態を確認します。表示更新時刻と対象サーバーを記録します。
表示されないときは、対象サーバー、管理権限、Windowsファイアウォール、リモート管理、SMBサービス、名前解決を確認します。「誰も使っていない」と即断せず、別クラスターノード、DFS名前空間、NAS、同期製品経由でアクセスしていないかも調べます。
PowerShellでセッションを確認する
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens,SecondsExists
Get-SmbOpenFile | Select-Object FileId,ClientUserName,ClientComputerName,Path,ShareRelativePath
結果を時刻付きで保存するなら、機密情報を含むファイルパスとユーザー名の取り扱いを先に決めます。管理共有や個人フォルダーの名前から業務内容が推測できる場合があります。保存先のアクセス権、保持期間、閲覧者、廃棄方法を監査方針へ合わせます。
サーバー台数が多い場合は、対象一覧を固定し、接続失敗とデータ0件を区別します。管理者資格情報をスクリプトへ直書きせず、JEA、署名済みスクリプト、タスク用サービスアカウントなど組織の標準を使います。全サーバーへ高頻度で問い合わせると管理系負荷が増えるため、間隔とタイムアウトを測定します。
「開いている」と「利用した」を区別する
- Get-SmbSession: SMBクライアントとの接続単位。接続中でも操作していない場合がある
- Get-SmbOpenFile: サーバー側で現在開かれているファイル。短時間のアクセスは取得間隔の間に消える
- 共有の接続数: 利用人数と一致しない。1端末・1ユーザーでも複数接続になり得る
- ファイルシステム監査: 監査方針とSACLに一致したアクセスをイベントとして残す
- バックアップ／ウイルス対策／インデックス: 利用者以外のプロセスがファイルを開くことがある
「リアルタイム監視」という言葉だけで要件を決めず、障害対応でロック元を探したいのか、ライセンス数を数えたいのか、不正アクセスを検知したいのか、削除者を追跡したいのかを分けます。それぞれ必要なデータ、粒度、保持、誤検知、プライバシーが違います。
ファイルロックの調査手順
- 利用者から、サーバー名、共有名、ファイルの相対パス、エラー、発生時刻、再現頻度を聞きます。
- Get-SmbOpenFileで対象パスを絞り、ユーザーと接続元を確認します。
- Officeの所有者ファイル、業務アプリのロック、バックアップやスキャンの可能性を確認します。
- 利用者へ保存・終了を依頼し、再取得してロックが消えたことを確認します。
- 必要な場合だけ変更承認を得て切断し、実行者、FileId、時刻、理由、影響を記録します。
- アプリケーションを再度開き、破損、競合コピー、未反映データがないか確認します。
ファイルIDだけを見て別の接続を切らないよう、対象サーバーとユーザー、パスを複数条件で照合します。SMBセッション全体を切ると、そのユーザーが開く別ファイルまで影響します。単一ファイルのClose-SmbOpenFileもデータ損失リスクがあるため、読み取り確認とは別の承認操作です。
過去のアクセスを監査する
過去の変更者を調べたい場合は、Advanced Audit Policyの「Audit File System」を設計し、対象フォルダーのSACLで成功／失敗、主体、操作を絞ります。監査ポリシーだけ、またはSACLだけでは期待するイベントが出ません。全アクセスを無差別に記録するとログ量と機密情報が増えるため、重要フォルダーと必要操作に限定します。
設定前に通常業務のイベント量を測り、Securityログ容量、上書き方式、転送先、保持、時刻同期、SIEMの検索項目を決めます。監査担当とサーバー管理者の権限を分離し、ログ転送停止や監査設定変更も検知します。ファイル内容そのものをログへ収集する必要があるかは慎重に判断します。
簡易監視を自動化する場合
定期取得では、取得開始・終了時刻、サーバー、成功／失敗、件数、スクリプト版を必ず出力します。CSVへ追記するだけだと列変更や文字コード、ファイル肥大化、同時実行で壊れるため、日次ローテーションと整合性確認を用意します。ユーザー名とパスは必要最小限にします。
アラート条件は「セッション数が1以上」のような常時発報ではなく、基準値からの急増、禁止された管理共有への接続、長時間ロック、営業時間外の重要フォルダー操作など、対応可能な条件にします。アラートを受けた人が確認するコマンド、誤検知解除、エスカレーション、証拠保全まで手順化します。
トラブル時の確認
- 管理コンソールとPowerShellで結果が違う場合は、同じサーバーと同じ時刻か
- DFS、クラスタ、スケールアウトファイルサーバー、NASの実体ノードを見ているか
- 資格情報、UAC、ファイアウォール、WinRM／RPCの許可範囲
- 短時間アクセスをポーリングで取り逃していないか
- ユーザー名がサービス、コンピューター、別ドメイン表記になっていないか
- サーバーとログ収集基盤の時刻が同期しているか
監視を終える基準
一時的な障害調査で高頻度取得を始めたら、終了時刻を決めます。問題解消後はタスク、資格情報、出力ファイル、例外的なファイアウォール許可を元へ戻し、収集データを保持方針に従って削除します。「念のため」永久保存すると、利用者追跡データ自体が新たなリスクになります。
平常運用は、現況確認、履歴監査、容量・性能監視、セキュリティ検知を別の指標としてダッシュボード化します。各データの責任者と正しい用途を記載し、Get-SmbOpenFileのスナップショットだけで勤務状況や不正を断定しないことが重要です。
性能問題と利用状況を混同しない
セッション数が多いだけで遅さの原因とは限りません。SMBの遅延を調べる場合はCPU、メモリ、ディスク待ち、ネットワーク再送、ウイルス対策、バックアップ、クライアント側の回線を同じ時刻で確認します。オープンファイル一覧は手掛かりですが、性能カウンターの代替ではありません。
障害時間帯だけ高頻度取得する場合は、平常時との比較値を用意します。利用者名を根拠に責任を断定せず、アプリケーションやサービスアカウント、共有ロックの仕様を再現してから原因を説明します。
コメント