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