自 2005 年以来，累计有超过 110 亿条消费者记录在 8500 多次数据泄露中遭到泄露。这是来自隐私权信息交换所的最新数据，其中报告了自 2005 年以来对消费者造成重大影响的数据泄露和安全漏洞事件。
为了提高消费者数据的安全性和对支付系统的信任，相关组织设立了一个数据安全的最低标准。Visa、Mastercard、American Express、Discover 和 JCB 于 2006 年成立了支付卡行业安全标准委员会 (PCI SSC)，负责管理信用卡数据处理公司的安全标准。在 PCI SSC 设立之前，这五家信用卡公司都有自己的安全标准程序，且都具有大致相似的要求和目标。他们通过 PCI SSC 联合起来，实施同一项标准政策，即 PCI 数据安全标准（简称 PCI DSS），在互联网时代为消费者和银行提供基线水平的保护。
对 PCI DSS 进行深入理解是一项颇为复杂且具有挑战性的工作
如果您的商业模式使得您必须要处理卡数据，那么您可能需要满足 PCI DSS 中全部 300 多项安全控制标准。PCI 委员会发布的关于 PCI DSS 的官方文件超过 1800 页，其中仅仅用来说明使用何种表单来验证合规的内容就有 300 多页。单纯是阅读这些内容就需要 72 个小时以上。
为了减轻您的负担，以下是我们提供的关于 PCI 合规验证和维护的分步指南。
PCI DSS 版本 4.0 将于 2024 年 3 月 31 日生效
PCI 数据安全标准 (PCI DSS) 概述
PCI DSS 是面向所有存储、处理或传输持卡人数据和/或敏感验证数据的实体的全球性安全标准。PCI DSS 为消费者设定了一个基准保护级别，能够帮助减少整个支付系统的欺诈和数据泄露问题。它适用于任何接受或处理支付卡的组织。
PCI DSS 合规性涉及三个主要组成部分：
- 处理客户信用卡数据的准入，即安全地收集和传输敏感信用卡信息
- 安全地存储数据，这在 PCI 标准的 12 个安全域中有所概述，例如加密、持续监控和对支付卡数据的访问进行安全测试
- 每年都要验证所需的安全控制措施是否到位，这可以包括表单、问卷、外部漏洞扫描服务及第三方审核（见下方的 分步 指南，表格中包含有四个级别的要求）
处理卡数据
某些商业模式确实需要在接受付款时直接处理敏感的信用卡数据，而有些则不然。需要处理卡数据的公司（例如在支付页面上接受未加密的 PAN）可能需要满足 PCI DSS 中全部 300 多项安全控制措施要求。即使卡数据仅在短时间内通过其服务器，相关公司也需要购买、实施和维护安全软件和硬件。
如果一家公司并不需要处理敏感信用卡数据，则应没有这种要求。第三方解决方案（例如，Stripe Elements）可以安全地接受和存储数据，从而在很大程度上消除或降低复杂性、成本和风险。由于卡数据不接触其服务器，公司只需要符合部分安全控制措施，其中大部分都是很简单直接的措施，例如使用较为安全的强密码。
安全存储数据
如果一家组织需要处理或存储信用卡数据，则需要定义其持卡人数据环境（缩写 CDE）的范围。PCI DSS 将 CDE 定义为存储、处理或传输信用卡数据的人员、流程和技术，或任何与其连接的系统。鉴于 PCI DSS 中的所有 300 多项安全要求都适用于 CDE，因此将支付环境与其他业务部门进行适当分割是非常重要的，这样可以限制 PCI 验证的范围。如果一家组织无法精细分割 CDE 范围，那么 PCI 安全控制措施就会适用于企业网络上的每个系统、笔记本电脑和设备，这可不太妙！
年检
无论以何种方式接受银行卡数据，相关组织都需要每年完成一份 PCI 检验表。验证 PCI 合规的方式取决于许多因素，具体如下。以下是相关组织可能会被要求证明其符合 PCI 标准的 3 种情境：
- 支付服务商在向支付卡品牌提供必要报告时可能会有此要求。
- 商业合作伙伴可能会有此要求，作为签订商业协议的先决条件。
- 对于平台企业（其技术能够帮助各种不同的用户进行在线交易），客户可能会有此要求，以便向自己的客户证明他们是在以安全的方式处理数据。
PCI DSS 安全标准 中包括 12 个主要要求，其中 300 多个次级要求反映了领先的安全实践。
创建和维护安全的网络和系统
- 1. 安装和维护网络安全控制措施。
- 2. 对所有系统组件应用安全配置。
保护账户数据
- 3. 保护已存储的持卡人数据。
- 4. 在开放的公共网络传输过程中，使用强加密技术保护持卡人数据。
维护一项漏洞管理计划
- 5. 保护所有系统和网络，使其免受恶意软件的攻击。
- 6. 开发和维护安全系统和软件。
实施严格的访问控制措施
- 7. 根据业务需要限制对系统组件和持卡人数据的访问。
- 8. 识别用户并对系统组件的访问权限进行身份验证。
- 9. 限制对持卡人数据的物理访问。
定期检测和测试网络
- 10. 记录和监控对系统组件和持卡人数据的所有访问。
- 11. 定期测试系统和网络的安全性。
维护一项信息安全政策
- 12. 利用组织层面的政策和程序，支持信息安全。
为了使新企业相对容易地获得 PCI 合规验证，PCI 委员会创建了九种不同形式的自我评估问卷 (SAQ)，这些内容包含在 PCI DSS 的整体要求中。其中的棘手之处在于要弄清楚哪些是适用的内容，或者是否有必要聘请经 PCI 委员会批准的审计师来验证是否已满足每项 PCI DSS 安全要求。此外，PCI 委员会每三年修订一次规则，并且全年都会发布新增更新，这更增加了不断变化的复杂性。
PCI DSS 合规分步指南
1.了解您需符合的要求
实现 PCI 合规的第一步是了解哪些要求适用于您的公司。PCI 有 4 个合规级别，通常基于您公司在 12 个月内处理的信用卡交易量。
|
合规等级
|
适用对象
|
要求
|
|---|---|---|
|
1 级
|
|
|
|
2 级
|
|
|
|
3 级
|
|
|
|
4 级
|
|
|
针对 2-4 级别，根据您的支付集成方式可选择不同的 SAQ 类别。此处是一个简略的表格：
|
集成
|
要求
|
建议
|
|---|---|---|
|
Checkout 或 Elements
|
SAQ A |
Checkout 以及 Stripe.js 和 Elements 在 Stripe 的域名（而非您的域名）提供的 iframe 内托管所有银行卡数据收集输入字段，因此您客户的银行卡信息永远不会接触到您的服务器。
|
|
Connect
|
SAQ A | 如果您仅仅通过 Connect 平台（如 Squarespace）收集银行卡数据，我们可以确定平台是否提供了必要的 PCI 文档。 |
|
移动端 SDK
|
SAQ A |
Stripe 的移动端 SDK 的开发和修改控制符合 PCI DSS（要求 6.3 - 6.5）的要求，并且是通过我们的 PCI 验证系统来实施的。当您仅使用来自我们官方的 iOS 或 Android SDK 的用户界面组件时，或者在 WebView 中使用 Elements 构建支付表单时，卡号将直接从您的客户传递到 Stripe，因此您的 PCI 合规负担最轻。 如果您不这样做，例如编写自己的代码来处理银行卡信息，则您可能需要负责额外的 PCI DSS 要求 (6.3-6.5)，并且不再具有 SAQ A 资格。请与 PCI 合格安全评估员 (QSA) 联系，以确定如何根据 PCI 委员会的现行指南来最好地验证您的合规性。 如果您的应用程序要求客户在他们自己的设备上输入其信息，那么您便有资格使用 SAQ A。如果您的应用程序在您的设备上接受多个客户的银行卡信息（例如，销售点应用程序），则请咨询 PCI 合格安全评估员，了解如何最好地验证您的 PCI 合规性。 |
|
Stripe.js v2
|
SAQ A-EP | |
|
Terminal
|
SAQ C |
如果您专门通过 Stripe Terminal 收集银行卡数据，则可以使用 SAQ C 进行验证。 如果您使用本表所列的其他方法与 Stripe 集成，则必须按照描述，分别证明它们的合规性。 |
|
管理平台
|
SAQ C-VT |
只有在特殊情况下才可以通过管理平台手动处理银行卡付款，不可作为常规付款处理方式。为您的客户提供合适的支付表单或移动应用程序来输入他们的银行卡信息。 我们无法验证手动输入的银行卡信息在 Stripe 之外是否安全，因此您必须根据 PCI 合规要求保护银行卡数据，并每年完成 SAQ C-VT，以证明您的业务符合 PCI 合规要求。 |
|
直接 API
|
SAQ D |
2.映射反应您的数据流
要想保护敏感的信用卡数据，您需要首先知道它的位置以及它是通过何种路径到达的。您需要针对与贵组织的信用卡数据进行交互的系统、网络连接和应用程序，创建一个完整的映射图。根据您业务职能的不同，您可能需要与您的 IT 及安全团队成员合作，来完成该任务。
- 首先，确定涉及支付交易的每一个面向消费者的业务领域。例如，您可能是通过网上购物车、店内支付终端或电话订单接受付款。
- 接下来，明确整个公司处理持卡人数据的不同方式。要确切知道数据的存储位置以及谁拥有访问权限，这一点很重要。
- 之后，确定接触支付交易的内部系统或底层技术。这包括您的网络系统、数据中心和云环境。
3.检查安全控制措施和协议
一旦确定了贵组织内信用卡数据的所有潜在接触点，即与 IT 和安全团队合作，确保部署了恰当的安全配置和协议（参见上文 PCI DSS 12 项安全要求列表）。这些协议旨在对数据传输提供保护，例如传输层安全 (TLS)。
PCI DSS 的 12 项安全要求源于保护任何企业敏感数据的领先实践方式。其中有些与 GDPR（欧盟通用数据保护条例）、HIPAA 和其他隐私权要求有所重叠，因此其中一些可能已经在贵组织实施。
4.监测与维护
值得注意的是，PCI 合规并不是一次性事件。这是一个持续的过程。随着数据流和客户接触点的不断发展，同时也要确保业务的合规性。有些信用卡品牌可能会要求您提交季度或年度报告，或完成年度现场评估以持续验证合规性（尤其是如果您每年的交易量超过 600 万笔）。
全年（以及每年）管理 PCI 合规通常需要跨部门的支持和协作。在内部组建一个专门的团队来妥善维护合规性是一个较为可行的方式（如果您尚未设立此类团队的话）。当然，每家公司都有自身的独特性，但是，“PCI 团队”的最初构成通常包括：
- 安全：首席安全官 (CSO)、首席信息安全官 (CISO) 及其团队能够确保组织始终对必要的数据安全和隐私资源和政策进行适当投入。
- 技术/支付：首席技术官 (CTO)、支付副总裁及其团队能够确保核心工具、集成和基础架构在组织系统发展过程中保持合规性。
- 财务：首席财务官 (CFO) 及其团队能够确保在应对支付系统和合作伙伴事务时，考虑到所有的支付数据流。
- 法律：该团队可以帮助解决 PCI DSS 合规要求在法律方面的诸多细微差别。
如需详细了解复杂的 PCI 合规问题，请访问 PCI 安全标准委员会网站。如果您只阅读过本指南和一些其他 PCI 文档，我们建议先从这些内容开始了解：首选方法，SAQ 说明及指南，使用 SAQ 资格标准确定 现场评估要求 的常见问题，以及为接受支付卡数据的消费者设备 开发应用程序的商家义务 的常见问题。
Stripe 如何帮助组织达成和维护 PCI 合规
对于集成使用 Checkout、Elements、移动 SDK 和 Terminal SDK 的公司来说，Stripe 能够显著减轻 PCI 带来的负担。Stripe Checkout 和 Stripe Elements 使用托管的支付字段来处理所有支付卡信息。这样一来，持卡人在支付字段输入的所有敏感支付信息都直接来自于我们经 PCI DSS 认证的服务器。Stripe 移动 SDK 和 Terminal SDK 还能让持卡人将敏感的支付信息直接发送到我们经 PCI DSS 认证的服务器。
对于我们的所有用户（无论集成类型如何），Stripe 扮演着 PCI 推动者的角色，可以通过几个不同的方式提供帮助。
- 分析您的集成方式，针对如何减轻合规负担提供建议。
- 如果交易量增加使您需要更改您的合规验证方式，我们会提前通知您。
- 针对大型商家（1 级），如果您需要与一家 PCI QSA 合作（因为您存储信用卡数据或者拥有更为复杂的支付流程），全球有超过 350 家这类 QSA 公司 可供选择，我们可以帮助您联系一些对 Stripe 各种集成方式颇有了解的审计人员。