聊聊API 安全

API 安全的现状

随着互联网的高速发展和技术的日趋成熟，人们在享受技术所带来的便利之时，也开始关注技术层面的安全问题。

近年来，应用市场成为各大互联网平台企业的最爱，Facebook、Twitter、新浪微博、微信公众号、抖音等均使用了这种模式，即平台和第三方开发者之间建立一种合作共赢机制，平台方允许第三方调取数据开发应用并部署在平台上，从而丰富平台内容，增加用户黏性，第三方则通过提供优质内容或程序实现引流和变现。多产品互动虽然丰富了用户的使用场景和易用性，但也为隐私保护埋下了隐患。

Salt Security 是一家 API 安全公司，它提供了一个 API 保护平台来防止攻击，它使用机器学习和 AI 来自动连续地识别和保护 API。

根据 Salt Security 2022 年 API 安全的调查数据显示，在 250 多位受访者中：

有 95% 的人表示他们在过去 12 个月内经历过 API 安全事件；
只有 11% 的受访者表示正在使用包括专用 API 测试和保护在内的 API 安全策略；
当被问及他们对公司 API 计划的最大担忧时，40% 的受访者强调安全漏洞是他们最担心的问题；
40% 的受访者正在努力解决 API 至少每周都在变化的问题，9% 的受访者表示他们的 API 每天都在变化。

而根据 Salt 客户的相关数据统计，94% 的 API 攻击发生在经过身份验证的 API 上。从上述采访和客户数据的反馈来看，绝大多数公司都经历过 API 安全事件，但只有 11% 的公司制定了包含专用 API 测试和保护的 API 安全策略。

因此，对于一家公司而言，要构筑什么程度的安全防线，才能抵御绝大部分安全攻击呢？

上述提问并不是有了互联网之后才存在的问题，而是在人类几千年的战争历史中，各个国家都在探索和实践各种防御策略和防御工事，这些经验和思路同样也适用于网络安全领域。比如：WAF 之于城墙，身份认证之于兵符，蜜罐之于草船借箭。

而这些战争策略中，纵深防御是行之有效的方式之一。

纵深防御是什么

纵深防御（Defence-in-Depth，简称 DiD），是多层、立体的安全防线，其工作原理是在每一道防线上提供不同类型的保护，以便成为阻止攻击的最佳手段。这些防线可以防止不同类型的安全问题，全方位覆盖多个领域。

目前纵深防御从纵深层面上大概可分为以下 3 种不同的防线。

边界

边界防御是最基础和最常见的防御类型，几乎所有的公司都会在边界防御上进行投入，比如 WAF。通过正则表达式、IP 黑名单等方式来防御已知的攻击手段和安全漏洞。

大部分所谓的攻击，都是由“脚本小子”发起的，他们并没有很强的技术能力和黑客思维，只能通过一些脚本和工具，批量对目标进行尝试性攻击。这时候，边界防御就可以很好地抵挡这些无差别攻击。

虽然从技术层面看，WAF 并没有特别高的技术含量，但它一直是必备的防御手段之一，并且部署在防御最外层。

除了 WAF 之外，还有一些专门针对 Bot 的安全防御工具。使用 Bot 进行“撞库”攻击，是盗取账户等高价值数字资产的常见手段。一般的攻击方式主要通过购买已经泄漏的 Email 或密码等登陆信息，然后批量登陆其他网站。这种情况下，最高效的防御方式就是识别出 Bot，然后拦截 Bot 发出的所有请求。

Bot 拦截的基本原理即设备以中间人的形式串接在服务端和访问端之间，当服务端返回响应页面时，设备在返回页面中插入 JavaScript，要求访问端（浏览器或黑客工具）执行 JS 并计算出相关 Token 并放入 Cookie 返回，设备收到 Token后进行判断，判断对方是否为黑客工具并采取相应动作。

这类产品还可以对页面中的指定内容（比如页面中的 URL 或表单内容）进行加密。从理论上讲，这种加密程度难不倒一个“意志坚定”的密码学爱好者（因为客户端和服务端之间并没有实现一个完美的密钥建立机制），但对付那些熟练的渗透工具使用者已经足够。

在常规的企业服务端架构中，WAF、SSL 网关、流量网关和 API 网关等组件，都是串联的上下游关系，这些组件可以分开部署也可以合并为一个统一的基础组件。

站在 API 网关层面，我们以 Apache APISIX 为例，APISIX 在边界防御上也提供了一些常见的能力，比如 IP 黑白名单、WAF 规则引擎、故障注入、限流限速等。将这些能力组合起来使用时，就可以利用网关阻断大部分无差别的安全攻击。

观测

在安全领域，最可怕的不是发现了安全事件，而是从来没有发现过安全事件。后者则意味着，你的业务可能已经被入侵了很多次但是仍毫无感知。

感知到安全风险并能够进行持续的观测，是对抗“有目的攻击”中最重要的一步。在黑客突破了最外层的边界防御后，我们就需要可观测性的能力，来识别哪些是潜在的恶意攻击流量。

在观测防御层面，常见的手段如蜜罐、IDS、NTA、NDR、APT（Advanced Persistent Threat）高级持续性威胁检测、威胁情报等。

其中蜜罐是历史最悠久的手段之一，通过模仿一些高价值的目标来给恶意攻击者设置陷阱，进而分析攻击行为甚至定位到攻击者。而 APT 检测和一些机器学习的手段，就不太好直观地评价效果。因为在真正的生产环境中，机器学习的效果并不会很好，因为在安全层面，机器学习还是会出现误报的情况。

因此对于大部分企业用户来说，能够在这个层面做好日志收集和分析、行为追溯和电子证据、及时发现异常行为，就已经足够使用了。

回到 API 网关层面，APISIX 在可观测角度可以做到更多的事情。

首先是可以进行 Tracing、Logging、Metrics 这些日志数据和统计，通过定位到每一个请求，来进行溯源、记录日志进行安全策略调整、标记异常流量或参数等。在 APISIX 中主要是在四层和七层协议上接入其他可观测性组件，如 SkyWalking、Datadog 等。

其次可以通过插件的编排来模拟出蜜罐和高价值标的，来迷惑攻击者。比如通过 APISIX 的 workflow 插件，可以在流量层面进行非常精准的控制。比如当条件 A 成立时执行某个行为，条件 B 成立时执行另一个行为等。通过这种更加清晰的方式，让用户在网关层面更加方便地调度各种业务流量，及时做出响应。

当然也可以通过流量镜像的功能，把部分请求发送到并联或串联的安全检测设备上，进行快速的安全判断，来阻断攻击。比如说像一些检测 ABT 攻击这样的东西，它可能会比较慢。那如果利用网关上把这些 API 流量镜像到一个安全的设备上进行分析，分析完之后再把数据导回。

身份

当攻击者突破了外层的双防线进入到内网时，就是身份认证和访问控制发挥作用的时候了。

这种防御手段的场景类似于，人们在机场和火车站刷身份证进站或者在商场和写字楼扫描场所码登记等。没有对应的身份和权限，是无法进入到对应的系统中去。

这层防线主要体现企业业务的安全基本功，也体现一个企业的信息科技实力。很多公司的内部系统并没有健全的身份识别和权限控制系统，因为这些系统的搭建需要长期和持续的投入。

从安全的本质讲，第三道防线是最重要的。因为边界防护和安全威胁观测的支持，在很大程度上都是在帮助第三道防线。边界和观测的安全防御是投入产出比的平衡，是误报和漏报之间的平衡，所以一定会有漏网之鱼进入到内网应用系统的门口。

这道防线也是 API 网关大展身手的地方。以 APISIX 为例，比如：

实现对接 JWT、Key Auth 等各种身份认证方式；
实现对接 Okta、Auth 2.0 等各种身份认证系统；
通过 APISIX 进行流量的 TLS 和 mTLS 加密；
对接 Vault 、KMS 等密钥管理服务，支持密钥的自动轮转；
国密的支持。

以上这些角度实现的话，通过 API 网关就能提高你的 API 和微服务领域的安全等级。

上文中描述的这几层防御措施，是需要多个部门和多个工具的通力配合，才能有效地阻断安全攻击。当然，这些多层次防护，都可以在 API ⽹关层面进行一些配置进行抵御。

那么，有没有一种更有效的方式，也就是所谓的“银弹”，来解决所有的安全问题呢？

从“非黑即白”到“非白即黑”的安全策略

安全届一直在思考这个问题。绝大部分的安全防御和检测手段，都是在海量的数据中，寻找少数的安全威胁。这种操作无异于大海捞针，而且不可避免的会出现误报和漏报。

如果我们转换一个思路，把“找出坏人”变成“识别好人”，是不是就柳暗花明又一村了呢？

十几年前，就有防病毒软件公司开始进行这样的尝试，他们的出发点是这样的：既然 Windows 系统和常用软件是固定的，那么我们就把这些软件都加入到白名单中，其他的可执行程序我就一个个识别，剩下的不就是病毒了吗？这样的话，任何新的病毒都逃不过杀毒软件的法眼。这个方案相当理想化，从想法到落地可用，花了四五年的时间，但也不是绝对的“非白即黑”，而是分级管理。

在网络安全和 API 安全领域，“非白即黑”的思路更加适用。举个例子来说，假如某公司对外提供了支付的 API 接口，需要 Token 才能访问。如果遇到没有 Token 或者 Token 错误的访问，那么一定是恶意的请求，需要将直接拒绝。

在理想的情况下，所有的 API 都应该有类似的身份认证和访问控制，只有通过了身份认证才能访问。这样虽然不能防御“内鬼”、社会工程学和 0-Day 攻击，但会大大提升攻击者的门槛和难度，让攻击的成本变得非常高，使“无差别”攻击变得不可能。

对于攻击者而言，当 ROI（投入产出比）变得不合理的时候，他们就会马上调转枪头，寻找其他容易攻破的目标。

基于“纵深防御”和“非白即黑”的基本思路，逐渐发展出了“零信任”的安全框架，希望可以一劳永逸地解决网络安全问题。