このアーキテクチャ パターンは、Microsoft DataverseとSharePointの統合に関する一般的な課題に対処します。 Dataverse ではレコード レベルのセキュリティが適用されますが、これらのアクセス許可は、SharePointに格納されているドキュメントには自動的には適用されません。 このアーキテクチャ パターンでは、制限付きSharePointナビゲーションと制限付きドキュメントの検出可能性が使用されます。 これらのセーフガードにより、ユーザーはアプリケーション エクスペリエンスを通じてSharePointドキュメントを開き、過剰共有のリスクを軽減できます。
Tip
この記事では、ネイティブ SharePoint統合を使用するときに、ユーザーの Dataverse アクセス許可の外部にあるSharePoint ドキュメントへのアクセスを減らすシナリオの例と視覚的な表現を示します。 このソリューションは汎用的な例示アーキテクチャであるため、さまざまなシナリオや業界で使用可能です。 この記事は、ベスト プラクティスに特化しています。
アーキテクチャ ダイアグラム
Workflow
次のワークフローでは、このパターンがネイティブに統合されたSharePoint サイトへのアクセスを構造化および管理し、ドキュメント アクセスを Dataverse ロールベースのアクセス制御 (RBAC) とレコード レベルのエンタイトルメントとより適切に調整する方法について説明します。
このパターンでは、ナビゲーションを制限し、検出メカニズムを無効にすることで、承認されていない Dataverse レコードに関連付けられているドキュメントにユーザーがアクセスするリスクを大幅に軽減しながら、シームレスなアプリケーション内ドキュメント エクスペリエンスを維持します。
アクセスと環境を準備する
アクセス管理を構成する
現在、組織が Dataverse 環境と関連するSharePoint サイトへのアクセスを管理する方法を確認します。
Entra IDセキュリティ グループを使用して、Dataverse 環境および関連SharePointドキュメントへのアクセスを管理します。 詳細については、「Microsoft Entra グループとグループ メンバーシップの管理」を参照してください。
Dataverse 環境と SharePoint サイトを準備する
Dataverse 環境が適切なセキュリティ グループに制限されていることを確認します。 詳細については、セキュリティ グループとライセンスで環境へのユーザー アクセスを制御する を参照してください。
必要に応じて、管理 された環境をガバナンスに適用します。
ユーザーに環境へのアクセス権を付与します。
専用サイトがまだ存在しない場合は、ワークロードの作業ドキュメント用にSharePointチーム サイトをプロビジョニングします。 この手順では、既定のMicrosoft 365 グループとSharePoint グループを作成します。
SharePointアクセスと検出可能性を構成する
新しいアクセス許可レベルを作成します。
次の一覧のアクセス許可を適用します。
- 項目の追加
- アイテムの編集
- アイテムの削除
- アイテムの表示 (必須)
- アイテムを開く (必須)
- バージョンの表示
次のサイトのアクセス許可を適用します。
- ページの表示 (必須)
- 開く (必須)
サイトのアクセス許可 [ ディレクトリの参照 ] がオフになっていることを確認します。
このアクセス許可レベルを持つユーザーは、親フォルダーを参照したり、サイト階層を移動したりすることはできません。 Dynamics 365 アプリまたはカスタム モデル駆動型アプリからアイテムを追加、編集、または開くことができます。 この制限により、他のレコードに属するドキュメントの検出が困難になります。 アクセス許可レベルを作成および編集する方法と、SharePointのアクセス許可レベルについて説明します。
[高度なアクセス許可] で、サイト グループを作成し、新しいアクセス許可レベルを割り当てます。 SharePointサイトのアクセス許可をカスタマイズする方法について説明します。
新しいSharePoint グループでワークロード セキュリティ グループ サイトへのアクセス権を付与します。
サイト内SharePoint検索を無効にします。 この設定により、ユーザー (またはCopilot) が Dataverse のコンテキストの外部でコンテンツを検索できなくなります。 詳細については、「 サイトのコンテンツを検索可能にする」を参照してください。
必要に応じて、サイトからコンテンツを検索して提供するCopilotを制限します。 詳細については、「SharePoint サイトとコンテンツの検出を制限する」を参照してください。
必要に応じて、SharePoint "メンバー" または "所有者" サイト グループにユーザーを追加することで、特定のロールの昇格されたアクセス権を保持します。 この手順は、すべてのレコードでドキュメントを完全に表示する必要がある場合や、SharePoint フォルダー構造 (役員や監視単位など) をナビゲートする必要があるユーザーに役立ちます。 既定のグループは削除しないでください。 削除すると、システムが不安定になる可能性があります。
Dataverse SharePoint統合を有効にする
SharePoint統合を有効にして、SharePoint サイトを Dataverse 環境に接続します。 詳細については、「SharePoint統合の設定」を参照してください。
必要に応じて、選択SharePoint Dataverse テーブルのドキュメント管理を有効にします。 たとえば、アカウント、ケース、プロジェクト、アプリケーション、苦情、カスタムテーブルなどです。
ユーザーが SharePoint Document レコードと Document Location レコードに対する適切な Dataverse アクセス許可を持っていることを確認します。 詳細については、「 ドキュメント管理タスクに必要なアクセス許可」を参照してください。
ユーザーは、Dynamics 365 アプリまたはモデル駆動型アプリ インターフェイスPower Apps介してファイルに完全にアクセスします。 アプリケーションのフォーム、サブグリッド、またはボタンを使用してファイルを開きます。 直接SharePointには移動しません。
オプションの拡張機能
条件付きアクセスまたはアプリによって適用される制限を追加のセーフガードとして追加します (非管理対象デバイスの Web のみのダウンロードや制限付きダウンロードなど)。 条件付きアクセスの詳細を確認します。
SharePointと Purview 監査ログを使用して使用状況を監視し、予期しないアクセス パターンを検出します。 Microsoft Purviewの監査ソリューションについて説明します。
Components
Dataverse: コア アプリケーション プラットフォームとして機能し、RBAC を介してレコード レベルのアクセス制御を適用します。 Dataverse は、ユーザーがドキュメントにアクセスするときに操作するセキュリティ モデル、テーブル構造、アプリケーション サーフェイスを提供します。
Power Appsモデル駆動型アプリ: ユーザーが Dataverse レコードと関連するSharePoint ドキュメントを表示および管理する、制御されたガイド付きインターフェイスを提供します。 ユーザーは、制限なくSharePointを参照するのではなく、アプリケーションを介してドキュメントにアクセスします。
Entra ID: ID 管理とセキュリティ グループに使用されます。 Entra IDセキュリティ グループは、Dataverse 環境および関連するSharePoint サイトへのアクセスを許可するユーザーを定義するために使用されます。 これらのグループは、環境アクセスとサイト アクセスの間のアラインメントを作成します。
SharePoint Online: ネイティブ ドキュメント管理が有効なテーブルのドキュメント ストレージ レイヤーとして機能します。 このパターンでのSharePointの役割は次のとおりです。
- 各レコードの Dataverse で生成されたドキュメントの場所をホストする
- ワークロードのEntra ID セキュリティ グループへのサイト アクセスの制限
- サイト ナビゲーション パスの削除または無効化
- サイトとライブラリの検索を無効にする
Microsoft Purview (省略可能): コンプライアンスまたは運用上の監視が必要な場合に、監査、アクセス ログ、およびデータ ガバナンスの機能を提供します。
シナリオの詳細
Microsoft Power PlatformまたはDynamics 365でビジネス アプリケーションを構築している組織は、Dataverse レコードに関連付けられているファイルを格納および管理するために、ネイティブ SharePoint ドキュメント管理に頻繁に依存しています。
ビジネスの課題
ネイティブの Dataverse と SharePoint の統合は、使いやすさに優れた利点を提供しますが、SharePointのアクセス許可モデルが Dataverse のレコード レベルのセキュリティ (RBAC) と自動的に一致しないという、よく知られたアーキテクチャ上の課題も発生します。
ケース管理、苦情処理、承認、プロジェクト、調査、アプリケーションの許可、規制ワークフローなどの一般的なシナリオでは、各ユーザー グループは特定のレコードにのみアクセスできます。 Dataverse では、これらのアクセス許可を適用するために、きめ細かいロールベースのアクセス制御 (RBAC) が使用されます。 ただし、関連付けられているSharePoint サイトにアクセスするユーザーは、Dataverse セキュリティによってアプリで表示できないレコードのフォルダーまたはファイルにアクセスすることがよくあります。
このミスアラインメントにより、いくつかの問題が発生します。
意図しないデータの公開: ユーザーは、他のチームまたは部署に関連付けられているドキュメント ライブラリを誤って参照または検索する可能性があります。
過剰な共有リスク:Dataverse フォームでのみドキュメントを表示する必要があるユーザーは、親フォルダー、"最近使用した" リスト、またはSharePoint検索を介してドキュメントを検出する場合があります。
代替手段の運用の複雑さ:
項目ごとのアクセス制御リスト (ACL) の自動化には、継承の解除、Microsoft Graph を使用した自動化、および大規模なアクセス権管理が必要であり、その結果、多大な運用負荷が生じます。
チームまたは部署ごとに 1 つのサイトなど、マルチサイトの分離により、管理とアプリケーション ライフサイクル管理 (ALM) の複雑さが増します。
サード パーティ ベンダーは追加のライセンス コストを引き付け、多くの場合、特権アクセスを必要とします。これは、特に政府機関のコンプライアンス要件を満たしていない可能性があります。
提案されたソリューション
制御されたSharePointドキュメント アクセス パターンは、実用的な中間パスを提供します。 このアーキテクチャでは、ファイルまたはフォルダー レベルで Dataverse の RBAC を再現しようとするのではなく、SharePoint での見つけやすさを制限し、ナビゲーション経路を限定することで、Dataverse および Power Apps/Dynamics 365 内からのネイティブなドキュメント管理エクスペリエンスを維持します。 ワークロード セキュリティ グループへのサイト アクセスを制限し、ナビゲーション要素を削除し、サイトとライブラリの検索を無効にし、主に Dataverse で生成された URL を介してユーザーがドキュメントにアクセスできるようにすることで、アーキテクチャはワークロード境界内のSharePointを効果的に "含む" ことになります。 Dataverse RBAC はレコードとそのドキュメント リンクへのアクセスを制御し、SharePointアクセス許可はドキュメントへの直接アクセスを制御します。
このパターンを使用する場合
このパターンは、次の場合に特に重要です。
組織は、承認ではなく検出可能性が主な懸念事項であるリスク管理アプローチを受け入れます。
このビジネスには、レコードごとの ACL を維持することなく、使い慣れたコラボレーションSharePointエクスペリエンスが必要です。
高度にカスタマイズされたセキュリティ自動化よりも、シンプルさ、保守容易性、予測可能な操作が推奨されます。
規制要件は、不注意によるアクセスの削減、監査証跡の維持、項目ごとの厳格な実施ではなく、適切な監視の確保に重点を置きます。
このパターンでは、サイトに直接移動するのではなく、Dataverse を介してドキュメントを開くようユーザーに指示します。 顧客が期待するシームレスなSharePointドキュメント管理エクスペリエンスを維持しながら、意図しないクロスレコード アクセスを減らします。
このシンプルで反復可能なアーキテクチャは、追加のガードレールを必要とする政府機関、企業、規制業界のガバナンスをサポートします。 サポートされていない、または複雑なセキュリティ構造を回避し、使いやすさ、コスト、セキュリティのバランスを取ります。 このアーキテクチャでは、ファイル レベルで厳密な適用を行うのではなく、検出可能性コントロールを使用して一般的なドキュメント アクセスを管理します。
代替アプローチを検討する場合
このパターンは、コンプライアンス上の理由から厳密なファイル レベルのセキュリティが必要な場合には適していません。 このパターンは、検出可能性制御によって不注意によるアクセスを減らしますが、URL が共有されている場合、意図的または悪意のあるアクセスを防ぐことはありません。 保証されたファイル レベルの分離を必要とする組織は、項目ごとの ACL または代替分離パターンを実装する必要があります。
考慮事項
これらの考慮事項は、ワークロードの品質を向上させる一連の基本原則である Power Platform Well-Architected の柱を実行します。 詳細については、Microsoft Power Platform Well-Architected を参照してください。
Reliability
不要な複雑さを避けるためにワークロードを設計する: このアーキテクチャ パターンにより、項目ごとの ACL の脆弱な自動化、継承の中断、複雑な統合が回避されます。 ドキュメント アクセスの動作はシンプルで予測可能で、サポートされているプラットフォーム機能に合わせて調整されます。
構造化、テスト、文書化された BCDR を実装する: アーキテクチャでは Dataverse と SharePoint Online のみを使用するため、カスタムのビジネス継続性とディザスター リカバリー プロセスを必要とせずに、Microsoftのネイティブ (および文書化された) geo 冗長性、バックアップ、復元機能を継承します。
セキュリティ
プラットフォーム のガイダンスに沿ったセキュリティ ベースラインを確立する: 環境とSharePoint サイトの両方の単一アクセス境界として専用のEntra ID セキュリティ グループを使用すると、ID ドリブン アクセスの明確で一貫性のあるベースラインが提供されます。
意図的なセグメント化と境界の作成: SharePointサイトのワークロード セキュリティ グループへのアクセスを制限し、ナビゲーションと検索機能を削除することで、Dataverse コンテキスト外のドキュメントの検出を制限する明確な境界が確立されます。 リンクを取得したユーザーは、SharePoint サイトのセキュリティ グループに属している場合、ファイルにアクセスできます。 このパターンの目的は、SharePoint項目レベルでセキュリティを適用することではありません。 代わりに、シンプルな設計を使用して追加のセーフガードを提供します。 このパターンにより、このトレードオフが意図的に行われます。
厳密、条件付き、監査可能な ID とアクセス管理 (IAM) を実装する: すべてのアクセスは、Entra IDを通じて ID ベースであり、Dataverse とSharePointログを通じて監査可能です。 このセットアップは透明性をサポートし、組織が予期しないアクセス パターンを監視できるようにします。
オペレーショナル エクセレンス
プラットフォーム機能を使用して日常的な運用タスクを形式化する: このパターンでは、ネイティブの Dataverse とSharePointの動作に依存して、カスタム自動化を回避します。 この方法により、操作が簡略化され、手動による介入が減ります。
ID とアクセス管理を一元化する: すべてのアクセス許可は、Entra ID グループを通過します。 組織は、カスタム ロール ロジックを導入することなく、アクセス レビュー、ライフサイクル ガバナンス、既存のエンタープライズ プロセスを使用できます。
パフォーマンス効率
パフォーマンスの期待に応える適切なサービスを選択します。アーキテクチャでは、構造化されたビジネス データに Dataverse を使用し、ドキュメント ストレージにSharePointを使用し、追加の処理レイヤーなしで各サービスを目的に活用します。
プラットフォームに責任をオフロードしてロジックを最適化します。Dataverse と SharePointはドキュメントのアクセスとレンダリングを処理し、待機時間を最小限に抑え、Dataverse の最適化されたファイル処理パイプラインを活用します。
エクスペリエンスの最適化
一貫性のある情報アーキテクチャを実装する: SharePointナビゲーション オプションを削除し、Dataverse のレコード コンテキスト ドキュメント ビューに依存することで、ユーザーは一貫性のある予測可能な情報構造を体験できます。
使いやすさに優先順位を付け、コグニティブな負荷を軽減する: ユーザーは、レコードに関連付けられている Dataverse フォーム内からのみドキュメントにアクセスし、混乱を最小限に抑え、関連のないファイルへの露出を防ぎます。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主な執筆者: