• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# 事前定義されたパッチベースラインおよびカスタムパッチベースライン
AWS Systems Manager のツールである Patch Manager には、Patch Manager のサポート対象のオペレーティングシステムごとに定義済みのパッチベースラインがあります。これらのベースラインは、現在設定されているとおりに使用することも (カスタマイズすることはできません)、独自のカスタムパッチベースラインを作成することもできます。カスタムパッチベースラインを使用すると、環境に対してどのパッチを承認または拒否するかをより詳細に制御できます。また、定義済みのベースラインでは、これらのベースラインを使用してインストールされるすべてのパッチに、コンプライアンスレベル `Unspecified` が割り当てられます。コンプライアンス値を割り当てるには、定義済みのベースラインのコピーを作成し、パッチに割り当てるコンプライアンス値を指定できます。詳細については、「[カスタムベースライン](#patch-manager-baselines-custom)」および「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。
**注記**
このトピックの情報は、パッチ適用オペレーションに使用している設定方法やタイプに関係なく適用されます。
Quick Setup で設定されているパッチポリシー
Quick Setup で設定されているホスト管理オプション
パッチ `Scan` または `Install` のタスクを実行するためのメンテナンスウィンドウ
オンデマンドの **[今すぐパッチ適用]** オペレーション
**Topics**
+ [事前定義されたベースライン](#patch-manager-baselines-pre-defined)
+ [カスタムベースライン](#patch-manager-baselines-custom)
## 事前定義されたベースライン
次の表に、Patch Manager に用意されている事前定義されたパッチベースラインを示します。
Patch Manager でサポートされている各オペレーティングシステムのバージョンについては、「[Patch Manager の前提条件](patch-manager-prerequisites.md)」を参照してください。
****
| 名前 | サポートされるオペレーティングシステム | 詳細 |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | 分類が「セキュリティ」で、重要度レベルが「非常事態」または「重要」のすべてのオペレーティングシステムパッチを承認します。また、分類が「Bugfix」(バグ修正) のすべてのパッチを承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | 分類が「セキュリティ」で、重要度レベルが「非常事態」または「重要」のすべてのオペレーティングシステムパッチを承認します。また、分類が「Bugfix」(バグ修正) のすべてのパッチを承認します。パッチはリリースから 7 日後に自動承認されます。¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | 分類が「セキュリティ」で、重要度レベルが「非常事態」または「重要」のすべてのオペレーティングシステムパッチを承認します。パッチはリリースから 7 日後に自動承認されます。また、分類が "Bugfix" のすべてのパッチをリリースから 7 日後に承認します。 |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | すべての更新は、更新 (セキュリティ以外の更新を含む) が使用可能になってから 7 日後に承認されます。 |
| AWS-DebianDefaultPatchBaseline | Debian Server | 優先度が「Required」、「Important」、「Standard」、「Optional」、「Extra」のすべてのオペレーティングシステムのセキュリティに関連するパッチを即時に承認します。リポジトリに信頼できるリリース日がないため、承認前の待機期間はありません。 |
| AWS-MacOSDefaultPatchBaseline | macOS | 「セキュリティ」に分類されるすべてのオペレーティングシステムパッチを承認します。また、現在の更新を含むすべてのパッケージを承認します。 |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | 分類が「セキュリティ」で、重要度レベルが「重要」または「中」のすべてのオペレーティングシステムパッチを承認します。また、分類が「Bugfix」(バグ修正) のすべてのパッチをリリースから 7 日後に承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | 分類が「セキュリティ」で、重要度レベルが「非常事態」または「重要」のすべてのオペレーティングシステムパッチを承認します。また、分類が「Bugfix」(バグ修正) のすべてのパッチを承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | 分類が「セキュリティ」で、重要度レベルが「非常事態」または「重要」のすべてのオペレーティングシステムパッチを承認します。また、分類が「Bugfix」(バグ修正) のすべてのパッチを承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | 分類が「セキュリティ」で、重要度が「非常事態」または「重要度」のすべてのオペレーティングシステムパッチを承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | 優先度が「Required」、「Important」、「Standard」、「Optional」、「Extra」のすべてのオペレーティングシステムのセキュリティに関連するパッチを即時に承認します。リポジトリに信頼できるリリース日がないため、承認前の待機期間はありません。 |
| AWS-DefaultPatchBaseline | Windows Server | 分類が「CriticalUpdates」または「SecurityUpdates」で、MSRC 重要度が「非常事態」または「重要」のすべての Windows Server オペレーティングシステムパッチを承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | 分類が「CriticalUpdates」または「SecurityUpdates」で、MSRC 重要度が「非常事態」または「重要」のすべての Windows Server オペレーティングシステムパッチを承認します。パッチは、リリースまたは更新されてから 7 日後に自動承認されます。² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Windows Server オペレーティングシステムの場合は、分類が「CriticalUpdates」または「SecurityUpdates」で、MSRC 重要度が「非常事態」または「重要」のすべてのパッチを承認します。Microsoft がリリースしたアプリケーションについては、すべてのパッチを承認します。OS とアプリケーションのパッチのどちらも、リリースまたは更新から 7 日後に自動承認されます。² |
¹ Amazon Linux 2 の場合、パッチが自動承認されるまでの 7 日間の待機時間は、`Release Date` 値ではなく、`updateinfo.xml` の `Updated Date` 値から計算されます。さまざまな要因が `Updated Date` 値に影響を与える可能性があります。他のオペレーティングシステムでは、リリース日と更新日の処理が異なります。自動承認の遅延による予期しない結果を避けるのに役立つ情報については、「[パッケージのリリース日と更新日の計算方法](patch-manager-release-dates.md)」を参照してください。
² Windows Server の場合、デフォルトのベースラインには 7 日間の自動承認遅延が含まれています。リリース後 7 日以内にパッチをインストールするには、カスタムベースラインを作成する必要があります。
## カスタムベースライン
次の情報は、パッチ適用目標を達成するためのカスタムパッチベースラインの作成に役立ちます。
**Topics**
+ [カスタムベースラインでの自動承認の使用](#baselines-auto-approvals)
+ [パッチベースラインを作成するための追加情報](#baseline-additional-info)
### カスタムベースラインでの自動承認の使用
独自のパッチベースラインを作成する場合は、以下のカテゴリを使用して自動承認するパッチを選択できます。
+ **オペレーティングシステム**: Windows Server、Amazon Linux、Ubuntu Server などのサポートされているバージョン。
+ **製品名 **(オペレーティングシステム): 例えば、RHEL 7.5、Amazon Linux 2023 2023.8.20250808、Windows Server 2012、Windows Server 2012 R2 など。
+ **製品名 **(Windows Server で Microsoft がリリースしたアプリケーションのみ): 例えば、Word 2016、BizTalk Server など。
+ **分類**: 例えば、緊急更新プログラム、セキュリティ更新プログラムなど。
+ **重大度**: 例えば、緊急、重要など。
作成する承認ルールごとに、自動承認の遅延を指定するか、パッチ承認の期限日を指定するかを選択できます。
**注記**
Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペティングシステムでは自動承認オプションがサポートされていません。
自動承認の遅延とは、パッチがリリースまたは最後に更新されてから自動承認されて適用されるまでの待機日数です。例えば、`CriticalUpdates` 分類を使用してルールを作成し、自動承認の遅延として 7 日間を設定した場合、7 月 7 日にリリースされた新しい重要なパッチは 7 月 14 日に自動的に承認されます。
Linux リポジトリがパッケージのリリース日情報を提供しない場合、Patch Manager はパッケージのビルド時間を Amazon Linux 2、Amazon Linux 2023、および Red Hat Enterprise Linux (RHEL) の自動承認日指定の日付として使用します。パッケージのビルド時間が特定できない場合、Patch Manager はデフォルトの日付である 1970 年 1 月 1 日を使用します。これにより、Patch Manager は 1970 年 1 月 1 日以降の任意の日付のパッチを承認するように設定されたパッチベースラインの自動承認日指定をバイパスします。
自動承認の期限日を指定すると、Patch Manager はその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用します。例えば、期限日として 2023 年 7 月 7 日を指定すると、2023 年 7 月 8 日以降にリリースまたは最終更新されたパッチは自動的にインストールされません。
カスタムのパッチベースラインを作成する場合、そのパッチベースラインによって承認されたパッチのコンプライアンスの重要度レベル (`Critical` または `High` など) を指定できます。承認された任意のパッチのパッチ状態が `Missing` と報告された場合、パッチベースラインで報告される全体的なコンプライアンスの重要度は、指定した重要度レベルになります。
### パッチベースラインを作成するための追加情報
パッチベースラインを作成する場合は、以下の点に注意してください。
+ Patch Manager には、サポートされているオペレーティングシステムごとに 1 つの事前定義されたパッチベースラインがあります。対応するオペレーティングシステムの種類ごとに、独自のパッチベースラインを作成して、デフォルトとして指定してする場合を除き、これらの事前定義されたパッチベースラインが、オペレーティングシステムの種類ごとの、デフォルトのパッチベースラインとして使用されます。
**注記**
Windows Server では、3 つの事前に定義されたパッチベースラインが提供されます。パッチベースラインの `AWS-DefaultPatchBaseline` と `AWS-WindowsPredefinedPatchBaseline-OS` は、Windows オペレーティングシステム自体のオペレーティングシステム更新プログラムのみをサポートしています。`AWS-DefaultPatchBaseline` は、別のパッチベースラインを指定しない限り、Windows Server マネージドノードのデフォルトのパッチベースラインとして使用されます。これら 2 つのパッチベースラインの構成設定は同じです。2 つのうち新しい方である `AWS-WindowsPredefinedPatchBaseline-OS` は、Windows Server 用の 3 つ目の事前定義されたパッチベースラインと区別するために作成されました。そのパッチベースライン `AWS-WindowsPredefinedPatchBaseline-OS-Applications` を使用して、Windows Server オペレーティングシステムおよびサポートされている Microsoft アプリケーションの両方にパッチを適用できます。
+ デフォルトで、Windows Server 2019 および Windows Server 2022 は後続の更新に置き換えられた更新を削除します。その結果、Windows Server パッチベースラインで `ApproveUntilDate` パラメータを使用しても、`ApproveUntilDate` パラメータで選択された日付が最新パッチの日付よりも前になっている場合は、パッチ適用オペレーションの実行時に新しいパッチがインストールされません。Windows Server パッチ適用ルールの詳細については、「[セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md)」の [Windows Server] タブを参照してください。
これは、前月の緊急パッチがインストールされていない可能性がある場合でも、Systems Manager オペレーションに関してはマネージドノードが準拠状態にあることを意味します。`ApproveAfterDays` パラメータの使用時にも同じシナリオが発生する可能性があります。Microsoft の置き換えられたパッチ動作のため、`ApproveAfterDays` の日数が経過する前に Microsoft からの最新のパッチがリリースされた場合でも Windows Server 向けのパッチがインストールされないように、日数を設定することが可能です (通常は 30 日を超える日数)。
+ Windows Server の場合のみ、パッチベースラインで承認されていない使用可能なセキュリティ更新パッチは、カスタムパッチベースラインでの定義に従い、コンプライアンス値 (`Compliant` または `Non-Compliant`) を持つことができます。
パッチベースラインを作成または更新するときに、パッチベースラインで指定されたインストール基準を満たしていないため、使用可能ではあるものの承認されていないセキュリティパッチに割り当てるステータスを選択します。例えば、パッチがリリースされてからインストールされるまでに待機する期間を長く指定している場合は、インストールするセキュリティパッチをスキップできます。指定した待機期間中にパッチの更新がリリースされると、パッチのインストールの待機期間がもう一度開始されます。待機期間が長すぎる場合、複数のバージョンのパッチがリリースされ、インストールされない可能性があります。
コンソールを使用してパッチベースラインを作成または更新するには、**[使用可能なセキュリティ更新のコンプライアンスステータス]** フィールドでこのオプションを指定します。AWS CLI を使用して [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) または [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) コマンドを実行し、`available-security-updates-compliance-status` パラメータでこのオプションを指定します。
+ オンプレミスのサーバーおよび仮想マシン (VM) の場合、Patch Manager では独自にデフォルトとして指定したパッチベースラインが使用されます。独自のデフォルトパッチベースラインがない場合は、事前定義済みのパッチベースラインが対応するオペレーティングシステムに使用されます。
+ 同じパッチベースラインで承認および拒否の両方の対象に指定されているパッチがある場合、そのパッチは拒否されます。
+ 1 つのマネージドノードに定義できるパッチベースラインは 1 つに限ります。
+ パッチベースラインの承認されたパッチと拒否されたパッチのリストに追加できるパッケージ名の形式は、パッチするオペレーティングシステムにより異なります。
承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。
+ Quick Setup で[パッチポリシー設定](patch-manager-policies.md)を使用している場合、カスタムパッチベースラインに加えた更新は 1 時間に 1 回 Quick Setup と同期されます。
パッチポリシーで参照されていたカスタムパッチベースラインを削除すると、Quick Setup のそのパッチポリシーについての **[Configuration details]** (設定の詳細) ページにバナーが表示されます。バナーには、パッチポリシーが既に存在しないパッチベースラインを参照していること、およびそれ以降のパッチ適用オペレーションができないことが示されます。この場合は、Quick Setup の **[Configurations]** (設定) ページに戻り、Patch Manager 設定を選択し、**[Actions]** (アクション)、**[Edit configuration]** (設定を編集) を選択します。削除されたパッチベースライン名が強調表示されます。影響を受けるオペレーティングシステム用の新しいパッチベースラインを選択する必要があります。
+ 複数の `Classification` および `Severity` 値を使用して承認ルールを作成すると、パッチは使用可能な属性に基づいて承認されます。`Classification` と `Severity` の両方の属性を持つパッケージは、両方のフィールドで選択されたベースライン値と照合されます。`Classification` 属性のみを持つパッケージは、選択したベースラインの `Classification` 値に対してのみ照合されます。`Severity` 属性を持たないパッケージでは、同じルールの重要度要件は無視されます。
パッチベースラインの作成については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」および「[チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する](patch-manager-patch-servers-using-the-aws-cli.md)」を参照してください。