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

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

注記

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

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

Amazon Linux and Amazon Linux 2

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

• リポ ID: amzn-main/latest

  リポ名: amzn-main-Base

• リポ ID: amzn-updates/latest

  リポ名: amzn-updates-Base

注記

すべての更新は、インスタンスに設定されているリモートリポからダウンロードされます。したがって、パッチを適用するために、インスタンスはリポに接続できる必要があります。

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

注記

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

CentOS

CentOS の場合、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 のインスタンスではパッケージマネージャーとして DNF が使用されます。どちらのパッケージマネージャーでも、更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。

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

注記

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

Debian Server

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

その後、パッケージは debian-security codename リポからフィルタリングされます。つまり、Debian Server 8 では、Patch Manager は debian-security jessie に含まれるアップグレードのみを識別します。Debian サーバー 9 の場合、debian-security stretch に含まれるアップグレードのみを識別します。Debian サーバー 10 の場合、debian-security buster に含まれるアップグレードのみを識別します。

注記

Debianサーバー 8 の場合のみ: 一部の Debian サーバー 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 インスタンスはパッケージマネージャーとして Yum を使用します。Yum は updateinfo.xml という名前のファイルとして、更新通知の概念を使用します。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。

注記

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

RHEL

Red Hat Enterprise Linux の場合、Systems Manager パッチベースラインサービスはインスタンスの事前設定済みのリポジトリ (リポ) を使用します。通常、インスタンスには 3 つの設定済みリポがあります。

すべての更新は、インスタンスに設定されているリモートリポからダウンロードされます。したがって、パッチを適用するために、インスタンスはリポに接続できる必要があります。

注記

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

Red Hat Enterprise Linux 7 のインスタンスではパッケージマネージャーとして Yum が使用されます。Red Hat Enterprise Linux 8 のインスタンスではパッケージマネージャーとして DNF が使用されます。どちらのパッケージマネージャーでも、updateinfo.xml という名前のファイルとして更新通知の概念が使用されます。更新通知は、特定の問題を修正するパッケージの集合にすぎません。個々のパッケージには分類や重要度は割り当てられません。このため、Patch Manager は、更新通知の属性を関連するパッケージに割り当てて、パッチベースラインで指定された分類フィルターに基づいてパッケージをインストールします。

RHEL 7と RHEL 8 ではリポジトリの場所が異なります。

RHEL 7

注記

以下のレポ ID は RHUI 2 に関連付けられています。RHUI 3は 2019 年 12 月に開始され、Yum リポジトリ ID に異なる命名スキームを導入しました。インスタンス作成元の RHEL-7 AMI によっては、コマンドを更新する必要がある場合があります。詳細については、Red Hat カスタマーポータルの「Repository IDs for RHEL 7 in AWS Have Changed」を参照してください。

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

RHEL 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

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-gorilla

Windows

Microsoft Windows オペレーティングシステムの場合、Patch Manager は Microsoft が Microsoft Update に公開して Windows Server Update Services (WSUS) で自動的に利用可能になる更新プログラムのリストを取得します。

Patch Manager は各 AWS リージョン で新しい更新を継続的にモニタリングします。利用可能な更新プログラムのリストは、各リージョンで 1 日 1 回以上更新されます。Microsoft からのパッチ情報が処理されると、Patch Manager は最新の更新プログラムで置き換えられた前の更新プログラムをパッチのリストから削除します。したがって、最新の更新のみが表示され、インストール可能になります。例えば、KB4012214 が KB3135456 に置き換えられると、KB4012214では Patch Manager のみが利用可能になります。

注記

Patch Managerでは、Windows Server でサポートされている Patch Manager オペレーティングシステムのバージョンで利用可能なパッチのみを使用できます。例えば、Patch Managerを使用して Windows RT にパッチを適用することはできません。