编写符合 PCI 标准的程序集需要什么？
我有一个 WPF 应用程序，我们已将信用卡处理集成到其中。目前，我们正在将信用信息刷入/输入到 WPF Web 浏览器的网页中，以满足 PCI 合规性。显然这是可以的，因为 Web 浏览器组件符合 PCI 标准，并且我们的代码从不处理信用卡信息。
我非常讨厌这种设计，并且希望编写一个独立的、符合 PCI 标准的 WPF 控件/程序集，我们可以插入它来代替 Web 浏览器组件。如果我们的应用程序代码可以使用浏览器而无需本身经过 PCI 认证，那么它可以使用我们自己的 PCI 认证程序集而无需本身经过 PCI 认证，对吗？它要做的所有新控制/组件都是收集卡信息，并通过 WCF 服务将其安全地发送到远程安全服务器。它不会在本地存储信用卡或对其进行任何处理。我被告知这样做需要大约 9 个月的审核过程，这就是我们采用浏览器方法的原因。
有人能给我一个大概的想法吗？
- 可以用C#/WPF写吗？
- 代码是否必须实施特殊的安全措施 （如 CAS）？
- 程序集是否必须被混淆？
- 一旦写好了，那么你需要做什么？
I have a WPF application that we have integrated credit card processing into. We're currently having the credit info swiped/typed into a webpage in a WPF web browser to satisfy PCI compliance. Apparently this is ok because the web browser component is PCI compliant and our code never deals with the credit card info.
I pretty much hate this design and would love to write a stand-alone, PCI-Compliant WPF control/assembly that we can plug in instead of the web browser component. If our app's code can use the browser without itself being PCI certified, then it could use our own PCI certified assembly w/out itself being PCI certified right? All the new control/assembly it would do is collect the card info, and securely send it to a remote secure server via a WCF service. It wouldn't be storing the credit card or doing any processing with it locally. I've been told doing this requires like a 9 month review process which was why we went with the browser approach.
Can someone give me a general idea of what it would take to do this?
- Can it be written in C#/WPF?
- Does the code have to have special security measures implemented
(like CAS)? - Does the assembly have to be obfuscated?
- And once it's written, then what do you have to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
尽管与 PCI-DSS 有大量重叠，但您正在寻找的正式名称是 PA-DSS（支付应用程序数据安全标准）。
解决问题的最佳方法之一是将卡输入/卡处理部分分离到一个完全独立的解决方案中。这个单独的解决方案最终将成为通过 PA-DSS 认证的“应用程序”。一旦获得认证，您就可以将其嵌入到您的大型项目中（这不会改变大型项目的 PCI 合规性）。
当您研究 PA-DSS 时，将其分离出来的优势将变得显而易见。标准之一是任何需要重新编译应用程序的更改都需要重新认证应用程序。这不是您想要经常做的事情！
另一个有助于简化流程的策略是考虑“内部”应用程序（不分发给客户）不需要经过 PA-DSS 认证（尽管如果它们明显处理卡数据，则仍然属于 PCI-DSS） 。因此，在您的域中使用 Web 服务可能会让事情变得更容易。例如，您可以托管“付款条目详细信息”网页，然后在主应用程序中使用标准网络浏览器指向您的付款条目页面。这可能会让您绕过 PA-DSS 认证（尽管您现在托管的网页仍然需要 PCI 认证）
无论您决定如何，最好的建议是一旦您对预期设计有了合理的了解，就立即让 QSA 介入。 QSA 将就哪些领域可能导致合规问题提供建议，并最终由 QSA 签署您的合规性
Although there is a large amount of overlap with PCI-DSS, the formal name you're looking for is PA-DSS (Payment Application Data Security Standards).
One strategy on the best way to tackle your issue would be to separate out the card entry/card processing parts to an entirely separate solution. This separate solution would then ultimately be the 'app' that goes through PA-DSS certification. Once certified you would embed it into your larger project (which wouldn't alter the PCI compliance of the larger project)
The advantage of separating it out will become clear as you look into PA-DSS. One of the criteria is that any change that requires the app to be recompiled would then need the app to be recertified. That's not something you want to do on a frequent basis!
Another strategy to help make the process easier is to consider that 'in-house' applications (which are not distributed to clients) do not need to be PA-DSS certified (though still fall under PCI-DSS if they handle card data obviously). Therefore using a webservice within your domain would potentially make things easier. You could for example host a 'payment entry details' webpage, then use a standard webbrowser in your main app pointing to your payment entry page. This would potentially allow you to bypass PA-DSS certification (though still require PCI certification for the webpage you now host)
Whatever you decide, best advice would be to get a QSA involved as soon as you have a reasonable grasp on your intended design. The QSA will offer advice on what areas may cause compliance issues, and ultimately its the QSA that will sign off your compliance