社内ファイルサーバーの設計で「共有権限は Everyone フル、実際の制御は NTFS で」という古典的なやり方に違和感を持ちつつも、完全には捨て切れていない──そんな管理者は少なくありません。この記事では、Microsoft の公式ドキュメントの考え方と、現代的な最小権限の原則を踏まえたうえで、「NTFS／共有（Share）権限をどう設計するか」を、規模別・運用スタイル別に具体的なパターンとして整理します。
NTFS 権限と共有（Share）権限の基本整理
そもそも「共有権限」と「NTFS 権限」は何が違うのか
まずは復習です。Windows ファイルサーバーでは、ネットワーク経由でアクセスされるとき、少なくとも次の 2 つのチェックが入ります。
- フォルダー／ファイルの NTFS 権限（セキュリティタブ）
- SMB 共有の 共有（Share）権限（共有タブまたは New-SmbShare など）
両者の違いをざっくり表にするとこうなります。
| 項目 | NTFS 権限 | 共有（Share）権限 |
|---|---|---|
| 適用される範囲 | ローカルアクセス＋ネットワークアクセス | SMB 経由のネットワークアクセスのみ |
| 設定場所 | フォルダー／ファイルの「セキュリティ」タブ | フォルダーの「共有」タブや SMB 共有設定 |
| 粒度 | ファイル単位まで細かく制御可能 | 共有単位（Read／Change／FullControl の 3 段階） |
| ローカル管理者の影響 | ローカル管理者は最終的にフルコントロール | ローカル管理者が共有設定を変更可能 |
| 歴史的な位置付け | NTFS が前提の現代 Windows では主役 | NTFS が使えない場合の補完としても設計されている |
Microsoft のアクセス制御の解説でも、「共有権限と NTFS 権限を両方設定した場合、ネットワークアクセス時には“より制限の厳しい方” が有効権限になる」とされています。
「最も制限の厳しい方が勝つ」の具体例
組み合わせルールはシンプルです。ネットワークアクセスでは、共有権限と NTFS 権限を掛け算した交差部分（インターセクション）が最終権限になります。
| 共有権限 | NTFS 権限 | 結果（有効権限） |
|---|---|---|
| Everyone：フル コントロール | 部門グループ：読み取り | 読み取りのみ |
| 部門グループ：読み取り | 部門グループ：変更 | 読み取りのみ（共有側が制限） |
| 部門グループ：変更 | 部門グループ：フル コントロール | 変更 |
| 部門グループ：読み取り | 部門グループ：アクセスなし | アクセス拒否 |
この仕組みのせいで、共有側でうっかり権限を絞ってしまうと、「NTFS はちゃんと付けたのにアクセスできない」というトラブルが起きます。この記事で後述するように、「どちら側でどこまで絞るか」をあらかじめ方針として決めておくことが重要です。
Microsoft の公式スタンスは？「唯一の正解」は示していない
公式ドキュメントが言っているのは「設計指針」と「最小権限」
Microsoft は、共有権限と NTFS 権限について「必ず Everyone フルにしろ／するな」というような単一のベストプラクティスは明示していません。公式ドキュメントでは、主に次の 3 点が一貫して述べられています。
- 共有と NTFS の役割の違いを理解したうえで、両方を使って適切にロックダウンすること
- ネットワークアクセス時は「より制限の厳しい方」が最終権限になること
- 環境全体として最小権限の原則（Principle of Least Privilege）を徹底すること
つまり、「Everyone フル＋NTFS で制御」が 公式に禁止されたわけでも、唯一推奨されているわけでもない、というのが現状です。Microsoft 自身の例でも、共有側で Domain Users や特定グループに Change あるいは Full Control を与え、実際のアクセス権は NTFS 側で細かく制御するパターンが紹介されています。
昔と今で何が変わったのか
かつてのトレーニングでは「共有＝Everyone フル、NTFS で制御」が半ば定石のように教えられていました。その背景には次のような事情があります。
- Windows NT〜2000 期は、NTFS の普及途上であり、共有権限が主な制御メカニズムだった
- ツリー構造が複雑になると、共有側と NTFS 側の両方を細かく管理するのは難しい
- 「権限はできるだけ 1 か所（NTFS）で管理した方がトラブルが減る」という実務的な知見
一方で、近年はランサムウェアや内部不正など、ファイルサーバーの侵害リスクが高まり、「そもそも Everyone や Authenticated Users にフルを与えた構成そのものが危険」という見方も強くなっています。セキュリティベンダーのガイドラインでは、「共有に Everyone や Authenticated Users を使うこと自体を避ける」ことを推奨するものもあります。
つまり現在は、
- 運用を簡素化するために「共有は開放気味＋NTFS で締める」
- ゼロトラスト寄りに「共有でも最小権限をかけ、多重防御にする」
という 2 つのパラダイムが共存しており、どちらを選ぶかは環境の規模・リスク許容度・運用体制次第、というのが現実的な答えです。
Everyone / Authenticated Users / Domain Users の違いと注意点
「共有を Everyone にするのは怖いから Authenticated Users にしておきたい」という悩みはよく聞きます。ここで代表的な SID の違いを整理しておきます。
| グループ | 概要 | 実務的な注意点 |
|---|---|---|
| Everyone | ほぼすべてのユーザーを含む。近年の Windows では匿名ユーザーは含まれない。 | Guest なども含まれる可能性があり、読み取りであっても安易に使うべきではない。 |
| Authenticated Users | ドメイン／ローカルに正しく認証されたユーザーすべて。 | 社内 AD 環境なら「とりあえず社内ユーザー全員」を指すので、Everyone よりは安全。 |
| Domain Users | そのドメインに所属する標準ユーザーアカウント。 | サービスアカウントや一部特殊なアカウントを除外できるため、実務上は最も使いやすい “全社員” 的グループ。 |
最小権限の原則を守るなら、「共有権限に Everyone フル」はできれば避けたいところです。現代的な設計では、少なくともAuthenticated Users または Domain Users を最小限の権限（Change または Read）で使うことをスタート地点にし、必要に応じてさらに細かいグループに置き換えていく、という考え方が現実的です。
代表的な 2 つの設計パターン
ここからは、実際の構成としてよく採用される 2 パターンを、メリット・デメリットとともに整理します。
パターン A：共有は広く開放、NTFS で最小権限
「共有＝Authenticated Users または Domain Users に変更 or フル」「実際のアクセス制御＝NTFS」とする方式です。かつて「共有＝Everyone フル」と言われていたやり方の、安全寄りアレンジだと考えると分かりやすいと思います。
構成イメージ
| レイヤー | 設定内容 | ポイント |
|---|---|---|
| 共有権限 | Authenticated Users または Domain Users：変更（Change） BUILTIN\Administrators：フル | 共有側は「ドメインの通常ユーザーならひとまず通す」レベルにする。 |
| NTFS（ルート） | 管理者／バックアップアカウント：フル 部門別のドメインローカルグループ：変更／読み取りなど | NTFS 側に AGDLP を適用し、実際のアクセス制御はすべてここで行う。 |
| NTFS（サブフォルダー） | 必要に応じて継承を切り、特定プロジェクトグループだけにアクセス権を絞る | 継承を多用し、例外だけをピンポイントで明示するのがコツ。 |
メリット
- 権限管理を NTFS の 1 か所に集中できるため、設計・検証・棚卸しがしやすい
- サブフォルダーへのアクセスやディレクトリトラバーサルで、共有側の過度な制限に引っかかりにくい
- Access-Based Enumeration（ABE）を併用すると、「見えるフォルダー＝アクセスできるフォルダー」にでき、ユーザー体験も良い
- 大規模環境でのテンプレート化・自動化（PowerShell など）に向いている
デメリット／リスク
- NTFS 側の設定ミスがそのまま情報漏えいにつながりやすい（誤って Domain Users に変更を付けるなど）
- 「とりあえず Everyone フル」で運用されがちで、レビューされないまま長年放置されるケースも多い
- 共有をまたいだ細かい制限（共有 A は読み取りのみ、共有 B は変更可など）は表現しにくい
向いている環境
- ユーザー数・部署数が多い大規模組織
- 専任のインフラ／セキュリティ担当がいて、NTFS 権限の設計・棚卸しを定期的に行える
- ファイルサーバーが複数台・複数拠点にまたがる
パターン B：共有側でも最小権限（多重防御）
こちらは、共有権限の段階で部門ごと・用途ごとに最小権限を付与し、NTFS 側はそれをさらに細かく調整する方式です。いわば 二重ロック に近い考え方です。
構成イメージ
| レイヤー | 設定内容 | ポイント |
|---|---|---|
| 共有権限 | Dept_Sales_RW：変更 Dept_Sales_RO：読み取り BUILTIN\Administrators：フル | 共有名 Sales$ に対して、Sales 部門用グループだけを許可する。 |
| NTFS（ルート） | Dept_Sales_RW：変更 Dept_Sales_RO：読み取り | 共有と NTFS で同じグループを基本にしつつ、後述の AGDLP 構造で整理。 |
| NTFS（サブフォルダー） | 「人事連携」「経営会議」など、Sales 内でもさらに限られたグループだけに許可 | 共有レベルの制限＋NTFS の制限が掛け合わさり、多層防御になる。 |
メリット
- 万一 NTFS 側で誤って広く許可しても、共有側が「最後のフタ」になる
- 「この共有は誰に、どのレベルで公開しているか」が一目で分かる
- 小規模環境では、共有数がそこまで増えないため運用負荷が現実的
デメリット／リスク
- 共有側と NTFS 側で権限がズレると、トラブルシュートが難しくなる
- 共有を細かく分けすぎると、ユーザー側のドライブマッピングも煩雑になる
- 大規模環境では、共有ごとの設定変更・棚卸しがボトルネックになる
向いている環境
- 数十〜数百ユーザー程度の中小規模組織
- 個人情報や経営情報など、一部に非常に高リスクなデータが含まれる
- 「とにかく間違っても外に出したくない」タイプのデータが多い（人事・経理・医療など）
どちらを選ぶ？ 環境別の判断マトリクス
| 観点 | パターン A：共有広く＋NTFS 最小権限 | パターン B：共有でも最小権限 |
|---|---|---|
| 組織規模 | 数百〜数万ユーザー向け | 〜数百ユーザー向け |
| 運用体制 | 専任インフラチームあり。標準設計・自動化ができる。 | 兼任管理者が多い。設定箇所を増やしすぎたくない。 |
| データの機密性 | 「中〜高」レベルが中心。極端に機微な情報は別システムで管理。 | 個人情報・機微情報をファイルサーバーで直接扱うケースが多い。 |
| 誤設定の影響 | 誤った NTFS 設定がそのまま開示につながるリスクが高い。 | 共有側の制限により、一部の誤設定が吸収されることがある。 |
| ユーザー体験 | 共有を少なくし、サブフォルダーを ABE で隠すことでスッキリ。 | 用途ごとに共有を分けるため、ドライブ文字がやや増えがち。 |
| おすすめ度 | 大規模・複雑な環境では第一候補 | 小規模・高機密データ中心なら有力候補 |
実務上は、両方を併用することも多く、「通常データはパターン A、特に機密性の高い共有だけパターン B」といったハイブリッド構成にするのが現実的です。
グループ設計：AGDLP で「誰に何を許可したか」を見える化
権限設計のベースとして、Microsoft が推奨しているのが AGDLP モデルです。
- Account（ユーザー・コンピュータアカウント）
- Global Group（業務ロール、例：Sales_Staff）
- Domain Local Group（リソース単位の権限グループ、例：FS_Sales_RW）
- Permission（NTFS や共有への実際の許可）
NTFS／共有権限に直接ユーザーを追加するのではなく、次のような階層で整理します。
| レイヤー | 例 | 役割 |
|---|---|---|
| Account | user_001（田中太郎） | 実ユーザー。ここを直接権限に使わない。 |
| Global Group | GG_Sales_Staff | 「営業部の一般職」のような業務ロール。 |
| Domain Local Group | DL_FS_Sales_RW | 「Sales 共有に対して変更可能」などリソース固有の権限。 |
| Permission | DL_FS_Sales_RW に対して Sales$ 共有と D:\Data\Sales に変更権限を付与 | 実際の NTFS／共有権限設定。 |
この構造を守ることで、「誰が」「どのロールで」「どの共有・フォルダーに」「どのレベルの権限を持っているか」が、後から見ても分かりやすくなります。棚卸しや監査、異動時の権限変更もグループ単位で行えるため、運用負荷を大きく減らせます。
ABE（アクセスベース列挙）で「見えるフォルダーだけ触れる」世界にする
Windows Server では、Access-Based Enumeration（ABE）を有効にすると、ユーザーが読み取り権限を持たないフォルダーをエクスプローラーから隠すことができます。
- ユーザーから見えるのは「アクセス権を持つフォルダー」だけ
- 「見えるけど入れない」フォルダーが減り、問い合わせも減る
- フォルダー名自体が機密情報を含む場合（例：2025_リストラ案）、
存在すら見えなくなるためリスクを下げられる
パターン A（共有広く＋NTFS 最小権限）と ABE を組み合わせると、
- 共有は 1〜数個に集約
- NTFS ＋ ABE で「見える＝アクセス可能」を実現
という現代的なファイルサーバーの姿になります。ABE 自体は Windows Server 2003 R2 から存在し、Windows Server 2016〜2025 でも標準的な機能としてサポートされています。
フォルダー構成と継承の設計
トップレベルを増やしすぎない
ファイルサーバーを長年運用していると、いつの間にか共有やトップレベルフォルダーが乱立し、どこに何を置くべきか分からなくなりがちです。ファイルサーバーのセキュリティベストプラクティスでは、「トップレベルフォルダーはなるべく少なく、分かりやすく保つ」ことが推奨されています。
例として、次のような構成がシンプルで運用しやすいです。
D:\Data ├─ Dept │ ├─ Sales │ ├─ HR │ └─ IT ├─ Project │ ├─ PJ_A │ └─ PJ_B └─ Public
共有は例えば次のようにまとめます。
| 共有名 | パス | 想定用途 |
|---|---|---|
| Data$ | D:\Data | 標準的な業務データ（ABE＋NTFS で制御） |
| HR$ | D:\Data\Dept\HR | 人事部専用の高機密データ（パターン B） |
このように、「原則 1 共有＋例外的に高機密共有を追加」という方針にしておくと、管理・説明ともに楽になります。
継承を基本に、例外だけ明示する
NTFS 権限は、基本的にはルートで設定し、サブフォルダーには継承させる方が管理が簡単です。ベストプラクティスでは、「権限は可能な限り上位で設定し、下位での例外を最小限にする」ことが推奨されています。
- Dept\Sales には Sales 部門グループをフル継承
- その下の「HR連携」フォルダーだけ継承を切り、人事＋営業マネージャーのみに限定
といった形で、「例外」だけをピンポイントに設定すると、構造を頭に描きやすくなります。
拒否（Deny）権限の扱い：最終手段としての運用
共有／NTFS のどちらにも「拒否（Deny）」を設定できますが、これを多用すると権限の読み解きが極端に難しくなります。
- 「Allow」と「Deny」が混在すると、どちらが優先されるかを毎回検証する必要がある
- 上位フォルダーに設定した Deny が、下位で思わぬ影響を与えることもある
- 後から新しいグループを追加した際に、既存の Deny と衝突しやすい
そのため、拒否の利用は次のようなケースに限定するのが現実的です。
- 「ほぼ全員に与えている権限から、特定のユーザーだけ除外したい」場合
- どうしても構造上、Allow だけで表現できない例外がある場合
また、可能な限り上位のフォルダーでは Deny を使わず、例外フォルダー側で限定的に使うのが、トラブルシュートの観点では安全です。共有権限側の Deny は、さらに影響が読みにくくなるため、基本的には使用を避けることをおすすめします。
トラブルを防ぐ運用ベストプラクティス
パターンごとの「やってはいけない」例
| パターン | ありがちな NG 設定 | 発生しうるトラブル |
|---|---|---|
| 共有広く＋NTFS 最小権限 | 共有＝Everyone フル＋NTFS 側で Domain Users に変更権限を付与 | 全社員が全データを読み書きできる「何でも箱」状態になる。 |
| 共有広く＋NTFS 最小権限 | NTFS 側でアクセス権を追加したのに、共有側が Read のまま | ユーザーが「編集できない」と問い合わせ。設定箇所が 2 箇所で混乱。 |
| 共有でも最小権限 | 共有・NTFS で別のグループ名を使い、紐付きが分からない | 棚卸し時に「このグループは何用？」から毎回調査が必要。 |
| 共有でも最小権限 | 共有を用途ごとに細かく作りすぎる | ユーザーのドライブ文字が増えすぎ、どこに保存すべきか分からなくなる。 |
変更管理とドキュメント化
どのパターンを選ぶにせよ、次のような「台帳」を持つことを強くおすすめします。
- 共有名、パス、用途
- 共有権限に設定しているグループと権限レベル
- ルートフォルダーに設定している NTFS 権限（グループ名と権限）
- 継承を切っているサブフォルダーと、その理由
最低限これだけを Excel や Wiki に整理しておくだけでも、「なぜこの設定なのか」「誰が使っているのか」が説明しやすくなり、不要権限の削除や棚卸しが一気に楽になります。
監査ログと定期レビュー
ファイルサーバーのセキュリティベストプラクティスでは、権限設定だけでなく、アクセスログや権限変更ログの監査も推奨されています。
- 重要共有・フォルダーに対するアクセス監査（成功・失敗）を有効化
- 特定の管理者グループによる「権限変更イベント」の監査
- 年 1〜2 回程度の棚卸し（不要グループ・不要権限の削除）
SIEM や専用ツールを使うのが理想ですが、そこまでできなくても、イベントログに最低限の記録を残しておくだけでも、インシデント発生時の調査に大きく役立ちます。
実践的な設計例
例 1：大規模環境での標準ファイルサーバー（パターン A ベース）
前提：
- ユーザー数 1000 名超の企業
- 部門数が多く、ファイルサーバーも複数台
- 専任インフラチームが存在し、PowerShell による自動化も可能
設計方針：
- 共有は「Data$」1 つに集約
- 共有権限は Domain Users：変更、管理者：フル
- NTFS 側で部門／プロジェクトごとの権限を AGDLP で管理
- ABE を有効化し、「見えるフォルダー＝アクセスできるフォルダー」にする
この場合、
- 新しい部門ができたら、GG_xxx_Staff と DL_FS_xxx_RW を追加し、
D:\Data\Dept\Xxx にだけ NTFS 権限を付与 - 共有側は一切変更しない（標準設定からいじらない）
という運用にすることで、「権限は NTFS グループをいじる」というルールに集約できます。
例 2：機微情報を扱う人事部門共有（パターン B ベース）
前提：
- 人事部門が、給与・評価・採用選考など極めて機密性の高い情報をファイルサーバーで扱う
- 一部のファイルは経営層も閲覧するが、一般社員には絶対に見せたくない
設計方針：
- 人事専用の共有「HR$」を別途作成
- 共有権限は DL_FS_HR_RW（人事部）と DL_FS_HR_RO（経営層）のみ
- NTFS 側でさらに「評価」「給与」などフォルダーごとに権限を分ける
- 一般社員は HR$ 共有自体にアクセスできない（パターン B）
このように、高機密データだけをパターン B で硬く守り、それ以外はパターン A で運用効率を優先するのが現実的な折衷案です。
最小権限と運用負荷のバランスをどう取るか
最後に、当初の問いに対する実務的な答えをまとめます。
- Microsoft は「共有＝Everyone フルにせよ」とも「絶対にするな」とも言っておらず、
「共有＋NTFS で最小権限を実現せよ」という設計指針だけを示している。 - 大規模・複雑な環境では、共有側は Authenticated Users or Domain Users を広めに許可し、
権限管理を NTFS に集約するパターン Aが現実的。 - 小規模／高機密データでは、共有側でも部門・用途ごとに権限を分けた
パターン B にすることで多重防御を実現できる。 - どちらを選ぶにせよ、AGDLP によるグループ設計・ABE・ドキュメント化・監査を組み合わせることが、
「最小権限」と「運用効率」を両立させる現代的なベストプラクティスと言える。
「Everyone フル＋NTFS で制御」は、今でも実務上はよく見かける構成です。ただし、2020 年代の脅威環境を踏まえると、少なくとも「Everyone」から「Authenticated Users／Domain Users」への置き換え、そして権限設計そのものの見直しは、どの組織でも検討すべきタイミングに来ていると言えるでしょう。
コメント