脆弱性サービスは、Insights クライアントを使用して RHEL システムに関する情報を収集します。クライアントはシステムに関する情報を収集し、脆弱性サービスにアップロードします。

次に Vulnerability サービスは、Red Hat の CVE データベースとセキュリティーボットに対してデータを評価し、システムに影響を与える可能性のある未処理の CVE があるかを判断し、これらの比較の結果を提供します。

データを分析したら、表示される結果を表示して並べ替えたり、脆弱性のリスクと優先順位の評価、ステータスの報告、Ansible Playbook の作成およびデプロイ、修復ができます。脆弱性サービスの目的は、RHEL インフラストラクチャーのセキュリティーの脆弱性から保護する反復可能なプロセスを有効にすることです。

Vulnerability administrator ロールは、Default access グループ のデフォルトロールです。アカウント上の Red Hat Insights for Red Hat Enterprise Linux の全ユーザーは、デフォルトで Default アクセスグループ のメンバーです。デフォルト設定では、Vulnerability 管理者 ロールを持つグループのメンバーは、すべての Vulnerability サービスリソースにアクセスできます。

組織は、デフォルトロールの制限が多すぎるか、または許容度を超えるかを決定する場合があります。一部の機能へのアクセスを制限したり、User Access 管理者 はロールをカスタマイズし、必要なアクセス許可を使用してロールを設定できます。事前設定されたロールをカスタマイズすると、Default アクセスグループ が置き換えられます。

デフォルト設定では、Vulnerability ビューアー ロールは Vulnerability サービスリソースを読み取ることができます。これは事前設定されたロールですが、Default アクセスグループ には含まれません。Vulnerability ビューアー ロールには以下のパーミッションが含まれます。

組織が Vulnerability ビューアーのロールのデフォルト設定が不十分であると判断した場合、User Access 管理者は、必要な特定のアクセス許可を使用してカスタムロールを作成できます。

Red Hat セキュリティーアドバイザリー (RHSA) のエラータでは、修正または軽減策が利用可能な Red Hat 製品のセキュリティー脆弱性が文書にまとめられています。Red Hat Insights for Red Hat Enterprise Linux の Vulnerability サービスは、CVE のリスクに晒されている各システムに紐付けられているアドバイザリー ID を表示します。

CVE を選び、セキュリティールールカードの Filter by affected systems のリンクを選択してこの情報を表示します。システムにアドバイザリーが存在する場合には、RHSA ID が Exposed systems リストの Advisory コラムで、システムの横にリンクとして表示されます。アドバイザリーがない場合は、Advisory 列が表示されなかったり、「Not available」と表示されます。

システムにアドバイザリーが存在する場合は、影響を受けるシステムの一覧など、RHSA に関する詳細情報を表示できます。Patch サービスでは、システムを選択し、Ansible Playbook を作成して修復を適用できます。

セキュリティールールは、リスクの割合が高いことや、CVE に関連するセキュリティーリスクが理由で、CVE が強調されています。これらは、重大なメディア報道を受ける可能性のあるセキュリティー上の欠陥であり、Red Hat Product Security チームによって精査され、Product Security Incident Response Plan ワークフローを使用して RHEL 環境の露出を判断するのに役立ちます。これらのセキュリティールールにより、組織を保護するための適切なアクションを実行できます。

セキュリティールールは、システムで実行している RHEL のバージョンを分析するだけにとどまらず、詳細にわたる脅威インテリジェンスを提供します。また、セキュリティールールは、Insights クライアントが収集するシステムメタデータを分析して、手動でキュレートされ、セキュリティーの脅威にさらされるかどうかを判断します。Vulnerability サービスにより、セキュリティールールのリスクに晒されるシステムが特定された場合には、セキュリティーリスクが高まる可能性があり、早急に問題を対処する必要があります。

最後に、CVE に晒されているシステムすべてが、その CVE に関連するセキュリティールールのリスクに晒されているわけではありません。脆弱なバージョンのソフトウェアを実行している場合でも、他の環境条件により、特定のポートが閉じられたり、SELinux を実行している場合など、その他の環境状態により脅威が緩和される可能性があります。

Red Hat は Metasploit データを分析して、CVE を悪用するコードが公開されているか、また CVE が一般的に悪用されていないかを判断します。Vulnerability サービスは、対象基準を満たす CVE に「既知の不正使用」ラベルを適用します。

脅威評価がこのように強化されることで、極めてリスクの高い CVE を特定して先に対処できるようになります。Red Hat は、「既知の不正使用」ラベルの CVE を最優先ですべて確認し、これらの問題の修正に向けて取り組むことを推奨します。

脆弱性サービスは、個々の Common Vulnerabilities and Exposures (CVE) と、Insights に登録されたシステムへの影響に関するデータを提供します。CVE は、脆弱 または 影響を受けるが脆弱ではないものとして分類されます。このレベルの脅威インテリジェンスは、Security Rule ラベルを持つ CVE、または Red Hat Product Security の厳密な分析を経た CVE で利用できます。

この強化された脅威インテリジェンスにより、問題をトリアージし、最も緊急性の高い問題に最初に対処することができます。大規模なサーバー群を管理する場合、これは迅速な保護と大幅な効率化につながります。

影響を受けているが脆弱ではない CVE ステータスは、脆弱性があるが現在悪用できないソフトウェアを実行していることを示します。このシステムには修復が必要ですが、すぐに対処する必要はありません。

脆弱な CVE ステータスは、コードに欠陥があり、悪用へのパスが開いていることを示します。オープンパスは、次のいずれかを許可するポートまたは OS バージョンである可能性があります: 機密情報の漏えい、システムの整合性の侵害、またはシステムの可用性の妨害。

脆弱な サーバーと、影響を受けるが脆弱ではない サーバーの例を見てみましょう。

サーバー A が、システムへの root アクセスを許可する脆弱なソフトウェアを実行しているとします。サーバー A は脆弱であると見なされ、すぐにパッチを適用する必要があります。

対照的に、サーバー B の現在の設定では、影響を受けるコードに脆弱性が存在する場合でも、脆弱性が顕在化しないとします。サーバー B は 影響を受けると見なされますが、脆弱ではありません。これは、サーバー B が to-do リストに追いやられ、より差し迫った脅威である サーバー A を修復できることを意味します。

重要: サーバー A は潜在的に脆弱なコードを実行しているため、サーバー A に対処したら、サーバー B にパッチを適用する必要があります。バージョンの更新やその他のイベントにより、将来脆弱になる可能性があります。

フィルタリングにより、CVE および関連システムの表示一覧が絞り込まれるため、特定の問題にフォーカスしやすくなります。CVE 一覧にフィルターを適用して、重大度やビジネスリスクに応じて CVE にフォーカスします。以下に例を示します。個々の CVE を選択した後、影響を受けるシステムの結果リストにフィルターを適用して、たとえば、特定の RHEL メジャーバージョンまたはマイナーバージョンのシステムに焦点を合わせます。

フィルターは、左側のフィルターのドロップダウンリストからプライマリーフィルターを選択し、右側のフィルターオプションのドロップダウンリストからセカンダリーサブフィルターを選択してアクティベートされます。選択したフィルターはフィルターメニューに表示され、各フィルターの横にある X をクリックしてフィルタリングを解除できます。

以下の主要フィルターは、CVEs ページからアクセスできます。プライマリーフィルターを選択し、サブフィルターにパラメーターを定義します。

CVE の詳細ページのシステム一覧から、以下のプライマリーフィルターにアクセスできます。

セキュリティールール (特に重大度の高いセキュリティールールなど) は、お使いのインフラストラクチャーに非常に大きな脅威となる可能性があり、リスクの特定および修復の優先順位を 1 番として考える必要があります。以下の手順に従い、CVE リストで重大度の高いセキュリティールール CVE だけを表示して影響を受けるシステムを特定します。

「既知の不正使用」のラベルが付いた CVE で、Red Hat は、CVE を悪用するコードが公開されているか、不正使用が行われたと一般的に知られているかなど、不正使用が行われているかどうかを判断します。このような理由から、不正使用されていることが分かっている CVE は、優先的に特定と修復を図る必要があります。

以下の手順に従って、CVE 一覧から不正使用されていることが分かっている CVE をフィルタリングします。

CVE 一覧をフィルタリングし、最も重大な脅威だけを表示した後に、個別の CVE を選択して、セキュリティーリスクに晒されたシステム一覧を表示して、その一覧にフィルターを適用します。

システムやワークロードのグループ別に Vulnerability サービスの結果をフィルタリングする機能を使用すると、特定のグループに所属するとのタグが付いたシステムだけを表示できます。これらは、Satellite ホストグループ、または Insights クライアント設定ファイルに追加されたカスタムタにより SAP ワークロード (または SAP ID) を実行しているシステムが考えられます。

グループフィルタリングは、Insights for Red Hat Enterprise Linux アプリケーション全体のページ上部にある フィルター結果 ボックスを使用して、Insights for Red Hat Enterprise Linux でグローバルに設定できます。サービスやページが変わっても、グループの選択項目は維持されます。ただし、機能は、さまざまな Insights for Red Hat Enterprise Linux サービス内で異なります。

グループのフィルタリングは、Vulnerability ダッシュボードと Vulnerability サービスの CVE およびシステムリストで機能します。

本書の タグおよびシステムグループ のセクションでは、グループタグや、カスタムタグの設定について説明します。

Vulnerability サービスでは、CVE のビジネスリスクを、High、Medium、Low、または Not Defined (デフォルト) などのオプションで定義できます。

CVE の一覧では各 CVE の重大度を示していますが、ビジネスリスクを割り当てることで、組織に与える可能性のある影響に基づいて CVE をランク付けできます。これにより、大規模な環境でリスクを効率的に管理し、運用上の意思決定を改善できます。

デフォルトでは、特定の CVE のビジネスリスクフィールドは Not Defined に設定されます。ビジネスリスクを設定したら、CVE 行の横にある Red Hat Enterprise Linux > Vulnerability > CVEs 一覧に表示されます。

また、各 CVE の詳細カードにビジネスリスクが表示されます。これには、より多くの情報が表示され、影響を受けるシステムが一覧表示されます。

Vulnerability サービスを使用すると、特定のシステムを脆弱性分析から除外することができます。除外することで、組織の目標と関連せのないシステムで問題を確認、再確認する時間と労力を軽減できます。

たとえば、QA、Dev、および Production というサーバーのカテゴリーがあり、QA サーバーの脆弱性を確認する必要がない場合は、Vulnerability サービスの分析対象からこれらのシステムを除外できます。

脆弱性分析からシステムを除外すると、Insights クライアントはシステム上のスケジュールに従ってそのまま実行されますが、システムの結果は Vulnerability サービスには表示されません。クライアントがそのまま稼働されるので、他の Red Hat Insights for Red Hat Enterprise Linux サービスで必要なデータをアップロードできます。また、フィルターを使用してこれらのシステムの結果を確認することもできます。

選択した RHEL システムをVulnerability サービスの分析から除外するには、以下の手順を実行します。

以前に除外したシステムを表示するには、以下の手順を実行します。

システムの脆弱性分析を再開するには、以下の手順を実行します。

システムに影響を与える CVE を管理する方法として他に、CVE のステータスを設定することが挙げられます。Vulnerability サービスを使用すると、以下の方法で CVE のステータスを設定できます。

ステータス値は事前設定されており、以下のオプションが含まれます。

CVE のステータスを設定すると、ライフサイクルによる順序づけが、順序の認識から変更までにわたり容易になります。ステータスを定義すると、組織は、ライフサイクル内のどの部分で重大度の最も高い CVE が存在するのか、またビジネスのニーズに合わせて最も重要な問題への対処に焦点を合わせる必要がある状況について、より効果的に監視できます。CVE のステータスは、Vulnerability サービスおよび個別の CVE ビューの全 CVE テーブルに表示されます。

Vulnerability サービスの検索機能は、表示中のページのコンテキストで機能します。

Vulnerability サービスのソート機能は、表示ページのコンテキストにより異なります。

コンプライアンスサービスを使用すると、ユーザーは、コンプライアンスデータを報告するシステムにタグおよびグループフィルターを適用できます。ただし、Filter by status ドロップダウンを使用して設定することはできません。Insights for Red Hat Enterprise Linux アプリケーションの他のほとんどのサービスとは異なり、コンプライアンスサービスは、次の条件下でのシステムのデータのみを表示します。

これらの条件のため、コンプライアンスサービスのユーザーは、コンプライアンスサービス UI のシステムのリストの上にあるプライマリーフィルターとセカンダリフィルターを使用して、タグフィルターとグループフィルターを設定する必要があります。

2025 年に Linux は SAP ERP ワークロードの必須オペレーティングシステムになるため、Red Hat Enterprise Linux および Red Hat Insights for Red Hat Enterprise Linux では、Insights for RHEL が SAP 管理者に選ばれる管理ツールとなるように取り組んでいます。

この継続的な取り組みの一環として、Insights for Red Hat Enterprise Linux は、管理者によるカスタマイズを必要とせずに、SAP ワークロードを実行しているシステムに SAP ID (SID) によって自動的にタグを付けます。ユーザーは、グローバル Filter by tags ドロップダウンメニューを使用して、Insights for Red Hat Enterprise Linux アプリケーション全体でこれらのワークロードを簡単にフィルター処理できます。

Satellite ホストグループは Satellite で設定され、Insights for Red Hat Enterprise Linux で自動的に認識されます。

タグによるグローバルフィルター 機能を使用して、Red Hat Insights for Red Hat Enterprise Linux ユーザーは、Microsoft SQL Server ワークロードを実行しているシステムのグループを選択できます。

2019 年 5 月、Red Hat Insights チームは、Red Hat Enterprise Linux (RHEL) で実行されている Microsoft SQL Server 向けの RHEL 推奨事項の新しい一連の Insights を導入しました。これらのルールは、オペレーティングシステムレベルの設定が Microsoft および Red Hat から文書化された推奨事項に準拠していないことを管理者に警告します。

これらのルールの制限は、データベース自体ではなく、主にオペレーティングシステムを分析することでした。Insights for Red Hat Enterprise Linux および RHEL 8.5 の最新リリースでは、Microsoft SQL Assessment API が導入されています。SQL Assessment API は、MS SQL Server のデータベース設定のベストプラクティスを評価するメカニズムを提供します。API には、Microsoft SQL Server チームが提案するベストプラクティスルールを含むルールセットが付属しています。このルールセットは新しいバージョンのリリースで拡張されていますが、API は高度にカスタマイズ可能で拡張可能なソリューションを提供することを目的として構築されており、ユーザーはデフォルトのルールを調整して独自のルールを作成できます。

SQL Assessment API は PowerShell for Linux (Microsoft から入手可能) でサポートされており、Microsoft は、API を呼び出してその結果を JSON 形式のファイルとして保存するために使用できる PowerShell スクリプトを開発しました。RHEL 8.5 では、Insights クライアントがこの JSON ファイルをアップロードし、結果を Insights for Red Hat Enterprise Linux UI にわかりやすい形式で表示するようになりました。

Insights for Red Hat Enterprise Linux での SQL Server 評価の詳細については、Red Hat Insights で利用できるようになった SQL Server データベースのベストプラクティス を参照してください。

システムにカスタムグルーピングとタグ付けを適用して、個別のシステムにコンテキストマーカーを追加したり、Insights for Red Hat Enterprise Linux アプリケーションでこれらのタグ別にフィルタリングしたり、より簡単に関連システムに焦点を当てたりすることができます。この機能は、何百または何千ものシステムが管理されている環境で、Red Hat Enterprise Linux の Insights を大規模にデプロイメントする場合に特に価値があります。

複数の Insights for Red Hat Enterprise Linux サービスにカスタムタグを追加する機能に加えて、定義済みタグを追加できます。advisor サービスは、これらのタグを使用して、より高いレベルのセキュリティーを必要とするシステムなど、より注意が必要なシステムに的を絞った推奨事項を作成できます。

# tags
---
group: eastern-sap
name: Jane Example
contact: jexample@corporate.com
Zone: eastern time zone
Location:
- gray_rack
- basement
Application: SAP

5.5.5. 定義済みタグの設定

Red Hat Insights for Red Hat Enterprise Linux advisor サービスの定義済みタグを使用すると、システムの推奨事項の動作を調整し、拡張されたセキュリティー強化と強化された検出および修復機能を得ることができます。以下の手順に従って、事前定義されたタグを設定できます。

前提条件

• システムへの root レベルのアクセスがある。
• Insights クライアントがインストールされている。
• Insights クライアント内にシステムが登録されている。
• すでに tags.yaml ファイルを作成している。tags.yaml ファイルの作成とカスタムグループの追加 を参照してください。

手順

1. コマンドラインと任意のエディターを使用して、/etc/insights-client/tags.yaml を開きます。(次の例では Vim を使用しています。)

   [root@server ~]# vi /etc/insights-client/tags.yaml

2. /etc/insights-client/tags.yaml ファイルを編集して、タグの定義済みの key=value ペアを追加します。この例は、security: strict および network_performance: latency タグを追加する方法を示しています。

   # cat /etc/insights-client/tags.yaml
   group: redhat
   location: Brisbane/Australia
   description:
   - RHEL8
   - SAP
   security: strict
   network_performance: latency

3. 変更を保存します。
4. エディターを終了します。

5. オプション: Insights-client コマンドを実行して、Red Hat Insights for Red Hat Enterprise Linux へのアップロードを生成するか、次のスケジュールされた Red Hat Insights アップロードまで待ちます。

   [root@server ~]# insights-client

定義済みタグが実稼働環境にあることの確認

Red Hat Insights へのアップロードを生成した後 (またはスケジュールされた次の Insights アップロードを待っている間)、Red Hat Enterprise Linux > Inventory にアクセスして、タグが実稼働環境にあるかどうかを確認できます。システムを見つけて、新たに作成されたタグを探します。次のことを示す表が表示されます。

• 名前
• 値
• タグソース (例: insights-client)。

次のイメージは、タグを作成した後にインベントリーに表示される内容の例を示しています。

定義済みタグを適用した後の推奨事項の例

次の図では、advisor サービスは network_performance: latency タグが設定されたシステムを示しています。

システムは、総リスク (重要に分類) が高い推奨事項を表示します。network_performance: latency タグのないシステムの場合、総リスクは中程度に分類されます。総リスクの高さに基づいて、システムの優先順位付けに関する決定を行うことができます。

Vulnerability サービスの詳細は、以下の資料を参照してください。