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

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

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

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

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

注記

Amazon Linux 2023 (AL2023) は、1 つ以上のシステム設定を通じて特定のバージョンにロックできるバージョン管理されたリポジトリを使用します。AL2023 EC2 インスタンスに対するすべてのパッチ適用オペレーションについて、Patch Manager はシステム設定に関係なく、最新のリポジトリバージョンを使用します。詳細については、「Amazon Linux 2023 ユーザーガイド」の「バージョン対応リポジトリによる確定的なアップグレード」を参照してください。

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

  1. マネージドノードで、YUM ライブラリ (Amazon Linux 2) または DNF ライブラリ (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 2 の場合、このワークフローに対する同等の yum コマンドは次のとおりです。

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

    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 2 の場合、このワークフローに対する同等の yum コマンドは次のとおりです。

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

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

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

    yum または dnf コマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません。

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

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

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

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

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

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

    注記

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

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

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

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

    • 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
    注記

    yum または dnf コマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません。

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

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

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

  1. マネージドノードで、YUM ライブラリ (RHEL 7) または DNF ライブラリ (AlmaLinux 8 と 9、RHEL 8、9、10、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、10、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、10、Rocky Linux 8 と 9 の場合、このワークフローに相当する dnf コマンドは次のとおりです。

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

    yum または dnf コマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません。

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

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 16.04 LTS: xenial-security

    • Ubuntu Server 18.04 LTS: bionic-security

    • Ubuntu Server 20.04 LTS: focal-security

    • Ubuntu Server 22.04 LTS (jammy-security)

    • Ubuntu Server 24.04 LTS (noble-security)

    • Ubuntu Server 25.04 (plucky-security)

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

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

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

注記

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

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

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

name, priority, section, archive, candidate version

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