自 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 数据安全标准 (PCI DSS) 概述
PCI DSS 是面向所有存储、处理或传输持卡人数据和/或敏感验证数据的实体的全球性安全标准。PCI DSS 为消费者设定了一个基准保护级别,能够帮助减少整个支付系统的欺诈和数据泄露问题。它适用于任何接受或处理支付卡的组织。
PCI DSS 合规性涉及三个主要组成部分:
1.处理客户信用卡数据的准入,即安全地收集和传输敏感信用卡信息
2.安全地存储数据,这在 PCI 标准的 12 个安全域中有所概述,例如加密、持续监控和对支付卡数据的访问进行安全测试
3.每年都要验证所需的安全控制措施是否到位,这可以包括表单、问卷、外部漏洞扫描服务及第三方审核(见下方的分步指南,表格中包含有四个级别的要求)
处理卡数据
某些商业模式确实需要在接受付款时直接处理敏感的信用卡数据,而有些则不然。需要处理卡数据的公司(例如付款页面上接受未加密的 PAN)可能需要满足 PCI DSS 中所有 300 多项安全控制。即使卡数据仅在短时间内通过其服务器,相关公司也需要购买、实施和维护安全软件和硬件。
如果一家公司并不需要处理敏感卡数据,则应没有这种要求。第三方解决方案(例如,Stripe Elements)可以安全地接受和存储数据,从而在很大程度上消除或降低复杂性、成本和风险。由于卡数据不接触其服务器,公司只需要符合 22 项安全控制措施,其中大部分都很简单直接,例如使用较为安全的强密码。
安全存储数据
如果一家组织需要处理或存储信用卡数据,则需要定义其持卡人数据环境(缩写 CDE)的范围。PCI DSS 将 CDE 定义为存储、处理或传输信用卡数据的人员、流程和技术,或任何与其连接的系统。鉴于 PCI DSS 中的所有 300 多项安全要求都适用于 CDE,因此将支付环境与其他业务部门进行适当分割是非常重要的,这样可以限制 PCI 验证的范围。如果一家组织无法精细分割 CDE 范围,那么 PCI 安全控制措施就会适用于企业网络上的每个系统、笔记本电脑和设备,这可不太妙!
年检
无论以何种方式接受银行卡数据,相关组织都需要每年完成一份 PCI 检验表。验证 PCI 合规的方式取决于许多因素,以下是相关组织可能会被要求证明其符合 PCI 标准的 3 种情况:
- 支付服务商在向支付卡品牌提供必要报告时可能会有此要求。
- 商业合作伙伴可能会有此要求,作为签订商业协议的先决条件。
- 对于平台企业(其技术能够帮助各种不同的用户进行在线交易),客户可能会有此要求,以便向自己的客户证明他们是在以安全的方式处理数据。
最新的安全标准 PCI DSS 版本 3.2.1中包括 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 v3.2.1 合规分步指南
1. 了解您需符合的要求
实现 PCI 合规的第一步是了解哪些要求适用于您的公司。PCI 有 4 个合规级别,通常基于您公司在 12 个月内处理的信用卡交易量。
合规等级
|
适用于
|
要求
|
---|---|---|
1 级
|
|
|
2 级
|
年交易量在 100 万-600 万笔的企业 | |
3 级
|
|
同上 |
4 级
|
|
同上 |
针对 2-4 级别,根据您的支付集成方式可选择不同的 SAQ 类别。此处是一个简略的表格:
SAQ
|
描述
|
---|---|
A
|
将所有持卡人数据功能完全外包给第三方 PCI DSS 合规服务提供商的不需要展示真实银行卡的商家(电子商务或邮件/电话订单),商家的系统或设施不对任何持卡人数据进行电子存储、处理或传输。
不适用于面对面的渠道。 |
A-EP
|
将所有支付处理外包给经 PCI DSS 验证的第三方的电子商务商家,并且商家所拥有的网站不直接接收持卡人数据但可能影响支付交易安全性。商家的系统或设施不对持卡人的数据进行电子存储、处理或传输。
仅适用于电商渠道。 |
B
|
商家仅使用:
|
B-IP
|
仅使用 PTS 认可的独立支付终端的商家,其 IP 连接到支付处理器,不存储持卡人的电子数据。
不适用于电商渠道。 |
C-VT
|
用键盘将交易逐笔手动输入基于互联网的虚拟支付终端解决方案的商家,该解决方案由 PCI DSS 验证的第三方服务提供商提供和托管。不存储持卡人的电子数据。
不适用于电商渠道。 |
C
|
支付应用系统连接到互联网的商家,不存储持卡人的电子数据。
不适用于电商渠道。 |
P2PE
|
仅使用特定硬件支付终端的商家,该终端包含在经过验证的 PCI SSC 列出的点对点加密 (P2PE) 解决方案中,并通过该解决方案进行管理,不存储持卡人的电子数据。
不适用于电商渠道。 |
D
|
针对商家的 SAQ D:所有未包含在上述 SAQ 类型描述中的商家。
针对服务提供者的 SAQ D:支付品牌定义的所有有资格完成 SAQ 的服务提供者。 |
2. 映射反应您的数据流
要想保护敏感的信用卡数据,您需要首先知道它的位置以及它是通过何种路径到达的。您需要针对与您整个公司的信用卡数据进行交互的系统、网络连接和应用,创建一个完整的映射图。根据您业务职能的不同,您可能需要与您的 IT 及安全团队成员合作,来完成该任务。
- 首先,确定涉及支付交易的每一个面向消费者的业务领域。例如,您可能是通过网上购物车、店内支付终端或电话订单接受付款。
- 接下来,明确整个公司处理持卡人数据的不同方式。要确切知道数据的存储位置以及谁拥有访问权限,这一点很重要。
- 之后,确定接触支付交易的内部系统或底层技术。这包括您的网络系统、数据中心和云环境。
3. 检查安全控制和协议
一旦确定了整个公司内信用卡数据的所有潜在接触点,立即与 IT 和安全团队合作,确保部署了恰当的安全配置和协议(参见本文前述的 PCI DSS 12 项安全要求)。这些协议旨在对数据传输提供保护,例如 Transport Layer Security (TLS)。
PCI DSS v3.2.1 的 12 项安全要求源于保护任何企业敏感数据的最佳实践方式。其中有些与 GDPR、HIPAA 和其他隐私权要求有所重叠,因此其中一些可能已经在您的公司实施。
4. 监测与维护
值得注意的是,PCI 合规并不是一次性事件,这是一个持续的过程。随着数据流和客户接触点的不断发展,同时也要确保业务的合规性。有些信用卡品牌可能会要求您提交季度或年度报告,或完成年度现场评估以持续验证合规性(尤其是如果您每年的交易量超过 600 万笔)。
全年(以及每年)管理 PCI 合规通常需要跨部门的支持和协作。在内部组建一个专门的团队来正确维护合规性是一个较为可行的方式(如果您尚未设立此类团队的话)。当然,每家公司都有自身的独特性,但是,PCI 团队的最初构成通常包括:
- 安全:首席安全官 (CSO)、首席信息安全官 (CISO) 及其团队能够确保组织始终对必要的数据安全和隐私资源和政策进行适当投入。
- 技术/支付:首席技术官 (CTO)、支付副总裁及其团队能够确保核心工具、集成和基础架构在组织系统发展过程中保持合规性。
- 财务:首席财务官 (CFO) 及其团队能够确保在应对支付系统和合作伙伴事务时,考虑到所有的支付数据流。
- 法律:该团队可以帮助解决 PCI DSS 合规要求在法律方面的诸多细微差别。
有关 PCI 合规的更多复杂信息,请访问 PCI 安全标准委员会网站。如果您只阅读过本指南和少部分其他 PCI 文档,建议先从这些内容开始:PCI DSS 首选方法、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 表单 (SAQ),这样可以一键完成 PCI 验证。对于规模较小的企业来说,这可以节省几百个小时的工作时间,而对于较大的企业,则可以节省数千个小时。
对于我们的所有用户(无论集成方式如何),Stripe 扮演着 PCI 推动者的角色,可以通过几个不同的方式提供帮助。
- 分析您的集成方式,建议您应该使用哪一个 PCI 表单,以及如何减少您的合规负担。
- 如果交易量增加使您需要更改您的验证合规方式,我们会提前通知您。
- 针对大型商家(1 级),我们提供一项 PCI 组合包,可以缩短 PCI 验证时间(从几个月缩短为几天)。如果您需要与一家 PCI QSA 合作(因为贵方存储信用卡数据或者拥有更为复杂的支付流程),不必担心,全球有超过 350 家这类 QSA 公司,我们可以帮助您联系一些深入了解 Stripe 各种不同集成方式的审计师。
结论
对 PCI 合规的评估和验证通常每年进行一次,但 PCI 合规并非一次性事件——它是持续进行的评估和补救工作。公司的发展会带来核心业务逻辑和流程的增长,这意味着合规性也要跟上。例如,线上企业可能决定开设实体店、进入新市场或设立客户支持中心。如果有任何新内容涉及支付卡数据,最好主动检查这是否会对您的 PCI 验证方式产生任何影响,并在必要时重新验证 PCI 合规性。
PCI 合规对您有益,但这还不够
遵守 PCI DSS 是您公司的一项必要保护措施,但仅做到这点还不够。PCI DSS 为处理和存储持卡人的数据设定了重要标准,但其本身并不能为每个支付环境都提供足够的保护。寻求更安全的接受银行卡支付的方式(如 Stripe Checkout、Elements 和移动 SDK)则是一种更有效的方法。从长远利益来看,您就不必依赖行业基线标准或担心安全控制的潜在失败风险。这种方法让敏捷公司得以中和潜在数据泄露的风险,并避免了传统 PCI 验证方式所耗费的精力、时间和成本。更重要的是,更安全的集成方法能够提供全天候的可靠保护。
Visa 的商家级别
|
平均审计时间
(每年估计值) |
Stripe Elements、Checkout 或 Mobile SDK 的平均审计时间
(每年估计值) |
---|---|---|
1 级
|
3-5 个月 | 2-5 天 |
2 级
|
1-3 个月 | 0 天 |
3 级
|
1-3 个月 | 0 天 |
4 级
|
1-3 个月 | 0 天 |