セキュリティワークショップのトピック

50 分

このユニットでは、セキュリティモデルのワークショップに含めることが推奨されるトピックに焦点を当てます。

セキュリティモデルの概要

テンプレートのセキュリティモデルの概要セクションには、出席者のセキュリティモデルに関する大まかな概要を示す必要があります。テンプレートの後方で特定の領域について詳しく説明するため、詳細をあまり細かくする必要はありません。

次に、どのようにしてレコードへのアクセスを管理するかという質問に答えます。この情報は、データに固有の制限 (たとえば、営業担当者が自分の顧客データのみを表示できるようにする場合) や、セキュリティモデルに影響するその他の特殊なデータアクセス情報があるかどうかを把握するのに役立ちます。加えて、このセクションには、システムデータにアクセスするために多要素認証を必須とするなど、技術的な詳細も含めることができます。

基本

テンプレートの 2 つのスライドでは、セキュリティモデルに関する基本情報について説明します。これらのスライドには、次の質問が含まれています。

ユーザー数 (あるいはターゲットとするユーザー数) は何人ですか? - ユーザー数は、セキュリティモデルのスケーラビリティに大きく影響します。たとえば、顧客がアクセスを提供するためにレコードの共有に依存している場合、多数のユーザー間で多数のレコードを共有することにより、潜在的なパフォーマンスへの影響を把握する必要があります。一部のセキュリティモデルは、ユーザー数が少ない場合に適しているため、ユーザー数の増加に応じて不適切になります。そのため、現在および将来のユーザーの成長を考慮することが重要となります。
モデルで一意のセキュリティパターンまたは構成をいくつ所有していますか、また、各パターン構成に含まれるユーザー数はいくつですか? - セキュリティパターンとは、顧客が要求に応えるために実装するさまざまなセキュリティ構成を指しています。たとえば、営業部門の担当者はユーザーセキュリティロールの標準使用を使用し、顧客サービスの担当者はユーザーロールとマネージャー階層の組み合わせを使用します。マーケティングの担当者は、アクセスチームのみを使用します。予想されるパターン数を決定することにより、セキュリティモデルが過度に複雑であるか、長期的な管理が困難であるかどうかを特定します。
他のユーザーと比べて、セキュリティ要件が複雑になる可能性があるユーザーの割合は何ですか? - 顧客が標準プロセスに対する特定分野の例外についてデザインすることにより、セキュリティモデルが過剰に複雑化することがあります。さまざまな非標準の要件が存在することを特定した場合は、要件を検討し、メインプロセスでの標準化を推奨する必要があります。
データへのアクセスを制限またはデータへのアクセスをフィルター処理する必要がありますか? - この質問では、コンビニエンスフィルターと実際のセキュリティ要件を区別します。ユーザーにとって最も重要なデータを簡単に表示できるようにすることをお勧めします。ただし、セキュリティはこの目標を達成するために使用するべきではありません。使用可能な他のレコードへのアクセスを残しながら、ビューを使用してデータをフィルター処理します。
必要なセキュリティロールの数はいくつですか? - セキュリティロールの数を最小限に抑えることで、管理タスクを行いやすくなります。 Dynamics 365 には、営業マネージャー、顧客サービス担当者、システム管理者などの標準ユーザータイプに対する多くの標準セキュリティロールが含まれています。これらのロールは、顧客のセキュリティロールの基礎として使用する必要があります。

要件が標準のロールと異なる場合は、標準のロールのコピーを作成し、それらを繰り返して処理することを検討してください。
既存のセキュリティロールをカスタマイズする代わりに、新しいセキュリティロールを作成しましたか? - 推奨されるベストプラクティスとして、新しいロールを作成するのではなく、標準セキュリティロールのコピーを保存することをお勧めします。

セキュリティロールには、アプリケーションにアクセスするために必要な多くのアクセス許可が含まれています。新しいロールを作成すると、顧客が一部の必要な基本アクセス許可を保持できない可能性があるため、問題が発生します。

通常のアプリケーション更新を使用すると、多くの場合は標準セキュリティロールに新しいアクセス許可が追加され、既存のカスタムセキュリティロールには自動的に追加されないことを顧客に通知します。カスタムセキュリティロールを使用する場合は、新たに追加されたアクセス許可を識別し、各更新の後でカスタムセキュリティロールを更新して、システムアクセスの継続性を確保する人物が必要です。
セキュリティロールの数を可能な限り減らしてみましたか? - Dynamics 365 の展開で使用されるセキュリティロールの数が多いほど、長期の管理がより困難になります。新しい機能が追加されたときに、25 の個別のセキュリティロールが使用可能であり、すべてのユーザーがその機能を必要とする場合は、新しい機能へのアクセスを提供するために、メーカーが 25 のセキュリティロールを更新する必要があります。

基本的なロールを利用して、アプリケーションにサインインするために必要な機能のベースラインを提供し、すべてのユーザーが使用できるすべてのテーブルを活用する戦略が一般的です。次に、そのロールに必要なロール固有の機能を備えた追加のロールでそのロールを補完します。

たとえば、すべてのユーザーがアカウントを読み取る必要があるが、営業マネージャーのみが新しいアカウントを作成できるようにする場合は、基本ロールに組織レベルのアカウントの読み取りアクセス許可を含めます。また、営業マネージャーロールには、アカウントの作成アクセス許可のみが含まれます。その後、すべてのユーザーに必要な新しい機能が追加されている場合は、基本ロールにのみ追加できます。
個々のユーザーが必要とするセキュリティロールの数はいくつですか? - 個々のユーザーに追加する必要があるセキュリティロールの数が増えるほど、ユーザーのオンボードが複雑になり、より多くの人が間違いを犯す可能性が高くなります。必要なロールが多数存在する場合は、これらのロールを統合して、継続的な管理を容易にする必要があります。

この他にも、Microsoft Entra ID セキュリティグループまたは Microsoft Entra ID オフィスグループチームを活用して、ロールを 1 回チームに付与することができ、その後、該当する Microsoft Entra ID グループに追加されたチームのロール (チームの事業単位のコンテキスト) が自動的にユーザーに引き継ぐという方法もあります。
ルート事業単位レベルまたは子レベルで作成されたセキュリティロールはありますか? - 1 つの下位の部署に固有のロールを作成することもできますが、ルート事業単位レベルでセキュリティロールを作成および編集することをお勧めします。

ルート事業単位レベルでロールを作成すると、ロールはすべての事業単位で使用できるようになります。一方、子レベルのロールは、1 つの事業単位レベルでのみ使用できます。事業単位固有のロールがある場合、ユーザーを別の事業単位に移動すると、そのロールは使用できなくなります。そうでないと、別の事業単位の同じロールの異なるバージョンになり、システムの管理が困難になります。
どのような戦略を使用して、新しいテーブルおよび機能をロールアウトしたときにセキュリティロールを更新しますか? - 絶え間なく開発が行われる、急速に変化する環境では、ロールを更新したり、システム管理者のアクセス権でテストのみを実行したり、新しい機能を含めるためのセキュリティロールの更新を忘れたりすることがあります。顧客の戦略には、構成リリースがロールアウトされるたびに、セキュリティロールを更新し、各ペルソナのロールミックスをテストするプロセスが含まれている必要があります。

この情報を求める理由

出席者にあらかじめ情報を求める必要がある理由は次のとおりです。

1 つのセキュリティパターンが、すべてのユーザーのニーズとロールに対して適していることはまれです。プロジェクトに実装するために必要となるパターンの数を把握しておく必要があります。
多くの場合、複雑なセキュリティモデルは、メインモデルに該当しないわずかなユーザーのニーズに対応するように設計されています。その場合、ユーザーが別の方法や、レポートなどの別の場所で目的のデータにアクセスすることができなかった場合、問題が発生する可能性があります。

事業単位

このセクションでは、顧客の内部組織の階層構造と Dynamics 365 の事業単位構造について説明します。事業単位構造と組織構造の間にはある程度のリレーションシップがありますが、事業単位構造は組織構造ほど詳細にする必要はありません。 2 つのグループが会社の異なる部門に存在していても、2 つのグループ間のレコードの可視性を制限する必要があるわけではありません。多くの場合、複数の部門が同じ事業単位を共有できます。

Microsoft Visio やその他のビジュアルダイアグラム/グラフアプリケーションのツールを使用して、構造のビジュアル化表現を作成します。会社の組織階層をビジュアル化するドキュメントが既にある場合は、その図のスクリーンショットをドキュメントに貼り付けることができます。

事業単位が多すぎるか、または十分な事業単位がないという 2 つの潜在的な問題に注意してください。

事業単位が多すぎる

提案されたセキュリティモデルで、事業単位が数百または数千になることが示されている場合は、リスクとして問題にフラグを付ける必要があります。事業単位は、大きなグラナイトの岩のようです。永久的で、ほとんど移動することはないように設計されています。ユーザーは事業単位間を移動できますが、特に多数のレコードを所有している場合は、それは簡単ではありません。

事業単位 1 から事業単位 2 にユーザーを移動すると、ユーザーが所有している各レコードの事業単位のアソシエーションが変更されます。そのため、事業単位レベルの読み取りアクセス許可が与えられている場合は、そのユーザーの元の事業単位に属している他のユーザーにとって予期しない状況が発生する可能性があります。移動したユーザーによって所有されているレコードは使用できなくなりますが、活動など、それらのレコードの子レコードを所有している場合は、特殊なシナリオが発生する可能性があります。また、ユーザーが多数のレコードを所有している場合は、ユーザーを事業単位間で移動するのに時間がかかることがあります。

多くの事業単位に対するもう 1 つの潜在的な影響として、非常に遅いセキュリティロール更新があります。各ロールのレコードは 1 つだけではありません。各ロールのコピーが各事業単位に追加されます。したがって、多数の事業単位を作成した場合、1 つのセキュリティロールに小さな変更を加えるにも数時間かかることがあります。

事業単位の数を最小限に抑えることをお勧めします。実際の事業単位のセキュリティ要件を容易にするために、最小の数の事業単位のみを使用します。ユーザー区分をより細分化するために、チームの使用を検討します。チームの方が柔軟であるため、レコードへのセキュリティアクセスの管理に使用でき、ユーザーは複数のチームのメンバーになることができます。

不十分な数の事業単位

単一のグループに対して実装している場合は、すべてのユーザーに対してルート事業単位のみを使用するのが一般的です。

「シンプルにしておく」というアプローチは非常に優れていますが、顧客がユーザーのサブセットから隠しておきたいデータがある時点で存在する可能性が高くなります。

次のシナリオを検討してください。

Dynamics 365 の使用を会社の他の部分に広げます。
大規模な多国籍企業により会社が買収されます。
CEO は、メールを追跡することを決定し、全員に読んでほしいわけではありません。
営業部門の VP は、Dynamics 365 になくてはならないが、会社の他の部分に公開しないことが望ましい連絡先がアドレス帳に複数あることを発見します。

事業単位間のユーザーの移動は困難であるため、必要な場合にのみ行う必要があるプロセスです。顧客が、基本事業単位のすべてのユーザーから開始し、変更が大きくなってデータのサブセットを分離しなければならなくなった場合、ルート事業単位のリペアレントを実行できないため、既存のユーザーの多くまたはすべてを再配置する必要が生じます。

この偶発性を防ぐには、最初に 1 つの下位の部署を作成し、その事業単位にすべてのユーザーを配置することをお勧めします。業務上の変更によってデータの細分化が必要になった場合は、多数のユーザーを含む事業単位のリペアレントを実行したり、CEO のような、選択したユーザーを基本事業単位に移動したりすることができるため、このアプローチによって変更を簡単にすることができます。すべてのユーザーの全面的な事業単位の移動を回避することができます。

チーム

セキュリティモデルテンプレートの [チーム] セクションでは、Dynamics 365 のセキュリティに関するチームレコードの予定使用に関する詳細が取得されます。

このセクションでは、次の質問に対して回答します。

ユーザーにロールを割り当てるために、所有者チームを使用していますか? - 所有者チーム (Microsoft Entra ID セキュリティグループと Microsoft Entra ID オフィスグループチームを含む) は、セキュリティロールをユーザーに割り当て、管理作業を軽減するための優れた手段です。セキュリティロールをチームに割り当てると、そのロールはメンバーユーザーに継承されますが、チームの事業単位のスコープ内で適用されます。
所有者チームを使用してレコードを所有していますか? - チームのレコードの所有権は、標準の所有ユーザーの事業単位とは別の事業単位とのレコードのアソシエーションを管理するものであると見なすことができます。このアプローチは、レコードおよび事業単位の機能的なアソシエーションが、事業単位とのユーザーのアソシエーションが異なる場合に役立ちます。

注意する必要のあるチームのレコードの所有権には、マイナス面とリスクがいくつかあります。一般に、一貫して使いやすいように自動化が必要です。目標や予測などの一部の機能は、ユーザーによるレコードの所有権に依存しています。また、ユーザーのレコードを一括して再割り当てする機能 (たとえば、新しい営業担当者が退職する営業担当者に代わり、顧客ポートフォリオを継承する場合など) を所有者チームは使用できません。

レコードのチーム所有権を使用すると、複雑なセキュリティモデルを簡素化し、レコードを過度に共有する必要性を減らすことができます。所有者チームのロールは、チームによって所有されるレコードのコンテキストで、特別なセキュリティアクセス許可を付与します。したがって、営業チームのメンバーが、関連付けられている営業案件を編集する権限を持っている必要がある場合、関連付けられていない営業案件は読み取り専用であるため、所有者セキュリティチームは、複雑な共有を使用しなくても、この例外を有効にすることができます。
レコードの割り当てとその方法を自動化しますか? - 新しいアカウントが作成されるとき、どのようにレコードを割り当てるかを決定する必要があります。さらに、営業コーディネーターが確実に手動でレコードを正確に割り当てられるかどうかを考慮する必要があります。重要なレコードのタイプ (アカウントなど) については、システムの継続的な管理を簡略化するために作成されたときに自動的に割り当てられる自動プロセスを用意することをお勧めします。あるアプローチでは、Dynamics 365 の担当地域レコードの都道府県ごとに営業担当者の割り当てを保存することができます。次に、新しいアカウントが作成されると、Microsoft Power Automate フローが実行されます。これは、住所の都道府県 1 を [担当地域の状態] フィールドと比較し、適切な担当地域と営業担当者に割り当ててから、新しい見込み顧客に連絡するように通知するメールを営業担当者に送信します。
アクセスチーム (システムまたは手動で管理) を使用していますか。 - アクセスチームは、特殊なレコードのアクセス許可を管理するための優れたソリューションです。たとえば、営業アシスタントが 25 個の異なるアカウントで編集のアクセス許可を持っている必要がある場合、手動でアカウントを共有するのではなく、レコードのアクセスチームサブグリッドに追加すれば、グリッドに関連付けられているアクセスチームテンプレートに基づいて編集のアクセス許可が継承されます。レコードの共有のようにユーザーごとに個々のレコードではなく、アクセスチーム全体に対して POA テーブルに作成される共有レコードは 1 つだけであるため、アクセスチームは非常に優れたソリューションです (このモジュールの前の「共有」セクションを参照してください)。このアプローチにより、管理者は、レコードにアクセスできるユーザーを確認することができます。

同じグループが複数のレコードにアクセスする必要がある場合は、アクセスチームを使用してそのチームとレコードを共有することもできますが、アクセスチームはレコードを所有することはできないため、セキュリティロールを割り当てることはできないことに注意してください。
アクセスチームのメンバーシップを自動化しますか? - レコードにアクセスする必要があるユーザーをマトリックスにするのが一般的です。たとえば、1 つの製造プロジェクトにはエンジニア、電気技師、およびセイフティエンジニアが必要です。多くの場合、これらの割り当ては別のシステムで維持されます。

この場合、個々の従業員の組み合わせはレコードごとに異なり、チームのメンバーに対してセキュリティアクセス権を必要とするため、アクセスチームを使用する必要があります。統合、アクション、プラグインなどのアプローチを使用して、アクセスチームメンバーシップを自動化できます。
どのように環境全体にアクセスチームテンプレートを展開しますか? - チームレコードのアクセス許可は、アクセスチームテンプレートによって設定されます。テンプレートによって、チームのメンバーと共有されるアクセス許可が決まります。

問題点は、ソリューションがアクセスチームテンプレートレコードを認識していない、つまりソリューションに追加できないということです。カスタマイズを環境間で移動する場合は、アクセスチームテンプレートを移動するか、ターゲット環境で手動で再作成する必要があります。アクセスチームのメンバーシップを自動化している場合、テンプレートは、ロジックで参照されているため、環境全体で同じ GUID を使用する必要があります。

アクセスチームテンプレート (構成データ移行ユーティリティ、Scribe や SSIS などの ETL ツール、または XrmToolBox のユーティリティを含む) を移行するためのアプローチは複数あります。
Microsoft Entra ID の同期化グループを使用して、アクセス権限を管理しますか? - Microsoft Entra ID セキュリティグループチームまたは Microsoft Entra ID オフィスグループチームは、ユーザーに対するロールアクセス許可の割り当てを自動化するのに優れており、大規模で複雑な展開にも考慮する必要があります。

Microsoft Entra ID を使用すると、アクセス許可を 1 つのソースから完全に制御できます。
標準モデルに適合しない要件がありますか? - 標準以外のセキュリティ要件を特定します。調査結果およびレコメンデーションセクションでは、非標準の要件を標準化するための推奨方法について説明します。

実装されたセキュリティメカニズム

このセクションでは、自動化された共有、フィールドレベルのセキュリティ、階層のセキュリティ、プラグイン、およびリレーションシップの動作を含む、セキュリティの自動化に使用する方法を特定します。これらの方法に慣れていない場合は、このモジュールの「セキュリティツール」セクションを参照してください。

この情報を提供する理由は次のとおりです。

共有を大規模に自動化すると、パフォーマンス上の問題が発生する場合があります。 PrincipalObjectAccess または POA テーブルは、標準セキュリティモデルの例外とともに入力されます。
共有は、通常は、例外を所定のセキュリティモデルに付与するために手動プロセスのままにしておき、大きな規模では回避する必要があります。
ユーザーの事業単位、チーム、およびロールは簡単に調整できますが、組織の再編成後にカスタムの共有ルールでデータ移行を行うことは複雑になる場合があります。
フィールドレベルのセキュリティは、ユーザーまたは事業単位を認識していません。
階層の深さのレベルが多すぎる場合、階層セキュリティにより、複雑な構成でパフォーマンスの問題が発生する可能性があります。
リレーションシップのカスケード動作は便利ですが、予期しない結果 (アカウントが再割り当てされたときにクローズした活動を再割り当てする場合など) が生じることがあります。カスケード割り当てまたは共有は、リレーションシップベースまたは ORG DB 設定 DisableImplicitSharingOfCommunicationActivities を使用して無効にしたり変更したりできます。

ユーザーインターフェイス

Dynamics 365 の多くのコンポーネントは、セキュリティロールが有効になっており、その品目へのアクセスを 1 つ以上のセキュリティロールに制限できます。さまざまなユーザーが共通のテーブルを使用する際にさまざまなエクスペリエンスを必要とするため、この機能は重要です。ユーザーが必要としないアプリコンポーネントへのアクセスを制限することにより、より簡単で、よりカスタマイズされたエクスペリエンスをユーザーに提供することができます。

ロールが有効な Dynamics 365 の品目には、次のようなものがあります。

モデル駆動型アプリ
ダッシュボード
フォーム
ビジネスプロセスフロー
サイトマップサブ領域
コマンドバーボタン
ドキュメントテンプレート

テンプレートのこのセクションでは、これらの領域へのアクセスを簡略化するためにロールが使用されているかどうかを特定します。

この情報を提供する理由は次のとおりです。

セキュリティロールとテーブルの特権を使用して、ユーザーのエクスペリエンスを調整したり、トリミングしたりすることができます。
そのユーザーに対して表示される要素が少ないほど、エクスペリエンスがより簡単になります。
モデル駆動型アプリをセキュリティロールに関連付けることができ、ビュー、グラフ、ダッシュボード、フォーム、およびビジネスプロセスフローの一覧をトリミングすることにより、全体的なユーザーエクスペリエンスを簡素化することができます。
この領域に戦略がない顧客については、予期しない問題が発生することがあります。たとえば、営業ハブ、顧客サービスハブ、App for Outlook などのアプリアクセスセキュリティロールを使用してアクセスを制御するための一般的な Microsoft アプリ。顧客がシステム管理者ロールのみを使用してテストした場合、このロールを持たないユーザーは、アプリを使用するためにアプリアクセスロールを必要とする (またはアプリをカスタムセキュリティロールで共有する必要がある) ということに気づかない可能性があります。このシナリオにより、ユーザーは展開時に必要なアプリにアクセスできなくなる可能性があります。

スケーラビリティ、パフォーマンスとメインテナンス性

テンプレートのこのセクションでは、アプリケーションをさらにユーザーに拡大してデータ量が増加した場合に問題が発生する可能性があるかどうかを特定するための質問を分析します。

メンテナンスに関する質問とそれが重要な理由

テンプレートで次のメンテナンスの質問に回答します。

ユーザーまたはチームがレコードを所有している必要がないというシナリオを特定しましたか? - 会社間参照データを表す新しいテーブルを作成し、事業単位、チーム、またはユーザーごとに細分化する必要がない場合、組織所有のテーブルとして作成することを検討してください。

レコードの所有権は、変数の可視性または編集のアクセス許可を異なるユーザーに与える必要がある場合に重要です。ただし、すべてのユーザーに対して表示する必要のある一般レコードが存在し、すべてのユーザーが同じレベルの編集アクセス許可 (統合を使用して生成されたレコードなど) を共有している場合は、従業員の退職時にこれらのレコードを再割り当てする必要がないように、事業単位チームへのレコードの割り当てなどの戦略を考慮する必要があります。
より大きな容量でのセキュリティ設計における潜在的なスケーラビリティの問題を特定しましたか? - レコードを共有する方法は小規模な展開でも十分に機能しますが、多数のユーザーにスケールアップするとすぐに効率が悪くなる可能性があります。

また、ユーザーを多数の事業単位の数千ものチームのメンバーすると、パフォーマンスとスケーラビリティの点から大きな課題となる可能性があります。
データおよびセキュリティモデルが POA テーブルに与える影響を検討しましたか? - 過剰な共有は、大きな POA テーブルにつながり、システムのパフォーマンスが低下する可能性があります。
ユーザー、チーム、または事業単位のレコードを定期的に更新していますか? - 原則として、ユーザー、チーム、または事業単位テーブルに対する定期的な更新を回避する必要があります。たとえば、ユーザーテーブルの属性を更新すると、セキュリティキャッシュがフラッシュして、パフォーマンスに影響を与える可能性があります。
ユーザー、チーム、事業単位、およびレコードに対する大規模な再編成の影響を検討しましたか? - ビジネスの構造は変化します。新しい会社が買収され、部門が売却され、従業員は退職または他の部署に異動します。セキュリティモデルを完全に設計し直すことなく、ユーザー、チーム、または事業単位を簡単に追加したり削除したりできるように、構造を柔軟にする必要があります。
既に大量のレコードにアクセスしているユーザーに対して、グローバルアクセスを提供してパフォーマンスを向上させることを考慮しましたか? - レコードに対する組織/グローバル読み取りアクセスを提供することにより、レコードの取得時にシステムがユーザー (個々のロール、チームロール、共有レコード、階層) に適用されるセキュリティプリンシパルを考慮する必要がないので、ビューの実装のパフォーマンスを最適化することができます。

ユーザーは、セキュリティの観点からすべてのレコードにアクセスできる場合もありますが、レコード数をフィルター処理するシステムビューをカスタマイズして、作業に関連するものだけを表示する必要があります。
ユーザーの退職時にレコードを一括再割り当てしますか? カスケードリレーションシップの影響を考慮していますか? - 活動やその他の共通レコードに対するリレーションシップのカスケード設定により、レコードの再割り当て時に予期しない結果が生じることがあります。また、顧客アカウントと連絡先レコードを再割り当てするときに、終了した活動を再割り当てしない場合は、この動作を変更する必要があります。

セキュリティテスト

セキュリティモデルは連携して機能する複数の部分で構成されており、失敗する可能性のある領域が複数存在します。テンプレートのこのセクションでは、セキュリティのテストに使用するアプローチを確認し、Dynamics 365 へのアクセスを監視するための継続的な計画を特定します。また、セキュリティロールの設計を確実に文書化し、長期的に容易に管理できるようにします。

セキュリティに関する質問とそれが重要な理由

セキュリティモデルテンプレートの [セキュリティテスト] セクションで、次の質問に回答してください。

セキュリティ要件のコンテキストでデータを検証するためのテスト環境がありますか? - セキュリティロールを適切にテストするために、顧客は、実稼動と同じ構成の非実働環境と、実稼動データセットの近似値を必要とします。実稼動データの 100% が必要なわけではありませんが、データはセキュリティロールの動作を正確にテストするために十分に類似している必要があります。また、異なるテストユーザーを持つことや、ロールを同じテストユーザーに再割り当てしないことも重要です。もともと上位のアクセス許可を持つユーザーは、レコードの所有権または共有を使用してロールを削除しても、特定のレコードへのアクセスを保持できる場合があるためです。

企業や顧客によって定義されたアクセスレベルと特権を持つセキュリティマトリックスの Excel シートがありますか? 特定のユーザーが Dynamics 365 のセキュリティロールを変更し、その設計方法を忘れてしまった場合に備えて、Dynamics 365 セキュリティロールの外部にセキュリティ設計についてのドキュメントを保持することが重要です。このドキュメントは、テーブルごとに適切なアクセス許可レベルを示す Excel スプレッドシートにすることができます。
すべてのセキュリティロールにセキュリティマトリックスに関するテストケースがありますか? - 顧客のセキュリティ要件は、プロジェクトの以前のワークショップで収集された要件に基づいている可能性が高く、これらの要件によって、セキュリティテストケースの基礎が作成されます。各セキュリティ制限には、テストケースを作成し、本番運用の前に徹底的にテストする必要があります。その後、影響を受けるセキュリティロールまたはペルソナのコンテキストでテストする必要があります。
フィールドレベルのセキュリティフィールドとチームにおける否定的なテストを検討したことはありますか? - ロールを持つユーザーが、セキュリティで保護されたフィールドを参照できるか、チームに割り当てられているレコードにアクセスできるかをテストすることが重要です。また、これらのロールまたはチーム割り当てを持たないユーザーがこれらの品目にアクセスできないことを検証する必要もあります。
プラットフォームで侵入テストを実行しますか? - 高度にセキュリティ保護された環境では、侵入テストはオプションです。侵入テストについては、Microsoft Cloud の契約ルールに従う必要があります。詳細については、侵入テストの活動規則を参照してください。

その他の Dynamics 365 セキュリティに関する質問

セキュリティモデルテンプレートのこのセクションでは、Dynamics 365 内の関連する機能に関するセキュリティについて分析します。

Dynamics 365 のセキュリティに関する質問とそれが重要な理由

次の質問に回答します。

Excel へのエクスポート特権について検討しましたか? - Excelへのエクスポートは便利なレポート機能ですが、顧客によっては、従業員が会社から退職したときにクライアントデータを取得している場合もあるため、リスクになる可能性があります。

Excel へのエクスポート特権により、一部のユーザーが Dynamics 365 から簡単にデータをダウンロードすることを防ぐことができますが、Excel にエクスポート ボタンをクリックすると、レコードへの読み取りアクセス権を持つユーザーは、API を使用してそのデータにアクセスし、最終的にそれをエクスポートすることができることを認識しておくことが重要です。
必要に応じて、データエクスポートサービス、Azure SQL、または Data Lake へのエクスポートと Power BI のセキュリティをどのように管理するかを計画していますか? - レポートまたは統合のために Microsoft Dataverse からデータが離れると、Dynamics 365 のセキュリティで保護されなくなります。組織では、この特徴を認識して、データがシステムから離れた時点でセキュリティを計画する必要があります。
必要な場合、Power Pages と Unified Service Desk に対するセキュリティモデル戦略は何ですか? - Power Pages では、外部にデータを公開することができ、外部の関係者が Dynamics 365 データを更新することも許可できます。ただし、この機能によるセキュリティ上の影響を考慮して、安全で機密性の高いデータを間違ったユーザーに公開しないことが重要です。

ユーザーがチームから独占的にセキュリティロールを継承する場合、セキュリティロールで直接ユーザーへの継承 設定を使用することを考慮しましたか? 所有者チーム (Microsoft Entra ID セキュリティグループチームまたは Azure AD オフィスグループチームを含む) にセキュリティロールを割り当てるときは、そのメンバーの特権継承設定をオンにして、正しく設定されていることを確認する必要があります。この設定を使用すると、チームのメンバーであるユーザーは、セキュリティロールが直接割り当てられているかのように、ユーザーレベルの (事業単位レベルやそれ以上のレベルではない) 特権を継承することができます。

この機能は、ユーザーが自分に直接割り当てられたセキュリティロールを持っていない場合でも、ユーザーが名前でレコードを所有する上で役立ちます。たとえば、この設定を使用すると、ユーザーは自分の個人用ビューを所有できます。所有者チームを使用すると、セキュリティロールを個々のユーザーに直接付与する必要がなく、管理作業を軽減できます。
仮想テーブルの使用を計画している場合、その周辺のセキュリティモデルを作成することを検討しましたか? - 仮想テーブルを使用すると、Dataverse にデータを保存していないが、外部データソースにポイントするテーブルを作成できます。この機能は便利なことであり、多くの場合、データを使用して Dynamics 365 をオーバーロードするよりも好ましいことですが、仮想テーブル接続では単一のデータソースを使用するため、仮想テーブルにアクセスできるすべてのユーザーに同じレコードが表示されることを理解しておく必要があります。すべてのユーザーに対して表示する必要のない重要なレコードがある場合は、データ統合を行うことをお勧めします。

セキュリティの監視

テンプレートのこのセクションでは、適切なアクセス権を監視するための顧客の戦略を確認し、アプリケーションの誤用を特定します。 Dynamics 365 で活動監査が有効になっている場合、多くのユーザーの活動が Microsoft 365 管理センターに記録されます。これらのログを使用することで、次のような一般的なアクションを含む、システム内の異常な、または潜在的に悪意のある活動を特定できます。

カスタマイズを公開したユーザー
チームに追加されたユーザー
ソリューションを追加したユーザー
カスタマイズを公開したユーザー
Excel にエクスポートしたユーザー
レポートを表示したユーザー
レポートをエクスポートしたユーザー

標準監査ログは、ユーザーがいつシステムにアクセスしたかを監視します。 Microsoft Power Automate のようなツールでは、特定の活動が発生したときに警告が表示され、Microsoft Entra ID は、通常の地理的な地域以外のユーザーがシステムにアクセスしようとしたときに警告を表示できます。

セキュリティモデルワークショップテンプレートのこのセクションでは、異常な動作の監視と警告の方法と、Dynamics 365 のユーザーアクセス許可を定期的に検証するための計画についてを要約します。

規制およびコンプライアンス

テンプレートのこのセクションでは、Dynamics 365 のセキュリティモデルに影響を与える可能性がある政府規制またはコンプライアンスの規制があるかどうかを確認します。それらの規制には、HIPAA などの消費者データ保護規制、SEC、ビジネスのセグメント化などの監査の懸案事項が含まれます。規制とコンプライアンスに関するスライドの情報を完了します。

Dynamics 365 以外のセキュリティ

このテンプレートセクションでは、Dynamics 365 以外の Dynamics 365 に統合される他のシステムと、関連するセキュリティについて確認します。 Dynamics 365 は自律的ではなく、他のシステムが操作したり統合したりします。したがって、個々の要素のセキュリティだけでなく、総合的にセキュリティを把握することが重要です。 Dynamics 365 以外のセキュリティ スライドを更新して、次の質問に回答してください。

アクセス権を持つユーザーを制御するために、環境をセキュリティグループに関連付けたことがありますか? - Dynamics 365 環境を Microsoft Entra ID セキュリティグループに関連付けると、グループ外のユーザーの環境へのアクセスが制限され、システムで有効として表示されるユーザーが制限されます。また、ユーザーがアクセス可能な環境のみが [環境] リストに表示されるため、ユーザーのエクスペリエンスが簡素化されます。
ユーザーが Office 365/Dynamics 365 データにアクセスする方法を制御するために、Microsoft Entra ID の条件付きアクセスを使用しますか? - Microsoft Entra ID の条件付きアクセスを使用して、環境を使用できるデバイスの場所と種類、使用できるサービスおよびコネクタを制限することができます。
モバイルデバイス管理を使用して、さまざまなデバイス (携帯電話など) を管理していますか? - Microsoft Intune のようなモバイルデバイス管理 (MDM) ソリューションを使用すると、セキュリティを適用して Dynamics 365 モバイルアプリの展開をリモートで管理したり、デバイスの紛失または盗難の場合にデータをリモートから削除することもできます。
SharePoint と統合しますか? はいの場合、SharePoint のセキュリティと Dynamics 365 のセキュリティへの対処方法は何ですか? - SharePoint ドキュメントの統合により、Dynamics 365 レコードから SharePoint のドキュメントライブラリの作成が自動化され、Dynamics 365 ユーザーは、SharePoint に格納されているドキュメントにすばやくアクセスできるようになります。セキュリティが問題になるのは、SharePoint ドキュメントライブラリのセキュリティが Dynamics 365 セキュリティを反映していないためです。 Dynamics 365 ドキュメントが格納されている SharePoint サイトにアクセスできるユーザーがいる場合、関連する Dynamics 365 レコードへのアクセスがない場合でも、ライブラリ内のドキュメントを表示することができます。この状況が懸念事項である場合、SharePoint 側のアクセス権の範囲が狭くなる (たとえば、複数の SharePoint サイトを使用した OneDrive for Business 統合または Teams 統合) 別の方法を検討する必要があります。
Microsoft Power BI と統合しますか? はいの場合、Power BI のセキュリティと Dynamics 365 のセキュリティへの対処方法は何ですか? - Power BI が標準 Microsoft Dataverse コネクタを使用して Dataverse から直接レポートを作成すると、ユーザーがシステム内でアクセスできるデータだけが反映されます。ただし、その Power BI レポートが共有されている場合、そのレポートを共有している他のユーザーには、レポートの所有者のデータが表示されます。

行レベルのセキュリティを実装して、Power BI 側にセキュリティを適用することもできますが、接続したユーザーコンテキストに表示される Power BI の SQL DirectQuery レポートを作成するというオプションもあります。その場合、レポートを共有すると、実際のデータではなくデータの表示のみが共有され、Dynamics 365 セキュリティモデルは完全に適用されます。
他のセキュリティメカニズムを使用していますか? - 他のセキュリティメカニズムには、多要素認証、OKTA などの外部認証が含まれる場合があります。
セキュリティモデルには、独立系ソフトウェアベンダー (ISV) ソリューションへの依存関係がありますか? はいの場合は、それは何ですか? - ISV は、Dynamics 365 の展開を強化する重要なソリューションを提供しますが、セキュリティリスクや依存関係を招く可能性もあります。このソリューションをどのように展開するか、その更新方法、および ISV が必要とするセキュリティアクセスの種類について理解しておくことが重要です。
データ統合セキュリティパターンの要件は何ですか? - システム間でデータが流れるときは、フローレベルでセキュリティを制御する必要がある時期について理解しておくことが重要です。必ず、統合に必要なソースシステムに対するセキュリティアクセス、統合に必要な Dynamics 365 のセキュリティアクセス、および統合プロセスの実行に必要なアカウントを決定してください。統合アカウントのアクセスを制御するために、アプリケーション (非対話型) ユーザーを活用することをお勧めします。
Power Automate や Power Apps などの他の Microsoft Power Platform 機能を活用している場合は、セキュリティ要件やデザインは何ですか? - Power Apps および Power Automate は、コネクタを使用して数百の異なるシステムを統合し、これらのツールは Dynamics 365 と同じプラットフォームに含まれています。 Power Apps および Power Automate フロー内のキャンバスアプリは、Dynamics 365 と同様に Dataverse を使用し、ソリューション内の他の Dynamics 365 コンポーネントと共にアプリとフローを管理します。このプロセスにその他のコネクタを導入すると、それらのシステムにおけるデータアクセスとセキュリティ、実稼動 Dynamics 365 にタッチするアプリとフローの構築される場所など、他にもさまざまなセキュリティ上の考慮事項が発生します。セキュリティ上の考慮事項としては、実稼動 Dataverse 環境に接続しているメーカーに対するアクセス、一緒に使用できるコネクタを決定するデータ損失防止 (DLP) 規則などもあります。ソリューションアーキテクトは、Microsoft Power Platform 環境戦略と DLP 戦略について明確にするための質問をした後、そのユーザーに付与されるアプリとフローを作成するためのアクセス許可を特定する必要があります。
特定のインフラストラクチャのセキュリティ要件 (暗号化など) がありますか? - Dynamics 365 は、適格なシナリオの顧客管理キーなど、高度な暗号化オプションを備えています。これらのオプションが使用されているかどうか、およびこれらの方法を長期に維持するための戦略が顧客によって設定されているかどうかを確認します。

続行

セキュリティ ワークショップのトピック

セキュリティ モデルの概要

基本