SEC10-BP02 制定事件管理計劃 - AWS Well-Architected 架構
實作指引資源

SEC10-BP02 制定事件管理計劃

建立計劃以協助您回應、在事件期間進行溝通，以及從事件中復原。例如您可以從工作負載和組織最可能發生的情境，開始建立事件回應計畫。包括您在內部和外部進行溝通和向上呈報的流程。

若未建立此最佳實務，暴露的風險等級： 高

實作指引

事件管理計劃對於回應、減輕安全事件所造成潛在影響並從中復原而言至關重要。事件管理計劃是結構清晰的程序，可及時找出、修復和回應安全事件。

雲端有許多在內部部署環境中所見的相同營運角色和需求。建立事件管理計劃時，您必須將與業務成果和合規需求最相符的應變及復原策略納入考量。例如，如果您在 AWS 中運作的工作負載符合美國的 FedRAMP，那麼遵循 NIST SP 800-61 電腦安全處理指南便很有用。同樣地，當運行帶有歐洲 PII (個人身分識別資訊) 資料的工作負載時，請考量以下情境，例如如何保護和回應與 歐盟一般資料保護規範 (GDPR) 中所要求之資料落地的相關問題。

為在 AWS 中運行的工作負載建立事件管理計劃時，請從 AWS 共同的責任模型開始，以便建立事件應變的深度防禦方法。在此模型中，AWS 會管理雲端的安全，但維護雲端的安全是您的責任。此表示您保有控制權，並對您選擇實作的安全控制項負責。AWS AWS 安全事件應變指南 詳細說明在建立以雲端為中心的事件管理計劃時的重要概念和基礎指引。

有效的事件管理計劃必須經過持續的反覆測試，以與您的雲端營運目標保持同步。在您建立和制定事件管理計劃時，請考慮使用以下詳述的實作計劃。

  • 針對事件應變提供指導和訓練： 當發生偏差，偏離您定義的基準時 (例如，錯誤的部署或錯誤的設定)，您可能需要回應和調查。為了順利回應和調查，您必須了解在 AWS 環境中可以使用哪些控制項和功能，來回應安全事件，以及需要考量哪些程序，以便為參與事件應變的雲端團隊提供指導和訓練，並確保他們做好準備。

    • 程序手冊 和 執行手冊 都是有效的機制，可讓您以一致的方式，來訓練事件的回應方式。從建立初步清單開始，此清單會列出在事件應變期間頻繁執行的程序，並隨著您學習或使用新的程序持續反覆測試。

    • 透過排定的演練日傳播 程序手冊和執行手冊。在演練日期間，在受控的環境中模擬事件應變，讓團隊可以回想如何回應，並確認事件應變的參與團隊是否都熟知工作流程。審查模擬事件的成果，來找出待改善的地方，並判斷是否需要進一步的培訓或額外的工具。

    • 應將安全性視為每個人的職責。透過將平常運行工作負載的所有人員都納入，來建立對事件管理程序的集體知識。這包括您業務的各個方面；營運、測試、開發、安全性、業務營運和業務領導者。

  • 記錄事件管理計劃： 記錄要記錄、據以採取行動和溝通進度的工具及程序，並提供與作用中事件有關的通知。事件管理計劃的目標是確認平常的營運都能盡快恢復，將對業務造成的影響降到最低，以及所有相關的人員都能了解情形。事件的例子包含 (但不限於) 網路連線的遺失或效能降低、無回應的程序或 API、未執行的排定任務 (例如，修補失敗)、應用程式資料或服務不可用、因為安全性事件而造成的意外服務中斷、憑證洩漏或設定錯誤。

    • 找出負責解決事件的主要擁有者，例如工作負載的擁有者。清楚地指導誰將執行事件以及如何處理溝通。當事件解決程序中參與的當事人不只一位時，例如外部廠商，請考慮建立 責任 (RACI) 矩陣，此矩陣會詳述事件解決所需的各種團隊或人員的角色和責任。

      RACI 矩陣詳述以下內容：

      • R： 負責任的 當事人會負責完成任務。

      • A： 專責的 當事人或利害關係人有最終的權力，可決定特定任務是否成功完成。

      • C： 徵求意見的 被諮詢當事人，其身分通常是各領域的專家。

      • I： 收到進度通知的 當事人，通常只在任務完成或交付成果時才會接獲通知。

  • 將事件分類： 根據嚴重性和影響分數定義及分類事件，可為分類和解決事件提供有條理的方法。下列建議描述的是 對解決方案造成影響的緊急矩陣， 可將事件造成的影響量化。例如，影響輕微、較不緊急的事件會被視為低嚴重性事件。

    • 高 (H)： 您的業務受到嚴重的影響。與 AWS 資源相關的應用程式重要功能無法使用。為對生產系統造成影響的最關鍵事件而保留。事件帶來的影響會隨著修復措施的時效性而快速提高。

    • 中 (M)： 與 AWS 資源相關的業務服務或應用程式受到中度的影響並在降級的狀態下運作。有助於服務水準目標 (SLO) 的應用程式在服務水準協議 (SLA) 限制中受到影響。系統可以在能力下降的情況下執行，而不會產生太大的財務或聲譽影響。

    • 低 (L)： 與 AWS 資源相關的業務服務或應用程式的非關鍵功能受到影響。系統可以在能力下降的情況下執行，並產生最輕微的財務或聲譽影響。

  • 將安全控制項標準化： 將安全控制項標準化的目標是為了實現營運成果的一致性、可追蹤性和可重複性。推動對事件應變至關重要之活動的標準化，例如：

    • 身分和存取管理： 建立機制，來控制資料的存取和同時管理人類與機器身分的權限。將您專屬的身分和存取管理擴展至雲端，使用聯合身分安全搭配單一登入和以角色為基礎的權限，來優化存取管理作業。如需將存取管理作業標準化的最佳實務建議和改善計劃，請參閱 安全支柱白皮書 的身分和存取管理一節。

    • 漏洞管理： 建立機制，來找出在 AWS 環境中很可能遭攻擊者用來入侵和濫用系統的漏洞。實作預防性和偵測性控制作為安全機制，以回應並減輕安全事件的潛在影響。在基礎設施建立和應用程式交付生命週期中，將威脅建模等程序標準化。

    • 組態管理： 定義標準組態和自動化程序，以便在 AWS 雲端 中部署資源。同時將基礎設施和資源佈建標準化，有助於減輕因錯誤部署所造成的錯誤設定或意外人為設定錯誤的風險。請參閱 卓越營運支柱白皮書 設計原則一節，來了解實作此控制項的指引和改善計劃。

    • 稽核控制項的記錄和監控： 實作機制，來監控資源的故障、效能降低和安全性問題。將這些控制項標準化也能提供系統中所發生之活動的稽核軌跡，進而協助及時分類和修復問題。SEC04 下的最佳實務 (「您如何偵測和調查安全事件？」) 提供實作此控制項的指引。

  • 使用自動化： 自動化可讓您大規模及時解決事件。AWS 提供數種服務來在事件應變策略的情境中進行自動化。專注於在自動化和人工介入之間尋找適當的平衡。當您在程序手冊和執行手冊中建立事件應變時，請將可重複的步驟自動化。使用 AWS Systems Manager Incident Manager 之類的 AWS 服務來 快速解決 IT 事件。使用 開發人員工具 來提供版本控制和自動化 Amazon Machine Images (AMI) 與基礎設施即程式碼 (IaC) 部署，而不需人工介入。在適用的情況下，使用 Amazon GuardDuty、Amazon Inspector、AWS Security Hub、AWS Config 和 Amazon Macie 之類的受管服務，將偵測和合規評估自動化。使用 Amazon DevOps Guru 之類的機器學習優化偵測功能，在異常營運模式問題發生前加以偵測。

  • 執行根本原因分析以及汲取經驗教訓： 實作機制以便於事件後應變審查中汲取經驗教訓。當事件的根本原因揭露更大的缺陷、設計缺點、設定錯誤或再發的可能性時，就會將該事件分類為問題。在這類案例中，分析和解決問題來將對正常營運的中斷降到最低。

資源

相關文件：

相關影片：

相關範例：