为符合PCI标准的系统处理未加密的HTTP数据-适用于PCI v3，而不是v2？

Question

我们目前有一个自定义的、基于云的应用程序，它可以分析HTTP和HTTPS通过域的流量。因此，如果客户端想使用我们的服务，他们会将DNS重新指向我们应用程序的IP地址，我们的应用程序将分析流量，然后根据情况进行路由。

为了满足客户端的PCI要求，我们不对HTTPS流量进行解密或分析，只对HTTP进行解密和分析。HTTPS流量被简单地路由到目标系统。这意味着我们不必自己遵守PCI以保持客户的遵从性。

然而，为了维持我们客户在2014年底开始使用的PCI v3的遵从性，我们被告知这是不可接受的。HTTP数据正在通过我们的系统，这将使客户端系统不兼容，因为我们系统中的缺陷可能允许MITM将支付详细信息的重定向更改到另一个站点，而不是对卡持有者详细信息进行加密的HTTPS通道(类似于单条)。我们的另一种解决方案，即要求我们的客户端将HTTPS内容托管在一个直接指向客户系统的单独域上，也不太可能为PCI v3所接受，因为未加密的HTTPS数据将受到相同的攻击(即它们可能被指向其他地方)。

对于这个问题，PCI v3中哪些特定的更改可能会影响客户的PCI遵从性？

Answer 1

两种答案的一部分：

免责声明:我不是QSA。我在这里的看法比我喜欢的要远，所以要以谷物的形式应用盐。

新答案以下问题编辑：

DSS 3中有两个变化与你似乎在调情的东西有关。

1. 增加新的SAQ A-EP类别。
2. 后巷斗争一直是与javascript，它一直威胁要爆发某种形式的官方指导。

这两项都与信用卡交易流程的来源有关。如果我去网站X，并点击“结帐”从他们的购物车，我去某处输入我的信用卡详细信息。在哪儿？我怎么知道这是我注定要去的地方？我怎么知道我的车不是先经过保加利亚？

你的生意似乎是个交通中间商。瞧，你正是PCI正朝着避免，或至少是安全的方向发展。您希望您的客户端以您的方式无缝发送流量，并且您将提供值X。但是PCI不希望流量无缝地被重定向，除非有足够的安全性--例如，为了确保没有人可以编辑该进程来使用不同的(恶意)签出页面。

你根据分析确定交通路线。太棒了！这意味着攻击者可以利用您重新路由通信量。在PCI术语中，这意味着您要么在范围内，要么不允许。而作为一个服务提供商，在过去一直保持在范围之外，这意味着一些事情很可能会改变。

现在，种源问题还没有得到明确的阐述。我不能指向DSS 3第13.7节，它说你正在做的事情是被解决的。但我可以告诉你，QSA将开始问这样的问题：“这家公司做了什么?他们把您所有的HTTP流量，包括送人到购物车和结账的流量？”然后，他们会希望看到您的服务提供商认证，因为根据服务提供者的定义：

这还包括提供控制或可能影响持卡人数据安全的服务的公司。

所以，是的，随着向DSS 3的转变，你可能会遇到一些问题。我仍然不相信我理解你的业务，所以我不能肯定地说什么，但你是中等流量，你在名单上，如果你不是一个认证的服务提供商，可能会失去客户。(前遗学不是，阿卡迈是。谁能说呢？)

原始答案如下：

最近，我对PCI DSS v2和v3进行了逐行比较，并且我不记得DSS本身中有任何东西会影响跨提供者的HTTPS流量的遍历。第4节涉及“跨开放的公共网络的持卡人数据的加密”，这是显而易见的地方，而且几乎没有改变。

话虽如此，但有两个注意事项：

1)决策支持系统并非唯一值得关注的问题。如果这些准则适用于有关企业，则其措辞以及阐述质量保证含义的其他各种指导文件也很重要。

2)我不完全清楚您的服务是否只是加密通信量的管道。您声明您的客户端“将他们的DNS重新指向我们应用程序的IP地址，我们的应用程序将分析流量，然后根据需要进行路由。”“分析流量”这个短语将吸引任何QSA来进行更深入的研究。在HTTPS的情况下，您不应该有太多的分析需要处理；您必须允许SSL协商通过真正的后端来在通道对您安全之前确定HTTPS，如果这是您所做的全部工作，那么您的服务就没有什么作用。总之，我觉得我们对你的服务没有足够的细节来给你提供可靠的建议。