本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 技術
如果您在安全事件之前開發並實作適當的技術，您的事件回應人員將能夠調查、了解範圍，並及時採取行動。
# 開發 AWS 帳戶結構
[AWS Organizations](https://aws.amazon.com/organizations/) 當您成長和擴展 AWS 資源時， 會協助集中管理 AWS 環境。 AWS 組織會合併 AWS 您的帳戶，以便您以單一單位管理它們。您可以使用組織單位 (OU) 將帳戶群組在一起，以單一單位的形式進行管理。
對於事件回應，擁有支援事件回應功能 AWS 的帳戶結構很有幫助，其中包括*安全 OU* 和*鑑識 OU*。在安全性 OU 中，您應該擁有下列項目的帳戶：
+ ** 日誌封存 **– 彙總日誌封存 AWS 帳戶中的日誌。
+ ** 安全工具** – 將安全服務集中在安全工具 AWS 帳戶中。此帳戶會以安全性服務的委派系統管理員身分運作。
在鑑識 OU 中，您可以選擇為營運所在的每個區域實作一或多個鑑識帳戶，具體視哪個區域最適合您業務和營運模式而定。對於每個區域帳戶方法的範例，如果您僅在美國東部 （維吉尼亞北部） (us-east-1) 和美國西部 （奧勒岡） (us-west-2) 中操作，則您會在鑑識 OU 中有兩個帳戶：一個用於 us-east-1，另一個用於 us-west-2。佈建新帳戶需要一些時間，因此必須在事件之前建立和檢測鑑識帳戶，以便回應者能夠有效地使用這些帳戶進行回應。
下圖顯示範例帳戶結構，包括具有每個區域鑑識帳戶的鑑識 OU：
![\[事件回應的每個區域帳戶結構圖表\]](http://docs.aws.amazon.com/zh_tw/security-ir/latest/userguide/images/incident-response-account-structure.png)
# 制定和實作標記策略
取得有關業務使用案例的內容資訊以及與 AWS 資源相關的內部利益相關者可能很困難。其中一種做法是標籤形式，將中繼資料指派給您的 AWS 資源，並包含使用者定義的金鑰和值。您可以建立標籤，依目的、擁有者、環境、處理的資料類型以及您選擇的其他條件來分類資源。
擁有一致的標記策略可讓您快速識別和辨別 AWS 資源的相關內容資訊，以加快回應時間。標籤也可以作為啟動回應自動化的機制。如需如何標記的詳細資訊，請參閱[標記 AWS 資源的文件](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。您需要先定義要在整個組織中實作的標籤。之後，您將實作並強制執行此標記策略。您可以在 AWS 部落格中找到實作和強制執行的詳細資訊 [使用標籤政策和服務控制政策 (SCPs) AWS 實作 AWS 資源標記策略](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)。
# 更新 AWS 帳戶聯絡資訊
對於您的每個 AWS 帳戶，請務必擁有準確且up-to-date聯絡資訊，以便正確的利益相關者收到 AWS 來自 安全性、帳單和操作等主題的重要通知。對於每個 AWS 帳戶，您都有主要聯絡人和用於安全性、帳單和操作的替代聯絡人。您可以在[AWS 帳戶管理參考指南](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate)中找到這些聯絡人之間的差異。
如需管理替代聯絡人的詳細資訊，請參閱[AWS 新增、變更或移除替代聯絡人的文件](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-alternate-contacts)。如果您的團隊管理帳單、操作和安全相關問題，最佳實務是使用電子郵件分發清單。電子郵件分發清單會移除一個人的相依性，如果他們不在辦公室或離開公司，可能會導致封鎖。您也應該驗證電子郵件和帳戶聯絡資訊，包括電話號碼，是否受到保護，以防止根帳戶密碼重設和多重驗證 (MFA) 重設。
對於使用 的客戶 AWS Organizations，組織管理員可以使用管理帳戶或委派管理員帳戶集中管理成員帳戶的替代聯絡人，而不需要每個 AWS 帳戶的登入資料。您也需要驗證新建立的帳戶具有準確的聯絡資訊。請參閱[自動更新新建立 AWS 帳戶 部落格文章的替代聯絡人](https://aws.amazon.com/blogs/mt/automatically-update-alternate-contacts-for-newly-created-aws-accounts/)。
# 準備對 的存取 AWS 帳戶
在事件期間，您的事件回應團隊必須能夠存取事件涉及的環境和資源。在事件發生之前，請確定您的團隊具有適當的存取權來執行其職責。若要這樣做，您應該知道團隊成員需要的存取層級 （例如，他們可能採取的動作類型），並應事先佈建最低權限存取。
若要實作和佈建此存取權，您應該識別帳戶策略和雲端身分策略，並與組織的雲端架構師討論 AWS ，以了解已設定哪些身分驗證和授權方法。由於這些登入資料具有特殊權限，因此在實作過程中，您應該考慮使用核准流程或從保存庫或安全中擷取登入資料。實作之後，您應該在事件發生之前妥善記錄和測試團隊成員的存取權，以確保他們可以毫無延遲地回應。
最後，專為回應安全事件而建立的使用者通常具有特殊權限，以提供足夠的存取權。因此，應限制、監控這些登入資料，且不用於日常活動。
# 了解威脅環境
## 開發威脅模型
透過開發威脅模型，組織可以在未經授權的使用者可以識別威脅和緩解措施。威脅建模有多種策略和方法；請參閱[如何處理威脅建模](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)部落格文章。對於事件回應，威脅模型可協助識別威脅行為者在事件期間可能使用的攻擊媒介。了解您要防禦的內容至關重要，以便及時回應。您也可以使用 AWS Partner 進行威脅建模。若要搜尋 AWS 合作夥伴，請使用 [AWS Partner Network](https://partners.amazonaws.com/)。
## 整合和使用網路威脅情報
網路威脅情報是威脅行為者意圖、機會和能力的資料和分析。取得和使用威脅情報有助於及早偵測事件，並更好地了解威脅行為者的行為。網路威脅情報包括靜態指標，例如 IP 地址或惡意軟體的檔案雜湊。它還包含高階資訊，例如行為模式和意圖。您可以從許多網路安全供應商和開放原始碼儲存庫收集威脅情報。
若要為您的 AWS 環境整合和最大化威脅情報，您可以使用一些out-of-the-box功能，並整合您自己的威脅情報清單。Amazon GuardDuty 使用 AWS 內部和第三方威脅情報來源。其他服務 AWS ，例如 DNS 防火牆和 AWS WAF 規則，也會接受來自進階威脅情報群組 AWS的輸入。有些 GuardDuty 調查結果會映射到 [MITRE ATT&CK 架構，該架構](https://attack.mitre.org/)提供有關對手策略和技術的真實世界觀察資訊。
# 選取並設定日誌以進行分析和提醒
在安全調查期間，您需要能夠審核相關日誌以記錄和了解該事件的完整範圍和時間表。產生提醒也需要日誌，以指出特定關注的動作已發生。選擇、啟用、儲存和設定查詢與擷取機制和設定提醒至關重要。本節會檢閱每個動作。如需詳細資訊，請參閱[安全事件回應的記錄策略](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/) AWS 部落格文章。
# 選取並啟用日誌來源
在安全調查之前，您需要擷取相關日誌，以追溯重建 AWS 帳戶中的活動。選取並啟用與其 AWS 帳戶工作負載相關的日誌來源。
AWS CloudTrail 是一種記錄服務，可追蹤針對擷取 AWS 服務活動 AWS 的帳戶發出的 API 呼叫。它預設為啟用，並保留 90 天的管理事件，這些事件可透過 [ CloudTrail 的事件歷史記錄](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)設施 AWS 管理主控台使用 AWS CLI、 或 AWS SDK 擷取。若要延長資料事件的保留和可見性，您需要[建立 CloudTrail Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) 並與 Amazon S3 儲存貯體建立關聯，以及選擇性地與 CloudWatch 日誌群組建立關聯。或者，您可以建立 [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html)，這會保留 CloudTrail 日誌長達七年，並提供以 SQL 為基礎的查詢設施。
AWS 建議使用 VPC 的客戶分別使用 [VPC 流程日誌](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)和 [Amazon Route 53 解析程式查詢日誌](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)來啟用網路流量和 DNS 日誌，並將其串流至 Amazon S3 儲存貯體或 CloudWatch 日誌群組。您可以為 VPC、子網路或網路界面建立 VPC 流程日誌。對於 VPC 流程日誌，您可以選擇啟用流程日誌以降低成本的方式和位置。
AWS CloudTrail 日誌、VPC 流程日誌和 Route 53 解析程式查詢日誌是支援 中安全調查*的基本日誌三角結構* AWS。
AWS 服務可以產生基本記錄 trifecta 未擷取的日誌，例如 Elastic Load Balancing 日誌、 AWS WAF 日誌、 AWS Config 記錄器日誌、Amazon GuardDuty 調查結果、Amazon Elastic Kubernetes Service (Amazon EKS) 稽核日誌，以及 Amazon EC2 執行個體作業系統和應用程式日誌。如需記錄和監控選項的完整清單[附錄 A：雲端功能定義](appendix-a-cloud-capability-definitions.md)，請參閱 。
# 選取日誌儲存
日誌儲存的選擇通常與您使用的查詢工具、保留功能、熟悉度和成本有關。當您啟用 AWS 服務日誌時，請提供儲存設施；通常是 Amazon S3 儲存貯體或 CloudWatch 日誌群組。
Amazon S3 儲存貯體透過選用的生命週期政策，提供經濟實惠的耐用儲存體。存放在 Amazon S3 儲存貯體中的日誌可以使用 Amazon Athena 等服務進行原生查詢。CloudWatch 日誌群組透過 CloudWatch Logs Insights 提供耐用的儲存方式和內建查詢設施。
# 識別適當的日誌保留
當您使用 S3 儲存貯體或 CloudWatch 日誌群組存放日誌時，您必須為每個日誌來源建立足夠的生命週期，以最佳化儲存和擷取成本。客戶通常有 3 到 12 個月的日誌可供查詢，保留期長達七年。可用性和保留時間的選擇應該配合您的安全需求與各種法令、法規和業務規定。
# 選取並實作日誌的查詢機制
在 中 AWS，您可以用來查詢日誌的主要服務是存放在 [CloudWatch 日誌群組中的資料的 CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)，以及存放在 Amazon S3 中的資料的 [Amazon Athena](https://aws.amazon.com/athena/) 和 Amazon [ OpenSearch Service](https://aws.amazon.com/opensearch-service/)。 CloudWatch Amazon S3 您也可以使用第三方查詢工具，例如安全性資訊和事件管理 (SIEM)。
選取日誌查詢工具的過程中應該考慮安全營運的人員、程序和技術層面。選取可滿足營運、業務和安全需求，且長期可存取和可維護的工具。請記住，將要掃描的日誌數目維持在日誌查詢工具限制之內，以便以最佳狀態運作。由於成本或技術限制，客戶擁有多個查詢工具並不常見。例如，客戶可能會使用第三方 SIEM 來執行過去 90 天的查詢，並使用 Athena 執行超過 90 天的查詢，因為 SIEM 的日誌擷取成本。無論實作為何，請確認您的方法能將最大化營運效率所需的工具數量降至最低，尤其是在安全事件調查期間。
# 使用日誌來提醒
AWS 原生透過安全服務提供提醒，例如 Amazon GuardDuty、 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)和 AWS Config。您也可以針對這些服務未涵蓋的安全提醒，或與您環境相關的特定提醒，使用自訂提醒產生引擎。[偵測](detection.md) 本文件中稱為 的章節涵蓋了建立這些提醒和偵測。
# 開發鑑識功能
在安全事件發生之前，將開發鑑識功能納入考量，以協助安全事件調查。將[鑑識技術整合至 NIST 事件回應的指南](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf)提供此類指導。
# 上的鑑識 AWS
適用於傳統內部部署鑑識的概念 AWS。部落格文章[中的鑑識調查環境策略 AWS 雲端](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)為您提供重要資訊，以開始將鑑識專業知識遷移至 AWS。
將環境和 AWS 帳戶結構設定為鑑識之後，您會想要定義在四個階段有效執行鑑識健全方法所需的技術：
+ ** 收集** – 收集相關 AWS 日誌，例如 AWS CloudTrail、 AWS Config、VPC 流程日誌和主機層級日誌。收集受影響 AWS 資源的快照、備份和記憶體傾印。
+ ** 檢查** – 透過擷取和評估相關資訊來檢查收集的資料。
+ ** 分析** – 分析收集的資料，以了解事件並從中得出結論。
+ ** 報告** – 呈現分析階段所產生的資訊。
# 擷取備份和快照
設定重要系統和資料庫的備份，對於從安全事件中復原和鑑識用途非常重要。備份就緒後，您可以將系統還原到先前的安全狀態。在 上 AWS，您可以拍攝各種資源的快照。快照可為您提供那些資源的時間點備份。有許多 AWS 服務，可以在備份和復原方面為您提供支援。如需這些服務和備份[和復原方法的詳細資訊，請參閱備份和復原規範指南](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html)。如需詳細資訊，請參閱[使用備份從安全事件復原](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/)部落格文章。
尤其是當涉及勒索軟體等情況時，務必確保備份是否有充足的保護。請參閱部落格文章[中保護備份安全的 10 大安全最佳實務 AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/)，以取得保護備份的指導方針。除了確保備份的安全之外，您還應該定期測試備份和還原程序，以確認您現有的技術和程序是否如預期般運作。
# 在 上自動化鑑識 AWS
在安全事件期間，您的事件回應團隊必須能夠快速收集和分析證據，同時在事件周圍的期間內保持準確性。事件回應團隊在雲端環境中手動收集相關證據既具有挑戰性又耗時，尤其是在大量執行個體和帳戶中。此外，手動收集可能容易出現人為錯誤。基於這些原因，客戶應該開發和實作鑑識的自動化。
AWS 為鑑識提供了多種自動化資源，這些資源合併在 下的附錄中[鑑識資源](appendix-b-incident-response-resources.md#forensic-resources)。這些資源是我們已開發和客戶已實作的鑑識模式範例。雖然這些範例在一開始可能是有用的參考架構，但請根據環境、需求、工具和鑑識程序，考慮是否加以修改或建立新的鑑識自動化模式。