• 2026 年 4 月 30 日之後， AWS Systems Manager CloudWatch Dashboard 將不再可用。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板，就像現在一樣。如需詳細資訊，請參閱 [Amazon CloudWatch Dashboard 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# AWS Systems Manager Patch Manager
Patch Manager中的工具 會使用安全相關更新和其他類型的更新 AWS Systems Manager，自動修補受管節點的程序。
**注意**
Systems Manager 在 Quick Setup ( AWS Systems Manager中的工具) 中提供*修補程式政策*支援。使用修補程式政策，是設定修補操作的建議方法。使用單一修補程式政策組態，您可以定義為組織中所有區域的所有帳戶、僅您選擇的帳戶和區域或者單一帳戶-區域對進行修補。如需詳細資訊，請參閱[Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
您可以使用 Patch Manager 以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發行的應用程式更新。) 您可以使用 Patch Manager 在 Windows 節點上安裝 Service Pack，並在 Linux 節點上執行次要版本升級。您可以依據作業系統類型，修補 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體、邊緣裝置或內部部署伺服器與虛擬機器 (VM)。這包括數個作業系統的支援版本，如 [Patch Manager 先決條件](patch-manager-prerequisites.md) 中所列。您可以掃描執行個體，僅查看遺漏的修補程式報告，或者掃描並自動安裝所有遺漏的修補程式。若要開始使用 Patch Manager，請開啟 [Systems Manager 主控台](https://console.aws.amazon.com//systems-manager/patch-manager)。在導覽窗格中，選擇 **Patch Manager**。
AWS 在 中提供修補程式之前， 不會對其進行測試Patch Manager。此外， Patch Manager 不支援升級主要版本的作業系統，例如 Windows Server 2016 年至 Windows Server 2019 年，或 Red Hat Enterprise Linux(RHEL) 7.0 至 RHEL 8.0 年。
對於報告修補程式嚴重性級別的 Linux 作業系統類型，Patch Manager 使用軟體發布者為更新通知或個別修補程式報告的嚴重性級別。Patch Manager 不會從第三方來源推導出嚴重性級別，例如[通用漏洞評分系統](https://www.first.org/cvss/) (CVSS)，或者[美國國家漏洞資料庫](https://nvd.nist.gov/vuln) (NVD) 發行的指標。
## Patch Manager 如何為我的組織帶來益處？
Patch Manager 以自動化程序透過安全相關更新和其他類型的更新來修補受管節點。其提供了數種關鍵優勢：
+ **集中式修補控制** – 使用修補程式政策，您可以為組織中所有區域的所有帳戶、特定帳戶和區域或單一帳戶區域對設定重複修補操作。
+ **靈活的修補操作** – 您可以選擇掃描執行個體，僅查看遺漏的修補程式報告，或者掃描並自動安裝所有遺漏的修補程式。
+ **全面合規報告** – 掃描操作後，您可以檢視有關哪些受管節點不符合修補程式合規要求，以及缺少哪些修補程式的詳細資訊。
+ **跨平台支援** – Patch Manager 支援多個作業系統，包括各種 Linux 發行版本、macOS 和 Windows Server。
+ **自訂修補基準** – 您可以透過自訂修補基準，指定哪些修補程式已核准進行安裝，來定義組織的修補程式合規。
+ **與其他 AWS 服務的整合** – Patch Manager 整合 AWS Organizations AWS Security Hub CSPM、 AWS CloudTrail和 AWS Config ，以增強管理和安全性。
+ **確定性升級** – 透過適用於 Amazon Linux 2023 等作業系統的版本控制儲存庫支援確定性升級。
## 誰應該使用Patch Manager？
Patch Manager 專為以下受眾設計：
+ 需要維持其受管節點機群中修補程式合規性的 IT 管理員
+ 需要了解其基礎設施中修補程式合規狀態的營運經理
+ 想要大規模實作自動化修補解決方案的雲端架構師
+ 需要將修補整合到其操作工作流程中的 DevOps 工程師
+ 擁有多帳戶/多區域部署、需要集中式修補程式管理的組織
+ 負責維護 AWS 受管節點、邊緣裝置、內部部署伺服器和虛擬機器的安全狀態和運作狀態的任何人
## Patch Manager有哪些主要功能？
Patch Manager 提供數個關鍵功能：
+ **修補程式政策** – 透過與 整合，使用單一政策設定跨多個 AWS 帳戶 和 區域的修補操作 AWS Organizations。
+ **自訂修補基準** – 定義在修補程式發行後的數日內自動核准修補程式的規則，以及已核准和拒絕的修補程式清單。
+ **多種修補方法** – 從修補政策、維護時段或隨需「立即修補」操作中進行選擇，以滿足您的特定需求。
+ **合規報告** – 產生修補程式合規狀態的詳細報告，且該類報告能以 CSV 格式傳送至 Amazon S3 儲存貯體。
+ **跨平台支援** – 跨 Windows Server、Linux 的各種發行版本和 macOS 修補作業系統和應用程式。
+ **排程彈性** – 使用自訂 CRON 或 Rate 表達式設定掃描和安裝修補程式的不同排程。
+ **Lifecycle hook** – 使用 Systems Manager 文件在修補操作前後執行自訂指令碼。
+ **安全重點** – 依預設，Patch Manager 會專注於安全相關更新，而不是安裝所有可用的修補程式。
+ **速率控制** – 設定修補操作的並行和錯誤閾值，以將操作影響降至最低。
## Patch Manager 中的合規是什麼？
Systems Manager 機群中構成受管節點*修補程式合規性*的基準，並非由作業系統 AWS(OS) 供應商或第三方定義，例如安全諮詢公司。
反之，您可以在*修補基準*中定義組織或帳戶中受管節點的修補程式合規的意義。修補基準是一種組態，可指定必須在受管節點上安裝哪些修補程式的規則。當受管節點與您在修補基準中指定的核准條件相符的所有修補程式處於最新狀態時，即為修補程式合規。
請注意，與修補基準*合規*並不表示受管節點一定是*安全的*。合規表示由修補基準定義的*可用*和*經核准的*修補程式都已安裝在節點上。受管節點的整體安全性取決於 Patch Manager 範圍之外的許多因素。如需詳細資訊，請參閱[AWS Systems Manager 中的安全性](security.md)。
每個修補基準都是特定支援的作業系統 (OS) 類型 (例如 Red Hat Enterprise Linux (RHEL)、macOS 或 Windows Server) 的組態。修補基準可以為所有支援的作業系統版本定義修補規則，或僅為您指定的作業系統版本 (例如 RHEL 7.8 和 RHEL 9.3) 定義修補規則。
在修補基準中，您可以指定特定分類和嚴重性等級的所有修補程式均得到核准可進行安裝。例如，您可以包含分類為 `Security` 的所有修補程式，但排除其他分類，例如 `Bugfix` 或 `Enhancement`。您也可以包含嚴重性為 `Critical` 的所有修補程式，並排除其他修補程式，例如 `Important` 和 `Moderate`。
您也可以在修補基準中明確定義修補程式，方法是將其 ID 新增至要核准或拒絕的特定修補程式清單，例如 Windows Server 的 `KB2736693` 或 Amazon Linux 2023 (AL2023) 的 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`。您可以選擇性地指定在修補程式可用之後等待修補的特定天數。對於 Linux 和 macOS，您可以選擇為合規指定修補程式的外部清單 (安裝覆寫清單)，而不是修補基準規則定義的修補程式清單。
執行修補操作時，Patch Manager 會將當前套用至受管節點的修補程式與應當根據修補基準或安裝複寫清單中設定之規則來進行套用的修補程式進行比較。您可以選擇讓 Patch Manager 僅顯示遺失修補程式的報告 (`Scan` 操作)，亦可選擇讓 Patch Manager 自動安裝所找到的受管節點中遺失的全部修補程式 (`Scan and install` 操作)。
**注意**
修補程式合規資料代表最新成功修補操作的point-in-time快照。每個合規報告都包含一個擷取時間，可識別何時計算合規狀態。檢閱合規資料時，請考慮擷取時間，以判斷操作是否如預期執行。
Patch Manager 提供預先定義的修補基準，可用於修補操作；不過，這些預先定義的組態會以範例的形式提供，而非建議的最佳實務。建議您建立自己的自訂修補基準，以更好地控制哪些要素構成機群的修補程式合規。
如需有關修補基準的詳細資訊，請參閱下列主題：
+ [預先定義和自訂的修補基準](patch-manager-predefined-and-custom-patch-baselines.md)
+ [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)
+ [檢視 AWS 預先定義的修補程式基準](patch-manager-view-predefined-patch-baselines.md)
+ [使用自訂修補基準](patch-manager-manage-patch-baselines.md)
+ [使用修補程式合規報告](patch-manager-compliance-reports.md)
## 主要元件
開始使用 Patch Manager 工具之前，您應該先熟悉工具修補操作的一些主要元件和功能。
**修補基準**
Patch Manager 會使用*修補基準*，其中包含在修補程式發行後的數日內自動核准修補程式等規則，以及已核准和拒絕的修補程式可選清單。執行修補操作時，Patch Manager 會將當前套用至受管節點的修補程式與應當根據修補基準中設定之規則來進行套用的修補程式進行比較。您可以選擇讓 Patch Manager 僅顯示遺失修補程式的報告 (`Scan` 操作)，亦可選擇讓 Patch Manager 自動安裝所找到的受管節點中遺失的全部修補程式 (`Scan and install` 操作)。
**修補操作方法**
Patch Manager 目前提供了四種執行 `Scan` 和 `Scan and install` 操作的方法：
+ **（建議） 在 中設定的修補程式政策 Quick Setup** – 根據與 的整合 AWS Organizations，單一修補程式政策可以定義整個組織的修補排程和修補程式基準，包括多個 AWS 帳戶 和所有 AWS 區域 這些帳戶在其中操作。修補程式政策也可以只針對組織中的某些組織單位 (OU)。您可以使用單一修補程式政策依照不同的排程進行掃描和安裝。如需詳細資訊，請參閱[使用 Quick Setup 修補程式政策設定組織中執行個體的修補](quick-setup-patch-manager.md)及[Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
+ **在 中設定的主機管理選項 Quick Setup** – 與 整合也支援主機管理組態 AWS Organizations，因此可以對整個 Organization 執行修補操作。不過，此選項僅限於使用目前預設修補基準掃描遺失的修補程式，並在合規報告中提供結果。此操作方法無法安裝修補程式。如需詳細資訊，請參閱[使用 Quick Setup 設定 Amazon EC2 主機管理](quick-setup-host-management.md)。
+ **用於執行修補程式 `Scan` 或 `Install` 任務的維護時段** – 在稱為 Maintenance Windows 的 Systems Manager 工具中設定的維護時段，可以設定為依照您定義的排程執行不同類型的任務。Run Command 類型的任務可用來在您選擇的一組受管節點上執行 `Scan` 或 `Scan and install` 任務。每個維護時段任務只能以 AWS 帳戶單一AWS 區域 配對中的受管節點為目標。如需詳細資訊，請參閱[教學課程：使用主控台建立修補維護時段](maintenance-window-tutorial-patching.md)。
+ **Patch Manager 中的隨需**立即修補**操作**：**立即修補**選項可讓您在需要盡快修補受管節點時略過排程設定。使用 **Patch now** (立即修補)，可指定是否執行 `Scan` 或 `Scan and install` 操作，以及要在哪些受管節點上執行操作。您也可以選擇在修補操作期間，將 Systems Manager 文件 (SSM 文件) 作為 lifecycle hook 執行。每個**修補程式現在**只能以 AWS 帳戶單一AWS 區域 配對中的受管節點為目標。如需詳細資訊，請參閱[隨需修補受管節點](patch-manager-patch-now-on-demand.md)。
**合規報告**
`Scan` 操作完成後，您可以使用 Systems Manager 主控台來檢視哪些受管節點不符合修補程式規範，以及每個節點遺失了哪些修補程式。您也可以產生可傳送至所選 Amazon Simple Storage Service (Amazon S3) 儲存貯體的修補程式合規報告，格式為 .csv。您可以產生一次性報告，或定期產生報告。對於單一受管節點，報告包含節點之所有修補程式的詳細資訊。對於所有受管節點的報告，只會提供缺少修補程式數量的摘要。產生報告後，您可以使用 Amazon Quick 之類的工具來匯入和分析資料。如需詳細資訊，請參閱[使用修補程式合規報告](patch-manager-compliance-reports.md)。
**注意**
透過使用修補程式政策產生之合規項的執行類型為 `PatchPolicy`。不是在修補程式政策操作中產生的合規項的執行類型為 `Command`。
**整合**
Patch Manager 與下列其他 整合 AWS 服務：
+ **AWS Identity and Access Management (IAM)** – 使用 IAM 控制哪些使用者、群組和角色可以存取 Patch Manager 操作。如需詳細資訊，請參閱 [AWS Systems Manager 搭配 IAM 的運作方式](security_iam_service-with-iam.md) 和[設定 Systems Manager 所需的執行個體許可](setup-instance-permissions.md)。
+ **AWS CloudTrail** – 使用 CloudTrail 記錄由使用者、角色或群組啟動之修補操作事件的可稽核歷史記錄。如需詳細資訊，請參閱[使用 記錄 AWS Systems Manager API 呼叫 AWS CloudTrail](monitoring-cloudtrail-logs.md)。
+ **AWS Security Hub CSPM** – 來自 的修補程式合規資料Patch Manager可以傳送到 AWS Security Hub CSPM。Security Hub CSPM 可讓您全面檢視高優先順序的安全提醒和合規狀態。它還會監控您的機群的修補狀態。如需詳細資訊，請參閱[Patch Manager 與 整合 AWS Security Hub CSPM](patch-manager-security-hub-integration.md)。
+ **AWS Config** – 在 中設定記錄 AWS Config ，以在Patch Manager儀表板中檢視 Amazon EC2 執行個體管理資料。如需詳細資訊，請參閱[檢視修補程式儀表板摘要](patch-manager-view-dashboard-summaries.md)。
**Topics**
+ [Patch Manager 如何為我的組織帶來益處？](#how-can-patch-manager-benefit-my-organization)
+ [誰應該使用Patch Manager？](#who-should-use-patch-manager)
+ [Patch Manager有哪些主要功能？](#what-are-the-main-features-of-patch-manager)
+ [Patch Manager 中的合規是什麼？](#patch-manager-definition-of-compliance)
+ [主要元件](#primary-components)
+ [Quick Setup中的修補程式政策組態](patch-manager-policies.md)
+ [Patch Manager 先決條件](patch-manager-prerequisites.md)
+ [Patch Manager 操作的運作方式](patch-manager-patching-operations.md)
+ [用於修補受管節點的 SSM 命令文件](patch-manager-ssm-documents.md)
+ [修補基準](patch-manager-patch-baselines.md)
+ [在 Amazon Linux 2 受管節點上使用 Kernel Live Patching](patch-manager-kernel-live-patching.md)
+ [透過主控台使用 Patch Manager 資源與合規](patch-manager-console.md)
+ [透過AWS CLI使用 Patch Manager 資源](patch-manager-cli-commands.md)
+ [AWS Systems ManagerPatch Manager 教學課程](patch-manager-tutorials.md)
+ [Patch Manager 疑難排解](patch-manager-troubleshooting.md)
# Quick Setup中的修補程式政策組態
AWS 建議使用*修補程式政策*為您的組織和 設定修補 AWS 帳戶。修補程式政策於 2022 年 12 月在 Patch Manager 中推出。
修補程式政策是您使用 Quick Setup ( AWS Systems Manager中的工具) 設定的組態。與先前設定修補的方法相比，修補程式政策可提供更廣泛且更集中的修補操作控制。修補程式政策可用於 [Patch Manager 支援的所有作業系統](patch-manager-prerequisites.md#pm-prereqs)，包括 Linux、macOS 和 Windows Server 的支援版本。如需建立修補程式政策的說明，請參閱[使用 Quick Setup 修補程式政策設定組織中執行個體的修補](quick-setup-patch-manager.md)。
## 修補程式政策的主要功能
請不要使用其他修補節點的方法，而是使用修補程式政策來利用這些主要功能：
+ **單一設定** – 使用維護時段或 State Manager 關聯來設定修補操作可能需要在 Systems Manager 主控台的不同部分中執行多項任務。使用修補程式政策，您可以在單一精靈中設定所有修補操作。
+ **多帳戶/多區域支援** – 使用 中的維護時段、State Manager關聯或**修補程式功能**Patch Manager，您僅限於以 AWS 帳戶單一AWS 區域 配對中的受管節點為目標。如果您使用多個帳戶和多個區域，則設定與維護任務可能需要大量的時間，因為您必須在每個帳戶-區域對中執行設定任務。不過，如果您使用 AWS Organizations，您可以設定一個修補程式政策，套用至所有 中所有 AWS 區域 受管節點 AWS 帳戶。或者，如果您進行了選擇，則修補程式政策只能套用至您選擇的帳戶和區域中的某些組織單位 (OU)。如果您進行了選擇，則修補程式政策也可套用至單一本機帳戶。
+ **組織層級的安裝支援** – Quick Setup 中的現有主機管理組態選項可支援受管節點的每日掃描，以確保修補程式的合規性。不過，此掃描會在預定時間完成，並且只會產生修補程式合規資訊。不會執行修補程式安裝。使用修補程式政策時，您可以指定不同的掃描和安裝排程。您也可以使用自訂 CRON 或 Rate 運算式來選擇這些操作的頻率和時間。例如，您可以每天掃描遺失的修補程式，以提供定期更新的合規資訊。但是，您的安裝排程可能每週只有一次，以避免不必要的停機時間。
+ **簡化的修補基準選取** – 修補程式政策仍包含修補基準，而且修補基準的設定方式沒有任何變更。不過，當您建立或更新修補程式政策時，您可以在單一清單中選取您要用於每個作業系統 (OS) 類型的 AWS 受管或自訂基準。您不需要在單獨的任務中為每個作業系統類型指定預設基準。
**注意**
當修補操作基於修補程式政策執行時，其會使用 `AWS-RunPatchBaseline` SSM 文件。如需詳細資訊，請參閱[用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
**相關資訊**
[使用 Systems Manager 在整個 AWS 組織中集中部署修補操作 Quick Setup](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/)(AWS 雲端操作和遷移部落格）
## 修補程式政策的其他差異
以下是使用修補程式政策而非先前設定修補的方法時需注意的一些其他差異：
+ **不需要修補程式群組** – 在先前的修補操作中，您可以標記屬於一個修補程式群組的多個節點，然後指定要用於該修補程式群組的修補基準。如果沒有定義修補程式群組，則 Patch Manager 會使用作業系統類型的當前預設修補基準來修補執行個體。使用修補程式政策，不再需要設定和維護修補程式群組。
**注意**
對於在 2022 年 12 月 22 日發布修補程式政策支援之前尚未使用修補程式群組的帳戶區域對，主控台中不支援修補程式群組功能。對於在此日期之前開始使用修補程式群組的帳戶區域對，修補程式群組功能仍然可用。
+ **「設定修補程式」頁面已移除** – 在發行修補程式政策之前，您可以在 **Configure patching** (設定修補程式) 頁面中指定要修補的節點、修補排程以及修補操作的預設值。此頁面已從 Patch Manager 中移除。這些選項現在已在修補程式政策中指定。
+ **沒有「立即修補」支援** - 隨需修補節點的功能仍僅限於一次單一 AWS 帳戶AWS 區域 對。如需相關資訊，請參閱[隨需修補受管節點](patch-manager-patch-now-on-demand.md)。
+ **修補程式政策和合規資訊** – 根據修補程式政策組態掃描受管節點是否合規時，即可提供合規資料供您使用。您可以使用與其他合規掃描方法相同的方式來檢視和使用資料。雖然您可以為整個組織或多個組織單位設定修補程式政策，但每個 AWS 帳戶AWS 區域 配對的合規資訊都會個別報告。如需詳細資訊，請參閱[使用修補程式合規報告](patch-manager-compliance-reports.md)。
+ **關聯合規狀態和修補程式政策**：Quick Setup 修補程式政策下受管節點的修補狀態符合該節點的 State Manager 關聯執行狀態。如果關聯執行狀態為 `Compliant`，受管節點的修補程式狀態也會標示為 `Compliant`。如果關聯執行狀態為 `Non-Compliant`，受管節點的修補程式狀態也會標示為 `Non-Compliant`。
## AWS 區域 支援修補程式政策
下列區域目前支援 Quick Setup 中的修補程式政策組態：
+ 美國東部 (俄亥俄) (us-east-2)
+ 美國東部 (維吉尼亞北部) (us-east-1)
+ 美國西部 (加利佛尼亞北部) (us-west-1)
+ 美國西部 (奧勒岡) (us-west-2)
+ 亞太區域 (孟買) (ap-south-1)
+ 亞太區域 (首爾) (ap-northeast-2)
+ 亞太地區 (新加坡) (ap-southeast-1)
+ 亞太地區 (雪梨) (ap-southeast-2)
+ 亞太地區 (東京) (ap-northeast-1)
+ 加拿大 (中部) (ca-central-1)
+ 歐洲 (法蘭克福) (eu-central-1)
+ 歐洲 (愛爾蘭) (eu-west-1)
+ 歐洲 (倫敦) (eu-west-2)
+ 歐洲 (巴黎) (eu-west-3)
+ 歐洲 (斯德哥爾摩) (eu-north-1)
+ 南美洲 (聖保羅) (sa-east-1)
# Patch Manager 先決條件
在 中使用 工具之前Patch Manager，請確定您已符合必要的先決條件 AWS Systems Manager。
**Topics**
+ [SSM Agent 版本](#agent-versions)
+ [Python 版本](#python-version)
+ [其他套件需求](#additional-package-requirements)
+ [與修補程式來源的連線](#source-connectivity)
+ [S3 端點存取](#s3-endpoint-access)
+ [在本機安裝修補程式的許可](#local-installation-permissions)
+ [Patch Manager 支援的作業系統](#supported-os)
## SSM Agent 版本
執行於您要以 Patch Manager 進行管理之受管節點的 SSM Agent 版本 2.0.834.0 或更新版本。
**注意**
當 Systems Manager 新增了新工具，或現有工具有更新時，會發行 SSM Agent 的更新版本。若未使用最新版本的 Agent，您的受管節點可能會無法使用 Systems Manager 中的各種工具及功能。因此，我們建議您讓機器的 SSM Agent 自動保持最新狀態。如需相關資訊，請參閱[自動化 SSM Agent 更新](ssm-agent-automatic-updates.md)。請訂閱 GitHub 上的 [SSM Agent 版本備註](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)頁面，以便接收有關 SSM Agent 更新的通知。
## Python 版本
對於 macOS和大多數 Linux 作業系統 OSs)， Patch Manager目前支援 Python 2.6 - 3.12 版。AlmaLinux、Debian Server 及 Ubuntu Server 作業系統需要 Python 3 的支援版本 (3.0 - 3.12)。
## 其他套件需求
對於 DNF 作業系統，解壓縮儲存庫資訊和修補程式檔案時可能需要 `xz`、 和 `zstd``unzip`公用程式。DNF 型作業系統包括 Amazon Linux 2023、8 Red Hat Enterprise Linux 和更新版本、Oracle Linux8 和更新版本、Rocky Linux、AlmaLinux、CentOS 8 和更新版本。如果您因為缺少 而看到類似 `No such file or directory: b'zstd'`、 `No such file or directory: b'unxz'`或修補失敗的錯誤`unzip`，則需要安裝這些公用程式。`xz`、 `zstd`和 `unzip`可以透過執行下列操作進行安裝：
```
dnf install zstd xz unzip
```
## 與修補程式來源的連線
如果您的受管節點沒有直接連線至網際網路，而且您使用具有 VPC 端點的 Amazon Virtual Private Cloud (Amazon VPC)，則必須確保節點能夠存取來源修補程式儲存庫 (repos)。在 Linux 節點上，修補程式更新通常會從節點上設定的遠端儲存庫下載。因此，節點必須能夠連接至儲存庫，以便執行修補。如需詳細資訊，請參閱[如何選取安全性修補程式](patch-manager-selecting-patches.md)。
修補僅限 IPv6 環境中執行的節點時，請確定節點已連線至修補程式來源。您可以檢查修補執行的Run Command輸出，以檢查有關無法存取儲存庫的警告。對於以 DNF 為基礎的作業系統，如果 `skip_if_unavailable`選項設定為 `True`下，則可以設定在修補期間略過無法使用的儲存庫`/etc/dnf/dnf.conf`。DNF 型作業系統包括 Amazon Linux 2023、8 Red Hat Enterprise Linux 和更新版本、8 Oracle Linux 和更新版本、Rocky Linux、AlmaLinux、CentOS 8 和更新版本。在 Amazon Linux 2023 上，`skip_if_unavailable`選項`True`預設為 。
**CentOS Stream：啟用 `EnableNonSecurity` 旗標**
CentOS Stream 節點將 DNF 作為套件管理工具，該工具使用更新通知的概念。更新通知僅只是修復特定問題的套件集合。
不過，CentOS Stream 預設儲存庫並未設定更新通知。這表示 Patch Manager 不會偵測預設 CentOS Stream 儲存庫上的套件。若要啟用 Patch Manager 來處理不包含在更新通知中的套件，您必須在修補基準規則中啟用 `EnableNonSecurity` 旗標。
**Windows Server：確保連線至 Windows Update 目錄或 Windows Server 更新服務 (WSUS)**
Windows Server 受管節點必須能夠連線至 Windows 更新目錄或 Windows 伺服器更新服務 (WSUS)。確認您的節點已透過網際網路閘道、NAT 閘道或 NAT 執行個體連線至 [Microsoft 更新目錄](https://www.catalog.update.microsoft.com/home.aspx)。如果使用 WSUS，請確認節點已連線至您環境中的 WSUS 伺服器。如需詳細資訊，請參閱[問題：受管節點無法存取 Windows 更新目錄或 WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access)。
## S3 端點存取
無論您的受管節點是在私有或公有網路中運作，而無法存取所需的 AWS 受管 Amazon Simple Storage Service (Amazon S3) 儲存貯體，修補操作都會失敗。如需受管節點必須能夠存取之 S3 儲存貯體的相關資訊，請參閱 [SSM Agent 與 AWS 受管 S3 儲存貯體的通訊](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 和 [使用適用於 Systems Manager 的 VPC 端點來改善 EC2 執行個體的安全性](setup-create-vpc.md)。
## 在本機安裝修補程式的許可
在 Windows Server 和 Linux 作業系統上，Patch Manager 會分別擔任管理員和根使用者帳戶來安裝修補程式。
然而，在 macOS 上，對於 Brew 和 Brew Cask，Homebrew 不支援其在根使用者帳戶下執行的命令。因此，Patch Manager 以 Homebrew 目錄的擁有者或屬於 Homebrew 目錄之擁有者群組的有效使用者身分查詢和執行 Homebrew 命令。因此，為了安裝修補程式，`homebrew` 目錄的擁有者也需要 `/usr/local` 目錄的遞迴擁有者許可。
**提示**
下列命令為指定使用者提供此許可：
```
sudo chown -R $USER:admin /usr/local
```
## Patch Manager 支援的作業系統
Patch Manager 工具並不支援其他 Systems Manager 工具支援的所有相同作業系統版本。(如需 Systems Manager 支援的作業系統完整清單，請參閱 [Systems Manager 支援的作業系統](operating-systems-and-machine-types.md#prereqs-operating-systems)。) 因此，確保您要使用 Patch Manager 的受管節點執行於下表所列的作業系統之一。
**注意**
Patch Manager 依賴在受管節點上設定的修補程式儲存庫，例如 Windows Update 目錄和 Windows 的 Windows Server 更新服務，來擷取可用的修補程式以進行安裝。因此，在終止服務 (EOL) 作業系統版本中，如果沒有可用的新更新，Patch Manager 可能無法報告新的更新。這可能是因為 Linux 發行版本維護者、Microsoft 或 Apple 未發行新的更新，或因為受管節點沒有存取新更新的適當授權。
強烈建議您避免使用已達生命週期結束 (EOL) 的作業系統版本。包括 在內的作業系統廠商 AWS 通常不會為已達到 EOL 的版本提供安全修補程式或其他更新。繼續使用 EOL 系統可大幅提高無法套用升級的風險，包括安全性修正和其他操作問題。 AWS 不會在已達到 EOL 的作業系統版本上測試 Systems Manager 功能。
Patch Manager 針對受管節點上的可用修補程式，報告合規狀態。因此，如果執行個體正在執行 EOL 作業系統，而且沒有可用的更新，Patch Manager 可能會根據針對修補操作設定的修補基準，將節點報告為合規。
| 作業系統 | 詳細資訊 |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS 僅支援 Amazon EC2 執行個體。* 13.0–13.5 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia) macOS OS 更新 Patch Manager 不支援 macOS 的作業系統 (OS) 更新或升級，例如從 13.1 至 13.2。若要在 macOS 上執行 OS 版本更新，我們建議您使用 Apple 內建的 OS 升級機制。如需詳細資訊，請參閱 Apple Developer Documentation 網站上的 [Device Management](https://developer.apple.com/documentation/devicemanagement)。 Homebrew 支援 Patch Manager 需要將開放原始碼軟體套件管理系統 Homebrew 安裝到下列其中一個預設安裝位置： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-prerequisites.html) 未安裝 Homebrew 時，使用 Patch Manager 的修補操作無法正常運作。 區域支援 macOS 不支援全部 AWS 區域。如需有關 macOS Amazon EC2 支援的詳細資訊，請參閱《Amazon EC2 使用者指南》**中的 [Amazon EC2 Mac instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)。 macOS 邊緣裝置 SSM Agent 不支援 AWS IoT Greengrass 核心裝置的 macOS。您無法使用 Patch Manager 修補 macOS 邊緣裝置。 |
| Windows | Windows Server 2012 到 Windows Server 2025，包括 R2 版本。 SSM Agent Windows 10 不支援 AWS IoT Greengrass 核心裝置的 。您無法使用 Patch Manager 修補 Windows 10 邊緣裝置。 Windows Server 2012 和 2012 R2 支援 Windows Server 2012 和 2012 R2 已於 2023 年 10 月 10 日終止支援。若要將 Patch Manager 與這些版本搭配使用，我們亦建議使用 Microsoft 的延伸安全性更新 (ESU)。如需詳細資訊，請參閱 Microsoft 網站上的 [Windows Server 2012 和 2012 R2 即將終止支援](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support)。 |
# Patch Manager 操作的運作方式
本節提供技術詳細資訊，說明 Patch Manager (AWS Systems Manager 中的工具) 如何決定要安裝哪些修補程式以及如何在各個支援的作業系統上安裝這些修補程式。。對於 Linux 作業系統，它也提供有關在自訂修補基準中指定來源儲存庫受管節點上預設以外的其他修補程式。本節亦提供有關修補基準規則用於不同 Linux 作業系統發行版的詳細資訊。
**注意**
無論您使用哪種方法或組態類型進行修補操作，下列主題中的資訊都適用：
在 Quick Setup 中設定的修補程式政策
在 Quick Setup 中設定的主機管理選項
用來執行修補程式 `Scan` 或 `Install` 任務的維護時段
隨需 **Patch now** (立即修補) 操作
**Topics**
+ [套件發行日期和更新日期的計算方式](patch-manager-release-dates.md)
+ [如何選取安全性修補程式](patch-manager-selecting-patches.md)
+ [如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)
+ [如何安裝修補程式](patch-manager-installing-patches.md)
+ [修補基準規則在 Linux 系統上的運作方式](patch-manager-linux-rules.md)
+ [Linux 和 Windows Server 之間的修補操作差異](patch-manager-windows-and-linux-differences.md)
# 套件發行日期和更新日期的計算方式
**重要**
本頁面上的資訊適用於 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體的 Amazon Linux 2 和 Amazon Linux 2023 作業系統 (OS)。這些 OS 類型的套件由 Amazon Web Services 建立和維護。其他作業系統的製造商管理其套件和儲存庫的方式，會影響其發行日期和更新日期的計算方式。對於 Amazon Linux 2 和 Amazon Linux 2023 之外的作業系統，例如 Red Hat Enterprise Linux，請參閱製造商的說明文件，了解有關如何更新和維護套件的資訊。
在您建立的[自訂修補程式基準](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)設定中，對於大多數作業系統類型，您可以指定在特定天數後自動核准安裝修補程式。 AWS 提供數個預先定義的修補程式基準，其中包含 7 天的自動核准日期。
*自動核准延遲*是修補程式發行之後，在自動核准修補程式進行修補之前的等待天數。例如，您可以使用 `CriticalUpdates` 分類建立規則，並將其設定為 7 天的自動核准延遲。因此，發行日期或最後更新日期為 7 月 7 日的新關鍵修補程式會在 7 月 14 日自動核准。
為了避免在 Amazon Linux 2 和 Amazon Linux 2023 上因自動核准延遲導致意外結果，請務必了解其發布日期和更新日期的計算方式。
**注意**
如果 Amazon Linux 2 或 Amazon Linux 2023 儲存庫未提供套件的發布日期資訊，Patch Manager 會使用套件的建置時間作为自動核准日期規格的日期。如果無法判斷套件的建置時間，Patch Manager 會使用 1970 年 1 月 1 日的預設日期。這會導致 Patch Manager 繞過修補基準中設定為核准 1970 年 1 月 1 日之後的任何日期的修補程式的任何自動核准日期規格。
在大多數情況下，安裝修補程式之前的自動核准等待時間從 `updateinfo.xml` 中的 `Updated Date` 值開始計算，而不是從 `Release Date` 值開始。以下是有關這些日期計算的重要詳細資訊：
+ `Release Date` 是發佈*通知*的日期。這並不意味著該套件必定在關聯的儲存庫中可用。
+ `Update Date` 是更新通知的最後日期。通知的更新可以表示小到一段文字或描述更新的內容。這並不意味著該套件於該日期發行，或必定在關聯的儲存庫中可用。
這意味著一個套件的 `Update Date` 值可能為 7 月 7 日，但直到 7 月 13 日 (例如) 才可以安裝。假設在此案例中，指定 7 天自動核准延遲的修補基準會在 7 月 14 日的 `Install` 操作中執行。由於 `Update Date` 值為執行日期前 7 天，套件中的修補程式和更新會在 7 月 14 日安裝。即使自套件可用於實際安裝以來僅過去 1 天，也會進行安裝。
+ 包含作業系統或應用程式修補程式的套件可在初始版本發行後多次更新。
+ 套件可以釋放到 AWS 受管儲存庫，但如果稍後發現問題，則會復原。
在某些修補操作中，這些因素可能並不重要。例如，如果將修補基準設定為安裝嚴重性值 `Low` 和 `Medium`、分類 `Recommended` 的修補程式，任何自動核准延遲可能對您的操作影響很小。
但是，如果嚴重或高嚴重性修補程式的時機更為重要，則您可能會想要對安裝修補程式的時機進行更多控制。建議的方法是使用替代的修補程式來源儲存庫，而非預設儲存庫來進行受管節點上的修補操作。
當您建立自訂修補基準時，可以指定替代的修補程式來源儲存庫。在每個自訂修補基準中，您可以指定修補程式來源組態，最多可達 20 個支援 Linux 作業系統的版本。如需詳細資訊，請參閱[如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。
# 如何選取安全性修補程式
中Patch Manager工具 的主要重點 AWS Systems Manager是在受管節點上安裝作業系統安全相關更新。在預設情況下，Patch Manager 不會安裝所有可用的修補程式，而是安裝以安全性為主的部分修補程式。
依預設，Patch Manager 不會使用任何不同名稱的替換套件取代在套件儲存庫中標示為過時的套件，除非另一個套件更新的安裝需要此替換套件。相反地，對於更新套件的命令，Patch Manager 只會報告和安裝已安裝但過時之套件的遺失更新。這是因為取代過時的套件通常需要解除安裝現有的套件並安裝其替換套件。取代過時的套件可能會帶來重大變更或您不想要的其他功能。
此行為與 YUM 和 DNF 的 `update-minimal` 命令一致，其著重於安全性更新，而不是功能升級。如需詳細資訊，請參閱[如何安裝修補程式](patch-manager-installing-patches.md)。
**注意**
當您在修補程式基準規則中使用 `ApproveUntilDate` 參數或 `ApproveAfterDays` 參數時， 會使用國際標準時間 (UTC) Patch Manager評估修補程式發行日期。
例如，對於 `ApproveUntilDate`，如果您指定日期，例如 `2025-11-16`，`2025-11-16T23:59:59Z`則會核准 `2025-11-16T00:00:00Z`和 之間發行的修補程式。
請注意，受管節點上原生套件管理員顯示的修補程式發行日期可能會根據您系統的本機時區顯示不同的時間，但Patch Manager一律使用 UTC 日期時間進行核准計算。這可確保與官方安全諮詢網站上發佈的修補程式發行日期一致。
對於報告修補程式嚴重性級別的 Linux 作業系統類型，Patch Manager 使用軟體發佈者為更新通知或個別修補程式報告的嚴重性級別。Patch Manager 不會從第三方來源推導出嚴重性級別，例如[通用漏洞評分系統](https://www.first.org/cvss/) (CVSS)，或者[美國國家漏洞資料庫](https://nvd.nist.gov/vuln) (NVD) 發佈的指標。
**注意**
在 Patch Manager 支援的所有 Linux 為基礎的系統上，您可以選擇為受管節點設定不同的來源儲存庫，通常用於安裝非安全性更新。如需相關資訊，請參閱[如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。
請從以下標籤選擇，了解 Patch Manager 如何為您的作業系統選擇安全性修補程式。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
預先設定的儲存庫在 Amazon Linux 2 上的處理方式與在 Amazon Linux 2023 上不同。
在 Amazon Linux 2 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫。節點上通常會有兩個預先設定的儲存庫 (repos)：
**在 Amazon Linux 2 上**
+ **儲存庫 ID**：`amzn2-core/2/architecture`
**儲存庫名稱**：`Amazon Linux 2 core repository`
+ **儲存庫 ID**：`amzn2extra-docker/2/architecture`
**儲存庫名稱**：`Amazon Extras repo for docker`
**注意**
*架構*可以是 x86\$164 或 aarch64 (適用於 Graviton 處理器)。
如果您建立 Amazon Linux 2023 (AL2023) 執行個體，它包含 AL2023 版本中可用的更新，以及您選取的特定 AMI。AL2023 執行個體不會在啟動時自動接收其他關鍵和重要的安全性更新。而藉由 AL2023 支援的*透過版本化儲存庫進行確定性升級*功能 (預設為開啟)，您可以根據滿足特定需求的排程套用更新。如需詳細資訊，請參閱《Amazon Linux 2023 使用者指南》**中的[透過版本化儲存庫使用決定性升級](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)一節。
在 AL2023 上，預先設定的儲存庫如下：
+ **儲存庫 ID**：`amazonlinux`
**儲存庫名稱**：Amazon Linux 2023 儲存庫
在 Amazon Linux 2023 （預覽版本） 上，預先設定的儲存庫會繫結至套件更新的*鎖定版本*。所發布的適用於 AL2023 的新 Amazon Machine Images (AMIs) 會鎖定至特定版本。針對修補程式更新，Patch Manager 會擷取修補程式更新儲存庫的最新鎖定版本，然後根據該鎖定版本的內容，更新受管節點上的套件。
**套件管理工具**
Amazon Linux 2 受管節點使用 Yum 作為套件管理工具。Amazon Linux 2023 使用 DNF 作為套件管理工具。
這兩個套件管理工具都使用*更新通知*的概念做為一個名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。更新通知中的所有套件皆被 Patch Manager 視為是安全的。個別套件不會被指派分類或嚴重性等級。因此，Patch Manager 會指派更新通知的屬性給相關的套件。
**注意**
如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。
如需有關**包含非安全性更新**選項的詳細資訊，請參閱[如何安裝修補程式](patch-manager-installing-patches.md)和[修補基準規則在 Linux 系統上的運作方式](patch-manager-linux-rules.md)。
------
#### [ CentOS Stream ]
在 CentOS Stream 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。下列清單提供虛構 CentOS 9.2 Amazon Machine Image(AMI) 的範例：
+ **儲存庫 ID**：`example-centos-9.2-base`
**儲存庫名稱**：`Example CentOS-9.2 - Base`
+ **儲存庫 ID**：`example-centos-9.2-extras`
**儲存庫名稱**：`Example CentOS-9.2 - Extras`
+ **儲存庫 ID**：`example-centos-9.2-updates`
**儲存庫名稱**：`Example CentOS-9.2 - Updates`
+ **儲存庫 ID**：`example-centos-9.x-examplerepo`
**儲存庫名稱**：`Example CentOS-9.x – Example Repo Packages`
**注意**
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
CentOS Stream 節點使用 DNF 作為套件管理工具。套件管理工具使用更新通知的概念。更新通知僅只是修復特定問題的套件集合。
不過，CentOS Stream 預設儲存庫並未設定更新通知。這表示 Patch Manager 不會偵測預設 CentOS Stream 儲存庫上的套件。若要啟用 Patch Manager 來處理不包含在更新通知中的套件，您必須在修補基準規則中啟用 `EnableNonSecurity` 旗標。
**注意**
支援 CentOS Stream 更新通知。啟動後，可下載含有更新通知的儲存區。
------
#### [ Debian Server ]
在 Debian Server 上，Systems Manager 修補基準服務會使用執行個體上預先設定的儲存庫 (repos)。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，Systems Manager 執行相當於 `sudo apt-get update` 命令。
然後套件會從 `debian-security codename` 儲存庫進行篩選。這表示，在每個 Debian Server 版本上，Patch Manager 只會識別屬於該版本關聯儲存庫的升級，如下所示：
+ Debian Server 11： `debian-security bullseye`
+ Debian Server 12： `debian-security bookworm`
------
#### [ Oracle Linux ]
在 Oracle Linux 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。節點上通常會有兩個預先設定的儲存庫。
**Oracle Linux 7**︰
+ **儲存庫 ID**：`ol7_UEKR5/x86_64`
**儲存庫名稱**：`Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **儲存庫 ID**：`ol7_latest/x86_64`
**儲存庫名稱**：`Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**︰
+ **儲存庫 ID**：`ol8_baseos_latest`
**儲存庫名稱**：`Oracle Linux 8 BaseOS Latest (x86_64)`
+ **儲存庫 ID**：`ol8_appstream`
**儲存庫名稱**：`Oracle Linux 8 Application Stream (x86_64)`
+ **儲存庫 ID**：`ol8_UEKR6`
**儲存庫名稱**：`Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**：
+ **儲存庫 ID**：`ol9_baseos_latest`
**儲存庫名稱**：`Oracle Linux 9 BaseOS Latest (x86_64)`
+ **儲存庫 ID**：`ol9_appstream`
**儲存庫名稱**：`Oracle Linux 9 Application Stream Packages(x86_64)`
+ **儲存庫 ID**：`ol9_UEKR7`
**儲存庫名稱**：`Oracle Linux UEK Release 7 (x86_64)`
**注意**
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
Oracle Linux 受管節點使用 Yum 做為套件管理工具，且 Yum 使用更新通知的概念，以做為名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。出於此原因，Patch Manager 會為相關套件指派更新通知的屬性，並根據修補基準中指定的分類篩選條件安裝套件。
**注意**
如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。節點上通常會有三個預先設定的儲存庫。
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
**注意**
如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。
Red Hat Enterprise Linux 7 受管節點使用 Yum 作為套件管理工具。AlmaLinux、Red Hat Enterprise Linux 8 和 Rocky Linux 受管節點使用 DNF 作為套件管理工具。這兩個套件管理工具都使用更新通知的概念做為一個名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。出於此原因，Patch Manager 會為相關套件指派更新通知的屬性，並根據修補基準中指定的分類篩選條件安裝套件。
RHEL 7
下列儲存庫 ID 與 RHUI 2 相關聯。RHUI 3 於 2019 年 12 月推出，並為 Yum 儲存庫 ID 引入了不同的命名方式。根據您建立受管節點的 RHEL-7 AMI，您可能需要更新命令。如需詳細資訊，請參閱 Red Hat [RHEL 客戶入口網站上 AWS 變更的 中 7 的儲存庫 IDs](https://access.redhat.com/articles/4599971)。 **
+ **儲存庫 ID**：`rhui-REGION-client-config-server-7/x86_64`
**儲存庫名稱**：`Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **儲存庫 ID**：`rhui-REGION-rhel-server-releases/7Server/x86_64`
**儲存庫名稱**：`Red Hat Enterprise Linux Server 7 (RPMs)`
+ **儲存庫 ID**：`rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**儲存庫名稱**：`Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux 8、RHEL 8 和 Rocky Linux 8
+ **儲存庫 ID**：`rhel-8-appstream-rhui-rpms`
**儲存庫名稱**：`Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **儲存庫 ID**：`rhel-8-baseos-rhui-rpms`
**儲存庫名稱**：`Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **儲存庫 ID**：`rhui-client-config-server-8`
**儲存庫名稱**：`Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9、RHEL 9 和 Rocky Linux 9
+ **儲存庫 ID**：`rhel-9-appstream-rhui-rpms`
**儲存庫名稱**：`Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **儲存庫 ID**：`rhel-9-baseos-rhui-rpms`
**儲存庫名稱**：`Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **儲存庫 ID**：`rhui-client-config-server-9`
**儲存庫名稱**：`Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
在 SUSE Linux Enterprise Server (SLES) 受管節點上，ZYPP 程式庫從下列位置取得可用修補程式的集合 (套件的集合)：
+ 儲存庫的清單：`etc/zypp/repos.d/*`
+ 套件資訊：`/var/cache/zypp/raw/*`
SLES 受管節點使用 Zypper 作為套件管理工具，Zypper 使用修補程式的概念。修補程式只是修復特定問題的套件集合。Patch Manager 處理安全性相關修補程式中參考的所有套件。由於個別套件並未指定分類或嚴重性，因此 Patch Manager 會將修補程式所屬的屬性指派給套件。
------
#### [ Ubuntu Server ]
在 Ubuntu Server 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，Systems Manager 執行相當於 `sudo apt-get update` 命令。
然後套件會從 `codename-security` 儲存庫中進行篩選，其中的代號名稱為發行版本專屬，例如 Ubuntu Server 14 的 `trusty`。Patch Manager 僅識別屬於這些儲存庫之一部分的升級：
+ Ubuntu Server 16.04 LTS︰`xenial-security`
+ Ubuntu Server 18.04 LTS︰`bionic-security`
+ Ubuntu Server 20.04 LTS︰`focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
------
#### [ Windows Server ]
在 Microsoft Windows 作業系統上，Patch Manager 會擷取 Microsoft 透過更新服務發佈的可用更新清單，並自動對 Windows Server Update Services (WSUS) 可用。
**注意**
Patch Manager 僅為 Patch Manager 支援的 Windows Server 作業系統版本提供可用的修補程式。例如，Patch Manager 無法用於修補 Windows RT。
Patch Manager 持續監控每個 AWS 區域中的新更新。各個區域中可用的更新清單將至少每天重新整理一次。Microsoft 的修補程式資訊經處理後，Patch Manager 會從其修補程式清單中刪除已被更新版本取代的更新。因此，只有最新的更新會顯示出來並提供安裝。例如，如果 `KB4012214` 取代了 `KB3135456`，Patch Manager 中只會有 `KB4012214` 可供更新。
同樣地，Patch Manager 只能在修補操作期間安裝受管節點上提供的修補程式。依預設，Windows Server 2019 和 Windows Server 2022 會移除更新，而這些更新會由稍後的更新取代。因此，如果您在 Windows Server 修補基準中使用 `ApproveUntilDate` 參數，但 `ApproveUntilDate` 參數中選取的日期*早於*最新修補程式的日期，則會發生下列情況：
+ 取代的修補程式會從節點中移除，因此無法使用 Patch Manager 進行安裝。
+ 節點上存在最新的替代修補程式，但尚未根據 `ApproveUntilDate` 參數指定的日期核准安裝。
這表示即使可能未安裝上個月的關鍵修補程式，受管節點在 Systems Manager 操作方面也符合規範。使用 `ApproveAfterDays` 參數時，可能會發生相同的情況。由於 Microsoft 取代了修補程式行為，可以設定數字 (通常大於 30 天)，這樣，若在 `ApproveAfterDays` 的天數之前發行 Microsoft 最新的可用修補程式，則永遠不會安裝 Windows Server 的修補程式。請注意，如果您已修改 Windows 群組政策物件 (GPO) 設定，以在受管節點上提供取代的修補程式，則此系統行為不適用。
**注意**
在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發行修補程式。在這些情況下，預設會提供 `01/01/1970` 的更新日期和時間。
------
# 如何指定替代修補程式來源儲存庫 (Linux)
當您使用受管節點上設定的預設儲存庫進行修補操作時， Patch Manager是 中的工具 AWS Systems Manager，會掃描或安裝與安全相關的修補程式。這是 Patch Manager 的預設行為。如需有關 Patch Manager 如何選擇和安裝安全性修補程式的完整資訊，請參閱 [如何選取安全性修補程式](patch-manager-selecting-patches.md)。
但是在 Linux 系統上，您也可以使用 Patch Manager 安裝與安全無關的修補程式，或安裝位於與設定於受管節點上的預設儲存庫不同來源儲存庫上的修補程式。當您建立自訂修補基準時，可以指定替代的修補程式來源儲存庫。在每個自訂修補基準中，您可以指定修補程式來源組態，最多可達 20 個支援 Linux 作業系統的版本。
例如，假設您的 Ubuntu Server 機群包含 Ubuntu Server 25.04 受管節點。在這種情況下，您可以為同一自訂修補基準中的每個版本指定備用儲存庫。您為每個版本提供名稱，指定作業系統版本類型 (產品)，然後提供儲存庫組態。您也可以指定單一替代來源儲存庫，適用於所有支援的作業系統版本。
**注意**
執行為受管節點指定替代修補程式儲存庫的自訂修補基準並不會將這些儲存庫設為作業系統上的新預設儲存庫。修補操作完成後，先前設定為節點作業系統之預設值的儲存庫會保留為預設儲存庫。
如需使用此選項的範例案例清單，請參閱本主題後面的[替代修補程式來源儲存庫使用範例](#patch-manager-alternative-source-repository-examples)。
如需有關預設和自訂修補基準的詳細資訊，請參閱[預先定義和自訂的修補基準](patch-manager-predefined-and-custom-patch-baselines.md)。
**範例：使用主控台**
若要在 Systems Manager 主控台中工作時指定替代的修補程式來源儲存庫，請使用 **Create patch baseline** (建立修補基準) 頁面上的 **Patch sources** (修補程式來源) 區段。如需使用 **Patch sources (修補程式來源)** 選項的詳細資訊，請參閱[建立適用於 Linux 的自訂修補基準](patch-manager-create-a-patch-baseline-for-linux.md)。
**範例：使用 AWS CLI**
如需在 AWS Command Line Interface (AWS CLI) 中使用 `--sources` 選項的範例，請參閱 [建立包含不同作業系統版本之自訂儲存庫的修補基準](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources)。
**Topics**
+ [替代儲存庫的重要考量](#alt-source-repository-important)
+ [替代修補程式來源儲存庫使用範例](#patch-manager-alternative-source-repository-examples)
## 替代儲存庫的重要考量
在您使用替代修補程式儲存庫規劃修補策略時，請注意以下重點。
**強制執行儲存庫更新驗證 (YUM 和 DNF)**
如果無法建立與儲存庫的連線，Linux 發行版本上套件管理員的預設組態可能會設定為略過無法連線的套件儲存庫。若要強制執行儲存庫更新驗證，請將 `skip_if_unavailable=False`新增至儲存庫組態。
如需有關 `skip_if_available` 選項的詳細資訊，請參閱 [與修補程式來源的連線](patch-manager-prerequisites.md#source-connectivity)。
**只有指定的儲存庫會用於修補**
指定替代儲存庫不表示指定*額外的*儲存庫。您可以選擇受管節點上設定為預設儲存庫以外的儲存庫。不過，如果您希望套用預設儲存庫的更新，您也必須指定預設儲存庫做為替代修補程式來源組態的一部分。
例如，在 Amazon Linux 2 受管節點上，預設的儲存庫是 `amzn2-core` 和 `amzn2extra-docker`。若您希望將 Extra Packages for Enterprise Linux (EPEL) 儲存庫包含在您的修補操作中，您必須將這三個儲存庫全部指定為替代儲存庫。
**注意**
執行為受管節點指定替代修補程式儲存庫的自訂修補基準並不會將這些儲存庫設為作業系統上的新預設儲存庫。修補操作完成後，先前設定為節點作業系統之預設值的儲存庫會保留為預設儲存庫。
**以 YUM 為基礎之分發的修補行為取決於 updateinfo.xml 資訊清單**
為以 YUM 為基礎之發行版本 (例如 Amazon Linux 2 或 Red Hat Enterprise Linux) 指定替代修補程式儲存庫時，修補行為取決於儲存庫是否包含更新資訊清單，其形式為完整且格式正確的 `updateinfo.xml` 檔案。此檔案指定各種套件的發行日期、分類和嚴重性。以下項目將會影響修補行為：
+ 如果您篩選 **Classification (分類)** 與 **Severity (嚴重性)**，但是在 `updateinfo.xml` 中並未指定這些項目，則該套件將不會被篩選條件所包含。這也表示沒有 `updateinfo.xml` 檔案的套件不會包含在修補中。
+ 如果您篩選 **ApprovalAfterDays**，但套件發行日期並非 Unix Epoch 格式 (或沒有指定發行日期)，該套件將不會被篩選條件所包含。
+ 如果您選取**建立修補基準**頁面中的**包含非安全性更新**核取方塊，則會有例外狀況。在這種情況下，沒有 `updateinfo.xml` 檔案的套件 (或包含此檔案但未正確格式化**分類**、**嚴重性**和**日期**值的套件)，*會*包含在預先篩選的修補程式清單中。(它們必須仍符合其他修補基準規則的要求，才能進行安裝。)
## 替代修補程式來源儲存庫使用範例
**範例 1 – Ubuntu Server 的非安全性更新**
您已使用 Patch Manager，使用 AWS提供的預先定義修補程式基準，在Ubuntu Server受管節點的機群上安裝安全修補程式`AWS-UbuntuDefaultPatchBaseline`。您可以建立以此預設為基礎的新修補基準，但在核准規則中指定，您希望也安裝預設分發中非安全性相關的更新。當此修補基準在您的節點上執行時，將會套用安全性與非安全性問題的修補程式。您也可以選擇在您為基準指定的修補程式例外狀況中，核准非安全性修補程式。
**範例 2 - Ubuntu Server 的個人套件存檔 (PPA)**
您的 Ubuntu Server 受管節點執行透過 [Ubuntu 個人套件封存 (PPA) 分發的軟體](https://launchpad.net/ubuntu/+ppas)。在此案例下，您建立一個修補基準，指定您已在受管節點上設定的 PPA 儲存庫做為修補操作的來源儲存庫。然後，使用 Run Command 執行在節點上的修補基準文件。
**範例 3 - 支援的 Amazon Linux 版本上的內部公司應用程式**
您需要在您的 Amazon Linux 受管節點上執行一些應用程式，以符合產業法律合規需求。您可以在節點上為這些應用程式設定儲存庫，使用 YUM 初步安裝應用程式，然後更新或建立新的修補基準，以包含這個新的公司儲存庫。在此之後，您可以使用 Run Command，執行具有 `Scan` 選項的 `AWS-RunPatchBaseline` 文件，查看公司套件是否列在已安裝的套件中，並且在受管節點上是否為最新狀態。如果不是最新的，您可以使用 `Install` 選項更新應用程式以再次執行該文件。
# 如何安裝修補程式
Patch Manager是 中的工具 AWS Systems Manager，使用作業系統內建套件管理員在受管節點上安裝更新。例如，它在 Amazon Linux 2023 Windows Server和 `DNF`上使用 Windows Update API。修補程式管理員會遵守節點上現有的套件管理員和儲存庫組態，包括儲存庫狀態、鏡像 URLs、GPG 驗證和選項等設定`skip_if_unavailable`。
Patch Manager 不會安裝取代目前安裝之過時套件的新套件。(例外：新套件是正在安裝的另一個套件更新的相依性，或者新套件具有與過時套件相同的名稱。) 反之，Patch Manager 會報告並安裝已安裝套件的可用更新。此方法有助於防止系統功能意外變更，這些變更可能會在一個套件取代另一個套件時發生。
如果您需要解除安裝已過時的套件並安裝其替換套件，您可能需要使用自訂指令碼，或在 Patch Manager 的標準操作之外使用套件管理工具命令。
請從以下標籤選擇，了解 Patch Manager 如何在作業系統上安裝修補程式。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
在 Amazon Linux 2 和 Amazon Linux 2023 受管節點上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. 如果核准修補程式的多個版本，將會套用最新版本。
1. YUM 更新 API (Amazon Linux 2) 或 DNF 更新 API (Amazon Linux 2023) 會套用至已核准的修補程式，如下所示：
+ 對於由 AWS提供的預先定義預設修補基準，僅會套用 `updateinfo.xml` 中指定的修補程式 (僅限安全性更新)。這是因為未選取**包含非安全性更新**核取方塊。預先定義的基準等同於具有下列項目的自訂基準：
+ 未選取**包含非安全性更新**核取方塊
+ `[Critical, Important]` 嚴重性清單
+ `[Security, Bugfix]` 分類清單
對於 Amazon Linux 2，此工作流程的等效 yum 命令為：
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
對於 Amazon Linux 2023，此工作流程的等效 dnf 命令為：
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
如果選取**包含非安全性更新**核取方塊，則位於 `updateinfo.xml` 中的修補程式和不位於 `updateinfo.xml` 中的修補程式皆會套用 (安全性和非安全性更新)。
對於 Amazon Linux 2，如果選取**包含非安全性更新**的基準，且該基準具有 `[Critical, Important]` 嚴重性清單和 `[Security, Bugfix]` 分類清單，則等效 yum 命令為：
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
對於 Amazon Linux 2023，等效 dnf 命令為：
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**注意**
如果您在 Patch Manager 外部執行這些 `yum` 或 `dnf` 命令，則會安裝取代現已過時套件的具有不同名稱的新套件。不過，這些套件*不是*由等效 Patch Manager 操作安裝。
**Amazon Linux 2023 的其他修補詳細資訊**
支援嚴重性等級「無」
Amazon Linux 2023 也支援修補程式嚴重性層級 `None`，該層級由 DNF 套件管理員識別。
支援嚴重性等級「中」
對於 Amazon Linux 2023， 的修補程式嚴重性等級`Medium`等同於在某些外部儲存庫中`Moderate`定義的嚴重性。如果在修補基準中包含 `Medium` 嚴重性修補程式，則外部修補程式的 `Moderate` 嚴重性修補程式也會安裝在執行個體上。
當您使用 API 動作 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) 查詢合規資料時，嚴重性等級 `Medium` 篩選會報告嚴重性等級為 `Medium` 和 `Moderate` 的修補程式。
Amazon Linux 2023 的可轉移相依性處理
對於 Amazon Linux 2023，Patch Manager 可能會安裝與等效 `dnf` 命令所安裝的可轉移相依性不同的版本。可轉移相依性是會自動安裝的套件，以滿足其他套件的需求 (相依性的相依性)。
例如，`dnf upgrade-minimal --security` 會安裝為解決已知安全問題所需的*最低*可轉移相依性版本，而 Patch Manager 會安裝**相同可轉移相依性的最新可用版本。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
**注意**
Linux 發行版本上套件管理員的預設組態可能會設定為略過無法連線的套件儲存庫，而不會發生錯誤。在這種情況下，相關的修補操作會繼續進行，而不安裝來自儲存庫的更新，並成功完成。若要強制執行儲存庫更新，請將 `skip_if_unavailable=False`新增至儲存庫組態。
如需有關 `skip_if_available` 選項的詳細資訊，請參閱 [與修補程式來源的連線](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ CentOS Stream ]
在 CentOS Stream 受管節點上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. 如果核准修補程式的多個版本，將會套用最新版本。
1. 對 CentOS Stream 的 DNF 更新將套用至核准的修補程式。
**注意**
對於 CentOS Stream，Patch Manager 可能會安裝與等效 `dnf` 命令所安裝的可轉移相依性不同的版本。可轉移相依性是會自動安裝的套件，以滿足其他套件的需求 (相依性的相依性)。
例如，`dnf upgrade-minimal ‐‐security` 會安裝為解決已知安全問題所需的*最低*可轉移相依性版本，而 Patch Manager 會安裝相同可轉移相依性的*最新可用版本*。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
------
#### [ Debian Server ]
在 Debian Server 執行個體上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 若有可用於 `python3-apt` (`libapt` 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
**注意**
因為無法可靠地判斷 Debian Server 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
**注意**
對於 Debian Server，修補程式候選版本僅限於 `debian-security` 中包含的修補程式。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. APT 程式庫用於升級套件。
**注意**
Patch Manager 不支援使用 APT `Pin-Priority` 選項，將優先順序指派給套件。Patch Manager 會從所有已啟用的儲存庫彙總可用的更新，並選取符合每個已安裝套件基準的最新更新。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
------
#### [ macOS ]
在 macOS 受管節點上，修補程式安裝工作流程如下：
1. `/Library/Receipts/InstallHistory.plist` 屬性清單是使用 `softwareupdate` 和 `installer` 套件管理工具的已安裝和已升級軟體記錄。使用 `pkgutil` 命令列工具 (用於 `installer`) 以及 `softwareupdate` 套件管理工具時，會執行 CLI 命令來剖析此清單。
對於 `installer`，對 CLI 命令的回應包括 `package name`、`version`、`volume`、`location` 和 `install-time` 詳細資訊，但 Patch Manager 僅使用 `package name` 和 `version`。
對於 `softwareupdate`，對 CLI 命令的回應會包含套件名稱 (`display name`)、`version` 和 `date`，但 Patch Manager 只會使用套件名稱和版本。
對於 Brew 和 Brew Cask，Homebrew 不支援其在根使用者下執行的命令。因此，Patch Manager 以 Homebrew 目錄的擁有者或屬於 Homebrew 目錄之擁有者群組的有效使用者身分查詢和執行 Homebrew 命令。這些命令類似於 `softwareupdate` 和 `installer` 並透過 Python 子程序執行命令，以收集套件資料，並解析輸出以識別套件名稱和版本。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. 如果核准修補程式的多個版本，將會套用最新版本。
1. 在受管節點上叫用適當的套件 CLI，以處理核准的修補程式，如下所示：
**注意**
`installer` 缺乏檢查和安裝更新的功能。因此，對於 `installer`，Patch Manager 只會報告已安裝的套件。因此，`installer` 套件永遠不會報告為 `Missing`。
+ 針對 AWS提供的預先定義預設修補基準，以及*未*選取**包含非安全性更新**核取方塊的自訂修補基準，則只會套用安全性更新。
+ 針對*已*選取**包含非安全性更新**核取方塊的自訂修補基準，會套用安全性和非安全性更新。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
------
#### [ Oracle Linux ]
在 Oracle Linux 受管節點上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. 如果核准修補程式的多個版本，將會套用最新版本。
1. 在版本 7 受管節點上，YUM 更新 API 會套用至核准的修補程式，如下所示：
+ 針對 AWS提供的預先定義預設修補基準，以及*未*選取**包含非安全性更新**核取方塊的自訂修補基準，則只會套用 `updateinfo.xml` 中指定的修補程式 (僅限安全性更新)。
此工作流程的同等 yum 命令為：
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ 針對*已*選取**包含非安全性更新**核取方塊的修補基準，位於 `updateinfo.xml` 中的修補程式和不位於 `updateinfo.xml` 中的修補程式皆會套用 (安全性和非安全性更新)。
此工作流程的同等 yum 命令為：
```
sudo yum update --security --bugfix -y
```
在版本 8 和 9 的受管節點上，DNF 更新 API 會套用至核准的修補程式，如下所示：
+ 對於預先定義的預設修補程式基準 AWS，以及*未*選取**包含非安全性更新**核取方塊的自訂修補程式基準，只會`updateinfo.xml`套用 中指定的修補程式 （僅安全性更新）。
此工作流程的同等 yum 命令為：
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**注意**
對於 Oracle Linux，Patch Manager 可能會安裝與等效 `dnf` 命令所安裝的可轉移相依性不同的版本。可轉移相依性是會自動安裝的套件，以滿足其他套件的需求 (相依性的相依性)。
例如，`dnf upgrade-minimal --security` 會安裝為解決已知安全問題所需的*最低*可轉移相依性版本，而 Patch Manager 會安裝相同可轉移相依性的*最新可用版本*。
+ 針對*已*選取**包含非安全性更新**核取方塊的修補基準，位於 `updateinfo.xml` 中的修補程式和不位於 `updateinfo.xml` 中的修補程式皆會套用 (安全性和非安全性更新)。
此工作流程的同等 yum 命令為：
```
sudo dnf upgrade --security --bugfix
```
**注意**
如果您在 Patch Manager 外部執行這些 `yum` 或 `dnf` 命令，則會安裝取代現已過時套件的具有不同名稱的新套件。不過，這些套件*不是*由等效 Patch Manager 操作安裝。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
**注意**
Linux 發行版本上套件管理員的預設組態可能會設定為略過無法連線的套件儲存庫，而不會發生錯誤。在這種情況下，相關的修補操作會繼續進行，而不安裝來自儲存庫的更新，並成功完成。若要強制執行儲存庫更新，請將 `skip_if_unavailable=False`新增至儲存庫組態。
如需有關 `skip_if_available` 選項的詳細資訊，請參閱 [與修補程式來源的連線](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 受管節點上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. 如果核准修補程式的多個版本，將會套用最新版本。
1. YUM 更新 API (在 RHEL 7 上) 或 DNF 更新 API (在 AlmaLinux 8 和 9、RHEL 8、9、10 以及 Rocky Linux 8 和 9 上) 會根據下列規則，套用至已核准的修補程式：
**案例 1：排除非安全性更新**
+ **適用於**： 提供的預先定義預設修補程式基準 AWS 和自訂修補程式基準。
+ **包含非安全性更新**核取方塊：*未*選取。
+ **套用的修補程式**：*僅當* `updateinfo.xml` 中指定的修補程式 (僅限安全性更新) 既符合修補基準組態，又能在設定的儲存庫中找到時，才會套用這些修補程式。
在某些情況下，`updateinfo.xml` 中指定的修補程式可能無法再在設定的儲存庫中使用。設定的儲存庫通常只有某一修補程式的最新版本，這是所有先前更新的累積滾動結果，但最新版本可能不符合修補基準規則，並從修補操作中省略。
+ **命令**：對於 RHEL 7，此工作流程的等效 yum 命令為：
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
對於 AlmaLinux、RHEL 8 和 Rocky Linux，此工作流程的同等 dnf 命令為：
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**注意**
對於 AlmaLinux、RHEL 和 Rocky LinuxRocky Linux，Patch Manager 可能會安裝與等效 `dnf` 命令所安裝的可轉移相依性不同的版本。可轉移相依性是會自動安裝的套件，以滿足其他套件的需求 (相依性的相依性)。
例如，`dnf upgrade-minimal --security` 會安裝為解決已知安全問題所需的*最低*可轉移相依性版本，而 Patch Manager 會安裝相同可轉移相依性的*最新可用版本*。
**案例 2：包含非安全性更新**
+ **適用於**：自訂修補基準。
+ **包含非安全性更新**核取方塊：已選取。
+ **套用的修補程式**：將套用 `updateinfo.xml` 中的修補程式*和*不在 `updateinfo.xml` 中的修補程式 (安全性和非安全性更新)。
+ **命令**：對於 RHEL 7，此工作流程的等效 yum 命令為：
```
sudo yum update --security --bugfix -y
```
對於 AlmaLinux 8 和 9、RHEL 8 和 9 以及 Rocky Linux 8 和 9，此工作流程的同等 dnf 命令為：
```
sudo dnf update --security --bugfix -y
```
**注意**
如果您在 Patch Manager 外部執行這些 `yum` 或 `dnf` 命令，則會安裝取代現已過時套件的具有不同名稱的新套件。不過，這些套件*不是*由等效 Patch Manager 操作安裝。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
**注意**
Linux 發行版本上套件管理員的預設組態可能會設定為略過無法連線的套件儲存庫，而不會發生錯誤。在這種情況下，相關的修補操作會繼續進行，而不安裝來自儲存庫的更新，並成功完成。若要強制執行儲存庫更新，請將 `skip_if_unavailable=False`新增至儲存庫組態。
如需有關 `skip_if_available` 選項的詳細資訊，請參閱 [與修補程式來源的連線](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ SLES ]
在 SUSE Linux Enterprise Server (SLES) 受管節點上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. 如果核准修補程式的多個版本，將會套用最新版本。
1. Zypper 更新 API 將套用至核准的修補程式。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
------
#### [ Ubuntu Server ]
在 Ubuntu Server 受管節點上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 若有可用於 `python3-apt` (`libapt` 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，以便僅進一步處理合格的套件。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每個核准規則皆可將套件定義為已核准。
**注意**
因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
**注意**
對於每個 Ubuntu Server 版本，修補程式候選版本僅限於屬於該版本關聯儲存庫的修補程式，如下所示：
Ubuntu Server 16.04 LTS︰`xenial-security`
Ubuntu Server 18.04 LTS︰`bionic-security`
Ubuntu Server 20.04 LTS)︰`focal-security`
Ubuntu Server 22.04 LTS︰`jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已核准的修補程式即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 捨棄或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中沒有指定核准規則授予其核准，仍將會核准用於更新。
1. 套用修補程式基準中指定的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
1. APT 程式庫用於升級套件。
**注意**
Patch Manager 不支援使用 APT `Pin-Priority` 選項，將優先順序指派給套件。Patch Manager 會從所有已啟用的儲存庫彙總可用的更新，並選取符合每個已安裝套件基準的最新更新。
1. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
------
#### [ Windows Server ]
在 Windows Server 受管節點上執行修補操作時，節點會從 Systems Manager 請求適當修補基準的快照。此快照包含已核准部署之修補基準中所有可用更新的清單。此更新清單會傳送至 Windows Update API，決定哪些更新適用於受管節點並視需要安裝這些更新。Windows 只允許安裝最新版本的 KB。如果最新版本的 KB 或任何舊版 KB 符合套用的修補基準，Patch Manager 會安裝最新版本的 KB。如有安裝任何更新，受管節點將會重新啟動，重新啟動的次數依據完成所有必要修補的需要而定。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。) 在 Run Command 請求的輸出中，可以找到修補操作的摘要。在 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` 資料夾的受管節點上，可以找到額外的日誌。
由於 Windows Update API 用於下載和安裝 KB，因此會遵守適用於 Windows Update 的所有群組政策設定。使用 Patch Manager 無需任何群組政策設定，但您已定義的所有設定都將會套用，例如將受管節點導向至 Windows Server Update Services (WSUS) 伺服器。
**注意**
依預設，Windows 會從 Microsoft 的 Windows Update 網站中下載所有 KB，因為 Patch Manager 使用 Windows Update API 來推動下載和安裝 KB。因此，受管節點必須能夠連接至 Microsoft Windows Update 網站，否則修補將會失敗。或者，您可以設定 WSUS 伺服器作為 KB 儲存庫，並設定您的受管節點以 WSUS 伺服器為目標使用群組政策。
在建立 Windows Server 的自訂修補基準時，Patch Manager 可能會參考 KB ID，例如當基準組態中包含**已核准修補程式**清單或**已拒絕修補程式**清單時。只有在 Microsoft Windows Update 或 WSUS 伺服器中獲得 KB ID 指派的更新，才會由 Patch Manager 安裝。缺少 KB ID 的更新不會包含在修補操作中。
如需有關建立自訂修補基準的資訊，請參閱下列主題：
[建立 Windows Server 的自訂修補基準](patch-manager-create-a-patch-baseline-for-windows.md)
[建立修補基準 (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[適用於 Windows 作業系統的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# 修補基準規則在 Linux 系統上的運作方式
Linux 分發的修補基準中的規則，運作方式依據分發類型而有不同。與Windows Server受管節點上的修補程式更新不同，每個節點都會評估規則，以考量執行個體上設定的儲存庫。 Patch Manager是 中的工具 AWS Systems Manager，使用原生套件管理員來推動修補程式基準核准的修補程式安裝。
對於報告修補程式嚴重性級別的 Linux 作業系統類型，Patch Manager 使用軟體發布者為更新通知或個別修補程式報告的嚴重性級別。Patch Manager 不會從第三方來源推導出嚴重性級別，例如[通用漏洞評分系統](https://www.first.org/cvss/) (CVSS)，或者[美國國家漏洞資料庫](https://nvd.nist.gov/vuln) (NVD) 發行的指標。
**Topics**
+ [修補基準規則在 Amazon Linux 2 和 Amazon Linux 2023 上的運作方式](#linux-rules-amazon-linux)
+ [修補基準規則在 CentOS Stream 上的運作方式](#linux-rules-centos)
+ [修補基準規則在 Debian Server 上的運作方式](#linux-rules-debian)
+ [修補基準規則在 macOS 上的運作方式](#linux-rules-macos)
+ [修補基準規則在 Oracle Linux 上的運作方式](#linux-rules-oracle)
+ [修補基準規則在 AlmaLinux、RHEL 和 Rocky Linux 上的運作方式](#linux-rules-rhel)
+ [修補基準規則在 SUSE Linux Enterprise Server 上的運作方式](#linux-rules-sles)
+ [修補基準規則在 Ubuntu Server 上的運作方式](#linux-rules-ubuntu)
## 修補基準規則在 Amazon Linux 2 和 Amazon Linux 2023 上的運作方式
**注意**
Amazon Linux 2023 (AL2023) 使用可透過一或多個系統設定鎖定為特定版本的版本控制儲存庫。對於 AL2023 EC2 執行個體上的所有修補操作，Patch Manager 會使用最新儲存庫版本，與系統組態無關。如需詳細資訊，請參閱《Amazon Linux 2023 使用者指南》**中的[透過版本化儲存庫使用決定性升級](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)一節。
在 Amazon Linux 2 和 Amazon Linux 2023 上，修補程式選取程序如下：
1. 在受管節點上，YUM 程式庫 (Amazon Linux 2) 或 DNF 程式庫 (Amazon Linux 2023) 會存取每個已設定儲存庫的 `updateinfo.xml` 檔案。
如果沒有找到 `updateinfo.xml` 檔案，是否安裝修補程式取決於**包含非安全性更新**和**自動核准**的設定。例如，如果允許非安全性更新，則會在自動核准時間到達時進行安裝。
1. `updateinfo.xml` 中的每個更新通知皆包含數個屬性，以表示通知中的套件的屬性，如下表所述。
**更新通知屬性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需已核准修補程式和遭拒的修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 受管節點的產物取決於 SSM Agent。此屬性對應至修補程式基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
## 修補基準規則在 CentOS Stream 上的運作方式
CentOS Stream 預設儲存庫不包含 `updateinfo.xml` 檔案。不過，您建立或使用的自訂儲存庫可能包含此檔案。在本主題中，`updateinfo.xml` 的參考僅適用於這些自訂儲存庫。
在 CentOS Stream 上，修補程式選擇程序如下：
1. 在受管節點上，如果 `updateinfo.xml` 檔案存在於自訂儲存庫中，則對於每個已設定儲存庫，DNF 程式庫都會存取此檔案。
如果沒有找到一律包含預設儲存庫的 `updateinfo.xml`，是否安裝修補程式取決於**包含非安全性更新**和**自動核准**的設定。例如，如果允許非安全性更新，則會在自動核准時間到達時進行安裝。
1. 如果存在 `updateinfo.xml`，則在檔案中的每個更新通知皆包含數個屬性，以表示通知中的套件的屬性，如下表所述。
**更新通知屬性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需已核准修補程式和遭拒的修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 在任何情況下，受管節點的產物取決於 SSM Agent。此屬性對應至修補程式基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
## 修補基準規則在 Debian Server 上的運作方式
在 Debian Server 上，修補基準服務提供*優先順序*與*區段*篩選欄位。這些欄位通常會顯示所有 Debian Server 套件。為了判斷修補程式是否已被修補基準選取，Patch Manager 會執行下列動作：
1. 在 Debian Server 系統上，會執行與 `sudo apt-get update` 相當的命令以重新整理可用套件清單。儲存區未設定，資料從設定於 `sources` 清單中的儲存區提取。
1. 若有可用於 `python3-apt` (`libapt` 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
1. 接著，將套用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 和 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 清單。
**注意**
因為無法可靠地判斷 Debian Server 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。在這種情形下，對於 Debian Server 來說，修補候選版本僅限於以下儲存庫中包含的修補程式：
這些儲存庫的命名如下：
+ Debian Server 11： `debian-security bullseye`
+ Debian Server 12： `debian-security bookworm`
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
若要檢視 *Priority (優先順序)* 和 *Section (區段)* 欄位的內容，請執行下列 `aptitude` 命令：
**注意**
您可能必須先在 Debian Server 系統上安裝 Aptitude。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
在此命令的回應中，所有可升級的套裝將以此格式回報：
```
name, priority, section, archive, candidate version
```
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
## 修補基準規則在 macOS 上的運作方式
在 macOS 上，修補程式選擇程序如下：
1. 在受管節點上，Patch Manager 會存取 `InstallHistory.plist` 檔案已剖析的內容，並識別套件名稱和版本。
如需剖析程序的詳細資訊，請參閱 [如何安裝修補程式](patch-manager-installing-patches.md) 中的 **macOS** 索引標籤。
1. 受管節點的產物取決於 SSM Agent。此屬性對應至修補程式基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
## 修補基準規則在 Oracle Linux 上的運作方式
在 Oracle Linux 上，修補程式選擇程序如下：
1. 在受管節點上，YUM 程式庫存取每個已設定之儲存庫的 `updateinfo.xml` 檔案。
**注意**
如果儲存庫不是由 Oracle 管理的，則可能沒有 `updateinfo.xml` 檔案。如果沒有找到 `updateinfo.xml`，是否安裝修補程式取決於**包含非安全性更新**和**自動核准**的設定。例如，如果允許非安全性更新，則會在自動核准時間到達時進行安裝。
1. `updateinfo.xml` 中的每個更新通知皆包含數個屬性，以表示通知中的套件的屬性，如下表所述。
**更新通知屬性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需已核准修補程式和遭拒的修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 受管節點的產物取決於 SSM Agent。此屬性對應至修補程式基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
## 修補基準規則在 AlmaLinux、RHEL 和 Rocky Linux 上的運作方式
在 AlmaLinux、Red Hat Enterprise Linux (RHEL) 和 Rocky Linux 上，修補程式選擇程序如下：
1. 在受管節點上，YUM 程式庫 (RHEL 7) 或 DNF 程式庫 (AlmaLinux 8 和 9、RHEL 8、9、10 以及 Rocky Linux 8 和 9 ) 會存取每個已設定儲存庫的 `updateinfo.xml` 檔案。
**注意**
如果儲存庫不是由 Red Hat 管理的，則可能沒有 `updateinfo.xml` 檔案。如果沒有 `updateinfo.xml`，將不會套用任何修補程式。
1. `updateinfo.xml` 中的每個更新通知皆包含數個屬性，以表示通知中的套件的屬性，如下表所述。
**更新通知屬性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需已核准修補程式和遭拒的修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 受管節點的產物取決於 SSM Agent。此屬性對應至修補程式基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-linux-rules.html)
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
## 修補基準規則在 SUSE Linux Enterprise Server 上的運作方式
在 SLES 上，每個修補程式皆包含下列屬性，以表示修補程式中的套件的屬性：
+ **分類**：對應至修補基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的**分類**金鑰屬性的值。表示包含在更新通知中的修補程式類型。
您可以使用 AWS CLI 命令**[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)**或 API 操作 來檢視支援的值清單**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**。您也可以在 Systems Manager 主控台之 **Create patch baseline** (建立修補基準) 頁面或 **Edit patch baseline** (編輯修補基準) 頁面的 **Approval rules** (核准規則) 區域中檢視清單。
+ **嚴重性**：對應至修補基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的**嚴重性**金鑰屬性的值。表示修補程式的嚴重性。
您可以使用 AWS CLI 命令**[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)**或 API 操作 來檢視支援的值清單**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**。您也可以在 Systems Manager 主控台之 **Create patch baseline** (建立修補基準) 頁面或 **Edit patch baseline** (編輯修補基準) 頁面的 **Approval rules** (核准規則) 區域中檢視清單。
受管節點的產物取決於 SSM Agent。此屬性對應至修補基準之 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 資料類型中的**產品**金鑰屬性的值。
對於每個修補程式，修補基準做為篩選條件使用，只允許更新中包含合格的套件。如果在套用修補基準定義後，有多個套件可以適用，將使用最新的版本。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
## 修補基準規則在 Ubuntu Server 上的運作方式
在 Ubuntu Server 上，修補基準服務提供*優先順序*與*區段*篩選欄位。這些欄位通常會顯示所有 Ubuntu Server 套件。為了判斷修補程式是否已被修補基準選取，Patch Manager 會執行下列動作：
1. 在 Ubuntu Server 系統上，會執行與 `sudo apt-get update` 相當的命令以重新整理可用套件清單。儲存區未設定，資料從設定於 `sources` 清單中的儲存區提取。
1. 若有可用於 `python3-apt` (`libapt` 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
1. 接著，將套用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 和 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 清單。
**注意**
因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。在這種情形下，對於 Ubuntu Server 來說，修補候選版本僅限於以下儲存庫中包含的修補程式：
+ Ubuntu Server 16.04 LTS︰`xenial-security`
+ Ubuntu Server 18.04 LTS︰`bionic-security`
+ Ubuntu Server 20.04 LTS︰`focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
若要檢視 *Priority (優先順序)* 和 *Section (區段)* 欄位的內容，請執行下列 `aptitude` 命令：
**注意**
您可能必須先在 Ubuntu Server 16 系統上安裝 Aptitude。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
在此命令的回應中，所有可升級的套裝將以此格式回報：
```
name, priority, section, archive, candidate version
```
如需有關修補程式合規狀態值的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
# Linux 和 Windows Server 之間的修補操作差異
本主題說明 Patch Manager ( AWS Systems Manager中的工具) 中 Linux 與 Windows Server 修補之間的重要差異。
**注意**
若要修補 Linux 受管節點，您的節點必須執行 SSM Agent 2.0.834.0 版或更新的版本。
當 Systems Manager 新增了新工具，或現有工具有更新時，會發行 SSM Agent 的更新版本。若未使用最新版本的 Agent，您的受管節點可能會無法使用 Systems Manager 中的各種工具及功能。因此，我們建議您讓機器的 SSM Agent 自動保持最新狀態。如需相關資訊，請參閱[自動化 SSM Agent 更新](ssm-agent-automatic-updates.md)。請訂閱 GitHub 上的 [SSM Agent 版本備註](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)頁面，以便接收有關 SSM Agent 更新的通知。
## 差異 1：修補程式評估
Patch Manager 會在 Windows 受管節點以及 Linux 受管節點上使用不同的程序，藉此評估哪些修補程式應該出現。
**Linux**
對於 Linux 修補，Systems Manager 會評估修補基準規則，以及*每個*受管節點上已核准與已拒絕修補程式的清單。Systems Manager 必須評估各個節點上的修補，因為服務會從受管節點上已設定的儲存庫擷取已知修補程式與更新的清單。
**Windows**
對於 Windows 修補，Systems Manager 會*直接在服務中*評估修補基準規則，以及已核准與已拒絕修補程式的清單。它可以這麼做，因為 Windows 修補程式皆來自於單一儲存庫 (Windows Update)。
## 差異 2：`Not Applicable` 修補程式
由於 Linux 作業系統有大量的可用套件，Systems Manager 不會報告狀態為*不適用*之修補程式的詳細資訊。例如，執行個體未安裝 Apache 時，`Not Applicable` 修補程式是 Apache 軟體的修補程式。Systems Manager 不會在摘要中報告 `Not Applicable` 修補程式的數目，但是如果您為受管節點呼叫 [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API，則傳回的資料不會包含狀態為 `Not Applicable` 的修補程式。此行為不同於 Windows。
## 差異 3：SSM 文件支援
`AWS-ApplyPatchBaseline` Systems Manager 文件 (SSM 文件) 不支援 Linux 受管節點。若要將修補基準套用至 Linux、macOS 和 Windows Server 受管節點，建議的 SSM 文件是 `AWS-RunPatchBaseline`。如需詳細資訊，請參閱[用於修補受管節點的 SSM 命令文件](patch-manager-ssm-documents.md)及[用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
## 差異 4：應用程式修補程式
Patch Manager 的主要重點是將修補程式套用到作業系統。不過，您也可以使用 Patch Manager 在您受管節點的一些應用程式上套用修補程式。
**Linux**
在 Linux 作業系統上，Patch Manager 會使用已設定儲存庫進行更新，且不會區分作業系統和應用程式的修補程式。您可以使用 Patch Manager 來定義要擷取更新的儲存庫。如需詳細資訊，請參閱[如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。
**Windows**
在 Windows Server 受管節點上，您可以為 Microsoft 發佈的應用程式 (如 Microsoft Word 2016 和 Microsoft Exchange Server 2016) 套用核准規則以及*已核准*和*已拒絕*的修補程式例外狀況。如需詳細資訊，請參閱[使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
## 差異 5：自訂修補基準中遭拒的修補程式清單選項
建立自訂修補基準時，可以為**遭拒的修補程式**清單指定一個或多個修補程式。對於 Linux 受管節點，如果它們是基準允許的其他修補程式的相依性，您也可以選擇允許安裝它們。
然而，Windows Server 不支援修補程式相依性的概念。您可以在 Windows Server 自訂基準中的**遭拒的修補程式**清單中新增修補程式，但結果取決於 (1) 是否已在受管節點上安裝拒絕的修補程式，以及 (2) 您為**拒絕的修補程式動作**選擇哪個選項。
如需有關 Windows Server 上遭拒的修補程式選項的詳細資訊，請參閱下表。
| 安裝狀態 | 選項：「當做相依性允許」 | 選項：「區塊」 |
| --- | --- | --- |
| 修補程式已安裝 | 報告狀態：INSTALLED\$1OTHER | 報告狀態：INSTALLED\$1REJECTED |
| 修補程式未安裝 | 修補程式已略過 | 修補程式已略過 |
Microsoft 發行的每個 Windows Server 修補程式通常都包含成功安裝所需的全部資訊。不過，有時可能需要您必須手動安裝的先決條件套件。Patch Manager 不會報告這些先決條件的相關資訊。如需相關資訊，請參閱 Microsoft 網站上的 [Windows Update 問題疑難解答](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)。
# 用於修補受管節點的 SSM 命令文件
此主題描述九個目前可用的 Systems Manager 文件 (SSM 文件)，協助您確保受管節點以最新的安全相關更新進行修補。
我們建議在您的修補操作中僅使用其中五個文件。這五個 SSM 文件可共同在您使用 AWS Systems Manager時提供完整的修補選項。其中四個文件的發佈晚於四個舊有 SSM 文件，它們取代並代表功能的擴充或合併。
**適用於修補的建議 SSM 文件**
我們建議在您的修補操作中使用下方的五個 SSM 文件。
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**適用於修補的舊版 SSM 文件**
下列四個舊版 SSM 文件仍可在某些 AWS 區域 中使用，但不再更新或受支援。這些文件不保證可在 IPv6 環境中運作，且僅支援 IPv4。無法保證它們適用於所有案例，且未來它們可能會失去支援。建議您不要將這些文件用於修補操作。
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
如需在僅支援 IPv6 的環境中設定修補操作的步驟，請參閱 [教學課程：修補僅限 IPv6 環境中的伺服器](patch-manager-server-patching-iPv6-tutorial.md)。
如需有關在修補操作中使用這些 SSM 文件的詳細資訊，請參閱以下部分。
**Topics**
+ [建議用於修補受管節點的 SSM 文件](#patch-manager-ssm-documents-recommended)
+ [用於修補受管節點的舊版 SSM 文件](#patch-manager-ssm-documents-legacy)
+ [修補受管節點的 SSM 文件已知限制](#patch-manager-ssm-documents-known-limitations)
+ [用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中 InstallOverrideList 參數的範例案例](patch-manager-override-lists.md)
+ [使用 BaselineOverride 參數](patch-manager-baselineoverride-parameter.md)
## 建議用於修補受管節點的 SSM 文件
建議在您的受管節點修補操作中，使用以下五個 SSM 文件。
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
支援設定基本 Windows Update 功能以及使用它們自動安裝更新 (或關閉自動更新)。在全部 AWS 區域中提供。
此 SSM 文件提示 Windows Update 下載並安裝指定的更新，然後視需要重新啟動受管節點。將此文件與 中的State Manager工具搭配使用 AWS Systems Manager，以確保 Windows Update 維持其組態。您也可以使用 中的Run Command工具手動執行它 AWS Systems Manager，以變更 Windows Update 組態。
此文件中可用的參數支援指定要安裝的更新類別 (或是否停用自動更新)，以及指定要在星期幾的什麼時間執行修補操作。如果您不需要嚴格控制 Windows 更新，也不需要收集合規資訊，那麼此 SSM 文件是最有用的。
**取代舊有 SSM 文件：**
+ *無*
### `AWS-InstallWindowsUpdates`
在 Windows Server 受管節點上安裝更新。在全部 AWS 區域中提供。
在您希望安裝特定更新 (使用 `Include Kbs` 參數)，或希望安裝特定分類或類別的更新，但不需要修補程式合規資訊時，此 SSM 文件可提供基本修補功能。
**取代舊有 SSM 文件：**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
三個舊有文件執行不同的功能，但您可以使用更新的 SSM 文件 `AWS-InstallWindowsUpdates` 與不同的參數設定達到相同的結果。這些參數設定如[用於修補受管節點的舊版 SSM 文件](#patch-manager-ssm-documents-legacy)中所述。
### `AWS-RunPatchBaseline`
在您的受管節點上安裝修補程式，或掃描節點以判斷是否有遺漏任何合格的修補程式。在全部 AWS 區域中提供。
`AWS-RunPatchBaseline` 允許您使用指定為作業系統類型之「預設」的修補基準來控制修補程式核准。報告修補程式合規資訊，您可以使用 Systems Manager 合規工具檢視。這些工具提供您受管節點修補程式合規狀態的洞見分析，例如哪些節點遺漏修補程式，以及遺漏的是哪些修補程式。當您使用 `AWS-RunPatchBaseline` 時，修補程式合規資訊會使用 `PutInventory` API 命令進行記錄。對於 Linux 作業系統，提供給修補程式的合規資訊來自受管節點上設定的預設來源儲存庫，以及您在自訂修補基準中指定的任何替代來源儲存庫。如需有關替代來源儲存庫的詳細資訊，請參閱 [如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。如需有關 Systems Manager 合規工具的詳細資訊，請參閱 [AWS Systems Manager合規](systems-manager-compliance.md)。
**取代舊有文件：**
+ `AWS-ApplyPatchBaseline`
舊版文件 `AWS-ApplyPatchBaseline` 僅適用於 Windows Server 受管節點，不支援應用程式修補。較新的 `AWS-RunPatchBaseline` 為 Windows 和 Linux 系統提供相同的支援。SSM Agent 的 2.0.834.0 版或更新版本，才能使用 `AWS-RunPatchBaseline` 文件。
如需 `AWS-RunPatchBaseline` SSM 文件的詳細資訊，請參閱 [用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
### `AWS-RunPatchBaselineAssociation`
在您的執行個體上安裝修補程式，或掃描執行個體以判斷是否有遺漏任何合格的修補程式。已在所有商業 AWS 區域提供。
`AWS-RunPatchBaselineAssociation` 在以下幾個重要方面不同於 `AWS-RunPatchBaseline`：
+ `AWS-RunPatchBaselineAssociation` 主要適用於使用 Quick Setup ( AWS Systems Manager中的工具) 建立的 State Manager 關聯。尤其是，當您使用 Quick Setup 主機管理組態類型時，如果您選擇 **Scan instances for missing patches daily** (每天掃描執行個體查看是否遺漏修補程式)，則系統會使用 `AWS-RunPatchBaselineAssociation` 進行操作。
不過，在大多數情況下，當設定自己的修補操作時，您應該選擇 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 或 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)，而不是 `AWS-RunPatchBaselineAssociation`。
如需詳細資訊，請參閱下列主題：
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` 支援使用標籤來識別執行一組目標時要與哪個修補基準搭配使用。
+ 對於使用 `AWS-RunPatchBaselineAssociation` 的修補操作，修補程式合規資料會根據特定 State Manager 關聯進行編譯。`AWS-RunPatchBaselineAssociation` 執行時收集的修補程式合規資料會使用 `PutComplianceItems` API 命令，而不是 `PutInventory` 命令進行記錄。這樣可以防止覆寫不與此特定關聯相關聯的合規資料。
對於 Linux 作業系統，提供給修補程式的合規資訊來自執行個體上設定的預設來源儲存庫，以及您在自訂修補基準中指定的任何替代來源儲存庫。如需有關替代來源儲存庫的詳細資訊，請參閱 [如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。如需有關 Systems Manager 合規工具的詳細資訊，請參閱 [AWS Systems Manager合規](systems-manager-compliance.md)。
**取代舊有文件：**
+ **無**
如需 `AWS-RunPatchBaselineAssociation` SSM 文件的詳細資訊，請參閱 [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)。
### `AWS-RunPatchBaselineWithHooks`
使用可在修補週期期間的三個點執行 SSM 文件的選用掛鉤，在您的受管節點上安裝修補程式，或掃描節點，以判斷是否遺漏任何合格的修補程式。已在所有商業 AWS 區域提供。macOS 上不支援。
`AWS-RunPatchBaselineWithHooks` 不同於其 `Install` 操作中的 `AWS-RunPatchBaseline`。
`AWS-RunPatchBaselineWithHooks` 支援在受管節點修補期間在指定點執行的生命週期掛鉤。由於修補程式安裝有時需要受管節點重新啟動，因此修補操作會分為兩個事件，總共有三個支援自訂功能的掛鉤。第一個掛鉤是在 `Install with NoReboot` 操作之前。第二個掛鉤是在 `Install with NoReboot` 操作之後。節點重新啟動後，第三個掛鉤可用。
**取代舊有文件：**
+ **無**
如需 `AWS-RunPatchBaselineWithHooks` SSM 文件的詳細資訊，請參閱 [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)。
## 用於修補受管節點的舊版 SSM 文件
以下四個 SSM 文件仍可於某些 AWS 區域中取得。但是，這些文件不會再更新而且可能在未來不再受到支援，因此不建議使用。反之，請使用[建議用於修補受管節點的 SSM 文件](#patch-manager-ssm-documents-recommended)中所述的文件。
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
僅支援 Windows Server 受管節點，但不支援修補其替換項 `AWS-RunPatchBaseline` 中找到的應用程式。不適用於 2017 年 8 月之後 AWS 區域 推出的 。
**注意**
此 SSM 文件的替代文件 `AWS-RunPatchBaseline`，需要 SSM Agent 的 2.0.834.0 版本或更新版。您可以使用 `AWS-UpdateSSMAgent` 文件將您的受管節點更新為最新版本的代理程式。
### `AWS-FindWindowsUpdates`
由 `AWS-InstallWindowsUpdates` 取代，可執行所有相同的動作。不適用於 2017 年 4 月之後 AWS 區域 推出的 。
為了達到與此舊有 SSM 文件相同的結果，請使用下列參數組態與建議的替代文件 `AWS-InstallWindowsUpdates`：
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
由 `AWS-InstallWindowsUpdates` 取代，可執行所有相同的動作。不適用於 2017 年 4 月之後 AWS 區域 啟動的任何 。
為了達到與此舊有 SSM 文件相同的結果，請使用下列參數組態與建議的替代文件 `AWS-InstallWindowsUpdates`：
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
由 `AWS-InstallWindowsUpdates` 取代，可執行所有相同的動作。不適用於 2017 年 4 月之後 AWS 區域 啟動的任何 。
為了達到與此舊有 SSM 文件相同的結果，請使用下列參數組態與建議的替代文件 `AWS-InstallWindowsUpdates`：
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *逗號分隔的 KB 文章清單*
## 修補受管節點的 SSM 文件已知限制
### 外部重新啟動中斷
如果在修補程式安裝期間由節點上的系統啟動重新啟動 （例如，將更新套用至韌體或功能，例如 SecureBoot)，即使修補程式已成功安裝，修補文件執行仍可能會中斷並標記為失敗。這是因為 SSM 代理程式無法在外部重新啟動期間持續並繼續文件執行狀態。
若要在失敗執行後驗證修補程式安裝狀態，請執行`Scan`修補操作，然後檢查修補程式管理員中的修補程式合規資料，以評估目前的合規狀態。
# 用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`
AWS Systems Manager 支援 `AWS-RunPatchBaseline`、適用於 的 Systems Manager 文件 (SSM 文件）Patch Manager、 中的工具 AWS Systems Manager。此 SSM 文件在受管節點上執行與安全相關和其他更新類型的修補操作。執行文件時，如果未指定修補程式群組，則會使用指定為作業系統類型之「預設」的修補基準。否則，它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊，請參閱 [修補程式群組](patch-manager-patch-groups.md)。
您可以使用 `AWS-RunPatchBaseline` 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發行的應用程式更新。)
本文件支援 Linux、macOS，以及 Windows Server 受管節點。此文件會為各個平台執行適當的動作。
**注意**
Patch Manager 也支援舊版 SSM 文件 `AWS-ApplyPatchBaseline`。不過，此文件僅支援 Windows 受管節點上的修補。建議您改為使用 `AWS-RunPatchBaseline`，因為它支援在 Linux、macOS 和 Windows Server 受管節點上修補。SSM Agent 的 2.0.834.0 版或更新版本，才能使用 `AWS-RunPatchBaseline` 文件。
------
#### [ Windows Server ]
在 Windows Server 受管節點上，`AWS-RunPatchBaseline` 文件會下載並叫用 PowerShell 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照集包含已核准修補程式清單，這些修補程式是藉由查詢修補基準針對 Windows Server 更新服務 (WSUS) 伺服器進行編譯。此清單會傳遞至 Windows Update API，視需要控制下載和安裝核准的修補程式。
------
#### [ Linux ]
在 Linux 受管節點上，`AWS-RunPatchBaseline` 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照使用已定義的規則，以及已核准與已封鎖的修補程式清單，為各個節點類型推動適當的套件管理員：
+ Amazon Linux 2、Oracle Linux 和 RHEL 7 受管節點使用 YUM。針對 YUM 操作，Patch Manager 需要 `Python 2.6` 或更新版本的支援版本 (2.6 - 3.12)。Amazon Linux 2023 使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。
+ RHEL 8 受管節點使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。(預設不會在 RHEL 8 上安裝兩個版本。您必須手動安裝其中一個。)
+ Debian Server 和 Ubuntu Server 執行個體使用 APT。針對 APT 操作，Patch Manager 需要 `Python 3` 的支援版本 (3.0 - 3.12)。
------
#### [ macOS ]
在 macOS 受管節點上，`AWS-RunPatchBaseline` 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。接著，Python 子程序會叫用節點上的 AWS Command Line Interface (AWS CLI)，以擷取指定套件管理員的安裝和更新資訊，並為每個更新套件驅動適當的套件管理員。
------
每個快照都專屬於 AWS 帳戶、修補程式群組、作業系統和快照 ID。快照是透過預先簽署的 Amazon Simple Storage Service (Amazon S3) URL 交付，快照會在建立後 24 小時過期。不過，URL 過期後，如果想要將相同的快照內容套用到其他受管節點，則您可以在建立快照後最多 3 天內產生新的預先簽署 Amazon Simple Storage Service (Amazon S3) URL。若要這麼做，請使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 命令。
在安裝所有已核准且適用的更新，並視需要重新啟動之後，會在受管節點上產生修補程式合規資訊，並回報 Patch Manager。
**注意**
如果在 `AWS-RunPatchBaseline` 文件中將 `RebootOption` 參數設定為 `NoReboot`，則在執行 Patch Manager 後不會重新啟動受管節點。如需詳細資訊，請參閱[參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。
如需有關檢視修補程式合規資料的詳細資訊，請參閱[關於修補程式合規](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaseline` 參數
`AWS-RunPatchBaseline` 支援六個參數。`Operation` 參數是必要參數。`InstallOverrideList`、`BaselineOverride` 和 `RebootOption` 參數是選用的。`Snapshot-ID` 技術上是選用的，但我們建議您在維護時段之外執行 `AWS-RunPatchBaseline` 時提供自訂值，並讓 Patch Manager 在該文件做為維護時段操作的一部分執行時自動提供自訂值。
**Topics**
+ [參數名稱：`Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [參數名稱：`AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [參數名稱：`Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [參數名稱：`InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [參數名稱：`BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [參數名稱：`StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### 參數名稱：`Operation`
**用量**：必要。
**選項**：`Scan` \$1 `Install`。
Scan
當您選擇 `Scan` 選項時，`AWS-RunPatchBaseline` 會判斷受管節點的修補程式合規狀態，並將此資訊回報至 Patch Manager。`Scan` 不會提示要安裝的更新或需要重新啟動的受管節點。反之，此操作會識別遺漏了哪些已核准且適用於節點的更新。
安裝
當您選擇 `Install` 選項，`AWS-RunPatchBaseline` 會嘗試安裝受管節點上遺漏的已核准且適用的更新。在 `Install` 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時，節點將重新啟動，以確保安裝並啟動更新。(例外：如果 `AWS-RunPatchBaseline` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。)
如果在 Patch Manager 更新受管節點*之前*已安裝基準規則指定的修補程式，系統可能無法如預期重新啟動。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 `unattended-upgrades` 套件) 時，就會發生這種情況。
### 參數名稱：`AssociationId`
**用量**：選用。
`AssociationId` 是 State Manager ( AWS Systems Manager中的工具) 中的現有關聯的 ID。它由 Patch Manager 使用，將合規資料新增至指定的關聯。此關聯與 [Quick Setup 中的修補程式政策中設定](quick-setup-patch-manager.md)的修補操作有關。
**注意**
使用 `AWS-RunPatchBaseline` 時，如果提供 `AssociationId` 值時發生修補程式政策基準覆寫，則修補會以 `PatchPolicy` 操作的形式完成，且 `AWS:ComplianceItem` 中報告的 `ExecutionType` 值也為 `PatchPolicy`。如果未提供任何 `AssociationId` 值，則會以 `Command` 操作形式完成修補，而且提交的 `AWS:ComplianceItem` 中報告的 `ExecutionType` 值也為 `Command`。
如果您還沒有想要使用的關聯，則可以透過執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 命令建立關聯。
### 參數名稱：`Snapshot ID`
**用量**：選用。
`Snapshot ID` 是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組受管節點皆有一組完全相同的核准修補程式。雖然此參數定義為選用，但我們的最佳實務建議取決於您是否會在維護時段中執行 `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 值。 | 如果您不是使用維護時段執行 `AWS-RunPatchBaseline`，我們建議您為每個修補基準產生並指定唯一的快照 ID，特別是如果您在相同的操作中，在多個受管節點上執行 `AWS-RunPatchBaseline` 文件時。如果您在此情況下沒有指定 ID，Systems Manager 將為命令傳送至的每個受管節點產生不同的快照 ID。這可能會導致在受管節點間指定不同的修補程式集合。 例如，假設您正在直接透過 Run Command ( AWS Systems Manager中的工具) 執行 `AWS-RunPatchBaseline` 文件，並以包含 50 個受管節點的群組為目標。指定自訂快照 ID 會產生單一基準快照，用於評估和修補所有節點，以確保它們最終處於一致的狀態。 |
| ¹您可以使用任何能產生 GUID 的工具來為快照 ID 參數產生一個值。例如，在 PowerShell，您可以使用 `New-Guid` cmdlet 產生 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 格式的 GUID。 |
### 參數名稱：`InstallOverrideList`
**用量**：選用。
使用 `InstallOverrideList`，您可以將 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL 指定至要安裝的修補程式清單。此修補程式安裝清單 (以 YAML 格式維護) 會覆寫目前預設修補基準指定的修補程式。這可讓您更精密地控制哪些修補程式將安裝於您的受管節點。
**重要**
`InstallOverrideList` 檔案名稱不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。
使用 `InstallOverrideList` 參數時的修補操作行為在 Linux 和 macOS 受管節點與 Windows Server 受管節點之間有所不同。在 Linux 與 macOS 上，Patch Manager 會嘗試套用 `InstallOverrideList` 修補程式清單中包含的修補程式，這些修補程式存在於節點上啟用的任何儲存庫中，無論修補程式是否符合修補基準規則。不過，*只有*在 `InstallOverrideList` 修補程式清單中的修補程式也符合修補基準規則時，才會在 Windows Server 節點上套用修補程式。
請注意，合規報告根據修補基準中的指定來反映修補程式狀態，而非您在 `InstallOverrideList` 合規清單中的指定。換言之，掃描操作會忽略 `InstallOverrideList` 參數。這是為了確保合規報告根據政策而非已核准用於特定修補操作的內容，來持續反映修補程式狀態。
**注意**
當您修補僅使用 IPv6 的節點時，請確定提供的 URL 可從節點連線。如果SSM Agent組態選項`UseDualStackEndpoint`設定為 `true`，則會在提供 S3 URL 時使用雙堆疊 S3 用戶端。[教學課程：修補僅限 IPv6 環境中的伺服器](patch-manager-server-patching-iPv6-tutorial.md) 如需將代理程式設定為使用 dualstack 的詳細資訊，請參閱 。
如需如何使用 `InstallOverrideList` 參數依不同的維護時段排程將不同類型的修補程式套用至目標群組的說明，同時繼續單一修補基準，請參閱[使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中 InstallOverrideList 參數的範例案例](patch-manager-override-lists.md)。
**有效的 URL 格式**
**注意**
如果您的檔案存放在公開可用的儲存貯體中，則可以指定 https URL 格式或 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。如果您的檔案存放在私有儲存貯體中，則必須指定 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。
+ **https URL 格式**：
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon Simple Storage Service (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](http://www.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，並回報為「Failed-NonCompliant」。
------
#### [ Windows Server ]
**id**
**id** 欄位是必要的。利用它來使用 Microsoft 知識庫 ID (例如 KB2736693) 和 Microsoft 資訊安全佈告欄 ID (例如 MS17-023) 指定修補程式。
您想在 Windows 修補程式清單中提供的任何其他欄位都是選用的，並僅供自己參考。您可以使用其他欄位，例如**標題**、**分類**、**嚴重性**等，提供有關指定的修補程式的更多詳細資訊。
------
#### [ macOS ]
**id**
**id** 欄位是必要的。**id** 欄位的值可以使用 `{package-name}.{package-version}` 格式或 \$1package\$1name\$1 格式。
------
**範例修補程式清單**
+ **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'
```
+ **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` \$1 `NoReboot`
**預設**：`RebootIfNeeded`
**警告**
預設選項為 `RebootIfNeeded`。請務必選取適用於您使用案例的正確選項。例如，如果您的受管節點必須立即重新啟動才能完成組態程序，則請選擇 `RebootIfNeeded`。或者，如果您需要維持受管節點的可用性，直到排定的重新啟動時間，則請選擇 `NoReboot`。
**重要**
我們不建議使用 Patch Manager 修補 Amazon EMR (以前稱為 Amazon Elastic MapReduce) 中的叢集執行個體。特別是，請勿為 `RebootOption` 參數選取 `RebootIfNeeded` 選項。(此選項在用於修補 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks` 的 SSM 命令文件中可用。)
使用 Patch Manager 進行修補時所使用的基礎命令使用 `yum` 和 `dnf` 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊，請參閱《Amazon EMR 管理指南》**中的[使用 Amazon EMR 的預設 AMI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) 一節。
RebootIfNeeded
當您選擇 `RebootIfNeeded` 選項時，受管節點在下列情況下會重新啟動：
+ Patch Manager 已安裝一或多個修補程式。
Patch Manager 不會評估修補程式是否*需要*重新開機。即使修補程式不需要重新開機，系統也會重新開機。
+ Patch Manager 偵測到一或多個修補程式在 `Install` 操作期間狀態為 `INSTALLED_PENDING_REBOOT`。
`INSTALLED_PENDING_REBOOT` 狀態可能表示上次執行 `Install` 操作時已選取 `NoReboot` 選項，或者自上次重新啟動受管節點後，已在 Patch Manager 外部安裝修補程式。
在這兩種情況下重新啟動受管節點，可確保更新的套件會從記憶體中清除，並在所有作業系統中保持修補和重新啟動行為一致。
NoReboot
當您選擇 `NoReboot` 選項時，即使受管節點在 `Install` 作業期間安裝了修補程式，Patch Manager 也不會重新啟動受管節點。如果您知道您的受管節點在套用修補程式之後不需要重新啟動，或是您在節點上執行的應用程式或程序不應因於修補操作重新啟動而中斷，則此選項非常有用。當您想要進一步控制受管節點重新啟動的時間時 (例如使用維護時段)，此選項也很有用。
如果您選擇 `NoReboot` 選項並安裝修補程式，則會為修補程式指派 `InstalledPendingReboot` 的狀態。但是，受管節點本身會標示為 `Non-Compliant`。重新啟動並執行 `Scan` 操作之後，受管節點狀態會更新為 `Compliant`。
`NoReboot` 選項只會防止作業系統層級的重新啟動。服務層級的重新啟動仍然可能在修補程序中發生。例如，Docker 更新後，即使啟用了 `NoReboot`，Amazon Elastic Container Service 等相依服務也可能自動重新啟動。如果您有不能中斷的重要服務，請考慮採取其他措施，例如暫時從服務中移除執行個體或在維護時段期間排程修補。
**修補程式安裝追蹤檔案**：若要追蹤修補程式安裝，特別是自上次系統重新啟動後已安裝的修補程式，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` 檔案名稱不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。
如需使用 `BaselineOverride` 參數的詳細資訊，請參閱 [使用 BaselineOverride 參數](patch-manager-baselineoverride-parameter.md)。
### 參數名稱：`StepTimeoutSeconds`
**用量**：必要。
在命令完成到被認定為失敗之間的秒數，即 1 至 36,000 秒 (10 小時) 之間。
# 用於修補的 SSM 命令文件：`AWS-RunPatchBaselineAssociation`
像 `AWS-RunPatchBaseline` 文件，`AWS-RunPatchBaselineAssociation` 在執行個體上執行與安全相關和其他更新類型的修補操作。您還可以使用 `AWS-RunPatchBaselineAssociation` 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發佈的應用程式更新。)
本文件支援適用於 Linux、macOS 和 Windows Server 的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。其不支援[混合多雲端](operating-systems-and-machine-types.md#supported-machine-types)環境中的非 EC2 節點。文件將在各個平台執行適當的動作，在 Linux 和 macOS 執行個體上叫用 Python 模組，在 Windows 執行個體上叫用 PowerShell 模組。
但是，`AWS-RunPatchBaselineAssociation` 在以下方面不同於 `AWS-RunPatchBaseline`：
+ `AWS-RunPatchBaselineAssociation` 主要適用於使用 [Quick Setup](systems-manager-quick-setup.md) ( AWS Systems Manager中的工具) 建立的 State Manager 關聯。尤其是，當您使用 Quick Setup 主機管理組態類型時，如果您選擇 **Scan instances for missing patches daily** (每天掃描執行個體查看是否遺漏修補程式)，則系統會使用 `AWS-RunPatchBaselineAssociation` 進行操作。
不過，在大多數情況下，當設定自己的修補操作時，您應該選擇 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 或 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)，而不是 `AWS-RunPatchBaselineAssociation`。
+ 使用 `AWS-RunPatchBaselineAssociation` 文件時，您可以在文件的 `BaselineTags` 參數欄位指定標籤金鑰對。如果您的 中的自訂修補程式基準 AWS 帳戶 共用這些標籤， Patch Manager中的工具會在目標執行個體上執行時使用該標記的基準 AWS Systems Manager，而不是目前為作業系統類型指定的「預設」修補程式基準。
**注意**
如果您選擇使用修補操作中的 `AWS-RunPatchBaselineAssociation`，而不是使用 Quick Setup 的設定，並且您想要使用其選用 `BaselineTags` 參數，則必須提供部分額外的許可給[執行個體設定檔](setup-instance-permissions.md)，用於 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。如需詳細資訊，請參閱[參數名稱：`BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)。
以下兩種格式對 `BaselineTags` 參數都是有效的：
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
標籤索引鍵和值不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。
+ `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 2` 或 `Python 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`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)。
如需有關檢視修補程式合規資料的詳細資訊，請參閱[關於修補程式合規](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaselineAssociation` 參數
`AWS-RunPatchBaselineAssociation` 支援五個參數。`Operation` 和 `AssociationId` 是必要參數。`InstallOverrideList`、`RebootOption` 和 `BaselineTags` 是選用參數。
**Topics**
+ [參數名稱：`Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [參數名稱：`BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [參數名稱：`AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [參數名稱：`InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### 參數名稱：`Operation`
**用量**：必要。
**選項**：`Scan` \$1 `Install`。
Scan
當您選擇 `Scan` 選項時，`AWS-RunPatchBaselineAssociation` 會判斷執行個體的修補程式合規狀態，並將此資訊回報至 Patch Manager。`Scan` 不會提示要安裝的更新或需要重新啟動的執行個體。反之，此操作會識別遺漏哪些已核准且適用於執行個體的更新。
安裝
當您選擇 `Install` 選項，`AWS-RunPatchBaselineAssociation` 會嘗試安裝執行個體上遺漏的已核准且適用的更新。在 `Install` 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於執行個體時，執行個體將重新啟動，以確保安裝並啟動更新。(例外：如果 `AWS-RunPatchBaselineAssociation` 文件中的 `RebootOption` 參數設為 `NoReboot`，執行個體不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)。)
如果在 Patch Manager 更新執行個體*之前*已安裝基準規則指定的修補程式，系統可能無法如預期重新開機。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 `unattended-upgrades` 套件) 時，就會發生這種情況。
### 參數名稱：`BaselineTags`
**用量**：選用。
`BaselineTags` 是唯一的標籤鍵值對，您可以選擇並指派給個別自訂修補基準。您可以為此參數指定一或多個值。以下兩種格式都是有效的：
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
標籤索引鍵和值不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。
`BaselineTags` 值是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組執行個體皆有一組完全相同的核准修補程式。修補操作執行時，Patch Manager 會檢查作業系統類型的修補基準是否已使用您為 `BaselineTags` 指定的相同鍵值對進行標記。如果有相符項目，則會使用此自訂修補基準。如果沒有相符項目，則會根據針對修補操作指定的任何修補程式群組來識別修補基準。如果沒有，則會使用該作業系統的 AWS 受管預先定義修補程式基準。
**額外的許可要求**
如果您使用修補操作中的 `AWS-RunPatchBaselineAssociation`，而不是使用 Quick Setup 的設定，並且您想要使用其選用 `BaselineTags` 參數，則必須新增以下許可給[執行個體設定檔](setup-instance-permissions.md)，用於 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 中建立的主機管理組態](quick-setup-host-management.md)中啟用的修補程式 `Scan` 操作有關。藉由傳送修補結果作為關聯合規資料而非庫存合規資料，不會在修補操作之後覆寫執行個體的現有庫存合規資訊，也不會複寫其他關聯 ID。如果您還沒有想要使用的關聯，則可以透過執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 命令建立關聯。例如：
------
#### [ 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` 檔案名稱不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。
使用 `InstallOverrideList` 參數時的修補操作行為在 Linux 和 macOS 受管節點與 Windows Server 受管節點之間有所不同。在 Linux 與 macOS 上，Patch Manager 會嘗試套用 `InstallOverrideList` 修補程式清單中包含的修補程式，這些修補程式存在於節點上啟用的任何儲存庫中，無論修補程式是否符合修補基準規則。不過，*只有*在 `InstallOverrideList` 修補程式清單中的修補程式也符合修補基準規則時，才會在 Windows Server 節點上套用修補程式。
請注意，合規報告根據修補基準中的指定來反映修補程式狀態，而非您在 `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](http://www.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` \$1 `NoReboot`
**預設**：`RebootIfNeeded`
**警告**
預設選項為 `RebootIfNeeded`。請務必選取適用於您使用案例的正確選項。例如，如果您的執行個體必須立即重新啟動才能完成組態程序，則請選擇 `RebootIfNeeded`。或者，如果您需要維持執行個體的可用性，直到排定的重新啟動時間，則請選擇 `NoReboot`。
**重要**
`NoReboot` 選項只會防止作業系統層級的重新啟動。服務層級的重新啟動仍然可能在修補程序中發生。例如，Docker 更新後，即使啟用了 `NoReboot`，Amazon Elastic Container Service 等相依服務也可能自動重新啟動。如果您有不能中斷的重要服務，請考慮採取其他措施，例如暫時從服務中移除執行個體或在維護時段期間排程修補。
**重要**
我們不建議使用 Patch Manager 修補 Amazon EMR (以前稱為 Amazon Elastic MapReduce) 中的叢集執行個體。特別是，請勿為 `RebootOption` 參數選取 `RebootIfNeeded` 選項。(此選項在用於修補 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks` 的 SSM 命令文件中可用。)
使用 Patch Manager 進行修補時所使用的基礎命令使用 `yum` 和 `dnf` 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊，請參閱《Amazon EMR 管理指南》**中的[使用 Amazon EMR 的預設 AMI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) 一節。
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`
# 用於修補的 SSM 命令文件：`AWS-RunPatchBaselineWithHooks`
AWS Systems Manager 支援 `AWS-RunPatchBaselineWithHooks`、適用於 的 Systems Manager 文件 (SSM 文件）Patch Manager、 中的工具 AWS Systems Manager。此 SSM 文件在受管節點上執行與安全相關和其他更新類型的修補操作。
`AWS-RunPatchBaselineWithHooks` 在以下方面不同於 `AWS-RunPatchBaseline`：
+ **包裝文件**–`AWS-RunPatchBaselineWithHooks` 是 `AWS-RunPatchBaseline` 的包裝，並依賴 `AWS-RunPatchBaseline` 進行其操作。
+ **`Install` 操作** – `AWS-RunPatchBaselineWithHooks` 支援在受管節點修補期間在指定點執行的生命週期掛鉤。由於修補程式安裝有時需要受管節點重新啟動，因此修補操作會分為兩個事件，總共有三個支援自訂功能的掛鉤。第一個掛鉤是在 `Install with NoReboot` 操作之前。第二個掛鉤是在 `Install with NoReboot` 操作之後。受管節點重新啟動後，第三個掛鉤可用。
+ **不支援自訂修補程式清單** – `AWS-RunPatchBaselineWithHooks` 不支援 `InstallOverrideList` 參數。
+ **SSM Agent 支援** – `AWS-RunPatchBaselineWithHooks` 需要 SSM Agent 3.0.502 或更新版本安裝在要修補的受管節點上。
執行文件時，如果未指定修補程式群組，則會使用當前指定為作業系統類型之「預設」的修補基準。否則，它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊，請參閱 [修補程式群組](patch-manager-patch-groups.md)。
您可以使用 `AWS-RunPatchBaselineWithHooks` 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發行的應用程式更新。)
本文件支援 Linux 以及 Windows Server 受管節點。此文件會為各個平台執行適當的動作。
**注意**
macOS 不支援 `AWS-RunPatchBaselineWithHooks`。
------
#### [ Linux ]
在 Linux 受管節點上，`AWS-RunPatchBaselineWithHooks` 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照使用已定義的規則，以及已核准與已封鎖的修補程式清單，為各個節點類型推動適當的套件管理員：
+ Amazon Linux 2、Oracle Linux 和 RHEL 7 受管節點使用 YUM。針對 YUM 操作，Patch Manager 需要 `Python 2.6` 或更新版本的支援版本 (2.6 - 3.12)。Amazon Linux 2023 使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。
+ RHEL 8 受管節點使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。(預設不會在 RHEL 8 上安裝兩個版本。您必須手動安裝其中一個。)
+ Debian Server 和 Ubuntu Server 執行個體使用 APT。針對 APT 操作，Patch Manager 需要 `Python 3` 的支援版本 (3.0 - 3.12)。
------
#### [ Windows Server ]
在 Windows Server 受管節點上，`AWS-RunPatchBaselineWithHooks` 文件會下載並叫用 PowerShell 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照集包含已核准修補程式清單，這些修補程式是藉由查詢修補基準針對 Windows Server 更新服務 (WSUS) 伺服器進行編譯。此清單會傳遞至 Windows Update API，視需要控制下載和安裝核准的修補程式。
------
每個快照都專屬於 AWS 帳戶、修補程式群組、作業系統和快照 ID。快照是透過預先簽署的 Amazon Simple Storage Service (Amazon S3) URL 交付，快照會在建立後 24 小時過期。不過，URL 過期後，如果想要將相同的快照內容套用到其他受管節點，則您可以在建立快照後最多三天內產生新的預先簽署 Amazon Simple Storage Service (Amazon S3) URL。若要這麼做，請使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 命令。
在安裝所有已核准且適用的更新，並視需要重新啟動之後，會在受管節點上產生修補程式合規資訊，並回報 Patch Manager。
如果在 `AWS-RunPatchBaselineWithHooks` 文件中將 `RebootOption` 參數設定為 `NoReboot`，則在執行 Patch Manager 後不會重新啟動受管節點。如需詳細資訊，請參閱[參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。
**重要**
雖然 `NoReboot` 選項可防止作業系統重新啟動，但無法防止更新特定套件時可能發生的服務層級重新啟動。例如，即使 `NoReboot` 已指定，更新 Docker 之類的套件也可能會觸發相依服務 (例如容器協同運作服務) 的自動重新啟動。
如需有關檢視修補程式合規資料的詳細資訊，請參閱[關於修補程式合規](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaselineWithHooks` 操作步驟
當 `AWS-RunPatchBaselineWithHooks` 執行時，會進行下列步驟：
1. **掃描** – 在受管節點上執行使用 `AWS-RunPatchBaseline` 的 `Scan` 操作，並產生並上傳合規報告。
1. **確認本機修補程式狀態** – 執行指令碼，以確定將根據所選的操作和步驟 1 的 `Scan` 結果執行什麼步驟。
1. 如果選取的操作為 `Scan`，則操作會標示為完成。操作結束。
1. 如果選取的操作為 `Install`，則 Patch Manager 會評估步驟 1 的 `Scan` 結果，以確定接下來要執行的內容：
1. 如果未偵測到遺漏的修補程式，且不需要擱置中的重新開機，則操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。
1. 如果未偵測到遺漏的修補程式，但有所需的擱置中重新開機，且所選重新開啟選項為 `NoReboot`，則操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。
1. 否則，操作會繼續至下一個步驟。
1. **修補程式前掛鉤操作** - 您為第一個lifecycle hook `PreInstallHookDocName` 提供的 SSM 文件在受管節點上執行。
1. **使用 NoReboot 安裝** – 使用 `AWS-RunPatchBaseline` 且具有 `NoReboot` 重啟啟動選項的 `Install` 操作在受管節點上執行，還會產生並上傳合規報告。
1. **安裝後掛鉤操作** - 您為第二個lifecycle hook `PostInstallHookDocName` 提供的 SSM 文件在受管節點上執行。
1. **確認重新啟動** – 執行指令碼以判斷受管節點是否需要重新開機，以及需要執行哪些步驟：
1. 如果選取的重新開機選項為 `NoReboot`，則操作會直接進行到最後一個步驟 (步驟 8)，其中包含您提供的掛鉤。兩者之間的任何步驟都會略過。
1. 如果選取的重新開機選項為 `RebootIfNeeded`，則 Patch Manager 會檢查步驟 4 中所收集的庫存是否有所需之任何擱置中的重新開機。這意味著在下列任一情況下，作業會繼續執行步驟 7，且受管節點會重新啟動：
1. Patch Manager 已安裝一個或多個修補程式。(Patch Manager 不評估修補程式是否需要重新啟動。即使修補程式不需要重新啟動，系統也會重新啟動。)
1. Patch Manager 偵測到一或多個修補程式在安裝操作期間狀態為 `INSTALLED_PENDING_REBOOT`。`INSTALLED_PENDING_REBOOT` 狀態可能表示上次 Install 操作時已選取 `NoReboot` 選項，或者自上次重新啟動受管節點後，已在 Patch Manager 外部安裝修補程式。
如果找不到需要符合這些條件的修補程式，則受管節點修補操作即完成，且操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。
1. **重新啟動和報告** – 具有 `RebootIfNeeded` 重啟啟動選項的安裝操作在使用 `AWS-RunPatchBaseline` 的受管節點上執行，還會產生並上傳合規報告。
1. **重新啟動後掛鉤操作** – 您為第三個lifecycle hook `OnExitHookDocName` 提供的 SSM 文件在受管節點上執行。
對於 `Scan` 操作，如果步驟 1 失敗，則執行文件的程序會停止並報告為失敗，儘管後續步驟會報告為成功。
對於 `Install` 操作，如果有任何 `aws:runDocument` 步驟在操作期間失敗，則這些步驟會報告為失敗，而且操作會直接進行到最後一個步驟 (步驟 8)，其中包含您提供的掛鉤。兩者之間的任何步驟都會略過。此步驟會報告為失敗，最後一個步驟會報告其操作結果的狀態，而兩者之間的所有步驟都會報告為成功。
## `AWS-RunPatchBaselineWithHooks` 參數
`AWS-RunPatchBaselineWithHooks` 支援六個參數。
`Operation` 參數是必要參數。
`RebootOption`、`PreInstallHookDocName`、`PostInstallHookDocName` 和 `OnExitHookDocName` 是選用參數。
`Snapshot-ID` 在技術上是選用的，但建議您在維護時段以外執行 `AWS-RunPatchBaselineWithHooks` 時，為其提供自訂值。當文件以維護時段操作的一部分執行時，讓 Patch Manager 自動提供值。
**Topics**
+ [參數名稱：`Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [參數名稱：`Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [參數名稱：`PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [參數名稱：`PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [參數名稱：`OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### 參數名稱：`Operation`
**用量**：必要。
**選項**：`Scan` \$1 `Install`。
Scan
當您選擇 `Scan` 選項時，系統會使用 `AWS-RunPatchBaseline` 文件判斷受管節點的修補程式合規狀態，並將此資訊回報至 Patch Manager。`Scan` 不會提示要安裝的更新或需要重新啟動的受管節點。反之，此操作會識別遺漏了哪些已核准且適用於節點的更新。
安裝
當您選擇 `Install` 選項，`AWS-RunPatchBaselineWithHooks` 會嘗試安裝受管節點上遺漏的已核准且適用的更新。在 `Install` 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時，節點將重新啟動，以確保安裝並啟動更新。(例外：如果 `AWS-RunPatchBaselineWithHooks` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)。)
如果在 Patch Manager 更新受管節點*之前*已安裝基準規則指定的修補程式，系統可能無法如預期重新啟動。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 `unattended-upgrades` 套件) 時，就會發生這種情況。
### 參數名稱：`Snapshot ID`
**用量**：選用。
`Snapshot ID` 是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組受管節點皆有一組完全相同的核准修補程式。雖然此參數定義為選用，但我們的最佳實務建議取決於您是否會在維護時段中執行 `AWS-RunPatchBaselineWithHooks`，如下表所述。
**`AWS-RunPatchBaselineWithHooks` 最佳實務**
| Mode | 最佳實務 | 詳細資訊 |
| --- | --- | --- |
| 在維護時段內執行 AWS-RunPatchBaselineWithHooks | 請勿提供快照 ID。Patch Manager 將會為您提供。 | 若您使用維護時段執行 `AWS-RunPatchBaselineWithHooks`，您不應提供自己產生的快照 ID。在此案例中，Systems Manager 會根據維護時段執行 ID 提供 GUID 值。這可確保維護時段中所有 `AWS-RunPatchBaselineWithHooks` 呼叫皆使用正確的 ID。 如果您在此情況下指定值，則請注意修補基準的快照可能不會保留超過 3 天。之後，即使您在快照過期後指定相同的 ID，仍將會產生新的快照。 |
| 在維護時段外執行 AWS-RunPatchBaselineWithHooks | 為快照 ID¹ 產生及指定自訂 GUID 值。 | 如果您不是使用維護時段執行 `AWS-RunPatchBaselineWithHooks`，我們建議您為每個修補基準產生並指定唯一的快照 ID，特別是如果您在相同的操作中，在多個受管節點上執行 `AWS-RunPatchBaselineWithHooks` 文件時。如果您在此情況下沒有指定 ID，Systems Manager 將為命令傳送至的每個受管節點產生不同的快照 ID。這可能會導致在節點間指定不同的修補程式集合。 例如，假設您正在直接透過 Run Command (AWS Systems Manager中的工具) 執行 `AWS-RunPatchBaselineWithHooks` 文件，並以包含 50 個受管節點的群組為目標。指定自訂快照 ID 會產生單一基準快照，用於評估和修補所有受管節點，以確保它們最終處於一致的狀態。 |
| ¹您可以使用任何能產生 GUID 的工具來為快照 ID 參數產生一個值。例如，在 PowerShell，您可以使用 `New-Guid` cmdlet 產生 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 格式的 GUID。 |
### 參數名稱：`RebootOption`
**用量**：選用。
**選項**: `RebootIfNeeded` \$1 `NoReboot`
**預設**：`RebootIfNeeded`
**警告**
預設選項為 `RebootIfNeeded`。請務必選取適用於您使用案例的正確選項。例如，如果您的受管節點必須立即重新啟動才能完成組態程序，則請選擇 `RebootIfNeeded`。或者，如果您需要維持受管節點的可用性，直到排定的重新啟動時間，則請選擇 `NoReboot`。
**重要**
我們不建議使用 Patch Manager 修補 Amazon EMR (以前稱為 Amazon Elastic MapReduce) 中的叢集執行個體。特別是，請勿為 `RebootOption` 參數選取 `RebootIfNeeded` 選項。(此選項在用於修補 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks` 的 SSM 命令文件中可用。)
使用 Patch Manager 進行修補時所使用的基礎命令使用 `yum` 和 `dnf` 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊，請參閱《Amazon EMR 管理指南》**中的[使用 Amazon EMR 的預設 AMI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) 一節。
RebootIfNeeded
當您選擇 `RebootIfNeeded` 選項時，受管節點在下列情況下會重新啟動：
+ Patch Manager 已安裝一或多個修補程式。
Patch Manager 不會評估修補程式是否*需要*重新開機。即使修補程式不需要重新開機，系統也會重新開機。
+ Patch Manager 偵測到一或多個修補程式在 `Install` 操作期間狀態為 `INSTALLED_PENDING_REBOOT`。
`INSTALLED_PENDING_REBOOT` 狀態可能表示上次執行 `Install` 操作時已選取 `NoReboot` 選項，或者自上次重新啟動受管節點後，已在 Patch Manager 外部安裝修補程式。
在這兩種情況下重新啟動受管節點，可確保更新的套件會從記憶體中清除，並在所有作業系統中保持修補和重新啟動行為一致。
NoReboot
當您選擇 `NoReboot` 選項時，即使受管節點在 `Install` 作業期間安裝了修補程式，Patch Manager 也不會重新啟動受管節點。如果您知道您的受管節點在套用修補程式之後不需要重新啟動，或是您在節點上執行的應用程式或程序不應因於修補操作重新啟動而中斷，則此選項非常有用。當您想要進一步控制受管節點重新啟動的時間時 (例如使用維護時段)，此選項也很有用。
如果您選擇 `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`
### 參數名稱：`PreInstallHookDocName`
**用量**：選用。
**預設**︰`AWS-Noop`。
提供給 `PreInstallHookDocName` 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供 AWS 受管文件的名稱，或已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。（對於從不同 與您共用的 SSM 文件 AWS 帳戶，您必須指定完整的資源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。)
您指定的 SSM 文件會在 `Install` 操作之前執行，並執行 SSM Agent 支援的任何動作，例如用於在受管節點上執行修補之前進行應用程式運作狀態檢查的 shell 指令碼。(如需動作清單，請參閱 [命令文件外掛程式參考](documents-command-ssm-plugin-reference.md))。預設 SSM 文件名稱為 `AWS-Noop`，它不會對受管節點執行任何操作。
如需建立自訂 SSM 文件的詳細資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。
### 參數名稱：`PostInstallHookDocName`
**用量**：選用。
**預設**︰`AWS-Noop`。
提供給 `PostInstallHookDocName` 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供 AWS 受管文件的名稱，或已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。（對於從不同 與您共用的 SSM 文件 AWS 帳戶，您必須指定完整的資源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。)
在 `Install with NoReboot` 操作之後執行您指定的 SSM 文件，還會執行 SSM Agent 支援的任何操作，例如重新開機前安裝第三方更新的 shell 指令碼。(如需動作清單，請參閱 [命令文件外掛程式參考](documents-command-ssm-plugin-reference.md))。預設 SSM 文件名稱為 `AWS-Noop`，它不會對受管節點執行任何操作。
如需建立自訂 SSM 文件的詳細資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。
### 參數名稱：`OnExitHookDocName`
**用量**：選用。
**預設**︰`AWS-Noop`。
提供給 `OnExitHookDocName` 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供 AWS 受管文件的名稱，或已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。(若是來自不同 AWS 帳戶且已與您共用的 SSM 文件，您必須指定完整資源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。)
您指定的 SSM 文件會在受管節點重新啟動操作之後執行，並執行 SSM Agent 支援的任何動作，例如用於在修補操作完成之後確認節點運作狀態的 shell 指令碼。(如需動作清單，請參閱 [命令文件外掛程式參考](documents-command-ssm-plugin-reference.md))。預設 SSM 文件名稱為 `AWS-Noop`，它不會對受管節點執行任何操作。
如需建立自訂 SSM 文件的詳細資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。
# 使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 中 InstallOverrideList 參數的範例案例
當您想要覆寫 Patch Manager ( AWS Systems Manager中的工具) 中目前預設修補基準指定的修補程式時，可以使用 `InstallOverrideList` 參數。本主題提供示範如何使用此參數來達成下列目標的範例：
+ 將不同的修補程式集套用至目標受管節點群組。
+ 依不同的頻率套用這些修補程式集。
+ 兩項操作都使用相同的修補基準。
假設您要在 Amazon Linux 2 受管節點上安裝兩種不同類別的修補程式。您想要使用維護時段，依不同的排程上安裝這些修補程式。您希望每週執行一個維護時段，並安裝所有 `Security` 修補程式。您希望另一個維護時段每月執行一次，並安裝所有可用的修補程式或 `Security` 以外的修補程式類別。
不過，一次只能將一個修補基準定義為作業系統的預設值。此要求有助於避免某個修補基準核准修補程式，而另一個修補程式封鎖該修補程式，這可能在衝突的版本之間導致問題。
下列策略可讓您使用 `InstallOverrideList` 參數，依不同的排程將不同類型的修補程式套用至目標群組，同時繼續使用相同的修補基準。
1. 在預設修補基準中，確定僅指定 `Security` 更新。
1. 建立維護時段，在每週執行 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation`。請勿指定覆寫清單。
1. 建立您要每月套用之所有修補程式類型的覆寫清單，並將其存放在 Amazon Simple Storage Service (Amazon S3) 儲存貯體中。
1. 建立第二個維護時段，在每月執行一次。不過，針對您為此維護時段註冊的 Run Command 任務，請指定覆寫清單的位置。
結果：每週只會安裝預設修補基準中定義的 `Security` 修補程式。每月都會安裝所有可用的修補程式，或您定義的任何修補程式子集。
**注意**
當您修補僅使用 IPv6 的節點時，請確定提供的 URL 可從節點連線。如果SSM Agent組態選項`UseDualStackEndpoint`設定為 `true`，則會在提供 S3 URL 時使用雙堆疊 S3 用戶端。[教學課程：修補僅限 IPv6 環境中的伺服器](patch-manager-server-patching-iPv6-tutorial.md) 如需將代理程式設定為使用 dualstack 的詳細資訊，請參閱 。
如需詳細資訊和範例清單，請參閱 [參數名稱：`InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)。
# 使用 BaselineOverride 參數
使用 Patch Manager ( AWS Systems Manager中的工具) 中的基準覆寫功能，您可以在執行時期定義修補偏好設定。透過指定 Amazon Simple Storage Service (Amazon S3) 儲存貯體完成此操作，其中包含具有修補基準清單的 JSON 物件。修補操作使用符合主機作業系統之 JSON 物件中所提供的基準，而不是從預設修補基準套用規則。
**重要**
`BaselineOverride` 檔案名稱不能包含下列字元：反引號 (`)、單引號 (')、雙引號 (") 和美元符號 (\$1)。
除非修補操作使用修補程式政策，否則使用 `BaselineOverride` 參數不會覆寫參數中所提供之基準的修補程式合規。輸出結果記錄在 Run Command ( AWS Systems Manager中的工具) 的 Stdout 日誌中。結果只會列印標示為 `NON_COMPLIANT` 的套件。這意味著該套件會標記為 `Missing`、`Failed`、`InstalledRejected` 或 `InstalledPendingReboot`。
然而，當修補程式操作使用修補程式政策時，系統會從關聯的 S3 儲存貯體傳遞覆寫參數，並更新受管節點的合規值。如需有關修補程式政策行為的詳細資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
**注意**
當您修補僅使用 IPv6 的節點時，請確定提供的 URL 可從節點連線。如果SSM Agent組態選項`UseDualStackEndpoint`設定為 `true`，則會在提供 S3 URL 時使用雙堆疊 S3 用戶端。[教學課程：修補僅限 IPv6 環境中的伺服器](patch-manager-server-patching-iPv6-tutorial.md) 如需將代理程式設定為使用 dualstack 的詳細資訊，請參閱 。
## 使用修補基準覆寫 Snapshot Id 或 Install Override List 參數
在兩種情況下，修補基準覆寫具有值得注意的行為。
**同時使用基準線覆寫和 Snapshot Id**
Snapshot Id 可確保特定修補命令中的所有受管節點都套用相同的項目。例如，如果您一次修補 1,000 個節點，則修補程式將會相同。
同時使用 Snapshot Id 和修補基準覆寫時，Snapshot Id 的優先順序高於修補基準覆寫。仍會使用基準線覆寫規則，但只會評估一次。在先前的範例中，1,000 個受管節點的修補程式仍會永遠相同。如果在修補操作中間，您將參考之 S3 儲存貯體中的 JSON 檔案變更為不同的內容，則套用的修補程式仍然相同。這是因為已提供 Snapshot Id。
**同時使用基準覆寫和 Install Override List**
您無法同時使用這兩個參數。如果提供這兩個參數，則修補文件就會失敗，而且不會在受管節點上執行任何掃描或安裝。
## 程式碼範例
下列 Python 程式碼範例顯示如何產生修補基準覆寫。
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
這會產生修補基準覆寫，如以下所示。
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# 修補基準
本節中的主題提供當您在受管節點上執行 `Scan` 或 `Install` 操作時，修補基準在 Patch Manager (AWS Systems Manager 中的工具) 中之運作方式的相關資訊。
**Topics**
+ [預先定義和自訂的修補基準](patch-manager-predefined-and-custom-patch-baselines.md)
+ [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)
+ [修補程式群組](patch-manager-patch-groups.md)
+ [在 Windows Server 上由 Microsoft 發行的修補應用程式](patch-manager-patching-windows-applications.md)
# 預先定義和自訂的修補基準
Patch Manager是 中的工具 AWS Systems Manager，可為 支援的每個作業系統提供預先定義的修補基準Patch Manager。您可以依照目前設定的方式使用這些基準 (您無法自訂)，也可以建立自己的自訂修補基準。自訂修補基準可讓您進一步控制為您的環境核准或拒絕哪些修補程式。此外，預先定義的基準會將 `Unspecified` 的合規層級指派給使用這些基準安裝的所有修補程式。針對要指派的合規值，您可以建立預先定義基準的複本，並指定要指派給修補程式的合規值。如需詳細資訊，請參閱[自訂基準](#patch-manager-baselines-custom)及[使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
**注意**
無論您使用哪種方法或組態類型進行修補操作，此主題中的資訊都適用：
在 Quick Setup 中設定的修補程式政策
在 Quick Setup 中設定的主機管理選項
用來執行修補程式 `Scan` 或 `Install` 任務的維護時段
隨需 **Patch now** (立即修補) 操作
**Topics**
+ [預先定義的基準](#patch-manager-baselines-pre-defined)
+ [自訂基準](#patch-manager-baselines-custom)
## 預先定義的基準
下表說明 Patch Manager 提供的預先定義修補基準。
如需有關 Patch Manager 支援各作業系統的哪些版本的詳細資訊，請參閱 [Patch Manager 先決條件](patch-manager-prerequisites.md)。
****
| 名稱 | 支援的作業系統 | 詳細資訊 |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准所有被歸類為「Bugfix」的修補程式。在發行後 7 日，修補程式將自動核准。¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。在發行後七日，修補程式將自動核准。同時在修補程式發布七天之後，核准被歸類「Bugfix」的所有修補程式。 |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | 在更新可用 7 天之後核准所有更新，包括非安全性更新。 |
| AWS-DebianDefaultPatchBaseline | Debian Server | 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。 |
| AWS-MacOSDefaultPatchBaseline | macOS | 核准所有被歸類為「安全」的作業系統修補程式。同時核准包含目前更新的所有套件。 |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | 核准所有被歸類為「安全性」以及嚴重性等級為「重要」或「中等」的作業系統修補程式。同時在修補程式發行 7 天之後，核准被歸類為 "Bugfix" 的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | 核准所有在被歸類為「安全性」以及嚴重性為「關鍵」或「重要」的作業系統修補程式。在發行或更新 7 天後，修補程式將自動核准。¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。 |
| AWS-DefaultPatchBaseline | Windows Server | 核准所有被歸類為「CriticalUpdates」或「SecurityUpdates」以及 MSRC 嚴重性為「關鍵」或「重要」的 Windows Server 作業系統修補程式。在發佈或更新 7 天後，修補程式將自動核准。² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | 核准所有被歸類為「CriticalUpdates」或「SecurityUpdates」以及 MSRC 嚴重性為「關鍵」或「重要」的 Windows Server 作業系統修補程式。在發佈或更新 7 天後，修補程式將自動核准。² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | 在修補程式發佈七天之後，核准所有被歸類為「CriticalUpdates」或「SecurityUpdates」以及 MSRC 嚴重性為「關鍵」或「重要」的 Windows Server 作業系統修補程式。對 Microsoft 發行的應用程式核准所有的修補程式。作業系統和應用程式的修補程式會在發佈或更新 7 天後自動核准。² |
¹ 對於 Amazon Linux 2，修補程式自動批准前的 7 天等待時間從 `updateinfo.xml` 中的 `Updated Date` 值開始計算，而不是從 `Release Date` 值計算。各種因素會影響 `Updated Date` 值。其他作業系統會以不同的方式處理發行和更新日期。如需詳細資訊來協助您避免因自動核准延遲而導致非預期結果，請參閱[套件發行日期和更新日期的計算方式](patch-manager-release-dates.md)。
² 對於 Windows Server，預設基準包括 7 天自動核准延遲。若要在發佈後 7 天內安裝修補程式，必須建立自訂基準。
## 自訂基準
使用下列資訊，協助您建立自訂修補基準，以符合您的修補目標。
**Topics**
+ [在自訂基準中使用自動核准](#baselines-auto-approvals)
+ [建立修補基準的其他資訊](#baseline-additional-info)
### 在自訂基準中使用自動核准
如果您建立自己的修補基準，您可以使用以下類別來選擇自動核准哪些修補程式。
+ **作業系統**：Windows Server 的支援版本、Amazon Linux、Ubuntu Server 等。
+ **產品名稱 **（適用於作業系統）：例如 RHEL 7.5、Amazon Linux 2023 2023.8.20250808、Windows Server2012、Windows Server2012 R2 等。
+ **產品名稱** (僅適用於在 Windows Server 由 Microsoft 發行的應用程式)：例如，Word 2016、BizTalk Server 等。
+ **分類**：例如，重要更新、安全性更新等。
+ **嚴重性**：例如關鍵、重要等。
對於您建立的每個核准規則，您可以選擇指定自動核准延遲，或指定修補程式核准截止日期。
**注意**
因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。
自動核准延遲是修補程式發行或最後更新之後，在自動核准修補程式進行修補之前的等待天數。例如，如果您使用 `CriticalUpdates` 分類來建立規則，並將自動核准延遲設定為 7 天，則 7 月 7 日發行的新的關鍵修補程式將在 7 月 14 日自動核准。
如果 Linux 儲存庫沒有提供套件發布日期資訊，Patch Manager 會將套件的建置時間用作 Amazon Linux 2、Amazon Linux 2023 和 Red Hat Enterprise Linux (RHEL) 的自動核准日期規格的日期。如果無法判斷套件的建置時間，Patch Manager 會使用 1970 年 1 月 1 日的預設日期。這會導致 Patch Manager 繞過修補基準中設定為核准 1970 年 1 月 1 日之後的任何日期的修補程式的任何自動核准日期規格。
當您指定自動核准截止日期時，Patch Manager 會自動套用在該日期當天或之前發行或最後更新的所有修補程式。例如，如果您指定 2023 年 7 月 7 日作為截止日期，則不會自動安裝在 2023 年 7 月 8 日或之後發行或最後更新的修補程式。
當您建立自訂修補基準時，您可以指定此修補基準所核准之修補程式的合規嚴重性等級，例如 `Critical` 或 `High`。如果任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
### 建立修補基準的其他資訊
建立修補基準時，請謹記下列事項：
+ Patch Manager 為每個支援的作業系統提供一個預設修補基準。除非您建立自己的修補基準，並將其指定為相應作業系統類型的預設基準，否則這些預先定義的修補基準會用於每種作業系統類型的預設修補基準。
**注意**
對於 Windows Server，則會提供三個預先定義的修補基準。修補基準 `AWS-DefaultPatchBaseline` 和 `AWS-WindowsPredefinedPatchBaseline-OS` 僅支援 Windows 作業系統本身的作業系統更新。`AWS-DefaultPatchBaseline` 會用作 Windows Server 受管節點的預設修補基準，除非您指定了不同的修補基準。這兩個修補基準中的組態設定是相同的。兩者中較新的 `AWS-WindowsPredefinedPatchBaseline-OS` 是為了區分它與 Windows Server 第三方預先定義修補基準而建立的。修補基準 `AWS-WindowsPredefinedPatchBaseline-OS-Applications` 可用來將修補程式套用至 Windows Server 作業系統和 Microsoft 發行的支援應用程式。
+ 依預設，Windows Server 2019 和 Windows Server 2022 會移除更新，而這些更新會由稍後的更新取代。因此，如果您在 Windows Server 修補基準中使用 `ApproveUntilDate` 參數，但 `ApproveUntilDate` 參數中選取的日期早於最新修補程式的日期，則修補操作執行時不會安裝新的修補程式。如需有關 Windows Server 修補規則的詳細資訊，請參閱 [如何選取安全性修補程式](patch-manager-selecting-patches.md) 中的 Windows Server 索引標籤。
這表示即使可能未安裝上個月的關鍵修補程式，受管節點在 Systems Manager 操作方面也符合規範。使用 `ApproveAfterDays` 參數時，可能會發生相同的情況。由於 Microsoft 取代了修補程式行為，可以設定數字 (通常大於 30 天)，這樣，若在 `ApproveAfterDays` 的天數之前發行 Microsoft 最新的可用修補程式，則永遠不會安裝 Windows Server 的修補程式。
+ 僅對於 Windows Server，未經修補基準核准的可用安全性更新修補程式可以具有 `Compliant` 或 `Non-Compliant` 的合規值，如自訂修補基準中所定義。
在建立或更新修補基準時，您可以選擇要指派給可用但未經核准的安全修補程式的狀態，因為這些修補程式不符合修補基準中指定的安裝條件。例如，如果您已指定在修補程式發布後、安裝前需要等待很長的時間，則可以略過您可能想要安裝的安全修補程式。如果在指定的等待期間發布了修補程式更新，安裝修補程式的等待期間會重新開始。如果等待期間過長，可以發布多個版本的修補程式，但絕不會安裝。
您可以使用主控台建立或更新修補基準，在**可用安全性更新合規狀態**欄位中指定此選項。使用 AWS CLI 執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)或 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)命令，您可以在 `available-security-updates-compliance-status` 參數中指定此選項。
+ 對於內部部署伺服器和虛擬機器 (VM)，Patch Manager 會嘗試使用您的自訂預設修補基準。如果不存在自訂預設修補基準，系統將使用為對應作業系統預先定義的修補基準。
+ 如果修補程式已在相同的修補基準中同時列為核准與拒絕，修補程式將遭到拒絕。
+ 一個受管節點只能有一個為其定義的修補基準。
+ 可新增至修補基準之核准與拒絕修補程式清單的套件名稱格式，取決於您要修補之作業系統的類型。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 如果您在 Quick Setup 中使用[修補程式政策組態](patch-manager-policies.md)，則您對自訂修補基準所做的更新會每小時與 Quick Setup 同步一次。
如果刪除修補程式政策中參照的自訂修補基準，則修補程式政策的 Quick Setup **Configuration details** (組態詳細資訊) 頁面上會顯示橫幅。此橫幅會通知您修補程式政策參照修補基準不再存在，而後續的修補操作將會失敗。在此情況下，請返回到 Quick Setup **Configurations** (組態) 頁面，選取 Patch Manager 組態，然後選擇 **Actions** (動作)、**Edit configuration** (編輯組態)。刪除的修補基準名稱會反白顯示，您必須為受影響的作業系統選取新的修補基準。
+ 您建立具有多個 `Classification` 和 `Severity` 值的核准規則時，系統會根據修補程式的可用屬性核准修補程式。具有 `Classification` 和 `Severity` 屬性的套件將符合兩個欄位的所選基準值。僅具有 `Classification` 屬性的套件只會與選取的基準 `Classification` 值進行比對。對於沒有 `Severity` 屬性的套件，會忽略相同規則中的嚴重性要求。
如需有關建立修補基準的詳細資訊，請參閱[使用自訂修補基準](patch-manager-manage-patch-baselines.md)與[教學課程：使用 修補伺服器環境 AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)。
# 已核准與遭拒的修補程式清單的套件名稱格式
可新增至核准與拒絕修補程式清單的套件名稱格式，取決於您要修補之作業系統的類型。
## 適用於 Linux 作業系統的套件名稱格式
您可為修補基準中的核准與拒絕修補程式指定的格式，依據 Linux 類型而有不同。具體來說，支援的格式取決於 Linux 作業系統類型所使用的套件管理工具。
**Topics**
+ [Amazon Linux 2、Amazon Linux 2023、Oracle Linux 和 Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server 和 Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2、Amazon Linux 2023、Oracle Linux 和 Red Hat Enterprise Linux (RHEL)
**套件管理工具**：YUM，Amazon Linux 2023 和 RHEL 8 除外，它使用 DNF 作為套件管理工具。
**核准的修補程式**：對於核准的修補程式，您可以指定以下任何項目：
+ Bugzilla ID，格式為 `1234567` (系統將僅有數字的字串處理為 Bugzilla ID。)
+ CVE ID，格式為 `CVE-2018-1234567`
+ 諮詢 ID，格式範例為 `RHSA-2017:0864` 及 `ALAS-2018-123`
+ 使用一個或多個可用於套件命名的元件建構的套件名稱。為了說明，對於名為 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` 的套件，元件如下所示：
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
支援具有下列結構的套件名稱：
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
一些範例：
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ 我們也支援使用上述格式之單一萬用字元的套件名稱元件，例如下列所示：
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**拒絕的修補程式**：對於拒絕的修補程式，您可以指定以下任何項目：
+ 使用一個或多個可用於套件命名的元件建構的套件名稱。為了說明，對於名為 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` 的套件，元件如下所示：
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
支援具有下列結構的套件名稱：
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
一些範例：
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ 我們也支援使用上述格式之單一萬用字元的套件名稱元件，例如下列所示：
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server 和 Ubuntu Server
**套件管理工具**：APT
**核准的修補程式**與**拒絕修補程式**：對於核准與拒絕的修補程式，請指定以下項目：
+ 套件名稱，格式為 `ExamplePkg33`
**注意**
對於 Debian Server 清單和 Ubuntu Server 清單，請勿包含諸如架構或版本之類的元素。例如，您指定套件名稱 `ExamplePkg33` 將下列所有項目包含在修補程式清單中：
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**套件管理工具**：Zypper
**核准的修補程式** 與 **拒絕修補程式**：對於核准與拒絕的修補程式清單，可指定以下任何項目：
+ 完整套件名稱，格式範例：
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ 套件名稱含一個萬用字元，例如：
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## macOS 的套件名稱格式
**支援的套件管理工具**：softwareupdate、installer、Brew、Brew Cask
**核准的修補程式** 與 **拒絕修補程式**：對於核准與拒絕的修補程式清單，您可以使用以下格式指定完整套件名稱：
+ `XProtectPlistConfigData`
+ `MRTConfigData`
macOS 的已核准和已拒絕修補程式清單不支援萬用字元。
## 適用於 Windows 作業系統的套件名稱格式
對於 Windows 作業系統，請使用修補程式的 Microsoft 知識庫 ID 和 Microsoft 資訊安全佈告欄 ID，例如：
```
KB2032276,KB2124261,MS10-048
```
# 修補程式群組
**注意**
修補程式群組不會用於基於*修補程式政策*的修補操作。如需有關使用修補程式政策的資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
對於在 2022 年 12 月 22 日發布修補程式政策支援之前尚未使用修補程式群組的帳戶區域對，主控台中不支援修補程式群組功能。對於在此日期之前開始使用修補程式群組的帳戶區域對，修補程式群組功能仍然可用。
您可以使用*修補程式群組*，將受管節點與 Patch Manager (AWS Systems Manager 中的工具) 中的特定修補基準關聯。修補程式群組會協助您根據相關的修補基準規則，確保您部署適當的修補程式至正確的節點。修補程式群組也能協助您避免在充分測試之前即部署修補程式。例如，您可以為不同的環境建立修補程式群組 (例如，開發、測試和生產) 並將每個修補程式群組註冊到適當的修補基準。
在您執行 `AWS-RunPatchBaseline` 或其他 SSM 命令文件進行修補時，可以使用其 ID 或標籤來鎖定受管節點。然後，SSM Agent 和 Patch Manager 會根據您新增至受管節點的修補程式群組值來評估要使用的修補基準。
## 使用標籤定義修補程式群組
您可以使用套用至[混合多雲端](operating-systems-and-machine-types.md#supported-machine-types)環境中的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體和非 EC2 節點的標籤來建立修補程式群組。請注意下列有關使用修補程式群組標籤的詳細資訊：
+
必須使用套用至受管節點的標籤鍵 `Patch Group` 或 `PatchGroup` 來定義修補程式群組。為修補基準註冊修補程式群組時，為這兩個鍵指定的任何相同*值*都會解譯為相同群組的一部分。例如，假設您已使用下列鍵值對中的第 1 個來標記 5 個節點，並使用當中的第 2 個來標記 5 個節點：
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
建立基準的 Patch Manager 命令會根據值 `DEV`，將這 10 個受管節點合併為單一群組。為修補程式群組建立修補基準的命令的 AWS CLI 等效命令如下：
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
將不同鍵的值合併為單一目標，是用於建立新修補程式群組的此 Patch Manager 命令的唯一功能，且不受其他 API 動作支援。例如，如果您使用具有相同值的 `PatchGroup` 和 `Patch Group` 鍵執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 動作，則您是鎖定了兩組完全不同的節點：
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ 以標籤為基礎的目標鎖定存在限制。`SendCommand` 的每個目標陣列最多可包含 5 個鍵值對。
+ 建議您僅選擇其中 1 個標籤鍵慣例，可以是 `PatchGroup` (不含空格) 或 `Patch Group` (含空格)。不過，如果您在執行個體上[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup`。
+ 該金鑰區分大小寫。您可以指定任何*值*來協助您識別並鎖定該群組中的資源，例如 "web servers" 或 "US-EAST-PROD"，但鍵必須是 `Patch Group` 或 `PatchGroup`。
在您建立修補程式群組並標記受管節點之後，您可以使用修補基準註冊修補程式群組。使用修補基準註冊修補程式群組，可確保修補程式群組中的節點使用相關修補基準中定義的規則。
有關如何建立修補程式群組，以及將修補程式群組與修補基準建立關聯的詳細資訊，請參閱 [建立和管理修補程式群組](patch-manager-tag-a-patch-group.md) 和 [Add a patch group to a patch baseline](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline)(新增修補程式群組至修補基準)。
若要檢視使用 AWS Command Line Interface (AWS CLI) 建立修補基準與修補程式群組的範例，請參閱 [教學課程：使用 修補伺服器環境 AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)。如需有關 Amazon EC2 標籤的詳細資訊，請參閱《Amazon EC2 使用者指南》[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)中的 *Tag your Amazon EC2 resources*。
## 運作方式
當系統執行將修補基準套用於受管節點的任務時，SSM Agent 會驗證是否為該節點定義了修補程式群組值。如果節點已指派給修補程式群組，則 Patch Manager 會驗證該群組註冊了哪一個修補基準。如果找到了該群組的修補基準，則 Patch Manager 會通知 SSM Agent 使用關聯的修補基準。如果節點未針對修補程式群組進行設定，則 Patch Manager 會自動通知 SSM Agent 已使用目前設定的預設修補基準。
**重要**
受管節點只能存在於一個修補程式群組中。
一個修補程式群組只能為每個作業系統類型註冊一個修補基準。
如果在執行個體上啟用 **Allow tags in instance metadata** (允許執行個體中繼資料中的標籤) 選項，則您不得將 `Patch Group` 標籤 (有空格) 套用至 Amazon EC2 執行個體。允許執行個體中繼資料中的標籤可防止標籤鍵名稱含空格。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用標籤索引鍵 `PatchGroup` (不留空格)。
**圖 1：修補操作處理流程一般範例**
下圖顯示 Systems Manager 將 Run Command 任務傳送到您的伺服器機群，以使用 Patch Manager 進行修補時執行程序的一般範例。這些程序會確定要在修補操作中使用的修補基準。(當維護時段設定為使用 Patch Manager 向修補程式傳送命令時，將使用類似的程序。)
完整程序見圖例下方的說明。
![\[Patch Manager 工作流程，用於確定在執行修補操作時要使用的修補基準。\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
在此範例中，我們有三個 Windows Server EC2 執行個體群組已套用以下標籤：
****
| EC2 執行個體群組 | Tags (標籤) |
| --- | --- |
| Group 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| Group 2 | `key=OS,value=Windows` |
| Group 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
在這個範例中，我們也有這兩個 Windows Server 修補基準：
****
| 修補基準 ID | 預設 | 關聯的修補程式群組 |
| --- | --- | --- |
| `pb-0123456789abcdef0` | 是 | `Default` |
| `pb-9876543210abcdef0` | 否 | `DEV` |
使用 Run Command (AWS Systems Manager 中的工具) 和 Patch Manager 掃描或安裝修補程式的一般程序如下所示：
1. **傳送命令至修補程式**：透過 Systems Manager 主控台、軟體開發套件、AWS Command Line Interface (AWS CLI)，或 AWS Tools for Windows PowerShell 以使用文件 `AWS-RunPatchBaseline` 傳送 Run Command 任務。該圖顯示了透過定位標籤 `key=OS,value=Windows` 來修補受管執行個體的 Run Command 任務。
1. **修補基準判定**：SSM Agent 會驗證套用於 EC2 執行個體的修補程式群組標籤，並查詢 Patch Manager 以取得對應的修補基準。
+ **符合與修補基準關聯的修補程式群組值：**
1. 安裝在群組 1 中的 EC2 執行個體上的 SSM Agent 會接收步驟 1 中發出的命令以開始修補操作。SSM Agent 會驗證 EC2 執行個體是否已套用修補程式群組標籤值 `DEV`，並向 Patch Manager 查詢關聯的修補基準。
1. Patch Manager 會確認修補基準 `pb-9876543210abcdef0` 已關聯修補程式群組 `DEV`，並通知 SSM Agent。
1. SSM Agent 會根據在 `pb-9876543210abcdef0` 中設定的核准規則和例外狀況從 Patch Manager 擷取修補基準快照，然後繼續執行下一步驟。
+ **無新增至執行個體的修補程式群組標籤：**
1. 安裝在群組 2 中 EC2 執行個體上的 SSM Agent 會接收步驟 1 中發出的命令，以開始修補操作。SSM Agent 會驗證 EC2 執行個體未套用的 `Patch Group` 或 `PatchGroup` 標籤，因此，SSM Agent 會查詢 Patch Manager 以取得預設 Windows 修補基準。
1. Patch Manager 會確認預設的 Windows Server 修補基準是 `pb-0123456789abcdef0` 並通知 SSM Agent。
1. SSM Agent 會根據在預設修補程式基線 `pb-0123456789abcdef0` 中設定的核准規則和例外狀況，從 Patch Manager 擷取修補程式基線快照，然後繼續執行下一步驟。
+ **沒有符合與修補基準關聯的修補程式群組值：**
1. 安裝在群組 3 中的 EC2 執行個體上的 SSM Agent 會接收步驟 1 中發出的命令以開始修補操作。SSM Agent 會驗證 EC2 執行個體是否已套用修補程式群組標籤值 `QA`，並向 Patch Manager 查詢關聯的修補基準。
1. Patch Manager 未找到與修補程式群組 `QA` 相關聯的修補基準。
1. Patch Manager 會通知 SSM Agent 以使用預設的 Windows 修補基準 `pb-0123456789abcdef0`。
1. SSM Agent 會根據在預設修補基準 `pb-0123456789abcdef0` 中設定的核准規則和例外狀況，從 Patch Manager 擷取修補基準快照，然後繼續執行下一步驟。
1. **修補程式掃描或安裝**：在決定欲使用的適當修補基準後，SSM Agent 會根據步驟 1 中指定的作業值開始掃描或安裝修補程式。掃描或安裝的修補程式，是由 Patch Manager 提供的修補基準快照中所定義的核准規則和修補程式的例外狀況所判斷。
**詳細資訊**
+ [修補程式合規狀態值](patch-manager-compliance-states.md)
# 在 Windows Server 上由 Microsoft 發行的修補應用程式
使用本主題中的資訊來協助您準備使用 Patch Manager ( AWS Systems Manager中的工具) 修補 Windows Server 上的應用程式。
**Microsoft 應用程式修補**
對 Windows Server 受管節點上應用程式的修補支援僅限於 Microsoft 發行的應用程式。
**注意**
在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發行修補程式。在這些情況下，預設會提供 `01/01/1970` 的更新日期和時間。
**修補由 Microsoft 發行之應用程式的修補基準**
對於 Windows Server，則會提供三個預先定義的修補基準。修補基準 `AWS-DefaultPatchBaseline` 和 `AWS-WindowsPredefinedPatchBaseline-OS` 僅支援 Windows 作業系統本身的作業系統更新。`AWS-DefaultPatchBaseline` 會用作 Windows Server 受管節點的預設修補基準，除非您指定了不同的修補基準。這兩個修補基準中的組態設定是相同的。兩者中較新的 `AWS-WindowsPredefinedPatchBaseline-OS` 是為了區分它與 Windows Server 第三方預先定義修補基準而建立的。修補基準 `AWS-WindowsPredefinedPatchBaseline-OS-Applications` 可用來將修補程式套用至 Windows Server 作業系統和 Microsoft 發行的支援應用程式。
您也可以建立自訂修補基準以在 Windows Server 電腦上更新 Microsoft 發行的應用程式。
**對於 Microsoft 在內部部署伺服器、邊緣裝置、VM 和其他非 EC2 節點上發行之應用程式的修補支援**
若要修補 Microsoft 在虛擬機器 (VM) 和其他非 EC2 受管節點上發行的應用程式，您必須開啟 advanced-instances 方案。使用 advanced-instance 方案會產生費用。**但是，修補由 Microsoft 在 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上發行的應用程式無須另外付費。**如需詳細資訊，請參閱[設定執行個體方案](fleet-manager-configure-instance-tiers.md)。
**「其他 Microsoft 產品」的 Windows 更新選項**
為了讓 Patch Manager 能夠在您的 Windows Server 受管節點上修補 Microsoft 發行的應用程式，必須在受管節點上啟用 Windows 更新選項 **Give me updates for other Microsoft products when I update Windows** (當我更新 Windows 時，為我提供其他 Microsoft 產品的更新)。
如需在單一受管節點上允許此選項的相關資訊，請參閱[使用 Microsoft Update 更新 Office](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) (位於 Microsoft Support 網站)。
針對執行 Windows Server 2016 及更新版本的受管節點機群，您可以使用群組政策物件 (GPO) 來開啟設定。在群組政策管理編輯器中，移至 **Computer Configuration** (電腦組態)、**Administrative Templates** (管理範本)、**Windows Components** (Windows 元件)、**Windows Updates** (Windows 更新)，然後選擇 **Install updates for other Microsoft products** (為其他 Microsoft 產品安裝更新)。我們還建議您使用其他參數來設定 GPO，以防止 Patch Manager 之外的計劃外自動更新和重新開機。如需詳細資訊，請參閱 Microsoft 技術文件網站上的[在非作用中目錄環境設定自動更新](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499)。
針對執行 Windows Server 2012 或 2012 R2 的受管節點機群，您可以使用指令碼來開啟選項，如 Microsoft Docs 部落格網站上的[透過指令碼啟用和停用 Windows 7 的 Microsoft 更新](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script)所述。例如，您可以執行下列操作：
1. 將部落格文章中的指令碼儲存在檔案中。
1. 將檔案上傳至 Amazon Simple Storage Service (Amazon S3) 儲存貯體或其他可存取的位置。
1. 使用 中的Run Command工具 AWS Systems Manager，透過類似以下的`AWS-RunPowerShellScript`命令，使用 Systems Manager 文件 (SSM 文件） 在受管節點上執行指令碼。
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**最低參數要求**
若要在自定修補基準中包含 Microsoft 發行的應用程式，您至少必須指定要修補的產品。following AWS Command Line Interface (AWS CLI) 命令示範修補產品的最低需求，例如 Microsoft Office 2016。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
如果您指定了 Microsoft 應用程式產品系列，則您指定的每個產品都必須是所選產品系列的受支援成員。例如，若要修補產品「Active Directory Rights Management Services Client 2.0」，您必須指定其產品系列為「Active Directory」而非「Office」或「SQL Server」。下列 AWS CLI 命令示範產品系列和產品的配對。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**注意**
如果您收到有關不相符產品與家庭配對的錯誤訊息，請參閱 [問題：產品系列/產品配對不相符](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)，以取得解決問題的協助。
# 在 Amazon Linux 2 受管節點上使用 Kernel Live Patching
適用於 Amazon Linux 2 的 Kernel Live Patching 可讓您將安全性漏洞和重大錯誤修補程式套用至執行中的 Linux 核心，而不需要重新啟動或中斷執行中的應用程式。這可讓您從改善的服務和應用程式可用性中受益，同時保持基礎設施的安全和最新狀態。在 Amazon EC2 執行個體、 AWS IoT Greengrass 核心裝置和執行 Amazon Linux 2 的[內部部署虛擬機器](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html)上支援 Kernel Live Patching。
如需有關 Kernel Live Patching 的一般資訊，請參閱 *Amazon Linux 2 User Guide* 中的 [Kernel Live Patching on AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)。
在 Amazon Linux 2 受管節點上開啟 Kernel Live Patching 後，您可以使用 Patch Manager ( AWS Systems Manager中的工具) 將核心即時修補程式套用至該受管節點。使用 Patch Manager 是在節點上使用現有 yum 工作流程來套用更新的替代方法。
**開始之前**
若要使用 Patch Manager 將核心即時修補程式套用至您的 Amazon Linux 2 受管節點，請確定您的節點是以正確的架構和核心版本為基礎。如需相關資訊，請參閱《Amazon EC2 使用者指南》**中的 [Supported configurations and prerequisites](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)。
**Topics**
+ [使用 Patch Manager 的 Kernel Live Patching](#about-klp)
+ [使用 Patch Manager 的 Kernel Live Patching 如何運作](#how-klp-works)
+ [使用 Run Command 開啟 Kernel Live Patching](enable-klp.md)
+ [使用 Run Command 套用核心即時修補程式](install-klp.md)
+ [使用 Run Command 關閉 Kernel Live Patching](disable-klp.md)
## 使用 Patch Manager 的 Kernel Live Patching
更新核心版本
套用核心即時修補程式更新後，您不需要重新啟動受管節點。不過， 會在 Amazon Linux 2 核心版本發行後最多三個月內 AWS 提供核心即時修補程式。在 3 個月期間過後，您必須更新至較新的核心版本，才能繼續接收核心即時修補程式。我們建議您使用維護時段，排程至少每三個月重新啟動節點一次，以提示核心版本更新。
解除安裝核心即時修補程式
無法使用 Patch Manager 解除安裝核心即時修補程式。您可以改為關閉 Kernel Live Patching，這會為已套用核心即時修補程式移除 RPM 套件。如需詳細資訊，請參閱[使用 Run Command 關閉 Kernel Live Patching](disable-klp.md)。
核心合規
在某些情況下，從目前核心版本的即時修補程式安裝所有 CVE 修正程式，可能會使該核心達到與較新核心版本相同的合規狀態。發生這種情況時，會將較新的版本報告為 `Installed`，並將受管節點報告為 `Compliant`。但是，對於較新的核心版本，不會報告任何安裝時間。
一個核心即時修補程式，多個 CVE
如果核心即時修補程式可處理多個 CVE，且這些 CVE 具有各種分類和嚴重性值，則只會報告 CVE 中最高的分類和嚴重性。
本節的其餘部分說明如何使用 Patch Manager，將核心即時修補程式套用至符合這些需求的受管節點。
## 使用 Patch Manager 的 Kernel Live Patching 如何運作
AWS 為 Amazon Linux 2 發行兩種類型的核心即時修補程式：安全性更新和錯誤修正。若要套用這些類型的修補程式，您可以使用修補基準文件，僅針對下表所列分類與嚴重性。
| 分類 | 嚴重性 |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
您可以建立自訂修補基準，僅針對這些修補程式，或使用預先定義的 `AWS-AmazonLinux2DefaultPatchBaseline` 修補基準。換句話說，您可以使用 `AWS-AmazonLinux2DefaultPatchBaseline` 搭配啟用 Kernel Live Patching 的 Amazon Linux 2 受管節點，如此將套用核心即時更新。
**注意**
`AWS-AmazonLinux2DefaultPatchBaseline` 組態會指定在自動安裝修補程式之前、發行或最後更新修補程式之後的 7 天等待期。如果不想等待七天，讓核心即時修補程式自動核准，則您可以建立並使用自訂修補基準。在修補基準中，您可以指定非自動核准等待期間，或指定較短或較長的等待期間。如需詳細資訊，請參閱[使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
我們建議您採用下列策略，以核心即時更新修補您的受管節點：
1. 在您的 Amazon Linux 2 受管節點上開啟 Kernel Live Patching。
1. 使用 中的Run Command工具 AWS Systems Manager，使用預先定義`AWS-AmazonLinux2DefaultPatchBaseline`或自訂修補程式基準在您的受管節點上執行`Scan`操作，該基準也僅以嚴重性分類為 `Critical`和 `Important`，以及`Bugfix`嚴重性為 的`Security`更新為目標`All`。
1. 使用 中的工具 Compliance AWS Systems Manager來檢閱是否報告任何已掃描受管節點的修補不合規。若是如此，請檢視節點合規詳細資訊，以判斷受管節點是否遺漏任何核心即時修補程式。
1. 若要安裝遺漏的核心即時修補程式，請使用 Run Command 搭配您之前指定的相同修補基準，但這次請執行 `Install` 操作而非 `Scan` 操作。
由於安裝核心即時修補程式並不需要重新開機，因此您可以為此操作選擇 `NoReboot` 重新開機選項。
**注意**
如果安裝在受管節點上的其他類型修補程式有需要重新啟動，或者您想要更新至較新的核心，仍然可以重新啟動受管節點。在這些情況下，請改選 `RebootIfNeeded` 重新開機選項。
1. 返回 合規以確認已安裝核心即時修補程式。
# 使用 Run Command 開啟 Kernel Live Patching
若要開啟 Kernel Live Patching，您可以在受管節點上執行 `yum` 命令，或使用 Run Command 和您建立的自訂 Systems Manager 文件 (SSM 文件)。
如需有關透過直接在受管節點上執行 `yum` 命令來關閉 Kernel Live Patching 的資訊，請參閱《Amazon EC2 使用者指南》**中的[啟用 Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)。
**注意**
當您開啟「核心即時修補」時，如果受管節點上已經執行的核心*早於* `kernel-4.14.165-131.185.amzn2.x86_64` (最低支援的版本)，則程序會安裝最新的可用核心版本並重新啟動受管節點。如果節點已在執行 `kernel-4.14.165-131.185.amzn2.x86_64` 或更新版本，則程序不會安裝較新的版本，也不會重新啟動節點。
**使用 Run Command 開啟 Kernel Live Patching (主控台)**
1. 開啟位於 AWS Systems Managerhttps://console.aws.amazon.com/systems-manager/ 的主控台。[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. 在導覽窗格中，選擇 **Run Command**。
1. 選擇**執行命令**。
1. 在 **Command document** (命令文件) 清單中，選擇 SSM 文件 `AWS-ConfigureKernelLivePatching`。
1. 在 **Command parameters (命令參數)** 區段中，指定是否要在此操作中重新啟動受管節點。
1. 如需使用此頁面上其餘控制項的詳細資訊，請參閱[從主控台執行命令](running-commands-console.md)。
1. 選擇**執行**。
**開啟 Kernel Live Patching (AWS CLI)**
+ 在本機機器上執行以下命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
將 i*instance-id* 取代為您要啟用該功能的 Amazon Linux 2 受管節點 ID，例如 i-02573cafcfEXAMPLE。若要在多個受管節點上開啟此功能，您可以使用下列其中一種格式。
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
如需可以在命令中使用之其他選項的相關資訊，請參閱《AWS CLI 命令參考》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 一節。
# 使用 Run Command 套用核心即時修補程式
若要套用核心即時修補程式，您可以在受管節點上執行 `yum` 命令，或使用 Run Command 和 SSM 文件 `AWS-RunPatchBaseline`。
如需有關透過直接在受管節點上執行 `yum` 命令來套用核心即時修補程式的資訊，請參閱《Amazon EC2 使用者指南》**中的[套用核心即時修補程式](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply)。
**使用 Run Command 套用核心即時修補程式 (主控台)**
1. 開啟位於 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 的 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Run Command**。
1. 選擇**執行命令**。
1. 在 **Command document** (命令文件) 清單中，選擇 SSM 文件 `AWS-RunPatchBaseline`。
1. 在 **Command parameters (命令參數)** 區段中，執行以下其中一項：
+ 如果您要檢查是否有新的核心即時修補程式，請在 **Operaions** (操作) 中選擇 `Scan`。對於 **Reboot Option** (重新開機選項)，如果不希望受管節點在此操作之後重新啟動，請選擇 `NoReboot`。操作完成後，您可以在「合規」中檢查新的修補程式和合規狀態。
+ 如果您已檢查修補程式合規性，並準備好套用可用的核心即時修補程式，請在 **Operation (操作)** 中選擇 `Install`。對於 **Reboot Option** (重新開機選項)，如果不希望受管節點在此操作之後重新啟動，請選擇 `NoReboot`。
1. 如需使用此頁面上其餘控制項的詳細資訊，請參閱[從主控台執行命令](running-commands-console.md)。
1. 選擇**執行**。
**使用 Run Command 套用核心即時修補程式 (AWS CLI)**
1. 若要檢查合規中的結果之前執行 `Scan` 操作，請從本機電腦執行下列命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
如需可以在命令中使用之其他選項的相關資訊，請參閱《AWS CLI 命令參考》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 一節。
1. 若要檢查 合規中的結果之後執行 `Install` 操作，請從本機電腦執行下列命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
在上述兩個命令中，將 *instance-id* 取代為您要套用核心即時修補程式的 Amazon Linux 2 受管節點 ID，例如 i-02573cafcfEXAMPLE。若要在多個受管節點上開啟此功能，您可以使用下列其中一種格式。
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
如需可以在命令中使用之其他選項的相關資訊，請參閱《AWS CLI 命令參考》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 一節。
# 使用 Run Command 關閉 Kernel Live Patching
若要關閉 Kernel Live Patching，您可以在受管節點上執行 `yum` 命令，或使用 Run Command 和自訂 SSM 文件 `AWS-ConfigureKernelLivePatching`。
**注意**
如果您不再需要使用 Kernel Live Patching，您可以隨時停用它。在大多數情況下，不需要關閉功能。
如需有關透過直接在受管節點上執行 `yum` 命令來關閉 Kernel Live Patching 的資訊，請參閱《Amazon EC2 使用者指南》**中的[啟用 Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable)。
**注意**
當您關閉 Kernel Live Patching 時，程序會解除安裝 Kernel Live Patching 外掛程式，然後重新啟動受管節點。
**使用 Run Command 關閉 Kernel Live Patching (主控台)**
1. 開啟位於 AWS Systems Managerhttps://console.aws.amazon.com/systems-manager/ 的主控台。[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. 在導覽窗格中，選擇 **Run Command**。
1. 選擇**執行命令**。
1. 在 **Command document** (命令文件) 清單中，選擇 SSM 文件 `AWS-ConfigureKernelLivePatching`。
1. 在 **Command parameters (命令參數)** 區段，指定所需的參數值。
1. 如需使用此頁面上其餘控制項的詳細資訊，請參閱[從主控台執行命令](running-commands-console.md)。
1. 選擇**執行**。
**關閉 Kernel Live Patching (AWS CLI)**
+ 使用類似以下的命令：
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
將 i*instance-id* 取代為您要啟用該功能的 Amazon Linux 2 受管節點 ID，例如 i-02573cafcfEXAMPLE。若要在多個受管節點上關閉此功能，您可以使用下列其中一種格式。
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
如需可以在命令中使用之其他選項的相關資訊，請參閱《AWS CLI 命令參考》**中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 一節。
# 透過主控台使用 Patch Manager 資源與合規
若要使用 中的Patch Manager工具 AWS Systems Manager，請完成下列任務。本節將詳細說明這些任務。
1. 確認您使用的每個作業系統類型的 AWS 預先定義修補程式基準符合您的需求。如果沒有，請建立一個修補基準，為該受管節點類型定義一組標準修補程式，並將其設定為預設值。
1. 使用 Amazon Elastic Compute Cloud (Amazon EC2) 標籤，將受管節點組織到修補程式群組中 (選用，但建議使用)。
1. 執行以下任意一項：
+ (建議使用) 在 Quick Setup (Systems Manager 中的工具) 中設定修補程式政策，可讓您針對整個組織、組織單位的子集或單一 AWS 帳戶的排程來安裝遺失的修補程式。如需詳細資訊，請參閱[使用 Quick Setup 修補程式政策設定組織中執行個體的修補](quick-setup-patch-manager.md)。
+ 在 Run Command 任務類型中建立使用 Systems Manager 文件 (SSM 文件) `AWS-RunPatchBaseline` 的維護時段。如需詳細資訊，請參閱[教學課程：使用主控台建立修補維護時段](maintenance-window-tutorial-patching.md)。
+ 手動執行 Run Command 操作中的 `AWS-RunPatchBaseline`。如需詳細資訊，請參閱[從主控台執行命令](running-commands-console.md)。
+ 使用 **Patch now** (立即修補) 功能，依需求手動修補節點。如需詳細資訊，請參閱[隨需修補受管節點](patch-manager-patch-now-on-demand.md)。
1. 監控修補以確認合規並調查失敗。
**Topics**
+ [建立修補程式政策](patch-manager-create-a-patch-policy.md)
+ [檢視修補程式儀表板摘要](patch-manager-view-dashboard-summaries.md)
+ [使用修補程式合規報告](patch-manager-compliance-reports.md)
+ [隨需修補受管節點](patch-manager-patch-now-on-demand.md)
+ [使用修補基準](patch-manager-create-a-patch-baseline.md)
+ [檢視可用修補程式](patch-manager-view-available-patches.md)
+ [建立和管理修補程式群組](patch-manager-tag-a-patch-group.md)
+ [Patch Manager 與 整合 AWS Security Hub CSPM](patch-manager-security-hub-integration.md)
# 建立修補程式政策
修補程式政策是您使用 Quick Setup ( AWS Systems Manager中的工具) 設定的組態。與其他設定修補的方法相比，修補程式政策可提供更廣泛且更集中的修補操作控制。修補程式政策會定義自動修補節點和應用程式時要使用的排程和基準。
如需詳細資訊，請參閱下列主題：
+ [Quick Setup中的修補程式政策組態](patch-manager-policies.md)
+ [使用 Quick Setup 修補程式政策設定組織中執行個體的修補](quick-setup-patch-manager.md)
# 檢視修補程式儀表板摘要
Patch Manager 中的**儀表板**索引標籤會在主控台中提供摘要檢視，您可以在合併檢視中監控修補操作。Patch Manager 是 AWS Systems Manager中的工具。您可以在 **Dashboard** (儀表板) 索引標籤上檢視下列內容：
+ 有多少受管節點符合和不符合修補規則的快照。
+ 受管節點之修補程式合規結果存留期的快照。
+ 每個最常見的不合規原因中有多少個不合規受管節點的連結計數。
+ 最近修補操作的連結清單。
+ 已設定之週期性修補任務的連結清單。
**檢視修補程式儀表板摘要**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Dashboard** (儀表板) 標籤。
1. 捲動至包含您要檢視之摘要資料的區段：
+ **Amazon EC2 instance management** (Amazon EC2 執行個體管理)
+ **Compliance summary** (合規摘要)
+ **Noncompliance counts** (不合規計數)
+ **Compliance reports** (合規報告)
+ **Non-patch policy-based operations** (非修補程式政策型操作)
+ **Non-patch policy-based recurring tasks** (非修補程式政策型週期性任務)
# 使用修補程式合規報告
使用下列主題中的資訊，協助您在 Patch Manager ( AWS Systems Manager中的工具) 中產生和使用修補程式合規報告。
無論您使用哪種方法或組態類型進行修補操作，下列主題中的資訊都適用：
+ 在 Quick Setup 中設定的修補程式政策
+ 在 Quick Setup 中設定的主機管理選項
+ 用來執行修補程式 `Scan` 或 `Install` 任務的維護時段
+ 隨需 **Patch now** (立即修補) 操作
**重要**
修補程式合規報告是僅由成功修補操作產生的point-in-time快照。每個報告都包含一個擷取時間，可識別何時計算合規狀態。
如果您有多種類型的操作來掃描執行個體以檢查修補程式合規性，則請注意每次掃描都會覆寫先前掃描的修補程式合規資料。因此，最終可能會在修補程式合規資料中產生非預期的結果。如需詳細資訊，請參閱[識別建立修補程式合規資料的執行](patch-manager-compliance-data-overwrites.md)。
若要驗證使用哪個修補基準來產生最新的合規資訊，請導覽至 Patch Manager 中的**合規報告**索引標籤，找到您想要其相關資訊的受管節點的資料列，然後在**使用的基準 ID** 資料欄中選擇基準 ID。
**Topics**
+ [檢視修補程式合規結果](patch-manager-view-compliance-results.md)
+ [產生 .csv 修補程式合規報告](patch-manager-store-compliance-results-in-s3.md)
+ [使用 Patch Manager 修復不符合標準的受管節點](patch-manager-noncompliant-nodes.md)
+ [識別建立修補程式合規資料的執行](patch-manager-compliance-data-overwrites.md)
# 檢視修補程式合規結果
使用這些處理程序來檢視有關受管節點的修補程式合規資訊
此處理程序適用於使用 `AWS-RunPatchBaseline` 文件的修補程式操作。如需檢視使用 `AWS-RunPatchBaselineAssociation` 文件之修補程式操作的修補程式合規資訊，請參閱 [識別不合規的受管節點](patch-manager-find-noncompliant-nodes.md)。
**注意**
Quick Setup 和 的修補程式掃描操作Explorer使用 `AWS-RunPatchBaselineAssociation` 文件。 Quick Setup和 Explorer 都是其中的工具 AWS Systems Manager。
**識別特定 CVE 問題的修補程式解決方案 (Linux)**
對於許多 Linux 作業系統，修補程式合規結果會指出哪些常見弱點和暴露 (CVE) 重要問題可以透過哪些修補程式來解決。此資訊可協助您判斷安裝遺漏或失效修補程式的迫切性。
下列作業系統類型的支援版本包含 CVE 詳細資訊：
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**注意**
依預設，CentOS Stream 不會提供有關更新的 CVE 資訊。但是，您可以使用第三方儲存庫，例如 Fedora 發行的 Extra Packages for Enterprise Linux (EPEL) 儲存庫，以允許這項支援。如需相關資訊，請參閱 Fedora Wiki 上的 [EPEL](https://fedoraproject.org/wiki/EPEL)。
目前，僅針對狀態為 `Missing` 或 `Failed` 的修補程式報告 CVE ID 值。
您也可以將 CVE ID 新增至修補基準中已核准或已拒絕的修補程式清單，視情形和您的修補目標而定。
如需使用已核准和已拒絕修補程式清單的相關資訊，請參閱下列主題：
+ [使用自訂修補基準](patch-manager-manage-patch-baselines.md)
+ [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)
+ [修補基準規則在 Linux 系統上的運作方式](patch-manager-linux-rules.md)
+ [如何安裝修補程式](patch-manager-installing-patches.md)
**注意**
在某些情況下，Microsoft 會針對未指定更新日期和時間的應用程式發行修補程式。在這些情況下，預設會提供 `01/01/1970` 的更新日期和時間。
## 檢視修補程式合規結果
使用以下程序在 AWS Systems Manager 主控台中檢視修補合規資料。
**注意**
如需產生已下載至 Amazon Simple Storage Service (Amazon S3) 儲存貯體之修補程式合規報告的相關資訊，請參閱 [產生 .csv 修補程式合規報告](patch-manager-store-compliance-results-in-s3.md)。
**檢視修補程式合規結果**
1. 執行下列其中一項操作。
**選項 1** (建議) – 從 Patch Manager ( AWS Systems Manager中的工具) 導覽：
+ 在導覽窗格中，選擇 **Patch Manager**。
+ 選擇 **Compliance reporting** (合規報告) 索引標籤。
+ 在**節點修補詳細資訊**中，請選擇要檢閱修補程式合規結果之受管節點的節點 ID。目前`stopped`或`terminated`不會在此顯示節點。
+ 在**詳細資訊**區域的**屬性**清單中選擇**修補程式**。
**選項 2** – 從合規 ( AWS Systems Manager中的工具) 導覽：
+ 在導覽窗格中，選擇 **Compliance** (合規)。
+ 對於 **Compliance resources summary** (合規資源摘要)，請在您要檢閱的修補程式資源類型欄中選擇一個數字，例如 **Non-Compliant resources** (不合規資源)。
+ 在下方的**資源**清單中，請選擇要檢閱修補程式合規結果的受管節點 ID。
+ 在**詳細資訊**區域的**屬性**清單中選擇**修補程式**。
**選項 3** – 從 Fleet Manager ( AWS Systems Manager中的工具) 導覽。
+ 在導覽窗格中，選擇 **Fleet Manager**。
+ 在**受管執行個體**區域中，請選擇要檢閱修補程式合規結果的受管節點 ID。
+ 在**詳細資訊**區域的**屬性**清單中選擇**修補程式**。
1. (選用) 在搜尋方塊 (![\[The Search icon\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/images/search-icon.png)) 中，請選擇可用的篩選條件。
例如，對於 Red Hat Enterprise Linux (RHEL)，請從下列選項中選擇：
+ 名稱
+ 分類
+ State
+ 嚴重性
針對 Windows Server，請選擇下列項目：
+ KB
+ 分類
+ State
+ 嚴重性
1. 為您選擇的篩選條件類型選擇其中一個可用的值。例如，如果您選擇了 **State** (狀態)，則現在選擇合規狀態，例如 **InstalledPendingReboot**、**Failed** 或 **Missing**。
**注意**
目前，僅針對狀態為 `Missing` 或 `Failed` 的修補程式報告 CVE ID 值。
1. 根據受管節點的合規狀態，您可以選擇要採取的動作來修復任何不合規節點。
例如，您可以選擇立即修補不合規受管節點。如需隨需修補受管節點的詳細資訊，請參閱 [隨需修補受管節點](patch-manager-patch-now-on-demand.md)。
如需有關修補程式合規資料的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。
# 產生 .csv 修補程式合規報告
您可以使用 AWS Systems Manager 主控台產生修補程式合規報告，這些報告會儲存為您選擇的 Amazon Simple Storage Service (Amazon S3) 儲存貯體的 .csv 檔案。您可以產生單一隨需報告，或指定自動產生報告的排程。
您可以為單一受管節點或所選 AWS 帳戶 和 中的所有受管節點產生報告 AWS 區域。對於單一節點，報告包含完整的詳細資訊，包括與不合規節點相關的修補程式 ID。針對所有受管節點的報告，只會提供摘要資訊和不合規節點的修補程式計數。
產生報告後，您可以使用 Amazon Quick 之類的工具來匯入和分析資料。Quick 是一種商業智慧 (BI) 服務，可用來探索和解譯互動式視覺化環境中的資訊。如需詳細資訊，請參閱 [Amazon Quick 使用者指南](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html)。
**注意**
當您建立自訂修補基準時，您可以指定此修補基準所核准之修補程式的合規嚴重性等級，例如 `Critical` 或 `High`。如果任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
您也可以指定 Amazon Simple Notification Service (Amazon SNS) 主題，在產生報告時傳送通知。
**產生修補程式合規報告的服務角色**
第一次產生報告時，Systems Manager 會建立名為 `AWS-SystemsManager-PatchSummaryExportRole` 的 Automation 擔任角色以用於匯出至 S3 的程序。
**注意**
如果您要將合規資料匯出至加密的 S3 儲存貯體，您必須更新其相關聯的 AWS KMS 金鑰政策，以提供 所需的許可`AWS-SystemsManager-PatchSummaryExportRole`。例如，新增類似於 S3 儲存貯體 AWS KMS 政策的許可：
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
將 *role-arn* 替換為您帳戶中建立的資源的 Amazon Resource Name (ARN)，並遵循格式 `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`。
如需詳細資訊，請參閱*《AWS Key Management Service 開發人員指南》*中的[在 AWS KMS中使用金鑰政策](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)。
當您第一次依排程產生報告時，Systems Manager 會建立另一個名為 `AWS-EventBridge-Start-SSMAutomationRole` 的服務角色，以及 `AWS-SystemsManager-PatchSummaryExportRole` 服務角色 (如果尚未建立) 以用於匯出程序。`AWS-EventBridge-Start-SSMAutomationRole` 可讓 Amazon EventBridge 使用 Runbook [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) 啟動自動化。
建議您不要嘗試修改這些政策和角色。這樣做可能會導致修補程式合規報告產生失敗。如需詳細資訊，請參閱[對修補程式合規報告產生進行故障診斷](#patch-compliance-reports-troubleshooting)。
**Topics**
+ [產生的修補程式合規報告中有哪些內容？](#patch-compliance-reports-to-s3-examples)
+ [為單一受管節點產生修補程式合規報告](#patch-compliance-reports-to-s3-one-instance)
+ [為所有受管節點產生修補程式合規報告](#patch-compliance-reports-to-s3-all-instances)
+ [檢視修補程式合規報告歷史](#patch-compliance-reporting-history)
+ [檢視修補程式合規報告排程](#patch-compliance-reporting-schedules)
+ [對修補程式合規報告產生進行故障診斷](#patch-compliance-reports-troubleshooting)
## 產生的修補程式合規報告中有哪些內容？
本主題提供產生並下載至指定 S3 儲存貯體之修補程式合規報告中所包含之內容類型的相關資訊。
### 單一受管節點的報告格式
針對單一受管節點產生的報告會提供摘要和詳細資訊。
[下載範例報告 (單一節點)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
單一受管節點的摘要資訊包括下列各項：
+ 索引
+ 執行個體 ID
+ 執行個體名稱
+ 執行個體 IP
+ 平台名稱
+ 平台版本
+ SSM Agent 版本
+ 修補基準
+ 修補程式群組
+ 合規狀態
+ 合規嚴重性
+ 不合規關鍵嚴重性修補程式計數
+ 不合規高嚴重性修補程式計數
+ 不合規中嚴重性修補程式計數
+ 不合規低嚴重性修補程式計數
+ 不合規資訊嚴重性修補程式計數
+ 不合規未指定嚴重性修補程式計數
單一受管節點的詳細資訊包括下列各項：
+ 索引
+ 執行個體 ID
+ 執行個體名稱
+ 修補程式名稱
+ KB ID /修補程式 ID
+ 修補程式狀態
+ 上次報告時間
+ 合規層級
+ 修補程式嚴重性
+ 修補程式分類
+ CVE ID
+ 修補基準
+ 日誌 URL
+ 執行個體 IP
+ 平台名稱
+ 平台版本
+ SSM Agent 版本
**注意**
當您建立自訂修補基準時，您可以指定此修補基準所核准之修補程式的合規嚴重性等級，例如 `Critical` 或 `High`。如果任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
### 所有受管節點的報告格式
針對所有受管節點產生的報告僅提供摘要資訊。
[下載範例報告 (所有受管節點)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
所有受管節點的摘要資訊包括下列各項：
+ 索引
+ 執行個體 ID
+ 執行個體名稱
+ 執行個體 IP
+ 平台名稱
+ 平台版本
+ SSM Agent 版本
+ 修補基準
+ 修補程式群組
+ 合規狀態
+ 合規嚴重性
+ 不合規關鍵嚴重性修補程式計數
+ 不合規高嚴重性修補程式計數
+ 不合規中嚴重性修補程式計數
+ 不合規低嚴重性修補程式計數
+ 不合規資訊嚴重性修補程式計數
+ 不合規未指定嚴重性修補程式計數
## 為單一受管節點產生修補程式合規報告
請使用下列處理程序來產生 AWS 帳戶中單一受管節點的修補程式摘要報告。單一受管節點的報告提供有關每個不合規之修補程式的詳細資訊，包括修補程式名稱和 ID。
**為單一受管節點產生修補程式合規報告**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Compliance reporting** (合規報告) 索引標籤。
1. 選擇您要產生報告之受管節點資料列的按鈕，然後選擇 **View detail** (檢視詳細資訊)。
1. 在 **Patch summary** (修補程式摘要) 區段中，選擇 **Export to S3** (匯出至 S3)。
1. 對於 **Report name** (報告名稱)，輸入一個名稱以協助您稍後識別報告。
1. 對於 **Reporting frequency** (報告頻率)，選擇下列其中一項：
+ **On demand** (隨需) – 建立一次性報告。跳至步驟 9。
+ **On a schedule** (排程) – 指定自動產生報告的週期性排程。繼續步驟 8。
1. 對於 **Schedule type** (排程類型)，請指定 Rate 表達式 (例如每 3 天)，或提供 Cron 表達式來設定報告頻率。
如需 cron 表達式的相關資訊，請參閱 [參考：Systems Manager 的 Cron 和 Rate 運算式](reference-cron-and-rate-expressions.md)。
1. 對於 **Bucket name** (儲存貯體名稱)，請選擇您要存放 .csv 報告檔案的 S3 儲存貯體名稱。
**重要**
如果您在 2019 年 3 月 20 日之後 AWS 區域 啟動的 中工作，則必須選取相同區域中的 S3 儲存貯體。依預設，在該日期之後啟動的區域會處於關閉狀態。如需詳細資訊和這些區域的清單，請參閱《Amazon Web Services 一般參考》**中的[啟用區域](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)一節。
1. (選用) 若要在報告產生時傳送通知，請展開 **SNS topic** (SNS 主題) 區段，然後從 **SNS topic Amazon Resource Name (ARN)** (SNS 主題 Amazon Resource Name (ARN)) 中選擇現有的 Amazon SNS 主題。
1. 選擇**提交**。
如需檢視產生報告之歷史記錄的相關資訊，請參閱 [檢視修補程式合規報告歷史](#patch-compliance-reporting-history)。
如需檢視已建立之報告排程詳細資訊的相關資訊，請參閱 [檢視修補程式合規報告排程](#patch-compliance-reporting-schedules)。
## 為所有受管節點產生修補程式合規報告
請使用下列處理程序來產生 AWS 帳戶中所有受管節點的修補程式摘要報告。所有受管節點的報告會指出哪些節點不合規，以及不合規修補程式的數目。它不會提供修補程式的名稱或其他識別符。如需這些其他詳細資訊，您可以為單一受管節點產生修補程式合規報告。如需相關資訊，請參閱本主題中稍早的 [為單一受管節點產生修補程式合規報告](#patch-compliance-reports-to-s3-one-instance)。
**為所有受管節點產生修補程式合規報告**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Compliance reporting** (合規報告) 索引標籤。
1. 選擇 **Export to S3** (匯出至 S3)。(請勿先選取節點 ID。)
1. 對於 **Report name** (報告名稱)，輸入一個名稱以協助您稍後識別報告。
1. 對於 **Reporting frequency** (報告頻率)，選擇下列其中一項：
+ **On demand** (隨需) – 建立一次性報告。跳至步驟 8。
+ **On a schedule** (排程) – 指定自動產生報告的週期性排程。繼續步驟 7。
1. 對於 **Schedule type** (排程類型)，請指定 Rate 表達式 (例如每 3 天)，或提供 Cron 表達式來設定報告頻率。
如需 cron 表達式的相關資訊，請參閱 [參考：Systems Manager 的 Cron 和 Rate 運算式](reference-cron-and-rate-expressions.md)。
1. 對於 **Bucket name** (儲存貯體名稱)，請選擇您要存放 .csv 報告檔案的 S3 儲存貯體名稱。
**重要**
如果您在 2019 年 3 月 20 日之後 AWS 區域 啟動的 中工作，則必須選取相同區域中的 S3 儲存貯體。依預設，在該日期之後啟動的區域會處於關閉狀態。如需詳細資訊和這些區域的清單，請參閱《Amazon Web Services 一般參考》**中的[啟用區域](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)一節。
1. (選用) 若要在報告產生時傳送通知，請展開 **SNS topic** (SNS 主題) 區段，然後從 **SNS topic Amazon Resource Name (ARN)** (SNS 主題 Amazon Resource Name (ARN)) 中選擇現有的 Amazon SNS 主題。
1. 選擇**提交**。
如需檢視產生報告之歷史記錄的相關資訊，請參閱 [檢視修補程式合規報告歷史](#patch-compliance-reporting-history)。
如需檢視已建立之報告排程詳細資訊的相關資訊，請參閱 [檢視修補程式合規報告排程](#patch-compliance-reporting-schedules)。
## 檢視修補程式合規報告歷史
使用本主題中的資訊，協助您檢視 中產生之修補程式合規報告的詳細資訊 AWS 帳戶。
**檢視修補程式合規報告歷史**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Compliance reporting** (合規報告) 索引標籤。
1. 選擇 **View all S3 exports** (檢視所有 S3 匯出)，然後選擇 **Export history** (匯出歷史記錄) 索引標籤。
## 檢視修補程式合規報告排程
使用本主題中的資訊來協助您檢視在 中建立的修補程式合規報告排程的詳細資訊 AWS 帳戶。
**檢視修補程式合規報告歷史**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Compliance reporting** (合規報告) 索引標籤。
1. 選擇 **View all S3 exports** (檢視所有 S3 匯出)，然後選擇 **Report schedule rules** (報告排程規則) 索引標籤。
## 對修補程式合規報告產生進行故障診斷
使用下列資訊協助您使用 Patch Manager ( AWS Systems Manager中的工具) 中的修補程式合規報告產生對問題進行疑難排解。
**Topics**
+ [報告 `AWS-SystemsManager-PatchManagerExportRolePolicy` 政策已損毀的訊息](#patch-compliance-reports-troubleshooting-1)
+ [刪除修補程式合規政策或角色後，無法成功產生排定的報告](#patch-compliance-reports-troubleshooting-2)
### 報告 `AWS-SystemsManager-PatchManagerExportRolePolicy` 政策已損毀的訊息
**問題**：您會收到類似下列的錯誤訊息，指出 `AWS-SystemsManager-PatchManagerExportRolePolicy` 已損毀：
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **解決方案**：使用 Patch Manager主控台或 在產生新的修補程式合規報告之前 AWS CLI 刪除受影響的角色和政策。
**使用主控台刪除損毀的政策**
1. 前往 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。
1. 執行以下任意一項：
**隨需報告** – 如果在產生一次性隨需報告時發生問題，則請在左側導覽中選擇 **Policies** (政策)，搜尋 `AWS-SystemsManager-PatchManagerExportRolePolicy`，然後刪除政策。接下來，選擇 **Roles** (角色)，搜尋 `AWS-SystemsManager-PatchSummaryExportRole`，然後刪除該角色。
**排定的報告** – 如果問題在依排程產生報告時發生，則請在左側導覽中選擇**政策**，對於 `AWS-EventBridge-Start-SSMAutomationRolePolicy` 和 `AWS-SystemsManager-PatchManagerExportRolePolicy`，一次搜尋一個，然後刪除每個政策。接下來，選擇 **Roles** (角色)，一次搜尋一個 `AWS-EventBridge-Start-SSMAutomationRole` 和 `AWS-SystemsManager-PatchSummaryExportRole`，然後刪除每個角色。
**使用 刪除損毀的政策 AWS CLI**
使用您的帳戶 ID 取代*預留位置的值*。
+ 如果在產生一次性隨需報告時發生問題，請執行下列命令：
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
如果在產生排程報告時發生問題，請執行下列命令：
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
在完成上述任一程序後，依照步驟產生或排程新的修補程式合規報告。
### 刪除修補程式合規政策或角色後，無法成功產生排定的報告
**問題**：第一次產生報告時，Systems Manager 會建立服務角色和政策以用於匯出程序 (`AWS-SystemsManager-PatchSummaryExportRole` 和 `AWS-SystemsManager-PatchManagerExportRolePolicy`)。當您第一次依排程產生報告時，Systems Manager 會建立另一個服務角色和政策 (`AWS-EventBridge-Start-SSMAutomationRole` 和 `AWS-EventBridge-Start-SSMAutomationRolePolicy`)。這些可讓 Amazon EventBridge 使用 Runbook [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) 啟動自動化。
如果您刪除這些政策或角色中的任何一個，則排程與指定 S3 儲存貯體和 Amazon SNS 主題之間的連線可能會遺失。
+ **解決方案**：若要解決這個問題，建議刪除先前的排程，並建立新的排程，以取代發生問題的排程。
# 使用 Patch Manager 修復不符合標準的受管節點
本節中的主題提供如何識別修補程式不合規的受管節點，以及如何讓節點合規的概觀。
**Topics**
+ [識別不合規的受管節點](patch-manager-find-noncompliant-nodes.md)
+ [修補程式合規狀態值](patch-manager-compliance-states.md)
+ [修補不相容的受管節點](patch-manager-compliance-remediation.md)
# 識別不合規的受管節點
系統會在兩個 AWS Systems Manager 文件 (SSM 文件) 中的任何一個文件執行時，識別不合規受管節點。這些 SSM 文件會參考 Patch Manager ( AWS Systems Manager中的工具) 中每個受管節點的適當修補基準。然後，他們會評估受管節點的修補程式狀態，然後將合規結果提供給您。
有兩個 SSM 文件可用來識別或更新不合規受管節點：`AWS-RunPatchBaseline` 和 `AWS-RunPatchBaselineAssociation`。每個都會由不同的程序使用，而其合規結果則可透過不同的通道取得。下表概述了這些文件之間的差異。
**注意**
來自 的修補程式合規資料Patch Manager可以傳送到 AWS Security Hub CSPM。Security Hub CSPM 可讓您全面檢視高優先順序的安全提醒和合規狀態。它還會監控您的機群的修補狀態。如需詳細資訊，請參閱[Patch Manager 與 整合 AWS Security Hub CSPM](patch-manager-security-hub-integration.md)。
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| 使用文件的程序 | **隨需修補程式** – 您可以使用 **Patch now** (立即修補) 選項隨需掃描或修補受管節點。如需相關資訊，請參閱[隨需修補受管節點](patch-manager-patch-now-on-demand.md)。 **Systems Manager Quick Setup 修補程式政策** – 您可以在 Quick Setup ( AWS Systems Manager中的工具) 中建立修補組態，該組態可針對整個組織、組織單位子集或單一 AWS 帳戶的單獨排程來掃描或安裝遺失的修補程式。如需相關資訊，請參閱[使用 Quick Setup 修補程式政策設定組織中執行個體的修補](quick-setup-patch-manager.md)。 **執行命令** – 您可以在 Run Command ( AWS Systems Manager中的工具) 中的操作中手動執行 `AWS-RunPatchBaseline`。如需相關資訊，請參閱[從主控台執行命令](running-commands-console.md)。 **Maintenance window** (維護時段) – 您可以在 Run Command 任務類型中建立使用 SSM 文件 `AWS-RunPatchBaseline` 的維護時段。如需相關資訊，請參閱[教學課程：使用主控台建立修補維護時段](maintenance-window-tutorial-patching.md)。 | **Systems Manager Quick Setup 主機管理** – 您可以在 Quick Setup 中啟用主機管理組態選項，每天掃描受管執行個體，檢查修補程式是否合規。如需相關資訊，請參閱[使用 Quick Setup 設定 Amazon EC2 主機管理](quick-setup-host-management.md)。 **Systems Manager [Explorer](Explorer.md)** – 當您允許 中的工具時Explorer， AWS Systems Manager它會定期掃描受管執行個體是否有修補程式合規，並在Explorer儀表板中報告結果。 |
| 修補程式掃描結果資料的格式 | `AWS-RunPatchBaseline` 執行後，Patch Manager 會傳送 `AWS:PatchSummary` 物件至庫存 ( AWS Systems Manager中的工具)。此報告僅由成功修補操作產生，並包含識別何時計算合規狀態的擷取時間。 | `AWS-RunPatchBaselineAssociation` 執行後，Patch Manager 會傳送 `AWS:ComplianceItem` 物件至 Systems Manager 庫存。 |
| 在主控台檢視修補的合規報告 | 您可以在 [Systems Manager 組態合規](systems-manager-compliance.md)和 [使用受管節點](fleet-manager-managed-nodes.md) 中檢視使用 `AWS-RunPatchBaseline` 之程序的修補程式合規資訊。如需詳細資訊，請參閱[檢視修補程式合規結果](patch-manager-view-compliance-results.md)。 | 如果使用Quick Setup掃描受管執行個體的修補程式是否合規，則您可以在 [Systems Manager Fleet Manager](fleet-manager.md) 中查看合規報告。在 Fleet Manager 主控台中，選擇受管節點的節點 ID。在**一般**選單中，選擇**組態合規**。 如果使用 Explorer 掃描受管執行個體的修補程式是否合規，則您可以在 Explorer 和 [Systems Manager OpsCenter](OpsCenter.md) 中查看合規報告。 |
| AWS CLI 檢視修補程式合規結果的 命令 | 對於使用 的程序`AWS-RunPatchBaseline`，您可以使用下列 AWS CLI 命令來檢視受管節點上修補程式的摘要資訊。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | 對於使用 的程序`AWS-RunPatchBaselineAssociation`，您可以使用下列 AWS CLI 命令來檢視執行個體上修補程式的摘要資訊。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| 修補操作 | 對於使用 `AWS-RunPatchBaseline` 的程序，您可以指定是否讓操作僅執行 `Scan` 操作，或者 `Scan and install` 操作。 如果您的目標是識別不合規受管節點，而不是進行修復，請僅執行 `Scan` 操作。 | 使用 AWS-RunPatchBaselineAssociation 的 Quick Setup 和 Explorer 程序僅執行 Scan 操作。 |
| 詳細資訊 | [用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
如需您可能會看到報告各種修補程式合規狀態的相關資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)
如需修復修補程式不合規之受管節點的相關資訊，請參閱 [修補不相容的受管節點](patch-manager-compliance-remediation.md)。
# 修補程式合規狀態值
受管節點修補程式的相關資訊包括每個個別修補程式的狀態報告或狀態。
**提示**
如果您想要將特定修補程式合規狀態指派給受管節點，您可以使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) 命令或 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 操作。主控台中不支援指派合規狀態。
使用下表中的資訊，協助您識別受管節點可能不符合修補程式規範的原因。
## Debian Server 和 Ubuntu Server 的修補程式合規值
對於 Debian Server 和 Ubuntu Server，不同合規狀態的套件分類規則如以下表格所示：
**注意**
評估 `INSTALLED`、`INSTALLED_OTHER` 和 `MISSING` 狀態值時，請記住下列事項：如果您未在建立或更新修補基準時選取**包含非安全性更新**核取方塊，則修補程式候選版本僅限於下列儲存庫中的修補程式：
Ubuntu Server 16.04 LTS︰`xenial-security`
Ubuntu Server 18.04 LTS︰`bionic-security`
Ubuntu Server 20.04 LTS︰`focal-security`
Ubuntu Server 22.04 LTS (`jammy-security`)
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
`debian-security` (Debian Server)
如果選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊，則也會考慮來自其他儲存庫的修補程式。
| 修補程式狀態 | Description | 合規狀態 |
| --- | --- | --- |
| **`INSTALLED`** | 修補程式列在修補基準中，而且已安裝在受管節點上。可能已經由個人手動安裝，或在受管節點上執行 `AWS-RunPatchBaseline` 文件時由 Patch Manager 自動安裝。 | 合規 |
| **`INSTALLED_OTHER`** | 修補程式未包含在基準中，或未經基準核准，但已安裝在受管節點上。修補程式可能是手動安裝的，套件可能是另一個已核准修補程式的必要相依性，或者修補程式可能已包含在 InstallOverrideList 操作中。如果您不指定 `Block` 作為 **Rejected patches** (已拒絕的修補程式) 動作，則 `INSTALLED_OTHER` 修補程式也包含已安裝但拒絕的修補程式。 | 合規 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` 可表示下列兩種情況之一： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-compliance-states.html) 在這兩種情況下，這都不表示具有此狀態的修補程式*需要*重新啟動，只表示自安裝修補程式以來尚未重新啟動節點。 | 不合規 |
| **`INSTALLED_REJECTED`** | 修補程式已安裝在受管節點，但是列於 **Rejected patches** (已拒絕修補程式) 清單。這通常表示修補程式在加到遭拒的修補程式清單中前就已安裝。 | 不合規 |
| **`MISSING`** | 修補程式在基準中已核准，但未安裝在受管節點。如果您設定 `AWS-RunPatchBaseline` 文件任務掃描 (而不是安裝)，系統會為在掃描期間找到，但尚未安裝的修補程式報告此狀態。 | 不合規 |
| **`FAILED`** | 修補程式在基準中已核准，但無法安裝在執行個體。若要排除這種情況，請檢視命令輸出的資訊，或許能幫助您了解問題。 | 不合規 |
## 適用於其他作業系統的修補程式合規值
對於除 Debian Server 和 Ubuntu Server 之外的所有作業系統，不同合規狀態的套件分類規則如以下表格所示：
| 修補程式狀態 | Description | 合規值 |
| --- | --- | --- |
| **`INSTALLED`** | 修補程式列在修補基準中，而且已安裝在受管節點上。可能已經由個人手動安裝，或在節點上執行 `AWS-RunPatchBaseline` 文件時由 Patch Manager 自動安裝。 | 合規 |
| **`INSTALLED_OTHER`**1 | 修補程式不在基準範圍中，但安裝了受管節點。這有兩個可能的原因： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-compliance-states.html) | 合規 |
| **`INSTALLED_REJECTED`** | 修補程式已安裝在受管節點，但是列於 Rejected patches (已拒絕修補程式) 清單。這通常表示修補程式在加到遭拒的修補程式清單中前就已安裝。 | 不合規 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` 可表示下列兩種情況之一： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/patch-manager-compliance-states.html) 在這兩種情況下，這都不表示具有此狀態的修補程式*需要*重新啟動，只表示自安裝修補程式以來尚未重新啟動節點。 | 不合規 |
| **`MISSING`** | 修補程式在基準中已核准，但未安裝在受管節點。如果您設定 `AWS-RunPatchBaseline` 文件任務掃描 (而不是安裝)，系統會為在掃描期間找到，但尚未安裝的修補程式報告此狀態。 | 不合規 |
| **`FAILED`** | 修補程式在基準中已核准，但無法安裝在執行個體。若要排除這種情況，請檢視命令輸出的資訊，或許能幫助您了解問題。 | 不合規 |
| **`NOT_APPLICABLE`**1 | *此合規狀態只會針對 Windows Server 作業系統報告。* 修補程式在基準中已核准，但使用該修補程式的服務或功能尚未安裝在受管節點上。例如，若已在基準中核准，但尚未在受管節點上安裝 Web 服務，則 Internet Information Services (IIS) 等 Web 伺服器服務的修補程式會顯示 `NOT_APPLICABLE`。如果修補程式已由後續更新所取代，也可能標示為 `NOT_APPLICABLE`。這表示已安裝較新的更新，不再需要 `NOT_APPLICABLE` 更新。 | 不適用 |
| AVAILABLE\$1SECURITY\$1UPDATES | *此合規狀態只會針對 Windows Server 作業系統報告。* 未經修補基準核准的可用安全性更新修補程式可以具有 `Compliant` 或 `Non-Compliant` 的合規值，如自訂修補基準中所定義。 在建立或更新修補基準時，您可以選擇要指派給可用但未經核准的安全修補程式的狀態，因為這些修補程式不符合修補基準中指定的安裝條件。例如，如果您已指定在修補程式發布後、安裝前需要等待很長的時間，則可以略過您可能想要安裝的安全修補程式。如果在指定的等待期間發布了修補程式更新，安裝修補程式的等待期間會重新開始。如果等待期間過長，可以發布多個版本的修補程式，但絕不會安裝。 對於修補程式摘要計數，當修補程式報告為 `AvailableSecurityUpdate` 時，它一律會包含在 `AvailableSecurityUpdateCount` 中。如果基準設定為將這些修補程式報告為 `NonCompliant`，它們也會包含在 `SecurityNonCompliantCount` 中。如果基準設定為將這些修補程式報告為 `Compliant`，則它們不會包含在 `SecurityNonCompliantCount` 中。這些修補程式一律會以未指定的嚴重性進行報告，絕不會包含在 `CriticalNonCompliantCount` 中。 | 合規或不合規，取決於為可用安全性更新選取的選項。 您可以使用主控台建立或更新修補基準，在**可用安全性更新合規狀態**欄位中指定此選項。使用 AWS CLI 執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)或 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)命令，您可以在 `available-security-updates-compliance-status` 參數中指定此選項。 |
¹ 對於具有 `INSTALLED_OTHER` 與 `NOT_APPLICABLE` 狀態的修補程式，Patch Manager 根據 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) 命令忽略了查詢結果中的一些資料，例如 `Classification` 和 `Severity` 的值。這樣做是為了協助防止超過庫存 ( AWS Systems Manager中的工具) 中對於個別節點的資料限制。若要檢視所有修補程式的詳細資訊，您可以使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 命令。
# 修補不相容的受管節點
您可以使用許多相同的 AWS Systems Manager 工具和程序來檢查受管節點的修補程式合規性，以讓節點符合目前套用的修補程式規則。若要將受管節點納入修補程式合規， Patch Manager中的工具 AWS Systems Manager必須執行 `Scan and install`操作。(如果您的目標僅是識別不合規受管節點，而不是進行修復，請改為執行 `Scan` 操作。如需詳細資訊，請參閱 [識別不合規的受管節點](patch-manager-find-noncompliant-nodes.md)。)
**使用 Systems Manager 安裝修補**
您可以從數種工具中選擇以執行 `Scan and install` 操作：
+ (建議使用) 在 Quick Setup (Systems Manager 中的工具) 中設定修補程式政策，可讓您針對整個組織、組織單位的子集或單一 AWS 帳戶的排程來安裝遺失的修補程式。如需詳細資訊，請參閱[使用 Quick Setup 修補程式政策設定組織中執行個體的修補](quick-setup-patch-manager.md)。
+ 在 Run Command 任務類型中建立使用 Systems Manager 文件 (SSM 文件) `AWS-RunPatchBaseline` 的維護時段。如需相關資訊，請參閱[教學課程：使用主控台建立修補維護時段](maintenance-window-tutorial-patching.md)。
+ 手動執行 Run Command 操作中的 `AWS-RunPatchBaseline`。如需相關資訊，請參閱[從主控台執行命令](running-commands-console.md)。
+ 使用 **Patch now** (立即修補) 選項隨需安裝修補程式。如需相關資訊，請參閱[隨需修補受管節點](patch-manager-patch-now-on-demand.md)。
# 識別建立修補程式合規資料的執行
修補程式合規資料代表最新成功修補操作的point-in-time快照。每個合規報告都包含執行 ID 和擷取時間，協助您識別哪些操作建立合規資料以及產生資料的時間。
如果您有多種類型的操作來掃描執行個體以檢查修補程式合規性，則每次掃描都會覆寫先前掃描的修補程式合規資料。因此，最終可能會在修補程式合規資料中產生非預期的結果。
例如，假設您建立的修補程式政策會在當地時間每天凌晨 2 點掃描修補程式合規性。該修補程式政策使用修補基準，該基準以嚴重性標記為 `Critical`、`Important` 和 `Moderate` 的修補程式為目標。此修補基準也會指定幾個特別拒絕的修補程式。
此外，假設您已經設定了維護時段，以便每天在當地時間凌晨 4 點掃描同一組受管節點，而您不會刪除或停用這些節點。該維護時段的任務會使用不同的修補基準，該基準僅針對嚴重性為 `Critical` 的修補程式，且不會排除任何特定修補程式。
當維護時段執行第二次掃描時，會刪除第一次掃描中的修補程式合規資料，並取代為第二次掃描中的修補程式合規性。
因此，強烈建議您只使用一種自動化方法在修補操作中進行掃描和安裝。如果您正在設定修補程式政策，則應刪除或停用其他掃描方法，以確保修補程式合規性。如需詳細資訊，請參閱下列主題：
+ 移除維護時段中的修補程式操作 - [使用主控台更新或取消註冊維護時段任務](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ 刪除 State Manager 關聯 – [刪除關聯](systems-manager-state-manager-delete-association.md)。
若要停用主機管理組態中的每日修補程式合規掃描，請在 Quick Setup 中執行下列動作：
1. 在導覽窗格中，選擇 **Quick Setup**。
1. 選取要更新的主機管理組態。
1. 選擇 **Actions, Edit configuration** (動作、編輯組態)。
1. 清除 **Scan instances for missing patches daily** (每日掃描遺失修補程式的執行個體) 核取方塊。
1. 選擇**更新**。
**注意**
使用 **Patch now** (立即修補) 選項掃描受管節點是否合規，會導致覆寫修補程式合規資料。
# 隨需修補受管節點
您可以使用 Patch Manager ( AWS Systems Manager中的工具) 中的**立即修補**選項，在 Systems Manager 主控台執行隨需修補操作。這表示您不需要建立排程，即可更新受管節點的合規狀態或在不合規節點上安裝修補程式。您也不需要在 中的Maintenance Windows工具 Patch Manager和 之間切換 Systems Manager 主控台 AWS Systems Manager，以設定或修改排定的修補時段。
**Patch now** (立即修補) 在您必須儘快在受管節點上套用零時差更新或安裝其他重要修補程式時，特別實用。
**注意**
一次 AWS 帳戶單AWS 區域 對支援隨需修補。其無法用於以*修補程式政策*為基礎的修補操作。建議您使用修補程式政策來維持所有受管節點的合規性。如需有關使用修補程式政策的詳細資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
**Topics**
+ [「立即修補」的運作方式](#patch-on-demand-how-it-works)
+ [執行「立即修補」](#run-patch-now)
## 「立即修補」的運作方式
若要執行 **Patch now** (立即修補)，您只需指定兩個必要設定：
+ 是否只掃描缺少的修補程式，或掃描*和*安裝受管節點上的修補程式
+ 要在哪些受管節點上執行操作
當 **Patch now** (立即修補) 操作執行時，它會決定要使用哪個修補基準，以與為其他修補操作所選取的相同方式使用。如果受管節點與修補程式群組相關聯，則會使用為該群組指定的修補基準。如果受管節點未與修補程式群組關聯，則操作會使用目前設定為受管節點之操作系統類型預設值的修補基準。這可以是預先定義基準，也可以是您已設定為預設值的自訂基準。如需修補基準選取項目的詳細資訊，請參閱 [修補程式群組](patch-manager-patch-groups.md)。
您可以為 **Patch now** (立即修補) 指定的選項包括在修補後選擇何時或是否重新啟動受管節點、指定 Amazon Simple Storage Service (Amazon S3) 儲存貯體來存放修補操作的日誌資料，以及在修補期間將 Systems Manager 文件 (SSM 文件) 作為生命週期掛鉤執行。
### 「立即修補」的並行和錯誤閾值
對於 **Patch now** (立即修補) 操作，並行和錯誤閾值選項由 Patch Manager 處理。您不需要指定要一次修補的受管節點數目，也不需要指定操作失敗之前允許的錯誤數目。當您進行隨需修補時，Patch Manager 會套用下表所述的並行和錯誤閾值設定。
**重要**
以下閾值僅適用於 `Scan and install` 操作。對於 `Scan` 操作，Patch Manager 會嘗試並行掃描最多 1,000 個節點，並繼續掃描，直至遇到最多 1,000 個錯誤。
**並行：安裝操作**
| **Patch now** (立即修補) 操作中受管節點的總數 | 一次掃描或修補的受管節點數目 |
| --- | --- |
| 低於 25 個 | 1 |
| 25-100 | 5% |
| 101 到 1,000 個 | 8% |
| 1,000 個以上 | 10% |
**錯誤閾值：安裝操作**
| **Patch now** (立即修補) 操作中受管節點的總數 | 操作失敗前允許的錯誤數目 |
| --- | --- |
| 低於 25 個 | 1 |
| 25-100 | 5 |
| 101 到 1,000 個 | 10 |
| 1,000 個以上 | 10 |
### 使用「立即修補」生命週期掛鉤
**Patch now** (立即修補) 為您提供在 `Install` 修補操作期間能夠將 SSM Command 文件作為生命週期掛鉤執行的功能。您可以將這些掛鉤用於任務，例如在修補之前關閉應用程式，或在修補後或重新開機後對應用程式執行運作狀態檢查。
如需有關生命週期關聯的詳細資訊，請參閱 [用於修補的 SSM 命令文件：`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)。
除了每個掛鉤的使用範例，下表還為三個 **Patch now** (立即修補) 重新開機選項中的每個選項列出可用的生命週期掛鉤。
**生命週期掛鉤和使用範例**
| 重新開機選項 | 掛鉤：安裝前 | 掛鉤：安裝後 | 掛鉤：結束時 | 掛鉤：排定的重新開機後 |
| --- | --- | --- | --- | --- |
| Reboot if needed (必要時重新開機) | 開始修補之前，請先執行 SSM 文件。 使用範例：在修補程序開始之前，安全地關閉應用程式。 | 在修補操作結束時和受管節點重新開機之前，執行 SSM 文件。 使用範例：執行操作，例如在潛在重新開機前安裝第三方應用程式。 | 修補操作完成並且執行個體重新開機後，執行 SSM 文件。 使用範例：確定應用程式在修補後如預期般執行。 | 不適用 |
| Do not reboot my instances (請勿重新開機執行個體) | 同上。 | 在修補操作結束時，執行 SSM 文件。 使用範例：確定應用程式在修補後如預期般執行。 | *不適用* | *不適用* |
| Schedule a reboot time (排程重新開機時間) | 同上。 | 與 Do not reboot my instances (請勿重新開機執行個體) 相同。 | 不適用 | 在排定的重新開機完成後，立即執行 SSM 文件。 使用範例：確定應用程式在重新開機後如預期般執行。 |
## 執行「立即修補」
使用下列處理程序，隨需修補受管節點。
**執行「立即修補」**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Patch now** (立即修補)。
1. 對於 **Patching operation** (修補操作)，選擇下列其中一項：
+ **Scan** (掃描)：Patch Manager 會發現受管節點中缺少哪些修補程式，但不會進行安裝。您可以在 **Compliance** (合規) 儀表板或其他用於檢視修補程式合規的工具中檢視結果。
+ **Scan and install** (掃描和安裝)：Patch Manager 會發現受管節點中缺少哪些修補程式，但不會進行安裝。
1. 只有在上一個步驟中選擇 **Scan and install** (掃描和安裝) 時，才使用該步驟。針對 **Regions option** (區域選項)，選擇以下其中一個選項：
+ **Reboot if needed** (依需要重新啟動)：安裝完成後，Patch Manager 僅在需要完成修補程式安裝時，才會重新啟動受管節點。
+ **Don't reboot my instances** (請勿重新啟動執行個體)：安裝完成後，Patch Manager 不會重新啟動受管節點。您可以在選擇或管理 Patch Manager 以外的重新開機時，自動重新開機節點。
+ **Schedule a reboot time** (排程重新開機時間)：指定 Patch Manager 的日期、時間和 UTC 時區重新開機您的受管節點。在您執行 **Patch now** (立即修補) 操作時，排定的重新開機會列為具有 `AWS-PatchRebootAssociation` 名稱之 State Manager 中的關聯。
**重要**
如果您在主要修補操作啟動後取消， 中的`AWS-PatchRebootAssociation`關聯State Manager不會自動取消。為了防止意外重新啟動，State Manager如果您不想再進行排定的重新啟動，您必須`AWS-PatchRebootAssociation`從 手動刪除 。否則可能會導致系統意外重新啟動，進而影響生產工作負載。您可以在 Systems Manager 主控台 **State Manager** > 關聯下找到此**關聯**。
1. 在 **Instances to patch** (要修補的執行個體)，選擇以下其中一項：
+ **修補所有執行個體**： Patch Manager 會在目前 中 AWS 帳戶 的所有受管節點上執行指定的操作 AWS 區域。
+ **Patch only the target instances I specify** (只修補我指定的目標執行個體)：您可以在下一個步驟中指定要鎖定的受管節點。
1. 僅當您在上一個步驟中選擇 **Patch only the target instances I specify** (只修補我指定的目標執行個體) 時，使用該步驟。在 **Target selection** (目標選擇範圍) 區段中，指定標籤、手動選取節點或指定資源群組，以識別您要執行這項操作的節點。
**注意**
如果您預期看到的受管節點未列出，請參閱 [疑難排解受管節點的可用性](fleet-manager-troubleshooting-managed-nodes.md) 以取得疑難排解秘訣。
如果您選擇以資源群組為目標，請注意，以 AWS CloudFormation 堆疊為基礎的資源群組仍必須加上預設`aws:cloudformation:stack-id`標籤。如果已經移除，Patch Manager 可能無法判斷哪些受管節點屬於資源群組。
1. (選用) 對於 **Patching log storage** (修補日誌儲存)，如果您要從此修補操作建立並儲存日誌，請選取 S3 儲存貯體來存放日誌。
**注意**
授予能力以將資料寫入至 S3 儲存貯體的 S3 許可，會是指派給執行個體之執行個體設定檔 (適用於 EC2 執行個體) 或 IAM 服務角色 (啟用混合模式的機器) 的許可，而不是執行此任務之 IAM 使用者的許可。如需詳細資訊，請參閱[設定 Systems Manager 所需的執行個體許可](setup-instance-permissions.md)或[在混合多雲端環境中建立 Systems Manager 所需的 IAM 服務角色](hybrid-multicloud-service-role.md)。此外，如果指定的 S3 儲存貯體位於不同的 中 AWS 帳戶，請確定與受管節點相關聯的執行個體描述檔或 IAM 服務角色具有寫入該儲存貯體的必要許可。
1. (選用) 如果您要在修補操作的特定時間點執行 SSM 文件作為生命週期掛鉤，則請執行下列動作：
+ 選擇 **Use lifecycle hooks** (使用生命週期掛鉤)。
+ 針對每個可用的掛鉤，選取要在操作之指定時間點執行的 SSM 文件：
+ 安裝前
+ 安裝後
+ 結束時
+ 排定的重新開機後
**注意**
預設文件 `AWS-Noop` 不會執行任何操作。
1. 選擇 **Patch now** (立即修補)。
**Association execution summary** (關聯執行摘要) 頁面隨即開啟。(修補程式現在使用 State Manager ( AWS Systems Manager中的工具) 中的關聯執行其操作。) 在 **Operation summary** (操作摘要) 區域中，您可以監控指定受管節點上的掃描或修補狀態。
# 使用修補基準
Patch Manager ( AWS Systems Manager中的工具) 的修補基準會定義在受管節點上核准安裝的修補程式。您可以逐一指定核准或拒絕修補程式。您也可以建立自動核准規則，以指定應自動核准某些類型的更新 (例如，關鍵的更新)。拒絕清單會覆寫規則與核准清單。若要使用核准修補程式清單安裝特定套件，首先要移除所有自動核准規則。如果您明確將修補程式識別為拒絕，將不會核准或安裝該修補程式，即使它符合自動核准規則中的所有條件。此外，即使修補程式已核准用於受管節點，但只有在修補程式適用於節點上的軟體時，修補程式才會安裝於受管節點。
**Topics**
+ [檢視 AWS 預先定義的修補程式基準](patch-manager-view-predefined-patch-baselines.md)
+ [使用自訂修補基準](patch-manager-manage-patch-baselines.md)
+ [將現有的修補基準設為預設值 (主控台)](patch-manager-default-patch-baseline.md)
**詳細資訊**
+ [修補基準](patch-manager-patch-baselines.md)
# 檢視 AWS 預先定義的修補程式基準
Patch Manager中的工具 AWS Systems Manager包含 支援的每個作業系統的預先定義修補程式基準Patch Manager。您可以使用這些修補基準 (您無法自訂它們)，或建立自己的修補基準。下列程序說明如何查看預先定義的修補基準是否符合您的需求。若要進一步了解修補基準，請參閱[預先定義和自訂的修補基準](patch-manager-predefined-and-custom-patch-baselines.md)。
**檢視 AWS 預先定義的修補程式基準**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 在修補基準清單中，請選擇其中一個預先定義的修補基準的基準 ID。
-或-
如果您是第一次在目前的 AWS 區域存取 Patch Manager，請選擇**從概觀開始**，然後選擇**修補基準**索引標籤，再選擇其中一個預先定義的修補基準的基準 ID。
**注意**
對於 Windows Server，則會提供三個預先定義的修補基準。修補基準 `AWS-DefaultPatchBaseline` 和 `AWS-WindowsPredefinedPatchBaseline-OS` 僅支援 Windows 作業系統本身的作業系統更新。`AWS-DefaultPatchBaseline` 會用作 Windows Server 受管節點的預設修補基準，除非您指定了不同的修補基準。這兩個修補基準中的組態設定是相同的。兩者中較新的 `AWS-WindowsPredefinedPatchBaseline-OS` 是為了區分它與 Windows Server 第三方預先定義修補基準而建立的。修補基準 `AWS-WindowsPredefinedPatchBaseline-OS-Applications` 可用來將修補程式套用至 Windows Server 作業系統和 Microsoft 發行的支援應用程式。
如需詳細資訊，請參閱[將現有的修補基準設為預設值 (主控台)](patch-manager-default-patch-baseline.md)。
1. 在**核准規則**區段中，檢閱修補基準組態。
1. 如果該設定適用於您的受管節點，您可以請直接跳到程序 [建立和管理修補程式群組](patch-manager-tag-a-patch-group.md)。
-或-
若要建立自己的預設修補基準，請繼續前往主題 [使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
# 使用自訂修補基準
Patch Manager中的工具 AWS Systems Manager包含 支援的每個作業系統的預先定義修補程式基準Patch Manager。您可以使用這些修補基準 (您無法自訂它們)，或建立自己的修補基準。
下列程序說明如何建立、更新並刪除自己的自訂修補基準。若要進一步了解修補基準，請參閱[預先定義和自訂的修補基準](patch-manager-predefined-and-custom-patch-baselines.md)。
**Topics**
+ [建立適用於 Linux 的自訂修補基準](patch-manager-create-a-patch-baseline-for-linux.md)
+ [建立 macOS 的自訂修補基準](patch-manager-create-a-patch-baseline-for-macos.md)
+ [建立 Windows Server 的自訂修補基準](patch-manager-create-a-patch-baseline-for-windows.md)
+ [更新或刪除自訂修補基準](patch-manager-update-or-delete-a-patch-baseline.md)
# 建立適用於 Linux 的自訂修補基準
請使用下列程序在 Patch Manager ( AWS Systems Manager中的工具) 中建立 Linux 受管節點的自訂修補基準。
如需為 macOS 受管節點建立修補基準的資訊，請參閱 [建立 macOS 的自訂修補基準](patch-manager-create-a-patch-baseline-for-macos.md)。如需為 Windows 受管節點建立修補基準的資訊，請參閱 [建立 Windows Server 的自訂修補基準](patch-manager-create-a-patch-baseline-for-windows.md)。
**為 Linux 受管節點建立自訂修補基準**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇**修補基準**索引標籤，然後選擇**建立修補基準**。
-或-
如果您是第一次在目前的 AWS 區域存取 Patch Manager，請選擇**從概觀開始**，然後選擇**修補基準**索引標籤，接著再選擇**建立修補基準**。
1. 在 **Name (名稱)** 中，為新的修補基準輸入一個名稱，例如 `MyRHELPatchBaseline`。
1. (選用) 在 **Description (描述)** 中，輸入此修補基準的描述。
1. 在 **Operating system (作業系統)** 選擇作業系統，例如 `Red Hat Enterprise Linux`。
1. 如果要在建立所選作業系統時，立即開始將此修補基準做為所選作業系統的預設設定，請核取 **Set this patch baseline as the default patch baseline for *operating system name* instances** (將此修補基準設定為「作業系統名稱」執行個體的預設修補基準) 旁的方塊。
**注意**
唯有當您在 2022 年 12 月 22 日[修補程式政策](patch-manager-policies.md)發行前第一次存取 Patch Manager，才能使用此選項。
如需有關設定現有修補基準為預設的更多資訊，請參閱 [將現有的修補基準設為預設值 (主控台)](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating-system (作業系統核准規則)** 部分中，使用欄位來建立一或多個自動核准規則。
+ **產品**：此核准規則適用的作業系統版本，例如 `RedhatEnterpriseLinux7.4`。預設的選取為 `All`。
+ **Classification (分類)**：此核准規則適用的修補程式類型，例如 `Security` 或 `Enhancement`。預設的選取為 `All`。
**提示**
您可以設定修補基準，以控制是否安裝 Linux 的次要版本升級，例如 RHEL 7.8。Patch Manager 可以自動安裝次要版本升級，前提是適當的存放庫中有可用的更新。
對於 Linux 作業系統，次要版本升級分類並不一致。即使在相同的核心版本中，它們可能被歸類為錯誤修正或安全更新，或者未歸類。以下是控制是否要安裝修補基準的幾個選項。
**選項 1**：確保在次要版本升級可用時進行安裝的最廣泛核准規則是將 **Classification (分類)** 指定為 `All` (\$1)，然後選擇 **Include nonsecurity updates (包含非安全更新)** 選項。
**選項 2**：若要確保安裝作業系統版本的修補程式，您可以使用萬用字元 (\$1)，在基準的 **Patch exceptions (修補程式例外狀況)** 區段中指定其核心格式。例如，RHEL 7.\$1 的核心格式為 `kernel-3.10.0-*.el7.x86_64`。
在修補基準的 **Approved patches** (已核准的修補程式) 清單中輸入 `kernel-3.10.0-*.el7.x86_64`，確保所有修補程式 (包括次要版本升級) 已套用至 RHEL 7.\$1 受管節點。(如果您知道次要版本修補程式的確切套件名稱，可以改輸入該名稱。)
**選項 3**：您可以對哪些修補程式套用至受管節點 (包括次要版本升級) 進行最大控制，方法是使用 `AWS-RunPatchBaseline` 文件中的 [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) 參數。如需詳細資訊，請參閱[用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
+ **核准規則 (嚴重性)**：此規則適用的修補程式嚴重性值，例如 `Critical`。預設的選取為 `All`。
+ **Auto-approval (自動核准)**：選取修補程式以進行自動核准的方法。
**注意**
因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。
+ **Approve patches after a specified number of days** (指定天數之後核准修補程式)：修補程式發行或最後更新之後，Patch Manager 自動核准修補程式之前的等待天數。您可以輸入零 (0) 到 360 的任何整數。在大部分情形下，建議等候不要超過 100 天。
+ **Approve patches released up to a specific date** (核准特定日期前發布的修補程式)：Patch Manager 會自動套用在此發行或更新日期當天或之前發行的所有修補程式。例如，如果您指定 2023 年 7 月 7 日，則不會自動安裝在 2023 年 7 月 8 日或之後發行或最後更新的修補程式。
+ (選用) **合規報告**：您要指派給基準所核准之修補程式的嚴重性等級，例如 `Critical` 或 `High`。
**注意**
如果您指定合規報告等級，且任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
+ **Include non-security updates (包含非安全性更新)**：除了安裝安全性相關修補程式之外，選取此核取方塊可安裝來源儲存庫中可用的非安全性修補程式。
如需有關在自訂修補基準中使用核准規則的詳細資訊，請參閱[自訂基準](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)。
1. 如果您要明確核准符合核准規則之修補程式以外的任何修補程式，請在 **Patch exceptions (修補程式例外狀況)** 部分執行下列動作：
+ 在 **Approved patches (核准的修補程式)**，輸入您要核准之修補程式的逗號分隔清單。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ (選用) 在 **Approved patches compliance level (核准的修補程式合規層級)**中，將合規層級指派至清單中的修補程式。
+ 如果您指定的任何核准修補程式都與安全性無關，請選取**包含非安全性更新**核取方塊，以便在您的 Linux 作業系統中也安裝這些修補程式。
1. 如果您要明確拒絕任何符合核准規則之修補程式，請在 **Patch exceptions (修補程式例外狀況)** 部分執行下列動作：
+ 在 **Rejected patches (拒絕的修補程式)** 中，輸入您要拒絕之修補程式的逗號分隔清單。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 在 **Rejected patches action** (已拒絕修補程式動作) 中，選擇要讓 Patch Manager在 **Rejected patches** (已拒絕修補程式) 清單所包含之修補程式上執行的動作。
+ **Allow as dependency** (當做相依性允許)：只有當套件是其他套件的相依性時，才會安裝 **Rejected patches** (已拒絕修補程式) 清單中的套件。這被視為符合修補基準，其狀態回報為 *InstalledOther*。若未指定選項，此為預設動作。
+ **封鎖**：**遭拒的修補程式**清單中的套件，以及將這些套件作為相依性而包含在內的套件，Patch Manager 在任何情況下都無法安裝。如果在**遭拒的修補程式**清單中新增套件之前即安裝該套件，或在之後於 Patch Manager 外部安裝該套件，則會被視為不符合修補基準，並且會將其狀態回報為 *InstalledRejected*。
**注意**
Patch Manager 會以遞迴方式搜尋修補程式相依性。
1. (選用) 如果您要為不同版本的作業系統指定替代的修補程式儲存庫，例如 *AmazonLinux2016.03* 與 *AmazonLinux2017.09*，請為 **Patch sources (修補程式來源)** 部分中的每個產品執行以下動作：
+ 在 **Name (名稱)** 中輸入一個名稱以協助您識別來源組態。
+ 在 **Product (產品)** 中，請選取修補程式來源儲存庫適用的作業系統版本，例如 `RedhatEnterpriseLinux7.4`。
+ 在**組態**中輸入要以適當格式使用的儲存庫組態的值：
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**提示**
如需有關 yum 儲存庫組態可用選項的詳細資訊，請參閱 [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html)。
------
#### [ Examples for Ubuntu Server and Debian Server ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
Ubuntu Server 儲存庫的儲存庫資訊必須以單行指定。如需更多範例和資訊，請參閱 *Ubuntu Server Manuals* 網站上的 [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) 和 *Debian Wiki* 上的 [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format)。
------
選擇 **Add another source (新增其他來源)**，為每個額外的作業系統版本指定來源儲存庫，最多 20 個。
如需有關替代來源修補程式儲存庫的詳細資訊，請參閱[如何指定替代修補程式來源儲存庫 (Linux)](patch-manager-alternative-source-repository.md)。
1. (選用) 對於 **Manage tags (管理標籤)**，請套用一或多個索引鍵名稱/值對至修補基準。
標籤是您指派給資源的選用性中繼資料。標籤允許您以不同的方式 (例如用途、擁有者或環境) 將資源分類。例如，您可能希望標記修補基準，以識別其指定的修補程式的嚴重性等級、其適用的作業系統系列，以及環境類型。在這種情況下，您可以指定類似以下索引鍵名稱/值對的標籤：
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. 選擇 **Create patch baseline (建立修補基準)**。
# 建立 macOS 的自訂修補基準
請使用下列程序在 Patch Manager ( AWS Systems Manager中的工具) 中建立 macOS 受管節點的自訂修補基準。
如需為 Windows Server 受管節點建立修補基準的資訊，請參閱 [建立 Windows Server 的自訂修補基準](patch-manager-create-a-patch-baseline-for-windows.md)。如需為 Linux 受管節點建立修補基準的資訊，請參閱 [建立適用於 Linux 的自訂修補基準](patch-manager-create-a-patch-baseline-for-linux.md)。
**注意**
macOS 不支援全部 AWS 區域。如需有關 macOS Amazon EC2 支援的詳細資訊，請參閱《Amazon EC2 使用者指南》**中的 [Amazon EC2 Mac instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)。
**為 macOS 受管節點建立自訂修補基準**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇**修補基準**索引標籤，然後選擇**建立修補基準**。
-或-
如果您是第一次在目前的 AWS 區域存取 Patch Manager，請選擇**從概觀開始**，然後選擇**修補基準**索引標籤，接著再選擇**建立修補基準**。
1. 在 **Name (名稱)** 中，為新的修補基準輸入一個名稱，例如 `MymacOSPatchBaseline`。
1. (選用) 在 **Description (描述)** 中，輸入此修補基準的描述。
1. 在 **Operating system (作業系統)** 中，選擇 macOS。
1. 如果要在建立 macOS 時，立即開始將此修補基準做為所選作業系統的預設設定，請核取 **Set this patch baseline as the default patch baseline for macOS instances** (將此修補基準設定為 MacOS 執行個體的預設修補基準) 旁的方塊。
**注意**
唯有當您在 2022 年 12 月 22 日[修補程式政策](patch-manager-policies.md)發行前第一次存取 Patch Manager，才能使用此選項。
如需有關設定現有修補基準為預設的更多資訊，請參閱 [將現有的修補基準設為預設值 (主控台)](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating-system (作業系統核准規則)** 部分中，使用欄位來建立一或多個自動核准規則。
+ **產品**：此核准規則適用的作業系統版本，例如 `BigSur11.3.1` 或 `Ventura13.7`。預設的選取為 `All`。
+ **Classification** (分類)：您想要在修補程式期間套用套件的套件管理工具。您可以選擇下列項目：
+ softwareupdate
+ Installer (安裝程式)
+ brew
+ brew cask
預設的選取為 `All`。
+ (選用) **合規報告**：您要指派給基準所核准之修補程式的嚴重性等級，例如 `Critical` 或 `High`。
**注意**
如果您指定合規報告等級，且任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
如需有關在自訂修補基準中使用核准規則的詳細資訊，請參閱[自訂基準](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)。
1. 如果您要明確核准符合核准規則之修補程式以外的任何修補程式，請在 **Patch exceptions (修補程式例外狀況)** 部分執行下列動作：
+ 在 **Approved patches (核准的修補程式)**，輸入您要核准之修補程式的逗號分隔清單。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ (選用) 在 **Approved patches compliance level (核准的修補程式合規層級)**中，將合規層級指派至清單中的修補程式。
1. 如果您要明確拒絕任何符合核准規則之修補程式，請在 **Patch exceptions (修補程式例外狀況)** 部分執行下列動作：
+ 在 **Rejected patches (拒絕的修補程式)** 中，輸入您要拒絕之修補程式的逗號分隔清單。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 在 **Rejected patches action** (已拒絕修補程式動作) 中，選擇要讓 Patch Manager在 **Rejected patches** (已拒絕修補程式) 清單所包含之修補程式上執行的動作。
+ **Allow as dependency** (當做相依性允許)：只有當套件是其他套件的相依性時，才會安裝 **Rejected patches** (已拒絕修補程式) 清單中的套件。這被視為符合修補基準，其狀態回報為 *InstalledOther*。若未指定選項，此為預設動作。
+ **封鎖**：**遭拒的修補程式**清單中的套件，以及將這些套件作為相依性而包含在內的套件，Patch Manager 在任何情況下都無法安裝。如果在**遭拒的修補程式**清單中新增套件之前即安裝該套件，或在之後於 Patch Manager 外部安裝該套件，則會被視為不符合修補基準，並且會將其狀態回報為 *InstalledRejected*。
1. (選用) 對於 **Manage tags (管理標籤)**，請套用一或多個索引鍵名稱/值對至修補基準。
標籤是您指派給資源的選用性中繼資料。標籤允許您以不同的方式 (例如用途、擁有者或環境) 將資源分類。例如，您可能希望標記修補基準，以識別其指定的修補程式的嚴重性等級、其適用的套件管理工具，以及環境類型。在這種情況下，您可以指定類似以下索引鍵名稱/值對的標籤：
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. 選擇 **Create patch baseline (建立修補基準)**。
# 建立 Windows Server 的自訂修補基準
請使用下列程序在 Patch Manager ( AWS Systems Manager中的工具) 中建立 Windows 受管節點的自訂修補基準。
如需為 Linux 受管節點建立修補基準的資訊，請參閱 [建立適用於 Linux 的自訂修補基準](patch-manager-create-a-patch-baseline-for-linux.md)。如需有關建立 macOS 受管節點的修補基準的詳細資訊，請參閱[建立 macOS 的自訂修補基準](patch-manager-create-a-patch-baseline-for-macos.md)。
如需建立僅限於安裝 Windows Service Pack 之修補基準的範例，請參閱[教學課程：使用主控台建立安裝 Windows Service Pack 的修補基準](patch-manager-windows-service-pack-patch-baseline-tutorial.md)。
**建立自訂修補基準 (Windows)**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇**修補基準**索引標籤，然後選擇**建立修補基準**。
-或-
如果您是第一次在目前的 AWS 區域存取 Patch Manager，請選擇**從概觀開始**，然後選擇**修補基準**索引標籤，接著再選擇**建立修補基準**。
1. 在 **Name (名稱)** 中，為新的修補基準輸入一個名稱，例如 `MyWindowsPatchBaseline`。
1. (選用) 在 **Description (描述)** 中，輸入此修補基準的描述。
1. 在 **Operating system (作業系統)** 中，選擇 `Windows`。
1. 在**可用的安全性更新合規狀態**中，選擇您要指派給可用但未經核准的安全修補程式的狀態，因為這些修補程式不符合修補基準、**不合規**或**合規**中指定的安裝條件。
範例案例：如果您已指定在修補程式發布後、安裝前需要等待很長的時間，則可以略過您可能想要安裝的安全修補程式。如果在指定的等待期間發布了修補程式更新，安裝修補程式的等待期間會重新開始。如果等待期間過長，可以發布多個版本的修補程式，但絕不會安裝。
1. 如果要在建立 Windows 時立即開始將此修補基準做為 Windows 的預設設定，請選擇 **Set this patch baseline as the default patch baseline for Windows Server instances (將此修補基準設為 Windows Server 執行個體的預設修補基準)**。
**注意**
唯有當您在 2022 年 12 月 22 日[修補程式政策](patch-manager-policies.md)發行前第一次存取 Patch Manager，才能使用此選項。
如需有關設定現有修補基準為預設的更多資訊，請參閱 [將現有的修補基準設為預設值 (主控台)](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating system (作業系統核准規則)** 部分中，使用欄位來建立一或多個自動核准規則。
+ **產品**：此核准規則適用的作業系統版本，例如 `WindowsServer2012`。預設的選取為 `All`。
+ **Classification (分類)**：此核准規則適用的修補程式類型，例如 `CriticalUpdates`、`Drivers` 和 `Tools`。預設的選取為 `All`。
**提示**
透過包含 `ServicePacks` 或在 **Classification** (分類) 清單中選擇 `All`，您可以在核准規則中包含 Windows Service Pack 安裝。如需範例，請參閱 [教學課程：使用主控台建立安裝 Windows Service Pack 的修補基準](patch-manager-windows-service-pack-patch-baseline-tutorial.md)。
+ **核准規則 (嚴重性)**：此規則適用的修補程式嚴重性值，例如 `Critical`。預設的選取為 `All`。
+ **Auto-approval (自動核准)**：選取修補程式以進行自動核准的方法。
+ **Approve patches after a specified number of days** (指定天數之後核准修補程式)：修補程式發行或更新之後，Patch Manager 自動核准修補程式之前的等待天數。您可以輸入零 (0) 到 360 的任何整數。在大部分情形下，建議等候不要超過 100 天。
+ **Approve patches released up to a specific date** (核准特定日期前發布的修補程式)：Patch Manager 會自動套用在此發行或更新日期當天或之前發行的所有修補程式。例如，如果您指定 2023 年 7 月 7 日，則不會自動安裝在 2023 年 7 月 8 日或之後發行或最後更新的修補程式。
+ (選用) **Compliance reporting (合規報告)**：您要指派給基準所核准之修補程式的嚴重性等級，例如 `High`。
**注意**
如果您指定合規報告等級，且任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
1. (選用) 在 **Approval rules for applications** (應用程式的核准規則) 區段中，使用這些欄位建立一個或多個自動核准規則。
**注意**
您可以將已核准和已拒絕修補程式清單指定為修補程式例外狀況，而不是指定核准規則。請參閱步驟 10 和 11。
+ **Product family (產品系列)**：您想指定規則的一般 Microsoft 產品系列，例如 `Office` 或 `Exchange Server`。
+ **產品**：核准規則適用的應用程式版本，例如 `Office 2016` 或 `Active Directory Rights Management Services Client 2.0 2016`。預設的選取為 `All`。
+ **Classification (分類)**：此核准規則適用的修補程式類型，例如 `CriticalUpdates`。預設的選取為 `All`。
+ **核准規則 (嚴重性)**：此規則適用的修補程式嚴重性值，例如 `Critical`。預設的選取為 `All`。
+ **Auto-approval (自動核准)**：選取修補程式以進行自動核准的方法。
+ **Approve patches after a specified number of days** (指定天數之後核准修補程式)：修補程式發行或更新之後，Patch Manager 自動核准修補程式之前的等待天數。您可以輸入零 (0) 到 360 的任何整數。在大部分情形下，建議等候不要超過 100 天。
+ **Approve patches released up to a specific date** (核准特定日期前發布的修補程式)：Patch Manager 會自動套用在此發行或更新日期當天或之前發行的所有修補程式。例如，如果您指定 2023 年 7 月 7 日，則不會自動安裝在 2023 年 7 月 8 日或之後發行或最後更新的修補程式。
+ (選用) **合規報告**：您要指派給基準所核准之修補程式的嚴重性等級，例如 `Critical` 或 `High`。
**注意**
如果您指定合規報告等級，且任何核准之修補程式的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
1. (選用) 如果您想要明確核准任何修補程式，而非依據核准規則選取修補程式，請在 **Patch exceptions** (修補程式例外狀況) 區段中進行以下操作：
+ 在 **Approved patches (核准的修補程式)**，輸入您要核准之修補程式的逗號分隔清單。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ (選用) 在 **Approved patches compliance level (核准的修補程式合規層級)**中，將合規層級指派至清單中的修補程式。
1. 如果您要明確拒絕任何符合核准規則之修補程式，請在 **Patch exceptions (修補程式例外狀況)** 部分執行下列動作：
+ 在 **Rejected patches (拒絕的修補程式)** 中，輸入您要拒絕之修補程式的逗號分隔清單。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
+ 在 **Rejected patches action** (已拒絕修補程式動作) 中，選擇要讓 Patch Manager在 **Rejected patches** (已拒絕修補程式) 清單所包含之修補程式上執行的動作。
+ **當做相依性允許**：Windows Server 不支援套件相依性的概念。如果**遭拒的修補程式**清單中的套件已安裝在節點上，則會將其狀態回報為 `INSTALLED_OTHER`。任何尚未安裝在節點上的套件都會被略過。
+ **封鎖**：在任何情況下，Patch Manager 都不會安裝**遭拒的修補程式**清單中的套件。如果在**遭拒的修補程式**清單中新增套件之前即安裝該套件，或在之後於 Patch Manager 外部安裝該套件，則會被視為不符合修補基準，並且會將其狀態回報為 `INSTALLED_REJECTED`。
如需有關遭拒的套件動作的詳細資訊，請參閱[自訂修補基準中遭拒的修補程式清單選項](patch-manager-windows-and-linux-differences.md#rejected-patches-diff)。
1. (選用) 對於 **Manage tags (管理標籤)**，請套用一或多個索引鍵名稱/值對至修補基準。
標籤是您指派給資源的選用性中繼資料。標籤允許您以不同的方式 (例如用途、擁有者或環境) 將資源分類。例如，您可能希望標記修補基準，以識別其指定的修補程式的嚴重性等級、其適用的作業系統系列，以及環境類型。在這種情況下，您可以指定類似以下索引鍵名稱/值對的標籤：
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. 選擇 **Create patch baseline (建立修補基準)**。
# 更新或刪除自訂修補基準
您可以在 Patch Manager ( AWS Systems Manager中的工具) 中更新或刪除已建立的自訂修補基準。在更新修補基準時，您可以變更其名稱或說明、核准規則以及已核准和已拒絕的修補程式例外狀況。您也可以更新套用到修補基準的標籤。您無法變更已建立修補程式基準的作業系統類型，也無法變更 提供的預先定義修補程式基準 AWS。
## 更新或刪除修補基準
請依照以下步驟更新或刪除修補基準。
**重要**
刪除 Quick Setup 中修補程式政策組態可能會使用的自訂修補基準時務必小心。
如果您在 Quick Setup 中使用[修補程式政策組態](patch-manager-policies.md)，則您對自訂修補基準所做的更新會每小時與 Quick Setup 同步一次。
如果刪除修補程式政策中參照的自訂修補基準，則修補程式政策的 Quick Setup **Configuration details** (組態詳細資訊) 頁面上會顯示橫幅。此橫幅會通知您修補程式政策參照修補基準不再存在，而後續的修補操作將會失敗。在此情況下，請返回到 Quick Setup **Configurations** (組態) 頁面，選取 Patch Manager 組態，然後選擇 **Actions** (動作)、**Edit configuration** (編輯組態)。刪除的修補基準名稱會反白顯示，您必須為受影響的作業系統選取新的修補基準。
**更新或刪除修補基準**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇您要更新或刪除的修補基準，然後執行以下其中一項：
+ 若要從 中移除修補程式基準 AWS 帳戶，請選擇**刪除**。系統會提示您確認您的動作。
+ 如要變更修補基準名稱或說明、核准規則或修補程式例外狀況，請選擇 **Edit (編輯)**。在 **Edit patch baseline (編輯修補基準)** 頁面上，變更您需要的值和選項，然後選擇 **Save changes (儲存變更)**。
+ 若要新增、變更或刪除套用到修補基準的標籤，請選擇 **Tags (標籤)** 標籤，然後選擇 **Edit tags (編輯標籤)**。在 **Edit patch baseline tags (編輯修補基準標籤)** 頁面上，更新修補基準標籤，然後選擇 **Save changes (儲存變更)**。
如需您可以選擇的組態的相關資訊，請參閱 [使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
# 將現有的修補基準設為預設值 (主控台)
**重要**
您在此處選取的任何預設修補基準不會套用至以修補程式政策為基礎的修補操作。修補程式政策使用自己的修補基準規範。如需有關修補程式政策的詳細資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
在 Patch Manager ( AWS Systems Manager中的工具) 中建立自訂修補基準時，您可以在建立基準時即刻將基準設定為關聯作業系統類型的預設值。如需相關資訊，請參閱[使用自訂修補基準](patch-manager-manage-patch-baselines.md)。
您也可以將現有的修補基準設為作業系統類型的預設值。
**注意**
您需要遵循的步驟取決於您是在 2022 年 12 月 22 日修補程式政策發佈之前還是之後首次存取 Patch Manager。如果您在該日期之前使用 Patch Manager，則您可以使用主控台程序。否則，請使用 AWS CLI 程序。在這些修補程式政策發佈之前未使用 Patch Manager 的區域中，主控台程序中所參考的**動作**選單不會顯示。
**將預設修補基準設為預設**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Patch baselines** (修補基準) 索引標籤。
1. 在修補基準清單中，請選擇目前未設為作業系統類型預設值的修補基準按鈕。
**Default baseline (預設基準)** 欄位會指示目前哪些基線設為預設值。
1. 在 **Actions** 功能表中，選擇 **設定預設修補基準**。
**重要**
如果您在 2022 年 12 月 22 日之前未在目前 AWS 帳戶 和 Patch Manager 區域中使用 ，則**動作**功能表無法使用。如需詳細資訊，請參閱本主題稍早的**注意**部分。
1. 在確認對話方塊中，選擇 **Set default (設為預設)**。
**將預設修補基準設為預設 (AWS CLI)**
1. 執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) 命令以檢視可用修補基準及其 ID 和 Amazon 資源名稱 (ARN) 的清單。
```
aws ssm describe-patch-baselines
```
1. 執行 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) 命令，將一個基準設定為與其相關聯之作業系統的預設值。將 *baseline-id-or-ARN* 替換為要使用的自訂修補基準或預先定義基準的 ID。
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
以下是將自訂基準設定為預設值的範例。
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
以下是將 管理的預先定義基準設定為 AWS 預設值的範例。
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
以下是將自訂基準設定為預設值的範例。
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
以下是將 管理的預先定義基準設定為 AWS 預設值的範例。
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# 檢視可用修補程式
使用 中的Patch Manager工具 AWS Systems Manager，您可以檢視指定作業系統的所有可用修補程式，也可以檢視特定作業系統版本。
**提示**
若要產生可用修補程式的清單並將其儲存到檔案中，您可以使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 命令並指定您偏好的[輸出](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html)。
**檢視可用的修補程式**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Patches** (修補程式) 索引標籤。
-或-
如果您是第一次在目前 AWS 區域存取 Patch Manager，請選擇**從概觀開始**，然後選擇**修補**索引標籤。
**注意**
對於 Windows Server，**修補程式**索引標籤會顯示可從 Windows Server Update Service 取得的更新。
1. 對於 **Operating system** (作業系統)，選擇您要檢視可用修補程式的作業系統，例如 `Windows` 或 `Amazon Linux`。
1. (選用) 對於 **Product** (產品)，請選擇作業系統版本，例如 `WindowsServer2019` 或 `AmazonLinux2018.03`。
1. (選用) 若要新增或移除結果的資訊欄，請選擇位於 **Patches** (修補程式) 清單右上角的設定按鈕 (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/images/configure-button.png))。(根據預設，**Patches** (修補程式) 索引標籤只會顯示部分可用修補程式中繼資料的欄。)
如需可新增至檢視的中繼資料類型詳細資訊，請參閱《*AWS Systems Manager API 參考*》中的[修補程式](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html)。
# 建立和管理修補程式群組
如果您*未*在作業中使用修補程式政策，建議您使用標籤將受管節點新增至修補程式群組來整理您的修補工作。
**注意**
修補程式群組不會用於基於*修補程式政策*的修補操作。如需有關使用修補程式政策的資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
對於在 2022 年 12 月 22 日發布修補程式政策支援之前尚未使用修補程式群組的帳戶區域對，主控台中不支援修補程式群組功能。對於在此日期之前開始使用修補程式群組的帳戶區域對，修補程式群組功能仍然可用。
若要在修補作業中使用標籤，您必須將標籤鍵鍵 `Patch Group` 或 `PatchGroup` 套用至受管節點。您還必須將要為修補程式群組指定的名稱指定為標籤值。您可以指定任何標籤值，但標籤索引鍵必須是 `Patch Group` 或 `PatchGroup`。
如果您已在 [EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup` (不留空格)。
使用標籤將受管節點分組後，請將修補程式群組值新增至修補基準。透過使用修補基準註冊修補程式群組，您可以確保在修補操作期間安裝正確的修補程式。如需有關修補程式群組的詳細資訊，請參閱[修補程式群組](patch-manager-patch-groups.md)。
完成本主題中的任務，讓受管節點可以透過節點標籤和修補基準實現修補。只有在修補 Amazon EC2 執行個體時，才需要完成任務 1。只有當您在[混合多雲端](operating-systems-and-machine-types.md#supported-machine-types)環境中修補非 EC2 執行個體時，才需要完成任務 2。所有受管節點都需要完成任務 3。
**提示**
您也可以使用 AWS CLI 命令`[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)`或 Systems Manager API 操作 ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`，將標籤新增至受管節點。
**Topics**
+ [任務 1：使用標籤將 EC2 執行個體新增至修補程式群組](#sysman-patch-group-tagging-ec2)
+ [任務 2：使用標籤將受管節點新增至修補程式群組](#sysman-patch-group-tagging-managed)
+ [任務 3：將修補程式群組新增至修補基準](#sysman-patch-group-patchbaseline)
## 任務 1：使用標籤將 EC2 執行個體新增至修補程式群組
您可以使用 Systems Manager 主控台或 Amazon EC2 主控台將標籤新增至 EC2 執行個體。只有在修補 Amazon EC2 執行個體時，才需要完成此任務。
**重要**
如果在執行個體上啟用 **Allow tags in instance metadata** (允許執行個體中繼資料中的標籤) 選項，則您不得將 `Patch Group` 標籤 (有空格) 套用至 Amazon EC2 執行個體。允許執行個體中繼資料中的標籤可防止標籤鍵名稱含空格。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用標籤索引鍵 `PatchGroup` (不留空格)。
**選項 1：將 EC2 執行個體新增至修補程式群組 (Systems Manager 主控台)**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Fleet Manager**。
1. 在**受管執行個體**清單中選擇您要設定以進行修補之受管 EC2 執行個體的 ID。EC2 執行個體的節點 ID 開頭為 `i-`。
**注意**
使用 Amazon EC2 主控台和 時 AWS CLI，可以將 `Key = Patch Group`或 `Key = PatchGroup`標籤套用至尚未設定為與 Systems Manager 搭配使用的執行個體。
如果您預期看到的受管節點未列出，請參閱 [疑難排解受管節點的可用性](fleet-manager-troubleshooting-managed-nodes.md) 以取得疑難排解秘訣。
1. 選擇**標籤**索引標籤，然後選擇**編輯**。
1. 在左側欄中，輸入 **Patch Group** 或 **PatchGroup**。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup` (不留空格)。
1. 在右側欄中，輸入一個標籤值，用作此修補程式群組的名稱。
1. 選擇**儲存**。
1. 重複此程序，將其他 EC2 執行個體新增至相同的修補程式群組。
**選項 2：將 EC2 執行個體新增至修補程式群組 (Amazon EC2 主控台)**
1. 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/)，然後在導覽窗格中選擇 **Instances** (執行個體)。
1. 在執行個體清單中，選擇要設定修補的執行個體。
1. 在**動作**功能表中，依次選擇**執行個體設定** > **管理標籤**。
1. 選擇 **Add new tag (新增標籤)**。
1. 對於 **Key** (索引鍵)，輸入 **Patch Group** 或 **PatchGroup**。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup` (不留空格)。
1. 針對**值**，輸入一個值，用作此修補程式群組的名稱。
1. 選擇**儲存**。
1. 重複此程序，將其他執行個體新增至相同的修補程式群組。
## 任務 2：使用標籤將受管節點新增至修補程式群組
遵循本主題中的步驟，將標籤新增至 AWS IoT Greengrass 核心裝置non-EC2 混合啟用的受管節點 (mi-\$1)。只有當您在混合多雲端環境中修補非 EC2 執行個體時，才需要完成此任務。
**注意**
您不能使用 Amazon EC2 主控台為非 EC2 受管節點新增標籤。
**將非 EC2 受管節點新增至修補程式群組 (Systems Manager 主控台)**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Fleet Manager**。
1. 在**受管節點**清單中，選擇您要設定進行修補的受管節點名稱。
**注意**
如果您預期看到的受管節點未列出，請參閱 [疑難排解受管節點的可用性](fleet-manager-troubleshooting-managed-nodes.md) 以取得疑難排解秘訣。
1. 選擇**標籤**索引標籤，然後選擇**編輯**。
1. 在左側欄中，輸入 **Patch Group** 或 **PatchGroup**。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup` (不留空格)。
1. 在右側欄中，輸入一個標籤值，用作此修補程式群組的名稱。
1. 選擇**儲存**。
1. 重複此程序以將其他受管節點新增至相同的修補程式群組。
## 任務 3：將修補程式群組新增至修補基準
要將特定修補基準與受管節點關聯，您必須將修補程式群組值新增至修補基準。透過使用修補基準註冊修補程式群組，您可以確保在修補執行期間安裝正確的修補程式。無論您是修補 EC2 執行個體 或非 EC2 受管節點，還是同時修補兩者，您都需要完成此任務。
如需有關修補程式群組的詳細資訊，請參閱[修補程式群組](patch-manager-patch-groups.md)。
**注意**
您需要遵循的步驟取決於您是在 2022 年 12 月 22 日[修補程式政策](patch-manager-policies.md)發佈之前還是之後首次存取 Patch Manager。
**將修補程式群組新增至修補基準 (Systems Manager 主控台)**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 如果在目前 AWS 區域 您是第一次存取 Patch Manager，且 Patch Manager 開始頁面開啟，請選擇**從概觀開始**。
1. 選擇**修補基準**索引標籤，然後在**修補基準**清單中，選擇您要為修補程式群組設定的修補基準的名稱。
如果在修補程式政策發佈之後才首次存取 Patch Manager，則您必須選擇已建立的自訂基準。
1. 如果**基準 ID** 詳細資訊頁面包含**動作**選單，請執行下列動作：
+ 選擇 **Actions (動作)**，然後選擇 **Modify patch groups (修改修補程式群組)**。
+ 輸入您在 [任務 2：使用標籤將受管節點新增至修補程式群組](#sysman-patch-group-tagging-managed) 中新增到受管節點的標籤*值*，然後選擇**新增**。
如果**基準 ID** 詳細資訊頁面*未*包含**動作**選單，則無法在主控台中設定修補程式群組。這時您可以執行下列任一操作：
+ (建議) 在 Quick Setup ( AWS Systems Manager中的工具) 中設定修補程式政策，以將修補基準映射至一或多個 EC2 執行個體。
如需詳細資訊，請參閱[使用修 Quick Setup 補程式政策](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html)和[使用 Quick Setup 修補程式政策自動化整個組織的修補工作](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)。
+ 使用 AWS Command Line Interface (AWS CLI) 中的 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)命令來設定修補程式群組。
# Patch Manager 與 整合 AWS Security Hub CSPM
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 可讓您全面檢視 的安全狀態 AWS。Security Hub CSPM 會從跨 AWS 帳戶 AWS 服務和支援的第三方合作夥伴產品收集安全資料。使用 Security Hub CSPM，您可以根據安全產業標準和最佳實務來檢查環境。Security Hub CSPM 可協助您分析安全趨勢，並識別最高優先順序的安全問題。
透過使用 Patch Manager中的工具 AWS Systems Manager和 Security Hub CSPM 之間的整合，您可以將有關不合規節點的問題清單從 Patch Manager 傳送至 Security Hub CSPM。問題清單是安全檢查或安全性相關偵測的可觀察記錄。然後，Security Hub CSPM 可以在分析您的安全狀態時包含這些修補程式相關調查結果。
無論您使用哪種方法或組態類型進行修補操作，下列主題中的資訊都適用：
+ 在 Quick Setup 中設定的修補程式政策
+ 在 Quick Setup 中設定的主機管理選項
+ 用來執行修補程式 `Scan` 或 `Install` 任務的維護時段
+ 隨需 **Patch now** (立即修補) 操作
**Contents**
+ [Patch Manager 如何將調查結果傳送到 Security Hub CSPM](#securityhub-integration-sending-findings)
+ [Patch Manager 傳送的問題清單類型](#securityhub-integration-finding-types)
+ [傳送問題清單延遲](#securityhub-integration-finding-latency)
+ [無法使用 Security Hub CSPM 時重試](#securityhub-integration-retry-send)
+ [在 Security Hub CSPM 中檢視問題清單](#securityhub-integration-view-findings)
+ [來自 Patch Manager 的一般問題清單](#securityhub-integration-finding-example)
+ [開啟與設定整合](#securityhub-integration-enable)
+ [如何停止傳送問題清單](#securityhub-integration-disable)
## Patch Manager 如何將調查結果傳送到 Security Hub CSPM
在 Security Hub CSPM 中，將安全問題做為調查結果進行追蹤。有些問題清單來自其他 AWS 服務 或第三方合作夥伴偵測到的問題。Security Hub CSPM 也有一組規則，可用來偵測安全問題並產生問題清單。
Patch Manager 是將問題清單傳送至 Security Hub CSPM 的 Systems Manager 工具之一。在您執行 SSM 文件 (`AWS-RunPatchBaseline`、 或 `AWS-RunPatchBaselineWithHooks`) 執行修補操作之後`AWS-RunPatchBaselineAssociation`，修補資訊會傳送至庫存或合規、 中的工具 AWS Systems Manager，或兩者。在「庫存」、「合規」或兩者都收到資料之後，Patch Manager 會收到通知。然後，Patch Manager 在準確性、格式和合規方面對資料進行評估。如果符合所有條件， 會將資料Patch Manager轉送至 Security Hub CSPM。
Security Hub CSPM 提供用來跨所有這些來源管理調查結果的工具。您可以檢視並篩選問題清單列表，並檢視問題清單的詳細資訊。如需詳細資訊，請參閱《*AWS Security Hub 使用者指南*》中的[檢視問題清單](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html)。您也可以追蹤問題清單的調查狀態。如需詳細資訊，請參閱《*AWS Security Hub 使用者指南*》中的[針對問題清單採取動作](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html)。
Security Hub CSPM 中的所有問題清單都使用稱為 AWS 安全問題清單格式 (ASFF) 的標準 JSON 格式。ASFF 包含問題來源、受影響的資源以及問題清單目前狀態的詳細資訊。請參閱《*AWS Security Hub 使用者指南*》中的 [AWS 安全問題清單格式 (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm)。
### Patch Manager 傳送的問題清單類型
Patch Manager 會使用安全調查結果[AWS 格式 (ASFF) 將調查結果傳送至 Security](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) Hub CSPM。在 ASFF 中，`Types` 欄位提供問題清單類型。來自 Patch Manager 的問題清單可以具有以下 `Types` 值：
+ 軟體和組態檢查/修補程式管理
Patch Manager 會針對每個不合規受管節點傳送一份問題清單。問題清單是以 資源類型報告，[https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)以便問題清單可以與其他報告`AwsEc2Instance`資源類型的 Security Hub CSPM 整合建立關聯。只有在操作發現受管節點不合規時， Patch Manager才會將問題清單轉送至 Security Hub CSPM。問題清單包括「修補程式摘要」結果。
**注意**
向 Security Hub CSPM 報告不合規節點之後。在節點合規之後， Patch Manager 不會將更新傳送至 Security Hub CSPM。在將所需的修補程式套用至受管節點之後，您可以手動解析 Security Hub CSPM 中的問題清單。
如需合規定義的詳細資訊，請參閱 [修補程式合規狀態值](patch-manager-compliance-states.md)。如需有關 `PatchSummary` 的詳細資訊，請參閱《*AWS Security Hub API 參考*》中的 [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)。
### 傳送問題清單延遲
當 Patch Manager建立新的問題清單時，通常會在幾秒鐘到 2 小時內傳送至 Security Hub CSPM。速度取決於該時間點 AWS 區域 中處理的流量。
### 無法使用 Security Hub CSPM 時重試
如果發生服務中斷，則會執行 AWS Lambda 函數，以在服務再次執行後將訊息放回主佇列。訊息位於主要佇列之後，會自動重試。
如果 Security Hub CSPM 無法使用， Patch Manager 會重試傳送問題清單，直到收到問題清單為止。
### 在 Security Hub CSPM 中檢視問題清單
此程序說明如何在 Security Hub CSPM 中檢視有關機群中不符合修補程式合規之受管節點的問題清單。
**檢閱 Security Hub CSPM 調查結果是否符合修補程式合規**
1. 登入 AWS 管理主控台 並在 https：//[https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/) 開啟 AWS Security Hub CSPM 主控台。
1. 在導覽窗格中，選擇**調查結果**。
1. 選擇**新增篩選條件** (![\[The Search icon\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/images/search-icon.png)) 方塊。
1. 在選單中的**篩選條件**下，選擇**產品名稱**。
1. 在開啟的對話方塊中，在第一個欄位中選擇**是**，然後在第二個欄位中輸入 **Systems Manager Patch Manager**。
1. 選擇**套用**。
1. 新增任何您想要用於縮小搜尋結果範圍的其他篩選條件。
1. 在結果清單中，選擇您想要獲取詳細資訊的調查結果的標題。
畫面右側會開啟一個窗格，其中會顯示有關資源、發現的問題以及建議的修復方法的詳細資訊。
**重要**
目前，Security Hub CSPM 會將所有受管節點的資源類型報告為 `EC2 Instance`。這包含您已登記為與 Systems Manager 搭配使用的內部部署伺服器和虛擬機器 (VM)。
**嚴重性分類**
**Systems Manager Patch Manager** 的調查結果清單包含調查結果嚴重性的報告。**嚴重性**分下列等級 (程度從最低到最高)：
+ **資訊性** – 未發現任何問題。
+ **低** – 此問題不需要修復。
+ **中** – 此問題必須解決，但不緊急。
+ **高** – 此問題必須優先處理。
+ **嚴重** – 此問題必須立即修正以免加重。
嚴重性是由執行個體上不合規程度最嚴重的套件所決定。由於您可以擁有多個具有不同嚴重性等級的修補基準，因此會報告所有不合規的套件中最高的嚴重性。例如，假設您有兩個不合規的套件，其中套件 A 的嚴重性為「嚴重」，而套件 B 的嚴重性為「低」。則報告的嚴重性將為「嚴重」。
請注意，嚴重性欄位與 Patch Manager `Compliance` 欄位直接相關。這是您設定並指派給符合規則的個別修補程式的欄位。由於此 `Compliance` 欄位是指派給個別修補程式，因此它不會反映在「修補程式摘要」層級。
**相關內容**
+ 《AWS Security Hub 使用者指南》**中的[調查結果](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html)一節
+ *AWS 管理與治*理部落格中的[使用 Patch Manager 和 Security Hub 實現多帳戶修補程式合規](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/)
## 來自 Patch Manager 的一般問題清單
Patch Manager 使用安全調查結果[AWS 格式 (ASFF) 將調查結果傳送至 Security](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) Hub CSPM。
這是來自 Patch Manager 的一般問題清單範例。
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## 開啟與設定整合
若要使用與 Security Hub CSPM 的Patch Manager整合，您必須開啟 Security Hub CSPM。如需有關如何開啟 Security Hub CSPM 的資訊，請參閱*AWS Security Hub 《 使用者指南*》中的[設定 Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)。
下列程序說明如何在 Security Hub CSPM 已處於作用中狀態但Patch Manager整合已關閉時整合 Patch Manager和 Security Hub CSPM。只有在手動關閉整合時，您才需要完成此處理程序。
**將 Patch Manager新增至 Security Hub CSPM 整合**
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇 **Settings** (設定) 標籤。
-或-
如果您是第一次在目前 AWS 區域存取 Patch Manager，請選擇**從概觀開始**，然後選擇**設定**索引標籤。
1. 在**匯出至 Security Hub CSPM** 區段下，**修補程式合規調查結果右側的 不會匯出至 Security Hub**，請選擇**啟用**。
## 如何停止傳送問題清單
若要停止將調查結果傳送至 Security Hub CSPM，您可以使用 Security Hub CSPM 主控台或 API。
如需詳細資訊，請參閱《*AWS Security Hub 使用者指南*》中的以下主題：
+ [停用和啟用從整合接收問題清單的流程 (主控台)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [從 整合停用問題清單的流程 (Security Hub CSPM API AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# 透過AWS CLI使用 Patch Manager 資源
本節包含 AWS Command Line Interface (AWS CLI) 命令的範例，您可以用來執行 Patch Manager中的工具 組態任務 AWS Systems Manager。
如需使用 AWS CLI 來透過自訂修補基準修補伺服器環境的圖例，請參閱 [教學課程：使用 修補伺服器環境 AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)。
如需使用 AWS CLI AWS Systems Manager 任務的詳細資訊，請參閱 [AWS Systems ManagerAWS CLI 命令參考的 一節](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html)。
**Topics**
+ [AWS CLI 修補程式基準的 命令](#patch-baseline-cli-commands)
+ [AWS CLI 修補程式群組的 命令](#patch-group-cli-commands)
+ [AWS CLI 檢視修補程式摘要和詳細資訊的 命令](#patch-details-cli-commands)
+ [AWS CLI 用於掃描和修補受管節點的 命令](#patch-operations-cli-commands)
## AWS CLI 修補程式基準的 命令
**Topics**
+ [建立修補基準](#patch-manager-cli-commands-create-patch-baseline)
+ [建立包含不同作業系統版本之自訂儲存庫的修補基準](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [更新修補基準](#patch-manager-cli-commands-update-patch-baseline)
+ [重新命名修補基準](#patch-manager-cli-commands-rename-patch-baseline)
+ [刪除修補基準](#patch-manager-cli-commands-delete-patch-baseline)
+ [列出所有修補基準](#patch-manager-cli-commands-describe-patch-baselines)
+ [列出 AWS所有提供的修補程式基準](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [列出我的修補基準](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [顯示修補基準](#patch-manager-cli-commands-get-patch-baseline)
+ [取得預設的修補基準](#patch-manager-cli-commands-get-default-patch-baseline)
+ [將自訂修補基準設定為預設](#patch-manager-cli-commands-register-default-patch-baseline)
+ [將 AWS 修補程式基準重設為預設值](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [標記修補基準](#patch-manager-cli-commands-add-tags-to-resource)
+ [列出修補基準的標記](#patch-manager-cli-commands-list-tags-for-resource)
+ [從修補基準移除標記](#patch-manager-cli-commands-remove-tags-from-resource)
### 建立修補基準
以下命令建立修補基準，在 Windows Server 2012 R2 5 的所有重大和重要安全性更新發行 5 日之後，核准這些更新。也已針對「已核准」和「已拒絕」修補程式清單指定修補程式。此外，修補基準已加上標籤，以表示其用於生產環境。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 建立包含不同作業系統版本之自訂儲存庫的修補基準
僅適用於 Linux 受管節點。以下命令說明如何指定修補程式儲存庫，以用於特定版本的 Amazon Linux 作業系統。此範例使用 Amazon Linux 2017.09 預設啟用的來源儲存庫，但可適應您已為受管節點設定的不同來源儲存庫。
**注意**
為了更好的展示這個更為複雜的命令，我們使用 `--cli-input-json` 選項以及存放外部 JSON 檔案的其他選項。
1. 以類似 `my-patch-repository.json` 的名稱建立 JSON 檔案，並將以下內容新增至該檔案：
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. 在您儲存該檔案的目錄中執行下列命令。
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
系統會傳回如下資訊。
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 更新修補基準
以下命令新增兩個修補程式以拒絕現有的修補基準，另一個修補程式核准現有的修補基準。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](patch-manager-approved-rejected-package-name-formats.md)。
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 重新命名修補基準
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 刪除修補基準
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 列出所有修補基準
```
aws ssm describe-patch-baselines
```
系統會傳回如下資訊。
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
以下是另一個命令，列出 AWS 區域中的所有修補基準。
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
系統會傳回如下資訊。
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### 列出 AWS所有提供的修補程式基準
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
系統會傳回如下資訊。
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### 列出我的修補基準
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
系統會傳回如下資訊。
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### 顯示修補基準
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**注意**
若為自訂修補基準，您可以指定修補基準 ID 或完整的 Amazon Resource Name (ARN)。對於 AWS提供的修補程式基準，您必須指定完整的 ARN。例如 `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`。
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 取得預設的修補基準
```
aws ssm get-default-patch-baseline --region us-east-2
```
系統會傳回如下資訊。
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 將自訂修補基準設定為預設
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 將 AWS 修補程式基準重設為預設值
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 標記修補基準
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### 列出修補基準的標記
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### 從修補基準移除標記
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## AWS CLI 修補程式群組的 命令
**Topics**
+ [建立修補程式群組](#patch-manager-cli-commands-create-patch-group)
+ [向修補程式群組「Web Servers」註冊修補基準](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [使用 AWS提供的修補程式基準註冊修補程式群組 "Backend"](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [顯示修補程式群組登錄](#patch-manager-cli-commands-describe-patch-groups)
+ [從修補基準重新登錄修補程式群組](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### 建立修補程式群組
**注意**
修補程式群組不會用於基於*修補程式政策*的修補操作。如需有關使用修補程式政策的資訊，請參閱 [Quick Setup中的修補程式政策組態](patch-manager-policies.md)。
為了協助您組織修補工作，建議您使用標籤將受管節點新增至修補程式群組。修補程式群組需要使用標籤索引鍵 `Patch Group` 或 `PatchGroup`。如果您[已在 EC2 執行個體中繼資料中允許標籤](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)，則必須使用 `PatchGroup` (不留空格)。您可以指定任何標籤值，但標籤索引鍵必須是 `Patch Group` 或 `PatchGroup`。如需有關修補程式群組的詳細資訊，請參閱[修補程式群組](patch-manager-patch-groups.md)。
使用標籤將受管節點分組後，請將修補程式群組值新增至修補基準。透過使用修補基準註冊修補程式群組，您可以確保在修補操作期間安裝正確的修補程式。
#### 任務 1：使用標籤將 EC2 執行個體新增至修補程式群組
**注意**
使用 Amazon Elastic Compute Cloud (Amazon EC2) 主控台和 時 AWS CLI，可以將 `Key = Patch Group`或 `Key = PatchGroup`標籤套用至尚未設定為與 Systems Manager 搭配使用的執行個體。如果套用 `Patch Group` 或 `Key = PatchGroup` 標籤後您預期在 Patch Manager 中看到的 EC2 執行個體未列出，請參閱 [疑難排解受管節點的可用性](fleet-manager-troubleshooting-managed-nodes.md) 以取得故障診斷秘訣。
執行以下命令來將 `PatchGroup` 標籤新增到 EC2 執行個體。
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### 任務 2：使用標籤將受管節點新增至修補程式群組
執行以下命令，來將 `PatchGroup` 標籤新增到受管節點。
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### 任務 3：將修補程式群組新增至修補基準
執行以下命令，來將 `PatchGroup` 標籤值與指定的修補程式基線建立關聯。
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
系統會傳回如下資訊。
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 向修補程式群組「Web Servers」註冊修補基準
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
系統會傳回如下資訊。
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 使用 AWS提供的修補程式基準註冊修補程式群組 "Backend"
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
系統會傳回如下資訊。
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 顯示修補程式群組登錄
```
aws ssm describe-patch-groups --region us-east-2
```
系統會傳回如下資訊。
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### 從修補基準重新登錄修補程式群組
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
系統會傳回如下資訊。
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## AWS CLI 檢視修補程式摘要和詳細資訊的 命令
**Topics**
+ [取得修補基準定義的所有修補程式](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [為擁有 `SECURITY` 分類和 `Critical` 嚴重性的 AmazonLinux2018.03 取得全部修補程式。](#patch-manager-cli-commands-describe-available-patches-linux)
+ [為 Windows Server 2012 取得 `Critical`MSRC 嚴重性的所有修補程式](#patch-manager-cli-commands-describe-available-patches)
+ [取得所有可用的修補程式](#patch-manager-cli-commands-describe-available-patches)
+ [取得每個受管節點的修補程式摘要狀態](#patch-manager-cli-commands-describe-instance-patch-states)
+ [取得受管節點的修補程式合規詳細資訊](#patch-manager-cli-commands-describe-instance-patches)
+ [檢視修補程式合規結果 (AWS CLI)](#viewing-patch-compliance-results-cli)
### 取得修補基準定義的所有修補程式
**注意**
此命令僅支援 Windows Server 修補基準。
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
系統會傳回如下資訊。
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### 為擁有 `SECURITY` 分類和 `Critical` 嚴重性的 AmazonLinux2018.03 取得全部修補程式。
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
系統會傳回如下資訊。
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### 為 Windows Server 2012 取得 `Critical`MSRC 嚴重性的所有修補程式
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
系統會傳回如下資訊。
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### 取得所有可用的修補程式
```
aws ssm describe-available-patches --region us-east-2
```
系統會傳回如下資訊。
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### 取得每個受管節點的修補程式摘要狀態
各受管節點摘要提供各節點處於以下狀態的修補程式數量："NotApplicable"、"Missing"、"Failed"、"InstalledOther" 和 "Installed"。
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
系統會傳回如下資訊。
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### 取得受管節點的修補程式合規詳細資訊
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
系統會傳回如下資訊。
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### 檢視修補程式合規結果 (AWS CLI)
**為單一受管節點檢視修補程式合規結果**
在 AWS Command Line Interface (AWS CLI) 中執行下列命令，以檢視單一受管節點的修補程式合規結果。
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
使用您想要檢視結果之受管節點的 ID 取代 *instance-id*，格式為 `i-02573cafcfEXAMPLE` 或 `mi-0282f7c436EXAMPLE`。
系統傳回的資訊如下。
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**檢視區域中所有 EC2 執行個體的修補程式計數摘要**
`describe-instance-patch-states` 支援一次只擷取一個受管執行個體的結果。不過，使用具有 `describe-instance-patch-states` 命令的自訂指令碼，您可以產生更精密的報告。
例如，如果在本地計算機上安裝了 [jq 篩選工具](https://stedolan.github.io/jq/download/)，則您可以執行以下命令來識別特定 AWS 區域 中狀態為 `InstalledPendingReboot` 的 EC2 執行個體。
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*region* 代表 AWS 區域 支援的 識別符 AWS Systems Manager，例如`us-east-2`美國東部 （俄亥俄） 區域。如需支援的 *region* 值的清單，請參閱《Amazon Web Services 一般參考》**中 [Systems Manager 服務端點](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)一節的**區域**資料欄。
例如：
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
系統會傳回如下資訊。
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
除了 `InstalledPendingRebootCount`，您可以搜尋的計數類型清單包括下列項目：
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## AWS CLI 用於掃描和修補受管節點的 命令
執行下列命令以掃描檢查修補程式是否合規或安裝修補程式之後，您可以使用 [AWS CLI 檢視修補程式摘要和詳細資訊的 命令](#patch-details-cli-commands) 區段中的命令，以檢視修補程式狀態和合規的相關資訊。
**Topics**
+ [掃描受管節點，檢查修補程式是否合規 (AWS CLI)](#patch-operations-scan)
+ [在受管節點上安裝修補程式 (AWS CLI)](#patch-operations-install-cli)
### 掃描受管節點，檢查修補程式是否合規 (AWS CLI)
**掃描特定受管節點，檢查修補程式是否合規**
執行下列命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
系統會傳回如下資訊。
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**依修補程式群組標籤掃描受管節點，檢查修補程式是否合規**
執行下列命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
系統會傳回如下資訊。
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### 在受管節點上安裝修補程式 (AWS CLI)
**在特定受管節點上安裝修補程式**
執行下列命令。
**注意**
視需要重新啟動目標受管節點，以完成修補程式安裝。如需詳細資訊，請參閱[用於修補的 SSM 命令文件：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
系統會傳回如下資訊。
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**在特定修補程式群組的受管節點上安裝修補程式**
執行下列命令。
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
系統會傳回如下資訊。
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# AWS Systems ManagerPatch Manager 教學課程
本節中的教學課程示範如何針對多種修補案例使用 中的Patch Manager工具 AWS Systems Manager。
**Topics**
+ [教學課程：修補僅限 IPv6 環境中的伺服器](patch-manager-server-patching-iPv6-tutorial.md)
+ [教學課程：使用主控台建立安裝 Windows Service Pack 的修補基準](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [教學課程：使用主控台更新應用程式相依性、修補受管節點，以及執行應用程式特定的運作狀態檢查](aws-runpatchbaselinewithhooks-tutorial.md)
+ [教學課程：使用 修補伺服器環境 AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# 教學課程：修補僅限 IPv6 環境中的伺服器
Patch Manager 支援修補只有 IPv6 的環境中的節點。透過更新SSM Agent組態，修補操作可以設定為僅呼叫 IPv6 服務端點。
**修補僅限 IPv6 環境中的伺服器**
1. 確保 3SSM Agent.3270.0 版或更新版本已安裝在受管節點上。
1. 在受管節點上，導覽至SSM Agent組態檔案。您可以在下列目錄中找到 `amazon-ssm-agent.json` 檔案：
+ Linux：`/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
如果 尚`amazon-ssm-agent.json`不存在，請將相同目錄`amazon-ssm-agent.json.template`下的 內容複製到 `amazon-ssm-agent.json`。
1. 更新下列項目以設定正確的區域，並將 `UseDualStackEndpoint`設定為 `true`：
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. 使用適用於您作業系統的適當命令重新啟動SSM Agent服務：
+ Linux：`sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Server 使用 Snap： `sudo snap restart amazon-ssm-agent`
+ macOS：`sudo launchctl stop com.amazon.aws.ssm`後面接著 `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server：`Stop-Service AmazonSSMAgent`後面接著 `Start-Service AmazonSSMAgent`
如需每個作業系統的完整命令清單，請參閱 [檢查 SSM Agent 狀態並啟動代理程式](ssm-agent-status-and-restart.md)。
1. 執行任何修補操作，以驗證修補操作在您的IPv6-only環境中是否成功。確保要修補的節點具有與修補程式來源的連線。您可以檢查修補執行的Run Command輸出，以檢查有關無法存取儲存庫的警告。修補僅限 IPv6 環境中執行的節點時，請確定節點已連線至修補程式來源。您可以檢查修補執行的Run Command輸出，以檢查有關無法存取儲存庫的警告。對於以 DNF 為基礎的作業系統，如果 `skip_if_unavailable`選項設定為 `True`下，則可以設定在修補期間略過無法使用的儲存庫`/etc/dnf/dnf.conf`。DNF 型作業系統包括 Amazon Linux 2023、8 Red Hat Enterprise Linux 和更新版本、8 Oracle Linux 和更新版本、Rocky Linux、AlmaLinux、CentOS 8 和更新版本。在 Amazon Linux 2023 上，`skip_if_unavailable`選項`True`預設為 。
**注意**
使用安裝覆寫清單或基準覆寫功能時，請確定可從節點存取提供的 URL。如果SSM Agent組態選項`UseDualStackEndpoint`設定為 `true`，則會在提供 S3 URL 時使用雙堆疊 S3 用戶端。
# 教學課程：使用主控台建立安裝 Windows Service Pack 的修補基準
當您建立自訂修補基準時，可以指定安裝所有、部分或僅安裝一種支援的修補程式類型。
在 Windows 的修補基準中，您可以選取 `ServicePacks` 做為唯一的 **Classification (分類)** 選項，以限制僅修補 Service Pack 的更新。中的工具 Patch Manager可以自動安裝 Service Pack AWS Systems Manager，前提是更新可在 Windows Update 或 Windows Server Update Services (WSUS) 中使用。
您可以設定修補基準，以控制是否安裝所有 Windows 版本的 Service Pack，或只安裝特定版本 (例如 Windows 7 或 Windows Server 2016) 的 Service Pack。
使用下列程序建立自訂修補基準，專門用在 Windows 受管節點上安裝所有 Service Pack。
**建立修補基準用於安裝 Windows Service Pack (主控台)**
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇**修補基準**索引標籤，然後選擇**建立修補基準**。
1. 在 **Name (名稱)** 中，為新的修補基準輸入一個名稱，例如 `MyWindowsServicePackPatchBaseline`。
1. (選用) 在 **Description (描述)** 中，輸入此修補基準的描述。
1. 在 **Operating system (作業系統)** 中，選擇 `Windows`。
1. 如果要在建立 Windows 時立即開始將此修補基準做為 Windows 的預設設定，請選擇 **Set this patch baseline as the default patch baseline for Windows Server instances (將此修補基準設為 Windows Server 執行個體的預設修補基準)**。
**注意**
唯有當您在 2022 年 12 月 22 日[修補程式政策](patch-manager-policies.md)發行前第一次存取 Patch Manager，才能使用此選項。
如需有關設定現有修補基準為預設的更多資訊，請參閱 [將現有的修補基準設為預設值 (主控台)](patch-manager-default-patch-baseline.md)。
1. 在 **Approval rules for operating system (作業系統核准規則)** 部分中，使用欄位來建立一或多個自動核准規則。
+ **產品**：核准規則適用的作業系統版本，例如 `WindowsServer2012`。您可以選擇一個、多個或所有支援的 Windows 版本。預設的選取為 `All`。
+ **Classification (分類)**：選擇 `ServicePacks`。
+ **Serverity (嚴重性)**：此規則適用的修補程式嚴重性值。若要確保所有 Service Pack 都包含在規則中，請選擇 `All`。
+ **Auto-approval (自動核准)**：選取修補程式以進行自動核准的方法。
+ **Approve patches after a specified number of days** (指定天數之後核准修補程式)：修補程式發行或更新之後，Patch Manager 自動核准修補程式之前的等待天數。您可以輸入零 (0) 到 360 的任何整數。在大部分情形下，建議等候不要超過 100 天。
+ **Approve patches released up to a specific date** (核准特定日期前發布的修補程式)：Patch Manager 會自動套用在此發行或更新日期當天或之前發行的所有修補程式。例如，如果您指定 2023 年 7 月 7 日，則不會自動安裝在 2023 年 7 月 8 日或之後發行或最後更新的修補程式。
+ (選用) **Compliance reporting (合規報告)**：您要指派給基準所核准之 Service Pack 的嚴重性等級，例如 `High`。
**注意**
如果您指定合規報告等級，且任何核准之 Service Pack 的修補程式狀態回報為 `Missing`，則修補基準的整體報告合規嚴重性是您指定的嚴重性等級。
1. (選用) 對於 **Manage tags (管理標籤)**，請套用一或多個索引鍵名稱/值對至修補基準。
標籤是您指派給資源的選用性中繼資料。標籤允許您以不同的方式 (例如用途、擁有者或環境) 將資源分類。針對此專用於更新 Service Pack 的修補基準，您可以指定如下所示的鍵值組：
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. 選擇 **Create patch baseline (建立修補基準)**。
# 教學課程：使用主控台更新應用程式相依性、修補受管節點，以及執行應用程式特定的運作狀態檢查
在許多情況下，受管節點必須在使用最新的軟體更新修補後重新啟動。不過，在沒有保護措施的生產環境中重新啟動節點，可能會導致數個問題，例如叫用警示、記錄不正確的指標資料，以及中斷資料同步。
此教學課程會示範如何透過使用 AWS Systems Manager 文件 (SSM 文件) `AWS-RunPatchBaselineWithHooks` 達成完成了以下項目的複雜、多步驟修補操作，以避免類似問題：
1. 防止新連線至應用程式
1. 安裝作業系統的更新。
1. 更新應用程式的套件相依性
1. 重新啟動系統
1. 執行應用程式特定的運作狀態檢查
在此範例中，以這種方式設定了基礎設施：
+ 目標虛擬機器會透過 Systems Manager 註冊為受管節點。
+ `Iptables` 會用作本機防火牆。
+ 受管節點上託管的應用程式正在連接埠 443 上執行。
+ 受管節點上託管的應用程式是 `nodeJS` 應用程式。
+ 受管節點上託管的應用程式由 pm2 程序管理工具管理。
+ 應用程式已經有指定的運作狀態檢查端點。
+ 應用程式的運作狀態檢查端點不需要最終使用者身分驗證。端點允許執行符合組織建立可用性需求的運作狀態檢查。(在您的環境中，完全可以簡單地確定 `nodeJS` 應用程式正在執行，並能夠監聽請求。在其他情形下，您可能還想要驗證快取層或資料庫層的連線是否已經建立)。
本教學課程中的範例僅供示範之用，並不代表在生產環境中以原樣實作。另外，請記住，具有 `AWS-RunPatchBaselineWithHooks` 文件的 Patch Manager lifecycle hook 功能 (Systems Manager 中的工具)，可以支援許多其他案例。以下是數個範例。
+ 受管節點重新啟動之後，在修補和重新啟動之前，停止指標報告代理程式。
+ 修補之前將受管節點從 CRM 或 PCS 叢集分開，並在節點重新啟動之後重新連接。
+ 作業系統 (OS) 更新套用之後，但在受管節點重新開機之前，在 Windows Server 機器上更新第三方軟體 (例如，Java、Tomcat、Adobe 應用程式等)。
**更新應用程式相依性、修補受管節點，以及執行應用程式特定的運作狀態檢查**
1. 使用下列內容建立預先安裝指令碼的 SSM 文件，並命名為 `NodeJSAppPrePatch`。使用應用程式的名稱取代 *your\$1application*。
此指令碼會立即封鎖新的傳入請求，並在開始修補操作之前提供五秒鐘，讓已處於作用中狀態的請求完成。對於 `sleep` 選項，指定的秒數要大於完成傳入請求通常所需的秒數。
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
如需有關建立 SSM 文件的資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。
1. 為您的安裝後指令碼建立具有以下內容的另一個 SSM 文件，以更新應用程式相依性並將其命名為 `NodeJSAppPostPatch`。使用您應用程式的路徑取代 */your/application/path*。
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. 為您的 `onExit` 指令碼建立另一個 SSM 文件，其中包含下列內容，讓您的應用程式備份並執行運作狀態檢查。命名此 SSM 文件 `NodeJSAppOnExitPatch`。使用應用程式的名稱取代 *your\$1application*。
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. 在 State Manager ( AWS Systems Manager中的工具) 中建立關聯，以執行下列步驟來核發操作：
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **State Manager**，然後選擇 **Create association (建立關聯)**。
1. 對於 **Name** (名稱)，請提供名稱以協助識別關聯的目的。
1. 在 **Document** (文件) 清單中，請選擇 `AWS-RunPatchBaselineWithHooks`。
1. 針對 **Operation** (操作)，選擇 **Install** (安裝)。
1. (選用) 對於 **Snapshot Id** (快照 ID)，提供您產生的 GUID，以協助加速操作並確保一致性。GUID 值可以像 `00000000-0000-0000-0000-111122223333` 一樣簡單。
1. 對於 **Pre Install Hook Doc Name** (安裝前掛鉤文件名稱)，請輸入 `NodeJSAppPrePatch`。
1. 對於 **Post Install Hook Doc Name** (安裝後掛鉤文件名稱)，請輸入 `NodeJSAppPostPatch`。
1. 對於 **On ExitHook Doc Name** (結束時掛鉤文件名稱)，請輸入 `NodeJSAppOnExitPatch`。
1. 對於 **Targets** (目標)，透過指定標籤、手動選擇節點、選擇資源群組或選擇所有受管節點來識別您的受管節點。
1. 對於 **Specify schedule** (指定排程)，請指定執行關聯的頻率。對於受管節點修補，每週一次是常見頻率。
1. 在 **Rate control** (速率控制) 區段中，選擇選項來控制關聯在多個受管節點上的執行方式。確保一次僅更新部分受管節點。否則，您的所有或大部分機群都可能立即離線。如需使用速率控制的詳細資訊，請參閱[了解 State Manager 關聯中的目標和速率控制](systems-manager-state-manager-targets-and-rate-controls.md)。
1. (選用) 針對**輸出選項**，若要將命令輸出儲存至檔案，請選取**啟用將輸出寫入 S3** 方塊。在方塊中輸入儲存貯體和字首 (資料夾) 名稱。
**注意**
授予能力以將資料寫入至 S3 儲存貯體的 S3 許可，會是指派給受管節點之執行個體設定檔的許可，而不是執行此任務之 IAM 使用者的許可。如需詳細資訊，請參閱[設定 Systems Manager 所需的執行個體許可](setup-instance-permissions.md)或[建立混合環境的 IAM 服務角色](hybrid-multicloud-service-role.md)。此外，若指定的 S3 儲存貯體位於不同的 AWS 帳戶內，請驗證與受管節點相關聯的執行個體設定檔或 IAM 服務角色是否具有寫入該儲存貯體的必要許可。
1. 選擇 **Create Association (建立關聯)**。
# 教學課程：使用 修補伺服器環境 AWS CLI
以下程序說明如何使用自訂修補程式基線、修補程式群組及維護時段來修補伺服器環境。
**開始之前**
+ 在受管節點上安裝或更新 SSM Agent。若要修補 Linux 受管節點，您的節點必須執行 SSM Agent 2.0.834.0 版或更新的版本。如需詳細資訊，請參閱[使用 Run Command 更新 SSM Agent](run-command-tutorial-update-software.md#rc-console-agentexample)。
+ 設定 中Maintenance Windows工具 的角色和許可 AWS Systems Manager。如需詳細資訊，請參閱[設定 Maintenance Windows](setting-up-maintenance-windows.md)。
+ 如果您尚未安裝並設定 AWS Command Line Interface (AWS CLI)，請安裝並設定 。
如需相關資訊，請參閱[安裝或更新最新版本的 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。
**設定 Patch Manager 並修補受管節點 (命令列)**
1. 執行下列命令以建立名為 `Production-Baseline` 的 Windows 修補基準。此修補基準會在修補程式發行或最後更新 7 天後核准生產環境的修補程式。也就是說，我們已標記修補基準，以表示其用於生產環境。
**注意**
`OperatingSystem` 參數和 `PatchFilters` 取決於修補基準所套用之目標受管節點的作業系統。如需詳細資訊，請參閱 [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) 和 [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
系統會傳回如下資訊。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 執行下列命令，以註冊兩個修補程式群組的「Production-Baseline」修補基準。群組命名為「資料庫伺服器」和「前端伺服器」。
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
系統會傳回如下資訊。
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
系統會傳回如下資訊。
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 執行以下命令來為生產伺服器建立兩個維護時段。第一個時段為每個星期二的晚上 10 點。第二個時段為每個星期六的晚上 10 點。此外，維護時段已加上標籤，表示其用於生產環境。
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
系統會傳回如下資訊。
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
系統會傳回如下資訊。
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. 執行下列命令，將 `Database` 和 `Front-End` 伺服器修補程式群組註冊到各自的維護時段。
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
系統會傳回如下資訊。
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
系統會傳回如下資訊。
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. 執行下列命令以註冊修補程式任務，該任務會在 `Database` 和 `Front-End` 伺服器各自的維護時段上安裝伺服器缺少的更新。
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
系統會傳回如下資訊。
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
系統會傳回如下資訊。
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. 執行以下命令以取得修補程式群組的高階修補程式合規摘要。高階修補程式合規摘要包括處於各別修補程式狀態之修補程式的受管節點數目。
**注意**
在第一個維護時段期間執行修補程式任務之前，摘要中的受管節點數目預計為零。
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
系統會傳回如下資訊。
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. 執行以下命令以取得修補程式群組中各受管節點的修補程式摘要狀態。每個受管節點摘要包括修補群組之每個受管節點中，處於個別修補程式狀態的多個修補程式。
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
系統會傳回如下資訊。
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
如需可用於Patch Manager組態任務的其他 AWS CLI 命令範例，請參閱 [透過AWS CLI使用 Patch Manager 資源](patch-manager-cli-commands.md)。
# Patch Manager 疑難排解
使用下列資訊以協助您對 Patch Manager ( AWS Systems Manager中的工具) 的問題進行疑難排解。
**Topics**
+ [問題：`baseline_overrides.json` 的 "Invoke-PatchBaselineOperation : Access Denied" 錯誤或 "Unable to download file from S3" 錯誤](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [問題：修補失敗且沒有明顯的原因或錯誤訊息](#race-condition-conflict)
+ [問題：非預期的修補程式合規結果](#patch-manager-troubleshooting-compliance)
+ [在 Linux 上執行 `AWS-RunPatchBaseline` 時發生錯誤](#patch-manager-troubleshooting-linux)
+ [在 Windows Server 上執行 `AWS-RunPatchBaseline` 時發生錯誤](#patch-manager-troubleshooting-windows)
+ [在 macOS `AWS-RunPatchBaseline`上執行時發生錯誤](#patch-manager-troubleshooting-macos)
+ [使用 AWS 支援 自動化 Runbook](#patch-manager-troubleshooting-using-support-runbooks)
+ [聯絡 AWS 支援](#patch-manager-troubleshooting-contact-support)
## 問題：`baseline_overrides.json` 的 "Invoke-PatchBaselineOperation : Access Denied" 錯誤或 "Unable to download file from S3" 錯誤
**問題**：執行修補程式政策指定的修補作業時，您收到類似以下範例的錯誤。
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**原因**：您已在 Quick Setup 中建立修補程式政策，並且部分受管節點已連接執行個體設定檔 (適用於 EC2 執行個體) 或已連接服務角色 (適用於非 EC2 機器)。
然而，如下圖所示，您並未選取**在連接至執行個體的現有執行個體設定檔中新增必要的 IAM 政策**核取方塊。
![\[\]](http://docs.aws.amazon.com/zh_tw/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
建立修補程式政策時，也會建立 Amazon S3 儲存貯體來存放政策的組態 `baseline_overrides.json` 檔案。如果您在建立政策時未選取**將必要的 IAM 政策新增至連接至執行個體的現有執行個體設定檔**核取方塊，則存取 S3 儲存貯體中的 `baseline_overrides.json` 所需的 IAM 政策和資源標籤不會自動新增至現有的 IAM 執行個體設定檔和服務角色。
**解決方案 1**：刪除現有的修補程式政策組態，然後建立替代項目，並在建立過程中確保選取**將必要的 IAM 政策新增至連接至執行個體的現有執行個體設定檔**核取方塊。此選項會將此 Quick Setup 組態建立的 IAM 政策套用至已連接執行個體設定檔或服務角色的節點。(根據預設，Quick Setup 會將必要的政策新增至*仍沒有*執行個體設定檔或服務角色的執行個體和節點。) 如需詳細資訊，請參閱[使用 Quick Setup 修補程式政策自動化整個組織的修補工作](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)。
**解決方案 2**：手動將必要的許可和標籤新增至每個您搭配 Quick Setup 使用的 IAM 執行個體設定檔和 IAM 服務角色。如需說明，請參閱[適用於修補程式政策 S3 儲存貯體的許可](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions)。
## 問題：修補失敗且沒有明顯的原因或錯誤訊息
**問題**：修補作業失敗且未傳回錯誤訊息。
**可能原因**：修補受管節點時，即使已成功安裝修補程式，文件執行仍可能會中斷並標記為失敗。如果系統在修補操作期間啟動意外重新啟動 （例如，將更新套用至韌體或 SecureBoot 等功能），就會發生這種情況。SSM 代理程式無法在外部重新啟動期間保留和繼續文件執行狀態，導致執行報告為失敗。
**解決方案**：若要在執行失敗後驗證修補程式安裝狀態，請執行`Scan`修補操作，然後檢查修補程式管理員中的修補程式合規資料，以評估目前的合規狀態。
如果您判斷外部重新啟動不是此案例中失敗的原因，我們建議您聯絡 [AWS 支援](#patch-manager-troubleshooting-contact-support)。
## 問題：非預期的修補程式合規結果
**問題**：檢閱 `Scan` 操作之後產生的修補程式合規詳細資訊時，結果包含未反映修補基準中設定的規則之資訊。例如，您在修補基準中新增至 **Rejected patches** (已拒絕的修補程式) 清單的例外狀況會列為 `Missing`。或者，即使修補基準僅指定 `Critical` 修補程式，分類為 `Important` 的修補程式仍會列為遺失。
**原因**：Patch Manager 目前支援多種執行 `Scan` 操作的方法：
+ 在 Quick Setup 中設定的修補程式政策
+ 在 Quick Setup 中設定的主機管理選項
+ 用來執行修補程式 `Scan` 或 `Install` 任務的維護時段
+ 隨需 **Patch now** (立即修補) 操作
當 `Scan` 操作執行時，其會覆寫最近掃描的合規詳細資訊。如果您已設定多個方法來執行 `Scan` 操作，而且其使用具有不同規則的不同修補基準，則會產生不同的修補程式合規結果。
**解決方案**：為避免非預期的修補程式合規結果，建議您一次僅使用一種方法來執行 Patch Manager `Scan` 操作。如需詳細資訊，請參閱[識別建立修補程式合規資料的執行](patch-manager-compliance-data-overwrites.md)。
## 在 Linux 上執行 `AWS-RunPatchBaseline` 時發生錯誤
**Topics**
+ [問題：'No such file or directory' (沒有該檔案或目錄) 錯誤](#patch-manager-troubleshooting-linux-1)
+ [問題：'another process has acquired yum lock' (另一個程序已取得 yum 鎖定) 錯誤](#patch-manager-troubleshooting-linux-2)
+ [問題：'Permission denied / failed to run commands' (許可被拒/無法執行命令) 錯誤](#patch-manager-troubleshooting-linux-3)
+ [問題：'Unable to download payload' (無法下載酬載) 錯誤](#patch-manager-troubleshooting-linux-4)
+ [問題：'unsupported package manager and python version combination' (不支援的套件管理工具和 python 版本組合) 錯誤](#patch-manager-troubleshooting-linux-5)
+ [問題：Patch Manager 不會套用指定的規則來排除某些套件](#patch-manager-troubleshooting-linux-6)
+ [問題：修補失敗，且 Patch Manager 報告 TLS 的伺服器名稱指示延伸項目無法使用](#patch-manager-troubleshooting-linux-7)
+ [問題：Patch Manager 報告 'No more mirrors to try' (沒有更多鏡像可以嘗試)](#patch-manager-troubleshooting-linux-8)
+ [問題：修補失敗並顯示訊息 "Error code returned from curl is 23"](#patch-manager-troubleshooting-linux-9)
+ [問題：修補失敗並顯示訊息 "Error unpacking rpm package…"](#error-unpacking-rpm)
+ [問題：修補失敗並顯示 "Encounter service side error when uploading the inventory"](#inventory-upload-error)
+ [問題：修補失敗並顯示訊息 "Errors were encountered while downloading packages"](#errors-while-downloading)
+ [問題：修補失敗，並出現記憶體不足 (OOM) 錯誤](#patch-manager-troubleshooting-linux-oom)
+ [問題：修補失敗並顯示訊息 "The following signatures couldn't be verified because the public key is not available"](#public-key-unavailable)
+ [問題：修補失敗並顯示訊息 "NoMoreMirrorsRepoError"](#no-more-mirrors-repo-error)
+ [問題：修補失敗並顯示訊息 "Unable to download payload"](#payload-download-error)
+ [問題：修補失敗並顯示訊息 "install errors: dpkg: error: dpkg frontend is locked by another process"](#dpkg-frontend-locked)
+ [問題：在 Ubuntu Server 上的修補失敗，並顯示 "dpkg was interrupted" 錯誤](#dpkg-interrupted)
+ [問題：套件管理工具公用程式無法解決套件相依性問題](#unresolved-dependency)
+ [問題：SLES 受管節點上的 Zypper 套件鎖定相依性失敗](#patch-manager-troubleshooting-linux-zypper-locks)
+ [問題：無法取得鎖定。另一個修補操作正在進行中。](#patch-manager-troubleshooting-linux-concurrent-lock)
### 問題：'No such file or directory' (沒有該檔案或目錄) 錯誤
**問題**：當您執行 `AWS-RunPatchBaseline` 時，修補會失敗，並顯示下列其中一個錯誤。
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**原因 1**：要執行 `AWS-RunPatchBaseline` 的兩個命令在同一受管節點上同時執行。這將建立一個競爭條件，導致無法建立或正常存取臨時 `file patch-baseline-operations*`。
**原因 2**：`/var` 目錄下保留的儲存空間不足。
**解決方案 1**：確定沒有維護時段具有兩個或更多 Run Command 任務 (以相同優先順序執行 `AWS-RunPatchBaseline` 的任務和在相同目標 ID 上執行的任務)。如果是這種情況，請重新排序優先順序。 Run Command 是 中的工具 AWS Systems Manager。
**解決方案 2**：確保一次只有一個維護時段正在執行 Run Command 任務，這些任務在相同目標依相同排程使用 `AWS-RunPatchBaseline`。若發生此情形，請變更排程。
**解決方案 3**：確保只有一個 State Manager 關聯正在依相同排程執行 `AWS-RunPatchBaseline`，並以相同的受管節點為目標。State Manager 是 AWS Systems Manager中的工具。
**解決方案 4**：在 `/var` 目錄下為更新套件釋放足夠的儲存空間。
### 問題：'another process has acquired yum lock' (另一個程序已取得 yum 鎖定) 錯誤
**問題**：當您執行 `AWS-RunPatchBaseline` 時，修補會失敗，並顯示下列錯誤。
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**原因**：`AWS-RunPatchBaseline` 文件已經開始在另一個操作中執行的受管節點上執行，並且已經取得套件管理工具 `yum` 程序。
**解決方案**：確保沒有 State Manager 關聯、維護時段任務或依排程執行 `AWS-RunPatchBaseline` 的其他組態大約在同一時間針對同一個受管節點。
### 問題：'Permission denied / failed to run commands' (許可被拒/無法執行命令) 錯誤
**問題**：當您執行 `AWS-RunPatchBaseline` 時，修補會失敗，並顯示下列錯誤。
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**原因**：`/var/lib/amazon/` 可能掛載了 `noexec` 許可。這是一個問題，因為 SSM Agent 將酬載指令碼下載至 `/var/lib/amazon/ssm` 並從該位置執行指令碼。
**解決方案**：請確定您已將專屬分割區設定為 `/var/log/amazon` 和 `/var/lib/amazon`，並且這些分割區掛載了 `exec` 許可。
### 問題：'Unable to download payload' (無法下載酬載) 錯誤
**問題**：當您執行 `AWS-RunPatchBaseline` 時，修補會失敗，並顯示下列錯誤。
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**原因**：受管節點沒有存取指定 Amazon Simple Storage Service (Amazon S3) 儲存貯體的必要許可。
**解決方案**：更新您的網路組態，讓 S3 端點可以連線。如需詳細資訊，請參閱 [SSM Agent 與 AWS 受管 S3 儲存貯體的通訊](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 中的對 Patch Manager S3 儲存貯體進行必要存取的相關資訊。
### 問題：'unsupported package manager and python version combination' (不支援的套件管理工具和 python 版本組合) 錯誤
**問題**：當您執行 `AWS-RunPatchBaseline` 時，修補會失敗，並顯示下列錯誤。
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**原因**：Python 3 的支援版本未安裝在 Debian Server 或 Ubuntu Server 執行個體上。
**解決方案**：在伺服器上安裝 Python 3 (3.0 - 3.12) 的支援版本，這是 Debian Server 和 Ubuntu Server 受管節點必需的。
### 問題：Patch Manager 不會套用指定的規則來排除某些套件
**問題**：您已嘗試透過在 `/etc/yum.conf` 檔案中指定套件以排除某些套件，格式為 `exclude=package-name`，但在 Patch Manager `Install` 操作期間，不會排除這些套件。
**原因**：Patch Manager 未包含 `/etc/yum.conf` 檔案中指定的排除項目。
**解決方案**：若要排除特定套件，請建立自訂修補基準，並建立規則以排除您不想安裝的套件。
### 問題：修補失敗，且 Patch Manager 報告 TLS 的伺服器名稱指示延伸項目無法使用
**問題**：修補操作會發出下列訊息。
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**原因**：此訊息並不表示錯誤。相反，這是一個警告，即與作業系統分發的舊版 Python 不支援 TLS 伺服器名稱指示。Systems Manager 修補程式承載指令碼會在連線至支援 SNI AWS APIs 時發出此警告。
**解決方案**：若要在報告此訊息時對任何修補故障進行故障診斷，請檢閱 `stdout` 和 `stderr` 檔案的內容。如果尚未將修補基準設定為將這些檔案儲存在 S3 儲存貯體或 Amazon CloudWatch Logs 中，則您可以在 Linux 受管節點的下列位置找到這些檔案。
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### 問題：Patch Manager 報告 'No more mirrors to try' (沒有更多鏡像可以嘗試)
**問題**：修補操作會發出下列訊息。
```
[Errno 256] No more mirrors to try.
```
**原因**：受管節點上設定的儲存庫無法正常運作。可能的原因包括：
+ `yum` 快取已毀損。
+ 由於網路相關問題，無法連線儲存庫 URL。
**解決方案**：Patch Manager 會使用受管節點的預設套件管理工具來執行修補操作。再次檢查儲存庫是否已設定並正常運作。
### 問題：修補失敗並顯示訊息 "Error code returned from curl is 23"
**問題**：使用 `AWS-RunPatchBaseline` 的修補作業失敗，並出現類似以下內容的錯誤：
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**原因**：您的系統上使用的 curl 工具缺少寫入文件系統所需的許可。如果套件管理工具的預設 curl 工具被其他版本取代，例如使用 snap 安裝的版本，就會發生這種情況。
**解決方案**：如果在安裝不同版本時解除安裝了套件管理工具提供的 curl 版本，請重新安裝。
如果您需要保留安裝的多個 curl 版本，請確保與套件管理工具相關聯的版本位於 `PATH` 變數中列出的第一個目錄中。您可以透過執行 `echo $PATH` 命令來檢查，以查看檢查系統上的目錄是否有可執行檔的目錄順序。
### 問題：修補失敗並顯示訊息 "Error unpacking rpm package…"
**問題**：修補作業失敗，並出現類似下列內容的錯誤：
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**原因 1**：當特定套件存在於多個套件安裝程式 (例如 `pip` 和 `yum` 或 `dnf`) 時，使用預設套件管理工具時可能會發生衝突。
`urllib3` 套件 (可在 `pip`、`yum` 和 `dnf` 中找到) 就是一個常見的範例。
**原因 2**：`python-urllib3` 套件已損毀。如果 `rpm` 套件在先前由 `yum` 或 `dnf` 安裝，並且之後由 `pip` 安裝或更新了套件檔案，就可能會發生這種情況。
**解決方案**：透過執行 `sudo pip uninstall urllib3` 命令從 pip 中移除 `python-urllib3` 套件，僅將套件保留在預設套件管理工具 (`yum` 或 `dnf`) 中。
### 問題：修補失敗並顯示 "Encounter service side error when uploading the inventory"
**問題**：執行 `AWS-RunPatchBaseline` 文件時，您會收到下列錯誤訊息：
```
Encounter service side error when uploading the inventory
```
**原因**：執行 `AWS-RunPatchBaseline` 的兩個命令在同一受管節點上同時執行。這會在修補操作期間初始化 boto3 用戶端時建立競爭條件。
**解決方案**：確保沒有 State Manager 關聯、維護時段任務或依排程執行 `AWS-RunPatchBaseline` 的其他組態大約在同一時間針對同一個受管節點。
### 問題：修補失敗並顯示訊息 "Errors were encountered while downloading packages"
**問題**：在修補期間，收到類似以下內容的錯誤：
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**原因**：在受管節點上的記憶體不足時，可能會發生此錯誤。
**解決方案**：設定 swap 記憶體，或將執行個體升級為其他類型以增加記憶體。然後啟動新的修補作業。
### 問題：修補失敗，並出現記憶體不足 (OOM) 錯誤
**問題**：執行 時`AWS-RunPatchBaseline`，修補操作會因為受管節點上的記憶體不足而失敗。您可能會看到錯誤，例如 `Cannot allocate memory`、 `Killed`（來自 Linux OOM 刪除器），或操作意外失敗。此錯誤更可能發生在 RAM 少於 1 GB 的執行個體上，但當有大量更新可用時，也可能影響具有更多記憶體的執行個體。
**原因**：修補程式管理員會在受管節點上使用原生套件管理員執行修補操作。修補操作期間所需的記憶體取決於幾個因素，包括：
+ 受管節點上已安裝和可用更新的套件數量。
+ 使用中的套件管理員及其記憶體特性。
+ 修補操作時在受管節點上執行的其他程序。
具有大量已安裝套件或大量可用更新的受管節點在修補操作期間需要更多記憶體。當可用的記憶體不足時，修補程序將會失敗，並在發生錯誤時結束。作業系統也可以終止修補程序。
**解決方案**：嘗試下列一或多個項目：
+ 在受管節點上的低工作負載活動期間排程修補操作，例如使用維護時段。
+ 將執行個體升級至具有更多記憶體的類型。
+ 在受管節點上設定交換記憶體。請注意，在 EBS 輸送量有限的執行個體上，大量交換使用可能會導致效能降低。
+ 檢閱並減少修補操作期間在受管節點上執行的程序數量。
### 問題：修補失敗並顯示訊息 "The following signatures couldn't be verified because the public key is not available"
**問題**：在 Ubuntu Server 上的修補失敗，並出現類似以下內容的錯誤：
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**原因**：GNU Privacy Guard (GPG) 密鑰已過期或遺失。
**解決方案**：重新整理 GPG 金鑰，或者，再次新增金鑰。
例如，根據前面顯示的錯誤，我們看到 `467B942D3A79BD29` 金鑰遺失且必須新增。若要這麼做，請執行任一下列命令：
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
或者，若要重新整理所有金鑰，請執行以下命令：
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
如果在此之後發生錯誤，建議您將問題報告給維護儲存庫的組織。在修補可用之前，您可以編輯 `/etc/apt/sources.list` 檔案，以便在修補期間省略此儲存庫。
若要這麼做，請開啟要編輯的 `sources.list` 檔案，找到儲存庫所在的行，然後在該行的開頭插入一個 `#` 字元以將其註解掉。然後儲存並關閉檔案。
### 問題：修補失敗並顯示訊息 "NoMoreMirrorsRepoError"
**問題**：收到類似以下內容的錯誤：
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**原因**：來源儲存庫中存在錯誤。
**解決方案**：建議您將問題報告給維護該儲存庫的組織。在錯誤得到修正之前，您可以在作業系統層級停用此儲存庫。若要這麼做，請執行以下命令，並以您的儲存庫名稱取代 *repo-name* 的值：
```
yum-config-manager --disable repo-name
```
以下是範例。
```
yum-config-manager --disable pgdg94
```
執行此命令之後，請另執行修補操作。
### 問題：修補失敗並顯示訊息 "Unable to download payload"
**問題**：收到類似以下內容的錯誤：
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**原因**：受管節點組態包含錯誤或不完整。
**解決方案**：請確保受管節點的設定如下：
+ 安全群組中的有傳出 TCP 443 規則。
+ NACL 中有傳出 TCP 443 規則。
+ NACL 中有傳入 TCP 1024-65535 規則。
+ 路由表中有 NAT/IGW 以提供與 S3 端點的連線。如果執行個體無法存取網際網路，請提供與 S3 端點的連線。若要這麼做，請在相關 VPC 中新增 S3 閘道端點，並將其與受管節點的路由表整合。
### 問題：修補失敗並顯示訊息 "install errors: dpkg: error: dpkg frontend is locked by another process"
**問題**：修補失敗並出現類似以下內容的錯誤：
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**原因**：套件管理工具已經在作業系統層級的受管節點上執行另一個程序。如果此另一個程序需要很長時間才能完成，則 Patch Manager 修補作業可能會逾時並失敗。
**解決方案**：在使用套件管理工具的另一個程序完成之後，執行新的修補作業。
### 問題：在 Ubuntu Server 上的修補失敗，並顯示 "dpkg was interrupted" 錯誤
**問題**：在 Ubuntu Server 上，修補失敗並出現類似以下內容的錯誤：
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**原因**：一個或多個套件設定錯誤。
**解決方案**：執行以下步驟：
1. 一次執行一條下列命令，以查看哪些套件受到影響以及每個套件的問題：
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. 執行以下命令以修正有問題的套件：
```
sudo dpkg --configure -a
```
1. 如果上一個命令未能完全解決問題，請執行以下命令：
```
sudo apt --fix-broken install
```
### 問題：套件管理工具公用程式無法解決套件相依性問題
**問題**：受管節點上的原生套件管理工具無法解決套件相依性問題，且修補失敗。以下錯誤訊息範例指出在使用 `yum` 作為套件管理工具的作業系統上發生的這種失敗類型。
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**原因**：Linux 作業系統上，Patch Manager 使用機器上的原生套件管理工具執行修補作業。例如 `yum`、`dnf`、`apt` 和 `zypper`。應用程式會根據需要自動偵測、安裝、更新或移除相依套件。但是，某些情況可能會導致套件管理工具無法完成相依性作業，例如：
+ 作業系統上設定了多個衝突的儲存庫。
+ 由於網路相關的問題，無法存取遠端儲存庫 URL。
+ 在儲存庫中找到適用於錯誤架構的套件。
**解決方案**：修補程式可能會因為各種原因造成的相依性問題而失敗。因此，我們建議您聯絡 AWS 支援 以協助故障診斷。
### 問題：SLES 受管節點上的 Zypper 套件鎖定相依性失敗
**問題**：您在 SUSE Linux Enterprise Server 執行個體上搭配 `Install` 操作執行 `AWS-RunPatchBaseline` 時，修補會失敗，並發生與套件鎖定相關的相依性檢查錯誤。您可能會看到類似下列的錯誤訊息：
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
在此範例中，套件 `mock-pkg-standalone` 已鎖定，您可以在輸出中執行 `sudo zypper locks` 並尋找此套件名稱來進行驗證。
或者，您可能會看到指出相依性檢查失敗的日誌項目：
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**注意**
此問題只會在 `Install` 操作期間發生。`Scan` 操作不會套用套件鎖定，也不會受到現有鎖定的影響。
**原因**：當 zypper 套件鎖定因相依性衝突而阻止安裝或更新套件時，就會發生此錯誤。套件鎖定可能有多種原因：
+ **客戶套用的鎖定**：您或您的系統管理員使用 zypper 命令 (例如 `zypper addlock`) 手動鎖定套件。
+ **Patch Manager 拒絕的修補程式**：當您在修補基準的**已拒絕修補程式**清單中指定套件時，Patch Manager 會自動套用套件鎖定，以防止其安裝。
+ **中斷操作导致的剩餘鎖定**：在極少數情況下，如果在 Patch Manager 能够清除暫時鎖定之前修補程式操作中斷 (例如透過系統重新啟動)，則剩餘套件鎖定可能會保留在您的受管節點上。
**解決方案**：若要解決 zypper 套件鎖定問題，請根據原因遵循下列步驟：
**步驟 1：識別鎖定的套件**
連線至您的 SLES 受管節點，並執行下列命令來列出所有目前鎖定的套件：
```
sudo zypper locks
```
**步驟 2：判斷鎖定來源**
+ 如果鎖定的套件是您為了系統穩定性而刻意鎖定的套件，請考慮它們是否需要保持鎖定狀態，或者是否可以暫時解除鎖定以進行修補。
+ 如果鎖定的套件符合修補基準的**已拒絕修補程式**清單中的項目，這些可能是中斷修補程式操作导致的剩餘鎖定。在正常操作期間，Patch Manager 會暫時套用這些鎖定，並在操作完成時自動將其移除。您可以從拒絕清單中移除套件，或修改修補基準規則。
+ 如果您無法辨識鎖定的套件，且未刻意鎖定，它們可能是先前中斷修補程式操作导致的剩餘鎖定。
**步驟 3：視需要移除鎖定**
若要移除特定套件鎖定，請使用下列命令：
```
sudo zypper removelock package-name
```
若要移除所有套件鎖定 (請謹慎使用)，請執行下列命令：
```
sudo zypper cleanlocks
```
**步驟 4：更新修補基準 (如適用)**
如果鎖定是由修補基準中已拒絕的修補程式造成：
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Patch Manager**。
1. 選擇**修補基準**索引標籤，然後選擇自订修補基準。
1. 選擇**動作**、**修改修補基準**。
1. 在**已拒絕修補程式**區段中，檢閱列出的套件，並移除應允許安裝的任何套件。
1. 選擇**儲存變更**。
**步驟 5：重試修補程式操作**
移除有問題的鎖定並視需要更新修補基準後，請再次執行 `AWS-RunPatchBaseline` 文件。
**注意**
當 Patch Manager 在 `Install` 操作期間为已拒絕修補程式套用鎖定時，其設計為會在修補程式操作完成後自動清除這些鎖定。如果您在執行 `sudo zypper locks` 時看到這些鎖定，則表示先前的修補程式操作在進行清除之前已中斷。不過，如果修補程式操作中斷，則可能需要手動清除，如本程序中所述。
**預防**：若要避免未來的 zypper 鎖定衝突：
+ 仔細檢閱修補基準的已拒絕修補程式清單，確保只包含您真正想要排除的套件。
+ 避免手動鎖定可能需要作為安全性更新相依性的套件。
+ 如果您必須手動鎖定套件，請記錄原因並定期檢閱鎖定。
+ 請確保修補程式操作成功完成，且這些操作不會因系統重新啟動或其他因素而中斷。
+ 全程監控修補程式操作直至完成，並避免因系統重新啟動或其他動作而中斷這些操作，而可能導致暫時鎖定無法正確清除。
### 問題：無法取得鎖定。另一個修補操作正在進行中。
**問題**：執行 時`AWS-RunPatchBaseline`，修補失敗，錯誤碼 4 和下列錯誤訊息。
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**原因**：當多個修補操作同時嘗試在相同的受管節點上執行時，會發生此錯誤。鎖定檔案可防止並行修補操作，以避免衝突並確保系統穩定性。
**解決方案**：確保修補操作未排定在同一受管節點上同時執行。檢閱下列組態，以識別和解決排程衝突：
+ **修補程式政策**：檢查您的快速設定修補程式政策組態，以確保它們不會與其他修補排程重疊。
+ **維護時段**：檢閱您的維護時段關聯，以確認多個時段未在重疊時間以具有修補任務的相同受管節點為目標。
+ **現在手動修補操作**：避免在排程修補進行時**，立即**啟動手動修補操作。
## 在 Windows Server 上執行 `AWS-RunPatchBaseline` 時發生錯誤
**Topics**
+ [問題：產品系列/產品配對不相符](#patch-manager-troubleshooting-product-family-mismatch)
+ [問題：`AWS-RunPatchBaseline` 輸出會傳回 `HRESULT` (Windows Server)](#patch-manager-troubleshooting-hresult)
+ [問題：受管節點無法存取 Windows 更新目錄或 WSUS](#patch-manager-troubleshooting-instance-access)
+ [問題：PatchBaselineOperations PowerShell 模組無法下載](#patch-manager-troubleshooting-module-not-downloadable)
+ [問題：缺少修補程式](#patch-manager-troubleshooting-missing-patches)
+ [問題：無法取得鎖定。另一個修補操作正在進行中。](#patch-manager-troubleshooting-windows-concurrent-lock)
### 問題：產品系列/產品配對不相符
**問題**：當您在 Systems Manager 主控台中建立修補基準時，您會指定產品系列和產品。例如，您可能選擇：
+ **產品系列**：`Office`
**產品**：`Office 2016`
**原因**：如果您嘗試以不符合的產品系列/產品配對來建立修補基準，則會出現錯誤訊息。以下為此狀況發生的原因：
+ 您已選擇有效的產品系列和產品配對，但將該產品系列選擇移除了。
+ 您選擇了 **Obsolete or mismatched options (已淘汰或不符合的選項)** 子清單中的產品，而非 **Available and matching options (可用和符合的選項)** 子清單中的產品。
產品**淘汰或不匹配選項**子清單中的項目可能已透過 SDK 或 AWS Command Line Interface (AWS CLI) `create-patch-baseline`命令錯誤輸入。這可能代表著導入了拼寫錯誤或產品被指派給錯誤的產品系列。如果已為之前的修補基準指定，但沒有 Microsoft 提供的修補程式，則產品也會包含在 **Obsolete or mismatched options** (已淘汰或不符合的選項) 子清單中。
**解決方案**：為了避免在主控台中出現此問題，請一律從 **Currently available options** (目前可用的選項) 子清單中進行選擇。
您也可以使用 AWS CLI 或 `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` API 命令中的 `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` 命令以檢視擁有可用修補程式的產品。
### 問題：`AWS-RunPatchBaseline` 輸出會傳回 `HRESULT` (Windows Server)
**問題**：您收到以下錯誤：
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**原因**：這個輸出表示原生的 Windows 更新 API 無法執行修補操作。
**解決方案**：檢查以下 microsoft.com 主題中的 `HResult` 程式碼以識別解決錯誤的故障診斷步驟：
+ [按元件列出的 Windows Update 錯誤代碼](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Windows Update 常見錯誤和緩解措施](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### 問題：受管節點無法存取 Windows 更新目錄或 WSUS
**問題**：您收到以下錯誤：
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**原因**：這個錯誤可能與 Windows 更新元件相關，或缺乏至 Windows 更新目錄或 Windows 伺服器更新服務 (WSUS) 的連線。
**解決方案**：確認您的受管節點已透過網際網路閘道、NAT 閘道或 NAT 執行個體連線至 [Microsoft 更新目錄](https://www.catalog.update.microsoft.com/home.aspx)。如果使用 WSUS，請確認受管節點已連線至您環境中的 WSUS 伺服器。如果連線能夠提供給預定的目的地，請查看 Microsoft 文件，了解 `HResult 0x80072EE2` 的其他潛在原因。這可能表示作業系統層級有問題。
### 問題：PatchBaselineOperations PowerShell 模組無法下載
**問題**：您收到以下錯誤：
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**解決方案**：檢查受管節點的連線和 Amazon Simple Storage Service (Amazon S3) 的許可。受管節點的 AWS Identity and Access Management (IAM) 角色必須使用 中引用的最低許可[SSM Agent 與 AWS 受管 S3 儲存貯體的通訊](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)。節點必須透過 Amazon Simple Storage Service (Amazon S3) 閘道端點、NAT 閘道或網際網路閘道與 Amazon Simple Storage Service (Amazon S3) 端點進行通訊。如需 (SSM Agent) 的 AWS Systems Manager SSM Agent VPC 端點需求的詳細資訊，請參閱 [使用適用於 Systems Manager 的 VPC 端點來改善 EC2 執行個體的安全性](setup-create-vpc.md)。
### 問題：缺少修補程式
**問題**：`AWS-RunPatchbaseline` 成功完成，但有一些缺少的修補程式。
以下是一些常見原因及其解決方案。
**原因 1**：基準無效。
**解決方案 1**：如需檢查這是否為原因，請使用下列處理程序。
1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 AWS Systems Manager 主控台。
1. 在導覽窗格中，選擇 **Run Command**。
1. 選取 **Command history** (命令歷史記錄) 標籤，然後選取您要檢查其基準的命令。
1. 選取缺少修補程式的受管節點。
1. 選擇 **Step 1 - Output** (步驟 1 – 輸出) 並尋找 `BaselineId` 值。
1. 檢查指派的[修補基準組態](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)，即修補基準的作業系統、產品名稱、分類和嚴重性。
1. 前往 [Microsoft 更新目錄](https://www.catalog.update.microsoft.com/home.aspx)。
1. 搜尋 Microsoft 知識庫 (KB) 文章 ID (例如 KB3216916)。
1. 確認 **Product** (產品) 下的該值是否與受管節點的值相符，並選取相應的 **Title** (標題)。新的 **Update Details** (更新詳細資訊) 時段將會開啟。
1. 在 **Overview** (概觀) 標籤上，**classification** (分類) 和 **MSRC severity** (MSRC 嚴重性) 必須符合您先前找到的修補基準組態。
**原因 2**：修補程式已被取代。
**解決方案 2**：如需檢查這是否為真實情形，請使用下列處理程序。
1. 前往 [Microsoft 更新目錄](https://www.catalog.update.microsoft.com/home.aspx)。
1. 搜尋 Microsoft 知識庫 (KB) 文章 ID (例如 KB3216916)。
1. 確認 **Product** (產品) 下的該值是否與受管節點的值相符，並選取相應的 **Title** (標題)。新的 **Update Details** (更新詳細資訊) 時段將會開啟。
1. 前往 **Package Details** (套件詳細資訊) 標籤。尋找 **This update has been replaced by the following updates:** (此更新已由以下更新取代) 標頭下的項目。
**原因 3**：相同的修補程式可能有不同的 KB 數，因為 WSUS 和 Windows 線上更新會作為獨立的 Microsoft 發行通道處理。
**解決方案 3**：檢查修補程式的資格。如果 WSUS 下無法使用套件，請安裝 [OS Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57)。如果套件適用於所有作業系統組建，請安裝[作業系統組建 18362.1256 和 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9)。
### 問題：無法取得鎖定。另一個修補操作正在進行中。
**問題**：執行 時`AWS-RunPatchBaseline`，修補失敗，錯誤碼 4 和下列錯誤訊息。
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**原因**：當多個修補操作同時嘗試在相同的受管節點上執行時，會發生此錯誤。鎖定檔案可防止並行修補操作，以避免衝突並確保系統穩定性。
**解決方案**：確保修補操作未排定在同一受管節點上同時執行。檢閱下列組態，以識別和解決排程衝突：
+ **修補程式政策**：檢查您的快速設定修補程式政策組態，以確保它們不會與其他修補排程重疊。
+ **維護時段**：檢閱您的維護時段關聯，以確認多個時段未在重疊時間以具有修補任務的相同受管節點為目標。
+ **現在手動修補操作**：避免在排程修補進行時**，立即**啟動手動修補操作。
## 在 macOS `AWS-RunPatchBaseline`上執行時發生錯誤
**Topics**
+ [問題：無法取得鎖定。另一個修補操作正在進行中。](#patch-manager-troubleshooting-macos-concurrent-lock)
### 問題：無法取得鎖定。另一個修補操作正在進行中。
**問題**：當您執行 時`AWS-RunPatchBaseline`，修補失敗，錯誤碼 4 和下列錯誤訊息。
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**原因**：當多個修補操作同時嘗試在相同的受管節點上執行時，會發生此錯誤。鎖定檔案可防止並行修補操作，以避免衝突並確保系統穩定性。
**解決方案**：確保修補操作未排定在同一受管節點上同時執行。檢閱下列組態，以識別和解決排程衝突：
+ **修補程式政策**：檢查您的快速設定修補程式政策組態，以確保它們不會與其他修補排程重疊。
+ **維護時段**：檢閱您的維護時段關聯，以確認多個時段未在重疊時間針對具有修補任務的相同受管節點。
+ **現在手動修補操作**：避免在排程修補進行時**，立即**啟動手動修補操作。
## 使用 AWS 支援 自動化 Runbook
AWS 支援 提供兩個 Automation Runbook，可用來疑難排解與修補相關的特定問題。
+ `AWSSupport-TroubleshootWindowsUpdate` – [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) 執行手冊用於識別可能使 Amazon Elastic Compute Cloud (Amazon EC2) Windows Server 執行個體的 Windows Server 更新失敗的問題。
+ `AWSSupport-TroubleshootPatchManagerLinux` – [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) 執行手冊可對使用 Patch Manager 在 Linux 受管節點上修補程式的常見失敗問題進行疑難排解。此執行手冊的主要目標是識別修補程式命令失敗的根本原因，並建議修復計畫。
**注意**
執行 Automation 執行手冊需要付費。有關資訊，請參閱 [AWS Systems Manager 自動化定價](https://aws.amazon.com/systems-manager/pricing/#Automation)。
## 聯絡 AWS 支援
如果您在本節或 [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager) 的 Systems Manager 問題中找不到疑難排解解決方案，且您擁有[開發人員、商業或企業 支援 計畫](https://aws.amazon.com/premiumsupport/plans)，則您可以在 [AWS 支援](https://aws.amazon.com/premiumsupport/) 建立技術支援案例。
聯絡之前 支援，請收集下列項目：
+ [SSM 代理程式日誌](ssm-agent-logs.md)
+ Run Command 命令 ID、維護時段 ID 或 Automation 執行 ID
+ 對於 Windows Server 受管節點，也會收集下列項目：
+ 如 [如何安裝修補程式](patch-manager-installing-patches.md) 的 **Windows** (Windows) 標籤中所述的 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`
+ Windows 更新日誌：對於 Windows Server 2012 R2 和更舊版本，請使用 `%windir%/WindowsUpdate.log`。對於 Windows Server 2016 和更新版本，請在使用 `%windir%/WindowsUpdate.log` 之前首先執行 PowerShell 命令 [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)
+ 對於 Linux 受管節點，也會收集下列項目：
+ 目錄 `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux` 的內容