• 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)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 透過主控台使用 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)