アカウント・ライフサイクル管理- ジョイナ・ムーバーおよびリーバー(JML)プロセスの自動プロビジョニング
Oracle Access Governanceは、アイデンティティ・ライフサイクル・ステージに基づくアカウントおよびアクセスの自動プロビジョニングおよびプロビジョニング解除をサポートします。アイデンティティ・ライフサイクルには、ジョイナ、ムーバーおよびリーバーの3つの主要なステージがあり、一般にJMLプロセスと呼ばれます。このプロセスのサポートには、統合オーケストレート済システムの属性変更に基づくアイデンティティ・アカウントとそのアクセス権限の作成、変更および削除が含まれます。
このプロセスにより、アイデンティティはアクセス・リクエストを手動で呼び出さずに、必要なアクセスを自動的に取得できます。管理の負担を軽減するだけでなく、データの整合性とコンプライアンスも確保します。プロビジョニングのその他の方法は、アクセスを手動でリクエストするか、管理対象システムから直接プロビジョニングすることです。詳細は、マイ・アクセス・リクエストの表示を参照してください。
AG_ServiceDesk_Adminロールを持つユーザーは、承認ワークフローなしでアカウントのライフサイクルを直接管理できます。「アイデンティティの管理」→「アイデンティティ」ページから、アイデンティティのすべてのアカウントおよび関連付けられたアクセスを有効化、無効化、削除または終了できます。失敗または保留中のステータスのプロビジョニングを再試行し、直接またはリクエストを介して割り当てられた権限を取り消すこともできます。詳細なステップは、サービス・デスク・エグゼクティブ・サポートによるアカウント・ライフサイクルの管理を参照してください。
Oracle Access Governanceの場合:
- ジョイナーは、企業に加入すると、出生に適したアクセス権を得ることができます。
- Moversは、ロールを変更したり、社内異動を取得したり、企業内でプロモーションを取得する際に、必要なアクセスを取得します。
- リーバーは、エンタープライズを終了するとアカウントが取り消されます(削除または無効化されます)。
Oracle Access Governanceでは、アイデンティティ情報はコアおよびカスタム・アイデンティティ属性のセットを使用して構築されます。認可ソースでアイデンティティ・レコードを作成、変更または更新するたびに、Oracle Access Governanceは次回のデータ・ロード操作で最新データを収集し、対応するプロビジョニング/プロビジョニング解除操作を開始します。Oracle Access Governanceは、ポリシーベースのアクセス制御(PBAC)モデルを使用して、このきめ細かく柔軟なアクセス制御メカニズムを実現します。Oracle Access Governanceでは、属性(属性ベースのアクセス制御(ABAC))を使用してメンバーシップをアイデンティティに割り当て、定義済のポリシーに基づいてアイデンティティをプロビジョニングします。ポリシーでは、ロールベースのアクセス制御モデルをさらに活用して、アイデンティティ属性から取り込まれた適切なロールベースの権限を割り当てることができます。
サポートされている操作: アカウントの作成、アカウントの読取り、権限の割当て、権限の取消し、パスワードの変更、アカウントの無効化、アカウントの更新、アカウントの削除。詳細は、Oracle Access Governanceでサポートされる統合に記載されている、特定のOrchestrated Systemドキュメントを参照してください。
従業員オンボーディング- ジョイナ・プロビジョニング
新規従業員が企業に参加または採用されると、Oracle HCMなどの新しいレコードが認可ソースに作成されます。アイデンティティがOracle Access Governanceでオンボーディングされると、Oracle Access Governanceで実行されたアクセス制御構成に基づいて、出生権アクセスまたはアカウントと権限のデフォルト・セットをプロビジョニングできます。
ジョイナ・プロセスでは、すべての新規従業員がオンボーディング・プロセスを開始するために必要なアカウントおよび権限を取得することが保証されます。
Oracle Access Governanceでアイデンティティがオンボーディングされ、アクティブになると、すべてのアイデンティティ属性が定義済ポリシーと比較されます。Oracle Access Governanceポリシーによって、特定の部門に属するアイデンティティへの特定のロールまたはアクセス・バンドルのアクセス権が付与されると、そのロールまたはアクセス・バンドルに対してプロビジョニングされます。
シナリオ: 新しい従業員であるAliceがSales部門のCustomer Success部門に加わった場合、Joinersのプロビジョニングにより、Aliceは自分の部署および自分の部署に適用可能なすべての必須アカウントおよび権限を受け取ります。Oracle Access Governanceでこれを実現する方法を見てみましょう。
Oracle Access Governanceでのジョイナ・プロビジョニングの実行
前述のシナリオでは、Oracle Access GovernanceでJoinersプロビジョニングを実現するための概要ステップを見てみましょう。
- アクセス制御管理者として、アクセス制御構成を次のように設定します。
- メンバーシップ・ルールに基づいてアイデンティティ・コレクションを作成します。たとえば、メンバーシップ・ルールが「ソース組織」が「営業」で、別のアイデンティティ・コレクション(「部門」が「顧客成功事例」)であるアイデンティティ・コレクションを作成します。詳細は、アイデンティティ・コレクションの作成を参照してください。
- アクセス・バンドルまたはロールを作成し、必要な権限へのアクセスをパッケージ化します。たとえば、Salesに適用される権限とともにアクセス・バンドルSales_ABを作成し、別のアクセス・バンドルCustomer_Success_ABにCustomer Successに適用される権限を作成します。詳細は、アクセス・バンドルの作成を参照してください。
- ポリシーを作成し、アクセス・バンドルの権限部分をアイデンティティ・コレクションに関連付けます。たとえば、ポリシーSales_Policyを作成し、Sales_ABをSalesアイデンティティ・コレクションに関連付けます。同様に、Customer_Success_Policyを作成し、Customer_Success_ABをCustomer Successアイデンティティ・コレクションに関連付けます。詳細は、ポリシーの作成を参照してください。
- 「認可ソース」では、従業員の新しいレコードが登録されます。たとえば、HRは、「ビジネス・ユニット」が「営業」、「部門」が「顧客成功事例」のAliceの新規レコードを追加します。
- Orchestrated Systemは、データ・ロードを実行し、最新データを取り込み、Oracle Access Governanceにコンポジット・アイデンティティ・プロファイルを作成します。詳細は、アイデンティティ・オーケストレーション・プロセス・フローを参照してください。
新しいアイデンティティ・プロファイルがOracle Access Governanceに作成されます。属性が定義済のポリシーと照合され、適切なプロビジョニング操作がトリガーされます。ジョイナの場合、Orchestrated Systemによってアカウントの作成およびアカウントまたは権限データの追加プロビジョニング操作がトリガーされ、新しいアカウントおよび権限が割り当てられます。
Oracle Access Governanceでのジョイナ・プロビジョニングの検証
- エンタープライズ全体のアクセス管理者は、アイデンティティを検索して、アイデンティティ属性、権限およびアカウント情報を表示する完全なアイデンティティ詳細を表示できます。アイデンティティ・コレクションの詳細を表示して、新しいメンバー・リストを確認することもできます。
- Identity Managerは、「誰が何にアクセスできるか」→「自分の直属のアクセス」で直属の部下の包括的なアイデンティティ詳細を表示できます。
- ユーザーは、「自分の作業」→「自分のアクセス」ページからアカウントおよび権限を検証できます。
オーケストレート済システム用に構成されたアカウント設定に応じて、新しいアカウントが作成されるたびにユーザーまたはユーザー・マネージャに通知を受信します。デフォルトでは、通知は「ユーザー」に送信されます。詳細は、Configure Orchestrated System Account Settingsを参照してください。
従業員異動- ムーバー・プロビジョニング
従業員が社内で異動、転属、または組織内で昇進すると、その従業員のレコードが認可ソースで更新されます。転送時に、アイデンティティは、新しいジョブ・プロファイルに関連する適切な権限にのみアクセスする必要があります。アカウント・ライフサイクル設定に基づいて、残りのアカウントおよび権限を取り消す必要があります。この自動プロビジョニングは、Oracle Access Governanceで実行されたアクセス制御構成に基づいて実現できます。
ムーバー・プロセスでは、新しいロールで必要な権限またはアカウントの必要な正しいセットのみが従業員に割り当てられます。
シナリオ: 従業員のAliceが、Customer Success部門からSales部門のCloud Sales部門への内部異動を取得すると、Moversプロビジョニングにより、Aliceは新しいロールに適用可能なすべての権限を受信し、以前のロールに必要な以前のアカウントおよび権限を取り消したり、無効化できます。この例では、Aliceは引き続きSales部門に適用可能な権限を持ちますが、Cloud Sales部門に関連する新しい権限を取得します。該当しなくなった場合、以前のアカウントは無効または取り消され、アカウントに関連付けられた権限も削除されます。Oracle Access Governanceでこれを実現する方法を見てみましょう。
Oracle Access GovernanceでのMoverプロビジョニングの実行
前述のシナリオでは、Oracle Access Governanceでムーバー・プロビジョニングを実現するための概要ステップを見てみましょう。
- アクセス制御管理者は、この最小限の設定を次のように行う必要があります。
- メンバーシップ・ルールに基づいてアイデンティティ・コレクションを作成します。たとえば、メンバーシップ・ルールがDepartmentがCloud Salesで、別のアイデンティティ・コレクションがDepartmentがCustomer Successであるアイデンティティ・コレクションを作成します。詳細は、アイデンティティ・コレクションの作成を参照してください。
- アクセス・バンドルまたはロールを作成し、必要な権限へのアクセスをパッケージ化します。たとえば、Cloud Salesに適用可能な権限でアクセス・バンドルCloud_Sales_ABを作成し、別のアクセス・バンドルCustomer_Success_ABにCustomer Successに適用可能な権限で作成します。詳細は、アクセス・バンドルの作成を参照してください。
- ポリシーを作成し、アクセス・バンドルの権限部分をアイデンティティ・コレクションに関連付けます。たとえば、ポリシーCloud_Sales_Policyを作成し、Cloud_Sales_ABをCloud Salesに関連付けます。詳細は、ポリシーの作成を参照してください。
- 「認可ソース」には、アイデンティティの更新が記録されます。たとえば、HRはAliceの部門をCustomer SuccessからCloud Salesに更新します。
-
Orchestrated Systemは、データ・ロードを実行し、最新データを取り込み、Oracle Access Governanceにコンポジット・アイデンティティ・プロファイルを作成します。オーケストレート済システムのアカウント・ライフサイクル設定に基づいて、権限またはアカウントが無効化または取り消されます。詳細は、アイデンティティ・オーケストレーション・プロセス・フローを参照してください。
AG_ServiceDesk_Adminロールを持つユーザーは、「権限の取消し」操作を使用して、「アイデンティティの管理」ページから権限を直接取り消すことができます。これらの権限の付与タイプは、DIRECTまたはREQUESTを介して付与されるアクセス・バンドルのいずれかである必要があります。Oracle Cloud Infrastructure (OCI)またはOracle Identity Governance (OIG)システムの権限を取り消すことはできません。詳細なステップは、アカウントの1つ以上の権限の取消しを参照してください。
Oracle Access GovernanceでのMoverプロビジョニングの検証
- 以前の権限とアイデンティティ・アカウントの関連付けを解除するために、アカウントまたは権限データの削除がトリガーされます。
- アカウントを無効にしたり、アカウントの更新をトリガーしたり、アカウントを削除するために、取消しをトリガーします。
- 新しいアカウントおよび権限を関連付けるために、「アカウントの作成」および「アカウントまたは権限データの追加」がトリガーされます。
- 権限のみが異なる場合、アカウントは有効なままですが、「アカウントまたは権限データの追加」または「アカウントまたは権限データの削除」操作(あるいはその両方)がトリガーされ、そのアカウントの権限が更新されます。
- 無効なアカウントが有効になっている場合、「アカウントの更新」と「アカウントまたは権限データの追加」または「アカウントまたは権限データの削除」(あるいはその両方)がトリガーされます。
- エンタープライズ全体のアクセス管理者は、アイデンティティを検索したり、アイデンティティ属性、権限およびアカウント情報を表示する完全なアイデンティティ詳細を表示できます。アイデンティティ・コレクションの詳細を表示して、新しいメンバー・リストを確認することもできます。
- ユーザーは、「自分の作業」→「自分のアクセス」ページからアカウントおよび権限を検証できます。
オーケストレート済システム用に構成されたアカウント設定に応じて、新しいアカウントが作成されるたびにユーザーまたはユーザー・マネージャに通知を受信します。デフォルトでは、通知は「ユーザー」に送信されます。既存のアカウントは、アカウント設定に応じて削除または無効化できます。詳細は、Configure Orchestrated System Account Settingsを参照してください。
従業員オフボーディング- 退職者のプロビジョニング解除
従業員が企業を終了すると、認可ソースでレコードが削除または無効になります。終了すると、そのアイデンティティに割り当てられているすべてのアカウントおよび関連付けられた権限が、管理対象システムから削除または無効化されます。
リーバー・プロセスでは、アイデンティティに割り当てられているすべてのアカウントおよび権限が、終了時に自動的に取り消されます。アイデンティティが終了し、Oracle Access Governanceで「非アクティブ」とマークされると、アカウント設定に基づいてアイデンティティ・アクセスが取り消されるか無効になります。
AG_ServiceDesk_Adminロールを持つユーザーは、「権限の取消し」操作を使用して、「アイデンティティの管理」ページから権限を直接取り消すことができます。これらの権限の付与タイプは、DIRECTまたはREQUESTを介して付与されるアクセス・バンドルのいずれかである必要があります。Oracle Cloud Infrastructure (OCI)またはOracle Identity Governance (OIG)システムの権限を取り消すことはできません。詳細なステップは、アカウントの1つ以上の権限の取消しを参照してください。
AG_ServiceDesk_Adminロールを持つユーザーは、「アカウントの無効化」操作を使用して、「アイデンティティの管理」ページからOracle Access Governanceで管理されているアカウントを直接無効化できるようになりました。無効にすると、関連するすべてのアクセスが取り消されます。アカウントは、引き続きOracle Access Governanceで管理できます。詳細なステップは、Oracle Access Governanceで管理されるアカウントの無効化および有効化を参照してください。
シナリオ: 従業員のAliceが企業を終了すると、Leaversのプロビジョニング解除によって、自分のロールに適用可能なすべての割当て済アカウントおよび権限が取り消されます(削除または無効化)。Oracle Access Governanceでこれを実現する方法を見てみましょう。
Oracle Access Governanceでのリーバのプロビジョニング解除の実行
前述のシナリオでは、Oracle Access Governanceでリーバーのプロビジョニング解除を実現するための概要ステップを見てみましょう:
- アクセス制御管理者は、この最小限の設定を次のように行う必要があります。
- メンバーシップ・ルールに基づくアイデンティティ・コレクション。詳細は、アイデンティティ・コレクションの作成を参照してください。
- 必要な権限がまとめてパッケージ化されているアクセス・バンドルまたはロール。詳細は、アクセス・バンドルの作成およびロールの管理を参照してください。
- (アクセス・バンドルを介して)権限をアイデンティティ・コレクションに関連付けるポリシー。詳細は、ポリシーの作成を参照してください。
- [権限ソース]は、システム内の従業員の既存のレコードを非アクティブ化します。
- Orchestrated Systemは、データ・ロードを実行し、最新データを取り込みます。詳細は、アイデンティティ・オーケストレーション・プロセス・フローを参照してください。
アイデンティティ・プロファイルが非アクティブ化され、データ・ロードが成功すると、アイデンティティのアカウントを削除または無効化するために、「アカウントの更新」または「アカウントの更新」プロビジョニング・タスクがトリガーされます。アカウントに関連付けられた権限が取り消され、「アカウントまたは権限データの削除」がトリガーされて、管理対象システムから権限が削除されます。詳細は、Configure Orchestrated System Account Settingsを参照してください。