本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 了解 AMS Accelerate 中的修補程式管理 **重要** 加速修補程式報告會定期部署以 AWS Glue 資源為基礎的政策。請注意，修補系統的 AMS 更新會覆寫現有的 AWS Glue 資源型政策。 **重要** 您可以為受管節點指定替代修補程式儲存庫。當 AMS 實作您請求的修補程式組態時，您需負責選取和驗證所選儲存庫的安全性。您也必須接受使用這些儲存庫的任何風險，例如供應鏈風險。 以下是修補程式管理程序安全的最佳實務： 僅使用受信任且經過驗證的儲存庫來源 盡可能預設為標準作業系統廠商儲存庫 定期稽核自訂儲存庫組態 您可以使用 AMS Accelerate 修補系統修補程式附加元件，透過安全相關和其他類型的更新來修補您的執行個體。Accelerate Patch Add-On 是一項功能，可為 AMS 執行個體提供標籤型修補。它利用 AWS Systems Manager (SSM) 功能，因此您可以標記執行個體，並使用您設定的基準和視窗修補這些執行個體。AMS Accelerate Patch 附加元件是一種加入選項，如果您在加入 Accelerate 帳戶期間未取得，請聯絡您的雲端服務交付經理 (CSDM) 以取得。 AMS Accelerate 修補程式管理使用 Systems Manager 修補程式基準功能來控制套用至執行個體的修補程式定義。修補程式基準包含預先核准的修補程式清單；例如，所有安全修補程式。根據與其相關聯的修補程式基準來衡量執行個體的合規性。AMS Accelerate 預設會安裝所有可用的修補程式，讓執行個體保持最新狀態。 **注意** AMS Accelerate 僅適用於作業系統 (OS) 修補程式。例如，對於 Windows，只會套用 Windows 更新，而非 Microsoft 更新。 如需報告的資訊，請參閱 [AMS 主機管理報告](ams-host-man.md)。 AMS Accelerate 提供各種營運服務，協助您實現卓越營運 AWS。若要快速了解 AMS 如何 AWS 雲端 透過我們的一些關鍵營運功能，包括全年無休服務台、主動監控、安全性、修補、記錄和備份，協助您的團隊在 中實現整體卓越營運，請參閱 [ AMS 參考架構圖表](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/AWS-managed-services-for-operational-excellence-ra.pdf)。 **Topics** + [ ## 修補建議 ](#acc-patching-recos) + [ # 在 AMS 中建立修補程式維護時段 ](acc-p-maint-window.md) + [ # 具有勾點的修補程式 ](acc-p-hooks.md) + [ # AMS Accelerate 修補程式基準 ](acc-patch-baseline.md) + [ # 建立 IAM 角色以隨需修補 AMS Accelerate ](acc-p-user-access.md) + [ # 了解 AMS Accelerate 中的修補程式通知和修補程式失敗 ](acc-patch-mon-remediate.md) ## 修補建議 如果您參與應用程式或基礎設施操作，您會了解作業系統 (OS) 修補解決方案的重要性，其彈性和可擴展性足以滿足您的應用程式團隊的各種需求。在典型組織中，某些應用程式團隊使用涉及不可變執行個體的架構，而其他則將其應用程式部署在可變執行個體上。 如需修補 AWS 規範指引的詳細資訊，請參閱[使用 的混合雲端中可變執行個體的自動修補 AWS Systems Manager](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)。 **注意** Accelerate Patch Add-On 是一項功能，可為 AMS 執行個體提供標籤型修補。它利用 AWS Systems Manager (SSM) 功能，因此您可以標記執行個體，並使用您設定的基準和視窗修補這些執行個體。AMS Accelerate Patch 附加元件是一種加入選項，如果您在加入 Accelerate 帳戶期間未取得，請聯絡您的雲端服務交付經理 (CSDM) 以取得。 ### 修補程式責任建議 持久性執行個體的修補程序應涉及下列團隊和動作： + **應用程式 (DevOps) 團隊**會根據應用程式環境、作業系統類型或其他條件，為其伺服器定義修補程式群組。它們也會定義每個修補程式群組特定的維護時段。此資訊應存放在連接到執行個體的標籤上。建議的標籤名稱為「修補程式群組」和「維護時段」。在每個修補週期期間，應用程式團隊會準備修補、在修補後測試應用程式，以及在修補期間疑難排解其應用程式和作業系統的任何問題。 + **安全操作團隊**會定義應用程式團隊使用的各種作業系統類型的修補程式基準，並透過 Systems Manager Patch Manager 提供修補程式。 + **自動化修補解決方案**會定期執行，並根據使用者定義的修補程式群組和維護時段，部署修補程式基準中定義的修補程式。 + **控管和合規團隊會**定義修補準則和例外狀況程序與機制。 如需詳細資訊，請參閱[針對可變 EC2 執行個體的修補解決方案設計](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/design-standard.html)。 ### 應用程式團隊的指引 + 檢閱並熟悉建立和管理維護時段；請參閱[AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)和[建立 SSM 維護時段以進行修補](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-patching.html#acc-p-maint-window)以進一步了解。了解一般結構和維護時段的使用可協助您了解，如果您不是建立資訊的人員，應提供哪些資訊。 + 對於高可用性 (HA) 設定，計劃在每個可用區域和每個環境 (Dev/Test/Prod) 有一個維護時段。這可確保修補期間的持續可用性。 + 建議的維護時段持續時間為 4 小時，間隔 1 小時，加上每 50 個執行個體額外 1 小時 + 具有足夠時間的修補程式開發和測試版本，可讓您在生產修補之前識別任何潛在問題。 + 透過 SSM 自動化自動化常見的修補前和修補後任務，並將其做為維護時段任務執行。請注意，對於修補後任務，您必須確保配置足夠的時間，因為一旦達到截止值，任務就不會啟動。 + 熟悉修補程式基準及其功能 - 特別是修補程式嚴重性類型的自動核准延遲，這些嚴重性類型可用於確保只有在開發/測試中套用的修補程式才能在日後的生產中套用。如需詳細資訊，請參閱[關於修補程式基準](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html)。 ### 安全營運團隊的指引 + 檢閱並熟悉修補程式基準。修補程式核准會以自動化方式處理，並具有不同的規則選項。如需詳細資訊，請參閱[關於修補程式基準](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html)。 + 與應用程式團隊討論修補 Dev/Test/Prod 的需求，並開發多個基準以滿足這些需求。 ### 控管和合規團隊的指引 + 修補應該是「選擇退出」函數。預設維護時段和自動標記應該存在，以確保沒有未修補的內容。AMS Resource Tagger 可以提供這項協助；請與您的雲端架構師 (CA) 或雲端服務交付管理員 (CSDM) 討論此選項，以取得實作指引。 + 請求豁免修補應該需要文件證明豁免。資訊安全長 (CISO) 或其他核准主管應核准或拒絕請求。 + 修補合規應透過修補程式管理員主控台、Security Hub 或漏洞掃描器定期審查。 ### 高可用性 Windows 應用程式的範例設計 ![\[Patch Tuesday schedule showing development, test, and production environments with baseline approval timelines.\]](http://docs.aws.amazon.com/zh_tw/managedservices/latest/accelerate-guide/images/acc-maint-window.png) **概觀：** + 每個可用區域一個維護時段。 + 每個環境一組維護時段。 + 每個環境一個修補程式基準： + 開發：核准 0 天後的所有嚴重性和分類。 + 測試：在 0 天後核准關鍵安全性更新修補程式，並在 7 天後核准所有其他嚴重性和分類。 + 生產：在 0 天後核准關鍵安全性更新修補程式，並在 14 天後核准所有其他嚴重性和分類。 **CloudFormation 指令碼：** 這些指令碼的設定是使用上述基準核准設定，為兩個可用區域 Windows HA EC2 應用程式建置維護時段、基準和修補任務。 + Windows 開發 CFN 堆疊範例：[HA-Patching-Dev-Stack.json](samples/HA-Patching-Dev-Stack.zip) + Windows 測試 CFN 堆疊範例：[HA-Patching-Test-Stack.json](samples/HA-Patching-Test-Stack.zip) + Windows 產品 CFN 堆疊範例：[HA-Patching-Prod-Stack.json](samples/HA-Patching-Prod-Stack.zip) ### 修補程式建議FAQs 問：如何處理「0」日攻擊的未排程修補？ 答：SSM 支援**立即修補**功能，該功能使用執行個體作業系統的目前預設基準。AMS 部署一組預設的修補程式基準，在 0 天後核准所有修補程式。不過，使用**立即修補**功能時，不會擷取預先修補快照，因為此命令會執行 AWS-RunPatchBaseline SSM 文件。我們建議您在修補之前手動備份。 問：AMS 是否支援自動擴展群組 (ASGs) 中執行個體的修補？ 答：否。加速客戶目前不支援 ASG 修補。 問：維護 Windows 是否有任何需要記住的限制？ 答：是，您應該注意一些限制。 + 每個帳戶的維護時段：50 + 每個維護時段的任務數：20 + 每個維護時段的並行自動化數目上限：20 + 並行維護時段數目上限：5 如需預設 SSM 限制的完整清單，請參閱[AWS Systems Manager 端點和配額](https://docs.aws.amazon.com/general/latest/gr/ssm.html)。 # 在 AMS 中建立修補程式維護時段 修補程式維護時段會根據目標 Amazon EC2 執行個體的設定排程執行 AMS 修補程式自動化。目標由一組執行個體的標籤或標籤定義。您可以根據修補程式星期二前後的日期和時間來設定排程，也可以使用 *Cron 表達*式定義排程。如需詳細資訊，請參閱*AWS Systems Manager 《 使用者指南*》中的[參考：Systems Manager 的 Cron 和 Rate 表達](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html)式。在修補之前，AMS 會建立每個執行個體根磁碟區的快照。如果 AMS 偵測到修補會影響執行個體的運作狀態，或者如果您通知 AMS 修補的應用程式影響，則 AMS 會使用此快照將根磁碟區還原為預先修補狀態。 ## AMS Accelerate 修補程式維護時段限制 AMS 修補 use AWS Systems Manager (Systems Manager)。除了 Systems Manager 服務限制之外，AMS 修補在每個修補程式維護時段都有 300 個目標執行個體的限制。假設每個執行個體的一般修補程式完成時間為 30 分鐘，下表提供維護時段和持續時間數量的範例。 | 要修補的執行個體 | 維護時段持續時間 （小時） | 需要並行維護時段 | | --- | --- | --- | | 100 | 1 | 1 | | 200 | 1 | 1 | | 300 | 2 | 1 | | 600 | 3 | 2 | | 800 | 4 | 3 | | 1200 | 6 | 4 | | 1500 | 8 | 5 | **重要** 這些範例假設沒有其他 Systems Manager 維護時段處於作用中狀態，也沒有其他自動化正在執行。 如需限制的詳細資訊，請參閱[AWS Systems Manager 端點和配額](https://docs.aws.amazon.com/general/latest/gr/ssm.html)。 **Topics** + [ ## AMS Accelerate 修補程式維護時段限制 ](#acc-p-maint-limit) + [ # 從 AMS 主控台建立週期性「修補程式」維護時段 （建議） ](acc-p-maint-window-ams-console.md) + [ # 使用 CloudFormation for AMS Accelerate 建立修補程式維護時段 ](acc-p-maint-window-cfn.md) + [ # 從適用於 AMS Accelerate 的 Systems Manager 主控台建立維護時段 ](acc-p-maint-window-console.md) + [ # 使用適用於 AMS Accelerate 的 Systems Manager 命令列界面 (CLI) 建立維護時段 ](acc-p-maint-window-cli.md) # 從 AMS 主控台建立週期性「修補程式」維護時段 （建議） Microsoft 會在每個月的第二個星期二為其作業系統發行修補程式，也稱為修補程式星期二。相對於修補程式星期二，排程 Windows 和 Linux 執行個體的修補很常見。若要排定修補程式週二後第一個或第二個週末的週期性修補程式維護時段，請造訪 AMS 主控台並遵循下列步驟： 1. 為您的修補程式維護時段提供名稱。 1. 【選用】 提供修補程式維護時段的描述。 1. 選取相對於修補程式星期二的日期。 1. 輸入修補程式維護時段以 hh：mm 開始的時間。例如，午夜是 **00：00**，11pm 是 **23：00**。然後選取時區。 1. 【選用】 變更持續時間以符合您的需求。AMS 建議最短持續時間為四小時。 1. 輸入目標的修補程式標籤索引鍵和值。如需詳細資訊，請參閱[什麼是標籤？](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-tag-intro.html#acc-tag-what-is)。 1. 【選用】 展開選用參數以調整並行、錯誤率和維護時段截止。 1. 並行控制同時修補的目標執行個體數量。例如，10 個目標執行個體的 50% 並行不會一次修補超過 5 個執行個體，而 100% 並行會一次修補全部 10 個執行個體。 1. 錯誤率可在修補暫停之前控制錯誤的容錯能力。例如，10 個目標執行個體的 100% 錯誤率會修補所有執行個體，無論失敗多少，而 50% 錯誤率會在 5 個執行個體無法修補時暫停修補。AMS 建議 100% 錯誤率。 1. 修補程式維護時段截止點可在修補程式維護時段結束前的指定小時暫停開始新的修補活動，以防止違反修補程式維護時段。例如，截止 1 小時 （建議）， 會在修補程式維護時段結束前 1 小時停止新的修補程式活動。 **重要** 驗證下一次執行時間。 請造訪 [SSM 維護時段主控台](https://console.aws.amazon.com/systems-manager/maintenance-windows) ，搜尋新建立的修補程式維護時段，並驗證下一次執行時間。如果您有任何問題或需要編輯修補程式維護時段，請建立服務請求以與 AMS 修補程式專家交談 若要使用 CloudFormation 排程 CRON 型修補程式維護時段，請參閱 [使用 CloudFormation for AMS Accelerate 建立修補程式維護時段](acc-p-maint-window-cfn.md)。 # 使用 CloudFormation for AMS Accelerate 建立修補程式維護時段 若要使用 建立 AMS Accelerate 修補程式維護時段 AWS CloudFormation，請先登入您的 Accelerate 帳戶，然後選取 AWS 區域 目標執行個體所在的 。然後遵循 https：//[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) 上的下列步驟： 1. 選取兩個自訂加速修補 CloudFormation 範本的其中一個。 + 修補程式星期二排程：Microsoft 會在每個月的第二個星期二發佈其作業系統的修補程式，也稱為修補程式星期二，以在修補程式星期二之後的第一個或第二個週末排程修補程式維護時段：登入加速主控台後，請使用此連結 [ PatchTuesdayScheduling CloudFormation 範本](https://console.aws.amazon.com/cloudformation/home?#/stacks/create/parameters?templateURL=https://ams-patch-templates-us-east-1.s3.amazonaws.com/AmsPatchMaintenanceWindowTemplatePatchTuesdayScheduling.yml) 。 + CRON 排程：若要使用 CRON 建立修補程式維護時段來定義開始日期，請使用此連結 [ CRONScheduling CloudFormation 範本](https://console.aws.amazon.com/cloudformation/home?#/stacks/create/parameters?templateURL=https://ams-patch-templates-us-east-1.s3.amazonaws.com/AmsPatchMaintenanceWindowTemplateCronScheduling.yml)。請記住，Systems Manager CRON 編號天數為 1-7 天 （如需 Systems Manager CRON 的詳細資訊，請參閱 Systems [Manager 的參考：Cron 和 Rate 運算式](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html))。 選擇其中一個連結會導致範本自動載入 CloudFormation 主控台。然後按一下 **Next (下一步)**。 1. 在**指定堆疊詳細資訊**頁面上 （建立堆疊頁面的步驟 2)，輸入堆疊名稱和範本參數 （顯示的預設參數是 AMS 建議的預設值，為您的使用案例選取日期和時間）。完成後，請按一下**下一步**。 1. 設定堆疊選項 （選用）。如需選項的資訊，請參閱[設定 AWS CloudFormation 堆疊選項](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html)。完成後，請按一下**下一步**。 1. 檢閱堆疊值 （選用）。如需檢閱堆疊詳細資訊以估算成本的資訊，請參閱[檢閱堆疊和估算堆疊成本](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-review.html)。準備就緒時，請按一下**建立堆疊**。 堆疊最多可能需要一分鐘的時間才能建立。成功建立堆疊後，您的修補程式維護時段會在指定的時間執行。您可以透過建立和執行 CloudFormation 變更集 （建議） （如需執行此操作的詳細資訊，請參閱[使用變更集建立堆疊](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stacks-changesets.html)) 或更新 Systems Manager 維護時段主控台 () 上的修補程式維護時段，來變更修補程式**維護時段**[https://console.aws.amazon.com/systems-manager/maintenance-windows](https://console.aws.amazon.com/systems-manager/maintenance-windows)。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/6fSfFeFn6Vc/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/6fSfFeFn6Vc) # 從適用於 AMS Accelerate 的 Systems Manager 主控台建立維護時段 若要從 Systems Manager 主控台建立 AMS Accelerate 維護時段，請遵循下列步驟： 1. 在**變更管理**區域的左側導覽列中，按一下**維護時段**，然後按一下畫面右上角的**建立維護時段**。填寫表單。如需任何選項的詳細資訊，請參閱[建立維護時段 （主控台）](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-create-mw.html)。完成後，請按一下**建立維護時段**。 維護時段清單頁面隨即開啟。 1. 選取新建立的維護時段。 維護時段詳細資訊頁面隨即開啟。 1. 前往**目標**索引標籤，然後選擇**註冊目標**。 **註冊目標**頁面隨即開啟。 1. 新增您的加速目標。如需目標的資訊，請參閱[將目標指派給維護時段 （主控台）](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-assign-targets.html)。完成後，請按一下**註冊目標**。記下您稍後需要的目標。 維護時段詳細資訊頁面會在**目標**索引標籤上重新開啟，其中包含包含新目標的清單。 1. 在維護時段詳細資訊頁面的任務****索引標籤上，選擇**註冊任務**，然後從下拉式清單中選擇**註冊自動化任務**。填寫表單。加速備註： + 提供有意義的任務名稱。例如：AcceleratePatch。 + 在**自動化文件**區域中按一下搜尋方塊中，選擇**擁有者**，然後選擇**共用文件**。 + 在搜尋方塊中按一下並選擇**文件名稱字首** --> ** 等於**，然後輸入：**AWSManagedServices-PatchInstance**，以選取自動化文件。然後選取其選項按鈕，以選取 **AWSManagedServices-PatchInstance** 文件。 + 在文件版本下，選擇**執行時間的預設版本**。 + 在**目標**區段中： + 將**目標設定為：****選取已註冊的目標群組**。 + 在目標清單中，選取您在目標索引標籤中註冊**的目標**。 + 在**輸入參數**區段中，填寫表單。 + **InstanceId**： `{{TARGET_ID}}` + **StartInactiveInstances**：在修補程式維護時段期間停止執行個體時`True`啟動執行個體。 **注意** **InstanceId** 參數值區分大小寫，且 **StartInactiveInstances** 參數值可以是 True 或 False。 當標籤鎖定目標時，無法啟動已停止的執行個體。如需詳細資訊，請參閱[無要執行的調用](https://aws.amazon.com/premiumsupport/knowledge-center/ssm-no-invocations-automation)。 + 在**速率控制**區段中，選擇百分比。AMS Accelerate 建議 **100%** 用於**並行**，**100%** 用於**錯誤閾值**，以嘗試同時修補所有執行個體，無論自動化錯誤為何。例如，如果您希望一次修補一半的目標，讓一半的目標執行個體保持在負載平衡執行後，請將**並行**設定為 50%。 + 在 **IAM 服務角色**區段中，選擇**使用自訂服務角色**，然後選擇 **ams\$1ssm\$1automation\$1role**。 按一下**註冊自動化任務**。 修補維護時段已建立。在**描述**索引標籤下，您可以看到**下一次執行時間**。 # 使用適用於 AMS Accelerate 的 Systems Manager 命令列界面 (CLI) 建立維護時段 若要使用命令列界面建立 AMS Accelerate 維護時段： 1. 遵循 SSM [ 教學課程：建立和設定維護時段 (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/maintenance-windows-cli-tutorials-create.html)。對於教學課程的每個步驟，以下是用於修補的範例 CLI 命令。 **注意** 這些範例專屬於 Linux 或 macOS。命令也可以從中執行 AWS CloudShell ，其可能比`awscli`在本機電腦上設定更簡單。如需詳細資訊，請參閱[使用 AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/working-with-cloudshell.html) 。 1. 在教學課程的步驟 1 中，若要建立維護時段： ``` aws ssm create-maintenance-window \ --name Sample-Maintenance-Window \ --schedule "cron(0 30 23 ? * TUE#2 *)" \ --duration 4 \ --cutoff 1 \ --allow-unassociated-targets \ --tags "Key=Environment,Value=Production" ``` 成功完成時，`window-id`會傳回 。 1. 在教學課程的步驟 2 中，註冊目標節點： ``` aws ssm register-target-with-maintenance-window \ --window-id "mw-xxxxxxxxx" \ --resource-type "INSTANCE" \ --target "Key=tag:Environment,Values=Prod" ``` 成功完成時，會傳回 `WindowTargetID`。 1. 在教學課程的步驟 3 中，註冊任務： ``` aws ssm register-task-with-maintenance-window \ --window-id "mw-xxxxxx" \ --targets "Key=WindowTargetIds,Values=63d4f63c-xxxxxx-9b1d-xxxxxfff" \ --task-arn "AWSManagedServices-PatchInstance" \ --service-role-arn "arn:aws:iam::AWS-Account-ID:role/ams_ssm_automation_role" \ --task-invocation-parameters "{\"Automation\":{\"DocumentVersion\":\"\$DEFAULT\",\"Parameters\":{\"InstanceId\":[\"{{TARGET_ID}}\"],\"StartInactiveInstances\":[\"True\"]}}}" \ --max-concurrency 50 \ --max-errors 50 \ --name "AutomationExample" \ --description "Sample Description" \ --task-type=AUTOMATION ``` # 具有勾點的修補程式 您可以使用 AMS 修補程式掛鉤，將 AMS 修補設定為在修補前後執行作業系統 (OS) 層級命令。使用 AMS 修補程式掛鉤在修補之前執行 SSM 命令文件來停止服務，然後在修補之後啟動服務，或在修補之後執行命令來確認您的應用程式運作狀態良好。 若要使用 AMS 修補程式掛鉤，您需要執行下列動作： 1. 建立 SSM 命令文件以用作修補程式掛鉤。 1. 建立 AMS 修補程式維護時段，或使用現有的 AMS 修補程式維護時段。如需詳細資訊，請參閱 [AMS 修補程式維護時段](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-p-maint-window.html)。 1. 設定 AMS 修補程式維護時段，以將 SSM 命令文件用於 AMS 修補程式掛鉤。 ## AMS 修補程式掛鉤 RACI 負責、負責、諮詢和告知 或 RACI，矩陣會將主要責任指派給客戶或 AMS 以進行各種活動。下表提供使用 AMS 修補程式勾點之應用程式中活動的客戶和 AMS 責任概觀。 + R 代表負責方執行工作以達成任務 + 代表責任方 + C 代表已諮詢的對象；尋求意見的對象，通常是主題專家；以及與之進行雙邊溝通的對象 + 我代表知情；收到進度通知的一方，通常只在完成任務或可交付項目時 | 活動 | 客戶 | AMS | | --- | --- | --- | | 建立修補前/後 SSM 命令文件和文件內容 | R | C | | 設定 AMS 修補的修補程式掛鉤參數 | R | C | | 執行前/後修補程式 SSM 命令文件 | I | R | | 分類和回應修補程式掛接失敗 | I | R | | 通知客戶修補程式掛接失敗 | I | R | | 如果客戶要求，則轉返至預先修補狀態 | C | R | ## 建立修補程式掛鉤的 SSM 文件 AMS 修補程式掛鉤會在修補期間使用 Amazon EC2 Systems Manager (SSM) 文件。建立 SSM 命令文件，或與發生修補的帳戶共用現有的 SSM 命令文件。如需 SSM 文件的資訊，包括限制，請參閱[共用 SSM 文件](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-ssm-sharing.html)。 若要建立 SSM 命令文件，請遵循下列步驟： 1. 建立[文件**類型 = "Command" 的 SSM 文件**](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-ssm-console.html)。 1. 在 ****內容 （內容） 區段中輸入您的命令。如需詳細資訊，請參閱[建立 SSM 文件內容](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-creating-content.html)。 **注意** AMS 修補程式掛鉤的 SSM 文件也可以使用 AWS CLI 或 建立 CloudFormation。如果您需要為 AMS 修補程式掛鉤建立 SSM 文件的協助，請聯絡您的 Cloud Architect。 ## 設定 AMS 修補程式維護時段，以使用您的 SSM 命令文件做為 AMS 修補程式掛鉤 AMS 修補程式維護時段是 Systems Manager 維護時段，可執行您設定的 AMS 修補程式自動化。 若要編輯 AMS 修補程式維護時段以使用修補程式掛鉤，請遵循下列步驟： 1. 在 [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 左側導覽窗格的變更**管理工具**下，選取**維護時段**。 隨即開啟列出現有維護時段的頁面。 1. 選取以 **mw-** 開頭的視窗 ID。 該維護時段的詳細資訊頁面隨即開啟。 1. 選取**任務**索引標籤和具有 **AMS-PatchInstance** 任務 ARN 的視窗任務 ID，然後按一下**編輯**。 ![\[AWS Systems Manager maintenance window tasks interface showing three AWSManagedServices-PatchInstance tasks.\]](http://docs.aws.amazon.com/zh_tw/managedservices/latest/accelerate-guide/images/mwindow-detail-edit-border.png) 1. 向下捲動至**參數**區段，並更新下列參數。 AMS 修補程式掛鉤參數： + **PrePatchHook**：您要在修補之前執行的類型為 "Command" 的 SSM 文件名稱。如果您在修補之前未執行命令，請保留此空白或輸入「AWS-Noop」（區分大小寫）。 + **PostPatchHook**：您想要在修補後執行之類型為「命令」的 SSM 文件名稱。如果您在修補後未執行命令，請保留此空白或輸入「AWS-Noop」（區分大小寫）。 + **ExecutePatchBasedOnPreHookStatus**：根據 PrePatchHook 執行的成功或失敗執行修補，請選擇一項： + **OnPreHookSuccess**：只有在 PrePatchHook 成功時才執行 AMS 修補程式自動化。 + **一律**：在 PrePatchHook 成功且失敗時執行 AMS 修補程式自動化。 + **OnPreHookFailure** - 僅在 PrePatchHook 失敗時執行 AMS 修補程式自動化。 + **從**不：請勿執行 AMS 修補程式自動化。這在測試 PrePatchHook 時可能很有用。 + **ExecutePostHookBasedOnPatchStatus**：根據 AMS 修補程式自動化的成功或失敗執行修補程式後勾點，請選擇一項： + **OnPatchSuccess**：只有在 AMS 修補程式自動化成功執行時，才能執行 PostPatchHook。 + **一律**：在 AMS 修補程式自動化成功且失敗時執行 PostPatchHook。 + **OnPatchFailure** - 僅在 AMS 修補程式自動化失敗時執行 PostPatchHook。 **注意** 如果其中任何變數缺少文字方塊，請捲動至相同頁面上的**自動化文件**區段，然後選取不同的文件，然後重新選取原始文件，以修正此問題。這會重新整理輸入參數，讓您可以編輯它們。 # AMS Accelerate 修補程式基準 修補程式基線會定義在您的執行個體上核准安裝的修補程式。您可以逐一指定核准或拒絕修補程式。您也可以建立自動核准規則，以指定應自動核准某些類型的更新 (例如，關鍵的更新)。拒絕清單會覆寫規則與核准清單。 ## 預設修補程式基準 當您加入 AMS Accelerate 修補時，下列作業系統的預設修補基準會由 AMS Accelerate 預設修補基準覆寫。 + **Windows** + **Amazon Linux 1** + **Amazon Linux 2** + **CentOS** + **暫停** + **Rhel** + **Ubuntu** **重要** 預設修補程式基準由 AMS 管理。請勿編輯預設修補程式基準，因為您的變更可能會遺失。反之，請建立自訂修補程式基準。請參閱[使用 AMS Accelerate 自訂修補程式基準](acc-patch-baseline-custom.md) **注意** AMS Accelerate 修補程式基準定義為 **product = \$1**，表示所有修補程式都會套用至所有安全性和分類的執行個體。 # 使用 AMS Accelerate 自訂修補程式基準 若要搭配 AMS Accelerate 使用自訂修補程式基準，請先確定您有修補程式群組，然後建立自訂基準。 如需詳細資訊，請參閱下列資源： + [ 使用修補程式群組](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-group-tagging.html) + [ 建立自訂修補基準 (Windows)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-windows.html) + [ 建立自訂修補基準 (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html) + [ 更新或刪除自訂修補基準 （主控台）](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-baseline-update-or-delete.html) # 建立 IAM 角色以隨需修補 AMS Accelerate 在您的帳戶加入 AMS Accelerate 修補之後，AMS Accelerate 會部署受管政策 **amspatchmanagedpolicy**。此政策包含使用 AMS 自動化文件 進行隨需修補的必要許可`AWSManagedServices-PatchInstance`。若要使用此自動化文件，帳戶管理員會為使用者建立 IAM 角色。請遵循下列步驟： **使用 建立角色 AWS 管理主控台**： 1. 登入 AWS 管理主控台 並開啟 [IAM 主控台](https://console.aws.amazon.com/iam/)。 1. 在主控台的導覽窗格中，選擇**角色**，然後**建立角色**。 1. 選擇 **Anotherrole AWS 帳戶** 類型。 1. 對於**帳戶 ID**，輸入您要授予資源存取權 AWS 的帳戶 ID。 指定帳戶的管理員可以授予許可給該帳戶中的任何 IAM 使用者來擔任此角色。若要這樣做，管理員會將政策連接至使用者或群組，以授予**sts：AssumeRole**action 的許可。該政策必須指定角色的 Amazon Resource Name (ARN) 做為資源。請注意以下內容： + 如果您要從您未控制的 帳戶將許可授予使用者，而使用者將以程式設計方式擔任此角色，則 choose**Require external ID**。外部 ID 可以是您和第三方帳戶管理員之間商定的任何文字或數字。此選項會自動將條件新增至信任政策，讓使用者只有在請求包含 **correctsts：ExternalID** 時才能擔任角色。如需詳細資訊，請參閱[如何將 AWS 資源的存取權授予第三方時使用外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)。 + 如果您想要將角色限制為使用多重要素驗證 (MFA) 登入的使用者，請選擇**要求 MFA**。這會新增條件到角色的信任政策，以檢查 MFA 登入。想要擔任該角色的使用者必須從設定的 MFA 裝置使用臨時的一次性密碼登入。沒有 MFA 身分驗證的使用者無法擔任該角色。如需 MFA 的詳細資訊，請參閱[在 中使用多重要素驗證 (MFA) AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)。 1. 選擇**下一步：許可**。 IAM 包含帳戶中的政策清單。在**新增許可**下，在篩選方塊中輸入 **amspatchmanagedpolicy**，然後選取此許可政策的核取方塊。按一下 **Next (下一步)**。 1. 在**角色詳細資訊**下，輸入角色名稱，例如 PatchRole，為角色新增描述 （建議），也新增標籤以協助您識別此角色。角色名稱不區分大小寫，但在 中必須是唯一的 AWS 帳戶。完成後，按一下**建立角色**。 **注意** 角色名稱建立後就無法編輯。 # 了解 AMS Accelerate 中的修補程式通知和修補程式失敗 **重要** 從 2025 年 2 月 1 日開始，AMS 客戶將不再收到其受管帳戶中空修補程式維護 Windows 的通知。 ## 修補程式服務請求和電子郵件通知 AMS 會在下一個修補程式維護時段的四天前建立新的服務請求。例如，在名為 **App1 PROD** 的修補程式維護時段執行前四天，AMS 會為**帳戶 【帳戶 ID】 的 App1 Prod 建立名為四月修補程式維護時段**的服務請求。如果您需要調整排定的修補程式，請使用修補程式服務請求與 AMS 通訊，或略過即將發生的修補程式。建立服務請求時，系統會傳送一封電子郵件到您的修補程式通知地址，其中包含服務請求的連結。每次 AMS 更新服務請求時，您會收到額外的電子郵件。 **注意** AMS 會建立新的服務請求，即使修補程式維護時段是在排程執行前四天內建立的。 [修補程式維護時段必須處於「啟用」狀態](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-disable.html)，才能接收服務請求通知。 修補開始前一小時，AMS 會透過修補服務請求通知您。修補完成後，AMS 會使用修補程式管理員主控台的連結來更新修補程式服務請求。使用連結檢視修補程式維護時段鎖定之執行個體的修補程式合規。 **注意** 修補程式管理員主控台中的連結會顯示執行個體目前的合規。如果在 AMS 完成修補且您存取連結之間發行新的修補程式，修補程式管理員會將執行個體顯示為不合規。 ## 透過 CloudWatch Events 的修補程式通知 AMS 在修補程序期間會傳送 CloudWatch Events 三次，包括下列項目： + 修補程式維護時段執行前四天。 + 修補程式維護時段執行前一小時。 + 當修補程式維護時段完成時。 以下是修補程式維護時段預先通知事件結構描述： ``` { "version": "0", "id": "37004d81-458d-2cef-fe1c-8afa8af30406", "detail-type": "AMS Patch Window Execution State Change", "source": "aws.managedservices", "account": "145917996532", "time": "2021-05-20T02:00:00Z", "region": "us-east-1", "resources": [ "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaab" ], "detail": { "State": "PREEMPTIVE", "StartTime": "2021-05-24T02:00:00.000000", "WindowArn": "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "Results": "[{\"instanceId\": \"i-0000000aaaaaaaaaa\"}, {\"instanceId\": \"i-0000000aaaaaaaaab\"}]" } } ``` 下表說明修補程式維護時段預先通知事件結構描述： **修補程式通知詳細資訊** | 屬性名稱 | 描述 | 範例值 | | --- | --- | --- | | State | 修補維護時段的狀態 | PREEMPTIVE - 排定的修補時段即將開始 | | 狀態 | 修補維護時段的狀態 | 成功 - 所有執行個體都是修補且未失敗 失敗 – 至少有一個執行個體無法修補 | | StartTime | 修補維護時段的開始時間，採用 ISO 格式 | 2021-02-03T22：14：05.814308 | | WindowArn | 修補維護時段的唯一識別符 | arn：aws：ssm：us-east-1： 123456789012：maintenancewindow/mw-00000001235 | | 結果 | 修補程式視窗鎖定目標的執行個體清單 | InstanceId – 目標執行個體的執行個體 ID | 以下是修補程式維護時段結束事件結構描述： ``` {"version": "0", "id": "0f25add5-44a9-0702-d2bc-bd2102affefe", "detail-type": "AMS Patch Window Execution State Change", "source": "aws.managedservices", "account": "123456789012", "time": "2021-02-03T22:14:06Z", "region": "us-east-1", "resources": [ "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaab" ], "detail": {"State": "[COMPLETED]", "Status": "SUCCESS", "StartTime": "2021-02-03T22:12:00.814308", "EndTime": "2021-02-03T22:14:05.814309", "WindowArn": "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "WindowExecutionId": "e32088eb-c05f-4c63-b766-6866e163c818", "Results": "[{\"instanceId\": \"i-0000000aaaaaaaaaa\", \"status\": \"Success\", \"missing_critical_patch_count\": 0, \"missing_total_patch_count\": 0} }, {\"instanceId\": \"i-0000000aaaaaaaaab\", \"status\": Success}, \"missing_critical_patch_count\": 0, \"missing_total_patch_count\": 0}]" } } ``` 下表說明修補程式維護時段結束事件結構描述： **修補程式視窗結束詳細資訊** | 屬性名稱 | 描述 | 範例值 | | --- | --- | --- | | State | 修補維護時段的狀態 | 已完成 – 修補時段已完成 | | 狀態 | 修補維護時段的狀態 | 成功 – 所有執行個體都是修補且未失敗 失敗 – 至少有一個執行個體無法修補 | | StartTime | 修補維護時段的開始時間，採用 ISO 格式 | 2021-02-03T22：14：05.814308 | | EndTime | 修補維護時段的結束時間，採用 ISO 格式 | 2021-02-03T23：14：05.814308 | | WindowArn | 修補維護時段的唯一識別符。 | arn：aws：ssm：us-east-1： 123456789012：maintenancewindow/mw-00000001235 | | WindowExecutionId | 視窗執行 ID，可從 SSM 維護時段主控台查看 | e32088eb-c05f-4c63-b766-6866e163c818 | | 結果 | 修補程式視窗將鎖定目標的執行個體清單 | InstanceId – 目標執行個體 ID 狀態 – 執行個體修補程式狀態 missing\$1critical\$1patch\$1count - 執行個體上遺失的關鍵修補程式計數 missing\$1total\$1patch\$1count - 執行個體上遺失的修補程式總數 | 您可以使用 CloudWatch Events 事件來觸發 CloudWatch 規則，以便在傳送修補維護時段預先通知時通知您。若要這樣做，請使用下列組態設定 CloudWatch 規則： ``` { "source": [ "aws.managedservices" ], "detail-type": [ "AMS Patch Window Execution State Change" ], "detail": { "State": ["PREEMPTIVE"] } } ``` **注意** 如果執行個體的作業系統不受支援，或在維護時段內停止，則不會建立修補程式失敗提醒。 ## AMS 中的修補程式失敗調查 AWS Managed Services (AMS) 會管理修補，並包含修補失敗修復。修補失敗時，AMS Operations 會收到提醒，並遵循 AWS 和 AMS 最佳實務來嘗試修復問題。 如果修補程式失敗，則 AMS 會在帳戶中建立具有下列標題的 SSM OpsItem：**AWS Managed Services – 執行個體 的修補程式執行個體失敗**。 AMS 接著會調查 OpsItem。如果 AMS 可以在不介入的情況下修正故障，則 AMS 會解析 OpsItem。如果需要您的介入，則 AMS 會透過包含調查結果和建議修復步驟的服務請求通知您。如果您不採取行動來解決問題，則 AMS 會在下一個排定的修補程式維護時段嘗試修補執行個體。 **注意** 修補程式失敗 OpsItems 不會針對具有不支援作業系統，或在修補程式維護時段處於已停止狀態的執行個體建立。