从AWS捕获证据

我们之前讨论了如何将证据上传到AWS环境进行分析。由于能够在几分钟内启动高规格系统，这种方法显然具有优势。但同时也存在限制因素，如带宽可用性、成本和法律问题。由于亚马逊网站上有大量技术信息，我不打算过多讨论技术细节。现在我们将探讨需要从AWS捕获证据的一些场景。

在任何AWS证据收集中，您可能需要：

（大规模情况下，这种镜像保存方法将花费不少成本。一个能够最大限度保证数据完整性、证据连续性和成本效益的退出策略，可以预先避免后续困难的成本影响或对话）

在AWS账户间共享证据

您可能出于几个原因希望从目标环境共享特定快照：目标环境可能已受损，他们可能因各种原因不希望您现场工作，或者您可能只是想将快照共享到自己的账户，因为那里配置了所有强大的实例和工具。

要从目标环境共享快照，您需要确定要获取的AMI或快照，从中创建卷，然后将卷共享到您自己的平台。

我不会讨论哈希处理，但您需要确定证据的确定性水平，特别是在通过数据中心物理移动数据或从AWS平台下载时，这应该是显而易见的。

将卷移动到自己的平台后，您需要以只读方式挂载它，然后可以像通常那样使用取证工具进行审查。

此时您可能希望捕获此卷的取证镜像以保持连续性，或用于下载和离线分析。根据案件要求和时间限制，您可能还希望直接与其交互以快速获得结果。

只要您采取了适当措施来捕获快照和卷，以这种方式与写保护的卷直接交互是执行事件响应的可接受方法（依我拙见）。

这就是我将卷从目标环境共享到自己环境进行镜像和分析的方法。

您可能面临的另一种情况是，客户将数据托管在您法律管辖范围之外的区域，或者存在保密协议或其他合同义务，这将影响您从他们环境中物理带走证据的能力。

这会严重影响您坚持传统的"死盒"方法捕获证据的能力，即捕获取证镜像并下载进行离线分析。我最近处理的一个案例要求不得访问或将任何客户数据（存储在AWS中）带出客户办公室。

设计的方案涉及在全世界多个区域设置分析工作站，以挂载我们怀疑涉及事件的系统卷。我们必须从客户办公室内部访问这些系统，并且在整个过程中只收集不包含客户数据的证据。实质上，这导致我们的大部分事件响应调查都围绕事件日志、注册表配置单元和文件系统元数据展开，以满足这些要求。

这种方法基本上与将卷共享到自己的实例相同，尽管还有其他影响：

这就是我在AWS中捕获和分析证据所用方法的高度概括视图。