AWS-RunPatchBaseline SSM ドキュメントについて - AWS Systems Manager

AWS-RunPatchBaseline SSM ドキュメントについて

AWS Systems Manager は、AWS Systems Manager の一機能である Patch Manager 用の Systems Manager ドキュメント (SSM ドキュメント) である AWS-RunPatchBaseline をサポートしています。この SSM ドキュメントでは、セキュリティ関連および他のタイプの更新の両方について、インスタンスにパッチ適用オペレーションを実行します。パッチグループが指定されていない場合、ドキュメントを実行すると、オペレーティングシステムタイプの「デフォルト」として指定されているパッチベースラインが使用されます。それ以外の場合は、パッチグループに関連付けられているパッチベースラインが使用されます。パッチグループの詳細については、「パッチグループについて」を参照してください。

ドキュメント AWS-RunPatchBaseline を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。

このドキュメントでは、Linux、macOS、および Windows Server インスタンスをサポートしています。ドキュメントは、プラットフォーム別に適切なアクションを実行します。

注記

Patch Manager は、レガシー SSM ドキュメント AWS-ApplyPatchBaseline もサポートしています。ただし、このドキュメントが対応するのは Windows インスタンスのみです。Linux、macOS 、および Windows Server インスタンスでのパッチ適用をサポートしているため、代わりに AWS-RunPatchBaseline を使用することをお勧めします。AWS-RunPatchBaseline ドキュメントを使用するには、バージョン 2.0.834.0 以降の SSM Agent が必要です。

Windows

Windows Server インスタンスの場合、AWS-RunPatchBaseline ドキュメントは、PowerShell モジュールをダウンロードして呼び出します。これに伴って、インスタンスに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインスナップショットには、Windows Server Update Services (WSUS) サーバーに対してパッチベースラインを照会することによってコンパイルされる承認済みパッチのリストが含まれています。このリストは、Windows Update API に渡され、ここで承認済みパッチのダウンロードとインストールが適切に制御されます。

Linux

Linux インスタンスの場合、AWS-RunPatchBaseline ドキュメントは、Python モジュールを呼び出します。これに伴って、インスタンスに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインのスナップショットは、定義済みルールと、承認済みパッチおよび拒否済みパッチのリストを使用し、インスタンスタイプ別に適切なパッケージマネージャーを設定します。

  • Amazon Linux、Amazon Linux 2、CentOS、Oracle Linux、および RHEL 7 インスタンスが YUM を使用しています。YUM のオペレーションでは、Patch Manager は Python 2.6 以降を必要とします。

  • RHEL 8 インスタンスでは DNF が使用されています。DNF オペレーションでは、Patch Manager は Python 2 または Python 3 を必要とします。(どちらのバージョンも RHEL 8 にはデフォルトでインストールされていません。どちらか一方を手動でインストールする必要があります。)

  • Debian サーバーと Ubuntu Server インスタンスでは APT が使用されています。APT オペレーションでは、Patch Manager は Python 3 を必要とします。

  • SUSE Linux Enterprise Server インスタンスでは Zypper が使用されています。Zypper オペレーションでは、Patch Manager は Python 2.6 以降を必要とします。

macOS

macOS インスタンスの場合、AWS-RunPatchBaseline ドキュメントは、Python モジュールを呼び出します。これに伴って、インスタンスに適用するパッチベースラインのスナップショットがダウンロードされます。次に、Python サブプロセスがインスタンスで AWS Command Line Interface ( AWS CLI )を呼び出し、指定されたパッケージマネージャーのインストールおよび更新情報を取得し、各更新パッケージに適切なパッケージマネージャーを実行します。

各スナップショットは、 AWS アカウント 、パッチグループ、オペレーティングシステム、スナップショット ID に固有のものです。スナップショットは、署名付きの Amazon Simple Storage Service (Amazon S3) URL を介して配信されます。この URL は、スナップショットが作成されてから 24 時間後に期限切れになります。ただし、URL の有効期限が切れた後に、同じスナップショットコンテンツを他のインスタンスに適用する場合は、スナップショットを作成してから 3 日以内であれば新しい署名付き Amazon S3 URL を生成できます。これを行うには、get-deployable-patch-snapshot-for-instance コマンドを使用します。

すべての承認済みで適用可能な更新プログラムがインストールされ、必要に応じて再起動されると、パッチのコンプライアンス情報がインスタンスで生成されて Patch Manager にレポートされます。

注記

AWS-RunPatchBaseline ドキュメントで RebootOption パラメータが NoReboot に設定されている場合、Patch Managerの実行後、インスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。

パッチコンプライアンスデータの表示方法については、「パッチコンプライアンスについて」を参照してください。

AWS-RunPatchBaseline 個のパラメータ

AWS-RunPatchBaseline は 5 つのパラメータをサポートしています。Operation パラメータは必須です。InstallOverrideListBaselineOverrideRebootOption の各パラメータはオプションです。Snapshot-ID は技術的にはオプションですが、メンテナンスウィンドウを使用せずに AWS-RunPatchBaseline を実行する場合はカスタム値を指定することをお勧めします。このドキュメントをメンテナンスウィンドウオペレーションの一部として実行する場合は、Patch Manager がカスタム値を自動的に提供します。

パラメータ名: Operation

使用: 必須。

オプション: Scan | Install

スキャン

Scan オプションを選択すると、AWS-RunPatchBaseline はインスタンスのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。Scan では、更新のインストールや、インスタンスの再起動を求めません。代わりに、承認済み更新でインスタンスに適用可能なものが見つからない個所を示します。

インストール

Install オプションを選択すると、AWS-RunPatchBaseline はインスタンスに見つからない承認済み更新と適用可能な更新のインストールを試行します。Install オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がインスタンスにインストールされるたびに、インスタンスが再起動され、更新がインストール済みで有効になっていることが確認されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

注記

Patch Managerがインスタンスを更新するに、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の unattended-upgrades パッケージなどの別のプログラムによって自動的にインストールされた場合です。

パラメータ名: Snapshot ID

使用: オプション。

Snapshot ID は、Patch Managerが使用する一意の ID (GUID) です。この ID により、1 回のオペレーションでパッチを適用するインスタンスのすべてに同じ承認済みパッチのセットが適用されます。このパラメータは省略可能ですが、次の表に示すようにメンテナンスウィンドウで AWS-RunPatchBaseline を実行しているかどうかに応じて、推奨されるベストプラクティスが異なります。

AWS-RunPatchBaseline のベストプラクティス
モード ベストプラクティス 詳細
メンテナンスウィンドウ内で AWS-RunPatchBaseline を実行する スナップショット ID は指定しないでください。Patch Manager によって指定されます。

メンテナンスウィンドウを使用して AWS-RunPatchBaseline を実行する場合は、独自に生成したスナップショット ID を提供すべきではありません。このシナリオでは、メンテナンスウィンドウの実行 ID に基づく GUID 値が Systems Manager から提供されます。これにより、そのメンテナンスウィンドウでは、AWS-RunPatchBaseline のすべての呼び出しで正しい ID が使用されます。

このシナリオで値を指定しないと、パッチベースラインのスナップショットは 3 日以内に有効期限が切れる場合があります。スナップショットの有効期限が切れると、同じ ID を指定しても、別のスナップショットが生成されます。

メンテナンスウィンドウ外で AWS-RunPatchBaseline を実行する スナップショット ID のカスタム GUID 値を生成および指定します。¹

メンテナンスウィンドウを使用しないで AWS-RunPatchBaseline を実行する場合は、パッチベースラインごとに一意のスナップショット ID を生成し指定することをお勧めします (特に、同一のオペレーションで AWS-RunPatchBaseline ドキュメントを複数のインスタンスで実行する場合)。このシナリオで ID を指定しないと、コマンドの送信先のインスタンスごとに異なるスナップショット ID が Systems Manager で生成されます。これにより、インスタンス間で異なるパッチセットが指定される場合があります。

例えば、AWS Systems Manager の一機能である Run Command を使用して AWS-RunPatchBaseline ドキュメントを直接実行し、50 個のインスタンスのグループをターゲットにしているとします。カスタムスナップショット ID を指定すると、1 つのベースラインスナップショットが作成され、これがすべてのインスタンスの評価とパッチ適用に使用されるため、すべてのインスタンスの状態が一致します。

¹Snapshot ID パラメータの値を生成するには、GUID を生成できる任意のツールを使用できます。たとえば、PowerShell では、New-Guid cmdlet を使用して 12345699-9405-4f69-bc5e-9315aEXAMPLE という形式の GUID を生成できます。

パラメータ名: InstallOverrideList

使用: オプション。

InstallOverrideList を使用すると、インストールするパッチのリストに対する https URL または Amazon S3 パス形式の URL を指定できます。このパッチインストールリストは、YAML 形式で管理され、デフォルトのパッチベースラインで指定されたパッチを上書きします。これにより、どのインスタンスにどのパッチがインストールされているかを、より詳細にコントロールできます。

コンプライアンスレポートは、パッチの InstallOverrideList リストで指定するものではなく、パッチのベースラインで指定されているものに従ってパッチの状態が反映されることに注意してください。つまり、スキャンオペレーションは InstallOverrideList パラメータを無視します。これは、コンプライアンスレポートが、特定のパッチ適用オペレーションで承認されたものではなく、ポリシーに従ってパッチ状態を一貫して反映することを保証するためです。

単一のパッチベースラインを使用しながら、InstallOverrideList パラメータを使用して、異なるメンテナンスウィンドウスケジュールで異なるタイプのパッチをターゲットグループに適用する方法の詳細については、「AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation で InstallOverrideList パラメータを使用するサンプルシナリオ」を参照してください。

有効な URL 形式

注記

ファイルが公開されているバケットに格納されている場合は、「https」URL 形式または Amazon S3 パススタイルの URL を指定できます。ファイルがプライベートバケットに格納されている場合は、Amazon S3 パススタイルの URL を指定する必要があります。

  • https URL 形式:

    https://s3.amazonaws.com/DOC-EXAMPLE-BUCKET/my-windows-override-list.yaml
  • Amazon S3 パス形式の URL :

    s3://DOC-EXAMPLE-BUCKET/my-windows-override-list.yaml

有効な YAML コンテンツ形式

リストにパッチを指定するために使用する書式は、インスタンスのオペレーティングシステムによって異なります。ただし、一般的な形式は次のとおりです。

patches: - id: '{patch-d}' title: '{patch-title}' {additional-fields}:{values}

YAML ファイルにフィールドを追加することはできますが、パッチオペレーション中は無視されます。

さらに、S3 バケットのリストを追加または更新する前に、YAML ファイルのフォーマットが有効であることを確認することをお勧めします。YAML 形式の詳細については、yaml.org を参照してください。検証ツールのオプションについては、ウェブで「yaml 形式の検証」を検索します。

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」として報告されます。

Windows

id

id フィールドは必須です。Microsoft Knowledge Base ID (KB2736693 など) および Microsoft Security Bulletin ID (MS17-023 など) を使用してパッチを指定する場合に使用します。

Windows 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、titleclassificationseverity などの追加フィールドを使用することができます。

macOS

id

id フィールドは必須です。id フィールドの値は、{package-name}.{package-version} 形式または {package_name} 形式のいずれかを使用して指定することができます。

サンプルパッチリスト

  • 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'
  • CentOS

    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'
  • Debian サーバー

    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'
  • macOS

    patches: - id: 'XProtectPlistConfigData' - id: 'MRTConfigData.1.61' - id: 'Command Line Tools for Xcode.11.5' - id: 'Gatekeeper Configuration Data'
  • Oracle Linux

    patches: - id: 'audit-libs.x86_64' title: '*2.8.5-4.el7' - id: 'curl.x86_64' title: '*.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:2.02-0.81.0.1.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:*-0.81.0.1.el7'
  • 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オプションを選択すると、次のいずれかの場合にインスタンスが再起動されます。

  • Patch Manager が 1 つ以上のパッチをインストールしている場合。

    Patch Manager は、パッチによる再起動が必要かどうか評価しない場合。パッチで再起動が必要ない場合でも、システムは再起動されます。

  • Patch Manager は、Install オペレーションの実行中、ステータスが INSTALLED_PENDING_REBOOT のパッチをひとつ以上検出します。

    INSTALLED_PENDING_REBOOT ステータスは、Install オペレーションを最後に実行したときに NoReboot オプションが選択されていたことを意味します。

    注記

    Patch Manager 外にインストールされたパッチは、ステータスが INSTALLED_PENDING_REBOOT になることはありません。

上記 2 つの場合にインスタンスを再起動すると、更新されたパッケージがメモリからフラッシュされ、パッチ適用と再起動の動作があらゆるオペレーティングシステムで一貫して維持されます。

NoReboot

NoReboot オプションを選択すると、Patch Manager が Install オペレーション中にパッチをインストールした場合でも、インスタンスは再起動されません。このオプションは、パッチ適用後にインスタンスを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがインスタンスで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、インスタンスの再起動のタイミングをより詳細に制御する場合にも役立ちます。

注記

パッチがインストールされている場合に NoReboot オプションを選択すると、ステータス InstalledPendingReboot がパッチに割り当てられます。ただし、インスタンス自体は Non-Compliant としてマークされます。再起動が発生し、Scan 操作が実行されると、インスタンスのステータスは Compliant に更新されます。

パッチのインストール追跡ファイル: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、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

パラメータ名: BaselineOverride

使用: オプション。

BaselineOverride パラメータを使用して、実行時にパッチ適用設定を定義できます。このベースラインオーバーライドは、S3 バケット内の JSON オブジェクトとして維持されます。これにより、パッチ適用操作で、デフォルトのパッチベースラインのルールを適用する代わりに、ホストオペレーティングシステムに一致する指定されたベースラインが使用されるようにします。

BaselineOverride パラメータの使用方法の詳細については、「BaselineOverride パラメータの使用」を参照してください。