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

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

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

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

究竟什么是“API 安全”？

解决 API 安全难题

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

设计 API

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

安全控制

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

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

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

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

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

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

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

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。