Microsoft Dataverse のセキュリティ概念

[アーティクル]
07/23/2024

Dataverse の主要な機能の 1 つは、多くのビジネス使用シナリオに合わせることができる豊富なセキュリティモデルです。このセキュリティモデルは、環境に Dataverse データベースがある場合にのみ適用されます。管理者として、セキュリティモデル全体を自分で構築することはおそらくありませんが、ユーザーを管理し、ユーザーが適切に構成されていることを確認し、セキュリティアクセス関連の問題をトラブルシューティングするプロセスに関与することはよくあります。

チップ

次のビデオを確認してください: Microsoft Dataverse – デモに示されているセキュリティの概念。

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

Dataverse では、ロールベースのセキュリティを使用して、権限のコレクションをグループ化します。これらのセキュリティロールは、ユーザーに直接関連付けることができます。または Dataverse チームおよび部署に関連付けることもできます。その後、ユーザーをチームに関連付けることができるため、チームに関連付けられているすべてのユーザーがロールの恩恵を受けることができます。理解しておく必要がある Dataverse セキュリティの主な概念は、すべての特権付与が累積的であり、最大のアクセス権が優勢になるということです。幅広い組織レベルですべての取引先担当者レコードへの読み取りアクセス権を付与した場合、戻って 1 件のレコードを非表示にすることはできません。

部署

チップ

次のビデオを確認してください: 部署の最新化。

部署はセキュリティロールと連携して、ユーザーにとって効果的なセキュリティを決定します。部署は、ユーザーとユーザーがアクセスできるデータの管理に役立つセキュリティモデルの構成要素です。部署はセキュリティ境界を定義します。すべての Dataverse データベースには、単一のルート部署があります。

ユーザーとデータをさらにセグメント化するため、下位の部署を作成できます。環境に割り当てられたすべてのユーザーは、ビジネスユニットに属します。部署を使用して 1:1 の真の組織階層をモデル化することもできますが、多くの場合、セキュリティモデルのニーズを達成するために、定義されたセキュリティ境界に傾きます。

理解を深めるために、次の例を見てみましょう。 3 つの部署があります。 Woodgrove はルート部署で、常に最上位にあり、変更できません。他に2つの子ビジネスユニットAとBを作成しました。これらのビジネスユニットのユーザーには、異なるアクセスニーズがあります。ユーザーをこの環境に関連付けると、これらの 3 つの部署のいずれかにユーザーを設定できます。ユーザーが関連付けられている場所によって、そのユーザーが所有するレコードを所有するビジネスユニットが決まります。その関連付けを行うことで、ユーザーがその部署のすべてのレコードを表示できるようにセキュリティロールを調整できます。

階層データアクセス構造

顧客は、データとユーザーがツリー状の階層に区分された組織構造を使用できます。

ユーザーをこの環境に関連付けると、ユーザーをこれら 3 つの部署のいずれかに設定し、部署からユーザーにセキュリティロールを割り当てることができます。ユーザーが関連付けられている部署は、ユーザーがレコードを作成するときに、どの部署がレコードを所有するかを決定します。この関連付けにより、セキュリティロールをカスタマイズできるようになり、ユーザーはそのビジネスユニット内のレコードを表示できるようになります。

ユーザー A は部署 A に関連付けられ、部署 A からセキュリティロール Y を割り当てられます。これにより、ユーザー A は取引先担当者 #1 と取引先担当者 #2 のレコードにアクセスできます。部門BのユーザーBは部門Aの連絡先レコードにアクセスできませんが、連絡先 #3のレコードにはアクセスできます。

マトリックスデータアクセス構造の例

マトリックスデータアクセス構造 (最新の部署)

顧客は、データがツリー状の階層に区分された組織構造を使用でき、ユーザーは、ユーザーが割り当てられている部署に関係なく、どの部署のデータでも操作およびアクセスができます。

ユーザーをこの環境に関連付けると、これらの 3 つの部署のいずれかにユーザーを設定できます。ユーザーがデータにアクセスする必要がある部署ごとに、その部署からセキュリティロールがユーザーに割り当てられます。ユーザーがレコードを作成するときに、ユーザーはレコードを所有する部署を設定できます。

ユーザー A は、ルート部署を含む任意の部署に関連付けることができます。部署 A のセキュリティロール Y がユーザー A に割り当てられ、ユーザーは取引先担当者 #1 と取引先担当者 #2 のレコードにアクセスできるようになります。部署 B のセキュリティロール Y がユーザー A に割り当てられ、ユーザーは取引先担当者 #3 のレコードにアクセスできるようになります。

階層データアクセス構造の例

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

Note

この機能を有効にする前に、すべてのカスタマイズを公開して、すべての新しい非公開テーブルを機能に対して有効にする必要があります。この機能を有効にした後、この機能で動作しない未公開のテーブルがあることがわかった場合は、Microsoft Dynamics CRM 用 OrgDBOrgSettings ツールを使って RecomputeOwnershipAcrossBusinessUnits 設定を設定できます。 RecomputeOwnershipAcrossBusinessUnits を true に設定すると、所有部署フィールドを設定/更新できます。

Power Platform 管理センターに管理者 (Dynamics 365管理者または Microsoft Power Platform 管理者) としてログインします。
環境を選択し、この機能を有効にする環境を選択します。
設定>製品>機能を選択します。
部署全体のレコードの所有権 スイッチをオンにします。

この機能スイッチをオンにすると、ユーザーにセキュリティロールを割り当てるときに部署を選択できます。これにより、さまざまな部署からユーザーにセキュリティロールを割り当てることができます。ユーザーには、モデル駆動型アプリを実行するためのユーザー設定特権と共に、ユーザーが割り当てられている部署のセキュリティロールも必要です。 Basic ユーザーセキュリティロールを参照して、これらのユーザー設定特権を有効にする方法を確認することができます。

ユーザーがレコードテーブルに対する読み取り権限を持つセキュリティロールを持っている限り、レコードを所有するビジネスユニットでセキュリティロールを割り当てる必要なく、任意のビジネスユニットでユーザーをレコード所有者として割り当てることができます。最新の部署で所有権を記録するをご覧ください。

Note

この機能スイッチは、EnableOwnershipAcrossBusinessUnits 設定に格納することができ、Microsoft Dynamics CRM 用 OrgDBOrgSettings ツールを使用して設定することもできます。

部署を Microsoft Entra セキュリティロールに関連付ける

Microsoft Entra セキュリティグループを使用して、ユーザー管理とロールの割り当てを合理化するために部署をマップすることができます。

各部署に Microsoft Entra セキュリティグループを作成し、各部署のセキュリティロールを各グループチームに割り当てます。

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

各部署に Microsoft Entra セキュリティグループを作成します。各 Microsoft Entra セキュリティグループに Dataverse グループチームを作成します。部署の各セキュリティロールを Dataverse グループチームに割り当てます。上の図のユーザーは、ユーザーが環境にアクセスするとルート部署に作成されます。ユーザーと Dataverse チームをルート部署に配置すると問題ありません。セキュリティロールが割り当てられている部署のデータにのみアクセスできます。

ユーザーを各 Microsoft Entra セキュリティグループに追加して、部署へのアクセスを許可します。ユーザーはすぐにアプリを実行して、そのリソース/データにアクセスできます。

マトリックスデータアクセスでは、ユーザーは複数の部署のデータを使用したりアクセスでき、そこでユーザーを、それらの部署にマップされる Microsoft Entra セキュリティグループに追加します。

所属部署

各レコードには 所有ビジネスユニット 列があり、どのビジネスユニットがレコードを所有しているかを決定します。この列は、レコードの作成時にデフォルトでユーザーのビジネスユニットに設定され、機能スイッチがオンになっている場合を除いて変更できません。

注意

レコードを所有する部署を変更する場合は、カスケード効果に関する情報 SDK for .NET を使用してカスケード動作を構成する参照してください。

機能スイッチがオンのときに、ユーザーが [所属部署] 列を設定できるようにするかどうかを管理できます。 [所属部署] 列を設定するには、ユーザーのセキュリティロールに部署テーブルの 追加先 権限をローカルレベルの許可で付与する必要があります。

ユーザーがこの列を設定できるようにするには、次の方法で列を有効にします。

フォーム - 本文とヘッダーの両方。
表示する。
列マッピング。 AutoMapEntity を使用している場合は、列マッピングで列を指定できます。

Note

環境間でデータを同期するジョブ/プロセスがある場合、所有部署 はスキーマの一部として含まれ、ターゲット環境に同じ 所有部署 の値がない場合、ジョブは 外部キー の制約違反で失敗します。

所有部署 列をソーススキーマから削除するか、ソースの 所有部署 列の値をターゲットの任意の部署に更新します。

環境から PowerBI などの外部リソースにデータをコピーするジョブ/プロセスがある場合は、ソースから 所有部署 列を選択するか、削除する必要があります。リソースが受信できる場合は選択し、そうでない場合は選択を解除します。

テーブル / レコード所有権

Dataverse は、2 つの種類のレコード所有権をサポートしています。これらは、組織による所有、およびユーザーまたはチームによる所有です。これは、テーブルの作成時に行われる選択であり、変更はできません。セキュリティ上の目的で、組織が所有しているレコードのアクセスレベルの選択肢は、ユーザーが操作を実行できるか、実行できないかのどちらかのみになります。ユーザーおよびチームが所有するレコードの場合、ほとんどの特権のアクセスレベルの選択肢は、階層化された組織、部署、部署、および下位の部署、またはユーザー自身のレコードのみです。つまり、取引先担当者の読み取り特権について、ユーザー所有として設定すると、ユーザーは自分のレコードのみを表示できます。

別の例を挙げると、ユーザー A が事業部 A に関連付けられていて、取引先担当者の部署レベルの読み取りアクセス権を与えたとします。取引先担当者 #1と #2 は表示されますが、取引先担当者 #3 は表示されません。

セキュリティロール特権を構成または編集する際、各オプションのアクセスレベルを設定します。以下は、セキュリティロール特権エディターの例です。

セキュリティロール特権。

上記では、各テーブルの作成、読み取り、書き込み、削除、追加、追加先、割り当て、および共有の標準の特権タイプを確認できます。これらはそれぞれ個別に編集できます。それぞれのビジュアル表示は、付与したアクセスのレベルに関して、以下のキーと一致します。

セキュリティロール特権のキー。

上記の例では、取引先担当者への組織レベルのアクセス権を付与しました。つまり事業部 A のユーザーは、取引先担当者の所有者が誰であっても、表示および更新ができます。実際、最も一般的な管理ミスの 1 つは、アクセス許可への不満とアクセス権の過剰付与です。よくできたセキュリティモデルは、穴がたくさん空いたスイスチーズのように見えてくることでしょう。

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

チームは、もう 1 つの重要なセキュリティの構成要素です。チームは部署によって所有されます。各事業単位には、事業単位の作成時に自動的に作成される 1 つの既定のチームがあります。既定のチームメンバーは Dataverse によって管理され、その事業単位に関連付けられているすべてのユーザーが常に含まれます。既定のチームに手動でメンバーを追加したり、削除することはできません。新しいユーザーが部署に関連付けられたり、関連付けが解除されると、システムによって動的に調整されます。チームには、所有チームとアクセスチームの 2 種類があります。

所有チームはレコードを所有できます。これにより、チームメンバーはそのレコードに直接アクセスできます。ユーザーは、複数チームのメンバーに設定できます。これは、ユーザーに対して広範にアクセス許可を付与する強力な方法です。個々のユーザーレベルでアクセスを細かく管理する必要はありません。
アクセスチームについては、レコード共有の一環として次のセクションで説明します。

個々の行は、他のユーザーと 1 対 1 で共有できます。これは、レコードの所有権や部署アクセスモデルのメンバーに該当しない例外を処理する強力な方法です。例外的と説明したのは、アクセスの制御を効率良く行うことができないためです。アクセスの制御方法の一貫性を保てないため、共有による問題解決が難しくなります。共有は、ユーザーとチームレベルの両方で実行できます。チームレベルで共有を使用する方が効率的です。共有のより高度な概念は、適用されるアクセスチームテンプレート (権限のテンプレート) に基づいて、チームの自動作成およびチームとのレコードアクセスの共有を提供するアクセスチームでの使用です。アクセスチームは、テンプレートを使用せず、手動でメンバーを追加または削除するだけで使用することもできます。アクセスチームは、チームがレコードを所有したり、チームにセキュリティロールが割り当てられたりすることを許可しないため、効率が向上します。レコードがチームに共有されており、ユーザーはメンバーであるため、ユーザーはアクセスできます。

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

レコードへのアクセスを決定する要因は何でしょうか。これは単純な質問のように思えますが、特定のユーザーの場合、それはすべてのセキュリティロール、関連付けられているビジネスユニット、メンバーであるチーム、および共有されているレコードの組み合わせです。覚えておくべき大切なことは、Dataverse データベース環境の範囲内のすべての概念において、すべてのアクセスは累積的であるということです。これらの資格は単一のデータベース内でのみ付与され、各 Dataverse データベースで個別に追跡されます。これには、Dataverse にアクセスするための適切なライセンスが必要です。

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

場合によっては、レコードレベルのアクセス制御では不十分なことがあります。 Dataverse には、列レベルのセキュリティ機能があるため、列レベルでセキュリティを細かく制御できます。列レベルのセキュリティは、すべてのカスタム列とほとんどのシステム列で有効にできます。個人を特定できる情報 (PII) を含むほとんどのシステム列は、個別に保護できます。各列のメタデータは、それがシステム列で利用可能なオプションかどうかを定義します。

列レベルのセキュリティは、列ごとに有効になります。その後、列セキュリティプロファイルが作成され、アクセスが管理されます。このプロファイルには、列レベルのセキュリティが有効になっているすべての列と、その特定のプロファイルによって許可されたアクセスが含まれます。各列は、作成、更新、読み取りアクセスのプロファイル内で制御できます。次に、列セキュリティプロファイルはユーザーまたはチームに関連付けられ、それらの特権はユーザーが既にアクセス権を持っているレコードに付与されます。列レベルセキュリティは、レコードレベルセキュリティとは何の関係もないことに注目することが重要です。列セキュリティプロファイルが列にアクセス権を許可するには、ユーザーがレコードへのアクセス権をすでに持っている必要があります。列レベルのセキュリティは、必要に応じて使用する必要があります。過度に使用すると、悪影響を及ぼすオーバーヘッドが追加されるため、必要以上に使用することは避けてください。

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

セキュリティロールと列セキュリティプロファイルは、Dataverse ソリューションを使用してパッケージ化し、1 つの環境から次の環境に移動できます。各環境で部署とチームを作成および管理し、必要なセキュリティコンポーネントへユーザーを割り当てる必要があります。

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

環境でロール、チーム、および部署が作成されたら、ユーザーにセキュリティコンフィギュレーションを割り当てます。まず、ユーザーを作成するときに、そのユーザーを部署に関連付けます。既定では、これは組織のルート部署です。ユーザーは、その部署の既定チームにも追加されます。

さらに、ユーザーに必要なすべてのセキュリティロールを割り当てます。そして、ユーザーを任意のチームのメンバーとして追加します。セキュリティロールはチームにも設定される場合があるため、ユーザーの有効な権限は、ユーザーに直接割り当てたセキュリティロールと、そのユーザーが所属するチームのセキュリティロールを組み合わせたものになることを覚えておいてください。セキュリティは常に付加的なものであり、いずれの権利についても制限を最小限にしたアクセス許可を提供します。以下は、環境セキュリティの設定についての優れたチュートリアルです。

列レベルセキュリティを使用したことがある場合は、ユーザーまたはユーザーのチームを、作成した列セキュリティプロファイルの 1 つに関連付ける必要があります。

セキュリティは複雑な問題であり、アプリケーションの作成者とユーザーの権限を管理するチームの共同作業によって実現するのが最適です。環境に変更をデプロイする前に、すべての主な変更を十分に調整しておく必要があります。

次の方法で共有

Microsoft Dataverse のセキュリティ概念

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