導入
顧客の Microsoft Dynamics 365 の展開がセキュリティでより保護されていることを確認するために、ソリューション アーキテクトはセキュリティ モデル ワークショップを計画し提供する必要があります。 このワークショップの目的は、提案されたセキュリティ モデルを評価し、技術的なリスクや懸案事項を強調するためのフィードバックとレコメンデーションを提供して、ベスト プラクティスを特定することです。
セキュリティ モデル ワークショップは、プロジェクトの実装フェーズ中にスケジュールし、完了する必要があります。 このワークショップでは、前のワークショップで検討したセキュリティ関連のすべての領域のまとめを行う必要があります。
各モジュールのワークショップのサンプル テンプレートをダウンロード して、ソリューションでそれらのワークショップを実施するときに使用することができます。
セキュリティが重要である理由
Dynamics 365 は、顧客の業務を推進します。 システム内の顧客、財務情報、および業務上の重要なプロセスに関する機密性の高い業務データは、システムを採用する顧客にとって安全である必要があります。
適切なセキュリティ戦略は、正当なセキュリティ要件とシステム アクセスおよび企業内コラボレーションの必要性とのバランスをとっています。 Dynamics 365 を実装する際は、ユーザー アクセスとシステム セキュリティ の 2 つの懸念点のバランスをとる必要があります。
データとシステム セキュリティについて検討することが重要です。 業務を推進するのはデータです。 顧客、注文、主要なビジネス連絡先の情報は、競合企業の手に渡らないようにしなければなりません。 データの侵害が個人のデータに影響を与える場合、個人データに関連する規制により、会社は責任を問われる可能性があります。
また、システムのユーザビリティとユーザーの採用に関する懸念もあります。 Dynamics 365 を実装する主な理由の 1 つとして、組織内のデータ サイロの排除を含む、グループ間のビジネス データの可視性と共有の強化が挙げられます。 組織全体にわたって連絡先とアカウントを可視化することにより、各チームは競争をするのではなく、共同作業を効果的に行い、連絡先やアカウントのマスター情報に関しては、正しいバージョン 1 つのみが存在することが保証されます。 どちらかを重要視しすぎると、実装が失敗する恐れがあります。
セキュリティが充分でない場合、ユーザーは変更すべきでない唯一の正しいバージョンを変更できるようになり、システム データの信頼性が低いとの印象をユーザーに与えてしまいます。
セキュリティが厳しすぎると、ユーザーはシステム内のレコードの一部しか見ることができず、コラボレーション ツールとしての Dynamics 365 の価値を下げることになります。 その結果、以前のようなサイロ化されたデータを別の場所に移しただけになってしまいます。
セキュリティ モデルの考慮事項
以下のセクションでは、ワークショップの詳細に進む前に、最も多くの Dynamics 365 実装に共通するいくつかの主要なセキュリティ要素について説明します。
セキュリティ戦略の構築
すべての組織のセキュリティ戦略は同じではありませんが、実装には次のガイドラインが役立つ場合があります。
読み取りよりも書き込む方を制限する
適切なデータ品質を維持するには、レコードの所有者のみが編集または削除権限を制限するなど、レコードを編集または削除できるユーザーを制限することをお勧めします。 多くの場合、レコードの読み取り制限を緩やかなものにすることが適しています。 そうすることで、Dynamics 365 のユーザビリティを維持し、ユーザーは、レコードと親アカウントなどの他のレコードとの関係性を把握することができます。 また、ユーザーが、所有していないレコードを誤って編集したり削除したりするリスクを排除することができます。
簡素化
Dynamics 365 セキュリティ ツールボックスには多くのツールが用意されていますが、このツールを使用して作業を開始する前に、セキュリティ モデルを長期的に管理する作業をどのように簡素化するかについて検討してください。 セキュリティ モデルを機能させるために、管理者が 4 つの異なるロールを 1 人の新しいユーザーに割り当てて、そのユーザーを複数のチームに追加する必要がある場合、顧客はその戦略を長期間維持することができなくなる可能性があります。 ソリューション アーキテクトは、セキュリティ設計がユーザー エクスペリエンスに与える影響を検討する必要があります。 さらに、システム管理者へのセキュリティ戦略管理の複雑さを判断する必要があります。 最適なセキュリティ戦略とは、単純で、きちんと文書化されており、再現可能であるものです。 このような理由で、Active Directory セキュリティ グループなどの機能を使用すると、ロール、チーム、および事業単位の割り当てを自動化し、人為的ミスの可能性を最小限に抑えることができるため、より規模が大きく複雑な展開に適しています。
セキュリティ設計が正当なビジネス要件に基づいていることを確認する
セキュリティ設計の判断が脅威の視点に基づいているか、または正当なビジネスの懸念点に基づいているかを確認する必要があります。 脅威に基づいている場合、決定はユーザーによる過去のミスを理由に行われている可能性があります。 脅威、特に従業員の脅威は、良い設計するための動機ではありません。 職務を実行し、会社を代表し、製品の販売することについて、従業員を信頼しなければなりません。 セキュリティを過度に厳しく設計することで、管理者と従業員の間に根本的な信頼関係の問題が発生することがあります。
セキュリティ設計を文書化し再評価する
セキュリティ設計は、Dynamics 365 の実装の開始時に検討される概念ですが、一部の実装では、その後見落とされることがあります。 顧客の使用パターンやユーザー ベースが変わると、初期のセキュリティ設計が適さなくなるため、設計は定期的に調整する必要があります。
たとえば、より小さなユーザー ベースでは、1 つの事業単位を考慮した設計が機能します。 ただし、ユーザー ベースが成長し、多様な要件を持つ複数の部門が含まれるようになると、より大規模なユーザー ベース向けに展開をスケールするために、事業単位の追加が必要になることがあります。 絶対的なルールが確立されているわけではありませんが、セキュリティ戦略と設計を定期的に見直し、その長所と短所を評価して、改善する分野を特定することがベスト プラクティスとして推奨されます。 このため、Success by Design のフレームワークの一部としてセキュリティ モデルを文書化し、顧客やコンサルタントが継続的に参照でき、セキュリティ要件の変化に応じて更新できるようにすることが重要です。
セキュリティ戦略が構成の選択を促進
顧客またはパートナーがテーブル構造を設計する際は、セキュリティ戦略を念頭に置くことが必要です。 テーブルの構成によって、セキュリティ戦略がサポートされます。 たとえば、組織レベルの所有権を使用してテーブルが作成された場合、顧客は所有権または事業単位に応じてテーブル レコードへのアクセスを制限することができません。 テーブルへのアクセスを制限しない場合でも、ルックアップ リストのフィードのように、テーブルが会社間の参照データにのみ使用される場合を除いて、常にユーザーまたはチームの所有権を選択することがベスト プラクティスです。 また、あるテーブルのセキュリティが、関連するテーブルのセキュリティに与える影響についても考慮してください。 親レコードへのアクセス権を子レコードにカスケードする必要がある場合は、親または構成可能なカスケード リレーションシップ タイプを使用することをお勧めします。
アプリ レイヤーではなくプラットフォーム レイヤーでのセキュリティ
データの読み取りと編集を制御するには、さまざまな方法があります。 モデル駆動型フォームでは、フィールドを読み取り専用に設定できます。また、JavaScript を使用して、ユーザー エクスペリエンスのフィールドをマスクしたり、フォームやビューからフィールドを非表示にしたりできます。 これらの方法は、ユーザーの行動を制御しますが、データは保護しないため、セキュリティとしてはみなされません。 ユーザーは、他の方法でデータにアクセスできます。 データを保護するには、ロール、チーム、事業単位などのセキュリティ機能を使用する必要があります。
セキュリティ モデル コンポーネント
Dynamics 365 には、ほぼすべてのセキュリティ要件を満たすために使用できるいくつかのツールが用意されています。 このセクションでは、ソリューション アーキテクト向けに、包括的なセキュリティ モデルを構築するための主要なツールについて簡単に説明します。
事業単位
事業単位は、Dynamics 365 のユーザーおよびレコードの組織構造を定義するためのフレームワークを提供します。 事業単位は、組織階層に基づいてユーザーとチームをグループ化し、セキュリティ ロールと連携してデータへのアクセスを許可または制限することができます。
事業単位の機能は、事業単位の階層的な性質に由来しています。 ユーザーには、自分が所属する事業単位のみ、または自分の事業単位とその配下の事業単位のレコードへのアクセス許可を付与することができます。 たとえば、事業単位の階層に応じて、サイト、地域、リージョン、および企業レベルでのレコードへのアクセスを制限できます。
事業単位に関する以下のような要素について理解しておく必要があります。
Microsoft Dataverse データベースがプロビジョンされると、ルート事業単位が作成されます。
ユーザーまたはチームは、1 つの事業単位のメンバーにしかなれません。
レコードは、所有ユーザーまたはチームを通じて、1 つの事業単位にのみ関連付けられます。
ユーザーまたはチームは、別の事業単位に移動することができます。 事業単位間でユーザーまたはチームを移動する場合は、そのユーザーまたはチームが所有するすべてのレコードを新しい事業単位に再度関連付ける必要があります。元の事業単位で読み取りセキュリティが設定されているユーザーは、これらのレコードにアクセスできなくなります。
ユーザーまたはチームを新しい事業単位に移動する場合は、すべてのセキュリティ ロールをユーザーまたはチームに再度適用する必要があります。
ルート以外の事業単位は、無効にされた後に削除することができます。
事業単位は階層内で移動できますが、ルート事業単位をリペアレントすることはできません。
通常、事業単位の構造は会社の組織図と似ていますが、特別な業務上の理由がない限り、組織図ほど細分化する必要はありません。 事業単位は、セキュリティ モデルの構成要素として考える必要があります。 ほとんどの場合、会社の部門ごとに事業単位を作成する必要はありません。 たとえば、部門間で制限するレコードが存在しない場合は、営業部門とマーケティング部門は同じ事業単位を共有できます。 セキュリティ ロールは事業単位と連携して機能し、営業とマーケティングが同じ事業単位に含まれる場合でも、セキュリティ ロールによってユーザー レベルを制限している場合は、すべてのユーザーが必ずしもすべてのレコードにアクセスできるわけではありません。
セキュリティ ロール
セキュリティ ロールによって、組織のエンティティ内でユーザーに付与するアクセス許可レベルが決まります。 セキュリティ ロールは、ユーザーまたはチームに割り当てることができます。 セキュリティ ロールによって、ユーザーがアクセスできるエンティティ、作業ができるテーブル内のレコード、およびそれらのレコードに対するアクセス許可が決定されます。
セキュリティ ロールがユーザーまたはチームに割り当てられると、セキュリティ ロールは常にユーザーまたはチームの事業単位の範囲内で適用されます。 したがって、ユーザーがセキュリティ ロールをチームから継承した場合、そのセキュリティ ロールによって付与される権限は、ユーザーではなくチームの事業単位の範囲内に適用されます。 この方法は、ユーザーのアクセス権の範囲を追加の事業単位に拡張する場合に役立ちます。 たとえば、前の事業単位図では、シカゴ オフィスの事業単位のユーザーは、アトランタ オフィスの事業単位に関連付けられているチームに追加でき、その事業単位のレコードを読み取る権限をユーザーに付与することができます。
チーム
チームはユーザーをグループ化するもう 1 つの方法であり、セキュリティ戦略における役割を果たします。 Dynamics 365 では、次のようないくつかの種類のチームを使用することができます。
所有者チームには、セキュリティ ロールを割り当てることができ、Dynamics 365 のレコードの所有者として使用できます。 所有者チームのメンバーとしてユーザーが追加された際、チームのセキュリティ ロールから継承されますが、そのロールはチームの事業単位のコンテキストで適用されます。 所有者チームは、レコードを特定の事業単位にリンクする場合に便利です。
Microsoft Entra ID セキュリティ グループ チームは、オーナー チームに似ていますが、Microsoft Entra ID セキュリティ グループがリンクされています。 Dynamics 365 ライセンスを持つ Microsoft Entra ID セキュリティ グループに追加されたユーザーは、システム内で自動的に有効になり、ユーザーがその環境に接続すると、リンクされた Dynamics 365 チームに追加されます。 ユーザーは Dynamics 365 チームに割り当てられているセキュリティ ロールを継承できるようになるため、この機能は、Dynamics 365 外部のユーザー アクセス権を管理するために役立ちます。
Microsoft Entra ID オフィス グループ チームは、Microsoft Entra ID セキュリティ グループ チームと似ていますが、Microsoft Entra ID セキュリティ グループではなく Office 365 グループを使用します。 主な違いは、Office 365 グループの作成ができることと、Active Directory の管理者ではないユーザーがグループ管理を実行できることです。
アクセス チームは、レコードを所有できず、セキュリティ ロールを関連付けることができない特別なチームです。 ただし、所有者チームと同様に、アクセス チームはレコードを共有することができます。 テーブル レベルで有効にすると、アクセス チームは、レコードのアクセス チームのメンバーに対して特定のレコード レベルのアクセス許可を付与できます。 このオプションは、ユーザーまたはチームとレコードを手動で共有する代替方法です。 アクセス チームに構成されているエンティティの場合、これらのチームの作成は、アクセス チーム テンプレートを使用して自動化されます。
(Azure AD セキュリティ グループ チームまたは Microsoft Entra ID オフィス グループ チームを含む) 所有者チームにセキュリティ ロールを割り当てる際は、そのメンバーの権限継承が正しく設定されていることを確認する必要があります。 この設定によって、チームのメンバーであるユーザーは、セキュリティ ロールが直接割り当てられているかのように、ユーザーレベルの権限を継承することができます。 この機能は、ユーザーが自分に直接割り当てられたセキュリティ ロールを持たない場合でも、ユーザーがレコードを所有する上で役立ちます。 たとえば、この設定を使用すると、ユーザーは自分の個人用ビューを所有できます。 所有者チームを使用すると、セキュリティ ロールを個々のユーザーに直接付与する必要がなく、管理作業を軽減できます。
階層セキュリティ
階層セキュリティを使用すると、ユーザー所有のレコードを、そのユーザーの管理および階層の上位レベルに表示することができます。 たとえば、5 人のチームを管理する営業マネージャーは、自分のチームのメンバーが所有しているレコードを表示する必要があり、階層セキュリティは、そのアクセスを提供します。 階層セキュリティは、2 つの異なる階層モデルをサポートします。
マネージャー階層 - マネージャーのリレーションシップに基づいてアクセスが許可されます。 マネージャー階層のセキュリティ モデルでは、ユーザーまたはそのユーザーが所属するチームによって所有されているレコードにアクセスでき、ユーザーまたはユーザーが所属するチームが直接共有しているレコードにもアクセスすることができます。
職位階層 - 定義可能な職位レベルに基づいてアクセスを許可します。 このモデルは、間接的なレポート構造に基づいてセキュリティ アクセスを提供する必要がある場合に使用すると便利です。 職位階層のセキュリティ モデルでは、上位レベルに属するユーザーは、下位レベルのユーザーまたは下位レベルのユーザーが所属するチームによって所有されているレコードにアクセスでき、ユーザーまたはユーザーが所属するチームが直接共有しているレコードにもアクセスできます。
フィールド セキュリティ
フィールド セキュリティを使用すると、フィールド レベルでデータを保護することができ、たとえば、あるユーザーがレコードを表示または編集する必要がある場合でも、特定の詳細を非表示にすることができます。 この機能は、データがプラットフォーム レイヤーで保護されており、データを厳密に保護する必要がある場合に重要です。 つまり、ユーザーがモデル駆動型アプリやキャンバス アプリにログインするか、データを Microsoft Excel にエクスポートするか、またはレポートを実行するかに関係なく、フィールド セキュリティ プロファイルはデータを保護します。
フィールド セキュリティ プロファイルを使用して、セキュリティで保護された一連のフィールドへのアクセスをユーザーに許可すると (たとえば読み取り)、そのユーザーは、セキュリティ構成または共有によってアクセス権を付与された、すべてのレコードのこれらのフィールドへのアクセスを許可されます。
共有
共有では、特定のユーザーおよびチームに対して特定のレコード レベルのアクセス権を付与できます。 共有は、できるだけ例外を処理する目的に制限する必要があります。 以前は、複雑なレコード アクセス シナリオでは、レコードの共有を使用して自動化するのが一般的でした。 共有は、管理者とユーザーに適切なアクセス許可を付与し、特定のレコードへの特定のアクセス許可を付与する機能を提供するため、ルールの例外を処理するための優れた機能となりえます。 たとえば、営業担当者 B が 1 か月不在になる間、営業担当者 A が営業担当者 B のアカウントを処理する必要がある場合、共有を使用してこれに対応することができます。 また、共有を自動化することもできます。たとえば、ユーザーまたはチームに自動でレコードを共有する特定の状況がある場合、シンプルなプラグイン、ワークフロー アセンブリ、ETL ツールなどを使用することができます。 この機能は、多くの Dynamics 365 の顧客によって、セキュリティ上の要件の課題を解決するために使用されてきました。
共有は便利な機能ですが、次のような複数の潜在的な問題を生み出します。
パフォーマンス - 共有は、principal object access (POA) テーブルによって促進されます。 ユーザーまたはチームとレコードを共有すると、POA テーブルに、ユーザーの ID、レコードの ID、およびアクセス許可を含むレコードが作成されます。 共有が持つカスケードの性質は、共有が有効になっている親または構成可能なカスケード リレーションシップが既存する場合、これらリレーションシップに属する子レコードも、ユーザーまたはチームと共有されることを意味します (つまりより多くのレコードが POA に追加されます)。 また、複雑なリペアレントや継承共有のシナリオも、POA テーブルが急速に増大する原因となります。 テーブルが大きくなる場合 (2000 万レコードと 20 億レコードの間) 、パフォーマンスの問題が生じます。 ビューを開く、高度な検索、またはグラフを表示する際など、Dynamics 365 にクエリを実行すると、POA テーブルによって結果がフィルター処理されます。 テーブルが大きい場合や、インデックスが最適化されていない場合、システムのパフォーマンスが大幅に低下する可能性があります。
管理上の課題 - ユーザーによって共有されているレコードは、簡単に識別することができません。 レコードを選択して、そのレコードがどのユーザーと直接共有されているかを確認する方法は存在しません。 また、レコードの共有ダイアログには、カスケードまたは継承された共有は表示されません。 そのユーザーのコンテキストで各レコードを開かないかぎり、共有戦略が正しく機能しているかどうかを把握することはほぼ不可能です。
忘れられた共有 - 1 か月の不在中に同僚のアカウントを処理するために、営業担当者 A と営業担当者 B のレコードを共有するシナリオについて説明しました。 管理者は、それらのレコードの共有を停止することを忘れることがあり、営業担当者 B がワークフロー内のユーザーに再度接続する際に、問題が発生する可能性があります。
正しく実行できない - 顧客がシステムを 1、2 年使用した後に、システムが正しく機能しない、または最新の状態でないことに気がつくことがあります。 また、共有戦略に大幅な変更を加え、適切な共有へのアクセス許可を用いてすべてのレコードを設定し更新するためのバッチ ジョブを実行する場合があります。 共有を使用している場合、このタスクを実行する簡単な方法はありません。
共有に代わる方法
共有に関する問題を回避するための手順は次のとおりです。
チームの所有権を使用する - チームの所有権を使用すると、複数の事業単位のユーザー チームにレコードを割り当てることができます。
チームと共有し、ユーザーとは共有しない - 10 人のユーザーとレコードを共有する場合、共有レコードをカスケードする子ごとに 10 個の POA レコードに 10 個の POA レコードを掛けたものが作成されます。 10 人のユーザーを含むチームでレコードを共有する場合、1 つの POA レコードのみが作成されます (各カスケード共有に対して 1 つの POA レコードと併せて)。 こうすることで、POA テーブルのサイズが大幅に減少します。 ユーザーのアクセス許可を削除する場合は、チームからユーザーを削除できます。
共有を制御するためにアクセス チームを使用する - 所有者チームを使用することはできない場合に、特定のユーザーに特定のレコードへの一時アクセスを許可する必要がある場合は、この方法を使用します。 このシナリオでは、特定のユーザーにレコードの読み取りまたは書き込みのみのアクセス許可を付与し、他のユーザーにはレコードの読み取りおよび書き込みのアクセス許可を付与します。 アクセス チームはこの状況に対応することができ、1 つは読み取り用、もう 1 つは読み取りと書き込み用といった複数のアクセス チーム テンプレートを作成できます。 アクセス チームは、パフォーマンスを考慮して設計されているため、チームの最初のメンバーを追加するまで、実際にはチームを作成してレコードを共有することはありません。 レコードがアクセス チームで共有されている場合は、レコードが POA テーブルにも作成されます。
セキュリティ シナリオの例
次のシナリオで、これらのツールを組み合わせて、包括的なセキュリティ モデルを実現する方法を説明します。 この例の Contoso LTD は消費者向け製品の会社で、機密データを保護しながら、作業に必要な情報にユーザーが確実にアクセスできるようにしたいと考えています。 Dynamics 365 のセキュリティ ツールを組み合わせることで、この会社はこれらのシナリオに対処することができます。
Bob
フィールド レベル セキュリティを使用して、Bob がレコードの機密情報を表示できないようにし、チームまたは事業単位のセキュリティを使用して、Bob のビューを会社の問題だけに制限します。
製造技術者
クライアントによって報告された品質の問題を閲覧する必要がある
クライアントのメールや携帯電話は非表示にする必要がある
他の会社の問題を表示することを制限する必要がある
Amy
事業単位のセキュリティを使用すると、Amy は、自分が所属する部署のユーザーが所有するレコードを表示することができますが、他の部署のレコードを表示したり編集したりすることはできません。
顧客サービス担当者
使用に関する苦情から顧客サービス サポート案件を作成する
自分の部門の製品を使用しているクライアントの顧客情報やサポート案件の履歴を閲覧する必要がある
他部門の顧客データは閲覧できないようにする必要がある
Roy
階層セキュリティを使用すると、Roy は自分の直接または間接の部下によって所有されているレコードを閲覧できますが、他のユーザーが所有するレコードは閲覧できません。
営業マネージャー
自分の直属の部下のレコードを閲覧する必要がある
他の営業マネージャーのデータは閲覧できないようにする必要がある
Linda
Linda のセキュリティ ロールでは、Dynamics 365 の組織全体のデータを表示することができます。
ジェネラル マネージャー
顧客データとそれに関連するすべての問題を閲覧する必要がある
セキュリティ モデル ワークショップ
セキュリティ モデル ワークショップは、約 1 時間に制限し、全員がオンサイトで参加できない場合、Microsoft Teams ミーティングの一環としてしばしば実施されます。 参加者には、顧客およびパートナー チームからの主要な関係者を含める必要があります。 ソリューション アーキテクト、機能リーダー、および技術リーダーの参加は必須です。
セキュリティ モデル ワークショップの準備として、ソリューション ブループリント ワークショップ テンプレートからセキュリティの詳細を参照してください。