キャンペーンウィザードのフィールド
ウィザードで要件を構成します。
Okta管理者ロールを管理するキャンペーンを作成または管理するときは、スーパー管理者としてサインインします。
Okta管理者ロールの管理は早期アクセス機能です。ただし、Okta Identity Governanceをサブスクライブしている方向けには公開されています。
一般設定
次のフィールドに値を入力します。
フィールド |
値 |
---|---|
Campaign name(キャンペーン名) | キャンペーンの名前を入力します。理想的には、レビュアーにとってわかりやすい名前を入力してください。 |
Description(説明) | キャンペーンの目的を説明します。 |
Start date(開始日) | キャンペーンの開始日を選択します。 |
Start Time(開始時刻) |
キャンペーンの開始時刻とタイムゾーンを選択します。 |
Duration(所要時間) |
キャンペーンを実行する期間を選択します。 マルチレベルレビュアーを使用したキャンペーンは、7日間以上の期間を設定する必要があります。 |
繰り返しキャンペーンに関する考慮事項
スーパー管理者またはアクセス認定管理者は、キャンペーンの繰り返しスケジュールをセットアップして、定期的に実行できるようにすることができます。これにより、時間を節約し、生産性を向上させることができます。ただし、繰り返しキャンペーンを構成するときは、次の基準に留意する必要があります。
-
一連の繰り返しキャンペーンでは、各キャンペーンの期間は、キャンペーン間の間隔よりも短くする必要があります。
-
[Repeats Every(繰り返し間隔)]セクションのドロップダウンメニューでは、キャンペーンの期間に入力した値と、日、週、月、年などの繰り返し頻度のタイプに応じて、事前入力されたさまざまなオプションを利用できます。
繰り返し頻度タイプ | 期間(日) | 繰り返し間隔* | コメント |
---|---|---|---|
繰り返しなし | 1~90の値を入力します。 | 該当なし | 該当なし |
日 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 1~182の値を入力します。 | 該当なし |
週 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 1~26の値を入力します。 | 該当なし |
月 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 1~24の値を入力します。 |
ドロップダウンメニューから次のいずれかのオプションを選択できます。
括弧内の値は[Start date(開始日)]に基づいて自動入力されます。 Monthly on [day of the week] of Week 5(毎月第5週の[曜日])に繰り返すようにキャンペーンを設定し、その日の前に月が終了する場合、キャンペーンは第4週のその日から開始されます。 月に指定日がない場合、最終日がキャンペーンの開始日として自動的に使用されます。たとえば、キャンペーンを毎月30日に繰り返すように設定した場合、キャンペーンは2月28日または2月29日に開始されます。 |
年 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 値として1または2を入力します。 | N/A |
キャンペーンの期間を延長する場合は、90日まで、またはキャンペーンの次の繰り返しが始まる1日前まで延長できます。
たとえば、あるキャンペーンが15日に終了し、次のキャンペーンが28日に始まる一連の繰り返しキャンペーンがあるとします。この場合は、最初のキャンペーンのキャンペーン期間を最長で27日まで延長できます。ただし、キャンペーンが90日超の間隔で繰り返されるときは、キャンペーンの合計期間が90日以内に収まる範囲でしかキャンペーンの期間を延長できません。
リソースキャンペーン設定
リソースキャンペーンは、リソース(アプリやグループなど)にアクセスできるユーザー、関連するエンタイトルメント(標準およびカスタム管理者ロールを含む)を表示します。SOC2やSOXなどのプロフェッショナル基準の監査要件やコンプライアンス要件を満たすのに役立ちます。定期的にリソースキャンペーンを実施し、機密リソースへのアクセスを制限する必要があります。
リソースキャンペーンに対して複数の設定を構成できます。最大50のリソースを選択でき、それらにアクセスできるユーザーを確認できます。また、リソースに割り当てられたすべてのユーザーを選択するか、Okta Expression Languageを使用して特定のユーザーセットを定義できます。Govern Okta管理者ロール機能を有効にしている場合は、既存の管理者割り当ては、エンタイトルメントとリソース(Admin Console)のキー値ペアとして扱われます。
キャンペーンのレビューアイテムの数は100,000を超えることはできません。大規模なキャンペーンを管理するには、レビューを複数のキャンペーンに分割します。
リソース設定
フィールド | 値 | |
---|---|---|
Type(タイプ) | ||
Application(アプリケーション) |
|
|
Group(グループ) | 1つ以上のグループを選択します。 キャンペーンにエンタイトルメントを含めるときは、[Group(グループ)]を選択しないでください。[Group(グループ)]を選択すると、[Review entitlements(エンタイトルメントをレビュー)]トグルを利用できなくなります。 |
ユーザー設定
利用可能なオプション | アクション | 説明 |
---|---|---|
All users assigned to the resource(リソースに割り当てられているすべてのユーザー) | 過去に選択されたリソースに割り当てられているユーザーを含めるときは、このオプションを選択します。 | 該当なし |
Specify user scope(ユーザースコープを指定) | ユーザースコープをorg内の特定のユーザーセットに制限するには、このオプションを選択します。
|
式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。 レルム機能を有効にしたときは、このオプションを使ってキャンペーンに含まれるユーザーを特定レルムからのユーザーに制限します。 「ユーザースコープを定義する」を参照してください。 |
Only include active Okta users in this campaign(アクティブなOktaユーザーのみをこのキャンペーンに含める) |
Oktaで次のいずれかのステータスになっているユーザーのみを含めるときは、このオプションを選択します。
|
該当なし |
Exclude users from the campaign(ユーザーをキャンペーンの対象から除外) |
特定のユーザーをキャンペーンから除外するには、[Exclude users from the campaign(ユーザーをキャンペーンの対象から除外)]をオンにし、キャンペーンから除外するユーザーの名前を入力します。 |
該当なし |
ユーザーキャンペーン設定
ユーザーキャンペーンは、キャンペーンのユーザー範囲の定義に重点を置いているため、それらのユーザーに割り当てられたすべてのリソースを包括的に確認できます。これにより、部門、ロール、プロジェクトの変更など、特定のイベントが発生したときに、ユーザーのアクセスレベルが上昇しないようにすることができます。
特定のユーザーまたはユーザーグループを選択し、割り当てられたリソースへのアクセスと関連エンタイトルメントをレビューできます。グループに割り当てられたリソースは、グループメンバーシップとグループルールに従うため、ユーザーに個別に割り当てられたリソースのみをレビュアーにレビューさせ、グループに割り当てられたリソースをレビューさせないようにキャンペーンを構成することもできます。
最大50のアプリ、グループ、またはその組み合わせを除外できます。キャンペーンのレビューアイテムの数は、1~100,000である必要があります。大規模なキャンペーンをより適切に管理できるように、レビューを複数のキャンペーンに分割します。
ユーザー設定
フィールド | 値 |
---|---|
Select users or groups(ユーザーまたはグループを選択) | |
Individual users(個々のユーザー) |
1人以上のユーザーを選択します。最大100人のユーザーを選択できます。 |
Specific groups(特定のグループ) |
1つ以上のグループを選択します。最大5つのグループを選択できます。 |
カスタム(Okta Expression Language) | Okta Expression Language式を入力し、特定の基準を満たすユーザーまたはグループを含めます。式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。 レルム機能を有効にしたときは、このオプションを使ってキャンペーンのユーザースコープを特定のレルムに制限します。 「ユーザースコープを定義する」を参照してください。 |
リソース設定
フィールド | 値 |
---|---|
Resource scope(リソースのスコープ) | |
All apps and groups assigned to users in scope(スコープ内のユーザーに割り当てられたすべてのアプリとグループ) |
過去に選択されたユーザーに割り当てられているすべてのアプリとグループを含めるときは、このオプションを選択します。 |
All apps assigned to users in scope(スコープ内のユーザーに割り当てられたすべてのアプリ) |
過去に選択されたユーザーに割り当てられているすべてのアプリを含めるときは、このオプションを選択します。 |
All groups assigned to users in scope(スコープ内のユーザーに割り当てられたすべてのグループ) |
過去に選択されたユーザーに割り当てられているすべてのグループを含めるときは、このオプションを選択します。 キャンペーンにエンタイトルメントを含める、または管理者ロールを管理するときは、[All groups(すべてのグループ)]を選択しないでください。[All groups(すべてのグループ)]を選択すると、[Only include individually assigned entitlements(個別に割り当てられたエンタイトルメントのみを含める)]オプションを利用できなくなります。 |
Include options(含めるオプション) | |
Only include individually assigned apps(個別に割り当てられたアプリのみを含める) |
リソースのスコープをユーザーに個別に割り当てられたアプリに制限するときは、このチェックボックスをオンにします。 グループによって割り当てられたアプリケーションを含めません。ユーザーに割り当てられたアプリとグループの両方をレビューする際の余分なレビューを減らす(アプリとグループを割り当てるグループはすでにレビューされているため)ときは、このオプションを使用します。 |
Only include individually assigned groups(個別に割り当てられたグループのみを含める) |
リソースのスコープをユーザーに個別に割り当てられたグループに制限するときは、このチェックボックスをオンにします。 グループルールによって割り当てられたグループを含めません。グループルールによって割り当てられたリソースに問題がなく、グループルール外で割り当てられたグループのみをレビューするときは、このオプションが役立ちます。 |
Only include individually assigned entitlements(個別に割り当てられたエンタイトルメントのみを含める) |
エンタイトルメントポリシーによって割り当てられたエンタイトルメント除外する、またはグループ割り当てによって割り当てられた管理者ロールを除外するときは、このチェックボックスをオンにします。 |
Exclude options(除外オプション) | |
Exclude specific apps from the campaign(特定のアプリをキャンペーンの対象から除外する) |
このチェックボックスをオンにして、キャンペーンから除外するアプリを指定します。 |
Exclude specific groups from the campaign(特定のグループをキャンペーンの対象から除外する) | このチェックボックスをオンにして、キャンペーンから除外するグループを指定します。 |
レビュアー設定
レビュアータイプ
キャンペーンに含まれるレビュアーがキャンペーン開始設定時刻に非アクティブ化または削除されている場合、キャンペーンは開始されません。
レビュアータイプ | アクション | コメント |
---|---|---|
User(ユーザー) |
キャンペーン内のすべてのユーザーのアクセス認定をレビューする必要があるレビュアーの名前を入力します。 |
このレビュアーは、すべてのレビューアイテムをレビューする責任を負います。 |
Manager(マネージャー) |
|
Oktaのユーザーのプロファイルにマネージャーがリストされていない場合、レビューは最終レビュアーに割り当てられます。 |
Group(グループ) |
特定のユーザーグループのすべてのメンバーにレビューアイテムを割り当てます。 |
1人のグループメンバーのみがレビューを行い、レビューアイテムに対してアクションを実行する必要があります。そのため、グループメンバーがレビューアイテムへのアクセスを承認するか、取り消した場合、そのレビューアイテムはすべてのレビュアーに対して「完了済み」とマークされます。 ドロップダウンメニューには、1~10人のメンバーがいるグループのみが表示されます。それよりも多くのメンバーをグループに追加すると、レビューアイテムはグループの10人のメンバーにランダムに割り当てられます。 |
Group owner(グループオーナー) |
|
グループ内のグループオーナーの数が10人より多い場合、レビューアイテムは10人のグループオーナーにランダムに割り当てられます。 Group Owner(グループオーナー)のオプションは、次の条件が当てはまる場合のみ使用可能で有効です。
|
Custom(カスタム) |
|
式は、レビュアーとして割り当てる必要があるユーザーのOktaユーザーIDまたはユーザー名を返す必要があります。式がレビュアーの値を返さないときは、最終レビュアーがユーザーのレビュアーとして割り当てられます。 レルム機能を有効にしたときは、このオプションを使ってキャンペーンのレビュアーを特定のレルムに制限します。 「動的レビュアーを定義する」を参照してください。 |
Disable self-review(セルフレビューを無効にする)
このオプションは、含まれるリソースの重要性や機密性に応じて、キャンペーンのセルフレビューを許可するか許可しない柔軟性を提供します。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効化されます。
キャンペーンで [Disable self-review(セルフレビューを無効にする)] チェックボックスが選択されており、割り当てられるユーザーとレビュアーがたまたま同じ人物である場合、Oktaはキャンペーンの開始時に、レビュアータイプに応じて別のレビュアーにレビューを割り当てます。
-
[Manager(マネージャー)]、[Group owner(グループの所有者)]、または[Custom(カスタム)]:Oktaは、そのレビューアイテムを最終レビュアーに割り当てます。最終レビュアーが非アクティブ化されているか、Oktaに存在しない場合、または独自のレビューアイテムのレビュアーである場合、Oktaはキャンペーンの作成者にレビューを割り当てます。
レビュアーとしてグループの所有者が2人以上いる場合、Oktaはそのレビューアイテムをこのユーザー以外のグループの所有者に割り当てます。
-
[User(ユーザー)]:Oktaはキャンペーンの作成者にそのレビューアイテムを割り当てます。
-
[Group(グループ)]:Oktaはこのユーザーではない、このグループのその他メンバーにそのレビューアイテムを割り当てます。グループのメンバーが1人のみで、そのメンバーがキャンペーンに含まれているユーザーでもある場合、Oktaはキャンペーンの作成者にレビューを割り当てます。
Oktaがキャンペーンの作成者にレビューアイテムを割り当て、次の条件のいずれかが満たされる場合、キャンペーンの開始は失敗します。
-
キャンペーンを作成したユーザーが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(レビューの割り当て) | キャンペーンの開始時にレビューアイテムが割り当てられたとき、およびレビューアイテムが再割り当てされたときに、レビュアーはメール通知を受け取ります。管理者は、キャンペーンの開始時にレビュアーが受け取るメールをカスタマイズできます。「メールテンプレートをカスタマイズする」を参照してください。 |
Reminder for pending reviews(保留中レビューのリマインダー) |
保留中のレビューアイテムがあるレビュアーは、キャンペーンの終了前にメール通知を受け取ります。リマインダーは、キャンペーンの中間時点、キャンペーンの終了日、またはキャンペーン終了の数日前に送信されるように選択できます。 マルチレベルレビューが設定されているキャンペーンでは、第1レベルと第2レベルの両方のレビュアーがリマインダーを受け取ります。 キャンペーン終了予定日の前に自分も管理者としてリマインダーメールを受け取りたいときは、このオプションを選択します。 |
Overdue reminders for first-level reviewers(第1レベルのレビュアーの期限切れリマインダー) |
レビューアイテムを保留している第1レベルのレビュアーは、第1レベルレビューの終了後、キャンペーンの終了まで毎日メール通知を受け取ります。 このオプションは、マルチレベルレビューが設定されているキャンペーンで使用できます。 |
Campaign ended(キャンペーンの終了) | キャンペーンが終了するときに、レビュアーはメール通知を受け取ります。管理者は、自分が作成したキャンペーンが開始または終了するときのメール通知に自動サブスクライブされます。また、キャンペーンの開始に失敗したときは、キャンペーンのページへのリンクが記載されたメール通知を受け取ります。 |
追加設定
-
[Require justification(理由が必要)]:レビュアーがユーザーのリソースへのアクセスを承認または取り消した理由を入力することを必須にするときは、このオプションを選択します。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効化されます。
-
[Disable bulk decisions(一括決定を無効にする)]:レビュアーが承認または取り消すレビューを複数選択することができないようにするときは、このオプションを選択します。それでもレビュアーは複数のレビューを別のユーザーに再割り当てできますが、再割り当ての理由を入力する必要があります([Require justification(理由が必要)]チェックボックスがオフであっても)。管理者ロールへのアクセスをレビューするキャンペーンでは、このオプションはデフォルトで有効化されます。
修復設定
修復設定では、レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を決定できます。Okta Workflowsを使用して修復をカスタマイズすることもできます。ユーザーのアプリまたはグループがグループルールまたはグループメンバーシップによって割り当てられたときは、手動でレビューを修復する必要があります。
レビュアーのアクションを選択する
キャンペーンの作成または編集中に、レビュアーのアクションに対して次の修復オプションのいずれかを選択できます。
レビュアーのアクション | 利用可能なオプション |
---|---|
アクセスを承認する | デフォルトの修復は[Don’t take any action(アクションをとらない)]に設定されます。 |
アクセス権を取り消す |
|
対応しない |
|
レビューが1レベルのみのキャンペーンでは、修復プロセスは、レビュアーがユーザーのアクセスを承認または取り消した直後に開始されます。
マルチレベルレビューが設定されているキャンペーンでは、第2レベルのレビュアーにレビューが送信されるのは、第1レベルのレビュアーがレビューを承認または取り消した後のみとなります。第1レベルのレビュアーが応答せずにキャンペーンが終了すると、レビュアーの[Doesn’t respond(応答しない)]の修復構成が適用されます。
これらのアイテムの最終レビュアーと以後の修復は、第2レベルのレビュアーに送られる第1レベルのレビュアーの決定によって決まります。
[Only approved decisions(承認された決定のみ)]:承認されたレビューの最終レビュアーは、第2レベルのレビュアーとなります。これらのレビュアーが応答せずにキャンペーンが終了すると、レビュアーの[Doesn’t respond(応答しない)]の修復構成が適用されます。
たとえば、[Only approved decisions(承認された決定のみ)]が第2レベルのレビュアーに送られるように選択します。この場合、第2レベルのレビュアーが、承認されたすべてのレビューアイテムの最終レビュアーとなりますが、取り消されたアイテムの最終レビュアーとはなりません。修復構成は、第2レベルのレビュアーが下した決定に適用されます。
ただし、第1レベルのレビュアーが取り消したレビューアイテムの最終レビュアーは、第1レベルのレビュアーです。これらのレビューには、[Revoke access(アクセス権を取り消す)]の修復構成が適用されます。
[Both approved and revoked decisions(承認された決定と取り消された決定の両方)]:承認されたすべてのレビューと取り消されたすべてのレビューの最終レビュアーは、第2レベルのレビュアーとなります。第2レベルのレビュアーが応答せずにキャンペーンが終了すると、レビュアーの[Doesn’t respond(応答しない)]の修復構成が適用されます。
たとえば、[Both approved and revoked decisions(承認された決定と取り消された決定の両方)]が第2レベルのレビュアーに送られるように選択します。この場合、第2レベルのレビュアーが、これらのレビューアイテムの最終レビュアーとなります。修復構成は、第2レベルのレビュアーが下した決定に適用されます。これらのレビュアーが応答しない場合、レビュアーの[Doesn’t respond(応答しない)]の修復構成が適用されます。
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-sourced group(Oktaソースのグループ)] |
グループルール |
グループからユーザーを削除し、ユーザーをグループルールの例外として追加します。 |
[App-sourced group(アプリソースのグループ)] |
インポート |
アプリソースのグループからユーザーを削除します。 |