• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# Patch Managerの動作の仕組み
このセクションでは、サポートされているオペレーティングシステム別に、どのパッチをどのようにインストールするかについて、AWS Systems Manager のツールである Patch Manager で決定する方法を技術的に詳しく説明します。また、Linux オペレーティングシステムの場合に、マネージドノードに設定されたデフォルト以外のパッチ用に、カスタムのパッチベースラインでソースリポジトリを指定する方法についても説明します。さらに、Linux オペレーティングシステムのディストリビューション別に、パッチベースラインルールがどのように動作するかについて詳しく説明します。
**注記**
以下のトピックの情報は、パッチ適用オペレーションに使用する設定の方法や種類に関係なく適用されます。
Quick Setup で設定されているパッチポリシー
Quick Setup で設定されているホスト管理オプション
パッチ `Scan` または `Install` のタスクを実行するためのメンテナンスウィンドウ
オンデマンドの **[Patch now]** (今すぐパッチ適用) オペレーション
**Topics**
+ [パッケージのリリース日と更新日の計算方法](patch-manager-release-dates.md)
+ [セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md)
+ [代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)
+ [パッチのインストール方法](patch-manager-installing-patches.md)
+ [Linux ベースシステムでのパッチベースラインルールの動作方法](patch-manager-linux-rules.md)
+ [Linux と Windows Server のパッチ適用オペレーションの違い](patch-manager-windows-and-linux-differences.md)
# パッケージのリリース日と更新日の計算方法
**重要**
このページの情報は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの Amazon Linux 2 および Amazon Linux 2023 オペレーティングシステム (OS) に適用されます。Amazon Web Services では、これらの OS タイプのパッケージが作成、メンテナンスされます。他のオペレーティングシステムのメーカーがパッケージとリポジトリをどのように管理するかは、リリース日と更新日の計算方法に影響します。Red Hat Enterprise Linux などの Amazon Linux 2 および Amazon Linux 2023 以外の OS における、パッケージの更新方法とメンテナンス方法については、製造元のマニュアルを参照してください。
ほとんどの OS タイプでは、作成した[カスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)の設定で、特定の日数が経過するとパッチのインストールが自動承認されるように指定できます。AWS には、7 日間の自動承認日を含む、事前定義済みのパッチベースラインがいくつか用意されています。
自動承認の遅延とは、パッチがリリースされてから自動承認されて適用されるまでの待機日数です。たとえば、`CriticalUpdates` 分類を使用してルールを作成し、7 日間の自動承認遅延を設定します。その結果、リリース日または最終更新日が 7 月 7 日の新しい重大なパッチは 7 月 14 日に自動的に承認されます。
Amazon Linux 2 と Amazon Linux 2023 での自動承認遅延による予期しない結果を避けるには、リリース日と更新日の計算方法を理解することが重要です。
**注記**
Amazon Linux 2 または Amazon Linux 2023 リポジトリがパッケージのリリース日情報を提供しない場合、Patch Manager はパッケージのビルド時間を自動承認日指定の日付として使用します。パッケージのビルド時間が特定できない場合、Patch Manager はデフォルトの日付である 1970 年 1 月 1 日を使用します。これにより、Patch Manager は 1970 年 1 月 1 日以降の任意の日付のパッチを承認するように設定されたパッチベースラインの自動承認日指定をバイパスします。
ほとんどの場合、パッチがインストールされるまでの自動承認の待ち時間は、`Release Date` 値ではなく、`updateinfo.xml` の `Updated Date` 値から計算されます。これらの日付計算に関する重要な詳細は次のとおりです。
+ `Release Date` は通知がリリースされる日付です。パッケージが必ずしも関連するリポジトリで利用可能であるとは限りません。
+ `Update Date` は通知が最後に更新された日付です。通知の更新は、テキストや説明の更新のような小さなものを表すことができます。パッケージが必ずしもその日付からリリースされたり、関連するリポジトリで利用可能であったりするとは限りません。
つまり、パッケージの `Update Date` 値は 7 月 7 日ですが、(たとえば) 7 月 13 日までインストールできない場合があります。この場合、7 日間の自動承認遅延を指定するパッチベースラインが 7 月 14 日に `Install` オペレーションで実行されます。なぜなら、`Update Date` 値は実行日の 7 日前で、パッケージのパッチとアップデートは 7 月 14 日にインストールされるからです。パッケージが実際にインストール可能になってから 1 日しか経過していなくても、インストールは行われます。
+ オペレーティングシステムまたはアプリケーションパッチを含むパッケージは、初回リリース後に複数回更新できます。
+ パッケージは AWS 管理リポジトリにリリースできますが、後で問題が発見された場合はロールバックされます。
一部のパッチ処理では、これらの要素は重要ではない場合があります。たとえば、重要度の値が `Low` および `Medium`、ならびに `Recommended` の分類のパッチをインストールするようにパッチベースラインが設定されている場合、自動承認が遅れても、運用にほとんど影響しない可能性があります。
ただし、重大なパッチや重要度の高いパッチを配布するタイミングがより重要な場合は、パッチがいつインストールされるかをより細かく制御したい場合があります。これを行うための推奨される方法は、管理対象ノードでのパッチオペレーションでデフォルトリポジトリの代わりに代替のパッチソースリポジトリを使用することです。
カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。
# セキュリティに関連するパッチの選択方法
AWS Systems Manager のツールである Patch Manager の主な目的は、オペレーティングシステムのセキュリティに関連する更新プログラムをマネージドノードにインストールすることです。デフォルトでは、Patch Manager はすべての利用可能なパッチをインストールするのではなく、一部のセキュリティ関連のパッチをインストールします。
デフォルトでは、Patch Manager は、パッケージリポジトリで廃止とマークされたパッケージを、別のパッケージ更新のインストールでこの置換が必要な場合を除き、別の名前の置換パッケージに置き換えません。代わりに、パッケージを更新するコマンドの場合、Patch Manager はインストールされているが古いパッケージの欠落した更新のみを通知してインストールします。これは、古いパッケージを置き換えるには、通常、既存のパッケージをアンインストールし、改めて新しいパッケージをインストールする必要があるためです。古いパッケージを置き換えると、意図していない重大な変更や追加機能が発生する可能性があります。
この動作は、機能のアップグレードではなくセキュリティ更新に焦点を当てた YUM および DNF の `update-minimal` コマンドと一致しています。詳細については、「[パッチのインストール方法](patch-manager-installing-patches.md)」を参照してください。
**注記**
パッチベースラインルールで `ApproveUntilDate` パラメータまたは `ApproveAfterDays` パラメータを使用すると、Patch Manager は協定世界時 (UTC) を使用してパッチリリース日を評価します。
例えば、`ApproveUntilDate` の場合、`2025-11-16` などの日付を指定すると、`2025-11-16T00:00:00Z` と `2025-11-16T23:59:59Z` の間にリリースされたパッチが承認されます。
マネージドノードのネイティブパッケージマネージャーによって表示されるパッチリリース日は、システムのローカルタイムゾーンに基づいて異なる時間が表示される場合がありますが、Patch Manager は承認の計算で常に UTC 日時を使用することに注意してください。これにより、公式のセキュリティアドバイザリウェブサイトで公開されているパッチリリース日との一貫性が確保されます。
パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS ([共通脆弱性評価システム](https://www.first.org/cvss/)) のような サードパーティのソースからの、または NVD ([National Vulnerability Database](https://nvd.nist.gov/vuln)) がリリースしたメトリクスからの重要度レベルは取得しません。
**注記**
Patch Manager でサポートされているすべての Linux ベースのシステムでは、セキュリティに関連しない更新プログラムをインストールしたりするために、マネージドノードに別のソースリポジトリを選択することができます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。
以下の各タブを選択して、お使いのオペレーティングシステムで Patch Manager がセキュリティ関連のパッチを選択する方法を確認してください。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Amazon Linux 2 および Amazon Linux 2023 では、事前設定されたリポジトリの処理とは異なります。
Amazon Linux 2 では、Systems Manager のパッチベースラインサービスは、マネージドノード上の事前設定されたリポジトリを使用します。通常、ノードには 2 つの設定済みリポジトリ (リポウズ) があります。
**Amazon Linux 2 上**
+ **リポ ID**: `amzn2-core/2/architecture`
**リポ名**: `Amazon Linux 2 core repository`
+ **リポ ID**: `amzn2extra-docker/2/architecture`
**リポ名**: `Amazon Extras repo for docker`
**注記**
*architecture* は、x86\$164 または (Graviton プロセッサの場合は) aarch64 にすることができます。
Amazon Linux 2023 (AL2023) インスタンスを作成すると、AL2023 のバージョンで利用可能な更新と、選択した特定の AMI の更新が含まれます。AL2023 インスタンスは起動時に追加のクリティカルかつ重要なセキュリティアップデートを自動的に受信しません。代わりに、デフォルトで有効になっている AL2023 の*バージョン対応リポジトリによる確定的なアップグレード機能*を使用すると、特定のニーズを満たすスケジュールに基づいて更新を適用できます。詳細については、「Amazon Linux 2023 ユーザーガイド」の「[バージョン対応リポジトリによる確定的なアップグレード](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)」を参照してください。
AL2023 では、事前設定されたリポジトリは次のとおりです。
+ **リポ ID**: `amazonlinux`
**リポジトリ名**: Amazon Linux 2023 リポジトリ
Amazon Linux 2023 (プレビューリリース) では、事前設定されたリポジトリは*ロックされたバージョン*のパッケージ更新に関連付けられています。AL2023 用の新規 Amazon Machine Images (AMIs) がリリースされると、特定のバージョンにロックされます。パッチ更新では、Patch Manager は、パッチ更新リポジトリの最新のロックバージョンを取得し、そのロックされたバージョンの内容に基づいてマネージド ノード上のパッケージを更新します。
**パッケージマネージャー**
Amazon Linux 2 マネージドノードではパッケージマネージャーとして Yum が使用されます。Amazon Linux 2023 ではパッケージマネージャーとして DNF が使用されます。
どちらのパッケージマネージャーでも、`updateinfo.xml` という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。更新通知に含まれているすべてのパッケージは、Patch Manager ではセキュリティ関連とみなされます。個々のパッケージには分類や重要度は割り当てられません。そのため、Patch Manager は関連するパッケージに更新通知の属性を割り当てます。
**注記**
**[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。
**セキュリティ以外の更新を含める**オプションの詳細については、「[パッチのインストール方法](patch-manager-installing-patches.md)」および「[Linux ベースシステムでのパッチベースラインルールの動作方法](patch-manager-linux-rules.md)」を参照してください。
------
#### [ CentOS Stream ]
CentOS Stream の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。以下のリストは、架空の CentOS 9.2 Amazon Machine Image (AMI) の例を示します。
+ **リポ ID**: `example-centos-9.2-base`
**リポ名**: `Example CentOS-9.2 - Base`
+ **リポ ID**: `example-centos-9.2-extras`
**リポ名**: `Example CentOS-9.2 - Extras`
+ **リポ ID**: `example-centos-9.2-updates`
**リポ名**: `Example CentOS-9.2 - Updates`
+ **リポ ID**: `example-centos-9.x-examplerepo`
**リポ名**: `Example CentOS-9.x – Example Repo Packages`
**注記**
すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。
CentOS Stream のノードではパッケージマネージャーとして DNF が使用されます。パッケージマネージャーでは、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。
ただし、CentOS Stream のデフォルトリポジトリは更新通知で設定されません。これは、Patch Manager で CentOS Stream のデフォルトリポジトリのパッケージが検出されないことを意味します。Patch Manager を許可して更新通知に含まれていないパッケージを処理するには、パッチベースラインルールで `EnableNonSecurity` フラグを有効にする必要があります。
**注記**
CentOS Stream の更新通知がサポートされています。更新通知のあるリポは起動後にダウンロードできます。
------
#### [ Debian サーバー ]
Debian Server の場合、Systems Manager パッチベースラインサービスはインスタンスの事前設定済みのリポジトリ (リポ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、`sudo apt-get update` コマンドと同等のコマンドを実行します。
その後、パッケージは `debian-security codename` リポからフィルタリングされます。つまり、Debian Server の各バージョンでは、次のように、Patch Manager は、そのバージョンの関連リポジトリに含まれるアップグレードのみを識別します。
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
------
#### [ Oracle Linux ]
Oracle Linux の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。通常、ノードには 2 つの設定済みリポウズがあります。
**Oracle Linux 7**:
+ **リポ ID**: `ol7_UEKR5/x86_64`
**リポ名**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **リポ ID**: `ol7_latest/x86_64`
**リポ名**: `Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**:
+ **リポ ID**: `ol8_baseos_latest`
**リポ名**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **リポ ID**: `ol8_appstream`
**リポ名**: `Oracle Linux 8 Application Stream (x86_64)`
+ **リポ ID**: `ol8_UEKR6`
**リポ名**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**:
+ **リポ ID**: `ol9_baseos_latest`
**リポ名**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **リポ ID**: `ol9_appstream`
**リポ名**: `Oracle Linux 9 Application Stream Packages(x86_64)`
+ **リポ ID**: `ol9_UEKR7`
**リポ名**: `Oracle Linux UEK Release 7 (x86_64)`
**注記**
すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。
Oracle Linux マネージドノードではパッケージマネージャーとして Yum が使用されます。Yum では `updateinfo.xml` という名前のファイルとして、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。
**注記**
**[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
AlmaLinux では、Red Hat Enterprise Linux および Rocky Linux では、Systems Manager のパッチベースラインサービスでマネージドノードの事前設定済みリポジトリ (リポウズ) が使用されます。通常、ノードには 3 つの設定済みリポウズがあります。
すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。
**注記**
**[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。
Red Hat Enterprise Linux 7 のマネージドノードではパッケージマネージャーとして Yum が使用されます。AlmaLinux、Red Hat Enterprise Linux 8、および Rocky Linux のマネージドノードではパッケージマネージャーとして DNF が使用されます。どちらのパッケージマネージャーでも、`updateinfo.xml` という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。
RHEL 7
以下のレポ ID は RHUI 2 に関連付けられています。RHUI 3 は 2019 年 12 月に開始され、Yum リポジトリ ID に異なる命名スキームを導入しました。マネージドノード作成元の RHEL-7 AMI によっては、コマンドを更新する必要がある場合があります。詳細については、Red Hat カスタマーポータルの「[AWS にある RHEL 7 のリポジトリ ID が既に変化した](https://access.redhat.com/articles/4599971)」を参照してください。
+ **リポ ID**: `rhui-REGION-client-config-server-7/x86_64`
**リポ名**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **リポ ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64`
**リポ名**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **リポ ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**リポ名**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux、8 RHEL 8、および Rocky Linux 8
+ **リポ ID**: `rhel-8-appstream-rhui-rpms`
**リポ名**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **リポ ID**: `rhel-8-baseos-rhui-rpms`
**リポ名**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **リポ ID**: `rhui-client-config-server-8`
**リポ名**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9、 RHEL 9、および Rocky Linux 9
+ **リポ ID**: `rhel-9-appstream-rhui-rpms`
**リポ名**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **リポ ID**: `rhel-9-baseos-rhui-rpms`
**リポ名**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **リポ ID**: `rhui-client-config-server-9`
**リポ名**:`Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
SUSE Linux Enterprise Server (SLES) マネージドノードでは、ZYPP ライブラリは使用可能なパッチのリスト (パッケージの集合) を以下の場所から取得します。
+ リポジトリのリスト: `etc/zypp/repos.d/*`
+ パッケージの情報: `/var/cache/zypp/raw/*`
SLES マネージドノードはパッケージマネージャーとして Zypper を使用し、Zypper はパッチの概念を使用します。パッチは、特定の問題を修正するパッケージのコレクションです。Patch Manager は、パッチに含まれているすべてのパッケージをセキュリティ関連のパッケージとみなします。個々のパッケージには分類や重要度が与えられていないため、Patch Managerはパッケージにその属しているパッチの属性を割り当てます。
------
#### [ Ubuntu Server ]
Ubuntu Server の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、`sudo apt-get update` コマンドと同等のコマンドを実行します。
次に、パッケージを `codename-security` リポジトリでフィルタリングします。この codename はリリースバージョンに固有です (Ubuntu Server 14 の場合は `trusty` など)。Patch Managerは、次のリポジトリに含まれているアップグレードのみを識別します。
+ 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`)
------
#### [ Windows サーバー ]
Microsoft Windows オペレーティングシステムの場合、Patch Manager は Microsoft が Microsoft Update に公開して Windows Server Update Services (WSUS) で自動的に利用可能になる更新プログラムのリストを取得します。
**注記**
Patch Managerでは、Patch Manager でサポートされている Windows Server オペレーティングシステムのバージョンで利用可能なパッチのみを使用できます。例えば、Patch Managerを使用して Windows RT にパッチを適用することはできません。
Patch Manager は各 AWS リージョン で新しい更新を継続的にモニタリングします。利用可能な更新プログラムのリストは、各リージョンで 1 日 1 回以上更新されます。Microsoft からのパッチ情報が処理されると、Patch Manager は最新の更新プログラムで置き換えられた前の更新プログラムをパッチのリストから削除します。したがって、最新の更新のみが表示され、インストール可能になります。例えば、`KB3135456` が `KB4012214` に置き換えられると、Patch Manager では `KB4012214` のみが利用可能となります。
同様に、Patch Manager がインストールできるのは、パッチ適用オペレーション中にマネージドノードで利用可能になっているパッチのみです。デフォルトで、Windows Server 2019 および Windows Server 2022 は後続の更新に置き換えられた更新を削除します。その結果、Windows Server パッチベースラインで `ApproveUntilDate` パラメータを使用しても、`ApproveUntilDate` パラメータで選択された日付が最新パッチの日付よりも前になっている場合は、以下のシナリオが発生します。
+ 置き換えられたパッチはノードから削除されるため、Patch Manager を使用してインストールすることができない。
+ 最新の代替パッチがノードに存在するが、`ApproveUntilDate` パラメータで指定された日付に従ったインストールにはまだ承認されていない。
これは、前月の緊急パッチがインストールされていない可能性がある場合でも、Systems Manager オペレーションに関してはマネージドノードが準拠状態にあることを意味します。`ApproveAfterDays` パラメータの使用時にも同じシナリオが発生する可能性があります。Microsoft の置き換えられたパッチ動作のため、`ApproveAfterDays` の日数が経過する前に Microsoft からの最新のパッチがリリースされた場合でも Windows Server 向けのパッチがインストールされないように、日数を設定することが可能です (通常は 30 日を超える日数)。マネージドノードで置き換えられたパッチを利用できるように Windows グループポリシーオブジェクト (GPO) 設定を変更した場合、このシステム動作は該当しないことに注意してください。
**注記**
Microsoft がリリースするアプリケーションのパッチは、更新日時を指定していない場合があります。このような場合、デフォルトでは `01/01/1970` の更新日時が指定されています。
------
# 代替パッチソースリポジトリを指定する方法 (Linux)
マネージドノードに設定されているデフォルトのリポジトリをパッチオペレーションに使用すると、AWS Systems Manager のツールである Patch Manager はセキュリティに関連するパッチをスキャンまたはインストールします。これがPatch Managerのデフォルトの動作です。Patch Manager がセキュリティ関連のパッチを選択してインストールする方法の詳細については、「[セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md)」を参照してください。
ただし、Linux システムでは、Patch Manager を使用して、セキュリティに関連しないパッチや、マネージドノードに設定されているデフォルトのリポジトリとは異なるソースリポジトリにあるパッチをインストールすることもできます。カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。
例えば、Ubuntu Server フリートに Ubuntu Server 25.04 マネージドノードの両方が含まれているとします。この場合、同じカスタムパッチベースラインで、各バージョンの代替リポジトリを指定できます。バージョンごとに、名前、オペレーティングシステムのバージョンタイプ (製品)、リポジトリ設定を指定します。サポートされているオペレーティングシステムのすべてのバージョンに適用される 1 つの代替ソースリポジトリを指定することもできます。
**注記**
マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。
このオプションを使用するシナリオの例のリストについては、このトピックの後半の「[代替パッチソースリポジトリの使用例](#patch-manager-alternative-source-repository-examples)」を参照してください。
デフォルトおよびカスタムのパッチベースラインについては、「[事前定義されたパッチベースラインおよびカスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md)」を参照してください。
**例: コンソールを使用する場合**
Systems Manager コンソールでの作業時に代替パッチソースリポジトリを指定するには、[**Create patch baseline** (パッチベースラインの作成)] ページの [**Patch sources** (パッチソース)] セクションを使用します。[**Patch sources (パッチソース)**] のオプションの使用については、「[Linux 用 カスタムパッチベースラインの作成](patch-manager-create-a-patch-baseline-for-linux.md)」を参照してください。
**例: AWS CLI を使用する場合**
AWS Command Line Interface (AWS CLI) で `--sources` オプションを使用する例については、「[異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources)」を参照してください。
**Topics**
+ [代替リポジトリに関する重要な考慮事項](#alt-source-repository-important)
+ [代替パッチソースリポジトリの使用例](#patch-manager-alternative-source-repository-examples)
## 代替リポジトリに関する重要な考慮事項
代替パッチリポジトリを使用してパッチ適用戦略を計画する際は、次の点に注意してください。
**リポジトリ更新の認証を実施する (YUM と DNF)**
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、リポジトリへの接続が確立できない場合、アクセスできないパッケージリポジトリをスキップするように設定されることがあります。リポジトリの更新の認証を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。
`skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。
**指定されたリポジトリのみがパッチ適用に使用されます**
代替リポジトリの指定は、*追加*リポジトリの指定を意味しません。マネージドノードにデフォルトとして設定されているリポジトリ以外のリポジトリを選択することができます。ただし、更新を適用する場合は、代替のパッチソース設定の一部としてデフォルトのリポジトリも指定する必要があります。
例えば、Amazon Linux 2 マネージドノードでは、デフォルトのリポジトリは `amzn2-core` と `amzn2extra-docker` です。パッチ適用オペレーションで Extra Packages for Enterprise Linux (EPEL) リポジトリを含める必要がある場合は、3 つのリポジトリすべてを代替リポジトリとして指定する必要があります。
**注記**
マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。
**YUM ベースのディストリビューションのパッチ適用の動作は、updateinfo.xml マニフェストに依存します**
Amazon Linux 2 または Red Hat Enterprise Linux など、YUM ベースのディストリビューション用の代替パッチリポジトリを指定する場合、パッチ適用動作は、リポジトリに更新マニフェストが完全で正しい形式の `updateinfo.xml` ファイルで含まれているかどうかによって異なります。このファイルは、リリース日、分類、および各種パッケージの重要度を指定します。次のいずれかのパッチ動作に影響を与えます。
+ **Classification** や **Severity** でフィルターしても、それらが `updateinfo.xml` で指定されていない場合、そのパッケージはフィルターには含まれません。つまり、`updateinfo.xml` ファイルのないパッケージはパッチ適用に含まれません。
+ **ApprovalAfterDays** でフィルターしても、パッケージのリリース日が Unix エポック形式でない場合 (またはリリース日が指定されていない場合)、そのパッケージはフィルターに含まれません。
+ **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにした場合、例外が発生します。この場合、`updateinfo.xml` ファイルを持たないパッケージ (または、**分類**、**重要度**、**日付**の値が適切にフォーマットされていないこのファイルが含まれている) は、パッチの事前フィルタリングされたリストに含まれ*ます*。(インストールするには、パッチベースラインルールの他の要件を満たしていなければなりません。)
## 代替パッチソースリポジトリの使用例
**例 1 - Ubuntu Server のセキュリティに関連しない更新プログラム**
AWS が提供する事前定義されたパッチベースライン `AWS-UbuntuDefaultPatchBaseline` を使用して、セキュリティパッチを Ubuntu Server マネージドノードのフリート上にインストールするために Patch Manager を既に使用しているとします。このデフォルトに基づいて新しいパッチベースラインを作成できますが、デフォルトのディストリビューションに含まれるセキュリティに関連しない更新プログラムもインストールするように、承認ルールで指定できます。このパッチベースラインがノードに対して実行されると、セキュリティに関連する問題と関連しない問題の両方に対するパッチが適用されます。また、ベースラインに対して指定したパッチ例外で、セキュリティに関連しないパッチを承認することもできます。
**例 2 - Ubuntu Server の PPA (Personal Package Archives)**
Ubuntu Server マネージドノードで、[Personal Package Archives (PPA) for Ubuntu](https://launchpad.net/ubuntu/+ppas) を通じて配布されるソフトウェアを実行するとします。この場合、マネージドノードで設定した PPA リポジトリをパッチ適用オペレーションのソースリポジトリとして指定する、パッチベースラインを作成します。その後、Run Command を使用して、ノードでパッチベースライン ドキュメントを実行します。
**例 3 - サポートされている Amazon Linux のバージョンの社内アプリケーション**
Amazon Linux マネージドノードで、業界の規制コンプライアンスに必要なアプリケーションを実行する必要があるとします。ノードでこれらのアプリケーションのリポジトリを設定し、YUM を使用してアプリケーションをまずインストールしてから、この新しい企業リポジトリを含むように、新しいパッチベースラインを更新または作成できます。その後、Run Command を使用し、`Scan` オプション付きで `AWS-RunPatchBaseline` ドキュメントを実行することで、企業パッケージがインストールされたパッケージに含まれており、マネージドノードで最新かどうかを確認できます。最新でない場合は、`Install` オプション付きでそのドキュメントを再実行することで、アプリケーションを更新できます。
# パッチのインストール方法
AWS Systems Manager のツールである Patch Manager は、オペレーティングシステムの組み込みパッケージマネージャーを使用してマネージドノードに更新プログラムをインストールします。例えば、Windows Server に Windows Update API を使用して、Amazon Linux 2023 に `DNF` を使用します。Patch Manager は、ノード上の既存のパッケージマネージャーおよびリポジトリの設定に従います。これには、リポジトリのステータス、ミラー URL、GPG 認証、`skip_if_unavailable` などのオプションといった設定が含まれます。
Patch Manager は、現在インストールされている古いパッケージを置き換える新しいパッケージをインストールしません。(例外: 新しいパッケージが、インストールされている別のパッケージの更新で依存関係にあるか、新しいパッケージの名前が古いパッケージと同じである場合)。代わりに、Patch Manager はインストールされたパッケージに利用可能な更新を通知し、インストールします。このアプローチは、あるパッケージが別のパッケージを置き換えたときに発生する可能性のあるシステム機能の予期しない変更を防ぐのに役立ちます。
古くなったパッケージをアンインストールして新たなパッケージを改めてインストールする必要がある場合は、カスタムスクリプトを使用するか、Patch Manager の標準オペレーション外でパッケージマネージャーコマンドを使用する必要がある場合があります。
以下の各タブを選択して、Patch Manager がオペレーティングシステムにパッチをインストールする方法を確認してください。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Amazon Linux 2 および Amazon Linux 2023 マネージドノードでは、パッチのインストールワークフローは次のとおりです。
1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
1. YUM 更新 API (Amazon Linux 2) または DNF 更新 API (Amazon Linux 2023) は、承認されたパッチに次のように適用されます。
+ AWS により事前定義されたデフォルトのパッチベースラインについては、`updateinfo.xml` で指定されたパッチのみが適用されます (セキュリティ更新のみ)。これは、**[セキュリティ以外の更新を含める]** チェックボックスがオフになっているためです。事前定義されたベースラインは、以下を含むカスタムベースラインと同等です。
+ **[セキュリティ以外の更新を含める]** チェックボックスはオフになっています。
+ `[Critical, Important]` の重要度リスト
+ `[Security, Bugfix]` の分類リスト
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
```
**[セキュリティ以外の更新を含める]** チェックボックスがオンになっている場合、`updateinfo.xml` にあるパッチと `updateinfo.xml` にないパッチの両方が適用されます (セキュリティの更新とセキュリティ以外の更新)。
Amazon Linux 2 では、**[セキュリティ以外の更新を含める]** のベースラインが選択され、重要度リストが `[Critical, Important]` で、分類リストが `[Security, Bugfix]` である場合、同等の 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 オペレーションではインストールされません**。
**Amazon Linux 2023 の追加パッチ適用の詳細**
重要度レベル「なし」のサポート
Amazon Linux 2023 は、DNF パッケージマネージャーによって認識されるパッチの重要度レベル `None` もサポートしています。
重要度レベル「中」のサポート
Amazon Linux 2023 の場合、パッチの重大度レベル `Medium` は、一部の外部リポジトリで定義されている重大度レベル `Moderate` と同等です。パッチベースラインに `Medium` 重要度パッチを含めると、外部パッチからの `Moderate` 重要度パッチもインスタンスにインストールされます。
API アクション [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) を使用してコンプライアンスデータをクエリすると、重要度レベル `Medium` のフィルタリングによって、重要度レベルが `Medium` と `Moderate` の両方のパッチがレポートされます。
Amazon Linux 2023 の推移的な依存関係処理
Amazon Linux 2023 の場合、Patch Manager は、`dnf` コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。
例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、`dnf upgrade-minimal --security` は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。**
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
**注記**
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。
`skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。
------
#### [ CentOS Stream ]
CentOS Stream マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。
パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
1. CentOS Stream の DNF 更新は、承認済みパッチに適用されます。
**注記**
CentOS Stream の場合、Patch Manager は、`dnf` コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。
例えば、`dnf upgrade-minimal ‐‐security` は既知のセキュリティ問題の解決に必要な推移的依存関係の*最小*バージョンをインストールしますが、Patch Manager は同じ推移的な依存関係の*利用可能な最新バージョン*をインストールします。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
------
#### [ Debian サーバー ]
Debian Server インスタンスの場合、パッチのインストール手順は次のとおりです。
1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`InstallOverrideList` または `AWS-RunPatchBaseline` ドキュメントの `AWS-RunPatchBaselineAssociation` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。
1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
**注記**
Debian Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
**注記**
Debian Server では、パッチの候補となるバージョンは `debian-security` に含まれているパッチに限定されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. APT ライブラリを使用してパッケージをアップグレードします。
**注記**
Patch Manager では、APT `Pin-Priority` オプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
------
#### [ 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 サブプロセスを介してパッケージデータを収集し、出力を解析してパッケージ名とバージョンを識別します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
1. マネージドノードで適切なパッケージ CLI を呼び出し、承認されたパッチを次のように処理します。
**注記**
`installer` には、更新プログラムを確認してインストールする機能がありません。したがって、`installer` では、Patch Manager はインストールされているパッケージのみをレポートします。その結果、`installer` パッケージは `Missing` として報告されることはありません。
+ AWS によって事前定義されたデフォルトのパッチベースライン、ならびに **[セキュリティ以外の更新プログラムを含める]** チェックボックスが選択されてい*ない*状態のカスタムのパッチベースラインには、セキュリティ更新プログラムのみが適用されます。
+ **[セキュリティ以外の更新プログラムを含める]** チェックボックスが選択されてい*いる*状態のカスタムのパッチベースラインには、セキュリティ更新プログラムおよびセキュリティ以外の更新プログラムの両方が適用されます。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
------
#### [ Oracle Linux ]
Oracle Linux マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
1. バージョン 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 オペレーションではインストールされません**。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
**注記**
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。
`skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。
------
#### [ 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 はスキップされます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
1. 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 オペレーションではインストールされません**。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
**注記**
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。
`skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。
------
#### [ SLES ]
SUSE Linux Enterprise Server (SLES) マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
1. Zypper 更新 API は、承認済みパッチに適用されます。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
------
#### [ Ubuntu Server ]
Ubuntu Server マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。
1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
**注記**
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`)
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
1. APT ライブラリを使用してパッケージをアップグレードします。
**注記**
Patch Manager では、APT `Pin-Priority` オプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。
1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
------
#### [ Windows サーバー ]
Windows Server マネージドノードに対してパッチ適用オペレーションを実行すると、このノードは該当するパッチベースラインのスナップショットを Systems Manager にリクエストします。このスナップショットには、デプロイ用に承認されたすべての使用可能な更新がパッチベースラインとして含まれています。この更新のリストが Windows Update API に送信されて、マネージドノードに適用できる更新が確認され、必要に応じてインストールされます。Windows では、KB の使用可能な最新バージョンのみをインストールできます。Patch Manager は、KB の最新バージョンまたは以前のバージョンの KB が、適用されたパッチベースラインと一致する場合に KB の最新バージョンをインストールします。更新のインストール後に、マネージドノードが必要な回数だけ再起動されて、すべての必要なパッチが適用されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) パッチ適用オペレーションの概要は、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 がない更新は、パッチ適用のオペレーションに含まれません。
カスタムパッチベースラインの作成に関する詳細は、以下のトピックを参照してください。
[Windows Server のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-windows.md)
[パッチベースラインの作成 (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Windows オペレーティングシステムのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# Linux ベースシステムでのパッチベースラインルールの動作方法
Linux ディストリビューションのパッチベースラインのルールは、ディストリビューションタイプ別に動作が異なります。Windows Server マネージドノードでのパッチ更新とは異なり、ルールはノードごとに評価され、インスタンスに設定されているリポジトリが考慮されます。AWS Systems Manager のツールである Patch Manager は、ネイティブのパッケージマネージャーを使用して、パッチベースラインで承認されているパッチをインストールします。
パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS ([共通脆弱性評価システム](https://www.first.org/cvss/)) のような サードパーティのソースからの、または NVD ([National Vulnerability Database](https://nvd.nist.gov/vuln)) がリリースしたメトリクスからの重要度レベルは取得しません。
**Topics**
+ [Amazon Linux 2 および Amazon Linux 2023 でのパッチベースラインルールの仕組み](#linux-rules-amazon-linux)
+ [CentOS Stream でのパッチベースラインルールの仕組み](#linux-rules-centos)
+ [Debian Server でのパッチベースラインルールの仕組み](#linux-rules-debian)
+ [macOS でのパッチベースラインルールの仕組み](#linux-rules-macos)
+ [Oracle Linux でのパッチベースラインルールの仕組み](#linux-rules-oracle)
+ [AlmaLinux、RHEL、および Rocky Linux でのパッチベースラインルールの動作方法](#linux-rules-rhel)
+ [SUSE Linux Enterprise Server でのパッチベースラインルールの仕組み](#linux-rules-sles)
+ [Ubuntu Server でのパッチベースラインルールの仕組み](#linux-rules-ubuntu)
## Amazon Linux 2 および Amazon Linux 2023 でのパッチベースラインルールの仕組み
**注記**
Amazon Linux 2023 (AL2023) は、1 つ以上のシステム設定を通じて特定のバージョンにロックできるバージョン管理されたリポジトリを使用します。AL2023 EC2 インスタンスに対するすべてのパッチ適用オペレーションについて、Patch Manager はシステム設定に関係なく、最新のリポジトリバージョンを使用します。詳細については、「Amazon Linux 2023 ユーザーガイド」の「[バージョン対応リポジトリによる確定的なアップグレード](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)」を参照してください。
Amazon Linux 2 および Amazon Linux 2023 のパッチの選択プロセスは、次のとおりです。
1. マネージドノードで、YUM ライブラリ (Amazon Linux 2) または DNF ライブラリ (Amazon Linux 2023) が各設定済みリポジトリの `updateinfo.xml` ファイルにアクセスします。
`updateinfo.xml` ファイルが見つからない場合、パッチがインストールされるかどうかは、**[セキュリティ以外の更新を含める]** および **[自動承認]** の設定に応じます。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。
1. `updateinfo.xml` の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。
**更新通知の属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。
1. 更新用のパッケージは、次のガイドラインに従って選択されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
## CentOS Stream でのパッチベースラインルールの仕組み
CentOS Stream のデフォルトリポジトリに `updateinfo.xml` ファイルは含まれていません。ただし、作成または使用するカスタムリポジトリにはこのファイルが含まれる場合があります。このトピックでは、`updateinfo.xml` への参照はこれらのカスタムリポジトリにのみ適用されます。
CentOS Stream の場合、パッチの選択プロセスは次のとおりです。
1. マネージドノードでは、DNF ライブラリは、設定された各リポジトリのために `updateinfo.xml` ファイルにアクセスします (カスタムリポジトリに存在する場合)。
必ず含まれるデフォルトリポジトリでも `updateinfo.xml` ファイルが見つからない場合、パッチがインストールされるかどうかは、**[セキュリティ以外の更新を含める]** および **[自動承認]** の設定によって異なります。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。
1. `updateinfo.xml` が存在する場合、ファイル内の各更新通知には、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。
**更新通知の属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
1. どの場合でも、マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。
1. 更新用のパッケージは、次のガイドラインに従って選択されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
## Debian Server でのパッチベースラインルールの仕組み
Debian Server では、パッチベースラインサービスは、*Priority* フィールドと *Section* フィールドでフィルタリングを行います。通常、これらのフィールドはすべての Debian Server パッケージにあります。Patch Managerは、パッチベースラインでパッチが選択されているかどうかを確認するために以下の操作を行います。
1. Debian Server システムで、`sudo apt-get update` と同等のコマンドを実行して使用可能なパッケージのリストを更新します。リポは設定されず、データは `sources` リストに設定されているリポから取得されます。
1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)
1. 次に、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)、および [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) リストが適用されます。
**注記**
Debian Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。この場合、Debian Server では、パッチの候補となるバージョンは以下のリポジトリに含まれているパッチに限定されます。
これらのリポは、次のように名前が付けられます。
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
[Priority] フィールドと [Section] フィールドの内容を表示するには、次の `aptitude` コマンドを実行します。
**注記**
場合によっては、まず Debian Server システムに Aptitude をインストールする必要があります。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
このコマンドに対するレスポンスで、すべてのアップグレード可能なパッケージが次の形式で報告されます。
```
name, priority, section, archive, candidate version
```
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
## macOS でのパッチベースラインルールの仕組み
macOS の場合、パッチの選択プロセスは次のとおりです。
1. マネージドノードで、Patch Manager は `InstallHistory.plist` ファイルの解析済みコンテンツにアクセスし、パッケージ名とバージョンを識別します。
解析プロセスの詳細については、macOS の 「**[パッチのインストール方法](patch-manager-installing-patches.md)**」のタブを参照してください。
1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。
1. 更新用のパッケージは、次のガイドラインに従って選択されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
## Oracle Linux でのパッチベースラインルールの仕組み
Oracle Linux の場合、パッチの選択プロセスは次のとおりです。
1. マネージドノードで、YUM ライブラリが各設定済みリポの `updateinfo.xml` ファイルにアクセスします。
**注記**
`updateinfo.xml` ファイルは、リポジトリが Oracle で管理されていないと使用できない場合があります。`updateinfo.xml` ファイルが見つからない場合、パッチがインストールされるかどうかは、**[セキュリティ以外の更新を含める]** および **[自動承認]** の設定に応じます。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。
1. `updateinfo.xml` の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。
**更新通知の属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。
1. 更新用のパッケージは、次のガイドラインに従って選択されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
## 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` が見つからない場合、パッチは適用されません。
1. `updateinfo.xml` の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。
**更新通知の属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。
1. 更新用のパッケージは、次のガイドラインに従って選択されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html)
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
## SUSE Linux Enterprise Server でのパッチベースラインルールの仕組み
SLES では、各パッチには、パッチ内のパッケージのプロパティを示す以下の属性が含まれます。
+ **Category**: パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型の **Classification** キー属性の値に対応します。更新通知に含まれているパッチのタイプを表します。
サポートされている値のリストは、AWS CLI コマンド **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** または API オペレーション **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** を使用して表示できます。Systems Manager コンソールの [**Create patch baseline** (パッチベースラインの作成)] ページまたは [**Edit patch baseline** (パッチベースラインの編集)] ページの [**Approval rules** (承認ルール)] 領域でリストを表示することもできます。
+ **Severity**: パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型の **Severity** キー属性の値に対応します。パッチの重要度を示します。
サポートされている値のリストは、AWS CLI コマンド **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** または API オペレーション **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** を使用して表示できます。Systems Manager コンソールの [**Create patch baseline** (パッチベースラインの作成)] ページまたは [**Edit patch baseline** (パッチベースラインの編集)] ページの [**Approval rules** (承認ルール)] 領域でリストを表示することもできます。
マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型の **プロダクト** キー属性の値に対応します。
パッチごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に含まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
## Ubuntu Server でのパッチベースラインルールの仕組み
Ubuntu Server では、パッチベースラインサービスは、*Priority* フィールドと *Section* フィールドでフィルタリングを行います。通常、これらのフィールドはすべての Ubuntu Server パッケージにあります。Patch Managerは、パッチベースラインでパッチが選択されているかどうかを確認するために以下の操作を行います。
1. Ubuntu Server システムで、`sudo apt-get update` と同等のコマンドを実行して使用可能なパッケージのリストを更新します。リポは設定されず、データは `sources` リストに設定されているリポから取得されます。
1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)
1. 次に、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)、および [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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`)
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
[Priority] フィールドと [Section] フィールドの内容を表示するには、次の `aptitude` コマンドを実行します。
**注記**
場合によっては、まず Ubuntu Server 16 システムに Aptitude をインストールする必要があります。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
このコマンドに対するレスポンスで、すべてのアップグレード可能なパッケージが次の形式で報告されます。
```
name, priority, section, archive, candidate version
```
パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。
# Linux と Windows Server のパッチ適用オペレーションの違い
このトピックでは、AWS Systems Manager のツールである Patch Manager での Linux と Windows Server のパッチ適用における重要な違いについて説明します。
**注記**
Linux マネージドノードにパッチを適用するには、ノードが SSM Agent バージョン 2.0.834.0 以降実行されている必要があります。
新しいツールが Systems Manager に追加されるか、既存のツールが更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種ツールや機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。GitHub の「[SSM Agent リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)」ページをサブスクライブすると、SSM Agent の更新に関する通知を受け取ることができます。
## 違い 1: パッチ評価
Patch Manager では、Windows マネージドノードと Linux マネージドノードで、どのパッチを提供するかを評価するプロセスが異なります。
**Linux**
Linux のパッチ適用では、Systems Manager はパッチベースライン ルールと承認済みおよび拒否済みパッチのリストを*各*マネージドノードで評価します。Systems Manager が各ノードでパッチ適用を評価する必要があるのは、マネージドノードに設定された複数のリポジトリから既知のパッチと更新のリストが取得されるためです。
**Server**
Windows のパッチ適用では、Systems Manager はパッチベースラインルールと承認済みおよび拒否済みパッチのリストを*サービス内で直接*評価します。これが可能なのは、Windows パッチが単一のリポジトリ (Windows Update) から取得されるためです。
## 違い 2: `Not Applicable` パッチ
Linux オペレーティングシステムには多数の使用可能なパッケージがあるため、Systems Manager では*該当なし*状態のパッチについて詳細をレポートしません。`Not Applicable` パッチとは、例えば、インスタンスに Apache がインストールされていない場合の Apache ソフトウェア用パッチなどです。Systems Manager は要約で多数の `Not Applicable` パッチをレポートしますが、マネージドノードで [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API を呼び出す場合、戻りデータには状態が `Not Applicable` のパッチは含まれません。この動作は、Windows とは異なります。
## 違い 3: SSM ドキュメントのサポート
`AWS-ApplyPatchBaseline` Systems Manager ドキュメント (SSM ドキュメント) では、Linux マネージドノードはサポートされていません。Linux、macOS、Windows Server マネージドノードにパッチベースラインを適用する上で推奨されている SSM ドキュメントは、`AWS-RunPatchBaseline` です。詳細については、「[マネージドノードへのパッチ適用のための SSM コマンドドキュメント](patch-manager-ssm-documents.md)」および「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。
## 違い 4: アプリケーションパッチ
Patch Managerの主な目的は、オペレーティングシステムにパッチを適用することです。ただし、Patch Managerを使用して、マネージドノードの一部のアプリケーションにパッチを適用することもできます。
**Linux**
Linux オペレーティングシステムでは、Patch Manager は更新のために設定されたリポジトリを使用し、オペレーティングシステムとアプリケーションのパッチを区別しません。Patch Managerを使用して、更新を取得するリポジトリを定義できます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。
**Server**
Windows Server マネージドノードでは、Microsoft Word 2016 や Microsoft Exchange Server 2016 など、Microsoft によってリリースされたアプリケーションに対して、*[Approved]* (承認済み)および *[Rejected]* (拒否された) パッチの例外を適用できます。詳細については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。
## 違い 5: カスタムパッチベースラインでの拒否されたパッチリストのオプション
カスタムパッチベースラインを作成するときは、**拒否されたパッチリスト**に 1 つ、または複数のパッチを指定できます。Linux マネージドノードでは、パッチがベースラインで許可されている別のパッチの依存関係である場合に、それらのインストールを許可することも選択できます。
ただし、Windows Server はパッチ依存関係の概念をサポートしません。Windows Server 向けのカスタムベースラインの **[拒否されたパッチ]** リストにパッチを追加することはできますが、その結果は (1) 拒否されたパッチがマネージドノードに既にインストールされているかどうか、および (2) **[拒否されたパッチアクション]** にどのオプションを選択するかに応じて異なります。
Windows Server での拒否されたパッチオプションの詳細については、以下の表を参照してください。
| インストールステータス | オプション:「依存関係として許可する」 | オプション: 「ブロック」 |
| --- | --- | --- |
| パッチが既にインストールされている | 報告されるステータス: INSTALLED\$1OTHER | 報告されるステータス: INSTALLED\$1REJECTED |
| パッチがまだインストールされていない | パッチがスキップされた | パッチがスキップされた |
通常、Microsoft がリリースする Windows Server 用の各パッチには、インストールが正常に行われるために必要なすべての情報が含まれています。ただし、手動でインストールする必要がある前提条件パッケージが必要になる場合もあります。Patch Manager は、これらの前提条件に関する情報を報告しません。関連情報については、Microsoft ウェブサイトで「[Windows Update の問題のトラブルシューティング](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)」を参照してください。