在移动应用程序中从哪里开始使用 PCI-DSS？

Question

我们正在为拥有自己的支付处理解决方案的客户开发一款移动应用（iOS 和 Android）。该应用面向公众，可供个人消费者在自己的手机上使用。

应用必须通过 SOAP API 与支付处理解决方案交互。我们需要接受用户支付卡详细信息的输入，并通过该 API 传递它们。我们没有将他们的网站嵌入 iframe 或类似的东西的选项；我们必须使用这个特定的 API，这意味着我们的应用将不可避免地（短暂地）拥有和处理用户的支付卡详细信息。

应用所需要做的就是收集详细信息（通过让用户在手机键盘上点击它们），通过 API 发送它们，然后尽快丢弃它们。它不会存储超过完成事务所需的时间的数据，并且除了通过 API 到客户端的服务器之外，它不会将数据发送到任何地方。我们永远不会将数据保存在我们自己的服务器上，我们会小心谨慎，绝不将其写入日志，而且通常我们会将其视为应用程序拥有的短暂时间内的放射性废物。

我们可以有把握地假设（至少目前是这样）客户的系统已经在 PCI DSS 方面做了他们需要做的任何事情。当然，应用程序和支付服务器之间的流量是加密的。

我们正在努力掌握有关 PCI DSS 需要做的事情，如果有任何建议可以帮助我们入门，我们将不胜感激。我们非常乐意（确实想）聘请顾问来帮助我们实现合规性——但我们甚至不知道我们会与谁交谈。我们可以在网上轻松找到的所有内容（包括 PCI 本身的材料）似乎都与微妙的不同场景相关，或者建议我们通过使用 iframe 之类的东西来回避问题，这对我们来说不是一个选项。

老实说，我们对事实证明找到一些明确指示的难度感到惊讶。许多应用程序确实处理卡详细信息！这肯定是一个普遍的问题。

所以，我们的问题：

1. 我们应该去哪里获得与我们的特定场景相关的专家建议？
2. 完全是非正式的，并且理解我们将在稍后获得适当的合格建议……我们应该期望这会是一场多大的噩梦？我们已经到了想知道我们是否需要担心手机上安装的键盘记录器的地步。真的是这样吗，还是我们走得太远了？
3. 我们是否缺少灵丹妙药——例如已知合规的库？

Answer 1

我认为以上回复不能准确回答问题。我会敦促任何需要专门关于移动应用程序开发和 PCI 信息的人阅读以下内容，摘自Security Standard Councils documentation：

如果消费者也是持卡人，并且仅将设备用于他/她自己的持卡人数据输入，并且该应用程序只能由持卡人使用自己的凭据使用，则该设备的处理方式类似于持卡人的付款卡：应用程序运行的消费者环境不在 PCI DSS 范围内，面向消费者的应用程序不符合 PA-DSS 列表的条件。

还有这个：...

PCI SSC 同意（请参阅 PA-DSS 和移动应用程序常见问题解答），在制定适当的标准以确保此类应用程序能够胜任之前，将不会考虑对符合第 3 类条件的移动支付接受应用程序进行 PA-DSS 验证支持商家的 PCI DSS 合规性。 PCI SSC 建议使用 PA-DSS 要求和本文档中提供的指南作为基准开发符合第 3 类的移动支付接受应用程序。

阅读第 2 页的最后一段和第 3 页的第一段。简而言之，目前（2019 年 9 月 17 日）没有验证移动应用程序的 PCI 合规性 - 只有安全标准委员会的建议和指导。

Answer 2

我是 PCI QSA。

与 PCI 的很多事情一样，场景中有几个灰色区域。您可以向 10 个 QSA 提出同一个问题，并且可能会得到 10 个不同的答案，这是一个可悲的现实，因为在此类情况下缺乏明确的指导（并且有很多奇怪的情况）。

因此，在我的专业意见（我说的意见）中，一个移动应用程序，其中 100% 的卡摄取、处理和传输都在移动设备上处理，并且在所述移动设备上使用的卡属于单个用户，风险非常低。如果我没看错，您就是应用程序开发人员。您不是商家，如果您所做的只是为某些商家或服务提供商编写代码，那么这个问题更多地在于他们。

他们可能需要执行应用程序渗透测试和一些流量分析，以确认持卡人数据直接从设备流向收单机构（处理器）。作为软件开发人员，您不会被任何 PCI 所困扰，除非您在 App Store 或类似的方式上销售此应用程序。在这种情况下，上面的答案更准确。您可能需要使用 PA-QSA 对该应用程序进行 PA-DSS 审查。假设它通过了，它将在 PCI SSC 网站上的 PA-DSS 验证应用程序下列出。这不会使处理器符合 PCI 标准，但有助于评估过程。

至于魔弹，什么都没有。但是，如果您使用 Stripe 作为处理器及其移动 SDK 来处理和传输持卡人数据，那么 Stripe 将在您每年在其网站上完成一份简短的调查问卷后承担 PCI 责任。

我意识到这个问题已经很老了，但我认为答案可以帮助下游的人解决这个问题。另外，我与 Stripe 没有任何关系，但我最近遇到了这个问题，很惊讶地看到 Stripe 是如何处理它的。我可能会添加令人惊喜的惊喜。

Answer 3

我感受到了你的痛苦，你会认为像获取信用卡详细信息这样无处不在的事情会有大量简洁明了的信息来帮助你完成整个过程，遗憾的是事实并非如此。

对于您需要查找 QSA 的第一个问题，请查看 PCI council website 以获取这些问题的列表和所有官方信息。我建议您购物一下，质量和价格确实有所不同，您需要熟悉您的场景的人。正如您所说，在使用我提供的视图之前，您应该获得官方指导。

对于第二个问题，首先要说的是 PCI 是基于合同的。这完全是您客户的责任（取决于他们与商业银行或支付处理商达成的协议）。因此，如果您的合同没有说您需要提供符合 PCI 的解决方案，那么您不必...尽管我会小心，如果您已经暗示或符合目的等，这可能是律师的问题。务实地根据情况有几个选择，这里有点棘手，所以我会尽力而为：

• 如果客户无法控制代码或系统，他们只会收到结果，您可能会被视为服务提供商，并且您至少需要服务提供商的 SAQ D。
• 如果您只是将源代码提供给客户并由他们实施，那么他们将全权负责，如果在范围内，他们将不得不进行代码审查、渗透测试等。
• 如果您的客户想要将您的应用插入他们的系统，并且他们不想对其 PCI 详细信息负责，那么您需要符合 PA-DSS。

最终这将取决于您的客户可以采用的 PCI 范围，无论您采用什么课程，他们都可能至少需要 SAQ A（是的，您可能都需要证明 PCI 合规性）。

就噩梦而言，我不确定本机应用程序，但对于 Web 应用程序，如果 PAN（cc 编号）触及您的服务器，则它是完整的范围，SAQ D，简而言之，是的，如果您不这样做，那将是一场噩梦已经有一个安全的设置。最好的情况是 SAQ A，但您需要一个 iFrame，如果这不可能，那么可能是 SAQ A-EP，您可以将它与直接 POST 一起使用，因此如果直接来自您的 SOAP 接口，则可能没问题应用程序。我不确定一个应用程序是否被视为可以使用 SAQ A 和 A-EP 的“电子商务”，如果不是，您可能需要 SAQ C。至少看一下要求 6，它涵盖了软件开发。

对于您的最后一个问题，请查看spreedly.com，它们提供与多个网关的 PCI 兼容连接可能很有用。

祝你好运！很高兴听到您最终决定做什么。

Answer 4

此常见问题解答可能会有所帮助：https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application?q=mobile&l=en_US&fs=Search&

这基本上是说您只负责遵循“安全软件开发生命周期”，并在 Req 6.3、6.4 和 6.5 中概述了此类控制。