ロールベースのセキュリティを使用してエンティティへのアクセスを制御する方法
Dynamics 365 Customer Engagement (on-premises) では、ロールベースのセキュリティの基本概念は、ロールには組織内で実行できる一連のアクションを定義する特権が含まれるということです。 たとえば、営業担当者というロールには、そのロールに定義されたタスクの実行に関する一連の特権が割り当てられます。 すべてのユーザーは、これらの中で 1 つ以上の定義済みロールまたはユーザー定義ロールに割り当てられる必要があります。 Dynamics 365 Customer Engagement (on-premises) では、チームにもロールを割り当てることができます。 これらのロールのいずれかにユーザーまたはチームを割り当てると、そのロールに関連付けられた一連の特権がユーザーまたはチーム メンバーに割り当てられます。 ユーザーは、少なくとも 1 つのロールに割り当てられる必要があります。
特権は、特定のエンティティの種類に関する特定の操作の実行をユーザーに許可します。 特権は、オブジェクトの個々のインスタンスではなく、オブジェクトのクラス全体に適用されます。 たとえば、ユーザーに取引先企業を読み取る特権がない場合、そのユーザーがどの取引先企業の読み取りを試みても失敗します。 特権には、その特権が適用される組織内の階層を決定するアクセス レベルが含まれます。 各特権には最大 4 つのアクセス レベル (ベーシック、ローカル、ディープ、およびグローバル) を設定できます。
ロール
Dynamics 365 Customer Engagement (on-premises) には、14 の定義済みのロールが用意されています。これらのロールは、一般的なユーザー ロールを反映し、仕事の実行に必要な最小限の業務データへのアクセスを許可する、というセキュリティのベスト プラクティスの目的に沿うようにアクセス レベルが定義されています。 これらのロールを使用すると、独自のロールを定義しなくても、Dynamics 365 Customer Engagement (on-premises) システムを迅速に展開できます。 ただし、定義済みのロールをテンプレートとして使用してユーザー定義ロールを作成したり、まったく新しい一連のロールを定義することができます。 一覧については、「定義済みのセキュリティ ロールの一覧」を参照してください。
各ロールには、社内の情報に対するユーザーまたはチームのアクセス権を決定する一連の特権が関連付けられます。
Dynamics 365 Customer Engagement (on-premises) でロールを作成し、ビジネス ニーズに合わせてこれらのユーザー定義ロールを変更または削除することができます。 部署用に作成したロールは、階層内のすべての部署によって継承されます。
1 人のユーザーまたは 1 つの チームに 1 つ以上のロールを割り当てることができます。 たとえば、顧客サービス担当者というロールに加えて営業課長というロールを割り当てることができます。この場合、そのユーザーは両方のロールのすべての特権を取得します。
ユーザー レベルでは特権を変更できませんが、必要な特権を持つ新しいロールを作成できます。 たとえば、佐藤さんに営業担当者ロールが割り当てられており、このロールではそのユーザーに割り当てられた潜在顧客をすべて引き受ける必要があるとします。 これに対し管理者は、佐藤さんに割り当てられた潜在顧客を佐藤さんが再割り当てできるようにしたいと考えます。 この場合、管理者は営業担当者ロールを変更して再割り当てを可能にするか、または再割り当ての特権が組み込まれた新しいロールを作成し、そのロールに佐藤さんを追加する必要があります。 営業担当者ロールが割り当てられたすべてのユーザーに再割り当ての特権を追加する必要があると判断した場合を除き、新しいロールを作成する方法をお勧めします。
特権
Dynamics 365 Customer Engagement (on-premises) のセットアップ時には、システム全体に適用される 580 を超える特権が事前に定義されます。 特権は、Dynamics 365 Customer Engagement (on-premises) で操作を実行するためのアクセス許可です。 一部の特権は一般に適用され、一部は特定の種類のエンティティに適用されます。
Dynamics 365 Customer Engagement (on-premises) では、基盤となるセキュリティ チェックの核として特権が使用されます。 特権は製品に組み込まれており、アプリケーション層およびプラットフォーム層全体で使用されます。 特権の追加や削除、または特権を使用して特定の機能へのアクセスを許可する方法を変更することはできませんが、既存の特権セットから新しいロールを作成できます。
各ロールは、企業内の情報に対するユーザーまたはチームのアクセスを指定する一連の特権を定義します。 プラットフォーム側で特権が確認され、ユーザーが必要な特権を持っていなければ、操作は拒否されます。 特権は階層、つまりアクセス レベルと組み合わせて使用されます。
たとえば、営業担当者ロールには Read Account
アクセス レベルの Basic
特権とWrite Account
アクセス レベルの Basic
特権が含まれ、営業課長ロールにはRead Account
アクセス レベルの Local
特権と Assign Contact
アクセス レベルの Local
特権が含まれるといった具合です。
ほとんどのエンティティには、そのエンティティのレコードに対して実行できるさまざまな操作に対応する、ロールに追加できる一連の特権があります。
システム内の各操作および SDK ドキュメントに記載されている各メッセージを実行するには、1 つ以上の特権が必要です。
アクセス レベル
特権のアクセス レベル (特権の階層) は、特定のエンティティの種類について、組織の階層のどのレベルでユーザーがその種類のエンティティを操作できるかを決定します。
以下の表には、Dynamics 365 Customer Engagement (on-premises) のアクセス レベルが示されます (最も高いアクセス レベルから順番に並んでいます)。 アイコンは、Web アプリケーションのセキュリティ ロール エディターに表示されます。
アクセス レベル | Description |
---|---|
グローバル。 このアクセス レベルでは、ユーザーは、インスタンスやユーザーが属する部署階層レベルに関係なく、組織のすべてのレコードにアクセスできます。 グローバル アクセス レベルを持つユーザーは、自動的にディープ、ローカル、およびベーシックの各アクセス レベルも持つことになります。 このアクセス レベルでは、組織全体の情報へのアクセスが許可されるため、組織のデータ セキュリティ計画に合わせて制限する必要があります。 通常、このアクセス レベルは、組織に対する権限を持つ管理者のために予約されています。 このアクセス レベルは、アプリケーションでは組織と呼ばれます。 |
|
ディープ。 このアクセス レベルでは、ユーザーは、ユーザーの事業単位と、ユーザーの事業単位に従属するすべての事業単位のレコードへのアクセス許可が付与されます。 ディープ アクセス権を持つユーザーは、自動的にローカルおよびベーシックのアクセス権も持つようになります。 このアクセス レベルでは、事業単位と従属事業単位全体の情報へのアクセスが許可されるため、組織のデータ セキュリティ計画に合わせて制限する必要があります。 通常、このアクセス レベルは、事業単位に対する権限を持つ管理者のために予約されています。 このアクセス レベルは、アプリケーションでは部署配下と呼ばれます。 |
|
ローカル。 このアクセス レベルでは、ユーザーは、ユーザーの事業単位のレコードにアクセスできます。 ローカル アクセス権を持つユーザーは、自動的にベーシック アクセス権も持つようになります。 このアクセス レベルでは、事業単位全体の情報へのアクセスが許可されるため、組織のデータ セキュリティ計画に合わせて制限する必要があります。 通常、このアクセス レベルは、事業単位に対する権限を持つ管理者のために予約されています。 このアクセス レベルは、アプリケーションでは事業単位と呼ばれます。 |
|
ベーシック。 このアクセス レベルでは、ユーザーは、ユーザーが所有しているレコード、ユーザーが共有しているオブジェクト、ユーザーがメンバーになっているチームが共有しているオブジェクトにアクセスできます。 通常は、営業やサービスの担当者に対して使用されます。 このアクセス レベルは、アプリケーションではユーザーと呼ばれます。 |
|
なし。 アクセスは許可されません。 |
まとめ
Deep Read Account
特権を持つユーザーは、自分の部署のすべての取引先企業と、その配下のすべての部署の取引先企業を読み取ることができます。Local Read Account
特権を持つユーザーは、自分の部署のすべての取引先企業を読み取ることができます。Basic Read Account
特権を割り当てられたユーザーは、自分が所有または共有している取引先企業のみを読み取ることができます。Basic Read Account
権限を持つ顧客サービス担当者は、自分が所有している取引先企業と、別のユーザーが自分と共有している取引先企業を表示できます。 これにより、サービス要求に関連する取引先企業データを読み取ることができますが、そのデータを変更することはできません。Local Read Account
特権を持つデータ アナリストは、自分の部署のすべての取引先企業について、取引先企業データを表示したり取引先企業関連のレポートを実行することができます。Deep Read Account
特権を持つ会社の会計係は、自分の部署のすべての取引先企業とその配下の部署の取引先企業について、取引先企業データを表示したり取引先企業関連のレポートを実行することができます。
定義済みのセキュリティ ロールの一覧
次の表に、含まれている一連の事前定義のロールを示します。
ロール | 内容 |
---|---|
最高経営責任者 | 法人レベルの組織を管理するユーザー。 |
顧客サービス課長 | 地域またはチーム レベルで顧客サービス活動を管理するユーザー。 |
顧客サービス担当者 (CSR) | すべてのレベルの顧客サービス担当者 (CSR)。 |
代理人 | 別のユーザーに代わって行動することを許可されたユーザー。 |
マーケティング課長 | 地域またはチーム レベルでマーケティング活動を管理するユーザー。 |
マーケティング プロフェッショナル | すべてのレベルのマーケティング活動に関与するユーザー。 |
営業課長 | 地域またはチーム レベルで営業活動を管理するユーザー。 |
営業担当者 | 任意のレベルの営業担当者。 |
フィールド サービス課長 | サービスの予定を計画するユーザー。 |
フィールド サービス担当者 | サービスを管理するユーザーで、リソースと作業時間を必要とするユーザー。 |
サポート ユーザー | 顧客サポート エンジニアであるユーザー。 |
システム管理者 | 任意のレベルでプロセスを定義して実行するユーザー。 |
システムのカスタム担当者 | Dynamics 365 for Customer Engagement のエンティティ、属性、リレーションシップ、およびフォームをカスタマイズするユーザー。 |
マーケティング部長 | 部署レベルでマーケティング活動を管理するユーザー。 |
営業担当副社長 | 部署レベルの営業組織を管理するユーザー。 |
関連項目
Microsoft Dynamics 365 Customer Engagement (on-premises) のセキュリティモデル
特権およびロール エンティティ
レコード ベースのセキュリティを使用してレコードへのアクセスをコントロールする
Microsoft Dynamics 365 Customer Engagement (on-premises) で、フィールド セキュリティを使用してフィールド値へのアクセスを制御する方法