これはファイルサーバーのアクセス許可に推奨される/有効な方法ですか？

ファイルサーバーはIT業界では当たり前のことであり、グループを作成してクライアント上の共有フォルダーへのクライアントアクセスを管理するためのアクセス許可を適用する方法について、一般に受け入れられている慣行（ここでは「ベスト」という言葉を使うのをためらいます）があるかどうか知りたいです。ファイルサーバー。

私の現在の仕事では、ACLの数十のグループから個々のユーザーを直接ファイルシステムに置くだけに至るまで、これを行うためのさまざまな方法をかなり混乱させてしまいました。私の仕事は、混乱を解消し、会社全体でこれに対処するためのある種の標準化された方法（大規模な環境、15万人の従業員、9万人のクライアントコンピューター、数百のファイルサーバー）を考案することでした。

この問題についての私の理解から、保護されたリソースごとに必要なアクセスレベルごとに少なくとも1つのグループが必要であるようです。このモデルは、別のアクセスレベルをサポートする必要がない限り、ファイルシステムのアクセス許可に再度触れる必要がないという点で、最も柔軟性が高いようです。欠点は、複数の共有リソースで同じグループを再利用するよりも多くのグループを作成することです。

ここに私が何を意味するかを示す例があります：

FILE01という名前のファイルサーバーに "Test Results"という共有があり、読み取り専用アクセス、読み取り/書き込みアクセス、およびフルコントロールが必要なユーザーがいます。1つの保護されたリソース* 3つのアクセスレベル= 3つのセキュリティグループ。AD環境では、これらをユニバーサルグループとして作成するため、フォレスト内の任意のドメインからユーザー/グループを簡単に追加できます。各グループは共有フォルダとアクセスレベルを一意に参照するため、グループ名にはこれらの「主要な」データが組み込まれ、権限は次のようになります。

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

通常、ビルトインSYSTEMアカウントと、フルコントロールアクセス権を持つビルトインAdministratorsも含まれます。この共有へのアクセス権を実際に誰が取得するかに対する変更は、ACLに触れる必要なく、グループメンバーシップを使用して処理できるようになりました（マネージャー、技術者、QAアナリストなどの特定のビジネスロールを表す「ロール」グループを追加するか、または個人のみ） 1回限りのアクセスのユーザー）。

2つの質問：

1）これは実際にアクセス許可を処理するための推奨または有効なアプローチですか、それともより単純でエレガントなソリューションが欠けていますか？私は特に、継承を使用するソリューションに興味がありますが、物事が変わったときにファイルシステムの大部分を再ACLする必要がないという柔軟性を保持しています。

2）環境内でファイルサーバーのアクセス許可とグループ構造をどのように処理していますか？大規模な環境でも作業している人にはボーナスポイント。

私のアプローチは、ファイル/ディレクトリレベルのファイル権限を使用しないことです。ファイル共有レベルのアクセス許可を使用し、サーバーファイルシステムのデータドライブ全体をEveryone Full Control（これは無効になります）に設定します。

長年にわたって（10 +）、NTFSアクセス許可はより複雑で、より多くのエラーにつながることがわかりました。権限が正しく設定されていない場合、または継承が壊れている場合は、データを公開し、そのデータを見つけて見づらくします。さらに、移動/コピーの問題にさらされます...ファイルを移動するユーザーもファイルのACLを移動しますが、コピーは宛先ACLを継承します。

読み取り/書き込みグループは同じですが、Comp Mgmt MMCを使用してファイル共有全体で使用します。十分にしないでください...ユーザーは部分的な知識/最善の意図で自分を撃ちます。

そのアプローチは悪くありません。原則として、アクセス許可を追加するために個々のユーザーを使用することはなく、グループを使用してください。ただし、グループはリソース全体で使用できます。たとえば、HRはファイルへのRWアクセスを持っているかもしれませんが、MANAGERSはRを持っているかもしれません。アクセスベースの列挙を設定することもできます。次のWebキャストをご覧ください。

TechNet Webキャスト：Windows Server 2003管理シリーズ（12/4）：グループ管理（レベル200）

アクセスベースの列挙は、人生も見やすくします：

アクセスベースの列挙

ABEは、管理する必要があるさまざまな共有の数を減らすのに役立ちます。

あなたのアプローチは基本的に私がそれに取り組む方法です。
私が追加する唯一のものはこれらです：

1）私は、おそらくこれに対する外れ値に遭遇する1つのサーバーだけでなく、サーバー全体で必要なものを評価することによって、「ロール」スキームに追加しますが、それらに関する私の理論は、それらに遭遇したときに別のグループを作成することです。外れ値が1つある私の経験では、多くあります。

2）ユニバーサルグループ内のメンバーとグループはグローバルカタログサーバーにレプリケートされ、ドメインローカルとグローバルではグループのみであるので、すべてのユニバーサルグループのレプリケーションヒットが発生したときに、ユニバーサルグループの必要性を強く再評価します。グローバルカタログサーバーに複製されます。そのため、ユニバーサルグループに変更を加えた場合、レプリケーションは開始されますが、グローバルおよびドメインローカルでは行われません。

アクセスレベルごとにリソースグループを使用する方法は正しいです。私が検討する唯一のことは、リソースにドメインローカルグループを使用することです。サーバー固有のリソースグループを作成する場合は、必ずしもユニバーサルグループを使用する必要はありません。

リソースにドメインローカルグループを使用する場合の欠点は、グループの合計数が増えることです。利点は、Zypherが指摘したように、レプリケーションの問題が少ないことです。

提案されたアプローチはかなりしっかりしているようです。ただし、最初にファイル共有を設定する方法に注意する必要があります。推奨される方法は、サブフォルダを含む単一のトップレベルの共有を作成し、そこにグループのアクセス許可を割り当てることです。NTFSは、最上位フォルダの「トラバースフォルダ/実行ファイル」をバイパスして、サブフォルダへのアクセスを許可できます。

構造は\ servername \ sharename \ group-folderのようになり、共有のアクセス許可は「sharename」フォルダに設定するだけでよく、実際のNTFSアクセス許可は「group-folder」フォルダに設定します。

この種の設定でも、ファイルサーバーのパフォーマンスが向上します。

私がする他の一般的なことは、グループの名前がグループのフォルダー名と同じになるようにグループの命名規則を設定し（必要に応じてFC / RW / ROを追加）、フォルダーのUNCをグループの説明に貼り付けることです（ログオンスクリプトがそれを読み戻してドライブマッピングをそのように設定できるように、また、どの共有フォルダがどのグループに適用されるかをより簡単に確認できるようにするため）。

Windows 2000以降（Mark MinasiのMastering Windows Serverシリーズで説明されているので、詳細についてはそちらを参照してください）、Windowsファイルサーバーで使用している標準的な方法は、入れ子にするためにファイルサーバー自体にローカルなグループを使用することです。

たとえば、MUPPETSというドメインのKERMITという名前のファイルサーバーについて考えてみます。

KERMITにいくつかのファイル共有があるとします。

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

アクセスのためにKERMITのローカルグループを作成し、指定したとおりにファイルシステムに対する権限を付与します（つまり、共有ごとのアクセスレベルごとに1つのグループ）。

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

これらはローカルグループであるため、ドメインローカルグループ、グローバルグループ、ユニバーサルグループ、フォレスト内の任意のドメインのユーザーアカウントなど、他のグループやユーザーを好きなように配置できます。アクセス権管理は、ファイルシステムやADではなく、ファイルサーバーのグループに対してローカルになりました。

これにより、グループ管理に追加のレイヤーが追加されますが、（たとえば）サイトローカル管理者が、そのファイルサーバーに対する管理者権限以上のものを必要とせずに、自分のファイルサーバーを管理できるという利点があります。フェデレーション型のブランチオフィス構造があり、すべてのオフィスがサーバーで独自の処理を行う場合、これは大きなメリットになります。数十人のローカルサイト管理者にAD管理者権限を与える必要はありません。

また、ADが多数のグループで乱雑にならないようにし（サーバーごとの共有ごとのアクセスレベルごとに1つのグループが非常に迅速に追加される可能性があります）、GC間のグループレプリケーションを最小限に抑えます。権限の代わりにロール用にADグループを予約できます。

環境が厳密に標準化されており、すべてのファイルサーバーが同一で複製されている場合、これは明らかに、不要なグループのもう1つの層です。また、特定のADグループがすべての単一ファイルサーバーに存在する共有に対して同じ権限を持つ必要があることがわかっている場合は、それを維持するためにいくつかの自動化が必要になります。

簡単に言うと、ファイルサーバーが互いに異なっているほど、マシンローカルグループを使用することは理にかなっています。それらが類似しているほど、現在使用しているシステムをより多く使用したいです。

私はNetWareからWindows Server 2008への移行を検討しているので、これは最近、私の頭に浮かんできました。Server 2008（およびある程度Server 2003R2）には、この移行を本当に容易にする非常に優れた機能がいくつかあります。Server 2008には、すぐにアクセスベースの列挙が付属しています。これは、ユーザーが権限を持つディレクトリのみを表示できる非常に優れた機能です。次のような共有がある場合...

\\ user-home-srv \ homes \

ABEがなければ、エンドユーザーには数十、数百、数千のディレクトリが表示されます。ABEでは、エンドユーザーには1つしか表示されません。同じことが共有共有にも当てはまります。ABEを使用すると、必要に応じて、部門のすべてのディレクトリに1つの巨大なボリュームを作成でき、ユーザーがアクセスできないディレクトリを使用して、ユーザーを混乱させることはありません。ACLの問題ではありませんが、ある程度関連しているので取り上げます。

Server 2008が以前のバージョンよりも優れているように見えるもう1つのことは、ACLの継承です。大きなツリーの上部にあるACLの変更を葉まで伝搬する方が速いようです。

Netwareのレガシーにより、多数のグループがあり、その中に誰がいるかに基づいて名前が付けられています。そのうちのいくつかは、アクセス権を与えるために名前が付けられています。アクセスが制限されているディレクトリの場合は、「RO」「完全」という用語も使用します。

私たちはモノリシックな「共有」ボリューム（まだNetWare上にありますが、Windowsに移行するときにモノリシックにする予定です）を持っています。これは、4,400人のワーカーすべてのための単一の共有ボリュームであり、350万以上のファイルを持っています。トップレベルのディレクトリはすべて部門名であり、各部門はその内部で何が行われるかを規制します。非常に大規模な部門にはいくつかの例外があります。それらには、ACLが設定された第2レベルのディレクトリがあります。

私の最後の仕事では、許可を設定することさえできたので、求人に応募する人事従業員は自分のサーバーで自分のアプリケーションデータを見ることができませんでした。これを行うには、継承権フィルタがいくつか必要でした。これは、Windowsの「ブロック継承」タグに似ています。そこにはすべてを文書化するのが難しい部分がありましたが、うまくいきました。

最良の場合のシナリオは、すべてのユーザーをユーザーのジョブロールの1つのセキュリティグループに追加することです。その後、役割は必要に応じてアクセスを委任されます。

同様に、共有フォルダには、「FILE01-Test Results-RW」の例のように、「リソース」セキュリティグループを使用してアクセス権を付与する必要があります。これには、ジョブの役割、部門の役割、またはその他の該当するグループが含まれます。

この設計の利点は、グループ（チーム、部門など）ごとにアクセスを委任することであり、追跡が困難な1回限りのアクセスではないことです。ユーザーが別の部門に異動する場合、古いアクセスをすべてクリーンアップする必要があります。

欠点は、グループが誤用される可能性があることです。グループの使用目的を明確に区別することで、共有に割り当てられたリソースグループが部門のグループであるかのように再利用されず、複雑なアクセスの混乱が生じます。