从移动应用程序中的PCI-DSS开始？

Question

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

该应用必须通过SOAP API与支付处理解决方案连接。我们需要接受用户支付卡详细信息的输入，并将其传递给该API。我们无法将其网站嵌入iframe或类似内容;我们必须使用这个特定的API，这意味着我们的应用程序将不可避免地（简要地）拥有和处理用户的支付卡详细信息。

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

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

我们很难掌握有关PCI DSS需要做的事情，我们非常感谢能帮助我们开始的任何指示。我们非常乐意（确实希望）使用顾问帮助我们实现合规 - 但我们甚至不知道我们会与谁交谈。我们在网上很容易找到的所有东西（包括来自PCI本身的材料）似乎与微妙的不同场景有关，或者建议我们使用类似iframe的东西来回避这个问题，这对我们来说不是一个选择。

老实说，我们很惊讶它找到一些明确的指示是多么困难。很多应用都会处理卡片细节！这肯定是一个普遍的问题。

所以，我们的问题：

1. 我们应该从哪里获得与我们的特定情况相关的专家建议？
2. 完全非正式地，并且基于以下理解：我们将在稍后获得适当的合格建议......我们应该期待多少噩梦？我们想知道是否需要担心手机上安装的键盘记录器。那是真的吗，还是我们走得太远了？
3. 我们缺少一个神奇的子弹 - 例如，一个已经知道合规的图书馆吗？

非常感谢你能给我们的任何帮助。

Answer 1

我认为以上答复均无法准确回答问题。我敦促任何需要有关移动应用程序开发和PCI的信息的人阅读以下内容，这些内容摘自Security Standard Councils文档：

”“如果消费者也是持卡人，并且仅将设备用于自己的持卡人数据输入，并且该应用程序只能由持卡人使用其自己的凭据来使用，则该设备将被视为持卡人的设备。支付卡：运行该应用程序的消费者环境不在PCI DSS的范围内，并且面向消费者的应用程序不符合PA-DSS列表的条件。”

和这个：...

“ PCI SSC同意（请参阅PA-DSS和移动应用程序常见问题解答），只有在制定了适当的标准以确保此类应用程序合格后，才考虑将符合类别3的移动支付接受应用程序用于PA-DSS验证。 PCI SSC建议使用PA-DSS要求和本文档提供的指南作为基准来开发适合类别3的移动支付接受应用程序。”

全文可在此文档中找到： https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf

请阅读第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合规性），无论您采取什么课程。

就噩梦而言，我不确定本机应用程序，但对于网络应用程序，如果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 中概述了此类控制。