为什么 API 是黑客梦寐以求的目标？
全球数字经济需要应用编程接口 (API) 将基于应用程序的服务连接到客户、消费者、合作伙伴和员工。 传统、现代化和新应用正在向基于 API 的架构发展，以加速应用开发并缩短产品上市时间。 将应用功能移得更接近客户以减少摩擦是分散式架构和 API 优先运动的起源。
不幸的是，通过 API 在应用开发中获得的效率正被它们给 IT 企业带来的风险所掩盖。 黑客已经了解到，当 API 保护薄弱或不受保护时，破坏 API 很容易。 没有人会争辩说API 需要安全实践；但是，业界对于保护 API 的最佳方法并没有达成共识。 以下是 API 需要比通常更多的保护的一些主要原因。
API 漏洞大部分未得到解决
由于 API 可见性和安全性较差而导致的重大安全漏洞越来越多，并且在可预见的未来还会持续下去。1 组织数字化的竞赛将会把更多保护不充分的 API 投入生产。 许多组织会尝试通过更好的设计和编码来解决 API 漏洞，但却发现与一般应用相同的安全漏洞 - 部分原因是安全性不是典型应用开发人员的核心竞争力，并且安全团队可能不了解其环境中的所有第三方互连。
API 蔓延令人震惊地普遍
API 蔓延的核心是缺乏包含治理和最佳实践的整体战略。 敏捷应用开发导致同一 API 有多个版本，而没有 API 版本控制的好处。 转向微服务导致应用包含数十个 API。
非托管 API 会创建恶意 API、影子 API 和僵尸 API。 到2030年，API数量将接近20亿，这将进一步加剧这一问题。2
API 网关不足以保护复杂生态系统中的 API
如今，在分布式云环境中运行已成为常态。 但是，使用专用 API 网关作为控制安全性的单一入口点有局限性，包括单点故障和性能下降。 由于 API 网关如今已成为 API 基础设施的关键组件，因此很明显，API 的激增会增加 API 网关的部署，从而导致 API 网关蔓延。
Webapplication防火墙 (WAF) 仅部分保护 API
现代 WAF 为 API 协议（包括 GraphQL 和 gRPC）提供了强大的保护和安全性，并为关键软件漏洞提供了权宜之计——但它们通常不提供检测混合和多云架构中的高级威胁所需的 API 可观察性。 许多 WAF 缺乏动态 API 发现、自动检测和威胁缓解、测试以及 OpenAPI 文档规范自动化和执行功能。
现在我们知道了为什么黑客喜欢 API，那么我们该如何保护它们呢？
利用法规和标准为 API 保护项目争取支持
监管机构已经注意到 API 带来的风险，并鼓励公司在整个 IT 企业（包括第三方）中降低风险。 美国 财政部和消费者金融保护局（CFPB）向需要保护 API 的合规实体发布了强有力的指导。 从标准角度来看，PCI DSS v4 要求 6.3.2 要求 API 安全，而自 2007 年以来 NIST 800-95 安全 Web 服务指南建议 - 基于微服务的application系统的安全策略 800-24 规定了安全 API 管理。
关注架构
API安全架构必须考虑与分布式 IT 企业集成，包括多云、区域边缘和服务层。 该解决方案应该可以部署到任何硬件、虚拟化环境、docker、Kubernetes 等。 该解决方案必须允许安全策略通过其生态系统遵循 API。 以下是用于保护 API 安全的参考架构的示例。
最后的想法
黑客早就意识到 API 存在与 Web应用相同的安全漏洞，包括薄弱的身份验证和授权控制。 他们已经熟练地利用 API 漏洞、滥用业务逻辑和创建零日漏洞来轻而易举地访问 IT 企业。
个人数据是个人的财产，而不是应用或服务提供商的财产。 数字经济推动开放数据共享。 API 支持私人、公共、合作伙伴和第三方数据和服务。 API 需要应用隐私保护技术来遵守数据隐私法规。
部署API 安全解决方案需要基础设施集成和连接器，一些定制的定制才能在 IT 资产中正确部署。 了解部署的复杂性需要架构规划。 选择在现有 IT 企业架构中开箱即用的解决方案可减少部署时间。
要了解有关防御 API 攻击的更多信息，请查看我最近受 F5 委托撰写的报告《API 安全解决方案评估指南》 。 本报告讨论了选择 API 保护解决方案的最重要的考虑因素。
作者：Tari Schreider，C|CISO、CRISC – Datos Insights 战略顾问