修復を理解する
修復設定では、レビュアーがユーザーのリソースへのアクセスを承認または取り消した場合の処理、またはレビューを完了しなかった場合の処理を決定できます。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（グループベースのアクセスを自動的に削除する）］を選択すると、アクセス認定はグループに割り当てられたアプリのアクセスを自動的に取り消すことができます。だだし、アプリがグループルールで割り当てられている場合や、グループがアプリソースのグループである場合には、ユーザーのアクセスを修復する必要があります。
拡張されたグループ修復は早期アクセスの機能です。エンタイトルメントをレビューすることなく、アプリへのアクセスをレビューするリソースキャンペーンにのみ使用できます。「セルフサービス機能を有効にする」を参照してください。
手動修復に関する考慮事項
-
グループからユーザーを削除する前に、ユーザーがグループから取得する割り当てを確認してください。アプリ、管理者ロール、サインオンポリシー、その他の権限は、多くの場合、グループを通じて割り当てられます。ユーザーをグループから削除すると、そのユーザーがそのグループを通して取得したすべての割り当てが取り消されます。
-
ユーザーをアプリケーションに割り当てることができる複数のグループメンバーシップをユーザーが持っているかどうかを確認します。アクセスを削除するには、アプリケーションへのアクセスを付与するすべてのグループからそのユーザーを削除する必要があります。
-
アプリソースのグループを削除する前に、ソースアプリでそのグループがどのように使用されているかを確認してください。
次の推奨アクションを実行して、アクセスを修復します。
|
リソース |
割り当て元 |
推奨アクション |
|---|---|---|
|
［Application（アプリケーション）］ |
Oktaソースのグループメンバーシップ |
Okta Workflowsを使用して、Oktaソースのグループからユーザーを削除します。 |
|
［Application（アプリケーション）］ |
アプリソースのグループメンバーシップ（Active Directory（AD）グループなど） |
アプリソースのグループからユーザーを削除します。 |
|
［Okta-sourced group（Oktaソースのグループ）］ |
グループルール |
グループからユーザーを削除し、ユーザーをグループルールの例外として追加します。 |
|
［App-sourced group（アプリソースのグループ）］ |
インポート |
アプリソースのグループからユーザーを削除します。 |