View a markdown version of this page

用於修補的 SSM 命令文件:AWS-RunPatchBaselineAssociation - AWS Systems Manager

• 2026 年 4 月 30 日之後將不再提供 AWS Systems Manager CloudWatch Dashboard。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板,就像現在一樣。如需詳細資訊,請參閱 Amazon CloudWatch Dashboard 文件

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

用於修補的 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 主要適用於使用 Quick Setup ( AWS Systems Manager中的工具) 建立的 State Manager 關聯。尤其是,當您使用 Quick Setup 主機管理組態類型時,如果您選擇 Scan instances for missing patches daily (每天掃描執行個體查看是否遺漏修補程式),則系統會使用 AWS-RunPatchBaselineAssociation 進行操作。

    不過,在大多數情況下,當設定自己的修補操作時,您應該選擇 AWS-RunPatchBaselineAWS-RunPatchBaselineWithHooks,而不是 AWS-RunPatchBaselineAssociation

  • 使用 AWS-RunPatchBaselineAssociation 文件時,您可以在文件的 BaselineTags 參數欄位指定標籤金鑰對。如果您的 中的自訂修補程式基準 AWS 帳戶 共用這些標籤, Patch Manager中的工具會在目標執行個體上執行時使用該標記的基準 AWS Systems Manager,而不是目前為作業系統類型指定的「預設」修補程式基準。

    注意

    如果您選擇使用修補操作中的 AWS-RunPatchBaselineAssociation,而不是使用 Quick Setup 的設定,並且您想要使用其選用 BaselineTags 參數,則必須提供部分額外的許可給執行個體設定檔,用於 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。如需詳細資訊,請參閱參數名稱:BaselineTags

    以下兩種格式對 BaselineTags 參數都是有效的:

    Key=tag-key,Values=tag-value

    Key=tag-key,Values=tag-value1,tag-value2,tag-value3

    重要

    標籤索引鍵和值不能包含下列字元:反引號 (`)、單引號 (')、雙引號 (") 和美元符號 ($)。

  • AWS-RunPatchBaselineAssociation 執行時收集的修補程式合規資料會使用 PutComplianceItems API 命令,而不是 PutInventory 命令 (由 AWS-RunPatchBaseline 使用) 進行記錄。這種差異表示根據特定關聯存放和報告的修補程式合規資訊。不會覆寫在此關聯之外產生的修補程式合規資料。

  • 執行 AWS-RunPatchBaselineAssociation 後報告的修補程式合規資訊指出執行個體是否合規。它不包含修補程式層級詳細資訊,如 following 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 會傳回錯誤訊息,指出只有一個修補基準可以使用該鍵值對標記,以便繼續操作。

注意

在 Linux 節點上,我們會使用每個節點類型的適當套件管理工具來安裝套件:

  • Amazon Linux 2、Oracle Linux 和 RHEL 執行個體使用 YUM。針對 YUM 操作,Patch Manager 需要 Python 2.6 或更新版本的支援版本 (2.6 - 3.12)。Amazon Linux 2023 使用 DNF。針對 DNF 操作,Patch Manager 需要 Python 2Python 3 的支援版本 (2.6 - 3.12)。

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

在掃描完成後或在所有已核准且適用的更新已安裝後,並視需要重新啟動之後,會在執行個體上產生修補程式合規資訊,並回報修補程式管理員。

注意

如果在 AWS-RunPatchBaselineAssociation 文件中將 RebootOption 參數設定為 NoReboot,則在執行 Patch Manager 後不會重新啟動執行個體。如需詳細資訊,請參閱參數名稱:RebootOption

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

AWS-RunPatchBaselineAssociation 參數

AWS-RunPatchBaselineAssociation 支援五個參數。OperationAssociationId 是必要參數。InstallOverrideListRebootOptionBaselineTags 是選用參數。

參數名稱:Operation

用量:必要。

選項Scan | Install

Scan

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

安裝

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

注意

如果在 Patch Manager 更新執行個體之前已安裝基準規則指定的修補程式,系統可能無法如預期重新開機。當使用者手動安裝修補程式,或由其他程式自動安裝 (例如 Ubuntu Server 上的 unattended-upgrades 套件) 時,就會發生這種情況。

參數名稱:BaselineTags

用量:選用。

BaselineTags 是唯一的標籤鍵值對,您可以選擇並指派給個別自訂修補基準。您可以為此參數指定一或多個值。以下兩種格式都是有效的:

Key=tag-key,Values=tag-value

Key=tag-key,Values=tag-value1,tag-value2,tag-value3

重要

標籤索引鍵和值不能包含下列字元:反引號 (`)、單引號 (')、雙引號 (") 和美元符號 ($)。

BaselineTags 值是 Patch Manager 使用的唯一 ID (GUID),確保在單一操作中修補的一組執行個體皆有一組完全相同的核准修補程式。修補操作執行時,Patch Manager 會檢查作業系統類型的修補基準是否已使用您為 BaselineTags 指定的相同鍵值對進行標記。如果有相符項目,則會使用此自訂修補基準。如果沒有相符項目,則會根據針對修補操作指定的任何修補程式群組來識別修補基準。如果沒有,則會使用該作業系統的 AWS 受管預先定義修補程式基準。

額外的許可要求

如果您使用修補操作中的 AWS-RunPatchBaselineAssociation,而不是使用 Quick Setup 的設定,並且您想要使用其選用 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" }

使用您要為其提供存取權之修補基準的 Amazon Resource Name (ARN) 取代 patch-baseline-arn,格式為 arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE

參數名稱:AssociationId

用量:必要。

AssociationId 是 State Manager ( AWS Systems Manager中的工具) 中的現有關聯的 ID。它由 Patch Manager 使用,將合規資料新增至指定的關聯。此關聯與在 Quick Setup 中建立的主機管理組態中啟用的修補程式 Scan 操作有關。藉由傳送修補結果作為關聯合規資料而非庫存合規資料,不會在修補操作之後覆寫執行個體的現有庫存合規資訊,也不會複寫其他關聯 ID。如果您還沒有想要使用的關聯,則可以透過執行 create-association 命令建立關聯。例如:

Linux & macOS
aws ssm create-association \ --name "AWS-RunPatchBaselineAssociation" \ --association-name "MyPatchHostConfigAssociation" \ --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \ --parameters "Operation=Scan" \ --schedule-expression "cron(0 */30 * * * ? *)" \ --sync-compliance "MANUAL" \ --region us-east-2
Windows Server
aws ssm create-association ^ --name "AWS-RunPatchBaselineAssociation" ^ --association-name "MyPatchHostConfigAssociation" ^ --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^ --parameters "Operation=Scan" ^ --schedule-expression "cron(0 */30 * * * ? *)" ^ --sync-compliance "MANUAL" ^ --region us-east-2

參數名稱:InstallOverrideList

用量:選用。

使用 InstallOverrideList,您可以將 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL 指定至要安裝的修補程式清單。此修補程式安裝清單 (以 YAML 格式維護) 會覆寫目前預設修補基準指定的修補程式。這可讓您更精密地控制哪些修補程式將安裝於您的執行個體。

重要

InstallOverrideList 檔案名稱不能包含下列字元:反引號 (`)、單引號 (')、雙引號 (") 和美元符號 ($)。

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

在 Linux & macOS受管節點上, 中指定的修補程式只會InstallOverrideList套用為已安裝在節點上的套件更新。如果 InstallOverrideList包含目前未安裝在節點上之套件的修補程式,則不會安裝這些修補程式。

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

有效的 URL 格式

注意

如果您的檔案存放在公開可用的儲存貯體中,則可以指定 https URL 格式或 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。如果您的檔案存放在私有儲存貯體中,則必須指定 Amazon Simple Storage Service (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。有關驗證工具的選項,請執行 Web 搜尋「yaml 格式驗證工具」。

  • Microsoft Windows

    id

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

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

  • Linux

    id

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

    標題

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

    YUM/Red Hat Enterprise Linux (RHEL):

    {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,並回報為「Failed-NonCompliant」。

其他欄位

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

範例修補程式清單

  • 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 2

    patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '39.11.4-26.P2.amzn2.5.2' id: 'glibc*' - id: 'dhclient*' title: '*4.2.5-58.amzn2' - id: 'dhcp*' title: '*4.2.5-77.amzn2'
  • 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

重要

NoReboot 選項只會防止作業系統層級的重新啟動。服務層級的重新啟動仍然可能在修補程序中發生。例如,Docker 更新後,即使啟用了 NoReboot,Amazon Elastic Container Service 等相依服務也可能自動重新啟動。如果您有不能中斷的重要服務,請考慮採取其他措施,例如暫時從服務中移除執行個體或在維護時段期間排程修補。

重要

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

使用 Patch Manager 進行修補時所使用的基礎命令使用 yumdnf 命令。因此,相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊,請參閱《Amazon EMR 管理指南》中的使用 Amazon EMR 的預設 AMI 一節。

RebootIfNeeded

當您選擇 RebootIfNeeded 選項時,執行個體在下列情況下會重新開機:

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

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

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

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

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

NoReboot

當您選擇 NoReboot 選項時,即使執行個體在 Install 作業期間安裝了修補程式,Patch Manager 也不會重新啟動執行個體。如果您知道您的執行個體在套用修補程式之後不需要重新啟動,或是您在執行個體上執行的應用程式或程序不應因於修補操作重新啟動而中斷,則此選項非常有用。當您想要進一步控制執行個體重新啟動的時間時 (例如使用維護時段),此選項也很有用。

修補程式安裝追蹤檔案:若要追蹤修補程式安裝,特別是自上次系統重新啟動後已安裝的修補程式,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