• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# コンソールを使用した Patch Manager リソースとコンプライアンスの操作
AWS Systems Manager のツールである Patch Manager を使用するには、以下のタスクを実行します。各タスクについては、このセクションで詳しく説明します。
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)