リソースキャンペーンを作成する

リソースキャンペーンは、リソースにアクセスできるユーザーをすべて表示します。リソースキャンペーンを定期的に実行することは、機密のリソースに対するアクセスを制限するのに役立ちます。また、これらのキャンペーンは、SOC2やSOXなどのプロフェッショナル基準や、監査とコンプライアンスの要件を満たすのにも役立ちます。

［Govern Okta admin roles（Okta管理者ロールを管理）］を有効にした場合には、キャンペーンタイプを使用して、ユーザーの管理者ロール割り当てを見直してください。

アプリやグループなどのリソースを選択して、そのリソース、関係付けられているエンタイトルメントやバンドル（標準ロールと標準ロールとカスタム管理者ロールを含む）にアクセスできる人を確認することができます。リソースに割り当てられたすべてのユーザーを選択するか、Okta Expression Languageを使用して特定のユーザーを定義できます。キャンペーンから特定のユーザーを除外することもできます。

開始する前に

  • 最大50のリソースを選択して、それらにアクセスできる人を確認することができます。

  • キャンペーンには、最大100,000のレビューアイテムを持たせることができます。大規模なキャンペーンを管理するには、レビューを複数のキャンペーンに分割します。

  • 管理者ロールを管理するためのキャンペーンを作成するときは、スーパー管理者としてサインインし、機能が有効になっていることを確認します。

  • エンタイトルメント割り当ての矛盾をレビューするためのキャンペーンを作成するときは、キャンペーンを開始する前に、［Separation of duties (SoD) details（職務分離（SoD）の詳細）］チェックボックスが選択されていることを確認します。このチェックボックスは［Contextual Information（コンテキスト情報）］ページにあります。このチェックボックスは、キャンペーンのレビュアーがSoD矛盾の詳細を表示できるようにします。「カスタマイズ可能なレビュアーコンテキスト」を参照してください。

キャンペーンをセットアップする

  1. Okta Admin Consoleで［Identity Governance（IDガバナンス）］［Access Certifications（アクセス認定）］に移動します。

  2. ［Create campaign（キャンペーンを作成）］をクリックします。

  3. ［Create campaign（キャンペーンを作成）］ドロップダウンメニューから［Resource campaign（リソースキャンペーン）］をキャンペーンタイプに選択します。

  4. ウィザードで次の設定を構成してから、［Schedule campaign（キャンペーンの日程を設定）］ をクリックします。

一般設定を構成する

次の設定を構成します。

  1. ［Campaign name（キャンペーン名）］：キャンペーンの名前を入力します。理想的には、レビュアーにとってわかりやすい名前を入力してください。
  2. ［Description（説明）］：キャンペーンの目的を説明します。
  3. ［Start date（開始日）］：キャンペーンの開始日を選択します。
  4. ［Start time（開始時刻）］：キャンペーンの開始時刻とタイムゾーンを選択します。
  5. ［Duration（所要時間）］：キャンペーンを実行する期間を選択します。マルチレベルレビュアーを使用したキャンペーンは、7日間以上の期間を設定する必要があります。
  6. 任意。［Make this recurring（これを繰り返す）］を選択して、キャンペーンの定期スケジュールを設定します。繰り返しキャンペーンを効率よく計画する方法については、「繰り返しキャンペーンに関する考慮事項」を参照してください。

リソースの設定を構成する

リソースタイプに［Application（アプリケーション）］または［Group（グループ）］を選択します。

Application（アプリケーション）

  1. 1つ以上のアプリを選択します。
    • 職務分離ルールに矛盾するものも含めて、エンタイトルメントをレビューするには、ブルーに強調表示されているアプリを最大10個まで選択します。
    • 管理者ロールを管理するには、Okta Admin Consoleを検索して選択します。これを選択すると、他のアプリは追加できません。
  2. ［Review entitlements（エンタイトルメントをレビューする）］ トグルを有効にして、職務分離ルールに矛盾するものも含めて、エンタイトルメントをレビューします。ただし、非アクティブのユーザーを持つアプリをレビューする場合は、オフのままにしておきます。

  3. 各アプリについて、［All entitlements and bundles（すべてのエンタイトルメントとバンドル）］か［Specific entitlements and bundles（特定のエンタイトルメントとバンドル）］のどちらを表示したいか指定します。エンタイトルメントを特定した場合は、チェックボックスを選択して、エンタイトルメント値を含むバンドルを取得することもできます。

    ［Review entitlements（エンタイトルメントをレビューする）］トグルを有効にした後で、職務分離ルールに矛盾しているエンタイトルメントを表示するには、［All entitlements and bundles（すべてのエンタイトルメントとバンドル）］を選択する必要があります。

  4. ［Add（追加）］をクリックして、他のバンドルまたはエンタイトルメントを含めます。

Group（グループ）

1つ以上のグループを選択します。キャンペーンにエンタイトルメントを含めるときは、［Group（グループ）］を選択しないでください。［Group（グループ）］を選択すると、［Review entitlements（エンタイトルメントをレビューする）］トグルが利用できなくなります。

ユーザの設定を構成する

  1. 以下のオプションから1つを選択します。

    • ［All users assigned to the resource（リソースに割り当てられているすべてのユーザー）］：先ほど選択したリソースに割り当てられているユーザーを含めるには、このオプションを選択します。

    • ［Specify user scope（ユーザースコープを指定）］：ユーザースコープをorg内の特定のユーザーセットに制限するには、このオプションを選択します。領域機能を有効にしたときは、このオプションを使ってキャンペーンに含まれるユーザーを特定領域からのユーザーに制限します。

      1. 有効なOkta Expression Language（EL）式を入力して、ユーザースコープを指定します。式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。「ユーザースコープを定義する」を参照してください。

      2. 推奨。キャンペーンに含まれているかどうかを確認するユーザーの名前を［Previewer reviewer（プレビュアーとレビュアー）］フィールドに入力します。［Preview（プレビュー）］をクリックします。ユーザーがキャンペーンに含まれているかどうかを示すメッセージが表示されます。

        キャンペーンのリソースに割り当てられていないユーザーをプレビューすると、EL式にユーザーが含まれていても、プレビューにはそのユーザーがキャンペーンに含まれていないと示されます。

    • ［Predefined user scope（事前定義済みのユーザースコープ）］：

      • ［No recent activity（最近のアクティビティなし）］：一定期間使用されていないアプリをレビューするには、このオプションを選択します。ユーザーが非アクティブだった日数を指定します。このオプションは、キャンペーンのリソーススコープを［Apps（アプリ）］に設定し、［Review entitlements（エンタイトルメントをレビューする）］設定をオフにした場合にのみ表示されます。

      • ［Have separation of duties (SoD) conflicts（職務分離（SoD）の矛盾がある）］：割り当てられているエンタイトルメントが職務分離ルールに合致しないユーザーのみをレビューするには、このオプションを選択します。このオプションは、キャンペーンのリソーススコープを［Apps（アプリ）］に設定し、［Review entitlements（エンタイトルメントをレビューする）］設定をオンにして、［All entitlements and bundles（すべてのエンタイトルメントとバンドル）］を選択した場合にのみ表示されます。

    • ［Only include active Okta users in this campaign（アクティブなOktaユーザーのみをこのキャンペーンに含める）］：OktaでActive（アクティブ）、Password Reset（パスワードリセット）（またはRecovery（アカウント復旧））、Password Expired（パスワードの有効期限切れ）、またはLocked Out（ロックアウト）のステータスを持つユーザーのみを含めるには、このオプションを選択します。

  2. 任意。［Exclude users from the campaign（ユーザーをキャンペーンの対象から除外）］：特定のユーザーをキャンペーンから除外するには、［Exclude users from the campaign（ユーザーをキャンペーンの対象から除外）］を選択して、キャンペーンから除外するユーザーの名前を入力します。

レビュアーの設定を構成する

キャンペーンに含まれるレビュアーがキャンペーン開始設定時刻に非アクティブ化または削除されている場合、キャンペーンは開始されません。

  1. レビュアータイプを選択します：

    • ［Users（ユーザー）］：キャンペーン内のすべてのユーザーについて、アクセス認定のレビューを担当するレビュアーの名前を入力します。

    • ［Manager（マネージャー）］：Oktaでユーザーのプロファイルにリストされているユーザーのマネージャーにレビューアイテムを割り当てます。Oktaのユーザーのプロファイルにマネージャーがリストされていない場合、レビューは最終レビュアーに割り当てられます。

    • ［Group（グループ）］：特定のユーザーグループのすべてのメンバーにレビューアイテムを割り当てます。1人のグループメンバーのみがレビューを行い、レビューアイテムに対してアクションを実行する必要があります。そのため、グループメンバーがレビューアイテムへのアクセスを承認するか、取り消した場合、そのレビューアイテムはすべてのレビュアーに対して「完了済み」とマークされます。ドロップダウンメニューには、1～10人のメンバーがいるグループのみが表示されます。それよりも多くのメンバーをグループに追加すると、レビューアイテムはグループの10人のメンバーにランダムに割り当てられます。

    • ［Group owner（グループ所有者）］：Oktaでグループのプロファイルにリストされているグループの所有者にレビューアイテムを割り当てます。［Group Owner（グループ所有者）］のオプションは、次の条件が当てはまる場合のみ使用可能で有効です。

      • ［リソース］ペインで1つ以上のグループをリソースとして選択した。

      • 各グループのグループオーナーが個人またはグループである。どのグループについても、人とグループの組み合わせをグループ所有者にすることはできません。グループ内のグループ所有者の数が10人より多い場合、レビューアイテムは10人のグループ所有者にランダムに割り当てられます。

    • ［Custom（カスタム）］：有効なOkta Expression Language式を入力して、レビュアーを指定します。式は、レビュアーとして割り当てる必要があるユーザーのOktaユーザーIDまたはユーザー名を返す必要があります。式がレビュアーの値を返さないときは、最終レビュアーがユーザーのレビュアーとして割り当てられます。「動的レビュアーを定義する」を参照してください。

      領域機能を有効にしたときは、このオプションを使ってキャンペーンのレビュアーを特定の領域に制限します。

  2. ［Fallback reviewer（最終レビュアー）］フィールドで、すべてのレビューアイテムをレビューする責任を負うユーザーを指定します。
  3. 推奨。［Preview reviewer（プレビューレビュアー）］リンクをクリックし、ユーザー名を入力します。［Preview（プレビュー）］をクリックし、割り当てられたレビュアーを表示します。

  4. 任意。［Disable self-review（セルフレビューを無効にする）］を選択します。このオプションは、含まれるリソースの重要性や機密性に応じて、キャンペーンのセルフレビューを許可するか許可しない柔軟性を提供します。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効化されます。キャンペーンでセルフレビューが無効になっている場合、独自のレビューアイテムを承認、取り消し、または再割り当てすることはできません。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効化されます。「セルフレビューの無効化を理解する」を参照してください。

  5. 任意。［Add level（レベルの追加）］をクリックして、レビューに別のレベルを追加し、レビュアータイプを選択します。

  6. 第2レベルのレビュアーを追加した場合には、［追加レベルの設定］セクションで、第2レベルのレビュアーに送る第1レベルのレビュアーの決定を選択します。

    • ［Only approved decisions（承認された決定のみ）］：承認された決定の最終レビュアーは、第2レベルのレビュアーとなります。このオプションでは、第2レベルのレビュアーは、第1レベルのレビュアーの承認については決定を下すことができますが、取り消された決定についてはできません。取り消された決定の最終レビュアーは、引き続き第1レベルのレビュアーとなります。

    • ［Both approved and revoked decisions（承認された決定と取り消された決定の両方）］：承認されたすべての決定と取り消されたすべての決定の最終レビュアーは、第2レベルのレビュアーとなります。このオプションでは、第2レベルのレビュアーは、第1レベルのレビュアーが下したすべての決定について決定を下すことができます。

    • スライダーを使用して、第2レベルのレビューが開始される日を指定します。この数は、キャンペーンの期間より小さい必要があります。第2レベルのレビューは、第1レベルのレビューが終了すると開始されます。第2レベルのレビューの開始時にレビューが保留されている場合、第1レベルのレビューに期限切れのフラグが立てられます。

  7. 通知を設定します：

    • ［Reviews assigned（レビューの割り当て）］：キャンペーンの開始時にレビューアイテムが割り当てられたときや、レビューアイテムが再割り当てされたときに、レビュアーはメール通知を受け取ります。管理者は、キャンペーンの開始時にレビュアーが受け取るメールをカスタマイズできます。「メールテンプレートをカスタマイズする」を参照してください。

    • ［Reminder for pending reviews（保留中レビューのリマインダー）］：保留中のレビューアイテムがあるレビュアーは、キャンペーンの終了前にメール通知を受け取ります。リマインダーは、キャンペーンの中間時点、キャンペーンの終了日、またはキャンペーン終了の数日前に送信されるように選択できます。

      マルチレベルレビューが設定されているキャンペーンでは、第1レベルと第2レベルの両方のレビュアーがリマインダーを受け取ります。

      キャンペーン終了予定日の前に自分も管理者としてリマインダーメールを受け取りたいときは、このオプションを選択します。

    • ［Overdue reminders for first-level reviewers（第1レベルのレビュアーの期限切れリマインダー）］：レビューアイテムを保留している第1レベルのレビュアーは、第1レベルレビューの終了後、キャンペーンの終了まで毎日メール通知を受け取ります。このオプションは、マルチレベルレビューが設定されているキャンペーンでのみ使用できます。

    • ［Campaign ended（キャンペーンの終了）］：キャンペーンが終了すると、レビュアーはメール通知を受け取ります。管理者は、自分が作成したキャンペーンが開始または終了するときのメール通知に自動サブスクライブされます。また、キャンペーンの開始に失敗した場合は、キャンペーンのページへのリンクが記載されたメール通知を受け取ります。

  8. レビュアーの追加設定を構成します：

    • ［Require justification（理由が必要）］：レビュアーがユーザーのリソースへのアクセスを承認または取り消した理由を入力することを必須にするときは、このオプションを選択します。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効化されます。

    • ［Disable bulk decisions（一括決定を無効にする）］：レビュアーが承認または取り消すレビューを複数選択することができないようにするときは、このオプションを選択します。それでもレビュアーは複数のレビューを別のユーザーに再割り当てできますが、再割り当ての理由を入力する必要があります（［Require justification（理由が必要）］チェックボックスがオフであっても）。

    • ［Disable reassignment（再割り当てを無効にする）］：レビュアーがOkta Access Certifications Reviewsアプリでレビューアイテムを他のユーザーに再割り当てできないようにするには、このオプションを選択します。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効になります。ただし、スーパー管理者またはアクセス認定管理者は、Admin Consoleのキャンペーンのページからレビューアイテムを引き続き再割り当てすることができます。

修復設定を構成する

  1. レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を選択します。レビュアーのアクションに［Remove access from user（ユーザーからアクセス権を削除する）］を選択した場合には、［Automatically remove group-based access（グループベースのアクセスを自動的に削除する）］チェックボックスが選べるようになります。

    ［Enhanced group remediation（拡張されたグループ修復）］は、エンタイトルメントをレビューすることなく、アプリへのアクセスをレビューするリソースキャンペーンにのみ利用することができます。

  2. 任意。［Automatically remove group-based access（グループベースのアクセスを自動的に削除する）］を選択して、グループに割り当てられたアプリのアクセスを自動的に取り消すようにします。これによって、レビュアーがユーザーアクセスの取り消しを決めた後に、手動修復の必要性が低減されます。だだし、アプリがグループルールで割り当てられている場合や、グループがアプリソースのグループである場合には、ユーザーのアクセスを修復する必要があります。

  3. 任意。アプリへのアクセスを取り消すために、アクセス認定がユーザーを削除できるグループを50まで指定します。デフォルトで、アクセス認定は、アプリをユーザーに割り当てるすべてのグループからユーザーを削除できます。

Okta Workflowsを使用して修復をカスタマイズすることもできます。ほとんどのキャンペーンについて、ユーザーのアプリやグループがグループルールやグループメンバーシップによって割り当てられている場合には、手動でレビューを修復する必要があります。

修正の仕組みについては、「修復を理解する」を参照してください。

関連項目

Okta Expression Languageの例

アクティブなキャンペーンの進行状況を表示する

スケジュールされたキャンペーンを変更する

キャンペーンの終了日を変更する