建立可自定义的跨公司日志湖以满足合规要求，第一部分：业务背景

by Colin Carson 和 Sean OSullivan 于 2024年8月1日发布在 高级 (300) 、Amazon CloudWatch 、AWS CloudTrail 、AWS Glue 、AWS Systems Manager 、合规 、安全、身份与合规 、技术操作指南

关键要点

本文主要内容：

业务背景介绍了为何要创建日志湖，同时也提到了一些可能较快或更简便的AWS替代方案。提出优化日志存储和查询的数据结构以及满足合规需求的问题。强调了提高系统效率、确保数据存取便捷、简化治理方式等需求。

在前一篇文章中，我们阐述了如何使用 AWS Session Manager 管理对 Amazon Elastic Compute Cloud (Amazon EC2) 实例的访问。我们所在的大型全球组织拥有成千上万个账户，并被要求回答一个特定的业务问题：“有特权访问的员工在Session Manager中做了什么？”

这项问题的初步回答是借助Session Manager的 日志记录和审计功能，以及整合了其他AWS服务的能力，包括记录连接StartSession API调用和通过 Amazon CloudWatch Logs 实时记录命令键击记录。

尽管这些措施有帮助，但还只是开始。我们还有更多的要求和问题：

会话活动记录到CloudWatch Logs之后，接下来如何？ 如何提供有用的数据结构，以便减少读取工作、提升性能、加强数据利用，并增加便利性？如何支持多样的使用模式，例如系统间的批量传输或个人对单一会话的临时查询？如何共享和执行治理？更宏观来看，如何对其他服务或多种用例引入同样的问题？如何增加连接前后发生的其他API活动，即上下文信息？

我们需要比单一服务或功能所能提供的更全面的功能、更大的自由度和更多的控制。我们的旅程始于对先前客户案例的借鉴。此外，我们必须结合现有的方法和创意创建出新的模式：

低级原语例如 Amazon Simple Storage Service (Amazon S3)。最新的AWS特性和方法，如 AWS Glue 的垂直和水平扩展。我们在大型企业环境中与法律、审计和合规方面的经验。客户反馈。

在此文中，我们将介绍如何基于 CloudWatch 和 AWS CloudTrail 的日志创建一个可自定义的日志湖，分为三部分：

第一部分：业务背景 介绍我们为何创建日志湖以及可能更快或更便捷的AWS替代方案。第二部分：构建 描述该架构及如何使用AWS CloudFormation模板进行设置。第三部分：扩展 展示如何向日志湖添加调用日志、模型输入与模型输出数据。

你真的想自己来做吗？

在你构建自己的日志湖之前，考虑一下AWS中已经提供的最新、最高级的选项它们可能会为你节省大量工作。尽可能选择那些将无差异重担抽象化的AWS服务和方案，这样你就可以专注于增加新业务价值，而不是管理额外的开销。知晓这些服务的设计用途，可以让你了解它们今天的能力及未来发展方向。

如果这些不适合你，并且你没有发现能实现你需求的选项，那么你可以像我们为日志湖所做的那样，在AWS中混合搭配原语以获得更大的灵活性和自由度。

Session Manager活动日志

正如我们在引言中提到的，你可以通过 Amazon S3 保存日志数据，并在其上方添加一张 表，然后通过Amazon Athena查询该表这是我们首先推荐的简单方法。

一元机场 ink

这将导致带有sessionid的文件名。如果需要，你可以通过 S3事件通知 处理这些文件，形成calendarday、sessionid、sessiondata格式并确保保存到不同的桶中、不同的表中，以避免造成递归循环。此函数可以从S3键元数据中推导出calendarday和sessionid，而sessiondata则通常为整个文件内容。

另一种方法是将所有日志发送到一个CloudWatch日志组，然后通过 Amazon Data Firehose 订阅过滤器将这些数据移动到S3此文件会在JSON内容中附加元数据，并具有从 过滤器 进一步自定义的潜力。这种情况在我们的情境中得到了使用，但不足以单独满足需求。

AWS CloudTrail Lake

CloudTrail Lake 旨在对事件进行多年历史查询，具备近实时延迟，并提供比 CloudTrail事件历史 更深度且可自定义的事件视图。CloudTrail Lake使你能够 联合事件数据存储，从而在AWS Glue目录中查看元数据并运行Athena查询。对于涉及单一组织的持续 沉积数据或从Amazon S3的 实例导入，或二者结合，你可以考虑使用CloudTrail Lake。

我们考虑过CloudTrail Lake，作为管理湖选项或CloudTrail数据的来源，但最终选择了创建我们自己的AWS Glue作业。这是由于需要完全控制架构和作业，以及能够从我们选择的S3桶中作为持续来源提取数据、在账户、AWS区域和eventNameeventName 过滤对管理事件并未得到支持进行细粒度过滤等多个原因。此外，CloudTrail Lake的成本也是关键因素之一，因为基于 未压缩数据的费用数据大小可能比S3大10倍。

在一次测试中，我们发现CloudTrail Lake处理同一工作负载的速度要快38倍，但Log Lake的成本要低10至100倍，具体取决于过滤条件、时间和账户活动。我们的测试工作负载是在S3中的159 GB文件，各包含199亿个事件和40万个文件，分布在150多个账户和3个区域。Log Lake应用的过滤条件为eventname=StartSession AssumeRole AssumeRoleWithSAML，以及五个任意的白名单账户。这些测试可能不同于您的使用情况，所以请进行你自己的测试，收集自己的数据，独立得出结论。

其他服务

此前提到的产品与我们希望实现的成果最相关，但你还可以考虑AWS的 安全、身份和合规产品。这些产品和功能可以作为Log Lake的替代方案或补充功能。

例如，Amazon Bedrock可以通过三种方式添加功能：

跳过搜索，直接查询Log Lake对日志进行摘要作为日志源类似于Session Manager作为CloudWatch日志的来源

查询意味着你可以让 AI代理查询你的AWS Glue目录，以获得数据驱动的结果。摘要则意味着你可以使用生成性人工智能对来自知识库的文本日志进行总结，以便提出“有多少日志文件完全相同？”或“谁在昨晚更改了IAM角色？”等问题。注意事项和局限性适用。

将Amazon Bedrock作为源，意味着使用调用日志收集请求和响应。

由于我们希望以经济实惠的方式存储大量数据压缩和列存储格式，而非文本，并产生可用于法律合规和安全的非生成性基于数据结果，因此没有在Log Lake中使用Amazon Bedrock。因此，我们将在第三部分讨论如何应用我们在Session Manager上使用的方法来实现Amazon Bedrock。

业务背景

当我们与业务合作伙伴、赞助者和其他利益相关者进行对话时，重要的问题、问题、机会和需求逐渐浮现。

为什么我们需要这样做

我们工作的这个大型企业的法律、安全、身份与合规部门创建了一个客户特定控制。为了符合控制目标，使用提升的权限需要管理者手动审查所有可用数据包括任何会话管理器活动，以确认或否定是否合理使用了提升的权限。这是一个合规用例，解决之后可以应用到更多的审计和报告用例中。

术语说明：

此处的 客户 在 客户特定控制 中指的是由客户全权负责的控制，而非AWS，正如《AWS共享责任模型》所述。在本文中，我们广义上将 审计 定义为测试IT控制以降低风险，可以由任何人以任何节奏进行作为日常运营的一部分进行的持续审查或一次性的。我们不指代由独立第三方进行的财务审计，仅限于特定时期的审计。我们将 自我审查 和 审计 视为同义词。我们还广义上定义 报告 为为特定目的、特定格式提供数据以评估业务绩效并促进数据驱动决策，例如回答“上周有多少名员工进行了会话？”

使用案例

我们的第一个也是最重要的用例是管理者需要审查活动，比如来自前一天晚上值班报警的活动。如果管理者需要与其员工进行额外讨论或需要进一步考虑活动的内容，则他们有多达一周7天时间来确认或否定其团队程序是否需要提升的权限。管理者需要审查所有共享同一会话的事件，而无须特定的关键字或特定字符串内容，作为AWS中的“所有可用数据”。工作流程为：

员工使用自制应用程序和标准化工作流通过Session Manager以提升权限访问Amazon EC2。CloudTrail中的API活动和CloudWatch Logs的持续日志记录。问题空间数据以某种方式被获取、处理并提供这后来成为了Log Lake。另一个自制系统不同于步骤1向管理者呈现会话活动并应用访问控制管理者应仅审查自己员工的活动，不能随意查看其他团队的数据。这些数据可能仅是一次StartSession API调用，没有会话详细信息，也可能是来自cat file的成千上万行。管理者审查所有可用活动，做出明智决策，并确认或否定是否合理使用。

这是一个持续的日常操作，范围较窄。首先，这仅意味着AWS中可用的数据；如果某些内容无法被AWS捕获，则不在范围内。如果某些内容是可能的，则应使其可用。其次，这仅意味着某些特定工作流；仅在某个具体文档化的标准作业程序中使用Session Manager获得提升权限。

避免审查

最简单的解决方案是封锁具有提升权限的Amazon EC2会话，并完全自动化构建和部署。对于某些工作负载这是可能的，但并不适用于所有工作负载，因为某些工作负载需要的初始设置、故障排除或紧急更改。

准确的日志记录和审计是否可行？

我们在这里不会详细列举绕过控制的方法，但确实存在一些重要限制和注意事项，我们建议你也要考虑这一点。

首先，[sessionType](https//docsawsamazoncom/systemsmanager/latest/userguide/sessionmanagerschemahtml#type) Port的日志记录是不可用的，这包括SSH。可以通过确保员工只能使用自定义应用层来 启动会话 而不是SSH来减轻这一问题。通过 安全组策略 阻止对EC2实例的直接SSH访问是另一种选择。

其次，有多种方法可以故意或意外地隐藏或扰乱会话中的活动，使得审查特定命令变得困难甚至不可能。这在我们的用例中是可以接受的，基于多种原因：

管理者总会通过CloudTrail知道会话是否开始需进行审查我们的源信号。我们与CloudWatch连接以满足“所有可用数据”的要求。持续流式传输到CloudWatch Logs 会实时记录活动。此外，流式传输到CloudWatch Logs支持交互式Shell访问，而我们的用例仅使用了交互式Shell访问[sessionType](https//docsawsamazoncom/systemsmanager/latest/userguide/sessionmanagerschemahtml#type) StandardStream。流式传输不支持sessionType、InteractiveCommands或NonInteractiveCommands。复审工作流程涉及一个工程化的应用与一套标准操作程序多样性小于Session Manager的所有用法。最后，管理者负责审查报告，被期望施展自己的判断力并解读发生了什么。例如，管理者的复审可能会带来与员工后续的对话，以改进业务流程。管理者可以询问其员工：“你能帮我明白为什么你运行了此命令？我们是否需要更新我们的运行手册或在部署中自动化某个部分？”

为了保护数据不受篡改、变化或删除，AWS提供了如 AWS身份与访问管理(IAM) 政策和权限 和Amazon S3的 对象锁 等工具及功能。

安全和合规是一个共享的责任，在AWS和客户之间，客户需要决定使用哪些AWS服务和功能以满足他们的用例。我们建议客户考虑一个全面的方法，整体系统设计，包括多层安全控制深度防御。要了解更多信息，请查看安全支柱的AWS WellArchitected Framework。

避免自动化

手动审核可能是一个痛苦的过程，但我们无法实现审核自动化，原因有二：法律要求和增加经理在使用提升权限时所感受到的反馈循环隐患，以此阻止提升权限的随意使用。

与现有相兼容

我们不得不与现有架构协同工作，覆盖了数千个账户和多个AWS Organizations。这意味着必须将数据源从桶作为边缘和数据入口。具体而言，CloudTrail数据是管理并整合到S3桶之外的多个CloudTrail与Organizations中的。CloudWatch数据同样从 Session Manager到CloudWatch Logs 被整合到S3桶中