セキュリティに関連するパッチの選択方法

AWS Systems Manager のツールである Patch Manager の主な目的は、オペレーティングシステムのセキュリティに関連する更新プログラムをマネージドノードにインストールすることです。デフォルトでは、Patch Manager はすべての利用可能なパッチをインストールするのではなく、一部のセキュリティ関連のパッチをインストールします。

デフォルトでは、Patch Manager は、パッケージリポジトリで廃止とマークされたパッケージを、別のパッケージ更新のインストールでこの置換が必要な場合を除き、別の名前の置換パッケージに置き換えません。代わりに、パッケージを更新するコマンドの場合、Patch Manager はインストールされているが古いパッケージの欠落した更新のみを通知してインストールします。これは、古いパッケージを置き換えるには、通常、既存のパッケージをアンインストールし、改めて新しいパッケージをインストールする必要があるためです。古いパッケージを置き換えると、意図していない重大な変更や追加機能が発生する可能性があります。

この動作は、機能のアップグレードではなくセキュリティ更新に焦点を当てた YUM および DNF の update-minimal コマンドと一致しています。詳細については、「パッチのインストール方法」を参照してください。

パッチの重要度を報告する Linux ベースタイプのオペレーティングシステムの場合、Patch Manager は更新通知または個々のパッチのために、ソフトウェア発行者によって報告された重要度レベルを使用します。Patch Manager では、CVSS (共通脆弱性評価システム) のような サードパーティのソースからの、または NVD (National Vulnerability Database) がリリースしたメトリクスからの重要度レベルは取得しません。

注記

Patch Manager でサポートされているすべての Linux ベースのシステムでは、セキュリティに関連しない更新プログラムをインストールしたりするために、マネージドノードに別のソースリポジトリを選択することができます。詳細については、「代替パッチソースリポジトリを指定する方法 (Linux)」を参照してください。

以下の各タブを選択して、お使いのオペレーティングシステムで 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 ユーザーガイド」の「バージョン対応リポジトリによる確定的なアップグレード」を参照してください。

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 ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。

セキュリティ以外の更新を含めるオプションの詳細については、「パッチのインストール方法」および「Linux ベースシステムでのパッチベースラインルールの動作方法」を参照してください。

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 が既に変化した」を参照してください。

• リポ 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

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 Server

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 の更新日時が指定されています。