修復を理解する

修復設定では、レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を決定できます。Okta Workflowsを使用して修復をカスタマイズすることもできます。ユーザーのアプリまたはグループがグループルールまたはグループメンバーシップによって割り当てられたときは、手動でレビューを修復する必要があります。

マルチレベルレビューが設定されたキャンペーンを修復する

レビューが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（手動修復が必要）］と表示されることがあります。

  • ユーザーがグループまたはリソースコレクションを通じてアプリケーションに割り当てられた。

  • ユーザーがグループルールによってグループに追加された。

  • ユーザーがアプリソースのグループのメンバーである。

  • リソースコレクションを通じてユーザーにエンタイトルメントが割り当てられた。

［Automatically remove group-based access（グループベースのアクセスを自動的に削除する）］を選択すると、アクセス認定はグループに割り当てられたアプリのユーザーアクセスを自動的に取り消すことができます。だだし、アプリがグループルールで割り当てられている場合や、グループがアプリソースのグループである場合には、ユーザーのアクセスを修復する必要があります。

［Enhanced group remediation（拡張されたグループ修復）］は、エンタイトルメントをレビューすることなく、アプリへのアクセスをレビューするリソースキャンペーンにのみ利用することができます。

手動修復に関する考慮事項

  • グループからユーザーを削除する前に、ユーザーがグループから取得する割り当てを確認してください。アプリ、管理者ロール、サインオンポリシー、その他の権限は、多くの場合、グループを通じて割り当てられます。ユーザーをグループから削除すると、そのユーザーがそのグループを通して取得したすべての割り当てが取り消されます。

  • ユーザーをアプリケーションに割り当てることができる複数のグループメンバーシップをユーザーが持っているかどうかを確認します。アクセスを削除するには、アプリケーションへのアクセスを付与するすべてのグループからそのユーザーを削除する必要があります。

  • アプリソースのグループを削除する前に、ソースアプリでそのグループがどのように使用されているかを確認してください。

次の推奨アクションを実行して、アクセスを修復します。

リソース

割り当て元

推奨アクション

アプリ

Oktaソースのグループメンバーシップ

Okta Workflowsを使用して、Oktaソースのグループからユーザーを削除します。

アプリ

アプリソースのグループメンバーシップ（Active Directory（AD）グループなど）

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

アプリ

リソースコレクション

リソースコレクションからユーザーまたはアプリを削除します。

Entitlements（エンタイトルメント）

リソースコレクション

リソースコレクションからエンタイトルメントを削除します。

［Okta-sourced group（Oktaソースのグループ）］

グループルール

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

［App-sourced group（アプリソースのグループ）］

インポート

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

関連項目

事前構成されたキャンペーンを作成する

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

ユーザーキャンペーンを作成する