Skip to content

MS_CRMSecurityModel

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

CRM セキュリティモデルの作成

概要

ロール ベース

職務内容に即したアクセス許可を定義するロール ベースのセキュリティ モデルを適用できる。

移行メモ（正誤）: 元ページの「セキュリ モデル」は
「セキュリティ モデル」の脱字と判断し、補った（以下同様の箇所も同じ）。

  • 組織・チーム・ユーザ

    • 組織・チームはグループ的なもの。

    • 組織にはユーザ / チームを追加できる。

    • チームにはユーザを追加できる。

    • 組織・チーム・ユーザの作成

      • ユーザを作成する。
      • 組織構造を定義する部署を作成する。
      • チームを作成する。

  • セキュリティ ロールを作成する。

    • 特権（アクセス許可）の設定
    • アクセス レベルの設定

  • 組織・チームにセキュリティ ロールを割り当てる。

    • 組織にユーザを追加し、組織にセキュリティ ロールを割り当てる。

    • チームにユーザを追加し、チームにセキュリティ ロールを割り当てる。
      チームを使用し 1 ～複数の部署のユーザをグループ化できる。

    • ユーザ個人にセキュリティ ロールを割り当てる。

  • グループ的なものである組織・チームはソリューションに追加できない仕様。
    ちなみに、セキュリティ ロールはソリューションに追加できる仕様。

移行メモ（正誤）: 元ページの「ユーザ個人にに」は「に」の重複と判断し、修正した。

レコードベース

レコードベースのセキュリティは、

  • 個々のレコードに対してアクセス権を使用することで提供される。
  • エンティティ特権が有効な場合にのみレコードのアクセス権が適用される。

補足（2 つのモデルの関係）: この 2 つは並列ではなく、直列である。

ロール ベース（特権 × アクセス レベル）
  ↓ ここを通った上で
レコード ベース（個々のレコードのアクセス権）

「エンティティ特権が有効な場合にのみレコードのアクセス権が適用される」
という一文がそれを示している。
つまり、ロールで許されていないものは、
個別に共有しても見えない。
トラブルシューティングでは、まずロール側を疑うのが定石になる。

特権

  • 特権（privilege）≒ アクセス許可
  • CRM では、Administrator 等の特別な権限ではなく単にアクセス許可を指している。
  • システム開始時に、580 を超える特権が事前に定義される。

エンティティ特権

エンティティに対して実行できる特権

エンティティとレコードに対するアクセス許可をグリッドで表現している。

  • タブ：エンティティのカテゴリ
  • 縦：エンティティ
  • 横：特権（アクセス許可）
特権（アクセス許可） 説明
1 作成 レコード作成
2 読み取り レコード表示
3 書き込み レコード変更
4 削除 レコード削除
5 追加 別のレコードと関連付け。
6 追加先 エンティティと関連付け。
7 割り当て レコードの所有権を移転。
8 共有 レコードのアクセス権を共有。
9 リペアレント エンティティに異なる親を割り当て。

補足（「追加」と「追加先」の違い）: 混同しやすいが、
関連付けの方向が違う。
A を B に関連付ける場合、

  • A 側に「追加」 の特権
  • B 側に「追加先」 の特権

の両方が必要になる。
後述の「複数のアクセス権が必要な操作」の表でも
この対が現れる。
「関連付けができない」という問い合わせでは、
片側だけ見て判断しないことが要点になる。

各エンティティで使用できる特権

エンティティに関連付けられない特権

https://msdn.microsoft.com/ja-jp/library/gg328200.aspx

UI操作

UI 操作は、複数のエンティティ特権を必要とする場合も多い。

  • 例えば、営業案件の作成は以下の特権（アクセス許可）が必要になる。

    • 作成
    • 読み込み

  • ガイドとして、エンティティ特権がない場合、ボタンが表示されなくなる。

補足: 「特権がないとボタンが表示されない」という挙動は
親切である一方、「メニューに項目が出てこない」という問い合わせの
大半が権限不足という状況を生む。
エラーが出ないぶん原因に気づきにくいので、
権限を疑う習慣が要る。

その他の特権

アプリケーションの機能に関する特権（アクセス許可）

  • 機能

    • 印刷
    • 重複レコードの統合
    • Excel にエクスポート
    • オフラインにする

  • 指定可能なアクセス レベル

    • "なし"
    • "グローバル（組織全体）"

  • 設定場所：
    一部、［コア レコード］タブの［その他の特権］

補足（情報持ち出しの統制点）: 「印刷」「Excel にエクスポート」
「オフラインにする」は、データを CRM の外へ出す操作である。
これらが独立した特権になっているのは、
内部統制や情報漏洩対策の観点で制御できるようにするためで、
CRMのクライアント要件の
「企業のポリシーによってオフラインでの使用がサポートされていない場合」
という記述に対応する。

アクセス レベル

  • 特権（アクセス許可）にはアクセス レベルを設定できる。
  • アクセス レベルは、特権（アクセス許可）がどの範囲の所有者に適用されるか的な制御をする。
アクセス レベル 説明
1 グローバル（組織全体） 部署階層レベルに関係なく、組織のエンティティ（機能・データ）を使用可能
通常は組織全体に対する権限を持つ責任者に対してのみ使用される。
2 ディープ（部署配下） 部署とその配下の部署のエンティティ（機能・データ）を使用可能
通常は配下の部署全体に権限を持つ責任者に対してのみ使用される。
3 ローカル（部署） 自部署のエンティティ（機能・データ）を使用可能
通常は部署全体に権限を持つ責任者に対してのみ使用される。
4 ベーシック（ユーザー） ユーザ・共有・チームのエンティティ（機能・データ）を使用可能
通常は営業やサービスの担当者に対して使用される。

補足（このモデルの要点）: 権限が
「何ができるか」（特権）× 「誰のデータに対してか」（アクセス レベル）
の 2 軸で表現されている点が Dynamics CRM のセキュリティ モデルの核心である。

例えば「営業案件の読み取り」という 1 つの特権でも、

  • グローバル → 全社の案件が見える（役員）
  • ディープ → 配下部署の案件が見える（部長）
  • ローカル → 自部署の案件が見える（課長）
  • ベーシック → 自分の案件だけ見える（担当者）

と、同じ特権のまま見える範囲だけを変えられる。
役職の階層と部署階層が対応する日本の組織構造とは相性が良い。

指定可能なアクセス レベル

  • 組織所有のエンティティには、"なし" or "グローバル（組織全体）"のアクセス レベルのみ指定可能。
  • ユーザ・チーム所有のエンティティには、5 つすべてのアクセス レベルを指定可能。

移行メモ: 上の表は 4 段階だが、本文は「5 つすべて」としている。
"なし" を含めて 5 つと数えていると思われる。
元ページの記載のまま残す。

  • 一部のアクセス レベルを使用できない特権も存在する。

    • ユーザレベルに設定できない特権（アクセス許可）

      • ユーザ
      • チーム
      • 設備 / 備品

    • ユーザレベルにしか設定できない特権（アクセス許可）

      • 保存されているビュー
      • ユーザ グラフ
      • ユーザ エンティティの UI 設定

セキュリティ ロール

セキュリティ ロールとは、特権（アクセス許可）・アクセス レベルのグループ化。

  • ロールベースのセキュリティ モデルで使用するセキュリティ ロールを使用する。

  • ユーザに 1 つ以上のセキュリティ ロールを割り当て
    ユーザに特権（アクセス許可）・アクセス レベルを付与する。

  • 1 ユーザに複数のセキュリティ ロールを割り当てられた場合、

    • セキュリティ ロールの "OR"（合計）の特権（アクセス許可）・アクセス レベルが付与される。
    • 同じアクセス許可がある場合、アクセスレベルは高い方を使用できる。

  • これにより、組織、職務、役職、プロジェクトの一時的ロール等に基づいて
    ユーザへ与える特権（アクセス許可）・アクセス レベルの管理が容易になる。

移行メモ（正誤）: 元ページの「アクセク許可」は「アクセス許可」、
「一次的ロール」は「一時的ロール」、
「管理が用意になる」は「管理が容易になる」の誤記と判断し、修正した
（「アクセク許可」は本ページ内の他の箇所も同様に修正）。

補足（OR 合成であることの含意）: 複数ロールが OR で合成される
ということは、「あるロールで禁止する」ということができないことを意味する。
Azure 条件付きアクセスが
**ブロック優先（AND 合成）**であるのと対照的である。

したがって、権限を絞りたい場合は
強いロールを外すしかなく、
「基本ロール + 制限ロール」という設計は成立しない。
ロール設計では足し算だけで組み立てる必要がある。

ソリューションとセキュリティ ロール

ソリューションには、ルート部署のセキュリティ ロールのみ含めることができる。

既定のセキュリティ ロール

ロール 説明
1 最高経営責任者 会社レベルで組織を管理するユーザー。
2 顧客サービス課長 地域またはチーム レベルで顧客サービス活動を管理するユーザー。
3 顧客サービス担当者 (CSR) すべてのレベルの顧客サービス担当者 (CSR)。
4 代理人 別のユーザーに代わって行動することを許可されたユーザー。
5 マーケティング課長 地域またはチーム レベルでマーケティング活動を管理するユーザー。
6 マーケティング プロフェッショナル すべてのレベルのマーケティング活動に関与するユーザー。
7 営業課長 地域またはチーム レベルで営業活動を管理するユーザー。
8 営業担当者 任意のレベルの営業担当者。
9 フィールド サービス課長 サービスの予定を計画するユーザー。
10 フィールド サービス担当者 サービスを管理するユーザーで、リソースと作業時間を必要とするユーザー。
11 サポート ユーザー 顧客サポート エンジニアであるユーザー。
12 システム管理者 任意のレベルでプロセスを定義して実行するユーザー。
13 システム カスタマイザ Microsoft Dynamics CRM のエンティティ、属性、関連付け、およびフォームをカスタマイズするユーザー。
14 マーケティング担当副社長 部署レベルでマーケティング活動を管理するユーザー。
15 営業担当副社長 部署レベルで販売組織を管理するユーザー。

補足: 既定ロールが
マーケティング /
営業 /
サービス の 3 モジュールと
課長 / 担当者という 2 階層で構成されている点に注目したい。
Dynamics CRM の 3 モジュール構成が、
そのままロール設計にも反映されている。

システム管理者

すべての既定のロールを変更可能。

その他、以下の特別な性質を持つ。

  • 少なくとも 1 人がシステム管理者をもつ必要がある。

  • エンティティ、機能に対するグローバル（組織全体）レベルの全アクセス許可。

  • ただし、一部ベーシック（ユーザー）レベルだけが適用される例外がある。

    • 保存されているビュー
    • ユーザ グラフ
    • ユーザ エンティティの UI 設定

  • 追加されたカスタムエンティティに（組織全体）レベルのアクセス許可
    （このアクセス許可は、システムカスタマイザーにも付与される）

  • システム管理者フィールド セキュリティのメンバ

    • セキュリティで保護されたすべてのフィールドに対する全アクセス許可
    • フィールド セキュリティ プロファイルを管理し、
      フィールド レベル セキュリティを実装。

用例

以下のケースで使用する。

  • 経験の少ない小規模な組織で使用。
  • プロジェクトの初期段階のデモ・実証で使用。

変更

ビジネス要件から変更が必要な場合、以下の 3 つの変更方法がある。

  • 既定のロールを変更
    ユーザ・チームに割り当てる既定のロールを変更

  • 既定のロールをコピー
    ロールのコピー後にカスタマイズに使用する。

    • 新しい名前を指定可能。
    • 部署は指定不可能（同じ部署）
    • 継承されたロールのコピーも作成可能。
    • コピー元とコピー先のロールに関連は無い。
    • コピー元との比較（差分の確認）が可能。
      既定のロールのカスタマイズ時に便利。

  • ロールを新規作成

    • 主要なロールに追加する特権（アクセス許可）を持つロールを作成する。
    • チームにセキュリティ ロールを割り当てれば、
      ロールを持つユーザの識別が容易、管理し易い。

  • 注意：セキュリティ ロールは部署を変更できない。

補足（既定ロールを直接変更しない方がよい理由）: 3 つの方法のうち、
**「既定のロールをコピーしてカスタマイズ」**が実務では無難である。
既定ロールを直接変更すると、

  • 製品の更新で既定ロールが変更された場合に競合しうる
  • 元に戻せなくなる（比較の基準が失われる）
  • 新規に作った組織との差分が追えなくなる

という問題が生じる。
本ページが「コピー元との比較（差分の確認）が可能」と
わざわざ挙げているのは、この運用を前提にしているためと読める。

部署

  • 階層構造でアクセス許可のスコープを制御する境界として機能する。
  • レポートのクエリで部署を使用して結果をフィルタするなどができる。

ルート部署

  • 組織を作成する際に展開プロセスにより最初の部署として作成される。

    • 展開プロセス

  • ルート部署の特徴

    • 組織と同じ名前で作成される。
    • この名前は後に変更できる。
    • 1 つだけ存在する。
    • 上位部署は作成できない。
    • 削除や無効化はできない。
    • 他の部署は、ルート部署の派生。

作成

ポイント

  • 小規模：1 部署でも OK

  • 大規模：個別の部署が必要になることもある。

    • 会社の組織図を参考にする（ただし、複製では NG）。
    • 部署を、事業部、部門、子会社などに読み替えることもできる。

  • 部署を、スキル・役職・責任などユーザのグループに読み替えることもできる。
    （ただし、セキュリティ ロールを併用することもできる）

補足（「組織図の複製では NG」の意味）: 部署は
アクセス許可のスコープを決める境界であって、組織図そのものではない。
組織図をそのまま写すと、

  • 組織変更のたびに部署の再編が必要になる（後述のとおり、
    部署を移動するとセキュリティ ロールが削除される）
  • 階層が深くなり、ディープ／ローカルの使い分けが煩雑になる

という運用負荷を招く。
「データの見える範囲を分ける必要があるか」で切るのが原則で、
見える範囲が同じなら 1 部署にまとめてよい。
横断的なグループ化は次節のチームで行う。

方法

Microsoft Dynamics CRM
［設定］→［管理］→［部署］→［新規］

  • 入力
    • 新しい部署の名称
    • 上位の部署
    • , etc.

更新

ポイント（更新）

ルート部署を除いて部署は移動・削除（無効化）が可能。

方法（更新）

Microsoft Dynamics CRM
［設定］→［管理］→［部署］

  • 移動の場合、

    • 部署を選択し、メニューバーから［その他の操作］→［上位の部署の変更］
    • 部署をダブルクリックで開き、ツールバーから［操作］→［上位の部署の変更］
    • ※
      • 下位部署も合わせて移動される。
      • 循環する関係になるように移動できない。
      • 継承されていたセキュリティ ロールは削除される。

  • 無効化の場合、

    • 部署を選択し、メニューバーから［その他の操作］→［有効にする］・［無効にする］
    • 部署をダブルクリックで開き、ツールバーから［操作］→ 有効または無効的な。
    • ※
      • 再編準備などで使用する（作成後直ちに無効に、再編後に有効化）。
      • ユーザが所属する部署が無効化されると、ユーザは CRM にアクセスできなくなる。

  • 削除の場合、

    • 下位部署が存在しない状態にする。
      • 下位部署を削除する。
      • 下位部署の上位部署を変更する。
    • 次に無効化（非アクティブ化）する。
    • Microsoft Dynamics CRM →［設定］→［管理］→［部署］
      ビューから［非アクティブな部署］を選択、対象の部署を開き、コマンドバーで［削除］をクリック。
    • ※
      • 削除した場合、再び有効化できないので注意。

部署とセキュリティ ロール

  • セキュリティ ロールは部署内で作成・保持される。
  • セキュリティ ロールは部署を変更できない。
  • 部署のセキュリティ ロールは派生の下位部署に継承される（継承されたロール）。

ユーザ管理

  • 大規模な組織では日常的に行われている（入・退社、移動・昇進）。

  • ユーザ管理を便利にする多数の機能があり、セキュリティ管理とユーザ管理が分離されている。

  • 担当部署

    • 中央の運営機関
    • 支社・部門のシステム管理者・管理職

認証機構

Dynamics CRM 自体は認証機構を提供しない。

展開によって、以下の認証機構を使用する。

参考：クレームベース認証の用語

Online

  • Windows Live ID から、MOSP（Microsoft Subscription Program）に変更。
  • 全てのサブスクリプションベース SaaS に単一の認証プラットフォームが提供される。

内部的には、Azure AD を

  • STS（Security Token Service）
  • IdP（Identity Provider）

として使用している。

移行メモ（正誤）: 元ページの「MicrosOft」は「Microsoft」の
大文字小文字の誤りと判断し、修正した。
また、Azure AD は現在 Microsoft Entra ID に改称されている。

オンプレ

  • Intranet 展開
    AD DS のみ使用可能。

  • Internet 展開
    AD FS やサードパーティ製の STS（Security Token Service）を使用可能。
    従って、任意の IdP（Identity Provider）を使用可能。

補足: 「Dynamics CRM 自体は認証機構を提供しない」というのは重要な設計判断である。
認証を外部（AD DS / AD FS / Entra ID）に委ね、
CRM は認可（誰が何を見られるか）に専念するという分離になっている。
CRMインターネット展開用の構成（IFD）が
認証方式の切り替えの話に終始するのも、この分離のためである。

ユーザ管理機能

  • ユーザ作成

  • ユーザ有効化 / 無効化

  • ユーザの上司特定

  • チーム作成

  • ユーザをチームに割当

  • ユーザ / チームへのセキュリティ ロール割当

  • 部署間でのユーザ / チームの移動

  • 既定で自身のプロフィールをメンテできないが、
    適切な特権（アクセス許可）を追加して、
    住所・電話番号などのメンテナンスを可能に設定可能。

ユーザの追加 / 削除

追加

追加時に自動的に有効になる。

削除

  • 削除はできない。無効化のみ可能。

  • サインイン不可、ライセンス不要になる。

  • ユーザ所有のレコードは、システム所有になる。

  • レコードを有効なユーザに再割当てする適切な方法の検討が必要。

  • 無効化予定のユーザとワークフロー / プロセスの関連を考慮
    例：サポート案件のルーティングや、電子メール メッセージの送信

    • 特定の情報カテゴリの重要度の高いサポート案件は常に特定の技術者に割当てられる。
    • 顧客のサポート案件は取引先企業レコードで指定されているサービス担当にルーティングされる。

補足（「削除できない」ことの意味）: ユーザを物理削除できないのは、
レコードの所有者・作成者・更新者としての参照が残るためである。
監査の観点では正しい設計だが、運用上は

  • 退職者のアカウントが増え続ける
  • ワークフローの割り当て先が無効ユーザのまま残る

という問題が起きる。
本ページが「無効化予定のユーザとワークフロー / プロセスの関連を考慮」と
注意しているのはこの点で、
退職処理の手順にワークフローの割り当て先の棚卸しを含める必要がある。

チーム管理

  • Windows のグループ的なもの。
  • 基本的には、組織階層は部署を使用。
  • プロジェクト チームなどはチームを使用。

種類

所有者チーム

  • レコードの所有者
  • 実際のセキュリティ ロールを割当てる。

アクセス チーム

  • レコードを所有できない。
  • セキュリティ ロールを割当られない。
  • 複数のチーム間でレコードを共有するためのチーム
  • 詳しくは「アクセス チーム テンプレート」を参照。

チーム種類の変換

  • 可能：所有者チーム → アクセス チーム
  • 不可能：所有者チーム ← アクセス チーム

メリット

セキュリティ ロール（チームの利点）

部署の組織階層に限定されない
チーム レベルのセキュリティ ロール モデルの管理が可能。

共有（チームの利点）

  • 個人・個人のより効率が良い。
  • 任意のユーザが自分に関連するチームの情報を参照できる。

管理が容易

  • チームのセキュリティ ロールの管理
  • チームのメンバシップの管理

ワークフロー / プロセス

  • チームをキューにリンク、チームのキューを作成できる。
  • 所有者チームがベーシック（ユーザー）アクセス レベルの読み込みアクセス許可を持っていれば
    チームはそのエンティティ レコードを所有でき、チームへのルーティングが可能になる。

既定のチーム

部署との関連

部署を作成すると、部署名と同じ名称の "既定のチーム" が自動的に作成される。

  • 削除不可能
  • 名称変更不可能
  • 部署異動不可能

メンバシップ

"既定のチーム" には、

  • 部署の全ユーザが含まれる。
  • 部署のメンバシップを変更した場合、
    "既定のチーム" のメンバシップも自動的に反映される。
  • "既定のチーム" のメンバシップは変更できない。

セキュリティ ロール（既定のチーム）

  • "既定のチーム" に派生しないセキュリティ ロールを割当てるときに便利。
  • "既定のチーム" に派生しないセキュリティ ロールを割当てたくない場合は、
    "既定のチーム" を所有者チームからアクセスチームに変換する。

チームの作成

  • チームは 1 つの部署と関連付けが可能。

  • チームはメンバとしてユーザを追加・削除可能。

    • ユーザの所属部署を問わず組織の任意のユーザを追加可能。
    • 1 人のユーザは複数のチームに所属可能。

  • チームのネスト モデルはサポートしていない。

  • チームの共有機能で、チーム内のユーザとレコード共有が可能。

補足（部署とチームの使い分け）: 前述の
「組織図をそのまま部署にしない」という原則と合わせると、
次のような役割分担になる。

部署 チーム
構造 階層（ツリー） フラット（ネスト不可）
所属 ユーザは 1 つだけ 複数に所属可
部署をまたぐ 不可 可
用途 見える範囲の境界 プロジェクト、横断的な役割

つまり、縦の統制は部署、横のつながりはチームという設計になる。
組織変更のたびに部署を触るのではなく、
変わりやすいものはチームで表現するのが運用しやすい。

チームのメンバシップ管理

チームから所属ユーザを選択

Microsoft Dynamics CRM
［設定］→［管理］→［チーム］

  • ［所属部署のチーム］からチームを選択
  • コマンド バーで［メンバーの追加］
  • ［チームにメンバーを追加］ダイアログで 1 ～複数のユーザを追加。

ユーザから所属チームを選択

Microsoft Dynamics CRM
［設定］→［管理］→［ユーザ］

  • ユーザ レコードをダブル クリック。
    • 削除：
      • ナビゲーション バーの［チーム］をクリック。
      • 所属チームの一覧から 1 ～複数のチームを選択し［メンバーの削除］をクリック。
    • 追加：
      • ナビゲーション バーの［既存のチームの追加］をクリック。
      • チーム名を入力するか、チームのレコードを入力して追加

共有

  • 他のユーザ / チームに単一レコードに特定のアクセス権を与える。

  • 特定のエンティティの全てのレコードでは無く個々のレコードに適用される。

  • 共有を設定するユーザと同じ特権（アクセス許可）で共有のアクセスが構成される。

  • セキュリティ ロールのようにシステム管理者でなくても、共有は全てのユーザが設定可能。
    （共有の設定は、セキュリティ ロールを通じてベーシック（ユーザー）のアクセス レベルが必要）

  • アクセス レベルは適用されない。

チームとの共有

ユーザとの共有と比べ以下のメリットがある。

  • より少ない作業で共有アクセスを許可できる。
  • チームのメンバシップ管理と連動する。
  • 性能が向上する（共有設定は PrincipalObjectAccess テーブルに格納）
  • 部署内部での共有は、既定のチームを使用する。

移行メモ（正誤）: 元ページの「性能のが向上する」は
「性能が向上する」の誤記と判断し、修正した。

補足（PrincipalObjectAccess が肥大化する）: 共有は
「誰が」「どのレコードに」「どの権限を」持つかを 1 行ずつ記録するため、
ユーザ単位で共有すると行数が
ユーザ数 × レコード数で膨らむ。
チーム単位で共有すれば チーム数 × レコード数に抑えられる。
本ページが「性能が向上する」としているのはこのためで、
大規模環境では性能問題の直接の原因になり得る。

ビュー、グラフ、ダッシュボードの共有

  • メリット

    • スキルのあるユーザがコンポーネントを作成・共有することで労力を最小限にできる。
    • ユーザはメンテナンスを続け、使用の許可や変更の許可ができる。
      • 個別のカスタマイズは独自コピーを作成して行うことができる。

  • 共有の設定

    • ［高度な検索］ダイアログ ボックスの［保存されているビュー］のセクションで個人用ビューを共有。
    • ［グラフ ウィンドウ］の［その他の操作］メニューで、個人用グラフを共有。
    • ・・・、個人用ダッシュボードを共有。

レコードの共有

  • レコードを選択した状態で、
  • コマンドバーの［その他のコマンド］をクリックし［共有］をクリック
  • 表示されているダイアログ ボックスで［ユーザまたはチームの追加］をクリック
  • 1 つ以上のユーザ / チームを選択リストに追加し、［追加］をクリック
  • ダイアログ ボックスに表示されているユーザ / チームに
    チェックボックスを使用して特権（アクセス許可）を割当てる。

セキュリティ ロールの割当て

［Microsoft Dynamics CRM］→［設定］→［管理］

ユーザへの割当て

→［ユーザ］

  • 追加（割当て）

    • ユーザのレコードを選択
    • コマンド バーで［その他のコマンド］→［ロールの管理］
    • ［ユーザー ロールの管理］ダイアログ ボックスで
      ユーザに割り当てるロールのチェック ボックスをオンにして［OK］をクリック。

  • 確認、削除

    • ユーザのレコードをダブル クリックして開く
    • ナビゲーション バーから［セキュリティ ロール］を選択してクリック
    • ロール一覧を確認、削除する場合はロール一覧からロールを選択し［ロールの削除］をクリック

チームへの割当て

→［チーム］

  • 追加（割当て）
    • チームのレコードを選択
    • コマンド バーで［その他のコマンド］→［ロールの管理］
    • ［チーム ロールの管理］ダイアログ ボックスで
      チームに割り当てるロールのチェック ボックスをオンにして［OK］をクリック。

部署からユーザ / チームを移動

Microsoft Dynamics CRM
［設定］→［管理］→

ユーザの移動

→［ユーザ］

  • ユーザのレコードを選択
  • コマンド バーで［その他のコマンド］→［部署の変更］
  • ［部署の変更］ダイアログ ボックスで部署を検索＆選択。

チームの移動

→［チーム］

  • チームのレコードを選択
  • コマンド バーで［その他のコマンド］→［部署の変更］
  • ［部署の変更］ダイアログ ボックスで部署を検索＆選択。

移動後の対応

  • 部署の移動時、ユーザ / チームのセキュリティ ロールは削除される。

  • 移動先の部署のセキュリティ ロールをユーザ / チームに割当てる。

  • ユーザ移動の際、チームのセキュリティ ロールが一部、残るケースがある。

    • チームのセキュリティ ロールで基本操作の特権が割当てられているとそのまま操作可能。
    • 通常は、チームのセキュリティ ロールで基本操作の特権を割当てないようにする。

  • チーム移動の際、ユーザのセキュリティ ロール > 特権が失われる。

    • チーム移動の後、チームのセキュリティ ロール > 特権を復元する。
    • 他のチームを作成し、チームのセキュリティ ロール > 特権を復元する。
    • ユーザ個別に、セキュリティ ロール > 特権を割当てる。

補足（人事異動のたびに権限が消える）: 「部署の移動時、
セキュリティ ロールは削除される」というのは、
運用でかなり効く仕様である。
4 月の組織変更で一斉に部署を動かすと、
全員の権限を割り当て直す必要が生じる。

これを避けるために、

  • 部署は見える範囲で切り、頻繁に変えない（前述）
  • 権限は部署ではなくチームに寄せる

という設計が推奨される。
本ページが繰り返しチームの利点を挙げているのは、この文脈で読める。

レコードベースのセキュリティ

アクセス権

  • アクセス権は、特定のレコードに関してユーザーに付与される「操作」に対する権限。
  • アクセス権と特権との関係では、特権が有効な場合にのみアクセス権が適用される。
アクセス権 説明
1 読み取り 参照可能
2 書き込み 更新可能
3 割り当て 割り当て可能
4 追加 指定レコードに別レコードを添付可能。
別レコードの追加アクセス権と指定レコードの追加先アクセス権が必要。
5 追加先 当該レコードを別レコードに追加可能。
（上記参照）
6 共有 共有可能
7 削除 削除可能

複数のアクセス権が必要な操作

操作 アクセス権
1 作成 作成？
読み取り
2 共有 共有
読み取り
3 割り当て 割り当て
読み取り
書き込み
4 レコードを追加する 読み取り
追加
5 レコードに追加する 読み取り
追加先

補足: すべての操作に 読み取りが含まれる点が要点である。
「更新はできるが参照できない」という設定はできない、ということで、
権限設計の際は読み取りを土台に積み上げる形になる。

CRM 追加のセキュリティ オプション

参考

本 Wiki 内

Tags: Dynamics CRM

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally