-
Notifications
You must be signed in to change notification settings - Fork 0
MS_CRMAdditionalSecurityOptions
-
TOP > Dynamics CRM > CRMのカスタマイズ
- CRM セキュリティモデルの作成
- CRM 追加のセキュリティ オプション
特権（アクセス許可）
- 特権にアクセス レベルを設定、
- 部署やチームを作成、ユーザを追加し、
- セキュリティ ロールを使用する。
補足（3 つの層）: CRM セキュリティモデルの作成と
本ページを合わせると、権限は 3 つの層で構成される。
層 単位 手段 エンティティ 「何ができるか」× 「誰のデータか」 セキュリティ ロール レコード 個々のレコード 共有 / アクセス チーム フィールド 個々の項目 フィールド セキュリティ 本ページが扱う 2 つは、いずれも
上位の層を緩めるのではなく、さらに絞り込む／使いやすくするものである
（後述の AND を参照）。
データやシステム構成（設定、セキュリティ構成）に加えられた変更・変更したユーザを記録する。
- カスタマイズ作業内容の把握、プロセスに従って作業しているかを確認できる。
- 弱体化したセキュリティ構成変更を特定するのに役立つ。
- 設定を変更前の値に戻す場合に役立つ。
- SQL Server に設定が必要になる。
- 追加データが生成され運用コストが増加する。
-
システム エンティティ、カスタム エンティティのフィールドの表示・編集等のアクセスを制限
-
レコード レベルのセキュリティ ロールとは異なり、
より詳細なフィールド レベルのユーザ アクセス許可を制御
補足（使いどころ）: 典型的には、
- 取引先担当者の 個人情報（生年月日、自宅住所）
- 従業員の 給与・評価
- 案件の 原価・利益率
のように、レコード自体は見せてよいが、特定の項目は見せたくない
ケースで使う。
レコード単位でしか制御できないと
「案件は見えるが金額は隠す」ができないため、
この層が追加されている。
すべてのクライアント
- PC 用
- タブレット用
- 電話用
- Outlook 用
すべての表示・編集方法
- レポート
- 簡易表示
- グラフ
- フィルター ビュー
- データ インポート ウィザード
- 監査ログ、重複データ検出
- SDK からのアクセス
補足（この網羅性が重要）: フィールド セキュリティが
SDK やレポートにも効くという点が要点である。
CRMのサポート・テクノロジで
「テーブルに直接クエリを実行することはサポートされない」と
強く述べられているのは、まさに
この制御を迂回してしまうからである。
抜け道を 1 つでも残すと、フィールド セキュリティの意味がなくなる。
フィールド カスタマイズ フォームでフィールド セキュリティを有効にできる（CRM フィールドのカスタマイズ）。
- システム管理者しかアクセスできなくなる。
補足（既定は「全員に見せない」）: 有効にした瞬間に
システム管理者以外は誰も見られなくなるという挙動は、
明示的に許可した人だけが見られる（ホワイトリスト方式）という設計である。
運用中のフィールドに後から有効化すると
全ユーザから一斉に見えなくなるため、
プロファイルの用意を先に済ませておく必要がある。
-
フォーム エディター
ラベルに鍵マークが表示され、一部のユーザはアクセスできないフィールドであることをシステム カスタマイザーに知らせる。 -
フォーム
ラベルに鍵マークが表示され、一部のユーザはアクセスできないフィールドであることをユーザに知らせる。- 編集アクセス許可が無い場合、
フィールド横に南京錠マークが表示され、読み取り専用であることをユーザに知らせる。 - 表示アクセス許可が無い場合、
南京錠マークに加え、フィールド値が****で表示され、読み取り不可であることをユーザに知らせる。
- 編集アクセス許可が無い場合、
-
ビュー
- 表示アクセス許可が無い場合、
フィールドは空になる？
- 表示アクセス許可が無い場合、
システム管理者以外のユーザにアクセス許可を与える。
-
アクセス許可の種類
- 読取：フィールドのデータを参照可能。
- 更新：アップデート時にフィールドのデータを入力可能。
- 作成：インサート時にフィールドのデータを入力可能。
- 削除：削除のアクセス許可は無い
-
アクセス許可の設定方法
- ユーザやチームをフィールド セキュリティ プロファイルに追加する。
- フィールド セキュリティ プロファイルにフィールドと対応するアクセス許可を設定する。
補足（作成と更新が分かれている理由）: 「作成時は入力できるが、
後から更新はできない」という制御ができる。
申込時に一度だけ入力する項目（契約番号、初期設定値など）を
入力させたうえで後から書き換えさせない、といった
業務要件を表現できる。
このプロファイルは、
-
すべてのフィールド セキュリティを有効にしたフィールドへのアクセス許可がある。
-
ユーザ・チームの追加
- システム管理者ユーザ・チームが自動的に追加される。
- その他、任意のユーザ・チームを手動で追加できる。
-
削除不可能
- プロファイル自体
- プロファイルに追加されたシステム管理者ユーザ・チーム
-
ソリューションのフィールド セキュリティ プロファイル一覧に表示されない。
-
フィールド セキュリティ プロファイルの作成
- フィールド セキュリティを有効にしたフィールドを含むソリューションを開く
- ソリューション エクスプローラーで［フィールド セキュリティ プロファイル］をクリックする。
- メニューバーで［新規］をクリックする。
- 新しいプロファイルの名前・説明を入力する。
- ツールバーの［保存］をクリックする。
-
フィールド セキュリティ プロファイルにユーザ・チームを追加
- フィールド セキュリティ プロファイルのナビゲーション ウィンドウで［ユーザ］or［チーム］をクリックする。
- メニュー バーの［追加］をクリックする。
- プロファイルに追加するユーザ・チームを選択する。
- ［選択］をクリックし［選択したレコード］ボックスに追加。
- ［追加］をクリックする。
- 手順を繰り返してプロファイルにユーザ・チームを追加する。
-
フィールドのアクセス許可の設定
- フィールド セキュリティ プロファイルのナビゲーション ウィンドウで［フィールドのアクセス許可］をクリックする。
- アクセス許可を変更するフィールドを選択する（複数選択可能）。
- メニューバーの［編集］をクリックする。
- アクセス許可の種類（［読み取りを許可］、［更新を許可］、［作成を許可］）の
ドロップダウンリストから［あり］or［なし］を選択する。 - ［OK］をクリックする。
- 手順を繰り返してフィールドにアクセス許可を設定する。
-
［フィールド セキュリティ プロファイル］ツール バーの［保存して閉じる］をクリックする。
特定のレコードのフィールドに対してユーザに許可されるアクセスは、
以下の 3 種類のセキュリティの対象と制御方法を AND したものになる。
| 対象 | 制御方法 | |
|---|---|---|
| 1 | エンティティ | セキュリティ ロール |
| 2 | レコード | 共有 |
| 3 | フィールド | フィールド セキュリティ プロファイル |
-
セキュリティ ロール・共有は、フィールド セキュリティを拡張しない。
-
共有はセキュリティ ロールのスコープを拡大するが、
- ユーザのアクセス許可は拡張しない。
- アクセス レベルは拡張しない（ユーザ レベル以上が持っていない特権は変更できない）。
-
フィールド セキュリティは
- レコードの特権（アクセス許可）を拡張しない。
- レコードのアクセス レベルを拡張しない。
補足（ここが本ページで最も重要）: CRM セキュリティモデルの作成で
複数のセキュリティ ロールは OR で合成されると述べたが、
層をまたぐと AND になる。
つまり、（ロール OR ロール …）AND 共有 AND フィールド セキュリティという構造である。したがって、
- どれか 1 つで拒否されれば見えない
- どの層も、上位の層より広い権限を与えることはできない
これは Azure 条件付きアクセスの
「複数ポリシーは AND で合成され、ブロックが常に優先される」という規則と
同じ考え方である。
権限のトラブルシューティングでは、
どの層で落ちているかを順に確認するのが定石になる。
- アクセス チームを作成し同僚をレコードに簡単にリンクすることで通常持たないアクセス許可を与える。
-
共有（アクセス レベルは適用されない）に似ているが、
こちらの方が中央のアクセス許可の定義を容易に適用可能。
アクセス チーム テンプレートは、以下の共有の問題を解決する。
- 共有の度に、共有するユーザに［共有］ダイアログ ボックスを使用してアクセス許可を付与する必要がある。
- ［共有］ダイアログ ボックスを開かないと、共有されたレコードに誰がアクセスできるか判断できない。
［共有］ダイアログ ボックスを開く必要がない。
-
システム カスタマイザーの用意したアクセス許可セットを使用して、
共有するユーザに迅速にアクセス許可を付与することができる。 -
迅速に、共有レコードにアクセス可能なユーザの確認と編集ができる。
- レコードに対するアクセス権を持つユーザの一覧を出力できる。
- 特権を持つユーザは、一覧からのユーザとアクセス権を変更できる。
補足（共有の何が問題だったか）: 共有の問題は
アクセス許可の組み合わせを都度その場で決める点にあった。
- 人によって付与する権限がバラつく（統制できない）
- 誰に共有したかがレコードを開かないと分からない（可視性がない）
アクセス チーム テンプレートは、
権限セットを管理者が事前に定義し、
フォーム上のサブグリッドで一覧できるようにすることで、
この 2 点を解決している。
「案件チーム」「サポート案件の関係者」といった
レコード単位のメンバー管理が典型的な用途になる。
- エンティティのアクセス チームを有効にして変更を公開する。
- アクセス チーム テンプレートを作成してアクセス許可を定義する。
- エンティティのフォームでユーザ追加して表示するサブグリッドを追加する。
- このサブグリッドは、1 つのアクセス チーム テンプレートに関連付けられる。
-
名前
-
説明
-
アクセス権
- 削除
- 追加
- , etc（セキュリティ ロールや共有で称されるアクセス許可と同じ）
-
対象エンティティ
- 1 つのエンティティに複数のアクセス チーム テンプレートを作成できる。
- この最大値は、PowerShell で変更可能
-
MaxAutoCreatedAccessTeamsPerEntity：
エンティティに対して定義可能なアクセス チーム テンプレート数（既定値は 2） -
MaxEntitiesEnabledForAutoCreatedAccessTeams：
自動生成されたアクセス チームに対して有効にできるエンティティ数？（既定値は 5）
-
補足（既定値が小さい理由）: 既定値が 2 / 5 と抑えめなのは、
アクセス チームがレコードごとにチームを自動生成する仕組みだからである。
対象エンティティを増やすほどチーム数が爆発的に増え、
CRM セキュリティモデルの作成で触れた
PrincipalObjectAccessテーブルの肥大化と同じ性能問題を招く。
上限の引き上げは、影響を見積もってから行うべき設定である。
- アクセス チームは、ユーザをサブグリッドに追加することで自動生成される。
-
この操作は "レコードにアクセス チーム メンバを追加する" と言う。
-
"アクセス チーム メンバを追加する" ユーザは、
- レコードに対する共有特権が必要。
- アクセス チーム テンプレートに含まれるすべてのアクセス許可が必要。
- 標準の共有でも、共有するユーザの持っている以上のアクセス許可は付与できない。
-
"アクセス チーム メンバに追加される" ユーザは、
- アクセス チーム テンプレートに含まれるすべてのユーザ レベルのアクセス許可が必要。
- 標準の共有では、共有されるユーザの持っている以上のアクセス許可を付与できる。
-
アクセス チーム テンプレートに共有特権があると、
すべてのアクセス チーム メンバは、アクセス チーム メンバを追加できるようになる。 -
アクセス チームにより、
- レコード レベルでは、各ユーザと個別に共有されなくなる。
- しかし、エンティティ レベルでは、各ユーザと個別の共有が可能のままである。
エンティティのコマンド バーをカスタマイズして、共有用のボタンを削除 / 非表示にすることはできる。
これは、エンティティのコマンド バーを定義するリボン XML のカスタマイズにより行う。
-
移行メモ（正誤）: 元ページの「レコードにレコードに対する共有特権」は
「レコードに」の重複と判断し、修正した。
補足（共有との違いが 1 点ある）: 上記で対比されているとおり、
- 標準の共有 — 共有される側が持っていない権限も付与できる
- アクセス チーム — 追加される側がユーザ レベルの権限を持っている必要がある
という違いがある。
つまりアクセス チームはより厳格で、
「そのエンティティを扱う資格のある人だけを、
個別のレコードに追加する」という使い方になる。
全く権限のない人に見せる用途には使えない。
-
アクセス チーム名は、
"レコード GUID" + "サブグリッドに関連付けられたアクセス チーム テンプレートの GUID" になる。 -
これにより生成されるチームの
- 種類は、アクセス チームとなり、
- ［システムで管理されている］プロパティは、"はい" に設定される。
- この設定のチームは、チームの既定のビューでは表示されない。
3 つのレベルで監査機能を有効にできる。
- 有効化：［設定］→［管理］→［システムの設定］→［監査］
- 用途：システム レベルの変更が監査対象になり、不正な変更、誤った変更の判断・修正を支援する。
- 有効化：
- エンティティのプロパティで監査プロパティを選択する（CRM エンティティのカスタマイズ）。
- また、コレに加えて組織レベルの有効化も必要。
- 用途：エンティティの変更が監査対象になり、不正な変更、誤った変更の判断・修正を支援する。
- 有効化：
- フィールドのプロパティで監査プロパティを選択する（CRM フィールドのカスタマイズ）。
- また、コレに加えてエンティティ レベル、組織レベルの有効化も必要。
- 用途：フィールド値の変更が監査対象になり、不正な変更、誤った変更の判断・修正を支援する。
補足（3 段の AND）: 監査もまた AND で構成されている。
フィールドの監査を有効にしても、
上位のエンティティ・組織レベルが無効なら記録されない。
「監査を有効にしたのにログが出ない」という場合は、
上位のレベルを確認するのが先になる。
- 監査を有効にすると、変更が追跡され、SQL Server の監査テーブルに保存される。
- すべての監査エントリは、イベント種類、ユーザ、日付・時刻を記録している。
監査イベントは以下で確認できる。
-
監査履歴
- ［監査履歴の表示］で表示
- レコード単位にレコード フォームのナビゲーション バーを使用してアクセスする。
- レコード フォームが表示されなくなるので、削除されたレコードに対しては使用できない。
-
監査概要ビュー
- ［監査の概要の表示］で表示
- 組織レベル、エンティティ レベル、レコード レベルのイベントとデータ変更の概要が表示される。
- 変更の概要（CRUD）のみ表示され、変更の詳細（データ値）は表示されない。
補足（削除されたレコードの監査が見られない）: 「レコード フォームが
表示されなくなるので、削除されたレコードに対しては使用できない」というのは、
監査機能としては大きな制約である。
「誰が消したか」を追うには監査概要ビューを使うことになるが、
こちらは変更の詳細（消えた値）が見られない。
削除された内容まで追跡する要件がある場合は、
論理削除（無効化）で運用するなどの設計上の対処が要る。
CRM セキュリティモデルの作成で
ユーザが物理削除できない仕様になっているのも、同種の配慮と言える。
-
監査データへのアクセス許可
- 監査データのアクセスには監査の特権が必要になる。
- この特権の設定
セキュリティ ロールの［コア レコード］タブから設定する。- ［監査履歴の表示］
- ［監査の概要の表示］
- 既定のセキュリティ ロールと監査の特権
一部のセキュリティロールでは、以下の監査の特権が既定で有効になっている。- "上司" レベル以上のセキュリティ ロール：［監査履歴の表示］が有効
- システム管理者ロールのセキュリティ ロール：唯一、［監査の概要の表示］が有効
-
エンティティ、レコード、フィールドの監査データへのアクセス許可
-
エンティティとレコード単位での監査の許可は設定できないが、
レコード フォームが表示できなければレコードは監査できないので、
合わせてエンティティとレコードの読み取りアクセス許可が必要になる。 -
当然、フィールド セキュリティも考慮される。
フィールド セキュリティで読み取りアクセス許可が無い場合、
そのフィールドの監査データにはアクセスできない。
合わせてフィールド セキュリティの読み取りアクセス許可が必要になる。
-
補足: 監査データにも同じ AND のルールが適用されるという点が重要である。
「監査ログ経由でフィールド セキュリティを迂回する」ことができないよう
設計されている。
前述の表示・編集方法に「監査ログ」が
明記されているのと同じ趣旨である。
-
SQL Server のパーティショニングの機能を使用して、
監査ログが四半期の単位でパーティション分割されている。 -
これにより、削除やアーカイブのスライディング ウィンドウ実装が可能。
-
最も古い監査ログから削除やアーカイブのスライディング ウィンドウ操作が可能。
補足: 監査ログは放置すれば増え続けるため、
CRMの展開の管理とトラブルシューティングの
システム ジョブと同様に、保持期間を決めて削除する運用が必要になる。
四半期単位のパーティションは、
古いパーティションごと切り離すことで削除を高速に行うための設計である。
Tags: Dynamics CRM
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。