助力实现 PCI DSS v4.0 API 安全合规性的最佳做法

原版的要求涵盖了在安全领域中至关重要的核心要素，这些要素现在仍然与 2006 年发布时一样重要。例如：

• 在所有处理或存储持卡人数据的 IT 系统上，监视和控制对所有管理帐户的访问

• 根据拥有知情权的原则授予对系统和持卡人数据的访问权限，并按角色制定访问权限要求

问题在于，当前的威胁态势相比 2006 年要更为复杂。

是的，企业仍然必须解决攻击者倾向于针对特权账户和权限过多的用户等领域的问题。但是，现在有成千上万的 API 与支付技术息息相关，这也使得 API 成为攻击者频繁攻击的目标，当今的企业还需要调整其合规性计划来应对这些攻击者的威胁。这些攻击者知道 API 容易被利用，并且可以成为盗取持卡人数据的有效途径。

因此，为了遵守 PCI DSS v4.0的要求，企业需要了解 API 威胁并采取相应的防御措施。在这篇博文中，我们将深入剖析风险、要求以及用于遵守这些要求的方法。

整体而言，PCI DSS v4.0 具有四个关键目标：

1. 持续满足支付行业的安全需求

2. 倡导将安全防护视为一个持续的过程

3. 帮助企业灵活满足合规性要求（例如，提供新工具、新的控制措施）

4. 增强验证方法和验证流程

PCI DSS v4.0 明确指出 API 是需要进行监控和采取保护措施的关键领域。所有四个目标都涉及到这个方面。但是，考虑到与 API 相关的风险具有独特性，第三条（灵活使用新工具和新的控制措施）尤为重要。例如：

• API 是面向客户的数字化产品和服务的核心所在。平均而言，根据规模，大型企业会使用 15,000 到 25,000 个 API，这些 API 用于确保数据的持续交换。

• 而这些数据中包含着敏感的客户信息。在每次数字化支付过程中，后台都会有 API 在应用程序、系统、第三方等之间传输数据。

• 只要有一个 API 被入侵，就可能导致上百万条记录被盗、遭受勒索或公之于众。暴露或配置错误的 API 非常普遍，很容易遭到入侵，往往缺乏必要的安全保护，容易被忽视，而且缺少管理措施。

监管机构非常清楚与 API 相关的风险，而企业必须证明自身采取了监视和控制措施，来防止数据泄露。

根据 Verizon 的《2023 年数据泄露调查报告》，数据泄露中超过三分之一 (37%) 是支付卡数据泄露。PCI DSS v4.0 围绕 多重身份验证 和密码长度提出了新的要求，以便针对支付行业攻击面中的人为因素提供保护。

但务必要记住的是， 数据泄露 并不总是因为公开的、以人为中心的攻击方法所造成，如通过 网络钓鱼 获取员工的密码。

举例而言，电子商务中有 18% 的攻击是通过在银行卡处理网页中嵌入恶意代码来实施的。如今的攻击者越来越成熟，并将目标放在了 IT 环境中通常未得到妥善保护的自动化非人工部件上，例如 API。

根据 我们的研究，78% 的企业遇到过与 API 相关的安全事件。 认识到 API 威胁的紧迫性之后，PCI DSS v4.0 给出了新的 API 安全规则、指南和最佳做法。首先详细了解一下要求 6.2.3。

要求 6.2.3 的中心是企业需要审查其个性化定制和自定义的应用程序代码（即，由第三方供应商开发的应用程序，但并非标准的现成商用应用程序），以确保不会将漏洞发布到生产环境中。

这一要求提供了指导，以确认企业的软件能够安全地使用外部组件的功能（库、框架、API 等），其中说明了 API 在更广泛的软件供应链中发挥的关键作用，以及所采取的保护措施。

API 现已成为现代化应用程序环境中连接和数据交换的默认方法。考虑到这一点，采用生产前（左移）方法和生产后（右移）方法来保护 API，对于确保数字化业务能够弹性应对攻击至关重要。

此处介绍了六个 API 安全最佳做法，帮助您遵守要求 6.2.3。

1. 确认所用的基于 API 的部件以及安全态势（例如，查找有无任何错误配置导致漏洞，包括使用了标准中指出的弱加密密码）

2. 验证 API 使用过程中正常的预期行为，并实施控制措施来阻止可疑行为者滥用系统（例如，检查应用程序的行为来检测逻辑漏洞）

3. 检测用于支持 API 的第三方框架，确定是否有任何过时和易受攻击的地方

4. 建立所有 API 的完整清单，包括所运行的 API 的不同版本，这样可以深入了解可能存在的未记录的功能以及需要管理的后门

5. 验证 API 代码的安全性，避免将任何与 API 相关的漏洞引入到生产环境中

6. 实施针对 API 的安全编码最佳做法，这样您就可以采取程序性的方法来持续地安全交付代码

在 PCI DSS v4.0 中，PCI SSC 还增加了另外两个与 API 安全相关的部分。下面总结了您需要满足的这两个新增要求。

• 要求 6.3.2 用于维护个性化定制和自定义软件的清单，以及集成到个性化定制和自定义软件的第三方软件部件清单，以协助进行漏洞和修补程序管理。

• 要求 6.2.2 针对从事个性化定制和自定义软件工作的软件开发人员提出了培训要求。其中指出，开发人员需要根据与其工作职能相关的安全性要求，每 12 个月至少接受一次培训，培训包括安全软件设计和安全编码技术。此培训还包括安全测试工具，以及如何使用这些工具来检测软件中的漏洞。