Dataverse でレコードを共有する方法 (部署やアクセスチームなど)

はじめに

Microsoft Dataverse でキャンバスアプリを共有する方法について、以下の記事で紹介しました。

上記でも触れたように、Microsoft Dataverse では、セキュリティロールを利用して、テーブルに対して、特権 (例：作成、読み取り)、アクセスレベル ユーザー、組織) という仕組みでアクセス権を付与します。

そして、例えば、自分が作成した行について、アプリを利用する人は誰でも読み取り可能ですが、変更や削除は自分 (アプリの管理者は除く) しかできないようにしたい場合、以下のような感じで設定します。

個人的に、アクセスレベルのユーザー、組織を組み合わせることでアクセス制御に関する要件を満たせるケースも多くあると思いますが、今回は、それ以外の以下のような要件に関するアプローチ、考慮事項等について整理してみたいと思います。

• 同じ部署の人が作成したレコードは操作可能だが、異なる部署の人が作成したレコードは操作できないようにしたい

• 部署など関係なく、特定のユーザーに対して任意のタイミングでレコードを共有したい

同じ部署の人が作成したレコードは操作可能だが、異なる部署の人が作成したレコードは操作できないようにしたい

アプリ利用者が多い場合、自分が作成したレコード (ユーザー) or アプリ利用者が作成したレコードすべて (組織) というアクセスレベルでは要件を満たせない場合があると思います。

例えば、自部門の人が作成したデータは閲覧可能だが、他部門の人が作成したデータは閲覧できないようにしたいといった要件が考えられます。

このような要件がある場合、以下の、部署や部署配下のアクセスレベルを利用することが考えられます。こちらの部署について、もう少し深掘りしたいと思います。

部署とは

英語では、Business units となっており、何らかの事業単位となります。こちらを利用することで、部署 (Business units) が同じ人が作成したレコードの場合、操作が可能、異なる場合は操作ができないといったことが実現可能です。

例えば、以下のようにアクセス権を設定していた場合の動作は以下のような動作になります。

このようなアクセス権制御の要件を満たすことが可能ですが、実際に設計、運用をする際は色々考慮が必要になりますので、この点について深掘りしたいと思います。

部署のメンバーの割当、メンテナンスについて

まず、部署の作成は以下から可能で、環境単位で作成していきます。

メンバーの割当は、チームを介して行います。チームについては以下の情報を参考にしていただければと思います。

所有者チームの場合は手動でメンバーを割り当てる必要がありますが、Azure AD と紐づくチームの場合、メンバーのメンテナンスは Azure AD 側に委ねることになります。

元々 Azure AD のグループのメンバーは、組織改正があった際などにバッチ処理などでメンテナンスする運用となっている場合、Dataverse を利用するアプリ作成者がメンバーをメンテナンスする必要がなくなります。

そのため、こちらを利用すればやりたいことが楽に実現できるとお考えになる方も多いと思いますが、実際の運用を踏まえるともう少し考慮することがあります。

ユーザーが所属する部署

まず、Dataverse の各レコードには、レコードの所有者が存在します。そして、当たり前かもしれませんが、既定では、そのレコードを作成したユーザーが所有者となります。

そして、Dataverse の各環境のユーザーには、所属する部署を持ち、既定では、以下のように、組織のトップの階層の部署 (ルート部署) に所属することになります。

つまり、部署 A、部署 B を作成し、チームを介してこちらと紐づく Azure AD のグループと紐づけを行っただけの場合、以下のような動作になってしまいます。

こちらを踏まえると、以下のような対策が考えられますが、懸念点もございます。

• Datavese の各環境のユーザーが所属する部署を Power Automate 等で定期的にメンテナンスする
• レコードが作成された際、Power Automate を起動し、Azure AD のグループと紐づくチームをレコードの所有者にする

まず、前者のユーザーが所属する部署を定期的にメンテナンスする方法について、各ユーザーが紐づく部署情報 (Dataverse の環境における) を管理する必要があり、大規模な組織レベルでメンテナンスするのは現実的ではないかもしれません (アプリ作成者の負担が大きくなります) 。

後者について、実は以下のようにレコードの所有者をチームにすることができます。そのため、ユーザーがレコードを作成した際に、レコードの所有者をチームに変更することが出来れば、部署が同じ人が作成したレコードの場合、操作が可能、異なる場合は操作ができないといったことが実現可能です。

しかし、こちらの場合も、ユーザー A がレコードを作成したらチーム A (部署 A) をレコードの所有者に変更するといった管理情報が必要になり、大規模な組織レベルでメンテナンスするのは現実的ではないかもしれません。

その他考慮事項

上記も踏まえつつですが、その他考慮事項について、以下の情報をベースに述べたいと思います。

こちらのドキュメントにて、メンテナンス性やパフォーマンス等の観点から、部署 (Business units) の数を最小限に抑えることをお勧めする旨の記載があります。

日本語では部署という名前になっていることから、組織の部署と紐付ける (Azure AD のグループをチームを介して紐付けて)、つまり、組織階層と完全に同じような部署 (Business units) 階層を作成してアクセス権を制御する運用をイメージされるかもしれませんが、上述の情報を踏まえ、どのような単位で部署 (Business units) を利用するかについて、慎重に検討する必要があると考えます。

個人的には、部署とチームの紐づけは基本的に変わらない、また、ユーザーの所属部署を変更するにせよ、レコードの所有者を変更するにせよ、メンテナンス可能な範囲で利用するといった感じでしょうか。

部署など関係なく、特定のユーザーに対してレコードを共有したい

例えば、何かのプロジェクト単位、担当しているお客様単位など、組織階層などとは関係なくレコードを共有したい場合もあると思います。

こちらについては、レコードの共有とアクセスチームという ２ つのアプローチが考えられます。

レコードの共有

以下の箇所からレコードを他のユーザーに共有できます。

ただし、以下に記載がある通り、こちらの共有について、多数のユーザー間で多数のレコードを共有すると、パフォーマンス上懸念があるようです。

アクセスチーム

セキュリティ ロールを割り当てることができず、レコードも所有しないチームです。上述の通り、プロジェクトチームなど、一時的にアクセス権を付与する際のアプローチの一つです。

以下、実際のアクセスチームの使用例です。以下のようにしてユーザーを追加することで追加されたユーザーはレコードへのアクセスが可能になります。

設定方法について、まず、チームのテンプレートを作成します。その際、付与したいアクセス権を選択します。

アクセスチームを利用したいテーブルにて、アクセスチームを有効にします。

そして、テーブルのビューにサブグリッドを追加し、ユーザーテーブルを選択して、作成したチームテンプレートを選択します。

その結果、アクセスチームでユーザーを追加すると、そのレコードに対して、テンプレートで設定したアクセス権が付与されることになります。

動作確認してみます。まず、以下の状態で testuser002 がレコードを参照しようとすると、アクセス権がない旨のエラーになります。

testuser002 を追加します。

testuser002 の方でレコードを参照できました。

上述のセキュリティ ワークショップのトピックでも、レコードの共有よりはアクセスチームの方が推奨されているように見受けられます。

なお、例えば、レコードが追加された際にアクセス権を自動で追加したいといった要件がある場合、まず、レコードが作成された際に Power Automate が自動起動するようにします。

その上で、ユーザーテーブルに対して以下のアクションを実行します。

• 行 ID は、ユーザーテーブルにおいて、アクセス権を追加したいユーザーの一意な識別子 (GUID) です
• Record はアクセス権を追加したいレコードの GUID です。今回は、取引先企業 (accounts) のテーブルを利用しているため、トリガーとなったレコードの一意な識別子 (GUID) を選択します

• teamtemplate teamtemplateid は予め作成しておいたチームテンプレートの主キーを入れます

動かしてみます。

新規作成したレコードについて、アクセスチームに testuser004 が自動で追加されていました。

今回は、決め打ちで testuser004 をアクセスチームに追加しましたが、アクセスチームに追加したいユーザー (アクセス権を付与したいユーザー) の情報を控えておき、ユーザーテーブルのユーザーの一意な識別子 (GUID) をベースにアクセスチームに追加する感じになると思います

まとめ

今回は、Microsoft Dataverse のレコードを共有する方法について、主に、部署やアクセスチームについて深掘りしてみました。レコードのアクセス制御について、細かい要件がある場合、これらの機能がソリューションになる可能性がありますが、少なからず考慮事項などもあるため、この辺も踏まえつつ設計計、運用の参考にしていただけると幸いです。