支付卡行业数据安全标准 (PCI DSS) - V4.0.1 合规报告

支付卡行业数据安全标准 (PCI DSS) 合规报告帮助您评估应用程序的安全性，以符合旨在保护持卡人账户数据的要求。

关于 PCI DSS V4.0.1

支付卡行业数据安全标准 (PCI DSS) 的制定旨在鼓励和增强持卡人数据安全，并促进全球范围内一致的数据安全措施的广泛采用。PCI DSS 提供了保护账户数据的技术和操作要求的基线。

PCI DSS 包含保护持卡人数据的最低要求，并可以通过额外的控制和实践来进一步降低风险，以及本地、区域和行业法律法规。此外，立法或监管要求可能需要对个人信息或其他数据元素（例如，持卡人姓名）进行特定保护。PCI DSS 不会取代本地或区域法律、政府法规或其他法律要求。

PCI DSS 安全要求适用于包含在持卡人数据环境 (CDE) 中或与之连接的所有系统组件。CDE 由存储、处理或传输持卡人数据或敏感身份验证数据的人、流程和技术组成。

"系统组件" 包括网络设备、服务器、计算设备和应用程序。系统组件的示例包括但不限于以下内容：

  • 提供安全服务的系统（例如，认证服务器）、促进分段的系统（例如，内部防火墙）或可能影响 CDE 安全性的系统（例如，名称解析或网络重定向服务器）。
  • 虚拟化组件如虚拟机、虚拟交换机/路由器、虚拟设备、虚拟应用程序/桌面和虚拟机管理程序。
  • 网络组件包括但不限于防火墙、交换机、路由器、无线接入点、网络设备和其他安全设备。
  • 服务器类型包括但不限于 Web、应用程序、数据库、认证、邮件、代理、<uicontrol>网络时间协议 (NTP)</uicontrol> 和 <uicontrol>域名系统 (DNS)</uicontrol>。
  • 应用程序包括所有购买的和自定义的应用程序，包括内部和外部（例如，互联网）应用程序。
  • 任何位于 CDE 内或连接到 CDE 的其他组件或设备。

覆盖的实体

<uicontrol>PCI DSS</uicontrol> 适用于所有参与支付卡处理的实体——包括商家、处理器、收单行、发卡行和服务提供商，以及所有存储、处理或传输持卡人数据 (CHD) 和/或敏感认证数据 (SAD) 的其他实体。

PCI DSS 要求适用于存储、处理或传输账户数据（持卡人数据和/或敏感身份验证数据）的组织和环境。某些 PCI DSS 要求也可能适用于将其支付操作或 CDE 管理外包的组织。此外，将其 CDE 或支付操作外包给第三方的组织有责任确保第三方根据适用的 PCI DSS 要求保护账户数据。

合规处罚

如果商户或服务提供商不符合安全要求或未能纠正安全问题，信用卡公司可能会对收单成员处以罚款，或对商户或其代理施加限制。

合规要求

PCI DSS 版本 4.0.1 已取代 PCI DSS 版本 4.0，并于 2025 年 1 月 1 日生效。PCI DSS 版本 4.0 在 2024 年 12 月 31 日之后不能用于 PCI DSS 合规。

监管机构

PCI 安全标准委员会及其创始成员，包括 American Express、Discover Financial Services、JCB、MasterCard Worldwide 和 Visa International。

PCI DSS V4.0.1 报告漏洞

下表列出了评估的特定 PCI DSS V4.0.1 要求。在您的应用程序中发现的漏洞将映射到这些要求。

Table 1. 法规部分
ID 名称
要求 2 对所有系统组件应用安全配置
要求 2.2.2 如果将使用供应商默认账户，则根据要求8.3.6更改默认密码。如果不使用供应商默认账户，则删除或禁用该账户。
要求2.2.4 仅启用必要的服务、协议、守护进程和功能，所有不必要的功能都被删除或禁用。
要求2.2.6 系统安全参数配置为防止滥用。
要求4 在开放的公共网络上传输期间使用强加密保护持卡人数据
要求5 保护所有系统和网络免受恶意软件的侵害
要求6 开发和维护安全的系统和应用程序。
要求6.2.1 定制和专用软件的开发是安全的
要求6.2.4.1 软件开发人员定义并使用软件工程技术或其他方法，以防止或减轻定制和专用软件中的常见软件攻击和相关漏洞，包括但不限于注入攻击，包括SQL、LDAP、XPath或其他命令、参数、对象、故障或注入类型的缺陷。
要求6.2.4.2 软件开发人员定义并使用软件工程技术或其他方法，以防止或减轻定制和专用软件中的常见软件攻击和相关漏洞，包括但不限于对数据和数据结构的攻击，包括试图操纵缓冲区、指针、输入数据或共享数据。
Requirement 6.2.4.3 软件开发人员已定义并使用软件工程技术或其他方法，以防止或减轻定制和专用软件中的常见软件攻击和相关漏洞，包括但不限于对加密使用的攻击，包括试图利用弱、不安全或不适当的加密实现、算法、密码套件或操作模式。
Requirement 6.2.4.4 软件开发人员已定义并使用软件工程技术或其他方法，以防止或减轻定制和专用软件中的常见软件攻击和相关漏洞，包括但不限于对业务逻辑的攻击，包括试图通过操纵API、通信协议和通道、客户端功能或其他系统/应用程序功能和资源来滥用或绕过应用程序功能和功能。这包括跨站脚本（XSS）和跨站请求伪造（CSRF）。
Requirement 6.2.4.5 软件工程技术或其他方法由软件开发人员定义并使用，以防止或减轻定制和专用软件中的常见软件攻击和相关漏洞，包括但不限于对访问控制机制的攻击，包括试图绕过或滥用识别、认证或授权机制，或试图利用这些机制实现中的弱点。
要求 6.3 识别和解决安全漏洞
要求 6.3.2 维护定制和专用软件以及集成到定制和专用软件中的第三方软件组件的清单，以便于漏洞和补丁管理。
要求 6.3.3 通过安装适用的安全补丁/更新来保护所有系统组件免受已知漏洞的影响。
要求 6.4 保护面向公众的 Web 应用程序免受攻击。
要求 6.5.6 在系统投入生产之前，从系统组件中删除测试数据和测试账户。
要求 7 根据业务需要限制对系统组件和持卡人数据的访问。
要求 7.1 仅限于那些工作需要访问系统组件和持卡人数据的个人。
要求 7.2.2 根据：工作分类和职能以及执行工作职责所需的最低权限，分配给用户（包括特权用户）的访问权限。
要求 7.2.6 所有用户对存储的持卡人数据查询库的访问限制如下：通过应用程序或其他编程方法，访问和允许的操作基于用户角色和最小权限。只有负责的管理员可以直接访问或查询存储的CHD库。
要求 8.2.8 如果用户会话闲置超过15分钟，用户需要重新认证以重新激活终端或会话。
要求 8.3.1 所有用户和管理员对系统组件的访问都通过以下至少一种认证因素进行认证：您知道的东西，例如密码或口令。您拥有的东西，例如令牌设备或智能卡。您是的东西，例如生物特征元素
要求 8.3.2 在传输和存储在所有系统组件上时，使用强加密技术使所有认证因素不可读。
要求 8.6.2 任何可以用于交互式登录的应用程序和系统账户的密码/口令都不应硬编码在脚本、配置/属性文件或定制源代码中。
要求 11.4 定期进行外部和内部渗透测试，并修正可利用的漏洞和安全弱点。