適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
詳細に設定されたアクセス許可を実装した後、SharePoint 環境でセキュリティの問題やパフォーマンスの問題が発生することがあります。 詳細に設定されたアクセス許可に関連していると思われる問題を解決するため、次の情報を検討してください。
詳細に設定されたアクセス許可のパフォーマンスに関連してよく発生する問題の推奨される注意事項と解決策
詳細に設定されたアクセス許可を広範囲に使用することに関連したパフォーマンス上の問題の影響を軽減する上で、以下の問題が役立つことがあります。 以下の問題のそれぞれは、詳細に設定されたアクセス許可に関連したパフォーマンスの問題の原因となっている環境セキュリティ、オブジェクト階層、カスタム コードへの変更内容について説明しています。 各問題は、1 つの Web に複数のドキュメント ライブラリが含まれている次の環境例から始まります。それぞれに一意にアクセス許可された子オブジェクトが多数あります。
問題 1:詳細に設定されたアクセス許可を削除し、Web レベルでのみセキュリティ設定を使用
きめ細かいアクセス許可が不要になるように環境を再設計するには、環境クリーンアップ プロセスを実装し、スコープ付き項目の数を調整して、長期的な環境のスケーラビリティを向上させることができます。 以下の推奨事項は、このソリューションの実現のために必要とされる環境クリーンアップおよびアーキテクチャ セキュリティの変更内容について説明しています。
環境セキュリティ クリーンアップ
ユーザーが Web レベル スコープから削除される際には、内部オブジェクト モデルで、Web レベルの下のすべてのスコープからそのユーザーを削除する必要があります。 既存のアクセス許可をクリーンアップするために個々のユーザーを削除する作業は、時間のかかるプロセスです。 むしろ、まず固有の項目レベルそれぞれのスコープを削除し、項目がその親オブジェクトからアクセス許可を継承するように設定します。 これは項目の単一のスコープの作業だけでよいため、最初にユーザーを削除する方法よりも時間が短くてすみます。
重要
現在の Web がサイト コレクションのルートにない場合に、その Web が親 Web からアクセス許可を継承するように設定されていると、それより下のすべての固有のスコープは削除され、単一の SQL Server ラウンド トリップですべてのアクセス制限メンバーシップが同時に上書きされます。
項目レベルのスコープがすべて削除された後、Web レベルのスコープの個々のスコープ メンバーシップを、アクセスを許可する 1 つ以上のグループ メンバーシップで置き換えることができます。
環境セキュリティ アーキテクチャの再設計
既存のきめ細かいアクセス許可とスコープを削除した後、長期的なアーキテクチャ 計画は、Web レベルでのみ一意のスコープを維持する必要があります。 次の図は、Web レベルのスコープのみが残るように構成される方法を示しています。 アーキテクチャのコア要件は、ビュー内の項目を処理するために必要な時間が長くなるため、ドキュメント ライブラリ内の階層の同じレベルの項目が多すぎることではありません。
解決策:
階層内の任意のレベルの項目またはフォルダーの最大数は、約 2,000 項目でなければなりません。
アーキテクチャにさらに変更が必要な場合は、ドキュメント ライブラリを別の Web またはサイト コレクションに移動することを検討してください。 また、保存されているコンテンツの分類または対象ユーザーに基づくビジネス ニーズおよびスケーリングの推奨事項をより綿密にサポートするように、ドキュメント ライブラリの数を変更することも可能です。
問題 2:階層構造の変更によって詳細に設定されたアクセス許可を使用する
きめ細かいアクセス許可を引き続き使用するように環境を再設計しますが、1 つの Web スコープに対する更新やサイズ変更が多すぎないようにするには、異なるセキュリティで保護されたドキュメント ライブラリを異なる Web に移動することを検討してください。
環境階層構造の再設計
次の図では、各ドキュメント ライブラリが一意のアクセス許可を持つ Web に配置されるように、物理アーキテクチャが変更されました。 さらに、項目レベルのきめ細かいアクセス許可を保持する必要がある場合は、ベスト プラクティスとして、アクセスを許可されるセキュリティ プリンシパルの累積数は約 2,000 に制限する必要がありますが、これは固定の制限ではありません。 したがって、すべての制限付きアクセス メンバー ユーザーを含む各 Web の有効なメンバーシップは、約 2,000 ユーザー以下にする必要があります。 これにより、各 Web レベルのスコープが大きくなりすぎないようにします。
一意にスコープが設定された子の数は重要な問題ではなく、大きな数にスケーリングできます。 しかし、アクセス許可を固有に設定した最初の Web に至るまでスコープのチェーンをさかのぼって、制限アクセスとして追加されるプリンシパルの数が、制限要素となります。
最後に、詳細に設定されたアクセス許可に特に関する問題ではないものの、フォルダーの構造は、ドキュメント ライブラリの単一の階層レベルが約 2,000 項目を超えないということを保障するものでなければなりません。 この制限は、ユーザーから要求されるビューのパフォーマンスを良好に保つ上で役立ちます。
問題 3:スコープ構造の変更によって詳細に設定されたアクセス許可を使用する
きめ細かいアクセス許可を引き続き使用するように環境を再設計するが、単一の Web スコープに対する更新やサイズ変更が多すぎないようにするには、項目をセキュリティで保護する別のプロセスを使用することを検討してください。 これは、多数の一意のスコープの原因が、オブジェクトのアクセス許可を動的に変更するイベント ハンドラーやワークフローなどの自動化されたプロセスであった場合に適用されます。 この場合の推奨事項は、固有のセキュリティ スコープを作成していたプロセスについて、コードに変更を加えることです。
動的にセキュリティの変更を加えるコードの再設計
次の図では、スコープ のメンバーシップによって親ドキュメント ライブラリと Web で ACL 再計算が発生しないように、スコープ アーキテクチャが変更されました。 前述のように、Web レベルのスコープが大きくなりすぎないようにするため、制限アクセス メンバーのすべてを含む Web の実質的メンバーシップは、約 2,000 以下でなければなりません。 この場合、制限アクセス権限を付与されるすべてのメンバーを保持する新しい SharePoint グループを実装することによって、スコープが大きくなり過ぎることがなくなります。 SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly メソッドを使用して、ユーザーを Web レベルの個々のスコープに追加すると、Web およびドキュメント ライブラリ レベルで制限付きアクセス権を持つとして確立された新しいグループに追加することもできます。
解決策:
項目レベルのきめ細かいアクセス許可を保持する必要がある場合、アクセス権が付与されるセキュリティ プリンシパルの累積数は、固定制限ではありませんが、約 2,000 に制限する必要があります。 セキュリティ プリンシパルの数が増えると、バイナリ ACL の再計算に時間がかかります。 スコープのメンバーシップが変更された場合は、バイナリ ACL を再計算する必要があります。 子項目の一意のスコープにユーザーを追加すると、最終的に親スコープ メンバーシップが変更されない場合でも、親スコープが新しい制限付きアクセス メンバーで更新されます。 この場合、親スコープのバイナリ ACL も再計算する必要があります。
前のソリューションと同様に、一意のスコープの子の数は重要な問題ではなく、大きな数にスケーリングできます。 スコープのチェーンへの制限付きアクセスとして追加される原則の数は、最初の一意にアクセス許可された Web に制限要因になります。