解释如何将 API 安全性从纵深防御扩展到零信任模型

“这种流行病给企业带来了巨大的紧迫感，要求它们尽快启动各种数字化转型项目，这几乎可以肯定是攻击激增背后的驱动因素，”

— Peter Klimek ， Imperva技术总监。

DYKT API 已经使用了 20 多年。从那时起，API 发生了翻天覆地的变化——从有限的一组公司使用 API 来解决特定需求，到最近在各种规模的 DevOps 环境中使用的无穷无尽的集合。 API 可以在应用程序开发中找到——敏捷开发，将客户和合作伙伴与服务联系起来，并推动数字化转型计划。

但在网络安全方面，根据ProgrammableWeb的研究，自 2019 年以来，平均每月新增 220 个 API 。然而，随着 API 的广泛采用，如今 API 暴露的敏感数据比以往任何时候都多，使它们成为有价值的攻击目标。

这篇文章介绍了如何将 API 安全要求从纵深防御映射到零信任模型。

背景 - API 安全状况

在进入如何保护 API 之前，让我们看一下当前 API 安全的威胁态势。根据Salt Security 的 API 安全状况报告：

• API 攻击在过去 12 个月内增加了 681%
• 95% 的受访者在过去一年内经历过 API 安全事件
• 34% 的受访者缺乏任何 API 安全策略
• 62% 的调查受访者承认由于 API 安全问题而放慢了新应用程序的推出

简而言之，我们可以看出大多数企业都没有为基于 API 的攻击做好准备。此外，依赖现有的安全和 API 管理工具，例如 Web 应用程序防火墙 (WAF) 和 API 网关，可以有效地防止安全事件并提供错误的安全感。

左移怎么样？

该报告强调，左移策略无济于事，至少在 API 安全方面是这样。超过 50% 的受访者表示，开发人员、DevOps 或 DevSecOps 团队负责 API 安全。在预部署工作上花费更多的公司包括：

• 安全编码最佳实践，
• 代码扫描，和
• 手动测试

然而， 85% 的人承认他们的安全工具在预防 API 攻击方面无效——证明这些 DevOps 安全实践虽然重要，但还不够。

那么，组织应该建立或采用什么保护措施来抵御 API 攻击？要回答这个问题，首先，我们需要了解针对API的常见攻击。

当前的威胁形势

在最近谷歌云的API安全报告中，API安全威胁的来源有：

1. 错误配置的 API (40%)，
2. 过时的 API、数据和组件 (35%)，
3. 垃圾邮件、滥用、机器人 (34%)。

根据Imperva 研究实验室的另一项研究，最重要的攻击是远程代码执行 (RCE) 或远程文件包含 (RFI) ，跃升了 271%。黑客使用 RCE 或 RFI 攻击来窃取公司信息、破坏服务器和网站篡改，甚至控制网站。

根据OWASP API 安全的前 10 名，其他 API 漏洞是：

• API DDOS扇出，
• 零日 API 攻击，
• 被盗凭证，
• 周边突破口，
• 破坏的横向移动，
• 出口处的数据泄漏，或
• 资源劫持

网络安全：API 是新的端点

如上所述，API 安全风险增加的第一个原因是采用的爆炸式增长——一个环境中有许多 API。例如，一个 Kubernetes 应用程序有数百个 pod 和微服务。他们每个人都管理着六个或更多的 API。 （这是 DevOps 环境中的典型场景）。

现在补充一下，这些微服务工作负载（以及 API 调用）是临时的，跨云运行，以多语言方式编写，并使用不同的协议。或者简而言之，API 为安全团队监督 API 操作创造了一个复杂的环境和挑战。

其次，API 从来没有打算暴露给外界。然而，这就是我们在网络协议栈中发现的漏洞所面临的问题。那些开发者永远不会想到他们的作品会在今天被大规模采用。因此，API 具有先天的漏洞和内置的风险。

第三，攻击和破坏变得越来越复杂，尤其是那些在身份验证和授权后阶段执行的攻击和破坏。它们在 API 数据有效负载中也更加深刻。

因此，需要关注身份验证和授权之外的安全性，还有应用程序和 API 数据有效负载层。一种方法是将 API 安全性视为我们传统端点安全性的类比。

DiD（纵深防御），又来了！

安全问题也发生在我们日常生活中计算机以外的地方。从人类历史早期开始，各国就在探索和实践多重防御机制和防御工事。这些经验和想法也适用于端点、网络和 API 安全。

假设 Endpoint Software 类似于城堡：

• 身份认证等同于指挥官身份证明，
• 蜜罐（或战争中的诱饵）引诱攻击者远离高调目标。
• 在这些战争策略中，最有效的方法之一是纵深防御（DiD）。

DiD 方法可以分为两个方面：

1. 边界防御（反恶意软件签名）
2. 入侵检测/预防 (IDS/ IPS/ EDR)

我将用这些 DiD 领域一一解释 API 安全。

1#边防

边防是最基本的防御方式。几乎所有公司都投资边界防御。在端点安全中，我们使用签名和 IP 黑名单来防御已知的攻击方法。

作为保护的前线，这一层旨在阻止 90% 的所有攻击，这些攻击是无针对性的，由不具备扎实技术知识或黑客思维的非熟练人员发起。在这种场景下，边界防御足以抵御这些无差别的攻击。

在API安全方面，WAF在这方面做得非常出色。它提供边界防御的标准功能：

· IP 白名单和黑名单，

· WAF规则引擎，

· 速率限制，以及

·故障注入/模糊测试。

结合使用时，它可以阻止几乎所有商品攻击。

2#入侵检测（++）

安全可见性是攻击预防的关键要素。在黑客突破边界后，我们需要一种正确的方法来识别哪些文件/进程/流量可能与恶意攻击有关。在 Endpoint Software 中，我们有基于主机的 IDS/IPS来检查通过前门的所有请求。

一些其他检测方法，例如APT 检测和机器学习，可以更直观地评估针对目标攻击。

实施行为分析的其他典型方法是：

·蜜罐，

· EDR（端点检测和响应），以及

· 威胁情报（文件和进程）。

在所有这些方法中，蜜罐是最古老的方法之一（自战争开始以来）。通过将一些高价值目标引诱到陷阱/诱饵中，他们可以分析敌人的行为，甚至帮助定位他们。如今，我们采用这些策略并将它们变成欺骗技术。

在现代世界中，API 安全解决方案提供了上述技术的组合；例如，蜜罐中收集的工件随后可以发送到威胁情报源中供 WAF 或 Web 应用程序和 API 保护 (WAAP) 使用。在这一层，我们有类似的技术来提高可见性和阻止攻击的速度：

· 网络蜜罐

· NDR（网络检测和响应），以及

· 威胁情报（有效载荷和网络）。

使用机器人执行“凭据填充”攻击是另一种常见的攻击策略。它试图窃取高价值资产。该策略是找到一种方法来获取登录信息，例如泄露的电子邮件/密码，然后尝试批量访问网络位置（横向移动）。迄今为止，打击撞库最有效的防御措施是从源头入手：从真实用户中识别机器人，拦截机器人发出的所有请求。

因此，一些 AppSec 工具还配备了反机器人功能，这是一种特定类型的行为检测，作为 API 安全的一部分。

当 API 安全遇到零信任

我并不是说 DiD 没用。 API 和应用程序安全解决方案，例如 WAF 保护组织免受商品攻击。然而，如前所述，API 会创建一个复杂的环境，错误的配置会使问题恶化。

对于未清理的边界，可能需要的不仅仅是 DiD 方法。零信任基本上为攻击者到处设置了障碍，使他们无法在环境中横向移动。

零信任是一个全面的安全框架和策略。它需要对所有终端、BYOD（自带设备）、服务器、API、微服务、数据存储和内部服务进行严格和统一的验证步骤。

零信任的主要思想是将集中执行点转变为应用程序（包括 API）的每个路径中的多个微检查点。无论是内部访问外部请求，手机还是PC，API调用还是HTTP请求，普通员工还是CEO，都不可信任。

为了在不停止或减慢您的应用程序的情况下有效地实现这样的目标，编排和自动化将是关键的决定步骤。

为什么编排和自动化对于零信任 API 安全至关重要？

ZTA、NIST SP800–207 |图片由作者提供

为了解释这两者的必要性，让我们仔细看看零信任架构的一个支柱——用户/设备访问信任。这种防御方法类似于在机场检查站出示护照和身份证购买酒类。

没有相应的身份和权限，是无法进入相关系统的。这是 API 网关的强大之处，因为它提供了一些关键的身份验证功能：

• 键的自动旋转
• 与多种身份验证系统集成，例如 OKTA 和 Auth 2.0
• 支持流量的 TLS 和 mTLS 加密

用户和设备信任有两个核心组件：

• 身份和访问管理
• 具有集成安全性的 API 网关

想象一下，在机场、高铁等所有交通枢纽增加身份识别设备。您还必须了解往返所有交通枢纽的所有路线并实施保障措施。

在大型企业中，会有数百个系统、数万个 API 和微服务以及数十万个客户端。除非我们拥有无限的资源和时间，否则 DevOps、安全或应用程序团队无法在现代应用程序中定义和手动添加数十万个微识别检查。

零信任架构、应用程序、工作负载和数据的所有其他支柱也需要采用相同的逻辑。需要的是一种解决方案：

1. 它采用现代建筑，
2. 在异构环境中工作，
3. 减轻这些风险（不仅仅是商品），并且
4. 在多云环境中以自动化方式完成所有这些工作
5. （可选）开源，以实现技术敏捷性和创造力。

Idea 零信任 API 安全性是什么样的？

为了适应 API 中复杂和异构的环境，零信任 API 安全解决方案必须能够部署为多种格式，从而支持不同的设置，例如：

• 码头集装箱，
• 一个独立的反向代理，
• 网络/应用服务器代理，或
• 嵌入在 Kubernetes 入口控制器中。

在云和现代应用程序架构的支持下，自动化和可扩展性将得到照顾。

但为了保持编排，“代理”（或微执行点）必须能够部署在现有应用程序之上，而无需更改现有架构，同时确保最小延迟和最大控制。

在考虑部署和架构形式因素后，安全级别不降低也很重要。要真正采用零信任，安全处理应该在本地完成，而不是传输到其他云或引擎，例如云沙箱进行分析。

如果外部各方不受我们的控制，则很难验证数据/网络访问信任。在本地执行此操作还有一些其他好处，例如：

• 敏感数据不会离开受保护的环境。
• 您不需要与第三方共享证书和私钥。
• 处理流量不依赖于第 3 方正常运行时间。

最后一部分是考虑编排。理想情况下，我们需要一个可以融入应用程序环境的解决方案，而编排器可以管理这些代理并处理以下操作：

• 代理注册/注销
• 政策更新
• 配置更新
• 软件更新
• 记录和
• 数据同步。

简而言之，零可信 API 安全性应该以各种形式融入现代应用程序环境。同时，最好的解决方案应该能够提供编排和传统解决方案所能提供的所有安全功能。

如您所知，零信任并非完美无缺。零信任解决方案不能完全防御零日攻击或社会工程攻击，尽管它们可以显着减少攻击面和影响。

最后的话

API 已成为现代应用程序的中枢神经系统，将关键信息和数据从应用程序的一部分带到另一部分，或从一个应用程序带到另一个应用程序。因此，在保护应用程序时，API 安全性应该是重中之重。对于公共 API 尤其如此，全世界的用户都可以访问软件组件和敏感数据。

采用零信任框架将重点从单一的保护措施转移到不同的支柱（用户、设备、网络、应用程序和数据）。这可以帮助您确保 API 访问的每个部分，无论是在边界内还是边界外，都采用最小权限方法并受到持续监控。

感谢您阅读。愿 InfoSec 与你同在🖖。