PCI依从困境

Question

我正在寻找有关PCI依从性的建议。我被告知，我目前不符合PCI虽然我不确定这是否是准确的。

我们将支付管理和卡存储外包给第三方服务，只存储卡的外部ID和最后4位数字。

我在前端收集CC数据，并将其传递给Node应用程序，后者将其发送给我们的第三方服务。这是必需的，因为由于明显的安全原因，API密钥/机密不应该公开给客户端。

然而，有人告诉我，将数据从一个应用程序传递到另一个应用程序是不符合规定的，现在我被要求直接从浏览器发送CCs，这意味着每个使用应用程序的人都会将API密钥/秘密发送到他们的本地机器，如果知道有人可以轻松地使用它来访问我们的支付工具。

我做什么好？仅仅将数据从一种服务传输到另一种服务实际上是违背遵从性的吗？

Answer 1

你说得对，这是个进退两难的局面。我试着逐点回答。

我在前端收集CC数据，并将其传递给Node应用程序，后者将其发送给我们的第三方服务。..。然而，有人告诉我，将数据从一个应用程序传递到另一个应用程序是违反法规的，

与其说是传递数据是不恭维的(毕竟，您需要将它传递给第三方)，不如说是通过服务器传递它--这就是问题所在。我喜欢描述PCI级别，因为为了窃取卡数据，需要对哪些方面进行妥协。如果答案是“我的SAQ服务器”或“我的应用程序”，那么它们就是SAQ，最繁重的任务。如果答案是“我与信任的第三方的沟通渠道”，那么你可能是A或are，就像大多数电子商务一样。

这是必需的，因为由于明显的安全原因，API密钥/机密不应该公开给客户端。..。在浏览器中，这意味着每个使用该应用程序的人都会将API密钥/秘密发送到他们的本地机器，如果知道的话，有人可以很容易地使用它来访问我们的支付工具。

这并不像你想象的那么明显。有人能拿这些证件做什么呢？如果他们能用来给你钱，他们并不是那么敏感。如果他们能被用来退款，他们是非常敏感的。如果可以使用它们来检索不是PAN的信息，这是很重要的，但也没有那么糟糕。

这是API凭据几乎肯定不是您登录到他们的门户的一个重要原因。对于不付款操作，您也可能有不同的设置。

最后，你应该和你的支付提供者谈谈。你不是第一个遇到这些问题的人，他们可能已经掌握了如何处理这些问题的指导。(如果你是第一个.快跑！)

我见过的许多支付系统都要求服务器使用秘密凭据进行某种设置调用，然后返回一个一次性使用值(url、事务密钥等)，以便交付给客户端。其他人只需限制您可以使用这些creds做什么，这样它们才能安全地暴露给用户。

您也可能使用了错误的API/端点。你可能会使用一种用于面对面支付的方式，而电子商务则是另一种方式。我也看到了(我自己也犯了那个错误)。