Dataverseセキュリティロールと行レベルセキュリティ：どちらが必要か

By Mirko Peters · 2026-08-20

Dynamics 365とMicrosoft 365におけるDataverseセキュリティロール、行レベルセキュリティ、列レベルのアクセス許可の違いを解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft Dynamics 365およびPower Platformで業務ソリューションを設計する際、機密データへのアクセスを制御することは極めて重要です。テーブルレベルのDataverseセキュリティロールと、きめ細かな行レベルのセキュリティのどちらを選ぶかによって、不正なデータ公開を防ぎつつ、メンバーが日常業務を効率よく遂行するために必要なアクセス許可を確実に維持できます。

重要なポイント

• Dataverseセキュリティロールは、受付デスクのような役割を果たします。ユーザーが、どのテーブル（取引先企業やケースなど）を読み取り、作成、更新、削除できるかを決定します。
• 行レベルのセキュリティは、テーブル内の個々のレコードへのアクセスを制限します。たとえば、営業担当者が自分が所有する商談だけを閲覧できるようにします。
• Microsoft Entra IDはサインイン時にユーザーのIDを検証し、Dataverseは基盤のデータモデルに対してきめ細かなアクセス許可とビジネスルールを適用します。
• 列レベルのセキュリティは、アクセス可能な行の中にある財務メモや給与情報などの機密性の高い詳細に対して、追加の保護層を提供します。
• テーブル、行、列のアクセス許可を組み合わせることで、場当たり的なUIの調整に頼ることなく、業務上のニーズに正確に合わせてデータの表示範囲を調整できます。

Dataverseのセキュリティレイヤーを理解する

Microsoft Dataverseのデータセキュリティは、一律に切り替えるようなものではありません。その代わりに、運用効率と厳格なコンプライアンスのバランスを取るように設計された多層のアーキテクチャモデルとして機能します。セキュリティを後回しにしたり、個々のPower AppsやDynamics 365モジュール内のUI要素を隠すことだけに頼ったりすると、データ漏えいやユーザーの使いにくさを招くことは避けられません。堅牢なセキュリティ戦略には、ID、テーブル、行、列がどのように交差するかを理解することが欠かせません。

データ環境を、安全な企業の本社のようにイメージしてください。従業員は、すべてのオフィス、キャビネット、引き出しに自由にアクセスできるわけではありません。Dataverseのセキュリティも同じ考え方で、データ構造のすべてのレベルで明確な境界を設けます。ユーザーがどのビジネスレコードを操作する前にも、システムはそのIDを検証し、割り当てられた役割をデータベースの構造に照らして評価します。

テーブルレベルのセキュリティロールの解説

セキュリティロールは、Dataverseのアクセス許可の基礎となるレイヤーです。セキュリティロールとは、営業担当者、カスタマーサービス担当者、部門マネージャーなど、特定の職務や部門に紐づけられた特権の組み合わせのことです。

テーブルレベルでは、これらのロールによって、データ全体の種類に対して標準的な作成（Create）、読み取り（Read）、更新（Update）、削除（Delete）の各操作を実行できるかどうかが決まります。例えば次のとおりです。

• 営業担当者：通常、取引先企業、連絡先、リード、商談の読み取り、作成、更新の権限が付与されます。一方で、重要な履歴レコードの削除は制限されることが多いです。
• カスタマーサービス担当者：サポートケースと顧客キューを管理するように構成されます。ただし、営業パイプラインの段階や商談の変更はできないように制限される場合があります。
• 部門マネージャー: 複数の業務テーブルを横断する広範な監視権限が付与され、部門横断のレポート作成やチームのパフォーマンス監視が可能になります。

これらの権限はアプリの画面ではなく、データ基盤に直接紐づいています。そのため、カスタマイズしたキャンバスアプリ、モデル駆動型アプリ、接続された Power Automate のワークフローのいずれから情報にアクセスしても、同じガードレールが有効に働きます。

行レベルのセキュリティと所有権

テーブルレベルのセキュリティは、ユーザーがアカウントテーブル自体を開けるかどうかを決めます。一方、行レベルのセキュリティは、そのテーブル内で閲覧できる個々の取引先企業のレコードを決めます。行レベルのセキュリティがなければ、営業担当者のセキュリティロールを割り当てられたすべてのユーザーが、データベース内のすべての顧客レコードを参照できてしまいます。

行レベルのセキュリティは、レコードの所有者とビジネスユニットに大きく依存します。標準的な営業構成では、営業担当者は所有者として明示的に指定されたアカウントおよび連絡先の行だけにアクセスできるのが一般的です。一方、営業マネージャーはより上位のセキュリティスコープに属するため、地域チーム全体が所有する顧客の行をすべて参照できます。

このようにきめ細かく制御することで、従業員は自分に関係するタスクに集中でき、新人スタッフが他部門で管理している重要なアカウントを閲覧することも防げます。誤ってデータが公開されるリスクを大幅に減らし、ワークスペースの散らかりも最小限に抑えられます。

機密データに対する列レベルのセキュリティ

ユーザーが特定のアカウントや連絡先の行に正当にアクセスできる場合でも、個々の列には閲覧を制限すべき機密情報が含まれていることがあります。列レベルのセキュリティを使うと、管理者は口座情報、役員報酬の金額、機密性の高い交渉メモなどの特定のフィールドをロックできます。その一方で、顧客レコードの残りの部分は通常業務のためにすべて利用可能なままにできます。

ビジネスユニットと組み合わせることで、複雑な企業構造、地域の子会社、独立した業務部門を反映した堅牢な階層的境界を設定できます。こうした統合データ構造が裏側でどのように動作しているかを詳しく知りたい場合は、M365 FM Podcast のエピソード全編を聴くことができます。

まとめ

Microsoft Dataverse 環境を構成するには、ユーザーのアクセス許可を実際の業務ワークフローに合わせた、計画的な戦略が必要です。Entra ID による ID 検証、テーブルレベルのセキュリティロール、行レベルの所有権ルール、列レベルの保護を組み合わせることで、Dynamics 365 と Power Platform のための安全で高性能なデータ基盤を構築できます。組織のアクセス要件を時間をかけて評価し、データそのものを中心にセキュリティモデルを設計してください。Microsoft のクラウド環境を最適化するための実践的な手法や専門家の知見については、ポッドキャストのエピソード全編をお聴きください。

よくある質問

Dataverse におけるテーブルレベルのセキュリティと行レベルのセキュリティの違いは何ですか。

テーブルレベルのセキュリティは、すべての取引先企業やサポートケースなど、データのカテゴリ全体にユーザーがアクセスできるかどうかを制御します。行レベルのセキュリティは一歩進んで、所有者、チームの割り当て、ビジネスユニットに基づいて、そのテーブル内の特定のレコードへのアクセスを制限します。

Microsoft Entra ID は Dataverse のセキュリティとどのように連携しますか。

Microsoft Entra ID は最初の認証レイヤーとして機能し（ビルの受付のような役割です）、サインイン時にユーザーの ID を検証します。その後 Dataverse がその ID を受け取り、特定のセキュリティロールとアクセス許可を適用して、ユーザーが閲覧および変更できる内容を決定します。

顧客レコード内の特定のフィールドへのアクセスを制限できますか。

はい。Dataverse には列レベルのセキュリティがあり、アクセス可能な行の中でも個々のフィールド（財務データや非公開のメモなど）を保護できます。これにより、ユーザーは自分のロールに関連するデータだけを確認できます。

各 Power App ごとにセキュリティロールを個別に構成する必要がありますか。

いいえ。Dataverse は Dynamics 365 と Power Platform アプリケーションの共通データ基盤として機能するため、セキュリティロールとビジネスルールはデータレイヤーで直接適用されます。接続されたすべてのアプリに、一貫したガードレールが自動的に適用されます。