キャンペーン作成のベストプラクティス

キャンペーンを作成する前に、これらのベストプラクティスを参考にしてください。

Okta管理者ロールの管理を有効にした場合には、リソースキャンペーンを使用して、ユーザーの管理者ロール割り当てを見直してください。

注:

Okta管理者ロールの管理機能は、Okta Identity Governanceをサブスクライブしている方向けには公開されています。サブスクライブしていない場合、orgの適格性によってはOkta管理者ロールの管理機能を利用できない可能性があります。詳細については、アカウントエグゼクティブまたはカスタマーサクセスマネージャーまでお問い合わせください。

一般設定

わかりやすいキャンペーン名を選択してください。キャンペーン名はレビュアーに表示されます。
キャンペーンの説明には、レビュアーがキャンペーンの目的を理解する上で役立つ情報を含めます。たとえば、ユーザーのSalesforce権限を確認するキャンペーンをセットアップした場合、それをキャンペーンの説明として追加して、レビュアーにコンテキストを提供できます。
キャンペーンに関連付けられたリソースがOktaに存在し、非アクティブ化または削除されていないことを確認してください。
既知の問題と制限事項に留意してください。
繰り返しキャンペーンに関する考慮事項を参照してください。
監査およびコンプライアンスの要件を満たすためにリソースキャンペーンを実行している場合は、監査者レポートパッケージを作成（Create auditor reporting package）チェックボックスを選択することを検討してください。これにより、キャンペーンスコープに含まれるリソース、ユーザー、レビュアーに関する情報を提供するレポートを生成できるようになります。また、キャンペーン開始時のユーザーアクセス、レビューの決定、キャンペーン終了後の修復結果とユーザーアクセスついてレポートされます。監査者レポートパッケージを生成するを参照してください。

リソース設定

orgでリソースラベルが有効になっていてリソースに割り当てられている場合、リソースラベルを使用して、リソースキャンペーンに含める必要のあるリソースをフィルタリングして指定できます。Oktaは、デフォルトでクラウンジュエル（Crown Jewel）と特権（Privileged）のラベル値を提供します。ただし、ラベルの完全なリスト、orgのラベルでタグ付けされたリソースを表示する、またはリソースにラベルを割り当てるには、Labels APIを使用します。
ラベルを表示できるのはスーパー管理者またはアクセス認定管理者のみです。
サービスアカウントを認証するリソースキャンペーンを作成するときは、Okta Privileged Accessで管理されるサービスアカウントを持つアプリのみが利用可能なことにご注意ください。アプリに関連付けられたサービスアカウントは、Okta Privileged Accessをサブスクライブしている場合にのみリソースとして利用可能です。サービスアカウントを認定するを参照してください。

レビュアー設定（Reviewer settings）

選択したレビュアーと最終レビュアーがOktaでアクティブになっていることを確認します。
ユーザーのマネージャーをレビュアーとして割り当てるには、マネージャー（Manager）またはカスタム（Custom）のレビュアータイプを使用します。
- マネージャー（Manager）レビュアータイプ：managerIdユーザー属性が、ユーザーのマネージャーのOktaユーザー名またはOkta IDに設定されていることを確認します。
- カスタム（Custom）レビュアータイプ：参照する属性にマネージャーのOktaユーザー名またはOkta IDが含まれていることを確認します。たとえば、user.profile.manager属性を参照する場合、マネージャーのOktaユーザー名またはOkta IDをユーザーのプロファイルページに入力する必要があります。
  
  設定されていない場合は、キャンペーンはマネージャーの特定に失敗し、レビューは最終レビュアーに割り当てられます。
キャンペーンでアプリのエンタイトルメントをレビューする場合は、アプリに対してGovernance Engineを有効にしたこと、およびエンタイトルメントを作成したことを確認します。「エンタイトルメント管理を開始する」を参照してください。
グループ所有者（Group Owner）のレビュアータイプを使用するには、Oktaにグループ所有者が構成されていることを確認します。「Oktaグループ所有者を構成する」を参照してください。
レビュアータイプとしてリソース所有者（Resource owner）を使用する場合は、次の考慮事項に留意してください。
- Oktaは、キャンペーンでレビューされるリソースに応じてグループ、アプリ、エンタイトルメント、エンタイトルメントバンドル、またはリソースコレクションの所有者をレビュアーとして割り当てます。
- キャンペーン開始時にエンタイトルメントバンドルまたはエンタイトルメント所有者が利用できない場合は、アプリ所有者がレビュアーとして割り当てられます。アプリ所有者も利用できない場合は、Oktaはキャンペーンのレビュアー（Reviewer）設定で指定された最終レビュアーにレビューアイテムを割り当てます。
- コレクション所有者が利用できない場合、レビューは最終レビュアーに割り当てられます。
- Okta Privileged Accessのサブスクライバーの場合：サービスアカウントを認証するためのレビュアータイプとしてリソース所有者（Resource Owner）を選択すると、Oktaはサービスアカウントの所有者グループ（Owner groups）または所有者ユーザー（Owner users）属性に指定された値を使用して、レビュアーを割り当てます。サービスアカウントに対してこれらの値が定義されていない、または利用できない場合、レビューは最終レビュアーに割り当てられます。
重要なリソースに対する自分自身のアクセスをユーザーがレビューや承認しないように、レビュアーを定義する際にセルフレビューを無効にする（Disable self-review）チェックボックスを選択します。
任意。レビュアーがアクセス決定の理由を入力する必要がある場合をより詳細に制御するには、理由の要件のカスタマイズ（Customize Justification Requirements）機能を有効にします。すべての決定の理由を任意にする、決定を取り消す場合のみ必須にする、すべての決定で必須にする、または完全にオフにすることができます。「早期アクセス機能とBeta機能を管理する」を参照してください。

注:
理由の要件のカスタマイズ（Customize Justification Requirements）を有効にすると、この機能を有効にする前に理由が必要（Require justification）を選択したかどうかに応じて、既存のキャンペーンについて任意（Optional）またはアクセスの承認と取り消しに必要（Required for approve and revoke）オプションが自動的に選択されます。
マルチレベルレビューが設定されたキャンペーンでは、次の事項を考慮してください。
- 1つのキャンペーンに2レベルのレビューをセットアップできます。
- 第2レベルのレビュアーにレビューアイテムが送信されるのは、第1レベルのレビュアーがそれを承認または取り消した後のみとなります。キャンペーンの進捗を妨害しないためには、第1レベルのレビュアーが予定どおりにレビューアイテムの決定を下すことが重要です。
- 第2レベルのレビュアーは、レビューアイテムに関する第1レベルのレビュアーの決定とその理由を表示できます。
- 最終レビュアーは、キャンペーンの構成によって異なります。
- キャンペーン向けに構成する修復オプションは、最終レビュアーが下した決定に適用されます。修復を理解するを参照してください。
一定期間、レビュアーが対応不可であることが判明している場合は、Admin Consoleからレビュアーの代理人を割り当てることができます。Governance代理人およびAdmin Consoleから代理人を割り当てるを参照してください。
Slackでレビュアーに通知するには、Slackワークスペースをorgに接続し、OktaでSlack通知を有効にします。Slackを統合します。