本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
關於預先定義和自訂的修補基準
Patch Manager的功能,為支援的 AWS Systems Manager每個作業系統提供預先定義的修補程式基準Patch Manager。您可以依照目前設定的方式使用這些基準 (您無法自訂),也可以建立自己的自訂修補基準。自訂修補基準可讓您進一步控制為您的環境核准或拒絕哪些修補程式。此外,預先定義的基準會將 Unspecified
的合規層級指派給使用這些基準安裝的所有修補程式。針對要指派的合規值,您可以建立預先定義基準的複本,並指定要指派給修補程式的合規值。如需詳細資訊,請參閱 關於自訂基準 及 使用自訂修補基準。
注意
無論您使用哪種方法或組態類型進行修補操作,此主題中的資訊都適用:
-
在 Quick Setup 中設定的修補程式政策
-
在 Quick Setup 中設定的主機管理選項
-
用來執行修補程式
Scan
或Install
任務的維護時段 -
隨需 Patch now (立即修補) 操作
關於預先定義基準
下表說明 Patch Manager 提供的預先定義修補基準。
如需有關 Patch Manager 支援各作業系統的哪些版本的詳細資訊,請參閱 Patch Manager 先決條件。
名稱 | 支援的作業系統 | 詳細資訊 |
---|---|---|
|
AlmaLinux |
核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後,修補程式將自動核准。¹ |
|
Amazon Linux 1 |
核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時自動核准所有被歸類為「Bugfix」的修補程式。在發行或更新 7 天後,修補程式將自動核准。¹ |
AWS-AmazonLinux2DefaultPatchBaseline |
Amazon Linux 2 | 核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准所有被歸類為「Bugfix」的修補程式。在發行後 7 日,修補程式將自動核准。¹ |
AWS-AmazonLinux2022DefaultPatchBaseline |
Amazon Linux 2022 |
核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。在發佈後七日,修補程式將自動核准。同時在修補程式發布七天之後,核准被歸類「Bugfix」的所有修補程式。 |
AWS-AmazonLinux2023DefaultPatchBaseline |
Amazon Linux 2023 |
核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。在發佈後七日,修補程式將自動核准。同時在修補程式發布七天之後,核准被歸類「Bugfix」的所有修補程式。 |
AWS-CentOSDefaultPatchBaseline |
CentOS 和 CentOS Stream | 在更新可用 7 天之後核准所有更新,包括非安全性更新。 |
AWS-DebianDefaultPatchBaseline |
Debian Server | 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。 |
AWS-MacOSDefaultPatchBaseline |
macOS | 核准所有被歸類為「安全」的作業系統修補程式。同時核准包含目前更新的所有套件。 |
AWS-OracleLinuxDefaultPatchBaseline |
Oracle Linux | 核准所有被歸類為「安全性」以及嚴重性等級為「重要」或「中等」的作業系統修補程式。同時在修補程式發行 7 天之後,核准被歸類為 "Bugfix" 的所有修補程式。在發行或更新 7 天後,修補程式將自動核准。¹ |
AWS-DefaultRaspbianPatchBaseline |
Raspberry Pi OS | 立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。 |
|
Red Hat Enterprise Linux (RHEL) |
核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後,修補程式將自動核准。¹ |
|
Rocky Linux |
核准所有被歸類為「安全性」以及嚴重性等級為「關鍵」或「重要」的作業系統修補程式。同時核准被歸類為「Bugfix」的所有修補程式。在發行或更新 7 天後,修補程式將自動核准。¹ |
AWS-SuseDefaultPatchBaseline |
SUSE Linux Enterprise Server (SLES) | 核准所有在被歸類為「安全性」以及嚴重性為「關鍵」或「重要」的作業系統修補程式。在發行或更新 7 天後,修補程式將自動核准。¹ |
|
Ubuntu Server |
立即核准所有作業系統安全性相關且優先順序為「必要」、「重要」、「標準」、「選用」或「Extra」的修補程式。立刻核准是因為儲存庫未提供可靠的發行日期。 |
AWS-DefaultPatchBaseline |
Windows Server |
核准分類為 "" 或 CriticalUpdates ",且 MSRC 嚴重性為「嚴重SecurityUpdates」或「重要」的所有Windows Server作業系統修補程式。在發佈或更新 7 天後,修補程式將自動核准。² |
AWS-WindowsPredefinedPatchBaseline-OS |
Windows Server |
核准分類為 "" 或 CriticalUpdates ",且 MSRC 嚴重性為「嚴重SecurityUpdates」或「重要」的所有Windows Server作業系統修補程式。在發佈或更新 7 天後,修補程式將自動核准。² |
AWS-WindowsPredefinedPatchBaseline-OS-Applications |
Windows Server | 對於Windows Server作業系統,核准分類為 "" 或 CriticalUpdates SecurityUpdates ",且 MSRC 嚴重性為「嚴重」或「重要」的所有修補程式。對 Microsoft 發行的應用程式核准所有的修補程式。作業系統和應用程式的修補程式會在發佈或更新 7 天後自動核准。² |
¹ 對於 Amazon Linux 1 和 Amazon Linux 2,修補程序自動批准前的 7 天等待時間是根據中的值計算updateinfo.xml
,而不是根據Updated Date
值計算。Release Date
各種因素會影響 Updated Date
值。其他作業系統會以不同的方式處理發行和更新日期。如需詳細資訊來協助您避免因自動核准延遲而導致非預期結果,請參閱套件發行日期和更新日期的計算方式。
² 對於 Windows Server,預設基準包括 7 天自動核准延遲。若要在發佈後 7 天內安裝修補程式,必須建立自訂基準。
關於自訂基準
如果您建立自己的修補基準,您可以使用以下類別來選擇自動核准哪些修補程式。
-
作業系統:Windows Server、Amazon Linux、Ubuntu Server 等。
-
產品名稱 (作業系統):例如,RHEL 6.5、Amazon Linux 2014.09、Windows Server 2012、Windows Server 2012 R2 等。
-
產品名稱(Windows Server僅適用於 Microsoft 發布的應用程序):例如,Word 2016, BizTalk 服務器等。
-
分類:例如,重要更新、安全性更新等。
-
嚴重性:例如關鍵、重要等。
對於您建立的每個核准規則,您可以選擇指定自動核准延遲,或指定修補程式核准截止日期。
注意
因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期,此作業系統不支援自動核准選項。
自動核准延遲是修補程式發行或最後更新之後,在自動核准修補程式進行修補之前的等待天數。例如,如果您使用 CriticalUpdates
分類來建立規則,並將自動核准延遲設定為 7 天,則 7 月 7 日發行的新的關鍵修補程式將在 7 月 14 日自動核准。
注意
如果 Linux 儲存庫沒有提供套件的發行日期資訊,Systems Manager 會使用套件的建置時間作為 Amazon Linux 1、Amazon Linux 2 和 CentOS 的自動核准延遲。RHEL如果系統無法找到套件的建置時間,Systems Manager 會將自動核准延遲值視為 0。
當您指定自動核准截止日期時,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 發行的支援應用程式。 -
對於內部部署伺服器和虛擬機器 (VM),Patch Manager 會嘗試使用您的自訂預設修補基準。如果不存在自訂預設修補基準,系統將使用為對應作業系統預先定義的修補基準。
-
如果修補程式已在相同的修補基準中同時列為核准與拒絕,修補程式將遭到拒絕。
-
一個受管節點只能有一個為其定義的修補基準。
-
可新增至修補基準之核准與拒絕修補程式清單的套件名稱格式,取決於您要修補之作業系統的類型。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊,請參閱 關於核准與拒絕修補程式清單的套件名稱格式。
如果您在 Quick Setup 中使用修補程式政策組態,則您對自訂修補基準所做的更新會每小時與 Quick Setup 同步一次。
如果刪除修補程式政策中參照的自訂修補基準,則修補程式政策的 Quick Setup Configuration details (組態詳細資訊) 頁面上會顯示橫幅。此橫幅會通知您修補程式政策參照修補基準不再存在,而後續的修補操作將會失敗。在此情況下,請返回到 Quick Setup Configurations (組態) 頁面,選取 Patch Manager 組態,然後選擇 Actions (動作)、Edit configuration (編輯組態)。刪除的修補基準名稱會反白顯示,您必須為受影響的作業系統選取新的修補基準。
如需有關建立修補基準的詳細資訊,請參閱使用自訂修補基準與教學課程:修補伺服器環境 (AWS CLI)。