修復

レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を決定できます。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（リソースからユーザーを削除）］

マルチレベルレビューが設定されているキャンペーンでは、第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ソースのグループ

グループルール

グループからユーザーを削除し、ユーザーをグループルールの例外として追加します。

アプリソースのグループ

インポート

アプリソースのグループからユーザーを削除します。

関連項目

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

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