• 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)。

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

# 修補程式合規狀態值
<a name="patch-manager-compliance-states"></a>

受管節點修補程式的相關資訊包括每個個別修補程式的狀態報告或狀態。

**提示**  
如果您想要將特定修補程式合規狀態指派給受管節點，您可以使用 [put-compliance-items](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) 命令或 [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 操作。主控台中不支援指派合規狀態。

使用下表中的資訊，協助您識別受管節點可能不符合修補程式規範的原因。

## Debian Server 和 Ubuntu Server 的修補程式合規值
<a name="patch-compliance-values-ubuntu"></a>

對於 Debian Server 和 Ubuntu Server，不同合規狀態的套件分類規則如以下表格所示：

**注意**  
評估 `INSTALLED`、`INSTALLED_OTHER` 和 `MISSING` 狀態值時，請記住下列事項：如果您未在建立或更新修補基準時選取**包含非安全性更新**核取方塊，則修補程式候選版本僅限於下列儲存庫中的修補程式：  
`bionic-security` (Ubuntu Server 18.04 LTS)
`focal-security` (Ubuntu Server 20.04 LTS)
`jammy-security` (Ubuntu Server 22.04 LTS)
`noble-security` (Ubuntu Server 24.04 LTS)
`plucky-security` (Ubuntu Server 25.04)
`debian-security` (Debian Server)
如果選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊，則也會考慮來自其他儲存庫的修補程式。


| 修補程式狀態 | 說明 | 合規狀態 | 
| --- | --- | --- | 
| **`INSTALLED`** | 修補程式列在修補基準中，而且已安裝在受管節點上。可能已經由個人手動安裝，或在受管節點上執行 `AWS-RunPatchBaseline` 文件時由 Patch Manager 自動安裝。 | 合規 | 
| **`INSTALLED_OTHER`** | 修補程式未包含在基準中，或未經基準核准，但已安裝在受管節點上。修補程式可能是手動安裝的，套件可能是另一個已核准修補程式的必要相依性，或者修補程式可能已包含在 InstallOverrideList 操作中。如果您不指定 `Block` 作為 **Rejected patches** (已拒絕的修補程式) 動作，則 `INSTALLED_OTHER` 修補程式也包含已安裝但拒絕的修補程式。 | 合規 | 
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` 可表示下列兩種情況之一：+  Patch Manager `Install` 操作已將修補程式套用至受管節點，但節點尚未在套用修補程式後重新啟動。這通常表示 `NoReboot` 文件上次在受管節點上執行時，已為 `RebootOption` 參數選取了 `AWS-RunPatchBaseline` 選項。 <br />如需詳細資訊，請參閱[參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。 <br />+  自上次重新啟動受管節點以來，已在 Patch Manager 外部安裝修補程式。 <br />在這兩種情況下，這都不表示具有此狀態的修補程式*需要*重新啟動，只表示自安裝修補程式以來尚未重新啟動節點。 | 不合規 | 
| **`INSTALLED_REJECTED`** | 修補程式已安裝在受管節點，但是列於 **Rejected patches** (已拒絕修補程式) 清單。這通常表示修補程式在加到遭拒的修補程式清單中前就已安裝。 | 不合規 | 
| **`MISSING`** | 修補程式在基準中已核准，但未安裝在受管節點。如果您設定 `AWS-RunPatchBaseline` 文件任務掃描 (而不是安裝)，系統會為在掃描期間找到，但尚未安裝的修補程式報告此狀態。 | 不合規 | 
| **`FAILED`** | 修補程式在基準中已核准，但無法安裝在執行個體。若要排除這種情況，請檢視命令輸出的資訊，或許能幫助您了解問題。 | 不合規 | 

## 適用於其他作業系統的修補程式合規值
<a name="patch-compliance-values"></a>

對於除 Debian Server 和 Ubuntu Server 之外的所有作業系統，不同合規狀態的套件分類規則如以下表格所示：


|  修補程式狀態 | 說明 | 合規值 | 
| --- | --- | --- | 
| **`INSTALLED`** | 修補程式列在修補基準中，而且已安裝在受管節點上。可能已經由個人手動安裝，或在節點上執行 `AWS-RunPatchBaseline` 文件時由 Patch Manager 自動安裝。 | 合規 | 
| **`INSTALLED_OTHER`**1 | 修補程式不在基準範圍中，但安裝了受管節點。這有兩個可能的原因：1.  可能已手動安裝修補程式。 <br />2.  僅限 Linux：可能已安裝該套件，作為不同的已核准修補程式的必要*相依性*。如果將 `Allow as dependency` 指定為**遭拒的修補程式**動作，則安裝為相依性的修補程式會取得報告狀態 `INSTALLED_OTHER`。 <br />請注意：Windows Server 不支援修補程式相依性概念。如需有關 Patch Manager 如何處理 Windows Server 上**遭拒的修補程式**清單中之修補程式的資訊，請參閱[自訂修補基準中遭拒的修補程式清單選項](patch-manager-windows-and-linux-differences.md#rejected-patches-diff)。  | 合規 | 
| **`INSTALLED_REJECTED`** | 修補程式已安裝在受管節點，但是列於 Rejected patches (已拒絕修補程式) 清單。這通常表示修補程式在加到遭拒的修補程式清單中前就已安裝。 | 不合規 | 
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` 可表示下列兩種情況之一：+  Patch Manager `Install` 操作已將修補程式套用至受管節點，但節點尚未在套用修補程式後重新啟動。這通常表示 `NoReboot` 文件上次在受管節點上執行時，已為 `RebootOption` 參數選取了 `AWS-RunPatchBaseline` 選項。 <br />如需詳細資訊，請參閱[參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。 <br />+  自上次重新啟動受管節點以來，已在 Patch Manager 外部安裝修補程式。 <br />在這兩種情況下，這都不表示具有此狀態的修補程式*需要*重新啟動，只表示自安裝修補程式以來尚未重新啟動節點。 | 不合規 | 
| **`MISSING`** | 修補程式在基準中已核准，但未安裝在受管節點。如果您設定 `AWS-RunPatchBaseline` 文件任務掃描 (而不是安裝)，系統會為在掃描期間找到，但尚未安裝的修補程式報告此狀態。 | 不合規 | 
| **`FAILED`** | 修補程式在基準中已核准，但無法安裝在執行個體。若要排除這種情況，請檢視命令輸出的資訊，或許能幫助您了解問題。 | 不合規 | 
| **`NOT_APPLICABLE`**1 | *此合規狀態只會針對 Windows Server 作業系統報告。*<br />修補程式在基準中已核准，但使用該修補程式的服務或功能尚未安裝在受管節點上。例如，若已在基準中核准，但尚未在受管節點上安裝 Web 服務，則 Internet Information Services (IIS) 等 Web 伺服器服務的修補程式會顯示 `NOT_APPLICABLE`。如果修補程式已由後續更新所取代，也可能標示為 `NOT_APPLICABLE`。這表示已安裝較新的更新，不再需要 `NOT_APPLICABLE` 更新。 | 不適用 | 
| AVAILABLE\_SECURITY\_UPDATES | *此合規狀態只會針對 Windows Server 作業系統報告。*<br />未經修補基準核准的可用安全性更新修補程式可以具有 `Compliant` 或 `Non-Compliant` 的合規值，如自訂修補基準中所定義。<br />在建立或更新修補基準時，您可以選擇要指派給可用但未經核准的安全修補程式的狀態，因為這些修補程式不符合修補基準中指定的安裝條件。例如，如果您已指定在修補程式發布後、安裝前需要等待很長的時間，則可以略過您可能想要安裝的安全修補程式。如果在指定的等待期間發布了修補程式更新，安裝修補程式的等待期間會重新開始。如果等待期間過長，可以發布多個版本的修補程式，但絕不會安裝。<br />對於修補程式摘要計數，當修補程式報告為 `AvailableSecurityUpdate` 時，它一律會包含在 `AvailableSecurityUpdateCount` 中。如果基準設定為將這些修補程式報告為 `NonCompliant`，它們也會包含在 `SecurityNonCompliantCount` 中。如果基準設定為將這些修補程式報告為 `Compliant`，則它們不會包含在 `SecurityNonCompliantCount` 中。這些修補程式一律會以未指定的嚴重性進行報告，絕不會包含在 `CriticalNonCompliantCount` 中。 | 合規或不合規，取決於為可用安全性更新選取的選項。 您可以使用主控台建立或更新修補基準，在**可用安全性更新合規狀態**欄位中指定此選項。使用 AWS CLI 執行 [create-patch-baseline](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html)或 [update-patch-baseline](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html)命令，您可以在 `available-security-updates-compliance-status` 參數中指定此選項。  | 

¹ 對於具有 `INSTALLED_OTHER` 與 `NOT_APPLICABLE` 狀態的修補程式，Patch Manager 根據 [describe-instance-patches](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) 命令忽略了查詢結果中的一些資料，例如 `Classification` 和 `Severity` 的值。這是為了協助防止超過庫存中個別節點的資料限制。若要檢視所有修補程式的詳細資訊，您可以使用 [describe-available-patches](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 命令。