17個人セキュリティ・プロファイル

この章の内容は次のとおりです。

• 個人レコードの保護に関するガイドライン

• 職責範囲別の個人レコードを保護する方法

• 職責範囲別の個人レコードの保護

• HCM除外ルールの作成

• マネージャ階層によって個人レコードを保護するためのオプション

• 個人セキュリティ・プロファイルのマネージャ・タイプ

• 個人セキュリティ・プロファイルの階層コンテンツ

• 個人セキュリティ・プロファイルのPersonタイプ

• 「ジョブ・オファーの管理」タスクでジョブ・オファーのある候補者へのアクセスを保護する方法

• 個人セキュリティ・プロファイルでのカスタム基準

• カスタム基準の表と表示

• 個人セキュリティ・プロファイルのFAQ

個人レコードの保護に関するガイドライン

このトピックでは、公開個人レコードと管理個人レコード両方へのアクセスを保護する方法を説明します。推奨アプローチを使用すると、管理作業が最小化され、セキュリティ・パフォーマンスが向上します。

公開個人レコードの保護

公開個人レコードは、たとえば、すべての就業者が就業者ディレクトリでアクセスする必要があるレコードです。すべての就業者の表示事前定義済セキュリティ・プロファイルを使用してこのアクセスを提供します。すべての就業者の表示によって、次にアクセスできます。

• 現在アクティブまたは休止しているアサイメントを持つ従業員、派遣就業者、非就業者、および処理待ち就業者

• サインインしたユーザー自身のレコード

• 共有された個人情報

すべての就業者の表示では、先日付の個人レコードへのアクセスは提供されません。

ノート: すべての個人の表示セキュリティ・プロファイルでは、連絡先の個人レコードなどを含む、すべての個人レコードにアクセスできます。また、先日付の個人レコードにもアクセスできます。

マネージャ階層別の個人レコードの保護

マネージャは、マネージャ階層内の就業者の個人レコードにアクセスする必要があります。このアクセスを提供するには、マネージャ階層によって個人レコードを保護します。可能なかぎり、事前定義済マネージャ階層の表示セキュリティ・プロファイルを使用します。次の表に、マネージャ階層の表示セキュリティ・プロファイルの概要を示します。ここに表示される値は、これらのフィールドのデフォルト値でもあります。

フィールド	値
個人またはアサイメント・レベル	個人
階層内の最高レベル	最大なし
マネージャ・タイプ	ライン・マネージャ
階層コンテンツ	マネージャ階層

マネージャ階層の表示には、共有個人情報が含まれますが、先日付の個人レコードは含まれません。

非標準要件の場合は、個人セキュリティ・プロファイルを作成します。たとえば、企業内にカスタムの「プロジェクト・マネージャ」ジョブ・ロールがある場合は、そのマネージャ・タイプのセキュリティ・プロファイルを作成できます。これをHCMデータ・ロールに含めて、「プロジェクト・マネージャ」ジョブ・ロールを持っているすべてのユーザーにそのロールをプロビジョニングします。

職責範囲別の個人レコードの保護

個人レコードを職責範囲別に保護する場合、ユーザーがアクセスできるレコードのセットが動的に計算されます。計算は、ユーザーの割当済職責範囲に基づいて行われます。このアプローチには以下の利点があります。

• 管理する必要のある個人セキュリティ・プロファイルの数とHCMデータ・ロールの数が削減される。

• セキュリティ・パフォーマンスが向上する。

• 職責が変更された場合、セキュリティ・プロファイルを更新する必要がない。

たとえば、次の表の人事 (HR) 担当者について考えてます。これらの人事担当者は、同じジョブ・ロールを、様々なビジネス・ユニットの就業者に対して実行します。

HR担当者	ジョブ・ロール	ビジネス・ユニット
Fen Lee	人事担当者	USA1 BU
John Gorman	人事担当者	USA2 BU
Jenna Markum	人事担当者	USA3 BU

各ビジネス・ユニットの個人レコードへのアクセスを提供するには、次を実行します。

• 各HR担当者の職責範囲を定義します。この場合、職責のスコープは関連のビジネス・ユニットです。

• 職責範囲でアクセスを制限する単一の個人セキュリティ・プロファイルを作成します。この場合、「職責のスコープ」は「ビジネス・ユニット」です。

• 単一のHCMデータ・ロールを作成して、個人セキュリティ・プロファイルを含め、それを3人のすべてのHR担当者に割り当てます。

この図は、アプローチの概要を示しています。

職責範囲別に個人レコードへのアクセスを保護する場合、ユーザーは就業者のアサイメントをすべて参照できるわけではありません。かわりに、次のようになります。

• 現在の就業者の場合、承認済ユーザーは現在および休止アサイメントのみ参照できます。グローバル異動前にアクティブだったアサイメントなど、終了したアサイメントへのアクセスは回避されます。

• 退職済就業者の場合、承認済ユーザーは最近終了したアサイメントのみ参照できます。

最大3つの除外ルールを含めることもできます。これらのルールによって選択された個人レコードは、セキュリティ・プロファイルによって識別されたレコード・セットから除外されます。

インポート済候補者へのアクセスの保護

Oracle Talent Acquisition Cloudからインポートされた候補者のレコードへのアクセスを保護できます。個人セキュリティ・プロファイルの「基本詳細」セクションの「目的」フィールドを次のいずれかの値に設定します。

• インポート済候補者アクセス

• 個人およびインポート済候補者アクセス

インポート済候補者へのアクセスを職責範囲別またはマネージャ階層別に保護できます。

「採用統合」企業オプションが次のいずれかに設定される場合のみ、「目的」フィールドが使用できます。

• Oracle Integration Cloudと統合済

• 固定およびOracle Integration Cloudと統合済

それ以外の場合、「目的」フィールドは表示されません。

職責範囲別の個人レコードを保護する方法

職責範囲別に個人レコードを保護する場合は、スコープと職責タイプを選択します。スコープには、「ジョブ」や「事業所」などの単一の値、または「ビジネス・ユニットおよび部門」などの提供された値ペアを指定できます。このトピックでは、ユーザーが個人レコードにアクセスできるかどうかを見るため、これらのスコープ値がユーザーの職責範囲とどのように一致するかを説明します。

単一の職責スコープ値の使用

「部門」や「国」などの単一のスコープ値を選択する場合、ユーザーの職責範囲にはそのスコープ値を含める必要があります。そうでない場合、ユーザーは関連する個人レコードにアクセスできません。次の値を使用して個人レコードを保護するとします。

• 職責タイプ: 人事担当者

• スコープ: 部門

ユーザーは、職責タイプについて、次の表に示すように4つの職責範囲を持つことができます。

職責範囲	ビジネス・ユニット	部門
1	Vision BU 1	Vision Department 1
2	Vision BU 2	なし
3	Vision BU 3	Vision Department 3
4	なし	Vision Department 4

ユーザーは次の個人レコードにアクセスできます。

• Vision Department 1

• Vision Department 3

• Vision Department 4

ただし、ユーザーは、次の個人レコードにはアクセスできません。

• Vision BU 1 (Vision Department 1に属さない場合)

• Vision BU 2

• Vision BU 3 (Vision Department 3に属さない場合)

複数の職責スコープ値の使用

「国および部門」や「雇用主およびジョブ」など、2つの個別の値を組み合せた職責スコープ値を選択できます。これらのペア値の1つを使用して個人レコードを保護する場合、ユーザーの職責範囲にこれら両方の値が含まれている必要があります。そうでない場合、ユーザーは関連する個人レコードにアクセスできません。次の値を使用して個人レコードを保護するとします。

• 職責タイプ: 人事担当者

• スコープ: ビジネス・ユニットおよび部門

ユーザーは、職責タイプについて、次の表に示すように4つの職責範囲を持つことができます。

職責範囲	ビジネス・ユニット	部門
1	Vision BU 1	Vision Department 1
2	Vision BU 2	なし
3	Vision BU 3	Vision Department 3
4	なし	Vision Department 4

ユーザーは次の個人レコードにアクセスできます。

• Vision Department 1にも属するVision BU 1

• Vision Department 3にも属するVision BU 3

ただし、ユーザーは、次の個人レコードにはアクセスできません。

• Vision BU 2

• Vision Department 4

• Vision BU 1 (Vision Department 1に属さない場合、または部門がない場合)

• Vision BU 3 (Vision Department 3に属さない場合、または部門がない場合)

• Vision Department 1 (Vision BU 1に属さない場合)

• Vision Department 3 (Vision BU 3に属さない場合)

ユーザーの職責範囲には、Vision BU 1とVision Department 1のみではなく、Vision Location 1も含まれるとします。個人セキュリティ・プロファイルの条件が満たされているため、ユーザーは引き続き個人レコードにアクセスできます。ただし、3つの条件を満たすことを強制したり、提供外の値のペアを使用して個人レコードを保護したりする場合は、カスタム基準を作成する必要があります。たとえば、国、部門およびジョブの組合せを使用して個人レコードを保護するには、カスタム基準を使用する必要があります。

ヒント:職責範囲で識別したレコードから一部の個人レコードを除外するには、除外ルールを使用します。レコードを除外するためにカスタム基準を定義する必要はありません。

職責範囲別の個人レコードの保護

通常、マネージャ階層または職責範囲別に個人レコードへのアクセスを保護します。このトピックでは、職責範囲を使用する方法について説明します。

ノート: 職責範囲を使用する場合、個人レコードにアクセスする必要がある従業員に職責範囲を定義しておく必要があります。たとえば、人事担当者がある国の個人レコードを管理するとします。その担当者には、その国の職責範囲(人事担当者など)が必要になります。

個人セキュリティ・プロファイルの作成

1. 「ナビゲータ」→「自分のクライアント・グループ」→「ワークフォース・ストラクチャ」を選択します。

2. 「ワークフォース・ストラクチャ」作業領域の「タスク」パネル・タブで、「個人セキュリティ・プロファイルの管理」を選択します。

3. 「個人セキュリティ・プロファイルの管理」ページで、「作成」をクリックします。

4. 「個人セキュリティ・プロファイルの作成」ページの「基本詳細」セクションで、セキュリティ・プロファイルの名前を入力します。

5. 「職責範囲」セクションで、「職責範囲別保護」を選択します。

6. 「職責タイプ」の値を選択します。たとえば、「福利厚生担当者」または「組合代表」を選択します。

7. 「職責のスコープ」の値を選択します。

   「部門」や「ジョブ」などの単一の値を選択できます。または、「ビジネス・ユニットおよびジョブ」や「雇用主および事業所」など、値の組合せを選択できます。

   ノート: 「国」職責のスコープは、就業者アサイメントがある国ではなく、雇用主の国を意味します。

8. 必要に応じて、就業者タイプの選択を更新します。たとえば、従業員レコードに対するアクセス権のみを付与するには、「従業員」を除くすべての値の選択を解除します。

9. ここまでで、「職責範囲」セクションで数件の個人レコードが識別されました。これらのレコードの一部をセキュリティ・プロファイルから除外するには、「除外ルール」セクションで「除外ルールの適用」を選択します。

10. 「行の追加」アイコンをクリックします。

11. 除外ルールを選択します。

    ヒント: ルールが有効になっていることを確認してください。無効になっていると効果がありません。

    最大3つの除外ルールを追加できます。

12. 「次」をクリックします。

個人セキュリティ・プロファイルのプレビュー

「個人セキュリティ・プロファイルの作成: プレビュー」ページで、セキュリティ・プロファイルを保存前にテストできます。

1. 「個人アクセス・プレビュー」タブで、セキュリティ・プロファイルに含めた職責範囲を持つユーザーを選択します。「プレビュー」をクリックすると、次のようになります。

   • ページの「ユーザー要約」セクションに、このユーザーがアクセスできる個人レコードの数が表示されます。

   • このタブの「割当済職責範囲」セクションには、ユーザーの職責範囲が表示されます。

   ノート: 「個人アクセス・プレビュー」の結果は、この個人セキュリティ・プロファイルのみに基づく結果です。他の個人レコードへのアクセスを提供するロールがユーザーに付与される場合もあります。

2. このタブの「個人の検索」セクションで特定の個人レコードを検索して、そのレコードにアクセスできるかを確認できます。検索は、ユーザーの「プレビュー」をクリックしたときに識別された個人レコードが対象になります。たとえば、プレビューで50件の個人レコードが識別された場合、それら50件の個人レコードが検索されます。

3. このセキュリティ・プロファイルで生成されたSQL述語を表示するには、「個人アクセスのSQL述語」タブをクリックします。

4. 完了したら、「保存してクローズ」をクリックします。

• 職責範囲の割当て方法

HCM除外ルールの作成

個人セキュリティ・プロファイルのHCM除外ルールを使用して、一部のレコードを除外できます。たとえば、HR部門や特定のマネージャ階層にいる個人レコードを除外するには、HCM除外ルールを使用できます。このトピックでは、HCM除外ルールの作成方法を示します。

1. 「ナビゲータ」→「自分のクライアント・グループ」→「ワークフォース・ストラクチャ」を選択します。

2. 「ワークフォース・ストラクチャ」作業領域の「タスク」パネル・タブで、「HCM除外ルールの管理」を選択します。

3. 「HCM除外ルールの管理」ページで、「作成」をクリックします。

4. HCM除外ルールの作成ページで、ルールの名前を指定し、「使用可能」を選択したままにします。

   ヒント: 除外ルールが有効になっていない場合、個人セキュリティ・プロファイルで除外ルールは無視されます。

5. 「除外定義」セクションで、「除外基準」の値を選択します。

6. リスト値を選択した場合は、除外するオブジェクトをリストします。「部門リスト」を選択するとします。「部門」セクションで、次の操作を実行します。

   1. 「追加」をクリックします。

   2. 「部門」フィールドで、除外する部門を選択します。

   3. 「OK」をクリックします。

   リストに部門をさらに追加するには、前述のステップを繰り返します。

7. 「部門階層」を選択した場合、「部門階層」セクションで次を実行します。

   1. 「ツリー名」フィールドで、部門階層ツリーを選択します。

   2. 「最上位部門」フィールドで、階層の最上位部門を選択します。

   3. 「OK」をクリックします。

8. 「HCMポジション階層」を選択した場合は、「ポジション階層」セクションで最上位ポジションを選択します。

9. 「上長階層」を選択した場合は、「マネージャ階層」セクションで最上位マネージャを選択します。

   ヒント: 階層の場合は、除外ルールに最上位ノードを含めます。

10. 「部門属性」などの属性値を選択した場合は、「除外条件」セクションの「属性」、「演算子」および「値」フィールドの値を選択します。たとえば、次の値を選択します。

    属性	値
    属性	部門セット
    演算子	次と等しい
    値	EMEAセット

    属性にはオブジェクトのコア属性と構成されたフレックスフィールド属性が含まれます。

11. 完了したら、「保存してクローズ」をクリックします。

作成したこの除外ルールは、職責範囲別にレコードを保護するときに個人セキュリティ・プロファイルに含めることができます。

マネージャ階層によって個人レコードを保護するためのオプション

マネージャがアクセスできる個人レコードは、個人セキュリティ・プロファイルでのマネージャ階層の指定方法によります。このトピックでは、「個人またはアサイメント・レベル」オプションの影響を説明します。このオプションは「個人」または「アサイメント」のいずれかに設定します。

ノート: 「個人またはアサイメント・レベル」オプションは、その設定にかかわらず、個人レコードへのアクセスを制御します。特定のアサイメントへのアクセスを有効にできません。

次のマネージャ階層の例について考えます。

Harryは、2つのアサイメントを持つライン・マネージャです。彼は、自分のプライマリ・アサイメントで、Svenのプライマリ・アサイメントを管理します。Harryは、プライマリ・アサイメント2で、Janeのプライマリ・アサイメントを管理します。Monicaは、1つのアサイメントを持つライン・マネージャです。彼女はJaneのアサイメント2、およびAmirのプライマリ・アサイメントを管理します。Janeは、自分のプライマリ・アサイメントで、Francoのプライマリ・アサイメントを管理します。彼女はアサイメント2で、Kyleのプライマリ・アサイメントを管理します。この図は、このマネージャ階層の例を示しています。

ノート: ライン・マネージャ以外のマネージャは、そのロールが機能やデータにアクセスできる場合にのみ、マネージャ階層別に保護される個人レコードにアクセスできます。このアクセスの提供は、セキュリティ設定タスクです。

個人レベルのマネージャ階層

「個人またはアサイメント・レベル」が「個人」の場合、セキュリティ・プロファイルには、マネージャの任意のアサイメントに直接または間接的にレポートする個人が含まれます。

次の表は、3人のマネージャそれぞれが個人レベルのマネージャ階層でアクセスできる個人レコードを示しています。

マネージャ	Sven	Jane	Franco	Kyle	Amir
Harry	はい	はい	はい	はい	いいえ
Monica	いいえ	はい	はい	はい	はい
Jane	いいえ	いいえ	はい	はい	いいえ

サインインしたマネージャは、セキュリティ・プロファイルの他の基準に従って、自分のマネージャ階層内のすべての個人の個人レコードにアクセスします。たとえば、KyleはHarryが管理するアサイメントにレポートしませんが、HarryはKyleの個人レコードにアクセスできます。

アサイメントレベルのマネージャ階層

「個人またはアサイメント・レベル」が「アサイメント」の場合、マネージャは、次のユーザーの個人レコードを参照できます。

• 1つ以上のアサイメントから直接マネージャにレポートする。

• 管理しているアサイメントにレポートする。

次の表は、3人のマネージャそれぞれがアサイメントレベルのマネージャ階層でアクセスできる個人レコードを示しています。

マネージャ	Sven	Jane	Franco	Kyle	Amir
Harry	はい	はい	はい	いいえ	いいえ
Monica	いいえ	はい	いいえ	はい	はい
Jane	いいえ	いいえ	はい	はい	いいえ

このシナリオでは、次のようになります。

• HarryはSven、Jane、およびFrancoの個人レコードにアクセスします。KyleはMonicaが管理するアサイメントにレポートするため、HarryはKyleのレコードにアクセスできません。

• Monicaは、Jane、Kyle、およびAmirの個人レコードにアクセスします。FrancoはHarryが管理するアサイメントにレポートするため、MonicaはFrancoのレコードにアクセスできません。

• JaneはFrancoとKyleの個人レコードにアクセスします。

アサイメントレベルのマネージャ階層は、個々のアサイメントへのアクセスを保護するアサイメントレベルのセキュリティとは異なります。個々のアサイメントへのアクセスは保護できません。

退職済就業者へのアクセス

ライン・マネージャは、マネージャ階層での退職済就業者へのアクセス権を退職日の翌日に自動的に失います。

• マネージャ階層:管理方法

個人セキュリティ・プロファイルのマネージャ・タイプ

個人レコードをマネージャ階層で保護する場合、セキュリティ・プロファイルのデータ・インスタンス・セットには、指定したタイプのマネージャ階層からの個人レコードが含まれます。このトピックでは、使用可能なタイプ値とその影響について説明します。「個人セキュリティ・プロファイルの管理」タスクを実行するときに、「マネージャ・タイプ」の値を選択します。

次の表では、「マネージャ・タイプ」の値について説明しています。

マネージャ・タイプ	説明
すべて	セキュリティ・プロファイルには、マネージャ階層のすべてのタイプが含まれます。
ライン・マネージャ	セキュリティ・プロファイルには、ライン・マネージャ階層のみ含まれます。
選択済	セキュリティ・プロファイルには、指定したタイプのマネージャ階層のみ含まれます。

通常、ライン・マネージャの場合は「ライン・マネージャ」、プロジェクト・マネージャの場合は「プロジェクト・マネージャ」、などのように選択します。「すべて」を選択すると、たとえば「ライン・マネージャ」ジョブ・ロールを持つユーザーは、そのすべてのマネージャ階層に対するライン・マネージャのアクセス権を持ちます。このアクセス・レベルが不要な場合は、「すべて」を選択しないでください。

マネージャ・ジョブ・ロール

ライン・マネージャ以外のマネージャ・ジョブ・ロールは事前定義されていません。プロジェクト・マネージャやリソース・マネージャなどのマネージャのジョブ・ロールを作成するのはセキュリティ設定タスクです。これらのロールが存在する場合は、直接または個別のHCMデータ・ロールを作成してセキュリティ・プロファイルをそれらのロールに割り当てることができます。これらのロールを持つユーザーは、「ナビゲータ」→「自分のチーム」などを選択して、マネージャ階層にアクセスできます。

個人セキュリティ・プロファイルの階層コンテンツ

個人セキュリティ・プロファイルの「階層コンテンツ」属性は、次の場合にマネージャ階層へのアクセスを委任する方法を制御します。

• マネージャ階層別に個人レコードへのアクセスを保護する。

• 個人セキュリティ・プロファイルを含むロールを委任する。

個人セキュリティ・プロファイルを作成するには、「設定および保守」作業領域で、「個人セキュリティ・プロファイルの管理」タスクを使用します。

階層コンテンツの値

次の表では、「階層コンテンツ」の値について説明しています。

値	説明
マネージャ階層	サインインしたユーザーのマネージャ階層。この値がデフォルト値です。 関連付けられているロールを委任できる場合はこの値を使用しないでください。
委任マネージャ階層	委任マネージャのマネージャ階層。 関連付けられたロールが常にマネージャ以外のユーザーに委任されるためにマネージャ階層がない場合は、この値を選択します。
両方	プロキシ・ユーザーは、自分のマネージャ階層と委任マネージャの階層両方にアクセスできます。 この値は、1人のマネージャが「ライン・マネージャ」ロールを別のマネージャに委任する一般的なケースの場合に選択します。

「ライン・マネージャ」ロールが別のライン・マネージャに委任されると、プロキシは、たとえば「個人管理」作業エリアで委任者のレポートを管理できます。ただし、マネージャ階層はロールの委任で変更されないため、プロキシの「自分のチーム」情報には委任者のレポートは表示されません。

ノート: プロキシ・ユーザーが委任者のマネージャ階層内に存在する場合、委任されたロールによってプロキシ・ユーザーに自分のレコードへのアクセスが付与されます。

個人セキュリティ・プロファイルのPersonタイプ

システムPersonタイプまたはそのユーザーPersonタイプに基づいて、個人レコードへのアクセスを保護できます。たとえば、システムPersonタイプが従業員である就業者の個人レコードへのアクセスを保護できます。Personタイプ別に保護する場合は、アクティブまたは休止しているアサイメントを持つ就業者の個人レコードにのみアクセスできます。退職済就業者の個人レコードにはアクセスできません。このトピックでは、Personタイプ別に個人レコードへのアクセスを保護する場合の、「アクセス」の値の影響について説明します。

制限付きアクセス

Personタイプ別に保護する場合に「アクセス」を「制限付き」に設定すると、セキュリティ・プロファイル内のその他の基準も適用されます。たとえば、次の表に示す値を選択できます。

タイプ	システムPersonタイプ	アクセス
システムPersonタイプ	従業員	制限付き
システムPersonタイプ	派遣就業者	制限付き

さらに、同じ個人セキュリティ・プロファイルのマネージャ階層別に、個人レコードへのアクセスを保護する場合は、両方の基準セットが適用されます。つまり、次のようになります。

• ユーザーは、独自のレポート階層で、従業員と派遣就業者の個人レコードにアクセスできます。

• ユーザーは、この個人セキュリティ・プロファイルを使用する場合は、レポート階層の他のタイプの個人レコードと、レポート階層外の個人レコードにはアクセスできません。

すべてのアクセス

Personタイプ別に保護する場合に「アクセス」を「すべて」に設定すると、セキュリティ・プロファイル内のその他の基準が影響することはありません。たとえば、「システムPersonタイプ」を「従業員」、「アクセス」を「すべて」に設定すると、ユーザーは企業内のすべての従業員にアクセスできます。セキュリティ・プロファイルの他の基準がある場合、選択した就業者タイプでは無視されます。

「ジョブ・オファーの管理」タスクでジョブ・オファーのある候補者へのアクセスを保護する方法

Oracle Recruiting Cloudからジョブ・オファーを受け取った候補者は、Oracle Human Capital Management Cloudでオファー・アサイメントを持っています。これらのオファー・アサイメントに基づいて、ジョブ・オファーのある候補者へのアクセスを保護できます。そのため「ジョブ・オファーへの対処」集計権限を持つ人事担当者は、オンボーディングの開始前に、Oracle HCM Cloudでジョブ・オファーのある候補者を安全に管理できます。このトピックでは、ジョブ・オファーのある候補者へのアクセスを保護する方法について説明します。

ジョブ・オファーのある候補者へのアクセスの保護

職責範囲別にアクセスを保護するには、「個人セキュリティ・プロファイルの作成」ページの「職責範囲」セクションで「オファーした候補者」を選択します。または、「個人セキュリティ・プロファイルの作成」ページの「基本詳細」セクションで、「オファーした候補者へのアクセス」オプションを選択できます。このオプションを使用すると、職責範囲以外の基準によって、ジョブ・オファーのある候補者の個人レコードを含む、個人レコードへのアクセスを保護できます。たとえば、マネージャ階層別にアクセスを保護できます。また、ワークフォース・ストラクチャおよびグローバル名の範囲別にアクセスを保護することもできます(それらのセクションが個人セキュリティ・プロファイルに表示されている場合)。「ワークフォース・ストラクチャ」セクションおよび「グローバル名の範囲」セクションは、リリース11からリリース12にアップグレードした場合にのみ表示されます。

ヒント: 「オファーした候補者へのアクセス」と「オファーした候補者」の両方は選択できません。「職責範囲別保護」を選択すると、「オファーした候補者へのアクセス」オプションは「基本詳細」セクションで使用できなくなります。

ジョブ・オファーのある候補者へのアクセスの終了

ジョブ・オファーのある候補者が処理待ち就業者、従業員または派遣就業者になると、オファー・アサイメントが非アクティブになります。次の場合には、オファー・アサイメントが非アクティブになると、ジョブ・オファーのある候補者の個人レコードにアクセスできなくなります。

• 非アクティブなオファー・アサイメントにのみアクセスでき、かつ、アクセスを保護している個人セキュリティ・プロファイルによって、アクティブなアサイメントおよび休止アサイメントのみが評価される場合。

• アクセスが職責範囲によって保護され、かつ、新規採用就業者に対する職責がない場合。

• 候補者が再雇用で、以前のアクセス権が最後に終了したアサイメントに基づいていた場合。その就業者にアクティブなアサイメントが与えられたとき、そのアクティブなアサイメントに対するアクセス権がない場合、以前のアクセス権は失われます。

個人セキュリティ・プロファイルでのカスタム基準

個人レコードは職責範囲またはマネージャ階層別に保護できます。標準基準に加えてまたはそのかわりに、カスタム基準をSQL文の形式で使用することもできます。このトピックでは、個人セキュリティ・プロファイルでカスタム基準を使用する方法を説明します。

カスタム基準の使用例

この例では、個人セキュリティ・プロファイルでカスタム基準を使用する方法を説明します。この例では、個人セキュリティ・プロファイルに、1990年1月1日よりも前に生まれた個人の個人レコードを含めます。

&TABLE_ALIAS.PERSON_ID IN (SELECT PERSON_ID FROM PER_PERSONS
WHERE DATE_OF_BIRTH < TO_DATE('01-JAN-1990', 'DD-MON-YYYY'))

カスタム基準には、SQL述語がPERSON_IDまたはASSIGNMENT_IDで制限する任意の文を含めることができます。述語には、カスタム基準の制限列として&TABLE_ALIAS.PERSON_IDまたは&TABLE_ALIAS.ASSIGNMENT_IDを含める必要があります。

カスタム基準の検証

カスタム基準を2段階で検証します。

1. ページの「カスタム基準」セクションで「検証」をクリックすると、構文チェックが実行されます。欠落したカッコ、スペルが間違ったキーワード、1行コメントなどの構文エラーがレポートされます。

   ノート: SQL文に複数行のコメントを含めることができます。複数行のコメントは、スラッシュとアスタリスク(/*)で始まり、アスタリスクとスラッシュ(*/)で終了します。2つのハイフン(--)で始まる1行コメントは無効です。

2. 「次」をクリックして「プレビュー」ページを開くと、さらに検証が行われ、次の問題がレポートされます。

   • ASSIGNMENT_ID属性に対する別名としての文字Aの使用(文字AはOracleが使用する目的で予約されているため)

   • 個人識別可能情報(PII)を含む表への参照(ランタイム・エラーが発生する可能性があります)

   • UNIONやJOINなどのコマンドの使用(パフォーマンスに影響を与える可能性があります)

検証エラーはすべて修正する必要があります。

職責範囲の例外の定義

たとえば、特定の等級や事業所の個人レコードを除いて、組織内のすべての個人レコードにユーザーがアクセスできるようにする必要があるとします。職責範囲別にレコードを保護する場合、カスタム基準を使用して一部のレコードを除外する必要はありません。かわりに、個人セキュリティ・プロファイルに除外ルールを3個まで含めることができます。ルールでは、等級や事業所など、一部のレコードを除外するための基準を定義します。

カスタム基準の表と表示

カスタム基準をSQL述語の形式で使用して、個人レコードへのアクセスを保護できます。このトピックでは、カスタムのSQL文で使用できない表と表示を示します。これらの表または表示のいずれかを使用するとランタイム・エラーが発生する可能性があります。エラー・メッセージには、ORA28113: POLICY PREDICATE HAS ERRORというテキストが含まれます。

次の表に、個人レコードへのアクセスを保護するときにカスタムのSQL文に含めることができない表と表示を示します。

製品	表または表示
Contracts	OKC_EMPLOYEE_CONTACT_V OKC_SEARCH_EMPLOYEE_V OKC_SEARCH_INT_CONTACTS_V OKC_SIGNER_CONTACTS_V
Financials for EMEA	JE_RU_FA_EMPLOYEE_V
General Ledger	GL_HIERVIEW_PERSON_INFO_V
グローバル人事管理	HR_BU_LOCATIONS_X HR_LOCATIONS HR_LOCATIONS_ALL HR_LOCATIONS_ALL_F HR_LOCATIONS_ALL_F_VL HR_LOCATIONS_ALL_VL HR_LOCATIONS_ALL_X PER_ADDRESSES_F PER_ADDRESSES_FU_SEC PER_ADDRESSES_F_ PER_ADDRESSES_F_SEC PER_CONT_WORKERS_CURRENT_X PER_CONT_WORKERS_X PER_DISPLAY_PHONES_V PER_DRIVERS_LICENSES PER_DRIVERS_LICENSESU_SEC PER_DRIVERS_LICENSES_ PER_DRIVERS_LICENSES_SEC PER_EMAIL_ADDRESSES PER_EMAIL_ADDRESSESU_SEC PER_EMAIL_ADDRESSES_ PER_EMAIL_ADDRESSES_SEC PER_EMAIL_ADDRESSES_V PER_EMPLOYEES_CURRENT_X PER_EMPLOYEES_X PER_LOC_OTHER_ADDRESSES_V PER_NATIONAL_IDENTIFIERS PER_NATIONAL_IDENTIFIERSU_SEC PER_NATIONAL_IDENTIFIERS_ PER_NATIONAL_IDENTIFIERS_SEC PER_NATIONAL_IDENTIFIERS_V PER_PASSPORTS PER_PASSPORTSU_SEC PER_PASSPORTS_ PER_PASSPORTS_SEC PER_PERSON_ADDRESSES_V PER_PHONES PER_PHONESU_SEC PER_PHONES_ PER_PHONES_SEC PER_PHONES_V PER_VISAS_PERMITS_F PER_VISAS_PERMITS_FU_SEC PER_VISAS_PERMITS_F_SEC PER_WORKFORCE_CURRENT_X PER_WORKFORCE_X
グローバル給与	PAY_AMER_W4_LOC_ADDRESS_V PAY_AMER_W4_PERSON_ADDRESS_V
Grants Management	GMS_ALL_CONTACTS_V GMS_INTERNAL_CONTACTS_V
Payments	IBY_EXT_FD_EMP_HOME_ADDR
Planning Common Components	MSC_AP_INTERNAL_LOCATIONS_V
プロファイル管理	HRT_PERSONS_D HRT_PERSONS_X
Project Foundation	PJF_PROJ_ALL_MEMBERS_V PRJ_PROJECT_MANAGER_V PRJ_TEAM_MEMBERS_F_V
Workforce Reputation Management	HWR_VLTR_REGN_RGSTR_VL HWR_VLTR_REGN_TOTAL_VL

表と表示の詳細は、Oracle HCM Cloudの表と表示のガイドを参照してください。

• Oracle HCM Cloudの表およびビュー

個人セキュリティ・プロファイルのFAQ

ユーザーはアクセス可能な個人の連絡先レコードを参照できますか。

「個人の管理」作業領域の「連絡先」タブを参照するユーザーは、連絡先が就業者でないかぎり、就業者の連絡先を参照できます。連絡先が就業者である場合、連絡先の詳細は個人セキュリティ・プロファイルで保護されます。電話や電子メールなどの個人識別可能情報(PII)は、ユーザーが「連絡先個人PIIの管理」集計権限を継承しないかぎり、表示されません。

どのユーザーも自分の連絡先の連絡先レコードを参照できます。

個人が複数のアサイメントや個人タイプを持っている場合はどうなりますか。

個人レコードにアクセスできるユーザーは、アサイメント・タイプに関係なく、個人のすべてのアサイメントにアクセスできます。アサイメントは異なる雇用主が持つこともできます。

個人セキュリティ・プロファイルに共有情報を含めるとどうなりますか。

ユーザーは、共有しているすべての個人情報にアクセスできます。このアクセスは、個人セキュリティ・プロファイルで指定されている個人レコードに追加されるものです。このオプションを選択しない場合、ユーザーは、共有している個人レコードが個人セキュリティ・プロファイルで指定されていない場合、共有している個人情報にアクセスできません。

先日付のオブジェクトをセキュリティ・プロファイルに含めるとどうなりますか。

ユーザーは、セキュリティ・プロファイル基準を満たす先日付の個人、組織、またはポジションにアクセスできます。このオプションを選択解除のままにした場合、ユーザーは先日付のオブジェクトにアクセスできません。たとえば、開始日が先日付である組織は、セキュリティ・プロファイルのその他の基準をすべて満たしていても、ユーザーには表示されません。

オブジェクト内の有効日レコードは、このオプションの影響を受けません。

ワークフォース・ストラクチャまたはグローバル名の範囲別に個人レコードへのアクセスを保護できますか。

はい、できます。ただし、リリース11からアップグレードした場合のみに限られます。リリース12以上で実装が新規の場合は、ワークフォース・ストラクチャまたはグローバル名の範囲別に個人レコードへのアクセスを保護できません。

個人セキュリティ・プロファイルから一部のレコードを除外するにはどうすればよいですか。

個人セキュリティ・プロファイルに除外ルールを含めます。ルールで部門や等級などの基準を使用して、除外するレコードを特定します。ただし、職責範囲別に個人レコードを保護する必要があります。

個人セキュリティ・プロファイルには、除外ルールを3個まで含めることができます。階層に基づくルールは1つのみ使用できます。