キャンペーン設定

ウィザードで要件を構成します。

• 一般設定

• リソースキャンペーン設定

• ユーザーキャンペーン設定

• レビュアー設定

• 修復設定

一般設定

次のフィールドに値を入力します。

フィールド	値
Campaign name（キャンペーン名）	キャンペーンの名前を入力します。理想的には、レビュアーにとってわかりやすい名前を入力してください。
説明	キャンペーンの目的を説明します。
Start date（開始日）	キャンペーンの開始日を選択します。
Start Time（開始時刻）	キャンペーンの開始時刻とタイムゾーンを選択します。
Duration（所要時間）	キャンペーンを実行する期間を選択します。 マルチレベルレビュアーを使用したキャンペーンは、7日間以上の期間を設定する必要があります。

繰り返しキャンペーンに関する考慮事項

スーパー管理者またはアクセス認定管理者は、キャンペーンの繰り返しスケジュールをセットアップして、定期的に実行できるようにすることができます。これにより、時間を節約し、生産性を向上させることができます。ただし、繰り返しキャンペーンを構成するときは、次の基準に留意する必要があります。

• 一連の繰り返しキャンペーンでは、各キャンペーンの期間は、キャンペーン間の間隔よりも短くする必要があります。

• ［Repeats Every（繰り返し間隔）］セクションのドロップダウンメニューでは、キャンペーンの期間に入力した値と、日、週、月、年などの繰り返し頻度のタイプに応じて、事前入力されたさまざまなオプションを利用できます。

繰り返し頻度タイプ	期間（日）	繰り返し間隔*	コメント
繰り返しなし	1～90の値を入力します。	該当なし	該当なし
日	1～90の範囲で、繰り返し間隔よりも小さい値を入力します。	1～182の値を入力します。	該当なし
週間	1～90の範囲で、繰り返し間隔よりも小さい値を入力します。	1～26の値を入力します。	該当なし
月	1～90の範囲で、繰り返し間隔よりも小さい値を入力します。	1～24の値を入力します。	ドロップダウンメニューから次のいずれかのオプションを選択できます。 ［Monthly on [day of month]（毎月 [月の日]）］ ［Monthly on [day of week] of [week number]（毎月 [週番号] の [曜日]）］ 括弧内の値は［Start date（開始日）］に基づいて自動入力されます。 Monthly on [day of the week] of Week 5（毎月第5週の [曜日]）に繰り返すようにキャンペーンを設定し、その日の前に月が終了した場合、キャンペーンは第4週のその日から開始されます。 月に指定日がない場合、最終日がキャンペーンの開始日として自動的に使用されます。たとえば、キャンペーンを毎月30日に繰り返すように設定した場合、キャンペーンは2月28日または2月29日に開始されます。
年	1～90の範囲で、繰り返し間隔よりも小さい値を入力します。	値として1または2を入力します。	該当なし

キャンペーンの期間を延長する場合は、90日まで、またはキャンペーンの次の繰り返しが始まる1日前まで延長できます。

たとえば、あるキャンペーンが15日に終了し、次のキャンペーンが28日に始まる一連の繰り返しキャンペーンがあるとします。この場合は、最初のキャンペーンのキャンペーン期間を27日まで延長できます。ただし、キャンペーンが90日超の間隔で繰り返される場合は、キャンペーンの合計期間が90日以内に収まる範囲でしかキャンペーンの期間を延長できません。

リソースキャンペーン設定

リソースキャンペーンはキャンペーンのリソーススコープの設定に重点を置いているため、それらのリソースにアクセスできるすべてのユーザーを確認できます。このキャンペーンは、機密リソースへのアクセスを確認し、コンプライアンス要件を満たすのに役立ちます。

アプリまたはグループなどのリソースを選択し、誰がアクセス可能かを確認します。リソースに割り当てられたすべてのユーザーを選択するか、Okta Expression Languageを使用して特定のユーザーを定義できます。キャンペーンから特定のユーザーを除外することもできます。定期的にリソースキャンペーンを実施し、機密リソースへのアクセスを制限するようにします。

リソースキャンペーンは、SOC2やSOXなどのプロフェッショナル基準の監査要件やコンプライアンス要件を満たすのに役立ちます。

リソース設定

フィールド	値
タイプ
Applications（アプリケーション）
Groups（グループ）	1つ以上のグループを選択します。

ユーザー設定

利用可能なオプション	アクション	説明
リソースに割り当てられているすべてのユーザー	前に選択したリソースに割り当てられているユーザーを含める場合は、このオプションを選択します。	該当なし
ユーザースコープを指定	有効なOkta Expression Language（EL）式を入力して、ユーザースコープを指定します。 推奨。［Previewer reviewer（プレビュアーとレビュアー）］フィールドに、キャンペーンに含まれているかどうかを確認するユーザーの名前を入力します。［Preview（プレビュー）］をクリックします。ユーザーがキャンペーンに含まれているかどうかを示すメッセージが表示されます。 キャンペーンのリソースに割り当てられていないユーザーをプレビューすると、EL式にユーザーが含まれていても、プレビューにはそのユーザーがキャンペーンに含まれていないと示されます。	このオプションは、ユーザースコープを特定のユーザーセットに制限します。式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。「ユーザースコープを定義する」を参照してください。
Only include active Okta users in this campaign（アクティブなOktaユーザーのみをこのキャンペーンに含める）	Oktaで次のいずれかのステータスになっているユーザーのみを含める場合は、このオプションを選択します。 Provisioned（プロビジョニング済み） Active（アクティブ） Password Reset (or Recovery)（パスワードリセット（またはアカウント復旧）） Password Expired（パスワードの有効期限切れ） Locked Out（ロックアウト）	該当なし
Exclude users from the campaign（ユーザーをキャンペーンの対象から除外）	特定のユーザーをキャンペーンから除外するには、［Exclude users from the campaign（ユーザーをキャンペーンの対象から除外）］をオンにし、キャンペーンから除外するユーザーの名前を入力します。	該当なし

ユーザーキャンペーン設定

ユーザーキャンペーンは、キャンペーンのユーザー範囲の定義に重点を置いているため、それらのユーザーに割り当てられたすべてのリソースを包括的に確認できます。これにより、部門、ロール、プロジェクトの変更など、特定のイベントが発生したときにユーザーのアクセス レベルが上昇しないようにすることができます。

特定のユーザーまたはユーザーグループを選択し、割り当てられたリソースへのアクセスを確認できます。グループに割り当てられたリソースは、グループメンバーシップとグループルールに従うため、ユーザーに個別に割り当てられたリソースのみをレビュアーにレビューさせ、グループに割り当てられたリソースをレビューさせないようにキャンペーンを構成することもできます。

ユーザー設定

フィールド	値
ユーザーまたはグループを選択
個々のユーザー	1人以上のユーザーを選択します。最大100人のユーザーを選択できます。
特定のグループ	1つ以上のグループを選択します。最大5つのグループを選択できます。
カスタム（Okta Expression Language）	Okta Expression Language式を入力し、特定の基準を満たすユーザーまたはグループを含めます。 このオプションは、ユーザースコープを特定のユーザーセットに制限します。式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。「ユーザースコープを定義する」を参照してください。

リソース設定

フィールド	値
リソースのスコープ
スコープ内のユーザーに割り当てられたすべてのアプリとグループ	前に選択したユーザーに割り当てられているすべてのアプリとグループを含める場合は、このオプションを選択します。
スコープ内のユーザーに割り当てられたすべてのアプリ	前に選択したユーザーに割り当てられているすべてのアプリを含める場合は、このオプションを選択します。
スコープ内のユーザーに割り当てられたすべてのグループ	前に選択したユーザーに割り当てられているすべてのグループを含める場合は、このオプションを選択します。 キャンペーンにエンタイトルメントを含める場合は、［All groups（すべてのグループ）］を選択しないでください。［All groups（すべてのグループ）］を選択すると、［個別に割り当てられたエンタイトルメントのみを含める］オプションが利用できなくなります。
Include（含める）オプション
個別に割り当てられたアプリのみを含める	リソースのスコープをユーザーに個別に割り当てられたアプリに制限する場合は、このチェックボックスをオンにします。 グループによって割り当てられたアプリケーションを含めません。ユーザーに割り当てられたアプリとグループの両方をレビューするときの余分なレビューを減らす（アプリとグループを割り当てるグループはすでにレビューされているため）場合は、このオプションを使用します。
個別に割り当てられたグループのみを含める	リソースのスコープをユーザーに個別に割り当てられたグループに制限する場合は、このチェックボックスをオンにします。 グループルールによって割り当てられたグループを含めません。グループルールによって割り当てられたリソースに問題がなく、グループルール外で割り当てられたグループのみをレビューする場合は、このオプションが役立ちます。
Only include individually assigned entitlements（個別に割り当てられたエンタイトルメントのみを含める）	エンタイトルメントポリシーによって割り当てられたエンタイトルメント除外する場合は、このチェックボックスをオンにします。 キャンペーンでアプリのエンタイトルメントをレビューする場合は、アプリに対してGovernance Engineを有効にしたこと、およびエンタイトルメントを作成したことを確認してください。「エンタイトルメント管理を開始する」を参照してください。
Exclue（除外）オプション
特定のアプリをキャンペーンの対象から除外する	このチェックボックスをオンにして、キャンペーンから除外するアプリを指定します。
特定のグループをキャンペーンの対象から除外する	このチェックボックスをオンにして、キャンペーンから除外するグループを指定します。

レビュアー設定

レビュアータイプ

レビュアータイプ	アクション	コメント
ユーザー	キャンペーン内のすべてのユーザーのアクセス認定をレビューする必要があるレビュアーの名前を入力します。	このレビュアーは、すべてのレビューアイテムをレビューする責任を負います。
マネージャー	Oktaのユーザーのプロファイルにリストされているユーザーのマネージャーにレビューアイテムを割り当てます。 ［Fallback reviewer（最終レビュアー）］フィールドで、すべてのレビューアイテムをレビューする責任を負うユーザーを指定します。 推奨。［Preview reviewer（プレビューレビュアー）］リンクをクリックし、ユーザー名を入力します。［Preview（プレビュー）］をクリックし、割り当てられたレビュアーを表示します。	Oktaのユーザーのプロファイルにマネージャーがリストされていない場合、レビューは最終レビュアーに割り当てられます。
グループ	特定のユーザーグループのすべてのメンバーにレビューアイテムを割り当てます。	1人のグループメンバーのみがレビューを行い、レビューアイテムに対してアクションを実行する必要があります。そのため、グループメンバーがレビューアイテムへのアクセスを承認するか、取り消した場合、そのレビューアイテムはすべてのレビュアーに対して「完了済み」とマークされます。 ドロップダウンメニューには、1～10人のメンバーがいるグループのみが表示されます。それよりも多くのメンバーをグループに追加すると、レビューアイテムはグループの10人のメンバーにランダムに割り当てられます。
グループオーナー	Oktaのグループのプロファイルにリストされているグループのオーナーにレビューアイテムを割り当てます。 ［Fallback reviewer（最終レビュアー）］フィールドで、すべてのレビューアイテムをレビューする責任を負うユーザーを指定します。 推奨。［Preview reviewer（プレビューレビュアー）］リンクをクリックし、ユーザー名を入力します。［Preview（プレビュー）］をクリックし、割り当てられたレビュアーを表示します。	グループ内のグループオーナーの数が10人より多い場合、レビューアイテムは10人のグループオーナーにランダムに割り当てられます。 Group Owner（グループオーナー）のオプションは、次の条件が当てはまる場合のみ使用可能で有効です。 ［Resource（リソース）］ペインで1つ以上のグループをリソースとして選択した。 各グループのグループオーナーが個人またはグループである。どのグループについても、人とグループの組み合わせをグループオーナーにすることはできません。
カスタム	有効なOkta Expression Language式を入力して、レビュアーを指定します。 ［Fallback reviewer（最終レビュアー）］フィールドで、すべてのレビューアイテムをレビューする責任を負うユーザーを指定します。 推奨。［Preview reviewer（プレビューレビュアー）］リンクをクリックし、ユーザー名を入力します。［Preview（プレビュー）］をクリックし、割り当てられたレビュアーを表示します。	式は、レビュアーとして割り当てる必要があるユーザーのOktaユーザーIDまたはユーザー名を返す必要があります。「動的レビュアーを定義する」を参照してください。式がレビュアーの値を返さない場合は、最終レビュアーがユーザーのレビュアーとして割り当てられます。

Disable self-review（セルフレビューを無効にする）

このオプションは、含まれるリソースの重要性や機密性に応じて、キャンペーンのセルフレビューを許可するか許可しない柔軟性を提供します。

キャンペーンで ［Disable self-review（セルフレビューを無効にする）］ チェックボックスが選択されており、割り当てられるユーザーとレビュアーがたまたま同じ人物である場合、Oktaはキャンペーンの開始時に、レビュアータイプに応じて別のレビュアーにレビューを割り当てます。

• ［Manager（マネージャー）］、［Group owner（グループの所有者）］、または［Custom（カスタム）］：Oktaは、そのレビューアイテムを最終レビュアーに割り当てます。最終レビュアーが非アクティブ化されているか、Oktaに存在しない場合、または独自のレビューアイテムのレビュアーである場合、Oktaはキャンペーンの作成者にレビューを割り当てます。

  レビュアーとしてグループの所有者が2人以上いる場合、Oktaはそのレビューアイテムをこのユーザー以外のグループの所有者に割り当てます。

• ［User（ユーザー）］：Oktaはキャンペーンの作成者にそのレビューアイテムを割り当てます。

• ［Group（グループ）］：Oktaはこのユーザーではない、このグループのその他メンバーにそのレビューアイテムを割り当てます。グループのメンバーが1人のみで、そのメンバーがキャンペーンに含まれているユーザーでもある場合、Oktaはキャンペーンの作成者にレビューを割り当てます。

キャンペーンでセルフレビューが無効になっている場合、独自のレビューアイテムを承認、取り消し、または再割り当てすることはできません。

追加のレベル設定

• 第2レベルのレビュアーに送る第1レベルのレビュアーの決定を選択します。

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

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

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

Notifications（通知）

通知オプション	説明
Reviews assigned（レビューの割り当て）	キャンペーンの開始時にレビューアイテムが割り当てられたとき、およびレビューアイテムが再割り当てされたときに、レビュアーはメール通知を受け取ります。管理者は、キャンペーンの開始時にレビュアーが受け取るメールをカスタマイズできます。「メールテンプレートをカスタマイズする」を参照してください。
保留中レビューのリマインダー	保留中のレビューアイテムがあるレビュアーは、キャンペーンの終了前にメール通知を受け取ります。リマインダーは、キャンペーンの中間時点、キャンペーンの終了日、またはキャンペーン終了の数日前に送信されるように選択できます。 マルチレベルレビューが設定されているキャンペーンでは、第1レベルと第2レベルの両方のレビュアーがリマインダーを受け取ります。 管理者として自分もキャンペーンの終了予定日の前にリマインダーメールを受け取りたい場合は、このオプションを選択します。
第1レベルのレビュアーの期限切れリマインダー	レビューアイテムを保留している第1レベルのレビュアーは、第1レベルレビューの終了後、キャンペーンの終了まで毎日メール通知を受け取ります。 このオプションは、マルチレベルレビューが設定されているキャンペーンで使用できます。
キャンペーンの終了	キャンペーンが終了するときに、レビュアーはメール通知を受け取ります。管理者は、自分が作成したキャンペーンが開始または終了するときのメール通知に自動サブスクライブされています。また、キャンペーンの開始に失敗した場合は、キャンペーンのページへのリンクが記載されたメール通知を受け取ります。

追加設定

• ［Require justification（理由が必要）］：レビュアーがユーザーのリソースへのアクセスを承認または取り消した理由を入力することを必須にする場合は、このオプションを選択します。

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

修復設定

［修復］設定では、レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を決定できます。Okta Workflowsを使用して修復をカスタマイズすることもできます。グループルールまたはグループメンバーシップによってユーザーのアプリまたはグループが割り当てられた場合は、手動でレビューを修復する必要があります。

• レビュアーのアクションを選択する
• Okta Workflowsを使用して修復をカスタマイズする
• 修復を手動で処理する

レビュアーのアクションを選択する

キャンペーンの作成または編集中に、レビュアーのアクションに対して次の修復オプションのいずれかを選択できます。

レビュアーのアクション	利用可能なオプション
アクセスを承認する	デフォルトの修復は［Don’t take any action（アクションをとらない）］に設定されています。
アクセス権を取り消す	［Don’t take any action（アクションをとらない）］ ［Remove user from the resource（リソースからユーザーを削除）］
対応しない	［Don’t take any action（アクションをとらない）］ ［Remove user from the resource（リソースからユーザーを削除）］

レビューが1レベルのみのキャンペーンでは、修復プロセスは、レビュアーがユーザーのアクセスを承認または取り消した直後に開始されます。

Okta Workflowsを使用して修復をカスタマイズする

Okta Workflowsを使用すると、次のような修復タスクを自動化できます。

• ServiceNowなどのITサービス管理（ITSM）へのチケットをトリガーして、アプリケーションからアカウントを手動でデプロビジョニングします。

• 数日間、またはキャンペーンが終了するまで、修復イベントを遅らせます。

• アクセス権が削除されたユーザーにカスタム通知を送信して、ユーザーがそれを認識し、必要な場合は再度アクセス権を要求できるようにします。

すべてのアクセス認定決定をイベントとして使用して、カスタムワークフローを構築できます。Oktaコネクタの「アクセス認定決定の送信」を参照してください。

Okta Workflowsの構成の詳細については、「フローの構築」を参照してください。

修復を手動で処理する

［Remove user from the resource（リソースからユーザーを削除）］を修復オプションとして設定すると、次の場合に修復ステータスが［Manual Remediation Required（手動修復が必要）］と表示されることがあります。

• ユーザーがグループを通じてアプリケーションに割り当てられた。

• ユーザーがグループルールによってグループに追加された。

• ユーザーがアプリソースのグループのメンバーである。

手動修復に関する考慮事項

• グループからユーザーを削除する前に、ユーザーがグループから取得する割り当てを確認してください。アプリ、管理者ロール、サインオンポリシー、その他の権限は、多くの場合、グループを通じて割り当てられます。グループからユーザーを削除すると、そのユーザーがそのグループを通じて取得したすべての割り当てが取り消されます。

• ユーザーをアプリケーションに割り当てることができる複数のグループメンバーシップをユーザーが持っているかどうかを確認します。アクセスを削除するには、アプリケーションへのアクセスを付与するすべてのグループからそのユーザーを削除する必要があります。

• アプリソースのグループを削除する前に、ソースアプリでそのグループがどのように使用されているかを確認してください。

次の推奨アクションを実行して、アクセスを修復します。

リソース	割り当て元	推奨アクション
［Application（アプリケーション）］	Oktaソースのグループメンバーシップ	Okta Workflowsを使用して、Oktaソースのグループからユーザーを削除します。
［Application（アプリケーション）］	アプリソースのグループメンバーシップ（Active Directory（AD）グループなど）	アプリソースのグループからユーザーを削除します。
Oktaソースのグループ	グループルール	グループからユーザーを削除し、ユーザーをグループルールの例外として追加します。
アプリソースのグループ	インポート	アプリソースのグループからユーザーを削除します。

関連項目

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

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