• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# パッチベースライン
このセクションのトピックでは、`Scan` または `Install` オペレーションをマネージドノードで実行した場合、AWS Systems Manager のツールである Patch Manager でパッチベースラインがどのように機能するのかについて説明します。
**Topics**
+ [
# 事前定義されたパッチベースラインおよびカスタムパッチベースライン
](patch-manager-predefined-and-custom-patch-baselines.md)
+ [
# 承認されたパッチと拒否されたパッチのリストのパッケージ名の形式
](patch-manager-approved-rejected-package-name-formats.md)
+ [
# パッチグループ
](patch-manager-patch-groups.md)
+ [
# Windows Server で Microsoft がリリースしたアプリケーションへのパッチ適用について
](patch-manager-patching-windows-applications.md)
# 事前定義されたパッチベースラインおよびカスタムパッチベースライン
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)」を参照してください。
# 承認されたパッチと拒否されたパッチのリストのパッケージ名の形式
承認されたパッチと拒否されたパッチのリストに追加できるパッケージ名の形式は、パッチするオペレーティングシステムにより異なります。
## Linux オペレーティングシステムのパッケージ名の形式
パッチベースラインで承認されたパッチと拒否されたパッチに指定できる形式は Linux タイプにより異なります。具体的には、サポートされている形式は、Linux オペレーティングシステムのタイプで使用されているパッケージマネージャーにより異なります。
**Topics**
+ [
### Amazon Linux 2、Amazon Linux 2023、Oracle Linux、および Red Hat Enterprise Linux (RHEL)
](#patch-manager-approved-rejected-package-name-formats-standard)
+ [
### Debian Server および Ubuntu Server
](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [
### SUSE Linux Enterprise Server (SLES)
](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2、Amazon Linux 2023、Oracle Linux、および Red Hat Enterprise Linux (RHEL)
**パッケージマネージャー**: YUM (パッケージマネージャーとして DNF を使用する Amazon Linux 2023 および RHEL 8 を除く)。
**承認されたパッチ**: 承認されたパッチでは、次のいずれかを指定できます。
+ `1234567` 形式の Bugzilla ID (システムは数字のみの文字列を Bugzilla ID として処理します)。
+ `CVE-2018-1234567` 形式の CVE ID
+ `RHSA-2017:0864` や `ALAS-2018-123` などの形式のアドバイザリ ID
+ パッケージ名の指定に使用可能なコンポーネントを 1 つ以上使用して作成されたパッケージ名。例として、`dbus.x86_64:1:1.12.28-1.amzn2023.0.1` という名前のパッケージでは、コンポーネントは以下のとおりです。
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
次の構造のパッケージ名がサポートされます。
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
例:
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ また、以下のように、上記の形式で 1 つのワイルドカードを含むパッケージ名コンポーネントもサポートされます。
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**拒否されたパッチ**: 拒否されたパッチでは、次のいずれかを指定できます。
+ パッケージ名の指定に使用可能なコンポーネントを 1 つ以上使用して作成されたパッケージ名。例として、`dbus.x86_64:1:1.12.28-1.amzn2023.0.1` という名前のパッケージでは、コンポーネントは以下のとおりです。
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
次の構造のパッケージ名がサポートされます。
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
例:
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ また、以下のように、上記の形式で 1 つのワイルドカードを含むパッケージ名コンポーネントもサポートされます。
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server および Ubuntu Server
**パッケージマネージャー**: APT
**承認されたパッチ**と**拒否されたパッチ**: 承認されたパッチと拒否されたパッチの両方で、以下を指定します。
+ `ExamplePkg33` 形式のパッケージ名
**注記**
Debian Server のリスト、および Ubuntu Server のリストでは、アーキテクチャやバージョンなどの要素は含めません。たとえば、パッケージ名 `ExamplePkg33` を指定し、パッチリストに次のすべてが含まれるようにします。
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**パッケージマネージャー**: Zypper
**承認されたパッチ**と**拒否されたパッチ**: 承認されたパッチリストと拒否されたパッチリストの両方で、以下のいずれかを指定します。
+ 以下のような形式の完全パッケージ名
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ 以下のような単一のワイルドカードのあるパッケージ名
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## macOS のパッケージ名の形式
**サポートされているパッケージマネージャー**: softwareupdate、installer、Brew、Brew Cask
**承認されたパッチ**と**拒否されたパッチ**: 承認されたパッチと拒否されたパッチリストの両方について、次のような形式で詳細なパッケージ名を指定します。
+ `XProtectPlistConfigData`
+ `MRTConfigData`
macOS の承認済みおよび拒否されたパッチリストでは、ワイルドカードはサポートされません。
## Windows オペレーティングシステムのパッケージ名の形式
Windows オペレーティングシステムでは、Microsoft Knowledge Base ID と Microsoft Security Bulletin ID を使用して、以下の例のようにパッチを指定します。
```
KB2032276,KB2124261,MS10-048
```
# パッチグループ
**注記**
パッチグループは、パッチポリシーに基づくパッチ適用オペレーションでは使用されません。パッチポリシーの使用については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。
2022 年 12 月 22 日にパッチポリシーのサポートがリリースされる前にパッチグループを使用していなかったアカウントとリージョンのペアでは、コンソールでパッチグループの機能がサポートされていません。パッチグループの機能は、この日付より前にパッチグループの使用を開始したアカウントとリージョンのペアで引き続き使用できます。
*パッチグループ*を使用して、AWS Systems Manager のツールである Patch Manager でマネージドノードを特定のパッチベースラインに関連付けることができます。パッチグループは、正しい一連のノードに、関連するパッチベースラインのルールに基づいて、適切なパッチをデプロイしていることを確認するのに役立ちます。パッチグループを使用すると、適切なテストの完了前にパッチがデプロイされることも回避できます。たとえば、環境別 (開発、テスト、実稼働など) にパッチグループを作成して、適切なパッチベースラインに各パッチグループを登録できます。
パッチ適用のために `AWS-RunPatchBaseline` またはその他の SSM コマンドドキュメントを実行する場合は、ノード ID やタグを使用して、マネージドノードをターゲットにすることができます。SSM Agent と Patch Manager は、マネージドノードに追加したパッチグループの値に基づいて、使用するパッチベースラインを評価します。
## タグを使用してパッチグループを定義する
[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと非 EC2 ノードに適用されたタグを使用して、パッチグループを作成します。パッチグループのタグの使用に関する以下の詳細に注意してください。
+
パッチグループは、マネージドノードに適用されたタグキー `Patch Group` または `PatchGroup` のいずれかを使用して定義する必要があります。パッチベースラインのパッチグループを登録する場合、これら 2 つのキーに指定された同一の*値*は、同じグループの一部であると解釈されます。例えば、次のキーと値のペアの 1 つ目で 5 つのノードにタグ付けし、2 つ目で 5 つのノードにタグ付けしたとします。
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
ベースラインを作成する Patch Manager コマンドは、これらの 10 個のマネージドノードを、値 `DEV` に基づいて 1 つのグループに結合します。AWS CLI でパッチグループのパッチベースラインを作成するコマンドは次のとおりです。
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
異なるキーの値を 1 つのターゲットに結合することは、新しいパッチグループを作成するこの Patch Manager コマンドに固有であり、他の API アクションではサポートされていません。例えば、同じ値を持つ `PatchGroup` キーと `Patch Group` キーを使用して [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) アクションを実行する場合、2 つのまったく異なるノードセットをターゲットにしています。
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ タグベースのターゲティングには制限があります。`SendCommand` のターゲットの各配列には、最大 5 つのキーと値のペアを含めることができます。
+ これらのタグキー規則は、`PatchGroup` (スペースなし) または `Patch Group` (スペースあり) のいずれか 1 つだけ選択することをお勧めします。ただし、インスタンス上の [EC2 インスタンスメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、`PatchGroup` を使用する必要があります。
+ キーでは大文字と小文字が区別されます。グループのリソースを特定し対象としやすくするために任意の*値* (「Web サーバー」や「US-EAST-PROD」など) を指定できますが、キーは `Patch Group` または `PatchGroup` でなければなりません。
パッチグループを作成してマネージドノードにタグを付けたら、パッチグループをパッチベースラインに登録できます。パッチグループをパッチベースラインに登録することで、パッチグループ内のノードは、関連付けられたパッチベースラインで定義されているルールを使用します。
パッチグループを作成する方法とパッチグループをパッチベースラインに関連付ける方法の詳細については、「[パッチグループの作成と管理](patch-manager-tag-a-patch-group.md)」および「[パッチグループをパッチベースラインに追加する](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline)」を参照してください。
AWS Command Line Interface (AWS CLI)を使用したパッチベースラインとパッチグループの作成例については、「[チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する](patch-manager-patch-servers-using-the-aws-cli.md)」を参照してください。Amazon EC2 タグの詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。
## 使用方法
システムでタスクを実行してマネージドノードにパッチベースラインを適用するときに、SSM Agent はそのノードにパッチグループの値が定義されているかどうかを確認します。ノードがパッチグループに割り当てられている場合、Patch Manager はそのパッチグループにどのパッチベースラインが登録されているかを確認します。そのグループにパッチベースラインがある場合、Patch Manager は関連付けられているパッチベースラインを使用するように SSM Agent に通知します。ノードにパッチグループが設定されていない場合、Patch Manager は現在設定されているデフォルトのパッチベースラインを使用するように SSM Agent に自動的に通知します。
**重要**
マネージドノードは 1 つのパッチグループのみ所属できます。
パッチグループは、オペレーティングシステムタイプごとに 1 つのパッチベースラインのみに登録できます。
インスタンスで **[Allow tags in instance metadata]** (インスタンスメタデータ内のタグを許可する) オプションを有効にした場合は、Amazon EC2 インスタンスに `Patch Group` タグ (スペースなし) を適用することはできません。インスタンスメタデータでタグを許可すると、タグキー名にスペースが含まれなくなります。[EC2 インスタンスのメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、スペースなしでタグキー `PatchGroup` を使用する必要があります。
**図 1: パッチ適用オペレーションのプロセスの流れの一般的な例**
次の図は、Run Command タスクをサーバーのフリートに送信し、Patch Manager を使用してパッチを適用する場合に、Systems Manager が実行するプロセスの一般的な例を示しています。これらのプロセスは、パッチ適用オペレーションで使用するパッチベースラインを決定します。(コマンドを送信して Patch Manager を使用してパッチを適用するようにメンテナンスウィンドウを設定した場合にも、同様のプロセスが使用されます。)
完全なプロセスについては、以下の図で説明します。
![\[パッチ適用オペレーションの実行時に使用するパッチベースラインを決定するための Patch Manager ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
この例では、次のタグが適用される、Windows Server 用の 3 つの EC2 インスタンスのグループがあります。
****
| EC2 インスタンスグループ | タグ |
| --- | --- |
| グループ 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| グループ 2 | `key=OS,value=Windows` |
| グループ 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
この例では、これら 2 つの Windows Server パッチベースラインも用意されています。
****
| パッチベースライン ID | デフォルト | 関連するパッチグループ |
| --- | --- | --- |
| `pb-0123456789abcdef0` | はい | `Default` |
| `pb-9876543210abcdef0` | いいえ | `DEV` |
AWS Systems Manager のツールである Run Command、および Patch Manager を使用して、パッチのスキャンまたはインストールを行う場合の一般的な手順は以下のとおりです。
1. **パッチにコマンドを送信する**: ドキュメント `AWS-RunPatchBaseline` を使用して Run Command タスクを送信するには、Systems Manager コンソール、SDK、AWS Command Line Interface (AWS CLI)、または AWS Tools for Windows PowerShell を使用します。`key=OS,value=Windows` タグをターゲットにして、マネージドインスタンスにパッチを適用する Run Command タスクを図に示します。
1. **パッチベースラインの確認**: SSM Agentは、EC2 インスタンスに適用されているパッチグループタグを確認し、対応するパッチベースラインを Patch Manager に問い合わせます。
+ **パッチベースラインに関連付けられている一致するパッチグループの値: **
1. グループ 1 の EC2 インスタンスにインストールされている SSM Agent は、ステップ 1 で発行されたコマンドを受け取ってパッチ適用オペレーションを開始します。SSM Agentは、EC2 インスタンスのパッチグループタグの値に `DEV` が適用されていることを確認し、関連付けられているパッチベースラインをPatch Managerに問い合わせます。
1. Patch Managerは、パッチベースラインの `pb-9876543210abcdef0` がパッチグループの `DEV` に関連付けられていることを確認し、SSM Agentに通知します。
1. SSM Agent は、`pb-9876543210abcdef0` で設定されている承認ルールと例外に基づいてPatch Managerからパッチベースラインのスナップショットを取得して、次のステップに進みます。
+ **インスタンスに追加されたパッチグループタグはありません。**
1. グループ 2 の EC2 インスタンスにインストールされている SSM Agent は、ステップ 1 で発行されたコマンドを受け取ってパッチ適用オペレーションを開始します。SSM Agent は、EC2 インスタンスに `Patch Group` または `PatchGroup` タグが適用されていないことを確認します。そのため、SSM Agent はデフォルトの Windows のパッチベースラインを Patch Manager に問い合わせます。
1. Patch Managerは、デフォルトの Windows Server のパッチベースラインが `pb-0123456789abcdef0` であることを確認し、SSM Agentに通知します。
1. SSM Agent は、デフォルトのパッチベースラインの `pb-0123456789abcdef0` で設定されている承認ルールと例外に基づいてPatch Managerからパッチベースラインのスナップショットを取得して、次のステップに進みます。
+ **パッチベースラインに一致するパッチグループの値が関連付けられていません。**
1. グループ 3 の EC2 インスタンスにインストールされている SSM Agentは、ステップ 1 で発行されたコマンドを受け取ってパッチ適用オペレーションを開始します。SSM Agentは、EC2 インスタンスのパッチグループタグの値に `QA` が適用されていることを確認し、関連付けられているパッチベースラインをPatch Managerに問い合わせます。
1. Patch Manager は、パッチグループの `QA` に関連付けられているパッチベースラインを見つけられません。
1. Patch Managerは、デフォルトの Windows のパッチベースラインの `pb-0123456789abcdef0` を使用するように SSM Agentに通知します。
1. SSM Agent は、デフォルトのパッチベースラインの `pb-0123456789abcdef0` で設定されている承認ルールと例外に基づいてPatch Managerからパッチベースラインのスナップショットを取得して、次のステップに進みます。
1. **パッチのスキャンまたはインストール**。使用する適切なパッチベースラインを決定したら、SSM Agent は、ステップ 1 で指定されたオペレーションの値に基づいてスキャンまたはインストールのいずれかを開始します。スキャンまたはインストールするパッチは、Patch Managerによって提供されるパッチベースラインのスナップショットで定義されている承認ルールとパッチの例外に基づいて決定されます。
**詳細情報**
+ [パッチコンプライアンス状態の値](patch-manager-compliance-states.md)
# Windows Server で Microsoft がリリースしたアプリケーションへのパッチ適用について
このトピックの情報は、AWS Systems Manager のツールである Patch Manager を使用して Windows Server のアプリケーションにパッチを適用する準備を行う場合に役立ちます。
**Microsoft アプリケーションのパッチ適用**
Windows Server マネージドノードのアプリケーションのパッチ適用のサポートは、Microsoft がリリースしたアプリケーションに限定されます。
**注記**
Microsoft がリリースするアプリケーションのパッチは、更新日時を指定していない場合があります。このような場合、デフォルトでは `01/01/1970` の更新日時が指定されています。
**Microsoft がリリースしたパッチ適用アプリケーションのパッチベースライン**
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 マシンの Microsoft リリースのアプリケーションを更新するカスタムパッチベースラインを作成することもできます。
**オンプレミスサーバー、エッジデバイス、VM、その他の EC2 以外のノードでの Microsoft がリリースしたアプリケーションへのパッチ適用のサポート**
仮想マシン (VM) およびその他の EC2 以外のマネージドノードで Microsoft がリリースしたアプリケーションにパッチを適用するには、アドバンストインスタンス層を有効にする必要があります。アドバンストインスタンス層の使用には料金が発生します。**ただし、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで Microsoft がリリースしたアプリケーションにパッチを適用する場合、追加料金はかかりません。**詳細については、「[インスタンス層の設定](fleet-manager-configure-instance-tiers.md)」を参照してください。
**「他の Microsoft 製品」の Windows 更新オプション**
Patch Manager が Windows Server マネージドノードで Microsoft リリースのアプリケーションにパッチを適用できるようにするには マネージドノードで Windows Update オプションの **[Give me updates for other Microsoft products when I update Windows]** (Windows を更新するときに他の Microsoft 製品の更新を提供する) が有効になっている必要があります。
単一マネージドノードでこのオプションを有効にする方法の詳細については、Microsoft Support ウェブサイトの [｢Update Office with Microsoft Update｣](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) をご参照ください。
Windows Server 2016 以降を実行しているマネージドノードのフリートでは、グループ ポリシーオブジェクト (GPO) を使用して設定を有効にできます。グループポリシー管理エディターで、[**Computer Configuration**] (コンピューターの構成)、[**Administrative Templates**] (管理用テンプレート)、[**Windows Components**] (Windows コンポーネント)、[**Windows Updates**] (Windows の更新プログラム) にアクセスして、[**Install updates for other Microsoft products**] (他の Microsoft 製品の更新プログラムのインストール) を選択します。また、予定外の自動更新や Patch Manager 外部での再起動を防止する追加のパラメーターを使用して GPO を構成することをお勧めします。詳細については、Microsoft の技術文書ウェブサイトで公開されている「[Configuring Automatic Updates in a Non-Active Directory Environment](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499)」（非 Active Directory 環境での自動更新の構成）を参照してください。
Windows Server 2012 または 2012 R2 を実行しているマネージドノードのフリートの場合、スクリプトを使用してオプションを有効にできます。詳細については、Microsoft ドキュメント ブログのウェブサイトの「[Enabling and Disabling Microsoft Update in Windows 7 via Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script)」を参照してください。例えば、次の操作を実行できます。
1. ブログ投稿のスクリプトをファイルに保存します。
1. ファイルを Amazon Simple Storage Service (Amazon S3) バケットまたはその他のアクセス可能な場所にアップロードします。
1. AWS Systems Manager のツールである Run Command を使用して、次のようなコマンドを実行して、Systems Manager ドキュメント (SSM ドキュメント) `AWS-RunPowerShellScript` を使ってマネージドノードでスクリプトを実行します。
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**パラメータの最小要件**
カスタムパッチベースラインに Microsoft がリリースしたアプリケーションを含めるには、少なくとも、パッチを適用する製品を指定する必要があります。次の AWS Command Line Interface ( AWS CLI )コマンドは、Microsoft Office 2016 などの製品にパッチを適用する最小限の要件を示します。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows サーバー ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
Microsoft アプリケーション製品ファミリーを指定した場合、指定する各製品は、選択した製品ファミリーのサポートされたメンバーである必要があります。たとえば、「Active Directory Rights Management Services Client 2.0」という製品にパッチを適用する場合、「Office」や「SQL Server」などではなく、「Active Directory」を製品ファミリーに指定する必要があります。次の AWS CLI コマンドは、製品ファミリーと製品の一致したペアを示します。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows サーバー ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**注記**
商品とファミリーのペアリングのミスマッチに関するエラーメッセージが表示される場合は、「[問題:製品ファミリ/製品ペアの不一致](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)」を参照すると問題解決に役立ちます。