我有一个 WPF 应用程序，我们已将信用卡处理集成到其中。我们目前正在 WPF 网络浏览器中将信用信息刷入/输入到网页中以满足 PCI 合规性。显然这是可以的，因为 Web 浏览器组件是 PCI 兼容的，并且我们的代码从不处理信用卡信息。
我非常讨厌这种设计，并且很想编写一个独立的、符合 PCI 标准的 WPF 控件/程序集，我们可以将其插入而不是 Web 浏览器组件。如果我们的应用代码可以使用浏览器而无需本身经过 PCI 认证，那么它可以使用我们自己的经过 PCI 认证的程序集而无需本身经过 PCI 认证，对吧？它要做的所有新控件/组件都是收集卡信息，并通过 WCF 服务将其安全地发送到远程安全服务器。它不会在本地存储信用卡或对其进行任何处理。有人告诉我这样做需要大约 9 个月的审查过程，这就是我们采用浏览器方法的原因。
有人能给我一个大概的想法吗？
- 可以用C#/WPF写吗？
- 代码是否必须实现特殊的安全措施 (比如 CAS)？
- 是否必须混淆程序集？
- 写好后，您需要做什么？
最佳答案
虽然与 PCI-DSS 有大量重叠，但您要查找的正式名称是 PA-DSS(支付应用程序数据安全标准)。
解决问题的最佳方法之一是将卡输入/卡处理部分分离到一个完全独立的解决方案中。这个单独的解决方案最终将成为通过 PA-DSS 认证的“应用程序”。一旦获得认证，您就可以将其嵌入到您的大型项目中(这不会改变大型项目的 PCI 合规性)
当您研究 PA-DSS 时，将其分离出来的优势就会变得清晰。其中一项标准是，任何需要重新编译应用程序的更改都需要重新认证应用程序。这不是您想要经常做的事情!
另一种有助于简化流程的策略是考虑“内部”应用程序(未分发给客户)不需要通过 PA-DSS 认证(但如果它们处理卡，则仍属于 PCI-DSS数据很明显)。因此，在您的域中使用网络服务可能会使事情变得更容易。例如，您可以托管一个“付款条目详细信息”网页，然后在您的主应用程序中使用标准网络浏览器指向您的付款条目页面。这可能会让您绕过 PA-DSS 认证(尽管您现在托管的网页仍然需要 PCI 认证)
无论您做出什么决定，最好的建议是在合理掌握您的预期设计后尽快让 QSA 参与进来。 QSA 将就哪些领域可能导致合规性问题提供建议，并最终由 QSA 签署您的合规性
关于c# - 编写 PCI 兼容程序集需要什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9168623/