• 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 AWS Systems Manager のツールである Patch Manager は、セキュリティ関連の更新およびその他の種類の更新の両方を使用してマネージドノードにパッチを適用するプロセスを自動化します。 **注記** Systems Manager は、AWS Systems Manager のツールである Quick Setup で*パッチポリシー*をサポートしています。パッチポリシーの使用は、パッチ適用オペレーションの設定向けに推奨される方法です。1 つのパッチポリシー設定を使用して、組織内のすべてのリージョンにおける全アカウント、選択したアカウントとリージョンのみ、または 1 つのアカウントとリージョンのペアにパッチを定義できます。詳細については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。 Patch Manager を使用すると、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。Patch Manager を使用して、Windows ノードにサービスパックをインストールしたり、Linux ノードでマイナーバージョンのアップグレードを実行したりすることができます。オペレーティングシステムのタイプ別に、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのフリート、エッジデバイス、オンプレミスサーバー、および仮想マシン (VM) にパッチを適用できます。「[Patch Manager の前提条件](patch-manager-prerequisites.md)」に記載されているように、これにはサポートされているバージョンのオペレーティングシステムが複数含まれます。インスタンスをスキャンし、見つからないパッチのレポートのみを表示できます。または、すべての見つからないパッチをスキャンして自動的にインストールできます。Patch Manager の使用を開始するには、[Systems Manager コンソール](https://console.aws.amazon.com//systems-manager/patch-manager)を開きます。ナビゲーションペインで、**[Patch Manager]** を選択します。 AWS では、Patch Manager で公開する前にパッチをテストしません。また、Patch Manager では、Windows Server 2016～Windows Server 2019、Red Hat Enterprise Linux (RHEL) 7.0～RHEL 8.0 などのオペレーティングシステムのメジャーバージョンのアップグレードはサポートされていません。 パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS ([共通脆弱性評価システム](https://www.first.org/cvss/)) のような サードパーティのソースからの、または NVD ([National Vulnerability Database](https://nvd.nist.gov/vuln)) がリリースしたメトリクスからの重要度レベルは取得しません。 ## Patch Manager はどのように組織にとってメリットになりますか? Patch Manager は、セキュリティ関連の更新およびその他の種類の更新の両方を使用してマネージドノードにパッチを適用するプロセスを自動化します。これにはいくつかの主な利点があります。 + **一元化されたパッチ適用コントロール** – パッチポリシーを使用して、組織内のすべてのリージョン、特定のアカウントとリージョン、または単一のアカウントとリージョンのペアのすべてのアカウントに対して、定期的なパッチ適用オペレーションを設定できます。 + **フレキシブルなパッチ操作** - スキャンするインスタンスを選択し、検出されなかったパッチのレポートのみを表示できます。または、すべての検出されないパッチをスキャンして自動的にインストールできます。 + **包括的なコンプライアンスレポート** – スキャン操作後、パッチコンプライアンスに違反しているマネージドノードと不足しているパッチに関する詳細情報を表示できます。 + **クロスプラットフォームサポート** – Patch Manager は、さまざまな Linux ディストリビューション、macOS、Windows Server など、複数のオペレーティングシステムをサポートしています。 + **カスタムパッチベースライン** – インストールが承認されるパッチを指定するカスタムパッチベースラインを使用して、組織のパッチコンプライアンスを構成する内容を定義できます。 + **他の AWS サービスとの統合** – Patch Manager は AWS Organizations、AWS Security Hub CSPM、AWS CloudTrail、および AWS Config と統合され、管理とセキュリティを強化します。 + **確定的なアップグレード** – Amazon Linux 2023 など、オペレーティングシステム用のバージョン管理されたリポジトリによる確定的なアップグレードのサポート。 ## Patch Manager はどのようなユーザーに適していますか? Patch Manager は、以下のユーザー向けに設計されています。 + マネージドノードのフリート全体でパッチコンプライアンスを維持する必要がある IT 管理者 + インフラストラクチャ全体のパッチコンプライアンスステータスを可視化する必要があるオペレーションマネージャー + 自動パッチ適用ソリューションを大規模に実装したいクラウドアーキテクト + パッチ適用を運用ワークフローに統合する必要がある DevOps エンジニア + 一元化されたパッチ管理を必要とするマルチアカウント/マルチリージョンのデプロイを行う組織 + AWS マネージドノード、エッジデバイス、オンプレミスサーバー、仮想マシンのセキュリティ体制と運用状態を維持する責任者 ## Patch Manager の主な特徴は何ですか? Patch Manager には、いくつかの主要な機能があります。 + **パッチポリシー** – AWS Organizations との統合を通じて単一のポリシーを使用して、複数の AWS アカウント およびリージョンにまたがるパッチ適用オペレーションを設定します。 + **カスタムパッチベースライン** – リリースから数日以内にパッチを自動承認するためのルールと、承認および拒否されたパッチリストを定義します。 + **複数のパッチ適用方法** – 特定のニーズに合わせて、パッチポリシー、メンテナンスウィンドウ、またはオンデマンドの「今すぐパッチ適用」オペレーションから選択します。 + **コンプライアンスレポート** – CSV 形式で Amazon S3 バケットに送信できるパッチコンプライアンスステータスに関する詳細なレポートを生成します。 + **クロスプラットフォームサポート** – Windows Server 全体でオペレーティングシステムとアプリケーションの両方に、さまざまな Linux ディストリビューション、および macOS にパッチを適用します。 + **スケジューリングの柔軟性** – カスタム CRON 式または Rate 式を使用してパッチをスキャンしてインストールするためのさまざまなスケジュールを設定します。 + **ライフサイクルフック** – Systems Manager ドキュメントを使用して、パッチ適用操作の前後にカスタムスクリプトを実行します。 + **セキュリティの焦点** – デフォルトでは、Patch Manager は利用可能なすべてのパッチをインストールするのではなく、セキュリティ関連の更新に焦点を当てています。 + **Rate コントロール** – パッチ適用オペレーションの同時実行数とエラーのしきい値を設定して、オペレーションへの影響を最小限に抑えます。 ## Patch Manager におけるコンプライアンスとは。 Systems Manager フリート内のマネージドノードの *パッチコンプライアンス* を構成するもののベンチマークは、AWS、オペレーティングシステム (OS) ベンダー、またはセキュリティコンサルティング会社などのサードパーティーによって定義されていません。 代わりに、*パッチベースライン* の組織またはアカウントのマネージドノードに対するパッチコンプライアンスの意味を定義します。パッチベースラインは、マネージドノードにパッチをインストールする必要があるルールを指定する構成です。パッチベースラインで指定した承認基準を満たすすべてのパッチが最新である場合、マネージドノードはパッチに準拠します。 パッチベースラインに *準拠* しているからといって、マネージドノードが必ずしも *安全* であるとは限らないことに注意してください。準拠とは、パッチベースラインで定義された、*使用可能* で、かつ *承認済み* のパッチがノードにインストールされていることを意味します。マネージドノードの全体的なセキュリティは、Patch Manager の範囲外の多くの要因によって決まります。詳細については、「[AWS Systems Manager でのセキュリティ](security.md)」を参照してください。 各パッチベースラインは、Red Hat Enterprise Linux (RHEL)、macOS、または Windows Server など、サポートされている特定のオペレーティングシステム (OS) タイプの構成です。パッチベースラインは、サポートされているすべてのバージョンの OS のパッチ適用ルールを定義することも、RHEL 7.8 および RHEL 9.3 など、指定したもののみに制限することもできます。 パッチベースラインでは、特定の分類と重要度レベルのすべてのパッチのインストールが承認されるように指定できます。例えば、`Security` として分類されるすべてのパッチを含みますが、`Bugfix` や `Enhancement` などの他の分類を除外することもできます。また、重要度が `Critical` のすべてのパッチを含み、`Important` や `Moderate` などの他のパッチを除外することもできます。 また、Windows Server に `KB2736693`、または Amazon Linux 2023 (AL2023)に `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` など、承認または拒否する特定のパッチのリストに IDs を追加することで、パッチベースラインでパッチを明示的に定義することもできます。オプションで、パッチが利用可能になってからパッチ適用を待機する特定の日数を指定できます。Linux および macOS では、パッチベースラインルールで定義されているパッチの代わりに、コンプライアンス用のパッチの外部リスト (Install Override リスト) を指定するオプションがあります。 パッチ適用オペレーションを実行すると、Patch Manager はマネージドノードに現在適用されているパッチとパッチベースライン、または Install Override リストで設定されたルールに従い適用する必要があるパッチを比較します。マネージドノードに不足しているパッチのレポートのみを表示する Patch Manager (`Scan` オペレーション) か、不足しているパッチをすべて自動的にインストールする Patch Manager (`Scan and install` オペレーション) を選択できます。 **注記** パッチコンプライアンスデータは、最後に成功したパッチ適用オペレーションからのポイントインタイムスナップショットを表します。各コンプライアンスレポートには、コンプライアンスステータスが計算されたときを識別するキャプチャ時間が含まれています。コンプライアンスデータを確認するときは、キャプチャ時間を考慮して、オペレーションが予期した通りに実行されたかどうかを判断します。 Patch Manager は、パッチ適用オペレーションに使用できる事前定義されたパッチベースラインを提供します。ただし、これらの事前定義された設定は、推奨されるベストプラクティスではなく、例として提供されています。フリートのパッチコンプライアンスを構成するものをより細かく制御するために、独自のカスタムパッチベースラインを作成することをお勧めします。 パッチベースラインに関する詳細は、以下のトピックを参照してください。 + [事前定義されたパッチベースラインおよびカスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md) + [承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md) + [AWS の定義済みパッチベースラインの表示](patch-manager-view-predefined-patch-baselines.md) + [カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md) + [パッチコンプライアンスレポートの使用](patch-manager-compliance-reports.md) ## プライマリコンポーネント Patch Manager ツールを使用開始する前に、ツールのパッチ適用オペレーションの主なコンポーネントと機能を理解しておく必要があります。 **パッチベースライン** 承認および拒否されたパッチのオプションリストに加え、Patch Manager は*パッチベースライン*を使用します。これにはリリースから数日以内にパッチを自動承認するためのルールが含まれます。パッチ適用オペレーションを実行すると、Patch Manager はマネージドノードに現在適用されているパッチとパッチベースラインで設定されたルールに従い適用する必要があるパッチを比較します。マネージドノードに不足しているパッチのレポートのみを表示する Patch Manager (`Scan` オペレーション) か、不足しているパッチをすべて自動的にインストールする Patch Manager (`Scan and install` オペレーション) を選択できます。 **パッチ適用オペレーションメソッド** 現在、Patch Manager で `Scan` および `Scan and install` オペレーションを実行する場合、次の 4 つのメソッドがあります。 + **(推奨) Quick Setup で設定されるパッチポリシー** — AWS Organizations との統合に基づいて、1 つのパッチ定義ポリシーで組織全体 (複数の AWS アカウントおよびそれらが運用されているすべての AWS リージョンを含む) のパッチ定義スケジュールおよびパッチベースラインを定義できます。また、組織内の一部の組織単位 (OU) のみにパッチポリシーを適用することもできます。1 つのパッチポリシーを使用して、さまざまなスケジュールでスキャンおよびインストールを実行できます。詳細については、「[Quick Setup パッチポリシーを使用して組織内のインスタンスのためにパッチ適用を設定する](quick-setup-patch-manager.md)」および「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。 + **Quick Setup で設定されるホスト管理オプション** — AWS Organizations との統合によりホスト管理設定もサポートされるため、最大で組織全体に対してパッチ適用オペレーションを実行できます。ただしこのオプションでできるのは、現在のデフォルトのパッチベースラインを使用して不足しているパッチをスキャンし、結果をコンプライアンスレポートで提供することに限られます。このオペレーションメソッドでパッチをインストールすることはできません。詳細については、「[Quick Setup を使用して Amazon EC2 ホスト管理を設定する](quick-setup-host-management.md)」を参照してください。 + **パッチの `Scan` または `Install` タスクを実行するためのメンテナンスウィンドウ** — Maintenance Windows という Systems Manager ツールで設定できるメンテナンスウィンドウでは、定義したスケジュールに従いさまざまなタイプのタスクを実行するように設定を行えます。Run Command タイプのタスクを使用すると、`Scan` または `Scan and install` タスク、選択したマネージドノードのセットを実行できます。メンテナンスウィンドウの各タスクでは、AWS アカウント と AWS リージョン の 1 つのペアでのみマネージドノードをターゲットにできます。詳細については、「[チュートリアル: コンソールを使用してパッチ用メンテナンスウィンドウを作成する](maintenance-window-tutorial-patching.md)」を参照してください。 + Patch Manager での**オンデマンドの**[今すぐパッチ適用]**オペレーション** — **[Patch now]** (今すぐパッチ適用) オプションを使用すると、マネージドノードにできるだけ早くパッチ適用する必要がある場合に、スケジュール設定をバイパスすることができます。**[Patch now]** (今すぐパッチ適用) を使用して、`Scan` または `Scan and install` オペレーションを実行するか、どのマネージドノードでオペレーションを実行するかを指定します。また、パッチ適用オペレーション中に、Systems Manager ドキュメント (SSM ドキュメント) をライフサイクルフックとして実行することもできます。**[Patch now]** (今すぐパッチ適用) の各オペレーションでは、AWS アカウントと AWS リージョンの 1 つのペアでのみマネージドノードノードをターゲットにできます。詳細については、「[マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md)」を参照してください。 **コンプライアンスレポート** `Scan` オペレーションの後、Systems Manager コンソールを使用して、パッチのコンプライアンス違反であるマネージドノード、およびこれらの各ノードで不足しているパッチについての情報を確認できます。任意の Amazon Simple Storage Service (Amazon S3) バケットに送信する .csv 形式のパッチコンプライアンスレポートを生成することもできます。1 回限りのレポートを生成することも、定期的なスケジュールでレポートを生成することもできます。単一マネージドノードの場合、レポートにはノードのすべてのパッチの詳細が含まれます。すべてのマネージドノードに関するレポートでは、欠けているパッチの数についての概要のみが提供されます。レポートが生成されたら、Amazon Quick などのツールを使用してデータをインポートおよび分析できます。詳細については、「[パッチコンプライアンスレポートの使用](patch-manager-compliance-reports.md)」を参照してください。 **注記** パッチポリシーを使用して生成されたコンプライアンス項目の実行タイプは、`PatchPolicy` です。パッチポリシーのオペレーションで生成されないコンプライアンス項目の実行タイプは、`Command` です。 **統合** Patch Manager は、以下のような他の AWS のサービス サービスと統合します。 + **AWS Identity and Access Management (IAM)** — IAM を使用して、Patch Manager オペレーションにアクセスできるユーザー、グループ、ロールを制御できます。詳細については、「[AWS Systems Manager と IAM の連携方法](security_iam_service-with-iam.md)」および「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。 + **AWS CloudTrail** — CloudTrail を使用して、ユーザー、ロール、またはグループによって開始された監査可能なパッチ適用オペレーションのイベント履歴を記録できます。詳細については、「[AWS CloudTrail による AWS Systems Manager API コールのログ記録](monitoring-cloudtrail-logs.md)」を参照してください。 + **AWS Security Hub CSPM** — Patch Manager からのパッチコンプライアンスデータを AWS Security Hub CSPM に送信できます。Security Hub CSPM では、高優先度のセキュリティアラートとコンプライアンス状況を包括的に確認できます。また、フリートのパッチ適用状況も監視できます。詳細については、「[Patch Managerと AWS Security Hub CSPM の統合](patch-manager-security-hub-integration.md)」を参照してください。 + **AWS Config** — Amazon EC2 インスタンスの管理データを Patch Manager ダッシュボードに表示するように AWS Config の記録を設定できます。詳細については、「[パッチダッシュボードの概要の表示](patch-manager-view-dashboard-summaries.md)」を参照してください。 **Topics** + [Patch Manager はどのように組織にとってメリットになりますか?](#how-can-patch-manager-benefit-my-organization) + [Patch Manager はどのようなユーザーに適していますか?](#who-should-use-patch-manager) + [Patch Manager の主な特徴は何ですか?](#what-are-the-main-features-of-patch-manager) + [Patch Manager におけるコンプライアンスとは。](#patch-manager-definition-of-compliance) + [プライマリコンポーネント](#primary-components) + [Quick Setup でのパッチポリシー設定](patch-manager-policies.md) + [Patch Manager の前提条件](patch-manager-prerequisites.md) + [Patch Managerの動作の仕組み](patch-manager-patching-operations.md) + [マネージドノードへのパッチ適用のための SSM コマンドドキュメント](patch-manager-ssm-documents.md) + [パッチベースライン](patch-manager-patch-baselines.md) + [Amazon Linux 2 マネージドノードで Kernel Live Patching を使用](patch-manager-kernel-live-patching.md) + [コンソールを使用した Patch Manager リソースとコンプライアンスの操作](patch-manager-console.md) + [AWS CLI を使用して Patch Manager リソースを操作する](patch-manager-cli-commands.md) + [AWS Systems Manager Patch Manager のチュートリアル](patch-manager-tutorials.md) + [Patch Manager のトラブルシューティング](patch-manager-troubleshooting.md) # Quick Setup でのパッチポリシー設定 AWS では、*パッチポリシー*を使用して組織と AWS アカウントのパッチ適用を設定することが推奨されています。パッチポリシーは、2022 年 12 月に Patch Manager に導入されました。 パッチポリシーは、AWS Systems Manager のツールである Quick Setup を使用して設定します。パッチポリシーを使用すると、以前のパッチ適用を設定する方法に比べて、パッチ適用オペレーションをより広範囲かつ一元的に制御できます。パッチポリシーは、サポート対象バージョンの Linux、macOS、Windows Server など、[Patch Manager がサポートしているすべてのオペレーティングシステム](patch-manager-prerequisites.md#pm-prereqs)で使用できます。パッチポリシーの作成方法については、「[Quick Setup パッチポリシーを使用して組織内のインスタンスのためにパッチ適用を設定する](quick-setup-patch-manager.md)」を参照してください。 ## パッチポリシーの主な機能 ノードにパッチを適用する他の方法を使用せずに、パッチポリシーを使用して次に示す主な機能を活用してください。 + **一度にセットアップ** – メンテナンスウィンドウや State Manager アソシエーションを使用してパッチ適用オペレーションをセットアップするには、Systems Manager コンソールのさまざまな部分で複数のタスクを実行する必要があります。パッチポリシーを使用すると、すべてのパッチ適用オペレーションを 1 つのウィザードでセットアップできます。 + **複数アカウント/複数リージョンのサポート** – メンテナンスウィンドウ、State Manager アソシエーションや Patch Manager の **[Patch now]** (今すぐパッチ適用) 機能を使用すると、1 組の AWS アカウント-AWS リージョン ペアのマネージドノードを対象にすることしかできません。複数のアカウントと複数のリージョンを使用している場合、アカウントとリージョンの各ペアでセットアップタスクを実行する必要があるため、セットアップとメンテナンスのタスクに多大な時間がかかる可能性があります。ただし、AWS Organizations を使用すると、1 つのパッチポリシーを設定して、すべての AWS アカウント のすべての AWS リージョン のすべてのマネージドノードに適用されるようにできます。または、選択したアカウントとリージョンの一部の組織単位 (OU) にのみパッチポリシーを適用することもできます。パッチポリシーは、必要に応じて 1 つのローカルアカウントに適用することもできます。 + **組織レベルでのインストールをサポート** – Quick Setup の既存のホスト管理設定オプションでは、マネージドノードを毎日スキャンしてパッチコンプライアンスを確認することができます。ただし、このスキャンは予め決められた時間に行われ、パッチのコンプライアンス情報のみが得られます。パッチのインストールは実行されません。パッチポリシーを使用して、スキャンおよびインストールのさまざまなスケジュールを指定できます。カスタムの CRON 式または Rate 式を使用して、これらのオペレーションの頻度と時間を選択することもできます。例えば、未適用のパッチがないか毎日スキャンして、定期的に更新されるコンプライアンス情報を取得できます。ただし、不要なダウンタイムを避けるため、インストールスケジュールは週に 1 回にすることもできます。 + **パッチベースラインの選択の簡略化** – パッチポリシーには引き続きパッチベースラインが組み込まれており、パッチベースラインの設定方法に変更はありません。ただし、パッチポリシーを作成または更新するときは、オペレーティングシステム (OS) の種類ごとに使用する AWS マネージドベースラインまたはカスタムベースラインを 1 つのリストで選択できます。OS の種類ごとにデフォルトベースラインを別々のタスクで指定する必要はありません。 **注記** パッチポリシーに基づいてパッチ適用オペレーションが実行される場合、`AWS-RunPatchBaseline` SSM ドキュメントが使用されます。詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。 **関連情報** 「[Systems Manager Quick Setup を使用して AWS Organization 全体で一元的にパッチオペレーションをデプロイする](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/)」(AWS クラウド運用と移行に関するブログ) ## パッチポリシーとのその他の違い 以前のパッチ適用設定の方法の代わりにパッチポリシーを使用する場合に注意すべきその他の相違点は次のとおりです。 + **パッチグループは不要** – 以前のパッチ適用オペレーションでは、パッチグループに属するように複数のノードをタグ付けし、そのパッチグループに使用するパッチベースラインを指定できました。パッチグループがない場合、Patch Manager では、OS の種類に対する現在のデフォルトのパッチベースラインを使用してパッチが適用されました。パッチポリシーを使用すると、パッチグループをセットアップして管理する必要がなくなります。 **注記** 2022 年 12 月 22 日にパッチポリシーのサポートがリリースされる前にパッチグループを使用していなかったアカウントとリージョンのペアでは、コンソールでパッチグループの機能がサポートされていません。パッチグループの機能は、この日付より前にパッチグループの使用を開始したアカウントとリージョンのペアで引き続き使用できます。 + **[Configure patching] (パッチ適用を設定) ページが削除されました** – パッチポリシーがリリースされる前は、**[Configure patching]** (パッチ適用を設定) ページで、パッチを適用するノード、パッチ適用スケジュール、およびパッチ適用オペレーションのデフォルトを指定できました。このページは Patch Manager から削除されました。これらのオプションは、パッチポリシーで指定することになりました。 + **[Patch now] (今すぐパッチ適用) サポートなし** – 引き続き、ノードをオンデマンドでパッチできるのは、一度に 1 組の AWS アカウント-AWS リージョン ペアに限られています。詳細については、「[マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md)」を参照してください。 + **パッチポリシーとコンプライアンス情報** – パッチ適用ポリシーの設定に従ってマネージドノードのコンプライアンスをスキャンすると、コンプライアンスデータが利用可能になります。他のコンプライアンススキャン方法と同じ方法でデータを表示および操作できます。組織全体または複数の組織単位のパッチポリシーをセットアップできますが、AWS アカウント-AWS リージョン ペアそれぞれのコンプライアンス情報はペアごとに個別に報告されます。詳細については、「[パッチコンプライアンスレポートの使用](patch-manager-compliance-reports.md)」を参照してください。 + **関連付けコンプライアンスステータスとパッチポリシー** – Quick Setup パッチポリシーの下にあるマネージドノードのパッチステータスは、そのノードの State Manager 関連付け実行ステータスと一致します。関連付け実行ステータスが `Compliant` の場合、マネージドノードのパッチステータスも `Compliant` とマークされます。関連付け実行ステータスが `Non-Compliant` の場合、マネージドノードのパッチステータスも `Non-Compliant` とマークされます。 ## パッチポリシーがサポートされている AWS リージョン Quick Setup でのパッチポリシー設定は、現在、次のリージョンでサポートされています。 + 米国東部 (オハイオ) (us-east-2) + 米国東部 (バージニア北部) (us-east-1) + 米国西部 (北カリフォルニア) (us-west-1) + 米国西部 (オレゴン) (us-west-2) + アジアパシフィック (ムンバイ) (ap-south-1) + アジアパシフィック (ソウル) (ap-northeast-2) + アジアパシフィック (シンガポール) (ap-southeast-1) + アジアパシフィック (シドニー) (ap-southeast-2) + アジアパシフィック (東京) (ap-northeast-1) + カナダ (中部) (ca-central-1) + ヨーロッパ (フランクフルト) (eu-central-1) + 欧州 (アイルランド) (eu-west-1) + ヨーロッパ (ロンドン) (eu-west-2) + 欧州 (パリ) (eu-west-3) + 欧州 (ストックホルム) (eu-north-1) + 南米 (サンパウロ) (sa-east-1) # Patch Manager の前提条件 AWS Systems Manager のツールである Patch Manager を使用する前に、必要な前提条件を満たしていることを確認してください。 **Topics** + [SSM Agent バージョン](#agent-versions) + [Python バージョン](#python-version) + [その他のパッケージ要件](#additional-package-requirements) + [パッチソースへの接続](#source-connectivity) + [S3 エンドポイントアクセス](#s3-endpoint-access) + [パッチをローカルにインストールするためのアクセス許可](#local-installation-permissions) + [Patch Manager でサポートされているオペレーティングシステム](#supported-os) ## SSM Agent バージョン Patch Manager で管理するマネージドノードで SSM Agent のバージョン 2.0.834.0 以降が稼働しています。 **注記** 新しいツールが Systems Manager に追加されるか、既存のツールが更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種ツールや機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。GitHub の「[SSM Agent リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)」ページをサブスクライブすると、SSM Agent の更新に関する通知を受け取ることができます。 ## Python バージョン macOS とほとんどの Linux オペレーティングシステム (OS) では、現在、Patch Manager は Python バージョン 2.6～3.12 をサポートします。AlmaLinux、Debian Server、Ubuntu Server の OS では、サポートされるバージョンの Python 3 (3.0～3.12) が必要です。 ## その他のパッケージ要件 DNF ベースのオペレーティングシステムの場合、リポジトリ情報とパッチファイルを解凍するために `zstd`、`xz`、`unzip` のユーティリティが必要になることがあります。DNF ベースのオペレーティングシステムには、Amazon Linux 2023、Red Hat Enterprise Linux 8 以降のバージョン、Oracle Linux 8 以降のバージョン、Rocky Linux、AlmaLinux、および CentOS 8 以降のバージョンが含まれます。`No such file or directory: b'zstd'` や `No such file or directory: b'unxz'` のようなエラーまたは `unzip` の欠落によるパッチ適用の失敗が表示された場合は、これらのユーティリティをインストールする必要があります。`zstd`、`xz`、`unzip` は、以下を実行することによってインストールできます。 ``` dnf install zstd xz unzip ``` ## パッチソースへの接続 マネージドノードがインターネットに直接接続しておらず、VPC エンドポイントで Amazon Virtual Private Cloud (Amazon VPC) を使用している場合は、ノードがソース パッチ リポジトリ (repos) に確実にアクセスできるようにしておく必要があります。Linux ノードでは、通常、パッチ更新はノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用するために、ノードはレポジトリに接続できる必要があります。詳細については、「[セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md)」を参照してください。 IPv6 のみの環境で実行されているノードにパッチを適用する場合は、ノードがパッチソースに接続されていることを確認します。パッチ適用の実行からの Run Command 出力をチェックして、アクセスできないリポジトリに関する警告を確認できます。DNF ベースのオペレーティングシステムでは、 `/etc/dnf/dnf.conf` で `skip_if_unavailable` オプションが `True` に設定されている場合、使用できないリポジトリをパッチ適用中にスキップするように設定できます。DNF ベースのオペレーティングシステムには、Amazon Linux 2023、Red Hat Enterprise Linux 8 以降のバージョン、Oracle Linux 8 以降のバージョン、Rocky Linux、AlmaLinux、および CentOS 8 以降のバージョンが含まれます。Amazon Linux 2023 では、`skip_if_unavailable` オプションはデフォルトで `True` に設定されています。 **CentOS Stream: `EnableNonSecurity`フラグを有効にする** CentOS Stream ノードは、更新通知の概念を使用するパッケージマネージャーとして DNF を使用します。更新通知は、特定の問題を修正するパッケージの集合にすぎません。 ただし、CentOS Stream のデフォルトリポジトリは更新通知で設定されません。これは、Patch Manager で CentOS Stream のデフォルトリポジトリのパッケージが検出されないことを意味します。Patch Manager を許可して更新通知に含まれていないパッケージを処理するには、パッチベースラインルールで `EnableNonSecurity` フラグを有効にする必要があります。 **Windows Server: Windows Update カタログまたは Windows Server Update Services (WSUS) に確実に接続できるようにする** Windows Server マネージドノードは、Windows Update カタログまたは Windows Server Update Services (WSUS) に接続できなくてはなりません。ノードがインターネットゲートウェイ、NAT ゲートウェイ、または NAT インスタンスを介して [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) に接続されていることを確認します。WSUS を使用している場合は、ノードがお使いの環境内の WSUS サーバーに接続されていることを確認します。詳細については、「[問題: マネージドノードに Windows Update カタログまたは WSUS へのアクセスがない](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access)」を参照してください。 ## S3 エンドポイントアクセス マネージドノードが動作するのがプライベート ネットワークまたは公開ネットワークのいずれであるかにかかわらず、必要な AWS マネージド Amazon Simple Storage Service (Amazon S3) バケットにアクセスできない場合、パッチ適用オペレーションは失敗します。マネージドノードにアクセスする必要がある S3 バケットの詳細については、「[SSM Agent と AWS マネージド S3 バケットとの通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)」および「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](setup-create-vpc.md)」を参照してください。 ## パッチをローカルにインストールするためのアクセス許可 Windows Server および Linux オペレーティングシステムでは、Patch Manager はそれぞれ Administrator およびルートユーザーアカウントを使用してパッチをインストールします。 しかし、macOS では、Brew と Brew Cask について、Homebrew はルートユーザーアカウントで実行されるコマンドをサポートしていません。その結果、Patch Manager は Homebrew ディレクトリの所有者、または Homebrew ディレクトリの所有者グループに属する有効なユーザーとして、Homebrew コマンドを照会して実行します。したがって、パッチをインストールするには、`homebrew` ディレクトリの所有者にも `/usr/local` ディレクトリに対する再帰的な所有者のアクセス許可が必要です。 **ヒント** 次のコマンドは、指定されたユーザーにこのアクセス許可を付与します。 ``` sudo chown -R $USER:admin /usr/local ``` ## Patch Manager でサポートされているオペレーティングシステム Patch Manager のツールでは、Systems Manager の他のツールでサポートされているのと同じオペレーティングシステムのバージョンがすべてサポートされるわけではありません。(Systems Manager でサポートされるオペレーティングシステムの詳細なリストについては、「[System Manager でサポートされているオペレーティングシステム](operating-systems-and-machine-types.md#prereqs-operating-systems)」を参照してください)。そのため、Patch Manager で使用するマネージドノードで、次の表に示すオペレーティングシステムのいずれかが実行されていることを確認してください。 **注記** Patch Manager は、インストール可能なパッチを取得するために、Windows Update カタログや Windows Server Update Services for Windows など、マネージドノードに設定されているパッチリポジトリに依拠します。したがって、サポート終了 (EOL) のオペレーティングシステムバージョンでは、新しい更新プログラムが利用できない場合、Patch Manager は新しい更新プログラムについてレポートできない可能性があります。これは、Linux ディストリビューションのメンテナー、Microsoft、もしくは Apple によって新しい更新プログラムがリリースされていないか、またはマネージドノードに新しい更新プログラムにアクセスするための適切なライセンスがないことが原因である可能性があります。 サポート終了 (EOL) に達した OS バージョンを使用しないことを強くお勧めします。AWS を始めとする OS ベンダーは、通常、EOL に達したバージョンのセキュリティパッチやその他の更新を提供しません。EOL システムを使用し続けると、セキュリティ修正を始めとするアップグレードを適用できないリスクとその他の運用上の問題が大幅に増加します。AWS は、EOL に達した OS バージョンで Systems Manager の機能テストを行いません。 Patch Manager は、マネージドノードで使用可能なパッチに対するコンプライアンスステータスを報告します。したがって、インスタンスが EOL オペレーティングシステムを実行しており、更新プログラムが利用できない場合、Patch Manager はパッチ適用オペレーション用に設定されたパッチベースラインに応じて、ノードが準拠していると報告する可能性があります。 | オペレーティングシステム | 詳細 | | --- | --- | | Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-prerequisites.html) | | macOS | *macOS は Amazon EC2 インスタンスでのみサポートされています。* 13.0～13.7 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia) macOSOS アップデート Patch Manager は 13.1 から 13.2 など macOS のオペレーティングシステム (OS) のアップデートやアップグレードはサポートしていません。macOS の OS バージョンを更新するには、Apple に組み込まれている OS アップグレードメカニズムを使用することをおすすめします。詳細については、Apple デベロッパードキュメンテーションウェブサイトの「[Device Management](https://developer.apple.com/documentation/devicemanagement)」を参照してください。 HomeBrew サポート Patch Manager では、オープンソースのソフトウェアパッケージ管理システムである Homebrew を、次のいずれかのデフォルトのインストール場所にインストールする必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-prerequisites.html) Homebrew がインストールされていない場合、Patch Manager を使用したパッチ適用オペレーションが正しく機能しません。 リージョンのサポート すべての AWS リージョン において macOS はサポートされていません。macOS の Amazon EC2 サポートの詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 Mac インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)」を参照してください。 macOS エッジデバイス AWS IoT Greengrass コアデバイスの SSM Agent は、macOS ではサポートされていません。macOS エッジデバイスをパッチするために Patch Manager が使用できません。 | | Server | Windows Server 2012〜Windows Server 2025 (R2 バージョンを含む)。 AWS IoT Greengrass コアデバイスの SSM Agent は、Windows 10 ではサポートされていません。Windows 10 エッジデバイスをパッチするために Patch Manager が使用できません。 Windows Server 2012 および 2012 R2 のサポート Windows Server 2012 および 2012 R2 は、2023 年 10 月 10 日にサポートが終了しました。これらのバージョンで Patch Manager を使用する場合、Microsoft の拡張セキュリティ更新プログラム (ESU) も使用することをお勧めします。詳細については、Microsoft ウェブサイトの「[Windows Server 2012 および 2012 R2 のサポート終了](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support)」を参照してください。 | # Patch Managerの動作の仕組み このセクションでは、サポートされているオペレーティングシステム別に、どのパッチをどのようにインストールするかについて、AWS Systems Manager のツールである Patch Manager で決定する方法を技術的に詳しく説明します。また、Linux オペレーティングシステムの場合に、マネージドノードに設定されたデフォルト以外のパッチ用に、カスタムのパッチベースラインでソースリポジトリを指定する方法についても説明します。さらに、Linux オペレーティングシステムのディストリビューション別に、パッチベースラインルールがどのように動作するかについて詳しく説明します。 **注記** 以下のトピックの情報は、パッチ適用オペレーションに使用する設定の方法や種類に関係なく適用されます。 Quick Setup で設定されているパッチポリシー Quick Setup で設定されているホスト管理オプション パッチ `Scan` または `Install` のタスクを実行するためのメンテナンスウィンドウ オンデマンドの **[Patch now]** (今すぐパッチ適用) オペレーション **Topics** + [パッケージのリリース日と更新日の計算方法](patch-manager-release-dates.md) + [セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md) + [代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md) + [パッチのインストール方法](patch-manager-installing-patches.md) + [Linux ベースシステムでのパッチベースラインルールの動作方法](patch-manager-linux-rules.md) + [Linux と Windows Server のパッチ適用オペレーションの違い](patch-manager-windows-and-linux-differences.md) # パッケージのリリース日と更新日の計算方法 **重要** このページの情報は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの Amazon Linux 2 および Amazon Linux 2023 オペレーティングシステム (OS) に適用されます。Amazon Web Services では、これらの OS タイプのパッケージが作成、メンテナンスされます。他のオペレーティングシステムのメーカーがパッケージとリポジトリをどのように管理するかは、リリース日と更新日の計算方法に影響します。Red Hat Enterprise Linux などの Amazon Linux 2 および Amazon Linux 2023 以外の OS における、パッケージの更新方法とメンテナンス方法については、製造元のマニュアルを参照してください。 ほとんどの OS タイプでは、作成した[カスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)の設定で、特定の日数が経過するとパッチのインストールが自動承認されるように指定できます。AWS には、7 日間の自動承認日を含む、事前定義済みのパッチベースラインがいくつか用意されています。 自動承認の遅延とは、パッチがリリースされてから自動承認されて適用されるまでの待機日数です。たとえば、`CriticalUpdates` 分類を使用してルールを作成し、7 日間の自動承認遅延を設定します。その結果、リリース日または最終更新日が 7 月 7 日の新しい重大なパッチは 7 月 14 日に自動的に承認されます。 Amazon Linux 2 と Amazon Linux 2023 での自動承認遅延による予期しない結果を避けるには、リリース日と更新日の計算方法を理解することが重要です。 **注記** Amazon Linux 2 または Amazon Linux 2023 リポジトリがパッケージのリリース日情報を提供しない場合、Patch Manager はパッケージのビルド時間を自動承認日指定の日付として使用します。パッケージのビルド時間が特定できない場合、Patch Manager はデフォルトの日付である 1970 年 1 月 1 日を使用します。これにより、Patch Manager は 1970 年 1 月 1 日以降の任意の日付のパッチを承認するように設定されたパッチベースラインの自動承認日指定をバイパスします。 ほとんどの場合、パッチがインストールされるまでの自動承認の待ち時間は、`Release Date` 値ではなく、`updateinfo.xml` の `Updated Date` 値から計算されます。これらの日付計算に関する重要な詳細は次のとおりです。 + `Release Date` は通知がリリースされる日付です。パッケージが必ずしも関連するリポジトリで利用可能であるとは限りません。 + `Update Date` は通知が最後に更新された日付です。通知の更新は、テキストや説明の更新のような小さなものを表すことができます。パッケージが必ずしもその日付からリリースされたり、関連するリポジトリで利用可能であったりするとは限りません。 つまり、パッケージの `Update Date` 値は 7 月 7 日ですが、(たとえば) 7 月 13 日までインストールできない場合があります。この場合、7 日間の自動承認遅延を指定するパッチベースラインが 7 月 14 日に `Install` オペレーションで実行されます。なぜなら、`Update Date` 値は実行日の 7 日前で、パッケージのパッチとアップデートは 7 月 14 日にインストールされるからです。パッケージが実際にインストール可能になってから 1 日しか経過していなくても、インストールは行われます。 + オペレーティングシステムまたはアプリケーションパッチを含むパッケージは、初回リリース後に複数回更新できます。 + パッケージは AWS 管理リポジトリにリリースできますが、後で問題が発見された場合はロールバックされます。 一部のパッチ処理では、これらの要素は重要ではない場合があります。たとえば、重要度の値が `Low` および `Medium`、ならびに `Recommended` の分類のパッチをインストールするようにパッチベースラインが設定されている場合、自動承認が遅れても、運用にほとんど影響しない可能性があります。 ただし、重大なパッチや重要度の高いパッチを配布するタイミングがより重要な場合は、パッチがいつインストールされるかをより細かく制御したい場合があります。これを行うための推奨される方法は、管理対象ノードでのパッチオペレーションでデフォルトリポジトリの代わりに代替のパッチソースリポジトリを使用することです。 カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。 # セキュリティに関連するパッチの選択方法 AWS Systems Manager のツールである Patch Manager の主な目的は、オペレーティングシステムのセキュリティに関連する更新プログラムをマネージドノードにインストールすることです。デフォルトでは、Patch Manager はすべての利用可能なパッチをインストールするのではなく、一部のセキュリティ関連のパッチをインストールします。 デフォルトでは、Patch Manager は、パッケージリポジトリで廃止とマークされたパッケージを、別のパッケージ更新のインストールでこの置換が必要な場合を除き、別の名前の置換パッケージに置き換えません。代わりに、パッケージを更新するコマンドの場合、Patch Manager はインストールされているが古いパッケージの欠落した更新のみを通知してインストールします。これは、古いパッケージを置き換えるには、通常、既存のパッケージをアンインストールし、改めて新しいパッケージをインストールする必要があるためです。古いパッケージを置き換えると、意図していない重大な変更や追加機能が発生する可能性があります。 この動作は、機能のアップグレードではなくセキュリティ更新に焦点を当てた YUM および DNF の `update-minimal` コマンドと一致しています。詳細については、「[パッチのインストール方法](patch-manager-installing-patches.md)」を参照してください。 **注記** パッチベースラインルールで `ApproveUntilDate` パラメータまたは `ApproveAfterDays` パラメータを使用すると、Patch Manager は協定世界時 (UTC) を使用してパッチリリース日を評価します。 例えば、`ApproveUntilDate` の場合、`2025-11-16` などの日付を指定すると、`2025-11-16T00:00:00Z` と `2025-11-16T23:59:59Z` の間にリリースされたパッチが承認されます。 マネージドノードのネイティブパッケージマネージャーによって表示されるパッチリリース日は、システムのローカルタイムゾーンに基づいて異なる時間が表示される場合がありますが、Patch Manager は承認の計算で常に UTC 日時を使用することに注意してください。これにより、公式のセキュリティアドバイザリウェブサイトで公開されているパッチリリース日との一貫性が確保されます。 パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS ([共通脆弱性評価システム](https://www.first.org/cvss/)) のような サードパーティのソースからの、または NVD ([National Vulnerability Database](https://nvd.nist.gov/vuln)) がリリースしたメトリクスからの重要度レベルは取得しません。 **注記** Patch Manager でサポートされているすべての Linux ベースのシステムでは、セキュリティに関連しない更新プログラムをインストールしたりするために、マネージドノードに別のソースリポジトリを選択することができます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。 以下の各タブを選択して、お使いのオペレーティングシステムで Patch Manager がセキュリティ関連のパッチを選択する方法を確認してください。 ------ #### [ Amazon Linux 2 and Amazon Linux 2023 ] Amazon Linux 2 および Amazon Linux 2023 では、事前設定されたリポジトリの処理とは異なります。 Amazon Linux 2 では、Systems Manager のパッチベースラインサービスは、マネージドノード上の事前設定されたリポジトリを使用します。通常、ノードには 2 つの設定済みリポジトリ (リポウズ) があります。 **Amazon Linux 2 上** + **リポ ID**: `amzn2-core/2/architecture` **リポ名**: `Amazon Linux 2 core repository` + **リポ ID**: `amzn2extra-docker/2/architecture` **リポ名**: `Amazon Extras repo for docker` **注記** *architecture* は、x86\$164 または (Graviton プロセッサの場合は) aarch64 にすることができます。 Amazon Linux 2023 (AL2023) インスタンスを作成すると、AL2023 のバージョンで利用可能な更新と、選択した特定の AMI の更新が含まれます。AL2023 インスタンスは起動時に追加のクリティカルかつ重要なセキュリティアップデートを自動的に受信しません。代わりに、デフォルトで有効になっている AL2023 の*バージョン対応リポジトリによる確定的なアップグレード機能*を使用すると、特定のニーズを満たすスケジュールに基づいて更新を適用できます。詳細については、「Amazon Linux 2023 ユーザーガイド」の「[バージョン対応リポジトリによる確定的なアップグレード](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)」を参照してください。 AL2023 では、事前設定されたリポジトリは次のとおりです。 + **リポ ID**: `amazonlinux` **リポジトリ名**: Amazon Linux 2023 リポジトリ Amazon Linux 2023 (プレビューリリース) では、事前設定されたリポジトリは*ロックされたバージョン*のパッケージ更新に関連付けられています。AL2023 用の新規 Amazon Machine Images (AMIs) がリリースされると、特定のバージョンにロックされます。パッチ更新では、Patch Manager は、パッチ更新リポジトリの最新のロックバージョンを取得し、そのロックされたバージョンの内容に基づいてマネージド ノード上のパッケージを更新します。 **パッケージマネージャー** Amazon Linux 2 マネージドノードではパッケージマネージャーとして Yum が使用されます。Amazon Linux 2023 ではパッケージマネージャーとして DNF が使用されます。 どちらのパッケージマネージャーでも、`updateinfo.xml` という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。更新通知に含まれているすべてのパッケージは、Patch Manager ではセキュリティ関連とみなされます。個々のパッケージには分類や重要度は割り当てられません。そのため、Patch Manager は関連するパッケージに更新通知の属性を割り当てます。 **注記** **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。 **セキュリティ以外の更新を含める**オプションの詳細については、「[パッチのインストール方法](patch-manager-installing-patches.md)」および「[Linux ベースシステムでのパッチベースラインルールの動作方法](patch-manager-linux-rules.md)」を参照してください。 ------ #### [ CentOS Stream ] CentOS Stream の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。以下のリストは、架空の CentOS 9.2 Amazon Machine Image (AMI) の例を示します。 + **リポ ID**: `example-centos-9.2-base` **リポ名**: `Example CentOS-9.2 - Base` + **リポ ID**: `example-centos-9.2-extras` **リポ名**: `Example CentOS-9.2 - Extras` + **リポ ID**: `example-centos-9.2-updates` **リポ名**: `Example CentOS-9.2 - Updates` + **リポ ID**: `example-centos-9.x-examplerepo` **リポ名**: `Example CentOS-9.x – Example Repo Packages` **注記** すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。 CentOS Stream のノードではパッケージマネージャーとして DNF が使用されます。パッケージマネージャーでは、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。 ただし、CentOS Stream のデフォルトリポジトリは更新通知で設定されません。これは、Patch Manager で CentOS Stream のデフォルトリポジトリのパッケージが検出されないことを意味します。Patch Manager を許可して更新通知に含まれていないパッケージを処理するには、パッチベースラインルールで `EnableNonSecurity` フラグを有効にする必要があります。 **注記** CentOS Stream の更新通知がサポートされています。更新通知のあるリポは起動後にダウンロードできます。 ------ #### [ Debian サーバー ] Debian Server の場合、Systems Manager パッチベースラインサービスはインスタンスの事前設定済みのリポジトリ (リポ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、`sudo apt-get update` コマンドと同等のコマンドを実行します。 その後、パッケージは `debian-security codename` リポからフィルタリングされます。つまり、Debian Server の各バージョンでは、次のように、Patch Manager は、そのバージョンの関連リポジトリに含まれるアップグレードのみを識別します。 + Debian Server 11: `debian-security bullseye` + Debian Server 12: `debian-security bookworm` ------ #### [ Oracle Linux ] Oracle Linux の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。通常、ノードには 2 つの設定済みリポウズがあります。 **Oracle Linux 7**: + **リポ ID**: `ol7_UEKR5/x86_64` **リポ名**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)` + **リポ ID**: `ol7_latest/x86_64` **リポ名**: `Oracle Linux 7Server Latest (x86_64)` **Oracle Linux 8**: + **リポ ID**: `ol8_baseos_latest` **リポ名**: `Oracle Linux 8 BaseOS Latest (x86_64)` + **リポ ID**: `ol8_appstream` **リポ名**: `Oracle Linux 8 Application Stream (x86_64)` + **リポ ID**: `ol8_UEKR6` **リポ名**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)` **Oracle Linux 9**: + **リポ ID**: `ol9_baseos_latest` **リポ名**: `Oracle Linux 9 BaseOS Latest (x86_64)` + **リポ ID**: `ol9_appstream` **リポ名**: `Oracle Linux 9 Application Stream Packages(x86_64)` + **リポ ID**: `ol9_UEKR7` **リポ名**: `Oracle Linux UEK Release 7 (x86_64)` **注記** すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。 Oracle Linux マネージドノードではパッケージマネージャーとして Yum が使用されます。Yum では `updateinfo.xml` という名前のファイルとして、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。 **注記** **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。 ------ #### [ AlmaLinux, RHEL, and Rocky Linux ] AlmaLinux では、Red Hat Enterprise Linux および Rocky Linux では、Systems Manager のパッチベースラインサービスでマネージドノードの事前設定済みリポジトリ (リポウズ) が使用されます。通常、ノードには 3 つの設定済みリポウズがあります。 すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。 **注記** **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。 Red Hat Enterprise Linux 7 のマネージドノードではパッケージマネージャーとして Yum が使用されます。AlmaLinux、Red Hat Enterprise Linux 8、および Rocky Linux のマネージドノードではパッケージマネージャーとして DNF が使用されます。どちらのパッケージマネージャーでも、`updateinfo.xml` という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。 RHEL 7 以下のレポ ID は RHUI 2 に関連付けられています。RHUI 3 は 2019 年 12 月に開始され、Yum リポジトリ ID に異なる命名スキームを導入しました。マネージドノード作成元の RHEL-7 AMI によっては、コマンドを更新する必要がある場合があります。詳細については、Red Hat カスタマーポータルの「[AWS にある RHEL 7 のリポジトリ ID が既に変化した](https://access.redhat.com/articles/4599971)」を参照してください。 + **リポ ID**: `rhui-REGION-client-config-server-7/x86_64` **リポ名**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7` + **リポ ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64` **リポ名**: `Red Hat Enterprise Linux Server 7 (RPMs)` + **リポ ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64` **リポ名**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)` AlmaLinux、8 RHEL 8、および Rocky Linux 8 + **リポ ID**: `rhel-8-appstream-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)` + **リポ ID**: `rhel-8-baseos-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)` + **リポ ID**: `rhui-client-config-server-8` **リポ名**: `Red Hat Update Infrastructure 3 Client Configuration Server 8` AlmaLinux 9、 RHEL 9、および Rocky Linux 9 + **リポ ID**: `rhel-9-appstream-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)` + **リポ ID**: `rhel-9-baseos-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)` + **リポ ID**: `rhui-client-config-server-9` **リポ名**:`Red Hat Enterprise Linux 9 Client Configuration` ------ #### [ SLES ] SUSE Linux Enterprise Server (SLES) マネージドノードでは、ZYPP ライブラリは使用可能なパッチのリスト (パッケージの集合) を以下の場所から取得します。 + リポジトリのリスト: `etc/zypp/repos.d/*` + パッケージの情報: `/var/cache/zypp/raw/*` SLES マネージドノードはパッケージマネージャーとして Zypper を使用し、Zypper はパッチの概念を使用します。パッチは、特定の問題を修正するパッケージのコレクションです。Patch Manager は、パッチに含まれているすべてのパッケージをセキュリティ関連のパッケージとみなします。個々のパッケージには分類や重要度が与えられていないため、Patch Managerはパッケージにその属しているパッチの属性を割り当てます。 ------ #### [ Ubuntu Server ] Ubuntu Server の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、`sudo apt-get update` コマンドと同等のコマンドを実行します。 次に、パッケージを `codename-security` リポジトリでフィルタリングします。この codename はリリースバージョンに固有です (Ubuntu Server 14 の場合は `trusty` など)。Patch Managerは、次のリポジトリに含まれているアップグレードのみを識別します。 + Ubuntu Server 16.04 LTS: `xenial-security` + Ubuntu Server 18.04 LTS: `bionic-security` + Ubuntu Server 20.04 LTS: `focal-security` + Ubuntu Server 22.04 LTS (`jammy-security`) + Ubuntu Server 24.04 LTS (`noble-security`) + Ubuntu Server 25.04 (`plucky-security`) ------ #### [ Windows サーバー ] Microsoft Windows オペレーティングシステムの場合、Patch Manager は Microsoft が Microsoft Update に公開して Windows Server Update Services (WSUS) で自動的に利用可能になる更新プログラムのリストを取得します。 **注記** Patch Managerでは、Patch Manager でサポートされている Windows Server オペレーティングシステムのバージョンで利用可能なパッチのみを使用できます。例えば、Patch Managerを使用して Windows RT にパッチを適用することはできません。 Patch Manager は各 AWS リージョン で新しい更新を継続的にモニタリングします。利用可能な更新プログラムのリストは、各リージョンで 1 日 1 回以上更新されます。Microsoft からのパッチ情報が処理されると、Patch Manager は最新の更新プログラムで置き換えられた前の更新プログラムをパッチのリストから削除します。したがって、最新の更新のみが表示され、インストール可能になります。例えば、`KB3135456` が `KB4012214` に置き換えられると、Patch Manager では `KB4012214` のみが利用可能となります。 同様に、Patch Manager がインストールできるのは、パッチ適用オペレーション中にマネージドノードで利用可能になっているパッチのみです。デフォルトで、Windows Server 2019 および Windows Server 2022 は後続の更新に置き換えられた更新を削除します。その結果、Windows Server パッチベースラインで `ApproveUntilDate` パラメータを使用しても、`ApproveUntilDate` パラメータで選択された日付が最新パッチの日付よりも前になっている場合は、以下のシナリオが発生します。 + 置き換えられたパッチはノードから削除されるため、Patch Manager を使用してインストールすることができない。 + 最新の代替パッチがノードに存在するが、`ApproveUntilDate` パラメータで指定された日付に従ったインストールにはまだ承認されていない。 これは、前月の緊急パッチがインストールされていない可能性がある場合でも、Systems Manager オペレーションに関してはマネージドノードが準拠状態にあることを意味します。`ApproveAfterDays` パラメータの使用時にも同じシナリオが発生する可能性があります。Microsoft の置き換えられたパッチ動作のため、`ApproveAfterDays` の日数が経過する前に Microsoft からの最新のパッチがリリースされた場合でも Windows Server 向けのパッチがインストールされないように、日数を設定することが可能です (通常は 30 日を超える日数)。マネージドノードで置き換えられたパッチを利用できるように Windows グループポリシーオブジェクト (GPO) 設定を変更した場合、このシステム動作は該当しないことに注意してください。 **注記** Microsoft がリリースするアプリケーションのパッチは、更新日時を指定していない場合があります。このような場合、デフォルトでは `01/01/1970` の更新日時が指定されています。 ------ # 代替パッチソースリポジトリを指定する方法 (Linux) マネージドノードに設定されているデフォルトのリポジトリをパッチオペレーションに使用すると、AWS Systems Manager のツールである Patch Manager はセキュリティに関連するパッチをスキャンまたはインストールします。これがPatch Managerのデフォルトの動作です。Patch Manager がセキュリティ関連のパッチを選択してインストールする方法の詳細については、「[セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md)」を参照してください。 ただし、Linux システムでは、Patch Manager を使用して、セキュリティに関連しないパッチや、マネージドノードに設定されているデフォルトのリポジトリとは異なるソースリポジトリにあるパッチをインストールすることもできます。カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。 例えば、Ubuntu Server フリートに Ubuntu Server 25.04 マネージドノードの両方が含まれているとします。この場合、同じカスタムパッチベースラインで、各バージョンの代替リポジトリを指定できます。バージョンごとに、名前、オペレーティングシステムのバージョンタイプ (製品)、リポジトリ設定を指定します。サポートされているオペレーティングシステムのすべてのバージョンに適用される 1 つの代替ソースリポジトリを指定することもできます。 **注記** マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。 このオプションを使用するシナリオの例のリストについては、このトピックの後半の「[代替パッチソースリポジトリの使用例](#patch-manager-alternative-source-repository-examples)」を参照してください。 デフォルトおよびカスタムのパッチベースラインについては、「[事前定義されたパッチベースラインおよびカスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md)」を参照してください。 **例: コンソールを使用する場合** Systems Manager コンソールでの作業時に代替パッチソースリポジトリを指定するには、[**Create patch baseline** (パッチベースラインの作成)] ページの [**Patch sources** (パッチソース)] セクションを使用します。[**Patch sources (パッチソース)**] のオプションの使用については、「[Linux 用 カスタムパッチベースラインの作成](patch-manager-create-a-patch-baseline-for-linux.md)」を参照してください。 **例: AWS CLI を使用する場合** AWS Command Line Interface (AWS CLI) で `--sources` オプションを使用する例については、「[異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources)」を参照してください。 **Topics** + [代替リポジトリに関する重要な考慮事項](#alt-source-repository-important) + [代替パッチソースリポジトリの使用例](#patch-manager-alternative-source-repository-examples) ## 代替リポジトリに関する重要な考慮事項 代替パッチリポジトリを使用してパッチ適用戦略を計画する際は、次の点に注意してください。 **リポジトリ更新の認証を実施する (YUM と DNF)** Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、リポジトリへの接続が確立できない場合、アクセスできないパッケージリポジトリをスキップするように設定されることがあります。リポジトリの更新の認証を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。 `skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。 **指定されたリポジトリのみがパッチ適用に使用されます** 代替リポジトリの指定は、*追加*リポジトリの指定を意味しません。マネージドノードにデフォルトとして設定されているリポジトリ以外のリポジトリを選択することができます。ただし、更新を適用する場合は、代替のパッチソース設定の一部としてデフォルトのリポジトリも指定する必要があります。 例えば、Amazon Linux 2 マネージドノードでは、デフォルトのリポジトリは `amzn2-core` と `amzn2extra-docker` です。パッチ適用オペレーションで Extra Packages for Enterprise Linux (EPEL) リポジトリを含める必要がある場合は、3 つのリポジトリすべてを代替リポジトリとして指定する必要があります。 **注記** マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。 **YUM ベースのディストリビューションのパッチ適用の動作は、updateinfo.xml マニフェストに依存します** Amazon Linux 2 または Red Hat Enterprise Linux など、YUM ベースのディストリビューション用の代替パッチリポジトリを指定する場合、パッチ適用動作は、リポジトリに更新マニフェストが完全で正しい形式の `updateinfo.xml` ファイルで含まれているかどうかによって異なります。このファイルは、リリース日、分類、および各種パッケージの重要度を指定します。次のいずれかのパッチ動作に影響を与えます。 + **Classification** や **Severity** でフィルターしても、それらが `updateinfo.xml` で指定されていない場合、そのパッケージはフィルターには含まれません。つまり、`updateinfo.xml` ファイルのないパッケージはパッチ適用に含まれません。 + **ApprovalAfterDays** でフィルターしても、パッケージのリリース日が Unix エポック形式でない場合 (またはリリース日が指定されていない場合)、そのパッケージはフィルターに含まれません。 + **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにした場合、例外が発生します。この場合、`updateinfo.xml` ファイルを持たないパッケージ (または、**分類**、**重要度**、**日付**の値が適切にフォーマットされていないこのファイルが含まれている) は、パッチの事前フィルタリングされたリストに含まれ*ます*。(インストールするには、パッチベースラインルールの他の要件を満たしていなければなりません。) ## 代替パッチソースリポジトリの使用例 **例 1 - Ubuntu Server のセキュリティに関連しない更新プログラム** AWS が提供する事前定義されたパッチベースライン `AWS-UbuntuDefaultPatchBaseline` を使用して、セキュリティパッチを Ubuntu Server マネージドノードのフリート上にインストールするために Patch Manager を既に使用しているとします。このデフォルトに基づいて新しいパッチベースラインを作成できますが、デフォルトのディストリビューションに含まれるセキュリティに関連しない更新プログラムもインストールするように、承認ルールで指定できます。このパッチベースラインがノードに対して実行されると、セキュリティに関連する問題と関連しない問題の両方に対するパッチが適用されます。また、ベースラインに対して指定したパッチ例外で、セキュリティに関連しないパッチを承認することもできます。 **例 2 - Ubuntu Server の PPA (Personal Package Archives)** Ubuntu Server マネージドノードで、[Personal Package Archives (PPA) for Ubuntu](https://launchpad.net/ubuntu/+ppas) を通じて配布されるソフトウェアを実行するとします。この場合、マネージドノードで設定した PPA リポジトリをパッチ適用オペレーションのソースリポジトリとして指定する、パッチベースラインを作成します。その後、Run Command を使用して、ノードでパッチベースライン ドキュメントを実行します。 **例 3 - サポートされている Amazon Linux のバージョンの社内アプリケーション** Amazon Linux マネージドノードで、業界の規制コンプライアンスに必要なアプリケーションを実行する必要があるとします。ノードでこれらのアプリケーションのリポジトリを設定し、YUM を使用してアプリケーションをまずインストールしてから、この新しい企業リポジトリを含むように、新しいパッチベースラインを更新または作成できます。その後、Run Command を使用し、`Scan` オプション付きで `AWS-RunPatchBaseline` ドキュメントを実行することで、企業パッケージがインストールされたパッケージに含まれており、マネージドノードで最新かどうかを確認できます。最新でない場合は、`Install` オプション付きでそのドキュメントを再実行することで、アプリケーションを更新できます。 # パッチのインストール方法 AWS Systems Manager のツールである Patch Manager は、オペレーティングシステムの組み込みパッケージマネージャーを使用してマネージドノードに更新プログラムをインストールします。例えば、Windows Server に Windows Update API を使用して、Amazon Linux 2023 に `DNF` を使用します。Patch Manager は、ノード上の既存のパッケージマネージャーおよびリポジトリの設定に従います。これには、リポジトリのステータス、ミラー URL、GPG 認証、`skip_if_unavailable` などのオプションといった設定が含まれます。 Patch Manager は、現在インストールされている古いパッケージを置き換える新しいパッケージをインストールしません。(例外: 新しいパッケージが、インストールされている別のパッケージの更新で依存関係にあるか、新しいパッケージの名前が古いパッケージと同じである場合)。代わりに、Patch Manager はインストールされたパッケージに利用可能な更新を通知し、インストールします。このアプローチは、あるパッケージが別のパッケージを置き換えたときに発生する可能性のあるシステム機能の予期しない変更を防ぐのに役立ちます。 古くなったパッケージをアンインストールして新たなパッケージを改めてインストールする必要がある場合は、カスタムスクリプトを使用するか、Patch Manager の標準オペレーション外でパッケージマネージャーコマンドを使用する必要がある場合があります。 以下の各タブを選択して、Patch Manager がオペレーティングシステムにパッチをインストールする方法を確認してください。 ------ #### [ Amazon Linux 2 and Amazon Linux 2023 ] Amazon Linux 2 および Amazon Linux 2023 マネージドノードでは、パッチのインストールワークフローは次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。 1. YUM 更新 API (Amazon Linux 2) または DNF 更新 API (Amazon Linux 2023) は、承認されたパッチに次のように適用されます。 + AWS により事前定義されたデフォルトのパッチベースラインについては、`updateinfo.xml` で指定されたパッチのみが適用されます (セキュリティ更新のみ)。これは、**[セキュリティ以外の更新を含める]** チェックボックスがオフになっているためです。事前定義されたベースラインは、以下を含むカスタムベースラインと同等です。 + **[セキュリティ以外の更新を含める]** チェックボックスはオフになっています。 + `[Critical, Important]` の重要度リスト + `[Security, Bugfix]` の分類リスト Amazon Linux 2 の場合、このワークフローに対する同等の yum コマンドは次のとおりです。 ``` sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y ``` Amazon Linux 2023 の場合、このワークフローに対する同等の dnf コマンドは次のとおりです。 ``` sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y ``` **[セキュリティ以外の更新を含める]** チェックボックスがオンになっている場合、`updateinfo.xml` にあるパッチと `updateinfo.xml` にないパッチの両方が適用されます (セキュリティの更新とセキュリティ以外の更新)。 Amazon Linux 2 では、**[セキュリティ以外の更新を含める]** のベースラインが選択され、重要度リストが `[Critical, Important]` で、分類リストが `[Security, Bugfix]` である場合、同等の yum コマンドは次のようになります。 ``` sudo yum update --security --sec-severity=Critical,Important --bugfix -y ``` Amazon Linux 2023 の場合、同等の dnf コマンドは次のようになります。 ``` sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y ``` **注記** `yum` または `dnf` コマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません**。 **Amazon Linux 2023 の追加パッチ適用の詳細** 重要度レベル「なし」のサポート Amazon Linux 2023 は、DNF パッケージマネージャーによって認識されるパッチの重要度レベル `None` もサポートしています。 重要度レベル「中」のサポート Amazon Linux 2023 の場合、パッチの重大度レベル `Medium` は、一部の外部リポジトリで定義されている重大度レベル `Moderate` と同等です。パッチベースラインに `Medium` 重要度パッチを含めると、外部パッチからの `Moderate` 重要度パッチもインスタンスにインストールされます。 API アクション [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) を使用してコンプライアンスデータをクエリすると、重要度レベル `Medium` のフィルタリングによって、重要度レベルが `Medium` と `Moderate` の両方のパッチがレポートされます。 Amazon Linux 2023 の推移的な依存関係処理 Amazon Linux 2023 の場合、Patch Manager は、`dnf` コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。 例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、`dnf upgrade-minimal --security` は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。** 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) **注記** Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。 `skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。 ------ #### [ CentOS Stream ] CentOS Stream マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。 1. CentOS Stream の DNF 更新は、承認済みパッチに適用されます。 **注記** CentOS Stream の場合、Patch Manager は、`dnf` コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。 例えば、`dnf upgrade-minimal ‐‐security` は既知のセキュリティ問題の解決に必要な推移的依存関係の*最小*バージョンをインストールしますが、Patch Manager は同じ推移的な依存関係の*利用可能な最新バージョン*をインストールします。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) ------ #### [ Debian サーバー ] Debian Server インスタンスの場合、パッチのインストール手順は次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`InstallOverrideList` または `AWS-RunPatchBaseline` ドキュメントの `AWS-RunPatchBaselineAssociation` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。) 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 **注記** Debian Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 **注記** Debian Server では、パッチの候補となるバージョンは `debian-security` に含まれているパッチに限定されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. APT ライブラリを使用してパッケージをアップグレードします。 **注記** Patch Manager では、APT `Pin-Priority` オプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) ------ #### [ macOS ] macOS マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。 1. `/Library/Receipts/InstallHistory.plist` プロパティリストは、`softwareupdate` および `installer` パッケージマネージャーを使用してインストールおよびアップグレードされたソフトウェアのレコードです。`pkgutil` コマンドラインツール (`installer` 用) と `softwareupdate` パッケージマネージャーを使用して、CLI コマンドはこのリストを解析するために実行されます。 `installer` の場合、CLI コマンドに対する応答には `package name`、`version`、`volume`、`location`、および `install-time` の詳細が含まれますが、Patch Manager で使用されるのは、`package name` と `version` のみです。 `softwareupdate` の場合、CLI コマンドへの応答にはパッケージ名 (`display name`)、`version`、`date` が含まれますが、パッチマネージャーで使用されるのは、パッケージ名とバージョンのみです。 Brew と Brew Cask の場合、Homebrew は root ユーザーで実行されるコマンドをサポートしていません。その結果、Patch Manager は Homebrew ディレクトリの所有者、または Homebrew ディレクトリの所有者グループに属する有効なユーザーとして、Homebrew コマンドを照会して実行します。コマンドは、`softwareupdate` と `installer` に似ており、Python サブプロセスを介してパッケージデータを収集し、出力を解析してパッケージ名とバージョンを識別します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。 1. マネージドノードで適切なパッケージ CLI を呼び出し、承認されたパッチを次のように処理します。 **注記** `installer` には、更新プログラムを確認してインストールする機能がありません。したがって、`installer` では、Patch Manager はインストールされているパッケージのみをレポートします。その結果、`installer` パッケージは `Missing` として報告されることはありません。 + AWS によって事前定義されたデフォルトのパッチベースライン、ならびに **[セキュリティ以外の更新プログラムを含める]** チェックボックスが選択されてい*ない*状態のカスタムのパッチベースラインには、セキュリティ更新プログラムのみが適用されます。 + **[セキュリティ以外の更新プログラムを含める]** チェックボックスが選択されてい*いる*状態のカスタムのパッチベースラインには、セキュリティ更新プログラムおよびセキュリティ以外の更新プログラムの両方が適用されます。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) ------ #### [ Oracle Linux ] Oracle Linux マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。 1. バージョン 7 マネージドノードでは、YUM 更新 API が、次のように承認済みパッチに適用されます。 + AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、**[セキュリティ以外の更新を含める]** チェックボックスがオフである場合、`updateinfo.xml` で指定されたパッチのみが適用されます (セキュリティの更新のみ)。 このワークフローに該当する yum コマンドは次のとおりです。 ``` sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y ``` + カスタムのパッチベースラインについては、**[セキュリティ以外の更新を含める]** チェックボックスがオンである場合、`updateinfo.xml` にあるパッチと `updateinfo.xml` にないパッチの両方が適用されます (セキュリティの更新とセキュリティ以外の更新)。 このワークフローに該当する yum コマンドは次のとおりです。 ``` sudo yum update --security --bugfix -y ``` バージョン 8 と 9 のマネージドノードでは、DNF 更新 API が、次のように承認済みパッチに適用されます。 + AWS によって事前定義されたデフォルトのパッチベースライン、ならびに **[セキュリティ以外の更新プログラムを含める]** チェックボックスが選択されてい*ない*状態のカスタムのパッチベースラインには、`updateinfo.xml` で指定されたパッチのみが適用されます (セキュリティ更新プログラムのみ)。 このワークフローに該当する yum コマンドは次のとおりです。 ``` sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important ``` **注記** Oracle Linux の場合、Patch Manager は、`dnf` コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。 例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、`dnf upgrade-minimal --security` は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。** + **[セキュリティ以外の更新プログラムを含める]** チェックボックスが選択されてい*いる*状態のカスタムのパッチベースラインには、`updateinfo.xml` にあるパッチおよび `updateinfo.xml` にないパッチの両方が適用されます (セキュリティ更新プログラムおよびセキュリティ以外の更新プログラム)。 このワークフローに該当する yum コマンドは次のとおりです。 ``` sudo dnf upgrade --security --bugfix ``` **注記** `yum` または `dnf` コマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません**。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) **注記** Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。 `skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。 ------ #### [ AlmaLinux, RHEL, and Rocky Linux ] AlmaLinux、Red Hat Enterprise Linux、および Rocky Linux マネージドノードで、パッチのインストール手順は次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。 1. YUM 更新 API (RHEL 7) または DNF 更新 API (AlmaLinux 8 と 9、RHEL 8、9、10、Rocky Linux 8 と 9) は、承認されたパッチに次のルールに従って適用されます。   **シナリオ 1: セキュリティ以外の更新が除外される** + **適用先**: AWS によって提供される事前定義されたデフォルトのパッチベースラインとカスタムパッチベースライン。 + **[セキュリティ以外の更新を含める]** チェックボックス: *オフ*。 + **適用されるパッチ**: `updateinfo.xml` で指定されたパッチ (セキュリティ更新のみ) は、どちらもパッチベースライン設定と一致し、設定されたリポジトリで見つかった場合に*のみ*適用されます。 場合によっては、`updateinfo.xml` で指定されたパッチが、設定されたリポジトリで使用できなくなっていることがあります。通常、設定されるリポジトリには以前のすべての更新の累積的なロールアップであるパッチの最新バージョンのみが含まれていますが、最新バージョンがパッチベースラインルールと一致せず、パッチ適用オペレーションから除外される可能性があります。 + **コマンド**: RHEL 7 の場合、このワークフローに対する yum コマンドは次のとおりです。 ``` sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y ``` AlmaLinux、RHEL 8、および Rocky Linux の場合、このワークフローに対応する dnf コマンドは次のとおりです。 ``` sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \ sudo dnf update-minimal --sec-severity=Important --bugfix -y ``` **注記** AlmaLinu、RHEL、Rocky LinuxRocky Linux の場合、Patch Manager は、`dnf` コマンドでインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。 例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、`dnf upgrade-minimal --security` は既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。** **シナリオ 2: セキュリティ以外の更新が含まれる** + **適用先**: カスタムパッチベースライン。 + **[セキュリティ以外の更新を含める]** チェックボックス: オン。 + **適用されるパッチ**: `updateinfo.xml` にあるパッチ*と*、`updateinfo.xml` にないパッチが適用されます (セキュリティ更新とセキュリティ以外の更新)。 + **コマンド**: RHEL 7 の場合、このワークフローに対する yum コマンドは次のとおりです。 ``` sudo yum update --security --bugfix -y ``` AlmaLinux 8 および 9、RHEL 8 および 9、および Rocky Linux 8 および 9 の場合、このワークフローに相当する dnf コマンドは次のとおりです。 ``` sudo dnf update --security --bugfix -y ``` **注記** `yum` または `dnf` コマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません**。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) **注記** Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。 `skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。 ------ #### [ SLES ] SUSE Linux Enterprise Server (SLES) マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。 1. Zypper 更新 API は、承認済みパッチに適用されます。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) ------ #### [ Ubuntu Server ] Ubuntu Server マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。 1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` ドキュメントの `InstallOverrideList` パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。) 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) を適用し、追加処理のために対象のパッケージのみを保持します。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。 **注記** Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペティングシステムでは自動承認オプションがサポートされていません。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。 セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**セキュリティ以外の更新を含める**] チェックボックスがオンになっているかどうかによっても影響を受けます。 **注記** Ubuntu Server の各バージョンのパッチ候補バージョンは、次のように、そのバージョンの関連リポジトリに含まれるパッチに限定されます。 Ubuntu Server 16.04 LTS: `xenial-security` Ubuntu Server 18.04 LTS: `bionic-security` Ubuntu Server 20.04 LTS): `focal-security` Ubuntu Server 22.04 LTS: `jammy-security` Ubuntu Server 24.04 LTS (`noble-security`) Ubuntu Server 25.04 (`plucky-security`) 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) を適用します。承認済みパッチについては、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) によって破棄されている場合や、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。 1. パッチベースラインの指定どおりに [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。 1. APT ライブラリを使用してパッケージをアップグレードします。 **注記** Patch Manager では、APT `Pin-Priority` オプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。 1. 更新がインストールされると、マネージドノードは再起動されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) ------ #### [ Windows サーバー ] Windows Server マネージドノードに対してパッチ適用オペレーションを実行すると、このノードは該当するパッチベースラインのスナップショットを Systems Manager にリクエストします。このスナップショットには、デプロイ用に承認されたすべての使用可能な更新がパッチベースラインとして含まれています。この更新のリストが Windows Update API に送信されて、マネージドノードに適用できる更新が確認され、必要に応じてインストールされます。Windows では、KB の使用可能な最新バージョンのみをインストールできます。Patch Manager は、KB の最新バージョンまたは以前のバージョンの KB が、適用されたパッチベースラインと一致する場合に KB の最新バージョンをインストールします。更新のインストール後に、マネージドノードが必要な回数だけ再起動されて、すべての必要なパッチが適用されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) パッチ適用オペレーションの概要は、Run Command リクエストの出力で確認できます。詳細なログは、マネージドノードの `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` フォルダにあります。 KB のダウンロードとインストールには Windows Update API が使用されるため、Windows Update のすべてのグループポリシー設定が適用されます。Patch Manager の使用には、グループポリシー 設定は必須ではありませんが、ユーザー定義のすべての設定 (マネージドノードのターゲットを Windows Server Update Services (WSUS) サーバーにするなど) が適用されます。 **注記** Windows では、Patch Managerは Windows Update API を使用して KB のダウンロードとインストールを行うため、デフォルトではすべての KB が Microsoft の Windows Update サイトからダウンロードされます。そのため、マネージドノードは Microsoft Windows Update サイトに接続できる必要があります。そうでないと、パッチ適用は失敗します。別の方法として、WSUS サーバーを KB レポジトリとして設定し、グループポリシーを使用して WSUS サーバーをターゲットとするようマネージドノードを設定できます。 Patch Manager は、**承認済みパッチ**リストまたは**拒否済みパッチ**リストがベースライン設定に含まれている場合など、Windows Server のカスタムパッチベースラインを作成するときに KB ID を参照することがあります。Patch Manager がインストールするのは、KB ID が Microsoft Windows Update または WSUS サーバーに割り当てられている更新のみです。KB ID がない更新は、パッチ適用のオペレーションに含まれません。 カスタムパッチベースラインの作成に関する詳細は、以下のトピックを参照してください。 [Windows Server のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-windows.md) [パッチベースラインの作成 (CLI)](patch-manager-create-a-patch-baseline-for-windows.md) [Windows オペレーティングシステムのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows) ------ # Linux ベースシステムでのパッチベースラインルールの動作方法 Linux ディストリビューションのパッチベースラインのルールは、ディストリビューションタイプ別に動作が異なります。Windows Server マネージドノードでのパッチ更新とは異なり、ルールはノードごとに評価され、インスタンスに設定されているリポジトリが考慮されます。AWS Systems Manager のツールである Patch Manager は、ネイティブのパッケージマネージャーを使用して、パッチベースラインで承認されているパッチをインストールします。 パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS ([共通脆弱性評価システム](https://www.first.org/cvss/)) のような サードパーティのソースからの、または NVD ([National Vulnerability Database](https://nvd.nist.gov/vuln)) がリリースしたメトリクスからの重要度レベルは取得しません。 **Topics** + [Amazon Linux 2 および Amazon Linux 2023 でのパッチベースラインルールの仕組み](#linux-rules-amazon-linux) + [CentOS Stream でのパッチベースラインルールの仕組み](#linux-rules-centos) + [Debian Server でのパッチベースラインルールの仕組み](#linux-rules-debian) + [macOS でのパッチベースラインルールの仕組み](#linux-rules-macos) + [Oracle Linux でのパッチベースラインルールの仕組み](#linux-rules-oracle) + [AlmaLinux、RHEL、および Rocky Linux でのパッチベースラインルールの動作方法](#linux-rules-rhel) + [SUSE Linux Enterprise Server でのパッチベースラインルールの仕組み](#linux-rules-sles) + [Ubuntu Server でのパッチベースラインルールの仕組み](#linux-rules-ubuntu) ## Amazon Linux 2 および Amazon Linux 2023 でのパッチベースラインルールの仕組み **注記** Amazon Linux 2023 (AL2023) は、1 つ以上のシステム設定を通じて特定のバージョンにロックできるバージョン管理されたリポジトリを使用します。AL2023 EC2 インスタンスに対するすべてのパッチ適用オペレーションについて、Patch Manager はシステム設定に関係なく、最新のリポジトリバージョンを使用します。詳細については、「Amazon Linux 2023 ユーザーガイド」の「[バージョン対応リポジトリによる確定的なアップグレード](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)」を参照してください。 Amazon Linux 2 および Amazon Linux 2023 のパッチの選択プロセスは、次のとおりです。 1. マネージドノードで、YUM ライブラリ (Amazon Linux 2) または DNF ライブラリ (Amazon Linux 2023) が各設定済みリポジトリの `updateinfo.xml` ファイルにアクセスします。 `updateinfo.xml` ファイルが見つからない場合、パッチがインストールされるかどうかは、**[セキュリティ以外の更新を含める]** および **[自動承認]** の設定に応じます。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。 1. `updateinfo.xml` の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。 **更新通知の属性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。 1. 更新用のパッケージは、次のガイドラインに従って選択されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 ## CentOS Stream でのパッチベースラインルールの仕組み CentOS Stream のデフォルトリポジトリに `updateinfo.xml` ファイルは含まれていません。ただし、作成または使用するカスタムリポジトリにはこのファイルが含まれる場合があります。このトピックでは、`updateinfo.xml` への参照はこれらのカスタムリポジトリにのみ適用されます。 CentOS Stream の場合、パッチの選択プロセスは次のとおりです。 1. マネージドノードでは、DNF ライブラリは、設定された各リポジトリのために `updateinfo.xml` ファイルにアクセスします (カスタムリポジトリに存在する場合)。 必ず含まれるデフォルトリポジトリでも `updateinfo.xml` ファイルが見つからない場合、パッチがインストールされるかどうかは、**[セキュリティ以外の更新を含める]** および **[自動承認]** の設定によって異なります。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。 1. `updateinfo.xml` が存在する場合、ファイル内の各更新通知には、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。 **更新通知の属性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 1. どの場合でも、マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。 1. 更新用のパッケージは、次のガイドラインに従って選択されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 ## Debian Server でのパッチベースラインルールの仕組み Debian Server では、パッチベースラインサービスは、*Priority* フィールドと *Section* フィールドでフィルタリングを行います。通常、これらのフィールドはすべての Debian Server パッケージにあります。Patch Managerは、パッチベースラインでパッチが選択されているかどうかを確認するために以下の操作を行います。 1. Debian Server システムで、`sudo apt-get update` と同等のコマンドを実行して使用可能なパッケージのリストを更新します。リポは設定されず、データは `sources` リストに設定されているリポから取得されます。 1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。) 1. 次に、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)、および [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) リストが適用されます。 **注記** Debian Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。この場合、Debian Server では、パッチの候補となるバージョンは以下のリポジトリに含まれているパッチに限定されます。 これらのリポは、次のように名前が付けられます。 + Debian Server 11: `debian-security bullseye` + Debian Server 12: `debian-security bookworm` セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 [Priority] フィールドと [Section] フィールドの内容を表示するには、次の `aptitude` コマンドを実行します。 **注記** 場合によっては、まず Debian Server システムに Aptitude をインストールする必要があります。 ``` aptitude search -F '%p %P %s %t %V#' '~U' ``` このコマンドに対するレスポンスで、すべてのアップグレード可能なパッケージが次の形式で報告されます。 ``` name, priority, section, archive, candidate version ``` パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 ## macOS でのパッチベースラインルールの仕組み macOS の場合、パッチの選択プロセスは次のとおりです。 1. マネージドノードで、Patch Manager は `InstallHistory.plist` ファイルの解析済みコンテンツにアクセスし、パッケージ名とバージョンを識別します。 解析プロセスの詳細については、macOS の 「**[パッチのインストール方法](patch-manager-installing-patches.md)**」のタブを参照してください。 1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。 1. 更新用のパッケージは、次のガイドラインに従って選択されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 ## Oracle Linux でのパッチベースラインルールの仕組み Oracle Linux の場合、パッチの選択プロセスは次のとおりです。 1. マネージドノードで、YUM ライブラリが各設定済みリポの `updateinfo.xml` ファイルにアクセスします。 **注記** `updateinfo.xml` ファイルは、リポジトリが Oracle で管理されていないと使用できない場合があります。`updateinfo.xml` ファイルが見つからない場合、パッチがインストールされるかどうかは、**[セキュリティ以外の更新を含める]** および **[自動承認]** の設定に応じます。例えば、セキュリティ以外の更新プログラムが許可されている場合は、自動承認時刻が到来したときにインストールされます。 1. `updateinfo.xml` の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。 **更新通知の属性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。 1. 更新用のパッケージは、次のガイドラインに従って選択されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 ## AlmaLinux、RHEL、および Rocky Linux でのパッチベースラインルールの動作方法 AlmaLinux、Red Hat Enterprise Linux (RHEL)、および Rocky Linux では、パッチの選択プロセスは次のとおりです。 1. マネージドノードで、YUM ライブラリ (RHEL 7) または DNF ライブラリ (AlmaLinux 8 と 9、RHEL 8、9、10、Rocky Linux 8 と 9) が各設定済みリポジトリの `updateinfo.xml` ファイルにアクセスします。 **注記** リポが Red Hat の管理対象外のものであると、`updateinfo.xml` ファイルは使用できない場合があります。`updateinfo.xml` が見つからない場合、パッチは適用されません。 1. `updateinfo.xml` の更新通知ごとに、次の表に示すように、通知内のパッケージのプロパティを表す複数の属性が含まれています。 **更新通知の属性** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 1. マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型のプロダクトキー属性の値に対応します。 1. 更新用のパッケージは、次のガイドラインに従って選択されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-linux-rules.html) パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 ## SUSE Linux Enterprise Server でのパッチベースラインルールの仕組み SLES では、各パッチには、パッチ内のパッケージのプロパティを示す以下の属性が含まれます。 + **Category**: パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型の **Classification** キー属性の値に対応します。更新通知に含まれているパッチのタイプを表します。 サポートされている値のリストは、AWS CLI コマンド **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** または API オペレーション **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** を使用して表示できます。Systems Manager コンソールの [**Create patch baseline** (パッチベースラインの作成)] ページまたは [**Edit patch baseline** (パッチベースラインの編集)] ページの [**Approval rules** (承認ルール)] 領域でリストを表示することもできます。 + **Severity**: パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型の **Severity** キー属性の値に対応します。パッチの重要度を示します。 サポートされている値のリストは、AWS CLI コマンド **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** または API オペレーション **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** を使用して表示できます。Systems Manager コンソールの [**Create patch baseline** (パッチベースラインの作成)] ページまたは [**Edit patch baseline** (パッチベースラインの編集)] ページの [**Approval rules** (承認ルール)] 領域でリストを表示することもできます。 マネージドノードの成果は、SSM Agent で決まります。この属性は、パッチベースラインの [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) データ型の **プロダクト** キー属性の値に対応します。 パッチごとに、パッチベースラインがフィルターとして使用され、該当するパッケージのみが更新に含まれます。パッチベースラインの定義の適用後に複数のパッケージが該当する場合は、最新バージョンが使用されます。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 ## Ubuntu Server でのパッチベースラインルールの仕組み Ubuntu Server では、パッチベースラインサービスは、*Priority* フィールドと *Section* フィールドでフィルタリングを行います。通常、これらのフィールドはすべての Ubuntu Server パッケージにあります。Patch Managerは、パッチベースラインでパッチが選択されているかどうかを確認するために以下の操作を行います。 1. Ubuntu Server システムで、`sudo apt-get update` と同等のコマンドを実行して使用可能なパッケージのリストを更新します。リポは設定されず、データは `sources` リストに設定されているリポから取得されます。 1. 更新が可能な場合、`python3-apt` (Python ライブラリインターフェイスの `libapt`) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[**Include nonsecurity updates** (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。) 1. 次に、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)、および [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) リストが適用されます。 **注記** Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペティングシステムでは自動承認オプションがサポートされていません。 ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [**Include nonsecurity updates** (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。 セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。この場合、Ubuntu Server では、パッチの候補となるバージョンは以下のリポジトリに含まれているパッチに限定されます。 + Ubuntu Server 16.04 LTS: `xenial-security` + Ubuntu Server 18.04 LTS: `bionic-security` + Ubuntu Server 20.04 LTS: `focal-security` + Ubuntu Server 22.04 LTS (`jammy-security`) + Ubuntu Server 24.04 LTS (`noble-security`) + Ubuntu Server 25.04 (`plucky-security`) セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 [Priority] フィールドと [Section] フィールドの内容を表示するには、次の `aptitude` コマンドを実行します。 **注記** 場合によっては、まず Ubuntu Server 16 システムに Aptitude をインストールする必要があります。 ``` aptitude search -F '%p %P %s %t %V#' '~U' ``` このコマンドに対するレスポンスで、すべてのアップグレード可能なパッケージが次の形式で報告されます。 ``` name, priority, section, archive, candidate version ``` パッチのコンプライアンスステータス値については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 # Linux と Windows Server のパッチ適用オペレーションの違い このトピックでは、AWS Systems Manager のツールである Patch Manager での Linux と Windows Server のパッチ適用における重要な違いについて説明します。 **注記** Linux マネージドノードにパッチを適用するには、ノードが SSM Agent バージョン 2.0.834.0 以降実行されている必要があります。 新しいツールが Systems Manager に追加されるか、既存のツールが更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種ツールや機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。GitHub の「[SSM Agent リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)」ページをサブスクライブすると、SSM Agent の更新に関する通知を受け取ることができます。 ## 違い 1: パッチ評価 Patch Manager では、Windows マネージドノードと Linux マネージドノードで、どのパッチを提供するかを評価するプロセスが異なります。 **Linux** Linux のパッチ適用では、Systems Manager はパッチベースライン ルールと承認済みおよび拒否済みパッチのリストを*各*マネージドノードで評価します。Systems Manager が各ノードでパッチ適用を評価する必要があるのは、マネージドノードに設定された複数のリポジトリから既知のパッチと更新のリストが取得されるためです。 **Server** Windows のパッチ適用では、Systems Manager はパッチベースラインルールと承認済みおよび拒否済みパッチのリストを*サービス内で直接*評価します。これが可能なのは、Windows パッチが単一のリポジトリ (Windows Update) から取得されるためです。 ## 違い 2: `Not Applicable` パッチ Linux オペレーティングシステムには多数の使用可能なパッケージがあるため、Systems Manager では*該当なし*状態のパッチについて詳細をレポートしません。`Not Applicable` パッチとは、例えば、インスタンスに Apache がインストールされていない場合の Apache ソフトウェア用パッチなどです。Systems Manager は要約で多数の `Not Applicable` パッチをレポートしますが、マネージドノードで [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API を呼び出す場合、戻りデータには状態が `Not Applicable` のパッチは含まれません。この動作は、Windows とは異なります。 ## 違い 3: SSM ドキュメントのサポート `AWS-ApplyPatchBaseline` Systems Manager ドキュメント (SSM ドキュメント) では、Linux マネージドノードはサポートされていません。Linux、macOS、Windows Server マネージドノードにパッチベースラインを適用する上で推奨されている SSM ドキュメントは、`AWS-RunPatchBaseline` です。詳細については、「[マネージドノードへのパッチ適用のための SSM コマンドドキュメント](patch-manager-ssm-documents.md)」および「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。 ## 違い 4: アプリケーションパッチ Patch Managerの主な目的は、オペレーティングシステムにパッチを適用することです。ただし、Patch Managerを使用して、マネージドノードの一部のアプリケーションにパッチを適用することもできます。 **Linux** Linux オペレーティングシステムでは、Patch Manager は更新のために設定されたリポジトリを使用し、オペレーティングシステムとアプリケーションのパッチを区別しません。Patch Managerを使用して、更新を取得するリポジトリを定義できます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。 **Server** Windows Server マネージドノードでは、Microsoft Word 2016 や Microsoft Exchange Server 2016 など、Microsoft によってリリースされたアプリケーションに対して、*[Approved]* (承認済み)および *[Rejected]* (拒否された) パッチの例外を適用できます。詳細については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。 ## 違い 5: カスタムパッチベースラインでの拒否されたパッチリストのオプション カスタムパッチベースラインを作成するときは、**拒否されたパッチリスト**に 1 つ、または複数のパッチを指定できます。Linux マネージドノードでは、パッチがベースラインで許可されている別のパッチの依存関係である場合に、それらのインストールを許可することも選択できます。 ただし、Windows Server はパッチ依存関係の概念をサポートしません。Windows Server 向けのカスタムベースラインの **[拒否されたパッチ]** リストにパッチを追加することはできますが、その結果は (1) 拒否されたパッチがマネージドノードに既にインストールされているかどうか、および (2) **[拒否されたパッチアクション]** にどのオプションを選択するかに応じて異なります。 Windows Server での拒否されたパッチオプションの詳細については、以下の表を参照してください。 | インストールステータス | オプション:「依存関係として許可する」 | オプション: 「ブロック」 | | --- | --- | --- | | パッチが既にインストールされている | 報告されるステータス: INSTALLED\$1OTHER | 報告されるステータス: INSTALLED\$1REJECTED | | パッチがまだインストールされていない | パッチがスキップされた | パッチがスキップされた | 通常、Microsoft がリリースする Windows Server 用の各パッチには、インストールが正常に行われるために必要なすべての情報が含まれています。ただし、手動でインストールする必要がある前提条件パッケージが必要になる場合もあります。Patch Manager は、これらの前提条件に関する情報を報告しません。関連情報については、Microsoft ウェブサイトで「[Windows Update の問題のトラブルシューティング](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)」を参照してください。 # マネージドノードへのパッチ適用のための 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": [] } ] ``` # パッチベースライン このセクションのトピックでは、`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)」を参照すると問題解決に役立ちます。 # Amazon Linux 2 マネージドノードで Kernel Live Patching を使用 Amazon Linux 2 の Kernel Live Patching により、実行中のアプリケーションを再起動や中断せずに、実行中の Linux カーネルにセキュリティの脆弱性や重大なバグのパッチを適用できます。これにより、インフラストラクチャを安全かつ最新に保つとともに、サービスとアプリケーションの可用性を向上させることができます。Kernel Live Patching は、Amazon EC2 インスタンス、AWS IoT Greengrass コアのデバイス、および Amazon Linux 2 を実行する [[on-premises virtual machines]](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html) (オンプレミスの仮想マシン) でサポートされます。 Kernel Live Patching の一般的な情報については、Amazon Linux 2 ユーザーガイドの「[Kernel Live Patching on AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)」を参照してください。** Amazon Linux 2 マネージドノードで Kernel Live Patching を有効にした後、AWS Systems Manager のツールである Patch Manager を使用すると、カーネルライブパッチをマネージドノードに適用できます。Patch Manager は、ノードで既存の yum ワークフローを使用して更新を適用する代わりに使用できます。 **[開始する前に]** Patch Manager を使用してカーネルライブパッチを Amazon Linux 2 マネージドノードに適用するには、ノードが正しいアーキテクチャとカーネルバージョンに基づいていることを確認します。詳細については、「Amazon EC2 ユーザーガイド」の「[サポートされる設定と前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)」を参照してください。 **Topics** + [Patch Manager を使用した Kernel Live Patching](#about-klp) + [Patch Manager を使用した Kernel Live Patching の仕組み](#how-klp-works) + [Run Command を使用して Kernel Live Patching をオンにする](enable-klp.md) + [Run Command の使用によるカーネルライブパッチの適用](install-klp.md) + [Run Command を使用して Kernel Live Patching をオフにする](disable-klp.md) ## Patch Manager を使用した Kernel Live Patching カーネルバージョンの更新 カーネルライブ パッチ更新を適用した後、マネージドノードを再起動する必要はありません。ただし AWS では、リリース後最長 3 か月間、Amazon Linux 2 カーネルバージョンのカーネルライブパッチが提供されます。3 か月が過ぎた後にカーネルライブパッチを引き続き入手するには、新しいカーネルバージョンに更新する必要があります。メンテナンスウィンドウを使用して、少なくとも 3 か月に一度、ノードの再起動をスケジュールし、カーネルバージョンの更新を促すことをお勧めします。 カーネルライブパッチのアンインストール カーネルライブパッチは、Patch Manager を使用してアンインストールすることはできません。代わりに Kernel Live Patching を無効にすることができます。これにより、適用されたカーネルライブパッチの RPM パッケージが削除されます。詳細については、「[Run Command を使用して Kernel Live Patching をオフにする](disable-klp.md)」を参照してください。 カーネルのコンプライアンス 場合によっては、現在のカーネルバージョンのライブパッチからすべての CVE 修正をインストールすると、そのカーネルが新しいカーネルバージョンと同じコンプライアンス状態になることがあります。この場合は、新しいバージョンが `Installed` と報告され、マネージドノードノードは `Compliant` と報告されます。ただし、新しいカーネルバージョンのインストール時間は報告されません。 1 つのカーネルライブパッチ、複数の CVE カーネルライブパッチが複数の CVE に対応していて、これらの CVE にさまざまな分類や重要度値がある場合、そのパッチに対してレポートされるのは、CVE の中から最も高い分類と重要度だけです。 このセクションの以降では、Patch Manager を使用して、これらの要件を満たすマネージドノードノードにカーネルライブパッチを適用する方法について説明します。 ## Patch Manager を使用した Kernel Live Patching の仕組み AWS では、セキュリティ更新とバグ修正の 2 種類を Amazon Linux 2 用のカーネルライブパッチとしてリリースしています。これらのタイプのパッチを適用するには、次の表に示す分類と重要度のみを対象としたパッチベースラインドキュメントを使用します。 | 分類 | 重要度 | | --- | --- | | Security | Critical, Important | | Bugfix | All | これらのパッチのみを対象としたカスタムパッチベースラインを作成することも、定義済みの `AWS-AmazonLinux2DefaultPatchBaseline` パッチベースラインを使用することもできます。つまり、`AWS-AmazonLinux2DefaultPatchBaseline` が有効になっている Amazon Linux 2 マネージドノードで Kernel Live Patching を使用でき、カーネルライブアップデートが適用されます。 **注記** この `AWS-AmazonLinux2DefaultPatchBaseline` 設定では、パッチがリリースまたは最後に更新されてからパッチが自動的にインストールされるまでに 7 日間の待機期間が指定されます。カーネルライブパッチが自動承認されるまで 7 日間待機しない場合は、カスタムパッチベースラインを作成して使用できます。パッチベースラインでは、自動承認待機期間を指定しない、または短期間や長期間を指定できます。詳細については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。 カーネルライブアップデートでマネージドノードにパッチを適用するには、以下の戦略をお勧めします。 1. Amazon Linux 2 マネージドノードの Kernel Live Patching を有効にします。 1. AWS Systems Manager のツールである Run Command を使用し、マネージドノードに対して `Scan` オペレーションを実行します。このとき、定義済みの `AWS-AmazonLinux2DefaultPatchBaseline` を使用するか、`Critical` および `Important` として重要度が分類される `Security` 更新と `All` の `Bugfix` 重要度のみを対象としたカスタムパッチベースラインを使用します。 1. スキャンされたマネージドノードについてパッチ適用の非準拠が報告されているかどうかを調べるには、AWS Systems Manager のツールである Compliance を使用します。報告されている場合は、ノードのコンプライアンス 詳細を表示して、マネージドノードに適用されていないカーネルライブパッチがないかどうかを確認します。 1. 適用されていないカーネルライブパッチをインストールするには、前に指定したものと同じパッチベースラインで Run Command を使用します。ただし今回は `Install` 操作ではなく `Scan` 操作を実行します。 カーネルライブパッチは再起動しなくてもインストールされるため、この操作では再起動オプションとして `NoReboot` を選択できます。 **注記** マネージドノードにインストールされている他のタイプのパッチに必要な場合や、新しいカーネルに更新する場合は、マネージドノードを再起動できます。このような場合は、再起動オプション `RebootIfNeeded` を代わりに選択します。 1. Compliance に戻り、カーネルライブパッチがインストールされていることを確認します。 # Run Command を使用して Kernel Live Patching をオンにする Kernel Live Patching を有効にするには、お使いのマネージドノードで `yum` コマンドを実行するか、Run Command および作成するカスタム Systems Manager ドキュメント (SSM ドキュメント) を使用します。 マネージドノードで `yum` コマンドを直接実行して Kernel Live Patching をオンにする方法については、「Amazon EC2 ユーザーガイド」の「[Kernel Live Patching の有効化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)」を参照してください。 **注記** カーネルライブパッチを有効にしたときに、マネージドノードですでに実行されているカーネルが `kernel-4.14.165-131.185.amzn2.x86_64` (サポートされている最小バージョン) より*前の*場合、プロセスは、利用可能な最新のカーネルバージョンをインストールしてマネージドノードを再起動します。ノードがすでに `kernel-4.14.165-131.185.amzn2.x86_64` 以降を実行している場合、プロセスは、新しいバージョンをインストールせず、ノードを再起動しません。 **Run Command を使用して Kernel Live Patching をオンにするには (コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Run Command]** を選択します。 1. [**Run command (コマンドの実行)**] を選択します。 1. [**コマンドドキュメント**] リストで、カスタム SSM ドキュメント `AWS-ConfigureKernelLivePatching` を選択します。 1. **[Command parameters]** (コマンドのパラメータ) セクションで、このオペレーションのパートとしてマネージドノードを再起動するかどうかを指定します。 1. このページの残りのコントロールを操作する方法については、「[コンソールからコマンドを実行する](running-commands-console.md)」を参照してください。 1. [**Run (実行)**] を選択します。 **Kernel Live Patching をオンにするには (AWS CLI)** + ローカルマシンで次のコマンドを実行します。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name "AWS-ConfigureKernelLivePatching" \ --parameters "EnableOrDisable=Enable" \ --targets "Key=instanceids,Values=instance-id" ``` ------ #### [ Windows Server ] ``` aws ssm send-command ^ --document-name "AWS-ConfigureKernelLivePatching" ^ --parameters "EnableOrDisable=Enable" ^ --targets "Key=instanceids,Values=instance-id" ``` ------ *instance-id* は、この機能を有効にする Amazon Linux 2 マネージドノードの ID (例えば、i-02573cafcfEXAMPLE) に置き換えます。複数のマネージドノードでこの機能を有効にするには、次のいずれかの形式を使用できます。 + `--targets "Key=instanceids,Values=instance-id1,instance-id2"` + `--targets "Key=tag:tag-key,Values=tag-value"` コマンドで使用できるその他のオプションについては、*AWS CLI コマンドリファレンス* の [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) を参照してください。 # Run Command の使用によるカーネルライブパッチの適用 カーネルライブパッチを適用するには、マネージドノードで `yum` コマンドを実行するか、Run Command および SSM ドキュメント `AWS-RunPatchBaseline` を使用します。 マネージドノードで直接 `yum` コマンドを実行してカーネルライブパッチを適用する方法については、「Amazon EC2 ユーザーガイド」の「[カーネルライブパッチの適用](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply)」を参照してください。 **Run Command を使用してカーネルライブパッチを適用するには (コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Run Command]** を選択します。 1. [**Run command (コマンドの実行)**] を選択します。 1. [**Command document**] リストで、SSM ドキュメント `AWS-RunPatchBaseline` を選択します。 1. [**コマンドのパラメータ**] セクションで、次のいずれかの操作を行います。 + 新しいカーネルライブパッチが利用可能かどうかをチェックする場合は、[**オペレーション**] で `Scan` を選択します。**[Reboot Option]** (再起動オプション) で、この操作後にマネージドノードを再起動しない場合は、`NoReboot` を選択します。操作が完了したら、Compliance で新しいパッチとコンプライアンスのステータスを確認できます。 + パッチコンプライアンスをすでにチェック済みであり、利用可能なカーネルライブパッチを適用する準備ができている場合は、[**操作**] で `Install` を選択します。**[Reboot Option]** (再起動オプション) で、この操作後にマネージドノードを再起動しない場合は、`NoReboot` を選択します。 1. このページの残りのコントロールを操作する方法については、「[コンソールからコマンドを実行する](running-commands-console.md)」を参照してください。 1. [**Run (実行)**] を選択します。 **Run Command を使用してカーネルライブパッチを適用するには (AWS CLI)** 1. Compliance で結果を確認する前に `Scan` 操作を実行するには、ローカルマシンで次のコマンドを実行します。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name "AWS-RunPatchBaseline" \ --targets "Key=InstanceIds,Values=instance-id" \ --parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}' ``` ------ #### [ Windows Server ] ``` aws ssm send-command ^ --document-name "AWS-RunPatchBaseline" ^ --targets "Key=InstanceIds,Values=instance-id" ^ --parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]} ``` ------ コマンドで使用できるその他のオプションについては、*AWS CLI コマンドリファレンス* の [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) を参照してください。 1. Compliance で結果を確認した後に `Install` 操作を実行するには、ローカルマシンで次のコマンドを実行します。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name "AWS-RunPatchBaseline" \ --targets "Key=InstanceIds,Values=instance-id" \ --parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}' ``` ------ #### [ Windows Server ] ``` aws ssm send-command ^ --document-name "AWS-RunPatchBaseline" ^ --targets "Key=InstanceIds,Values=instance-id" ^ --parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]} ``` ------ 上記の両方のコマンドで、*instance-id* は、カーネルライブパッチを適用する Amazon Linux 2 マネージドノードの ID に置き換えます (i-02573cafcfEXAMPLE など)。複数のマネージドノードでこの機能を有効にするには、次のいずれかの形式を使用できます。 + `--targets "Key=instanceids,Values=instance-id1,instance-id2"` + `--targets "Key=tag:tag-key,Values=tag-value"` これらのコマンドで使用できるその他のオプションについては、*AWS CLI コマンドリファレンス* の [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) を参照してください。 # Run Command を使用して Kernel Live Patching をオフにする Kernel Live Patching をオフにするには、マネージドノードで `yum` コマンドを実行するか、Run Command およびカスタム SSM ドキュメント `AWS-ConfigureKernelLivePatching` を使用します。 **注記** カーネルライブパッチを使用する必要がなくなった場合は、いつでも無効にできます。ほとんどの場合、この機能を無効にする必要はありません。 マネージドノードで `yum` コマンドを直接実行して Kernel Live Patching をオフにする方法については、「Amazon EC2 ユーザーガイド」の「[Kernel Live Patching の有効化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable)」を参照してください。 **注記** Kernel Live Patching をオフにすると、プロセスは、Kernel Live Patching プラグインをアンインストールしてマネージドノードを再起動します。 **Run Command を使用して Kernel Live Patching をオフにするには (コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Run Command]** を選択します。 1. [**Run command (コマンドの実行)**] を選択します。 1. [**Command document**] リストで、SSM ドキュメント `AWS-ConfigureKernelLivePatching` を選択します。 1. [**Command parameters**] セクションで、必須パラメータの値を指定します。 1. このページの残りのコントロールを操作する方法については、「[コンソールからコマンドを実行する](running-commands-console.md)」を参照してください。 1. [**Run (実行)**] を選択します。 **Kernel Live Patching をオフにするには (AWS CLI)** + 以下のようなコマンドを使用します。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name "AWS-ConfigureKernelLivePatching" \ --targets "Key=instanceIds,Values=instance-id" \ --parameters "EnableOrDisable=Disable" ``` ------ #### [ Windows Server ] ``` aws ssm send-command ^ --document-name "AWS-ConfigureKernelLivePatching" ^ --targets "Key=instanceIds,Values=instance-id" ^ --parameters "EnableOrDisable=Disable" ``` ------ *instance-id* は、この機能を無効にする Amazon Linux 2 マネージドノードの ID (例えば、i-02573cafcfEXAMPLE) に置き換えます。複数のマネージドノードでこの機能を無効にするには、次のいずれかの形式を使用できます。 + `--targets "Key=instanceids,Values=instance-id1,instance-id2"` + `--targets "Key=tag:tag-key,Values=tag-value"` コマンドで使用できるその他のオプションについては、*AWS CLI コマンドリファレンス* の [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) を参照してください。 # コンソールを使用した Patch Manager リソースとコンプライアンスの操作 AWS Systems Manager のツールである Patch Manager を使用するには、以下のタスクを実行します。各タスクについては、このセクションで詳しく説明します。 1. 使用するオペレーティングシステムの種類ごとに、AWS の定義済みのパッチベースラインがニーズを満たしていることを確認します。そうでない場合は、そのマネージドノードタイプの標準パッチセットを定義するパッチベースラインを作成し、代わりにそれをデフォルトとして設定します。 1. Amazon Elastic Compute Cloud (Amazon EC2) タグを使用してマネージドノードをパッチグループに整理します (オプションですが推奨します)。 1. 次のいずれかを行います。 + (推奨) Systems Manager のツールである Quick Setup でパッチポリシーを設定すると、組織全体、組織単位の一部、またはシングル AWS アカウントに対して、未適用のパッチをスケジュールに従ってインストールできます。詳細については、「[Quick Setup パッチポリシーを使用して組織内のインスタンスのためにパッチ適用を設定する](quick-setup-patch-manager.md)」を参照してください。 + Run Command タスクタイプで、Systems Manager ドキュメント (SSM ドキュメント) `AWS-RunPatchBaseline` を使用するメンテナンスウィンドウを作成します。詳細については、「[チュートリアル: コンソールを使用してパッチ用メンテナンスウィンドウを作成する](maintenance-window-tutorial-patching.md)」を参照してください。 + Run Command オペレーションで `AWS-RunPatchBaseline` を手動で実行します。詳細については、「[コンソールからコマンドを実行する](running-commands-console.md)」を参照してください。 + **[Patch now]** (今すぐパッチ適用) 機能を使用して、必要に応じてノードに手動でパッチを適用します。詳細については、「[マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md)」を参照してください。 1. パッチ適用をモニタリングして、コンプライアンスを確認し、失敗を調査します。 **Topics** + [パッチポリシーの作成](patch-manager-create-a-patch-policy.md) + [パッチダッシュボードの概要の表示](patch-manager-view-dashboard-summaries.md) + [パッチコンプライアンスレポートの使用](patch-manager-compliance-reports.md) + [マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md) + [パッチベースラインの操作](patch-manager-create-a-patch-baseline.md) + [利用可能なパッチの表示](patch-manager-view-available-patches.md) + [パッチグループの作成と管理](patch-manager-tag-a-patch-group.md) + [Patch Managerと AWS Security Hub CSPM の統合](patch-manager-security-hub-integration.md) # パッチポリシーの作成 パッチポリシーは、AWS Systems Manager のツールである Quick Setup を使用して設定します。パッチポリシーを使用すると、他のパッチ適用の設定方法に比べて、パッチ適用オペレーションをより広範囲かつ一元的に制御できます。パッチポリシーでは、ノードとアプリケーションに自動的にパッチを適用するときに使用するスケジュールとベースラインを定義します。 詳細については、以下の各トピックを参照してください。 + [Quick Setup でのパッチポリシー設定](patch-manager-policies.md) + [Quick Setup パッチポリシーを使用して組織内のインスタンスのためにパッチ適用を設定する](quick-setup-patch-manager.md) # パッチダッシュボードの概要の表示 Patch Manager の **[ダッシュボード]** タブでは、コンソールの概要ビューが表示され、パッチ適用オペレーションを統合ビューで監視するために使用できます。Patch Manager は AWS Systems Manager のツールです。[**Dashboard** (ダッシュボード)] タブでは以下を表示できます。 + パッチ適用ルールに準拠している マネージドノードの数と非準拠の数のスナップショット。 + マネージドノードのパッチコンプライアンス結果の経過時間のスナップショット。 + 非準拠の最も一般的な理由ごとに、非準拠のマネージドノードの数を示すリンク数。 + 最新のパッチ適用オペレーションのリンクされたリスト。 + 設定された反復パッチ適用タスクのリンクされたリスト。 **パッチダッシュボードの概要を表示するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. [**Dashboard** (ダッシュボード)] タブを選択します。 1. 表示したい概要データを含むセクションまでスクロールします。 + **Amazon EC2 インスタンスの管理** + **コンプライアンスの概要** + **コンプライアンス違反数** + **コンプライアンスレポート** + **パッチポリシーに基づかないオペレーション** + **パッチポリシーに基づかない繰り返しタスク** # パッチコンプライアンスレポートの使用 次のトピックの情報を使用して、AWS Systems Manager のツールである Patch Manager でパッチコンプライアンスレポートの生成と操作を行います。 以下のトピックの情報は、パッチ適用オペレーションに使用する設定の方法や種類に関係なく適用されます。 + Quick Setup で設定されているパッチポリシー + Quick Setup で設定されているホスト管理オプション + パッチ `Scan` または `Install` のタスクを実行するためのメンテナンスウィンドウ + オンデマンドの **[今すぐパッチ適用]** オペレーション **重要** パッチコンプライアンスレポートは、パッチ適用オペレーションが成功した場合にのみ生成されるポイントインタイムスナップショットです。各レポートには、コンプライアンスステータスが計算されたときを識別するキャプチャ時間が含まれています。 パッチコンプライアンスのためにインスタンスをスキャンするオペレーションが複数種類ある場合は、スキャンするたびに以前のスキャンのパッチコンプライアンスデータが上書きされることに注意してください。その結果、パッチコンプライアンスデータで想定外の結果を得ることがあります。詳細については、「[パッチコンプライアンスデータを作成した実行の特定](patch-manager-compliance-data-overwrites.md)」を参照してください。 どのパッチベースラインが最新のコンプライアンス情報の生成に使用されたかを確認するには、Patch Manager の **[コンプライアンスレポート]** タブに移動し、情報を確認するマネージドノードの行を探して、**[使用されたベースライン ID]** 列にあるベースライン ID を選択します。 **Topics** + [パッチコンプライアンス結果の表示](patch-manager-view-compliance-results.md) + [.csv パッチコンプライアンスレポートの生成](patch-manager-store-compliance-results-in-s3.md) + [Patch Manager で非準拠のマネージドノードを修復するには](patch-manager-noncompliant-nodes.md) + [パッチコンプライアンスデータを作成した実行の特定](patch-manager-compliance-data-overwrites.md) # パッチコンプライアンス結果の表示 これらの手順を使用して、マネージドノードに関するパッチコンプライアンス情報を表示します。 この手順は、`AWS-RunPatchBaseline` ドキュメントを使用するパッチ操作に適用されます。`AWS-RunPatchBaselineAssociation` ドキュメントを使用するパッチ操作のパッチコンプライアンス情報の表示については、「[非準拠のマネージドノードの識別](patch-manager-find-noncompliant-nodes.md)」を参照してください。 **注記** Quick Setup と Explorer のパッチスキャンオペレーションでは、`AWS-RunPatchBaselineAssociation` ドキュメントが使用されます。Quick Setup と Explorer はどちらも AWS Systems Manager のツールです。 **特定の CVE の問題を解決するパッチの識別 (Linux)** 多くの Linux ベースのオペレーティングシステムでは、パッチのコンプライアンスの結果にどの共通脆弱性識別子 (CVE) の問題がどのパッチによって解決されるかが示されます。この情報は、不足または失敗したパッチのインストールを緊急に行う必要があるかどうかを判断するために役立ちます。 CVE の詳細は、以下のタイプのオペレーティングシステムでサポートされるバージョンについて表示されます。 + AlmaLinux + Amazon Linux 2 + Amazon Linux 2023 + Oracle Linux + Red Hat Enterprise Linux (RHEL) + Rocky Linux **注記** デフォルトでは、CentOS Stream は更新に関する CVE 情報を提供しません。ただし、サードパーティーのリポジトリ (Fedora によって公開されている Extra Packages for Enterprise Linux (EPEL) リポジトリなど) を使用して、このサポートを許可することができます。詳細については、Fedora Wiki の [EPEL](https://fedoraproject.org/wiki/EPEL) を参照してください。 現在、CVE ID の値は、ステータスが `Missing` または `Failed` のパッチについてのみ報告されます。 状況やパッチ適用の目的に応じて、パッチベースラインの承認済みパッチまたは拒否済みパッチのリストに CVE ID を追加することもできます。 承認済みパッチおよび拒否済みパッチのリストの使用については、以下のトピックを参照してください。 + [カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md) + [承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md) + [Linux ベースシステムでのパッチベースラインルールの動作方法](patch-manager-linux-rules.md) + [パッチのインストール方法](patch-manager-installing-patches.md) **注記** Microsoft がリリースするアプリケーションのパッチは、更新日時を指定していない場合があります。このような場合、デフォルトでは `01/01/1970` の更新日時が指定されています。 ## パッチ適用のコンプライアンス結果を表示する AWS Systems Manager コンソールでパッチコンプライアンス結果を表示するには、以下の手順に従います。 **注記** Amazon Simple Storage Service (Amazon S3) バケットにダウンロードされるパッチコンプライアンスレポートの生成については、「[.csv パッチコンプライアンスレポートの生成](patch-manager-store-compliance-results-in-s3.md)」を参照してください。 **パッチコンプライアンス結果を表示するには** 1. 以下のいずれかを行ってください。 **オプション 1** (推奨) – AWS Systems Manager のツールである Patch Manager から移動します。 + ナビゲーションペインで、**Patch Manager** を選択します。 + **[Compliance reporting]** (コンプライアンスレポート) タブを選択します。 + **[ノードのパッチ適用の詳細]** 領域で、パッチコンプライアンス結果を確認するマネージドノードのノード ID を選択します。`stopped` または `terminated` のノードはここに表示されません。 + **[詳細]** 領域の **[プロパティ]** リストで、**[パッチ]**を選択します。 **オプション 2** – AWS Systems Manager のツールである Compliance から移動します。 + ナビゲーションペインで、[**コンプライアンス**] を選択します。 + [**コンプライアンスリソースの概要**] で、確認するパッチリソースのタイプ ([**非準拠リソース**] など) の列で数値を選択します。 + 下方の **[リソース]** リストで、パッチコンプライアンス結果を確認するマネージドノードの ID を選択します。 + **[詳細]** 領域の **[プロパティ]** リストで、**[パッチ]**を選択します。 **オプション 3** – AWS Systems Manager のツールである Fleet Manager から移動します。 + ナビゲーションペインで、**Fleet Manager** を選択します。 + **[マネージドインスタンス]** 領域で、パッチコンプライアンス結果を確認するマネージドノードの ID を選択します。 + **[詳細]** 領域の **[プロパティ]** リストで、**[パッチ]**を選択します。 1. (オプション) [検索] ボックス (![\[The Search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) で、利用可能なフィルターから選択します。 たとえば、Red Hat Enterprise Linux ( RHEL )の場合は、以下から選択します。 + 名前 + 分類 + 状態 + 重要度 Windows Server の場合は、次の中から選択します。 + KB + 分類 + 状態 + 重要度 1. 選択したフィルタータイプに使用可能な値の 1 つを選択します。例えば、[**状態**] を選択した場合は、[**InstalledPendingReboot**]、[**失敗**] や [**見つかりません**] などのコンプライアンス状態を選択します。 **注記** 現在、CVE ID の値は、ステータスが `Missing` または `Failed` のパッチについてのみ報告されます。 1. マネージドノードのコンプライアンス状態に応じて、準拠していないノードを修正するために実行するアクションを選択できます。 例えば、準拠していないマネージドノードにすぐにパッチを適用するよう選択できます。オンデマンドでマネージドノードにパッチを適用する方法については、「[マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md)」を参照してください。 パッチコンプライアンス状態の詳細については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 # .csv パッチコンプライアンスレポートの生成 AWS Systems Manager コンソールを使用して、任意の Amazon Simple Storage Service (Amazon S3) バケットに .csv ファイルとして保存されるパッチコンプライアンスレポートを生成できます。オンデマンドレポートを 1 つだけ生成することも、レポートを自動的に生成するスケジュールを指定することもできます。 レポートは、単一のマネージドノードに対して、または選択した AWS アカウント および AWS リージョン のすべてのマネージドノードに対して生成することができます。単一のノードの場合、レポートには、非準拠のノードに関連するパッチの ID など、包括的な詳細が含まれます。すべてのマネージドノードに関するレポートでは、非準拠ノードのパッチ概要情報と数のみが表示されます。 レポートが生成されたら、Amazon Quick などのツールを使用してデータをインポートおよび分析できます。Quick は、インタラクティブなビジュアル環境で情報を探索および解釈するために使用できるビジネスインテリジェンス (BI) サービスです。詳細については、「[Amazon Quick ユーザーガイド](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html)」を参照してください。 **注記** カスタムのパッチベースラインを作成する場合、そのパッチベースラインによって承認されたパッチのコンプライアンスの重要度レベル (`Critical` または `High` など) を指定できます。承認された任意のパッチのパッチ状態が `Missing` と報告された場合、パッチベースラインで報告される全体的なコンプライアンスの重要度は、指定した重要度レベルになります。 レポートが生成されたときに通知を送信するために使用する Amazon Simple Notification Service (Amazon SNS) トピックを指定することもできます。 **パッチコンプライアンスレポートを生成するためのサービスロール** レポートを初めて生成する場合、Systems Manager は、S3 へのエクスポートプロセスに使用する `AWS-SystemsManager-PatchSummaryExportRole` という名前のオートメーション仮定ロールを作成します。 **注記** コンプライアンスデータを暗号化された S3 バケットにエクスポートする場合は、関連する AWS KMS キーポリシーを更新して、`AWS-SystemsManager-PatchSummaryExportRole` に必要な許可を与える必要があります。例えば、S3 バケットの AWS KMS ポリシーに次のような許可を追加してください。 ``` { "Effect": "Allow", "Action": [ "kms:GenerateDataKey" ], "Resource": "role-arn" } ``` *role-arn* を、アカウントで作成した Amazon リソースネーム (ARN) に、`arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole` 形式で置き換えます。 詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[AWS KMS でのキーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)」を参照してください。 スケジュールに基づいてレポートを初めて生成する際に、Systems Manager は、エクスポートプロセスに使用するサービスロール `AWS-SystemsManager-PatchSummaryExportRole` (まだ作成されていない場合) とともに、`AWS-EventBridge-Start-SSMAutomationRole` という名前の別のサービスロールを作成します。`AWS-EventBridge-Start-SSMAutomationRole` は、Amazon EventBridge を有効にしてランブック [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) を使用してオートメーションを開始できるようにします。 これらのポリシーとロールを変更することはお勧めしません。変更することにより、パッチコンプライアンスレポートの生成が失敗する可能性があります。詳細については、「」を参照してください[パッチコンプライアンスレポートの生成のトラブルシューティング](#patch-compliance-reports-troubleshooting) **Topics** + [生成されたパッチコンプライアンスレポートには何が含まれていますか?](#patch-compliance-reports-to-s3-examples) + [単一マネージドノードのパッチコンプライアンスレポートの生成](#patch-compliance-reports-to-s3-one-instance) + [すべてのマネージドノードのパッチコンプライアンスレポートの生成](#patch-compliance-reports-to-s3-all-instances) + [パッチコンプライアンスレポートの履歴の表示](#patch-compliance-reporting-history) + [パッチコンプライアンスレポートのスケジュールの表示](#patch-compliance-reporting-schedules) + [パッチコンプライアンスレポートの生成のトラブルシューティング](#patch-compliance-reports-troubleshooting) ## 生成されたパッチコンプライアンスレポートには何が含まれていますか? このトピックでは、指定された S3 バケットに生成およびダウンロードされるパッチコンプライアンスレポートに含まれるコンテンツの種類について説明します。 ### 単一のマネージドノードのレポートの形式 単一のマネージドノードノードについて生成されるレポートには、概要情報と詳細情報の両方が含まれています。 [[Download a sample report (single node)]](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip) (サンプルレポートをダウンロードする (単一ノード)) 単一マネージドノードの概要情報には、次の情報が含まれます。 + [Index] (インデックス) + インスタンス ID + Instance name + インスタンス IP + プラットフォーム名 + プラットフォームバージョン + SSM Agent バージョン + パッチベースライン + パッチグループ + コンプライアンス状況 + コンプライアンスの重要度 + 非準拠のパッチ数 (重大) + 非準拠のパッチ数 (高) + 非準拠のパッチ数 (中) + 非準拠のパッチ数 (低) + 非準拠のパッチ数 (情報) + 非準拠のパッチ数 (指定なし) 単一マネージドノードの詳細情報には、次の情報が含まれます。 + [Index] (インデックス) + インスタンス ID + Instance name + パッチ名 + KB ID/パッチ ID + パッチ状態 + 最終レポート時刻 + コンプライアンスレベル + パッチの重大度 + パッチの分類 + CVE ID + パッチベースライン + ログ URL + インスタンス IP + プラットフォーム名 + プラットフォームバージョン + SSM Agent バージョン **注記** カスタムのパッチベースラインを作成する場合、そのパッチベースラインによって承認されたパッチのコンプライアンスの重要度レベル (`Critical` または `High` など) を指定できます。承認された任意のパッチのパッチ状態が `Missing` と報告された場合、パッチベースラインで報告される全体的なコンプライアンスの重要度は、指定した重要度レベルになります。 ### すべてのマネージドノードのレポートの形式 すべてのマネージドノードについて生成されたレポートには、概要情報のみが含まれています。 [[Download a sample report (all managed nodes)]](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip) (サンプルレポートをダウンロードする (すべてのマネージドノード)) すべてのマネージドノードの概要情報には、次の情報が含まれます。 + [Index] (インデックス) + インスタンス ID + Instance name + インスタンス IP + プラットフォーム名 + プラットフォームバージョン + SSM Agent バージョン + パッチベースライン + パッチグループ + コンプライアンス状況 + コンプライアンスの重要度 + 非準拠のパッチ数 (重大) + 非準拠のパッチ数 (高) + 非準拠のパッチ数 (中) + 非準拠のパッチ数 (低) + 非準拠のパッチ数 (情報) + 非準拠のパッチ数 (指定なし) ## 単一マネージドノードのパッチコンプライアンスレポートの生成 AWS アカウント の単一マネージドノードのパッチ概要レポートを生成するには、以下の手順を実行します。単一マネージドノードのレポートには、コンプライアンス違反の各パッチの詳細 (パッチ名やIDなど) が表示されます。 **単一マネージドノードのパッチコンプライアンスレポートを生成するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[Compliance reporting]** (コンプライアンスレポート) タブを選択します。 1. レポートを生成するマネージドノードの行のボタンを選択し、[**View detail**] (詳細の表示) を選択します。 1. **[Patch summary]** (パッチの概要) セクションで、**[Export to S3]** (S3 へのエクスポート) を選択します。 1. [**Report name**] (レポート名) で、後でレポートを識別しやすくするための名前を入力します。 1. [**Reporting frequency**] (レポートの頻度) で、次のいずれかを選択します。 + **オンデマンド** – 1 回限りのレポートを作成します。ステップ 9 に進みます。 + **スケジュール** – レポートを自動的に生成する定期的なスケジュールを指定します。ステップ 8 に進みます。 1. [**Schedule type**] (スケジュールタイプ) で、3 日ごとなどのレート式を指定するか、または cron 式を指定してレポートの頻度を設定します。 cron 式の詳細については、「[リファレンス: Systems Manager の cron 式および rate 式](reference-cron-and-rate-expressions.md)」を参照してください。 1. [**Bucket name**] (バケット名) で、.csv レポートファイルを保存する S3 バケットの名前を選択します。 **重要** 2019 年 3 月 20 日以降に立ち上げられた AWS リージョン で作業している場合は、同じリージョンで S3 バケットを選択する必要があります。その日付以降に立ち上げられたリージョンは、デフォルトでは無効になっています。これらのリージョンの詳細およびリストについては、「Amazon Web Services 全般のリファレンス」の「[リージョンの有効化](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)」を参照してください。 1. (オプション) レポートの生成時に通知を送信するには、**[SNS topic] **(SNS トピック) セクションを消費して、**[SNS topic Amazon Resource Name (ARN)]** (SNS トピック Amazon リソースネーム (ARN)) から既存の Amazon SNS トピックを選択します。 1. [**Submit**] (送信) をクリックします。 生成されたレポートの履歴の表示については、「[パッチコンプライアンスレポートの履歴の表示](#patch-compliance-reporting-history)」を参照してください。 作成したレポートスケジュールの詳細を表示する方法については、「[パッチコンプライアンスレポートのスケジュールの表示](#patch-compliance-reporting-schedules)」を参照してください。 ## すべてのマネージドノードのパッチコンプライアンスレポートの生成 AWS アカウント のすべてのマネージドノードのパッチ概要レポートを生成するには、以下の手順を実行します。すべてのマネージドノードのレポートには、どのノードがコンプライアンス違反であるか、非準拠のパッチの数が表示されます。パッチの名前やその他の識別子は提供しません。これらの追加の詳細情報を確認するには、単一のマネージドノードのパッチコンプライアンスレポートを生成できます。詳細については、このトピックの前半の「[単一マネージドノードのパッチコンプライアンスレポートの生成](#patch-compliance-reports-to-s3-one-instance)」を参照してください。 **すべてのマネージドノードのパッチコンプライアンスレポートを生成するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[Compliance reporting]** (コンプライアンスレポート) タブを選択します。 1. [**Export to S3**] (S3 へのエクスポート) を選択します。(最初にノード ID を選択しないでください。) 1. [**Report name**] (レポート名) で、後でレポートを識別しやすくするための名前を入力します。 1. [**Reporting frequency**] (レポートの頻度) で、次のいずれかを選択します。 + **オンデマンド** – 1 回限りのレポートを作成します。ステップ 8 に進みます。 + **スケジュール** – レポートを自動的に生成する定期的なスケジュールを指定します。ステップ 7 に進みます。 1. [**Schedule type**] (スケジュールタイプ) で、3 日ごとなどのレート式を指定するか、または cron 式を指定してレポートの頻度を設定します。 cron 式の詳細については、「[リファレンス: Systems Manager の cron 式および rate 式](reference-cron-and-rate-expressions.md)」を参照してください。 1. [**Bucket name**] (バケット名) で、.csv レポートファイルを保存する S3 バケットの名前を選択します。 **重要** 2019 年 3 月 20 日以降に立ち上げられた AWS リージョン で作業している場合は、同じリージョンで S3 バケットを選択する必要があります。その日付以降に立ち上げられたリージョンは、デフォルトでは無効になっています。これらのリージョンの詳細およびリストについては、「Amazon Web Services 全般のリファレンス」の「[リージョンの有効化](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)」を参照してください。 1. (オプション) レポートの生成時に通知を送信するには、**[SNS topic] **(SNS トピック) セクションを消費して、**[SNS topic Amazon Resource Name (ARN)]** (SNS トピック Amazon リソースネーム (ARN)) から既存の Amazon SNS トピックを選択します。 1. [**Submit**] (送信) をクリックします。 生成されたレポートの履歴の表示については、「[パッチコンプライアンスレポートの履歴の表示](#patch-compliance-reporting-history)」を参照してください。 作成したレポートスケジュールの詳細を表示する方法については、「[パッチコンプライアンスレポートのスケジュールの表示](#patch-compliance-reporting-schedules)」を参照してください。 ## パッチコンプライアンスレポートの履歴の表示 このトピックの情報は、 で生成されたパッチコンプライアンスレポートの詳細を表示するのに役立ちますAWS アカウント **パッチコンプライアンスのレポート履歴を表示するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[Compliance reporting]** (コンプライアンスレポート) タブを選択します。 1. [**View all S3 exports**] (すべての S3 エクスポートを表示) を選択し、[**Export history**] (エクスポート履歴) タブを選択します。 ## パッチコンプライアンスレポートのスケジュールの表示 このトピックの情報は、 で作成されるパッチコンプライアンスレポートのスケジュールの詳細を表示するのに役立ちますAWS アカウント **パッチコンプライアンスのレポート履歴を表示するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[Compliance reporting]** (コンプライアンスレポート) タブを選択します。 1. **[View all S3 exports]** (すべての S3 エクスポートを表示) を選択し、**[Scheduled report]** (スケジュールされたレポート) タブを選択します。 ## パッチコンプライアンスレポートの生成のトラブルシューティング 以下の情報は、AWS Systems Manager のツールである Patch Manager でパッチコンプライアンスレポートを生成する際に発生する問題のトラブルシューティングに役立ちます。 **Topics** + [`AWS-SystemsManager-PatchManagerExportRolePolicy` ポリシーが壊れているというメッセージが表示される](#patch-compliance-reports-troubleshooting-1) + [パッチコンプライアンスポリシーまたはロールを削除した後、スケジュールされたレポートが正常に生成されない](#patch-compliance-reports-troubleshooting-2) ### `AWS-SystemsManager-PatchManagerExportRolePolicy` ポリシーが壊れているというメッセージが表示される **問題**: `AWS-SystemsManager-PatchManagerExportRolePolicy` が破損していることを示す、次のようなエラーメッセージが表示されます。 ``` An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy policy. If you have edited the policy, you might need to delete the policy, and any role that uses it, then try again. Systems Manager recreates the roles and policies you have deleted. ``` + **解決策**: 新しいパッチコンプライアンスレポートを生成する前に、Patch Manager コンソールまたは AWS CLI を使用して、影響を受けるロールとポリシーを削除します。 **コンソールを使用して破損したポリシーを削除するには** 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. 次のいずれかを行ってください。 **オンデマンドレポート** – 1 回限りのオンデマンドレポートの生成中に問題が発生した場合は、左側のナビゲーションで [**Policies**] (ポリシー) を選択し、`AWS-SystemsManager-PatchManagerExportRolePolicy` を検索して、ポリシーを削除します。次に、[**Roles**] (ロール) を選択し、`AWS-SystemsManager-PatchSummaryExportRole` を検索して、ロールを削除します。 **スケジュールされたレポート** – スケジュールに従ってレポートを生成しているときに問題が発生した場合は、左側のナビゲーションで **[ポリシー]** を選択し、`AWS-EventBridge-Start-SSMAutomationRolePolicy` と `AWS-SystemsManager-PatchManagerExportRolePolicy` をそれぞれ検索して、各ポリシーを削除します。次に、[**Roles**] (ロール) を選択し、`AWS-EventBridge-Start-SSMAutomationRole` と `AWS-SystemsManager-PatchSummaryExportRole` をそれぞれ検索して、各ロールを削除します。 **AWS CLI を使用して破損したポリシーを削除するには** *placeholder values* をアカウントID に置き換えます。 + 1 回限りのオンデマンドレポートの生成中に問題が発生した場合は、次のコマンドを実行します。 ``` aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy ``` ``` aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole ``` スケジュールに基づくレポートの生成中に問題が発生した場合は、次のコマンドを実行します。 ``` aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy ``` ``` aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy ``` ``` aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole ``` ``` aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole ``` いずれかの手順を完了したら、次のステップに従って新しいパッチコンプライアンスレポートを生成またはスケジュールします。 ### パッチコンプライアンスポリシーまたはロールを削除した後、スケジュールされたレポートが正常に生成されない **問題**: レポートを初めて生成する際、Systems Manager は、エクスポートプロセスに使用するサービスロールとポリシー (`AWS-SystemsManager-PatchSummaryExportRole` および `AWS-SystemsManager-PatchManagerExportRolePolicy`) を作成します。スケジュールに基づいてレポートを初めて生成する際、Systems Manager は、別のサービスロールとポリシー (`AWS-EventBridge-Start-SSMAutomationRole` および `AWS-EventBridge-Start-SSMAutomationRolePolicy`) を作成します。Amazon EventBridge では、ランブック -[AWSExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) を使用してオートメーションを開始します。 これらのポリシーまたはロールのいずれかを削除すると、スケジュールと指定した S3 バケットと Amazon SNS トピックの間の接続が失われる可能性があります。 + **解決方法**: この問題を回避するには、以前のスケジュールを削除し、問題が発生していたスケジュールの代わりとなる新しいスケジュールを作成することをお勧めします。 # Patch Manager で非準拠のマネージドノードを修復するには このセクションのトピックでは、パッチコンプライアンスに違反しているマネージドノードを識別する方法とノードをコンプライアンスに準拠させる方法の概要を説明します。 **Topics** + [非準拠のマネージドノードの識別](patch-manager-find-noncompliant-nodes.md) + [パッチコンプライアンス状態の値](patch-manager-compliance-states.md) + [非準拠マネージドノードへのパッチ適用](patch-manager-compliance-remediation.md) # 非準拠のマネージドノードの識別 コンプライアンス違反のマネージドノードは、2 つの AWS Systems Manager ドキュメント (SSM ドキュメント) のいずれかが実行されたときに識別されます。このような SSM ドキュメントは、AWS Systems Manager のツールである Patch Manager で各マネージドノードに対する適切なパッチベースラインを参照します。次に、マネージドノードのパッチ状態を評価すると、コンプライアンス結果を利用できるようになります。 非準拠のマネージドノードを識別または更新するために使用される 2 つの SSM ドキュメントは、`AWS-RunPatchBaseline` と `AWS-RunPatchBaselineAssociation` です。各ドキュメントは異なるプロセスで使用され、そのコンプライアンス結果は異なるチャネルを通じて入手できます。次の表に、これらのドキュメントの違いについて説明します。 **注記** Patch Manager からパッチコンプライアンスデータを AWS Security Hub CSPM に送信できます Security Hub CSPM では、高優先度のセキュリティアラートとコンプライアンス状況を包括的に確認できます。また、フリートのパッチ適用状況も監視できます。詳細については、「」を参照してください[Patch Managerと AWS Security Hub CSPM の統合](patch-manager-security-hub-integration.md) | | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` | | --- | --- | --- | | ドキュメントを使用するプロセス | **オンデマンドでパッチ** - **[Patch now]** (今すぐパッチ) オプションを使用して、オンデマンドでマネージドノードをスキャンするか、インスタンスにパッチを適用できます。詳細については、「[マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md)」を参照してください。 **Systems Manager Quick Setup パッチポリシー** – 組織全体、組織単位の一部、またはシングル AWS アカウントに対して、未適用のパッチがないかのスキャンと未適用のパッチのインストールを別々のスケジュールで実行できるパッチ適用設定を AWS Systems Manager のツールである Quick Setup で作成できます。詳細については、「[Quick Setup パッチポリシーを使用して組織内のインスタンスのためにパッチ適用を設定する](quick-setup-patch-manager.md)」を参照してください。 **コマンドを実行する** – AWS Systems Manager のツールである Run Command 内のオペレーションで `AWS-RunPatchBaseline` を手動で実行できます。詳細については、「[コンソールからコマンドを実行する](running-commands-console.md)」を参照してください。 **メンテナンスウィンドウ** – Run Command タスクタイプの SSM ドキュメント `AWS-RunPatchBaseline` を使用するメンテナンスウィンドウを作成できます。詳細については、「[チュートリアル: コンソールを使用してパッチ用メンテナンスウィンドウを作成する](maintenance-window-tutorial-patching.md)」を参照してください。 | **Systems Manager Quick Setup ホスト管理** – Quick Setup でホスト管理設定オプションを有効にすると、マネージインスタンスを毎日スキャンしてパッチコンプライアンスを確認できます。詳細については、「[Quick Setup を使用して Amazon EC2 ホスト管理を設定する](quick-setup-host-management.md)」を参照してください。 **Systems Manager [Explorer](Explorer.md)** – AWS Systems Manager のツールである Explorer を許可すると、マネージドインスタンスを定期的にスキャンしてパッチコンプライアンスと検出結果を Explorer ダッシュボードに表示できます。 | | パッチスキャン結果データの形式 | `AWS-RunPatchBaseline` の実行後、Patch Manager は `AWS:PatchSummary` オブジェクトを AWS Systems Manager のツールである Inventory に送信します。このレポートは、パッチ適用オペレーションが成功した場合にのみ生成され、コンプライアンスステータスが計算されたときを識別するキャプチャ時間が含まれます。 | `AWS-RunPatchBaselineAssociation` の実行後、Patch Manager は `AWS:ComplianceItem` オブジェクトをSystems Manager Inventory に送信します。 | | コンソールでのパッチコンプライアンスレポートの表示 | [Systems Manager Configuration Compliance](systems-manager-compliance.md) および `AWS-RunPatchBaseline` で [マネージドノードの使用](fleet-manager-managed-nodes.md) を使用するプロセスのパッチコンプライアンス情報を表示できます。詳細については、「[パッチコンプライアンス結果の表示](patch-manager-view-compliance-results.md)」を参照してください。 | Quick Setup を使用してマネージドインスタンスをスキャンしてパッチコンプライアンスを確認する場合、[[Systems Manager Fleet Manager]](fleet-manager.md) でコンプライアンスレポートを確認できます。Fleet Manager コンソールで、マネージドノードのノード ID を選択します。**[全般]** メニューで、**[設定コンプライアンス]** を選択します。 Explorer を使用してマネージドインスタンスをスキャンしてパッチコンプライアンスを確認する場合、Explorer と「[Systems Manager OpsCenter](OpsCenter.md)」の両方でコンプライアンスレポートを表示できます。 | | AWS CLIパッチコンプライアンス結果を表示するための コマンド | `AWS-RunPatchBaseline` を使用するプロセスの場合、次の AWS CLI コマンドを使用して、マネージドノードのパッチに関する概要情報を表示できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | `AWS-RunPatchBaselineAssociation` を使用するプロセスの場合、次の AWS CLI コマンドを使用して、インスタンスのパッチに関する概要情報を表示できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | | パッチ適用オペレーション | `AWS-RunPatchBaseline` を使用するプロセスの場合、オペレーションで `Scan` オペレーションのみを実行するか、`Scan and install` オペレーションを実行するかを指定します。 非準拠のマネージドノードを識別し、それらを修正しないことを目標とする場合は、`Scan` オペレーションのみを実行します。 | AWS-RunPatchBaselineAssociation を使用する Quick Setup および Explorer プロセスの場合は、Scan オペレーションのみを実行します。 | | 詳細情報 | [パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) | レポートされる可能性のあるさまざまなパッチコンプライアンス状態については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。 パッチコンプライアンスに違反しているマネージドノードの修正については、「[非準拠マネージドノードへのパッチ適用](patch-manager-compliance-remediation.md)」を参照してください。 # パッチコンプライアンス状態の値 マネージドノードのパッチに関する情報には、個々のパッチの状態、つまり、状況のレポートが含まれます。 **ヒント** マネージドノードに特定のパッチコンプライアンス状態を割り当てるには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) コマンドまたは [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API オペレーションを使用できます。コンプライアンス状態の割り当てはコンソールではサポートされていません。 以下の表の情報を使用して、マネージドノードがパッチコンプライアンスに違反している理由を特定します。 ## Debian Server と Ubuntu Server のパッチのコンプライアンスの値 次の表に、Debian Server と Ubuntu Server でパッケージをコンプライアンスの状態別に分類するルールを示します。 **注記** `INSTALLED`、`INSTALLED_OTHER`、`MISSING` のステータス値を評価する場合、パッチベースラインを作成または更新するときに **[セキュリティ以外の更新を含める]** チェックボックスをオンにしないと、パッチ候補バージョンは、次のリポジトリのパッチに制限されることに注意してください。 Ubuntu Server 16.04 LTS: `xenial-security` Ubuntu Server 18.04 LTS: `bionic-security` Ubuntu Server 20.04 LTS: `focal-security` Ubuntu Server 22.04 LTS (`jammy-security`) Ubuntu Server 24.04 LTS (`noble-security`) Ubuntu Server 25.04 (`plucky-security`) `debian-security` (Debian Server) [**セキュリティ以外の更新を含める**] チェックボックスをオンにした場合は、他のリポジトリからのパッチも考慮されます。 | パッチ状態 | 説明 | コンプライアンスステータス | | --- | --- | --- | | **`INSTALLED`** | パッチはパッチベースラインにリストされ、マネージドノードにインストールされます。マネージドノードで `AWS-RunPatchBaseline` ドキュメントを実行している場合は、既に手動で個別にインストールされていたり、Patch Manager で自動的にインストールされていたりすることがあります。 | 準拠 | | **`INSTALLED_OTHER`** | パッチがベースラインに含まれていない、またはベースラインによって承認されていませんが、マネージドノードにインストールされています。パッチが手動でインストールされているか、パッケージが別の承認済みパッチの必要な依存関係であるか、パッチが InstallOverrideList オペレーションに含まれている可能性があります。[**拒否されたパッチ**] アクションとして `Block` を指定しない場合は、インストール済みでも拒否されたパッチも `INSTALLED_OTHER` パッチに含まれます。 | 準拠 | | **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` は次の 2 つのいずれかを意味します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-compliance-states.html) いずれの場合も、このステータスのパッチで*再起動が必要*という意味ではなく、パッチがインストールされて以降ノードが再起動されていないことを意味します。 | 非準拠 | | **`INSTALLED_REJECTED`** | パッチはマネージドノードにインストールされますが、**[Rejected patches]** (拒否されたパッチ) リストに指定されています。これは通常、パッチが、拒否されたパッチのリストに追加される前にインストールされたことを意味します。 | 非準拠 | | **`MISSING`** | このパッチはベースラインで承認されていますが、マネージドノードにインストールされていません。`AWS-RunPatchBaseline` ドキュメントタスクでスキャン (インストールではなく) するように設定した場合、スキャンで見つかってもインストールされていないパッチがあると、このステータスがレポートされます。 | 非準拠 | | **`FAILED`** | パッチはベースラインで承認されていますが、インストールできませんでした。この状態のトラブルシューティングを行うには、コマンド出力で問題の理解に役立つ情報を確認します。 | 非準拠 | ## その他のオペレーティングシステムのパッチコンプライアンスの値 次の表に、Debian Server と Ubuntu Server 以外のすべてのオペレーティングシステムでパッケージをコンプライアンスの状態別に分類するルールを示します。 | パッチ状態 | 説明 | コンプライアンスの値 | | --- | --- | --- | | **`INSTALLED`** | パッチはパッチベースラインにリストされ、マネージドノードにインストールされます。ノードで `AWS-RunPatchBaseline` ドキュメントを実行している場合は、既に手動で個別にインストールされていたり、Patch Manager で自動的にインストールされていたりすることがあります。 | 準拠 | | **`INSTALLED_OTHER`**1 | パッチはベースラインに含まれていませんが、マネージドノードにインストールされています。これには、次の 2 つの理由が考えられます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-compliance-states.html) | 準拠 | | **`INSTALLED_REJECTED`** | パッチはマネージドノードにインストールされますが、[Rejected patches] (拒否されたパッチ) リストに指定されています。これは通常、パッチが、拒否されたパッチのリストに追加される前にインストールされたことを意味します。 | 非準拠 | | **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` は次の 2 つのいずれかを意味します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-compliance-states.html) いずれの場合も、このステータスのパッチで*再起動が必要*という意味ではなく、パッチがインストールされて以降ノードが再起動されていないことを意味します。 | 非準拠 | | **`MISSING`** | このパッチはベースラインで承認されていますが、マネージドノードにインストールされていません。`AWS-RunPatchBaseline` ドキュメントタスクでスキャン (インストールではなく) するように設定した場合、スキャンで見つかってもインストールされていないパッチがあると、このステータスがレポートされます。 | 非準拠 | | **`FAILED`** | パッチはベースラインで承認されていますが、インストールできませんでした。この状態のトラブルシューティングを行うには、コマンド出力で問題の理解に役立つ情報を確認します。 | 非準拠 | | **`NOT_APPLICABLE`**1 | *このコンプライアンス状態は、Windows Server オペレーティングシステムでのみレポートされます。* パッチはベースラインで承認されていますが、このパッチを使用するサービスまたは機能がマネージドノードにインストールされていません。例えば、Internet Information Services (IIS) などのウェブ サーバーサービスのパッチは、ベースラインで承認されていてもウェブサービスがマネージドノードにインストールされていなければ、`NOT_APPLICABLE` と表示されます。パッチは、後続の更新によって置き換えられた場合に、`NOT_APPLICABLE` マークを付けることもできます。これは、新しい更新プログラムがインストールされ、 `NOT_APPLICABLE` 更新プログラムが不要になったことを意味します。 | 該当しない | | AVAILABLE\$1SECURITY\$1UPDATES | *このコンプライアンス状態は、Windows Server オペレーティングシステムでのみレポートされます。* パッチベースラインで承認されていない使用可能なセキュリティ更新パッチは、カスタムパッチベースラインでの定義に従い、コンプライアンス値 (`Compliant` または `Non-Compliant`) を持つことができます。 パッチベースラインを作成または更新するときに、パッチベースラインで指定されたインストール基準を満たしていないため、使用可能ではあるものの承認されていないセキュリティパッチに割り当てるステータスを選択します。例えば、パッチがリリースされてからインストールされるまでに待機する期間を長く指定している場合は、インストールするセキュリティパッチをスキップできます。指定した待機期間中にパッチの更新がリリースされると、パッチのインストールの待機期間がもう一度開始されます。待機期間が長すぎる場合、複数のバージョンのパッチがリリースされ、インストールされない可能性があります。 パッチの概数では、パッチが `AvailableSecurityUpdate` としてレポートされる場合は、常に `AvailableSecurityUpdateCount` に含まれます。これらのパッチを `NonCompliant` としてレポートするようにベースラインが設定されている場合は、`SecurityNonCompliantCount` にも含まれます。これらのパッチを `Compliant` としてレポートするようにベースラインが設定されている場合は、`SecurityNonCompliantCount` には含まれません。これらのパッチは常に重要度が指定されていない状態でレポートされ、`CriticalNonCompliantCount` に含まれることはありません。 | 使用可能なセキュリティ更新用に選択されたオプションに応じて、準拠または非準拠。 コンソールを使用してパッチベースラインを作成または更新するには、**[使用可能なセキュリティ更新のコンプライアンスステータス]** フィールドでこのオプションを指定します。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` パラメータでこのオプションを指定します。 | ¹ 状態が `INSTALLED_OTHER` および `NOT_APPLICABLE` のパッチの場合、Patch Manager は [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) コマンドに基づいて、クエリ結果から一部のデータを省略します (`Classification` や `Severity` の値など)。これにより、AWS Systems Manager のツールである Inventory において、個々のノードのデータ制限を超えないようにすることができます。すべてのパッチの詳細を表示するには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) コマンドを使用します。 # 非準拠マネージドノードへのパッチ適用 パッチコンプライアンスについてマネージドノードをチェックするために使用できる AWS Systems Manager ツールおよびプロセスの多くは、現在適用されているパッチルールにノードを準拠させるために使用できます。マネージドノードをパッチコンプライアンスにするには、AWS Systems Manager のツールである Patch Manager で `Scan and install` オペレーションを実行する必要があります。(非準拠マネージドノードを識別し、それらを修正しないことを目標とする場合は、代わりに `Scan` オペレーションを実行します。詳細については、「[非準拠のマネージドノードの識別](patch-manager-find-noncompliant-nodes.md)」を参照してください。) **Systems Manager を使用してパッチをインストールする** `Scan and install` オペレーションを実行するには、いくつかのツールから選択できます。 + (推奨) Systems Manager のツールである Quick Setup でパッチポリシーを設定すると、組織全体、組織単位の一部、またはシングル AWS アカウントに対して、未適用のパッチをスケジュールに従ってインストールできます。詳細については、「[Quick Setup パッチポリシーを使用して組織内のインスタンスのためにパッチ適用を設定する](quick-setup-patch-manager.md)」を参照してください。 + Run Command タスクタイプで、Systems Manager ドキュメント (SSM ドキュメント) `AWS-RunPatchBaseline` を使用するメンテナンスウィンドウを作成します。詳細については、「[チュートリアル: コンソールを使用してパッチ用メンテナンスウィンドウを作成する](maintenance-window-tutorial-patching.md)」を参照してください。 + Run Command オペレーションで `AWS-RunPatchBaseline` を手動で実行します。詳細については、「[コンソールからコマンドを実行する](running-commands-console.md)」を参照してください。 + [**Patch now (今すぐパッチ)]** オプションを使用して、オンデマンドでパッチをインストールします。詳細については、「[マネージドノードへのオンデマンド パッチ適用](patch-manager-patch-now-on-demand.md)」を参照してください。 # パッチコンプライアンスデータを作成した実行の特定 パッチコンプライアンスデータは、最後に成功したパッチ適用オペレーションからのポイントインタイムスナップショットを表します。各コンプライアンスレポートには、実行 ID と、コンプライアンスデータを作成したオペレーションとその生成日時を特定するのに役立つキャプチャ時間の両方が含まれます。 インスタンスに対するパッチコンプライアンスのスキャン処理に複数の種類が存在する場合、スキャンからのパッチコンプライアンスデータは、次のスキャンが行われるたびに上書きされます。その結果、パッチコンプライアンスデータで想定外の結果を得ることがあります。 例えば、現地時間の午前 2 時に毎日、パッチコンプライアンスをスキャンするパッチポリシーを作成したとします。このパッチポリシーでは、重大度が `Critical`、`Important`、および `Moderate` としてマークされたパッチを対象とする、パッチベースラインを使用しています。このパッチベースラインでは、特に拒否されたパッチもいくつか指定されています。 また、毎日、現地時間の午前 4 時に同じマネージドノードのセットをスキャンするメンテナンスウィンドウがすでに設定されていて、それを削除したり無効化したりすることはないとします。このメンテナンスウィンドウのタスクでは、重大度が `Critical` のパッチのみを対象とする別のパッチベースラインを使用しており、また、特定のパッチを除外することはありません。 この 2 回目のスキャンがメンテナンスウィンドウで実行されると、1 回目のスキャンによるパッチコンプライアンスデータは削除され、この 2 回目のスキャンのパッチコンプライアンスデータにより置き換えられます。 そのため、パッチ適用処理においてスキャンとインストールを自動化する場合には、単一の方法のみを使用するように強くお勧めします。パッチポリシーを設定するには、パッチコンプライアンスの他のスキャン方法を削除または無効化する必要があります。詳細については、以下の各トピックを参照してください。 + パッチ適用オペレーションタスクを、メンテナンスウィンドウから削除するには – [コンソールを使用してメンテナンスウィンドウタスクを更新または登録解除する](sysman-maintenance-update.md#sysman-maintenance-update-tasks) + State Manager の関連付けを削除するには – [関連付けを削除する](systems-manager-state-manager-delete-association.md) ホスト管理設定で毎日のパッチコンプライアンススキャンを無効にするには、Quick Setup で次の操作を行います。 1. ナビゲーションペインで、**Quick Setup** を選択します。 1. 更新するホスト管理設定を選択します。 1. **[Actions, Edit configuration]** (アクション、設定の編集) を選択します。 1. **[Scan instances for missing patches daily]** (不足しているパッチがないか毎日インスタンスをスキャンする) のチェックボックスをオフにします。 1. **[更新]** を選択します。 **注記** **[Patch now]** (今すぐパッチ適用) オプションを使用して、マネージドノードのコンプライアンスをスキャンすると、同時にパッチコンプライアンスデータも上書きされます。 # マネージドノードへのオンデマンド パッチ適用 AWS Systems Manager のツールである Patch Manager の **[今すぐパッチ適用]** オプションを使用すると、Systems Manager コンソールからオンデマンドでパッチ適用オペレーションを実行できます。つまり、マネージドノードのコンプライアンス状況を更新したり、準拠していないノードにパッチをインストールしたりするために、スケジュールを作成する必要はありません。また、スケジュールされたパッチ適用ウィンドウを設定または変更するために、Systems Manager コンソールを Patch Manager と、AWS Systems Manager のツールである Maintenance Windows との間で切り替える必要もありません。 **[Patch now]** (今すぐパッチを適用) は、ゼロデイアップデートを適用したり、マネージドノードに他の重要なパッチをできるだけ早くインストールしたりする必要がある場合に特に便利です。 **注記** オンデマンドのパッチ適用では、一度に 1 組の AWS アカウント と AWS リージョン のペアのみサポートされます。パッチポリシーに基づくパッチ適用オペレーションには使用できません。すべてのマネージドノードをコンプライアンス状態にしておくために、パッチポリシーを使用することをお勧めします。パッチポリシーの使用の詳細については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。 **Topics** + [「Patch now (今すぐパッチ)」の仕組み](#patch-on-demand-how-it-works) + [[今すぐパッチ適用] の実行](#run-patch-now) ## 「Patch now (今すぐパッチ)」の仕組み [**Patch now** (今すぐパッチ)] を実行するには、次の 2 つの必須設定のみを指定します。 + 欠落しているパッチのみをスキャンするか、パッチをスキャンして、*かつ*、マネージドノードにインストールするか + どのマネージドノードでオペレーションを実行するか [**今すぐパッチ**] オペレーションを実行すると、他のパッチオペレーションで選択するのと同じ方法で使用するパッチベースラインを決定します。マネージドノードがパッチグループに関連付けられている場合は、そのグループに指定されたパッチベースラインが使用されます。マネージドノードがパッチグループに関連付けられていない場合、この操作では、マネージドノードのオペレーティングシステムタイプのデフォルトとして現在設定されているパッチベースラインが使用されます。定義済みのベースラインでも、デフォルトとして設定したカスタムベースラインでもかまいません。パッチベースライン選択の詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。 **[Patch now]** (今すぐパッチ) で指定できるオプションには、パッチ適用後にマネージドノードを再起動するタイミングまたは再起動するかどうかの選択、パッチ適用オペレーションのログデータを保存する Amazon Simple Storage Service (Amazon S3) バケットの指定、パッチ適用中のライフサイクルフックとしての Systems Manager ドキュメント (SSM ドキュメント) の実行などがあります。 ### [Patch now (今すぐパッチ適用)] の同時実行とエラーしきい値 [**Patch now** (今すぐパッチ適用)] オペレーションでは、Patch Manager が同時実行とエラーしきい値のオプションに対応します。一度にパッチを適用するマネージドノードの数を指定する必要も、操作が失敗するまでに許可するエラーの数を指定する必要もありません。Patch Manager は、オンデマンドでパッチを適用するときに、次の表に示す同時実行数とエラーのしきい値の設定を適用します。 **重要** 次のしきい値は、`Scan and install` オペレーションのみに適用されます。`Scan` オペレーションの場合、Patch Manager は最大 1,000 個のノードのスキャンを同時に試みます。また、最大 1,000 個のエラーが発生するまでスキャンを続行します。 **同時実行: インストールオペレーション** | **[Patch now]** (今すぐパッチ適用) オペレーションでのマネージドノードの合計数 | 一度にスキャンされる、またはパッチが適用されるマネージドノードの数 | | --- | --- | | 25 未満 | 1 | | 25～100 | 5% | | 101～1,000 | 8% | | 1000 超 | 10% | **エラーしきい値: インストールオペレーション** | **[Patch now]** (今すぐパッチ適用) オペレーションでのマネージドノードの合計数 | 操作が失敗する前に許可されるエラーの数 | | --- | --- | | 25 未満 | 1 | | 25～100 | 5 | | 101～1,000 | 10 | | 1000 超 | 10 | ### [今すぐパッチ適用] ライフサイクルフックの使用 [**Patch now** (今すぐパッチ適用)] では、`Install` パッチ適用オペレーション中、ライフサイクルフックとして SSM コマンドドキュメントを実行できます。これらのフックは、パッチの適用前にアプリケーションをシャットダウンしたり、パッチ適用後または再起動後にアプリケーションに対してヘルスチェックを実行したりするといったタスクに使用できます。 ライフサイクルフック使用の詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)」を参照してください。 次の表には、3 つの [**今すぐパッチ適用**] 再起動オプションのそれぞれで利用できるライフサイクルフックと、各フックの使用例が含まれています。 **ライフサイクルフックと使用例** | 再起動オプション | フック: インストール前 | フック: インストール後 | フック: 終了時 | フック：スケジュールされた再起動後 | | --- | --- | --- | --- | --- | | 必要に応じて再起動 | パッチ適用を開始する前に SSM ドキュメントを実行します。 使用例：パッチ適用プロセスの開始前に、アプリケーションを安全にシャットダウンします。 | パッチ適用の終了時およびマネージドノードの再起動前に SSM ドキュメントを実行します。 使用例: 再起動前にサードパーティーのアプリケーションのインストールなどの操作を実行します。 | パッチ適用オペレーションを完了し、インスタンスが再起動されてから SSM ドキュメントを実行します。 使用例: パッチ適用後、アプリケーションが期待どおりに動作していることを確認します。 | 利用不可 | | インスタンスを再起動しない | 上記と同じ。 | パッチ適用操作の終了時に SSMドキュメントを実行します。 使用例: パッチ適用後、アプリケーションが期待どおりに動作していることを確認します。 | *利用不可* | *利用不可* | | 再起動時間をスケジュールする | 上記と同じ。 | インスタンスを再起動しないと同じ。 | 利用不可 | スケジュールされていた再起動が完了した直後に SSM ドキュメントを実行します。 使用例：再起動後にアプリケーションが期待どおりに動作していることを確認します。 | ## [今すぐパッチ適用] の実行 以下の手順に従って、オンデマンドでマネージドノードにパッチを適用します。 **「Patch now (今すぐパッチ)」を実行するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. [**Patch now (今すぐパッチ)**] を選択します。 1. [**パッチ適用操作**] で、次のいずれかを選択します。 + **[Scan]** (スキャン): Patch Manager は、マネージドノードに不足しているパッチを検出しますが、インストールしません。結果は、[**コンプライアンス**] ダッシュボード、またはパッチコンプライアンスの表示に使用するその他のツールで表示できます。 + **[Scan and install]** (スキャンとインストール): Patch Manager は、マネージドノードに不足しているパッチを検出してインストールします。 1. この手順は、前の手順で [**Scan and install**] (スキャンとインストール) を選択した場合にのみ使用します。[**Reboot option**] (再起動オプション) で 、次のいずれかを選択します。 + **[Reboot if needed]** (必要に応じて再起動): インストール後、Patch Manager は、パッチのインストールを完了するために必要な場合にのみマネージドノードを再起動します。 + **[Don't reboot my instances]** (インスタンスを再起動しない): インストール後、Patch Manager はマネージドノードを再起動しません。Patch Manager 外での再起動を選択または管理するときに、ノードを手動で再起動できます。 + **[Schedule a reboot time]** (再起動時刻をスケジュール): Patch Manager でマネージドノードを再起動する日付、時刻、および UTC タイムゾーンを指定します。[**Patch now** (今すぐパッチ適用)] 操作の実行後、スケジュールされていた再起動は「`AWS-PatchRebootAssociation`」という名前で関連付けとして State Manager にリストされます。 **重要** 起動後にメインパッチ適用オペレーションをキャンセルした場合、 State Manager の `AWS-PatchRebootAssociation` 関連付けは自動的にキャンセルされません。予期しない再起動を防ぐには、スケジュールされた再起動が発生しないようにするには、`AWS-PatchRebootAssociation` を State Manager から手動で削除する必要があります。そうしないと、予期しないシステム再起動が発生し、本番ワークロードに影響を与える可能性があります。この関連付けは、Systems Manager コンソールの [**State Manager**] の [**関連付け**] にあります。 1. [**Instances to patch** (パッチを適用するインスタンス)] で、次のいずれかを選択します。 + **[Patch all instances]** (すべてのインスタンスにパッチを適用): Patch Manager は、現在の AWS リージョン の AWS アカウント ですべてのマネージドノードに対して、指定したオペレーションを実行します。 + **[Patch only the target instances I specify]**: (指定したターゲットインスタンスのみにパッチを適用) 次のステップで対象にするマネージドノードを指定します。 1. このステップは、前のステップで [**Patch only the target instances I specify**] (指定したターゲットインスタンスのみにパッチを適用) を選択した場合にのみ使用します。**[Target selection]** (ターゲットの選択) セクションで、タグの指定、ノードの手動選択、またはリソースグループの指定により、このオペレーションを実行するノードを特定します。 **注記** 表示されるはずのマネージドノードが表示されない場合は、トラブルシューティングのヒントについて「[マネージドノードの可用性のトラブルシューティング](fleet-manager-troubleshooting-managed-nodes.md)」を参照してください。 リソースグループを対象にすることを選択した場合、AWS CloudFormation スタックに基づいたリソースグループにデフォルトの `aws:cloudformation:stack-id` タグでタグ付けする必要があることに注意してください。これが削除されている場合、Patch Manager はリソースグループに属するマネージドノードを特定できないことがあります。 1. (オプション) [**Patching log storage**] (ログストレージのパッチ適用) で、このパッチ適用オペレーションからログを作成して保存する場合は、ログを保存する S3 バケットを選択します。 **注記** S3 バケットにデータを書き込む機能を許可する S3 許可は、このタスクを実行する IAM ユーザーのものではなく、インスタンスに割り当てられたインスタンスプロファイル (EC2 インスタンスの場合) または IAM サービスロール (ハイブリッドアクティベーションマシン) のものです。詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」または「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。さらに、指定された S3 バケットが別の AWS アカウント にある場合は、マネージドノードに関連付けられたインスタンスプロファイルまたは IAM サービスロールが、そのバケットへの書き込みに必要なアクセス許可があることを確認してください。 1. (オプション) パッチ適用オペレーションの特定の時点で SSM ドキュメントをライフサイクルフックとして実行する場合は、次の手順を実行します。 + [**Use lifecycle hooks**] (ライフサイクルフックを使用) を選択します。 + 使用可能なフックごとに、オペレーションの指定した時点で実行する SSM ドキュメントを選択します。 + インストール前 + インストール後 + 終了時 + スケジュールされた再起動後 **注記** デフォルトのドキュメント `AWS-Noop` では、オペレーションは実行されません。 1. [**Patch now (今すぐパッチ)**] を選択します。 [**Association execution summary (関連付け実行の概要)**] ページが開きます。([今すぐパッチ適用] では、AWS Systems Manager のツールである State Manager の関連付けをオペレーションに使用します)。**[Operation summary]** (オペレーションの概要) では、指定したマネージドノードのスキャンまたはパッチ適用の状況をモニタリングできます。 # パッチベースラインの操作 AWS Systems Manager のツールである Patch Manager のパッチベースラインは、マネージドノードでインストールを承認するパッチを定義します。パッチの承認または拒否は個別に指定できます。また、自動承認ルールを作成して特定のタイプの更新 (例: 重要な更新) を自動承認するよう指定できます。拒否済みリストは、これらのルールと承認リストの両方に優先します。承認済みパッチのリストを使用して特定のパッケージをインストールするには、最初にすべての自動承認ルールを削除します。パッチを明示的に拒否済みとして特定すると、そのパッチは自動承認ルールのすべての基準を満たしていても承認またはインストールされません。また、パッチがマネージドノードに対して承認されていても、パッチがマネージドノードにインストールされるのは、それがノードのソフトウェアに適用される場合に限ります。 **Topics** + [AWS の定義済みパッチベースラインの表示](patch-manager-view-predefined-patch-baselines.md) + [カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md) + [既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md) **詳細情報** + [パッチベースライン](patch-manager-patch-baselines.md) # AWS の定義済みパッチベースラインの表示 AWS Systems Manager のツールである Patch Manager には、Patch Manager でサポートされるオペレーティングシステムごとに事前定義されたパッチベースラインが含まれています。これらのパッチベースライン (カスタマイズはできません) を使用するか、独自のパッチベースラインを作成できます。次の手順では、事前定義されたパッチベースラインを表示してニーズに合っているかどうかを確認する方法について説明します。パッチベースラインの詳細については、「[事前定義されたパッチベースラインおよびカスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md)」を参照してください。 **AWS の定義済みのパッチベースラインを表示するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. パッチベースラインのリストで、事前定義されたパッチベースラインのいずれかのベースライン ID を選択します。 -または- 現在の AWS リージョン で Patch Manager に初めてアクセスしている場合は、**[概要から開始]** で **[パッチベースライン]** を選択してから、事前定義されたパッチベースラインのいずれかのベースライン ID を選択します。 **注記** 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 アプリケーションの両方にパッチを適用できます。 詳細については、「[既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md)」を参照してください。 1. **[承認ルール]** セクションで、パッチベースラインの設定を確認します。 1. 設定がマネージドノードで許容されている場合は、省略して [パッチグループの作成と管理](patch-manager-tag-a-patch-group.md) の手順に進むことができます。 -または- 独自のデフォルトパッチベースラインを作成するには、トピック [カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md) に進みます。 # カスタムパッチベースラインの操作 AWS Systems Manager のツールである Patch Manager には、Patch Manager でサポートされるオペレーティングシステムごとに事前定義されたパッチベースラインが含まれています。これらのパッチベースライン (カスタマイズはできません) を使用するか、独自のパッチベースラインを作成できます。 次の手順では、独自のカスタムパッチベースラインを作成、更新、および削除する方法について説明します。パッチベースラインの詳細については、「[事前定義されたパッチベースラインおよびカスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md)」を参照してください。 **Topics** + [Linux 用 カスタムパッチベースラインの作成](patch-manager-create-a-patch-baseline-for-linux.md) + [macOS のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-macos.md) + [Windows Server のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-windows.md) + [カスタムパッチベースラインの更新または削除](patch-manager-update-or-delete-a-patch-baseline.md) # Linux 用 カスタムパッチベースラインの作成 AWS Systems Manager のツールである Patch Manager で Linux マネージドノードのカスタムパッチベースラインを作成するには、以下の手順に従います。 macOS マネージドノードのパッチベースラインの作成については、「[macOS のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-macos.md)」を参照してください。Windows マネージドノードのパッチベースラインの作成については、「[Windows Server のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-windows.md)」を参照してください。 **Linux マネージドノードのカスタム パッチベースラインを作成するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[パッチベースライン]** タブを選択し、**[パッチベースラインの作成]** を選択します。 -または- 現在の AWS リージョン で Patch Manager に初めてアクセスしている場合は、**[概要から開始]** で **[パッチベースライン]** タブを選択してから、**[パッチベースラインの作成]** を選択します。 1. [**Name (名前)**] フィールドに、新しいパッチベースラインの名前 (例: `MyRHELPatchBaseline`) を入力します。 1. (オプション) [**Description (説明)**] に、パッチベースラインの説明を入力します。 1. [**Operating system (オペレーティングシステム)**] リストでオペレーティングシステム (`Red Hat Enterprise Linux` など) を選択します。 1. このパッチベースラインを作成してすぐに、選択したオペレーティングシステムのデフォルトとして使用する場合は、[**Set this patch baseline as the default patch baseline for *operating system name *instances** (このパッチベースラインをオペレーティングシステム名インスタンスのデフォルトのパッチベースラインにする)] の横にあるボックスをオンにします。 **注記** このオプションは、2022 年 12 月 22 日の[パッチポリシー](patch-manager-policies.md)リリース前に初めて Patch Manager にアクセスした場合にのみ使用できます。 既存のパッチベースラインのデフォルト設定の詳細については、「[既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md)」を参照してください。 1. [**Approval rules for operating-systems (オペレーティングシステムの承認ルール)**] セクションで、フィールドを使用して 1 つ以上の自動承認ルールを作成します。 + **[製品]**: 承認ルールが適用されるオペレーティングシステムのバージョン (`RedhatEnterpriseLinux7.4` など)。デフォルトの選択は `All` です。 + [**Classification (分類)**]: 承認ルールが適用されるパッチのタイプ (`Security` または `Enhancement` など)。デフォルトの選択は `All` です。 **ヒント** パッチベースラインを設定して、RHEL 7.8 などの Linux 用のマイナーバージョンアップグレードをインストールするかどうかを制御できます。マイナーバージョンのアップグレードは、更新プログラムが適切なリポジトリにある場合は、Patch Managerで自動的にインストールできます。 Linux オペレーティングシステムの場合、マイナーバージョンのアップグレードは分類が一貫していません。同じカーネルバージョン内であっても、バグ修正やセキュリティアップデートとして分類されることも、分類されないこともあります。パッチベースラインによってインストールされるかどうかを制御するためのいくつかのオプションを以下に示します。 **オプション 1**: マイナーバージョンのアップグレードが可能な場合に確実にインストールされるための最も広範な承認ルールは、[**分類**] を `All` (\$1) と指定し、[**Include nonsecurity updates (セキュリティ以外の更新を含める)**] オプションを選択することです。 **オプション 2**: オペレーティングシステムバージョンのパッチを確実にインストールするには、ワイルドカード (\$1) を使用して、ベースラインの [**Patch exceptions (パッチの例外)**] セクションでそのカーネル形式を指定できます。例えば、RHEL 7.\$1 のカーネル形式は `kernel-3.10.0-*.el7.x86_64` です。 パッチベースラインの **[Approved patches]** (承認済みパッチ) リストに `kernel-3.10.0-*.el7.x86_64` と入力して、マイナーバージョンアップグレードを含むすべてのパッチが RHEL 7.\$1 マネージドノードに適用されるようにします。(マイナーバージョンパッチの正確なパッケージ名がわかっている場合は、代わりにそれを入力できます)。 **オプション 3**: `AWS-RunPatchBaseline` ドキュメントの [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) パラメータを使用すると、マイナーバージョンのアップグレードなど、マネージドノードに適用するパッチを最大限に制御できます。詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。 + [**Severity (重要度)**]: ルールが適用されるパッチの重要度の値 (`Critical` など)。デフォルトの選択は `All` です。 + [**Auto-approval (自動承認)**]: 自動承認のためにパッチを選択する方法。 **注記** Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペティングシステムでは自動承認オプションがサポートされていません。 + **[Approve patches after a specified number of days]** (指定した日数後にパッチを承認): パッチがリリースまたは最後に更新されてから、自動的に承認されるまで Patch Manager が待機する日数。ゼロ (0) から 360 の任意の整数を入力できます。ほとんどのシナリオでは、待機日数を 100 日以内にすることをお勧めします。 + **[Approve patches released up to a specific date]** (特定の日付までにリリースされたパッチを承認): Patch Manager がその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用するパッチのリリース日。例えば、2023 年 7 月 7 日を指定した場合、リリース日または最後の更新日が 2023 年 7 月 8 日以降であるパッチは、自動的にインストールされません。 + (オプション) **[コンプライアンスレポート]**: ベースラインで承認されたパッチに割り当てる重要度 (`Critical` または `High` など)。 **注記** コンプライアンスレポートレベルを指定し、任意の承認されたパッチのパッチ状態が `Missing` として報告された場合、パッチベースラインで報告されるコンプライアンス全体の重要度は、指定した重要度レベルになります。 + [**Include non-security updates (セキュリティに関連しない更新を含める)**]: セキュリティに関連するパッチに加えて、ソースリポジトリで使用可能なセキュリティに関連しない Linux オペレーティングシステムのパッチをインストールするには、このチェックボックスをオンにします。 カスタムのパッチベースラインでの承認ルールの使用の詳細については、「[カスタムベースライン](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)」を参照してください。 1. 承認ルールに適合するパッチに加えて明示的に承認するパッチがある場合は、[**パッチの例外**] セクションで、以下の操作を実行します。 + [**Approved patches (承認済みパッチ)**] ボックスに、承認するパッチのカンマ区切りリストを入力します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 + (オプション) [**Approved patches compliance level (承認済みパッチのコンプライアンスレベル)**] リストで、リスト内のパッチにコンプライアンスレベルを割り当てます。 + 指定した承認済みパッチがセキュリティに関連しない場合は、**[セキュリティ以外の更新を含める]** チェックボックスをオンにして、これらのパッチも Linux オペレーティングシステムにインストールされるようにします。 1. 承認ルールに適合するパッチにもかかわらず明示的に拒否するパッチがある場合は、[**パッチの例外**] セクションで、以下の操作を実行します。 + [**Rejected patches (拒否済みパッチ)**] ボックスに、拒否するパッチのカンマ区切りリストを入力します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 + [**Rejected patches action (拒否されたパッチのアクション)**] で、[**Rejected patches (拒否されたパッチ)**] リストに含まれているパッチに実行するPatch Managerのアクションを選択します。 + **依存関係として許可**: [**拒否済みパッチ**] リスト内のパッケージは、他のパッケージの依存関係である場合にのみインストールされます。これはパッチベースラインに準拠しているとみなされ、そのステータスは *InstalledOther* として報告されます。オプションが何も指定されていないときは、これがデフォルトのアクションとなります。 + **ブロック**: **[拒否されたパッチ]** リスト内のパッケージ、およびそれらを依存関係として含むパッケージは、いかなる状況でも Patch Manager によってインストールされません。パッケージが **[拒否されたパッチ]** リストに追加される前にインストールされている場合、または後で Patch Manager 以外でインストールされている場合は、そのパッチはパッチベースラインに準拠していないとみなされ、そのステータスは InstalledRejected として報告されます。 **注記** Patch Manager はパッチの依存関係を再帰的に検索します。 1. (オプション) *AmazonLinux2016.03* や *AmazonLinux2017.09* など、異なるバージョンのオペレーティングシステム用に代替パッチリポジトリを指定する場合は、[**Patch sources (パッチソース)**] セクションで、各製品について以下の操作を行います。 + [**Name (名前)**] に、ソース設定を識別するための名前を入力します。 + [**Product (製品)**] で、パッチソースリポジトリが使用されるオペレーティングシステムのバージョン (`RedhatEnterpriseLinux7.4` など) を選択します。 + **[設定]** に、使用するリポジトリ設定の値を、適切な形式で入力します。 ------ #### [ Example for yum repositories ] ``` [main] name=MyCustomRepository baseurl=https://my-custom-repository enabled=1 ``` **ヒント** yum リポジトリ構成で使用できるその他のオプションについては、[ dnf.conf (5) ](https://man7.org/linux/man-pages/man5/dnf.conf.5.html) を参照してください。 ------ #### [ Examples for Ubuntu Server and Debian サーバー ] `deb http://security.ubuntu.com/ubuntu jammy main` `deb https://site.example.com/debian distribution component1 component2 component3` Ubuntu Server リポジトリのリポジトリ情報は、1 行で指定する必要があります。その他の例と情報については、ウェブサイト *Ubuntu Server Manuals* の「[jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html)」および *Debian Wiki* の「[sources.list format](https://wiki.debian.org/SourcesList#sources.list_format)」を参照してください。 ------ [**Add another source (別のソースの追加)**] を選択して、追加のオペレーティングシステムの最大 20 バージョンのそれぞれにソースリポジトリを指定できます。 代替ソースパッチリポジトリの詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。 1. (オプション) [**Manage tags (タグの管理)**] で、1 つ以上のタグキーの名前と値のペアをパッチベースラインに適用します。 タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。例えば、指定したパッチの重要度レベル、適用されるオペレーティングシステムファミリー、環境タイプを識別するためにパッチベースラインにタグ付けする場合があります。この場合、次のようなキーの名前と値のペアのタグを指定することができます。 + `Key=PatchSeverity,Value=Critical` + `Key=OS,Value=RHEL` + `Key=Environment,Value=Production` 1. [**Create patch baseline**] を選択します。 # macOS のカスタムパッチベースラインを作成する AWS Systems Manager のツールである Patch Manager で macOS マネージドノードのカスタムパッチベースラインを作成するには、以下の手順に従います。 Windows Server マネージドノードのパッチベースラインの作成については、「[Windows Server のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-windows.md)」を参照してください。Linux マネージドノードのパッチベースラインの作成については、「[Linux 用 カスタムパッチベースラインの作成](patch-manager-create-a-patch-baseline-for-linux.md)」を参照してください。 **注記** すべての AWS リージョン において macOS はサポートされていません。macOS についての Amazon EC2 のサポートの詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 Mac インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)」を参照してください。 **macOS マネージドノードのカスタム パッチベースラインを作成するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[パッチベースライン]** タブを選択し、**[パッチベースラインの作成]** を選択します。 -または- 現在の AWS リージョン で Patch Manager に初めてアクセスしている場合は、**[概要から開始]** で **[パッチベースライン]** タブを選択してから、**[パッチベースラインの作成]** を選択します。 1. [**Name (名前)**] フィールドに、新しいパッチベースラインの名前 (例: `MymacOSPatchBaseline`) を入力します。 1. (オプション) [**Description (説明)**] に、パッチベースラインの説明を入力します。 1. [**Operating system (オペレーティングシステム)**] で、macOS を選択します。 1. 作成してすぐに、このパッチベースラインを macOS のデフォルトとして使用する場合は、[**このパッチベースラインを macOS インスタンスのデフォルトのパッチベースラインとして設定します**] を選択します。 **注記** このオプションは、2022 年 12 月 22 日の[パッチポリシー](patch-manager-policies.md)リリース前に初めて Patch Manager にアクセスした場合にのみ使用できます。 既存のパッチベースラインのデフォルト設定の詳細については、「[既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md)」を参照してください。 1. [**Approval rules for operating-systems (オペレーティングシステムの承認ルール)**] セクションで、フィールドを使用して 1 つ以上の自動承認ルールを作成します。 + **[製品]**: 承認ルールが適用されるオペレーティングシステムのバージョン (`BigSur11.3.1` または `Ventura13.7` など)。デフォルトの選択は `All` です。 + **分類**: パッチ適用プロセス中にパッケージを適用するパッケージマネージャー。以下から選択できます。 + softwareupdate + installer + brew + brew cask デフォルトの選択は `All` です。 + (オプション) **[コンプライアンスレポート]**: ベースラインで承認されたパッチに割り当てる重要度 (`Critical` または `High` など)。 **注記** コンプライアンスレポートレベルを指定し、任意の承認されたパッチのパッチ状態が `Missing` として報告された場合、パッチベースラインで報告されるコンプライアンス全体の重要度は、指定した重要度レベルになります。 カスタムのパッチベースラインでの承認ルールの使用の詳細については、「[カスタムベースライン](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)」を参照してください。 1. 承認ルールに適合するパッチに加えて明示的に承認するパッチがある場合は、[**パッチの例外**] セクションで、以下の操作を実行します。 + [**Approved patches (承認済みパッチ)**] ボックスに、承認するパッチのカンマ区切りリストを入力します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 + (オプション) [**Approved patches compliance level (承認済みパッチのコンプライアンスレベル)**] リストで、リスト内のパッチにコンプライアンスレベルを割り当てます。 1. 承認ルールに適合するパッチにもかかわらず明示的に拒否するパッチがある場合は、[**パッチの例外**] セクションで、以下の操作を実行します。 + [**Rejected patches (拒否済みパッチ)**] ボックスに、拒否するパッチのカンマ区切りリストを入力します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 + [**Rejected patches action (拒否されたパッチのアクション)**] で、[**Rejected patches (拒否されたパッチ)**] リストに含まれているパッチに実行するPatch Managerのアクションを選択します。 + **依存関係として許可**: [**拒否済みパッチ**] リスト内のパッケージは、他のパッケージの依存関係である場合にのみインストールされます。これはパッチベースラインに準拠しているとみなされ、そのステータスは *InstalledOther* として報告されます。オプションが何も指定されていないときは、これがデフォルトのアクションとなります。 + **ブロック**: **[拒否されたパッチ]** リスト内のパッケージ、およびそれらを依存関係として含むパッケージは、いかなる状況でも Patch Manager によってインストールされません。パッケージが **[拒否されたパッチ]** リストに追加される前にインストールされている場合、または後で Patch Manager 以外でインストールされている場合は、そのパッチはパッチベースラインに準拠していないとみなされ、そのステータスは InstalledRejected として報告されます。 1. (オプション) [**Manage tags (タグの管理)**] で、1 つ以上のタグキーの名前と値のペアをパッチベースラインに適用します。 タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。例えば、指定したパッチの重要度レベル、適用されるパッケージマネージャー、環境タイプを識別するためにパッチベースラインにタグ付けする場合があります。この場合、次のようなキーの名前と値のペアのタグを指定することができます。 + `Key=PatchSeverity,Value=Critical` + `Key=PackageManager,Value=softwareupdate` + `Key=Environment,Value=Production` 1. [**Create patch baseline**] を選択します。 # Windows Server のカスタムパッチベースラインを作成する AWS Systems Manager のツールである Patch Manager で Windows マネージドノードのカスタムパッチベースラインを作成するには、以下の手順に従います Linux マネージドノードのパッチベースラインの作成については、「[Linux 用 カスタムパッチベースラインの作成](patch-manager-create-a-patch-baseline-for-linux.md)」を参照してください。macOS マネージドノードのパッチベースラインの作成については、「[macOS のカスタムパッチベースラインを作成する](patch-manager-create-a-patch-baseline-for-macos.md)」を参照してください。 Windows サービスパックのインストールのみに限定された修正プログラムベースラインの作成例については、「[チュートリアル: コンソールを使用して Windows サービスパックをインストールするためのパッチベースラインを作成する](patch-manager-windows-service-pack-patch-baseline-tutorial.md)」を参照してください 。 **カスタムパッチベースラインを作成するには (Windows)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[パッチベースライン]** タブを選択し、**[パッチベースラインの作成]** を選択します。 -または- 現在の AWS リージョン で Patch Manager に初めてアクセスしている場合は、**[概要から開始]** で **[パッチベースライン]** タブを選択してから、**[パッチベースラインの作成]** を選択します。 1. [**Name (名前)**] フィールドに、新しいパッチベースラインの名前 (例: `MyWindowsPatchBaseline`) を入力します。 1. (オプション) [**Description (説明)**] に、パッチベースラインの説明を入力します。 1. [**Operating system (オペレーティングシステム)**] で、`Windows` を選択します。 1. **[使用可能なセキュリティ更新のコンプライアンスステータス]** で、パッチベースラインで指定されたインストール基準を満たさないため、使用可能ではあるものの承認されていないセキュリティパッチに割り当てるステータス (**[非準拠]** または **[準拠]**) を選択します。 シナリオ例: パッチがリリースされてからインストールされるまでに待機する期間を長く指定している場合は、インストールするセキュリティパッチをスキップできます。指定した待機期間中にパッチの更新がリリースされると、パッチのインストールの待機期間がもう一度開始されます。待機期間が長すぎる場合、複数のバージョンのパッチがリリースされ、インストールされない可能性があります。 1. 作成してすぐに、このパッチベースラインを Windows のデフォルトとして使用する場合は、[**Set this patch baseline as the default patch baseline for Windows Server instances (このパッチベースラインを Windows Server インスタンスのデフォルトのパッチベースラインにする)**] を選択します。 **注記** このオプションは、2022 年 12 月 22 日の[パッチポリシー](patch-manager-policies.md)リリース前に初めて Patch Manager にアクセスした場合にのみ使用できます。 既存のパッチベースラインのデフォルト設定の詳細については、「[既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md)」を参照してください。 1. [**Approval rules for operating systems (オペレーティングシステムの承認ルール)**] セクションで、フィールドを使用して 1 つ以上の自動承認ルールを作成します。 + **[製品]**: 承認ルールが適用されるオペレーティングシステムのバージョン (`WindowsServer2012` など)。デフォルトの選択は `All` です。 + [**Classification (分類)**]: 承認ルールが適用されるパッチのタイプ (`CriticalUpdates`、`Drivers`、`Tools` など)。デフォルトの選択は `All` です。 **ヒント** `ServicePacks` を含めるか、**Classification** リストで `All` を選択して、Windows サービスパックのインストールを承認ルールに含めることができます。例については、「[チュートリアル: コンソールを使用して Windows サービスパックをインストールするためのパッチベースラインを作成する](patch-manager-windows-service-pack-patch-baseline-tutorial.md)」を参照してください。 + [**Severity (重要度)**]: ルールが適用されるパッチの重要度の値 (`Critical` など)。デフォルトの選択は `All` です。 + [**Auto-approval (自動承認)**]: 自動承認のためにパッチを選択する方法。 + **[Approve patches after a specified number of days]** (指定した日数後にパッチを承認): パッチがリリースまたは更新されてから、自動的に承認されるまで Patch Manager が待機する日数。ゼロ (0) から 360 の任意の整数を入力できます。ほとんどのシナリオでは、待機日数を 100 日以内にすることをお勧めします。 + **[Approve patches released up to a specific date]** (特定の日付までにリリースされたパッチを承認): Patch Manager がその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用するパッチのリリース日。例えば、2023 年 7 月 7 日を指定した場合、リリース日または最後の更新日が 2023 年 7 月 8 日以降であるパッチは、自動的にインストールされません。 + (オプション) [**Compliance reporting (コンプライアンスレポート)**]: ベースラインで承認されたパッチに割り当てる重要度 (`High` など)。 **注記** コンプライアンスレポートレベルを指定し、任意の承認されたパッチのパッチ状態が `Missing` として報告された場合、パッチベースラインで報告されるコンプライアンス全体の重要度は、指定した重要度レベルになります。 1. (オプション) [**Approval rules for applications (アプリケーションの承認ルール)**] セクションで、フィールドを使用して 1 つ以上の自動承認ルールを作成します。 **注記** 承認ルールを指定する代わりに、承認されたパッチと拒否されたパッチのリストをパッチ例外として指定できます。手順 10 と 11 を参照してください。 + [**Product family (製品ファミリー)**]: ルールを指定する Microsoft 製品ファミリー全般 (`Office` や `Exchange Server` など)。 + **[製品]**: 承認ルールが適用されるアプリケーションのバージョン (`Office 2016` や `Active Directory Rights Management Services Client 2.0 2016` など)。デフォルトの選択は `All` です。 + [**Classification (分類)**]: 承認ルールが適用されるパッチのタイプ (`CriticalUpdates` など)。デフォルトの選択は `All` です。 + [**Severity (重要度)**]: ルールが適用されるパッチの重要度の値 (`Critical` など)。デフォルトの選択は `All` です。 + [**Auto-approval (自動承認)**]: 自動承認のためにパッチを選択する方法。 + **[Approve patches after a specified number of days]** (指定した日数後にパッチを承認): パッチがリリースまたは更新されてから、自動的に承認されるまで Patch Manager が待機する日数。ゼロ (0) から 360 の任意の整数を入力できます。ほとんどのシナリオでは、待機日数を 100 日以内にすることをお勧めします。 + **[Approve patches released up to a specific date]** (特定の日付までにリリースされたパッチを承認): Patch Manager がその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用するパッチのリリース日。例えば、2023 年 7 月 7 日を指定した場合、リリース日または最後の更新日が 2023 年 7 月 8 日以降であるパッチは、自動的にインストールされません。 + (オプション) **[コンプライアンスレポート]**: ベースラインで承認されたパッチに割り当てる重要度 (`Critical` または `High` など)。 **注記** コンプライアンスレポートレベルを指定し、任意の承認されたパッチのパッチ状態が `Missing` として報告された場合、パッチベースラインで報告されるコンプライアンス全体の重要度は、指定した重要度レベルになります。 1. (オプション) 承認ルールに従ってパッチを選択させるのではなく、パッチを明示的に承認する場合は、[**パッチの例外**] セクションで次の手順を実行します。 + [**Approved patches (承認済みパッチ)**] ボックスに、承認するパッチのカンマ区切りリストを入力します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 + (オプション) [**Approved patches compliance level (承認済みパッチのコンプライアンスレベル)**] リストで、リスト内のパッチにコンプライアンスレベルを割り当てます。 1. 承認ルールに適合するパッチにもかかわらず明示的に拒否するパッチがある場合は、[**パッチの例外**] セクションで、以下の操作を実行します。 + [**Rejected patches (拒否済みパッチ)**] ボックスに、拒否するパッチのカンマ区切りリストを入力します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 + [**Rejected patches action (拒否されたパッチのアクション)**] で、[**Rejected patches (拒否されたパッチ)**] リストに含まれているパッチに実行するPatch Managerのアクションを選択します。 + **依存関係として許可**: Windows Server はパッケージ依存関係の概念をサポートしません。**[拒否されたパッチ]** リスト内のパッケージが既にノードにインストールされている場合、そのステータスは `INSTALLED_OTHER` として報告されます。ノードに既にインストールされていないパッケージはスキップされます。 + **ブロック**: どのような状況下でも、Patch Manager は **[拒否されたパッチ]** リスト内のパッケージをインストールしません。パッケージが **[拒否されたパッチ]** リストに追加される前にインストールされた場合、または追加後に Patch Manager 外でインストールされた場合、そのパッケージはパッチベースラインに準拠していないとみなされ、ステータスは `INSTALLED_REJECTED` として報告されます。 拒否されたパッケージアクションの詳細については、「[カスタムパッチベースラインでの拒否されたパッチリストのオプション](patch-manager-windows-and-linux-differences.md#rejected-patches-diff)」を参照してください。 1. (オプション) [**Manage tags (タグの管理)**] で、1 つ以上のタグキーの名前と値のペアをパッチベースラインに適用します。 タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。例えば、指定したパッチの重要度レベル、適用されるオペレーティングシステムファミリー、環境タイプを識別するためにパッチベースラインにタグ付けする場合があります。この場合、次のようなキーの名前と値のペアのタグを指定することができます。 + `Key=PatchSeverity,Value=Critical` + `Key=OS,Value=RHEL` + `Key=Environment,Value=Production` 1. [**Create patch baseline**] を選択します。 # カスタムパッチベースラインの更新または削除 AWS Systems Manager のツールである Patch Manager で作成したカスタムパッチベースラインは、更新または削除が可能です。パッチベースラインを更新するときに、名前や説明、承認ルール、および承認されたパッチと却下されたパッチの例外を変更できます。パッチベースラインに適用されたタグを変更することもできます。パッチベースラインが作成されたオペレーティングシステムタイプを変更することはできません。 によって提供される事前定義されたパッチベースラインを変更することはできませんAWS ## パッチベースラインの更新または削除 パッチベースラインを更新または削除するには、以下の手順を実行します。 **重要** Quick Setup のパッチポリシー設定で使用されている可能性のあるカスタムパッチベースラインを削除する場合は注意が必要です。 Quick Setup で[パッチポリシー設定](patch-manager-policies.md)を使用している場合、カスタムパッチベースラインに加えた更新は 1 時間に 1 回 Quick Setup と同期されます。 パッチポリシーで参照されていたカスタムパッチベースラインを削除すると、Quick Setup のそのパッチポリシーについての **[Configuration details]** (設定の詳細) ページにバナーが表示されます。バナーには、パッチポリシーが既に存在しないパッチベースラインを参照していること、およびそれ以降のパッチ適用オペレーションができないことが示されます。この場合は、Quick Setup の **[Configurations]** (設定) ページに戻り、Patch Manager 設定を選択し、**[Actions]** (アクション)、**[Edit configuration]** (設定を編集) を選択します。削除されたパッチベースライン名が強調表示されます。影響を受けるオペレーティングシステム用の新しいパッチベースラインを選択する必要があります。 **パッチベースラインを更新または削除するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. 更新あるいは削除するパッチベースラインを選択してから、次のいずれかを実行します。 + AWS アカウント からパッチベースラインを削除するには、[**Delete** (削除)] を選択します。システムからアクションを確認するよう求められます。 + パッチベースラインの名前または説明を変更するには、承認ルール、またはパッチの例外で、[**Edit (編集)**] を選択します。[**Edit patch baseline (パッチベースラインの編集)**] ページで値とオプションを変更してから、[**Save changes (変更を保存)**] を選択します。 + パッチベースラインの追加、変更、削除を適用するには、[**Tags (タグ)**] タブを選択して、[**Edit tags (タグの編集)**] を選択します。[**Edit patch baseline tags (パッチベースラインタグの編集)**] ページで、パッチベースラインタグを変更して、[**Save changes (変更の保存)**] を選択します。 設定の選択肢については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。 # 既存のパッチベースラインをデフォルトとして設定する **重要** ここで選択したデフォルトのパッチベースラインは、パッチポリシーに基づくパッチ適用オペレーションには適用されません。パッチポリシーは、独自のパッチベースライン仕様を使用します。パッチポリシーの詳細については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。 AWS Systems Manager のツールである Patch Manager でカスタムパッチベースラインを作成するときに、作成してすぐに、ベースラインを関連するオペレーティングシステムタイプのデフォルトに設定できます。詳細については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。 既存のパッチベースラインを、オペレーティングシステムタイプのデフォルトに設定することもできます。 **注記** 実行する手順は、最初に Patch Manager にアクセスしたのが 2022 年 12 月 22 日のパッチポリシーのリリース前か後かによって異なります。その日より前に Patch Manager を使用した場合は、コンソールプロシージャを使用できます。それ以外の場合は、「AWS CLI」の手順に従います。コンソールプロシージャで参照されている **[アクション]** メニューは、パッチポリシーがリリースされる前に Patch Manager が使用されていないリージョンでは表示されません。 **パッチベースラインをデフォルトとして設定するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. [**パッチベースライン**] タブを選択します。 1. パッチベースラインのリストで、現在オペレーティングシステムタイプのデフォルトとして設定されていないパッチベースラインのボタンを選択します。 [**Default baseline (デフォルトベースライン)**] 列は、現在デフォルトとして設定されているベースラインを表しています。 1. [**Actions (アクション)**] メニューで、[**Set default patch baseline (デフォルトパッチベースラインに設定)**] を選択します。 **重要** **[アクション]** メニューは、2022 年 12 月 22 日より前に現在の AWS アカウント およびリージョンで、Patch Manager と作業していなかった場合、利用できません。詳細については、このトピックの前半の「**注意**」を参照してください。 1. 確認ダイアログボックスで [**Yes, Set (はい、設定します)**] を選択します。 **パッチベースラインをデフォルトとして設定するには (AWS CLI)** 1. 使用可能なパッチベースラインとその ID、Amazon リソースネーム (ARN) のリストを表示するには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) コマンドを実行してください。 ``` aws ssm describe-patch-baselines ``` 1. ベースラインを関連するオペレーティングシステムのデフォルトとして設定するには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) コマンドを実行します。*baseline-id-or-ARN* の部分を、カスタムパッチベースラインまたは使用する定義済みのベースライン ID に置き換えます。 ------ #### [ Linux & macOS ] ``` aws ssm register-default-patch-baseline \ --baseline-id baseline-id-or-ARN ``` 以下は、カスタムベースラインをデフォルトとして設定する例です。 ``` aws ssm register-default-patch-baseline \ --baseline-id pb-abc123cf9bEXAMPLE ``` 以下は、デフォルトで AWS によって管理される定義済みベースラインの設定例です。 ``` aws ssm register-default-patch-baseline \ --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e ``` ------ #### [ Windows サーバー ] ``` aws ssm register-default-patch-baseline ^ --baseline-id baseline-id-or-ARN ``` 以下は、カスタムベースラインをデフォルトとして設定する例です。 ``` aws ssm register-default-patch-baseline ^ --baseline-id pb-abc123cf9bEXAMPLE ``` 以下は、デフォルトで AWS によって管理される定義済みベースラインの設定例です。 ``` aws ssm register-default-patch-baseline ^ --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63 ``` ------ # 利用可能なパッチの表示 AWS Systems Manager のツールである Patch Manager を使用すると、指定されたオペレーティングシステムおよび任意で特定のオペレーティングシステムのバージョンで使用できるすべてのパッチを表示できます。 **ヒント** 使用可能なパッチのリストを生成し、ファイルに保存するには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) コマンドを使用して、任意の[出力](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html)を指定します。 **利用可能なパッチを表示するには** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. [**Patches (パッチ)**] タブを選択します。 -または- 現在の AWS リージョン で Patch Manager に初めてアクセスしている場合は、**[概要から始める]** を選択してから、**[パッチ]** タブを選択します。 **注記** Windows Server の場合、**[パッチ]** タブに、Windows Server Update Service (WSUS) から利用できる更新が表示されます。 1. [**Operating system (オペレーティングシステム)**] で、利用可能なパッチを表示するオペレーティングシステム (`Windows` や `Amazon Linux` など) を選択します。 1. (オプション) [**Product (製品)**] で、オペレーティングシステムのバージョン (`WindowsServer2019` や `AmazonLinux2018.03` など) を選択します。 1. (オプション) 結果の情報列を追加または削除するには、[**Patches (パッチ)**] リストの右上にある設定ボタン (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/configure-button.png)) をクリックします。(デフォルトでは、[**Patches (パッチ)**] タブには、利用可能なパッチのメタデータの一部の列のみが表示されます。) ビューに追加できるメタデータのタイプについては、*AWS Systems Manager API リファレンス* の「[パッチ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html)」を参照してください。 # パッチグループの作成と管理 オペレーションでパッチポリシーを使用していない場合、タグを使用してマネージドノードをパッチグループに追加することで、パッチ適用作業を整理できます。 **注記** パッチグループは、パッチポリシーに基づくパッチ適用オペレーションでは使用されません。パッチポリシーの使用については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。 2022 年 12 月 22 日にパッチポリシーのサポートがリリースされる前にパッチグループを使用していなかったアカウントとリージョンのペアでは、コンソールでパッチグループの機能がサポートされていません。パッチグループの機能は、この日付より前にパッチグループの使用を開始したアカウントとリージョンのペアで引き続き使用できます。 パッチオペレーションでタグを使用するには、タグキー `Patch Group` または `PatchGroup` をマネージドノードに適用する必要があります。また、タグの値としてパッチグループに付ける名前を指定する必要があります。任意のタグ値を指定できますが、タグキーは `Patch Group` または `PatchGroup` とする必要があります。 [EC2 インスタンスのメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、`PatchGroup` (スペースなし) を使用する必要があります。 タグを使用してマネージドノードをグループ化する場合、パッチグループの値をパッチベースラインに追加します。パッチグループをパッチベースラインに登録することで、パッチ適用の実行時に正しいパッチがインストールされます。パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。 このトピックのタスクを実行して、ノードとパッチベースラインのタグを使用してマネージドノードにパッチを適用できるように準備します。タスク 1 は、Amazon EC2 インスタンスにパッチ適用する場合にのみ必要です。タスク 2 は、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で EC2 以外のインスタンスにパッチを適用する場合にのみ必要です。タスク 3 は、すべてのマネージドノードで必要です。 **ヒント** AWS CLI コマンド `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` または Systems Manager API オペレーション ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)` を使用してマネージドノードにタグを追加できます。 **Topics** + [タスク 1: タグを使用したパッチグループに EC2 インスタンスを追加する](#sysman-patch-group-tagging-ec2) + [タスク 2: タグを使用してパッチグループをマネージドノードに追加する](#sysman-patch-group-tagging-managed) + [タスク 3: パッチベースラインにパッチグループを追加します。](#sysman-patch-group-patchbaseline) ## タスク 1: タグを使用したパッチグループに EC2 インスタンスを追加する Systems Manager コンソールまたは Amazon EC2 コンソールを使用して、EC2 インスタンスにタグを追加できます。このタスクは、Amazon EC2 インスタンスにパッチ適用する場合にのみ必要です。 **重要** インスタンスで **[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: EC2 インスタンスをパッチグループに追加するには (Systems Manager コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Fleet Manager]** を選択します。 1. **[マネージドインスタンス]** リストで、パッチを設定するマネージド EC2 インスタンスの ID を選択します。EC2 インスタンスのノード ID は `i-` で始まります。 **注記** Amazon EC2 コンソールと AWS CLI を使用する場合、Systems Manager で使用するようにまだ設定されていないインスタンスに `Key = Patch Group` または `Key = PatchGroup` タグを適用できます。 表示されるはずのマネージドノードが表示されない場合は、トラブルシューティングのヒントについて「[マネージドノードの可用性のトラブルシューティング](fleet-manager-troubleshooting-managed-nodes.md)」を参照してください。 1. **[タグ]** タブを選択し、**[編集]** を選択します。 1. 左側の列に、**Patch Group** または **PatchGroup** を入力します。[EC2 インスタンスのメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、スペースなしで `PatchGroup` を使用する必要があります。 1. 右側の列に、パッチグループの名前として使用するタグ値を入力します。 1. **[保存]** を選択します。 1. この手順を繰り返して、同じパッチグループに他の EC2 インスタンスを追加します。 **オプション 2: EC2 インスタンスをパッチグループに追加するには (Amazon EC2 コンソール)** 1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)を開き、ナビゲーションペインで [**Instances (インスタンス)**] を選択します。 1. インスタンスの一覧で、パッチ適用を設定するインスタンスを選択します。 1. **[アクション]** メニューから、**[インスタンスの設定]**、**[タグの追加/編集]** の順に選択します。 1. [**新しいタグを追加**] をクリックします。 1. **[Key]** (キー) で **Patch Group** または **PatchGroup** を入力します。[EC2 インスタンスのメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、スペースなしで `PatchGroup` を使用する必要があります。 1. **[値]** に、パッチグループの名前として使用する値を入力します。 1. **[保存]** を選択します。 1. この手順を繰り返して、同じパッチグループ内の他のインスタンスを追加します。 ## タスク 2: タグを使用してパッチグループをマネージドノードに追加する このトピックの手順に従って、AWS IoT Greengrass コアデバイスと EC2 以外のハイブリッドアクティベーションマネージドノード (mi-\$1) にタグを追加します。このタスクは、ハイブリッドおよびマルチクラウド環境で EC2 以外のインスタンスにパッチを適用する場合にのみ必要です。 **注記** Amazon EC2 コンソールを使用して、非 EC2 マネージドノードにタグを追加することはできません。 **EC2 以外のマネージドノードをパッチグループに追加するには (Systems Manager コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Fleet Manager]** を選択します。 1. **[マネージドノード]** リストで、パッチ適用を設定するマネージドノードを選択します。 **注記** 表示されるはずのマネージドノードが表示されない場合は、トラブルシューティングのヒントについて「[マネージドノードの可用性のトラブルシューティング](fleet-manager-troubleshooting-managed-nodes.md)」を参照してください。 1. **[タグ]** タブを選択し、**[編集]** を選択します。 1. 左側の列に、**Patch Group** または **PatchGroup** を入力します。[EC2 インスタンスのメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、スペースなしで `PatchGroup` を使用する必要があります。 1. 右側の列に、パッチグループの名前として使用するタグ値を入力します。 1. **[保存]** を選択します。 1. この手順を繰り返して、同じパッチグループ内の他のマネージドノードを追加します。 ## タスク 3: パッチベースラインにパッチグループを追加します。 特定のパッチベースラインをマネージドノードと関連付ける場合は、パッチベースラインにパッチグループの値を追加する必要があります。パッチグループをパッチベースラインに登録することで、パッチ適用の実行時に正しいパッチがインストールされます。このタスクは、EC2 インスタンス、EC2 以外のマネージドノード、あるいはその両方にパッチを適用するかどうかにかかわらず必要です。 パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。 **注記** 実行する手順は、最初に Patch Manager にアクセスしたのが 2022 年 12 月 22 日の[パッチポリシー](patch-manager-policies.md)のリリース前か後かによって異なります。 **パッチグループをパッチベースラインに追加するには (System Manager コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. 現在の AWS リージョン で Patch Manager ページに初めてアクセスし、Patch Manager 開始ページが開いた場合は、**[概要から開始]** を選択します。 1. **[パッチベースライン]** タブを選択し、**[パッチベースライン]** リストから、パッチグループに設定するパッチベースラインの名前を選択します。 パッチポリシーのリリース後まで最初に Patch Manager にアクセスしなかった場合は、作成したカスタムベースラインを選択する必要があります。 1. **[ベースライン ID]** 詳細ページに **[アクション]** メニューがある場合は、次の操作を行います。 + [**Actions (アクション)**] 、[**Modify patch groups (パッチグループの変更)**] の順に選択します。 + [タスク 2: タグを使用してパッチグループをマネージドノードに追加する](#sysman-patch-group-tagging-managed) でマネージドノードに追加したタグの値を入力して、**[追加]** を選択します。 **[ベースライン ID]** 詳細ページに **[アクション]** メニューがない場合は、パッチグループはコンソールで設定できません。代わりに、以下のどちらかを実行できます。 + (推奨) AWS Systems Manager のツールである Quick Setup にパッチポリシーを設定し、パッチベースラインを 1 つ以上の EC2 インスタンスにマッピングします。 詳細については、「[Quick Setup パッチポリシーの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html)」および「[Quick Setup パッチポリシーを使用して組織全体のパッチ適用を自動化する](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)」を参照してください。 + AWS Command Line Interface (AWS CLI) の [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html) コマンドを使用して、パッチグループを設定します。 # Patch Managerと AWS Security Hub CSPM の統合 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) は、AWS のセキュリティ状態の包括的なビューを提供します。Security Hub CSPM は、AWS アカウント、AWS のサービス、およびサポートされているサードパーティーパートナー製品にわたってセキュリティデータを収集します。Security Hub CSPM により、セキュリティ業界の標準とベストプラクティスに照らしてお使いの環境をチェックできます。Security Hub CSPM を使用すると、セキュリティの傾向を分析して最も優先度の高いセキュリティ問題を特定できます。 AWS Systems Manager のツールである Patch Manager と Security Hub CSPM 間の統合を利用して、非準拠ノードの検出結果を Patch Manager から Security Hub CSPM に送信できます。検出結果は、セキュリティチェックまたはセキュリティ関連の検出の監視可能なレコードです。Security Hub CSPM では、このようなパッチ関連の検出結果をセキュリティ体制の分析に含めることができます。 以下のトピックの情報は、パッチ適用オペレーションに使用する設定の方法や種類に関係なく適用されます。 + Quick Setup で設定されているパッチポリシー + Quick Setup で設定されているホスト管理オプション + パッチ `Scan` または `Install` のタスクを実行するためのメンテナンスウィンドウ + オンデマンドの **[今すぐパッチ適用]** オペレーション **Contents** + [Patch Manager から Security Hub CSPM に検出結果を送信する方法](#securityhub-integration-sending-findings) + [Patch Manager が送信する検出結果の種類](#securityhub-integration-finding-types) + [検出結果が送信されるまでのレイテンシー](#securityhub-integration-finding-latency) + [Security Hub CSPM が使用できない場合の再試行](#securityhub-integration-retry-send) + [Security Hub CSPM での 検出結果の表示](#securityhub-integration-view-findings) + [Patch Manager からの一般的な検出結果](#securityhub-integration-finding-example) + [統合の有効化と設定](#securityhub-integration-enable) + [検出結果の送信を停止する方法](#securityhub-integration-disable) ## Patch Manager から Security Hub CSPM に検出結果を送信する方法 Security Hub CSPM では、セキュリティの問題が検出結果として追跡されます。結果の中には、他の AWS のサービス やサードパーティーのパートナーが検出した問題に由来するものもあります。Security Hub CSPM には、セキュリティの問題を検出し、検出結果を生成するために使用する一連のルールもあります。 Patch Manager は、Security Hub CSPM に検出結果を送信する Systems Manager ツールの 1 つです。SSM ドキュメント (`AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation`、または`AWS-RunPatchBaselineWithHooks` ) を実行してパッチ適用オペレーションを実行すると、AWS Systems Manager のツールである Inventory または Compliance、またはその両方にパッチ適用情報が送信されます。インベントリ、Compliance、またはその両方がデータを受け取ると、Patch Manager が通知を受信します。次に、Patch Manager はデータの精度、書式設定、およびコンプライアンスを評価します。すべての条件が満たされた場合、Patch Manager はデータを Security Hub CSPM に転送します。 Security Hub CSPM には、これらすべてのソースからの検出結果を管理するためのツールが用意されています。検出結果の一覧を表示およびフィルタリングして、検出結果の詳細を表示できます。詳細については、*AWS Security Hub ユーザーガイド*の「[検出結果の表示](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html)」を参照してください。検出結果の調査状況を追跡することもできます 詳細については、*AWS Security Hub ユーザーガイド*の「[検出結果に対するアクションの実行](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html)」を参照してください。 Security Hub CSPM では、すべての検出結果に AWS Security Finding Format (ASFF) と呼ばれる標準の JSON 形式が使用されます。ASFF には、問題のソース、影響を受けるリソース、および検出結果の現在のステータスに関する詳細が含まれます。詳細については、*AWS Security Hub ユーザーガイド*の [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm)を参照してください。 ### Patch Manager が送信する検出結果の種類 Patch Manager は、[AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) を使用して検出結果を Security Hub CSPM に送信します。ASFF では、`Types` フィールドが検出結果タイプを提供します。Patch Manager の検出結果には、`Types` に対する次の値があります。 + ソフトウェアおよび設定のチェック/パッチ管理 Patch Manager は、非準拠マネージドノードごとに 1 つの検出結果を送信します。検出結果は、[https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance) リソースタイプとともに報告されるため、検出結果の `AwsEc2Instance` リソースタイプを報告する他の Security Hub CSPM 統合と相関させることができます。Patch Manager は、オペレーションによってマネージドノードが非準拠であることが検出された場合にのみ Security Hub CSPM に検出結果を転送します。検出結果には、パッチのサマリー結果が含まれます。 **注記** 非準拠のノードを Security Hub CSPM に報告した後は、ノードが準拠した状態になっても、Patch Manager は Security Hub CSPM に更新を送信しません。必要なパッチがマネージドノードに適用されたら、Security Hub CSPM の検出結果を手動で解決できます。 コンプライアンス定義については、「[パッチコンプライアンス状態の値](patch-manager-compliance-states.md)」を参照してください。`PatchSummary` の詳細については、*AWS Security Hub API リファレンス*の [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html) を参照してください。 ### 検出結果が送信されるまでのレイテンシー Patch Manager によって新しい検出結果が作成されると、通常は数秒から 2 時間以内に Security Hub CSPM に送信されます。速度は、その時点で処理されている AWS リージョン のトラフィックによって異なります。 ### Security Hub CSPM が使用できない場合の再試行 サービスの停止が発生した場合、AWS Lambda 関数が実行され、サービスが再度実行された後、メッセージをメインキューに戻すことができます。メッセージがメインキューに入ると、再試行は自動的に行われます。 Security Hub CSPM が使用できない場合、Patch Manager は検出結果が受信されるまでその結果を再送信し続けます。 ### Security Hub CSPM での 検出結果の表示 以下の手順では、パッチコンプライアンスに違反しているフリート内のマネージドノードに関する Security Hub CSPM の検出結果を表示する方法について説明します。 **パッチコンプライアンスに関する Security Hub CSPM の検出結果を確認するには** 1. AWS マネジメントコンソール にサインインして、AWS Security Hub CSPM コンソール ([https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)) を開きます。 1. ナビゲーションペインで **調査検出結果** を選択します。 1. [**Add filters (フィルターの追加)**] (![\[The Search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスを選択します。 1. メニューの [**フィルタ**] で、[**製品名**] を選択します。 1. 表示されたダイアログボックスの最初のフィールドで [**is (=)**] を選択し、2 番目のフィールドに「**Systems Manager Patch Manager**」と入力します。 1. **[Apply]** (適用) を選択します。 1. 結果を絞り込むために必要なフィルターを追加します。 1. 結果のリストで、詳細情報が必要な検出結果のタイトルを選択します。 画面の右側にペインが開き、リソース、検出された問題、推奨される修正に関する詳細が表示されます。 **重要** 現時点では、Security Hub CSPM は、すべてのマネージドインスタンスのリソースタイプを `EC2 Instance` としてレポートします。これには、Systems Manager で使用するために登録したオンプレミスサーバーおよび仮想マシン (VM) が含まれます。 **重要度の分類** **Systems Manager Patch Manager** の検出結果の一覧には、検出結果の重大度に関するレポートが含まれています。**[重要度]** には、低いものから高いものまで、次のものが含まれます。 + **[情報]** - 問題は見つかりませんでした。 + **[低]** - この問題はアクションを必要としません。 + **[中]** - この問題は対処する必要がありますが、緊急ではありません。 + **[高]** - この問題は優先事項として対処する必要があります。 + **[重要]** - この問題を悪化させないようにすぐに修正する必要があります。 重要度は、インスタンス上の最も深刻である非準拠パッケージによって決定される。複数の重要度レベルのパッチベースラインを作成できるため、すべての非準拠パッケージの中で最も重要度が高いものが報告されます。例えば、パッケージ A の重要度が「重要」で、パッケージ B の重要度が「低」の 2 つの非準拠パッケージがあるとします。重要度として「重要」が報告されます。 重要度フィールドは Patch Manager `Compliance` フィールドと直接相関していることに注意してください。このフィールドは、ルールに一致する個々のパッチに割り当てるよう設定します。`Compliance` フィールドは個々のパッチに割り当てられるため、パッチの概要レベルには反映されません。 **関連情報** + 「AWS Security Hub ユーザーガイド」の「[検出結果](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html)」 + AWS 管理およびガバナンスのブログ内の「[Patch Manager およびセキュリティハブマルチを使用するアカウントパッチのコンプライアンス](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/)」 ## Patch Manager からの一般的な検出結果 Patch Manager は、[AWS Security Finding 形式 (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) を使用して検出結果を Security Hub CSPM に送信します。 以下に、Patch Manager からの一般的な検出結果の例を示します。 ``` { "SchemaVersion": "2018-10-08", "Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE", "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager", "GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE", "AwsAccountId": "111122223333", "Types": [ "Software & Configuration Checks/Patch Management/Compliance" ], "CreatedAt": "2021-11-11T22:05:25Z", "UpdatedAt": "2021-11-11T22:05:25Z", "Severity": { "Label": "INFORMATIONAL", "Normalized": 0 }, "Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant", "Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.", "Remediation": { "Recommendation": { "Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.", "Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html" } }, "SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2", "ProductFields": { "aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE", "aws/securityhub/ProductName": "Systems Manager Patch Manager", "aws/securityhub/CompanyName": "AWS" }, "Resources": [ { "Type": "AwsEc2Instance", "Id": "i-02573cafcfEXAMPLE", "Partition": "aws", "Region": "us-east-2" } ], "WorkflowState": "NEW", "Workflow": { "Status": "NEW" }, "RecordState": "ACTIVE", "PatchSummary": { "Id": "pb-0c10e65780EXAMPLE", "InstalledCount": 45, "MissingCount": 2, "FailedCount": 0, "InstalledOtherCount": 396, "InstalledRejectedCount": 0, "InstalledPendingReboot": 0, "OperationStartTime": "2021-11-11T22:05:06Z", "OperationEndTime": "2021-11-11T22:05:25Z", "RebootOption": "NoReboot", "Operation": "SCAN" } } ``` ## 統合の有効化と設定 Security Hub CSPM と Patch Manager 統合を使用するには、Security Hub を有効にする必要があります。Security Hub CSPM を有効にする方法の詳細については、AWS Security Hub ユーザーガイドの「[Setting up Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)」を参照してください。 次の手順では、Security Hub CSPM が既にアクティブであっても Patch Manager 統合が無効になっている場合に Patch Manager と Security Hub CSPM を統合する方法について説明します。以下の手順を完了する必要があるのは、統合を手動で無効にした場合だけです。 **Security Hub CSPM 統合に Patch Manager を追加するには** 1. ナビゲーションペインで、**Patch Manager** を選択します。 1. **[Settings]** (設定) タブを選択します。 -または- 現在の AWS リージョン で Patch Manager に初めてアクセスしている場合は、**[概要から開始]** を選択してから、**[設定]** タブを選択します。 1. **[Patch compliance findings are not being exported to Security Hub]** の右側にある **[Export to Security Hub]** セクションで、**[有効にする]** を選択します。 ## 検出結果の送信を停止する方法 Security Hub CSPM への結果の送信を停止するには、Security Hub CSPM コンソールまたは API を使用できます。 詳細については、*AWS Security Hub ユーザーガイド*の次のトピックを参照してください。 + [統合からの検出結果のフローの無効化と有効化 (コンソール)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console) + [統合からの検出結果のフローの無効化 (Security Hub CSPM API、AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api) # AWS CLI を使用して Patch Manager リソースを操作する このセクションには、AWS Systems Manager のツールである Patch Manager の設定タスクを実行するために使用できる AWS Command Line Interface (AWS CLI) コマンドの例が含まれています。 独自のパッチベースラインを使用して、AWS CLI でサーバー環境にパッチを適用する方法の詳細は、「[チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する](patch-manager-patch-servers-using-the-aws-cli.md)」を参照してください。 AWS Systems Manager タスクの AWS CLI の使用の詳細については、[AWS CLI コマンドリファレンスの AWS Systems Manager セクション](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html)を参照してください。 **Topics** + [パッチベースラインの AWS CLI コマンド](#patch-baseline-cli-commands) + [パッチグループの AWS CLI コマンド](#patch-group-cli-commands) + [パッチの概要と詳細を表示するための AWS CLI コマンド](#patch-details-cli-commands) + [AWS CLI マネージドノードのスキャンとパッチ適用のためのコマンド](#patch-operations-cli-commands) ## パッチベースラインの AWS CLI コマンド **Topics** + [パッチベースラインの作成](#patch-manager-cli-commands-create-patch-baseline) + [異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する](#patch-manager-cli-commands-create-patch-baseline-mult-sources) + [パッチベースラインの更新](#patch-manager-cli-commands-update-patch-baseline) + [パッチベースラインの名前変更](#patch-manager-cli-commands-rename-patch-baseline) + [パッチベースラインの削除](#patch-manager-cli-commands-delete-patch-baseline) + [すべてのパッチベースラインのリストアップ](#patch-manager-cli-commands-describe-patch-baselines) + [すべての AWS 提供のパッチベースラインのリストアップ](#patch-manager-cli-commands-describe-patch-baselines-aws) + [ユーザーのパッチベースラインのリストアップ](#patch-manager-cli-commands-describe-patch-baselines-custom) + [パッチベースラインの表示](#patch-manager-cli-commands-get-patch-baseline) + [デフォルトパッチベースラインの取得](#patch-manager-cli-commands-get-default-patch-baseline) + [カスタムパッチベースラインをデフォルトとして設定する](#patch-manager-cli-commands-register-default-patch-baseline) + [AWS パッチベースラインをデフォルトとしてリセットする](#patch-manager-cli-commands-register-aws-patch-baseline) + [パッチベースラインのタグ付け](#patch-manager-cli-commands-add-tags-to-resource) + [パッチベースラインのタグのリストアップ](#patch-manager-cli-commands-list-tags-for-resource) + [パッチベースラインからのタグの削除](#patch-manager-cli-commands-remove-tags-from-resource) ### パッチベースラインの作成 次のコマンドでは、リリースされてから 5 日後に Windows Server 2012 R2 のすべての緊急および重要なセキュリティ更新プログラムを承認するパッチベースラインを作成します。承認済みおよび拒否済みパッチリストに対しても、パッチが指定されています。また、パッチベースラインが本番環境用であることを示すタグが付けられます。 ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "Windows-Server-2012R2" \ --tags "Key=Environment,Value=Production" \ --description "Windows Server 2012 R2, Important and Critical security updates" \ --approved-patches "KB2032276,MS10-048" \ --rejected-patches "KB2124261" \ --rejected-patches-action "ALLOW_AS_DEPENDENCY" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows サーバー ] ``` aws ssm create-patch-baseline ^ --name "Windows-Server-2012R2" ^ --tags "Key=Environment,Value=Production" ^ --description "Windows Server 2012 R2, Important and Critical security updates" ^ --approved-patches "KB2032276,MS10-048" ^ --rejected-patches "KB2124261" ^ --rejected-patches-action "ALLOW_AS_DEPENDENCY" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ### 異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する Linux マネージドノードにのみ適用されます。以下のコマンドは、特定バージョンの Amazon Linux オペレーティングシステムに使用するパッチリポジトリを指定する方法を示しています。このサンプルは、Amazon Linux 2017.09 でデフォルトで 許可されているソースリポジトリを使用しますが、マネージドノード用に設定した別のソースリポジトリを使用するように調整することもできます。 **注記** この複雑なコマンドをわかりやすく示すために、外部 JSON ファイルに保存されている追加のオプションと共に `--cli-input-json` オプションを使用します。 1. JSON ファイルを `my-patch-repository.json` などの名前で作成し、以下のコンテンツを追加します。 ``` { "Description": "My patch repository for Amazon Linux 2", "Name": "Amazon-Linux-2", "OperatingSystem": "AMAZON_LINUX_2", "ApprovalRules": { "PatchRules": [ { "ApproveAfterDays": 7, "EnableNonSecurity": true, "PatchFilterGroup": { "PatchFilters": [ { "Key": "SEVERITY", "Values": [ "Important", "Critical" ] }, { "Key": "CLASSIFICATION", "Values": [ "Security", "Bugfix" ] }, { "Key": "PRODUCT", "Values": [ "AmazonLinux2" ] } ] } } ] }, "Sources": [ { "Name": "My-AL2", "Products": [ "AmazonLinux2" ], "Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes" } ] } ``` 1. ファイルを保存したディレクトリで、次のコマンドを実行します。 ``` aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json ``` システムが以下のような情報を返します。 ``` { "BaselineId": "pb-0c10e65780EXAMPLE" } ``` ### パッチベースラインの更新 次のコマンドでは、2 つのパッチを拒否済み、1 つのパッチを承認済みとして既存のパッチベースラインに追加します。 承認済みパッチと拒否済みパッチのリストの許容されるフォーマットの詳細については、「[承認されたパッチと拒否されたパッチのリストのパッケージ名の形式](patch-manager-approved-rejected-package-name-formats.md)」を参照してください。 ------ #### [ Linux & macOS ] ``` aws ssm update-patch-baseline \ --baseline-id pb-0c10e65780EXAMPLE \ --rejected-patches "KB2032276" "MS10-048" \ --approved-patches "KB2124261" ``` ------ #### [ Windows サーバー ] ``` aws ssm update-patch-baseline ^ --baseline-id pb-0c10e65780EXAMPLE ^ --rejected-patches "KB2032276" "MS10-048" ^ --approved-patches "KB2124261" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE", "Name":"Windows-Server-2012R2", "RejectedPatches":[ "KB2032276", "MS10-048" ], "GlobalFilters":{ "PatchFilters":[ ] }, "ApprovalRules":{ "PatchRules":[ { "PatchFilterGroup":{ "PatchFilters":[ { "Values":[ "Important", "Critical" ], "Key":"MSRC_SEVERITY" }, { "Values":[ "SecurityUpdates" ], "Key":"CLASSIFICATION" }, { "Values":[ "WindowsServer2012R2" ], "Key":"PRODUCT" } ] }, "ApproveAfterDays":5 } ] }, "ModifiedDate":1481001494.035, "CreatedDate":1480997823.81, "ApprovedPatches":[ "KB2124261" ], "Description":"Windows Server 2012 R2, Important and Critical security updates" } ``` ### パッチベースラインの名前変更 ------ #### [ Linux & macOS ] ``` aws ssm update-patch-baseline \ --baseline-id pb-0c10e65780EXAMPLE \ --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates" ``` ------ #### [ Windows サーバー ] ``` aws ssm update-patch-baseline ^ --baseline-id pb-0c10e65780EXAMPLE ^ --name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE", "Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates", "RejectedPatches":[ "KB2032276", "MS10-048" ], "GlobalFilters":{ "PatchFilters":[ ] }, "ApprovalRules":{ "PatchRules":[ { "PatchFilterGroup":{ "PatchFilters":[ { "Values":[ "Important", "Critical" ], "Key":"MSRC_SEVERITY" }, { "Values":[ "SecurityUpdates" ], "Key":"CLASSIFICATION" }, { "Values":[ "WindowsServer2012R2" ], "Key":"PRODUCT" } ] }, "ApproveAfterDays":5 } ] }, "ModifiedDate":1481001795.287, "CreatedDate":1480997823.81, "ApprovedPatches":[ "KB2124261" ], "Description":"Windows Server 2012 R2, Important and Critical security updates" } ``` ### パッチベースラインの削除 ``` aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE" ``` システムが以下のような情報を返します。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ### すべてのパッチベースラインのリストアップ ``` aws ssm describe-patch-baselines ``` システムが以下のような情報を返します。 ``` { "BaselineIdentities":[ { "BaselineName":"AWS-DefaultPatchBaseline", "DefaultBaseline":true, "BaselineDescription":"Default Patch Baseline Provided by AWS.", "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" }, { "BaselineName":"Windows-Server-2012R2", "DefaultBaseline":false, "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates", "BaselineId":"pb-0c10e65780EXAMPLE" } ] } ``` 次に示すのは、 内のすべてのパッチベースラインをリストアップする別のコマンドですAWS リージョン ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-baselines \ --region us-east-2 \ --filters "Key=OWNER,Values=[All]" ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-patch-baselines ^ --region us-east-2 ^ --filters "Key=OWNER,Values=[All]" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineIdentities":[ { "BaselineName":"AWS-DefaultPatchBaseline", "DefaultBaseline":true, "BaselineDescription":"Default Patch Baseline Provided by AWS.", "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" }, { "BaselineName":"Windows-Server-2012R2", "DefaultBaseline":false, "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates", "BaselineId":"pb-0c10e65780EXAMPLE" } ] } ``` ### すべての AWS 提供のパッチベースラインのリストアップ ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-baselines \ --region us-east-2 \ --filters "Key=OWNER,Values=[AWS]" ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-patch-baselines ^ --region us-east-2 ^ --filters "Key=OWNER,Values=[AWS]" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineIdentities":[ { "BaselineName":"AWS-DefaultPatchBaseline", "DefaultBaseline":true, "BaselineDescription":"Default Patch Baseline Provided by AWS.", "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" } ] } ``` ### ユーザーのパッチベースラインのリストアップ ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-baselines \ --region us-east-2 \ --filters "Key=OWNER,Values=[Self]" ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-patch-baselines ^ --region us-east-2 ^ --filters "Key=OWNER,Values=[Self]" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineIdentities":[ { "BaselineName":"Windows-Server-2012R2", "DefaultBaseline":false, "BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates", "BaselineId":"pb-0c10e65780EXAMPLE" } ] } ``` ### パッチベースラインの表示 ``` aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE ``` **注記** カスタムパッチベースラインについては、パッチベースライン ID か完全な Amazon リソースネーム (ARN) のどちらかを指定できます。AWS 提供のパッチベースラインについては、完全な ARN を指定する必要があります。例えば、`arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`。 システムが以下のような情報を返します。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE", "Name":"Windows-Server-2012R2", "PatchGroups":[ "Web Servers" ], "RejectedPatches":[ ], "GlobalFilters":{ "PatchFilters":[ ] }, "ApprovalRules":{ "PatchRules":[ { "PatchFilterGroup":{ "PatchFilters":[ { "Values":[ "Important", "Critical" ], "Key":"MSRC_SEVERITY" }, { "Values":[ "SecurityUpdates" ], "Key":"CLASSIFICATION" }, { "Values":[ "WindowsServer2012R2" ], "Key":"PRODUCT" } ] }, "ApproveAfterDays":5 } ] }, "ModifiedDate":1480997823.81, "CreatedDate":1480997823.81, "ApprovedPatches":[ ], "Description":"Windows Server 2012 R2, Important and Critical security updates" } ``` ### デフォルトパッチベースラインの取得 ``` aws ssm get-default-patch-baseline --region us-east-2 ``` システムが以下のような情報を返します。 ``` { "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" } ``` ### カスタムパッチベースラインをデフォルトとして設定する ------ #### [ Linux & macOS ] ``` aws ssm register-default-patch-baseline \ --region us-east-2 \ --baseline-id "pb-0c10e65780EXAMPLE" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-default-patch-baseline ^ --region us-east-2 ^ --baseline-id "pb-0c10e65780EXAMPLE" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ### AWS パッチベースラインをデフォルトとしてリセットする ------ #### [ Linux & macOS ] ``` aws ssm register-default-patch-baseline \ --region us-east-2 \ --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-default-patch-baseline ^ --region us-east-2 ^ --baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ### パッチベースラインのタグ付け ------ #### [ Linux & macOS ] ``` aws ssm add-tags-to-resource \ --resource-type "PatchBaseline" \ --resource-id "pb-0c10e65780EXAMPLE" \ --tags "Key=Project,Value=Testing" ``` ------ #### [ Windows サーバー ] ``` aws ssm add-tags-to-resource ^ --resource-type "PatchBaseline" ^ --resource-id "pb-0c10e65780EXAMPLE" ^ --tags "Key=Project,Value=Testing" ``` ------ ### パッチベースラインのタグのリストアップ ------ #### [ Linux & macOS ] ``` aws ssm list-tags-for-resource \ --resource-type "PatchBaseline" \ --resource-id "pb-0c10e65780EXAMPLE" ``` ------ #### [ Windows サーバー ] ``` aws ssm list-tags-for-resource ^ --resource-type "PatchBaseline" ^ --resource-id "pb-0c10e65780EXAMPLE" ``` ------ ### パッチベースラインからのタグの削除 ------ #### [ Linux & macOS ] ``` aws ssm remove-tags-from-resource \ --resource-type "PatchBaseline" \ --resource-id "pb-0c10e65780EXAMPLE" \ --tag-keys "Project" ``` ------ #### [ Windows サーバー ] ``` aws ssm remove-tags-from-resource ^ --resource-type "PatchBaseline" ^ --resource-id "pb-0c10e65780EXAMPLE" ^ --tag-keys "Project" ``` ------ ## パッチグループの AWS CLI コマンド **Topics** + [パッチグループの作成](#patch-manager-cli-commands-create-patch-group) + [パッチグループ "ウェブサーバー" のパッチベースラインへの登録](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers) + [パッチグループ "バックエンド" の AWS 提供のパッチベースラインへの登録](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend) + [パッチグループの登録の表示](#patch-manager-cli-commands-describe-patch-groups) + [パッチグループのパッチベースラインからの登録解除](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group) ### パッチグループの作成 **注記** パッチグループは、パッチポリシーに基づくパッチ適用オペレーションでは使用されません。パッチポリシーの使用については、「[Quick Setup でのパッチポリシー設定](patch-manager-policies.md)」を参照してください。 パッチ適用の仕組みを整理するため、タグを使用してマネージドノードをパッチグループに追加することをお勧めします。パッチグループでは、タグキー `Patch Group` または `PatchGroup` を使用する必要があります。[EC2 インスタンスのメタデータでタグを許可](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)している場合は、スペースなしで `PatchGroup` を使用する必要があります。任意のタグ値を指定できますが、タグキーは `Patch Group` または `PatchGroup` とする必要があります。パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。 タグを使用してマネージドノードをグループ化する場合、パッチグループの値をパッチベースラインに追加します。パッチグループをパッチベースラインに登録することで、パッチ適用の実行時に正しいパッチがインストールされます。 #### タスク 1: タグを使用したパッチグループに EC2 インスタンスを追加する **注記** Amazon Elastic Compute Cloud (Amazon EC2) コンソールと AWS CLI を使用する場合、Systems Manager で使用するためにまだ設定されていないインスタンスに `Key = Patch Group` または `Key = PatchGroup` タグを適用できます。`Patch Group` または `Key = PatchGroup` タグを適用しても Patch Manager に表示されるはずの EC2 インスタンスが表示されない場合は、[マネージドノードの可用性のトラブルシューティング](fleet-manager-troubleshooting-managed-nodes.md) でトラブルシューティングのヒントを参照してください。 次のコマンドを実行して、EC2 インスタンスに `PatchGroup` タグを追加します。 ``` aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue" ``` #### タスク 2: タグを使用してパッチグループをマネージドノードに追加する 次のコマンドを実行して、マネージドノードに `PatchGroup` タグを追加します。 ------ #### [ Linux & macOS ] ``` aws ssm add-tags-to-resource \ --resource-type "ManagedInstance" \ --resource-id "mi-0123456789abcdefg" \ --tags "Key=PatchGroup,Value=GroupValue" ``` ------ #### [ Windows サーバー ] ``` aws ssm add-tags-to-resource ^ --resource-type "ManagedInstance" ^ --resource-id "mi-0123456789abcdefg" ^ --tags "Key=PatchGroup,Value=GroupValue" ``` ------ #### タスク 3: パッチベースラインにパッチグループを追加します。 次のコマンドを実行して、`PatchGroup` タグ値を指定されたパッチベースラインに関連付けます。 ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id "pb-0c10e65780EXAMPLE" \ --patch-group "Development" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-patch-baseline-for-patch-group ^ --baseline-id "pb-0c10e65780EXAMPLE" ^ --patch-group "Development" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "PatchGroup": "Development", "BaselineId": "pb-0c10e65780EXAMPLE" } ``` ### パッチグループ "ウェブサーバー" のパッチベースラインへの登録 ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id "pb-0c10e65780EXAMPLE" \ --patch-group "Web Servers" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-patch-baseline-for-patch-group ^ --baseline-id "pb-0c10e65780EXAMPLE" ^ --patch-group "Web Servers" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "PatchGroup":"Web Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ### パッチグループ "バックエンド" の AWS 提供のパッチベースラインへの登録 ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --region us-east-2 \ --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \ --patch-group "Backend" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-patch-baseline-for-patch-group ^ --region us-east-2 ^ --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^ --patch-group "Backend" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "PatchGroup":"Backend", "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" } ``` ### パッチグループの登録の表示 ``` aws ssm describe-patch-groups --region us-east-2 ``` システムが以下のような情報を返します。 ``` { "PatchGroupPatchBaselineMappings":[ { "PatchGroup":"Backend", "BaselineIdentity":{ "BaselineName":"AWS-DefaultPatchBaseline", "DefaultBaseline":false, "BaselineDescription":"Default Patch Baseline Provided by AWS.", "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" } }, { "PatchGroup":"Web Servers", "BaselineIdentity":{ "BaselineName":"Windows-Server-2012R2", "DefaultBaseline":true, "BaselineDescription":"Windows Server 2012 R2, Important and Critical updates", "BaselineId":"pb-0c10e65780EXAMPLE" } } ] } ``` ### パッチグループのパッチベースラインからの登録解除 ------ #### [ Linux & macOS ] ``` aws ssm deregister-patch-baseline-for-patch-group \ --region us-east-2 \ --patch-group "Production" \ --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ``` ------ #### [ Windows サーバー ] ``` aws ssm deregister-patch-baseline-for-patch-group ^ --region us-east-2 ^ --patch-group "Production" ^ --baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "PatchGroup":"Production", "BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" } ``` ## パッチの概要と詳細を表示するための AWS CLI コマンド **Topics** + [パッチベースラインで定義されているすべてのパッチの取得](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline) + [AmazonLinux2018.03 の分類が `SECURITY` で重大度が `Critical` のすべてのパッチの取得](#patch-manager-cli-commands-describe-available-patches-linux) + [MSRC の重要度が「 `Critical` 」である Windows Server 2012 のすべてのパッチを取得する](#patch-manager-cli-commands-describe-available-patches) + [すべての利用可能なパッチの取得](#patch-manager-cli-commands-describe-available-patches) + [マネージドノードごとのパッチの概要の状態を取得](#patch-manager-cli-commands-describe-instance-patch-states) + [マネージドノードのパッチコンプライアンスの詳細の取得](#patch-manager-cli-commands-describe-instance-patches) + [パッチコンプライアンス結果の表示 ( AWS CLI )](#viewing-patch-compliance-results-cli) ### パッチベースラインで定義されているすべてのパッチの取得 **注記** このコマンドは、Windows Server のパッチベースラインでのみサポートされています。 ------ #### [ Linux & macOS ] ``` aws ssm describe-effective-patches-for-patch-baseline \ --region us-east-2 \ --baseline-id "pb-0c10e65780EXAMPLE" ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-effective-patches-for-patch-baseline ^ --region us-east-2 ^ --baseline-id "pb-0c10e65780EXAMPLE" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "NextToken":"--token string truncated--", "EffectivePatches":[ { "PatchStatus":{ "ApprovalDate":1384711200.0, "DeploymentStatus":"APPROVED" }, "Patch":{ "ContentUrl":"https://support.microsoft.com/en-us/kb/2876331", "ProductFamily":"Windows", "Product":"WindowsServer2012R2", "Vendor":"Microsoft", "Description":"A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.", "Classification":"SecurityUpdates", "Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)", "ReleaseDate":1384279200.0, "MsrcClassification":"Critical", "Language":"All", "KbNumber":"KB2876331", "MsrcNumber":"MS13-089", "Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d" } }, { "PatchStatus":{ "ApprovalDate":1428858000.0, "DeploymentStatus":"APPROVED" }, "Patch":{ "ContentUrl":"https://support.microsoft.com/en-us/kb/2919355", "ProductFamily":"Windows", "Product":"WindowsServer2012R2", "Vendor":"Microsoft", "Description":"Windows Server 2012 R2 Update is a cumulative set of security updates, critical updates and updates. You must install Windows Server 2012 R2 Update to ensure that your computer can continue to receive future Windows Updates, including security updates. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer.", "Classification":"SecurityUpdates", "Title":"Windows Server 2012 R2 Update (KB2919355)", "ReleaseDate":1428426000.0, "MsrcClassification":"Critical", "Language":"All", "KbNumber":"KB2919355", "MsrcNumber":"MS14-018", "Id":"8452bac0-bf53-4fbd-915d-499de08c338b" } } ---output truncated--- ``` ### AmazonLinux2018.03 の分類が `SECURITY` で重大度が `Critical` のすべてのパッチの取得 ------ #### [ Linux & macOS ] ``` aws ssm describe-available-patches \ --region us-east-2 \ --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-available-patches ^ --region us-east-2 ^ --filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Patches": [ { "AdvisoryIds": ["ALAS-2011-1"], "BugzillaIds": [ "1234567" ], "Classification": "SECURITY", "CVEIds": [ "CVE-2011-3192"], "Name": "zziplib", "Epoch": "0", "Version": "2.71", "Release": "1.3.amzn1", "Arch": "i686", "Product": "AmazonLinux2018.03", "ReleaseDate": 1590519815, "Severity": "CRITICAL" } ] } ---output truncated--- ``` ### MSRC の重要度が「 `Critical` 」である Windows Server 2012 のすべてのパッチを取得する ------ #### [ Linux & macOS ] ``` aws ssm describe-available-patches \ --region us-east-2 \ --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-available-patches ^ --region us-east-2 ^ --filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Patches":[ { "ContentUrl":"https://support.microsoft.com/en-us/kb/2727528", "ProductFamily":"Windows", "Product":"WindowsServer2012", "Vendor":"Microsoft", "Description":"A security issue has been identified that could allow an unauthenticated remote attacker to compromise your system and gain control over it. You can help protect your system by installing this update from Microsoft. After you install this update, you may have to restart your system.", "Classification":"SecurityUpdates", "Title":"Security Update for Windows Server 2012 (KB2727528)", "ReleaseDate":1352829600.0, "MsrcClassification":"Critical", "Language":"All", "KbNumber":"KB2727528", "MsrcNumber":"MS12-072", "Id":"1eb507be-2040-4eeb-803d-abc55700b715" }, { "ContentUrl":"https://support.microsoft.com/en-us/kb/2729462", "ProductFamily":"Windows", "Product":"WindowsServer2012", "Vendor":"Microsoft", "Description":"A security issue has been identified that could allow an unauthenticated remote attacker to compromise your system and gain control over it. You can help protect your system by installing this update from Microsoft. After you install this update, you may have to restart your system.", "Classification":"SecurityUpdates", "Title":"Security Update for Microsoft .NET Framework 3.5 on Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)", "ReleaseDate":1352829600.0, "MsrcClassification":"Critical", "Language":"All", "KbNumber":"KB2729462", "MsrcNumber":"MS12-074", "Id":"af873760-c97c-4088-ab7e-5219e120eab4" } ---output truncated--- ``` ### すべての利用可能なパッチの取得 ``` aws ssm describe-available-patches --region us-east-2 ``` システムが以下のような情報をレスポンスします。 ``` { "NextToken":"--token string truncated--", "Patches":[ { "Classification": "SecurityUpdates", "ContentUrl": "https://support.microsoft.com/en-us/kb/4074588", "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.", "Id": "11adea10-0701-430e-954f-9471595ae246", "KbNumber": "KB4074588", "Language": "All", "MsrcNumber": "", "MsrcSeverity": "Critical", "Product": "WindowsServer2016", "ProductFamily": "Windows", "ReleaseDate": 1518548400, "Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4074588)", "Vendor": "Microsoft" }, { "Classification": "SecurityUpdates", "ContentUrl": "https://support.microsoft.com/en-us/kb/4074590", "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.", "Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265", "KbNumber": "KB4074590", "Language": "All", "MsrcNumber": "", "MsrcSeverity": "Critical", "Product": "WindowsServer2016", "ProductFamily": "Windows", "ReleaseDate": 1518544805, "Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4074590)", "Vendor": "Microsoft" } ---output truncated--- ``` ### マネージドノードごとのパッチの概要の状態を取得 マネージドノードごとの概要により、ノードごとに状態が 「NotApplicable」、「Missing」、「Failed」、「InstalledOther」、「Installed」に該当するパッチの数を確認できます。 ------ #### [ Linux & macOS ] ``` aws ssm describe-instance-patch-states \ --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9 ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-instance-patch-states ^ --instance-ids i-08ee91c0b17045407 i-09a618aec652973a9 ``` ------ システムが以下のような情報をレスポンスします。 ``` { "InstancePatchStates":[ { "InstanceId": "i-08ee91c0b17045407", "PatchGroup": "", "BaselineId": "pb-0c10e65780EXAMPLE", "SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE", "InstalledCount": 50, "InstalledOtherCount": 353, "InstalledPendingRebootCount": 0, "InstalledRejectedCount": 0, "MissingCount": 0, "FailedCount": 0, "UnreportedNotApplicableCount": -1, "NotApplicableCount": 671, "OperationStartTime": "2020-01-24T12:37:56-08:00", "OperationEndTime": "2020-01-24T12:37:59-08:00", "Operation": "Scan", "RebootOption": "NoReboot" }, { "InstanceId": "i-09a618aec652973a9", "PatchGroup": "", "BaselineId": "pb-0c10e65780EXAMPLE", "SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE", "InstalledCount": 36, "InstalledOtherCount": 396, "InstalledPendingRebootCount": 0, "InstalledRejectedCount": 0, "MissingCount": 3, "FailedCount": 0, "UnreportedNotApplicableCount": -1, "NotApplicableCount": 420, "OperationStartTime": "2020-01-24T12:37:34-08:00", "OperationEndTime": "2020-01-24T12:37:37-08:00", "Operation": "Scan", "RebootOption": "NoReboot" } ---output truncated--- ``` ### マネージドノードのパッチコンプライアンスの詳細の取得 ``` aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407 ``` システムが以下のような情報をレスポンスします。 ``` { "NextToken":"--token string truncated--", "Patches":[ { "Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1", "KBId": "bind-libs.x86_64", "Classification": "Security", "Severity": "Important", "State": "Installed", "InstalledTime": "2019-08-26T11:05:24-07:00" }, { "Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1", "KBId": "bind-utils.x86_64", "Classification": "Security", "Severity": "Important", "State": "Installed", "InstalledTime": "2019-08-26T11:05:32-07:00" }, { "Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1", "KBId": "dhclient.x86_64", "Classification": "Security", "Severity": "Important", "State": "Installed", "InstalledTime": "2019-08-26T11:05:31-07:00" }, ---output truncated--- ``` ### パッチコンプライアンス結果の表示 ( AWS CLI ) **1 つのマネージドノードノードのパッチコンプライアンスの結果を表示する** 1 つのマネージドノードノードのパッチコンプライアンスの結果を表示するには、AWS Command Line Interface ( AWS CLI ) で次のコマンドを実行します。 ``` aws ssm describe-instance-patch-states --instance-id instance-id ``` *instance-id* を、結果を確認するマネージドノードの ID に、`i-02573cafcfEXAMPLE` または `mi-0282f7c436EXAMPLE` の形式で置き換えます。 以下のような情報が返されます。 ``` { "InstancePatchStates": [ { "InstanceId": "i-02573cafcfEXAMPLE", "PatchGroup": "mypatchgroup", "BaselineId": "pb-0c10e65780EXAMPLE", "SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE", "CriticalNonCompliantCount": 2, "SecurityNonCompliantCount": 2, "OtherNonCompliantCount": 1, "InstalledCount": 123, "InstalledOtherCount": 334, "InstalledPendingRebootCount": 0, "InstalledRejectedCount": 0, "MissingCount": 1, "FailedCount": 2, "UnreportedNotApplicableCount": 11, "NotApplicableCount": 2063, "OperationStartTime": "2021-05-03T11:00:56-07:00", "OperationEndTime": "2021-05-03T11:01:09-07:00", "Operation": "Scan", "LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00", "RebootOption": "RebootIfNeeded" } ] } ``` **リージョン内のすべての EC2 インスタンスのパッチ数の概要を表示するには** `describe-instance-patch-states` は、一度に 1 つのマネージドインスタンスの結果の取得をサポートします。ただし、`describe-instance-patch-states` コマンドでカスタムスクリプトを使用すると、より詳細なレポートを生成できます。 例えば、[jq フィルターツール](https://stedolan.github.io/jq/download/)がローカルマシンにインストールされている場合、次のコマンドを実行して、特定の AWS リージョン のどの EC2 インスタンスのステータスが `InstalledPendingReboot` であるかを特定できます。 ``` aws ssm describe-instance-patch-states \ --instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \ --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}' ``` *region* は、米国東部 (オハイオ) リージョンの `us-east-2` のように、AWS Systems Manager でサポートされている AWS リージョン の識別子を表します。サポートされている *region* 値の一覧については、「Amazon Web Services 全般のリファレンス」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある **Region** 列を参照してください。 例えば、次のようになります。 ``` aws ssm describe-instance-patch-states \ --instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \ --output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}' ``` システムが以下のような情報を返します。 ``` 1 i-02573cafcfEXAMPLE 0 i-0471e04240EXAMPLE 3 i-07782c72faEXAMPLE 6 i-083b678d37EXAMPLE 0 i-03a530a2d4EXAMPLE 1 i-01f68df0d0EXAMPLE 0 i-0a39c0f214EXAMPLE 7 i-0903a5101eEXAMPLE 7 i-03823c2fedEXAMPLE ``` `InstalledPendingRebootCount` に加えて、検索できるカウントタイプのリストには次のものが含まれます。 + `CriticalNonCompliantCount` + `SecurityNonCompliantCount` + `OtherNonCompliantCount` + `UnreportedNotApplicableCount ` + `InstalledPendingRebootCount` + `FailedCount` + `NotApplicableCount` + `InstalledRejectedCount` + `InstalledOtherCount` + `MissingCount` + `InstalledCount` ## AWS CLI マネージドノードのスキャンとパッチ適用のためのコマンド 次のコマンドを実行してパッチコンプライアンスをスキャンするか、パッチをインストールした後、「[パッチの概要と詳細を表示するための AWS CLI コマンド](#patch-details-cli-commands)」セクションのコマンドを使用して、パッチのステータスおよびコンプライアンスに関する情報を表示できます。 **Topics** + [マネージドノードをスキャンしてパッチコンプライアンスを確認する (AWS CLI)](#patch-operations-scan) + [マネージドノードへのパッチのインストール (AWS CLI)](#patch-operations-install-cli) ### マネージドノードをスキャンしてパッチコンプライアンスを確認する (AWS CLI) **特定のマネージドノードをスキャンしてパッチコンプライアンスを確認するには** 以下のコマンドを実行してください。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name 'AWS-RunPatchBaseline' \ --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \ --parameters 'Operation=Scan' \ --timeout-seconds 600 ``` ------ #### [ Windows サーバー ] ``` aws ssm send-command ^ --document-name "AWS-RunPatchBaseline" ^ --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^ --parameters "Operation=Scan" ^ --timeout-seconds 600 ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Command": { "CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE", "DocumentName": "AWS-RunPatchBaseline", "DocumentVersion": "$DEFAULT", "Comment": "", "ExpiresAfter": 1621974475.267, "Parameters": { "Operation": [ "Scan" ] }, "InstanceIds": [], "Targets": [ { "Key": "InstanceIds", "Values": [ "i-02573cafcfEXAMPLE, i-0471e04240EXAMPLE" ] } ], "RequestedDateTime": 1621952275.267, "Status": "Pending", "StatusDetails": "Pending", "TimeoutSeconds": 600, ---output truncated--- } } ``` **パッチグループタグでマネージドノードをスキャンしてパッチコンプライアンスを確認するには** 以下のコマンドを実行してください。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name 'AWS-RunPatchBaseline' \ --targets Key='tag:PatchGroup',Values='Web servers' \ --parameters 'Operation=Scan' \ --timeout-seconds 600 ``` ------ #### [ Windows サーバー ] ``` aws ssm send-command ^ --document-name "AWS-RunPatchBaseline" ^ --targets Key="tag:PatchGroup",Values="Web servers" ^ --parameters "Operation=Scan" ^ --timeout-seconds 600 ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Command": { "CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE", "DocumentName": "AWS-RunPatchBaseline", "DocumentVersion": "$DEFAULT", "Comment": "", "ExpiresAfter": 1621974983.128, "Parameters": { "Operation": [ "Scan" ] }, "InstanceIds": [], "Targets": [ { "Key": "tag:PatchGroup", "Values": [ "Web servers" ] } ], "RequestedDateTime": 1621952783.128, "Status": "Pending", "StatusDetails": "Pending", "TimeoutSeconds": 600, ---output truncated--- } } ``` ### マネージドノードへのパッチのインストール (AWS CLI) **特定のマネージドノードにパッチをインストールするには** 以下のコマンドを実行してください。 **注記** パッチのインストールを完了するために、ターゲット マネージドノードは必要に応じて再起動します。詳細については、「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name 'AWS-RunPatchBaseline' \ --targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \ --parameters 'Operation=Install' \ --timeout-seconds 600 ``` ------ #### [ Windows サーバー ] ``` aws ssm send-command ^ --document-name "AWS-RunPatchBaseline" ^ --targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^ --parameters "Operation=Install" ^ --timeout-seconds 600 ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Command": { "CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE", "DocumentName": "AWS-RunPatchBaseline", "DocumentVersion": "$DEFAULT", "Comment": "", "ExpiresAfter": 1621975301.791, "Parameters": { "Operation": [ "Install" ] }, "InstanceIds": [], "Targets": [ { "Key": "InstanceIds", "Values": [ "i-02573cafcfEXAMPLE, i-0471e04240EXAMPLE" ] } ], "RequestedDateTime": 1621953101.791, "Status": "Pending", "StatusDetails": "Pending", "TimeoutSeconds": 600, ---output truncated--- } } ``` **特定のパッチグループのマネージドノードにパッチをインストールするには** 以下のコマンドを実行してください。 ------ #### [ Linux & macOS ] ``` aws ssm send-command \ --document-name 'AWS-RunPatchBaseline' \ --targets Key='tag:PatchGroup',Values='Web servers' \ -parameters 'Operation=Install' \ --timeout-seconds 600 ``` ------ #### [ Windows サーバー ] ``` aws ssm send-command ^ --document-name "AWS-RunPatchBaseline" ^ --targets Key="tag:PatchGroup",Values="Web servers" ^ --parameters "Operation=Install" ^ --timeout-seconds 600 ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Command": { "CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE", "DocumentName": "AWS-RunPatchBaseline", "DocumentVersion": "$DEFAULT", "Comment": "", "ExpiresAfter": 1621975407.865, "Parameters": { "Operation": [ "Install" ] }, "InstanceIds": [], "Targets": [ { "Key": "tag:PatchGroup", "Values": [ "Web servers" ] } ], "RequestedDateTime": 1621953207.865, "Status": "Pending", "StatusDetails": "Pending", "TimeoutSeconds": 600, ---output truncated--- } } ``` # AWS Systems Manager Patch Manager のチュートリアル このセクションのチュートリアルでは、AWS Systems Manager のツールである Patch Manager をいくつかのパッチ適用シナリオで使用する方法を示します。 **Topics** + [チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md) + [チュートリアル: コンソールを使用して Windows サービスパックをインストールするためのパッチベースラインを作成する](patch-manager-windows-service-pack-patch-baseline-tutorial.md) + [チュートリアル: アプリケーションの依存関係の更新、マネージドノードへのパッチ適用、およびアプリケーション固有のヘルスチェックの実行](aws-runpatchbaselinewithhooks-tutorial.md) + [チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する](patch-manager-patch-servers-using-the-aws-cli.md) # チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する Patch Manager は、IPv6 のみの環境でのノードのパッチ適用をサポートします。SSM Agent 設定を更新することで、IPv6 サービスエンドポイントのみを呼び出すようにパッチ適用オペレーションを設定できます。 **IPv6 のみの環境でサーバーにパッチを適用するには** 1. SSM Agent のバージョン 3.3270.0 以降がマネージドノードにインストールされていることを確認します。 1. マネージドノードで、SSM Agent 設定ファイルに移動します。`amazon-ssm-agent.json` ファイルは次のディレクトリにあります。 + Linux: `/etc/amazon/ssm/` + macOS: `/opt/aws/ssm/` + Windows Server: `C:\Program Files\Amazon\SSM` `amazon-ssm-agent.json` がまだ存在しない場合は、同じディレクトリの `amazon-ssm-agent.json.template` の内容を `amazon-ssm-agent.json` にコピーします。 1. 次のエントリを更新して正しいリージョンを設定し、`UseDualStackEndpoint` を `true` に設定します。 ``` { -------- "Agent": { "Region": "region", "UseDualStackEndpoint": true }, -------- } ``` 1. オペレーティングシステムに適したコマンドを使用して SSM Agent サービスを再起動します。 + Linux: `sudo systemctl restart amazon-ssm-agent` + Snap を使用する Ubuntu Server: `sudo snap restart amazon-ssm-agent` + macOS: `sudo launchctl stop com.amazon.aws.ssm` の前の `sudo launchctl start com.amazon.aws.ssm` + Windows Server: `Stop-Service AmazonSSMAgent` の前の `Start-Service AmazonSSMAgent` オペレーティングシステムごとのコマンドの完全なリストについては、「[SSM Agent ステータスの確認とエージェントの起動](ssm-agent-status-and-restart.md)」を参照してください。 1. パッチ適用オペレーションを実行して、IPv6 のみの環境でパッチ適用オペレーションが正常に完了することを確認します。パッチを適用するノードがパッチソースに接続されていることを確認します。パッチ適用の実行からの Run Command 出力をチェックして、アクセスできないリポジトリに関する警告を確認できます。IPv6 のみの環境で実行されているノードにパッチを適用する場合は、ノードがパッチソースに接続されていることを確認します。パッチ適用の実行からの Run Command 出力をチェックして、アクセスできないリポジトリに関する警告を確認できます。DNF ベースのオペレーティングシステムでは、 `/etc/dnf/dnf.conf` で `skip_if_unavailable` オプションが `True` に設定されている場合、使用できないリポジトリをパッチ適用中にスキップするように設定できます。DNF ベースのオペレーティングシステムには、Amazon Linux 2023、Red Hat Enterprise Linux 8 以降のバージョン、Oracle Linux 8 以降のバージョン、Rocky Linux、AlmaLinux、および CentOS 8 以降のバージョンが含まれます。Amazon Linux 2023 では、`skip_if_unavailable` オプションはデフォルトで `True` に設定されています。 **注記** Install Override List または Baseline Override 機能を使用する場合は、指定された URL がノードから到達可能であることを確認してください。SSM Agent config オプション `UseDualStackEndpoint` が `true` に設定されている場合、S3 の URL を指定するとデュアルスタック S3 クライアントが使用されます。 # チュートリアル: コンソールを使用して Windows サービスパックをインストールするためのパッチベースラインを作成する カスタムパッチベースラインを作成するときに、サポートされているパッチのすべて、一部、または 1 つのタイプのみをインストールするように指定できます。 Windows のパッチベースラインでは、パッチ適用の更新をサービスパックのみに制限するために、唯一の [**分類**] オプションとして `ServicePacks` を選択できます。サービスパックは、更新プログラムが Windows Update または Windows Server Update サービス (WSUS) で利用可能であれば、AWS Systems Manager のツールである Patch Manager によって自動的にインストールできます。 パッチベースラインを構成して、すべての Windows バージョンのサービスパックをインストールするか、Windows 7 や Windows Server 2016 などの特定のバージョンのサービスパックだけをインストールするかを制御できます。 Windows マネージドノードにすべてのサービスパックをインストールするためにのみ使用されるカスタム パッチベースラインを作成するには、以下の手順を使用します。 **Windows サービスパックをインストールするためのパッチベースラインを作成するには (コンソール)** 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[パッチベースライン]** タブを選択し、**[パッチベースラインの作成]** を選択します。 1. [**Name (名前)**] フィールドに、新しいパッチベースラインの名前 (例: `MyWindowsServicePackPatchBaseline`) を入力します。 1. (オプション) [**Description (説明)**] に、パッチベースラインの説明を入力します。 1. [**Operating system (オペレーティングシステム)**] で、`Windows` を選択します。 1. 作成してすぐに、このパッチベースラインを Windows のデフォルトとして使用する場合は、[**Set this patch baseline as the default patch baseline for Windows Server instances (このパッチベースラインを Windows Server インスタンスのデフォルトのパッチベースラインにする)**] を選択します。 **注記** このオプションは、2022 年 12 月 22 日の[パッチポリシー](patch-manager-policies.md)リリース前に初めて Patch Manager にアクセスした場合にのみ使用できます。 既存のパッチベースラインのデフォルト設定の詳細については、「[既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md)」を参照してください。 1. [**Approval rules for operating systems (オペレーティングシステムの承認ルール)**] セクションで、フィールドを使用して 1 つ以上の自動承認ルールを作成します。 + **[製品]**: 承認ルールが適用されるオペレーティングシステムのバージョン (`WindowsServer2012` など)。1 つ、複数、またはサポートされているすべてのバージョンの Windows を選択できます。デフォルトの選択は `All` です。 + **分類**: `ServicePacks` を選択します。 + [**Severity (重要度)**]: ルールが適用されるパッチの重要度の値。ルールによってすべてのサービスパックが含まれるようにするには、`All` を選択します。 + [**Auto-approval (自動承認)**]: 自動承認のためにパッチを選択する方法。 + **[Approve patches after a specified number of days]** (指定した日数後にパッチを承認): パッチがリリースまたは更新されてから、自動的に承認されるまで Patch Manager が待機する日数。ゼロ (0) から 360 の任意の整数を入力できます。ほとんどのシナリオでは、待機日数を 100 日以内にすることをお勧めします。 + **[Approve patches released up to a specific date]** (特定の日付までにリリースされたパッチを承認): Patch Manager がその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用するパッチのリリース日。例えば、2023 年 7 月 7 日を指定した場合、リリース日または最後の更新日が 2023 年 7 月 8 日以降であるパッチは、自動的にインストールされません。 + (オプション) [**Compliance reporting (コンプライアンスレポート)**]: ベースラインで承認されたサービスパックに割り当てる重要度 (`High` など)。 **注記** コンプライアンスレポートレベルを指定し、承認されたサービスパックのパッチ状態が `Missing` として報告された場合、パッチベースラインで報告されるコンプライアンス全体の重要度は、指定した重要度レベルになります。 1. (オプション) [**Manage tags (タグの管理)**] で、1 つ以上のタグキーの名前と値のペアをパッチベースラインに適用します。 タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。サービスパックの更新専用のこのパッチベースラインでは、次のようなキーと値のペアを指定できます。 + `Key=OS,Value=Windows` + `Key=Classification,Value=ServicePacks` 1. [**Create patch baseline**] を選択します。 # チュートリアル: アプリケーションの依存関係の更新、マネージドノードへのパッチ適用、およびアプリケーション固有のヘルスチェックの実行 多くの場合、マネージドノードは、最新のソフトウェア更新プログラムでパッチを適用した後に再起動する必要があります。ただし、安全対策を講じずに本番環境でノードを再起動すると、アラームの発動、不正なメトリクス データの記録、データ同期の中断など、いくつかの問題が発生する可能性があります。 このチュートリアルでは、AWS Systems Manager ドキュメント (SSM ドキュメント) `AWS-RunPatchBaselineWithHooks` を使用して、このような問題を回避する方法を学習します。これにより、複雑なマルチステップのパッチオペレーションを実現し、以下のことを達成できます。 1. アプリケーションへの新しい接続を防止 1. オペレーティングシステムの更新のインストール 1. アプリケーションのパッケージの依存関係の更新 1. システムの再起動 1. アプリケーション固有のヘルスチェックの実行 この例では、インフラストラクチャを次のようにセットアップしました。 + 対象の仮想マシンは、マネージドノードとして Systems Manager に登録されます。 + `Iptables` はローカルファイアウォールとして使用されます。 + マネージドノードでホストされているアプリケーションは、ポート 443 で実行されています。 + マネージドノードでホストされるアプリケーションは `nodeJS` アプリケーションです。 + マネージドノードでホストされるアプリケーションは、pm2 プロセスマネージャーによって管理されます。 + アプリケーションには、指定したヘルスチェックエンドポイントが既に存在します。 + アプリケーションのヘルスチェックエンドポイントは、エンドユーザー認証を必要としません。エンドポイントにより、可用性を確立する際に組織の要件を満たすヘルスチェックを行うことが可能になります。(実際の環境では、`nodeJS` アプリケーションが実行中であり、リクエストをリッスンできることを確認するだけで十分な場合があります。また、キャッシュレイヤーまたはデータベースレイヤーへの接続が既に確立されていることを確認する必要があります)。 このチュートリアルの例は、デモンストレーションのみを目的としており、本番環境にそのまま実装することを意図していません。また、Systems Manager のツールである Patch Manager のライフサイクルフック機能は、`AWS-RunPatchBaselineWithHooks` ドキュメントとともに他の多数のシナリオをサポートできることに注意してください。次にいくつかの例を示します。 + マネージドノードの再起動後にパッチを適用して再起動する前に、メトリクスレポート エージェントを停止します。 + パッチを適用する前に、CRM または PCS クラスターからマネージドノードをデタッチし、ノードの再起動後に再アタッチします。 + オペレーティングシステム (OS) の更新が適用された後、マネージドノードが再起動する前に、Windows Server マシン上のサードパーティーソフトウェア (Java、Tomcat、Adobe アプリケーションなど) を更新します。 **アプリケーションの依存関係を更新し、マネージドノードにパッチを適用し、アプリケーション固有のヘルスチェックを実行するには** 1. preinstallation スクリプトの SSM ドキュメントを次の内容で作成し、`NodeJSAppPrePatch` と名前を付けます。*your\$1application* をアプリケーションの名前に置き換えます。 このスクリプトは、新しい受信リクエストを直ちにブロックし、既にアクティブなリクエストが完了するまで 5 秒間待ってからパッチ適用操作を開始します。`sleep` オプションでは、受信リクエストが完了するのに通常かかる秒数よりも長い秒数を指定します。 ``` # exit on error set -e # set up rule to block incoming traffic iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1 # wait for current connections to end. Set timeout appropriate to your application's latency sleep 5 # Stop your application pm2 stop your_application ``` SSM ドキュメントの作成の詳細については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。 1. postinstall スクリプト用に次の内容を含む別の SSM ドキュメントを作成し、アプリケーションの依存関係を更新し、`NodeJSAppPostPatch` と名前を付けます。*/your/application/path* をお使いのアプリケーションへのパスに置き換えます。 ``` cd /your/application/path npm update # you can use npm-check-updates if you want to upgrade major versions ``` 1. アプリケーションをバックアップし、ヘルスチェックを実行するには、`onExit` スクリプト用に次の内容を含む別の SSM ドキュメントを作成します。この SSM ドキュメント `NodeJSAppOnExitPatch` の名前を付けます。*your\$1application* をアプリケーションの名前に置き換えます。 ``` # exit on error set -e # restart nodeJs application pm2 start your_application # sleep while your application starts and to allow for a crash sleep 10 # check with pm2 to see if your application is running pm2 pid your_application # re-enable incoming connections iptables -D INPUT -j DROP -p tcp --syn --destination-port # perform health check /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1 ``` 1. AWS Systems Manager のツールである State Manager で関連付けを作成し、以下の手順を実行してオペレーションを発行します。 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、[**State Manager**] を選択し、[**Create association (関連付けの作成)**] を選択します。 1. [**Name (名前)**] に、関連付けの目的を特定するのに役立つ名前を指定します。 1. [**Document (ドキュメント)**] リストで、[`AWS-RunPatchBaselineWithHooks`] を選択します。 1. [**Operation (オペレーション)**] で、[**Install (インストール)**] を選択します。 1. (オプション) [**Snapshot Id**] では、GUID を指定します。これは、オペレーションの高速化と一貫性の確保のために生成します。この GUID は `00000000-0000-0000-0000-111122223333` と同じくらいシンプルです。 1. [**Pre Install Hook Doc Name (インストール前のフックドキュメント名)**] に、「`NodeJSAppPrePatch`」と入力します。 1. [**Post Install Hook Doc Name (インストール後のフックドキュメント名)**] に、「`NodeJSAppPostPatch`」と入力します。 1. [**On ExitHook Doc Name (ExitHook ドキュメント名)**] に、「`NodeJSAppOnExitPatch`」と入力します。 1. **[Targets]** (ターゲット) では、タグの指定、ノードの手動選択、リソースグループの選択、またはすべてのマネージドノードの選択により、マネージドノードを特定します。 1. [**Specify schedule (スケジュールの指定)**] では、関連付けを実行する頻度を指定します。マネージドノードのパッチ適用では、週に 1 回が一般的な頻度です。 1. **[Rate control]** (レート制御) セクションで、複数のマネージドノードでの関連付けの実行方法を制御するオプションを選択します。一度に更新されるのは一部のマネージドノードであることを確認します。そうしないと、フリートのすべてまたはほとんどを同時にオフラインにすることになってしまいます。レート制御については、「[State Manager 関連付けのターゲットとレート制御について](systems-manager-state-manager-targets-and-rate-controls.md)」を参照してください。 1. (オプション) [**出力オプション**] で、コマンド出力をファイルに保存するには、[**S3 への出力の書き込みを有効にします**] ボックスをオンにします。ボックスにバケット名とプレフィックス (フォルダ) 名を入力してください。 **注記** S3 バケットにデータを書き込む機能を許可する S3 アクセス許可は、このタスクを実行する IAM ユーザーのものではなく、マネージドノードに割り当てられたインスタンスプロファイルのものです。詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」または「[ハイブリッド環境に IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。さらに、指定された S3 バケットが別の AWS アカウント にある場合は、マネージドノードに関連付けられたインスタンスプロファイルまたは IAM サービスロールに、そのバケットへの書き込みに必要なアクセス許可があることを確認してください。 1. **[関連付けの作成]** を選択します。 # チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する 次の手順では、カスタムパッチベースライン、パッチグループ、メンテナンスウィンドウを使用してサーバー環境にパッチを適用する方法を説明します。 **[開始する前に]** + マネージドノードに SSM Agent をインストールまたはアップデートしてください。Linux マネージドノードにパッチを適用するには、ノードが SSM Agent バージョン 2.0.834.0 以降実行されている必要があります。詳細については、「[Run Command を使用して SSM Agent を更新する](run-command-tutorial-update-software.md#rc-console-agentexample)」を参照してください。 + AWS Systems Manager のツールである Maintenance Windows のロールとアクセス許可を設定します 詳細については、「[Maintenance Windows を設定する](setting-up-maintenance-windows.md)」を参照してください。 + まだ AWS Command Line Interface (AWS CLI) をインストールして設定していない場合は、インストールして設定します。 詳細については、「[AWS CLI の最新バージョンをインストールまたは更新します。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 **Patch Manager を設定してマネージドノードにパッチを適用するには (コマンドライン)** 1. 次のコマンドを実行して、`Production-Baseline` という名前の Windows のパッチベースラインを作成します。このパッチベースラインは、リリースまたは最後に更新されてから 7 日後に、実稼働環境のパッチを承認します。つまり、パッチベースラインが本番環境用であることを示すタグ付けがされています。 **注記** `OperatingSystem` パラメータおよび `PatchFilters` は、パッチベースラインが適用されるターゲット マネージドノードのオペレーティングシステムによって異なります。詳細については、「[OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem)」および「[PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)」を参照してください。 ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "Production-Baseline" \ --operating-system "WINDOWS" \ --tags "Key=Environment,Value=Production" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \ --description "Baseline containing all updates approved for production systems" ``` ------ #### [ Windows サーバー ] ``` aws ssm create-patch-baseline ^ --name "Production-Baseline" ^ --operating-system "WINDOWS" ^ --tags "Key=Environment,Value=Production" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^ --description "Baseline containing all updates approved for production systems" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. 次のコマンドを実行して、2 つのパッチグループの「実稼働ベースライン」パッチベースラインを登録します。グループの名前は「データベースサーバー」と「フロントエンドサーバー」です。 ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group "Database Servers" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-patch-baseline-for-patch-group ^ --baseline-id pb-0c10e65780EXAMPLE ^ --patch-group "Database Servers" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "PatchGroup":"Database Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group "Front-End Servers" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-patch-baseline-for-patch-group ^ --baseline-id pb-0c10e65780EXAMPLE ^ --patch-group "Front-End Servers" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "PatchGroup":"Front-End Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. 次のコマンドを実行し、実稼働サーバー用の 2 つのメンテナンスウィンドウを作成します。最初のウィンドウは、毎火曜日の午後 10 時に実行します。2 番目のウィンドウは、毎土曜日の午後 10 時に実行します。また、メンテナンスウィンドウが実稼働環境用であることを示すタグが付けられます。 ------ #### [ Linux & macOS ] ``` aws ssm create-maintenance-window \ --name "Production-Tuesdays" \ --tags "Key=Environment,Value=Production" \ --schedule "cron(0 0 22 ? * TUE *)" \ --duration 1 \ --cutoff 0 \ --no-allow-unassociated-targets ``` ------ #### [ Windows サーバー ] ``` aws ssm create-maintenance-window ^ --name "Production-Tuesdays" ^ --tags "Key=Environment,Value=Production" ^ --schedule "cron(0 0 22 ? * TUE *)" ^ --duration 1 ^ --cutoff 0 ^ --no-allow-unassociated-targets ``` ------ システムが以下のような情報をレスポンスします。 ``` { "WindowId":"mw-0c50858d01EXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm create-maintenance-window \ --name "Production-Saturdays" \ --tags "Key=Environment,Value=Production" \ --schedule "cron(0 0 22 ? * SAT *)" \ --duration 2 \ --cutoff 0 \ --no-allow-unassociated-targets ``` ------ #### [ Windows サーバー ] ``` aws ssm create-maintenance-window ^ --name "Production-Saturdays" ^ --tags "Key=Environment,Value=Production" ^ --schedule "cron(0 0 22 ? * SAT *)" ^ --duration 2 ^ --cutoff 0 ^ --no-allow-unassociated-targets ``` ------ システムが以下のような情報をレスポンスします。 ``` { "WindowId":"mw-9a8b7c6d5eEXAMPLE" } ``` 1. 次のコマンドを実行して、`Database` および `Front-End` サーバーのパッチグループをそれぞれのメンテナンスウィンドウに登録します。 ------ #### [ Linux & macOS ] ``` aws ssm register-target-with-maintenance-window \ --window-id mw-0c50858d01EXAMPLE \ --targets "Key=tag:PatchGroup,Values=Database Servers" \ --owner-information "Database Servers" \ --resource-type "INSTANCE" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-target-with-maintenance-window ^ --window-id mw-0c50858d01EXAMPLE ^ --targets "Key=tag:PatchGroup,Values=Database Servers" ^ --owner-information "Database Servers" ^ --resource-type "INSTANCE" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm register-target-with-maintenance-window \ --window-id mw-9a8b7c6d5eEXAMPLE \ --targets "Key=tag:PatchGroup,Values=Front-End Servers" \ --owner-information "Front-End Servers" \ --resource-type "INSTANCE" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-target-with-maintenance-window ^ --window-id mw-9a8b7c6d5eEXAMPLE ^ --targets "Key=tag:PatchGroup,Values=Front-End Servers" ^ --owner-information "Front-End Servers" ^ --resource-type "INSTANCE" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE" } ``` 1. 次のコマンドを実行して、それぞれのメンテナンスウィンドウ中に、`Database` および `Front-End` サーバー上に不足している更新プログラムをインストールするパッチタスクを登録します。 ------ #### [ Linux & macOS ] ``` aws ssm register-task-with-maintenance-window \ --window-id mw-0c50858d01EXAMPLE \ --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \ --task-arn "AWS-RunPatchBaseline" \ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \ --task-type "RUN_COMMAND" \ --max-concurrency 2 \ --max-errors 1 \ --priority 1 \ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-task-with-maintenance-window ^ --window-id mw-0c50858d01EXAMPLE ^ --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^ --task-arn "AWS-RunPatchBaseline" ^ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^ --task-type "RUN_COMMAND" ^ --max-concurrency 2 ^ --max-errors 1 ^ --priority 1 ^ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm register-task-with-maintenance-window \ --window-id mw-9a8b7c6d5eEXAMPLE \ --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \ --task-arn "AWS-RunPatchBaseline" \ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \ --task-type "RUN_COMMAND" \ --max-concurrency 2 \ --max-errors 1 \ --priority 1 \ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ #### [ Windows サーバー ] ``` aws ssm register-task-with-maintenance-window ^ --window-id mw-9a8b7c6d5eEXAMPLE ^ --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^ --task-arn "AWS-RunPatchBaseline" ^ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^ --task-type "RUN_COMMAND" ^ --max-concurrency 2 ^ --max-errors 1 ^ --priority 1 ^ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE" } ``` 1. 以下のコマンドを実行して、パッチグループのパッチコンプライアンスの概要を取得します。高レベル パッチコンプライアンスの概要には、それぞれのパッチ状態のパッチがあるマネージドノードの数が含まれます。 **注記** 最初のメンテナンスウィンドウ中にパッチ タスクが実行されるまで、サマリー内のマネージドノード数はゼロであることが予想されます。 ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-group-state \ --patch-group "Database Servers" ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-patch-group-state ^ --patch-group "Database Servers" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "Instances": number, "InstancesWithFailedPatches": number, "InstancesWithInstalledOtherPatches": number, "InstancesWithInstalledPatches": number, "InstancesWithInstalledPendingRebootPatches": number, "InstancesWithInstalledRejectedPatches": number, "InstancesWithMissingPatches": number, "InstancesWithNotApplicablePatches": number, "InstancesWithUnreportedNotApplicablePatches": number } ``` 1. 以下のコマンドを実行して、パッチグループのマネージドノードごとにパッチ状態の概要を取得します。マネージドノードごとのサマリーには、パッチグループのマネージドノードごとのそれぞれのパッチ状態にある多数のパッチが含まれます。 ------ #### [ Linux & macOS ] ``` aws ssm describe-instance-patch-states-for-patch-group \ --patch-group "Database Servers" ``` ------ #### [ Windows サーバー ] ``` aws ssm describe-instance-patch-states-for-patch-group ^ --patch-group "Database Servers" ``` ------ システムが以下のような情報をレスポンスします。 ``` { "InstancePatchStates": [ { "BaselineId": "string", "FailedCount": number, "InstalledCount": number, "InstalledOtherCount": number, "InstalledPendingRebootCount": number, "InstalledRejectedCount": number, "InstallOverrideList": "string", "InstanceId": "string", "LastNoRebootInstallOperationTime": number, "MissingCount": number, "NotApplicableCount": number, "Operation": "string", "OperationEndTime": number, "OperationStartTime": number, "OwnerInformation": "string", "PatchGroup": "string", "RebootOption": "string", "SnapshotId": "string", "UnreportedNotApplicableCount": number } ] } ``` Patch Managerの設定タスクを実行するために使用できる他の AWS CLI コマンドの例については、「[AWS CLI を使用して Patch Manager リソースを操作する](patch-manager-cli-commands.md)」を参照してください。 # Patch Manager のトラブルシューティング AWS Systems Manager のツールである Patch Manager を使用したトラブルシューティングでは、以下の情報を使用します。 **Topics** + [問題:「Invoke-PatchBaselineOperation」:`baseline_overrides.json` についての「アクセスが拒否されました」エラーまたは「S3 からファイルをダウンロードできません」エラー](#patch-manager-troubleshooting-patch-policy-baseline-overrides) + [問題: パッチ適用が失敗したものの、明らかな原因やエラーメッセージが表示されない](#race-condition-conflict) + [問題: 想定外のパッチコンプライアンス結果](#patch-manager-troubleshooting-compliance) + [Linuxで `AWS-RunPatchBaseline` を実行時のエラー](#patch-manager-troubleshooting-linux) + [Windows Server で `AWS-RunPatchBaseline` 実行時のエラー](#patch-manager-troubleshooting-windows) + [macOS で `AWS-RunPatchBaseline` を実行する際のエラー](#patch-manager-troubleshooting-macos) + [AWS サポート Automation ランブックの使用方法](#patch-manager-troubleshooting-using-support-runbooks) + [AWS サポートに連絡する](#patch-manager-troubleshooting-contact-support) ## 問題:「Invoke-PatchBaselineOperation」:`baseline_overrides.json` についての「アクセスが拒否されました」エラーまたは「S3 からファイルをダウンロードできません」エラー **問題**: パッチポリシーによって指定されたパッチ適用オペレーションを実行すると、次の例のようなエラーが表示されます。 ------ #### [ Example error on Windows サーバー ] ``` ----------ERROR------- Invoke-PatchBaselineOperation : Access Denied At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13 + $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo nS3Exception + FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op erations.PowerShellCmdlets.InvokePatchBaselineOperation failed to run commands: exit status 0xffffffff ``` ------ #### [ Example error on Linux ] ``` [INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json [ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json. [ERROR]: Error loading entrance module. ``` ------ **原因**: Quick Setup でパッチポリシーを作成しましたが、マネージドノードの一部には、既にインスタンスプロファイル (EC2 インスタンスの場合) またはサービスロール (EC2 以外のマシンの場合) がアタッチされています。 ただし、次の画像に示すように、**[インスタンスにアタッチされている既存のインスタンスプロファイルに必要な IAM ポリシーを追加]** チェックボックスをオンにしませんでした。 ![\[\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/QS-instance-profile-option.png) パッチポリシーを作成すると、ポリシーの設定 `baseline_overrides.json` ファイルを保存するための Amazon S3 バケットも作成されます。ポリシーの作成時に **[インスタンスにアタッチされている既存のインスタンスプロファイルに必要な IAM ポリシーを追加]** チェックボックスをオンにしない場合、S3 バケット内で `baseline_overrides.json` にアクセスするために必要な IAM ポリシーとリソースタグは、既存の IAM インスタンスのプロファイルとサービスロールに自動的に追加されません。 **解決策 1**: 既存のパッチポリシー設定を削除し、代わりのポリシーを作成します。その際には、必ず **[インスタンスにアタッチされている既存のインスタンスプロファイルに必要な IAM ポリシーを追加]** チェックボックスをオンにしてください。これにより、この Quick Setup 設定によって作成された IAM ポリシーは、既にインスタンスプロファイルまたはサービスロールがアタッチされているノードに適用されます。(デフォルトでは、Quick Setup は、インスタンスプロファイルやサービスロールをまだ持ってい*ない*インスタンスおよびノードに必要なポリシーを追加します) 詳細については、「[Quick Setup パッチポリシーを使用して組織全体のパッチ適用を自動化する](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)」を参照してください。 **解決策 2**: Quick Setup で使用する各 IAM インスタンスプロファイルと IAM サービスロールに、必要な許可とタグを手動で追加します。手順については、「[パッチポリシー S3 バケットの許可](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions)」を参照してください。 ## 問題: パッチ適用が失敗したものの、明らかな原因やエラーメッセージが表示されない **問題**: パッチ適用操作はエラーメッセージを返さずに失敗します。 **考えられる原因**: マネージドノードにパッチを適用すると、パッチが正常にインストールされても、ドキュメントの実行が中断されて失敗としてマークされる場合があります。パッチ適用オペレーション中にシステムが予期しない再起動を実行した場合 (例えば、ファームウェアや SecureBoot などの機能に更新プログラムを適用するため)、発生する可能性があります。SSM Agent が外部再起動全体でドキュメントの実行状態を維持および再開できないため、実行は失敗として報告されます。 **解決策**: 実行が失敗した後にパッチ適用のインストールステータスを確認するには、`Scan` パッチ適用オペレーションを実行し、Patch Manager でパッチコンプライアンスデータを確認して現在のコンプライアンス状態を評価します。 このシナリオにおいて、外部からの再起動が障害の原因ではないと判断された場合は、「[AWS サポート](#patch-manager-troubleshooting-contact-support)」に問い合わせることをお勧めします。 ## 問題: 想定外のパッチコンプライアンス結果 **問題**: `Scan` オペレーション後に生成されたパッチ適用コンプライアンスの詳細を確認すると、結果にパッチベースラインに設定されたルールを反映していない情報が含まれています。例えば、パッチベースラインの **[Rejected patches]** (拒否されたパッチ) リストに追加した例外は、`Missing` として表示されます。または、パッチベースラインで `Critical` パッチのみと指定されている場合でも、`Important` に分類されたパッチが未適用と表示されます。 **原因**: Patch Manager は現在、`Scan` オペレーションを実行する複数の方法をサポートしています。 + Quick Setup で設定されているパッチポリシー + Quick Setup で設定されているホスト管理オプション + パッチ `Scan` または `Install` のタスクを実行するためのメンテナンスウィンドウ + オンデマンドの **[Patch now]** (今すぐパッチ適用) オペレーション `Scan` オペレーションを実行すると、最新のスキャンのコンプライアンスの詳細が上書きされます。`Scan` オペレーションを実行するために複数の方法を設定していて、それぞれの方法によってルールが異なるさまざまなパッチベースラインが使用されている場合、パッチコンプライアンスの結果も異なります。 **解決方法**: 想定外のパッチコンプライアンスの結果を避けるため、Patch Manager `Scan` オペレーションを実行する方法は一度に 1 つだけ使用することをお勧めします。詳細については、「[パッチコンプライアンスデータを作成した実行の特定](patch-manager-compliance-data-overwrites.md)」を参照してください。 ## Linuxで `AWS-RunPatchBaseline` を実行時のエラー **Topics** + [問題:「そのようなファイルまたはディレクトリがありません」というエラー](#patch-manager-troubleshooting-linux-1) + [問題:「別のプロセスが yum ロックを取得しました」というエラー](#patch-manager-troubleshooting-linux-2) + [問題:「権限が拒否された/コマンドを実行できませんでした」というエラー](#patch-manager-troubleshooting-linux-3) + [問題:「ペイロードをダウンロードできません」というエラー](#patch-manager-troubleshooting-linux-4) + [問題：「サポートされていないパッケージマネージャとPythonバージョンの組み合わせ」エラー](#patch-manager-troubleshooting-linux-5) + [問題: 特定のパッケージを除外するために指定されたルールを Patch Manager が適用しない。](#patch-manager-troubleshooting-linux-6) + [問題: パッチ適用が失敗し、TLS へのサーバー名表示拡張を利用できないことが Patch Manager から報告される](#patch-manager-troubleshooting-linux-7) + [問題: Patch Manager が「試行するミラーはもうありません」と報告する](#patch-manager-troubleshooting-linux-8) + [問題: 「curl から返されたエラーコードは 23 です」というメッセージが表示されてパッチが失敗する](#patch-manager-troubleshooting-linux-9) + [問題: パッチ適用が失敗し、「Error unpacking rpm package…」(rmp パッケージの解凍中にエラーが発生しました...) というメッセージが表示される](#error-unpacking-rpm) + [問題: パッチ適用が失敗し、「Encounter service side error when uploading the inventory」と表示される](#inventory-upload-error) + [問題:「Errors were encountered while downloading packages」(パッケージのダウンロード中にエラーが発生しました) というメッセージが表示されてパッチ適用が失敗する](#errors-while-downloading) + [問題: パッチ適用がメモリ不足 (OOM) エラーで失敗する](#patch-manager-troubleshooting-linux-oom) + [問題:「The following signatures couldn't be verified because the public key is not available」(公開鍵が利用できないため、次の署名を検証できませんでした) というメッセージが表示されてパッチ適用が失敗します。](#public-key-unavailable) + [問題:「NoMoreMirrorsRepoError」というメッセージが表示されてパッチ適用が失敗します。](#no-more-mirrors-repo-error) + [問題: 「Unable to download payload」(ペイロードをダウンロードできません) というメッセージが表示されてパッチ適用が失敗します。](#payload-download-error) + [問題:「install errors: dpkg: error: dpkg frontend is locked by another process」(インストールエラー:dpkg: エラー:dpkg フロントエンドが別のプロセスによってロックされています) というメッセージが表示されてパッチ適用が失敗します。](#dpkg-frontend-locked) + [問題: Ubuntu Server へのパッチ適用が「dpkg was interrupted」(dpkg が中断されました) というエラーで失敗します。](#dpkg-interrupted) + [問題: パッケージマネージャーユーティリティがパッケージの依存関係を解決できません。](#unresolved-dependency) + [問題: SLES マネージドノードで Zypper パッケージロックの依存関係に失敗する](#patch-manager-troubleshooting-linux-zypper-locks) + [問題:ロックを取得できません。別のパッチ適用オペレーショが進行中です。](#patch-manager-troubleshooting-linux-concurrent-lock) ### 問題:「そのようなファイルまたはディレクトリがありません」というエラー **問題**: `AWS-RunPatchBaseline` 実行時、パッチ適用が次のいずれかのエラーで失敗する。 ``` IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz' ``` ``` Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155 ``` ``` Unable to load and extract the content of payload, abort.failed to run commands: exit status 152 ``` **原因 1**: `AWS-RunPatchBaseline` を実行する 2 つのコマンドが同じマネージドノード上で同時に実行されています。これにより、競合状態が作成され、正しく作成されていない、またはアクセスされていない一時的な `file patch-baseline-operations*` という結果になります。 **原因 2**: `/var` ディレクトリー以下の不十分なストレージ領域 **解決策 1**: メンテナンスウィンドウに、`AWS-RunPatchBaseline` を同じ優先度レベル、同じターゲット ID で実行する 2 つ以上の Run Command タスク がないことを確保します。その場合は、優先順位を並べ替えます。Run Command は AWS Systems Manager のツールです。 **解決策 2**: 同じターゲットに対し、同じスケジュールで `AWS-RunPatchBaseline` を使用する Run Command タスクは、一度に 1 つのメンテナンスウィンドウだけが実行するようにします。このような場合は、スケジュールを変更してください。 **解決策 3**: 同じスケジュールで同じマネージドノードをターゲットにして `AWS-RunPatchBaseline` を実行する State Manager の関連付けは 1 つだけにしてください。State Manager は AWS Systems Manager のツールです。 **解決策 4**: アップデートパッケージ用の `/var` ディレクトリー下に、十分なストレージ領域を解放します。 ### 問題:「別のプロセスが yum ロックを取得しました」というエラー **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用は、次のエラーで失敗する。 ``` 12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry. ``` **原因**: マネージドノードが別のオペレーションで実行を開始し、パッケージマネージャ `yum` プロセスを取得した状態で、`AWS-RunPatchBaseline` ドキュメントがすでに実行されている。 **解決策**: State Manager の関連付けやメンテナンスウィンドウタスクなど、スケジュールに従って `AWS-RunPatchBaseline` を実行する設定が、同じ時間帯に同じマネージドノードをターゲットにしないようにします。 ### 問題:「権限が拒否された/コマンドを実行できませんでした」というエラー **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用は、次のエラーで失敗する。 ``` sh: /var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied failed to run commands: exit status 126 ``` **原因**:`/var/lib/amazon/` が `noexec` 許可でマウントされている可能性。これは、SSM Agent がペイロードスクリプトを`/var/lib/amazon/ssm` にダウンロードし、その場所からそれらを実行することが問題です。 **解決策**: 排他パーティションを `/var/log/amazon` および `/var/lib/amazon` に設定し、`exec` 許可でマウントされているようにする。 ### 問題:「ペイロードをダウンロードできません」というエラー **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用は、次のエラーで失敗する。 ``` Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156 ``` **原因**: マネージドノードには、指定した Amazon Simple Storage Service (Amazon S3) バケットへのアクセスに必要な許可がない。 **解決策**: S3 エンドポイントに到達できるようにネットワーク設定を更新します。詳細については、[SSM Agent と AWS マネージド S3 バケットとの通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) で Patch Manager の S3 バケットへの必要なアクセスに関する情報を参照してください。 ### 問題：「サポートされていないパッケージマネージャとPythonバージョンの組み合わせ」エラー **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用は、次のエラーで失敗する。 ``` An unsupported package manager and python version combination was found. Apt requires Python3 to be installed. failed to run commands: exit status 1 ``` **原因**: サポートされているバージョンの Python 3 が Debian Server または Ubuntu Server インスタンスにインストールされていない。 **解決策**: Debian Server および Ubuntu Server マネージドノードに必要なサポートされているバージョンの python3 (3.0～3.12) をサーバーにインストールします。 ### 問題: 特定のパッケージを除外するために指定されたルールを Patch Manager が適用しない。 **問題**: 形式 `exclude=package-name` の `/etc/yum.conf` ファイルで指定した特定のパッケージを除外しようとしたが、Patch Manager `Install` オペレーションでは除外されない。 **原因**: Patch Manager が、`/etc/yum.conf` ファイルで指定された除外項目を取り込まない。 **解決策**: 特定のパッケージを除外するには、カスタムパッチベースラインを作成し、インストールしないパッケージを除外するルールを作成します。 ### 問題: パッチ適用が失敗し、TLS へのサーバー名表示拡張を利用できないことが Patch Manager から報告される **問題**: パッチ適用操作が、次のメッセージを発行する。 ``` /var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369: SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension to TLS is not available on this platform. This might cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings ``` **原因**: このメッセージはエラーを示していません。代わりに、オペレーティングシステムと共に配布されている古いバージョンの Python が TLS サーバー名表示をサポートしていないという警告が表示されます。Systems Manager のパッチペイロードスクリプトは、SNI をサポートする AWS APIに接続する際に、この警告を出します。 **解決策**: このメッセージが報告されたときにパッチ適用の失敗をトラブルシューティングするには、`stdout` および `stderr` ファイルの内容を確認する。これらのファイルを S3 バケットまたは Amazon CloudWatch Logs に保存するようにパッチベースラインを設定していない場合は、Linux マネージドノードの次の場所にファイルを配置することができます。 `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux` ### 問題: Patch Manager が「試行するミラーはもうありません」と報告する **問題**: パッチ適用操作が、次のメッセージを発行する。 ``` [Errno 256] No more mirrors to try. ``` **原因**: マネージドノードに設定されているリポジトリーが正しく動作していません。エラーの原因として以下が考えられます。 + `yum` キャッシュが破損している。 + ネットワーク関連の問題により、リポジトリ URL にアクセスできない。 **解決策**: Patch Manager は、マネージドノードのデフォルトのパッケージマネージャーを使用してパッチ適用オペレーションを実行します。リポジトリーが正しく構成され、動作していることを確認します。 ### 問題: 「curl から返されたエラーコードは 23 です」というメッセージが表示されてパッチが失敗する **問題**: `AWS-RunPatchBaseline` を使用するパッチオペレーションに失敗すると、次のようなエラーが発生することがあります。 ``` 05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23 ``` **原因**: システムで使用している curl ツールには、ファイルシステムへの書き込みに必要な権限がありません。これは、パッケージマネージャーのデフォルトの curl ツールが、snap でインストールされたものなど、別のバージョンに置き換えられた場合に発生する可能性があります。 **解決方法**: 別のバージョンがインストールされたときにパッケージマネージャーから提供された curl バージョンがアンインストールされた場合は、再インストールします。 複数の curl バージョンをインストールしたままにしておく必要がある場合は、パッケージマネージャーに関連付けられているバージョンが、`PATH` 変数にリストされている最初のディレクトリにあることを確認してください。これを確認するには、`echo $PATH` コマンドを実行して、システム上の実行ファイルがチェックされているディレクトリの現在の順序を確認します。 ### 問題: パッチ適用が失敗し、「Error unpacking rpm package…」(rmp パッケージの解凍中にエラーが発生しました...) というメッセージが表示される **問題**: パッチ適用操作が次のようなエラーで失敗します。 ``` Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not! failed to run commands: exit status 1 ``` **原因 1**: 特定のパッケージが複数のパッケージインストーラー (両方など) に存在する場合、`pip` と `yum` の両方、または `dnf` など、デフォルトのパッケージマネージャーを使用したときにコンフリクトが発生する可能性があります。 `urllib3` パッケージで発生することが多く、`pip`、`yum`、`dnf` などに見られます。 **原因 2**: `python-urllib3` パッケージが壊れています。これは、`yum` または `dnf` によって `rpm` パッケージが前もってインストールされたあと、`pip` によってパッケージファイルがインストールまたは更新された場合に発生することがあります。 **解決策**: コマンド `sudo pip uninstall urllib3` を実行し、デフォルトのパッケージマネージャー (`yum` または `dnf`) にのみ、パッケージを保持することで、pip から `python-urllib3` パッケージを削除します。 ### 問題: パッチ適用が失敗し、「Encounter service side error when uploading the inventory」と表示される **問題**: `AWS-RunPatchBaseline` ドキュメントを実行すると、次のエラーメッセージが表示されます。 ``` Encounter service side error when uploading the inventory ``` **原因**: `AWS-RunPatchBaseline` を実行する 2 つのコマンドが同じマネージドノード上で同時に実行されています。これにより、パッチ適用オペレーション中に boto3 クライアントを初期化するときに競合状態が生じています。 **解決策**: State Manager の関連付けやメンテナンスウィンドウタスクなど、スケジュールに従って `AWS-RunPatchBaseline` を実行する設定が、同じ時間帯に同じマネージドノードをターゲットにしないようにします。 ### 問題:「Errors were encountered while downloading packages」(パッケージのダウンロード中にエラーが発生しました) というメッセージが表示されてパッチ適用が失敗する **問題**: パッチ適用中に、次のようなエラーが表示されます。 ``` YumDownloadError: [u'Errors were encountered while downloading packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12] Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5] [Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64: [Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64: [Errno 5] [Errno 12] Cannot allocate memory', ``` **原因**: このエラーは、マネージドノードで利用可能なメモリが不足している場合に発生する可能性があります。 **解決策**: スワップメモリを設定するか、インスタンスを別のタイプにアップグレードしてメモリサポートを増やします。その後、新しいパッチ適用操作を開始します。 ### 問題: パッチ適用がメモリ不足 (OOM) エラーで失敗する **問題**: `AWS-RunPatchBaseline` を実行すると、マネージドノードのメモリ不足のためにパッチ適用オペレーションが失敗します。`Cannot allocate memory`、`Killed` (Linux OOM キラーから) などのエラーが表示されるか、オペレーションが予期せず失敗することがあります。このエラーは、RAM が 1 GB 未満のインスタンスで発生する可能性が高くなりますが、多数の更新が利用可能になると、より多くのメモリを持つインスタンスにも影響する可能性があります。 **原因**: Patch Manager は、マネージドノードのネイティブパッケージマネージャーを使用してパッチ適用オペレーションを実行します。パッチ適用オペレーションに必要なメモリは、次のようないくつかの要因によって異なります。 + マネージドノードにインストールされ、利用可能な更新プログラムの数。 + 使用中のパッケージマネージャーとそのメモリ特性。 + パッチ適用オペレーション時にマネージドノードで実行されているその他のプロセス。 多数のインストール済みパッケージまたは多数の利用可能な更新を含むマネージドノードは、パッチ適用オペレーション中により多くのメモリを必要とします。使用可能なメモリが不足している場合、パッチ適用プロセスは失敗し、エラーで終了します。オペレーティングシステムはパッチ適用プロセスを終了することもできます。 **解決策**: 次のうち 1 つまたは複数を試してください。 + メンテナンスウィンドウを使用するなど、マネージドノードのワークロードアクティビティが少ない期間にパッチ適用オペレーションをスケジュールする。 + インスタンスをより多くのメモリを持つタイプにアップグレードする。 + マネージドノードでスワップメモリを設定する。EBS スループットが制限されているインスタンスでは、スワップを大量に使用するとパフォーマンスが低下する可能性があることに注意してください。 + パッチ適用オペレーション中にマネージドノードで実行されているプロセスを確認し、数を減らします。 ### 問題:「The following signatures couldn't be verified because the public key is not available」(公開鍵が利用できないため、次の署名を検証できませんでした) というメッセージが表示されてパッチ適用が失敗します。 **問題**: Ubuntu Server を使用するパッチ適用に失敗すると、次のようなエラーが発生することがあります。 ``` 02/17/2022 21:08:43 root [ERROR]: W:GPG error: http://repo.mysql.com/apt/ubuntu bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic ``` **原因:**: GNU Privacy Guard (GPG) キーの有効期限が切れているか、キーがありません。 **解決策**: GPG キーを更新するか、キーをもう一度追加してください。 例えば、前に示したエラーを見ると、`467B942D3A79BD29` キーがないため、追加する必要があります。そのためには、次のコマンドのいずれかを実行します。 ``` sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29 ``` ``` sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29 ``` または、すべてのキーを更新するには、以下のコマンドを実行します。 ``` sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys ``` この後もエラーが再発する場合は、リポジトリを管理している組織に問題を報告することをおすすめします。修正が利用できるようになるまでは、パッチ処理中にリポジトリを省略するため `/etc/apt/sources.list` ファイルを編集できます。 そのためには、`sources.list` を編集用に開き、リポジトリの行を見つけて、その行の先頭にコメントアウトする `#` 文字を挿入します。ファイルを保存してから閉じます。 ### 問題:「NoMoreMirrorsRepoError」というメッセージが表示されてパッチ適用が失敗します。 **問題**: 次のようなエラーが表示されます。 ``` NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try. ``` **原因**: ソースリポジトリにエラーがあります。 **解決策**: リポジトリを管理している組織に問題を報告することをおすすめします。エラーが修正されるまでは、オペレーティングシステムレベルでリポジトリを無効にできます。そのためには、以下のコマンドを実行します。*repo-name* の値を次のリポジトリ名で置き換えます。 ``` yum-config-manager --disable repo-name ``` 次に例を示します。 ``` yum-config-manager --disable pgdg94 ``` このコマンドを実行した後、別のパッチ適用操作を実行します。 ### 問題: 「Unable to download payload」(ペイロードをダウンロードできません) というメッセージが表示されてパッチ適用が失敗します。 **問題**: 次のようなエラーが表示されます。 ``` Unable to download payload: https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz. failed to run commands: exit status 156 ``` **原因**: マネージドノードの設定にエラーがあるか、不完全です。 **解決策**: マネージドノードが次のように設定されていることを確認します。 + セキュリティグループのアウトバウンド TCP 443 ルール。 + NACL のエグレス TCP 443 ルール。 + NACL のイングレス TCP 1024-65535 ルール。 + S3 エンドポイントへの接続を提供するルートテーブル内の NAT/IGW。インスタンスがインターネットにアクセスできない場合は、S3 エンドポイントとの接続を確立します。そのためには、VPC に S3 ゲートウェイエンドポイントを追加し、マネージドノードのルートテーブルと統合します。 ### 問題:「install errors: dpkg: error: dpkg frontend is locked by another process」(インストールエラー:dpkg: エラー:dpkg フロントエンドが別のプロセスによってロックされています) というメッセージが表示されてパッチ適用が失敗します。 **問題**: 次のようなエラーが発生してパッチ適用が失敗することがあります。 ``` install errors: dpkg: error: dpkg frontend is locked by another process failed to run commands: exit status 2 Failed to install package; install status Failed ``` **原因**: パッケージマネージャーは、オペレーティングシステムレベルのマネージドノード上で既に別のプロセスを実行しています。他のプロセスが完了するまでに長い時間がかかる場合は、Patch Manager パッチ適用操作はタイムアウトして失敗することがあります。 **解決策**: パッケージマネージャーを使用している他のプロセスが完了したら、新しいパッチ適用操作を実行します。 ### 問題: Ubuntu Server へのパッチ適用が「dpkg was interrupted」(dpkg が中断されました) というエラーで失敗します。 **問題**: Ubuntu Server では、次のようなエラーで、パッチ適用が失敗します。 ``` E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. ``` **原因**: 1 つまたは複数のパッケージの設定が間違っています。 **解決方法**: 以下のステップを実行します。 1. 以下のコマンドを 1 つずつ実行して、どのパッケージが影響を受けるか、また各パッケージの問題点を確認してください。 ``` sudo apt-get check ``` ``` sudo dpkg -C ``` ``` dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci] ``` 1. 以下のコマンドを実行して、問題のあるパッケージを修正します。 ``` sudo dpkg --configure -a ``` 1. 前のコマンドで問題が完全に解決されなかった場合は、以下のコマンドを実行します。 ``` sudo apt --fix-broken install ``` ### 問題: パッケージマネージャーユーティリティがパッケージの依存関係を解決できません。 **問題**: マネージドノード上のネイティブパッケージマネージャーがパッケージの依存関係を解決できず、パッチ適用が失敗します。以下のエラーメッセージ例は、パッケージマネージャーとして `yum` を使用するオペレーティングシステムでのこのタイプの問題を示しています。 ``` 09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1, message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3', u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31'] ``` **原因**: Linux オペレーティングシステムでは、Patch Manager はマシン上のネイティブパッケージマネージャを使用して、`yum`、`dnf`、`apt`、`zypper` のようなパッチ操作を実行します。アプリケーションは、必要に応じて依存パッケージを自動的に検出、インストール、更新、または削除します。ただし、次のような状況によっては、パッケージマネージャーが依存関係の操作を完了できなくなる場合があります。 + オペレーティングシステムには複数の競合するリポジトリが設定されています。 + ネットワーク関連の問題により、リモートリポジトリの URL にアクセスできません。 + 間違ったアーキテクチャのパッケージがリポジトリで見つかりました。 **解決策**: さまざまな理由の依存性の問題で、パッチ適用が失敗する可能性があります。そのため、トラブルシューティングの支援を受けるには、AWS サポート にお問い合わせください。 ### 問題: SLES マネージドノードで Zypper パッケージロックの依存関係に失敗する **問題**: SUSE Linux Enterprise Server インスタンスで `AWS-RunPatchBaseline` を `Install` オペレーションで実行すると、パッチ適用が失敗し、パッケージロックに関連する依存関係チェックのエラーが発生する。次のようなエラーメッセージが表示される。 ``` Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo] Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo] Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c] (c): c ``` この例では、パッケージ `mock-pkg-standalone` がロックされています。これは、`sudo zypper locks` を実行し、出力でこのパッケージ名を探すことにより確認できます。 また、依存関係チェックの失敗を示すログエントリが表示されることもあります。 ``` Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4') ``` **注記** この問題は `Install` オペレーション中にのみ発生します。`Scan` オペレーションはパッケージロックを適用せず、既存のロックの影響を受けません。 **原因**: このエラーは、依存関係の競合が原因で、zypper パッケージロックによりパッケージのインストールまたは更新が妨げられた場合に発生します。パッケージロックが発生する理由は複数あります。 + **お客様がロックを使用した**: ユーザーまたはシステム管理者が、`zypper addlock` などの zypper コマンドを使用してパッケージを手動でロックした。 + **Patch Manager がパッチを拒否した**: パッチベースラインの**拒否されたパッチ**リストでパッケージを指定すると、Patch Manager が自動的にパッケージロックを適用し、インストールが中断します。 + **中断されたオペレーションの残りのロック**: まれに、Patch Manager が一時的なロックをクリーンアップする前に、パッチオペレーションが (システムの再起動などにより) 中断された場合、残りのパッケージロックがマネージドノードに残ることがあります。 **解決方法**: zypper パッケージロックの問題を解決するには、原因に応じて次の手順を実行します。 **ステップ 1: ロックされたパッケージを特定する** SLES マネージドノードに接続し、次のコマンドを実行して、現在ロックされているすべてのパッケージをすべて表示します。 ``` sudo zypper locks ``` **ステップ 2: ロックの原因を特定する** + ロックされたパッケージが、システムの安定性のために故意にロックされている場合は、ロック状態を維持する必要があるか、またはパッチ適用のために一時的にロックを解除できるか検討します。 + ロックされたパッケージがパッチベースラインの**拒否されたパッチ**リストのエントリと一致する場合、これらは、中断したパッチオペレーションの残りのロックである可能性があります。通常のオペレーション中、Patch Manager はこれらのロックを一時的に適用し、オペレーションが完了すると自動的に解除します。拒否されたパッチのリストからパッケージを削除するか、パッチベースラインのルールを変更します。 + ロックされたパッケージが認識されておらず、ロックが故意ではない場合は、以前に中断したパッチオペレーションの残りのロックである可能性があります。 **ステップ 3: 必要に応じてロックを解除する** 特定のパッケージロックを解除するには、次のコマンドを実行します。 ``` sudo zypper removelock package-name ``` すべてのパッケージロックを解除するには (注意が必要)、以下を実行します。 ``` sudo zypper cleanlocks ``` **ステップ 4: パッチベースラインを更新する (該当する場合)** ロックの原因がパッチベースラインで拒否されたパッチだった場合 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Patch Manager]** を選択します。 1. **[パッチベースライン]** タブを選択し、カスタムパッチベースラインを選択します。 1. **[アクション]**、**[パッチベースラインの変更]** を選択します。 1. **[拒否されたパッチ]** のセクションで、表示されているパッケージを確認し、インストールを許可するパッケージをすべて削除します。 1. **[Save changes]** (変更の保存) をクリックします。 **ステップ 5: パッチオペレーションを再試行する** 問題のあるロックを解除して、必要に応じてパッチベースラインを更新したら、`AWS-RunPatchBaseline` ドキュメントを再度実行します。 **注記** Patch Manager が、`Install` オペレーション中に、拒否されたパッチにロックを適用すると、パッチオペレーションの完了後、これらのロックは自動的にクリーンアップされます。`sudo zypper locks` の実行時にこれらのロックが表示された場合は、以前のパッチオペレーションが、クリーンアップが行われる前に中断されたことを意味します。ただし、パッチオペレーションが中断された場合、本手順で説明しているように、手動でのクリーンアップが必要になる可能性があります。 **回避策**: zypper ロックの競合を未然に防ぐには + パッチベースラインの拒否されたパッチのリストを注意深く確認し、除外すべきパッケージのみが含まれていることを確認します。 + セキュリティ更新の依存関係として必要になる可能性があるパッケージを、手動でロックすることはおやめください。 + パッケージを手動でロックする必要がある場合は、理由を記録に残し、定期的にロックを確認します。 + パッチオペレーションが正常に完了し、システムの再起動やその他の要因によって中断されないことを確認します。 + パッチオペレーションを完了までモニタリングし、システムの再起動や、一時ロックの適切なクリーンアップを妨げるその他アクションによって中断されることのないようにします。 ### 問題:ロックを取得できません。別のパッチ適用オペレーショが進行中です。 **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用がエラーコード 4 で失敗し、以下のエラーメッセージが表示されます。 ``` [ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress. ``` **原因**: このエラーは、複数のパッチ適用操作が同時に同じ管理対象ノード上で実行されようとした場合に発生します。ロックファイルは競合を回避しシステムの安定性を確保するため、同時並行でのパッチ適用操作を防止します。 **解決策**: パッチ適用オペレーションが、同一の管理対象ノード上で同時に実行されるようにスケジュールされないことを確認してください。以下の設定を確認し、スケジューリングの競合を特定して解決してください。 + **パッチポリシー**: Quick Setup のパッチ適用ポリシー設定を確認し、他のパッチ適用スケジュールと重複していないことを確認してください。 + **メンテナンスウィンドウ**: メンテナンスウィンドウの関連付けを確認し、複数のウィンドウが重複する時間帯に同じ管理対象ノードに対してパッチ適用タスクを実行していないことを確認してください。 + **手動パッチ適用オペレーション**: スケジュールされたパッチ適用が進行中の間は、手動による**「今すぐパッチを適用」**オペレーショを開始しないでください。 ## Windows Server で `AWS-RunPatchBaseline` 実行時のエラー **Topics** + [問題:製品ファミリ/製品ペアの不一致](#patch-manager-troubleshooting-product-family-mismatch) + [問題:`AWS-RunPatchBaseline` 出力が `HRESULT` ( Windows Server )を返す。](#patch-manager-troubleshooting-hresult) + [問題: マネージドノードに Windows Update カタログまたは WSUS へのアクセスがない](#patch-manager-troubleshooting-instance-access) + [問題:パッチベースラインオペレーション PowerShell モジュールがダウンロードできない](#patch-manager-troubleshooting-module-not-downloadable) + [問題: パッチが見つからない](#patch-manager-troubleshooting-missing-patches) + [問題: ロックを取得できません。別のパッチ適用オペレーショが進行中です。](#patch-manager-troubleshooting-windows-concurrent-lock) ### 問題:製品ファミリ/製品ペアの不一致 **問題**: Systems Managerコンソールでパッチベースラインを作成するとき、製品ファミリーと製品を指定します。例えば、以下のように選択します。 + **Product family (製品ファミリー**)`Office`]: **Product (製品**)`Office 2016`]: **原因**: 一致していない製品ファミリー/製品ペアでパッチベースラインを作成しようとすると、エラーメッセージが表示されます。以下の理由で、これが発生する場合があります。 + 有効な製品ファミリーと製品ペアが選択されましたが、その後、製品ファミリーの選択が削除されました。 + [**Available and matching options (利用可能なマッチングオプション)**] サブリストからではなく、[**Obsolete or mismatched options (サポートされなくなった、または不一致のオプション)**] サブリストから製品が選択されました。 製品の [**Obsolete or mismatched options** (サポートされなくなった、または不一致のオプション)] サブリストの項目が、SDK または AWS Command Line Interface(AWS CLI) `create-patch-baseline` コマンドにより誤って入力された可能性があります。これは、タイプミスがあったか、製品が間違った製品ファミリーに割り当てられたことを意味します。以前のパッチベースラインに指定されても、 Microsoft から入手可能なパッチがない場合、その製品は、[**Obsolete or mismatched options** (サポートされなくなった、または不一致のオプション)] サブリストにも含まれます。 **解決策**: この問題を回避するには、[**Currently available options (現在利用可能なオプション)**] サブリストから常にオプションを選択します。 AWS CLI の `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` コマンド、または `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` API コマンドを使用して、利用可能なパッチのある製品を表示することもできます。 ### 問題:`AWS-RunPatchBaseline` 出力が `HRESULT` ( Windows Server )を返す。 **問題:** 次のようなエラーが発生しました。 ``` ----------ERROR------- Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update. Exception Level 1: Error Message: Exception from HRESULT: 0x80240437 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria).. (Windows updates) 11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates. 11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437 ----------ERROR------- failed to run commands: exit status 4294967295 ``` **原因**: この出力は、ネイティブの Windows Update API がパッチ適用操作を実行できなかったことを示します。 **解決策**: エラーを解決するためのトラブルシューティング手順を特定するには、次の microsoft.com トピックの `HResult` コードを確認します。 + [コンポーネント別の Windows Update エラー コード](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference) + [Windows Update の一般的なエラーと軽減策](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors) ### 問題: マネージドノードに Windows Update カタログまたは WSUS へのアクセスがない **問題:** 次のようなエラーが発生しました。 ``` Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip. Extracting PatchBaselineOperations zip file contents to temporary folder. Verifying SHA 256 of the PatchBaselineOperations PowerShell module files. Successfully downloaded and installed the PatchBaselineOperations PowerShell module. Patch Summary for PatchGroup : BaselineId : Baseline : null SnapshotId : RebootOption : RebootIfNeeded OwnerInformation : OperationType : Scan OperationStartTime : 1970-01-01T00:00:00.0000000Z OperationEndTime : 1970-01-01T00:00:00.0000000Z InstalledCount : -1 InstalledRejectedCount : -1 InstalledPendingRebootCount : -1 InstalledOtherCount : -1 FailedCount : -1 MissingCount : -1 NotApplicableCount : -1 UnreportedNotApplicableCount : -1 EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169 ----------ERROR------- Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update. Exception Level 1: Error Message: Exception from HRESULT: 0x80072EE2 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria) at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searchCriteria) At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58 e3\PatchWindows\_script.ps1:230 char:13 + $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv oke-PatchBaselineOperation], Exception + FullyQualifiedErrorId : Exception Level 1: Error Message: Exception Details: An error occurred when attempting to search Windows Update. Exception Level 1: Error Message: Exception from HRESULT: 0x80072EE2 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria) at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc ---Error truncated---- ``` **原因**: このエラーは、Windows Update コンポーネント、または Windows Update カタログもしくは Windows Server Update Services (WSUS) への接続の欠如にまつわる可能性があります。 **解決策**: マネージドノードがインターネットゲートウェイ、NAT ゲートウェイ、または NAT インスタンスを介して [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) に接続されていることを確認します。WSUS を使用している場合は、マネージドノードがお使いの環境内の WSUS サーバーに接続されていることを確認します。目的の送信先への接続が確立されている場合は、Microsoft のドキュメントで考えられる他の `HResult 0x80072EE2` の原因を確認してください。これは、オペレーティングシステムレベルに問題があることを示している可能性があります。 ### 問題:パッチベースラインオペレーション PowerShell モジュールがダウンロードできない **問題:** 次のようなエラーが発生しました。 ``` Preparing to download PatchBaselineOperations PowerShell module from S3. Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip. ----------ERROR------- C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\ PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1 failed to run commands: exit status 4294967295 ``` **解決策**: Amazon Simple Storage Service (Amazon S3) へのマネージドノードの接続とアクセス許可を確認します。マネージドノードの AWS Identity and Access Management (IAM) ロールに使用するのは、「[SSM Agent と AWS マネージド S3 バケットとの通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)」に挙げた最小限の許可である必要があります。ノードは、Amazon S3 ゲートウェイエンドポイント、NAT ゲートウェイ、またはインターネットゲートウェイを介して Amazon S3 エンドポイントと通信する必要があります。AWS Systems Manager SSM Agent (SSM Agent) の VPC エンドポイント要件の詳細については、「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](setup-create-vpc.md)」を参照してください。 ### 問題: パッチが見つからない **問題**: `AWS-RunPatchbaseline` は正常に完了しましたが、一部のパッチが見つからない。 一般的な原因とその解決策を以下に示します。 **原因 1**: ベースラインが有効ではありません。 **解決策 1**: これが原因かどうかを確認するには、以下の手順を実行します。 1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。 1. ナビゲーションペインで、**[Run Command]** を選択します。 1. [**Command history (コマンド履歴)**] タブをクリックし、ベースラインをチェックするコマンドを選択します。 1. パッチがないマネージドノードを選択します。 1. [**Step 1 - Output (ステップ 1 - 出力)**] を選択し、`BaselineId` 値を見つけます。 1. 割り当てられた[パッチベースライン設定](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)、つまり、パッチベースラインのオペレーティングシステム、製品名、分類、および重大度を確認します。 1. [[Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx)] に移動します。 1. Microsoft Knowledge Base (KB) の記事 ID (KB3216916 など) を検索します。 1. **[Product]** (成果) の値がマネージドノードの値と一致することを確認し、対応する **[Title]** (タイトル) を選択します。新しい [**Update Details (詳細を更新)**] ウィンドウが開きます。 1. [**Overview (概要)**] タブで、[**classification (分類)**]と [**MSRC severity (MSRC の重大度)**]は、前に見つけたパッチベースライン設定と一致する必要があります。 **原因 2**: パッチが置き換えられました。 **解決策 2**: これが本当かどうかを確認するには、以下の手順を実行します。 1. [[Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx)] に移動します。 1. Microsoft Knowledge Base (KB) の記事 ID (KB3216916 など) を検索します。 1. **[Product]** (成果) の値がマネージドノードの値と一致することを確認し、対応する **[Title]** (タイトル) を選択します。新しい [**Update Details (詳細を更新)**] ウィンドウが開きます。 1. [**Package Details (パッケージの詳細)**] タブに移動します。[**This update has been replaced by the following updates: (この更新は次の更新に置き換えられました:)**] ヘッダーの下でエントリを探します。 **原因 3**: WSUS と Window のオンライン更新プログラムは、Microsoft によって独立したリリースチャネルとして処理されるため、同じ修正プログラムの KB 番号が異なる可能性があります。 **解決策 3**: パッチの適格性を確認します。パッケージが WSUS で利用できない場合は、[OS Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57) をインストールします。パッケージがすべてのオペレーティングシステムビルドで利用できる場合は、[OS Build 18362.1256 および 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9) をインストールします。 ### 問題: ロックを取得できません。別のパッチ適用オペレーショが進行中です。 **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用がエラーコード 4 で失敗し、以下のエラーメッセージが表示されます。 ``` Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress. ``` **原因**: このエラーは、複数のパッチ適用操作が同時に同じ管理対象ノード上で実行されようとした場合に発生します。ロックファイルは競合を回避しシステムの安定性を確保するため、同時並行でのパッチ適用操作を防止します。 **解決策**: パッチ適用オペレーションが、同一の管理対象ノード上で同時に実行されるようにスケジュールされないことを確認してください。以下の設定を確認し、スケジューリングの競合を特定して解決してください。 + **パッチポリシー**: Quick Setup のパッチ適用ポリシー設定を確認し、他のパッチ適用スケジュールと重複していないことを確認してください。 + **メンテナンスウィンドウ**: メンテナンスウィンドウの関連付けを確認し、複数のウィンドウが重複する時間帯に同じ管理対象ノードに対してパッチ適用タスクを実行していないことを確認してください。 + **手動パッチ適用オペレーション**: スケジュールされたパッチ適用が進行中の間は、手動による**「今すぐパッチを適用」**オペレーショを開始しないでください。 ## macOS で `AWS-RunPatchBaseline` を実行する際のエラー **Topics** + [問題: ロックを取得できません。別のパッチ適用オペレーショが進行中です。](#patch-manager-troubleshooting-macos-concurrent-lock) ### 問題: ロックを取得できません。別のパッチ適用オペレーショが進行中です。 **問題**: `AWS-RunPatchBaseline` を実行すると、パッチ適用がエラーコード 4 で失敗し、以下のエラーメッセージが表示されます。 ``` [ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress. ``` **原因**: このエラーは、複数のパッチ適用操作が同時に同じ管理対象ノード上で実行されようとした場合に発生します。ロックファイルは競合を回避しシステムの安定性を確保するため、同時並行でのパッチ適用操作を防止します。 **解決策**: パッチ適用オペレーションが、同一の管理対象ノード上で同時に実行されるようにスケジュールされないことを確認してください。以下の設定を確認し、スケジューリングの競合を特定して解決してください。 + **パッチポリシー**: Quick Setup のパッチ適用ポリシー設定を確認し、他のパッチ適用スケジュールと重複していないことを確認してください。 + **メンテナンスウィンドウ**: メンテナンスウィンドウの関連付けを確認し、複数のウィンドウが重複する時間帯に同じ管理対象ノードに対してパッチ適用タスクを実行していないことを確認してください。 + **手動パッチ適用オペレーション**: スケジュールされたパッチ適用が進行中の間は、手動による**「今すぐパッチを適用」**オペレーショを開始しないでください。 ## AWS サポート Automation ランブックの使用方法 AWS サポートには、パッチ適用に関連する特定の問題のトラブルシューティングに使用できる、2 つの Automation ランブックが用意されています。 + `AWSSupport-TroubleshootWindowsUpdate` – [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) ランブックは、Amazon Elastic Compute Cloud (Amazon EC2) Windows Server インスタンスの、Windows Server 更新の失敗につながる可能性のある問題を特定するために使用します。 + `AWSSupport-TroubleshootPatchManagerLinux` – [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) ランブックは、Patch Manager を使用して、Linux ベースのマネージドノードでパッチ障害を引き起こす一般的な問題をトラブルシューティングします。このランブックの主な目的は、パッチコマンドが失敗する根本原因を見きわめ、修復プランを提案することにあります。 **注記** Automation ランブックの実行には料金がかかります。詳細については、「[AWS Systems Manager の料金」の「オートメーション](https://aws.amazon.com/systems-manager/pricing/#Automation)」を参照してください。 ## AWS サポートに連絡する トラブルシューティングの解決策がこのセクションまたは [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager)での Systems Manager問題で見つからない、そして[開発者、ビジネス、またはエンタープライズ サポート プラン](https://aws.amazon.com/premiumsupport/plans)がある場合は、[AWS サポート](https://aws.amazon.com/premiumsupport/) で技術サポートケースを作成できます。 サポート に連絡する前に、以下の情報を収集します。 + [SSM Agent ログ](ssm-agent-logs.md) + Run Command コマンド ID、メンテナンスウィンドウ ID、またはオートメーション実行 ID + Windows Server マネージドノードの場合では、以下も収集します。 + [パッチのインストール方法](patch-manager-installing-patches.md) の** Windows** タブで説明されている `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` + Windows の更新ログ:Windows Server 2012 R2 以前の場合、`%windir%/WindowsUpdate.log` を使用してください。Windows Server 2016 以降の場合は、`%windir%/WindowsUpdate.log` を使用する前にまず PowerShell コマンド [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps) を実行します + Linux マネージドノードの場合では、以下も収集します。 + `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux` ディレクトリの内容。