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

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

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

以下の各タブを選択して、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
      注記

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

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

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

  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) が適用されます。

  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 name、version、volume、location、および install-time の詳細が含まれますが、Patch Manager で使用されるのは、package name と version のみです。

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

    Brew と Brew Cask の場合、Homebrew は root ユーザーで実行されるコマンドをサポートしていません。その結果、Patch Manager は Homebrew ディレクトリの所有者、または Homebrew ディレクトリの所有者グループに属する有効なユーザーとして、Homebrew コマンドを照会して実行します。コマンドは、softwareupdate と installer に似ており、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

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

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

        sudo dnf upgrade --security --bugfix

  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、および Rocky Linux 8 および 9) は、承認されたパッチに次のように適用されます。

    • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオフである場合、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

    • カスタムのパッチベースラインについては、[セキュリティ以外の更新を含める] チェックボックスがオンである場合、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

  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-lobster

  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 サーバーをターゲットとするようマネージドノードを設定できます。