深入解析实时清单

在 FireMon 成立初期（确切地说，是在我们成为 FireMon 之前），我们就意识到，试图对客户的云账户（包括订阅/项目）进行实时评估是……存在问题的。运行如此大量的评估会很快触及服务限制，并可能干扰客户内部的 API 调用。请注意，我们大约在 7 年前就开始这样做了，当时 CSPM 尚未出现，所有人都在汲取同样的经验教训。

我们提出的第一个解决方案是：将配置数据采集一次，录入我们自己的清单，然后在其中执行评估。这样，我们可以将 API 调用减少到仅获取元数据所必需的程度。随后，我们便能基于同一数据集运行多项评估。在一段时间内，这种方法效果良好。我们仍然执行基于时间的配置扫描，但可以将其更均匀地分散开来，并进行优化以尽量减少 API 调用的过载。然而，这种方法也有其自身的一系列问题。如果在我们扫描之后、有人最终介入处理告警之前发生了变更，该怎么办？此外，遍历整个 AWS 服务以获取该服务中的所有资源，仍然会逼近基于服务和区域设定的 API 限制。

为了更好地应对这一状况，我们为自己设定了两项挑战。第一，实时更新清单，以减少对特定服务的 API 调用峰值，并确保客户永远不会使用过时的数据。第二，保留历史记录，使客户和调查人员能够回溯查看究竟发生了哪些变更以及变更是如何发生的。我们稍后会深入探讨技术架构，各个云平台的实现略有不同。简而言之，通过直接连接到云服务提供商的事件流，我们可以识别变更类 API 调用、提取所涉及的资源、实时更新我们的清单，并同时触发针对特定清单类型的所有评估。

虽然我们仍然通过每日一次/非工作时段的基于时间的扫描来提供支持，但转向实时机制解决了许多问题，并带来了一些有趣的收益。这些收益包括：

• 客户永远不会遇到陈旧数据；平台中的所有内容都应与实际运行的配置/状态高度一致。
• 由于我们监控 API 调用，因此可以识别是谁发起了这些调用。于是，我们的清单中立即具备了完整的身份归属信息。
• 在变更发生的同时即可轻松定位变更内容，从而实现全面的变更追踪。
• 我们可以在变更发生时实时运行所有检查和评估。这不仅包括识别新问题，也包括在有人于外部修复问题时将其“解决”。

就此完成。一份完整的、实时的、带变更追踪和身份归属的历史清单！诚然，AWS Config 之类的服务在云提供商内部原生提供了这一功能。不过，除了成本优势之外，我们的清单与评估紧密集成，可覆盖多种云部署和多家提供商，并提供一些相当出色的能力，例如全面的搜索功能。

体验这一切的最佳方式是观看我们 90 秒的视频导览！以下是几张关键截图：

主页面，在单一视图中呈现大量重要数据：

这是变更历史视图，以完整的详细信息和归属信息呈现各项变更。它还具备一些实用功能，例如相关事件、关联资源、豁免项，以及该资源的通过/未通过检查结果历史记录：

该历史视图按时间顺序追踪变更，并以图表展示活动趋势。点击时间轴即可跳转至相应日期：

您是否曾需要了解，在某个特定时间点出现在日志中的 IP 地址归属于哪个临时云资源？事件响应人员非常喜欢这项功能……

以上就是简要概述。在后续文章中，我们将进一步介绍该架构，以及我们如何在多云环境中实现这一切。