記事公開日
最終更新日
モデル駆動型アプリ概説 ⑤セキュリティロールの構成
こんにちは。システムソリューション営業本部の吾妻です。
「モデル駆動型アプリ概説」連載の第5回目として、前回までに作成したPower Platform環境やDataverseテーブル、モデル駆動型アプリに対して、アクセス制御を行う手順をご紹介していきます。
モデル駆動型アプリの作成手順（復習）
モデル駆動型アプリを作成するための手順として、以下のものがありました。今回は「セキュリティロールの構成」のために、セキュリティグループやセキュリティロールの設定を行っていきます。| 手順 | 内容 |
| ①ビジネスデータのモデル化 | |
| ②ビジネスプロセスの定義 | |
| ③モデル駆動型アプリの作成 | |
| ④セキュリティロールの構成 | ユーザーごとの権限に応じたデータのみにアクセスできるようにする ・セキュリティグループ ・セキュリティロール |
| ⑤アプリの共有 | |
| ⑥応用的なカスタマイズ | |
用語
今回利用する各機能についてご紹介します。モデル駆動型アプリ（Dataverseテーブル）には、ユーザーがレコードにアクセスできるか否かを判定する、以下の関門が存在します。
- Power Appsライセンス
…Power Platform製品を利用するためには、ユーザーにライセンスが紐づけられている必要がある
- セキュリティグループ
…Power Platform環境に対してアクセスするためには、ユーザーが所属しているセキュリティグループが環境に紐づけられている必要がある（もしくは全ユーザーに環境へのアクセスを許可することもできるが、環境を作るときに明示的に指定する必要がある）
- セキュリティロール
…Dataverseレコードにアクセスするためには、ユーザー個人またはユーザーが所属しているチームに対して、レコードへのアクセスを許可する設定がなされたセキュリティロールが割り当てられている必要がある
（ただし、セキュリティロールで許可されていなくても、レコードが共有されている場合はアクセスできる）
これらの関門を突破したうえで、レコードが関連付けられた部署、ユーザーがメンバーとして所属しているチーム、共有しているレコードの組み合わせをもとに、最終的にレコードにアクセスできるかどうかが判定されます。
セキュリティロールの仕組みと設定手順
ライセンスとセキュリティグループについては、単純に紐づけているかどうかの設定だけなので問題ないかと思います。ライセンスについてはMicrosoft 365 管理センターから、セキュリティグループについては、Dataverse環境を作成する際に選択するか、環境の設定画面から再設定することができます。
次に、セキュリティロールについては、もう少し深堀りしていきたいと思います。
公式ドキュメントだと説明が分かりにくいので、図や表を交えてご紹介したいと思います。
部署
セキュリティロール自体の話の前に、まずはDataverseにおいて、部署を登録しておく必要があります。部署の設定は、Power Platform環境ごとの設定画面から行います。セキュリティロールの設定も同じ画面から行うことができます。
Dataverseの部署設定は、必ずしも現実の部署やAzure ADの部署と一対一対応で設定する必要はなく、データアクセスさせる範囲が一緒であればまとめることも可能です。
今回は、全社を示す「ルート部署」の配下に総務部とシステム本部があり、システム本部の中に営業部と開発部があるような簡略化した組織を例に考えていきたいと思います。
Power Platform環境の設定画面で上図の部署を設定した結果はこのようになります。各部署には、所属するものとして「ユーザー」「部署」「チーム」を設定することができます。今回はチームは設定しませんが、部署に所属するメンバーをAzure ADの情報に基づいて動的に変更したい場合にはチームを利用することになります。
セキュリティロール
部署の設定を済ませたら、さっそくセキュリティロールの設定を行っていきます。セキュリティロール設定では、対象となる「テーブル」と、「特権」、「アクセスレベル」の組み合わせを定義していきます。
セキュリティロールは、①所有者チーム（Dataverseの部署を作成すると追加されるチーム）、②Azure ADグループチーム（Azure ADのセキュリティグループ／Microsoft 365グループに紐づくチーム）、③ユーザーに割り当てることができます。2種類のチームはDataverse環境の設定から確認することができます。
ちなみに、メーカーポータルにアクセスすると、画面右上のドロップダウンに、現在アクセスしている「環境」が表示されると思いますが、
これも主にセキュリティロールによって表示できるか決められていて、システム管理者、システムカスタマイザー、環境作成者のいずれかのセキュリティロールが割り当てられているか、対象の環境内のアプリの所有者であることが条件となっています。
実際に設定画面を開く前に、まずは特権とアクセスレベルを一覧表で確認してみましょう。
特権
| 手順 | 許可する操作 |
| Create | レコードを作成する |
| Read | レコードを閲覧する |
| Write | レコードを変更する |
| Delete | レコードを削除する |
| Append （追加） |
現在のレコードを別のレコードに関連付ける |
| Append to （追加先） |
別のレコードを現在のレコードに関連付ける |
| Assign | レコードの所有権を別のユーザーに与える |
| Share | 自分のアクセス権を保持したまま、 レコードへのアクセス権を別のユーザーに与える |
アクセスレベル
| タイプ | 許可するユーザーの範囲（組織階層観点） | |
 |
組織 | 全ユーザー |
 |
部署配下 | 同じ部署のユーザーと上位部署のユーザー |
 |
部署 | 同じ部署のユーザーのみ |
 |
ユーザー | 自分自身のみ |
 |
なし | （許可しない） |
例えば、開発部員が自分自身が所有するレコードのみアクセスする場合には「ユーザー」を指定します。この開発部員のレコードに開発部長もアクセスするもののシステム本部長はアクセスしない場合には「部署」を指定します。さらに、開発部員のレコードにシステム本部長がアクセスできるようにする場合は「部署配下」を指定します。一方で、ユーザーマスタや祝日マスタのようなマスタデータを格納するテーブルについては、「組織」を指定することで、部署に依らず、誰でもアクセスできるようにします。
アクセスレベルで注意を要するのが、「部署」「部署配下」はあっても「上位部署」のアクセスレベルは存在しないことです。マスタデータのテーブルなど、「所属する上位部署階層のレコード」を「下位部署」のユーザーがアクセスする必要があり、なおかつ他の部署階層の下位部署にはアクセスさせたくないといった場合には、レコードを共有する、チームを階層ごとに個別に用意してセキュリティロールを各々定義する、といった別の方法を取る必要があります。
また、複数のセキュリティロールが（既定で定義済みのセキュリティロールも含めて）設定されている場合は、特権が累積され（特権の和を取り）ます。なので、試用環境を自分自身で用意して元々システム管理者ロールが割り当てられている状況だと、セキュリティロールを意識せずにDataverseレコードにアクセスできてしまい、後から管理者ではない一般ユーザーを追加した際にレコードにアクセスできずに慌てる、といったことがよく起こります。
このように、部署の数や役割の数が増えるごとにセキュリティロールの数も増大し、セキュリティロールの数が増大すると、どのセキュリティロールの効果でレコードにアクセスできているか確認しにくくなったり、ユーザーの異動／退職／兼務等に伴うメンテナンスも難しくなったりすることから、部署や役割（権限）の数はなるべく少なく抑えて、管理・運用しやすい状態を保つことが重要になってきます。
定義済みのセキュリティロール
Dataverseデータベースを持つ環境であらかじめ用意されているセキュリティロールとして、以下のものがあります。
サービス用のロールはユーザー個人やチームに割り当てることはできません。このため、例えば、個々のユーザーに対してカスタムテーブルを含めたすべてのテーブルに読み書き権限を与えたい、といった場合には、「サービスライター」ロールのメンバーにユーザーを追加するのではなく、まず「サービスライター」ロールを複製した「サービスライター②」のようなロールを作成してから、そちらのメンバーにユーザーを追加する必要があります。
| セキュリティロール | 内容 |
| アプリオープナー | カスタムのセキュリティロールを定義する際のもととなる、最小権限のロール |
| Basicユーザー | 環境内でアプリを実行して、自分が所有するレコードに対して一般的なタスクを実行できるロール |
| 代理人 | 偽装者として、他ユーザーに代わってタスクを実行するロール |
| 環境作成者 | アプリ、フローなどリソースを作成・共有できるが、環境内のデータにアクセスできないロール |
| サービスデリーター (Service Deleter) |
すべてのエンティティに対する完全な削除権限がある、サービス用のロール |
| サービスリーダー | すべてのエンティティに対する完全な読み取りアクセス許可権限がある、サービス用のロール |
| サービスライター | すべてのエンティティに対する完全な作成、読み取り、書き込み権限がある、サービス用のロール |
| サポートユーザー | カスタマイズおよびビジネス管理設定に対する完全な読み取りアクセス許可がある、サービス用のロール |
| システム管理者 | セキュリティロールを管理でき、 環境内のすべてのデータを表示できるロール |
| システムのカスタム担当者 （システムカスタマイザー） |
環境をカスタマイズするための完全なアクセス許可が付与され、環境内のすべてのカスタム テーブル データ（取引先企業、取引先担当者、活動のテーブルで作成した行のみ）を表示できるロール |
独自のセキュリティロールを準備する場合、一から作るのではなく「アプリオーナー」ロールを複製して作り始めることで、スピーディーに作成することができます。従来は、Basicユーザーをコピーしてカスタムのセキュリティロールを作成するように案内されていましたが、現在はアプリオープナーを基にすることが推奨されています。また、モデル駆動型アプリを作成することが前提なので今回は関係ありませんが、Dataverseデータベースを持たない環境では環境作成者と環境管理者の2つのセキュリティロールしか生成されません。
セキュリティロールを明示的に割り当てなくても、環境にユーザーが追加されたタイミングで自動的にセキュリティロールが割り当てられることもあります。
まず、テナント管理者、Power Platform管理者、Dynamics 365サービス管理者などのAzure AD管理者には、システム管理者ロールが割り当てられます。
次に、Dataverse環境設定の「ライセンスとロールのマッピング」にマッピングが定義されている場合は、各ユーザーに割り当てられているライセンスに応じてセキュリティロールが自動的に割り当てられます。
さらに、既定環境の場合、追加されたすべてのユーザーに対して、Basicユーザーと環境作成者のセキュリティロールが割り当てられます。
また、Power Platform統合でDynamics 365の財務と運用アプリを接続している場合には、財務と運用のBasicユーザーセキュリティロールが、追加されたすべてのユーザーに対して割り当てられます。
設定例
いくつかのシナリオについて、セキュリティロールをどう設定するべきか考えてみたいと思います。①自分自身がAzure AD側のシステム管理者である場合
セキュリティロールを設定しなくても、自動的にシステム管理者ロールが割り当てられるため、カスタムテーブルを含めたすべてのテーブルのレコードの読み書きが可能です。②システム管理者が作成したモデル駆動型アプリを、特定のユーザーに共有し、カスタムテーブルのレコードを読み書きさせたい場合
アプリオープナーロールを複製し、カスタムテーブルへの読み書き権限を追加した後で、共有画面からユーザーに割り当てます。③特定のユーザーにアプリを作成させたいが、レコードはユーザー自身のものしか読み書きさせたくない場合
Basicユーザーロールと環境作成者ロールをユーザーに割り当てます。まとめ
今回は、Power Platform環境やDataverseテーブル、モデル駆動型アプリに対して、アクセス制御を行う際の考え方について、簡単にご紹介しました。次回の記事では、モデル駆動型アプリを社内の他のユーザーに使ってもらうための共有方法や管理方法についてご紹介できればと考えています。QESの Power Platform サポート＆アプリカタログサービス は、キャンバスアプリやモデル駆動型アプリ、Power Pagesといった各種Power Platform製品群の導入、環境構築、弊社で開発したカタログアプリのご提供などを行うサービスです。まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
