代替パッチソースリポジトリを指定する方法 (Linux) - AWS Systems Manager

代替パッチソースリポジトリを指定する方法 (Linux)

インスタンスに設定されているデフォルトのリポジトリをパッチオペレーションに使用すると、AWS Systems Manager の一機能であるパッチマネージャーはセキュリティに関連するパッチをスキャンまたはインストールします。これは Patch Manager のデフォルトの動作です。Patch Manager がセキュリティに関連するパッチを選択してインストールする方法の詳細については、「セキュリティに関連するパッチの選択方法」を参照してください。

ただし、Linux システムでは、Patch Manager を使用して、セキュリティに関連しないパッチや、インスタンスで設定されているデフォルトのリポジトリとは異なるソースリポジトリにあるパッチをインストールすることもできます。カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。

例えば、お使いの Ubuntu Server フリートには、Ubuntu Server 14.04 と Ubuntu Server 16.04 インスタンスの両方が含まれているとします。この場合、同じカスタムパッチベースラインで、各バージョンの代替リポジトリを指定できます。バージョンごとに、名前、オペレーティングシステムのバージョンタイプ (製品)、リポジトリ設定を指定します。サポートされているオペレーティングシステムのすべてのバージョンに適用される 1 つの代替ソースリポジトリを指定することもできます。

注記

インスタンス上の代替パッチリポジトリを指定するカスタムのパッチベースラインを実行しても、インスタンス用に設定されたデフォルトのリポジトリは変更されません。

このオプションを使用するシナリオの例のリストについては、このトピックの後半の「代替パッチソースリポジトリの使用例」を参照してください。

デフォルトおよびカスタムのパッチベースラインについては、「事前定義されたパッチベースラインおよびカスタムパッチベースラインについて」を参照してください。

例: コンソールを使用する場合

Systems Manager コンソールでの作業時に代替パッチソースリポジトリを指定するには、[Create patch baseline (パッチベースラインの作成)] ページの [Patch sources (パッチソース)] セクションを使用します。[Patch sources (パッチソース)] のオプションの使用については、「カスタムパッチベースラインの作成 (Linux)」を参照してください。

例: AWS CLI を使用する場合

AWS Command Line Interface ( AWS CLI )で --sources オプションを使用する例については、「 異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する 」を参照してください。

代替リポジトリに関する重要な考慮事項

代替パッチリポジトリを使用してパッチ適用戦略を計画する際は、次の点に注意してください。

指定されたリポジトリのみがパッチ適用に使用されます

代替リポジトリの指定は、追加リポジトリの指定を意味しません。インスタンスにデフォルトとして設定されているリポジトリ以外のリポジトリを指定することができます。ただし、更新を適用する場合は、代替のパッチソース設定の一部としてデフォルトのリポジトリも指定する必要があります。

例えば、Amazon Linux 2 インスタンスでは、デフォルトのリポジトリは amzn-mainamzn-update です。パッチ適用オペレーションで Extra Packages for Enterprise Linux (EPEL) リポジトリを含める必要がある場合は、3 つのリポジトリすべてを代替リポジトリとして指定する必要があります。

注記

インスタンスの代替パッチリポジトリを指定するカスタムパッチベースラインを実行しても、リポジトリは新しいデフォルトリポジトリにはなりません。パッチ適用オペレーションが完了すると、以前にデフォルトとして定義されていたリポジトリは、インスタンスに設定されたデフォルトのリポジトリのままになります。

YUM ベースのディストリビューションのパッチ適用の動作は、updateinfo.xml マニフェストに依存します

Anazib nLinux、Amazon Linux 2、Red Hat Enterprise Linux、CentOS など、YUM ベースのディストリビューション用の代替パッチリポジトリを指定する場合、パッチ適用動作は、リポジトリに更新マニフェストが完全で正しい形式の updateinfo.xml ファイルで含まれているかどうかによって異なります。このファイルは、リリース日、分類、および各種パッケージの重要度を指定します。次のいずれかのパッチ動作に影響を与えます。

  • ClassificationSeverity でフィルターしても、それらが updateinfo.xml で指定されていない場合、そのパッケージはフィルターには含まれません。つまり、updateinfo.xml ファイルのないパッケージはパッチ適用に含まれません。

  • ApprovalAfterDays でフィルターしても、パッケージのリリース日が Unix エポック形式でない場合 (またはリリース日が指定されていない場合)、そのパッケージはフィルターに含まれません。

  • [パッチベースラインの作成] ページの [Approved patches include non-security updates (承認済みパッチにセキュリティに関連しない更新プログラムを含める)] チェックボックスをオンにした場合は例外があります。この場合、updateinfo.xml ファイルのないパッケージ (または、ファイルを含んでいても 分類重要度日付の値が適切にフォーマットされていないパッケージ) は、事前にフィルタリングされたパッチのリストに含まれます。(インストールするには、パッチベースラインルールの他の要件を満たしていなければなりません。)

代替パッチソースリポジトリの使用例

例 1 – Ubuntu Server のセキュリティに関連しない更新プログラム

既にパッチマネージャーで、AWS が提供する事前定義されたパッチベースライン AWS-UbuntuDefaultPatchBaseline を使用して、セキュリティに関連するパッチを Ubuntu Server インスタンスのフリート上にインストールしたとします。このデフォルトに基づいて新しいパッチベースラインを作成できますが、デフォルトのディストリビューションに含まれるセキュリティに関連しない更新プログラムもインストールするように、承認ルールで指定できます。このパッチベースラインがインスタンスに対して実行されると、セキュリティに関連する問題と関連しない問題の両方に対するパッチが適用されます。また、ベースラインに対して指定したパッチ例外で、セキュリティに関連しないパッチを承認することもできます。

例 2 - Ubuntu Server の PPA (Personal Package Archives)

Ubuntu Server インスタンスで、Ubuntu の PPA (Personal Package Archives) を通じて配布されるソフトウェアを実行するとします。この場合、インスタンスで設定した PPA リポジトリをパッチ適用オペレーションのソースリポジトリとして指定する、パッチベースラインを作成します。その後、Run Command を使用して、インスタンスでパッチベースラインドキュメントを実行します。

例 3 - Amazon Linux の社内アプリケーション

Amazon Linux インスタンスで、業界の規制コンプライアンスに必要なアプリケーションを実行する必要があるとします。インスタンスでこれらのアプリケーションのリポジトリを設定し、YUM を使用してアプリケーションをまずインストールしてから、この新しい企業リポジトリを含むように、新しいパッチベースラインを更新または作成できます。その後、Run Command を使用して、AWS-RunPatchBaseline オプション付きで Scan ドキュメントを実行することで、企業パッケージがインストールされたパッケージに含まれており、インスタンスで最新であるかどうかを確認できます。最新でない場合は、Install オプション付きでそのドキュメントを再実行することで、アプリケーションを更新できます。