• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。 # 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**] を選択します。