# 事故回應
<a name="a-incident-response"></a>

**Topics**
+ [SEC 10  您如何預估、回應事件以及從事件中復原？](w2aac19b7c15b5.md)

# SEC 10  您如何預估、回應事件以及從事件中復原？
<a name="w2aac19b7c15b5"></a>

準備對於及時且有效的調查、回應事件以及從事件中復原至關重要，有助於將對組織的干擾降到最低。

**Topics**
+ [SEC10-BP01 確定關鍵人員和外部資源](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 制定事件管理計劃](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 準備鑑識功能](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 自動化遏制能力](sec_incident_response_auto_contain.md)
+ [SEC10-BP05 預先佈建存取權](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 預先部署工具](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 執行演練日](sec_incident_response_run_game_days.md)

# SEC10-BP01 確定關鍵人員和外部資源
<a name="sec_incident_response_identify_personnel"></a>

 確定可以幫助您的組織回應事件的內部和外部人員、資源及法律義務。 

當您在雲端定義回應事件的方法時，與其他團隊 (例如您的法律顧問、領導階層、業務利害關係人、AWS Support Services 等等) 共同合作時，您必須識別關鍵人員、利害關係人和相關聯絡人。為了減少相依性並縮短回應時間，請確保您的團隊、專業安全團隊和回應人員受過您所使用服務的教育訓練，並有機會實際操作。

我們鼓勵您找出可提供外部專業知識和不同觀點，為您增強回應能力的外部 AWS 安全合作夥伴。您信任的安全合作夥伴可協助您識別您可能不熟悉的潛在風險或威脅。

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

## 實作指引
<a name="implementation-guidance"></a>
+  識別組織中的關鍵人員：維護人員聯絡清單，將組織中參與事故回應和復原的人員納入其中。 
+  識別外部模式：如有必要，可雇用外部合作夥伴，以幫助您應對事件並從中復原。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 事故回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **相關影片：** 
+  [準備和回應 AWS 環境中的安全事故 ](https://youtu.be/8uiO0Z5meCs)

 **相關範例：** 

# SEC10-BP02 制定事件管理計劃
<a name="sec_incident_response_develop_management_plans"></a>

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

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

## 實作指引
<a name="implementation-guidance"></a>

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

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

 為在 AWS 中運行的工作負載建立事件管理計劃時，請從 [AWS 共同的責任模型開始，](https://aws.amazon.com/compliance/shared-responsibility-model/)以便建立事件應變的深度防禦方法。在此模型中，AWS 會管理雲端的安全，但維護雲端的安全是您的責任。此表示您保有控制權，並對您選擇實作的安全控制項負責。AWS [AWS 安全事件應變指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 詳細說明在建立以雲端為中心的事件管理計劃時的重要概念和基礎指引。

 有效的事件管理計劃必須經過持續的反覆測試，以與您的雲端營運目標保持同步。在您建立和制定事件管理計劃時，請考慮使用以下詳述的實作計劃。 
+  **針對事件應變提供指導和訓練：** 當發生偏差，偏離您定義的基準時 (例如，錯誤的部署或錯誤的設定)，您可能需要回應和調查。為了順利回應和調查，您必須了解在 AWS 環境中可以使用哪些控制項和功能，來回應安全事件，以及需要考量哪些程序，以便為參與事件應變的雲端團隊提供指導和訓練，並確保他們做好準備。 
  +  [程序手冊](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) 和 [執行手冊](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 都是有效的機制，可讓您以一致的方式，來訓練事件的回應方式。從建立初步清單開始，此清單會列出在事件應變期間頻繁執行的程序，並隨著您學習或使用新的程序持續反覆測試。
  +  透過排定的演練日傳播 [程序手冊和執行手冊](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)。在演練日期間，在受控的環境中模擬事件應變，讓團隊可以回想如何回應，並確認事件應變的參與團隊是否都熟知工作流程。審查模擬事件的成果，來找出待改善的地方，並判斷是否需要進一步的培訓或額外的工具。
  +  應將安全性視為每個人的職責。透過將平常運行工作負載的所有人員都納入，來建立對事件管理程序的集體知識。這包括您業務的各個方面；營運、測試、開發、安全性、業務營運和業務領導者。 
+  **記錄事件管理計劃：** 記錄要記錄、據以採取行動和溝通進度的工具及程序，並提供與作用中事件有關的通知。事件管理計劃的目標是確認平常的營運都能盡快恢復，將對業務造成的影響降到最低，以及所有相關的人員都能了解情形。事件的例子包含 (但不限於) 網路連線的遺失或效能降低、無回應的程序或 API、未執行的排定任務 (例如，修補失敗)、應用程式資料或服務不可用、因為安全性事件而造成的意外服務中斷、憑證洩漏或設定錯誤。 
  +  找出負責解決事件的主要擁有者，例如工作負載的擁有者。清楚地指導誰將執行事件以及如何處理溝通。當事件解決程序中參與的當事人不只一位時，例如外部廠商，請考慮建立 *責任 (RACI) 矩陣*，此矩陣會詳述事件解決所需的各種團隊或人員的角色和責任。

     RACI 矩陣詳述以下內容： 
    +  **R：** *負責任的* 當事人會負責完成任務。
    +  **A：** *專責的* 當事人或利害關係人有最終的權力，可決定特定任務是否成功完成。
    +  **C：** *徵求意見的* 被諮詢當事人，其身分通常是各領域的專家。
    +  **I：** *收到進度通知的* 當事人，通常只在任務完成或交付成果時才會接獲通知。
+  **將事件分類：** 根據嚴重性和影響分數定義及分類事件，可為分類和解決事件提供有條理的方法。下列建議描述的是 *對解決方案造成影響的緊急矩陣，* 可將事件造成的影響量化。例如，影響輕微、較不緊急的事件會被視為低嚴重性事件。 
  +  **高 (H)：** 您的業務受到嚴重的影響。與 AWS 資源相關的應用程式重要功能無法使用。為對生產系統造成影響的最關鍵事件而保留。事件帶來的影響會隨著修復措施的時效性而快速提高。 
  +  **中 (M)：** 與 AWS 資源相關的業務服務或應用程式受到中度的影響並在降級的狀態下運作。有助於服務水準目標 (SLO) 的應用程式在服務水準協議 (SLA) 限制中受到影響。系統可以在能力下降的情況下執行，而不會產生太大的財務或聲譽影響。 
  +  **低 (L)：** 與 AWS 資源相關的業務服務或應用程式的非關鍵功能受到影響。系統可以在能力下降的情況下執行，並產生最輕微的財務或聲譽影響。 
+  **將安全控制項標準化：** 將安全控制項標準化的目標是為了實現營運成果的一致性、可追蹤性和可重複性。推動對事件應變至關重要之活動的標準化，例如： 
  +  **身分和存取管理：** 建立機制，來控制資料的存取和同時管理人類與機器身分的權限。將您專屬的身分和存取管理擴展至雲端，使用聯合身分安全搭配單一登入和以角色為基礎的權限，來優化存取管理作業。如需將存取管理作業標準化的最佳實務建議和改善計劃，請參閱 [安全支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) 的身分和存取管理一節。
  +  **漏洞管理：** 建立機制，來找出在 AWS 環境中很可能遭攻擊者用來入侵和濫用系統的漏洞。實作預防性和偵測性控制作為安全機制，以回應並減輕安全事件的潛在影響。在基礎設施建立和應用程式交付生命週期中，將威脅建模等程序標準化。
  +  **組態管理：** 定義標準組態和自動化程序，以便在 AWS 雲端 中部署資源。同時將基礎設施和資源佈建標準化，有助於減輕因錯誤部署所造成的錯誤設定或意外人為設定錯誤的風險。請參閱 [卓越營運支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) 設計原則一節，來了解實作此控制項的指引和改善計劃。
  +  **稽核控制項的記錄和監控：** 實作機制，來監控資源的故障、效能降低和安全性問題。將這些控制項標準化也能提供系統中所發生之活動的稽核軌跡，進而協助及時分類和修復問題。SEC04 下的最佳實務 [(「您如何偵測和調查安全事件？」)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) 提供實作此控制項的指引。
+  **使用自動化：** 自動化可讓您大規模及時解決事件。AWS 提供數種服務來在事件應變策略的情境中進行自動化。專注於在自動化和人工介入之間尋找適當的平衡。當您在程序手冊和執行手冊中建立事件應變時，請將可重複的步驟自動化。使用 AWS Systems Manager Incident Manager 之類的 AWS 服務來 [快速解決 IT 事件](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/)。使用 [開發人員工具](https://aws.amazon.com/devops/) 來提供版本控制和自動化 [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) 與基礎設施即程式碼 (IaC) 部署，而不需人工介入。在適用的情況下，使用 Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、AWS Config 和 Amazon Macie 之類的受管服務，將偵測和合規評估自動化。使用 Amazon DevOps Guru 之類的機器學習優化偵測功能，在異常營運模式問題發生前加以偵測。
+  **執行根本原因分析以及汲取經驗教訓：** 實作機制以便於事件後應變審查中汲取經驗教訓。當事件的根本原因揭露更大的缺陷、設計缺點、設定錯誤或再發的可能性時，就會將該事件分類為問題。在這類案例中，分析和解決問題來將對正常營運的中斷降到最低。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 安全事件應變指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST：電腦安全事件處理指南 ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

 **相關影片：** 
+  [將 AWS 中的事件應變和鑑識自動化 ](https://youtu.be/f_EcwmmXkXk)
+ [ 執行手冊、事件報告和事件應變的 DIY 指南 ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [ 準備和回應 AWS 環境中的安全事件 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **相關範例：** 
+  [實驗室︰使用 Jupyter 的事件應變程序手冊 - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) 
+ [ 實驗室︰使用 AWS 主控台和 CLI 來應變事件 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP03 準備鑑識功能
<a name="sec_incident_response_prepare_forensic"></a>

 了解鑑識調查何時以及如何適合您的回應計劃，對於您的事故回應者而言很重要。您的組織應定義收集的證據以及過程中使用的工具。識別和準備適合的鑑識調查功能，包括外部專家、工具和自動化。您應該預先做出的關鍵決定是您是否將從即時系統中收集資料。如果系統關閉電源或重新啟動，某些資料 (例如易消逝性記憶體的內容或作用中的網路連線) 將會遺失。 

您的回應團隊可以結合 AWS Systems Manager Amazon EventBridge 和 AWS Lambda 等工具，在作業系統和 VPC 流量鏡像內自動運行鑑識工具，以取得網路封包擷取，來收集非持久性證據。使用自訂的鑑識工作站和可供回應者存取的工具，在專用安全帳戶中進行其他活動，例如日誌分析或分析磁碟映像。

定期將相關日誌傳送到提供高耐久性和完整性的資料存放區。回應者應該可以存取這些日誌。AWS 會提供數種工具，讓日誌調查更容昣進行，例如 Amazon Athena、Amazon OpenSearch Service (OpenSearch Service) 和 Amazon CloudWatch Logs Insights。此外，還會使用 Amazon Simple Storage Service (Amazon S3) 物件鎖定，安全地保留證據。此服務遵循 WORM (一次寫入-多次讀取) 模型，並防止物件在定義的期間遭到刪除或覆寫。由於鑑識調查技術需要專業培訓，您可能需要聘請外部專家。

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

## 實作指引
<a name="implementation-guidance"></a>
+  識別鑑識能力：研究組織的鑑識調查能力、可用的工具以及外部專家。 
+  [自動化事故回應和鑑識 ](https://youtu.be/f_EcwmmXkXk)

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [如何在 AWS 中將鑑識磁碟收集自動化](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 

# SEC10-BP04 自動化遏制能力
<a name="sec_incident_response_auto_contain"></a>

將事件範圍侷限與復原自動化，以縮短回應時間與對組織的影響。

一旦您依照程序手冊建立和操演程序和工具，就可以將邏輯解構成為以程式碼為基礎的解決方案，許多回應人員可將其做為工具使用，以做到自動回應，並免除回應人員面對的變通或猜測。如此可以加速回應的生命週期。下一個目標是透過提醒或事件本身 (而不是由回應人員) 叫用，讓此程式碼能夠完全自動化，以建立事件驅動的回應。這些程序也應該自動將相關資料新增到您的安全系統。例如，涉及來自不需要 IP 地址的流量的事故可以自動填入 AWS WAF 封鎖清單或網路防火牆規則群組，以防止進一步的活動。

![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)


*圖 3：自動封鎖已知惡意 IP 地址的 AWS WAF。*

使用事件驅動的回應系統，偵測機制會觸發回應機制，以自動修復事件。您可以使用事件驅動的回應功能，減少偵測機制與回應機制之間體現價值的時間。若要建立此事件驅動架構，您可以使用 AWS Lambda；這是一種無伺服器運算服務，可執行程式碼以回應事件，並自動為您管理基礎運算資源。例如，假設您有一個已啟用 AWS CloudTrail 服務的 AWS 帳戶。如果 AWS CloudTrail 發生停用 (透過 `cloudtrail:StopLogging` API 呼叫)，您可以使用 Amazon EventBridge 監控特定的 `cloudtrail:StopLogging` 事件，並叫用 AWS Lambda 函數以呼叫 `cloudtrail:StartLogging` 以重新啟動記錄。

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

## 實作指引
<a name="implementation-guidance"></a>

 自動化遏制能力。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+ [AWS 事故回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **相關影片：** 
+  [準備和回應 AWS 環境中的安全事故](https://youtu.be/8uiO0Z5meCs) 

# SEC10-BP05 預先佈建存取權
<a name="sec_incident_response_pre_provision_access"></a>

確認事件回應者具有在 AWS 中預先佈建的正確存取權限，以縮短調查直至復原所需的時間。

 **常見的反模式：** 
+  使用事件應變的根帳戶。 
+  更改現有的使用者帳戶。 
+  當提供即時權限提升時直接操控 IAM 許可。 

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

## 實作指引
<a name="implementation-guidance"></a>

AWS 建議盡可能降低或避免對長期憑證的依賴，而是採用臨時憑證和 *即時* 權限提升機制。長期憑證容易發生安全性風險並會增加營運負擔。對於大多數管理任務，以及事件應變任務，我們建議您實作 [聯合身分](https://docs.aws.amazon.com/identity/federation/) 以及 [適用於管理存取權的臨時權限提升](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。在此模型中，使用者會請求提升至較高層級的權限 (例如事件應變角色)；如果使用者符合提升的資格，則會將請求傳送至核准者。如果請求獲得核准，使用者就會收到一組臨時 [AWS 憑證](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) ，使用者可使用此憑證來完成其任務。在這些憑證過期後，使用者就必須提交新的提升權限請求。

 我們建議在大多數事件應變情境中，使用臨時權限提升。正確的做法是使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) 和 [工作階段政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) 來界定存取權的範圍。 

 當發生聯合身分不可用的情況，例如 
+  與遭盜用身分提供者 (IdP) 相關的中斷。 
+  設定錯誤或人為錯誤會導致聯合存取管理系統遭到破壞。 
+  分散式阻斷服務 (DDoS) 事件或使系統無法使用之類的惡意活動。 

 在前述的案例中，應會有已設定的 *緊急* 存取權，可協助調查和及時修復事件。我們建議您使用 [具有適當許可的 IAM 使用者，](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) 來執行任務和存取 AWS 資源。僅將根憑證用於 [需要根使用者存取權的任務](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。若要確認事件回應者是否具有 AWS 和其他相關系統的正確存取權，我們建議預先佈建專屬的使用者帳戶。該類使用者帳戶需要提升的存取權，且必須受到嚴格的控制和監控。必須以執行必要任務所需的最低權限來建置這些帳戶，而存取權層級應以事件管理計劃中建立的程序手冊為基礎。 

 使用專用和專屬的使用者及角色作為最佳實務。透過新增 IAM 政策而臨時提升權限的使用者和角色存取權，會同時使得使用者在事件發生期間的存取權不明確，又有無法將提升的權限撤銷的風險。 

 您必須盡可能移除相依性，來確認可在各種可能的失敗情境下獲得存取權。為了做到這一點，建立程序手冊來確認事件應變使用者的建立身分是專屬安全性帳戶中的 AWS Identity and Access Management 使用者，且不會透過任何現有的聯合或單一登入 (SSO) 解決方案來管理事件應變使用者。每個個別回應者必須具備其專屬的指定帳戶。帳戶組態必須強制執行 [強式密碼政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 和多重要素驗證 (MFA)。如果事件應變程序手冊僅需要 AWS 管理主控台 的存取權，使用者就不應設定存取金鑰，且應明確禁止使用者建立存取金鑰。您可以使用 IAM 政策或服務控制政策 (SCP) 進行設定，如同 AWS Organizations SCP 的 AWS 安全性 [最佳實務中所述](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。除了在其他帳戶中擔任事件應變角色的能力外，使用者不應具備任何權限。 

 在事件期間，必須將存取權授予其他內部或外部人員，來協助調查、修復和復原活動。在此案例中，使用先前提到的程序手冊機制，而且必須制定程序，以確認在事件完成後，立即將任何其他存取權撤回。 

 若要確認事件應變角色的使用是否受到適當的監控和稽核，則必須確保未在人員之間共用為此目的建立的 IAM 使用者帳戶，且除非特定任務所需，否則不得使用 AWS 帳戶 [根使用者](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。如果需要根使用者 (例如，特定帳戶的 IAM 存取權不可用時)，請使用獨立的程序，其中有可用的程序手冊，來確認根使用者密碼和 MFA 權杖是否可用。 

 若要為事件應變角色設定 IAM 政策，請考慮使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 來根據 AWS CloudTrail 日誌產生政策。若要這麼做，請向管理員授予在非生產帳戶上事件應變角色的存取權，並透過程序手冊加以執行。完成後，您就可以建立政策來僅允許所採取的動作。接著就可以將此政策套用至所有帳戶中的所有事件應變角色。您可能希望為每個程序手冊建立個別 IAM 政策，來讓管理和稽核作業更輕鬆。範例程序手冊可能包含勒索軟體、資料洩漏、生產存取權遺失和其他情境的應變計劃。 

 使用事件應變使用者帳戶來擔任 [在其他 AWS 帳戶 中專屬事件應變 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。必須將這些角色設定為僅供安全性帳戶中的使用者擔任，而信任關係必須要求呼叫主體使用 MFA 進行驗證。這些角色必須使用嚴格控制範圍的 IAM 政策來控制存取權。確保所有對這些角色的 `AssumeRole` 請求都記錄在 CloudTrail 中並據以發出警示，而使用這些角色採取的任何動作都會記錄下來。 

 強烈建議必須清楚地命名 IAM 使用者帳戶和 IAM 角色，因此您可以輕鬆地在 CloudTrail 日誌中找到這些帳戶和角色。這類範例便是將 IAM 帳戶命名為 `<USER_ID>-BREAK-GLASS` 以及將 IAM 角色命名為 `BREAK-GLASS-ROLE`。

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 會用來在 AWS 帳戶中記錄 API 活動，且應用來 [設定對事件應變角色使用情形的警示](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)。請參閱部落格貼文，其中會說明使用根金鑰如何設定警示。您可以修改說明，以便針對以下事件設定 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指標篩選條件至篩選條件： `AssumeRole` 事件，該事件與事件應變 IAM 角色相關： 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 由於事件應變角色可能具備很高的存取權限，因此必須將這些警示傳送給多個群組，並據此快速採取行動。 

 在事件期間，回應者可能需要存取未受 IAM 直接保護的系統。其中可能包含 Amazon Elastic Compute Cloud 執行個體、Amazon Relational Database Service 資料庫或軟體即服務 (SaaS) 平台。強烈建議使用此方法，而不是使用 SSH 或 RDP 等原生通訊協定，[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 會用於對 Amazon EC2 執行個體的所有管理存取權。您可以使用安全且受稽核的 IAM 來控制此存取權。 您也可以使用 AWS Systems Manager Run Command 文件 [來自動化部分程序手冊，](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)如此可減少使用者錯誤並縮短復原時間。如需資料庫和第三方工具的存取權，我們建議將存取憑證存放在 AWS Secrets Manager 中，並將存取權授予事件回應者角色。 

 最後，應將事件應變 IAM 使用者帳戶的管理作業新增至 [加入者、異動者和離職者程序中，](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) 並定期審查和測試此管理作業，以確認僅允許預期的存取。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [管理對 AWS 環境的臨時提升存取權](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS 安全事件應變指南 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [為 IAM 使用者設定帳戶密碼政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [在 AWS 中使用多重要素驗證 (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ 使用 MFA 設定跨帳戶存取權 ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ 使用 IAM Access Analyzer 來產生 IAM 政策 ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ 在多帳戶環境中 AWS Organizations 服務控制政策的最佳實務 ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ 如何在使用 AWS 帳戶的根存取金鑰時接收通知 ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ 使用 IAM 受管政策來建立精細的工作階段許可 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **相關影片：** 
+ [ 將 AWS 中的事件應變和鑑識自動化 ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [執行手冊、事件報告和事件應變的 DIY 指南](https://youtu.be/E1NaYN_fJUo) 
+ [ 準備和回應 AWS 環境中的安全事件 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **相關範例：** 
+ [ 實驗室：AWS 帳戶設定和根使用者 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ 實驗室︰使用 AWS 主控台和 CLI 來應變事件 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 預先部署工具
<a name="sec_incident_response_pre_deploy_tools"></a>

 確保安全人員具有預先部署到 AWS 中的適當工具，以縮短調查直至復原的時間。 

若要將安全工程和操作功能自動化，您可以使用 AWS 提供的完整 API 和工具集。您可以將身份管理、網路安全、資料保護和監控功能完全自動化，並使用現有的熱門軟體開發方法遞送這些功能。建置安全自動化時，您的系統可以監控、檢閱和啟動回應，而不是讓人員監控您的安全地位並手動回應事件。自動跨 AWS 服務將可搜尋和相關日誌資料提供給事故回應者的有效方法，就是啟用 [Amazon Detective](https://aws.amazon.com/detective/)。

若您的事件回應團隊持續以相同方式回應警示，可能會形成警示疲勞的風險。隨著時間的推移，團隊可能會變得對收到提醒不敏感，而且在處理一般情況時可能會犯錯，或是錯過不尋常的警示。自動化使用能夠處理重複和一般提醒的功能，讓人員處理敏感和獨特的事件，有助於避免發生提醒疲倦的情形。整合異常偵測系統 (例如 Amazon GuardDuty、AWS CloudTrail Insights 和 Amazon CloudWatch 異常檢測) 可以減輕常見閾值型提醒的負擔。

您可以透過程式設計方式將程序中的步驟自動化，以改善手動程序。定義事件的補救模式之後，您可以將該模式分解為可行的邏輯，並撰寫程式碼來執行該邏輯。回應人員接著可以執行該程式碼來修正問題。隨著時間的推移，您可以將越來越多的步驟自動化，最終自動處理整個類別的常見事件。

對於在 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體的作業系統內執行的工具，您應該使用 AWS Systems Manager Run Command 進行評估，這可讓您使用在 Amazon EC2 執行個體作業系統上安裝的代理程式，從遠端安全地管理執行個體。這需要 Systems Manager Agent ( SSM 代理程式)，此代理程式預設安裝在許多 Amazon Machine Image (AMI) 上。不過請注意，執行個體一旦遭侵害，對於在其上執行的工具或代理程式發出的回應都不應視為可信任。

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

## 實作指引
<a name="implementation-guidance"></a>
+  預先部署工具：確保安全人員具有預先部署到 AWS 中的適當工具，以便可以對事件做出適當的回應。 
  +  [實驗室︰使用 AWS 管理主控台和 CLI 處理事故回應 ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
  + [ 使用 Jupyter 的事故回應手冊 - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
  +  [AWS 安全自動化 ](https://github.com/awslabs/aws-security-automation)
+  實作資源標記：使用資訊標記資源 (例如調查中資源的程式碼)，以便您可以在事件期間識別資源。
  + [AWS 標記策略 ](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 事故回應指南 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)

 **相關影片：** 
+  [ 執行手冊、事件報告和事件回應的 DIY 指南 ](https://youtu.be/E1NaYN_fJUo)

# SEC10-BP07 執行演練日
<a name="sec_incident_response_run_game_days"></a>

演練日也稱為模擬或練習，是內部舉辦的活動，提供有條理的機會，供您在寫實情境下演練事件管理計劃和程序。這些事件應該使用在真實世界情境中使用的相同工具和技術來鍛煉回應者 - 甚至模仿真實世界環境。演練日基本上就是用來準備和反覆改善您的回應能力。對於進行演練日的活動，您可能會發現有價值的原因包括： 
+ 驗證整備
+ 培養信心 – 從模擬和培訓員工得到學習
+ 遵守合規或合約義務
+ 產生用於認證的成品
+ 靈活 – 增量改進
+ 加速並改善工具
+ 精簡溝通和上報
+ 培養安然面對罕見和意外情形的能力

基於上述原因，參與模擬活動所衍生的價值，會在壓力事件期間提高組織發揮的效用。開發既實際又有益的模擬活動可能是艱鉅的作業。雖然測試處理熟知事件的程序或自動化具有某些優勢，但參與創造性的 [安全事故回應模擬 (SIRS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) 活動，以考驗自己面對意外和持續改善的能力，同樣也有價值。

建立針對您的環境、團隊和工具量身打造的自訂模擬。找出問題並根據它設計您的模擬。這可能是洩露的憑證、與不需要的系統通訊的伺服器，或導致未經授權暴露的錯誤組態等項目。識別熟悉貴組織的工程師來建立情境，以及另一個要參與的群組。情境應該是真實的，且具有足夠的挑戰性來彰現價值。它應該包括實作記錄、通知、呈報和執行執行手冊或自動化的機會。在模擬期間，您的回應者應該鍛煉其技術和組織技能，而且領導者應該參與以建立其事故管理技能。模擬結束時，讚揚團隊的努力，並尋找反覆、重複和擴充到進一步模擬的方法。

[AWS 已建立事故回應執行手冊範本](https://github.com/aws-samples/aws-incident-response-playbooks) ，您可以不僅將其用來準備您的回應工作，還可以將其做為模擬的基礎。規劃時，模擬可以分成五個階段。

**收集證據： **在這個階段，團隊將透過各種方式獲得提醒，例如內部票證系統、來自監控工具的提醒、匿名提示，甚至是公共新聞。然後，團隊開始審查基礎設施和應用程式日誌，以判定入侵的來源。此步驟還應涉及內部呈報和事故領導地位。一旦識別，團隊就會繼續遏制事故

**遏制事故： **團隊將判定發生了事故並確定入侵的來源。團隊現在應該採取行動來遏制它，例如，停用遭入侵的憑證、隔離運算資源或撤銷角色的許可。

**杜絕事故： **既然他們已遏制事故，團隊就會努力緩解應用程式或基礎設施組態中易受入侵的任何漏洞。這可能包括輪換用於工作負載的所有憑證、修改存取控制清單 (ACL) 或變更網路組態。

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

## 實作指引
<a name="implementation-guidance"></a>
+  執行 [在生產環境中](https://wa.aws.amazon.com/wat.concept.gameday.en.html)：針對涉及關鍵人員和管理層的各種威脅執行模擬的 [事故](https://wa.aws.amazon.com/wat.concept.incident.en.html) 回應 [活動 (演練日)](https://wa.aws.amazon.com/wat.concept.event.en.html) 。
+  汲取經驗教訓：從 [在生產環境中](https://wa.aws.amazon.com/wat.concept.gameday.en.html) 中獲得的經驗教訓應該成為改善程序的回饋意見的一部分。

## 資源
<a name="resources"></a>

 **相關文件：** 
+ [AWS 事故回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [AWS 彈性災難復原](https://aws.amazon.com/cloudendure-disaster-recovery/) 

 **相關影片：** 
+ [ 執行手冊、事件報告和事件回應的 DIY 指南 ](https://youtu.be/E1NaYN_fJUo)