Dataverse へのアクセス
データは常に貴重な資産と見なす必要があります。 したがって、セキュリティ設計では、その貴重な資産への適切な使用とアクセスを徹底するセキュリティ モデルを作成することが重要となります。 Microsoft Dataverse は、Microsoft Power Platform のデータを格納し、アプリのサービスを提供します。 Microsoft Power Platform には Dataverse 環境へのアクセスを制御する階層的セキュリティが設定されていますが、ユーザーが環境へのアクセスを取得すると、ソリューション アーキテクトはデータベース内のアクセスを制御する必要があります。 Dataverse の 1 つの主要機能は、多種多様なシビジネス使用シナリオに合わせて調整できる豊富なセキュリティ モデルです。
認可
認可とは、リソースに対するアクセス権 (権限) を指定する関数です。 セキュリティ設計には、データおよび機能にアクセスするための認可が実装されます。 誰にアクセスを許可するかと、どのデータやサービスへのアクセスを許可するかを決定することは、どのようなソリューションの設計でも不可欠な要素です。
セキュリティ設計の不備は、システム設計の不備につながり、これらの要素は広範囲に影響を与え、修正にはコストがかかります。
- 管理の煩わしさ - 個別のアクセスの管理は困難です。
- パフォーマンス - たとえば、共有時には PrincipalAccessObject (POA) テーブルが増加する場合などです。
- 使いにくさ - アクセス権付与の手順が面倒になります。
- 可視性の欠如 - レコードを見るだけでは誰がアクセス権を持っているかわかりません。
ソリューションごとに要件は異なりますが、一般的な機能やパターンを特定して流用することはできます。
共通パターン
多くのビジネス アプリ内の一般的な使用パターンは次のとおりです。
- 積極的な関与 - 顧客/データに対する定期的、大規模な直接的関与。 顧客/データおよび現在の関連活動に関する既存の知識、および関係者との直接的関係に基づいた個人的な活動による情報提供。
- 二次的関与 - 活動に関する有効な情報を維持するが、データや顧客に直接に参加したり処置 (積極的に関与しているスタッフが欠勤の場合にカバーするなど) を行うことはない、情報に基づいた関与。 積極的に関与している人々にアドバイスやサポートを提供する、特定のデータや顧客に関する専門的な知識を提供するなど、顧客と個人的関係がある他の人をサポートする。
- トランザクションの相互作用 - 顧客の住所を更新する要求を受け取って処理するなど、特定の活動指向の関与。 コンタクト センター内など、個人的または進行中のエンゲージメントはない。
- マネジメントによる監視 - ビジネスまたは地理的領域にわたる経営者またはガバナンスの責任。 特定の関与ではなく、他者の関与を見る、および指示する。
- レポート - 集計ビジネス レポート。 データは、顧客/取引へ直接アクセスを提供するのではなく、匿名性を維持するために整理される。
- コンプライアンス - ビジネス領域のすべてのレコードに対する読み取り専用アクセスを監視する。
セキュリティを設計する際、ソリューション アーキテクトはユーザーの仕事のやり方を理解する必要があります。 つまり、自分ひとりで作業しているのか、静的チームの一部として作業しているのか、または特定のルールに基づいて変更される動的なチームで作業しているのかを判断する必要があります。 これらの要素はセキュリティ設計に影響します。 これらの要素を判断したら、ソリューション アーキテクトは、他のスタッフがどのようにサポートを提供しているかを理解する必要があります。 たとえば、ユーザーにサポート スタッフが割り当てられているかどうかや、そのサポート スタッフが他のユーザーと共有されているかどうかを確認する必要があります。 また、サポート スタッフがいない場合はどうなるか、夜間や週末はどうなるか、監視はどのように処理されるのかを確認する必要があります。
設計原則
セキュリティを設計するとき、ソリューションは次のような特定の原則に従う必要があります。
- 割り当てられる役割に、制限付きアクセスが必要とは限らない。
- 例外は例外として処理し、頻度の高いアクセス パターンを重視する。
- 広範なデータ セットに対するアクセス権を付与した場合、その中に含まれる特定のレコードへのアクセス権のみを取り消すことはできない。
- 事業単位は組織構造との一致度でなく、管理性と包含性も考慮して使用する。
- 要件をクリアできる最もシンプルでパフォーマンスに優れた設計を使用する。
メモ
必要なセキュリティ構造と組織構造が一致する場合もありますが、これはまれです。 セキュリティを設計する場合、既定で組織構造のみを使用しないでください。
セキュリティ機能
Dataverse は、データにアクセスするさまざまなセキュリティ機能を提供しています。
- テーブル所有権
- ユーザー
- チーム
- 事業単位
- セキュリティ ロール
- 共有
- Microsoft Entra ID セキュリティ グループ
- 列レベルのセキュリティ
- 階層セキュリティ
- 監査
ソリューション アーキテクトはこれらの各機能、そしてどのように組み合わせてソリューションのセキュリティ モデルを作成するかを理解する必要があります。 このユニットでこれらのセキュリティ機能の詳細は説明されませんが、ソリューションのセキュリティ モデルを作成するためにどのように組み合わせて使用できるのかを説明しています。
テーブル所有権
Dataverse のテーブルは、ユーザー/チーム所有または組織所有のいずれかです。 ユーザー/チーム所有のテーブルには所有者フィールドがあり、テーブルの各行に所有者を割り当てることができます。 行の所有者は、他のセキュリティ機能と併用して誰が行にアクセスできるかを決定できるため、行へのアクセス設定が細かく、水平にパーティション分割できます。 または、組織所有のテーブルでは個々の行へのアクセスを制限することはできず、ユーザーはすべてのレコードにアクセスできるか、一切できないかのどちらかです。
メモ
テーブルの作成後に所有権の種類を変更することはできません。 はっきりわからない場合は、テーブルの作成時にユーザー/チームの所有権の種類を指定してください。
チーム
チームとは、ユーザーがデータにアクセスできるユーザーのコレクションです。 チームは、個々のユーザー レベルで細かいアクセス管理を行わず、広範にユーザーにアクセス許可を付与する強力な方法です。 ユーザーは、複数チームのメンバーに設定できます。
チームには次の 3 種類があります。
- 所有者 - これらのチームは行を所有でき、どのチーム メンバーもその行に直接アクセスできます。
- アクセス - ユーザーがフォーム内の別のメンバーと行を簡単に共有する方法です。
- Microsoft Entra ID グループ - 所有者チームと類似していますが、チームのメンバーシップは Microsoft Entra ID で制御されます。
セキュリティ ロール
セキュリティ ロールは、Dataverse のデータ セキュリティの基盤です。 ユーザーに個別の権限を付与せず、セキュリティ ロールを作成します。 Dataverse では、ロール ベースのセキュリティを使用して、権限のコレクションをグループ化します。
セキュリティ ロールは、ユーザーおよびチームに割り当てることができます。 チームとユーザーには、集約された権限を提供するセキュリティ ロールを割り当てることができます。
重要
すべての権限付与は、最大のアクセスの量が優先するように累積されます。 すべての連絡先レコードに広範な組織レベルの読み取りアクセス許可を付与する場合、1 つのレコードに戻って非表示にすることはできません。
事業単位
事業単位はユーザーとチームで構成され、セキュリティ境界として機能します。 事業単位は、テーブル内のデータのサブセット (データの水平方向のパーティション分割) へのアクセスを制御する主要な方法です。 事業単位を使用すると、ユーザーとそのデータを区分できます。
すべての Dataverse データベースには、単一ルート事業単位があります。 厳格な階層内でユーザーのグループを表す下位の事業単位を作成できます。
メモ
事業単位には、その事業単位の全ユーザーを含むチームが既定で割り当てられます。 既定のチームに手動で追加や削除はできないため、ソリューションが進化するに伴い、一部のシナリオで阻害要因となる可能性があります。
重要
これは、Dataverse のセキュリティ モデルの土台として使用されるセキュリティ ロールと事業単位の組み合わせです。
事業単位は、大量のユーザーを効率的に管理し、アクセスを記録するための効率的な方法です。 事業単位はアプリケーションのユーザーには表示されず、管理者のみに表示されます。 組織の組織図をミラーリングするだけではなく、セキュリティ要件を満たす事業単位階層を設計する必要もあります。 このアプローチは、Sales および Marketing の事業単位の親となる事業単位を作成して、一部のユーザーがこれらの単位にアクセスできるようにしながら、Operation の事業単位へのアクセスを防ぐなど、セキュリティ要件を満たすために事業単位を作成することもあることを意味します。
行の共有
個々の行をユーザーおよびチームと共有できます。 この機能により、ユーザーは、事業単位が生成するセキュリティ モデルによって制限されているレコードにアクセスできます。 共有を使用すると、厳格な事業単位階層の外部にある行にアクセスできます。
セキュリティ ロールとチーム
セキュリティ ロールは、チームに関連付けることができます。 ユーザーはチームに関連付けられるため、チームに関連付けられているすべてのユーザーはこのロールから利点を享受できます。 ユーザーはチームが所有する行へのアクセスを持つため、他のセキュリティ機能によっては、チーム内の他のユーザーが所有する行へアクセスできる可能性があります。
セキュリティ ロールがチームとどのように連携するかを制御するオプションは次のとおりです。
- 既定 - チーム権限のみ
- 直接ユーザー (ベーシック) アクセス レベルとチーム権限
直接ユーザー オプションを使用すると、権限がユーザーに直接割り当てたように扱われます。 このオプションを使用することで、ユーザーにセキュリティ ロールを割り当てず、チームとチームに割り当てられているセキュリティ ロールを代わりに使用することができます。
メモ
所有者チームは事業単位に所属します。 1 人のユーザーは一度に 1 つの事業単位にしか所属できませんが、別の事業単位のチームに追加することはできます。 この機能により、ユーザーが階層内にない事業単位のデータにアクセスできます。
列レベルのセキュリティ
セキュリティ ロールによって提供される権限は、行レベルで動作します。 行に更新権限を持つユーザーは、その行のすべての列を更新できます。 個人を特定可能な情報を含む列など、行レベルのアクセス制御が適切ではない場合があります。 Dataverse には、列レベルのセキュリティ機能があるため、列レベルでセキュリティを細かく制御できます。
列レベルのセキュリティは、セキュリティ ロールに対して個別に機能します。 列のセキュリティ プロファイルは、列の読み取り/書き込み権限を定義し、ユーザーとチームに割り当てられます。
メモ
ユーザーにセキュリティ保護された列を読み取る権限がない場合、フォームの列は表示されますが、内容 (データの値) は見ることができません。 コードを使用してセキュリティ保護されたフィールドにアクセスする際、ユーザーに読み取り権限がなければ、値は NULL になります。
階層セキュリティ
事業単位の使用に関する問題の 1 つは、その厳格な階層です。 データへのアクセスは、事業単位の階層にのみ従うことができます。 事業単位の図では、Sales のユーザーに北、中央、および南の事業単位へのアクセス許可を付与できます。 逆に、Operations 事業単位のユーザーはその組織の全データに対するアクセス権限を付与されない限り Sales に属するデータにはアクセスできません。
階層セキュリティでは、職位が上のユーザーは部下の全データの読み取りと書き込みができます。 さらに、階層がさらに下のユーザーのデータを読み取ることができます。
階層セキュリティは、マネジメントによる監視を必要とするユーザーが事業単位階層の同じ部分にいないシナリオのために設計された代替セキュリティ モデルです。 階層セキュリティは、マネージャーが直属の部下と異なる国/地域や部署にいる場合に役立ちます。
階層セキュリティには次の 2 つのオプションがあります。
- マネージャー階層 - このオプションは、systemuser テーブルのユーザー階層を使用します。 この制限は、同じ事業単位または真上の事業単位にいるマネージャーが、異なる部門のユーザーのデータを読み取りおよび書き込みできないという制限です。
- 職位階層 - このオプションは、Position テーブルを使用します。 このオプションの方が柔軟で、事業単位の構造を無視します。 職位階層では、1 つの職位に複数のユーザーを設定することもできます。
同時に使用できる階層タイプは 1 つのみです。
監査
監査では、すべてのデータ変更がキャプチャされます。 監査では、誰がどのような変更を行ったかを監視し、ユーザーが実際にシステムを使用している状況を分析するのにも役立ちます。 Dataverse 内の監査機能では、データの読み取りや Microsoft Excel へのエクスポートなどのアクションがキャプチャされません。
使用可能な他の監査は、活動ログと呼ばれ、Microsoft 365 セキュリティおよびコンプライアンス センターにあります。 活動ログには、データの読み取りその他の操作が含まれます。 活動ログは有効にする必要があり、コンプライアンス目標を満たすのに役立ちます。
複数の環境にまたがるセキュリティ管理
セキュリティ ロールおよび列セキュリティ プロファイルは、ソリューションにパッケージ化して他の環境に転送できます。 アクセス チーム テンプレートは、テーブル メタデータの一部であり、ソリューションに追加した時点ですテーブルに含まれます。 事業単位やチームなどの他のセキュリティ機能は、ソリューションにパッケージ化することはできず、ソリューション アーキテクトは環境の人口に合わせて計画する必要があります。
セキュリティ ロールを定義する戦略
セキュリティ ロールを構築するための 3 つの基本的な戦略は次のとおりです。
- 職位別
- ベースライン + 職位
- ベースライン + 能力
職位別戦略は、ジョブ ロールに必要なすべての権限を含む単一のセキュリティ ロールを作成する場合です。 標準のロールは職位にょって異なり、ジョブ ロール (営業担当者など) にちなんで名付けられます。 特定のジョブ ロールに対してこのロールのモデルを実行できますが、類似しており、維持する必要がある多くのセキュリティ ロールが生じる可能性があります。 たとえば、新しいカスタム テーブルを追加すると、すべてではなくても多くのロールが変更されます。
より新しいモデルは、レイヤー化されたセキュリティ モデルを使用します。 このモデルでは、販売担当者や基本ユーザーなどの標準のロールをコピーし、アクセス レベルをすべてのユーザーが必要とする共通、または最小限のレベルに変更します。 このロールに「ベースライン」と名付けるといいでしょう。 その後、新しいロールを作成し、基本ロールに加え各ユーザーのグループに必要な少数の権限に対するアクセス レベルを設定します。 これらの最低限のロールには、職位に必要なその他の権限や必要な能力が含まれています。
次の図では、ベースライン ロールは「全スタッフ」と名付けられており、すべてのユーザーにこのロールが割り当てられます。 Sales の全ユーザーには、「Sales」という名前の職位ロールも割り当てられますが、一部のユーザーには能力ロールである「モバイル」ロールが割り当てられて「Go Mobile」権限のみが付与され、マネージャーには「Sales」ロールと「マネージャー」ロールが割り当てられます。
わかりにくいかもしれませんが、セキュリティ ロールは事業単位にリンクされています。 ルート事業単位で作成されたロールは、すべての下位の部署に継承されます。 特定の事業単位のユーザーにロールを限定する場合は、その事業単位のセキュリティ ロールを作成できます。 ただし、ソリューションのセキュリティ ロールは、ソリューションのインポート時に必ずルート事業単位に追加されることに注意してください。
Microsoft Entra ID グループ チーム
Microsoft Entra ID グループ チームは、レコードを所有し、チームにセキュリティ ロールを割り当てることができるという点で、所有者チームと似ています。 違いは、Dataverse のチーム メンバーシップが、関連付けられている Microsoft Entra ID グループのメンバーシップから動的に派生するという点です。 Microsoft Entra ID グループ メンバーシップは手動で割り当てるか、または Microsoft Entra ID のユーザーの属性に基づいて、ルール ベースの割り当てからさらに派生させることもできます。
チームへの割り当てセキュリティ ロールを持つ Microsoft Entra ID グループ チームと直接ユーザー オプションを組み合わせると、新規ユーザーの追加の管理を大幅に簡素化できます。
セキュリティ グループと Office 365 グループは Microsoft Entra ID グループ チームに使用できます。