前回までの投稿でセキュリティロールをベースとした権限管理を説明した。
権限設計を行う上では、セキュリティロールによる制御を第一に検討すべきであるということも記載した。
この上で、更なる制御を行う場合はその他標準機能を検討するべきであるとも記載した。
今回は、更なる制御の1つとしての標準機能である、フィールドセキュリティに関して記載する。
フィールドセキュリティとは、フィールドに対する制御を行う機能である。
セキュリティーロールがエンティティ単位での制御であるのに対して、
フィールドセキュリティはフィールド単位での制御を行うことができる。
フィールドセキュリティの有効有無はフィールドセキュリティプロファイルを用い、
ユーザーもしくはチーム単位で制御を行う。
また、大きな制限であるが、システムフィールド（デフォルトで存在するフィールド）には
適用できず、カスタムフィールドのみに適用ができる。
以下の要件を例にとり、設定を行ってみる。
「取引先企業の重要取引先フラグフィールドは営業担当者が更新せず、営業アシスタントが更新するものとする。
経理部派遣社員には閲覧制限を設けるものとする。」
設定の流れは以下のとおりである。
①フィールドでフィールドセキュリティを有効化する
②フィールドセキュリティプロファイルで権限を設定し、ユーザーまたはチームを追加する
③動作確認
①フィールドでフィールドセキュリティを有効化する
（フィールドを作成し、）以下のようにフィールドセキュリティのチェックをオンにする。
保存して公開する。
②フィールドセキュリティプロファイルで権限を設定し、ユーザーまたはチームを追加する
フィールドセキュリティは2つ作成する。
・値の閲覧はできるが作成/修正できないプロファイル
・値の閲覧及び作成/修正ができるプロファイル
[設定]>[フィールドセキュリティプロファイル]をクリック
[新規]をクリック
・値の閲覧はできるが作成/修正できないプロファイルの作成
[名前]を入力し、一度保存保存する。
[フィールドのアクセス許可]をクリック
フィールドセキュリティがオンになっているフィールドが一覧表示される。
[読み込み]：可、[更新]：不可、[作成]:不可とする。
レコードをダブルクリックし、上記に変更し保存。
ユーザーもしくはチームを追加する。
登場人物は以下のようにしている。
営業：crmuser1、営業1課部署（同チーム）
営業アシスタント：crmuser2、営業アシスタント部署（同チーム）
営業派遣社員：crmuser3、経理部部署（同チーム）
※セキュリティロールに関しては取引先企業に対してフル権限を付与。
※チームに関する画面は割愛
[チーム]から[営業1課]を追加する。
・値の閲覧及び作成/修正ができるプロファイル
同様にプロファイルを作成する。
営業アシスタントはフィールドに対してフル権限
[営業アシスタント]チームを追加
③動作確認
crmuser1でログインする。
取引先企業の新規フォーム。フィールドセキュリティ項目にはフィールドの先頭に鍵マークが表示される。
入力フィールド前に錠マークが表示されて入力できないが、値は確認できる。
既存データ。同じく錠マークが表示され、修正はできないが値は確認できる。
crmuser2でログインする。
取引先企業の新規フォーム。入力可能。
既存データ。閲覧、修正可能。
crmuser3でログインする。
取引先企業の新規フォーム。[*******]でマスクされ、閲覧/入力不可。
既存データ。同じく[*******]でマスクされ、閲覧/入力不可。
以上のような実装で要件を満たすことができる。
[*******]マスクはビューやExcelダウンロードでも行われる。
また、crmuser3は特殊な派遣社員であってある取引先企業のこの値を閲覧させるたい要望が発生した場合、
一般ユーザーにて権限付与を行うことができる。
既存レコードの[・・・]から[セキュリティで保護されたフィールドの共有]をクリック
「crmuser3」を追加し、[読み込み][更新]共に「あり」に変更する。
crmuser3でログイン。該当レコードを表示すると、制御が解除されていることが分かる。
別の既存レコードは従来同様、制御が機能している。
当然、この操作はcrmuser3自身が行うことはできない。
crmuser2など該当権限に対して「あり」という権限を保有しているユーザーのみが実施可能である。
セキュリティーロールで制御しているわけではないという点に注意が必要である。
以上。
本来はもう少し注意点や別の実装方法を記載しようと思ったが、
長くなってしまったので以下程度の軽い形にしておく。雑な記載のため理解困難かもしれない。
・システム管理者ロールを保有するユーザーには制限を加えられない。
自動的に[システム管理者]というプロファイルに追加されてしまうため。
・チームをプロファイルに追加するような設計に注意。
ユーザーの部署で設定した部署名と同名のチームから外れることはできないというのがチームの仕様である。
今回、crmuser3は経理部という別の部署としたが、当初のストーリーでは
営業1課部署に所属する派遣社員としたかった。しかしながら、
このようにすると必ず、営業1課チームに所属することとなってしまい、
crmuser1と同様になってしまうためストーリーを変更した（のだが。。事項に続く）
・複数チームに所属され複数のプロファイルを適用すると制御は加算され弱いほうが適用される
ストーリーを変更したのだが、よく考えたところ、以下のように実装できることが分かった。
1.「派遣」チームを作成し、crmuser3を所属
2.「派遣用」フィールドセキュリティを作成し、「派遣」チームを追加
3.フィールドに対する制御は営業と同様
crmuser3は[営業1課]と[派遣]チーム所属し、それぞれのプロファイルが適用される。
読み込み等制御はそれぞれの弱いほうが適用されるため、
営業と同様の権限制御が可能。
・安易に使いすぎるないほうがいい
複雑なクエリが実行されるであろうというのは容易に想像がつく。
また、そもそも要件自体が細かくなり勝ちであるため、テストが複雑化する。
どこかのタイミングで説明をしようと思うが、要件次第では複数フォームの利用を検討すべきである。
実践 Dynamics 365/CRM 〜2017 