版权声明：本文为博主原创文章，未经博主允许不得转载，否则将追究法律责任。 https://blog.csdn.net/qq_29277155/article/details/80148538
0x00 前言
本支付卡行业数据安全标准 (PCI DSS) 旨在促进并增强持卡人的数据安全，便于统一的数据安全措施在全球范围内的广泛应用。PCI DSS 为意在保护持卡人数据的技术和操作要求提供了一个基准。PCI DSS 适用于所有涉及支付卡处理的实体，包括商户、处理机构、收单机构、发卡机构、服务 提供商以及所有其他存储、处理或传输持卡人数据 (CHD) 和/或敏感验证数据 (SAD) 的实体。以下是对 12 条 PCI DSS 要求的主要概述。
0x01 附录 A：针对共享托管服务提供商的 PCI DSS 附加要求
| 要求 | 测试程序 | ||||||||||||||||||
| A.1 根据 A.1.1 至 A.1.4，保护每个实体（即商户、服务提供商 或其他实体）的托管环境和数据： 托管服务提供商必须满足这些求以及PCI DSS 中所有其他相 关章节的要求。 注：即使托管服务提供商满足这些要求，也不能保证雇用该托管 服务提供商的实体的遵从性。如果适用，每个实体均必须遵守PCI DSS并验证其遵从性。 |
A.1 尤其在对共享托管服务提供商进行 PCI DSS 评估时，若要确认共享托管 服务提供商确实会保护实体（商户和服务提供商）的托管环境和数据，请从 托管商户和服务提供商的代表性样本中选择部分服务器（Microsoft Windows 和 Unix/Linux）并执行以下 A.1.1 到 A.1.4 的操作： | ||||||||||||||||||
| A.1.1 确保每个实体仅运行可访问自身持卡人数据环境的流程。 | A.1.1 如果共享托管服务提供商允许实体（例如，商户或服务提供商）运行 自己的应用程序，请确认使用该实体的唯一 ID 来运行这些应用程序流程。 例如： · 系统中的任何实体均不得使用共享的网络服务器用户 ID。 · 实体使用的所有 CGI 脚本必须作为该实体的唯一用户 ID 创建和运 行。 |
||||||||||||||||||
| A.1.2 每个实体的访问权限和 特权仅限自身的持卡人数据环境。 | A.1.2.a 确认任何应用程序流程的用户 ID 均不属于特权用户（root 权限/管 理员权限）。 | ||||||||||||||||||
| A.1.2.b 确认每个实体（商户、服务提供商）拥有的读取、写入或执行权限 仅适用于其所属的文件或目录或者必要的系统文件（通过文件系统权限、 访问控制列表、chroot 作业系统、jailshell 等加以限制）。 注意：实体的文件不能与群组共享。 | |||||||||||||||||||
| A.1.2.c 确认实体用户没有共享系统二进制文件的写入权限。 | |||||||||||||||||||
| A.1.2.d 确认只有拥有日志条目的实体才能查看这些条目。 | |||||||||||||||||||
| A.1.2.e 为确保各实体不会独占服务器资源从而利用漏洞（例如，错误、争 用和重启会导致缓冲区溢出等情况），请确认已针对这些系统资源的使用 制定相关限制： § 磁盘空间 § 带宽 § 内存 § CPU |
|||||||||||||||||||
| A.1.3 确保日志记录和检查记录已启用、对于每个实体的持卡人数据唯一且符合PCI DSS要求 10。 | A.1.3 确认共享托管服务提供商已按如下方式启用每个商户和服务提供商环 境中的日志记录： 启用第三方常见应用程序的日志。 默认情况下，日志处于活动状态。 日志可供其所属实体审核。 日志位置已清楚传达给其所属实体。 |
||||||||||||||||||
| A.1.4 启用相关流程，确保在任何托管商户或服务提供商受到威胁时提供及时的取证调 查。 | A.1.4 确认共享托管服务提供商具备相关书面政策，可在出现威胁时针对相 关服务器提供及时的取证调查。 | ||||||||||||||||||
0x02 附录 B： 补偿性控制
当实体因合理的技术限制或书面业务限制无法满足明确指定的要求，但已通过实施其他措施或补偿性控制充分降低与该要求相关的风险时，大部分 PCI DSS 要求可能都需要考虑引入补偿性控制。 补偿性控制必须满足以下标准
1. 符合最初 PCI DSS 要求的目的和严格程度。
2. 提供与最初 PCI DSS 要求相似的防御级别，使补偿性控制能充分抵消最初 PCI DSS 要求旨在防御的 风险。（请参阅 PCI DSS 导航，了解每条 PCI DSS 要求的目的。）
3. “超越”其他 PCI DSS 要求。
（仅仅只是遵循其他 PCI DSS 要求并不构成补偿性控制。评估补偿性控制的“超越”部分时，请考虑以下各项：
"注：以下从 a) 到 c) 的各项为示例，仅供参考。所有补偿性控制都必须由执行 PCI DSS 审核的评估商审核
并验证其充分性。补偿性控制的有效性取决于实施控制的具体环境、相关的安全控制以及控制配置。公司 应了解特定的补偿性控制并非在所有环境下均有效。"
a) 如果受审核的项目需要用到现有的 PCI DSS 要求，则不能将该要求视为补偿性控制。例如，非控台管理访问的密码在发送时必须进行加密，从而降低明文管理密码遭到拦截的风险。实体不得使 用其他 PCI DSS 密码要求（入侵者锁定、复杂密码等） 来补偿缺失的加密密码，因为此类密码要 求不会降低明文口令遭到拦截的风险。而且，其他密码控制已经是受审核项目（密码）的 PCI DSS 要求。
b) 如果其他领域需要而受审核项目不需要用到现有的 PCI DSS 要求，则可将该要求视为补偿性控制。 例如，双因素验证是针对远程访问的 PCI DSS 要求。当不支持加密密码传输时，来自内部网络的 双因素验证也可视为非控制台管理访问的补偿性控制。符合以下条件时，双因素验证是可接受的补 偿性控制：
(1) 通过解决明文管理密码遭到拦截的风险，满足最初要求的目的；(2) 在安全的环境中 正确设置。
c) 现有的 PCI DSS 要求可结合新的控制措施成为补偿性控制。例如，如果某公司无法根据要求 3.4 使持卡人数据不可读（例如，通过加密），则补偿性控制可包括一个或多个设备、应用程序以及能 处理以下各项的控制措施：
(1) 内部网络分段；(2) IP 地址或 MAC 地址过滤；以及 (3) 来自内部网 络的双因素验证。
4. 与不遵守 PCI DSS 要求导致的其他风险相称
评估商必须根据上述 1-4 项在每次年度 PCI DSS 评估中全面评估补偿性控制，以验证每项补偿性控制都能 充分解决最初 PCI DSS 要求旨在解决的风险。为保持遵从性，必须在评估完成后制定相应的流程和控制措 施，以确保补偿性控制始终有效。
0x03 附录 C： 补偿性控制工作表
如果要采用补偿性控制来满足 PCI DSS 要求，请使用本工作表界定针对任何要求的补偿性控制。注意：补偿性控制也应记录在 PCI DSS 要求相应章节的《遵从性报告》中。
注：只有已采取风险分析并具有合理的技术限制或书面业务限制的公司才能考虑使用补偿性控制来实现遵从性。
| 要求编号和定义： | 所需信息 | ||||||||||||||||
| 1. 限制 | 列出导致无法遵守最初要求的限制。 | ||||||||||||||||
| 2. 目的 | 定义最初控制的目的；确定通过补偿性 控制实现的目的。 | ||||||||||||||||
| 3. 已确定的风险 | 确定由于缺少最初控制而导致的任何其 他风险。 | ||||||||||||||||
| 4. 补偿性控制的定义 | 定义补偿性控制并解释其如何实现最初 控制的目的并解决增加的风险（若 有）。 | ||||||||||||||||
| 5. 补偿性控制的验证 | 定义如何验证并测试补偿性控制。 | ||||||||||||||||
| 6. 维护 | 规定流程和控制措施以维护补偿性控 制。 | ||||||||||||||||
0x04 附录 D： 网络分段与企业设施/系统组件抽样
0x05 参考资料
https://github.com/ym2011/SecurityManagement/tree/master/PCI DSS
欢迎大家分享更好的思路，热切期待^^_^^ !
扫描二维码关注公众号，回复：
4364819 查看本文章
