在过去几年中，API 驱动的应用程序在企业级云平台上部署以扩展规模兴起。它们能够根据用户需求进行扩展，彻底改变了应用程序的编写和部署方式。通常，这些分布式应用程序部署在 Kubernetes 平台上，以便更轻松地管理、编排和部署微服务容器。
DevOps 团队投入了大量资源，以确保他们在 Kubernetes 基础设施平台上运行的应用程序安全可靠，不会被利用。这可以包括强化操作系统，通过跨集群的微分段防止横向移动，以及通过严格的 RBAC 控制来限制访问来防止未经授权的访问。
然而，这只是成功的一半。从 Kubernetes 平台上移，部署的 API 驱动的应用程序有自己的安全问题类别，需要不同的方法来实现适当级别的安全保护。API 驱动的应用程序的兴起助长了一类新的 API 漏洞，这些漏洞无法被现有的应用程序安全产品保护。
隐藏在底层 API 中的漏洞可能会暴露等待被利用的弱点，从而暴露关键业务数据。网络犯罪分子已经注意到并正在开发新的攻击向量，以便在企业向 API 经济发展时利用它们。
需要一种新的方法来摆脱专注于保护单体应用程序的应用程序安全性，并专注于 API 驱动的应用程序如何运行以提供适当级别的保护。
以下是企业在评估 API 安全解决方案时应考虑的一些关键标准。
1. API 可见性和监控：你无法保护看不到的东西
尽管 API 使用量呈爆炸式增长，但许多安全和开发团队仍无法回答有关其 API 程序的基本问题——例如我们有多少、谁拥有它们以及它们做什么。在当今复杂的威胁环境中，这给企业带来了巨大的安全风险。
为了防范安全风险，企业了解其 API 程序的所有方面及其相关的安全挑战至关重要。这可以更好地帮助领导者通过适当的缓解策略改善其组织的安全状况。
大多数企业都公开了许多内置的 API，并为客户和合作伙伴开源。它们由不同的团队发布，使用不同的应用程序堆栈和不同的程序。因此，很难跟踪和了解潜在风险在哪里。以下是企业应该考虑的一些关键 API 可见性挑战：
- 未知 API：影子、已弃用或隐藏的 API 可能会超出安全团队的可见范围，这通常会导致它们不受保护。这些 API 可能会传输敏感数据并危及组织的合规地位。
- API 参数：API 漏洞(例如批量分配)允许攻击者将用户配置文件更改为“管理员”，从而导致权限提升，这可能导致欺诈、数据丢失。
- 敏感数据暴露：在响应代码或错误消息中暴露机密或敏感数据可用于窃取数据或作为大规模攻击的侦察形式。
- 业务逻辑缺陷：应用程序业务逻辑缺陷可以使不良行为者通过帐户接管、抓取、虚假帐户创建和其他形式的 API 滥用进行欺诈。
在寻求解决这些常见的 API 安全挑战时，提出问题以评估和降低风险程度会有所帮助。有许多问题需要考虑：我们拥有的 API 有什么作用?API 所有者是谁?哪些 API 需要遵守法律或法规?我们如何监控 API 中的漏洞?我们的 API 是否会暴露敏感数据或 PII，这是否会导致我们不合规?我们如何测试和衡量 API 监控的有效性?
2. API 安全性：不同类型的应用程序安全性
大多数拥有 Web 应用程序的企业都将拥有 Web 应用程序防火墙 (WAF) 以进行安全保护。然而，随着企业继续扩大其 API 驱动的应用程序，他们发现传统的 WAF 无法很好地适应单体应用程序的需求，无法满足现代 API 驱动的应用程序的需求。
由于 API 驱动的应用程序的编写方式非常独特，这使其成为一个单独的可利用漏洞类别，这些漏洞与其 OWASP 前 10 名 Web 兄弟非常不同。有效保护单体 Web 应用程序漏洞免受 OWASP 的 10 大 Web 漏洞攻击的安全方法在 API 世界中并不能很好地转化。
使用传统的 Web 安全方法很难防御 BOLA(损坏的对象级授权)和批量分配等关键 API 漏洞。越来越多的客户逐渐意识到，部署 WAF 来保护他们的 API 就像在枪战中拿刀一样，是低级且错误的武器。
现在出现了一种新的 API 安全产品类别，它取代了 Web 应用程序防火墙，更符合保护 API 驱动的应用程序免受利用的特定要求。这些 API 安全解决方案是围绕应用程序的日常行为方式构建的。这些安全解决方案由机器学习 (ML) 提供支持，专注于学习应用程序行为和发现异常活动。
构建应用程序机器学习模型可以为发现嵌入在数百个微服务中的内在业务逻辑缺陷和 API 漏洞奠定基础。用户驱动的流量为机器学习模型的开发提供动力，并捕捉应用程序的微服务如何协同工作以交付应用程序业务逻辑。
如果企业正在寻找 API 安全解决方案，应该考虑以下三个标准：
- 发现：识别企业环境中的所有 API。理想情况下，API 安全工具应该知道定义允许的 API 请求的 API 参数。例如，API 应该只允许用户响应 255 个字符串字符。通常，未经验证的 API 响应可用于利用应用程序漏洞。
- 学习：API 安全工具应该能够从用户驱动的流量中学习 API 行为。这允许 API 安全解决方案的机器模型了解定义正常应用程序行为的所有细微差别。用户行为的轻微和突然偏差会通过警报向安全运营团队显示。
- 适应：在敏捷环境中开发的大多数现代应用程序都在迅速变化。API 安全解决方案应该能够自动调整其安全模型以不断适应所有新变化，以确保应用程序安全始终与 DevOps 保持同步。
3. 威胁分析：在网络攻击发生时检测它们
当网络犯罪分子从应用程序中泄露敏感数据时，他们会采取必要的预防措施来逃避检测。为了对抗它们，需要威胁分析来检测访问您的应用程序的用户之间的恶意活动。
从应用程序中获得的数据的质量和广度将决定企业的安全保护级别，并影响其在多长时间内检测到即将发生的网络攻击。随着应用程序变得更加复杂和分布式，更多地了解应用程序的内部工作原理、工作方式、业务逻辑以及与其他第三方技术合作伙伴的交互变得更加重要。
收集应用程序内所有点的数据交互可确保其全面了解所有用户与应用程序的交互。数据集越丰富，就越容易将恶意与合法用户交易区分开来，并使企业的安全团队能够尽快发现数据泄露。
API 安全平台应使安全团队能够执行以下操作：
- 威胁搜寻：安全分析师可以通过数据湖搜索正在进行的活动。
- 跟踪攻击者：当攻击者深入挖掘应用程序时，您可以跟踪杀伤链活动，例如侦察或扫描活动。
- 事后分析：安全分析师可以获得事后取证，以了解网络攻击如何利用应用程序的业务逻辑或漏洞。
结论
快速变化的 API 驱动应用程序有助于加快产品上市速度，但也释放了可被网络犯罪分子快速利用的 API 漏洞。可以很好地保护单体 Web 应用程序的应用程序安全产品在保护 API 驱动的应用程序方面无法很好地扩展。
由于跨更复杂和分布式应用架构的快速变化，API 安全的要求与市场上现有的应用安全产品有着根本的不同。在评估 API 安全解决方案时，一定要关注解决方案如何提供可见性、它对应用程序的理解程度以及威胁分析的质量和深度。
获得专门针对 API 应用程序的适当应用程序安全解决方案将帮助企业更好地防御不断增加的 API 驱动的网络攻击，这些攻击旨在利用企业最有价值的资产——数据。
