アクセスを制御する階層セキュリティ
階層セキュリティ モデルは、部署、セキュリティ ロール、共有、およびチームを使用する、既存のセキュリティ モデルの拡張機能です。 これは、他のすべての既存のセキュリティ モデルで使用できます。 階層セキュリティは、組織のレコードに対してよりきめの細かいアクセスを実現し、保守費用の低減を支援します。
たとえば、高度なシナリオでは、複数の部署の作成から始めて、次に階層セキュリティを追加できます。 この追加されたセキュリティは、多くの部署が必要としているところの、より少ない保守費用でよりきめ細かいアクセスを達成します。
管理者階層およびポジション階層セキュリティ モデル
階層には、マネージャー階層 と ポジション階層 のセキュリティ モデルを使用できます。 マネージャー階層では、マネージャーは部下と同じ事業単位内にいるか、または部下の事業単位の上位の部署にいなければ、部下のデータにアクセスできません。 ポジション階層では、部署全体のデータにアクセスできます。 財務管理者の場合は、自分の部署以外のデータ アクセスを防止するために、管理者階層モデルを好む場合があります。 ただし、自分が顧客サービス組織の一部であり、管理者が異なる部署で対処するサービス サポート案件にアクセスすることを望んでいる場合は、ポジション階層が正しく機能する場合があります。
注意
階層セキュリティ モデルはデータに対して特定のレベルのアクセスを行うと同時に、セキュリティ ロールなどの他のフォームのセキュリティを使用して追加のアクセスを実施できます。
管理者階層
管理者階層セキュリティ モデルは管理チェーン構造または直接レポート構造に基づいています。この構造では、管理者の関連付けとレポートの関連付けが、システム ユーザー テーブルの 管理者 フィールドを使用して確立されます。 このセキュリティ モデルでは、管理者はアクセス権を持っているデータにアクセスできます。 マネージャーは、直属の部下の代わりに作業を実行したり、承認が必要な情報にアクセスすることができます。
注意
管理者階層セキュリティ モデルでは、管理者は、ユーザーが所有するまたはユーザーがメンバーになっているチームが所有するレコードに対して、またユーザーまたはユーザーがメンバーになっているチームと直接共有するレコードに対してアクセスできます。 管理チェーン外のユーザーが、読み取り専用アクセス権を持つ直接レポート ユーザーとレコードを共有している場合、直接レポートの管理者は共有レコードへの読み取り専用アクセス権のみを持ちます。
部署全体の所有権を記録する オプションを有効にすると、マネージャーはさまざまな部署からの直属の部下を持つことができます。 次の環境データベースの設定を使って、部署の制限を削除できます。
ManagersMustBeInSameOrParentBusinessUnitAsReports
既定値 = True
これを false に設定でき、マネージャーの部署は直属の部下の部署と同じである必要はありません。
管理者階層セキュリティ モデルのほかに、レポートのデータを表示するには、テーブルに対して少なくともユーザー レベルの読み取り特権を持つ必要があります。 たとえば、管理職にサポート案件テーブルに対する読み取りアクセス権がない場合は、管理職は自分たちのレポートがアクセスするサポート案件を表示できません。
管理者の同じ管理チェーンにおける間接レポートについて、管理者は間接レポートのデータに読み取り専用のアクセス権を持ちます。 直接レポートについては、管理者はレポートのデータに対する Read、Write、Append、AppendTo のアクセス権を所有しています。 管理者階層のセキュリティ モデルを説明するために、以下の図を参照してください。 CEO は、営業担当部長データとサービス担当部長データを読み取りまたは更新できます。 しかし、CEO が読むことができるのは、営業マネージャーのデータとサービス マネージャーのデータ、そして営業とサポートのデータのみです。 マネジャーがアクセスできるデータ量は、深さ でさらに制限できます。 深度は、管理者がレポートのデータに対して何階層まで読み取り専用でアクセスできるかを制限するために使用されます。 たとえば、深さを 2 に設定した場合、CEO は営業担当部長、サービス担当部長、営業およびサービス マネージャーのデータを見ることができます。 ただし、CEO は営業データやサポート データを表示できません。
直接レポートのテーブルへのアクセス権が管理者よりも深い場合、管理者は直接レポートがアクセス権を持つ一部のレコードを表示できない場合があることに注意してください。 次の例は、この点を示しています。
一つの部署に次の 3 名のユーザーがいます: ユーザー 1、ユーザー 2、ユーザー 3。
ユーザー 2 はユーザー 1 の直接レポートです。
ユーザー 1 とユーザー 3 は、取引先企業テーブルのユーザー レベルの読み取りアクセス権を持ちます。 このアクセス レベルでは、ユーザーは、ユーザーが所有しているレコード、ユーザーが共有しているレコード、ユーザーがメンバーになっているチームが共有しているレコードにアクセスできます。
ユーザー 2 は、取引先企業テーブルの部署レベルの読み取りアクセス権を持ちます。 このアクセスによって、ユーザー 2 はユーザー 1 とユーザー 3.が所有する取引先企業すべてを含む、部署のすべての取引先企業を表示することができます。
ユーザー 2 の直属の上司としてのユーザー 1 は、ユーザー 2 が所有または共有する取引先企業 (他のユーザー 2 チームが所有または共有する取引先企業を含む) へのアクセス権を持ちます。 ただし、直接レポートがユーザー 3 の取引先企業へのアクセス権がある可能性がありますが、ユーザー 1 はユーザー 3 の取引先企業に対するアクセス権を持ちません。
ポジション階層
ポジション階層は、管理者階層のような、直接レポート構造に基づいていません。 ユーザーは、別のユーザーのデータにアクセスするために、そのユーザーの実際の管理者になる必要はありません。 管理者の場合は、組織内のさまざまな職位を定義し、職位をポジション階層に配置します。 次に、特定のポジションにユーザーを追加します。すなわち、ユーザーに特定のポジションを タグ付け します。 ユーザーには特定の階層の 1 つポジションのみをタグ付けできますが、1 つのポジションを複数のユーザーに使用できます。 階層内の高いポジションにいるユーザーは、直接の上位パス内の低いポジションにいるユーザーのデータにアクセスできます。 直接の高いポジションは、直接の上位パス内の低いポジションのデータに対して、Read、Write、Append、AppendTo のアクセス権を所有します。 間接の高いポジションは、直接の上位パス内の低いポジションのデータに対して、読み取り専用のアクセス権を所有します。
上位パスの概念を説明するために、次の図を参照してください。 営業マネージャー ポジションは営業データにアクセスできるが、異なる上位パスにあるサポート データにはアクセスできません。 サービス マネージャーのポジションも同様です。 営業パスにある営業データにはアクセスできません。 管理者階層と同様に、高いポジションがアクセスできるデータの量を 深さ を使用して制限できます。 深さのパスは、高いポジションが読み取り専用のアクセスをできる深さのレベルを、直接の上位パス内の低いポジションのデータに制限します。 たとえば、深さを 3 に設定した場合、CEO のポジションは、営業担当部長やサービス担当部長から営業やサポートのポジションに至るまで、データを見ることができる。
注意
ポジション階層セキュリティでは、高いポジションのユーザーは、低いポジションのユーザーが所有するまたはユーザーがメンバーになっているチームが所有するレコードに対して、またユーザーまたはユーザーがメンバーになっているチームと直接共有するレコードに対してアクセスできます。
高いレベルにいるユーザーは、ポジション階層セキュリティ モデルに加えて、低いポジションのユーザーがアクセスできるレコードを表示するためには、少なくとも 1 つのテーブルに対するユーザー レベルの読み取り特権を所有する必要があります。 たとえば、高いレベルにいるユーザーにサポート案件テーブルに対する読み取りアクセス権がない場合、そのユーザーは低いポジションのユーザーがアクセスできるサポート案件を表示できません。
階層セキュリティのセットアップ
階層セキュリティを設定するには、設定を更新するシステム管理者の権限があることを確認してください。
- ユーザー プロフィールを表示する で、次の手順に従います。
- 適切なアクセス許可を持っていない場合は、 システム管理者に問い合わせてください。
階層セキュリティは既定では無効になっています。 階層セキュリティを有効にするには、以下の手順を実行します。
環境を選択し、設定>ユーザー + アクセス許可>階層セキュリティの順に進みます。
階層モデルで、 要件に応じて、マネージャー階層モデルを有効にする または ポジション階層モデルを有効にするのいずれか を選択します。
重要
階層セキュリティを変更するには、階層セキュリティ設定の変更特権が必要です。
階層テーブル管理エリアでは、すべてのシステム テーブルは階層セキュリティが標準で有効になっていますが、選択したテーブルを階層から除外することができます。 階層モデルから特定のテーブルを除外するには、除外するテーブルのチェックボックスをオフにして、変更を保存します。
深さ を必要な値に設定して、管理者が自分たちのレポートのデータに対して読み取り専用のアクセスができるレベルの深さを制限します。
たとえば、深さが 2 の場合は、管理者は自分のアカウントと 2 レベルの深さまでのレポートのアカウントにのみアクセスできます。 この例では、管理者以外の営業担当副社長として Customer Engagement アプリにログインすると、次のようにユーザーのアクティブなアカウントのみが表示されます。
注意
階層セキュリティが営業担当部長に赤色の四角形内のレコードへのアクセスを付与している間は、営業担当部長が所有するセキュリティ ロールに基づいて追加のアクセスを使用できます。
階層テーブル管理 セクションでは、既定で、すべてのシステム テーブルの階層セキュリティが有効になっています。 階層モデルから特定のテーブルを除外するには、テーブル名の横にあるチェック マークをオフにして、変更を保存します。
重要
- これはプレビュー機能です。
- プレビュー機能は運用環境での使用を想定しておらず、機能が制限されている可能性があります。 これらの機能を公式リリースの前に使用できるようにすることで、顧客が一足先にアクセスし、そこからフィードバックを得ることができます。
管理者および職位の階層を設定する
管理者階層は、システム ユーザー レコード上の管理者関連付けを使用して間単に作成されます。 ユーザーの上司を指定するには、管理者 (ParentsystemuserID) 検索フィールドを使用します。 ポジション階層を作成している場合は、ユーザーにポジション階層の特定のポジションをタグ付けすることもできます。 次の例では、営業担当者が管理者階層の営業課長に直属し、またポジション階層の営業ポジションを所有しています。
ユーザーをポジション階層の特定のポジションに追加するには、以下に示すように、ユーザー レコードのフォームの ポジション という名前の検索フィールドを使用します。
重要
ユーザーをポジションに追加したり、ユーザーのポジションを変更するには、ユーザーのポジションの割り当て 特権が必要です。
ユーザー レコードのフォーム上のポジションを変更するには、ナビゲーション バーで その他 (…) を選択し、別のポジションを選択します。
職位階層を作成するには:
環境を選択し、設定>ユーザー + 管理者>ポジションの順に進みます。
ポジションごとに、ポジションの名前、ポジションの親、および説明を入力します。 このポジションのユーザーという名前の検索フィールドを使用して、ユーザーをこのポジションに追加します。 次の画像は、アクティブなポジションを含むポジション階層の例です。
有効なユーザーと、その対応する位置の例を次の画像に示します。
無効なユーザーステータスを持つ直属の部下が所有するレコードを含めるか除外する
マネージャーは、2024 年 1 月 31 日以降に階層セキュリティが有効になっている環境で、無効化されたステータスの直属部下のレコードを確認できます。 他の環境の場合、無効ステータスの直属の部下のレコードはマネージャーのビューに含まれません。
無効ステータスの直属の部下のレコードを含めるには:
- OrganizationSettingsEditor ツールをインストールします。
- AuthorizationEnableHSMForDisabledUsers 設定を true に更新します。
- 階層モデルを無効にします。
- 再度有効にします。
無効ステータスの直属の部下のレコードを除外するには:
- OrganizationSettingsEditor ツールをインストールします。
- AuthorizationEnableHSMForDisabledUsers 設定を false に更新します。
- 階層モデルを無効にします。
- 再度有効にします。
注意
- 階層モデリングを無効にして再度有効にすると、システムがマネージャー レコード アクセスを再計算する必要があるため、更新に時間がかかることがあります。
- タイムアウトが発生した場合は、階層テーブル管理 リストの下のテーブルの数を減らし、マネージャーが表示する必要があるテーブルのみを含めるようにします。 タイムアウトが続く場合は、サポート チケットを送信してサポートをリクエストしてください。
- 無効ステータスの直属部下のレコードは、これらのレコードがアクティブな別の直属部下と共有されている場合に含まれます。 これらのレコードを除外するには、共有 を削除します。
パフォーマンスに関する考慮事項
パフォーマンスを向上するために、以下のことをお勧めします。
管理職とポジションの有効な階層セキュリティを 50 ユーザー以下に維持します。 階層には、管理者/ポジションの下に 50 を越えるユーザーを入れることができますが、深さの設定を使用して読み取り専用アクセスのレベル数を削減し、この制限を使用して管理者/ポジションの下の有効なユーザー数を 50 ユーザー以下に削減できます。
階層のセキュリティ モデルを既存のセキュリティ モデルと組み合わせて、複雑な設定を行うことができます。 多数の部署を作成しないようにし、代わりに、少ない部署と階層セキュリティを作成します。