最近发生的 Salesloft 数据泄露事件给我们上了一课：在 SaaS 应用程序之间的连接关系难以监测，这为安全团队带来了盲区，并可能引发灾难性的后果。类似的数据泄露事件很可能不会是最后一次。
为了解决这个问题，Cloudflare 正在开发一套解决方案，通过单一代理整合所有 SaaS 连接，以便更轻松地监控、检测和响应。一个适合所有人的 SaaS 到 SaaS 代理。
在构建此产品的过程中，我们需要来自社区（包括数据所有者和 SaaS 平台提供商）的反馈。如果您有兴趣获得提前体验权限，请在此处注册。
SaaS 平台提供商通常会为其客户提供应用市场，代客户存储数据，因而成为客户信赖的数据托管方。当平台与市场中的应用进行集成时，这种托管责任便面临考验。一旦这些集成中的任意一个发生密钥泄露，就可能导致大规模的数据外泄与篡改。随着接入应用数量的增加，攻击面也随之扩大。目前，代表数据所有者工作的安全团队尚无法检测或应对潜在的泄露风险。
在这篇文章中，我们将解释使这项工作成为可能的基础技术，并帮助确保您的互联网数据安全。
没有人会质疑 SaaS 应用程序及其集成功能所带来的价值。主流 SaaS 企业纷纷构建蓬勃发展的集成生态系统，这些系统通常以应用市场的形式呈现。对许多企业而言，这已成为其价值主张的重要组成部分。Salesforce 提供了 AppExchange。Zendesk 推出了应用市场。ServiceNow 则打造了集成中心。诸如此类，不一而足。
这些功能可为任何组织及复杂工作流提供重要价值。对于 SaaS 供应商原生不支持的数据分析或其他任务，仅需简单点击即可轻松完成。
另一方面，SaaS 应用程序给安全团队带来了越来越多的未知挑战：谁能访问这些数据？部署了哪些安全流程？更重要的是：我们该如何检测数据泄露、入侵或其他恶意行为？
Salesloft 数据泄露事件，导致包括 Cloudflare 在内的数百家公司的数据泄露，使得这些问题成为当前最受关注的焦点。
Cloudflare 正在积极试验两种方法，以应对 SaaS 应用日益严峻的安全挑战，主要包括增强对 SaaS 与 SaaS 之间连接的可见性，以及在发生数据泄露时实现异常检测与密钥管理。下面我们将逐一介绍这两种方法，它们均基于对 SaaS 与 SaaS 之间流量的代理机制。
Cloudflare 运营着全球规模最大的反向代理网络之一。由于我们在 L7 终止流量，因此能够执行多项安全相关功能，包括拦截恶意请求、检测异常流量、检测自动化流量等。这也是客户向我们寻求帮助的主要应用场景之一。
Cloudflare 可以代理客户控制下的任何主机名。
正是这种特定能力（通常被称为“个性化”、“品牌化”或“自定义”主机名）使我们能够代表客户充当 SaaS 供应商的前端。如果市场应用通过虚域集成，数据所有者可以选择使用 Cloudflare 的全新 SaaS 集成保护功能。
假设一个客户（在此示例中为 Acme 公司）要访问 SaaS 应用程序，URL 需要变为 saas.acme.com，因为该 URL 处于 Acme 的控制之下（而不是 acme.saas.com）。
这种部署方式允许 Cloudflare 部署在 SaaS 公司的前端，因为客户掌控着 DNS 主机名。通过代理流量，Cloudflare 成为唯一一个能够以编程方式访问 SaaS 公司 API 与数据的集成方，并能够透明地“交换”授权令牌——将其替换为有效令牌，同时利用密钥分割技术，为各个集成方签发独立的令牌。
请注意，在许多情况下，授权和身份验证流程不属于任何个性化/品牌主机名。事实上，OAuth 流程仍然会访问 SaaS 提供商 URL oauth.saas.com，这种情况非常常见。因此，在此设置中，市场应用需要为其 OAuth 和类似流程提供支持个性化/品牌 URL（如上图中的 oauth.saas.acme.com）。
归根结底，Cloudflare 为所有进出指定 SaaS 服务商的流量提供了完整的 L7 反向代理解决方案，从而满足核心安全需求，有效降低类似 Salesloft 数据泄露事件的影响程度。如果 Salesloft 当时是通过 Cloudflare 代理的域名进行集成的，那么数据所有者将能够：
了解在 SaaS 平台中谁或什么可以访问数据，以及这些访问请求来自何处。Cloudflare 已经提供分析和过滤工具，可帮助识别流量来源，包括托管位置、IP 地址、用户代理以及其他相关工具。
立即关闭对 SaaS 提供商的访问，无需在 SaaS 平台上轮换凭据，因为 Cloudflare 能够阻止来自代理的访问。
通过观察基线和流量模式，检测数据访问中的异常。例如，数据泄露流量流的变化会触发警报。
上述方案默认终端用户是那些数据面临风险的企业。但实际上，SaaS 平台自身如今也高度关注应用市场中的各类应用及其访问模式。从部署角度来看，为 SaaS 提供商提供额外的可见性其实更为简便——因为这属于标准的反向代理部署模式，而且我们已推出专为 SaaS 应用设计的相关工具，例如 Cloudflare for SaaS。
此部署模型允许 Cloudflare 代理所有流向 SaaS 供应商（包括所有 API 端点）的流量，从而能够洞察任何 SaaS 到 SaaS 的连接。为此，我们正在改进 API Shield 解决方案，为 SaaS 安全团队提供额外的控制力：
令牌/会话日志记录：能够跟踪 OAuth 令牌并提供会话日志，以用于审计目的。
会话异常检测：能够在给定的 OAuth（或其他会话）显示异常行为时发出警告。
令牌/会话替换：能够使用 Cloudflare 生成的令牌替换 SaaS 生成的令牌，从而实现快速轮换和访问锁定。
当然，SaaS 供应商可能会将其中一些功能作为其仪表板的一部分，向其终端客户开放。
上述两种部署方案均依赖于我们在不存储完整凭据的情况下控制访问的能力。虽然我们目前已为数百万个网站应用存储 SSL/TLS 私钥，但若存储完整的 SaaS 承载令牌，将会带来额外的安全负担。为解决这一问题，并实现前文提到的令牌交换与即时撤销功能，我们采用了密钥分割技术。
密钥分割技术将承载令牌通过密码学方法拆分为两个具有数学关联性的片段，分别称为 Part A 和 Part B。其中，Part A 会被发送至第四方集成服务（例如 Drift 或 Zapier），而 Part B 则保留在 Cloudflare 的边缘存储中。Part A 本质上只是一串随机噪声，无法用于 Salesforce 或任何要求完整令牌的 SaaS 平台的认证，因此这两个片段单独存在时均不具备可用性。
这就形成了一个无法绕过的控制节点。由于集成方仅持有令牌的 Part A，它们在进行 API 调用时必须经过 Cloudflare 的代理，无法避开这一环节。当某个集成需要访问数据时，它必须将 Part A 提交给我们的边缘。我们在边缘处获取令牌的 Part B，在内存中以微秒级时长重建完整令牌，随后转发经过验证的请求，并立即清除该令牌。这一机制确保完整的承载令牌永远不会存在于任何数据库或日志中。
这种强制协作机制意味着每一次 API 调用都会流经 Cloudflare，使我们能够监测异常情况、即时删除 B 部分以撤销访问权限（将事件响应时间从数小时缩短至数秒），并保持完整的审计追踪记录。更重要的是，这种方法大幅降低了我们存储敏感凭据的负担，因为即便我们的系统遭到入侵，攻击者也无法获取可用的令牌。
如果攻击者攻破了集成系统并窃取了 Part A，或者以某种方式突破了 Cloudflare 的存储系统并获取了 Part B，那么这两个部分中的任何一个都无法单独完成身份验证。这一机制从根本上改变了安全模型：从原本保护完整令牌，转变为管理各自毫无价值的拆分片段。同时，这也为安全团队提供了前所未有的可见性与控制力，使其能够清晰掌握数据在第三方集成中的访问情况。
我们很高兴能推进上述解决方案的开发，以便更好地控制和查看存储在 SaaS 环境中的数据，或者更普遍地说，存储在客户网络之外的数据。
如果您是担心此类风险的企业，并希望收到参与我们提前体验的通知，请点击此处注册。
如果您是 SaaS 供应商，愿意提供反馈并参与开发更好的 API 安全工具，以便将第三方集成到自己的平台，请在此注册。
我们期待助力您在 SaaS 到 SaaS 环境中更好地掌控自身数据。