理解预期成效：我们如何选定 Cloud Defense Free 的功能集

当我们决定推出 免费版 FireMon Cloud Defense 时，我们清楚必须平衡两个关键难题：

• 我们早已知道平台具备扩展能力，但能否将其调整为在经济上可持续地扩展，长期支撑大型企业？不言而喻，我们不能只是把它发布出去，然后指望 AWS 账单不会把我们拖入破产管理。
• 在这些成本限制之下，我们能否提供一套为用户带来真正价值的功能？这种价值究竟是什么？它能解决哪些问题？

现实情况是，“免费”（如同免费啤酒）从来都不是完全免费的，因为使用任何东西都要花费时间和精力。我们并不把 Cloud Defense 免费版看作从桌沿撒落的面包屑；我们明白，如果我们请用户注册、部署并使用该平台，那么只有在我们帮助他们完成工作时，他们才会这样做。

（我们从中得到什么？我们知道会有一定比例的用户升级到付费方案，但免费平台还能让我们获得极有价值的反馈，了解人们对 CSPM 的需求以及他们的使用方式，并让我们检验新的想法。）

在后续文章中，我们会更深入地探讨技术细节，而今天我们想介绍的是，我们如何决定哪些功能纳入免费版。由于我们把这一版本的平台视为独立的产品，因此决定采用指导我们大部分战略的同一套方法论。

定义期望成果

在 FireMon，我们非常推崇用于产品战略的 Jobs to be Done 框架。这个名称本身已说明了不少，该框架通过聚焦客户想要完成的任务以及他们期望的具体成果来指导产品决策。这是对 JTBD 框架的极度简化的说法，但意思大致如此。与其聚焦功能，不如聚焦潜在客户在使用产品时的期望成果，再以此设计功能。

在经过包含调研、经验总结和访谈的深入过程后，我们梳理出一份面向云安全专业人员的可能期望成果草案：

• 提升我对整个云环境中云安全态势的了解与认识。（可见性）
• 降低整个云环境中出现云配置错误的可能性。（预防）
• 在分散式环境中减少整个云环境的云安全与合规暴露面（数量和时间）。（修复）
• 提升我们向管理层和监管机构通报云安全问题的能力。
• 降低云部署中 IAM 访问权限丢失和滥用的可能性。
• 提升我们预防、检测和响应云攻击的能力
• 使我们的安全措施与多家提供商的云服务和平台变更保持同步。
• 在不增加安全风险的前提下，减少开发团队和云团队承受的安全摩擦与额外负担。
• 降低我们使用容器部署时发生安全漏洞事件的风险。
• 通过标准 API 和数据结构，减少我将云安全与自身安全项目集成所花费的时间。

显然，解决上述每个问题的方法有很多，因此我们面临的问题是：在运营一个免费托管平台的经济约束下，我们能够提供哪些能力？这与提供需要用户自行部署和运行的开源软件截然不同。我们希望打造出使用起来像商业产品一样快速、便捷的东西（好吧，希望比您过去用过的许多产品更快、更简单）。

将成果转化为功能

有了这份清单，接下来就是看我们能够改造或构建什么：

• 提升我对整个云环境中云安全态势的了解与认识。（可见性）

态势未必只关乎安全；态势是指各项资源的配置方式。仅仅提供一份配置错误清单无法体现态势，因此我们知道必须在成本约束内构建企业级规模的云资源清单。我们的平台已支持实时清单，但将其扩展到免费版并不具备成本效益。

我们认定，通过每天一次扫描以及带变更跟踪的 30 天清单历史记录，可以在平衡成本的同时仍然提供价值。您会注意到我们还没有谈到安全配置错误，但稍后会讲到。在进行了一些成本建模之后，我们意识到可以在预算范围内以企业级规模（数千个受监控账户）运行，因此这既提供了价值，又控制了成本，两项要求都得以满足。

这实际上耗费了相当多的工程投入，因为商业产品主要支持实时清单更新，而非周期性扫描。不过，我们把这些更新与其他一些希望进行的、可提升整体效率的改动打包在一起，彼此契合良好，因此这是一个容易做出的决定。

• 降低整个云环境中出现云配置错误的可能性。（预防）

预防云配置错误比检测要困难得多。如果用户采用基础设施即代码，是否要在 CI/CD 流水线中加以拦截？手动变更又该如何处理？如何在不增加过多摩擦或破坏现有流程的情况下处理这些工作流？

我们知道，目前无法在免费产品中实现完整的预防能力。当前平台通过自动化来实现这一点，而免费大规模运行自动化的成本过高。不过，我们有一些可能可行的想法，现已列入开发待办事项。

• 在分散式环境中减少整个云环境的云安全与合规暴露面（数量和时间）。（修复）

自产品的最初版本以来，这一直是 Cloud Defense 的核心业务。虽然自动修复不适用于免费版（同样是出于成本与复杂度的平衡考虑），但没有理由不运行我们完整的安全检查套件。

但拿到一长串潜在安全问题清单并不一定有助于修复。我们产品的另一项核心能力是深度的 ChatOps 集成。开箱即用地支持 Slack 和 Teams，但 Teams 需要更多支持投入，原因嘛……毕竟它是 Teams。因此我们决定完全开放细粒度（按账户或项目）的 Slack 通知，因为这对我们并无实质成本，却能为用户带来大量价值。

• 提升我们向管理层和监管机构通报云安全问题的能力。

运行一份合规报告对我们造成的内部成本微乎其微，即使在大型环境中也是如此。就合规而言，每天一次的评估通常足以满足这一期望成果。我们确实投入了一些新的开发工作，以便为更大规模的部署（例如数百个账户）提供更好的 PDF 报告，但无论如何这对我们的商业客户也是必需的。

• 使我们的安全措施与多家提供商的云服务和平台变更保持同步。

由于免费产品与商业产品使用同一套我们持续更新的检查库，因此这一能力开箱即用。我们最初的工程投入集中在 AWS 的成本优化上，因此决定在发布之初不支持 Azure 或 GCP。Azure 已接近就绪，用户最终将免费获得完整的多云支持。

• 降低云部署中 IAM 访问权限丢失和滥用的可能性。

我们有一项非常出色的功能，名为 Authorization Control，它能切实提升 IAM 安全性，但在经济上无法将其纳入免费产品。

• 提升我们预防、检测和响应云攻击的能力

我们的商业产品支持实时威胁检测，但由于需要实时监控的活动量极大，这同样是一项在经济上无法在免费平台中支持的功能。

• 在不增加安全风险的前提下，减少开发团队和云团队承受的安全摩擦与额外负担。
• 降低我们使用容器部署时发生安全漏洞事件的风险。
• 通过标准 API 和数据结构，减少我将云安全与自身安全项目集成所花费的时间。

这些成果都会带来额外成本和/或复杂度，无论是基础设施、支持还是开发成本，我们认为都无法在免费产品中充分应对。

功能组合的打包

期望成果结合成本分析，帮助我们确定了要打包哪些功能：

• 每天一次扫描
• 带 30 天历史记录的资源清单
• 完整的安全检查套件
• 基础合规报告
• Slack 集成
• 目前支持 AWS，随着平台更新将支持 Azure 和 GCP

这些决定并非总是轻松。例如，即便是 30 天的清单也有成本，但我们认为仅提供配置错误报告无法充分满足用户的可见性需求。我们同样认为，限制安全检查范围或要求用户为获取合规报告而转向商业产品，都会导致产品无法真正提供足够的成果。

这一功能组合满足了核心的安全可见性期望成果，以及沟通方面的成果，从而既改善报告，又缩短修复周期。我们知道这里确有价值，因为这些正是人们最初构建云安全开源工具所要解决的期望成果，也是整个云安全态势管理市场的起源。

JTBD 框架切实帮助我们始终聚焦于改善客户成效，而不是仅仅拆分出一些拼凑在一起却真正帮不上任何人的功能。我们认为，最终成果是一个既能提供真正价值、又足够经济高效以支持我们长期运营的免费平台。

欢迎您试用，并告诉我们您的看法。 FireMon Cloud Defense 仍在持续完善中，也是我们提升自身能力、帮助云安全专业人员完成工作的重要途径。