---
sourceDocument: Xanadu のガバナンス、リスク、コンプライアンス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/governance-risk-compliance

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu のガバナンス、リスク、コンプライアンス

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# 脆弱性対応 とのポリシー例外統合

# 脆弱性対応 とのポリシー例外統合 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：5分

バージョン 10.1 以降、脆弱性対応 アプリケーションのバージョン 10.3 内から ポリシーとコンプライアンス管理 アプリケーションに固有の GRC ポリシー例外管理機能を使用してポリシー例外を要求できます。

## ポリシー例外統合を使用するメリット {#request-pe-from-vr__section_hpc_trh_rlb}

ポリシーとコンプライアンス管理 とのポリシー例外統合を使用して例外を要求すると、次のようなメリットが得られます。

* アセスメントを実行して、要求に関する追加情報を収集する。
* 特定のポリシーまたはコントロール目標に基づいて例外を要求する。このアクションは、例外が承認されたときのコンプライアンスへの影響を示します。
* ポリシー例外に関連付けられたリスク評価、ポリシー、またはコントロール目標に基づいて自動的にトリガーされるように承認を構成する。
{#request-pe-from-vr__ul_srf_tcv_plb}

## ポリシー例外統合の仕組み {#request-pe-from-vr__section_umc_1sh_rlb}

ここで説明するシナリオでは、システムで脆弱性が特定され、修正オーナーがソフトウェアパッチが必要であると判断したことを前提としています。パッチが完全にテストされておらず、オーナーがテストが完了するまでパッチの展開を遅らせるためポリシー例外を要求しています。  
次の図は、各アプリケーションでコンプライアンスマネージャーと修正オーナーが実行する手順を示しています。図 : 1. ポリシー例外統合  
注:  
GRC ビジネスユーザー (sn_grc.business_user) またはビジネスユーザー -- Lite (sn_grc.business_user_lite) は、アップストリームアプリケーションからポリシー例外を生成するために最低限必要なロールです。

1. 脆弱性対応 アプリケーションがインストールされると、脆弱性グループ用と脆弱性一致アイテム用の 2 つのポリシー例外統合レコードが自動的に作成され、統合レジストリに追加されます。図 : 2. ポリシー例外統合レジストリ  
   脆弱性一致アイテムレコードを設定するために、コンプライアンスマネージャーは次の手順を実行します。
   1. [2 つのアプリケーションを統合するために使用するテーブルのマッピングを指定します](https://servicenow-prod.fluidtopics.net/KBoqGSSKJeYvG0bKBCuQEQ "バージョン 10.1 以降、その他のアプリケーション内から ポリシーとコンプライアンス管理 で新しいポリシー例外機能を利用できます。")。
   2. [例外を要求する理由を定義します](https://servicenow-prod.fluidtopics.net/KoHlNQrXuc6WaDKXMmVbag "例外を要求するすべてのユーザーが使用可能な理由の選択肢を定義できます。")。
   3. (オプション) ポリシーをフィルタリングするための[ポリシーカテゴリを定義](https://servicenow-prod.fluidtopics.net/eOmMFAkoWS4GT4iM8Nv0GQ "特定の基準でポリシーをフィルタリングして、ポリシーの例外を作成するときに表示されるポリシーの数を制限できます。")します。
   4. (オプション) ポリシー例外要求に関する追加情報を収集するために、要求者に送信する [1 つ以上のアンケートを作成](https://servicenow-prod.fluidtopics.net/RvcmvDpTC9uDIr8OfCxXBw "ポリシー例外統合レジストリを設定するときに、テンプレートから作成されたリスクアセスメントに含めることができる構成可能な質問を定義できます。ポリシー例外統合レジストリは、一度に 1 つのテンプレートに関連付けることができます。")します。
   {#request-pe-from-vr__ol_esl_rmy_xlb}
2. また、コンプライアンスマネージャーは、オプションの[検証ルール](https://servicenow-prod.fluidtopics.net/cHTpAJvPgfwLqrQHtlxhrA "検証ルールは、承認のために送信する前にポリシー例外要求の正確性と完全性を検証するために使用されます。アプリケーションに対して複数のレベルの承認者を定義できます。")と[承認ルール](https://servicenow-prod.fluidtopics.net/Xy5ubxDpjWUuKHEMOKvC~w "承認ルールは、例外の承認要求を送信するために使用される基準 (リスク評価、ポリシー、またはコントロール目標) を定義します。ルールはアプリケーションに対して設定でき、必要に応じて複数のレベルの承認者を指定できます。")を定義して、ポリシー例外の承認を取得するプロセスを自動化します。
3. 脆弱性対応では、修復オーナーは [を使用した例外の要求 GRC：ポリシーとコンプライアンス管理](https://www.servicenow.com/docs/access?context=integration-with-grc&version=xanadu&pubname=xanadu-security-management&ft:locale=en-US) .
4. アプリケーションに対して検証ルールが定義されている場合、指定された承認者に承認が必要であることが通知されます。ポリシー例外要求のいずれかのフィールドが要求者によって入力されなかった場合 (ポリシーやコントロール目標など)、それらのフィールドは承認者にとって必須になります。承認者が要求をレビュー、完了、および承認すると、\[分析\] ステータスに移行し、さらに分析および承認するためにコンプライアンスマネージャーにアサインされます。
5. ポリシーとコンプライアンス管理 で、コンプライアンスマネージャーは承認された要求を受け取り、\[リスクアセスメント\] タブでリスク評価をポリシー例外要求に割り当てます。図 : 3. \[リスクアセスメント\] タブでのポリシー例外要求

   ポリシー例外レコードが保存されると、ソースアプリケーションとソースレコードを含む \[ソース\] タブの情報と、\[脆弱性一致アイテム\] 関連リストの情報が自動的に入力されます。これで、コンプライアンスマネージャーは、ポリシーの例外をレビューして承認するために必要なすべてのデータにアクセスできますできるようになりました。
6. ポリシーとコンプライアンス管理 では、[アセスメントが設定されている場合](https://servicenow-prod.fluidtopics.net/RvcmvDpTC9uDIr8OfCxXBw "ポリシー例外統合レジストリを設定するときに、テンプレートから作成されたリスクアセスメントに含めることができる構成可能な質問を定義できます。ポリシー例外統合レジストリは、一度に 1 つのテンプレートに関連付けることができます。")、コンプライアンスマネージャーが例外アセスメントを実行します。　アセスメントが完了すると、コンプライアンスマネージャーは \[リスクアセスメント\] タブに戻り、必要に応じてアセスメントの結果に基づいて \[リスク評価\] を更新します。また、コンプライアンスマネージャーは、アセスメント中に収集された情報を次のフィールドに入力します。{#request-pe-from-vr__table_zmt_1cn_rlb__entry__2}

   | フィールド | 説明 |
   |-|-|
   | リスク詳細 | このポリシー例外に関連付けられたリスクについての詳細を提供します。 |
   | リスクと影響度の分析 | ポリシー例外に対するリスクと影響度の分析についての詳細を提供します。 |
   | リスク軽減計画 | このポリシー例外に関連付けられた緩和計画についての詳細を提供します。 |
   [表 : 1. \[リスクアセスメント\] タブ]

   {#request-pe-from-vr__table_zmt_1cn_rlb}
7. ポリシー例外に情報が欠落している場合、コンプライアンスマネージャーは \[追加情報をリクエスト\] をクリックし、必要なデータのタイプを特定するコメントを追加できます。要求者は通知を受け取り、要求された情報を提供します。
8. 必要に応じて、コンプライアンスマネージャーは、\[レビューを要求\] をクリックして、承認前に追加の社内レビューのためにポリシー例外を送信できます。  
   注:  
   レビューを要求する前に、\[影響を受けるコントロール\] 関連リストにポリシー例外の影響を受けるコントロールが含まれていることを確認してください。関連リストを開き、\[追加\] をクリックしてコントロールを選択します。
9. ポリシー例外のリスクが特に高く、コンプライアンスマネージャーが組織内の上位のユーザー (CIO など) からの承認が必要であると考える場合、コンプライアンスマネージャーは \[承認を要求\] をクリックできます。  
   それ以外の場合は、次のシナリオで承認が実行されます。{#request-pe-from-vr__table_hdc_l3n_rlb__entry__2}

   | 承認ルールの定義 | 承認への影響 |
   |-|-|
   | 脆弱性対応 の承認ルールが定義されていない場合 | \[承認\] ボタンをクリックすると、ポリシーの例外が承認されます。 |
   | [承認ルールが定義されていても](https://servicenow-prod.fluidtopics.net/Xy5ubxDpjWUuKHEMOKvC~w "承認ルールは、例外の承認要求を送信するために使用される基準 (リスク評価、ポリシー、またはコントロール目標) を定義します。ルールはアプリケーションに対して設定でき、必要に応じて複数のレベルの承認者を指定できます。")、\[自動トリガー\] チェックボックスが選択されていなかった場合 | \[承認を要求\] をクリックすると、ルールで定義されているユーザーまたはグループにポリシーの例外を送信できます。たとえば、承認ルールは、ポリシー例外が特定のポリシーに基づいている場合、特定のユーザーまたはグループに対して、そのポリシー例外の承認を提供する必要があることを示すことができます。または、リスク評価が「重大」のポリシー例外が特定の承認者に送信されるように、承認ルールを定義することもできます。 ポリシーの例外を承認するために必要な承認者の数は、ルールの \[承認が必要\] フィールドの設定によって異なります。 \[承認\] をクリックして、自分でポリシーの例外を承認することもできます。 |
   | 承認ルールが定義されていて、\[自動トリガー\] チェックボックスが選択されていなかった場合 | \[承認\] ボタンをクリックすると、承認ルールが実行され、そのルールによって定義されたユーザーまたはグループにポリシー例外が自動的に送信されます。自動トリガーにより、このステップが必須になります。承認を受け取ると、ポリシー例外が有効になります。 |
   [ ]

   {#request-pe-from-vr__table_hdc_l3n_rlb}
10. 脆弱性対応 では、承認が受領された後、ポリシー例外がアクティブになり、脆弱性一致アイテムのパッチ適用アクティビティはポリシー例外が期限切れになるまで保留されます。\[有効期限\] の日付に達すると、ポリシーの例外が期限切れになり、脆弱性一致アイテムの状況が \[保留\] から \[オープン\] に変わります。
{#request-pe-from-vr__ol_bj3_3sh_rlb}