Linux ベースシステムでのパッチベースラインルールの動作方法 - AWS Systems Manager
Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022、および Amazon Linux 2023 でのパッチベースラインルールの仕組みCentOS および CentOS Stream でのパッチベースラインルールの動作方法Debian Server および Raspberry Pi OS でのパッチベースラインルールの動作方法macOS でのパッチベースラインルールの仕組みOracle Linux でのパッチベースラインルールの仕組みAlmaLinux、RHEL、および Rocky Linux でのパッチベースラインルールの動作方法SUSE Linux Enterprise Server でのパッチベースラインルールの仕組みUbuntu Server でのパッチベースラインルールの仕組み

Linux ベースシステムでのパッチベースラインルールの動作方法

Linux ディストリビューションのパッチベースラインのルールは、ディストリビューションタイプ別に動作が異なります。Windows Server マネージドノードでのパッチ更新とは異なり、ルールはノードごとに評価され、インスタンスに設定されているリポジトリが考慮されます。AWS Systems Manager の機能である Patch Manager は、ネイティブのパッケージマネージャーを使用して、パッチベースラインで承認されているパッチをインストールします。

パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS (共通脆弱性評価システム) のような サードパーティのソースからの、または NVD (National Vulnerability Database) がリリースしたメトリクスからの重要度レベルは取得しません。

Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022、および Amazon Linux 2023 でのパッチベースラインルールの仕組み

Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022、および Amazon Linux 2023 のパッチの選択プロセスは、次のとおりです。

  1. マネージドノードで、YUM ライブラリ (Amazon Linux 1、Amazon Linux 2) または DNF ライブラリ (Amazon Linux 2022 および Amazon Linux 2023) が各設定済みリポジトリの updateinfo.xml ファイルにアクセスします。

    注記

    updateinfo.xml ファイルが見つからない場合、パッチがインストールされるかどうかは、[セキュリティ以外の更新を含める] および [自動承認] の設定に応じます。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。

  2. updateinfo.xml の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。

    更新通知の属性
    属性 説明
    type

    パッチベースラインの PatchFilter データ型の分類キー属性の値に対応します。更新通知に含まれているパッケージのタイプを表します。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [Create patch baseline (パッチベースラインの作成)] ページまたは [Edit patch baseline (パッチベースラインの編集)] ページの [Approval rules (承認ルール)] 領域でリストを表示することもできます。
    severity

    パッチベースラインの PatchFilter データ型の重要度キー属性の値に対応します。更新通知に含まれているパッケージの重要度を表します。通常、セキュリティ更新通知にのみ適用されます。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [パッチベースラインの作成] ページまたは [パッチベースラインの編集] ページの [承認ルール] 領域でリストを表示することもできます。
    update_id

    ALAS-2017-867 などのアドバイザリ ID を表します。アドバイザリ ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    references

    更新通知の詳細情報を示します。CVE ID (形式: CVE-2017-1234567) などが該当します。CVE ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    更新済み

    パッチベースラインの ApproveAfterDays に対応します。更新通知に含まれているパッケージのリリース日 (更新日) を表します。この属性 (および ApproveAfterDays) の値と現在のタイムスタンプとを比較することで、パッチのデプロイを承認するかどうかが決定されます。
    注記

    承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

  3. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの PatchFilter データ型のプロダクトキー属性の値に対応します。

  4. 更新用のパッケージは、次のガイドラインに従って選択されます。

    セキュリティオプション パッチの選択

    AWS が提供した事前定義済みのデフォルトパッチベースラインと、[セキュリティ以外の更新を含める] チェックボックスが選択されていないカスタムパッチベースライン

    updateinfo.xml の更新通知ごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に取り込まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。

    Amazon Linux 1 および Amazon Linux 2 の場合、このワークフローに対する同等の yum コマンドは次のとおりです。

    sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

    Amazon Linux 2022 および Amazon Linux 2023 の場合、このワークフローに対する dnf コマンドは次のとおりです。

    sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

    [セキュリティ以外の更新を含める] チェックボックスがオンで、重要度リストが [Critical, Important] 、分類リストが [Security, Bugfix] である、カスタムパッチベースライン

    Patch Manager は、updateinfo.xml から選択したセキュリティ更新を適用するだけでなく、パッチのフィルタリングルールに該当しないセキュリティに関連しない更新を適用します。

    Amazon Linux および Amazon Linux 2 の場合、このワークフローに対する yum コマンドは次のとおりです。

    sudo yum update-minimal --security --sec-severity=Critical,Important --bugfix -y

    Amazon Linux 2022 および Amazon Linux 2023 の場合、このワークフローに対する dnf コマンドは次のとおりです。

    sudo dnf upgrade-minimal --security --sec-severity=Critical --sec-severity=Important --bugfix -y

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。

CentOS および CentOS Stream でのパッチベースラインルールの動作方法

CentOS と CentOS Stream デフォルトリポジトリに updateinfo.xml ファイルは含まれていません。ただし、作成または使用するカスタムリポジトリにはこのファイルが含まれる場合があります。このトピックでは、updateinfo.xml への参照はこれらのカスタムリポジトリにのみ適用されます。

CentOS および CentOS Stream の場合、パッチの選択プロセスは次のとおりです。

  1. マネージドノードで、YUM ライブラリ (CentOS 6.x および 7.x バージョン) または DNF ライブラリ (CentOS 8.x および CentOS Stream) が各設定済みリポジトリの updateinfo.xml ファイル (カスタムリポジトリに存在する場合) にアクセスします。

    必ず含まれるデフォルトリポジトリでも updateinfo.xml ファイルが見つからない場合、パッチがインストールされるかどうかは、[セキュリティ以外の更新を含める] および [自動承認] の設定によって異なります。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。

  2. updateinfo.xml が存在する場合、ファイル内の各更新通知には、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。

    更新通知の属性
    属性 説明
    type

    パッチベースラインの PatchFilter データ型の分類キー属性の値に対応します。更新通知に含まれているパッケージのタイプを表します。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [Create patch baseline (パッチベースラインの作成)] ページまたは [Edit patch baseline (パッチベースラインの編集)] ページの [Approval rules (承認ルール)] 領域でリストを表示することもできます。
    severity

    パッチベースラインの PatchFilter データ型の重要度キー属性の値に対応します。更新通知に含まれているパッケージの重要度を表します。通常、セキュリティ更新通知にのみ適用されます。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [パッチベースラインの作成] ページまたは [パッチベースラインの編集] ページの [承認ルール] 領域でリストを表示することもできます。
    update_id

    CVE-2019-17055 などのアドバイザリ ID を表します。アドバイザリ ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    references

    更新通知の詳細情報を示します。CVE ID (形式: CVE-2019-17055) または Bugzilla ID (形式: 1463241) などが該当します。CVE ID と Bugzilla ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    更新済み

    パッチベースラインの ApproveAfterDays に対応します。更新通知に含まれているパッケージのリリース日 (更新日) を表します。この属性 (および ApproveAfterDays) の値と現在のタイムスタンプとを比較することで、パッチのデプロイを承認するかどうかが決定されます。
    注記

    承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

  3. どの場合でも、マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの PatchFilter データ型のプロダクトキー属性の値に対応します。

  4. 更新用のパッケージは、次のガイドラインに従って選択されます。

    セキュリティオプション パッチの選択

    AWS が提供した事前定義済みのデフォルトパッチベースラインと、[セキュリティ以外の更新を含める] チェックボックスが選択されていないカスタムパッチベースライン

    updateinfo.xml の更新通知ごとに、カスタムリポジトリに存在する場合は、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に取り込まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。

    updateinfo.xml が存在する CentOS 6 および 7 の場合、このワークフローに対応する yum コマンドは次のとおりです。

    sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

    updateinfo.xml が存在する CentOS 8 および CentOS Stream の場合、このワークフローに対応する dnf コマンドは次のとおりです。

    sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

    [セキュリティ以外の更新を含める] チェックボックスがオンで、重要度リストが [Critical, Important]、分類リストが [Security, Bugfix] である、カスタムパッチベースライン

    Patch Manager は、updateinfo.xml から選択したセキュリティ更新を適用するだけでなく、カスタムリポジトリに存在する場合、パッチのフィルタリングルールに該当しないセキュリティに関連しない更新を適用します。

    updateinfo.xml が存在する CentOS 6 および 7 の場合、このワークフローに対応する yum コマンドは次のとおりです。

    sudo yum update --sec-severity=Critical,Important --bugfix -y

    updateinfo.xml が存在する CentOS 8 および CentOS Stream の場合、このワークフローに対応する dnf コマンドは次のとおりです。

    sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y

    デフォルトのリポジトリと updateinfo.xml がないカスタムリポジトリでは、オペレーティングシステム (OS) パッケージを更新するために、[セキュリティ以外のアップデートを含める] チェックボックスを選択する必要があります。

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。

Debian Server および Raspberry Pi OS でのパッチベースラインルールの動作方法

Debian Server および Raspberry Pi OS (旧称 Raspbian) の場合、パッチベースラインサービスにより、[Priority] (優先度) フィールドと [Section] (セクション) フィールドでフィルタリングが行われます。通常、これらのフィールドはすべての Debian Server および Raspberry Pi OS パッケージに存在します。Patch Managerは、パッチベースラインでパッチが選択されているかどうかを確認するために以下の操作を行います。

  1. Debian Server および Raspberry Pi OS システムの場合、sudo apt-get update と同等のコマンドを実行して使用可能なパッケージのリストを更新します。リポは設定されず、データは sources リストに設定されているリポから取得されます。

  2. 更新が可能な場合、python3-apt (Python ライブラリインターフェイスの libapt) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[Include nonsecurity updates (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)

    重要

    Debian Server 8 の場合のみ: Debian Server 8.* オペレーティングシステムはサポートされなくなったパッケージリポジトリ (jessie-backports) を参照するため、Patch Managerはパッチ適用オペレーションが正常に完了するように以下の追加の手順を実行します。

    1. お客様のマネージドノードでは、jessie-backports リポジトリへのリファレンスはソース場所リスト (/etc/apt/sources.list.d/jessie-backports) からコメントアウトされています。その結果、その場所からのパッチのダウンロードは試みられません。

    2. Stretch のセキュリティの更新の署名キーがインポートされます。このキーによって、Debian Server 8.* ディストリビューションでの更新およびインストールオペレーションに必要なアクセス許可が付与されます。

    3. この時点で、apt-get オペレーションを実行し、パッチ適用プロセスの開始前に最新バージョンの python3-apt がインストールされていることを確認します。

    4. インストールプロセスが完了すると、jessie-backports リポジトリへの参照が復元され、署名キーが apt ソースキーリングから削除されます。これは、パッチ適用オペレーション前のシステム設定をそのまま残すために行われます。

  3. 次に、GlobalFilters、ApprovalRules、ApprovedPatches、および RejectedPatches リストが適用されます。

    注記

    Debian Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。この場合、Debian Server では、パッチ候補バージョンは、以下のリポに含まれているパッチに制限されます。

    これらのリポは、次のように名前が付けられます。

    • Debian Server 8: debian-security jessie

    • Debian Server および Raspberry Pi OS 9: debian-security stretch

    • Debian Server 10: debian-security buster

    • Debian Server 11: debian-security bullseye

    • Debian Server 12: debian-security bookworm

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

    注記

    承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

[Priority] フィールドと [Section] フィールドの内容を表示するには、次の aptitude コマンドを実行します。

注記

場合によっては、まず Debian Server システムに Aptitude をインストールする必要があります。

aptitude search -F '%p %P %s %t %V#' '~U'

このコマンドに対するレスポンスで、すべてのアップグレード可能なパッケージが次の形式で報告されます。

name, priority, section, archive, candidate version

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。

macOS でのパッチベースラインルールの仕組み

macOS の場合、パッチの選択プロセスは次のとおりです。

  1. マネージドノードで、Patch Manager は InstallHistory.plist ファイルの解析済みコンテンツにアクセスし、パッケージ名とバージョンを識別します。

    解析プロセスの詳細については、macOS の 「パッチのインストール方法」のタブを参照してください。

  2. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの PatchFilter データ型のプロダクトキー属性の値に対応します。

  3. 更新用のパッケージは、次のガイドラインに従って選択されます。

    セキュリティオプション パッチの選択

    AWS が提供した事前定義済みのデフォルトパッチベースラインと、[セキュリティ以外の更新を含める] チェックボックスが選択されていないカスタムパッチベースライン

    使用可能な更新通知ごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に取り込まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。

    [セキュリティ以外の更新を含める] チェックボックスが選択されているカスタムパッチベースライン

    パッチマネージャーは、InstallHistory.plist を使用して識別されたセキュリティ更新プログラムを適用するだけでなく、パッチフィルタールールに適合するセキュリティ以外の更新プログラムを適用します。

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。

Oracle Linux でのパッチベースラインルールの仕組み

Oracle Linux の場合、パッチの選択プロセスは次のとおりです。

  1. マネージドノードで、YUM ライブラリが各設定済みリポの updateinfo.xml ファイルにアクセスします。

    注記

    updateinfo.xml ファイルは、リポジトリが Oracle で管理されていないと使用できない場合があります。updateinfo.xml ファイルが見つからない場合、パッチがインストールされるかどうかは、[セキュリティ以外の更新を含める] および [自動承認] の設定に応じます。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。

  2. updateinfo.xml の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。

    更新通知の属性
    属性 説明
    type

    パッチベースラインの PatchFilter データ型の分類キー属性の値に対応します。更新通知に含まれているパッケージのタイプを表します。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [Create patch baseline (パッチベースラインの作成)] ページまたは [Edit patch baseline (パッチベースラインの編集)] ページの [Approval rules (承認ルール)] 領域でリストを表示することもできます。
    severity

    パッチベースラインの PatchFilter データ型の重要度キー属性の値に対応します。更新通知に含まれているパッケージの重要度を表します。通常、セキュリティ更新通知にのみ適用されます。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [パッチベースラインの作成] ページまたは [パッチベースラインの編集] ページの [承認ルール] 領域でリストを表示することもできます。
    update_id

    CVE-2019-17055 などのアドバイザリ ID を表します。アドバイザリ ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    references

    更新通知の詳細情報を示します。CVE ID (形式: CVE-2019-17055) または Bugzilla ID (形式: 1463241) などが該当します。CVE ID と Bugzilla ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    更新済み

    パッチベースラインの ApproveAfterDays に対応します。更新通知に含まれているパッケージのリリース日 (更新日) を表します。この属性 (および ApproveAfterDays) の値と現在のタイムスタンプとを比較することで、パッチのデプロイを承認するかどうかが決定されます。
    注記

    承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

  3. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの PatchFilter データ型のプロダクトキー属性の値に対応します。

  4. 更新用のパッケージは、次のガイドラインに従って選択されます。

    セキュリティオプション パッチの選択

    AWS が提供した事前定義済みのデフォルトパッチベースラインと、[セキュリティ以外の更新を含める] チェックボックスが選択されていないカスタムパッチベースライン

    updateinfo.xml の更新通知ごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に取り込まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。

    バージョン 7 マネージドノードの場合、このワークフローの同等の yum コマンドは次のとおりです。

    sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    バージョン 8 および 9 マネージドノードの場合、このワークフローの同等の dnf コマンドは次のとおりです。

    sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important

    [セキュリティ以外の更新を含める] チェックボックスがオンで、重要度リストが [Critical, Important]、分類リストが [Security, Bugfix] である、カスタムパッチベースライン

    Patch Manager は、updateinfo.xml から選択したセキュリティ更新を適用するだけでなく、パッチのフィルタリングルールに該当しないセキュリティに関連しない更新を適用します。

    バージョン 7 マネージドノードの場合、このワークフローの同等の yum コマンドは次のとおりです。

    sudo yum update --security --sec-severity=Critical,Important --bugfix -y

    バージョン 8 および 9 マネージドノードの場合、このワークフローの同等の dnf コマンドは次のとおりです。

    sudo dnf upgrade --security --sec-severity=Critical, --sec-severity=Important --bugfix y

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。

AlmaLinux、RHEL、および Rocky Linux でのパッチベースラインルールの動作方法

AlmaLinux、Red Hat Enterprise Linux (RHEL)、および Rocky Linux では、パッチの選択プロセスは次のとおりです。

  1. マネージドノードで、YUM ライブラリ (RHEL 7) または DNF ライブラリ (AlmaLinux 8 および 9、RHEL 8 および 9、Rocky Linux 8 および 9) が各設定済みリポジトリの updateinfo.xml ファイルにアクセスします。

    注記

    リポが Red Hat の管理対象外のものであると、updateinfo.xml ファイルは使用できない場合があります。updateinfo.xml が見つからない場合、パッチは適用されません。

  2. updateinfo.xml の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。

    更新通知の属性
    属性 説明
    type

    パッチベースラインの PatchFilter データ型の分類キー属性の値に対応します。更新通知に含まれているパッケージのタイプを表します。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [Create patch baseline (パッチベースラインの作成)] ページまたは [Edit patch baseline (パッチベースラインの編集)] ページの [Approval rules (承認ルール)] 領域でリストを表示することもできます。
    severity

    パッチベースラインの PatchFilter データ型の重要度キー属性の値に対応します。更新通知に含まれているパッケージの重要度を表します。通常、セキュリティ更新通知にのみ適用されます。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [パッチベースラインの作成] ページまたは [パッチベースラインの編集] ページの [承認ルール] 領域でリストを表示することもできます。
    update_id

    RHSA-2017:0864 などのアドバイザリ ID を表します。アドバイザリ ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    references

    更新通知の詳細情報を示します。CVE ID (形式: CVE-2017-1000371) または Bugzilla ID (形式: 1463241) などが該当します。CVE ID と Bugzilla ID は、パッチベースラインの ApprovedPatches 属性または RejectedPatches 属性で使用できます。
    更新済み

    パッチベースラインの ApproveAfterDays に対応します。更新通知に含まれているパッケージのリリース日 (更新日) を表します。この属性 (および ApproveAfterDays) の値と現在のタイムスタンプとを比較することで、パッチのデプロイを承認するかどうかが決定されます。
    注記

    承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

  3. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの PatchFilter データ型のプロダクトキー属性の値に対応します。

  4. 更新用のパッケージは、次のガイドラインに従って選択されます。

    セキュリティオプション パッチの選択

    AWS により事前定義されたデフォルトのパッチベースラインと [セキュリティ以外の更新を含める] チェックボックスがオフであるカスタムのパッチベースライン

    updateinfo.xml の更新通知ごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に取り込まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。

    RHEL 7 の場合、このワークフローに対する yum コマンドは次のとおりです。

    sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

    AlmaLinux 8 および 9、RHEL 8 および 9、および Rocky Linux 8 および 9 の場合、このワークフローに相当する dnf コマンドは次のとおりです。

    sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

    [セキュリティ以外の更新を含める] チェックボックスがオンで、重要度リストが [Critical, Important]、分類リストが [Security, Bugfix] である、カスタムパッチベースライン

    Patch Manager は、updateinfo.xml から選択したセキュリティ更新を適用するだけでなく、パッチのフィルタリングルールに該当しないセキュリティに関連しない更新を適用します。

    RHEL 7 の場合、このワークフローに対する yum コマンドは次のとおりです。

    sudo yum update --security --sec-severity=Critical,Important --bugfix -y

    AlmaLinux 8 および 9、RHEL 8 および 9、および Rocky Linux 8 および 9 の場合、このワークフローに相当する dnf コマンドは次のとおりです。

    sudo dnf upgrade --sec-severity=Critical --sec-severity=Important --bugfix -y

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。

SUSE Linux Enterprise Server でのパッチベースラインルールの仕組み

SLES では、各パッチには、パッチ内のパッケージのプロパティを示す以下の属性が含まれます。

  • Category: パッチベースラインの PatchFilter データ型の Classification キー属性の値に対応します。更新通知に含まれているパッチのタイプを表します。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [Create patch baseline (パッチベースラインの作成)] ページまたは [Edit patch baseline (パッチベースラインの編集)] ページの [Approval rules (承認ルール)] 領域でリストを表示することもできます。

  • Severity: パッチベースラインの PatchFilter データ型の Severity キー属性の値に対応します。パッチの重要度を示します。

    サポートされている値のリストは、AWS CLI コマンド describe-patch-properties または API オペレーション DescribePatchProperties を使用して表示できます。Systems Manager コンソールの [Create patch baseline (パッチベースラインの作成)] ページまたは [Edit patch baseline (パッチベースラインの編集)] ページの [Approval rules (承認ルール)] 領域でリストを表示することもできます。

マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの PatchFilter データ型の プロダクト キー属性の値に対応します。

パッチごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に含まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。

注記

承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

Ubuntu Server でのパッチベースラインルールの仕組み

Ubuntu Server では、パッチベースラインサービスは、Priority フィールドと Section フィールドでフィルタリングを行います。通常、これらのフィールドはすべての Ubuntu Server パッケージにあります。Patch Managerは、パッチベースラインでパッチが選択されているかどうかを確認するために以下の操作を行います。

  1. Ubuntu Server システムで、sudo apt-get update と同等のコマンドを実行して使用可能なパッケージのリストを更新します。リポは設定されず、データは sources リストに設定されているリポから取得されます。

  2. 更新が可能な場合、python3-apt (Python ライブラリインターフェイスの libapt) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[Include nonsecurity updates (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)

  3. 次に、GlobalFilters、ApprovalRules、ApprovedPatches、および RejectedPatches リストが適用されます。

    注記

    Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペティングシステムでは自動承認オプションがサポートされていません。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。この場合、Ubuntu Server では、パッチ候補バージョンは、以下のリポに含まれているパッチに制限されます。

    • Ubuntu Server 14.04 LTS: trusty-security

    • Ubuntu Server 16.04 LTS: xenial-security

    • Ubuntu Server 18.04 LTS: bionic-security

    • Ubuntu Server 20.04 LTS: focal-security

    • Ubuntu Server 20.10 STR: groovy-security

    • Ubuntu Server 22.04 LTS (jammy-security)

    • Ubuntu Server 23.04 (lunar-security)

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

    注記

    承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「承認されたパッチと拒否されたパッチのリストのパッケージ名の形式」を参照してください。

[Priority] フィールドと [Section] フィールドの内容を表示するには、次の aptitude コマンドを実行します。

注記

場合によっては、まず Ubuntu Server 16 システムに Aptitude をインストールする必要があります。

aptitude search -F '%p %P %s %t %V#' '~U'

このコマンドに対するレスポンスで、すべてのアップグレード可能なパッケージが次の形式で報告されます。

name, priority, section, archive, candidate version

パッチのコンプライアンスステータス値については、「パッチコンプライアンス状態の値」を参照してください。