集成应用和 API 安全策略案例
显然，应用程序和 API 安全已经变得更加专业化。 API 不再仅仅是基于 URI 的应用入口点。 API 已经成长起来并成为一个具有自身安全需求的独立实体。
大多数安全需求与 API 交互的性质有关。 也就是说，API 需要根据每个交易进行授权。 这与通常根据会话应用授权的应用程序有明显不同。
API 的交互率也更高，并且许多其他特性也对 API 的安全提出了特殊挑战。
| 应用程序 | API | |
|---|---|---|
| 消息格式流畅性 | HTML、JSON、XML | ProtoBuf、JSON、GraphQL、二进制、XML、数据格式 |
| 互动 | 静态、不频繁变化 | 动态、频繁变化 |
| 数据 | 结构化、交易性 | 非结构化、流式和交易型 |
| 用户 | 人类 | 软件、人类 |
| 用户代理 | 浏览器、应用程序 | 软件、设备、脚本、应用程序、浏览器 |
| 验证 | 基于会话 | 基于交易（更像 ZT） |
| 协议流畅性 | HTTP/S、QUIC | gRPC、WebSockets、HTTP/S、QUIC |
应用程序和 API 的比较表明了导致安全需求分歧的差异。
话虽如此，应用程序和 API 都存在一些共同的安全风险，在实施安全解决方案时需要考虑。 例如，最近更新的2023 年 API 安全 Top 10清楚地显示了与应用共享的一部分风险：
- 身份验证/授权控制薄弱
- 配置错误
- 业务逻辑滥用（撞库攻击、账户接管）
- 服务器端请求伪造（SSRF）
除了这些风险之外，针对可用性的攻击仍然大量存在。 也就是说，应用程序和 API 都经常遭受 DDoS 攻击，因为它们通常对 TCP 和 HTTP 具有相同的依赖性，而这两者都容易受到各种旨在破坏访问和可用性的攻击。
解决应用程序、API 及其支持基础设施安全挑战的一种方法是部署多种解决方案。 机器人和欺诈防御、DDoS 保护、应用程序安全和 API 安全。 虽然这确实解决了安全挑战，但它带来了操作挑战，并使许多与安全相关的任务变得更加复杂，例如策略变更管理和对影响应用程序和 API 的威胁的反应。 复杂性不仅是安全性的敌人，也是速度的敌人。
根据我们的年度研究，对新出现的威胁做出反应的速度是采用安全即服务的主要驱动力。 每个需要修补、更新或部署新策略来减轻新出现的威胁的解决方案都会增加时间并增加配置错误或失误的可能性。 因此，缓解威胁的时间会随着复杂性的增加而增加——特别是如果组织在多个环境（混合 IT）中运营并利用每个环境的安全解决方案。 我没有通过计算来确定这是一个线性增长还是指数增长，因为老实说，任何增加应对迫在眉睫的威胁的时间的事情都不是好事。
这就是为什么更好的方法是结合解决方案，从而共享旨在对抗威胁的功能的运营和安全管理，同时允许特定的安全策略来解决应用程序和 API 独有的协议和有效负载。
这导致了集成应用和 API安全策略的出现，其中通用功能以越来越精细和特异性的方式共享，并更接近应用程序或 API。毕竟，机器人就是机器人，它们对数据质量、交付成本以及应用程序和 API 的风险状况的影响是大家共同关心的问题。 DDoS 就是 DDoS。 为了解决同一问题而运营两倍的服务在各个衡量标准上都是低效的。
集成的应用和 API安全策略具有良好的运营、财务和架构意义。