API 安全性与微服务架构的挑战

关键要点

微服务应用中的 API 是连接各个部分的关键。使用简单脚本替代 API 可能带来安全性和可扩展性问题。建议将服务拆分为独立的 Web 服务，并为其定义 API。公共 API 需要更严格的安全措施，以防范潜在攻击。自动化测试解决方案，如动态应用安全测试 (DAST)，可以帮助覆盖所有攻击面。

在构建基于微服务的应用时，应用程序编程接口API是支撑整个系统的关键所在。与传统的单体架构相比，暴露的 API 可能不那么明显，但如果你有一个 Web 应用，那么几乎可以肯定你在某些地方运行了服务，也就是说，你有需要测试功能和安全性的 API。这篇文章通过一个简单的场景展示了 API 在任何架构中都是如何迅速扩展，并潜在增加你整体 Web 攻击面，以及如何确保无论后台运行的是什么，都能保持安全。

隐秘的架构选择：简单脚本还是简单 API？

一个典型的情况是需要处理单独的过程来执行某些服务器端操作。假设你有一个全栈 JavaScript 应用，服务器端使用 Nodejs，需在某处进行图像处理功能，比如自动生成图像缩略图。你可以选择完全用 JavaScript 来实现，但为了性能和便利性，你可能选择现成的 Python 脚本。因此，在原型设计中，最简单的方式是调用：

shellimgData = exec(python3 resizepy inputfilepng outputfilepng)

这个命令会进行操作系统调用来执行 resizepy 脚本，传入输入文件并期望返回一个调整大小的输出文件。虽然这种方式对于原型是可行的，但它也存在一些缺点：

缺点描述命令注入风险如果恶意用户能够控制输入或输出文件名，并且未对数据进行清理，应用可能容易受到操作系统命令注入的攻击。可扩展性和性能问题脚本运行在与主应用相同的服务器上，可能导致高负载生产环境中的性能问题，尤其是在处理并发请求时。访问控制有限对于小脚本来说，可能不会有太大问题，但无法轻松控制对 resize 操作的访问，或者设置速率限制。

更优雅的解决方案是将图像处理功能放在一个独立的 Web 服务中，并为其定义一个 API。该服务会在指定的 URL 上监听调用，接受输入图像并返回调整大小后的图像。可在同一服务器上运行，也可以选择在完全不同的地方运行，你可能通过简单地向 https//yourservername/api/resize 发送输入图像来使用它。这样可以解决大多数简单本地 exec() 的缺点：

由于你不是直接将用户输入传递给本地脚本，因此没有直接的命令注入风险尽管这也带来了其他的安全问题。易于适应、重用和修改 一旦定义了 API 端点，如何实现所需操作完全由你决定。无论背后是单一功能的 Python 脚本，还是更复杂的多用途图像处理服务，该端点均可使用。该服务的可扩展性独立于主应用程序。根据负载和业务需求，你可以在单个本地服务器上运行它，或者在公共云的多个容器中分散部署，亦或选择其他选项。你可以为每个 API 端点定义细粒度的访问控制和速率限制，根据需要设置授权、审计和日志。

在某些情况下，选择 API 路线可能因为外部原因而更可取。例如，安全政策可能禁止使用 exec() 等函数执行操作系统命令，或者这一功能被简单地禁用。此外，在服务导向的应用架构中，添加另一个服务可能会显得很自然。

蚂蚁加速器免费

保持端点可见且安全

选择 Web 服务而非调用本地进程的架构收益意味着，API 可能在任何地方出现，即便应用本身并没有大量使用服务。虽然在某种程度上，相比直接从 Web 应用调用系统命令，运行 API