パッチ適用のための SSM コマンドドキュメント: AWS-RunPatchBaselineAssociation
AWS-RunPatchBaseline ドキュメントと同様に、AWS-RunPatchBaselineAssociation では、セキュリティ関連および他のタイプの更新の両方について、インスタンスにパッチ適用オペレーションを実行します。また、ドキュメント AWS-RunPatchBaselineAssociation を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することもできます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。
このドキュメントでは、Linux、macOS、および Windows Server 用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがサポートされています。ハイブリッドおよびマルチクラウド環境内の非 EC2 ノードは、サポートされていません。このドキュメントでは、各プラットフォームに対して適切なアクションを実行し、Linux インスタンスおよび macOS インスタンスでは Python モジュールを、Windows インスタンスでは PowerShell モジュールを呼び出します。
ただし、AWS-RunPatchBaselineAssociation は、次の点で AWS-RunPatchBaseline とは異なります。
-
AWS-RunPatchBaselineAssociationは、主に AWS Systems Manager の一機能である Quick Setup を使用して作成された State Manager 関連付けでの使用を目的としています。具体的には、Quick Setup ホスト管理設定タイプを使用する場合、[Scan instances for missing patches daily] (不足しているパッチがないか毎日インスタンスをスキャンする) オプションを選択すると、システムはオペレーションにAWS-RunPatchBaselineAssociationを使用します。ただし、ほとんどの場合、独自のパッチ適用オペレーションを設定する場合は、
AWS-RunPatchBaselineAssociationの代わりに、AWS-RunPatchBaseline または AWS-RunPatchBaselineWithHooks を選択する必要があります。 -
AWS-RunPatchBaselineAssociationドキュメントを使用すると、ドキュメントのBaselineTagsパラメータフィールドでタグのキーペアを指定できます。AWS アカウント 内のカスタムパッチベースラインがこれらのタグを共有している場合、AWS Systems Manager の一機能である Patch Manager は、ターゲットインスタンスでの実行時に、オペレーティングシステムタイプに対して現在指定されている「デフォルト」パッチベースラインではなく、そのタグ付きベースラインを使用します。重要
Quick Setup を使用してセットアップした以外のパッチオペレーションで
AWS-RunPatchBaselineAssociationを使用することを選択し、そのオプションのBaselineTagsパラメータを使用する場合は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのインスタンスプロファイルに対する追加のアクセス許可を指定する必要があります。詳細については、「パラメータ名: BaselineTags」を参照してください。次の形式はどちらも
BaselineTagsパラメータに対して有効です。Key=tag-key,Values=tag-valueKey=tag-key,Values=tag-value1,tag-value2,tag-value3 -
AWS-RunPatchBaselineAssociationの実行時に収集されるパッチコンプライアンスデータは、PutComplianceItemsによって使用されるPutInventoryコマンドではなく、AWS-RunPatchBaselineAPI コマンドを使用して記録されます。この違いは、特定の関連付けごとに保存およびレポートされるパッチコンプライアンス情報であることを意味します。この関連付けの外部で生成されたパッチコンプライアンスデータは上書きされません。 -
AWS-RunPatchBaselineAssociationの実行後にレポートされるパッチコンプライアンス情報は、インスタンスが準拠しているかどうかを示します。次の AWS Command Line Interface ( AWS CLI )コマンドの出力で示されているように、パッチレベルの詳細は含まれません。コマンドはコンプライアンスタイプとしてAssociationでフィルタリングされます。aws ssm list-compliance-items \ --resource-ids "i-02573cafcfEXAMPLE" \ --resource-types "ManagedInstance" \ --filters "Key=ComplianceType,Values=Association,Type=EQUAL" \ --region us-east-2システムが以下のような情報をレスポンスします。
{ "ComplianceItems": [ { "Status": "NON_COMPLIANT", "Severity": "UNSPECIFIED", "Title": "MyPatchAssociation", "ResourceType": "ManagedInstance", "ResourceId": "i-02573cafcfEXAMPLE", "ComplianceType": "Association", "Details": { "DocumentName": "AWS-RunPatchBaselineAssociation", "PatchBaselineId": "pb-0c10e65780EXAMPLE", "DocumentVersion": "1" }, "ExecutionSummary": { "ExecutionTime": 1590698771.0 }, "Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE" } ] }
AWS-RunPatchBaselineAssociation ドキュメントのパラメータとしてタグのキーペア値が指定されている場合、Patch Manager は、オペレーティングシステムのタイプと一致し、同じタグのキーペアでタグ付けされているカスタムパッチベースラインを検索します。この検索は、現在指定されているデフォルトのパッチベースライン、またはパッチグループに割り当てられたベースラインに制限されません。指定されたタグを持つベースラインが見つからない場合は、Patch Managerはパッチグループを検索します (AWS-RunPatchBaselineAssociation を実行するコマンドで指定されている場合)。一致するパッチグループがない場合、Patch Managerはオペレーティングシステムのアカウントにデフォルトに設定されているパッチベースラインを使用します。
AWS-RunPatchBaselineAssociation ドキュメントで指定されているタグを持つパッチベースラインが複数見つかった場合、Patch Managerは、オペレーションを続行するために、そのキーと値のペアでタグ付けできるパッチベースラインは 1 つだけであることを示すエラーメッセージを返します。
注記
Linux インスタンスでは、各インスタンスタイプに適切なパッケージマネージャーを使用してパッケージをインストールします。
-
Amazon Linux 1、Amazon Linux 2、CentOS、Oracle Linux、および RHEL インスタンスでは、YUM が使用されています。YUM のオペレーションでは、Patch Manager には、
Python 2.6またはそれ以降のサポートされているバージョン (2.6～3.10) が必要です。 -
Debian Server、Raspberry Pi OS、および Ubuntu Server インスタンスでは、APT が使用されています。APT のオペレーションでは、Patch Manager には、サポートされているバージョン (3.0～3.10) の
Python 3が必要です。 -
SUSE Linux Enterprise Server インスタンスでは Zypper が使用されています。Zypper のオペレーションでは、Patch Manager には、
Python 2.6またはそれ以降のサポートされているバージョン (2.6～3.10) が必要です。
スキャンが完了した後、またはすべての承認済み更新と該当する更新がインストールされた後、必要に応じて再起動されると、パッチコンプライアンス情報がインスタンスで生成されてパッチコンプライアンスサービスにレポートされます。
注記
AWS-RunPatchBaselineAssociation ドキュメントで RebootOption パラメータが NoReboot に設定されている場合、Patch Managerの実行後、インスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。
パッチコンプライアンスデータの表示方法については、「パッチコンプライアンスについて」を参照してください。
AWS-RunPatchBaselineAssociation 個のパラメータ
AWS-RunPatchBaselineAssociation は、4 つのパラメータをサポートしています。Operation および AssociationId パラメータが必要です。InstallOverrideList、RebootOption および BaselineTags パラメータはオプションです。
パラメータ
パラメータ名: Operation
使用: 必須。
オプション: Scan | Install。
- Scan
-
Scanオプションを選択すると、AWS-RunPatchBaselineAssociationはインスタンスのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。Scanでは、更新のインストールや、インスタンスの再起動を求めません。代わりに、承認済み更新でインスタンスに適用可能なものが見つからない個所を示します。 - インストール
-
Installオプションを選択すると、AWS-RunPatchBaselineAssociationはインスタンスに見つからない承認済み更新と適用可能な更新のインストールを試行します。Installオペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がインスタンスにインストールされるたびに、インスタンスが再起動され、更新がインストール済みで有効になっていることが確認されます。（例外:RebootOptionパラメータがAWS-RunPatchBaselineAssociationドキュメントのNoRebootで設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。）注記
Patch Managerがインスタンスを更新する前に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の
unattended-upgradesパッケージなどの別のプログラムによって自動的にインストールされた場合です。
パラメータ名: BaselineTags
使用: オプション。
BaselineTags は、一意のタグのキーと値のペアで、選択して個々のカスタムパッチベースラインに割り当てます。このパラメータには、1 つ以上の値を指定できます。次の形式はどちらも有効です。
Key=tag-key,Values=tag-value
Key=tag-key,Values=tag-value1,tag-value2,tag-value3
Patch Manager は、BaselineTags の値を使用して、1 回のオペレーションでパッチを適用するインスタンスのすべてに同じ承認済みパッチのセットが適用されるようにします。 パッチ適用オペレーションが実行すると、Patch Manager は、オペレーティングシステムのタイプのパッチベースラインが BaselineTags で指定したものと同じキーと値のペアでタグ付けされているか確認します。一致するものがある場合は、このカスタムパッチベースラインが使用されます。一致するものがない場合、パッチ適用オペレーションに指定されたパッチグループに従って、パッチベースラインが識別されます。存在しない場合は、そのオペレーティングシステムの AWS マネージド定義済みパッチベースラインが使用されます。
追加のアクセス許可要件
Quick Setup を使用してセットアップした以外のパッチオペレーションで AWS-RunPatchBaselineAssociation を使用し、オプションの BaselineTags パラメータを使用する場合は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのインスタンスプロファイルに対する以下のアクセス許可を追加する必要があります。
注記
Quick Setup と AWS-RunPatchBaselineAssociation は、オンプレミスのサーバーと仮想マシン (VM) をサポートしていません。
{ "Effect": "Allow", "Action": [ "ssm:DescribePatchBaselines", "tag:GetResources" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ssm:GetPatchBaseline", "ssm:DescribeEffectivePatchesForPatchBaseline" ], "Resource": "patch-baseline-arn" }
patch-baseline-arn を、アクセス許可を付与するパッチベースラインの Amazon リソースネーム (ARN) に、arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE 形式で置き換えます。
パラメータ名: AssociationId
使用: 必須。
AssociationId は、AWS Systems Manager の一機能である State Manager の既存の関連付けの ID です。これは、指定した関連付けにコンプライアンスデータを追加するために Patch Manager で使用します。この関連付けは、Quick Setup で作成されたホスト管理設定で有効になっているパッチ Scan オペレーションに関連しています。パッチ適用の結果をインベントリコンプライアンスデータではなく関連付けコンプライアンスデータとして送信することで、インスタンスの既存のインベントリコンプライアンス情報は、パッチ適用オペレーションの後やその他の関連付け ID に対して上書きされません。使用する関連付けがまだない場合は、create-association コマンドを実行して関連付けを作成できます。例:
パラメータ名: InstallOverrideList
使用: オプション。
InstallOverrideList を使用して、インストールするパッチのリストに対する https URL または Amazon Simple Storage Service (Amazon S3) パス形式の URL を指定します。このパッチインストールリストは、YAML 形式で管理され、デフォルトのパッチベースラインで指定されたパッチを上書きします。これにより、どのインスタンスにどのパッチがインストールされているかを、より詳細にコントロールできます。
InstallOverrideList パラメータを使用する場合のパッチ適用オペレーションの動作は、Linux および macOS マネージドノードと、Windows Server マネージドノードで異なります。Linux および macOS では、パッチがパッチベースラインルールと一致するかどうかにかかわらず、Patch Manager は、ノードで有効になっているリポジトリに存在する InstallOverrideList パッチリストに含まれるパッチを適用しようとします。一方、Windows Server ノードでは、InstallOverrideList パッチリスト内のパッチは、パッチベースラインルールとも一致する場合にのみ適用されます。
コンプライアンスレポートは、パッチの InstallOverrideList リストで指定するものではなく、パッチのベースラインで指定されているものに従ってパッチの状態が反映されることに注意してください。つまり、スキャンオペレーションは InstallOverrideList パラメータを無視します。これは、コンプライアンスレポートが、特定のパッチ適用オペレーションで承認されたものではなく、ポリシーに従ってパッチ状態を一貫して反映することを保証するためです。
有効な URL 形式
注記
ファイルが公開されているバケットに格納されている場合は、「https」URL 形式または Amazon S3 パススタイルの URL を指定できます。ファイルがプライベートバケットに格納されている場合は、Amazon S3 パススタイルの URL を指定する必要があります。
-
https URL 形式の例:
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml -
Amazon S3 パス形式 URL の例:
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
有効な YAML コンテンツ形式
リストにパッチを指定するために使用する書式は、インスタンスのオペレーティングシステムによって異なります。ただし、一般的な形式は次のとおりです。
patches: - id: '{patch-d}' title: '{patch-title}' {additional-fields}:{values}
YAML ファイルにフィールドを追加することはできますが、パッチオペレーション中は無視されます。
さらに、S3 バケットのリストを追加または更新する前に、YAML ファイルのフォーマットが有効であることを確認することをお勧めします。YAML 形式の詳細については、yaml.org
-
Microsoft Windows
id
id フィールドは必須です。Microsoft Knowledge Base ID (KB2736693 など) および Microsoft Security Bulletin ID (MS17-023 など) を使用してパッチを指定する場合に使用します。
Windows 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、title、classification、severity などの追加フィールドを使用することができます。
-
Linux
id
id フィールドは必須です。これにより、パッケージ名とアーキテクチャを使用してパッチを指定します。例:
'dhclient.x86_64'。ID にワイルドカードを使用すると、複数のパッケージを指定できます。例:'dhcp*'および'dhcp*1.*'。title
title フィールドはオプションですが、Linux システムでは追加のフィルタリング機能を提供します。title を使用する場合は、次のいずれかの形式でパッケージのバージョン情報を含める必要があります。
YUM/SUSE Linux Enterprise Server (SLES):
{name}.{architecture}:{epoch}:{version}-{release}APT
{name}.{architecture}:{version}Linux のパッチタイトルでは、任意の位置に 1 つ以上のワイルドカードを使用して一致するパッケージの数を拡張することができます。例:
'*32:9.8.2-0.*.rc1.57.amzn1'。以下に例を示します。
-
apt パッケージのバージョン 1.2.25 が現在インスタンスにインストールされていますが、バージョン 1.2.27 が利用できるようになりました。
-
apt.amd64 バージョン 1.2.27 をパッチリストに追加します。これは apt utils.amd64 バージョン 1.2.27 に依存しますが、apt-utils.amd64 バージョン 1.2.25 がリストで指定されています。
この場合、apt バージョン 1.2.27 のインストールはブロックされ、「Failed-NonCompliant」として報告されます。
-
その他のフィールド
Linux 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、classification、severity などの追加フィールドを使用することができます。
サンプルパッチリスト
-
Windows
patches: - id: 'KB4284819' title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)' - id: 'KB4284833' - id: 'KB4284835' title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)' - id: 'KB4284880' - id: 'KB4338814' -
APT
patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' -
Amazon Linux
patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '32:9.8.2-0.62.rc1.57.amzn1' - id: 'glibc*' - id: 'dhclient*' title: '*12:4.1.1-53.P1.28.amzn1' - id: 'dhcp*' title: '*10:3.1.1-50.P1.26.amzn1' -
Red Hat Enterprise Linux (RHEL)
patches: - id: 'NetworkManager.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'NetworkManager-*.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'audit.x86_64' title: '*0:2.8.1-3.el7' - id: 'dhclient.x86_64' title: '*.el7_5.1' - id: 'dhcp*.x86_64' title: '*12:5.2.5-68.el7' -
SUSE Linux Enterprise Server (SLES)
patches: - id: 'amazon-ssm-agent.x86_64' - id: 'binutils' title: '*0:2.26.1-9.12.1' - id: 'glibc*.x86_64' title: '*2.19*' - id: 'dhcp*' title: '0:4.3.3-9.1' - id: 'lib*' -
Ubuntu Server
patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' -
Windows
patches: - id: 'KB4284819' title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)' - id: 'KB4284833' - id: 'KB4284835' title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)' - id: 'KB4284880' - id: 'KB4338814'
パラメータ名: RebootOption
使用: オプション。
オプション: RebootIfNeeded | NoReboot
デフォルト: RebootIfNeeded
警告
デフォルトのオプションは RebootIfNeeded です。ユースケースに適したオプションを必ず選択してください。例えば、設定プロセスを完了するためにインスタンスをすぐに再起動する必要がある場合は、RebootIfNeeded を選択します。または、スケジュールされた再起動時間までインスタンスの可用性を維持する必要がある場合は、NoReboot を選択します。
重要
Amazon EMR (以前は Amazon Elastic MapReduce と呼ばれていました) のクラスターインスタンスへのパッチ適用には、Patch Manager を使用しないことをお勧めします。特に、RebootOption パラメータの RebootIfNeeded オプションは選択しないでください。(このオプションは、AWS-RunPatchBaseline、AWS-RunPatchBaselineAssociation、および AWS-RunPatchBaselineWithHooks のパッチ適用用の SSM コマンドドキュメントに記載されています。)
Patch Manager を使用してパッチを適用する基本コマンドは、yum と dnf コマンドを使用します。そのため、パッケージのインストール方法が原因となり、オペレーションの互換性が失われます。Amazon EMR クラスターのソフトウェアを更新するための推奨方法については、「Amazon EMR 管理ガイド」の「Amazon EMR のデフォルト AMI の使用」を参照してください。
- RebootIfNeeded
-
RebootIfNeededオプションを選択すると、次のいずれかの場合にインスタンスが再起動されます。-
Patch Manager が 1 つ以上のパッチをインストールしている場合。
Patch Manager は、パッチによる再起動が必要かどうか評価しない場合。パッチで再起動が必要ない場合でも、システムは再起動されます。
-
Patch Manager は、
Installオペレーションの実行中、ステータスがINSTALLED_PENDING_REBOOTのパッチをひとつ以上検出します。INSTALLED_PENDING_REBOOTステータスは、前回Installオペレーションを実行したときにオプションNoRebootが選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
上記 2 つの場合にインスタンスを再起動すると、更新されたパッケージがメモリからフラッシュされ、パッチ適用と再起動の動作があらゆるオペレーティングシステムで一貫して維持されます。
-
- NoReboot
-
NoRebootオプションを選択すると、Patch Manager がInstallオペレーション中にパッチをインストールした場合でも、インスタンスは再起動されません。このオプションは、パッチ適用後にインスタンスを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがインスタンスで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、インスタンスの再起動のタイミングをより詳細に制御する場合にも役立ちます。
パッチのインストール追跡ファイル: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、Systems Manager は、マネージドインスタンスのファイルを管理します。
重要
追跡ファイルを削除または変更しないでください。このファイルを削除または破損すると、インスタンスのパッチコンプライアンスレポートが不正確になります。ファイルを削除または破損した場合は、インスタンスを再起動し、パッチのスキャンオペレーションを実行してファイルを復元します。
この追跡ファイルは、マネージドインスタンスの以下の場所に保存されます。
-
Linux オペレーティングシステム:
-
/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json -
/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json
-
-
Windows Server オペレーティングシステム:
-
C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json -
C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json
-
