データへのきめ細かいアクセスのための階層セキュリティを設定する
) ナビゲーション バーにあります。
階層セキュリティ モデルは、部署、セキュリティ ロール、共有、およびチームを使用する、既存の Dynamics 365 Customer Engagement (on-premises) のセキュリティ モデルの拡張機能です。 これは、他のすべてのセキュリティ モデルとともに使用できます。 階層セキュリティは、組織のレコードに対してよりきめの細かいアクセスを実現し、保守費用の低減を支援します。 たとえば、高度なシナリオでは、複数の部署の作成から始めて、次に階層セキュリティを追加できます。 これは、多くの部署が必要としているところの、より少ない保守費用でよりきめ細かいアクセスを達成します。
管理者階層およびポジション階層セキュリティ モデル
管理者階層とポジション階層の階層に対して、2 のセキュリティ モデルを使用できます。 管理者階層の場合は、レポートのデータにアクセスするには、管理者はレポートと同じ部署内にいるか、レポートの部署の上位の部署にいる必要があります。 ポジション階層では、部署全体のデータにアクセスできます。 財務管理者の場合は、自分の部署以外のデータ アクセスを防止するために、管理者階層モデルを好む場合があります。 ただし、自分が顧客サービス組織の一部であり、管理者が異なる部署で対処するサービス サポート案件にアクセスすることを望んでいる場合は、ポジション階層が正しく機能する場合があります。
Note
階層セキュリティ モデルはデータに対して特定のレベルのアクセスを行うと同時に、セキュリティ ロールなどの他のフォームのセキュリティを使用して追加のアクセスを実施できます。
管理者階層
管理者階層セキュリティ モデルは管理チェーン構造または直接レポート構造に基づいています。この構造では、管理者の関連付けとレポートの関連付けが、システム ユーザー エンティティの管理者フィールドを使用して確立されます。 このセキュリティ モデルでは、管理者はアクセス権を持っているデータにアクセスできます。 管理者は、承認を必要とする自分たちの直接レポートまたはアクセス情報の代わりに仕事を遂行できます。
Note
管理者階層セキュリティ モデルでは、管理者は、ユーザーが所有するまたはユーザーがメンバーになっているチームが所有するレコードに対して、またユーザーまたはユーザーがメンバーになっているチームと直接共有するレコードに対してアクセスできます。 管理チェーン外のユーザーが、読み取り専用アクセス権を持つ直接レポート ユーザーとレコードを共有している場合、直接レポートの管理者は共有レコードへの読み取り専用アクセス権のみを持ちます。
管理者階層セキュリティ モデルのほかに、レポートのデータを表示するには、エンティティに対して少なくともユーザー レベルの読み取り特権を持つ必要があります。 たとえば、管理職にサポート案件エンティティに対する読み取りアクセス権がない場合は、管理職は自分たちのレポートがアクセスするサポート案件を表示できません。
管理者の同じ管理チェーンにおける間接レポートについて、管理者は間接レポートのデータに読み取り専用のアクセス権を持ちます。 直接レポートについては、管理者はレポートのデータに対する読み取り、書き込み、更新、追加、追加先のアクセス権を所有しています。 管理者階層セキュリティ モデルについて説明するために、次の図を参照します。 CEO は、営業担当部長データとサービス担当部長データを読み取りまたは更新できます。 ただし、CEO は、営業データとサポートデータのほかに、営業課長データとサービス課長データのみを読み取ることができます。 さらに、課長がアクセスできるデータの量を "深さ" を使用して制限できます。 深さは、課長が自分たちのレポートのデータのいくつのレベルまで深く読み取り専用アクセス権を使用できるかを制限するために使用します。 たとえば、深さが 2 に設定されている場合は、CEO は営業担当部長、サービス担当部長、営業課長およびサービス課長のデータを表示できます。 ただし、CEO は営業データやサポート データを表示できません。
直接レポートのエンティティへのアクセス権が管理者よりも深い場合、管理者は直接レポートがアクセス権を持つ一部のレコードを表示できない場合があることに注意してください。 次の例は、この点を示しています。
一つの部署に次の 3 名のユーザーがいます: ユーザー 1、ユーザー 2、ユーザー 3。
ユーザー 2 はユーザー 1 の直接レポートです。
ユーザー 1 とユーザー 3 は、取引先企業エンティティのユーザー レベルの読み取りアクセス権を持ちます。 このアクセス レベルでは、ユーザーは、ユーザーが所有しているレコード、ユーザーが共有しているレコード、ユーザーがメンバーになっているチームが共有しているレコードにアクセスできます。
ユーザー 2 は、取引先企業エンティティの部署レベルの読み取りアクセス権を持ちます。 これによって、ユーザー 2 はユーザー 1 とユーザー 3.が所有する取引先企業すべてを含む、部署のすべての取引先企業を表示することができます。
ユーザー 2 の直属の上司としてのユーザー 1 は、ユーザー 2 が所有または共有する取引先企業、およびユーザー 2 が属するチームが所有または共有する取引先企業へのアクセス権を持ちます。 ただし、直接レポートがユーザー 3 の取引先企業へのアクセス権がある可能性がありますが、ユーザー 1 はユーザー 3 の取引先企業に対するアクセス権を持ちません。
ポジション階層
ポジション階層は、管理者階層のような、直接レポート構造に基づいていません。 ユーザーは、別のユーザーのデータにアクセスするために、そのユーザーの実際の管理者になる必要はありません。 管理者の場合は、組織内のさまざまな職位を定義し、職位をポジション階層に配置します。 次に、特定のポジションにユーザーを追加します。すなわち、ユーザーに特定のポジションを "タグ付け" します。 ユーザーには特定の階層の 1 つポジションのみをタグ付けできますが、1 つのポジションを複数のユーザーに使用できます。 階層内の高いポジションにいるユーザーは、直接の上位パス内の低いポジションにいるユーザーのデータにアクセスできます。 直接の高いポジションは、直接の上位パス内の低いポジションのデータに対して、読み取り、書き込み、更新、追加、追加先のアクセス権を所有します。 間接の高いポジションは、直接の上位パス内の低いポジションのデータに対して、読み取り専用のアクセス権を所有します。
直接の上位パスの概念を説明するために、次を図を表示します。 営業課長のポジションは営業データにアクセスできますが、別の上位パスにあるサポート データへにはアクセスできません。 このことは、サービス課長のポジションについても同じです。 営業パスにある営業データにはアクセスできません。 管理者階層と同様に、高いポジションがアクセスできるデータの量を "深さ" を使用して制限できます。 深さのパスは、高いポジションが読み取り専用のアクセスをできる深さのレベルを、直接の上位パス内の低いポジションのデータに制限します。 たとえば、深さが 3 に設定されると、CEO ポジションは、営業担当部長とサービス部長のポジションから営業とサービスのポジションまでのデータを表示できます。
注意
ポジション階層セキュリティでは、高いポジションのユーザーは、低いポジションのユーザーが所有するまたはユーザーがメンバーになっているチームが所有するレコードに対して、またユーザーまたはユーザーがメンバーになっているチームと直接共有するレコードに対してアクセスできます。
高いレベルにいるユーザーは、ポジション階層セキュリティ モデルに加えて、低いポジションのユーザーがアクセスできるレコードを表示するためには、少なくとも 1 つのエンティティに対するユーザー レベルの読み取り特権を所有する必要があります。 たとえば、高いレベルにいるユーザーにサポート案件エンティティに対する読み取りアクセス権がない場合、そのユーザーは低いポジションのユーザーがアクセスできるサポート案件を表示できません。
階層セキュリティのセットアップ
セキュリティ階層をセットアップするには、管理者のセキュリティ ロールが必要です。
階層セキュリティは既定では無効になっています。 有効にするには、次の手順を実行します。
設定>セキュリティに移動します。
階層セキュリティを選択し、階層モデルの有効化を選択します。
重要
階層セキュリティを変更するには、階層セキュリティ設定の変更特権が必要です。
階層モデルを有効にしてから、管理者階層またはカスタム ポジション階層を選択して特定のモデルを選択します。 すべてのシステム エンティティは階層セキュリティが標準で有効になっていますが、選択したエンティティを階層から除外することができます。 階層セキュリティウィンドウを下に表示します。
深さ を必要な値に設定して、管理者が自分たちのレポートのデータに対して読み取り専用のアクセスができるレベルの深さを制限します。 たとえば、深さが 2 の場合は、管理者は自分のアカウントと 2 レベルの深さまでのレポートのアカウントにのみアクセスできます。 この例で Customer Engagement アプリへのログインが、すべてのアカウントを表示できる管理者としてでなく営業担当部長としてであった場合は、以下に説明するようにユーザーのアクティブなアカウントのみが赤色の四角に囲まれて表示されます。
注意
階層セキュリティが営業担当部長に赤色の四角形内のレコードへのアクセスを付与している間は、営業担当部長が所有するセキュリティ ロールに基づいて追加のアクセスを使用できます。
管理者階層とポジション階層のセットアップ
管理者階層は、システム ユーザー レコード上の管理者関連付けを使用して間単に作成されます。 ユーザーの上司を指定するには、管理者 (ParentsystemuserID) 検索フィールドを使用します。 ポジション階層をすでに作成している場合は、ユーザーにポジション階層の特定のポジションをタグ付けすることもできます。 次の例では、営業担当者が管理者階層の営業課長に直属し、またポジション階層の営業ポジションを所有しています。
ユーザーをポジション階層の特定のポジションに追加するには、以下に示すように、ユーザー レコードのフォームの [ポジション] という名前の検索フィールドを使用します。
重要
ユーザーをポジションに追加したり、ユーザーのポジションを変更するには、ユーザーのポジションの割り当て 特権が必要です。
ユーザー レコードのフォーム上のポジションを変更するには、以下に示すように、ナビゲーション バーでその他 (…) を選択し、別のポジションを選択します。
ポジション階層を作成するには:
設定>セキュリティに移動します。
ポジションを選択します。
ポジションごとに、ポジションの名前、ポジションの親、および説明を入力します。 このポジションのユーザーという名前の検索フィールドを使用して、ユーザーをこのポジションに追加します。 以下に、アクティブなポジションを持つポジション階層の例を示します。
対応するポジションを持つ有効なユーザーの例を次に示します。
パフォーマンスに関する考慮事項
パフォーマンスを向上するために、以下のことをお勧めします。
管理職とポジションの有効な階層セキュリティを 50 ユーザー以下に維持します。 階層には、管理者/ポジションの下に 50 を越えるユーザーを入れることができますが、深さの設定を使用して読み取り専用アクセスのレベル数を削減し、この制限を使用して管理者/ポジションの下の有効なユーザー数を 50 ユーザー以下に削減できます。
より高度なシナリオの場合は、既存のセキュリティ モデルと組み合わせて階層セキュリティ モデルを使用します。 多数の部署を作成しないようにし、代わりに、少ない部署と階層セキュリティを作成します。
関連項目
Microsoft Dynamics 365 for Customer Engagement のセキュリティ概念
階層データのクエリおよび視覚化