PCI DSS 3.0 要求

本文详细介绍了PCI-DSS要求。PCI DSS 3.0（支付卡行业数据安全标准3.0）的要求旨在促进并增强持卡人的数据安全，便于统一的数据安全措施在全球范围内的广泛应用。

PCI DSS 3.0 要求

• 建立并维护安全的网络和系统
  • 要求 1：安装并维护防火墙配置以保护持卡人数据
    • 1.1 建立并实施包含以下内容的防火墙和路由器配置标准：
    • 1.2 构建防火墙和路由器配置，以限制不可信网络与持卡人数据环境中任意系统组件之间连接。
    • 1.3 禁止互联网与持卡人数据环境中任何系统组 件之间的直接公共访问。
    • 1.4 在位于外网时仍连接到互联网且可用以访问 网络的任意移动设备和/或员工自有设备（例 如，员工使用的笔记本电脑）上安装个人防火墙 软件。防火墙配置包括：  个人防火墙软件设有特定的配置设置  个人防火墙软件正在积极运行  移动设备用户和/或员工自有设备用户无 法更改个人防火墙软件。
    • 1.5 确保已记录、正在使用且所有相关方了解用于防火墙管理的安全政策和操作程序。
  • 要求 2：不要使用供应商提供的默认系统密码和其他安全参数
    • 2.1 始终更改供应商提供的默认值并于在网络中 安装系统之前删除或禁用不必要的默认帐户。
    • 2.2 制定适合所有系统组件的配置标准。确保 这些标准能解决所有已知的安全漏洞并与行 业认可的系统强化标准一致。行业认可的系统强化标准来源包括但不限于：  互联网安全中心 (CIS)  国际标准化组织 (ISO)  美国系统网络安全协会 (SANS)  国家标准与技术研究所 (NIST)
    • 2.3 使用强效加密法对所有非控制台管理访 问进行加密。对于基于 web 的管理和其他非 控制台管理访问，可采用 SSH、VPN 或 SSL/TLS 等技术。
    • 2.4 保留一份 PCI DSS 范围内系统组件的清单
    • 2.5 确保已记录、正在使用且所有相关方了解 用于管理供应商默认设置及其他安全参数的安全政策和操作程序。
    • 2.6 共享托管服务提供商必须保护每个实体的 托管环境和持卡人数据。这些提供商必须符合 附录 A：《针对共享托管服务提供商的 PCI DSS 附加要求》中详述的具体要求。
• 保护持卡人数据
  • 要求 3：护存储的持卡人数据
    • 3.1 通过实施数据保留和处理政策、程序 和流程最大限度地减少持卡人数据存储， 对所有持卡人数据 (CHD) 存储而言，这些 政策、程序和流程至少应包含以下方面：  将数据存储量和保留时间限制在法 律、法规和业务要求的范围内  不再需要时安全删除数据的流程  持卡人数据的具体保留要求  按季度查找并安全删除所存储的超过 规定保留期限的持卡人数据的流程。
    • 3.2 授权之后，不要存储敏感验证数据（即使已加密）。如果收到敏感验证数 据，在完成验证流程后使所有数据不可恢 复。在下列情况下，允许发卡机构和支持发卡 服务的公司存储敏感验证数据：  有正当的业务理由且  数据存储安全。 敏感验证数据包括下文要求 3.2.1 至 3.2.3中列举的数据：
    • 3.3 显示 PAN 时予以掩盖（最多显示前 六位和后四位数字），这样仅具有正当业 务需要者方可看到完整的 PAN。 注：该要求不能取代现行更严格的有关持 卡人数据显示的要求，例如法律或支付卡 品牌对销售点 (POS) 收据的要求。
    • 3.4 通过采取下列任一方法使所有位置（包括便携式数字媒介上、备份媒介上和 日志中）存储的 PAN 均不可读：  基于强效加密法的单向散列函数（散 列必须要有完整的 PAN）  截词（不能用散列代替 PAN 被截词 的部分）  索引记号与索引簿（索引簿必须安全 地存储）  具有相关密钥管理流程和程序的强效 加密法 注：对恶意个人而言，如果能访问被截词 和散列的 PAN，要重建原始 PAN 数据是 件相当轻松的事。如果在实体环境中出现 同一个 PAN 的散列版本和截词版本，则 应采取额外控制措施，确保散列版本和截 词版本不能被相互关联，用于重建原始 PAN。"
    • 3.5 记录并实施保护程序，以保护用于防 止存储的持卡人数据被泄露和滥用的密钥： 注：本要求适用于用来为存储的持卡人数 据加密的密钥，也适用于用来保护数据加 密密钥的密钥加密密钥，这些密钥加密密 钥至少须与数据加密密钥一样强效。
    • 3.6 充分记录并实施用于持卡人数据加密 的所有密钥管理流程和程序，包括： 注：包括 NIST（可在 http://csrc.nist.gov 找到）在内的各种资源均提供有大量密钥 管理方面的行业标准。
    • 3.7 确保已记录、正在使用且所有相关方了解用于保护所存储持卡人数据的安全政策和操作程序。
  • 要求 4：加密持卡人数据在开放式公共网络中的传输
    • 4.1 使用强效加密法和安全协议（例如， SSL/TLS、IPSEC、SSH 等） 来保护在 开放式公共网络中传输的敏感持卡人数 据，包括：  只接受可信的密钥和证书  使用的协议只支持安全的版本或配置  加密强度适合所使用的加密方法 开放式公共网络包括但不限于：  互联网  无线技术，包括 802.11 和蓝牙  蜂窝技术，例如，全球移动通信系统 (GSM)、码分多址 (CDMA)  通用分组无线业务 (GPRS)。  卫星通信"
    • 4.2 不要使用终端用户通讯技术（例如， 电子邮件、即时通讯、聊天等）来传送不 受保护的 PAN。
    • 4.3 确保已记录、正在使用且所有相关方 了解用于加密持卡人数据传输的安全政策 和操作程序。
• 维护漏洞管理计划
  • 要求 5：为所有系统提供恶意软件防护并定期更新杀毒软件或程序
    • 5.1 在经常受恶意软件影响的所有系统（特别是个人电脑和服务器）中部署杀毒 软件。
    • 5.2 确保所有杀毒机制按如下方式维护：  保持为最新，  执行定期扫描  生成检查日志（PCI DSS 要求10.7 规定保留）
    • 5.3 确保杀毒机制积极运行且无法被用户禁 用或更改，除非管理人员根据具体情况做出 有时间限制的明确授权。 注：只有存在合理的技术需要且根据具体情 况经管理人员批准时，才能暂时禁用杀毒解 决方案。若出于特定目的需要禁用杀毒软件 保护，必须获得正式授权。杀毒软件保护禁 用期间，需要实施其他安全措施。
    • 5.4 确保已记录、正在使用且所有相关方了 解为系统提供恶意软件防护的安全政策和操 作程序。
  • 要求 6：开发并维护安全的系统和应用程序
    • 6.1 制定相关流程，通过使用外部信源获 取安全漏洞信息来识别安全漏洞，并为新 发现的安全漏洞指定风险等级（例如 “高”、“中”或“低”）。 注：风险等级应以行业最优方法和潜在影 响考虑为依据。例如，漏洞分级标准可能 包括对 CVSS 基础得分的考虑及/或供应商的分类及/或相关系统的类型。 根据组织的环境和风险评估策略不同，评 估漏洞和指定风险等级的方法也不尽相 同。风险等级至少应标识出所有被视为对 环境具有“高风险”的漏洞。除风险等级 外，如果安全漏洞即将对环境造成威胁、 影响关键系统且/或如果不解决可能会造成 潜在危害，则可被视为“重要”。关键系统 可能包括安全系统、面向公众的设备和系 统、数据库以及其他存储、处理或传输持 卡人数据的系统。
    • 6.2 通过安装供应商提供的适用安全补 丁，确保所有系统组件和软件均杜绝已知 漏洞。在发布后一个月内安装关键的安全 补丁。 注：应按照要求 6.1 中规定的风险分级流程标识关键安全补丁。
    • 6.3 遵照如下要求安全地开发内部和外部 软件应用程序（包括基于 web 的应用程序 管理访问）：  按照 PCI DSS（例如安全验证和记 录）  基于行业标准和/或最优方法。  将信息安全纳入软件开发的整个生命 周期。 注：该要求适用于所有内部开发的软件以 及由第三方开发的定制软件
    • 6.4 系统组件的所有变更均须遵守变更控 制流程和程序。该流程必须包括如下内 容：
    • 6.5 按照以下操作解决软件开发流程中常 见的编码漏洞：  为开发人员提供关于安全编码技术的 培训，包括如何避免常见的编码漏 洞，并理解敏感数据在内存中的处理 方式。  根据安全编码指南开发应用程序 注：在本版本 PCI DSS 发布时，已采用 行业最优方法将 6.5.1 到 6.5.10 中列举的漏洞保持为最新。但当有关漏洞管理的行业最优方法（例如 OWASP 指南、前 25 大高危软件错误、CERT安全编码等）出 现更新时，这些要求必须采用当下最新的 最优方法。
    • 6.6 对于面向公众的 web 应用程序，应不断解决新的威胁和漏洞，并通过以下任一 方法确保这些应用程序不会受到已知攻击：利用手动或自动应用程序漏洞安全评估工具或方法审核面向公众的 web应用程序，至少每年一次或在有任何变更后进行 注：该评估与要求 11.2 中执行的漏洞 扫描不同在面向公众的 web 应用程序前安装可 检查和防范网页式攻击的自动化技术 解决方案（例如 web 应用程序防火墙），用以不断检查所有流。
    • 6.7 确保已记录、正在使用且所有相关方 了解用于开发和维护安全系统和应用程序 的安全政策和操作程序。
• 实施强效访问控制措施
  • 要求 7：按业务知情需要限制对持卡人数据的访问
    • 7.1 仅有工作需要的个人才能访问系统组 件和持卡人数据。
    • 7.2 为系统组件建立访问控制系统，以根 据用户的知情需要限制访问，并且将系统 设为“全部拒绝”，特别允许访问时除外。 该访问控制系统必须包含以下内容：
    • 7.3 确保已记录、正在使用且所有相关方 了解用于限制持卡人数据访问的安全政策 和操作程序。
  • 要求 8：识别并验证对系统组件的访问
    • 8.1 规定并实施政策和程序，确保对所有 系统组件中的非消费者用户和管理员执行 以下适当的用户识别管理：
    • 8.2 除了分配唯一ID以外，至少采用以下一种方法来验证所有用户，确保对所有系统组件中的非消费者用户和管理员执行恰当的用户验证管理：  所知，如密码或口令等  所有，如令牌设备或智能卡等  个人特征，如生物特征等
    • 8.3 对来自网络外部人员（包括用户和管 理员）以及所有第三方的远程网络访问（包括基于支持或维护目的的供应商访 问）使用双因素验证。 注：双因素验证要求使用三种验证方法中 的两种（请参阅要求 8.2 验证方法的说 明）进行验证。使用一个因素两次（例 如，使用两个不同的密码）不视为双因素 验证。 双因素技术包括带令牌的远程认证拨号用 户服务 (RADIUS)、带令牌的终端访问控 制器访问控制系统 (TACACS) 以及便于双 因素验证的其他技术。
    • 8.4 记录并向所有用户传达验证程序和政 策，包括：  选择强效验证凭证的指南  关于用户应如何保护其验证凭证的指 南  关于不重用之前用过密码的说明  用户如怀疑密码可能暴露则应修改密 码"
    • 8.5 不要使用群组、共享或常规 ID、密码 或其他验证方法，具体如下：  常规用户 ID 已禁用或删除  用于系统管理和其他重要功能的共享用 户 ID 不存在  不使用共享和常规用户 ID 管理任何系 统组件
    • 8.6 如使用实物或逻辑安全令牌、智能卡 和证书等其他验证机制，则必须按如下方法分配这些机制的使用：  验证机制必须分配到单个帐户，不得 在多个帐户之间共享  必须要有物理和/或逻辑控制，以确 保仅既定帐户可使用该机制获得权限
    • 8.7 禁止对包含持卡人数据的任何数据库的一切访问（包括应用程序、管理员和所有其他用户的访问），具体如下：  用户对数据库的所有访问、查询和操作均通过编程方法完成。  仅数据库管理员能直接访问或查询数据库  数据库应用程序的应用ID仅可由这些应用程序使用（个人用户或其他非应用 程序流程不能使用）
    • 8.8 确保已记录，正在使用且所有相关方了解用于身份识别和验证的安全政策与操作程序。
  • 要求 9：限制对持卡人数据的物理访问
    • 9.1 采用适当的场所入口控制，对持卡人数据环境中系统的物理访问进行限制和监控。
    • 9.2 制定相关程序，轻松识别现场工作人员和访客，包括：  识别新的现场工作人员或访客（例如发放工卡）  修改访问要求  废除或取消现场工作人员和过期访客的身份证件（例如工卡）
    • 9.3 控制现场工作人员对敏感区域的物理访问， 具体如下：  必须根据个人的工作职能获取使用权  一旦离职，立即撤消使用权，所有物理访问机制（例如钥匙、访问卡等）均退回或禁用。
    • 9.4 实施相关程序，识别并批准访客。程序应包括以下方面：
    • 9.5 保护所有媒介的实体安全。
    • 9.6 严格控制任何媒介的内部或外部分发，包 括：
    • 9.7 严格控制对媒介的存储和获取。
    • 9.8 当媒介因业务或法律原因不再需要时应予销 毁，具体如下：
    • 9.9 保护通过直接接触卡本身便可捕获支付卡数 据的设备，以避免设备被篡改和替换。 注：本要求适用于销售点有卡交易（即刷卡）中使用的读卡设备。本要求不适用于手动密钥输入 组件，如计算机键盘和 POS 机键盘。 注：要求 9.9 在 2015 年 6 月有 30 日前属于最 优做法，此后将成为一项要求。"
    • 9.10 确保已记录、正在使用且所有相关方了解用于限制持卡人数据物理访问权的安全政策和操作程序。
• 定期监控并测试网络
  • 要求 10：跟踪并监控对网络资源和持卡人数据的所有访问
    • 10.1 实施检查记录，将对系统组件的所有访问链接到个人用户。
    • 10.2 对所有系统组件实施自动检查记录以重建以下事件：
    • 10.3 对于每次事件，至少记录所有系统组件的以下检查记录条目：
    • 10.4 使用时间同步技术来同步所有关键系统 的时钟和时间，并确保实施以下各项以获 取、分配并存储时间。 注：网络时间协议 (NTP) 便是一种时间同步 技术。
    • 10.5 保护检查记录，禁止进行更改。
    • 10.6 审核所有系统组件的日志和安全事件以 识别异常情况或可疑活动。 注：可使用日志搜集、分析和告警工具来满 足本要求。
    • 10.7 保留检查记录历史至少一年，其中最少3 个月的记录可立即访问以供分析（例如， 在线、存档或可从备份恢复）。
    • 10.8 确保已记录、正在使用且所有相关方了 解用于监控所有网络资源和持卡人数据访问 的安全政策和操作程序。
  • 要求 11：定期测试安全系统和流程
    • 11.1 实施流程以测试是否存在无线接入点 (802.11)，并按季度检测和识别所有授权和非 授权的无线接入点 注：可用于该流程的方法包括但不限于无线网 络扫描、系统组件和基础架构的物理/逻辑检 查、网络访问控制 (NAC) 或无线 IDS/IPS。 无论使用何种方法，都必须足以检测并识别授 权和非授权设备。
    • 11.2 至少每个季度运行一次内部和外部网络漏 洞扫描，并且在网络有任何重大变化（例如安 装新的系统组件，更改网络拓朴，修改防火墙 规则，产品升级）时也运行漏洞扫描。 注：可在季度扫描过程中综合多次扫描报告， 表明所有系统均已扫描，且所有相关漏洞均已 解决。 可能需要其他文档记录来确认未修复的漏洞正 在解决过程当中。 如果评估商确认 1) 最近的扫描结果为通过，2) 实体具备要求每季度扫描一次的书面政策和程 序，3) 扫描结果中指出的漏洞在重新扫描中显 示为已修复，则不要求四次季度扫描均通过才 能认定最初 PCI DSS 的遵从。在最初 PCI DSS 审核后的几年里，必须要出现四次季度扫 描结果均为通过的情况。
    • 11.3 实施一种包含以下内容的穿透测试法： 以行业认可的穿透测试法为基础（例如NIST SP800-115）  包括覆盖整个 CDE 环境和关键系统  来自网络内部和外部的测试  包括用于验证任何网段和范围缩小控制的 测试  定义应用层穿透测试，至少包括要求 6.5中列出的漏洞  定义网络层穿透测试，包括支持网络功能 和操作系统的组件  包括审核并考虑过去 12 个月内遇到的威 胁和漏洞  指定保留穿透测试结果和修复活动结果。 注：要求 11.3 中的此更新在 2015 年 6 月 30 日前属于最优方法，此后将成为一项要求。在 PCI DSS 3.0 版发布前，必须遵守 PCI DSS 2.0 版中的穿透测试要求。
    • 11.4 利用入侵检测和/或入侵防御技术来检测 和/或防御网络入侵。监控持卡人数据环境周围 以及持卡人数据环境中关键点的所有流量，并警示工作人员注意可疑威胁。确保所有入侵检测和防御引擎、基线和签名均 为最新。
    • 11.5 部署变更检测机制（例如文件完整性监控工具），在发现重要的系统文件、配置文件或 内容文件出现非授权修改时警示工作人员；同时配置该软件至少每周执行一次重要文件比对。 注：在变更检测中，重要文件通常指那些不经常变更但一旦变更即表示系统受到威胁或面临威胁风险的文件。变更检测机制（例如文件完整性监控产品）通常预先配置了相关操作系统的重要文件。其他重要文件（例如自定义应用 程序的重要文件）必须由该实体（即商户或服务提供商）评估和定义。
    • 11.6 确保已记录、正在使用且所有相关方了解 用于安全监控与测试的安全政策和操作程序。
  • 要求 12：维护针对所有工作人员的信息安全政策。
    • 12.1 制定、公布、维护和宣传安全政策
    • 12.2 实施符合以下条件的风险评估流程：  至少每年执行一次评估，并在环境发生 重大变更时（例如收购、合并、迁址 等）也执行评估；  确定重要资产、威胁和漏洞；以及  形成正式的风险评估。 （风险评估的方法包括但不限于 OCTAVE、 ISO 27005 和 NIST SP 800-30。）
    • 12.3 制定关键技术的使用政策，并规定这些 技术的正确用法。 注：关键技术包括但不限于远程访问和无线 技术、笔记本电脑、平板电脑、可移动电子 媒介、电子邮件的使用和互联网的使用确保这些使用政策要求：
    • 12.4 确保安全政策和程序明确规定所有工作 人员的信息安全责任。
    • 12.5 将下列信息安全管理职责分配给个人或 团队：
    • 12.6 实施正式的安全意识计划，使所有工作 人员意识到持卡人数据安全的重要性。
    • 12.7 在录用人员前筛选应征者，以最大程度 地降低内部攻击的风险。（背景调查包括以 往的工作经历、犯罪记录、信用记录以及证 明人调查。） 注：对于门店收银员这样的职位，本要求仅 作为建议，因为他们在交易时一次只能访问 一个卡号。
    • 12.8 维护并实施政策和程序，以管理共享持 卡人数据或可影响持卡人数据安全的服务提 供商，具体方式如下：
    • 12.9 针对服务提供商的额外要求：服务提供 商以书面形式向客户确认其负责维护所持有 的持卡人数据，或以其他方式代表客户存 储、处理或传输的持卡人数据的安全，或在 可能影响持卡人数据环境安全性的程度内维 护数据安全。 注：本要求在 2015 年 6 月 30 日前属于最优 方法，此后将成为一项要求。 注：“确认”的确切措辞取决于双方协议、所提 供服务的详情以及分配给每一方的责任。“确 认”不一定要包含与本要求完全相同的措辞。 仅当评估对象为服务提供商时，本要求才适 用。
    • 12.10 实施事故响应计划。随时准备立即响应 系统漏洞。