编写PCI兼容组件需要什么?

xr2*_*0xr 5 c# security wpf credit-card pci-compliance

我有一个WPF应用程序,我们已将信用卡处理集成到.我们目前正在将信用信息刷入/输入到WPF Web浏览器的网页中,以满足PCI合规性要求.显然这是可以的,因为Web浏览器组件符合PCI标准,我们的代码从不处理信用卡信息.

我非常讨厌这种设计,并且很乐意编写一个独立的,PCI兼容的WPF控件/程序集,我们可以插入而不是Web浏览器组件.如果我们的应用程序的代码可以使用浏览器而不经过PCI认证,那么它可以使用我们自己的PCI认证组件,而且它本身是PCI认证的吗?它所做的所有新控制/组装都是收集卡信息,并通过WCF服务安全地将其发送到远程安全服务器.它不会存储信用卡或在本地进行任何处理.我被告知这样做需要9个月的审核流程,这就是我们采用浏览器方法的原因.

有人可以让我大致了解这需要做些什么吗?

  • 它可以用C#/ WPF编写吗?
  • 代码是否必须实施特殊的安全措施(如CAS)?
  • 组件是否必须混淆?
  • 一旦写完,那你需要做什么?

Pau*_*ulG 3

尽管与 PCI-DSS 有大量重叠,但您正在寻找的正式名称是 PA-DSS(支付应用程序数据安全标准)。

解决问题的最佳方法之一是将卡输入/卡处理部分分离到一个完全独立的解决方案中。这个单独的解决方案最终将成为通过 PA-DSS 认证的“应用程序”。一旦获得认证,您就可以将其嵌入到您的大型项目中(这不会改变大型项目的 PCI 合规性)

当您研究 PA-DSS 时,将其分离出来的优势将会变得显而易见。标准之一是任何需要重新编译应用程序的更改都需要重新认证应用程序。这不是您想要经常做的事情!

另一个有助于简化流程的策略是考虑“内部”应用程序(不分发给客户)不需要经过 PA-DSS 认证(尽管如果它们明显处理卡数据,则仍然属于 PCI-DSS) 。因此,在您的域中使用网络服务可能会让事情变得更容易。例如,您可以托管“付款条目详细信息”网页,然后在主应用程序中使用标准网络浏览器指向您的付款条目页面。这可能会让您绕过 PA-DSS 认证(尽管您现在托管的网页仍需要 PCI 认证)

无论您做出什么决定,最好的建议是一旦您对预期设计有了合理的了解,就立即让 QSA 参与其中。QSA 将就哪些领域可能导致合规问题提供建议,并最终由 QSA 签署您的合规性