支付卡行业数据安全标准 (PCI DSS) 要求企业在存储和跨网络移动持卡人数据时予以保护。这意味着需要提供强加密功能，以及涵盖从证书强度到加密密钥的生成、存储和停用等方方面面的配套规则。

满足这些 PCI 加密要求不仅仅会影响您的合规清单。它有助于缩小攻击面，并塑造如果发生漏洞时企业所面临的风险敞口。2025 年全球数据泄露的平均成本达到 444 万美元，突显了保护敏感记录的重要性。下面，我们将介绍 PCI DSS 对加密的实际要求、如今满足该标准的算法和协议，以及加密如何与令牌化和网段化等相关策略协同作用。

要点

• PCI DSS 对静止和传输中的持卡人数据都要求进行强加密，接受的基准是采用 256 位密钥的高级加密标准 (AES) 以及传输层安全协议 (TLS) 1.2 或更高版本。

• 由于加密和令牌化解决的问题不同，您可以通过将点对点加密 (P2PE) 与令牌化结合使用来缩小 PCI 合规范围。

• 尽管底层的加密算法很可靠，但是弱密钥管理仍然是企业无法通过 PCI DSS 评估的最常见原因之一。

什么是 PCI 加密要求？

PCI DSS 加密规则在合规清单的要求 3（涵盖已存储的持卡人数据）和要求 4（涵盖跨网络传输的数据）中进行了定义。PCI 审计人员在评估银行卡信息的处理方式时会检查这两个领域。

根据要求 3，如果您存储主账号 (PAN)，则必须使其在出现的任何地方（无论是在数据库、日志文件还是备份中）都不可读。虽然强加密是主要的保护方法，但截断和散列处理也是一种选择，尤其是在收据或面向客户的屏幕上屏蔽 PAN。要求 4 规定，跨开放式公共网络传输的所有银行卡数据都必须进行端到端加密。对于内部便利或早于该标准的旧有环境，没有例外情况。

敏感验证数据 (SAD) 采用了不同的方法，包括完整的磁条或芯片数据、信用卡验证码 (CVV) 和 PIN 块。无论其加密状态如何，PCI DSS 都不允许在授权完成后存储上述任何内容。

PCI DSS 批准哪些加密标准和协议用于加密？

PCI DSS 要求实施“强加密”，PCI 安全标准委员会将其定义为可提供至少 112 位有效密钥强度的任何方法。在实践中，该定义指向了一小批可接受的选项：

• 静态数据： AES-256 是通用标准。它明确规定了强度阈值，并得到云提供商和支付基础设施的广泛支持。在某些配置中，3DES（即 Triple DES）在技术上仍符合要求，但 PCI 安全标准委员会已标记其为弃用，并且大多数新系统会直接跳过它。

• 非对称加密： 用于交换对称密钥或签名证书，通常指 2048 位或更高的 Rivest–Shamir–Adleman (RSA)，或 224 位或更高的椭圆曲线加密 (ECC)。

• 传输中的数据： TLS 1.2 是最低要求，TLS 1.3 越来越被认为是实际上的默认值。SSL 的各个版本以及早期的 TLS 版本（1.0 和 1.1）均被明确禁用。

• 密码套件： 合格的套件必须没有已知漏洞，这排除了 RC4（Rivest Cipher 4）以及较旧配置中遗留下来的任何出口级密码。

• 证书强度： 面向公众的证书需要 2048 位 RSA 或更高级别的密码、当前的到期日期，以及由受信任证书颁发机构签发的证书。

• 协议协商： 服务器必须拒绝回退到不允许协议版本的连接尝试，而不是默许它们。

加密如何缩小您的 PCI 合规范围？

PCI DSS 术语中的合规范围指的是存储、处理或传输持卡人数据的每个系统，以及与这些资产相连的、可能会影响其安全性的任何对象。这统称为持卡人数据环境 (CDE)。

如果某个系统处理加密的持卡人数据，但无法访问其解密方式，PCI 安全标准委员会会将其视为超出范围，或者至少是缩小范围类别。这就是P2PE 的用武之地。被列入 PCI 名单的 P2PE 解决方案会在内部验证的硬件中，在交互点对银行卡数据进行加密。解密仅限于 P2PE 解决方案提供商的安全环境，而不是企业自己的基础架构。

经过验证的 P2PE 解决方案通常符合 P2PE 自我评估问卷 (SAQ)（较短的 PCI SAQ 之一）的条件，因为 P2PE 大幅缩小了评估范围。分段处理会进一步缩小范围。将银行卡数据系统隔离在独立于一般业务系统的自有网段上时，就会使那些永远不会查看到持卡人数据的系统完全被排除在评估之外。

加密或令牌化：哪种策略最能满足您的 PCI 加密需求？

加密会将 PAN 转换为不可读的密文，但原始编号仍然存在于某个地方。任何拥有正确密钥的人都可以撤销该过程。令牌化会从企业环境中彻底移除 PAN，并用一个令牌来代替它，该令牌与原始编号没有任何数学关系，即使被盗也毫无价值。

当需要在初始交易之后引用客户的支付方式时，例如订阅、已存储的支付方式或一键结账，令牌化就能发挥作用了。如果加密的 PAN 存储在内部，您仍然掌握着完整的卡号及其附带的所有信息，包括密钥管理职责、扩大的审计范围，以及在相关密钥遭到泄露时的风险敞口。但如果您存储的是令牌，并且是由 Stripe 等支付服务提供商生成并保存的令牌，那么敏感值从一开始就不会触及您的系统。许多设置将两者结合使用，对于长期存储的任何数据使用令牌化，而对于在网络中传输的任何数据则使用加密。

为什么密钥管理是 PCI 加密中容易被忽视的一个部分？

加密的效果取决于对密钥的保护程度，而这些做法往往被忽视。请注意以下事项：

• 分散知识和双重控制： 完整的加密密钥不必被一个人访问。在多人之间分配密钥组件，并要求多人才能重构密钥，这样可防止任何一个人凭借一己之力破坏环境。

• 安全的密钥存储： 密钥需要与其保护的数据分离开进行存储，通常存储在硬件安全模块 (HSM) 或等效的密钥管理系统中；它们必须与加密值分开保存在同一个数据库或文件系统中。

• 确定的密码期限： 每个密钥都需要一个记录在案的生命周期，根据诸如受其保护的数据量及其使用频率等因素，在生命周期结束后该密钥将被停用和替换。

• 记录在案的密钥保管人责任： 编写程序来确定谁负责密钥管理任务；那些保管人必须正式确认该责任。

在 PCI DSS 4.0 之下，企业必须至少每 12 个月审视一次其加密架构，确认正在使用的算法、协议和密钥长度仍然符合现有标准，并未过时。

如果您的企业未满足 PCI 加密要求，会发生什么？

未能满足 PCI DSS 加密要求会改变漏洞出现前后的情况。在发生任何事件之前，违规情况会在年度审查流程中显现出来。收单行和卡组织可能会将某家企业标记为违规，这会影响其继续处理银行卡支付的能力，并促使将来进行更密切的监控或提出额外的审查要求。

如果发生漏洞并且调查发现当时未满足这些控制措施，那么后果将不堪设想。在发生涉及持卡人数据的已确认漏洞后，通常需要进行法证调查。它将专门检查 PAN 在存储和传输过程中是否得到了妥善加密。如果不是，则赔偿责任将不会与支付提供商或收单行共同承担，而是会更严重地转移到企业身上。

在发现此类问题后，可能很难在收单行或支付提供商那里重建信任。由于加密失败也往往会暴露内部数据处理方面的其他薄弱环节，因此如果在其他环节发现漏洞，即使只是纠正了某一项控制措施，银行也可能不会满意。

Stripe Payments 如何提供帮助

Stripe Payments 提供一体化的全球支付解决方案，能够助力各类企业（从成长型初创企业到全球性企业）在全球范围内接受线上、线下付款。

Stripe Payments 可帮助您：

• 优化您的结账体验： 借助预置的支付用户界面、对 125 种以上支付方式的访问权限以及由 Stripe 构建的钱包 Link，创造顺畅的客户体验并节省工程开发时间。

• 更快拓展新市场：覆盖全球客户，并通过跨境支付选项降低多币种管理的复杂性和成本，覆盖 195 个国家/地区，支持 135 种以上货币。

• 统一线下与线上支付：整合线上与线下渠道，打造一体化商务体验，实现个性化互动、提升客户忠诚度并增加营收。

• 提升支付表现：通过一系列可定制、易于配置的支付工具增加营收，包括无代码欺诈防护和提高授权率的高级功能。

• 利用灵活、可靠的平台加速业务增长：选择一个专为随业务扩展而设计的平台，历史正常运行时间达 99.999%，可靠性在行业内首屈一指。

进一步了解 Stripe Payments 如何为您的线上和线下付款提供支持，或者立即开始使用。