12-16-24
距离 PCI DSS 中新的 eSkimming 安全控制的合规截止日期仅剩不到四个月的时间，客户端安全领域的先驱 Source Defense 主办了一场重要的圆桌讨论，邀请了领先的合格安全评估师 (QSA) 参加。

网络研讨会汇集了顶尖的行业专家，以解决组织必须在 2025 年第一季度之前实施的要求 6.4.3 和 11.6.1。小组成员包括来自 Servadus 的 Ron Tosto、来自 RSM US 的 KJ Sedjro、来自 Protiviti 的 Daniel Baron 和来自 Source Defense 的 Matt McGuirk。

新前沿：客户端安全

Servadus 首席安全顾 手机号码数据 问Ron Tosto强调，这些要求直接源自记录在案的安全事件。 “这项要求并非凭空而来。它实际上是基于您在 PCI 取证调查中看到的真实情况，” Tosto 说道。

各组织最初的反应表明，他们对范围和适用性存在很大困惑。RSM US 支付安全总监KJ Sedjro强调了这一共同挑战： “很多客户一开始并不知道这是否适用于他们。因此，我们首先要让他们明白，即使是用户浏览器，无论那边发生什么，都会直接影响到他们，” Sedjro 说。

需求演变
这些要求的技术复杂性给组织带来了巨大挑战，特别是在跟踪可能出现在支付页面上的整个脚本链方面。虽然以前的要求侧重于直接库存，但新标准要求对动态加载的第三方、第四方甚至第五方脚本具有可视性。

Ron Tosto 强调了这一重大转变：“我记得第一次读到这个要求时，我当时想，我们该怎么做？我们该如何完成？因为即使在 6.4.3 中，它只是说要有库存，但现在它要有供应链的库存，” Tosto 说。

PCI DSS 4.0 版和 4.0.1 版之间发生了重大变化，放宽了对允许脚本的限制。4.0 版严格限制支付页面仅包含直接支持支付功能的脚本，而 4.0.1 版则采用了更灵活的方法。

Protiviti 高级总监Daniel Baron表示： “最初，它表示只支持支持支付功能的脚本。现在，在 4.01 中，它表示这是出于业务或技术原因而合理使用的任何脚本。”此修订使组织能够更灵活地维护必要的业务功能，同时要求对每个脚本的存在提供适当的理由。

了解范围和责任

许多组织在使用支付服 此外年报告显示个人捐赠捐赠份额最大 务提供商时最容易混淆的一个关键问题是他们的安全责任。许多商家认为，通过 iframe 或托管支付页面外包付款收款会将所有安全责任转移给其提供商。然而，Daniel Baron 强调，商家仍需承担重大的安全义务。

“即使在这种支付功能外包的情况下，比如利用 PCI 认证服务提供商的支付 iframe 进行付款收款，引用页面仍然存在一定的风险，” Baron 说。“调用 iframe 的代码、执行重定向的代码理论上可能会被攻击者修改，因此必须维护该代码的安全性。”

战略实施考虑

组织面临的最复杂 007 厘米 挑战之一是证明在支付页面上使用常见的第三方工具和服务的合理性。许多工具（例如分析、营销标签和客户体验解决方案）都具有基本的业务功能，但在设计时并未考虑到支付卡安全。组织现在必须仔细评估这些工具是否特别有必要出现在支付页面上，以及考虑到安全风险，它们的存在是否合理。

Ron Tosto 用 Google Tag Manager（一种广泛用于管理营销和分析标签的工具）这个常见示例说明了这一挑战：“如果你回到 Google 并说，嘿，你能证明 Tag Manager 没有对我的支付页面做任何 [坏事] 吗？他们会说，好吧，我没有为支付页面设计这个，我也不会解释为什么你应该使用它，” Tosto 说。

这个例子凸显了一个更广泛的挑战：许多广泛使用的第三方服务无法或不会提供组织所需的安全证明，以证明其在支付页面上的存在。因此，组织必须仔细权衡这些工具的商业利益与安全风险和合规性要求，并可能重新考虑在收集支付信息的页面上使用这些工具。

合规之路：展望未来

当组织应对这些新要求时，与 PCI 认证服务提供商合作可能会减轻合规义务的负担。Daniel Baron 解释了认证服务提供商如何帮助减轻合规负担。

Baron 说：“如果提供部分脚本或支付页面的服务提供商是拥有有效 AOC 的 PCI 验证服务提供商，那么组织就可以依赖该 AOC 来确保该服务提供商所提供的组件的完整性。”