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

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

Okta管理者ロールを管理（Govern Okta admin roles）を有効にした場合には、このキャンペーンタイプを使用して、ユーザーの管理者ロール割り当てを見直してください。アプリやグループなどのリソースを選択して、そのリソース、関係付けられているエンタイトルメントやバンドル（標準ロールと標準ロールとカスタム管理者ロールを含む）にアクセスできる人を確認することができます。

リソースコレクション、およびリソースコレクションの認定 - リソースコレクション（Certify resource collections - Resource collections）機能を有効にした場合、リソースキャンペーンを使用して、コレクションへのアクセスを確認し、取り消すことができます。

アプリに関連付けられたサービスアカウントは、Okta Privileged Accessをサブスクライブしている場合にもリソースとして利用可能です。キャンペーンに含めるには、サービスアカウントを持つアプリはOkta Privileged Accessで管理される必要があります。サービスアカウントを認定するを参照してください。

リソースに割り当てられたすべてのユーザーを選択するか、Okta式言語を使用して特定のユーザーを定義できます。キャンペーンから特定のユーザーを除外することもできます。

開始する前の確認事項

  • 任意。決定を取り消す場合にのみ理由を必須にするなど、レビュアーのより詳細な理由の要件を構成するには、理由の要件のカスタマイズ（Customize Justification Requirements）機能を有効にします。「早期アクセス機能とBeta機能を管理する」を参照してください。

  • orgでリソースラベルが有効になっていてリソースに割り当てられている場合、リソースラベルを使用して、リソースキャンペーンに含める必要のあるリソースをフィルタリングして指定できます。Oktaは、デフォルトでクラウンジュエル（Crown Jewel）と特権（Privileged）のラベル値を提供します。ただし、ラベルの完全なリスト、orgのラベルでタグ付けされたリソースを表示する、またはリソースにラベルを割り当てるには、Labels APIを使用します。ラベルを表示できるのはスーパー管理者またはアクセス認定管理者のみです。

  • 選択したレビュアーと最終レビュアーがOktaでアクティブになっていることを確認します。

  • グループ、アプリ、エンタイトルメント、エンタイトルメントバンドル、またはコレクションの所有者は、リソース所有者と見なされます。Oktaは、キャンペーン開始時にリソース所有者をレビュアーとして割り当てます。

    • エンタイトルメント所有者が利用できず、エンタイトルメントが含まれるバンドルがある場合、バンドルがキャンペーンのリソーススコープに含まれていれば、バンドル所有者がレビュアーとして割り当てられます。

    • エンタイトルメント所有者が利用できず、そのエンタイトルメントが含まれるバンドルがない場合は、アプリ所有者がレビュアーとして割り当てられます。

    • エンタイトルメントバンドル所有者が利用できない場合は、アプリ所有者がレビュアーとして割り当てられます。

    • アプリ所有者も利用できない場合は、Oktaはキャンペーンのレビュアー（Reviewer）設定で指定された最終レビュアーにレビューアイテムを割り当てます。

    • グループ所有者が利用できない場合は、Oktaはキャンペーンのレビュアー（Reviewer）設定で指定された最終レビュアーにレビューアイテムを割り当てます。

    • コレクション所有者が利用できない場合、レビューは最終レビュアーに割り当てられます。

  • Okta for AI Agentsのサブスクライバーの場合：レビュアータイプとしてリソース所有者（Resource Owner）を選択すると、レビューはAIエージェントにリンクされたユーザーサインオンアプリの所有者に割り当てられます。ただし、そのユーザーが非アクティブ化されている、またはアプリ所有者が定義されていない場合、レビューはAIエージェント所有者に割り当てられます。これは、アプリにリンクされたAIエージェントが1つのみある場合に適用されます。

  • Okta Privileged Accessのサブスクライバーの場合：サービスアカウントを認証するためのレビュアータイプとしてリソース所有者（Resource Owner）を選択すると、Oktaはサービスアカウントの所有者グループ（Owner groups）または所有者ユーザー（Owner users）属性に指定された値を使用して、レビュアーを割り当てます。サービスアカウントに対してこれらの値が定義されていない、または利用できない場合、レビューは最終レビュアーに割り当てられます。

  • 任意。一定期間、レビュアーが対応不可であることが判明している場合は、Admin Consoleからレビュアーの代理人を割り当てることができます。Admin Consoleから代理人を割り当てるを参照してください。レビュアータイプ（Reviewer type）がグループ（Group）、またはグループ所有者（Group Owner）かリソース所有者（Resource Owner）のキャンペーンでは、自身またはグループメンバーがグループのメンバーではない代理人を割り当てると、今後のレビューアイテムは既存のグループメンバーに加えて代理人にも割り当てられます。

  • 最大250のアプリ、グループ、またはその両方を選択して、それらにアクセスできる人を確認することができます。「既知の問題と制限事項」を参照してください。

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

  • 管理者ロールを管理するためのキャンペーンを作成するときは、スーパー管理者としてサインインしていることを確認します。任意で、次の手順を完了します。

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

  • 任意。Slackでレビュアーに通知するには、キャンペーンを開始する前に、Access CertificationにSlackを有効にする（Enable Slack for Access Certifications）トグルがオンになっていることを確認します。Slack通知を有効にするを参照してください。

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

  1. Admin Consoleで、IDガバナンス（Identity Governance） > アクセス認定 > 認定キャンペーン（Certification campaigns）に移動します。

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

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

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

一般設定を構成する

次の設定を構成します。

  1. キャンペーン名（Campaign name）：キャンペーンの名前を入力します。理想的には、レビュアーにとってわかりやすい名前を入力してください。
  2. 説明（Description）：キャンペーンの目的を説明します。
  3. 開始日（Start date）：キャンペーンの開始日を選択します。
  4. 開始時刻（Start time）：キャンペーンの開始時刻とタイムゾーンを選択します。
  5. 所要時間（Duration）：キャンペーンを実行する期間を選択します。マルチレベルレビュアーを使用したキャンペーンは、7日間以上の期間を設定する必要があります。
  6. 任意。これを繰り返す（Make this recurring）を選択して、キャンペーンの定期スケジュールを設定します。繰り返しキャンペーンを効率よく計画する方法については、「繰り返しキャンペーンに関する考慮事項」を参照してください。
  7. 任意。監査者レポートパッケージを作成（Create auditor reporting package）チェックボックスを選択します。これにより、監査とコンプライアンスの要件に役立つレポートを生成できるようになります。これにより、キャンペーンスコープに含まれるリソース、ユーザー、レビュアーに関する情報を提供するレポートを生成できるようになります。また、キャンペーン開始時のユーザーアクセス、レビューの決定、キャンペーン終了後の修復結果とユーザーアクセスついてレポートされます。

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

リソースタイプにアプリケーション（Application）、グループ（Group）、サービスアカウント（Service account）、またはコレクション（Collection）を選択します。

アプリケーション（Application）

  1. 次のいずれかの方法を使用します。

    • アプリ、エンタイトルメント、バンドルなど関連リソースをすべて含める場合は、最大10個のラベルを選択します。ラベルを使用してスコープを指定するときは、個々のアプリを選択できません。

    • 個々のアプリを選択します。SODルールに競合するものも含めて、エンタイトルメントをレビューするには、アプリを最大20個まで選択できます。「既知の問題と制限事項」を参照してください。個々のアプリを選択した場合、ラベルは使用できません。

    • 管理者ロールを管理するには、Okta Admin Consoleを検索して選択します。これを選択すると、他のアプリは追加できません。

  2. エンタイトルメントをレビューする（Review entitlements）トグルを有効にして、Governanceラベルが付いたもの、またはSODルールに競合するものも含めて、エンタイトルメントをレビューします。ただし、非アクティブのユーザーを持つアプリをレビューする場合は、オフのままにしておきます。

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

    ラベルを有効にし構成している場合は、追加のオプションを利用できます。

    1. 次のいずれかのオプションを選択します。

      • 特定のGovernanceラベルが付いたエンタイトルメント（Entitlements with specific governance labels）
      • 特定のGovernanceラベルが付いたバンドル（Bundles with specific governance labels）
      • 特定のGovernanceラベルが付いたエンタイトルメントまたはバンドル（Entitlements or bundles with specific governance labels）

    2. ラベルを指定します。

  4. エンタイトルメントを特定した場合は、これらのエンタイトルメント値を持つバンドルを含める（Include bundles with these entitlement values）チェックボックスを選択して、エンタイトルメント値を含むバンドルを取得することもできます。

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

グループ（Group）

次のいずれかの方法で1つ以上のグループを選択します。

  • 関連付けられたグループをすべて含める場合は、ラベルを最大10個まで選択します。ラベルを使用してスコープを指定する場合は、個々のグループを選択できません。

  • 個々のグループを選択します。個々のグループを選択した場合は、ラベルを使用できません。

サービスアカウント

このオプションは、Okta Privileged Accessをサブスクライブしている方のみご利用いただけます。「Okta Privileged Accessとアクセス認定」を参照してください。Okta Privileged Accessで管理されるサービスアカウントを持つアプリのみが利用可能なことにご注意ください。

サービスアカウントタイプをSaaSアプリケーションのサービスアカウント（SaaS application service account）またはOktaサービスアカウント（Okta service account）に設定します。

SaaSアプリケーションのサービスアカウント（SaaS application service account）

次のいずれかの方法を使用します。

  • サービスアカウントを持つ関連付けられたアプリをすべて含める場合は、ラベルを最大10個まで選択します。ラベルを使用してスコープを指定するときは、個々のアプリを選択できません。ラベルを選択すると、そのラベルに関連付けられたすべてのアプリがキャンペーンに含まれます。

  • 個々のアプリを選択します。「既知の問題と制限事項」を参照してください。個々のアプリを選択した場合、ラベルは使用できません。

    1. スコープを選択（Select scope）ドロップダウンメニューから、すべてのサービスアカウント（All service accounts）または特定のサービスアカウント（Specific service accounts）を選択し、アカウントを指定します。個別に選択する場合、最大20個のサービスアカウントを指定できます。

    2. 次へ（Next）をクリックします。

Oktaサービスアカウント（Okta service account）

  1. スコープを選択（Select scope）ドロップダウンメニューから、すべてのサービスアカウント（All service accounts）または特定のサービスアカウント（Specific service accounts）を選択し、アカウントを指定します。最大20個のサービスアカウントを指定できます。

  2. 次へ（Next）をクリックします。

コレクション

このオプションは、リソースコレクションとリソースコレクションの認定を有効にした場合にのみ利用できます。

  1. 次のいずれかの方法を使用します。

    • 関連付けられたリソースコレクションをすべて含める場合は、ラベルを最大10個まで選択します。ラベルを使用してスコープを指定する場合は、個々のコレクションを選択できません。ラベルを選択すると、そのラベルに関連付けられたすべてのコレクションがキャンペーンに含まれます。

    • 個別のコレクションを選択します。個々のコレクションを選択した場合は、ラベルを使用できません。

  2. 次へ（Next）をクリックします。

AIエージェント

このオプションは、Okta for AI Agentsをサブスクライブしている方のみご利用いただけます。

AIエージェントがリンクされているユーザーサインオンアプリを選択します。

ユーザーの設定を構成する

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

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

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

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

      2. 推奨。式スコープをプレビュー（Preview expression scope）をクリックし、UIプロンプトに従って、指定したOkta Expression Language（OEL）のスコープに含まれるかどうかを検証してください。

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

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

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

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

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

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

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

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

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

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

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

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

      • 各グループのグループ所有者は、個々のユーザー、グループ、またはその両方にすることができます。グループが10人より多い場合、レビューアイテムは10人のグループ所有者にランダムに割り当てられます。

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

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

  2. 最終レビュアー（Fallback reviewer）フィールドで、すべてのレビューアイテムをレビューする責任を負うユーザーを指定します。

    キャンペーン開始時にエンタイトルメントバンドルまたはエンタイトルメント所有者が利用できない場合は、アプリ所有者がレビュアーとして割り当てられます。アプリ所有者も利用できない場合は、Oktaはキャンペーンのレビュアー（Reviewer）設定で指定された最終レビュアーにレビューアイテムを割り当てます。

  3. 推奨。プレビューレビュアー（Preview reviewer）リンクをクリックし、UIのプロンプトに従ってください。

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

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

  6. 第2レベルのレビュアーを追加した場合には、追加レベルの設定（Additional level settings）セクションで、第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レベルの両方のレビュアーがリマインダーを受け取ります。

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

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

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

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

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

      orgで理由の要件のカスタマイズ（Customize Justification Requirements）が有効になっている場合、理由が必要（Require justification）チェックボックスは理由設定（Justification Settings） セクションに置き換えられます。次のいずれかのオプションを選択します。

      • 任意（Optional）：レビュアーは、アクセスの承認または取り消しの決定理由を入力するかどうか、選択できます。

      • アクセスの取り消しにのみに必要（Required for revoke access only）：レビュアーは、アクセスを取り消す場合に理由を入力する必要があります。

      • アクセスの取り消しには必須、承認には任意（Required for revoke and optional for approve access）：レビュー担当者は、アクセスを取り消す場合に理由を入力する必要があります。ただし、アクセスを承認する場合には、理由を入力するかどうかを選択できます。

      • アクセスの承認と取り消しに必要（Required for approve and revoke access）：レビュアーは、アクセスを承認または取り消す場合に理由を入力する必要があります。

      • 無効（Disabled）：レビュアーに、アクセスが承認または取り消される理由を説明するオプションはありません。

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

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

修復設定を構成する

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

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

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

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

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

関連項目

Okta Expression Languageの例

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

スケジュールされたアクセス認定キャンペーンを変更する

アクティブなアクセス認定キャンペーンを終了する