API 网关是新的战略控制点（但仍缺乏安全性）

从单体应用到微服务生态系统的转变使得 API 成为一个战略性和关键的控制点。 尽管Web应用防火墙(WAF) 一直是保护基于 HTTP 的应用的主要工具，但 API 缺乏同等的控制来实现足够的合规性、安全性和审计。 随着 API 和非人类流量超过 Web 应用程序流量，安全控制也需要进步。 安全领导者应该利用新兴趋势作为机会来更多地了解如何保护 API，并将其作为推动其组织内 API 安全性改进的手段。

API 爆炸式增长无处不在– API 的激增将会持续下去。 此外，推出 API 的可能不仅仅是 DevOps 团队。 组织的其他部分，例如营销团队，可以发布自己的 API 甚至使用第三方 API 作为营销工作的一部分。 对于安全团队来说，准确清点正在使用的 API 是至关重要的第一步。

协作是关键——安全团队需要与 DevOps 合作来设计和实施足够的 API 安全控制。 DevOps 希望快速发展。 安全团队需要了解 DevOps 动作并制定可集中管理和自动化到 CI/CD 流程的安全控制。

API 网关安全性滞后——当今的 API 网关通常专注于身份验证、版本控制和分析（用于计量和计费）。 虽然这些安全控制很重要，但它们并不能为 API 提供全面的保护。 足够的 API 安全性需要防御对身份验证服务、第 7 层 DoS、数据泄露、漏洞利用、注入和异常的攻击。

API 仍处于危险之中

API 是当今数字业务平台的核心，是关键的控制点。 API 通常设计为向外部公开并由业务合作伙伴、客户和微服务访问。 就像 Web应用一样，API 可以成为需要充分保护的敏感数据的门户。 Venmo、Facebook 和 Salesforce 等组织最近发生的与 API 相关的事件可以作为 API 安全重要性的教训。 F5 实验室在此重点介绍了其他值得注意的 API 故障。

与许多技术进步一样，安全性往往落后。 API 安全性也不例外。 随着 API 驱动的经济不断发展，安全专家可能会因解决 API 安全问题的数量、速度和复杂性而不知所措。

API 的大规模扩散将会持续下去。 随着应用成为企业的焦点，API 的激增将持续激增。 可编程 Web API 目录在 2019 年发布的 API 数量迅速增加（每月数百个新 API）。 我们预计这一数字将继续攀升，特别是在行业部门推动基于 API 的互操作性的情况下。 欧盟的PSD2（修订的支付服务指令）就是一个很好的例子。

安全性必须与 CI/CD 管道保持同步。 支持“版本控制”的 API 网关使 API 提供商能够不断添加新功能和特性，而不会破坏现有的客户端集成。 这对于 CI/CD 来说非常好，但是如果安全性减慢了这一进程，它就会直接影响业务并抵消敏捷开发的好处。 为了跟上这些环境，安全控制必须实现自动化并集成到发布过程中，以便安全团队可以集中执行常见控制而不会影响发布周期。

不同的 API 安全所有权是一个因素。 整个组织都在使用 API——移动应用程序、微服务、云端和本地。 整个组织的可见性和 API 库存功能仍在开发中，因此某些 API 超出了安全团队的职权范围。 必须教育跨组织领导层和利益相关者执行一致的安全实践和控制。

API网关安全性不成熟。 目前有许多供应商定位 API 网关——例如 MuleSoft、Google（Apigee）、Kong、Istio 和 Oracle 等公司。 这些提供了所需的 API 网关功能集，例如版本控制、路由、分析/计量和身份验证。 这些都有各自的优势和增值，但是需要与其他安全网关服务一起实施全面的安全控制，以防止访问冲突、注入、DoS 和漏洞利用。
_____

现在场景已经设定好，请继续关注下周的博客（链接添加到此处），我们将深入探讨您可以采取哪些措施来应对上述挑战……