SharePoint Online でアイテムごとにアクセス権を許可する際の注意点
全般的な情報交換
-
SharePoint Online でアイテム単位にアクセス権を付与する運用スタイルがあります。
この形式で運用する場合は、リストまたはライブラリごとに固有のセキュリティ スコープ 5000 が制限であることを注意する必要があります。
下記に SharePoint Online の制限事項が記載されたページがあります。
タイトル : SharePoint Online の制限
このページによると、以下の記載があります。
リストまたはライブラリごとに一意のセキュリティ スコープ- 5,000 です。大規模なリストは、可能な限り少ない権限を持つをデザインします。
より簡潔に記載すると、リストまたはライブラリにおいて、アイテム単位で固有のアクセス権を割り当てる場合 4,999 件までが格納可能ということになります。
エラーが発生するしきい値はさらに大きな値になります。これを超えてもすぐにエラーになることはありませんが、この制限を超えて運用している場合、パフォーマンスが突然大幅に下がるなどの発生例が確認されております。
客観的に利用者からみると、非常に不便な制限事項ではありますが、製品の特性ですので、これを考慮した利用方法が求められるため、情報開示に至りました。
セキュリティ スコープの数え方とは
セキュリティ スコープは、固有のアクセス権の数となります。
固有のアクセス権は、画面上ではリボン メニューで、[権限の継承を中止] をクリックすることであらたに 1 つ割り当てられます。
ここをクリックし、独自のアクセス権を保持したフォルダーやファイル、アイテムの数がセキュリティ スコープの数としてカウントされます。
例えば、以下のシナリオを想定します。以下のライブラリでは、1 つのフォルダー、2 つのファイルで固有のアクセス権を割り当てています。
この状況においては、親となる、リスト ライブラリのセキュリティ スコープに加え、3 つのフォルダーやファイルでの固有アクセス権をカウントし、合計 4 つのセキュリティ スコープが存在すると算出できます。
一般的に、アイテムごとに固有の権限を割り当てるシナリオでは、画面 UI ではなく、以下のようなカスタム ソリューションが使用されます。
・Microsoft Flow
・ワークフロー
・Webhook
・リモート イベント レシーバーなど
これらの実装で権限を操作するシナリオでは、データ数増加につれて、すぐに影響範囲が拡大していきますので、本投稿を事前に確認ください。
なぜセキュリティ スコープは 5000 までを推奨としているのか。
詳細な権限が付与されたリスト アイテムにデータ アクセスする際には、まずは自身がアクセス権のあるセキュリティ スコープを列挙します。
その後、アクセス権のあるデータをクエリするデータとなります。
上記図、緑部分はアクセス権ありの箇所となり、その内容をビューに指定されたクエリに基づき取得します。
このことから、リスト ライブラリのセキュリティ スコープは全取得が前提となります。ビュー設定をいくら工夫したとしても、セキュリティ スコープ列挙はその前処理にあたるため回避できません。リスト ビューのしきい値で指定された根拠と同様、ロック オブジェクトによってメモリーを多く消費するクエリはデータベース全体の遅延を招く動作となり、避けるべきとなりますので、リストやライブラリごとにセキュリティ スコープの数は 5000 までを推奨しています。
運用回避策
以下に紹介する 4 つの運用回避策はあくまでも例としてのご紹介です。ご参考にしてください。
1. アクセス権に頼らない : ビューなど表示側で制御する。
セキュリティ スコープを限りなく 1 に近づけて、ユーザーに見せるデータ領域を指定する方法です。そのために、カスタム ページを介してリストにアクセスできるようにし、代わりにページにアクセス権を割り当てます。
1) サイトのページまたはページ ライブラリにページを作成します。
2) 各ページ (*.aspx ファイル) にアクセス権を付与し、ページ単位でアクセスできる人を限定します。
3) 各ページに該当リストの Web パーツを貼り付けます。列の値などを駆使し、データ区分に応じたフィルターします。
4) 最後に、リストを非表示にして、サイト コンテンツなどの導線からアクセスできないようにします。
以下の PnP コマンドレットによる処理実行が便利です。
Connect-PnPOnline <サイト URL>
Set-PnPList -Identity "<リスト タイトル>" -Hidden $true
5) ビュー単位で非表示にし、ビューのセレクターを使用して移動できないようにします。
Set-PnPView -List "<リスト タイトル>" -Identity "<ビュー タイトル>" -Values @{Hidden = $true }
デメリット :
・URL などを直接指定してデータ アクセスする場合はアクセスできてしまいます。
・非表示リストはクロールの対象から外れるため、検索はできません。
注意事項
この方法の延長線でサイトやページ構成をしていると、応用して以下のような方法を試したくなりますが、以下は避けてください。
・対象ユーザーで Web パーツ単位にアクセス許可すること。
・構造ナビゲーションで、発行ページを列挙させること。
2. ライブラリやフォルダー単位でアクセス権を管理する。
各アイテムやファイル単位でアクセス権を制御せず、ライブラリやフォルダー単位でアクセス権を分割します。
権限を変更する際には、API などを使用して、アイテムやファイルの格納先フォルダー (またはライブラリ) を移動する実装となります。
タイトル : File.Move(String, String) Method
アドレス : https://docs.microsoft.com/ja-jp/dotnet/api/system.io.file.move?view=netframework-4.7.2
タイトル : Files and folders REST API reference
参考箇所 : MoveTo メソッド
表示側について
リスト内でシームレスに表示する際には、"フォルダーなしですべてのアイテムを表示する" 方法や、検索機能を行う方法が考えられます。
3. リスト ライブラリをどんどん分割する。
アイテムごとに権限を付与する方法を貫き通す場合、どこかでリストやライブラリを分割する必要が生じます。
例えば、時系列による分割が最も一般的ですが、人やカテゴリーなど他の方法で分割する方法もあると思います。
時系列の場合、各ユーザーが投稿する平均の入力数を確認しておき、5000 を超えるおおよその時期よりも短いスパンで、どんどん区切っていきます。
例えば、半期、クオーター、月などで区切っていきます。
データ型を統一するため、あらかじめサイト コンテンツ タイプを作成しておき、リストやライブラリを作成する際には、そのコンテンツ タイプを割り当てる形で使用します。
表示側について
リストやライブラリを超えたデータアクセスが必要な際には検索系のソリューションを使います。
先に記載していたコンテンツ タイプの統一を実施していれば、検索ソリューションとの親和性も高まります。
4. 別のサービスにデータ格納し、画面上に表示する
現在は、マイクロサービスの時代です。単一のサービスのみで、ソリューションを作成しなければならないわけではありません。
別のデータ ストレージにデータ格納し、SharePoint Framework のクライアント Web パーツなどを利用してデータ表示するという方法も考えられます。
また、PowerApps と CDS でソリューションを作成する方法などもあります。
補足
アクセス許可を付与する際には、できる限り個人よりもグループを使用してください。
リストやライブラリ単位でセキュリティ スコープの数を少なくしても、大量の個別ユーザーに固有のアクセス権を付与していくと、その分だけ親オブジェクトに制限付きアクセス権が付与されていきます。
これにより、セキュリティ スコープ単位のロール割り当て数が増加すると、別の角度でパフォーマンス劣化の原因にもなります。
まとめ
SharePoint Online を導入するにあたり、全く新規の導入もあれば、他システムからのマイグレーションや、オンプレミス システムからのマイグレーションなど、様々な状況が存在すると思います。
タイトル : SharePoint Online の制限
恐縮な部分もございますが、システム設計にそのまま当て込むのではなく、SharePoint Online の制限事項を理解し、アーキテクチャに沿ったシステム設計についても十分ご一考の程お願いします。
- 編集済み Kengo MoriMicrosoft employee, Owner 2019年5月15日 6:02
