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

Question

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

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

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

我们可以安全地假设(至少现在)客户端的系统已经做了他们需要做的关于PCI DSS的任何事情.当然,应用程序和支付服务器之间的流量是加密的.

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

说实话,我们很惊讶它找到一些明确的指针是多么困难.很多应用都会处理卡片细节!这肯定是一个常见的问题.

所以,我们的问题:

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

非常感谢您给我们的任何帮助.

Answer 1

我是 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 2

我认为以上回复没有准确回答问题。我敦促任何需要有关移动应用程序开发和 PCI 的具体信息的人阅读以下摘自安全标准委员会文档的内容：

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

和这个：...

PCI SSC 同意（参见 PA-DSS 和移动应用常见问题解答），在制定适当的标准以确保此类应用能够支持商家的 PCI DSS 合规性。PCI SSC 建议使用 PA-DSS 要求和本文档中提供的指南作为基准来开发适合第 3 类的移动支付接受应用程序。

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

Answer 3

我理解你的痛苦，你会认为像获取信用卡详细信息这样无处不在的东西会有大量清晰简洁的信息来帮助你指导你完成整个过程，遗憾的是事实并非如此。

对于您的第一个问题，您需要找到 QSA，请访问PCI 委员会网站以获取这些 QSA 的列表以及所有官方信息。我建议您货比三家，质量和价格确实有所不同，您需要熟悉您情况的人。正如您所说，在使用我提供的观点之前您应该获得官方指导。

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

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

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

就噩梦而言，我不确定对于本机应用程序，但对于网络应用程序，如果 PAN（抄送号码）接触到您的服务器，它就是完整范围，SAQ D，简而言之，是的，如果您还没有安全设置。最好的方案是 SAQ A，但您需要一个 iFrame，如果不可能，那么也许 SAQ A-EP，您可以将其与直接 POST 一起使用，因此如果直接来自您的 SOAP 接口，则可能可以使用 SOAP 接口应用程序。我不确定一个应用程序是否被认为是可以使用 SAQ A 和 A-EP 的“电子商务”，如果不是，您可能需要 SAQ C。至少看看要求 6，它涵盖了软件开发。

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

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