克服服务网格对分布式应用集群安全性的限制

这是系列博客中的第四篇，涵盖了我们构建和运营SaaS服务的各个方面：

1. 分布式 Kubernetes PaaS 的控制平面
2. 分布式applications的全局服务网格
3. 分布式基础设施、应用程序和数据的平台安全
4. 分布式集群application及网络安全
5. 跨全球分布式平台的可观察性
6. 全球分布式平台的运营和 SRE
7. 面向分布式微服务的Golang服务框架

在之前的博客中，我们深入分析了使用加密技术保护我们的平台（基础设施、应用程序和数据）所面临的挑战。 本博客将讨论我们用来保护平台免受来自网络（来自互联网以及内部）的针对性攻击的技术。 由于应用程序不再受限于任何物理位置，传统的基于边界的防火墙和基于签名的安全解决方案不再有效。 我们将概述我们最初的零信任安全实施的缺点，以及为什么+如何通过机器学习和算法技术来增强它，以正确保护我们的分布式基础设施+应用程序集群。

TL;DR（摘要）

1. 我们的平台运行着数百个微服务（跨多个 Kubernetes 集群）以及跨多个云提供商（AWS 和 Azure）、我们的全球网络和边缘位置的一些单体应用程序，这使得我们的应用程序到应用程序和用户到应用程序的安全要求变得复杂。
    
2. 我们还被要求构建流程并提供强大的网络 + 应用程序安全解决方案，为我们的开发人员、我们的运营团队、我们客户的开发人员、他们的运营团队和他们的最终用户提供对共享基础设施的选择性访问。 由于我们必须满足 PCI-DSS、SOC 等合规性要求，这变得更加复杂。
    
3. 虽然我们已经基于全局服务网格和 API 网关构建了零信任解决方案，但它并没有解决许多安全问题，例如系统漏洞、资源耗尽、来自机器人/恶意软件的互联网攻击以及提供未经身份验证的访问的少数服务的需求。 此外，有时我们的 secops 团队很难从开发人员那里获取 API 信息——这对于依赖访问白名单的良好零信任部署至关重要。
    
4. 为了满足这些需求，我们的平台团队需要从供应商/云提供商处采购服务，或者为我们的 L3-L7+ 数据路径（此处详述）添加额外的安全功能 — 网络防火墙、应用程序防火墙、DDoS 保护、特权访问权限管理等。 鉴于现有的供应商/云提供商无法通过提供统一策略、可观察性和自动 API 发现功能的工具解决这些问题，我们不得不做出艰难的决定，开展内部项目来增强我们的数据路径和控制平面。
    
5. 作为将网络 + 应用程序安全功能构建到数据路径的一部分，我们最终添加了许多新功能 - 这是迄今为止在任何网络数据路径中都尚未实现的。 我们将算法安全功能与网络 + 应用程序流量的机器学习以及跨堆栈（网络、HTTP 和 API）工作的可编程策略引擎融合在一起。 因此，我们现在能够根据部署环境、流量模型和延迟需求提供不同的安全功能。 这使得我们的全球服务网格更加安全，减少了我们的 SOC 团队的误报数量，并显著减少了延迟和计算资源。

服务网格和零信任架构的局限性

我们的平台运行着多个团队的大量应用程序，这些团队在边缘、我们的全球网络以及 AWS 和 Azure 公共云中运营自己的集群。 虽然大多数工作负载都是使用 Kubernetes 进行微服务编排的，但我们也有一些非常大规模的整体式应用（例如 elasticsearch），我们使用 terraform 进行管理。 图 1 展示了我们平台的分布式特性。 例如，在我们遍布全球网络PoP（拥有几十到百余台物理服务器）中，我们都运行着数千个应用程序 pod。 然而，在边缘，我们今天拥有单独的客户部署，其中有 3000 多个活跃位置（每个位置有一到七个计算设备），运行着几十个应用程序 pod。

该平台完全是多租户的，每个节点运行来自不同客户（和我们自己）的工作负载。 由于其中一些应用程序暴露在公共互联网上，我们需要确保与这些应用程序的所有通信都是安全的。 正如我们在前两篇博客中概述的那样，我们构建了一个强大的身份、身份验证 + 授权系统以及我们自己的 L3-L7+ 网络数据路径 (VoltMesh)，用于为我们的服务网格和API 网关提供支持。 如图 2 所示，这使我们能够跨应用程序集群（mTLS）、用户（TLS/mTLS）和员工（mTLS）提供传输级安全性，以及基于身份验证+授权的访问控制。

虽然这种零信任实施提供了许多好处，但它并没有自动解决几个安全问题：

1. 系统漏洞——应用程序可能由于系统漏洞或授权但恶意的员工而受到攻击——需要有一种机制来检测这种情况，自动采取补救措施并提醒我们的 SRE 团队。
    
2. 资源耗尽——在很多情况下，由于设计不佳，即使是合法、授权的客户端访问也会慢慢耗尽应用程序资源。 这些情况会严重降低其他用户的性能。
    
3. 互联网攻击——由于我们的（以及我们的客户）许多基础设施和应用程序直接暴露在公共互联网上，这些资源不断受到恶意用户、机器人和恶意软件的攻击。 我们需要检测并保护这些资源免受拒绝服务、容量耗尽和入侵攻击，以便为其他用户提供良好的响应时间。
    
4. 未经身份验证的服务——虽然大多数应用程序都需要身份验证（零信任也需要），但在某些情况下无法限制应用程序。 因此，这些应用程序需要使用基于网络的解决方案进行额外的保护。

在过去 2.5 年该平台的开发过程中，我们还意识到我们的开发人员经常会整合开源应用程序、对其进行容器化，然后要求我们的 DevOps 团队将其部署到平台上。 然而，他们通常缺少这些应用程序内 API 级别交互的详细信息，而我们的安全团队需要这些详细信息来创建将通信列入白名单的策略。 这对我们的零信任安全实施来说是一个巨大的障碍，因为它要求白名单策略只允许应用程序使用的 API 并阻止所有其他流量。 每当我们对此要求做出例外时，它都会给一些应用程序留下非常基本的网络级别分段，从而增加了攻击面。

增强我们的零信任服务网格

因此，我们需要增强现有的零信任安全解决方案，增加额外的安全功能来处理上述问题。 我们列出了必须在平台中构建的一系列额外安全功能：

1. API 发现与控制— 建立在运行应用程序中学习 API 的能力，并自动生成应用程序/API 白名单策略，而无需依赖开发人员
2. 异常检测——能够检测并防范来自任何来源类型（受信任或不受信任的用户/应用程序）的流量异常行为
3. 行为分析——保护应用程序免遭资源耗尽、应用程序/API 攻击（互联网或内部网络），并防止互联网对基础设施和/或应用程序的容量攻击
4. 日志记录和可视化— 能够记录和跟踪所有访问，以满足未来取证和/或合规性需求

我们决定结合使用传统的基于签名的技术、统计算法和更动态的机器学习方法来解决这些问题。 这要求我们对 SaaS 后端进行更改，并在网络数据路径中添加新功能。

用于 API 发现和控制的深度学习

为了锁定平台，我们仅允许基于每个应用程序的 API 白名单的网络连接。这需要我们的安全团队与开发人员进行协调，并确保我们的可编程策略引擎获得正确的 API 信息。 我们很快意识到，我们的开发人员不可能为不是使用我们的服务框架构建的应用程序提供此信息。

由于我们的服务网格代理位于应用程序每次访问的网络路径中，因此我们决定通过对通过代理的每个访问进行运行时分析来了解应用程序公开的 API 和静态资源。 这种方法的挑战在于通过检查 URL 并分离动态生成的组件来识别 API 端点。 例如，对于 API“api/user/<user_id>/vehicle/”，代理将看到如下访问：

此类请求可能有数百万个，因此解读起来非常具有挑战性。 因此，使用深度学习和图形分析来识别这些相关请求中的动态组件。 我们将整个 URL 组件集表示为一个图，然后执行图聚类，使用捕获动态生成组件的特定属性的特征集来查找具有相似属性的子图，例如：

• 结构特性
• 节点的熵
• 图各部分之间的 Jaccard 相似度
• 使用易于理解的深度学习方法进行简单的字符串分类

结果，动态组件被分类并且系统的输出如下：

使用这种 API 机器学习，我们可以轻松自动地生成可由我们的服务网格代理强制执行的策略。 根据发现的 API 端点，我们还了解其他属性，例如哪些应用程序使用哪些 API 与其他应用程序通信、这些 API 的典型行为等。 这使我们能够构建一个服务图，帮助我们的安全团队可视化服务到服务的交互，以进行取证、发现和 API 级微分段。

识别防火墙的缺陷

在着手添加剩下的两项功能（异常检测和行为分析）之前，我们决定看看现有的解决方案是否可以帮助我们。 尽管市场上有许多边界防火墙和 Web 应用防火墙产品，但大多数解决方案都是针对保护面向互联网的应用程序的。 他们假设所服务的流量是网络流量，并为 HTML、javascript、sql、CMS 等提供有针对性的保护——使得编写签名和规则来捕获漏洞和已知漏洞变得相对容易。

虽然此功能对于我们的网络流量很重要，但我们还需要在我们的环境中服务越来越多的 API 和机器对机器流量。 为了解决这个问题，我们的安全团队必须编写不属于已知的典型网络规则（如 OWASP CRS）的应用程序特定规则。 通常安全管理员对应用程序知之甚少，并且由于环境的动态特性，跟踪应用程序的类型和结构以编写特定于应用程序的规则变得更加困难。 因此，虽然我们的平台团队在我们的网络数据路径中提供了此功能，但我们的安全团队并不经常使用它。

我们从网络中获得大量数据的另一个问题是，应用程序攻击随着时间的推移变得越来越复杂。 攻击者花费数天时间进行侦察，通过查看 HTTP/TCP 签名等来确定 API、应用程序、底层基础设施和操作系统类型的细节。 在这些情况下，传统签名和基于规则的方法用处非常有限，我们决定继续采用基于人工智能的方法来自动学习用户行为并强制执行好行为与坏行为。

行为分析的机器学习

大多数应用程序都有特定的工作流程（API 序列）和上下文（API 内的数据），不同的用例/部署是根据这些工作流程和上下文设计的，通常由应用程序的用户遵循。 我们利用这些属性并训练我们的机器学习算法来模拟用户与应用程序的典型交互中的“有效”行为模式。

我们的数据路径对每个 API 的请求/响应以及相关数据进行采样，并将其发送到我们的中央学习引擎，如图 3 所示。 该引擎不断生成和更新有效行为模式模型，然后由数据路径中运行的推理引擎使用该模型来警报/阻止可疑行为。

学习引擎查看许多指标，例如 API 的序列、请求之间的间隙、对相同 API 的重复请求、身份验证失败等。 我们会针对每个用户分析这些指标，并以汇总的方式区分好行为和坏行为。 我们还进行行为聚类来识别多种不同的“良好行为”序列。 让我们举一个例子来说明这一点：

• 该模型对许多用户进行分析，以定义一系列良好的行为。 每种颜色代表不同的 API 调用：

以下 API 序列将被系统标记为可疑/不良行为，系统将自动缓解这些行为或生成警报以便管理员进行干预

我们在一年前将该系统投入生产时，根据使用情况和客户反馈不断完善模型。 我们已经成功识别了以下类型的攻击： 

• 爬虫/扫描器对应用程序进行侦察，以查找漏洞并创建应用程序公开的所有 API 的地图
   
• 通过向易受攻击的 API 发起多个攻击媒介来持续进行恶意活动
   
• HTTP 级拒绝服务攻击导致资源耗尽（例如多次尝试登录 API）
   
• 为获取信息而设计的机器人会泄露数据（例如，竞争对手从电子商务网站获取定价信息）
   
• 暴力攻击——登录名/密码的字典攻击
   
• 识别优质机器人（例如 Google、Bing 爬虫）

话虽如此，我们也意识到这种方法存在一些问题——它无法发现低速和慢速攻击（暴力破解、应用程序拒绝服务、扫描仪），我们需要应用异常检测技术。

基于算法+人工智能的异常检测

有时，我们会看到高度复杂的攻击，这些攻击使用大型分布式僵尸网络，而这些攻击无法通过我们的行为分析技术的监测。 此类攻击的示例包括： 

• 分布式暴力破解攻击
• 基于分布式字典的账户接管攻击
• 分布式扫描器可查找漏洞并从多个客户端利用它们
• 来自高度分布的僵尸网络的 HTTP DoS 攻击
• 僵尸网络针对一小部分计算密集型 API
• 僵尸网络瞄准大量数据密集型 API 以耗尽资源

由于我们的网络数据路径正在从全球网络中的每个节点收集信息，因此对特定应用程序的聚合指标（如请求率、错误率、响应吞吐量等）进行分析变得相对容易。 通过这种分析，我们可以检测分布式攻击，并通过识别可能属于此类僵尸网络的用户来减轻攻击（在每个节点）。 让我们举一个例子，我们试图通过查看请求率来检测不同时间窗口（过去 5 分钟、30 分钟、4 小时、24 小时）内的异常，如果给定时间窗口内的请求率很高，那么系统将执行以下更深入的访问日志分析： 

• 分析源 IP 地址分布是否高于或低于典型值。 如果请求来自大量唯一的源 IP，则表明存在高度分布式的攻击，这将触发对每个源 IP 进行更激进的用户行为分析。
• 对每个源 IP 地址运行更积极的用户行为分析，以分配怀疑分数并采取配置的缓解措施。
• 如果大多数请求都发往较少数量的 API 端点（比平时更多），则表明存在暴力破解攻击或 DoS 攻击。 如果 APIEP 传播范围比平常大，则表明存在分布式爬虫、扫描器或 DoS 攻击

虽然异常检测一直是防火墙设备中入侵检测和预防（IDS/IPS）的重要技术，但这些设备无法减轻全球应用层攻击。 凭借我们在全球平台上执行 API 标记和学习的能力，我们现在能够从源头上抑制分布式网络的攻击。

机器学习为应用 + 网络安全带来的好处

虽然我们对基于服务网格和 API 网关的零信任实现非常满意，但我们意识到它不足以全面保护分布式应用程序集群免受漏洞和恶意攻击。 我们必须通过机器学习来增强行为分析 + 异常检测，同时结合传统的签名 + 基于规则的技术，以提供更好的安全解决方案。

我们在 L3-L7+ 网络数据路径中添加分布式推理以及在集中式 SaaS 中运行学习核心，看到了三个显著的收益： 

1. 端到端零信任网络——我们现在能够在整个平台上实施 API 级微分段（100% 没有任何间隙）——整个网络是一个具有 API 级访问和零网络级访问的全球分布式代理。
    
2. 通过不断调整模型的能力，减少了误报（减少了 82% 以上） ，我们显著减少了 NOC 和 SOC 团队必须处理的误报数量。 这是传统工具的一个大问题，因为它们会发出大量警报，导致它们完全无用。
    
3. 通过将更多由传统规则和基于签名的算法执行的任务缓慢迁移到我们的新机器学习核心，显著降低延迟和计算利用率。

网络和应用程序安全是一条永无止境的跑道，看起来我们还有大量的新功能需要添加。 我们将在不久的将来回来分享有关我们已经实施的增量算法和技术的更多见解。

待续…

本系列博客将涵盖我们构建和运营全球分布式 SaaS 服务的各个方面，该服务在公共云、我们的私有网络 PoP 和边缘站点中拥有许多应用程序集群。 接下来将是“跨全球分布式平台的可观察性”（即将推出）...