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

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

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

注記

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

以下の各タブを選択して、お使いのオペレーティングシステムで Patch Manager がセキュリティ関連のパッチを選択する方法を確認してください。

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022 および Amazon Linux 2023 では、事前設定されたリポジトリの処理とは異なります。

Amazon Linux 1 および Amazon Linux 2 では、Systems Manager のパッチベースライン サービスは、マネージドノード上の事前設定されたリポジトリを使用します。通常、ノードには 2 つの設定済みリポジトリ (リポウズ) があります。

Amazon Linux 1 上

• リポ ID: amzn-main/latest

  リポ名: amzn-main-Base

• リポ ID: amzn-updates/latest

  リポ名: amzn-updates-Base

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 または aarch64 になります。

Amazon Linux 2023 (AL2023) インスタンスには、最初に AL2023 のバージョンで利用可能なアップデートと、選択した AMI が含まれています。デフォルトでは、AL2023 インスタンスは起動時に追加のクリティカルかつ重要なセキュリティアップデートを自動的に受信しません。代わりに、デフォルトで有効になっている AL2023 のバージョン対応リポジトリによる確定的なアップグレード機能を使用すると、特定のニーズを満たすスケジュールに基づいて更新を適用できます。詳細については、「Amazon Linux 2023 ユーザーガイド」の「バージョン対応リポジトリによる確定的なアップグレード」を参照してください。

Amazon Linux 2022 では、事前設定されたリポジトリはロックされたバージョンのパッケージ更新に関連付けられています。Amazon Linux 2022 用の新規 Amazon Machine Images (AMIs) がリリースされると、特定のバージョンにロックされます。パッチ更新では、Patch Manager は、パッチ更新リポジトリの最新のロックバージョンを取得し、そのロックされたバージョンの内容に基づいてマネージド ノード上のパッケージを更新します。

AL2023 では、事前設定されたリポジトリは次のとおりです。

• リポ ID: amazonlinux

  リポジトリ名: Amazon Linux 2023 リポジトリ

Amazon Linux 2022 (プレビューリリース) では、事前設定されたリポジトリはロックされたバージョンのパッケージ更新に関連付けられています。Amazon Linux 2022 用の新規 Amazon Machine Images (AMIs) がリリースされると、特定のバージョンにロックされます。パッチ更新では、Patch Manager は、パッチ更新リポジトリの最新のロックバージョンを取得し、そのロックされたバージョンの内容に基づいてマネージド ノード上のパッケージを更新します。

Amazon Linux 2022 では、事前設定されたリポジトリは次のとおりです。

• リポ ID: amazonlinux

  リポジトリ名: Amazon Linux 2022 リポジトリ

注記

すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。

Amazon Linux 1 および Amazon Linux 2 マネージド ノードではパッケージマネージャーとして Yum が使用されます。Amazon Linux 2022 および Amazon Linux 2023 ではパッケージマネージャーとして DNF が使用されます。

どちらのパッケージマネージャーでも、updateinfo.xml という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。更新通知に含まれているすべてのパッケージは、Patch Manager ではセキュリティ関連とみなされます。個々のパッケージには分類や重要度は割り当てられません。そのため、Patch Manager は関連するパッケージに更新通知の属性を割り当てます。

注記

[パッチベースラインの作成] ページで [セキュリティ以外の更新を含める] チェックボックスをオンにすると、updateinfo.xml ファイル (または、正しくフォーマットされた分類、重要度、および日付の値のないファイルを含むパッケージ) に分類されないパッケージは、事前にフィルタリングされたパッチのリストに含まれます。ただし、パッチを適用するためには、パッチはユーザーが指定したパッチベースラインルールを満たしている必要があります。

CentOS and CentOS Stream

CentOS および CentOS Stream の場合、Systems Manager のパッチベースラインサービスはマネージドノードの設定済みリポジトリ (リポウズ) を使用します。以下のリストは、架空の CentOS 8.2 Amazon Machine Image (AMI) の例を示します。

• リポ ID: example-centos-8.2-base

  リポ名: Example CentOS-8.2 - Base

• リポ ID: example-centos-8.2-extras

  リポ名: Example CentOS-8.2 - Extras

• リポ ID: example-centos-8.2-updates

  リポ名: Example CentOS-8.2 - Updates

• リポ ID: example-centos-8.x-examplerepo

  リポ名: Example CentOS-8.x – Example Repo Packages

注記

すべての更新は、マネージドノードに設定されているリモートリポジトリからダウンロードされます。したがって、パッチを適用できるようにレポジトリに接続するために、ノードにインターネットへのアウトバウンドアクセスが必要です。

CentOS 6 および 7 のマネージドノードではパッケージマネージャーとして Yum が使用されます。CentOS 8 および CentOS Stream のノードではパッケージマネージャーとして DNF が使用されます。どちらのパッケージマネージャーでも、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。

ただし、CentOS および CentOS Stream のデフォルトリポは更新通知で設定されません。これは、Patch Manager で CentOS および CentOS Stream のデフォルトリポのパッケージが検出されないことを意味します。Patch Manager を許可して更新通知に含まれていないパッケージを処理するには、パッチベースラインルールで EnableNonSecurity フラグを有効にする必要があります。

注記

CentOS および CentOS Stream の更新通知がサポートされています。更新通知のあるリポは起動後にダウンロードできます。

Debian サーバー and Raspberry Pi OS

Debian Server および Raspberry Pi OS (旧称 Raspbian) の場合、Systems Manager のパッチベースラインサービスでは、インスタンスの事前設定済みリポジトリ (リポウズ) を使用します。これらの構成済みリポを使用して、使用可能なパッケージアップグレードの最新リストを取得します。このため、Systems Manager は、sudo apt-get update コマンドと同等のコマンドを実行します。

その後、パッケージは debian-security codename リポからフィルタリングされます。つまり、Debian Server の各バージョンでは、次のように、Patch Manager は、そのバージョンの関連リポジトリに含まれるアップグレードのみを識別します。

• Debian Server 8: debian-security jessie

• Debian Server 9: debian-security stretch

• Debian Server 10: debian-security buster

• Debian Server 11: debian-security bullseye

• Debian Server 12: debian-security bookworm

注記

Debian Server 8 のみ: 一部の Debian Server 8.* マネージドノードはサポートされなくなったパッケージリポジトリ (jessie-backports) を参照するため、Patch Manager ではパッチ適用オペレーションが正常に完了するように追加の手順を実行します。詳細については、「パッチのインストール方法」を参照してください。

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

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 14.04 LTS: trusty-security

• Ubuntu Server 16.04 LTS: xenial-security

• Ubuntu Server 18.04 LTS: bionic-security

• Ubuntu Server 20.04 LTS: focal-security

• Ubuntu Server 20.10 STR: groovy-security

• Ubuntu Server 22.04 LTS (jammy-security)

• Ubuntu Server 23.04 (lunar-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 の更新日時が指定されています。