適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
詳細に設定された権限は SharePoint ファームのセキュリティに影響する可能性があります。 詳細に設定された権限を使用すると、潜在的なパフォーマンスの問題が発生することがあります。 以下の情報は、詳細に設定された権限の使用方法またはスケールが適切でないために環境内で発生した可能性のある問題に対処する場合に役立ちます。
詳細に設定された権限を回避するには、以下を実行します。
権限の継承をできるだけ解除しないようにします。
権限を割り当てる際にはフォルダーのメンバーシップに基づいてグループを使用します。
現在では SharePoint Server 検索の継続的クロール機能でセキュリティ情報が含まれるように変更されたため、ユーザーおよびグループの動的メンバーシップを管理する場合に SharePoint グループを使用しても問題ありません。 SharePoint Server 以前では、SharePoint グループで動的メンバーシップを使用すると、メンバーシップを変更してからフル クロールが実行されるまでの間、一部のメンバーに検索結果が正しく表示されませんでした。 現在では継続的クロール機能でセキュリティ情報が含まれるようになったため、動的メンバーシップまたはその他のセキュリティの変更はより短時間で変更され (既定値は 15 分)、クエリ結果のトリミングに使用されます。
可能な限り高いレベルで権限を割り当てます。 この戦略の一部として、以下の手法を検討します。
詳細に設定された権限を必要とするドキュメントを、各権限グループをサポートするように定義されているドキュメント ライブラリ内に配置します。ドキュメント ライブラリは別のサイト コレクションまたはサイトに保持します。
アクセスを制御するために別のドキュメント発行レベルを使用します。 ドキュメントが発行される前に、ドキュメント ライブラリ内のアイテムのみを承認できるユーザーに高度な権限およびバージョン管理設定を設定することができます。
ドキュメント ライブラリ以外 (リスト) では、 ReadSecurity および WriteSecurity の権限レベルを使用します。 リストが作成されると、所有者はアイテム レベルの権限を読み取りアクセス権または作成/編集アクセス権のいずれかに設定できます。
はじめに
この操作を開始する前に、前提条件に関する以下の情報を確認してください。
詳細に設定された権限の一般的な制限に関する問題を回避するためのベスト プラクティス
ビジネス要件により詳細に設定された権限を使用する必要がある場合は、以下の推奨されるベスト プラクティスを検討します。
ビュー内のアイテムの処理に必要な時間が長くなるため、ドキュメント ライブラリ内の階層の同じレベルの項目が多すぎないようにします。
イベント ハンドラーを使用して編集権限を制御します。 SPEventReceiverType.ItemUpdating および SPEventReceiverType.ItemUpdated メソッドを使用してイベントを登録するイベント ハンドラーを用意してから、コードを使用して更新を許可するかどうかを制御できます。 この方法は、ビューのレンダリング パフォーマンスに影響を及ぼすことなく、リストまたはアイテムのメタデータに基づいてセキュリティに関する決定を行うことができるため、非常に強力です。
AddToCurrentScopeOnly メソッドを使用して、SharePoint グループに制限付きアクセス メンバーシップを割り当てます。 この原則の重要な要素は、スコープ メンバーシップによって親ドキュメント ライブラリと Web で Access Control List (ACL) 再計算が行われないようにアーキテクチャを再設計することです。 スコープの変更に関する詳細については、「問題 3: スコープ構造の変更で詳細に設定された権限を使用する (2010 のみ)」をご覧ください。
きめ細かいアクセス許可を使用する場合、アクセス許可の解決を妨げる制限が意図せずに発生するのは簡単です。 このセクションでは、これらの制限の一部と、権限が適切に解決されるように設定する方法のベスト プラクティスについて説明します。
リスト内のスコープの数が多すぎる
リストまたはドキュメント ライブラリごとに 50,000 個のスコープの組み込み制限があります。 スコープ数が 50,000 に到達すると、該当するリストまたはドキュメント ライブラリへの新規スコープの追加は禁止されます。
ベスト プラクティス:
フォルダーなどの親オブジェクトに一意のスコープのみを設定します。
スコープが多いオブジェクトの下に、多数の一意のアクセス許可を持つオブジェクトを含むシステムを作成しないでください。
ビジネス要件によって、リストまたはドキュメント ライブラリ内に 50,000 を超える一意の権限を付与されたアイテムを含める必要がある場合は、一部のアイテムを別のリストまたはドキュメント ライブラリに移動させる必要があります。
組み込まれたスコープ制限を変更する
Microsoft PowerShell スクリプトを使用して、組み込まれたスコープ制限を変更します。
Windows PowerShell を使用して組み込まれたスコープ制限を変更するには
- 次のメンバーシップがあることを確認します。
SQL Server インスタンスにおける securityadmin 固定サーバー ロール。
更新するすべてのデータベースに対する db_owner 固定データベース ロール。
PowerShell コマンドレットを実行しているサーバー上の管理者グループ。
上に示した最小要件を満たすために必要なメンバーシップを追加します。
管理者は Add-SPShellAdmin コマンドレットを使用して、SharePoint Server 2016 のコマンドレットを使用する権限を付与できます。
注:
アクセス許可がない場合は、セットアップ管理者または SQL Server 管理者に連絡してアクセス許可を要求してください。 PowerShell のアクセス許可の詳細については、「 Add-SPShellAdmin」を参照してください。
SharePoint Management Shell を起動します。
PowerShell コマンド プロンプトで、次のコマンドを入力します。
$webapp = Get-SPWebApplication http://<serverName> $webapp.MaxUniquePermScopesPerList $webapp.MaxUniquePermScopesPerList = <Number of scope limit>ここで、
ここで <serverName> は SharePoint ファーム内のアプリケーション サーバーの名前です。
<スコープ制限の数>は、SharePoint リストごとに許可する一意のアクセス許可スコープの最大数です。 多数のスコープが同じ階層レベルに存在する場合、効果的な制限は 50,000 よりも大幅に少ないことが多くあります。 これは、その階層レベルの下位のアイテムに対する表示チェックが、そのアイテムの上位にあるすべてのスコープに対して実行される必要があるためです。 この制限により、特定のクエリで許可される効果的なスコープ数は 1,000 ～ 2,000 に減少します。
注:
コマンドライン管理タスクを実行するときには Windows PowerShell を使用することが推奨されています。 Stsadm コマンドライン ツールは推奨されていませんが、製品の以前のバージョンとの互換性をサポートするために含まれています。
権限スコープのメンバー数が多すぎる
前に説明したように、関連付けられた権限スコープのメンバーシップが変更されると、バイナリ ACL が計算されます。 これには、新しい制限付きアクセス メンバーが追加された場合も含まれます。 スコープのメンバーシップの数が増加するにつれて、バイナリ ACL の再計算に必要な時間が長くなります。
子オブジェクトの一意のスコープにユーザーを追加した場合、最終的にはその親スコープのメンバーシップが変更されない場合でも、親スコープが新しい制限付きアクセス メンバーで更新されるため、問題はさらに深刻になる可能性があります。 この場合、親スコープのバイナリ ACL も再計算される必要があるため、最終的には ACL が同じであっても、処理時間がさらに長くなります。
ベスト プラクティス:
権限スコープが個々のユーザー メンバーシップではなく、グループ メンバーシップに依存するようにします。 たとえば、1,000 の個々のユーザーを使用する代わりに 1 つのグループを使用すれば、権限スコープおよびその親スコープでは、999 のメンバーシップ エントリの分だけスコープが小さくなります。 また、制限付きのアクセス権限を持つ各ユーザーが更新される代わりに、1 つのグループが制限付きのアクセス権限で更新されます。 制限付きのアクセス権限のプッシュ速度や親スコープのオブジェクトの ACL を再計算する速度を向上させるためにも役立ちます。
重要
SharePoint グループを使用すると、インデックスのフル クロールが発生します。 可能であれば、ドメイン グループを使用します。
スコープの階層が非常に深い
前に説明したように、権限スコープの階層の深さは、制限付きアクセス ユーザーを親スコープに追加するために必要となる労力に影響する場合があります。 アイテムの上位 (一意の権限を付与された Web までの階層を含む) に存在する一意のスコープの数が多いほど、発生する追加の数が多くなります。 スコープの階層が非常に深い場合、最下層のスコープ アイテムの各メンバーシップを変更すると、制限付きアクセス権限を持つ、明示的に追加されたユーザーまたはグループのメンバーシップを追加することで親スコープが反復的に更新されるため、スコープのメンバーシップの変更が完了するまでに非常に長い時間がかかる可能性があります。 さらに、これにより、再計算が必要な ACL の数が増加し、パフォーマンスにも相応の影響が及ぼされます。
ベスト プラクティス:
一意の権限を付与された親オブジェクトの数を減らします。 これにより、子オブジェクトのスコープが変更された場合に、権限付きアクセス メンバーで更新されるスコープの数が減少します。