整体 API安全策略的 6 个原则
虽然 UX 是您的应用的门面，但 APls 却是您组织的支柱。 许多企业犯的一个常见错误是将 API 仅仅视为应用顶层的接口层。 事实上，APl 是您的应用和第三方生态系统的连接组织，它们越来越多地分布在混合和多云架构中。 虽然 APls 面临着与 Web应用相同的一些风险（即漏洞利用、业务逻辑滥用、配置错误），但还存在其他重大风险。 这些攻击包括绕过弱身份验证和授权控制、不当库存以及不安全使用第三方 APl 的攻击。 通过复杂的软件供应链和自动化的 Cl/CD 管道所采用的数字业务的速度进一步增加了风险，这可能导致未知、不受监控和不安全的 API。 具体来说，这些包括安全团队未知和/或开发团队未维护的影子和僵尸 APl。 在本文中，我们将探讨全面、完善的 API 安全方法的 6 个原则。
1. 了解您的 API 和端点
很有可能，如果您尝试，您现在无法识别环境中的每个 API 端点。 不幸的是，对于恶意行为者，你可能无法说同样的话。 如果存在端点，它可以被用作破坏关键业务功能的一种方式或途径。
此外，公开 API 可让您接收来自无数客户、合作伙伴和应用程序的查询。 这种暴露也会使您的组织面临风险，因此了解和监控 API 至关重要。 需要考虑多种风险控制措施来保护您的组织免受 API 可能暴露的漏洞和潜在威胁，这些漏洞和威胁可能会导致违规和停机。
对于任何防御者来说，API 发现是保护 API 的第一步，也是关键的一步。 虽然不言而喻，但是“你无法保护你看不到的东西”这句话却是再正确不过了。 拥有完整的 API 清单是开发或改进任何 API 安全态势的起点，帮助您了解和量化整个 API 威胁面。 它可作为以下内容的基线：
- 能见度： 通过对所有可用的 API 进行分类，您可以更好地了解 API 威胁形势，包括漏洞、敏感数据暴露以及未经授权或被遗忘的端点。
- 版本控制： 建立库存有助于版本管理——了解 API 的历史和不同版本可以帮助您淘汰过时或易受攻击的版本或正确保护它们。
- 监控： 集中的、完整的 API 清单使您能够更好地监控和记录 API 使用情况，从而更容易检测和应对可疑活动（异常）和潜在的安全事件 - 此外，如果发生事件，清晰的清单可以帮助您做出响应。
- 一致的安全控制和政策： 拥有这种可见性（包括完整的 API 清单）可让您在整个 API 威胁面上有效地实施控制和策略。
2. 在创新与安全之间找到平衡
这是一场经典的斗争。 一方面，敢于创新、突破界限、做竞争对手做不到的事情是任何成功企业的基石。 但另一方面，保持安全并不总是能与最新的创新相兼容。
实现平衡的关键有三点：
- 为每种类型的 API 设计 API 治理策略，以便设置适当的安全控制。
- 实施 API 安全策略，无论在何处部署 APl，都可以一致执行。
- 适应新出现的威胁、异常行为以及试图利用 AI 利用或滥用 APls 的恶意用户，以减轻安全团队的负担。
根据您所在的行业，合规标准会有所不同，有些标准要求比其他标准更严格的安全性。 无论如何，至关重要的是，您的 API 安全态势必须足够强大，以应对一系列威胁载体。
3. 在整个开发生命周期中管理风险
API 安全测试不是一次性的事情。 部署之前、部署期间和部署之后的测试至关重要。 通过将测试融入开发的每个阶段，您将获得更多机会在漏洞发生之前识别弱点和漏洞。 虽然特定于安全的测试工具很棒，但也不要忘记安全用例建模。
安全性需要在应用程序本身的相同连续生命周期中运行，这意味着与 CI/CD 管道、服务配置和事件监控生态系统紧密集成。
4. 从后端到最终客户的分层保护
从外部客户端到内部后端基础设施，架构的每个部分都必须有自己的保护措施。
此外，经过验证的安全实践仍然适用 - 默认拒绝架构、强加密和最小特权访问。
在考虑 API 层的保护时，首先将 API 分为两类会很有帮助：内部和外部。 由于 API 提供商可以与应用程序团队协调安全措施，因此内部 API 的安全性更加直接。 对于外部 API，风险计算有所不同。 您可以（并且应该）实施 API 级别的保护，其作用如下：
- 利用实时威胁情报和访问控制机制（例如强化会话令牌）来缩小安全漏洞的机会。
- 建立基线正常和异常交通模式。
- 限制 API 的使用并对任何经批准的聚合器和第三方集成提供精细控制。
在生产层面，API 蔓延产生的大量流量使得必须使用 AI 来检测异常行为和恶意用户。
5. 拥有正确的策略和工具
就像没有任何一种食物能够为我们提供充分的营养一样，也没有任何一种安全控制能够完全保护 API。 相反，您需要制定一个策略，将全面的工具生态系统作为整体应用程序和 API安全架构的一部分。 其中包括检测和在线执行，使您能够控制 API 行为、限制不良或恶意活动并阻止敏感数据泄露。
这可能包括多种功能和工具的组合，包括：
- API 网关
- 应用程序安全测试（SAST 和 DAST）
- Web应用防火墙 (WAF)
- 数据丢失防护 (DLP)
- 机器人管理
- DDoS 缓解
API 网关提供强大的库存和管理功能，但仅提供速率限制等基本安全性，无法阻止复杂的攻击者。 此外，API 的激增导致了工具的蔓延——包括 API 网关的蔓延。
应用程序安全测试始终至关重要，但在开发过程中用于实现强大应用安全性的左移方法需要通过右盾实践来增强，即在生产中保护 API 端点。
Web应用防火墙提供了一个重要的权宜之计，通过签名来缓解应用漏洞利用。 API 容易受到与其支持的应用相同类型的注入攻击 - 试图执行非预期的命令或访问数据。 但 WAF 通常缺乏必要的动态发现功能，无法持续检测未知（影子或僵尸）API 和问题（包括 API 的行为异常和业务逻辑的潜在漏洞）。
敏感数据检测和数据丢失预防功能通过检测和屏蔽敏感关键数据（包括个人身份信息 (PII) 和财务信息）来帮助保护 API 及其访问和传输的数据。 这使得组织可以创建数据保护规则来限制或屏蔽数据传输并阻止 API 端点完全暴露数据 - 有助于防止通过 API 泄露数据。
API 的机器人管理不能依赖于常用的安全控制，例如多因素身份验证 (MFA) 和 CAPTCHA，因为 API 流量通常是机器对机器的，并且除了基于 API 的系统的用户界面外，没有直接的人机交互。
传统的 DDoS 缓解措施侧重于网络和容量攻击，而 API 可能受到滥用关键业务逻辑的针对性第 7 层攻击。 最终结果是一样的——性能下降，甚至可能导致停机。
动态 API 发现、模式执行（积极安全）、访问控制以及基于机器学习的自动异常检测和保护已成为保护 API 的关键生态系统功能。 拥有一个或多个精通 API 协议并允许执行正确的 API 行为和创建 API 保护规则的工具非常重要。 组织需要能够创建专门管理 API 和 API 行为的自定义规则。 这包括允许和拒绝列表控制、速率限制、地理 IP 过滤和自定义规则创建以对 API 请求采取行动，包括屏蔽敏感数据以及针对特定 API 端点或组的匹配和请求约束标准。
6. 混合云和多云安全
API 的激增正在导致混合和多云环境中不可持续的架构蔓延。 同样，API 蔓延导致了 API 网关蔓延，因为许多安全工具无法跨数据中心、私有/公共云和边缘等多种架构提供一致的安全性。 整个数字生态系统中 API 流量的可见性和控制对于缓解下一个严重漏洞以及防止端点分布在不同的云提供商时可能发生的错误配置至关重要。
确保 API 安全无虞
API 无处不在——在数据中心、在云端、在边缘——并且在 Web 应用程序、移动应用程序和相关的第三方集成背后相互连接。 无论 API 位于何处，都需要受到保护，并且安全性永远不应休息。 相反，请确保您的策略包含能够持续保护 API 背后的关键业务逻辑并始终如一地保护与 API 连接的数字结构的解决方案，这样您就可以简化运营并充满信心地进行创新。
