Microsoft Dataverse のセキュリティ概念

Dataverse の主要な機能の 1 つは、多くのビジネス使用シナリオに合わせることができる豊富なセキュリティ モデルです。 このセキュリティ モデルは、環境に 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 のレコードにアクセスできるようになります。

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

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

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

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

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

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

各ビジネス ユニットにセキュリティ グループを作成し、それぞれのビジネス ユニット セキュリティ ロール を各グループ チームに割り当てます。 Microsoft Entra

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

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

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

所属部署

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

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

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

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

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

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

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

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

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

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

最新の部署で所有権を記録する

最新の部署 では、ユーザーをあらゆる部署のレコードの所有者にすることができます。 ユーザーが必要とするのは、レコード テーブルに対する読み取り権限を持つ セキュリティ ロール (任意の部署) だけです。 ユーザーは、レコードが存在する各部署にセキュリティ ロールを割り当てる必要はありません。

もしプレビュー期間中に運用環境で 部署全体で所有権を記録する で有効化されていた場合、部署全体でこのレコードの所有権を有効にするには、次の手順を実行する必要があります。

1. 組織設定エディター をインストールする
2. 部署全体で所有権を再計算する 組織の設定を true に設定します。 この設定を true にすると、システムはロックされ、再計算に最大 5 分かかります。この機能により、ユーザーは各部署から個別のセキュリティロールを割り当てなくても、部署間でレコードを所有できるようになります。 これにより、レコードの所有者は、レコードを所有する部署以外の人物に自分のレコードを割り当てることができます。
3. AlwaysMoveRecordToOwnerBusinessUnit を false に設定します。 これにより、レコードの所有権が変更されたときに、レコードは元の所有部署に残ります。

すべての非運用環境では、AlwaysMoveRecordToOwnerBusinessUnit を false に設定して、この機能を使用します。

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

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

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

レコードの共有

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

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

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

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

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

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

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

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

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

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

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

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

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

関連項目

環境 セキュリティを構成する
セキュリティの役割と権限