レコード ベースのセキュリティを使用してレコードへのアクセスをコントロールする
Dynamics 365 Customer Engagement (on-premises) のレコードベースのセキュリティは個々のレコードに適用されます。 これは、アクセス権を使用することで提供されます。
アクセス権と特権との関係では、特権が有効な場合にのみアクセス権が適用されます。 たとえば、ユーザーに取引先企業の読み取り特権がない場合、他のユーザーが行った共有操作によって特定の取引先企業に対するアクセス権を付与されたとしても、そのユーザーは取引先企業を読み取ることはできません。
アクセス権
アクセス権は、特定のレコードに関してユーザーに付与される権限です。 次の表では、これらのアクセス権について説明します。
| アクセス権 | AccessRights 列挙値 | 内容 |
|---|---|---|
| 読み込み | 読み取りアクセス権 | ユーザーがレコードを読み取ることができるかどうかを制御します。 |
| 書き込み | WriteAccess | ユーザーがレコードを更新できるかどうかを制御します。 |
| 割り当て | AssignAccess | ユーザーがレコードを別のユーザーに割り当てることができるかどうかを制御します。 |
| 追加 | AppendAccess | ユーザーが指定されたレコードに別のレコードを添付できるかどうかを制御します。 追加アクセス権と追加先アクセス権は連係して機能します。 レコードを別のレコードに関連付けるには、そのユーザーがこれら両方の権限を持っている必要があります。 たとえば、案件にメモを添付する場合は、メモに対する追加アクセス権と、操作対象の案件に対する追加先アクセス権が必要です。 |
| 追加先 | AppendToAccess | ユーザーが当該レコードを別のレコードに追加できるかどうかを制御します。 追加アクセス権と追加先アクセス権は連係して機能します。 詳細については、追加の説明を参照してください。 |
| 共有 | ShareAccess | ユーザーがレコードを別のユーザーまたはチームと共有できるかどうかを制御します。 共有すると、別のユーザーにレコードへのアクセス権が付与されます。 詳細については、「レコードの共有」を参照してください。 |
| 削除 | DeleteAccess | ユーザーがレコードを削除できるかどうかを制御します。 |
アクセス権の作成
上の表には、エンティティの種類に対するレコードを作成するための権限が示されていません。これは、この権限が、個々のレコードではなくエンティティのクラスに適用されるためです。 作成権はアクセス権ではなく特権として扱われます。 レコードを作成するユーザーは、そのユーザーの他の特権によって特定の権限が禁止されていない限り、作成したレコードに対してすべての権限を持ちます。
作成特権は、ユーザーがレコードを作成できるかどうかを制御します。 ローカル、ディープ、またはグローバル アクセス レベルの作成特権を持つユーザーは、他のユーザー用のレコードを作成できます。 ベーシック アクセス レベルの作成特権または読み取り特権を持つユーザーは、自分用のレコードを作成できます。
作成特権に関連する依存関係の詳細については、「アクセス権間の依存関係」を参照してください。
レコードの共有
共有によって、その他のユーザーやチームが特定の顧客情報にアクセスできるようになります。 ベーシックのアクセス レベルしかないロールのユーザーと情報を共有するのに役立ちます。 たとえば、営業担当者に取引先企業へのベーシックの読み取りおよび書き込みアクセス権限を与える組織において、営業担当者は営業案件を別の営業担当者と共有し、重要な販売の進行状況を両者が追跡できるようにすることができます。
セキュリティ上の理由のため、共有する必要があるレコードだけを最小限のユーザーと共有してください。 ユーザーが業務のために必要な最小限のアクセス権だけを付与してください。
Dynamics 365 Customer Engagement (on-premises) には、次の共有機能があります。
共有: 特定のエンティティの種類に対する共有特権を持っているユーザーは、その種類のレコードを Dynamics 365 Customer Engagement (on-premises) 内の他のユーザーまたはチームと共有できます。 レコードを共有するには、GrantAccessRequest を使用します。
レコードを別のユーザーと共有するときは、他のユーザーに付与するアクセス権 (読み取り、書き込み、削除、追加、割り当て、共有) を指示します。 共有レコードに対するアクセス権は、レコードを共有するユーザーごとに変えることができます。 ただし、ユーザーに割り当てられたロールに基づいてその種類のエンティティに付与される権限以外の権限を与えることはできません。 たとえば、取引先企業に対する読み取り特権がユーザーにない場合、そのユーザーと取引先企業を共有した場合でも、ユーザーはその取引先企業を表示することはできません。
共有の変更: 共有レコードに付与された権限を、共有された後で変更できます。 レコードの共有を変更するには、ModifyAccessRequest を使用します。
共有の削除: レコードを別のユーザーまたはチームと共有した場合は、レコードの共有を停止できます。 レコードの共有を削除した後は、他のユーザーやチームはそのレコードに対するアクセス権を失います。 レコードの共有を削除するには、RevokeAccessRequest を使用します。
チップ
共有には、GrantAccessRequest、ModifyAccessRequest、およびRevokeAccessRequest を使用します。
一人のユーザーが、同一のレコードに対するアクセス権を複数のコンテキストで持つ場合があります。 たとえば、特定のアクセス権によってレコードを直接共有しているユーザーが、同じレコードを他のアクセス権で共有しているチームに属している場合です。 この場合、このユーザーのレコードに対するアクセス権は、すべての権限を合わせたものになります。
共有をサポートするエンティティの一覧については、「GrantAccessRequest」を参照してください。
共有および継承
レコードの作成時に、そのレコードの親レコードに特定の共有プロパティがある場合、新しく作成されたレコードはそれらのプロパティを継承します。 たとえば、佐藤さんと安田さんは優先度の高い潜在顧客を担当しているとします。 佐藤さんが 1 件の新規潜在顧客と 2 つの活動を作成し、その潜在顧客を安田さんと共有し、伝播共有を選択します。 安田さんが新規潜在顧客に電話をかけ、電子メールを送信します。 佐藤さんには安田さんがその会社に 2 回連絡したことがわかるため、さらに電話をかけることはしません。
共有は、各レコードで個別に保持されます。 レコードは親から共有プロパティを継承し、かつ独自の共有プロパティも保持します。 したがって、1 つのレコードは、共有プロパティを 2 セット (1 つは独自のもの、もう 1 つは親から継承したもの) を持つことができます。
親レコードの共有を削除すると、親から継承したオブジェクト (レコード) の共有プロパティが削除されます。 これは、削除前はレコードを表示できたすべてのユーザーが、そのレコードを表示できなくなることを意味します。 子オブジェクトが親レコード経由ではなく個別に共有されている場合、これらのユーザーの一部は子オブジェクトを引き続き共有できます。
レコードの割り当て
レコードの割り当て特権を持つユーザーは、レコードを別のユーザーに割り当てることができます。 レコードが新しいユーザーに割り当てられると、新しいユーザーまたはチームは、レコードと、それに関連するレコードの所有者になります。 元のユーザーまたはチームはレコードの所有権を失いますが、新しい所有者と自動的にそのレコードを共有します。
Dynamics 365 for Customer Engagement では、システム管理者は、組織において、割り当て操作の後にレコードを前の所有者と共有する必要があるかどうかを決定できます。 譲受人について、以前の所有者に共有を設定するかどうかを指定する情報です。を選択すると、割り当て操作後に前の所有者が、すべてのアクセス権限を保持してレコードを共有します。 そうでない場合、前の所有者はレコードを共有しないため、その所有者が持っている特権によっては、レコードにアクセスできなくなる場合があります。 この設定は、Organization.ShareRoPreviousOwnerOnAssign 属性によって制御されます。
割り当てをサポートするエンティティの一覧については、「AssignRequest」を参照してください。
レコードのアクセス権の取得
指定されたセキュリティ プリンシパル (ユーザーまたはチーム) がレコードに対して持っているアクセス権を取得するには、RetrievePrincipalAccessRequest メッセージを使用します。
レコードに対するアクセス権を持つすべてのセキュリティ プリンシパル (ユーザーまたはチーム) と各自のアクセス権を取得する場合は、RetrieveSharedPrincipalsAndAccessRequest メッセージを使用します。
アクセス権間の依存関係
複数のアクセス権が必要となる特定の操作では、セキュリティの依存関係が存在する場合があります。 たとえば、取引先企業の作成アクセス権があれば、取引先企業エンティティの種類のレコードを作成できますが、 取引先企業の読み取りアクセス権がなければ、取引先企業レコードを作成し、新しいレコードの所有者になることはできません。
次の表に、指定した操作に対するアクセス権の依存関係を一覧表示します。
| アクション | 必要なアクセス権 |
|---|---|
| レコードを作成して、そのレコードの所有者になる | 作成 READ |
| レコードを共有する | SHARE。 共有操作を実行するユーザーにはこのアクセス権が必要です。 READ。 共有操作を実行するユーザーにはこのアクセス権が必要です。レコードが共有されているユーザーにも必要です。 |
| レコードを割り当てる | ASSIGN WRITE READ |
| レコードに追加する | WRITE READ APPENDTO |
| レコードを追加する | WRITE READ APPEND |
オブジェクトが別のオブジェクトに従属する場合、異なる依存関係が存在します。 たとえば、営業案件オブジェクトは単独で存在することはできません。 各営業案件は常に取引先企業または取引先担当者に付随します。 営業案件を作成するには、営業案件の追加アクセス権だけでなく、取引先企業の追加先アクセス権が必要です。
関連項目
Microsoft Dynamics 365 Customer Engagement (on-premises) のセキュリティモデル
ロール ベースのセキュリティを使用して Microsoft Dynamics 365 Customer Engagement (on-premises) におけるエンティティへのアクセスを制御する方法 フィールド セキュリティを使用して、Microsoft Dynamics 365 Customer Engagement (on-premises) におけるフィールド値へのアクセスを制御する方法
Microsoft Dynamics 365 Customer Engagement (on-premises) のエンティティの概要
エンティティ関係の動作
AccessRights
RetrievePrincipalAccessRequest
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示