• 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 は、パッケージリポジトリで廃止とマークされたパッケージを、別のパッケージ更新のインストールでこの置換が必要な場合を除き、別の名前の置換パッケージに置き換えません。代わりに、パッケージを更新するコマンドの場合、Patch Manager はインストールされているが古いパッケージの欠落した更新のみを通知してインストールします。これは、古いパッケージを置き換えるには、通常、既存のパッケージをアンインストールし、改めて新しいパッケージをインストールする必要があるためです。古いパッケージを置き換えると、意図していない重大な変更や追加機能が発生する可能性があります。 この動作は、機能のアップグレードではなくセキュリティ更新に焦点を当てた YUM および DNF の `update-minimal` コマンドと一致しています。詳細については、「[パッチのインストール方法](patch-manager-installing-patches.md)」を参照してください。 **注記** パッチベースラインルールで `ApproveUntilDate` パラメータまたは `ApproveAfterDays` パラメータを使用すると、Patch Manager は協定世界時 (UTC) を使用してパッチリリース日を評価します。 例えば、`ApproveUntilDate` の場合、`2025-11-16` などの日付を指定すると、`2025-11-16T00:00:00Z` と `2025-11-16T23:59:59Z` の間にリリースされたパッチが承認されます。 マネージドノードのネイティブパッケージマネージャーによって表示されるパッチリリース日は、システムのローカルタイムゾーンに基づいて異なる時間が表示される場合がありますが、Patch Manager は承認の計算で常に UTC 日時を使用することに注意してください。これにより、公式のセキュリティアドバイザリウェブサイトで公開されているパッチリリース日との一貫性が確保されます。 パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS ([共通脆弱性評価システム](https://www.first.org/cvss/)) のような サードパーティのソースからの、または NVD ([National Vulnerability Database](https://nvd.nist.gov/vuln)) がリリースしたメトリクスからの重要度レベルは取得しません。 **注記** Patch Manager でサポートされているすべての Linux ベースのシステムでは、セキュリティに関連しない更新プログラムをインストールしたりするために、マネージドノードに別のソースリポジトリを選択することができます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。 以下の各タブを選択して、お使いのオペレーティングシステムで Patch Manager がセキュリティ関連のパッチを選択する方法を確認してください。 ------ #### [ Amazon Linux 2 and Amazon Linux 2023 ] Amazon Linux 2 および Amazon Linux 2023 では、事前設定されたリポジトリの処理とは異なります。 Amazon Linux 2 では、Systems Manager のパッチベースラインサービスは、マネージドノード上の事前設定されたリポジトリを使用します。通常、ノードには 2 つの設定済みリポジトリ (リポウズ) があります。 **Amazon Linux 2 上** + **リポ ID**: `amzn2-core/2/{{architecture}}` **リポ名**: `Amazon Linux 2 core repository` + **リポ ID**: `amzn2extra-docker/2/{{architecture}}` **リポ名**: `Amazon Extras repo for docker` **注記** {{architecture}} は、x86\_64 または (Graviton プロセッサの場合は) aarch64 にすることができます。 Amazon Linux 2023 (AL2023) インスタンスを作成すると、AL2023 のバージョンで利用可能な更新と、選択した特定の AMI の更新が含まれます。AL2023 インスタンスは起動時に追加のクリティカルかつ重要なセキュリティアップデートを自動的に受信しません。代わりに、デフォルトで有効になっている AL2023 の*バージョン対応リポジトリによる確定的なアップグレード機能*を使用すると、特定のニーズを満たすスケジュールに基づいて更新を適用できます。詳細については、「Amazon Linux 2023 ユーザーガイド」の「[バージョン対応リポジトリによる確定的なアップグレード](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)」を参照してください。 AL2023 では、事前設定されたリポジトリは次のとおりです。 + **リポ ID**: `amazonlinux` **リポジトリ名**: Amazon Linux 2023 リポジトリ Amazon Linux 2023 (プレビューリリース) では、事前設定されたリポジトリは*ロックされたバージョン*のパッケージ更新に関連付けられています。AL2023 用の新規 Amazon Machine Images (AMIs) がリリースされると、特定のバージョンにロックされます。パッチ更新では、Patch Manager は、パッチ更新リポジトリの最新のロックバージョンを取得し、そのロックされたバージョンの内容に基づいてマネージド ノード上のパッケージを更新します。 **パッケージマネージャー** Amazon Linux 2 マネージドノードではパッケージマネージャーとして Yum が使用されます。Amazon Linux 2023 ではパッケージマネージャーとして DNF が使用されます。 どちらのパッケージマネージャーでも、`updateinfo.xml` という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。更新通知に含まれているすべてのパッケージは、Patch Manager ではセキュリティ関連とみなされます。個々のパッケージには分類や重要度は割り当てられません。そのため、Patch Manager は関連するパッケージに更新通知の属性を割り当てます。 **注記** **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。 **セキュリティ以外の更新を含める**オプションの詳細については、「[パッチのインストール方法](patch-manager-installing-patches.md)」および「[Linux ベースシステムでのパッチベースラインルールの動作方法](patch-manager-linux-rules.md)」を参照してください。 ------ #### [ CentOS Stream ] CentOS Stream の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。以下のリストは、架空の CentOS 9.2 Amazon Machine Image (AMI) の例を示します。 + **リポ ID**: `example-centos-9.2-base` **リポ名**: `Example CentOS-9.2 - Base` + **リポ ID**: `example-centos-9.2-extras` **リポ名**: `Example CentOS-9.2 - Extras` + **リポ ID**: `example-centos-9.2-updates` **リポ名**: `Example CentOS-9.2 - Updates` + **リポ ID**: `example-centos-9.x-examplerepo` **リポ名**: `Example CentOS-9.x – Example Repo Packages` **注記** すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。 CentOS Stream のノードではパッケージマネージャーとして DNF が使用されます。パッケージマネージャーでは、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。 ただし、CentOS Stream のデフォルトリポジトリは更新通知で設定されません。これは、Patch Manager で CentOS Stream のデフォルトリポジトリのパッケージが検出されないことを意味します。Patch Manager を許可して更新通知に含まれていないパッケージを処理するには、パッチベースラインルールで `EnableNonSecurity` フラグを有効にする必要があります。 **注記** CentOS Stream の更新通知がサポートされています。更新通知のあるリポは起動後にダウンロードできます。 ------ #### [ Debian サーバー ] Debian Server の場合、Systems Manager パッチベースラインサービスはインスタンスの事前設定済みのリポジトリ (リポ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、`sudo apt-get update` コマンドと同等のコマンドを実行します。 その後、パッケージは `debian-security {{codename}}` リポからフィルタリングされます。つまり、Debian Server の各バージョンでは、次のように、Patch Manager は、そのバージョンの関連リポジトリに含まれるアップグレードのみを識別します。 + Debian Server 11: `debian-security bullseye` + Debian Server 12: `debian-security bookworm` ------ #### [ Oracle Linux ] Oracle Linux の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。通常、ノードには 2 つの設定済みリポウズがあります。 **Oracle Linux 7**: + **リポ ID**: `ol7_UEKR5/x86_64` **リポ名**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)` + **リポ ID**: `ol7_latest/x86_64` **リポ名**: `Oracle Linux 7Server Latest (x86_64)` **Oracle Linux 8**: + **リポ ID**: `ol8_baseos_latest` **リポ名**: `Oracle Linux 8 BaseOS Latest (x86_64)` + **リポ ID**: `ol8_appstream` **リポ名**: `Oracle Linux 8 Application Stream (x86_64)` + **リポ ID**: `ol8_UEKR6` **リポ名**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)` **Oracle Linux 9**: + **リポ ID**: `ol9_baseos_latest` **リポ名**: `Oracle Linux 9 BaseOS Latest (x86_64)` + **リポ ID**: `ol9_appstream` **リポ名**: `Oracle Linux 9 Application Stream Packages(x86_64)` + **リポ ID**: `ol9_UEKR7` **リポ名**: `Oracle Linux UEK Release 7 (x86_64)` **注記** すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。 Oracle Linux マネージドノードではパッケージマネージャーとして Yum が使用されます。Yum では `updateinfo.xml` という名前のファイルとして、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。 **注記** **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。 ------ #### [ AlmaLinux, RHEL, and Rocky Linux ] AlmaLinux では、Red Hat Enterprise Linux および Rocky Linux では、Systems Manager のパッチベースラインサービスでマネージドノードの事前設定済みリポジトリ (リポウズ) が使用されます。通常、ノードには 3 つの設定済みリポウズがあります。 すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。 **注記** **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにすると、`updateinfo.xml` ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。 Red Hat Enterprise Linux 7 のマネージドノードではパッケージマネージャーとして Yum が使用されます。AlmaLinux、Red Hat Enterprise Linux 8、および Rocky Linux のマネージドノードではパッケージマネージャーとして DNF が使用されます。どちらのパッケージマネージャーでも、`updateinfo.xml` という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。 RHEL 7 以下のレポ ID は RHUI 2 に関連付けられています。RHUI 3 は 2019 年 12 月に開始され、Yum リポジトリ ID に異なる命名スキームを導入しました。マネージドノード作成元の RHEL-7 AMI によっては、コマンドを更新する必要がある場合があります。詳細については、Red Hat カスタマーポータルの「[AWS にある RHEL 7 のリポジトリ ID が既に変化した](https://access.redhat.com/articles/4599971)」を参照してください。 + **リポ ID**: `rhui-REGION-client-config-server-7/x86_64` **リポ名**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7` + **リポ ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64` **リポ名**: `Red Hat Enterprise Linux Server 7 (RPMs)` + **リポ ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64` **リポ名**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)` AlmaLinux、8 RHEL 8、および Rocky Linux 8 + **リポ ID**: `rhel-8-appstream-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)` + **リポ ID**: `rhel-8-baseos-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)` + **リポ ID**: `rhui-client-config-server-8` **リポ名**: `Red Hat Update Infrastructure 3 Client Configuration Server 8` AlmaLinux 9、 RHEL 9、および Rocky Linux 9 + **リポ ID**: `rhel-9-appstream-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)` + **リポ ID**: `rhel-9-baseos-rhui-rpms` **リポ名**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)` + **リポ ID**: `rhui-client-config-server-9` **リポ名**:`Red Hat Enterprise Linux 9 Client Configuration` ------ #### [ SLES ] SUSE Linux Enterprise Server (SLES) マネージドノードでは、ZYPP ライブラリは使用可能なパッチのリスト (パッケージの集合) を以下の場所から取得します。 + リポジトリのリスト: `etc/zypp/repos.d/*` + パッケージの情報: `/var/cache/zypp/raw/*` SLES マネージドノードはパッケージマネージャーとして Zypper を使用し、Zypper はパッチの概念を使用します。パッチは、特定の問題を修正するパッケージのコレクションです。Patch Manager は、パッチに含まれているすべてのパッケージをセキュリティ関連のパッケージとみなします。個々のパッケージには分類や重要度が与えられていないため、Patch Managerはパッケージにその属しているパッチの属性を割り当てます。 ------ #### [ Ubuntu Server ] Ubuntu Server の場合、Systems Manager パッチベースライン サービスはマネージドノードの事前設定済みのリポジトリ (リポウズ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、`sudo apt-get update` コマンドと同等のコマンドを実行します。 次に、パッケージを `{{codename}}-security` リポジトリでフィルタリングします。この codename はリリースバージョンに固有です (Ubuntu Server 14 の場合は `trusty` など)。Patch Managerは、次のリポジトリに含まれているアップグレードのみを識別します。 + Ubuntu Server 16.04 LTS: `xenial-security` + Ubuntu Server 18.04 LTS: `bionic-security` + Ubuntu Server 20.04 LTS: `focal-security` + Ubuntu Server 22.04 LTS (`jammy-security`) + Ubuntu Server 24.04 LTS (`noble-security`) + Ubuntu Server 25.04 (`plucky-security`) ------ #### [ Windows サーバー ] Microsoft Windows オペレーティングシステムの場合、Patch Manager は Microsoft が Microsoft Update に公開して Windows Server Update Services (WSUS) で自動的に利用可能になる更新プログラムのリストを取得します。 **注記** Patch Managerでは、Patch Manager でサポートされている Windows Server オペレーティングシステムのバージョンで利用可能なパッチのみを使用できます。例えば、Patch Managerを使用して Windows RT にパッチを適用することはできません。 Patch Manager は各 AWS リージョン で新しい更新を継続的にモニタリングします。利用可能な更新プログラムのリストは、各リージョンで 1 日 1 回以上更新されます。Microsoft からのパッチ情報が処理されると、Patch Manager は最新の更新プログラムで置き換えられた前の更新プログラムをパッチのリストから削除します。したがって、最新の更新のみが表示され、インストール可能になります。例えば、`KB3135456` が `KB4012214` に置き換えられると、Patch Manager では `KB4012214` のみが利用可能となります。 同様に、Patch Manager がインストールできるのは、パッチ適用オペレーション中にマネージドノードで利用可能になっているパッチのみです。デフォルトで、Windows Server 2019 および Windows Server 2022 は後続の更新に置き換えられた更新を削除します。その結果、Windows Server パッチベースラインで `ApproveUntilDate` パラメータを使用しても、`ApproveUntilDate` パラメータで選択された日付が最新パッチの日付よりも前になっている場合は、以下のシナリオが発生します。 + 置き換えられたパッチはノードから削除されるため、Patch Manager を使用してインストールすることができない。 + 最新の代替パッチがノードに存在するが、`ApproveUntilDate` パラメータで指定された日付に従ったインストールにはまだ承認されていない。 これは、前月の緊急パッチがインストールされていない可能性がある場合でも、Systems Manager オペレーションに関してはマネージドノードが準拠状態にあることを意味します。`ApproveAfterDays` パラメータの使用時にも同じシナリオが発生する可能性があります。Microsoft の置き換えられたパッチ動作のため、`ApproveAfterDays` の日数が経過する前に Microsoft からの最新のパッチがリリースされた場合でも Windows Server 向けのパッチがインストールされないように、日数を設定することが可能です (通常は 30 日を超える日数)。マネージドノードで置き換えられたパッチを利用できるように Windows グループポリシーオブジェクト (GPO) 設定を変更した場合、このシステム動作は該当しないことに注意してください。 **注記** Microsoft がリリースするアプリケーションのパッチは、更新日時を指定していない場合があります。このような場合、デフォルトでは `01/01/1970` の更新日時が指定されています。 ------