修復を理解する

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

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

レビューが1レベルのみのキャンペーンでは、修復プロセスは、レビュアーがユーザーのアクセスを承認または取り消した直後に開始されます。

マルチレベルレビューが設定されているキャンペーンでは、第2レベルのレビュアーにレビューが送信されるのは、第1レベルのレビュアーがレビューを承認または取り消した後のみとなります。第1レベルのレビュアーが応答せずにキャンペーンが終了すると、レビュアーの応答しない（Doesn’t respond）（Doesn't respond）の修復構成が適用されます。

これらのアイテムの最終レビュアーと以後の修復は、第2レベルのレビュアーに送られる第1レベルのレビュアーの決定によって決まります。

承認された決定のみ（Only approved decisions）：承認されたレビューの最終レビュアーは、第2レベルのレビュアーとなります。これらのレビュアーが応答せずにキャンペーンが終了すると、レビュアーの応答しない（Doesn’t respond）（Doesn't respond）の修復構成が適用されます。

たとえば、承認された決定のみ（Only approved decisions）が第2レベルのレビュアーに送られるように選択します。この場合、第2レベルのレビュアーが、承認されたすべてのレビューアイテムの最終レビュアーとなりますが、取り消されたアイテムの最終レビュアーとはなりません。修復構成は、第2レベルのレビュアーが下した決定に適用されます。

ただし、第1レベルのレビュアーが取り消したレビューアイテムの最終レビュアーは、第1レベルのレビュアーです。これらのレビューには、アクセス権を取り消す（Revoke access）の修復構成が適用されます。

承認された決定と取り消された決定の両方（Both approved and revoked decisions）：承認されたすべてのレビューと取り消されたすべてのレビューの最終レビュアーは、第2レベルのレビュアーとなります。第2レベルのレビュアーが応答せずにキャンペーンが終了すると、レビュアーの応答しない（Doesn’t respond）（Doesn't respond）の修復構成が適用されます。

たとえば、承認された決定と取り消された決定の両方（Both approved and revoked decisions）が第2レベルのレビュアーに送られるように選択します。この場合、第2レベルのレビュアーが、これらのレビューアイテムの最終レビュアーとなります。修復構成は、第2レベルのレビュアーが下した決定に適用されます。これらのレビュアーが応答しない場合、レビュアーの応答しない（Doesn’t respond）（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）を選択すると、アクセス認定はグループに割り当てられたアプリのユーザーアクセスを自動的に取り消すことができます。だだし、アプリがグループルールで割り当てられている場合や、グループがアプリソースのグループである場合には、ユーザーのアクセスを修復する必要があります。

Okta Privileged Accessをサブスクライブしており、サービスアカウントをキャンペーンのリソーススコープとして含める場合、サービスアカウントへのアクセスを手動で修復する必要があります。

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

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

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

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

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

リソース

割り当て元

推奨アクション

アプリ

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

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

アプリ

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

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

アプリ

これは、リソース（Resources）（Apps）ページでリソースタイプとしてアプリ（Apps）（Resources）を選択したキャンペーンにのみ適用されます。

リソースコレクション

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

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

これは、リソース（Resources）ページでリソースタイプとしてアプリ（Apps）を選択し、エンタイトルメントをレビューする（Review entitlements）をオンにしたキャンペーンにのみ適用されます。

以下のいずれかの方法、またはいずれかの方法の組み合わせ：

  • エンタイトルメントバンドル

  • リソースコレクション

  • エンタイトルメントポリシー

エンタイトルメントバンドル、リソースコレクションからエンタイトルメントを削除するか、ユーザーをエンタイトルメントポリシーから除外します。

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

グループルール

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

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

インポート

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

（Okta Privileged Accessで管理されている）アプリに関するサービスアカウント

グループまたはセキュリティポリシー

グループ、プロジェクト、またはセキュリティポリシーからユーザーを削除する

関連項目

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

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

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