Windows Serverのファイルサーバーで共有フォルダーを整理したいのに、Access Based Enumeration（ABE）を有効にしても他部署や他人のフォルダー名が見えてしまう──。本記事では原因の見抜き方と、部署別・ユーザー別に“見える範囲／入れる範囲”を分ける権限設計を具体例で解説します。
よくある相談：共有ドライブ配下を辿ると、部署フォルダーや他人のフォルダー名まで見える
既存のファイルサーバーを長年運用していると、フォルダーの権限が部署ごと・時期ごとに増改築され、いつの間にか「誰が何にアクセスできるのか」がわからなくなりがちです。特に次のような構成では、フォルダー名（一覧）だけが見えてしまう問題が頻発します。
\\fileserver\departments （部署別）
\\fileserver\uniquedrives （特定用途の共有）
\\fileserver\userfiles （ユーザー個人フォルダー）現象としては、一般ユーザーが共有ドライブを開いてツリーを辿るだけで、権限がないはずの部署フォルダーや、他人の個人フォルダー名まで一覧に表示されます。理想は次のような状態です。
- HR権限の人はHRだけが「見えて」入れる（ITなど他部署は見えない）
departments配下は、運用方針に応じて「一覧は見えても入れるのは自部署のみ」または「自部署のみ見える」を選べるuserfiles配下は自分のフォルダー以外は見えない
結論：ABEが効かないのではなく、どこかで「一覧できる権限」が残っている
Access Based Enumeration（アクセス ベースの列挙 / ABE）は、フォルダー一覧を表示する瞬間に「そのユーザーがアクセスできない項目を表示しない」ための仕組みです。裏を返すと、どこかで“読める／一覧できる”権限が付与されていると、ABEは隠しようがありません。
典型的な原因は、不要なグループに広すぎるアクセス権（例：ローカルのUsersグループ、Authenticated Users、Domain Users、Everyoneなど）が残っていることです。共有配下のフォルダー／ファイルから、そうした広範な許可を外して、必要なグループだけに絞ると、ABEが正しく動作して見える範囲が意図どおりになります。
Access Based Enumeration ABE を正しく理解する：できること・できないこと
まずはABEが何をしているかを整理します。ABEは「権限設計を肩代わりする魔法」ではなく、あくまで“一覧の見え方”を整える補助機能です。
| 項目 | ABEでできること | ABEではできないこと |
|---|---|---|
| フォルダー一覧（エクスプローラー表示） | アクセス権がないフォルダー/ファイルを一覧から非表示にする | アクセス権があるものを非表示にする（＝見せない）ことはできない |
| 直接パス指定（例：\\server\share\HR） | — | パスを知っていても権限がなければ拒否される（ABEは関与しない） |
| アクセス制御の本体 | — | アクセス可否はあくまで共有権限＋NTFS権限で決まる |
つまり、ABEが効いていないと感じるときは「ABEの設定」より先に、共有（Share）権限とNTFS権限のどこかに“見えてしまう権限”が残っていないかを疑うのが近道です。
ABEが効かない典型パターン：フォルダー名が見える“権限の入り口”を潰せていない
フォルダー名が見える原因は、ほぼ例外なく「一覧・読み取りが許可されている」ことです。具体的には次のような状態が多いです。
| よくある残り方 | なぜ問題になるか | 対策の方向性 |
|---|---|---|
| ルート配下に BUILTIN\Users や Domain Users が付いたまま | 意図せず全員に「一覧」や「読み取り」相当が付与され、ABEが隠せない | 本当に必要なグループだけに絞り、不要な広範グループを削除 |
| 親フォルダーの権限が 継承 されている | 「このフォルダーだけ」のつもりが配下に広がり、全サブフォルダーが見える | 継承を止める/スコープ（適用先）を見直す |
| 共有権限が広すぎる（Everyone/Fullなど）＋NTFSも広い | 両方広いと“見える”が確定し、ABEのフィルタ対象にならない | 共有はシンプルに、制御は基本NTFSで（または共有も最小化） |
| 「拒否（Deny）」で無理やり調整している | 例外が増え、後から追加したグループで意図せず見える/入れるが起きやすい | 原則は最小許可＋グループ設計、拒否は最終手段 |
特に多いのが、ローカルのUsersグループ等に広く許可が付いていて、「結果として読み取りが可能」になっているケースです。ABEは“アクセスできないものだけ”を隠すので、アクセスできてしまう権限の芽を摘むのが解決の本質です。
共有権限とNTFS権限：どちらか一方だけ見ても正解に辿り着けない
Windowsのファイル共有は、ざっくり言うと共有権限とNTFS権限の“掛け算（より厳しい方が勝つ）”で決まります。ABEの判定にも、実質的にこの組み合わせが影響します。
| 共有権限 | NTFS権限 | 最終結果 | 見え方の傾向 |
|---|---|---|---|
| 許可 | 許可 | アクセス可能 | ABEでも表示されやすい |
| 許可 | 拒否（または未許可） | アクセス不可 | ABEで非表示になりやすい（ただし権限の残り方次第） |
| 拒否（または未許可） | 許可 | アクセス不可 | 共有側で止まるため表示されないことが多い |
「ABEを有効化したのに見える」という状況は、上表の許可×許可がどこかで成立しているサインです。共有側かNTFS側のどちらか、または両方に“広すぎる許可”が残っていないか、必ず両面で確認します。
切り分け手順：まずは“どの権限で見えているのか”を特定する
闇雲に権限を剥がすと、業務停止や復旧作業が発生します。次の順番で「見えている根拠」を潰していくと、安全に整理できます。
- 共有のABE設定（フォルダー列挙モード）を確認する
- 共有権限に広すぎるグループがいないか確認する
- NTFS権限（特に継承）で広すぎる許可が配下に広がっていないか確認する
- 一般ユーザーを想定して有効なアクセス権（Effective Access）で検証する
- 変更は「ルート→サブフォルダー」の順に、小さく・段階的に適用する
ABE設定の確認とPowerShell例
SMB共有のABEは、共有のプロパティ（フォルダー列挙）で設定されます。PowerShellで確認・設定する例です。
Get-SmbShare -Name departments | Select Name, Path, FolderEnumerationMode
Set-SmbShare -Name departments -FolderEnumerationMode AccessBased既にAccessBasedになっている場合、原因はほぼ権限側にあります。
NTFS権限の棚卸しとicacls例
GUIだけで追うと見落としやすいため、いったん権限をテキストで吐き出すと全体像が掴みやすいです。
icacls D:\ShareRoot\departments /T
icacls D:\ShareRoot\userfiles /T出力に Users / Authenticated Users / Domain Users / Everyone などが配下まで広がっていないか、まず確認します。
設計の考え方：ゴールは「見える範囲」と「入れる範囲」を一致させること
現場で混乱が起きる最大の理由は、「見える（一覧に出る）」と「入れる（読み書きできる）」がズレることです。ABEで“見え方”を整えるにしても、権限設計としては次の2点を揃えるのが基本です。
- 見せたくないなら、そもそもアクセス権を与えない（ABEはその結果として隠れる）
- 見えても困らないなら、一覧は許可しても良い（ただし個人名・機微情報は例外）
今回の3つの共有を、要件に合わせて整理すると次のように設計しやすくなります。
| 共有 | 主な目的 | “見える”の扱い | “入れる”の制御 |
|---|---|---|---|
departments | 部署単位の情報共有 | 自部署のみ見せる（推奨）／運用上一覧を見せる、のどちらでも設計可能 | 部署グループ（RO/RW）で制御 |
uniquedrives | プロジェクト・用途別共有 | 関係者のみ見せる（推奨） | 用途別グループ（RO/RW）で制御 |
userfiles | 個人フォルダー | 本人以外は見せない（強く推奨） | 本人＋管理者のみ |
推奨の権限設計例：最小権限＋グループ運用で“ABEが効く土台”を作る
ここからは、3つの共有を「ABEが正しく効く」前提で設計する例を示します。ポイントは、広範グループの許可を配下に継承させないこと、そしてアクセスは必ずグループで付与することです。
departments：部署ごとに見せ分ける：HRはHRのみ見える
部署フォルダーを本当に隠したい場合は、ABE＋部署フォルダーにだけ権限を付与します。ルートには「共有を開ける最低限」だけを付け、サブフォルダーへ継承させません。
| 場所 | 付与対象 | 権限の目安 | 適用先 |
|---|---|---|---|
| departments ルート（例：D:\ShareRoot\departments） | Administrators / SYSTEM / ファイルサーバー管理者グループ | フルコントロール | このフォルダー、サブフォルダー、ファイル |
| departments ルート | Authenticated Users（または社内標準の全社員グループ） | 読み取り（一覧に必要な最小） | このフォルダーのみ |
| 各部署フォルダー（例：D:\ShareRoot\departments\HR） | FS_Dep_HR_RW | 変更（Modify） | このフォルダー、サブフォルダー、ファイル |
| 各部署フォルダー | FS_Dep_HR_RO | 読み取り | このフォルダー、サブフォルダー、ファイル |
この形にすると、IT所属ユーザーが \\fileserver\departments を開いても、HRフォルダー自体に権限がない限り、ABEによってHRが一覧に出ません（逆も同様です）。
「部署フォルダー一覧は見えても良い」場合の考え方
部署名が機微情報ではなく、一覧表示自体は許容できる場合は、ルートに「一覧」を許可して、ABEを無効にする（または部署フォルダー側に“一覧だけ”を許可する）という選択肢もあります。ただし、個人名が含まれる領域（userfiles）では同じ設計を使わないのが安全です。
uniquedrives：用途別共有は“例外”が増えるほど崩れやすい
用途別共有は「関係者が増減する」「期間限定」「外部委託が入る」など変化が多く、権限が散らかりやすい領域です。ここも部署共有と同じく、用途ごとのRO/RWグループを作り、ルートには広い許可を置かないのがコツです。
| 用途例 | 推奨グループ | 権限 | メモ |
|---|---|---|---|
| プロジェクトA | FS_Unique_ProjA_RW / FS_Unique_ProjA_RO | 変更 / 読み取り | 関係者の追加・削除はグループで完結 |
| 経理提出用（閲覧のみ） | FS_Unique_FinanceDrop_RO | 読み取り | 「提出」用途なら別途アップロード領域を分ける |
| 委託先連携 | FS_Unique_VendorX_RW（必要最小） | 変更 | 期間・範囲・監査ログの運用をセットで |
userfiles：自分以外のフォルダー名を見せない：ABEと個別ACL
個人フォルダー配下で他人の名前が見えるのは、心理的にもセキュリティ的にも避けたい状態です。userfilesは「本人＋管理者以外に権限を付けない」のが基本で、ここにABEを組み合わせると、本人以外のフォルダー名が一覧に出なくなります。
設計の要点は2つです。
- 親（
userfilesルート）には、全員に広い読み取りを付けない（付けるなら“このフォルダーのみ”に限定） - 各ユーザーフォルダーは、継承を止めて本人だけにフル権限を付ける
| 場所 | 付与対象 | 権限の目安 | 適用先 |
|---|---|---|---|
| userfiles ルート（例：D:\ShareRoot\userfiles） | Administrators / SYSTEM / ファイルサーバー管理者グループ | フルコントロール | このフォルダー、サブフォルダー、ファイル |
| userfiles ルート | Authenticated Users | 一覧・読み取り（最小）＋（必要なら）フォルダー作成 | このフォルダーのみ |
| 各ユーザーフォルダー（例：D:\ShareRoot\userfiles\t.yamada） | 当該ユーザー | フルコントロール | このフォルダー、サブフォルダー、ファイル |
| 各ユーザーフォルダー | Administrators / 管理者グループ / バックアップ運用に必要な主体 | フルコントロール（またはバックアップに必要な権限） | このフォルダー、サブフォルダー、ファイル |
重要なのは、「Authenticated Users（全員）」の権限が各ユーザーフォルダーに継承されていないことです。ここが残っていると、ABEを有効にしても他人のフォルダー名が見えてしまいます。
共有名の入れ子はできない：見せ方は「共有を増やす」か「1共有＋ABE＋NTFS」で作る
運用で意外と混同されがちなのが、共有名の扱いです。共有は「\\server\共有名」単位であり、\\fileserver\departments\HRのように“共有名の入れ子”はできません（これは「departmentsという共有の下にあるHRフォルダー」という意味になります）。
見せ方の選択肢は大きく2つです。
- 共有を1つにして配下をNTFS権限＋ABEで出し分ける（例：
\\fileserver\departments） - 共有を分ける（例：HR専用の共有を別名で作り
\\fileserver\HR$のように提供する）
部署が多い・用途が増える環境では、共有を増やしすぎると管理が破綻しやすいので、まずは「1共有＋配下をグループで管理」が扱いやすいことが多いです。
“広すぎる許可”を安全に削除するための実務ポイント
原因が分かったとしても、実作業で一番怖いのは「削除したら誰かの業務が止まった」です。そこで、削除・整理を行うときの現実的な進め方をまとめます。
作業前にやること：トラブル回避
- 対象の共有について、直近1〜2週間のアクセス要望や障害履歴を確認する
- 現行ACLをエクスポートしてバックアップする（例：
icacls /save） - 検証用の一般ユーザー（部署違いを含む）で「見える/入れる」を事前に記録する
変更の基本方針
- 拒否（Deny）で調整しない。まず許可（Allow）を最小化する
- “全員”に近いグループ（Users/Everyone/Authenticated Users/Domain Users）を配下に継承させない
- 例外は「例外用グループ」を作って吸収し、ACLに個人アカウントを直書きしない
権限変更後の確認チェック
| チェック項目 | 確認方法 | 期待結果 |
|---|---|---|
| departmentsで他部署フォルダーが見えない | 一般ユーザーでエクスプローラー表示 | 自部署のみ表示（ABEが効く） |
| userfilesで他人のフォルダー名が見えない | 一般ユーザーで一覧表示／検索 | 自分のフォルダーのみ表示 |
| 直パスアクセスの拒否 | 権限がない部署フォルダーを直指定 | アクセス拒否（権限が無いことが重要） |
| 管理者・バックアップ運用の継続 | バックアップジョブ、復元テスト | 必要な運用権限が保たれている |
運用でハマりやすいポイント：実際によく起きる落とし穴
- “昔のテンプレACL”が配下に残っている：古い運用で付けたUsers/Everyoneの読み取りが継承され続け、ABEの非表示条件を壊します。
- 個別ユーザー直付けが増えて追えない：異動・退職でメンテ不能になります。必ずADグループ経由に寄せます。
- 部署フォルダーの中にさらに機微領域がある：部署内でも権限階層が必要な場合、部署フォルダー直下に「Public」「Private」などを作り、同様にグループで分離します。
- “とりあえず拒否”を多用する：後からグループ追加したときに意図せずアクセス不可が出たり、逆に別経路で許可が残ったりして事故の温床になります。
- 共有を増やしすぎる：説明・申請・台帳管理が追いつかなくなります。まずは共有を絞り、配下のグループ運用で捌く方が長期的に安定します。
権限設計を“崩れにくく”するコツ：グループ命名と申請フローを整える
権限の整理は一度やって終わりではありません。新規プロジェクト、異動、組織変更があるたびに増えます。だからこそ、最初から崩れにくい型を用意しておくと、次の改修が圧倒的に楽になります。
グループの命名例：検索と棚卸しがしやすい
| 用途 | 例 | 意味 |
|---|---|---|
| 部署共有（読み書き） | FS_Dep_HR_RW | HR部署フォルダーに変更権限 |
| 部署共有（参照のみ） | FS_Dep_HR_RO | HR部署フォルダーに読み取り権限 |
| 用途別共有 | FS_Unique_ProjA_RW | プロジェクトA共有に変更権限 |
| 個人フォルダー例外（代理アクセスなど） | FS_User_t.yamada_Delegate | 委任アクセスが必要な場合の例外グループ |
申請・運用の最小セット
- 権限付与は「グループに所属させる」申請に統一し、ACLを触るのは管理者のみ
- 新しい共有（uniquedrives）は、RO/RWグループを必ずセットで作る
- 四半期ごとにグループメンバーを棚卸しし、不要メンバーを削除する
まとめ：ABEを効かせる最短ルートは「広すぎる権限を削って、必要なグループだけに絞る」
ABEは「アクセスできないものを見せない」機能なので、どこかで一覧・読み取り相当の権限が付与されている限り、フォルダー名は見えてしまいます。特にローカルUsersやAuthenticated Usersなどの広範グループが配下に残っていると、ABEの効果が消えます。
共有権限とNTFS権限を両面で棚卸しし、継承の扱いを整理し、部署・用途・個人の単位でグループを設計して付与する。この順番で整えると、「見える範囲／入れる範囲」を意図どおりに分離しながら、運用も破綻しにくいファイルサーバーにできます。
コメント