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

# 簡介
<a name="introduction"></a>

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

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

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

## 開始之前
<a name="before-you-begin"></a>

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

### AWS 安全標準和架構
<a name="aws-security-standards-and-frameworks"></a>

 首先，我們建議您檢閱[安全性、身分與合規、安全支柱 AWS 架構和雲端採用架構概觀 (CAF) 的安全觀點白皮書的最佳實務](https://aws.amazon.com/architecture/security-identity-compliance/)。 [AWSAWS](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)

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

### 產業事件回應標準和架構
<a name="industry-incident-response-standards-and-frameworks"></a>

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

## AWS 事件回應概觀
<a name="incident-response-overview"></a>

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

### AWS 事件回應的層面
<a name="aspects-of-incident-response"></a>

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

 若要分別了解這三個層面，請參考下列說明：
+  **準備** – 讓您的事件回應團隊 AWS 透過啟用偵測控制並驗證對必要工具和雲端服務的適當存取，來偵測和回應 內的事件。此外，備妥必要的程序手冊 (包括手動和自動)，以確認能夠做出可靠且一致的回應。
+  **操作** – 在 NIST 事件回應階段之後對安全事件和潛在事件進行操作：偵測、分析、遏制、消除和復原。
+  **事件後活動** – 反覆查看安全事件和模擬的結果，以改善回應的有效性、提高從回應和調查衍生的值，並進一步降低風險。您必須從事件中學習，並能夠確實實施後續改進。

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

![顯示 AWS 事件回應各方面的圖表](http://docs.aws.amazon.com/zh_tw/security-ir/latest/userguide/images/aspects-of-incident-response.png)


### AWS 事件回應原則和設計目標
<a name="incident-response-principles-and-design-goals"></a>

 雖然 [NIST SP 800-61 電腦安全事件處理指南](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)所定義的事件回應的一般程序和機制是健全的，但我們也建議您考慮這些與回應雲端環境中的安全事件相關的特定設計目標：
+ ** 建立回應目標** – 與利益相關者、法律顧問和組織領導層合作，以確定回應事件的目標。一些常見的目標包括包含和緩解問題、復原受影響的資源、保留資料以進行鑑識、返回已知的安全操作，以及最終從事件中學習。
+ ** 使用雲端回應** – 在雲端中實作回應模式，即事件發生和資料的位置。
+ **了解您擁有的內容和需求** – 將日誌、資源、快照和其他證據複製並儲存在專用於回應的集中式雲端帳戶中，以保留這些記錄、資源、快照和其他證據。運用標籤、中繼資料和機制，強制執行保留政策。您需要了解您使用的服務，然後識別調查這些服務的需求。為了協助您了解您的環境，您也可以使用標記，本文件稍後會在 [制定和實作標記策略](develop-and-implement-tagging-strategy.md)章節中說明此標記。
+ **使用重新部署機制** – 如果安全異常可歸因於組態錯誤，則修復方法可能很簡單，例如透過使用適當的組態重新部署資源來移除差異。如果發現可能的入侵，請確認重新部署包含成功且經過驗證的根本原因緩解。
+ **盡可能自動化** – 當問題發生或事件重複時，建立以程式設計方式分類和回應常見事件的機制。將人工回應用於自動化不足的唯一、複雜或敏感事件。
+ **選擇可擴展的解決方案** – 努力符合組織雲端運算方法的可擴展性。實作可跨環境擴展的偵測和回應機制，以有效縮短偵測和回應之間的時間。
+ **了解並改善您的程序** – 主動識別程序、工具或人員中的差距，並實作計畫來修正差距。模擬是尋找差距並改善程序的安全方法。如需如何在程序上反覆運算的詳細資訊，請參閱本文件的 [事後處理](post-incident-activity.md)一節。

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

### 雲端安全事件網域
<a name="cloud-security-incident-domains"></a>

 若要有效準備和回應 AWS 環境中的安全事件，您需要了解雲端安全事件的常見類型。客戶的責任中有三個網域可能發生安全事件：服務、基礎設施和應用程式。不同的網域需要不同的知識、工具和回應程序。請考慮這些網域：
+ **服務網域** – 服務網域中的事件可能會影響您的 AWS 帳戶、 [AWS Identity and Access Management](https://aws.amazon.com/iam/)(IAM) 許可、資源中繼資料、帳單或其他區域。服務網域事件是您專門使用 AWS API 機制回應的事件，或者您有與組態或資源許可相關聯的根本原因，並且可能有相關的服務導向記錄。
+ **基礎設施網域** – 基礎設施網域中的事件包括資料或網路相關活動，例如 [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) 執行個體上的程序和資料、虛擬私有雲端 (VPC) 內 Amazon EC2 執行個體的流量，以及其他區域，例如容器或其他未來服務。您對基礎設施網域事件的回應通常涉及取得事件相關資料以進行鑑識分析。它可能包括與執行個體作業系統的互動，而且在各種情況下，也可能涉及 AWS API 機制。在基礎設施網域中，您可以在訪客作業系統中使用 AWS APIs和數位鑑識/事件回應 (DFIR) 工具的組合，例如專用於執行鑑識分析和調查的 Amazon EC2 執行個體。基礎設施網域事件可能涉及分析網路封包擷取、[Amazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS) 磁碟區上的磁碟區塊，或從執行個體取得的揮發性記憶體。
+ **應用程式網域** – 應用程式網域中的事件發生在應用程式程式碼中，或部署到服務或基礎設施的軟體中。此網域應包含在雲端威脅偵測和回應手冊中，並可能包含與基礎設施網域類似的回應。透過適當且深思熟慮的應用程式架構，您可以使用自動擷取、復原和部署，使用雲端工具來管理此網域。

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

### 中事件回應的主要差異 AWS
<a name="key-differences-of-incident-response"></a>

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

#### 差異 \#1：作為共同責任的安全性
<a name="difference-1"></a>

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

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

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

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

#### 差異 \#2：雲端服務網域
<a name="difference-2"></a>

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

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

![服務網域範例圖表](http://docs.aws.amazon.com/zh_tw/security-ir/latest/userguide/images/service-domain-example.png)


#### 差異 \#3：用於佈建基礎設施APIs
<a name="difference-3"></a>

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

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

#### 差異 \#4：雲端的動態性質
<a name="difference-4"></a>

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

#### 差異 \#5：資料存取
<a name="difference-5"></a>

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

#### 差異 \#6：自動化的重要性
<a name="difference-6"></a>

 為了讓客戶完全實現雲端採用的優勢，他們的營運策略必須採用自動化。基礎設施即程式碼 (IaC) 是一種高效率的自動化環境模式，其中使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)或第三方解決方案等原生 IaC 服務促進的程式碼來部署、設定、重新設定和銷毀 AWS 服務。這會將事件回應的實作推送為高度自動化，最好能避免人為錯誤，尤其是在處理證據時。在現場部署使用自動化時，在 中它至關重要且更簡單 AWS 雲端。

#### 解決這些差異
<a name="addressing-these-differences"></a>

 若要解決這些差異，請遵循下一節中概述的步驟，以驗證您的事件回應計劃是否在人員、程序和技術之間做好萬全準備。