问题：僵尸 API 和影子 API 有什么区别？
Salt Security 现场首席技术官 Nick Rago： 僵尸 API 和影子 API 代表了当今企业正在努力应对的更大挑战的副产品：API 蔓延。
随着公司寻求最大化与 API 相关的商业价值，API 激增。 数字化转型、应用程序向微服务的现代化、API 优先的应用程序架构以及快速持续软件部署方法的进步推动了组织创建和使用的 API 数量的高速增长。 由于这种快速的 API 生产，API 蔓延已经在多个团队中表现出来，这些团队利用跨多个分布式基础设施（本地数据中心、多个公共云等）的多个技术平台（遗留、Kubernetes、VM 等） . 当组织没有适当的策略来管理 API 蔓延时，僵尸 API 和影子 API 等不需要的实体就会出现。
简而言之，僵尸 API 是暴露的 API 或已被遗弃、过时或遗忘的 API 端点。 有一次，API 发挥了作用。 但是，可能不再需要该功能，或者 API 已被替换/更新为较新的版本。 当一个组织没有围绕版本控制、弃用和淘汰旧 API 进行适当的控制时，这些 API 可能会无限期地存在——因此，术语僵尸。
因为它们基本上被遗忘了，所以僵尸 API 不会在任何功能或安全能力方面收到任何持续的补丁、维护或更新。 因此，僵尸 API 成为安全风险。 事实上，Salt Security 的“API 安全状态”报告将僵尸 API 列为组织在过去四次调查中排名第一的 API 安全问题。
相比之下，影子 API 是公开的 API 或 API 端点，其创建和部署是“在雷达下”完成的。 影子 API 是在组织的官方 API 治理、可见性和安全控制之外创建和部署的。 因此，它们可能会带来各种各样的安全风险，包括：
- API 可能没有适当的身份验证和访问门。
- API 可能未正确公开敏感数据。
- 从安全角度来看，API 可能没有遵循最佳实践，因此容易受到许多 OWASP API 安全 Top 10 攻击威胁。
开发人员或应用程序团队想要快速部署 API 或端点的背后有许多激励因素； 但是，无论出于何种动机，都必须遵循严格的 API 治理策略来强制控制和处理 API 的部署方式和时间。
除了内部开发的 API 外，API 蔓延以及僵尸和影子 API 的出现也增加了风险。 作为打包应用程序、基于 SaaS 的服务和基础架构组件的一部分部署和使用的第三方 API，如果没有适当的清点、管理和维护，也会带来问题。
Zombie 和 shadow API 构成相似 安全风险. 根据组织现有的 API 控制（或缺乏），一个可能比另一个问题更少或更多。 作为应对僵尸和影子 API 挑战的第一步，组织必须使用适当的 API 发现技术来帮助盘点和了解部署在其基础设施中的所有 API。 此外，组织必须采用 API 治理策略来标准化 API 的构建、记录、部署和维护方式——无论团队、技术和基础设施如何。
