编译| API 安全是新的云安全吗？

随着 API 越来越多成为了互联网流量最常见的通信渠道，保护它们的安全对企业安全团队来说将变得愈发重要，也更具挑战。API 的普遍性极大地拓展了非法分子的攻击面，也使这些攻击面之间的联系变得更加紧密了。

换句话说，API对所有企业、社会组织都构成了巨大的安全威胁。

Imperva 首席技术官 Peter Klimek 将这个 API 安全的概念比作成早期的云安全，他说：“在云迁移正式被关注前人们并不关心云安全，而针对不同渠道所开发的 API 数量确实呈爆炸式增长。虽然以前对API的使用方式似乎更谨慎，主要是用于移动应用程序或一些 B2B 流量等，但现在客观条件放在那儿，几乎所有东西都需要由 API 提供支持，因此，所有这些新的 API 都有可能带来更多的安全风险，这也是当下很多 CISO 会去关注的原因。”

根据 Klimek 的说法， Imperva 将 API 安全风险分为两类，第一类是技术漏洞，包括标准 Web 应用程序中也可能存在的一系列风险，例如OWASP 十大应用程序安全风险和CVE 漏洞，Log4j 漏洞就属于这一类。

大多数 Imperva 客户首先应对的就是这些威胁，因为它们往往是最严重的威胁，用户只需要采用现有的应用程序安全策略，例如在开发过程中进行代码扫描或部署 Web 应用程序防火墙或使用应用程序自保护技术等就可以了。用户采用了这些策略，并将其更多地转移到 API 安全方面。

而第二类风险对于 API 来说更为独特，这是因为API 与 Web 应用程序不同， API 安全性从根本上说是一个数据安全问题。API 使人们或系统能够快速查询数据、访问数据或修改数据、置换数据，因此我们现在在 API 安全中看到的一些策略都来自于围绕数据安全所制定的策略，用户会去研究了解到底是谁在访问这些数据，他们的敏感数据在哪里，以及哪些 API 暴露了敏感数据，然后将这些用作如何解决问题的模型。

API 安全的 4 个步骤

根据 Klimek 的说法，实现 API 安全性有四个步骤。与大多数安全策略一样，第一个是发现，这包括构建 API 、API 的端点、API的库存。

Klimek 说：“更为重要的是，当你深入研究API的安全时，你得弄清楚每个人实际处理的数据类型是什么？这么做是为了让企业更好地了解他们的风险状况以及所有 API 端点的风险状况。”

第二步涉及监控 API。API 的结构是什么样的？哪些 API 在请求进入企业系统？谁在访问这些请求？Klimek 表示，企业需要监控他们的 API 流量，并找出潜在的威胁。

第三步，Klimek认为我们通常需要以两种不同的方式对保护进行分类。第一，我们必须先确定该阻止哪些实时威胁，因为在这诸多攻击中，一个精心设计的恶意请求可以有效地毁掉整个公司，所以实时漏洞是必须得马上缓解的。第二则需要防止攻击者会策划更长远的攻击，因此就需要查看更长的事件链，而不是防止单个 API 攻击。

Klimek 说：“你得了解并基本能描述出个人消费者或客户在很长一段时间内访问了你们多少数据和 API，因为对于AI和分布式拒绝服务 (DDoS)攻击来说，问题并不在于个人请求，而在于持续抓取网站或来自受感染设备的大量流量。”

最后，API 安全性的第四步是验证和合规。Klimek 解释说：“这就好比企业为他们的开发团队设置了护栏的地方，相当于在开发生命周期中转移了安全性。在这种情况下，我们在开发周期的早期就能测试 API，以主动识别问题。”

安在新媒体