共有フォルダを移動した直後に「閲覧できる人が増えた」「逆に担当者が開けなくなった」という事故が起きることがあります。原因は、Windowsのコピーと移動でアクセス制御リスト（ACL）の扱いが同じではないことです。結論から言えば、同じNTFSボリューム内の移動では元のアクセス許可を保持するのが基本で、コピーや別ボリュームへの移動では移動先フォルダから継承するのが基本です。ただし明示的な権限、継承設定、実行主体の権限、利用したツールによって結果は変わるため、本番データでいきなり試してはいけません。
安全な進め方は「現状を記録する → 少量で試す → 有効なアクセスを確認する → 本番を段階移行する → 問題があれば元へ戻す」です。権限だけでなく共有設定とバックアップも別々に確認します。
コピーと移動で権限が変わる仕組み
Microsoftの説明では、同じNTFSボリューム内でファイルやフォルダを移動すると、オブジェクトは原則として元のアクセス許可を保持します。これはディレクトリエントリの付け替えに近い処理だからです。一方、別のNTFSボリュームへ移す操作は実質的にコピーして元を削除するため、新しく作成された側は移動先の親フォルダからアクセス許可を継承します。通常のコピーも同様です。
この違いが「権限も一緒に移ってしまった」と感じる主因です。移動先の標準権限へ揃うと思っていたのに、同一ドライブ内の移動では古い部署の明示的ACLが残ります。反対に、別ドライブへ移すと移動先の継承が働き、元の個別設定が消えたように見えることがあります。FAT系のファイルシステムやクラウド同期領域、NASではNTFSと同じ結果を前提にできません。製品仕様を確認してください。
NTFS権限と共有アクセス許可は別物
ネットワーク共有には、ファイルシステム側のNTFS権限と、共有そのものに付く共有アクセス許可があります。利用者がSMB経由で接続すると、両方を合わせた結果のうち、より制限の強い側が実効権限になります。フォルダを移しても共有定義が自動で移るとは限りません。共有名、共有パス、オフラインファイル、DFS参照、バックアップ対象、監査設定まで棚卸しする必要があります。
変更前に取るべき記録とバックアップ
最初に移動元と移動先のパス、ボリューム、所有者、継承の有効・無効、明示的な許可と拒否、共有定義を記録します。エクスプローラーの「プロパティ」から確認するだけでなく、権限一覧をテキストへ保存すると比較しやすくなります。icaclsはACLの表示と保存に使えますが、管理者権限が必要な環境では承認された管理端末から実行してください。出力ファイルにはユーザー名やサーバー名が含まれるため、公開領域へ置かないでください。
icacls "D:\Share\Target" /save "D:\AclBackup\target-acl.txt" /t /c上の例は読み取りとバックアップ取得が目的です。実際のパスへ置き換え、保存先の空き容量とアクセス制御を確認します。権限を変更するスイッチはまだ使いません。フォルダ本体については既存のバックアップ製品で復元テスト済みの世代を確保し、共有定義やDFS構成もエクスポートします。バックアップが「成功」と表示されるだけでなく、テスト用ファイルを復元して内容を開けることまで確認します。
小さく試すための手順
- 本番と同じ継承構造を持つ検証用フォルダを、移動元と移動先の双方に用意します。実データではなくダミーファイルを使います。
- 同じボリューム内の移動と、別ボリュームへのコピーを別々に行い、結果を混同しないよう時刻と操作方法を記録します。
- 移動後に「セキュリティの詳細設定」で継承元、明示的エントリ、所有者を比較します。icaclsの再出力も差分確認に使えます。
- 管理者だけでなく、閲覧者、編集者、アクセス不可であるべきテストアカウントで実際に開く・保存する・削除する操作を確認します。
- 期待した結果が得られた操作だけを手順書にし、少量の本番データでパイロット移行します。監査ログと問い合わせを観察してから範囲を広げます。
権限を維持したい場合と揃えたい場合
元のACLを維持する必要がある場合は、robocopyなどACLを扱える標準ツールを候補にします。ただしデータ、属性、タイムスタンプ、所有者、監査情報のどこまでコピーするかでオプションが変わります。過剰なオプションは不要な所有者や監査設定まで持ち込むため、検証環境でログを確認してから採用してください。単純なドラッグ操作と同じ結果になるとは限りません。
逆に移動先の権限へ統一したい場合は、親からの継承を有効にする設計が基本です。しかし明示的な拒否や業務上必要な個別許可を一括で消すと障害になります。まず差分を一覧化し、データ所有者の承認を得て、部署単位など小さな範囲から変更します。個人アカウントへ直接付けた権限より、役割ごとのセキュリティグループへ権限を付ける方が引き継ぎと監査をしやすくなります。
検証ポイントとロールバック
- 許可されるべき利用者が読み取り・更新でき、許可されない利用者が拒否されること
- アプリやサービスアカウント、バックアップ、検索インデックス、スキャン処理が従来どおり動くこと
- 共有パス、UNCパス、ショートカット、ログオンスクリプト、DFS参照が新しい場所を指すこと
- 監査ログに大量のアクセス拒否や予期しない所有権変更が出ていないこと
- 移行後のバックアップが取得され、テスト復元できること
ロールバックは、旧共有を直ちに消さず読み取り専用で一定期間保持し、切り戻し条件と担当者を事前に決めておくと安全です。重大なアクセス障害が出たら新しい共有を停止し、名前解決やDFS参照を旧経路へ戻し、保存しておいたACLとデータの整合を確認します。移行中に新旧双方で更新を許すと差分が発生するので、切替時間帯は更新を止めるか、どちらを正とするか明確にします。
よくある誤解
「Administratorsなら必ず開ける」「所有者なら何でもできる」「拒否を追加すれば安全」といった考え方は危険です。有効なアクセスはグループ所属、継承、明示的な許可・拒否、共有側の制限などを組み合わせて評価されます。また、権限表示を見ただけでは業務アプリ経由の動作までは保証できません。変更前後の実アカウント試験と監査をセットにしてください。
移行記録に残す具体項目
作業記録には、対象件数と総容量、開始・終了時刻、利用した端末とツールの版、コピー元とコピー先のボリュームID、ACLバックアップの保存先、検証アカウント、承認番号を残します。権限差分は「増えた許可」「消えた許可」「継承元が変わった項目」に分けるとレビューしやすくなります。個人名だけでなくSIDも保持すると、表示名変更や削除済みアカウントを識別できます。
旧フォルダを保持する期間は、容量だけでなく個人情報の重複保管リスクも考慮します。切り戻し期間終了後はデータ所有者の承認を得て、バックアップ保持方針に従って整理します。移行成功の判断を「コピー完了」にせず、利用部門の受入確認、監査、バックアップ、旧経路停止までを完了条件にしてください。
アクセス拒否が出た直後の判断
移行後に一部利用者だけ拒否される場合は、所有権取得や権限追加を急がず、その利用者のグループ所属、接続した共有名、Kerberosチケットの更新、継承元を確認します。切替前から開いていたセッションには古い資格情報が残ることがあるため、再サインイン後も再現するかを分けます。原因が未確定なら新規更新を停止し、旧共有を読み取り専用で案内します。
コメント