API 网格提供的安全控制效果如何？

现代系统依赖于通过各种网络公开的 API（应用程序接口）的复杂系统。很多企业借助 API 来传输数据和连接服务，提供便利。但同时，近年来一些严重的数据泄露都源于 API 遭到攻击和破环，导致敏感的信息被不法分子利用。

那什么是 API 安全，它如何融入到整体的安全计划？

所有应用程序都使用 API（比如，对内核的调用、软件开发工具包、密码库和 SOAP 协议）。如今，供应商提到的“ API 安全”是指这些 API 的子集 —— 通过网络公开的那些 API。

就本质而言，这些网络公开的 API 使信息能够自由传递以及在软件组件之间进行交互。攻击者有机会可以通过公共网络、云和专用网络的暴露端点来破坏系统的组件。一些知名公司（包括 USPS、T-Mobile 和 Salesforce 等）的重大违规事件是源于暴露或使用不安全的 API 端点。那么问题来了，要如何了解软件安全计划是否满足企业所需的安全控制的要求，以确保使用和创建的 API 是安全的？首先，你需要定义什么是“API 安全”。

究竟什么是“API 安全”？

API 安全是对企业创建和使用的（暴露在网络中）API 的保护。当然，这意味着需要使用与 API 紧密相关的通用安全控制：速率限制以及用户、服务和请求的身份验证和授权。这还意味着了解数据来源，以及在查看组成的系统时，在设计或查看讨论时准确地寻找到上下文的位置。对于软件安全领头企业来说，这意味着应用程序安全计划可以在适当的时间捕获活动并将其应用于暴露或使用 API的软件。强大的 API 安全性不只是购买一些新工具，还源于一种安全文化，它涉及整个软件安全计划中的活动。

解决 API 安全难题

诸如微服务架构等的流行软件开发趋势已将与软件安全计划（SSI）相关的软件单元从“应用程序”（或整体式）扩展至 API 的许多子组件。这些子组件具有自己的生命周期和合同，并必须遵守安全控制措施。软件安全企业可以从以下方面提升安全性：

设计 API

API 是被用在前端客户端（胖客户端或浏览器）和后端系统之间，以及后端组件之间。进一步考虑，单个 API 端点可能最终会同时处理前端和后端请求。当各个 API 端点暴露于各种已知和未知的调用方（网关或负载平衡器的上游消耗、组成或包装）时，很难确定单个 API 端点必须执行哪些安全控制。应用程序安全主管可以做出的一个决定是，推动使用 API，以明确记录提供商和使用者应承担的安全责任。

架构师还面临识别 API 跨领域问题的麻烦。安全领导者应该注意一些安全活动，例如统一访问控制，以及那些与业务逻辑接近的活动，例如统一客户身份认证。

安全控制

关于安全控制，API 安全中有多个抽象级别：业务逻辑中的控制（防止滥用）；保护业务逻辑的控制（身份验证和授权）；以及最终由架构启用或定义的架构安全控制（API 网关和微细分）。

由架构决策支持的安全控制，对于在 API 安全的环境中的应用程序开发而言相对较新。除了应用于业务逻辑的安全控制之外，还扩展到诸如速度检查、身份验证和授权决策等。我们需要知道如何最好地隔离一组 API，并在那里通过网关启用重要的安全控制。例如，微分段是否能达到要求？服务网格提供的安全控制效果如何？

一些架构决策试图提供阻塞点，以便安全架构师更深入地了解这些分布式系统。虽然某些架构决策需要集中管理的方法，但有的则启用端点强制的方法。

当然，我们建议进行威胁建模。应用安全企业必须开始识别各种类型的 API（第一方、第三方、客户或使用者）的风险、每个 API 端点的关键控制、针对采用很多 API 的架构（如微服务）造成的问题提供可接受的解决方案，以及是否将卖方索赔作为风险管理计划的一部分。

物料清单

应用安全企业需要了解他们的 API 足迹；衡量使用流程和工具来覆盖该足迹的工作；跟踪、记录正在进行的安全活动并确定优先级；并为各种类型的安全分析提供了丰富的上下文。当与程序所有者讨论 API 安全时，我们经常会发现现有的清单解决方案无法提供这些内容。安全计划负责人应该仔细研究是否可以采用现有的物料清单解决方案，或者是否必须采用新的解决方案。

安全测试

如今的安全测试与以往一样，对于深入了解上游软件安全实践的有效性都很重要。API 安全测试对手动、自动或者混合测试都提出了新挑战。其中上下文关联是一种。如果测试人员没有输入或感知威胁模型的能力，则无法找到对 SSI 不利的高风险问题，得不到及时修复。

静态分析工具可以有效地识别特定于语言的软件安全问题，或可以很好理解的注入攻击，对于那些使用大量 API 的代码库仍然有效，但是前提是这些工具必须对用于公开这些 API 路由的库和平台进行建模。有的企业已经采用静态分析推动安全控制（例如，使用身份验证和授权库），并可用于 API 安全。

动态分析可以生成 API 覆盖范围，其典型方法包括对客户端（或工具）、行为以及使用规范进行测试。该解决方案不是构建一个工具，并强迫开发团队使用一种测试工具，而是去支持各种可能的测试。

现代应用程序和系统依赖于通过各种公共和专用网络公开的 API 的复杂系统。我们可以采取一些步骤来了解这些更改如何影响我们的软件安全计划的各个要素，并确保在正确的时间和地方，将安全性内置到暴露在或使用 API的软件中。
       责任编辑:pj