我有这个想法，但我不确定它是否符合PCI标准。我是PCI合规领域的新手，很想知道这种情况是否违反了PCI。
所以，让我们设置场景。 A公司符合PCI标准，并且在https上有一个Web服务，在支付处理方面暴露了一些功能。 B公司不合规，但他们的网站是安全的。
以下是该方案的步骤。
问题是，由于javascript直接从用户的计算机转移到公司A的兼容服务器，它是否符合PCI标准？我很想知道这个领域的专家是怎么想的。
答案 0 :(得分：13)
Pamphlet on PCI DSS所有PCI Standards
PCI DSS（支付卡行业数据安全标准）具有“范围界定”的概念 - 确定哪些系统属于PCI保护伞。
您是商家还是软件供应商？ 如果PAN（主要帐号）（长信用卡号）从未发送到您的网站，那么您的网站通常不在PCI范围内。 - 假设你是商人。如果您是软件供应商，那么您的软件可能属于PA-DSS的范围（见下文）。
PAN转换您的服务器 旧的想法是PAN将被发送到您的网站（通过浏览器表单提交），然后您的网站将转身并将其发送到支付网关（例如Authorize.Net）。在这种情况下，PAN从未存储在您的服务器上，但是传输您的服务器。这通常意味着您的商家系统不会处于PCI DSS范围内，因为它们从未存储过PAN。但那些日子很快就结束了或者已经消失了。 （这取决于您的收购方/商家帐户供应商对PCI的积极程度。）
控制您的网页由于您的网页未向您的服务器传输任何PAN，因此您不在PCI范围内。但是，您怎么知道有人没有更改您的网页以将PAN传输回您的服务器（或其他地方，使用JSONP技术）？答案是，您需要确保没有人会篡改您的付款表单页面。
你如何向自己保证这取决于你。您可以使用PCI技术或其他技术。这是您的内部计算机安全和审计问题。
付款应用程序数据安全标准（PA-DSS）如果您将sw出售给商家，那么它可能属于PA-DSS标准的范围。请参阅standard。
PCI是政治性的，而不是技术性的请记住PCI范围取决于您。如果您是一个足够大的商家，那么您还需要与QSA（合格安全评估员）合作，他们将审核并确定您的PCI合规性和范围界定计划。
QSA当然可以说，因为你控制你的网页，它需要在PCI之下，因为它可能被某人破坏。但这将是一个有力的论点。毕竟，你可以说任何互联网商家的每个网页都需要在PCI之下，因为任何网页都可能被破坏，要求人们提供PAN，然后做一些不好的事情。另一方面，这正是Visa用于增加企业特许经营者PCI范围的论点。 Article
PCI认证不是借口另请注意，如果您有闯入，卡协会保留将您解雇的权利 - 即使您符合PCI标准。因此，您希望确定自己比目标中的其他任何人都更加强硬。
补充：有关范围的更多信息从上面可以看出，一个关键问题是哪些系统进出PCI Scope。 PCI理事会现在有一个特别兴趣小组（SIG）正在研究PCI范围内和内外的整个问题。而我的猜测是，他们希望信封能够增长，而不是缩小。
已添加：介于您和您的律师之间您的方案已开始在客户的浏览器上完成PAN处理。 PAN永远不会到达您的系统，即使是瞬间。所以我的解释是你没有Merchant PCI DSS范围。但您是签署PCI合规声明的人，这是您与收购方之间的合同。因此，您和您的律师需要解释PCI DSS标准，而不是我。
底线您永远不应该在系统上存储PAN数据。你甚至不应该让它通过你的系统。 Authorize.Net和Braintree的新支付网关协议支持非传输技术。根据您的信用卡交易量，PCI合规性从自我管理的清单到大型项目不等。
有关更多PCI战争故事，请查看StorefrontBacktalk博客及其PCI coverage。
答案 1 :(得分：6)
Larry K的回答很好。这主要是一个政治/层面的事情。
似乎使用iframe从B发布到A是一个公认的解决方案，而使用Ajax - 使用CORS或JSONP - 有点更值得怀疑，但至少对于一些大玩家来说，仍然可以接受。
Information Supplement: PCI DSS E-commerce Guidelines v2接口说这个解决方案（直接后API）没问题但你应该注意安全编码（虽然PCI DSS没有规定任何具体的你需要这样做） - 请参阅 3.4.3.1带有Direct Post的第三方嵌入式API 部分以及相关的 3.4.3.4共享管理电子商务实现的安全注意事项 ，其中包括：
直接后API方法：使用直接后API方法， 商家仍然负责提交给的网页 消费者和商家在付款页面上托管字段 接受数据 - 只有持卡人数据直接从中发布 消费者对服务提供者。由于付款页面是 由商家托管，付款页面只有安全 商家的网站，以及商家系统的妥协可能 导致支付卡数据的妥协。 ... 具体而言，对于所有上述场景，商家应该 监控系统已发生变化并快速响应的任何证据 在未经授权的更改时将系统还原到受信任状态 检测。采用这些共享管理的商家外包 应该注意最小化适用的PCI DSS要求的模型 这些类型系统固有的潜在风险 建筑。为了最大限度地减少这些情况下的攻击机会， 商家应该采取额外的尽职调查以确保网络 应用程序安全开发并经过彻底渗透 测试
例如自2012年以来Stripe payment gateway uses direct-post over JSONP而不是之前使用的iframe方法。
另一方面，WePay还提供直接后API，但建议iframe完全摆脱PCI要求[WP]（声称使用直接API API“ [..]你还是在适用的情况下，必须符合支付卡行业数据安全标准（PCI-DSS）和支付应用程序数据安全标准（PA-DSS）。“（未指定”适用时“的确切含义）。< / p>
[WP] WePay链接：https://www.wepay.com/developer/tutorial/tokenization
答案 2 :(得分：3)
我最近为我们的服务器完成了一些PCI合规工作，所以这就在我面前。简短的回答是否定的。
PCI合规性要求敏感信息通过的路径的每一步都符合PCI要求本身。有些东西可以是安全但不符合规定，正如你所说的关于B公司。因为你已经说公司B不符合PCI标准，但公司B正在通过他们自己的网站收集信用卡信息，然后整个过程，逻辑上是不合规。
PCI合规服务是否实际上连接了这些点以及它们如何将其证明为通过或失败可能是另一回事。
答案 3 :(得分：1)
无论是否“技术上”符合PCI标准（或不符合PCI标准），我都不会相信这种做事方式。
如果表单位于B主机名中的页面上，则B可以完全访问表单字段中的内容。 （B的服务器能够在需要时向用户发送恶意JavaScript。）
最安全的方法（保护信用卡号码）是将表单完全放在付款处理服务的主机名中，而不是放在不受信任的主机名上。
答案 4 :(得分：0)
以下是PCI Website
从根本上说，如果您可能看到卡号或卡的任何识别信息，您将需要遵守pci要求。我不确定它们是否仍然是“尚未”的法律文件，但如果您被发现违规，您可以撤销您处理或成为交易流程一部分的能力。此外，作为商家，您签署了有关您的责任的协议，并选择进入信用卡公司可以罚款的流程。所有人都有权接受信用卡。
为了好玩，这里有一个（pdf）链接到38页'Quick' Guide。