キャンペーン設定
ウィザードで要件を構成します。
一般設定
次のフィールドに値を入力します。
フィールド |
値 |
---|---|
Campaign name(キャンペーン名) | キャンペーンの名前を入力します。理想的には、レビュアーにとってわかりやすい名前を入力してください。 |
説明 | キャンペーンの目的を説明します。 |
Start date(開始日) | キャンペーンの開始日を選択します。 |
Start Time(開始時刻) |
キャンペーンの開始時刻とタイムゾーンを選択します。 |
Duration(所要時間) |
キャンペーンを実行する期間を選択します。 マルチレベルレビュアーを使用したキャンペーンは、7日間以上の期間を設定する必要があります。 |
繰り返しキャンペーンに関する考慮事項
スーパー管理者またはアクセス認定管理者は、キャンペーンの繰り返しスケジュールをセットアップして、定期的に実行できるようにすることができます。これにより、時間を節約し、生産性を向上させることができます。ただし、繰り返しキャンペーンを構成するときは、次の基準に留意する必要があります。
-
一連の繰り返しキャンペーンでは、各キャンペーンの期間は、キャンペーン間の間隔よりも短くする必要があります。
-
[Repeats Every(繰り返し間隔)]セクションのドロップダウンメニューでは、キャンペーンの期間に入力した値と、日、週、月、年などの繰り返し頻度のタイプに応じて、事前入力されたさまざまなオプションを利用できます。
繰り返し頻度タイプ | 期間(日) | 繰り返し間隔* | コメント |
---|---|---|---|
繰り返しなし | 1~90の値を入力します。 | 該当なし | 該当なし |
日 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 1~182の値を入力します。 | 該当なし |
週間 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 1~26の値を入力します。 | 該当なし |
月 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 1~24の値を入力します。 |
ドロップダウンメニューから次のいずれかのオプションを選択できます。
括弧内の値は[Start date(開始日)]に基づいて自動入力されます。 毎月第5週の [曜日]に繰り返すようにキャンペーンを設定し、その日の前に月が終了した場合、キャンペーンは第4週のその日から開始されます。 月に指定日がない場合、最終日がキャンペーンの開始日として自動的に使用されます。たとえば、キャンペーンを毎月30日に繰り返すように設定した場合、キャンペーンは2月28日または2月29日に開始されます。 |
年 | 1~90の範囲で、繰り返し間隔よりも小さい値を入力します。 | 値として1または2を入力します。 | 該当なし |
リソースキャンペーン設定
リソースキャンペーンはキャンペーンのリソーススコープの設定に重点を置いているため、それらのリソースにアクセスできるすべてのユーザーを確認できます。このキャンペーンは、機密リソースへのアクセスを確認し、コンプライアンス要件を満たすのに役立ちます。
アプリまたはグループなどのリソースを選択し、誰がアクセス可能かを確認します。リソースに割り当てられたすべてのユーザーを選択するか、Okta Expression Languageを使用して特定のユーザーを定義できます。キャンペーンから特定のユーザーを除外することもできます。定期的にリソースキャンペーンを実施し、機密リソースへのアクセスを制限するようにします。
リソースキャンペーンは、SOC2やSOXなどのプロフェッショナル基準の監査要件やコンプライアンス要件を満たすのに役立ちます。
キャンペーンには最大50個のリソースを追加できます。キャンペーンのレビューアイテムの数は、1~100,000である必要があります。大規模なキャンペーンをより適切に管理できるように、レビューを複数のキャンペーンに分割します。
リソース設定
フィールド | 値 |
---|---|
タイプ | |
アプリケーション |
1つ以上のアプリケーションを選択します。 |
グループ | 1つ以上のグループを選択します。 |
ユーザー設定
利用可能なオプション | アクション | 説明 |
---|---|---|
リソースに割り当てられているすべてのユーザー | 前に選択したリソースに割り当てられているユーザーを含める場合は、このオプションを選択します。 | 該当なし |
ユーザースコープを指定 |
|
このオプションは、ユーザースコープを特定のユーザーセットに制限します。式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。「ユーザースコープを定義する」を参照してください。 |
ユーザーをキャンペーンの対象から除外する |
特定のユーザーをキャンペーンから除外するには、[Exclude users from the campaign(ユーザーをキャンペーンの対象から除外)]をオンにし、キャンペーンから除外するユーザーの名前を入力します。 |
該当なし |
ユーザーキャンペーン設定
ユーザーキャンペーンは、キャンペーンのユーザー範囲の定義に重点を置いているため、それらのユーザーに割り当てられたすべてのリソースを包括的に確認できます。これにより、部門、ロール、プロジェクトの変更など、特定のイベントが発生したときにユーザーのアクセス レベルが上昇しないようにすることができます。
特定のユーザーまたはユーザーグループを選択し、割り当てられたリソースへのアクセスを確認できます。グループに割り当てられたリソースは、グループメンバーシップとグループルールに従うため、ユーザーに個別に割り当てられたリソースのみをレビュアーにレビューさせ、グループに割り当てられたリソースをレビューさせないようにキャンペーンを構成することもできます。
最大50のアプリ、グループ、またはその組み合わせを除外できます。キャンペーンのレビューアイテムの数は、1~100,000である必要があります。大規模なキャンペーンをより適切に管理できるように、レビューを複数のキャンペーンに分割します。
ユーザー設定
フィールド | 値 |
---|---|
ユーザーまたはグループを選択 | |
個々のユーザー |
1人以上のユーザーを選択します。最大100人のユーザーを選択できます。 |
特定のグループ |
1つ以上のグループを選択します。最大5つのグループを選択できます。 |
カスタム(Okta Expression Language) |
Okta Expression Language式を入力し、特定の基準を満たすユーザーまたはグループを含めます。 このオプションは、ユーザースコープを特定のユーザーセットに制限します。式の結果は、ユーザーをキャンペーンに含める場合はtrue、キャンペーンから除外する場合はfalseになります。「ユーザースコープを定義する」を参照してください。 |
リソース設定
フィールド | 値 |
---|---|
リソースのスコープ | |
スコープ内のユーザーに割り当てられたすべてのアプリとグループ |
前に選択したユーザーに割り当てられているすべてのアプリとグループを含める場合は、このオプションを選択します。 |
スコープ内のユーザーに割り当てられたすべてのアプリ |
前に選択したユーザーに割り当てられているすべてのアプリを含める場合は、このオプションを選択します。 |
スコープ内のユーザーに割り当てられたすべてのグループ |
前に選択したユーザーに割り当てられているすべてのグループを含める場合は、このオプションを選択します。 |
Include(含める)オプション | |
個別に割り当てられたアプリのみを含める |
リソースのスコープをユーザーに個別に割り当てられたアプリに制限する場合は、このチェックボックスをオンにします。 グループによって割り当てられたアプリケーションを含めません。ユーザーに割り当てられたアプリとグループの両方をレビューするときの余分なレビューを減らす(アプリとグループを割り当てるグループはすでにレビューされているため)場合は、このオプションを使用します。 |
個別に割り当てられたグループのみを含める |
リソースのスコープをユーザーに個別に割り当てられたグループに制限する場合は、このチェックボックスをオンにします。 グループルールによって割り当てられたグループを含めません。グループルールによって割り当てられたリソースに問題がなく、グループルール外で割り当てられたグループのみをレビューする場合は、このオプションが役立ちます。 |
Exclue(除外)オプション | |
特定のアプリをキャンペーンの対象から除外する |
このチェックボックスをオンにして、キャンペーンから除外するアプリを指定します。 |
特定のグループをキャンペーンの対象から除外する | このチェックボックスをオンにして、キャンペーンから除外するグループを指定します。 |
レビュアー設定
レビュアータイプ
- ここで選択したレビュアーは、[Access Certification Reviewer(アクセス認定レビュアー)]グループに自動的に追加されます。[Access Certification Reviewer(アクセス認定レビュアー)]グループを名前変更、変更、または削除しないでください。このグループを誤って削除してしまった場合は、Oktaサポートにお問い合わせください。
- キャンペーンを開始すると設定した時刻にキャンペーンに含まれるレビュアーが非アクティブ化または削除されている場合、キャンペーンは開始されません。
レビュアータイプ | アクション | コメント |
---|---|---|
ユーザー |
キャンペーン内のすべてのユーザーのアクセス認定をレビューする必要があるレビュアーの名前を入力します。 |
このレビュアーは、すべてのレビューアイテムをレビューする責任を負います。 |
マネージャー |
|
Oktaのユーザーのプロファイルにマネージャーがリストされていない場合、レビューは最終レビュアーに割り当てられます。 |
グループ |
特定のユーザーグループのすべてのメンバーにレビューアイテムを割り当てます。 |
1人のグループメンバーのみがレビューを行い、レビューアイテムに対してアクションを実行する必要があります。そのため、グループメンバーがレビューアイテムへのアクセスを承認するか、取り消した場合、そのレビューアイテムはすべてのレビュアーに対して「完了済み」とマークされます。 ドロップダウンメニューには、1~10人のメンバーがいるグループのみが表示されます。それよりも多くのメンバーをグループに追加すると、レビューアイテムはグループの10人のメンバーにランダムに割り当てられます。 |
グループオーナー |
|
グループ内のグループオーナーの数が10人より多い場合、レビューアイテムは10人のグループオーナーにランダムに割り当てられます。 グループオーナーのオプションは、次の条件が当てはまる場合のみ使用可能で有効です。
|
カスタム |
|
式は、レビュアーとして割り当てる必要があるユーザーの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レベルのレビューに期限切れのフラグが立てられます。
通知
通知オプション | 説明 |
---|---|
Reviews assigned(レビューの割り当て) | キャンペーンの開始時にレビューアイテムが割り当てられたとき、およびレビューアイテムが再割り当てされたときに、レビュアーはメール通知を受け取ります。管理者は、キャンペーンの開始時にレビュアーが受け取るメールをカスタマイズできます。「メールテンプレートをカスタマイズする」を参照してください。 |
保留中レビューのリマインダー |
保留中のレビューアイテムがあるレビュアーは、キャンペーンの終了前にメール通知を受け取ります。リマインダーは、キャンペーンの中間時点、キャンペーンの終了日、またはキャンペーン終了の数日前に送信されるように選択できます。 マルチレベルレビューが設定されているキャンペーンでは、第1レベルと第2レベルの両方のレビュアーがリマインダーを受け取ります。 管理者として自分もキャンペーンの終了予定日の前にリマインダーメールを受け取りたい場合は、このオプションを選択します。 |
第1レベルのレビュアーの期限切れリマインダー |
レビューアイテムを保留している第1レベルのレビュアーは、第1レベルレビューの終了後、キャンペーンの終了まで毎日メール通知を受け取ります。 このオプションは、マルチレベルレビューが設定されているキャンペーンで使用できます。 |
キャンペーンの終了 | キャンペーンが終了するときに、レビュアーはメール通知を受け取ります。管理者は、自分が作成したキャンペーンが開始または終了するときのメール通知に自動サブスクライブされています。また、キャンペーンの開始に失敗した場合は、キャンペーンのページへのリンクが記載されたメール通知を受け取ります。 |
修復設定
[修復]設定では、レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を決定できます。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ソースのグループ |
グループルール |
グループからユーザーを削除し、ユーザーをグループルールの例外として追加します。 |
アプリソースのグループ |
インポート |
アプリソースのグループからユーザーを削除します。 |