• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# マネージドノードへのパッチ適用のための SSM コマンドドキュメント
このトピックでは、マネージドノードが最新のセキュリティアップデートでパッチが適用された状態に維持できるように公開されている 9 種類の Systems Manager ドキュメント (SSM ドキュメント) をご紹介します。
パッチ適用オペレーションで使用が推奨されているのは、これらのうち 5 種類のドキュメントのみです。これらの 5 つの SSM ドキュメントには、 を使用したパッチ適用オプションの詳細が記載されていますAWS Systems Manager これらのうち、4 つのドキュメントは、それらが置き換えられた 4 つのレガシー SSM ドキュメントよりも後にリリースされ、機能の拡張または統合を表しています。
**パッチ適用に推奨されている SSM ドキュメント**
パッチ適用オペレーションには、以下の 5 種類の SSM ドキュメントの使用をお勧めします。
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**パッチ適用のレガシー SSM ドキュメント**
次の 4 つのレガシー SSM ドキュメントは、一部の AWS リージョン で引き続き使用可能ですが、更新またはサポートはされません。これらのドキュメントは IPv6 環境で動作することは保証されず、IPv4 のみをサポートします。すべてのシナリオで動作することは保証されず、将来サポートを失う可能性があります。パッチ適用オペレーションにこれらのドキュメントは使用しないことをお勧めします。
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
IPv6 のみをサポートする環境でパッチ適用オペレーションを設定する手順については、「[チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md)」を参照してください。
パッチ適用オペレーションでこれらの SSM ドキュメントを使用する方法の詳細については、次のセクションを参照してください。
**Topics**
+ [マネージドノードへのパッチ適用に推奨されている SSM ドキュメント](#patch-manager-ssm-documents-recommended)
+ [マネージドノードへのパッチ適用のためのレガシー SSM ドキュメント](#patch-manager-ssm-documents-legacy)
+ [マネージドノードにパッチを適用するための SSM ドキュメントにおける既知の制限](#patch-manager-ssm-documents-known-limitations)
+ [パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` で InstallOverrideList パラメータを使用するサンプルシナリオ](patch-manager-override-lists.md)
+ [BaselineOverride パラメータの使用](patch-manager-baselineoverride-parameter.md)
## マネージドノードへのパッチ適用に推奨されている SSM ドキュメント
マネージドノードのパッチ適用オペレーションで使用が推奨されている SSM ドキュメントは、次の 5 つです。
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
Windows Update の基本機能の設定、その機能を使用した更新の自動インストール (または自動更新の無効化) をサポートします。すべての AWS リージョン で利用可能。
この SSM ドキュメントを使用すると、Windows Update において、指定の更新をダウンロードおよびインストールし、必要に応じてマネージドノードを再起動するよう求められます。この文書は、Windows Update がその設定を維持できるようにするために、AWS Systems Manager のツールである State Manager と一緒に使用してください。AWS Systems Manager のツールである Run Command を使用して手動で実行し、Windows Update 設定を変更することもできます。
このドキュメントで利用可能なパラメータを使用することで、インストールする更新のカテゴリ (または自動更新を無効にするかどうか) だけでなく、パッチ適用オペレーションを実行する日時と曜日を指定することができます。この SSM ドキュメントは、Windows updates で厳重に管理する必要なく、コンプライアンス情報を収集する必要がない場合に非常に便利です。
**レガシーの SSM ドキュメントを置き換える:**
+ *[なし]*
### `AWS-InstallWindowsUpdates`
Windows Server マネージドノードに更新ファイルをインストールします。すべての AWS リージョン で利用できます。
この SSM ドキュメントには、特定の更新をインストール (`Include Kbs` パラメータを使用) するか、特定の分類やカテゴリのパッチをインストールするが、パッチのコンプライアンス情報が不要な場合の基本パッチ適用機能について記載されています。
**レガシーの SSM ドキュメントを置き換える:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
3 つのレガシードキュメントを使用してさまざまな機能を実行することができますが、新しい SSM ドキュメント (`AWS-InstallWindowsUpdates`) で別のパラメータ設定を使用して、同様の結果を得ることができます。これらのパラメータ設定については、「[マネージドノードへのパッチ適用のためのレガシー SSM ドキュメント](#patch-manager-ssm-documents-legacy)」を参照してください。
### `AWS-RunPatchBaseline`
必要なパッチが適用されているかどうかを確認するには、マネージドノードにパッチをインストールするか、ノードをスキャンします。すべての AWS リージョン で利用できます。
`AWS-RunPatchBaseline` を使用すると、オペレーティングシステムタイプの「デフォルト」として指定されているパッチベースラインを使用して、パッチの承認を制御できます。Systems Manager Compliance ツールを使用して表示できるパッチコンプライアンス情報をレポートします。これらのツールでは、必要なパッチが適用されていないノードや、そのパッチの内容など、マネージドノードのパッチコンプライアンス状態に関する洞察を得ることができます。`AWS-RunPatchBaseline` を使用すると、`PutInventory` API コマンドを使用してパッチコンプライアンス情報が記録されます。Linux オペレーティングシステムの場合、マネージドノードに設定されたデフォルトのソースリポジトリと、カスタムのパッチベースラインで指定した代替のソースリポジトリの両方から、パッチに関するコンプライアンス情報が提供されます。代替ソースリポジトリの詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。Systems Manager Compliance ツールの詳細については、「[AWS Systems Manager のコンプライアンス](systems-manager-compliance.md)」を参照してください。
**レガシードキュメントを置き換える:**
+ `AWS-ApplyPatchBaseline`
レガシー ドキュメント `AWS-ApplyPatchBaseline` は、Windows Server マネージドノードにのみ適用され、アプリケーションのパッチ適用をサポートしません。新しい `AWS-RunPatchBaseline` バージョンでは、Windows システムと Linux システムの両方で同じサポートが提供されます。 `AWS-RunPatchBaseline`ドキュメントを使用するには、バージョン 2.0.834.0 以降の SSM Agent が必要です。
`AWS-RunPatchBaseline` SSM ドキュメントの詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。
### `AWS-RunPatchBaselineAssociation`
必要なパッチが適用されているかどうかを確認するには、インスタンスにパッチをインストールするか、インスタンスをスキャンします。すべての商用 AWS リージョン で使用できます。
`AWS-RunPatchBaselineAssociation` はいくつかの重要な点で `AWS-RunPatchBaseline` とは異なります。
+ `AWS-RunPatchBaselineAssociation` は、主に AWS Systems Manager のツールである Quick Setup を使用して作成された State Manager 関連付けでの使用を目的としています。具体的には、Quick Setup ホスト管理設定タイプを使用する場合、**[Scan instances for missing patches daily]** (不足しているパッチがないか毎日インスタンスをスキャンする) オプションを選択すると、システムはオペレーションに `AWS-RunPatchBaselineAssociation` を使用します。
ただし、ほとんどの場合、独自のパッチ適用オペレーションを設定する場合は、`AWS-RunPatchBaseline` の代わりに、[`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaseline.md) または [`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselinewithhooks.md) を選択する必要があります。
詳細については、以下のトピックを参照してください。
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` は、実行時にターゲットのセットで使用するパッチベースラインを識別するためのタグの使用をサポートしています。
+ `AWS-RunPatchBaselineAssociation` を使用するパッチ適用オペレーションの場合、パッチコンプライアンスデータは特定の State Manager の関連付けに基づいてコンパイルされます。`AWS-RunPatchBaselineAssociation` 実行時に収集されたパッチコンプライアンスデータは、`PutComplianceItems` コマンドではなく、`PutInventory` API コマンドを使用して記録されます。これにより、この特定の関連付けに関連付けられていないコンプライアンスデータが上書きされるのを防ぐことができます。
Linux オペレーティングシステムの場合、インスタンスに設定されたデフォルトのソースリポジトリと、カスタムのパッチベースラインで指定した代替のソースリポジトリの両方から、パッチに関するコンプライアンス情報が提供されます。代替ソースリポジトリの詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。Systems Manager Compliance ツールの詳細については、「[AWS Systems Manager のコンプライアンス](systems-manager-compliance.md)」を参照してください。
**レガシードキュメントを置き換える:**
+ **[なし]**
`AWS-RunPatchBaselineAssociation` SSM ドキュメントの詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)」を参照してください。
### `AWS-RunPatchBaselineWithHooks`
マネージドノードにパッチをインストールするか、ノードをスキャンして、修飾されたパッチが欠けているかどうかを判断します。オプションのフックを使用すると、パッチ適用サイクル中の 3 つのポイントで SSM ドキュメントを実行できます。すべての商用 AWS リージョン で使用できます。macOS ではサポートされていません。
`AWS-RunPatchBaselineWithHooks` は その `AWS-RunPatchBaseline` オペレーションで `Install` とは異なります。
`AWS-RunPatchBaselineWithHooks` では、マネージドノードノードのパッチ適用中に指定されたポイントで実行されるライフサイクルフックがサポートされます。パッチのインストールにはマネージドノードの再起動が必要になる場合があるため、パッチ適用オペレーションは 2 つのイベントに分割され、合計 3 つのフックでカスタム機能をサポートします。最初のフックは `Install with NoReboot` オペレーションの前です。2 番目のフックは `Install with NoReboot` オペレーションの後です。3 番目のフックは、ノードの再起動後に使用できます。
**レガシードキュメントを置き換える:**
+ **[なし]**
`AWS-RunPatchBaselineWithHooks` SSM ドキュメントの詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)」を参照してください。
## マネージドノードへのパッチ適用のためのレガシー SSM ドキュメント
次の 4 つの SSM ドキュメントは、一部の AWS リージョン では引き続き使用できます。ただし、更新されておらず、今後サポートされなくなる可能性があるため、使用はお勧めしません。代わりに、「[マネージドノードへのパッチ適用に推奨されている SSM ドキュメント](#patch-manager-ssm-documents-recommended)」に記載されているドキュメントを使用します。
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Windows Server マネージドノードのみをサポートしますが、代わりの `AWS-RunPatchBaseline` にあるアプリケーションのパッチ適用のサポートは含みません。2017年8月以降にローンチされた AWS リージョン では使用できません。
**注記**
この SSM ドキュメントに置き換わる `AWS-RunPatchBaseline` を使用するには、2.0.834.0 以降のバージョンの SSM Agent が必要です。`AWS-UpdateSSMAgent` ドキュメントを使用して、マネージドノードを最新バージョンのエージェントに更新することができます。
### `AWS-FindWindowsUpdates`
`AWS-InstallWindowsUpdates` に置き換えられ、すべて同じアクションを実行できます。2017年4月以降にローンチされた AWS リージョン では使用できません。
このレガシー SSM ドキュメントから同様の結果を得るには、推奨されている置換ドキュメント (`AWS-InstallWindowsUpdates`) で次のパラメータ設定を使用します。
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
`AWS-InstallWindowsUpdates` に置き換えられ、すべて同じアクションを実行できます。2017 年 4 月以降にローンチされた AWS リージョン では使用できません。
このレガシー SSM ドキュメントから同様の結果を得るには、推奨されている置換ドキュメント (`AWS-InstallWindowsUpdates`) で次のパラメータ設定を使用します。
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
`AWS-InstallWindowsUpdates` に置き換えられ、すべて同じアクションを実行できます。2017 年 4 月以降にローンチされた AWS リージョン では使用できません。
このレガシー SSM ドキュメントから同様の結果を得るには、推奨されている置換ドキュメント (`AWS-InstallWindowsUpdates`) で次のパラメータ設定を使用します。
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *KB の記事のカンマ区切りリスト*
## マネージドノードにパッチを適用するための SSM ドキュメントにおける既知の制限
### 外部再起動による中断
パッチのインストール中にノード上のシステムによって再起動が実行された場合 (例えば、ファームウェアや SecureBoot などの機能に更新プログラムを適用するため)、パッチが正常にインストールされても、パッチ適用ドキュメントの実行が中断されて失敗としてマークされる場合があります。SSM Agent が外部再起動全体でドキュメントの実行状態を維持および再開できないために発生します。
実行が失敗した後にパッチ適用のインストールステータスを確認するには、`Scan` パッチ適用オペレーションを実行し、Patch Manager でパッチコンプライアンスデータを確認して現在のコンプライアンス状態を評価します。
# パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`
AWS Systems Manager は、AWS Systems Manager のツールである Patch Manager 用の Systems Manager ドキュメント (SSM ドキュメント) である `AWS-RunPatchBaseline` をサポートしています。この SSM ドキュメントでは、セキュリティ関連および他のタイプの更新の両方について、マネージドノードにパッチ適用オペレーションを実行します。パッチグループが指定されていない場合、ドキュメントを実行すると、オペレーティングシステムタイプの「デフォルト」として指定されているパッチベースラインが使用されます。それ以外の場合は、パッチグループに関連付けられているパッチベースラインが使用されます。パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。
ドキュメント `AWS-RunPatchBaseline` を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。
このドキュメントでは、Linux macOS、および Windows Server マネージドノードをサポートしています。ドキュメントは、プラットフォーム別に適切なアクションを実行します。
**注記**
Patch Manager は、レガシー SSM ドキュメント `AWS-ApplyPatchBaseline` もサポートしています。ただし、このドキュメントが対応するのは Windows マネージドノードのみです。Linux、macOS、および Windows Server マネージドノードでのパッチ適用をサポートしているため、代わりに `AWS-RunPatchBaseline` を使用することをお勧めします。 `AWS-RunPatchBaseline`ドキュメントを使用するには、バージョン 2.0.834.0 以降の SSM Agent が必要です。
------
#### [ Windows サーバー ]
Windows Server マネージドノードの場合、`AWS-RunPatchBaseline` ドキュメントは、PowerShell モジュールをダウンロードして呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインスナップショットには、Windows Server Update Services (WSUS) サーバーに対してパッチベースラインを照会することによってコンパイルされる承認済みパッチのリストが含まれています。このリストは、Windows Update API に渡され、ここで承認済みパッチのダウンロードとインストールが適切に制御されます。
------
#### [ Linux ]
Linux マネージドノードの場合、`AWS-RunPatchBaseline` ドキュメントは、Python モジュールを呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインのスナップショットは、定義済みルールと、承認済みパッチおよび拒否済みパッチのリストを使用し、ノードタイプ別に適切なパッケージマネージャーを設定します。
+ Amazon Linux 2、Oracle Linux、および RHEL 7 マネージドノードでは、YUM が使用されています。YUM のオペレーションでは、Patch Manager には、`Python 2.6` またはそれ以降のサポートされているバージョン (2.6～3.12) が必要です。Amazon Linux 2023 では DNF が使用されています。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です。
+ RHEL 8 マネージドノードでは DNF が使用されます。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です。(どちらのバージョンも RHEL 8 にはデフォルトでインストールされていません。どちらか一方を手動でインストールする必要があります。)
+ Debian Server、および Ubuntu Server インスタンスでは、APT が使用されています。APT のオペレーションでは、Patch Manager には、サポートされているバージョン (3.0～3.12) の `Python 3` が必要です。
------
#### [ macOS ]
macOS マネージドノードの場合、`AWS-RunPatchBaseline` ドキュメントは、Python モジュールを呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。次に、Python サブプロセスがノードで AWS Command Line Interface (AWS CLI) を呼び出し、指定されたパッケージマネージャーのインストールおよび更新情報を取得し、各更新パッケージに適切なパッケージマネージャーを実行します。
------
各スナップショットは、AWS アカウント 、パッチグループ、オペレーティングシステム、スナップショット ID に固有のものです。スナップショットは、署名付きの Amazon Simple Storage Service (Amazon S3) URL を介して配信されます。この URL は、スナップショットが作成されてから 24 時間後に期限切れになります。ただし、URL の有効期限が切れた後に、同じスナップショットコンテンツを他のマネージドノードに適用する場合は、スナップショットを作成してから 3 日以内であれば新しい署名付き Amazon S3 URL を生成できます。これを行うには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) コマンドを使用します。
すべての承認済みで適用可能な更新プログラムがインストールされ、必要に応じて再起動されると、パッチのコンプライアンス情報がマネージドノードで生成されて Patch Manager にレポートされます。
**注記**
`AWS-RunPatchBaseline` ドキュメントで `RebootOption` パラメータが `NoReboot` に設定されている場合、Patch Manager の実行後、マネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。
パッチコンプライアンスデータの表示方法については、「[パッチコンプライアンスについて](compliance-about.md#compliance-monitor-patch)」を参照してください。
## `AWS-RunPatchBaseline` 個のパラメータ
`AWS-RunPatchBaseline` では 6 つのパラメータがサポートされています。`Operation` パラメータは必須です。`InstallOverrideList`、`BaselineOverride`、`RebootOption` の各パラメータはオプションです。`Snapshot-ID` は技術的にはオプションですが、メンテナンスウィンドウを使用せずに `AWS-RunPatchBaseline` を実行する場合はカスタム値を指定することをお勧めします。このドキュメントをメンテナンスウィンドウオペレーションの一部として実行する場合は、Patch Manager がカスタム値を自動的に提供します。
**Topics**
+ [パラメータ名: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [パラメータ名: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [パラメータ名: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [パラメータ名: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [パラメータ名: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [パラメータ名: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### パラメータ名: `Operation`
**使用**: 必須。
**オプション**: `Scan` \$1 `Install`。
Scan
`Scan` オプションを選択すると、`AWS-RunPatchBaseline` はマネージドノードのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。`Scan` では、更新のインストールや、マネージドノードの再起動を求めません。その代わりに、このオペレーションでは、承認されたノードに適用可能なアップデートがどこに欠けているかを特定します。
インストール
`Install` オプションを選択すると、`AWS-RunPatchBaseline` はマネージドノードに見つからない承認済み更新と適用可能な更新のインストールを試行します。`Install` オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がマネージドノードにインストールされるたびに、ノードが再起動され、更新がインストール済みで有効になっていることが確認されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。)
Patch Manager がマネージドノードを更新する*前*に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の `unattended-upgrades` パッケージなどの別のプログラムによって自動的にインストールされた場合です。
### パラメータ名: `AssociationId`
**使用**: オプション。
`AssociationId` は、AWS Systems Manager のツールである State Manager の、既存の関連付けの ID です。これは、指定した関連付けにコンプライアンスデータを追加するために Patch Manager で使用します。この関連付けは、[Quick Setup のパッチポリシーでセットアップ](quick-setup-patch-manager.md)されたパッチ適用オペレーションに関連しています。
**注記**
`AWS-RunPatchBaseline` では、パッチポリシーベースラインのオーバーライドとともに `AssociationId` 値を指定すると、パッチ適用は `PatchPolicy` オペレーションとして実行され、`AWS:ComplianceItem` で報告される `ExecutionType` 値も `PatchPolicy` です。`AssociationId` 値が指定されていない場合、パッチ適用は `Command` オペレーションとして実行され、送信される `AWS:ComplianceItem` の `ExecutionType` 値のレポートも `Command` です。
使用する関連付けがまだない場合は、[https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) コマンドを実行して関連付けを作成できます。
### パラメータ名: `Snapshot ID`
**使用**: オプション。
`Snapshot ID` は、Patch Manager が使用する一意の ID (GUID) です。この ID により、1 回のオペレーションでパッチを適用するマネージドノードのすべてに同じ承認済みパッチのセットが適用されます。このパラメータは省略可能ですが、次の表に示すようにメンテナンスウィンドウで `AWS-RunPatchBaseline` を実行しているかどうかに応じて、推奨されるベストプラクティスが異なります。
**`AWS-RunPatchBaseline` のベストプラクティス**
| モード | ベストプラクティス | 詳細 |
| --- | --- | --- |
| メンテナンスウィンドウ内で AWS-RunPatchBaseline を実行する | スナップショット ID は指定しないでください。Patch Manager によって指定されます。 | メンテナンスウィンドウを使用して `AWS-RunPatchBaseline` を実行する場合は、独自に生成したスナップショット ID を提供すべきではありません。このシナリオでは、メンテナンスウィンドウの実行 ID に基づく GUID 値が Systems Manager から提供されます。これにより、そのメンテナンスウィンドウでは、`AWS-RunPatchBaseline` のすべての呼び出しで正しい ID が使用されます。 このシナリオで値を指定しないと、パッチベースラインのスナップショットは 3 日以内に有効期限が切れる場合があります。スナップショットの有効期限が切れると、同じ ID を指定しても、別のスナップショットが生成されます。 |
| メンテナンスウィンドウ外で AWS-RunPatchBaseline を実行する | スナップショット ID のカスタム GUID 値を生成および指定します。¹ | メンテナンスウィンドウを使用しないで `AWS-RunPatchBaseline` を実行する場合は、パッチベースラインごとに一意のスナップショット ID を生成し指定することをお勧めします (特に、同一のオペレーションで `AWS-RunPatchBaseline` ドキュメントを複数のマネージドノードで実行する場合)。このシナリオで ID を指定しないと、コマンドの送信先のマネージドノードごとに異なるスナップショット ID が Systems Manager で生成されます。これにより、マネージドノード間で異なるパッチセットが指定される場合があります。 例えば、AWS Systems Manager のツールである Run Command を使用して `AWS-RunPatchBaseline` ドキュメントを直接実行し、50 個のマネージドノードのグループをターゲットにしているとします。カスタムスナップショット ID を指定すると、1 つのベースラインスナップショットが作成され、これがすべてのノードの評価とパッチ適用に使用されるため、すべてのノードの状態が一致します。 |
| ¹Snapshot ID パラメータの値を生成するには、GUID を生成できる任意のツールを使用できます。たとえば、PowerShell では、`New-Guid` cmdlet を使用して `12345699-9405-4f69-bc5e-9315aEXAMPLE` という形式の GUID を生成できます。 |
### パラメータ名: `InstallOverrideList`
**使用**: オプション。
`InstallOverrideList` を使用すると、インストールするパッチのリストに対する https URL または Amazon S3 パス形式の URL を指定できます。このパッチインストールリストは、YAML 形式で管理され、デフォルトのパッチベースラインで指定されたパッチを上書きします。これにより、どのマネージドノードにどのパッチがインストールされているかを、より詳細にコントロールできます。
**重要**
`InstallOverrideList` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
`InstallOverrideList` パラメータを使用する場合のパッチ適用オペレーションの動作は、Linux および macOS マネージドノードと、Windows Server マネージドノードで異なります。Linux および macOS では、パッチがパッチベースラインルールと一致するかどうかにかかわらず、Patch Manager は、ノードで有効になっているリポジトリに存在する `InstallOverrideList` パッチリストに含まれるパッチを適用しようとします。一方、Windows Server ノードでは、`InstallOverrideList` パッチリスト内のパッチは、パッチベースラインルールとも一致する場合にのみ適用されます。
コンプライアンスレポートは、パッチの `InstallOverrideList` リストで指定するものではなく、パッチのベースラインで指定されているものに従ってパッチの状態が反映されることに注意してください。つまり、スキャンオペレーションは `InstallOverrideList` パラメータを無視します。これは、コンプライアンスレポートが、特定のパッチ適用オペレーションで承認されたものではなく、ポリシーに従ってパッチ状態を一貫して反映することを保証するためです。
**注記**
IPv6 のみを使用するノードにパッチを適用する場合は、指定された URL がノードから到達可能であることを確認してください。SSM Agent config オプション `UseDualStackEndpoint` が `true` に設定されている場合、S3 の URL を指定するとデュアルスタック S3 クライアントが使用されます。デュアルスタックを使用するためのエージェントの設定の詳細については、「[チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md)」を参照してください。
単一のパッチベースラインを使用しながら、`InstallOverrideList` パラメータを使用して、異なるメンテナンスウィンドウスケジュールで異なるタイプのパッチをターゲットグループに適用する方法の詳細については、「[`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` で InstallOverrideList パラメータを使用するサンプルシナリオ](patch-manager-override-lists.md)」を参照してください。
**有効な URL 形式**
**注記**
ファイルが公開されているバケットに格納されている場合は、「https」URL 形式または Amazon S3 パススタイルの URL を指定できます。ファイルがプライベートバケットに格納されている場合は、Amazon S3 パススタイルの URL を指定する必要があります。
+ **https URL 形式**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 パス形式の URL** :
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**有効な YAML コンテンツ形式**
リストにパッチを指定するために使用する書式は、マネージドノードのオペレーティングシステムによって異なります。ただし、一般的な形式は次のとおりです。
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
YAML ファイルにフィールドを追加することはできますが、パッチオペレーション中は無視されます。
さらに、S3 バケットのリストを追加または更新する前に、YAML ファイルのフォーマットが有効であることを確認することをお勧めします。YAML 形式の詳細については、[yaml.org](http://www.yaml.org) を参照してください。検証ツールのオプションについては、ウェブで「yaml 形式の検証」を検索します。
------
#### [ Linux ]
**id**
**id** フィールドは必須です。これにより、パッケージ名とアーキテクチャを使用してパッチを指定します。例: `'dhclient.x86_64'`。ID にワイルドカードを使用すると、複数のパッケージを指定できます。例: `'dhcp*'` および `'dhcp*1.*'`。
**タイトル**
**title** フィールドはオプションですが、Linux システムでは追加のフィルタリング機能を提供します。**title** を使用する場合は、次のいずれかの形式でパッケージのバージョン情報を含める必要があります。
YUM/SUSE Linux Enterprise Server (SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Linux のパッチタイトルでは、任意の位置に 1 つ以上のワイルドカードを使用して一致するパッケージの数を拡張することができます。例: `'*32:9.8.2-0.*.rc1.57.amzn1'`。
例:
+ apt パッケージのバージョン 1.2.25 が現在マネージドノードにインストールされていますが、バージョン 1.2.27 が利用できるようになりました。
+ apt.amd64 バージョン 1.2.27 をパッチリストに追加します。これは apt utils.amd64 バージョン 1.2.27 に依存しますが、apt-utils.amd64 バージョン 1.2.25 がリストで指定されています。
この場合、apt バージョン 1.2.27 のインストールはブロックされ、「Failed-NonCompliant」として報告されます。
------
#### [ Windows サーバー ]
**id**
**id** フィールドは必須です。Microsoft Knowledge Base ID (KB2736693 など) および Microsoft Security Bulletin ID (MS17-023 など) を使用してパッチを指定する場合に使用します。
Windows 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、**title**、**classification**、**severity** などの追加フィールドを使用することができます。
------
#### [ macOS ]
**id**
**id** フィールドは必須です。**id** フィールドの値は、`{package-name}.{package-version}` 形式または \$1package\$1name\$1 形式のいずれかを使用して指定することができます。
------
**サンプルパッチリスト**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### パラメータ名: `RebootOption`
**使用**: オプション。
**オプション**: `RebootIfNeeded` \$1 `NoReboot`
**デフォルト**: `RebootIfNeeded`
**警告**
デフォルトのオプションは `RebootIfNeeded` です。ユースケースに適したオプションを必ず選択してください。例えば、設定プロセスを完了するためにマネージドノードをすぐに再起動する必要がある場合は、`RebootIfNeeded` を選択します。または、スケジュールされた再起動時間までマネージドノードの可用性を維持する必要がある場合は、`NoReboot` を選択します。
**重要**
Amazon EMR (以前は Amazon Elastic MapReduce と呼ばれていました) のクラスターインスタンスへのパッチ適用には、Patch Manager を使用しないことをお勧めします。特に、`RebootOption` パラメータの `RebootIfNeeded` オプションは選択しないでください。(このオプションは、`AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation`、および `AWS-RunPatchBaselineWithHooks` のパッチ適用用の SSM コマンドドキュメントに記載されています。)
Patch Manager を使用してパッチを適用する基本コマンドは、`yum` と `dnf` コマンドを使用します。そのため、パッケージのインストール方法が原因となり、オペレーションの互換性が失われます。Amazon EMR クラスターのソフトウェアを更新するための推奨方法については、「Amazon EMR 管理ガイド」の「[Amazon EMR のデフォルト AMI の使用](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)」を参照してください。
RebootIfNeeded
`RebootIfNeeded` オプションを選択すると、次のいずれかの場合にマネージドノードが再起動されます。
+ Patch Manager が 1 つ以上のパッチをインストールしている場合。
Patch Manager は、パッチによる再起動が*必要*かどうか評価しない場合。パッチで再起動が必要ない場合でも、システムは再起動されます。
+ Patch Manager は、`Install` オペレーションの実行中、ステータスが `INSTALLED_PENDING_REBOOT` のパッチをひとつ以上検出します。
`INSTALLED_PENDING_REBOOT` ステータスは、前回 `Install` オペレーションを実行したときにオプション `NoReboot` が選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
上記 2 つの場合にマネージドノードを再起動すると、更新されたパッケージがメモリからフラッシュされ、パッチ適用と再起動の動作があらゆるオペレーティングシステムで一貫して維持されます。
NoReboot
`NoReboot` オプションを選択すると、Patch Manager が `Install` オペレーション中にパッチをインストールした場合でも、マネージドノードは再起動されません。このオプションは、パッチ適用後にマネージドノードを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがノードで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、マネージドノードの再起動のタイミングをより詳細に制御する場合にも役立ちます。
パッチがインストールされている場合に `NoReboot` オプションを選択すると、ステータス `InstalledPendingReboot` がパッチに割り当てられます。ただし、マネージドノード自体は、`Non-Compliant` と表示されています。再起動が発生し、`Scan` オペレーションが実行されると、マネージドノードのステータスは `Compliant` に更新されます。
`NoReboot` オプションは、オペレーティングシステムレベルの再起動のみを防ぎます。サービスレベルの再起動は、パッチ適用プロセスの一環として引き続き発生する可能性があります。例えば、Docker が更新されると、`NoReboot` が有効にされていても Amazon Elastic Container Service などの依存サービスが自動的に再起動される場合があります。中断してはならない重要なサービスがある場合は、一時的にインスタンスをサービスから削除したり、メンテナンス期間中にパッチ適用をスケジュールしたりするなどの追加の対策を検討してください。
**パッチのインストール追跡ファイル**: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、Systems Manager は、マネージドノードのファイルを管理します。
**重要**
追跡ファイルを削除または変更しないでください。このファイルを削除または破損すると、マネージドノードのパッチコンプライアンスレポートが不正確になります。ファイルを削除または破損した場合は、ノードを再起動し、パッチのスキャンオペレーションを実行してファイルを復元します。
この追跡ファイルは、マネージドノードの以下の場所に保存されます。
+ Linux オペレーティングシステム:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server オペレーティングシステム:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### パラメータ名: `BaselineOverride`
**使用**: オプション。
`BaselineOverride` パラメータを使用して、実行時にパッチ定義設定を定義できます。このベースラインオーバーライドは、S3 バケット内の JSON オブジェクトとして維持されます。これにより、パッチ適用操作で、デフォルトのパッチベースラインのルールを適用する代わりに、ホストオペレーティングシステムに一致する指定されたベースラインが使用されるようにします。
**重要**
`BaselineOverride` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
`BaselineOverride` パラメータの使用方法の詳細については、「[BaselineOverride パラメータの使用](patch-manager-baselineoverride-parameter.md)」を参照してください。
### パラメータ名: `StepTimeoutSeconds`
**使用**: 必須。
コマンドが失敗したとみなされるまでの経過時間 (秒、1～36,000 秒 (10 時間))。
# パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineAssociation`
`AWS-RunPatchBaseline` ドキュメントと同様に、`AWS-RunPatchBaselineAssociation` では、セキュリティ関連および他のタイプの更新の両方について、インスタンスにパッチ適用オペレーションを実行します。また、ドキュメント `AWS-RunPatchBaselineAssociation` を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することもできます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。
このドキュメントでは、Linux、macOS、および Windows Server 用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがサポートされています。[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境内の非 EC2 ノードは、サポートされていません。このドキュメントでは、各プラットフォームに対して適切なアクションを実行し、Linux インスタンスおよび macOS インスタンスでは Python モジュールを、Windows インスタンスでは PowerShell モジュールを呼び出します。
ただし、`AWS-RunPatchBaselineAssociation` は、次の点で `AWS-RunPatchBaseline` とは異なります。
+ `AWS-RunPatchBaselineAssociation` は、主に AWS Systems Manager のツールである [Quick Setup](systems-manager-quick-setup.md) を使用して作成された State Manager 関連付けでの使用を目的としています。具体的には、Quick Setup ホスト管理設定タイプを使用する場合、**[Scan instances for missing patches daily]** (不足しているパッチがないか毎日インスタンスをスキャンする) オプションを選択すると、システムはオペレーションに `AWS-RunPatchBaselineAssociation` を使用します。
ただし、ほとんどの場合、独自のパッチ適用オペレーションを設定する場合は、`AWS-RunPatchBaselineAssociation` の代わりに、[`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) または [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) を選択する必要があります。
+ `AWS-RunPatchBaselineAssociation` ドキュメントを使用すると、ドキュメントの `BaselineTags` パラメータフィールドでタグのキーペアを指定できます。AWS アカウント内のカスタムパッチベースラインがこれらのタグを共有している場合、AWS Systems Manager のツールである Patch Manager は、ターゲットインスタンスでの実行時に、オペレーティングシステムタイプに対して現在指定されている「デフォルト」パッチベースラインではなく、そのタグ付きベースラインを使用します。
**注記**
Quick Setup を使用してセットアップした以外のパッチオペレーションで `AWS-RunPatchBaselineAssociation` を使用することを選択し、そのオプションの `BaselineTags` パラメータを使用する場合は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの[インスタンスプロファイル](setup-instance-permissions.md)に対する追加のアクセス許可を指定する必要があります。詳細については、「[パラメータ名: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)」を参照してください。
次の形式はどちらも `BaselineTags` パラメータに対して有効です。
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
タグキーと値には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
+ `AWS-RunPatchBaselineAssociation` の実行時に収集されるパッチコンプライアンスデータは、`PutComplianceItems` によって使用される `PutInventory` コマンドではなく、 `AWS-RunPatchBaseline` API コマンドを使用して記録されます。この違いは、特定の*関連付け*ごとに保存およびレポートされるパッチコンプライアンス情報であることを意味します。この関連付けの外部で生成されたパッチコンプライアンスデータは上書きされません。
+ `AWS-RunPatchBaselineAssociation` の実行後にレポートされるパッチコンプライアンス情報は、インスタンスが準拠しているかどうかを示します。次の AWS Command Line Interface ( AWS CLI )コマンドの出力で示されているように、パッチレベルの詳細は含まれません。コマンドはコンプライアンスタイプとして `Association` でフィルタリングされます。
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
システムが以下のような情報をレスポンスします。
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
`AWS-RunPatchBaselineAssociation` ドキュメントのパラメータとしてタグのキーペア値が指定されている場合、Patch Manager は、オペレーティングシステムのタイプと一致し、同じタグのキーペアでタグ付けされているカスタムパッチベースラインを検索します。この検索は、現在指定されているデフォルトのパッチベースライン、またはパッチグループに割り当てられたベースラインに制限されません。指定されたタグを持つベースラインが見つからない場合は、Patch Managerはパッチグループを検索します (`AWS-RunPatchBaselineAssociation` を実行するコマンドで指定されている場合)。一致するパッチグループがない場合、Patch Managerはオペレーティングシステムのアカウントにデフォルトに設定されているパッチベースラインを使用します。
`AWS-RunPatchBaselineAssociation` ドキュメントで指定されているタグを持つパッチベースラインが複数見つかった場合、Patch Managerは、オペレーションを続行するために、そのキーと値のペアでタグ付けできるパッチベースラインは 1 つだけであることを示すエラーメッセージを返します。
**注記**
Linux ノードでは、各ノードタイプに適切なパッケージマネージャーを使用してパッケージをインストールします。
Amazon Linux 2、Oracle Linux、および RHEL インスタンスでは、YUM が使用されています。YUM のオペレーションでは、Patch Manager には、`Python 2.6` またはそれ以降のサポートされているバージョン (2.6～3.12) が必要です。Amazon Linux 2023 では DNF が使用されています。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です
Debian Server インスタンスと Ubuntu Server インスタンスでは、APT を使用します。APT のオペレーションでは、Patch Manager には、サポートされているバージョン (3.0～3.12) の `Python 3` が必要です。
スキャンが完了した後、またはすべての承認済み更新と該当する更新がインストールされた後、必要に応じて再起動されると、パッチコンプライアンス情報がインスタンスで生成されてパッチコンプライアンスサービスにレポートされます。
**注記**
`AWS-RunPatchBaselineAssociation` ドキュメントで `RebootOption` パラメータが `NoReboot` に設定されている場合、Patch Managerの実行後、インスタンスは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)」を参照してください。
パッチコンプライアンスデータの表示方法については、「[パッチコンプライアンスについて](compliance-about.md#compliance-monitor-patch)」を参照してください。
## `AWS-RunPatchBaselineAssociation` 個のパラメータ
`AWS-RunPatchBaselineAssociation` は 5 つのパラメータをサポートしています。`Operation` および `AssociationId` パラメータが必要です。`InstallOverrideList`、`RebootOption` および `BaselineTags` パラメータはオプションです。
**Topics**
+ [パラメータ名: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [パラメータ名: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [パラメータ名: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [パラメータ名: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### パラメータ名: `Operation`
**使用**: 必須。
**オプション**: `Scan` \$1 `Install`。
Scan
`Scan` オプションを選択すると、`AWS-RunPatchBaselineAssociation` はインスタンスのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。`Scan` では、更新のインストールや、インスタンスの再起動を求めません。代わりに、承認済み更新でインスタンスに適用可能なものが見つからない個所を示します。
インストール
`Install` オプションを選択すると、`AWS-RunPatchBaselineAssociation` はインスタンスに見つからない承認済み更新と適用可能な更新のインストールを試行します。`Install` オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がインスタンスにインストールされるたびに、インスタンスが再起動され、更新がインストール済みで有効になっていることが確認されます。（例外: `RebootOption` パラメータが `AWS-RunPatchBaselineAssociation` ドキュメントの `NoReboot` で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)」を参照してください。）
Patch Managerがインスタンスを更新する*前*に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の `unattended-upgrades` パッケージなどの別のプログラムによって自動的にインストールされた場合です。
### パラメータ名: `BaselineTags`
**使用**: オプション。
`BaselineTags` は、一意のタグのキーと値のペアで、選択して個々のカスタムパッチベースラインに割り当てます。このパラメータには、1 つ以上の値を指定できます。次の形式はどちらも有効です。
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
タグキーと値には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
Patch Manager は、`BaselineTags` の値を使用して、1 回のオペレーションでパッチを適用するインスタンスのすべてに同じ承認済みパッチのセットが適用されるようにします。 パッチ適用オペレーションが実行すると、Patch Manager は、オペレーティングシステムのタイプのパッチベースラインが `BaselineTags` で指定したものと同じキーと値のペアでタグ付けされているか確認します。一致するものがある場合は、このカスタムパッチベースラインが使用されます。一致するものがない場合、パッチ適用オペレーションに指定されたパッチグループに従って、パッチベースラインが識別されます。存在しない場合は、そのオペレーティングシステムの AWS マネージド定義済みパッチベースラインが使用されます。
**追加のアクセス許可要件**
Quick Setup を使用してセットアップした以外のパッチオペレーションで `AWS-RunPatchBaselineAssociation` を使用し、オプションの `BaselineTags` パラメータを使用する場合は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの[インスタンスプロファイル](setup-instance-permissions.md)に対する以下のアクセス許可を追加する必要があります。
**注記**
Quick Setup と `AWS-RunPatchBaselineAssociation` は、オンプレミスのサーバーと仮想マシン (VM) をサポートしていません。
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
*patch-baseline-arn* を、アクセス許可を付与するパッチベースラインの Amazon リソースネーム (ARN) に、`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE` 形式で置き換えます。
### パラメータ名: `AssociationId`
**使用**: 必須。
`AssociationId` は、AWS Systems Manager のツールである State Manager の、既存の関連付けの ID です。これは、指定した関連付けにコンプライアンスデータを追加するために Patch Manager で使用します。この関連付けは、[Quick Setup で作成されたホスト管理設定](quick-setup-host-management.md)で有効になっているパッチ `Scan` オペレーションに関連しています。パッチ適用の結果をインベントリコンプライアンスデータではなく関連付けコンプライアンスデータとして送信することで、インスタンスの既存のインベントリコンプライアンス情報は、パッチ適用オペレーションの後やその他の関連付け ID に対して上書きされません。使用する関連付けがまだない場合は、[https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) コマンドを実行して関連付けを作成できます。例えば、次のようになります。
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows サーバー ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### パラメータ名: `InstallOverrideList`
**使用**: オプション。
`InstallOverrideList` を使用して、インストールするパッチのリストに対する https URL または Amazon Simple Storage Service (Amazon S3) パス形式の URL を指定します。このパッチインストールリストは、YAML 形式で管理され、デフォルトのパッチベースラインで指定されたパッチを上書きします。これにより、どのインスタンスにどのパッチがインストールされているかを、より詳細にコントロールできます。
**重要**
`InstallOverrideList` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
`InstallOverrideList` パラメータを使用する場合のパッチ適用オペレーションの動作は、Linux および macOS マネージドノードと、Windows Server マネージドノードで異なります。Linux および macOS では、パッチがパッチベースラインルールと一致するかどうかにかかわらず、Patch Manager は、ノードで有効になっているリポジトリに存在する `InstallOverrideList` パッチリストに含まれるパッチを適用しようとします。一方、Windows Server ノードでは、`InstallOverrideList` パッチリスト内のパッチは、パッチベースラインルールとも一致する場合にのみ適用されます。
コンプライアンスレポートは、パッチの `InstallOverrideList` リストで指定するものではなく、パッチのベースラインで指定されているものに従ってパッチの状態が反映されることに注意してください。つまり、スキャンオペレーションは `InstallOverrideList` パラメータを無視します。これは、コンプライアンスレポートが、特定のパッチ適用オペレーションで承認されたものではなく、ポリシーに従ってパッチ状態を一貫して反映することを保証するためです。
**有効な URL 形式**
**注記**
ファイルが公開されているバケットに格納されている場合は、「https」URL 形式または Amazon S3 パススタイルの URL を指定できます。ファイルがプライベートバケットに格納されている場合は、Amazon S3 パススタイルの URL を指定する必要があります。
+ **https URL 形式の例**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 パス形式 URL の例**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**有効な YAML コンテンツ形式**
リストにパッチを指定するために使用する書式は、インスタンスのオペレーティングシステムによって異なります。ただし、一般的な形式は次のとおりです。
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
YAML ファイルにフィールドを追加することはできますが、パッチオペレーション中は無視されます。
さらに、S3 バケットのリストを追加または更新する前に、YAML ファイルのフォーマットが有効であることを確認することをお勧めします。YAML 形式の詳細については、[yaml.org](http://www.yaml.org) を参照してください。検証ツールのオプションについては、ウェブで「yaml 形式の検証」を検索します。
+ Microsoft Windows
**id**
**id** フィールドは必須です。Microsoft Knowledge Base ID (KB2736693 など) および Microsoft Security Bulletin ID (MS17-023 など) を使用してパッチを指定する場合に使用します。
Windows 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、**title**、**classification**、**severity** などの追加フィールドを使用することができます。
+ Linux
**id**
**id** フィールドは必須です。これにより、パッケージ名とアーキテクチャを使用してパッチを指定します。例: `'dhclient.x86_64'`。ID にワイルドカードを使用すると、複数のパッケージを指定できます。例: `'dhcp*'` および `'dhcp*1.*'`。
**title**
**title** フィールドはオプションですが、Linux システムでは追加のフィルタリング機能を提供します。**title** を使用する場合は、次のいずれかの形式でパッケージのバージョン情報を含める必要があります。
YUM/Red Hat Enterprise Linux (RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Linux のパッチタイトルでは、任意の位置に 1 つ以上のワイルドカードを使用して一致するパッケージの数を拡張することができます。例: `'*32:9.8.2-0.*.rc1.57.amzn1'`。
以下に例を示します。
+ apt パッケージのバージョン 1.2.25 が現在インスタンスにインストールされていますが、バージョン 1.2.27 が利用できるようになりました。
+ apt.amd64 バージョン 1.2.27 をパッチリストに追加します。これは apt utils.amd64 バージョン 1.2.27 に依存しますが、apt-utils.amd64 バージョン 1.2.25 がリストで指定されています。
この場合、apt バージョン 1.2.27 のインストールはブロックされ、「Failed-NonCompliant」として報告されます。
**その他のフィールド**
Linux 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、**classification**、**severity** などの追加フィールドを使用することができます。
**サンプルパッチリスト**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### パラメータ名: `RebootOption`
**使用**: オプション。
**オプション**: `RebootIfNeeded` \$1 `NoReboot`
**デフォルト**: `RebootIfNeeded`
**警告**
デフォルトのオプションは `RebootIfNeeded` です。ユースケースに適したオプションを必ず選択してください。例えば、設定プロセスを完了するためにインスタンスをすぐに再起動する必要がある場合は、`RebootIfNeeded` を選択します。または、スケジュールされた再起動時間までインスタンスの可用性を維持する必要がある場合は、`NoReboot` を選択します。
**重要**
`NoReboot` オプションは、オペレーティングシステムレベルの再起動のみを防ぎます。サービスレベルの再起動は、パッチ適用プロセスの一環として引き続き発生する可能性があります。例えば、Docker が更新されると、`NoReboot` が有効にされていても Amazon Elastic Container Service などの依存サービスが自動的に再起動される場合があります。中断してはならない重要なサービスがある場合は、一時的にインスタンスをサービスから削除したり、メンテナンス期間中にパッチ適用をスケジュールしたりするなどの追加の対策を検討してください。
**重要**
Amazon EMR (以前は Amazon Elastic MapReduce と呼ばれていました) のクラスターインスタンスへのパッチ適用には、Patch Manager を使用しないことをお勧めします。特に、`RebootOption` パラメータの `RebootIfNeeded` オプションは選択しないでください。(このオプションは、`AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation`、および `AWS-RunPatchBaselineWithHooks` のパッチ適用用の SSM コマンドドキュメントに記載されています。)
Patch Manager を使用してパッチを適用する基本コマンドは、`yum` と `dnf` コマンドを使用します。そのため、パッケージのインストール方法が原因となり、オペレーションの互換性が失われます。Amazon EMR クラスターのソフトウェアを更新するための推奨方法については、「Amazon EMR 管理ガイド」の「[Amazon EMR のデフォルト AMI の使用](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)」を参照してください。
RebootIfNeeded
`RebootIfNeeded`オプションを選択すると、次のいずれかの場合にインスタンスが再起動されます。
+ Patch Manager が 1 つ以上のパッチをインストールしている場合。
Patch Manager は、パッチによる再起動が*必要*かどうか評価しない場合。パッチで再起動が必要ない場合でも、システムは再起動されます。
+ Patch Manager は、`Install` オペレーションの実行中、ステータスが `INSTALLED_PENDING_REBOOT` のパッチをひとつ以上検出します。
`INSTALLED_PENDING_REBOOT` ステータスは、前回 `Install` オペレーションを実行したときにオプション `NoReboot` が選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
上記 2 つの場合にインスタンスを再起動すると、更新されたパッケージがメモリからフラッシュされ、パッチ適用と再起動の動作があらゆるオペレーティングシステムで一貫して維持されます。
NoReboot
`NoReboot` オプションを選択すると、Patch Manager が `Install` オペレーション中にパッチをインストールした場合でも、インスタンスは再起動されません。このオプションは、パッチ適用後にインスタンスを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがインスタンスで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、インスタンスの再起動のタイミングをより詳細に制御する場合にも役立ちます。
**パッチのインストール追跡ファイル**: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、Systems Manager は、マネージドインスタンスのファイルを管理します。
**重要**
追跡ファイルを削除または変更しないでください。このファイルを削除または破損すると、インスタンスのパッチコンプライアンスレポートが不正確になります。ファイルを削除または破損した場合は、インスタンスを再起動し、パッチのスキャンオペレーションを実行してファイルを復元します。
この追跡ファイルは、マネージドインスタンスの以下の場所に保存されます。
+ Linux オペレーティングシステム:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server オペレーティングシステム:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager は、AWS Systems Manager のツールである Patch Manager 用の Systems Manager ドキュメント (SSM ドキュメント) である `AWS-RunPatchBaselineWithHooks` をサポートしています。この SSM ドキュメントでは、セキュリティ関連および他のタイプの更新の両方について、マネージドノードにパッチ適用オペレーションを実行します。
`AWS-RunPatchBaselineWithHooks` は、次の点で `AWS-RunPatchBaseline` とは異なります。
+ **ラッパードキュメント** – `AWS-RunPatchBaselineWithHooks` は、`AWS-RunPatchBaseline` のラッパーであり、そのオペレーションの一部で `AWS-RunPatchBaseline` に依存しています。
+ **`Install` オペレーション** – `AWS-RunPatchBaselineWithHooks` では、マネージドノードのパッチ適用中に指定されたポイントで実行されるライフサイクルフックがサポートされます。パッチのインストールにはマネージドノードの再起動が必要になる場合があるため、パッチ適用オペレーションは 2 つのイベントに分割され、合計 3 つのフックでカスタム機能をサポートします。最初のフックは `Install with NoReboot` オペレーションの前です。2 番目のフックは `Install with NoReboot` オペレーションの後です。3 番目のフックは、マネージドノードの再起動後に使用できます。
+ **カスタムパッチリストはサポートしません** – `AWS-RunPatchBaselineWithHooks` では、`InstallOverrideList` パラメータはサポートされません。
+ **SSM Agent サポート** – `AWS-RunPatchBaselineWithHooks` では、パッチを適用するために SSM Agent 3.0.502 以降をマネージドノードにインストールする必要があります。
パッチグループが指定されていない場合、ドキュメントを実行すると、オペレーティングシステムタイプの「デフォルト」として現在指定されているパッチベースラインが使用されます。それ以外の場合は、パッチグループに関連付けられているパッチベースラインが使用されます。パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。
ドキュメント `AWS-RunPatchBaselineWithHooks` を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。
このドキュメントでは、Linux および Windows Server マネージドノードをサポートしています。ドキュメントは、プラットフォーム別に適切なアクションを実行します。
**注記**
`AWS-RunPatchBaselineWithHooks` は macOS ではサポートされていません。
------
#### [ Linux ]
Linux マネージドノードの場合、`AWS-RunPatchBaselineWithHooks` ドキュメントは、Python モジュールを呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインのスナップショットは、定義済みルールと、承認済みパッチおよび拒否済みパッチのリストを使用し、ノードタイプ別に適切なパッケージマネージャーを設定します。
+ Amazon Linux 2、Oracle Linux、および RHEL 7 マネージドノードでは、YUM が使用されています。YUM のオペレーションでは、Patch Manager には、`Python 2.6` またはそれ以降のサポートされているバージョン (2.6～3.12) が必要です。Amazon Linux 2023 では DNF が使用されています。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です。
+ RHEL 8 マネージドノードでは DNF が使用されます。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です。(どちらのバージョンも RHEL 8 にはデフォルトでインストールされていません。どちらか一方を手動でインストールする必要があります。)
+ Debian Server インスタンスと Ubuntu Server インスタンスでは、APT を使用します。APT のオペレーションでは、Patch Manager には、サポートされているバージョン (3.0～3.12) の `Python 3` が必要です。
------
#### [ Windows サーバー ]
Windows Server マネージドノードの場合、`AWS-RunPatchBaselineWithHooks` ドキュメントは、PowerShell モジュールをダウンロードして呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインスナップショットには、Windows Server Update Services (WSUS) サーバーに対してパッチベースラインを照会することによってコンパイルされる承認済みパッチのリストが含まれています。このリストは、Windows Update API に渡され、ここで承認済みパッチのダウンロードとインストールが適切に制御されます。
------
各スナップショットは、AWS アカウント 、パッチグループ、オペレーティングシステム、スナップショット ID に固有のものです。スナップショットは、署名付きの Amazon Simple Storage Service (Amazon S3) URL を介して配信されます。この URL は、スナップショットが作成されてから 24 時間後に期限切れになります。ただし、URL の有効期限が切れた後に、同じスナップショットコンテンツを他のマネージドノードに適用する場合は、スナップショットを作成してから 3 日以内であれば新しい署名付き Amazon S3 URL を生成できます。これを行うには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) コマンドを使用します。
すべての承認済みで適用可能な更新プログラムがインストールされ、必要に応じて再起動されると、パッチのコンプライアンス情報がマネージドノードで生成されて Patch Manager にレポートされます。
`AWS-RunPatchBaselineWithHooks` ドキュメントで `RebootOption` パラメータが `NoReboot` に設定されている場合、Patch Manager の実行後、マネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。
**重要**
`NoReboot` オプションはオペレーティングシステムの再起動を防止しますが、特定のパッケージの更新時に発生する可能性のあるサービスレベルの再起動は防止しません。例えば、Docker などのパッケージを更新すると、`NoReboot` が指定されていても依存サービス (コンテナオーケストレーションサービスなど) の自動再起動がトリガーされる場合があります。
パッチコンプライアンスデータの表示方法については、「[パッチコンプライアンスについて](compliance-about.md#compliance-monitor-patch)」を参照してください。
## `AWS-RunPatchBaselineWithHooks` オペレーションステップ
`AWS-RunPatchBaselineWithHooks` が実行されると、次の手順が実行されます。
1. **スキャン** - `Scan` を使用した `AWS-RunPatchBaseline` オペレーションがマネージドノードで実行され、コンプライアンスレポートが生成され、アップロードされます。
1. **ローカルパッチ状態の確認** - スクリプトを実行して、選択したオペレーションとステップ 1 の `Scan` 結果に基づいて実行されるステップを決定します。
1. 選択したオペレーションが `Scan` の場合、そのオペレーションは完了としてマークされます。オペレーションは終了します。
1. 選択したオペレーションが `Install` の場合、Patch Manager はステップ 1 の `Scan` 結果を評価し、次に実行するオペレーションを決定します。
1. パッチの欠落が検出されず、保留中の再起動が必要ない場合は、オペレーションは最後のステップ (ステップ 8) に直接進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。
1. パッチの欠落が検出されないが、保留中の再起動が必要で、選択した再起動オプションが `NoReboot` である場合、オペレーションは最後のステップ (ステップ 8) に直接進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。
1. それ以外の場合、オペレーションは次のステップに進みます。
1. **パッチ適用前のフックオペレーション** - 最初のライフサイクルフック用に指定した SSM ドキュメント (`PreInstallHookDocName`) は、マネージドノードで実行されます。
1. **再起動せずにインストール** - `Install` を使用して `NoReboot` の再起動オプションを含む `AWS-RunPatchBaseline` オペレーションがマネージドノードで実行され、コンプライアンスレポートが生成され、アップロードされます。
1. **インストール後のフックオペレーション** - 2 番目のライフサイクルフック用に指定した SSM ドキュメント (`PostInstallHookDocName`) は、マネージドノードで実行されます。
1. **パッチ適用前のフックオペレーション** - 最初のライフサイクルフック用に指定した SSM ドキュメントは、インスタンスで実行されます。
1. 選択した再起動オプションが `NoReboot` の場合、オペレーションは最後のステップ (ステップ 8) に直接進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。
1. 選択した再起動オプションが `RebootIfNeeded` の場合、Patch Manager はステップ4で収集されたインベントリから保留中の再起動が必要かどうかをチェックします。つまり、次のいずれかの場合に操作をステップ 7 に進み、マネージド ノードが再起動されます。
1. Patch Manager は、1 つ以上のパッチをインストールしました。(Patch Manager は、パッチに再起動が必要かどうかを評価しません。パッチに再起動が必要ない場合でも、システムは再起動されます。)
1. Patch Manager は、インストールの実行中、`INSTALLED_PENDING_REBOOT` の状態によってパッチをひとつ以上検出します。`INSTALLED_PENDING_REBOOT` ステータスは、前回インストールオペレーションを実行したときにオプション `NoReboot` が選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
これらの条件を満たすパッチが見つからない場合は、マネージド ノードのパッチ適用操作が完了し、操作は最終ステップ (ステップ 8) に直接進みます。これには、提供されたフックが含まれます。その間のステップはすべてスキップされます。
1. **再起動とレポート** - 再起動オプションが `RebootIfNeeded` であるインストールオペレーションは、`AWS-RunPatchBaseline` を使用してマネージドノードで実行され、コンプライアンスレポートが生成され、アップロードされます。
1. **再起動後のフックオペレーション** - 3 番目のライフサイクルフック用に指定した SSM ドキュメント (`OnExitHookDocName`) は、マネージドノードで実行されます。
`Scan` オペレーションの場合、ステップ 1 が失敗すると、ドキュメントの実行プロセスは停止し、ステップは失敗として報告されますが、後続のステップは成功として報告されます。
`Install` オペレーションの場合、オペレーション中にいずれかの `aws:runDocument` ステップが失敗すると、そのようなステップは失敗として報告され、オペレーションは直接最終ステップ (ステップ 8) に進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。このステップは失敗として報告され、最後のステップはそのオペレーション結果のステータスを報告し、その間にあるすべてのステップは成功として報告されます。
## `AWS-RunPatchBaselineWithHooks` 個のパラメータ
`AWS-RunPatchBaselineWithHooks` では 6 つのパラメータがサポートされています。
`Operation` パラメータは必須です。
`RebootOption`、`PreInstallHookDocName`、`PostInstallHookDocName` および `OnExitHookDocName` パラメータはオプションです。
`Snapshot-ID` は技術的にはオプションですが、`AWS-RunPatchBaselineWithHooks` をメンテナンスウィンドウ以外で実行する場合は、カスタム値を指定することをお勧めします。ドキュメントがメンテナンスウィンドウオペレーションの一部として実行されるときに、Patch Manager に値を自動的に指定させましょう。
**Topics**
+ [パラメータ名: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [パラメータ名: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [パラメータ名: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [パラメータ名: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [パラメータ名: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### パラメータ名: `Operation`
**使用**: 必須。
**オプション**: `Scan` \$1 `Install`。
Scan
`Scan` オプションを選択すると、システムは `AWS-RunPatchBaseline` ドキュメントを使用してマネージドノードのパッチコンプライアンスの状態を判断し、その情報を Patch Manager にレポートします。`Scan` では、更新のインストールやマネージドノードの再起動は行われません。その代わりに、このオペレーションでは、承認されたノードに適用可能なアップデートがどこに欠けているかを特定します。
インストール
`Install` オプションを選択すると、`AWS-RunPatchBaselineWithHooks` はマネージドノードに見つからない承認済み更新と適用可能な更新のインストールを試行します。`Install` オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がマネージドノードにインストールされるたびに、ノードが再起動され、更新がインストール済みで有効になっていることが確認されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaselineWithHooks` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)」を参照してください。)
Patch Manager がマネージドノードを更新する*前*に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の `unattended-upgrades` パッケージなどの別のプログラムによって自動的にインストールされた場合です。
### パラメータ名: `Snapshot ID`
**使用**: オプション。
`Snapshot ID` は、Patch Manager が使用する一意の ID (GUID) です。この ID により、1 回のオペレーションでパッチを適用するマネージドノードのすべてに同じ承認済みパッチのセットが適用されます。このパラメータは省略可能ですが、次の表に示すようにメンテナンスウィンドウで `AWS-RunPatchBaselineWithHooks` を実行しているかどうかに応じて、推奨されるベストプラクティスが異なります。
**`AWS-RunPatchBaselineWithHooks` のベストプラクティス**
| モード | ベストプラクティス | 詳細 |
| --- | --- | --- |
| メンテナンスウィンドウ内で AWS-RunPatchBaselineWithHooks を実行する | スナップショット ID は指定しないでください。Patch Manager によって指定されます。 | メンテナンスウィンドウを使用して `AWS-RunPatchBaselineWithHooks` を実行する場合は、独自に生成したスナップショット ID を提供すべきではありません。このシナリオでは、メンテナンスウィンドウの実行 ID に基づく GUID 値が Systems Manager から提供されます。これにより、そのメンテナンスウィンドウでは、`AWS-RunPatchBaselineWithHooks` のすべての呼び出しで正しい ID が使用されます。 このシナリオで値を指定しないと、パッチベースラインのスナップショットは 3 日以内に有効期限が切れる場合があります。スナップショットの有効期限が切れると、同じ ID を指定しても、別のスナップショットが生成されます。 |
| メンテナンスウィンドウ外で AWS-RunPatchBaselineWithHooks を実行する | スナップショット ID のカスタム GUID 値を生成および指定します。¹ | メンテナンスウィンドウを使用しないで `AWS-RunPatchBaselineWithHooks` を実行する場合は、パッチベースラインごとに一意のスナップショット ID を生成し指定することをお勧めします (特に、同一のオペレーションで `AWS-RunPatchBaselineWithHooks` ドキュメントを複数のマネージドノードで実行する場合)。このシナリオで ID を指定しないと、コマンドの送信先のマネージドノードごとに異なるスナップショット ID が Systems Manager で生成されます。これにより、ノード間で異なるパッチセットが指定される場合があります。 例えば、AWS Systems Manager のツールである Run Command を使用して `AWS-RunPatchBaselineWithHooks` ドキュメントを直接実行し、50 個のマネージドノードのグループをターゲットにしているとします。カスタムスナップショット ID を指定すると、1 つのベースラインスナップショットが作成され、これがすべてのマネージドノードの評価とパッチ適用に使用されるため、すべてのノードの状態が一致します。 |
| ¹Snapshot ID パラメータの値を生成するには、GUID を生成できる任意のツールを使用できます。たとえば、PowerShell では、`New-Guid` cmdlet を使用して `12345699-9405-4f69-bc5e-9315aEXAMPLE` という形式の GUID を生成できます。 |
### パラメータ名: `RebootOption`
**使用**: オプション。
**オプション**: `RebootIfNeeded` \$1 `NoReboot`
**デフォルト**: `RebootIfNeeded`
**警告**
デフォルトのオプションは `RebootIfNeeded` です。ユースケースに適したオプションを必ず選択してください。例えば、設定プロセスを完了するためにマネージドノードをすぐに再起動する必要がある場合は、`RebootIfNeeded` を選択します。または、スケジュールされた再起動時間までマネージドノードの可用性を維持する必要がある場合は、`NoReboot` を選択します。
**重要**
Amazon EMR (以前は Amazon Elastic MapReduce と呼ばれていました) のクラスターインスタンスへのパッチ適用には、Patch Manager を使用しないことをお勧めします。特に、`RebootOption` パラメータの `RebootIfNeeded` オプションは選択しないでください。(このオプションは、`AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation`、および `AWS-RunPatchBaselineWithHooks` のパッチ適用用の SSM コマンドドキュメントに記載されています。)
Patch Manager を使用してパッチを適用する基本コマンドは、`yum` と `dnf` コマンドを使用します。そのため、パッケージのインストール方法が原因となり、オペレーションの互換性が失われます。Amazon EMR クラスターのソフトウェアを更新するための推奨方法については、「Amazon EMR 管理ガイド」の「[Amazon EMR のデフォルト AMI の使用](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)」を参照してください。
RebootIfNeeded
`RebootIfNeeded` オプションを選択すると、次のいずれかの場合にマネージドノードが再起動されます。
+ Patch Manager が 1 つ以上のパッチをインストールしている場合。
Patch Manager は、パッチによる再起動が*必要*かどうか評価しない場合。パッチで再起動が必要ない場合でも、システムは再起動されます。
+ Patch Manager は、`Install` オペレーションの実行中、ステータスが `INSTALLED_PENDING_REBOOT` のパッチをひとつ以上検出します。
`INSTALLED_PENDING_REBOOT` ステータスは、前回 `Install` オペレーションを実行したときにオプション `NoReboot` が選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
上記 2 つの場合にマネージドノードを再起動すると、更新されたパッケージがメモリからフラッシュされ、パッチ適用と再起動の動作があらゆるオペレーティングシステムで一貫して維持されます。
NoReboot
`NoReboot` オプションを選択すると、Patch Manager が `Install` オペレーション中にパッチをインストールした場合でも、マネージドノードは再起動されません。このオプションは、パッチ適用後にマネージドノードを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがノードで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、マネージドノードの再起動のタイミングをより詳細に制御する場合にも役立ちます。
パッチがインストールされている場合に `NoReboot` オプションを選択すると、ステータス `InstalledPendingReboot` がパッチに割り当てられます。ただし、マネージドノード自体は、`Non-Compliant` と表示されています。再起動が発生し、`Scan` オペレーションが実行されると、ノードのステータスは `Compliant` に更新されます。
**パッチのインストール追跡ファイル**: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、Systems Manager は、マネージドノードのファイルを管理します。
**重要**
追跡ファイルを削除または変更しないでください。このファイルを削除または破損すると、マネージドノードのパッチコンプライアンスレポートが不正確になります。ファイルを削除または破損した場合は、ノードを再起動し、パッチのスキャンオペレーションを実行してファイルを復元します。
この追跡ファイルは、マネージドノードの以下の場所に保存されます。
+ Linux オペレーティングシステム:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server オペレーティングシステム:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### パラメータ名: `PreInstallHookDocName`
**使用**: オプション。
**デフォルト**: `AWS-Noop`。
`PreInstallHookDocName` パラメータに指定する値は、選択した SSM ドキュメントの名前または Amazon リソースネーム (ARN) です。AWS マネージドドキュメントの名前や、作成したか共有されたカスタム SSM ドキュメントの名前または ARN を指定できます。(別の AWS アカウント から共有されている SSM ドキュメントの場合は、`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` などの完全なリソース ARN を指定する必要があります)。
指定した SSM ドキュメントは、`Install` オペレーションの前に実行され、マネージドノードでパッチ適用が実行される前にアプリケーションのヘルスチェックを行うシェルスクリプトなど、SSM Agent がサポートするアクションを実行します。(アクションの一覧については、「[コマンドドキュメントプラグインリファレンス](documents-command-ssm-plugin-reference.md)」を参照してください)。デフォルトの SSM ドキュメント名は `AWS-Noop` で、マネージドノードに対するオペレーションは実行されません。
カスタム SSM ドキュメントの作成方法については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。
### パラメータ名: `PostInstallHookDocName`
**使用**: オプション。
**デフォルト**: `AWS-Noop`。
`PostInstallHookDocName` パラメータに指定する値は、選択した SSM ドキュメントの名前または Amazon リソースネーム (ARN) です。AWS マネージドドキュメントの名前や、作成したか共有されたカスタム SSM ドキュメントの名前または ARN を指定できます。(別の AWS アカウント から共有されている SSM ドキュメントの場合は、`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` などの完全なリソース ARN を指定する必要があります)。
指定した SSM ドキュメントは、`Install with NoReboot` オペレーション後に実行され、再起動前にサードパーティ製の更新プログラムをインストールするためのシェルスクリプトなど、SSM Agent がサポートするアクションを実行します。(アクションの一覧については、「[コマンドドキュメントプラグインリファレンス](documents-command-ssm-plugin-reference.md)」を参照してください)。デフォルトの SSM ドキュメント名は `AWS-Noop` で、マネージドノードに対するオペレーションは実行されません。
カスタム SSM ドキュメントの作成方法については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。
### パラメータ名: `OnExitHookDocName`
**使用**: オプション。
**デフォルト**: `AWS-Noop`。
`OnExitHookDocName` パラメータに指定する値は、選択した SSM ドキュメントの名前または Amazon リソースネーム (ARN) です。AWS マネージドドキュメントの名前や、作成したか共有されたカスタム SSM ドキュメントの名前または ARN を指定できます。(別の AWS アカウント から共有されている SSM ドキュメントの場合は、`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` などの完全なリソース ARN を指定する必要があります)。
指定した SSM ドキュメントは、マネージドノードの再起動オペレーションの後に実行され、パッチ適用オペレーションの完了後にノードの状態を確認するシェルスクリプトなど、SSM Agent がサポートするアクションを実行します。(アクションの一覧については、「[コマンドドキュメントプラグインリファレンス](documents-command-ssm-plugin-reference.md)」を参照してください)。デフォルトの SSM ドキュメント名は `AWS-Noop` で、マネージドノードに対するオペレーションは実行されません。
カスタム SSM ドキュメントの作成方法については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。
# `AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` で InstallOverrideList パラメータを使用するサンプルシナリオ
`InstallOverrideList` パラメータを使用すると、AWS Systems Manager のツールである Patch Manager の、現在のデフォルトのパッチベースラインで指定されたパッチを上書きできます。このトピックでは、このパラメータを使用して次のことを実現する方法の例を示します。
+ マネージドノードのターゲットグループに異なるパッチセットを適用する。
+ これらのパッチセットを異なる頻度で適用する。
+ 両方の操作に同じパッチベースラインを使用する。
Amazon Linux 2 マネージドノードに 2 つの異なるカテゴリのパッチをインストールするとします。メンテナンスウィンドウを使用して、これらのパッチを異なるスケジュールでインストールします。毎週 1 つのメンテナンスウィンドウを実行し、すべての `Security` パッチをインストールする必要があります。月に 1 回は、別のメンテナンスウィンドウを実行し、使用可能なすべてのパッチ、または `Security` 以外のカテゴリのパッチをインストールする必要があります。
ところが、オペレーティングシステムのデフォルトとして定義できるパッチベースラインは、一度に 1 つだけです。この要件は、あるパッチベースラインでパッチが承認され、別のパッチベースラインでパッチがブロックされる (これによって競合するバージョン間で問題が発生する) 状況を回避するために役立ちます。
次の方法では、同じパッチベースラインを使用しながら、`InstallOverrideList` パラメータを使用して、異なるスケジュールで異なるタイプのパッチをターゲットグループに適用します。
1. デフォルトのパッチベースラインで、`Security` 更新のみが指定されていることを確認します。
1. `AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` を毎週実行するメンテナンスウィンドウを作成します。上書きリストは指定しないでください。
1. 毎月適用するすべてのタイプのパッチの上書きリストを作成し、Amazon Simple Storage Service (Amazon S3) バケットに保存します。
1. 1 か月に 1 回実行する 2 番目のメンテナンスウィンドウを作成します。ただし、このメンテナンスウィンドウで登録する Run Command タスクについては、上書きリストの場所を指定します。
その結果、デフォルトのパッチベースラインで定義されている `Security` パッチのみが毎週インストールされます。利用可能なすべてのパッチや、定義したパッチのサブセットがすべて、毎月インストールされます。
**注記**
IPv6 のみを使用するノードにパッチを適用する場合は、指定された URL がノードから到達可能であることを確認してください。SSM Agent config オプション `UseDualStackEndpoint` が `true` に設定されている場合、S3 の URL を指定するとデュアルスタック S3 クライアントが使用されます。デュアルスタックを使用するためのエージェントの設定の詳細については、「[チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md)」を参照してください。
詳細とサンプルの一覧については、「[パラメータ名: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)」を参照してください。
# BaselineOverride パラメータの使用
AWS Systems Manager のツールである Patch Manager のベースラインオーバーライド機能を使用して、実行時にパッチ適用設定を定義できます。これを行うには、パッチベースラインのリストを備えた JSON オブジェクトを含む Amazon Simple Storage Service (Amazon S3) バケットを指定します。パッチ適用操作では、デフォルトのパッチベースラインのルールを適用する代わりに、ホストオペレーティングシステムに一致する JSON オブジェクトで指定されるベースラインを使用します。
**重要**
`BaselineOverride` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
パッチ適用オペレーションでパッチポリシーが使用される場合を除き、`BaselineOverride` パラメータを使用しても、パラメータで指定されたベースラインのパッチコンプライアンスはオーバーライドされません。出力結果は、AWS Systems Manager のツールである Run Command から Stdout ログに記録されます 結果は、`NON_COMPLIANT` としてマークされているパッケージのみを出力します。つまり、パッケージは `Missing`、`Failed`、`InstalledRejected`、または `InstalledPendingReboot` としてマークされます。
ただし、パッチオペレーションでパッチポリシーが使用される場合、システムは関連付けられた S3 バケットからオーバーライドパラメータを渡し、マネージドノードのコンプライアンスの値は更新されます。パッチポリシーの動作の詳細については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。
**注記**
IPv6 のみを使用するノードにパッチを適用する場合は、指定された URL がノードから到達可能であることを確認してください。SSM Agent config オプション `UseDualStackEndpoint` が `true` に設定されている場合、S3 の URL を指定するとデュアルスタック S3 クライアントが使用されます。デュアルスタックを使用するためのエージェントの設定の詳細については、「[チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md)」を参照してください。
## スナップショット ID またはインストールオーバーライドリストパラメータでパッチベースラインオーバーライドを使用する
パッチベースラインオーバーライドが注目に値する動作をするケースが 2 つあります。
**ベースラインオーバーライドとスナップショット ID を同時に使用する**
スナップショット ID により、特定のパッチ適用コマンドのすべてのマネージドノードがすべて同じことを適用するようにします。例えば、一度に 1,000 個のノードにパッチを適用すると、パッチは同じになります。
スナップショット ID とパッチベースラインオーバーライドの両方を使用する場合、スナップショット ID はパッチベースラインオーバーライドよりも優先されます。ベースラインオーバーライドルールは引き続き使用されますが、評価されるのは 1 回だけです。前の例では、1,000 マネージドノード間のパッチは常に同じになります。パッチ適用操作の途中で参照先の S3 バケット内の JSON ファイルを別のものに変更した場合、適用されたパッチは同じままになります。これは、スナップショット ID が指定されたためです。
**ベースラインオーバーライドとインストールオーバーライドリストを同時に使用する**
これら 2 つのパラメータを同時に使用することはできません。両方のパラメータが指定されると、パッチ適用ドキュメントは失敗し、マネージドノードに対するスキャンまたはインストールは実行されません。
## コードの例
次の Python のコード例は、パッチベースラインオーバーライドを生成する方法を示しています。
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
これにより、次のようなパッチベースラインオーバーライドが生成されます。
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```