簡介 - AWS 安全事件回應使用者指南
開始之前AWS 事件回應概觀

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

簡介

安全是 AWS .customers 的首要任務 AWS。 客戶受益於資料中心和網路架構，這些架構旨在協助支援最安全敏感組織的需求。 AWS 具有共同的責任模型： AWS 管理雲端的安全性，客戶需負責雲端的安全。這表示您可以完全控制安全實作，包括存取數種工具和服務，以協助達成您的安全目標。這些功能可協助您為在 中執行的應用程式建立安全基準 AWS 雲端。

當發生與基準的偏差時，例如組態錯誤或外部因素變更，您將需要回應和調查。若要成功做到這一點，您需要了解您 AWS 環境中安全事件回應的基本概念，以及在發生安全問題之前準備、教育和訓練雲端團隊的需求。請務必了解您可以使用哪些控制項和功能、檢閱主題範例以解決潛在問題，以及識別使用自動化來改善回應速度和一致性的修補方法。此外，您應該了解您的合規和法規要求，因為它們與建置安全事件回應計劃以滿足這些要求相關。

安全事件回應可能很複雜，因此建議您實作反覆方法：從核心安全服務開始，建立基礎偵測和回應功能，然後開發手冊，以建立初始的事件回應機制程式庫，以反覆執行和改善這些機制。

開始之前

開始了解 中安全事件的事件回應之前 AWS，請先熟悉 AWS 安全與事件回應的相關標準和架構。這些基礎將協助您了解本指南中介紹的概念和最佳實務。

AWS 安全標準和架構

首先，我們建議您檢閱安全性、身分和合規、安全支柱 AWS 架構和雲端採用架構概觀 () 的安全觀點白皮書的最佳實務。 AWSAWS CAF

AWS CAF 提供指引，支援移動到雲端的不同組織部分之間的協調。 AWS CAF 本指南分為數個重點領域，稱為與建置雲端 IT 系統相關的觀點。安全觀點說明如何跨工作流程實作安全計劃，其中一個是事件回應。本文件是我們與客戶合作的經驗產品，協助他們建立有效且高效率的安全事件回應計劃和功能。

產業事件回應標準和架構

本白皮書遵循美國國家標準技術研究所 () 所建立的電腦安全事件處理指南 SP 800-61 r2 的事件回應標準和最佳實務NIST。閱讀和了解 引進的概念NIST是有用的先決條件。NIST 本指南中的概念和最佳實務將套用至本文件中的 AWS 技術。不過，內部部署事件案例超出本指南的範圍。

AWS 事件回應概觀

首先，請務必了解雲端中的安全操作和事件回應有何不同。若要建置有效的回應功能 AWS，您需要了解與傳統現場部署回應的偏差，及其對事件回應計畫的影響。本節會詳細說明這些差異，以及核心 AWS 事件回應設計原則。

AWS 事件回應的層面

組織內的 AWS 所有使用者都應對安全事件回應程序有基本的了解，而安全人員應了解如何回應安全問題。教育、培訓和體驗是成功的雲端事件回應計畫必不可缺的一環，最好能預先實施，以因應發生安全事件的情況。雲端中成功事件回應計劃的基礎是準備、操作和事件後活動。

若要分別了解這三個層面，請參考下列說明：

  • 準備 – 讓您的事件回應團隊 AWS 透過啟用偵測控制並驗證對必要工具和雲端服務的適當存取，來偵測和回應 中的事件。此外，備妥必要的程序手冊 (包括手動和自動)，以確認能夠做出可靠且一致的回應。

  • 操作 – 在 事件回應NIST階段之後對安全事件和潛在事件進行操作：偵測、分析、控制、清除和復原。

  • 事後活動 – 反覆查看安全事件和模擬的結果，以提高回應的效能、增加回應和調查衍生的值，並進一步降低風險。您必須從事件中學習，並能夠確實實施後續改進。

本指南會探索和詳細說明這些層面。下圖顯示這些層面的流程，與先前提到NIST的事件回應生命週期保持一致，但與包含包含包含控制、根除和復原的偵測和分析的操作一致。

顯示 AWS 事件回應層面的圖表

AWS 事件回應的層面

AWS 事件回應原則和設計目標

雖然 NIST SP 800-61 電腦安全事件處理指南所定義的事件回應的一般程序和機制是合理的，但我們也建議您考慮與回應雲端環境中的安全事件相關的這些特定設計目標：

  • 建立回應目標 – 與利益相關者、法律顧問和組織領導合作，以判斷回應事件的目標。一些常見的目標包括包含和減輕問題、復原受影響的資源、保留資料以進行鑑識、返回已知的安全操作，以及最終從事件中學習。

  • 使用雲端進行回應 – 在雲端中實作回應模式，其中事件發生和資料。

  • 了解您擁有的內容和需求 – 將日誌、資源、快照和其他證據複製並儲存在專用於回應的集中式雲端帳戶中，以保留這些記錄、資源、快照和其他證據。運用標籤、中繼資料和機制，強制執行保留政策。您需要了解您使用的服務，然後識別調查這些服務的需求。為了協助您了解您的環境，您也可以使用標記，本文件稍後會在 制定和實作標記策略章節中說明。

  • 使用重新部署機制 – 如果安全異常可歸因於組態錯誤，則修復方法可能很簡單，例如透過使用適當的組態重新部署資源來移除差異。如果發現可能的入侵，請確認重新部署包含成功且經過驗證的根本原因緩解。

  • 盡可能自動化 - 當問題發生或事件重複時，建立以程式設計方式分類和回應常見事件的機制。將人工回應用於自動化不足的唯一、複雜或敏感事件。

  • 選擇可擴展的解決方案 – 努力符合組織雲端運算方法的可擴展性。實作可跨環境擴展的偵測和回應機制，以有效縮短偵測和回應之間的時間。

  • 了解和改善您的程序 – 主動識別程序、工具或人員中的差距，並實作修正這些差距的計劃。模擬是尋找差距並改善程序的安全方法。如需如何在程序上反覆運算的詳細資訊，請參閱本文件的 事後處理 一節。

這些設計目標可提醒您審核架構實作，以確認能夠進行事件回應和威脅偵測。當您規劃雲端實作時，請考慮回應事件，最好使用鑑識健全的回應方法。在某些情況下，這表示您可能有多個組織、帳戶和工具專門為這些回應任務設定。這些工具和功能應透過部署管道提供給事件回應人員使用。它們不應處於靜態，否則可能造成更大的風險。

雲端安全事件網域

若要有效地準備和回應 AWS 環境中的安全事件，您需要了解雲端安全事件的常見類型。客戶的責任中有三個網域可能發生安全事件：服務、基礎設施和應用程式。不同的網域需要不同的知識、工具和回應程序。請考慮這些網域：

  • 服務網域 – 服務網域中的事件可能會影響您的 AWS 帳戶、 AWS Identity and Access Management(IAM) 許可、資源中繼資料、帳單或其他區域。服務網域事件是您專門使用 AWS API機制回應的事件，或者您有與組態或資源許可相關聯的根本原因，並且可能有相關的服務導向記錄。

  • 基礎設施網域 – 基礎設施網域中的事件包括資料或網路相關活動，例如 Amazon Elastic Compute Cloud (AmazonEC2) 執行個體上的程序和資料、虛擬私有雲端 (VPC) 內 Amazon EC2執行個體的流量，以及其他區域，例如容器或其他未來服務。您對基礎設施網域事件的回應通常涉及取得事件相關資料以進行鑑識分析。它可能包括與執行個體作業系統的互動，而且在各種情況下，也可能涉及 AWS API機制。在基礎設施網域中，您可以在訪客作業系統中使用 和 數位鑑識/意外回應 (DFIR) 工具的 AWS APIs組合，例如專用於執行鑑識分析和調查的 Amazon EC2執行個體。基礎設施網域事件可能涉及分析網路封包擷取、Amazon Elastic Block Store (AmazonEBS) 磁碟區上的磁碟區塊，或從執行個體取得的揮發性記憶體。

  • 應用程式網域 – 應用程式網域中的事件發生在應用程式程式碼中，或部署到服務或基礎設施的軟體中。此網域應包含在雲端威脅偵測和回應手冊中，並可能包含與基礎設施網域類似的回應。透過適當且周到的應用程式架構，您可以使用自動擷取、復原和部署，使用雲端工具來管理此網域。

在這些網域中，請考慮可能針對 AWS 帳戶、資源或資料採取行動的演員。無論是內部或外部，請使用風險架構來判斷組織的特定風險，並據此進行準備。此外，您應該開發威脅模型，這可協助您規劃事件回應和建置深思熟慮的架構。

中事件回應的主要差異 AWS

事件回應是內部部署或雲端網路安全策略不可或缺的一部分。最低權限和深度防禦等安全原則旨在保護內部部署和雲端中資料的機密性、完整性和可用性。支援這些安全原則的數個事件回應模式都遵循規範，包括日誌保留、從威脅建模衍生的警示選擇、手冊開發，以及安全資訊和事件管理 (SIEM) 整合。當客戶開始在雲端架構和工程這些模式時，差異就開始了。以下是 中事件回應的主要差異 AWS。

差異 #1：安全作為共同的責任

安全與合規的責任由 AWS 與其客戶共同承擔。此共同責任模型可減輕客戶的一些營運負擔，因為 會 AWS 操作、管理和控制從主機作業系統和虛擬化層到服務營運所在設施實體安全性的元件。如需共同責任模型的詳細資訊，請參閱共同責任模型文件。

隨著您在雲端中的共同責任變更，事件回應的選項也會變更。規劃和了解這些權衡，並將其與您的控管需求配對，是事件回應中的關鍵步驟。

除了與您有直接關係之外 AWS，可能還有其他實體在您的特定責任模型中負有責任。例如，您可能有內部組織單位負責操作的某些層面。您可能也會與其他開發、管理或操作您部分雲端技術的第三方建立關係。

建立和測試適當的事件回應計劃，以及符合您操作模型的適當手冊非常重要。

差異 #2：雲端服務網域

由於雲端服務中存在安全責任的差異，因此引入了安全事件的新網域：服務網域，已在事件網域一節中稍早說明。服務網域包含客戶的 AWS 帳戶、IAM許可、資源中繼資料、帳單和其他區域。由於您的回應方式，此網域與事件回應不同。服務網域內的回應通常是透過檢閱和發出API呼叫，而不是傳統的主機型和網路型回應來完成。在服務網域中，您不會與受影響資源的作業系統互動。

下圖顯示基於架構反模式的服務網域中安全事件的範例。在這種情況下，未經授權的使用者會取得IAM使用者的長期安全登入資料。IAM 使用者具有允許其從 Amazon Simple Storage Service (Amazon S3) 儲存貯體擷取物件IAM的政策。若要回應此安全事件，您可以使用 AWS APIs 來分析 AWS 日誌，例如 AWS CloudTrail和 Amazon S3 存取日誌。您也可以使用 AWS APIs 來包含並從事件中復原。

服務網域範例的圖表

服務網域範例

差異 #3：APIs用於佈建基礎設施

另一個差異來自隨需自助服務的雲端特性。主要設施客戶 AWS 雲端 可透過全球許多地理位置提供的RESTfulAPI公有和私有端點與 互動。客戶可以使用APIs AWS 登入資料存取這些登入資料。與內部部署存取控制相反，這些登入資料不一定受網路或 Microsoft Active Directory 網域的約束。登入資料會改為與 AWS 帳戶內的 IAM 委託人相關聯。這些API端點可以在您的公司網路外部存取，這對於了解何時回應在預期網路或地理位置之外使用登入資料的事件非常重要。

由於 API型的本質 AWS，回應安全事件的重要日誌來源是 AWS CloudTrail，它會追蹤您 AWS 帳戶中進行的管理API呼叫，以及您可以在其中找到API呼叫來源位置的相關資訊。

差異 #4：雲端的動態性質

雲端是動態的，可讓您快速建立和刪除資源。透過自動擴展，資源可以根據流量增加向上和向下旋轉。透過短期基礎設施和快速步調變更，您正在調查的資源可能不再存在或可能已修改。了解 AWS 資源的暫時性性質，以及如何追蹤 AWS 資源的建立和刪除，對於事件分析非常重要。您可以使用 AWS Config 來追蹤 AWS 資源的組態歷史記錄。

差異 #5：資料存取

雲端的資料存取也不同。您無法插入伺服器以收集安全調查所需的資料。資料會透過線路和API通話收集。您需要練習並了解如何執行資料收集，APIs以便為此輪班做好準備，並驗證適當的儲存體以有效收集和存取。

差異 #6：自動化的重要性

若要讓客戶充分了解雲端採用的優勢，其營運策略必須採用自動化。基礎設施即程式碼 (IaC) 是一種高效率的自動化環境模式，其中使用原生 IaC 服務，例如 AWS CloudFormation 或第三方解決方案，來部署、設定、重新設定和銷毀 AWS 服務。這會將事件回應的實作推向高度自動化，最好避免人為錯誤，特別是在處理證據時。雖然在內部部署使用自動化，但在 中它至關重要且更簡單 AWS 雲端。

解決這些差異

若要解決這些差異，請依照下一節中概述的步驟，驗證您的事件回應計劃是否已準備好跨人員、程序和技術。