パッチのインストール方法 - AWS Systems Manager

パッチのインストール方法

AWS Systems Manager のツールである Patch Manager は、オペレーティングシステムのタイプ別に適切な組み込み機構を使用してマネージドノードに更新をインストールします。例えば、Windows Server には Windows Update API を使用し、Amazon Linux 2 には yum パッケージマネージャーを使用します。

Patch Manager は、現在インストールされている古いパッケージを置き換える新しいパッケージをインストールしません。(例外: 新しいパッケージが、インストールされている別のパッケージの更新で依存関係にあるか、新しいパッケージの名前が古いパッケージと同じである場合)。代わりに、Patch Manager はインストールされたパッケージに利用可能な更新を通知し、インストールします。このアプローチは、あるパッケージが別のパッケージを置き換えたときに発生する可能性のあるシステム機能の予期しない変更を防ぐのに役立ちます。

古くなったパッケージをアンインストールして新たなパッケージを改めてインストールする必要がある場合は、カスタムスクリプトを使用するか、Patch Manager の標準オペレーション外でパッケージマネージャーコマンドを使用する必要がある場合があります。

以下の各タブを選択して、Patch Manager がオペレーティングシステムにパッチをインストールする方法を確認してください。

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022 および Amazon Linux 2023 のマネージドノードでは、パッチのインストールワークフローは次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. YUM 更新 API (Amazon Linux 1、Amazon Linux 2) または DNF 更新 API (Amazon Linux 2022、Amazon Linux 2023) は、承認されたパッチに次のように適用されます。

    • AWS により事前定義されたデフォルトのパッチベースラインについては、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティ更新のみ)。これは、[セキュリティ以外の更新を含める] チェックボックスがオフになっているためです。事前定義されたベースラインは、以下を含むカスタムベースラインと同等です。

      • [セキュリティ以外の更新を含める] チェックボックスはオフになっています。

      • [Critical, Important] の重要度リスト

      • [Security, Bugfix] の分類リスト

      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

      [セキュリティ以外の更新を含める] チェックボックスがオンになっている場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティ以外の更新)。

      Amazon Linux 1、Amazon Linux 2 では、[セキュリティ以外の更新を含める] のベースラインが選択され、重要度リストが [Critical, Important] で、分類リストが [Security, Bugfix] である場合、同等の yum コマンドは次のようになります。

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

      Amazon Linux 2022 および Amazon Linux 2023 の場合、同等の dnf コマンドは次のようになります。

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

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

      Amazon Linux 2022 と Amazon Linux 2023 の追加パッチ適用の詳細
      重要度レベル「なし」のサポート

      Amazon Linux 2022 および Amazon Linux 2023 は、DNF パッケージマネージャーによって認識されるパッチの重要度レベル None もサポートしています。

      重要度レベル「中」のサポート

      Amazon Linux 2022 および Amazon Linux 2023 の場合、パッチの重要度レベル Medium は、一部の外部リポジトリで定義されている重要度レベル Moderate と同等です。パッチベースラインに Medium 重要度パッチを含めると、外部パッチからの Moderate 重要度パッチもインスタンスにインストールされます。

      API アクション DescribeInstancePatches を使用してコンプライアンスデータをクエリすると、重要度レベル Medium のフィルタリングによって、重要度レベルが Medium と Moderate の両方のパッチがレポートされます。

      Amazon Linux 2022 と Amazon Linux 2023 の推移的な依存関係処理

      Amazon Linux 2022 と Amazon Linux 2023 の場合、Patch Manager は、同等の dnf コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。

      例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、dnf upgrade-minimal --security は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

CentOS and CentOS Stream

CentOS および CentOS Stream マネージドノードの場合、パッチのインストールワークフローは次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

    パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  2. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  3. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  4. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  5. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  6. 承認済みパッチには、YUM 更新 API (CentOS 6.x および 7.x バージョン) または DNF 更新 (CentOS 8 および CentOS Stream) が適用されます。

    注記

    CentOS の場合、Patch Manager は、dnf コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。

    例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、dnf upgrade-minimal --security は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。

  7. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Debian サーバー and Raspberry Pi OS

Debian Server および Raspberry Pi OS (旧称 Raspbian) インスタンスの場合、パッチのインストール手順は次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  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 ソースキーリングから削除されます。これは、パッチ適用オペレーション前のシステム設定をそのまま残すために行われます。

    次にPatch Managerがシステムを更新するときにも、同じプロセスが行われます。

  3. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  4. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    注記

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

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

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

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

    注記

    Debian Server および Raspberry Pi OS では、パッチの候補となるバージョンは debian-security に含まれているパッチに限定されます。

  5. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  6. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  7. APT ライブラリを使用してパッケージをアップグレードします。

    注記

    Patch Manager では、APT Pin-Priority オプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

macOS

macOS マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。

  1. /Library/Receipts/InstallHistory.plist プロパティリストは、softwareupdate および installer パッケージマネージャーを使用してインストールおよびアップグレードされたソフトウェアのレコードです。pkgutil コマンドラインツール (installer 用) と softwareupdate パッケージマネージャーを使用して、CLI コマンドはこのリストを解析するために実行されます。

    installer の場合、CLI コマンドに対する応答には package nameversionvolumelocation、および install-time の詳細が含まれますが、Patch Manager で使用されるのは、package nameversion のみです。

    softwareupdate の場合、CLI コマンドへの応答にはパッケージ名 (display name)、versiondate が含まれますが、パッチマネージャーで使用されるのは、パッケージ名とバージョンのみです。

    Brew と Brew Cask の場合、Homebrew は root ユーザーで実行されるコマンドをサポートしていません。その結果、Patch Manager は Homebrew ディレクトリの所有者、または Homebrew ディレクトリの所有者グループに属する有効なユーザーとして、Homebrew コマンドを照会して実行します。コマンドは、softwareupdateinstaller に似ており、Python サブプロセスを介してパッケージデータを収集し、出力を解析してパッケージ名とバージョンを識別します。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. マネージドノードで適切なパッケージ CLI を呼び出し、承認されたパッチを次のように処理します。

    注記

    installer には、更新プログラムを確認してインストールする機能がありません。したがって、installer では、Patch Manager はインストールされているパッケージのみをレポートします。その結果、installer パッケージは Missing として報告されることはありません。

    • AWS により事前定義されたデフォルトのパッチベースラインと、カスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオフである場合、セキュリティの更新のみが適用されます。

    • カスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオンである場合、セキュリティの更新とセキュリティ以外の更新の両方が適用されます。

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Oracle Linux

Oracle Linux マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. バージョン 7 マネージドノードでは、YUM 更新 API が、次のように承認済みパッチに適用されます。

    • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオフである場合、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティの更新のみ)。

      このワークフローに該当する yum コマンドは次のとおりです。

      sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
    • カスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオンである場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティ以外の更新)。

      このワークフローに該当する yum コマンドは次のとおりです。

      sudo yum update --security --bugfix -y

      バージョン 8 と 9 のマネージドノードでは、DNF 更新 API が、次のように承認済みパッチに適用されます。

      • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオフである場合、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティの更新のみ)。

        このワークフローに該当する yum コマンドは次のとおりです。

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

        Oracle Linux の場合、Patch Manager は、dnf コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。

        例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、dnf upgrade-minimal --security は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。

      • カスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオンである場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティ以外の更新)。

        このワークフローに該当する yum コマンドは次のとおりです。

        sudo dnf upgrade --security --bugfix
    注記

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

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

AlmaLinux, RHEL, and Rocky Linux

AlmaLinux、Red Hat Enterprise Linux、および Rocky Linux マネージドノードで、パッチのインストール手順は次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. YUM 更新 API (RHEL 7) または DNF 更新 API (AlmaLinux 8 と 9、RHEL 8、9、10、Rocky Linux 8 と 9) は、承認されたパッチに次のルールに従って適用されます。

     

    シナリオ 1: セキュリティ以外の更新が除外される
    • 適用先: AWS によって提供される事前定義されたデフォルトのパッチベースラインとカスタムパッチベースライン。

    • [セキュリティ以外の更新を含める] チェックボックス: オフ

    • 適用されるパッチ: updateinfo.xml で指定されたパッチ (セキュリティ更新のみ) は、どちらもパッチベースライン設定と一致し、設定されたリポジトリで見つかった場合にのみ適用されます。

      場合によっては、updateinfo.xml で指定されたパッチが、設定されたリポジトリで使用できなくなっていることがあります。通常、設定されるリポジトリには以前のすべての更新の累積的なロールアップであるパッチの最新バージョンのみが含まれていますが、最新バージョンがパッチベースラインルールと一致せず、パッチ適用オペレーションから除外される可能性があります。

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

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

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

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \ sudo dnf update-minimal --sec-severity=Important --bugfix -y
      注記

      AlmaLinu、RHEL、Rocky LinuxRocky Linux の場合、Patch Manager は、dnf コマンドでインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。

      例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、dnf upgrade-minimal --security は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。

    シナリオ 2: セキュリティ以外の更新が含まれる
    • 適用先: カスタムパッチベースライン。

    • [セキュリティ以外の更新を含める] チェックボックス: オン。

    • 適用されるパッチ: updateinfo.xml にあるパッチupdateinfo.xml にないパッチが適用されます (セキュリティ更新とセキュリティ以外の更新)。

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

      sudo yum update --security --bugfix -y

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

      sudo dnf update --security --bugfix -y
    注記

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

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

SLES

SUSE Linux Enterprise Server (SLES) マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. Zypper 更新 API は、承認済みパッチに適用されます。

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Ubuntu Server

Ubuntu Server マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

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

  3. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  4. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    注記

    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)

    • Ubuntu Server 23.10 (mantic-security)

    • Ubuntu Server 24.04 LTS (noble-security)

    • Ubuntu Server 24.10 (oracular-security)

    • Ubuntu Server 25.04 (plucky-security)

  5. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  6. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  7. APT ライブラリを使用してパッケージをアップグレードします。

    注記

    Patch Manager では、APT Pin-Priority オプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。

  8. 更新がインストールされると、マネージドノードは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Windows Server

Windows Server マネージドノードに対してパッチ適用オペレーションを実行すると、このノードは該当するパッチベースラインのスナップショットを Systems Manager にリクエストします。このスナップショットには、デプロイ用に承認されたすべての使用可能な更新がパッチベースラインとして含まれています。この更新のリストが Windows Update API に送信されて、マネージドノードに適用できる更新が確認され、必要に応じてインストールされます。Windows では、KB の使用可能な最新バージョンのみをインストールできます。Patch Manager は、KB の最新バージョンまたは以前のバージョンの KB が、適用されたパッチベースラインと一致する場合に KB の最新バージョンをインストールします。更新のインストール後に、マネージドノードが必要な回数だけ再起動されて、すべての必要なパッチが適用されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。) パッチ適用オペレーションの概要は、Run Command リクエストの出力で確認できます。詳細なログは、マネージドノードの %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs フォルダにあります。

KB のダウンロードとインストールには Windows Update API が使用されるため、Windows Update のすべてのグループポリシー設定が適用されます。Patch Manager の使用には、グループポリシー 設定は必須ではありませんが、ユーザー定義のすべての設定 (マネージドノードのターゲットを Windows Server Update Services (WSUS) サーバーにするなど) が適用されます。

注記

Windows では、Patch Managerは Windows Update API を使用して KB のダウンロードとインストールを行うため、デフォルトではすべての KB が Microsoft の Windows Update サイトからダウンロードされます。そのため、マネージドノードは Microsoft Windows Update サイトに接続できる必要があります。そうでないと、パッチ適用は失敗します。別の方法として、WSUS サーバーを KB レポジトリとして設定し、グループポリシーを使用して WSUS サーバーをターゲットとするようマネージドノードを設定できます。

Patch Manager は、承認済みパッチリストまたは拒否済みパッチリストがベースライン設定に含まれている場合など、Windows Server のカスタムパッチベースラインを作成するときに KB ID を参照することがあります。Patch Manager がインストールするのは、KB ID が Microsoft Windows Update または WSUS サーバーに割り当てられている更新のみです。KB ID がない更新は、パッチ適用のオペレーションに含まれません。

カスタムパッチベースラインの作成に関する詳細は、以下のトピックを参照してください。