简介
自 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 的官方文件有 1,800 多页,其中有超过 300 页只是为了说明使用哪种表单来达到合规。单纯是“阅读”这些内容就需要 72 个小时以上的时间。
为了减轻这一负担,以下我们提供了关于 PCI 合规验证和维护的分步指南。
PCI 数据安全标准(PCI DSS)概述
PCI DSS 是面向所有存储、处理或传输持卡人数据和/或敏感验证数据的所有实体的全球性安全标准。PCI DSS 为消费者设定了一个基准保护级别,能够帮助减少整个支付系统的欺诈和数据泄露问题。它适用于任何接受或处理支付卡的组织。
PCI DSS 合规涉及 3 项主要内容:
- 处理来自客户的信用卡数据的准入,即安全地收集和传输具体的敏感支付信息。
- 安全地存储数据,这在 PCI 标准的 12 个安全域中有所概述,例如加密、持续监控和对支付卡数据的访问进行安全测试。
- 每年都要验证所需的安全控制措施是否到位,这可以包括表单、问卷、外部漏洞扫描服务及第三方审核(见下方的分步指南,表格中包含有四个级别的要求)
处理卡数据
某些商业模式确实需要在接受付款时直接处理敏感的信用卡数据,而有些则不然。需要处理卡数据的公司(例如付款页面上接受未加密的 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 多个次级要求反映了最佳安全实践方式。
- 安装并维护防火墙配置,保护持卡人数据
- 不要将供应商提供的默认选择用于系统密码和其他安全性参数
- 保护所存储的持卡人数据
- 在开放或公共网络上加密传输持卡人数据
- 保护所有系统免受恶意软件的侵害,定期更新防病毒软件
- 开发和维护安全的系统和应用程序
- 根据业务需要限制对持卡人数据的访问
- 辨别和验证对系统组件的访问权限
- 限制对持卡人数据的物理访问
- 跟踪和监控对网络资源和持卡人数据的所有访问
- 定期测试安全系统和流程
- 维持一项解决所有人员信息安全问题的政策
创建和维护安全的网络和系统
保护持卡人数据
维持一项漏洞管理程序
实施严格的访问控制措施
定期检测和测试网络
维持一项信息安全政策
为了使新企业“更容易”获得 PCI 合规验证,PCI 委员会创建了九种不同形式的自我评估问卷(SAQ),这些内容包含在 PCI DSS 的整个要求中。这其中的诀窍是要弄清楚哪些是适用的内容,或者是否有必要聘请经 PCI 委员会批准的审核人员来验证是否已满足每项 PCI DSS 安全要求。此外,PCI 委员会每三年修订一次规则,并且全年都会发布新增更新,这更增加了不断变化的复杂性。
PCI DSS v3.2.1 合规分步指南
1. 了解您要符合的要求
实现 PCI 合规的第一步是了解哪些要求适用于您的公司。PCI 合规级别有 4 个,通常基于的是您的公司在 12 个月内处理的信用卡交易额。
适用于 | 要求 | |
1 级 |
|
|
2 级 | 年交易额在 1-6 百万的公司 | |
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 的服务提供者。 |
要想选择最适合贵公司的 SAQ 和证明文档,可使用该 PCI 文件第 18 页的流程图。
PCI DSS 要求不断变化,因此获得这些变化中的认证要求并了解如何满足这些要求的最佳方法之一就是成为一家 PCI 参与组织 (PO) 。
2. 映射反应您的数据流
要想保护敏感的信用卡数据,您需要知道它的位置以及它是通过何种路径达到这里的。您需要针对与您整个公司的信用卡数据进行交互的系统、网络连接和应用创建一个完整的映射图。根据您的角色职能不同,您可能需要与您的 IT 及安全团队成员合作,来完成该任务。
- 首先,确定涉及支付交易的每一个面向消费者的业务领域。例如,您可能是通过网上购物车、店内支付终端或电话订单接受付款。
- 接下来,明确整个公司处理持卡人数据的不同方式。要确切知道数据的存储位置以及谁拥有访问权限,这一点很重要。
- 之后,确定接触支付交易的内部系统或底层技术。这包括您的网络系统、数据中心和云环境。
3. 检查安全控制和协议
一旦确定了整个公司内信用卡数据的所有潜在接触点,即与 IT 和安全团队合作,确保部署了恰当的安全配置和协议(参见 PCI DSS 12 项安全要求 列表)。这些协议旨在对数据传输提供保护,例如 Transport Layer Security (TLS)。
CI 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 还能让持卡人直接将敏感的付款信息发送到我们的服务器。
通过这些更安全的收款方式,我们会在 Stripe 管理平台填充 PCI 表单(SAQ),这样可以一键完成 PCI 验证。对于规模较小的企业来说,这可以节省几百个小时的工作时间,而对于较大的企业,则可以节省数千个小时。
对于我们的所有用户(无论集成方式如何),Stripe 扮演着 PCI 推动者的角色,可以通过几个不同的方式提供帮助。
- 分析您的集成方式,建议您应该使用哪一个 PCI 表单,以及如何减少您的合规负担。
- 如果交易量增加使您需要更改您的验证合规方式,我们会提前通知您。
- 针对大型商家(1级),我们提供一项 PCI-组合包,可以缩短 PCI 验证时间(从几个月缩短为几天)。如果您需要与一家 PCI QSA 合作(因为贵方存储信用卡数据或者拥有更为复杂的支付流程),不必担心,全球有超过 350 家这类 QSA 公司,我们可以帮助您联系一些深入了解 Stripe 各种不同集成方式的审核人员。
Visa 的商家级别 | 平均审核时间 (每年评估) | Stripe Elements、Checkout 或Mobile SDK 的平均审核时间 (每年评估) |
1 级 | 3-5 个月 | 2-5 天 |
2 级 | 1-3 个月 | 0 天 |
3 级 | 1-3 个月 | 0 天 |
4 级 | 1-3 个月 | 0 天 |
如需了解有关 Stripe 如何帮助您保护客户数据并实现 PCI 合规的更多信息,请查看我们关于集成安全性的文档。
结论
对 PCI 合规的评估和验证通常每年进行一次,但 PCI 合规并非一次性事件——它是持续进行的评估和补救工作。公司的发展会带来核心业务逻辑和流程的增长,这意味着合规性也要跟上。例如,线上企业可能决定开设实体店、进入新市场或设立客户支持中心。如果有任何新内容涉及支付卡数据,最好主动检查这是否会对您的 PCI 验证方式产生任何影响,并在必要时重新验证 PCI 合规性。
PCI 合规帮助。多少都不算多。
遵守 PCI DSS 指南是您公司的一项必要保护措施,但这还不够。PCI DSS 为处理和存储持卡人的数据设定了重要标准,但其本身并不能为每个支付环境都提供足够的保护。寻求更安全的接受银行卡支付的方式(如Stripe Checkout、Elements 和移动 SDK)则是的一种更有效的方法。从长远利益来看,您不需要依赖行业基线标准或担心安全控制的潜在失败风险。这种方法为敏捷的公司提供了一种减轻潜在的数据泄露的方法,并避免了传统 PCI 验证方式所耗费的精力、时间和成本。更重要的是,更安全的集成方法能够提供全天候的可靠保护。
返回指南