• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# カスタムパッチベースラインの操作
AWS Systems Manager のツールである Patch Manager には、Patch Manager でサポートされるオペレーティングシステムごとに事前定義されたパッチベースラインが含まれています。これらのパッチベースライン (カスタマイズはできません) を使用するか、独自のパッチベースラインを作成できます。
次の手順では、独自のカスタムパッチベースラインを作成、更新、および削除する方法について説明します。パッチベースラインの詳細については、「[事前定義されたパッチベースラインおよびカスタムパッチベースライン](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)」を参照してください。