SSM 修補的命令文件: AWS-RunPatchBaseline - AWS Systems Manager

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

SSM 修補的命令文件: AWS-RunPatchBaseline

AWS Systems Manager 支援 AWS-RunPatchBaseline,適用於 的 Systems Manager 文件 (SSM 文件) Patch Manager, 的功能 AWS Systems Manager。SSM 本文件會針對安全相關和其他類型的更新,對受管節點執行修補操作。執行文件時,如果未指定修補程式群組,則會使用指定為作業系統類型之「預設」的修補基準。否則,它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊,請參閱 修補程式群組

您可以使用 AWS-RunPatchBaseline 文件以套用適用於作業系統和應用程式的修補程式。(開啟 Windows Server,應用程式支援僅限於 Microsoft 發行之應用程式的更新。)

本文件支援 Linux、macOS 和 Windows Server 受管節點。此文件會為各個平台執行適當的動作。

注意

Patch Manager 也支援舊版SSM文件 AWS-ApplyPatchBaseline。不過,此文件僅支援 Windows 受管節點上的修補。我們建議您AWS-RunPatchBaseline改用 ,因為它支援 Linux 上的修補,macOS 和 Windows Server 受管節點。2.0.834.0 版或更新版本 SSM Agent 是必要項目,才能使用AWS-RunPatchBaseline文件。

Windows Server

開啟 Windows Server 受管節點,AWS-RunPatchBaseline文件會下載並調用 PowerShell 模組,進而下載適用於受管節點的修補程式基準快照。此修補程式基準快照包含已批准的修補程式清單,這些修補程式清單是針對 Windows Server Update Services (WSUS) 伺服器查詢修補程式基準所編譯。此清單會傳遞至 Windows Update API,該版本會視需要控制下載和安裝核准的修補程式。

Linux

在 Linux 受管節點上,AWS-RunPatchBaseline 文件會叫用 Python 模組,進而下載套用至受管節點的修補基準快照。此修補基準快照使用已定義的規則,以及已核准與已封鎖的修補程式清單,為各個節點類型推動適當的套件管理員:

  • Amazon Linux 1、Amazon Linux 2、CentOS 、Oracle Linux 和 RHEL 7 個受管節點使用 YUM。對於YUM操作,Patch Manager 需要 Python 2.6或更新版本支援的版本 (2.6 - 3.10)。

  • RHEL 8 個受管節點使用 DNF。對於DNF操作,Patch Manager 需要 Python 2Python 3(2.6 - 3.10) 的支援版本。(預設不會在 上安裝版本 RHEL 8. 您必須手動安裝其中一個。)

  • Debian Server, Raspberry Pi OS 和 Ubuntu Server 執行個體使用 APT。對於APT操作,Patch Manager 需要支援的 版本 Python 3(3.0 - 3.10)。

  • SUSE Linux Enterprise Server 受管節點使用 Zypper。對於 Zypper 操作,Patch Manager 需要 Python 2.6或更新版本支援的版本 (2.6 - 3.10)。

macOS

開啟 macOS 受管節點,AWS-RunPatchBaseline文件會叫用 Python 模組,進而下載適用於受管節點的修補程式基準快照。接下來,Python 子程序會叫用節點上的 AWS Command Line Interface (AWS CLI),以擷取指定套件管理員的安裝和更新資訊,並為每個更新套件驅動適當的套件管理員。

每個快照都是 AWS 帳戶、修補程式群組、作業系統和快照 ID 特有的。快照會透過預先簽章的 Amazon Simple Storage Service (Amazon S3) 交付URL,該 會在建立快照後 24 小時過期。不過,在 URL到期後,如果您想要將相同的快照內容套用至其他受管節點,您可以在建立快照後URL最多 3 天內產生新的預先簽章 Amazon S3。若要這麼做,請使用 get-deployable-patch-snapshot-for-instance 命令。

安裝所有核准且適用的更新後,視需要執行重新啟動,在受管節點上產生修補程式合規資訊,並回報給 Patch Manager.

注意

如果在NoRebootAWS-RunPatchBaseline文件中將 RebootOption 參數設定為 ,則受管節點在 Patch Manager 執行。如需詳細資訊,請參閱參數名稱:RebootOption

如需有關檢視修補程式合規資料的詳細資訊,請參閱關於修補程式合規

AWS-RunPatchBaseline 參數

AWS-RunPatchBaseline 支援五個參數。Operation 參數是必要參數。InstallOverrideListBaselineOverrideRebootOption 參數為選用。 技術上Snapshot-ID為選用,但建議您在維護時段AWS-RunPatchBaseline之外執行時為其提供自訂值。Patch Manager 可在文件作為維護時段操作的一部分執行時自動提供自訂值。

參數名稱:Operation

用量:必要。

選項Scan | Install

Scan

當您選擇 Scan選項時, 會AWS-RunPatchBaseline判斷受管節點的修補程式合規狀態,並將此資訊回報給 Patch Manager。 Scan 不會提示要安裝的更新或要重新啟動的受管節點。反之,此操作會識別遺漏了哪些已核准且適用於節點的更新。

安裝

當您選擇 Install 選項,AWS-RunPatchBaseline 會嘗試安裝受管節點上遺漏的已核准且適用的更新。在 Install 操作中產生的修補程式合規資訊不會列出任何遺失的更新,但如果因為任何原因導致未成功安裝更新,則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時,節點將重新啟動,以確保安裝並啟動更新。(例外:如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為 ,則受管節點在 Patch Manager 執行。如需詳細資訊,請參閱 參數名稱:RebootOption)。

注意

如果基準規則指定的修補程式在 之前安裝 Patch Manager 會更新受管節點,系統可能無法如預期重新啟動。當修補程式由使用者手動安裝或由其他程式自動安裝時,例如 上的unattended-upgrades套件時,可能會發生這種情況 Ubuntu Server.

參數名稱:AssociationId

用量:選用。

AssociationId 是 中現有關聯的 ID State Manager, 的功能 AWS Systems Manager。它由 使用 Patch Manager 將合規資料新增至指定的關聯。此關聯與 中修補程式政策中設定的修補操作有關 Quick Setup.

注意

使用 AWS-RunPatchBaseline 時,如果提供 AssociationId 值時發生修補程式政策基準覆寫,則修補會以 PatchPolicy 操作的形式完成,且 AWS:ComplianceItem 中報告的 ExecutionType 值也為 PatchPolicy。如果未提供任何 AssociationId 值,則會以 Command 操作形式完成修補,而且提交的 AWS:ComplianceItem 中報告的 ExecutionType 值也為 Command

如果您還沒有要使用的關聯,您可以執行 來建立關聯 create-association 命令。

參數名稱:Snapshot ID

用量:選用。

Snapshot ID 是 使用的唯一 ID (GUID) Patch Manager 以確保一組在單一操作中修補的受管節點都具有完全相同的核准修補程式集。雖然此參數定義為選用,但我們的最佳實務建議取決於您是否會在維護時段中執行 AWS-RunPatchBaseline,如下表所述。

AWS-RunPatchBaseline 最佳實務
Mode 最佳實務 詳細資訊
在維護時段內執行 AWS-RunPatchBaseline 請勿提供快照 ID。Patch Manager 會為您提供它。

若您使用維護時段執行 AWS-RunPatchBaseline,您不應提供自己產生的快照 ID。在此案例中,Systems Manager 會根據維護時段執行 ID 提供GUID值。這可確保維護時段中所有 AWS-RunPatchBaseline 呼叫皆使用正確的 ID。

如果您在此情況下指定值,則請注意修補基準的快照可能不會保留超過 3 天。之後,即使您在快照過期後指定相同的 ID,仍將會產生新的快照。

在維護時段外執行 AWS-RunPatchBaseline 產生並指定快照 ID 的自訂GUID值。1

如果您不是使用維護時段執行 AWS-RunPatchBaseline,我們建議您為每個修補基準產生並指定唯一的快照 ID,特別是如果您在相同的操作中,在多個受管節點上執行 AWS-RunPatchBaseline 文件時。如果您在此情況下沒有指定 ID,Systems Manager 將為命令傳送至的每個受管節點產生不同的快照 ID。這可能會導致在受管節點間指定不同的修補程式集合。

例如,假設您正在直接透過 執行AWS-RunPatchBaseline文件 Run Command、 和 的功能 AWS Systems Manager,以 50 個受管節點群組為目標。指定自訂快照 ID 會產生單一基準快照,用於評估和修補所有節點,以確保它們最終處於一致的狀態。

1 您可以使用任何能夠產生 的工具GUID來產生 Snapshot ID 參數的值。例如,在 中 PowerShell,您可以使用 New-Guid cmdlet 產生格式GUID為 的 12345699-9405-4f69-bc5e-9315aEXAMPLE

參數名稱:InstallOverrideList

用量:選用。

使用 InstallOverrideList,您可以將 https URL或 Amazon S3 路徑樣式指定URL至要安裝的修補程式清單。此修補程式安裝清單以 YAML 格式維護,會覆寫目前預設修補程式基準所指定的修補程式。這可讓您更精密地控制哪些修補程式將安裝於您的受管節點。

使用 InstallOverrideList 參數時的修補操作行為在 Linux 和 之間不同 macOS 受管節點和 Windows Server 受管節點。在 Linux 和 上 macOS, Patch Manager 會嘗試套用InstallOverrideList修補程式清單中包含的修補程式,這些修補程式存在於節點上啟用的任何儲存庫中,無論修補程式是否符合修補程式基準規則。開啟 Windows Server 不過,只有在修補程式清單中的InstallOverrideList修補程式也符合修補程式基準規則時,才會套用這些修補程式。

請注意,合規報告根據修補基準中的指定來反映修補程式狀態,而非您在 InstallOverrideList 合規清單中的指定。換言之,掃描操作會忽略 InstallOverrideList 參數。這是為了確保合規報告根據政策而非已核准用於特定修補操作的內容,來持續反映修補程式狀態。

如需如何使用 InstallOverrideList 參數依不同的維護時段排程將不同類型的修補程式套用至目標群組的說明,同時繼續單一修補基準,請參閱在 AWS-RunPatchBaseline或 中使用 InstallOverrideList 參數的範例案例 AWS-RunPatchBaselineAssociation

有效URL格式

注意

如果您的檔案存放在公開可用的儲存貯體中,您可以指定 https URL 格式或 Amazon S3 路徑樣式 URL。如果您的檔案存放在私有儲存貯體中,您必須指定 Amazon S3 路徑樣式 URL。

  • https URL 格式:

    https://s3.aws-api-domain/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檔案中提供其他欄位,但在修補操作期間會忽略這些欄位。

此外,建議您先驗證YAML檔案格式是否有效,再新增或更新 S3 儲存貯體中的清單。如需有關 YAML 格式的詳細資訊,請參閱 https://yaml.org。有關驗證工具的選項,請執行 Web 搜尋「yaml 格式驗證工具」。

Linux
id

id 欄位是必要的。利用它來使用套件名稱和架構以指定修補程式。例如:'dhclient.x86_64'。您可以在 id 中使用萬用字元以指示多個套件。例如:'dhcp*''dhcp*1.*'

Title

標題欄位是選用的,但是在 Linux 系統上,它提供額外的篩選功能。如果您使用標題,它應包含套件版本資訊,並使用以下其中一種格式:

YUM/SUSE Linux Enterprise Server (SLES):

{name}.{architecture}:{epoch}:{version}-{release}

APT

{name}.{architecture}:{version}

對於 Linux 修補程式標題,您可以在任何位置使用一或多個萬用字元以擴大相符套件的數量。例如:'*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 版將遭到封鎖,並報告為「失敗」NonCompliant。

Windows Server
id

id 欄位是必要的。使用它來指定使用 Microsoft 知識庫 IDs(例如 KB2736693) 和 Microsoft 安全公告 IDs(例如 MS17-023) 的修補程式。

您想在 Windows 修補程式清單中提供的任何其他欄位都是選用的,並僅供自己參考。您可以使用其他欄位,例如標題分類嚴重性等,提供有關指定的修補程式的更多詳細資訊。

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 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'
  • 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。請務必選取適用於您使用案例的正確選項。例如,如果您的受管節點必須立即重新啟動才能完成組態程序,則請選擇 RebootIfNeeded。或者,如果您需要維持受管節點的可用性,直到排定的重新啟動時間,則請選擇 NoReboot

重要

我們不建議使用 Patch Manager 用於修補 Amazon 中的叢集執行個體 EMR(先前稱為 Amazon Elastic) MapReduce。特別是,請勿為 RebootOption 參數選取 RebootIfNeeded 選項。(此選項可在用於修補 AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation和 的SSM命令文件中使用AWS-RunPatchBaselineWithHooks。)

使用 修補的基礎命令 Patch Manager 使用 yumdnf命令。因此,相關操作會因套件的安裝方式而導致不相容。如需在 Amazon EMR叢集上更新軟體的偏好方法的相關資訊,請參閱使用預設 AMI 適用於 Amazon EMRAmazon EMR管理指南。

RebootIfNeeded

當您選擇 RebootIfNeeded 選項時,受管節點在下列情況下會重新啟動:

  • Patch Manager 已安裝一或多個修補程式。

    Patch Manager 不會評估修補程式是否需要重新啟動。即使修補程式不需要重新開機,系統也會重新開機。

  • Patch Manager 會在Install操作INSTALLED_PENDING_REBOOT期間偵測一或多個狀態為 的修補程式。

    INSTALLED_PENDING_REBOOT 狀態可能表示上次執行Install操作時NoReboot已選取 選項,或已在 之外安裝修補程式 Patch Manager 自上次重新啟動受管節點以來。

在這兩種情況下重新啟動受管節點,可確保更新的套件會從記憶體中清除,並在所有作業系統中保持修補和重新啟動行為一致。

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 參數