Microsoft Dataverseでの所有権ベースのセキュリティ

Dataverse は、多くのビジネス シナリオに柔軟なセキュリティ モデルを提供します。 このモデルは、Dataverse データベースを持つ環境にのみ適用されます。 管理者は、ユーザーを管理し、セキュリティ構成を確認し、アクセスの問題のトラブルシューティングを行います。

ロールベースのセキュリティ

Dataverse は、セキュリティ ロールを使用して特権をグループ化します。 セキュリティ ロールをユーザーまたは Dataverse チームに直接割り当てます。 チーム メンバーは、チームに割り当てられた特権を受け取ります。

セキュリティ特権は累積的です。 ユーザーは、すべてのロールとチーム メンバーシップによって付与された最も広範なアクセス権を受け取ります。 たとえば、あるロールがすべての連絡先レコードに対する組織レベルの読み取りアクセスを許可する場合、別のロールは特定の連絡先をユーザーに隠すことはできません。

事業部門

Dataverse の事業単位を理解するには、次のビデオをご覧ください。

部署はセキュリティ ロールと連携して、ユーザーのアクセス権を決定します。 ユーザーとデータの管理に役立つセキュリティ境界を定義します。 すべての Dataverse データベースには、1 つのルート ビジネス ユニットがあります。

子ビジネス ユニットを作成 して、ユーザーとデータをより小さなセキュリティ境界に分割します。 環境内のすべてのユーザーは、1 つの部署に属します。 部署の構造は組織の階層と一致させることができますが、そうする必要はありません。

次の例では、3 つの部署を使用します。 Woodgrove はルート ビジネス ユニットであり、階層の最上位に残ります。 部門 A と B は子ビジネス ユニットです。 各部門のユーザーは、異なるアクセスニーズを持っています。

階層データ アクセス構造

階層構造を使用して、ツリーに似た階層内のユーザーとデータを分離します。

各ユーザーを 1 つの部署に割り当て、その部署のセキュリティ ロールをユーザーに割り当てます。 既定では、ユーザーの部署は、ユーザーが作成したレコードを所有します。 セキュリティ ロールは、ユーザーがその部署でアクセスできるレコードを決定します。

この例では、ユーザー A は部門 A に属し、部門 A のセキュリティ ロール Y を持っています。ユーザー A は、連絡先 #1 と連絡先 #2 にアクセスできます。 ユーザー B は部門 B に属しているため、ユーザー B は部門 A の連絡先にアクセスできませんが、連絡先 #3 にアクセスできます。

ユーザー A が部門 A の連絡先にアクセスし、ユーザー B が部門 B の連絡先 #3 にアクセスする階層型ビジネス ユニットの図。

マトリックス データ アクセス構造 (最新化されたビジネス ユニット)

マトリックス構造を使用してツリーに似た階層のデータを整理すると同時に、ユーザーは所属する部署に関係なく、複数の部署のデータにアクセスできます。

アクセスする必要があるデータを持つ各部署のセキュリティ ロールをユーザーに割り当てます。 ユーザーは、レコードを作成するときに、レコードを所有する部署を選択できます。

この例では、ユーザー A はルート部署を含む任意の部署に属できます。 部門 A のセキュリティ ロール Y は、ユーザー A に連絡先 #1 と連絡先 2 へのアクセス権を付与します。 部門 B のセキュリティ ロール Y は、ユーザー A に連絡先 #3 へのアクセス権を付与します。

各部署から割り当てられた役割 Y を使用して、部門 A と部門 B の連絡先にアクセスするユーザー A を示す図。

マトリックス データ アクセス構造を有効にする

注

この機能を有効にする前に、すべてのカスタマイズを公開して、機能が新しいテーブルに適用されるようにします。 この機能を有効にした後に未発行のテーブルが機能しない場合は、CRM Microsoft Dynamics OrgDBOrgSettings ツールを使用して RecomputeOwnershipAcrossBusinessUnits をtrueに設定します。 この設定で、所有ビジネス ユニット列を設定および更新できます。

  1. Power Platform 管理センターにDynamics 365管理者またはMicrosoft Power Platform管理者としてサインインします。
  2. ナビゲーション ウィンドウで、管理 を選択します。
  3. [ 管理 ] ウィンドウで、[ 環境] を選択し、環境を選択します。
  4. 設定>製品>機能を選択します。
  5. [複数の部署の所有権を記録する] をオンにします。
  6. 保存を選択します。

機能を有効にした後、 ユーザーにセキュリティ ロールを割り当てるときに部署を選択します。 このオプションを使用すると、さまざまな部署のロールをユーザーに割り当てることができます。 モデル駆動型アプリを実行するには、ユーザーには、必要な ユーザー設定特権を含む独自の部署のロールも必要です。 基本ユーザー ロールには、有効にするユーザー設定特権が表示されます。

セキュリティ ロールの 1 つがレコードのテーブルに対する 読み取り 権限を付与している場合は、ユーザーを任意の部署のレコード所有者にすることができます。 ユーザーは、レコードの所有部署のセキュリティ ロールを必要としません。 詳細については、「 最新化されたビジネス ユニットの所有権を記録する」を参照してください。

注

EnableOwnershipAcrossBusinessUnits 設定には、この機能の状態が格納されます。 また、Microsoft Dynamics CRM の OrgDBOrgSettings ツールを使用して設定を変更することもできます。

事業単位を Microsoft Entra セキュリティ グループに関連付ける

ユーザー管理とロールの割り当てを簡略化するために、ビジネス ユニットをMicrosoft Entraセキュリティ グループにマップします。

各部署のMicrosoft Entraセキュリティ グループを作成します。

各部署について:

  1. Microsoft Entra セキュリティ グループを作成します。
  2. Dataverse グループ チームをセキュリティ グループ用に作成します。
  3. ビジネス ユニットのセキュリティ ロールを Dataverse グループ チームに割り当てます。
  4. Microsoft Entra セキュリティ グループにユーザーを追加します。

ユーザーが最初に環境にアクセスすると、Dataverse によってルート ビジネス ユニットにユーザーが作成されます。 ユーザー チームと Dataverse グループ チームは、ルート ビジネス ユニットに残ることができます。 割り当てられたセキュリティ ロールは、対応する部署のデータへのアクセスを許可します。

マトリックス データ アクセスの場合は、アクセスする必要がある各部署のMicrosoft Entra セキュリティ グループにユーザーを追加します。

所属部署

各レコードには、レコード を所有する部署 を識別する所有部署列があります。 ユーザーがレコードを作成すると、列は既定でユーザーの部署に設定されます。 この値は、 事業単位間で所有権を記録 する場合にのみ変更できます。

注

所有する部署を変更すると、連鎖的な変更が発生する可能性があります。 詳細については、「.NETに SDK を使用してカスケード動作を構成する」を参照してください。

ユーザーが [所有部署 ] 列を設定できるようにするには、ユーザーのセキュリティ ロールに、部署テーブルのローカル レベルの 追加権限を 付与します。

列を次の値に追加します。

注

データ同期ジョブのスキーマに 所有部署 が含まれている場合、ターゲット環境に同じ値が含まれていない場合、ジョブは外部キー制約違反で失敗します。 ソース スキーマから列を削除するか、そのソース値をターゲット環境に存在する部署に変更します。

Power BIなどの外部リソースにデータをコピーする場合は、コピー先が列をサポートしている場合にのみ、所有部署を含めます。

テーブルとレコードの所有権

Dataverse では、次の 2 種類のレコード所有権がサポートされています。

  • 所有する組織: 権限はすべてのレコードに適用されるか、適用されません。
  • ユーザーまたはチーム所有: ほとんどの権限では、ユーザー、事業部門、親子事業部門、および組織のアクセスレベルがサポートされます。

テーブルを作成するときに所有権の種類を選択します。後で変更することはできません。 たとえば、連絡先テーブルに対するユーザー レベルの 読み取り アクセス権を使用すると、ユーザーは自分が所有する連絡先レコードのみを読み取ることができるとします。

ユーザー A が部門 A に属し、部署レベルの連絡先テーブルへの 読み取り アクセス権を持っている場合、ユーザー A は連絡先 #1 と連絡先 #2 を読み取ることができますが、連絡先 #3 は読み取りません。

セキュリティ ロールを構成するときは、各特権のアクセス レベルを選択します。

Contact テーブルと [標準の特権] 列が強調表示されている、セキュリティ ロールの特権とアクセス レベルのスクリーンショット。

標準テーブル権限を個別に構成します: 作成、読み取り、書き込み、削除、追加、追加先、割り当て、共有。 特権アイコンには、付与されたアクセス レベルが表示されます。

フィルター処理されたテーブル レコードの所有権 (プレビュー)

プレビュー機能は運用環境での使用を想定しておらず、機能が制限される可能性があります。 これらの機能は正式リリース前に利用できるため、お客様は早期にアクセスしてフィードバックを提供できます。

フィルター処理されたレコードの所有権により、管理者は列値フィルターを使用して Dataverse レコードへのアクセスを制御できます。 たとえば、 City 列が Redmond と等しいレコードにのみアクセス権を付与します。 ユーザーは、セキュリティ ロールのフィルターに一致するレコードのみを作成、読み取り、更新、および削除できます。

従来の Dataverse テーブルとは異なり、フィルター処理されたレコード所有権を持つテーブルは、レコードの所有権、共有、または割り当てをサポートしていません。 フィルターベースの権限は、レコード アクセスを制御し、テーブル、列、またはその他のモデル オブジェクトを制限することなく、詳細な行レベルのアクセスを提供します。

注

フィルター選択されたレコードの所有権を使用して、フィルター条件を満たすレコードに行レベルのアクセス権を付与します。 フィルターベースの特権を、フィルター処理されたレコード所有権テーブルと、既存のユーザー所有または組織所有のテーブルに適用します。 既存のテーブルの場合、このアプローチでは基になる所有権モデルが保持されます。

最新化されたビジネス ユニットの所有権を記録する

最新化されたビジネス ユニットでは、ユーザーは任意の部署のレコードを所有できます。 ユーザーには、レコードのテーブルに対する 読み取り 権限を付与する任意の部署のセキュリティ ロールが必要です。 ユーザーは、所有するレコードを含むすべての部署のロールを必要としません。

プレビュー期間中に運用環境の 部署間で所有権を記録 するを有効にした場合:

  1. 組織設定エディターをインストールします。
  2. RecomputeOwnershipAcrossBusinessUnits を true に設定します。 再計算中にシステムがロックされます。最大で 5 分かかる場合があります。 再計算後、ユーザーは、各部署とは別のセキュリティ ロールを持たない複数の部署のレコードを所有できます。 レコード所有者は、レコードの所有部署外のユーザーにレコードを割り当てることもできます。
  3. AlwaysMoveRecordToOwnerBusinessUnit をfalseに設定します。 その後、所有権が変更されると、レコードは元の所有部署に残ります。

非運用環境の場合は、 AlwaysMoveRecordToOwnerBusinessUnit を false に設定します。

注

事業単位間で所有権を記録 をオフにするか、RecomputeOwnershipAcrossBusinessUnits を false に設定すると、所有事業単位 列を設定または更新できません。 また、Dataverse は、レコード所有者の部署と一致するように、影響を受ける各レコードの所有部署も変更します。

チーム (グループ チームを含む)

各チームは、1 つの部署に属します。 Dataverse は、すべての部署の既定のチームを自動的に作成し、そのメンバーシップを管理します。 既定のチームには、ビジネス ユニット内のすべてのユーザーが常に含まれます。 メンバーを手動で追加または削除することはできません。 Dataverse では、ユーザーを 部署に関連付けるか関連付けを解除すると、メンバーシップが更新されます。

Dataverse には、次の 2 種類のチームが用意されています。

  • 所有者チーム はレコードを所有できます。 すべてのチーム メンバーは、チームのレコードに直接アクセスできます。 ユーザーは複数の所有者チームに属することができます。
  • アクセス チーム は共有レコードへのアクセスを提供しますが、レコードを所有していないか、セキュリティ ロールを持っていません。

レコードの共有

個々のレコードをユーザーまたはチームと共有して、所有権とビジネス ユニット モデルでカバーされていない例外を処理します。 パフォーマンスが低く、ロールベースのアクセスよりもトラブルシューティングが困難な場合があるため、例外に対してのみ共有を使用します。 チームとの共有は、各ユーザーと個別に共有するよりも効率的です。

アクセス チーム テンプレートを使用して、アクセス チームを自動的に作成し、レコードのアクセス許可を定義します。 テンプレートを使用せずにアクセス チームを作成し、メンバーを手動で管理することもできます。 アクセス チームはレコードを所有せず、セキュリティ ロールを持つことができません。 チーム メンバーは、レコードがチームと共有されるため、アクセス権を受け取ります。

Dataverse のレコードレベルのセキュリティ

ユーザーのレコード アクセスは、すべてのセキュリティ ロール、部署メンバーシップ、チーム メンバーシップ、共有レコードを組み合わせたものです。 アクセスは、Dataverse データベース内で累積されます。 Dataverse はデータベースごとに個別にアクセスを追跡し、ユーザーは適切な Dataverse ライセンスを持っている必要があります。

Dataverse での列レベルのセキュリティ

レコード レベルのセキュリティで十分な制御が提供されない場合は、列レベルのセキュリティを使用します。 すべてのカスタム列とほとんどのシステム列に対して有効にします。 個人を特定できる情報 (PII) を含むほとんどのシステム列では、列レベルのセキュリティがサポートされています。 システム列のメタデータは、セキュリティで保護できるかどうかを示します。

列ごとに列レベルのセキュリティを個別に有効にします。 次に、セキュリティで保護された列への作成、更新、読み取りアクセスを許可する列セキュリティ プロファイルを作成します。 プロファイルをユーザーまたはチームに割り当てます。

列レベルのセキュリティでは、レコードへのアクセスは許可されません。 ユーザーは、列セキュリティ プロファイルがセキュリティで保護された列へのアクセスを許可する前に、レコード アクセス権を既に持っている必要があります。 列レベルのセキュリティは、過剰な使用によってパフォーマンスが低下する可能性があるため、必要な場合にのみ使用してください。

複数の環境にまたがるセキュリティ管理

Dataverse ソリューションを使用して、セキュリティ ロールと列セキュリティ プロファイルを環境間で移動します。 各環境でビジネス ユニットとチームを個別に作成および管理します。 また、各環境の適切なセキュリティ コンポーネントにユーザーを割り当てる必要もあります。

ユーザー セキュリティの構成

ロール、チーム、および部署を作成したら、各ユーザーのアクセスを構成します。

  1. ユーザーを部署に関連付けます。 Dataverse では、既定でルート ビジネス ユニットが使用され、そのビジネス ユニットの既定のチームにユーザーが追加されます。
  2. ユーザーが必要とするセキュリティ ロールを割り当てます。
  3. 適切なチームにユーザーを追加します。
  4. 列レベルのセキュリティを使用する場合は、列セキュリティ プロファイルをユーザーまたはチームのいずれかに割り当てます。

ユーザーの有効なアクセスは、直接割り当てられたセキュリティ ロールと、チームによって割り当てられたロールを組み合わせたものになります。 Dataverse は常に、これらのロールから最も広範なアクセス許可を付与します。 詳細なチュートリアルについては、「 環境セキュリティの構成」を参照してください。

変更をデプロイする前に、アプリ作成者とユーザーのアクセス許可を管理する管理者と主要なセキュリティ変更を調整します。

関連項目