假设我决定使用支付网关而不是使用他们的托管页面,而是提供我自己的信用卡详细信息表单,然后通过 xml 将数据发送到他们的后端,如本页所述。然后:
- 我需要担心 PCI 合规性吗?如果是这样,我、我的托管公司或支付网关人员应该整理出哪些步骤(PCI 网站)
- 有人告诉我,只要我的表单在 SSL 上,我的网站就会自动合规。是对的吗?
谢谢你的帮助
1) 如果您在任何时候处理信用卡信息,您都需要符合 PCI 标准。您需要解决编码问题,您的主机需要处理服务器的任何硬件和软件问题,支付网关公司有很多问题需要处理(这里列出的列表太长但您没有无论如何都需要担心)。
2) 不会。SSL 将帮助您符合 PCI 标准,但 PCI 合规性比数据如何从用户传输到服务器更重要。您如何处理这些数据以及如何处理这些数据也会发挥作用。例如,如果您要存储信用卡信息,则需要使用加密,而不是存储 PCI 禁止存储的值(即 CVV 编号)。将此信息放入会话中算作存储。
对问题 1 的回答:是的,您应该更加担心 PCI 合规性。
对问题 2 的回答:使用 SSL 表单收集信用卡信息负责将数据从客户端安全传输到您的服务器。因此,如果您不打算将信用卡数据存储在您的服务器上,这就足够了。如果您想存储信用卡数据,那么您需要遵守 PCI DSS 来存储信用卡数据。
其他评论中没有出现的一个方面是 PCI-DSS 是根据已实施的运营系统进行评估的,并且该系统中最重要的组件是人工流程和控制。“我的站点将自动合规”背后的前提包括一个假设,即可以根据 PCI-DSS 评估一项技术,脱离上下文。
根据 PCI-DSS 和 PA-DSS 的定义,任何自定义应用程序都不能凭借其自身的优点被宣布为符合 PCI 标准。不可定制的交钥匙解决方案的应用程序和硬件可以根据 PA-DSS 进行评估,但即使在已实施系统以及与之相关的人工控制和流程的背景下,它们也不能被认证为符合 PCI 标准。
要求 2、10、11 和 12 完全与您的应用程序外部的系统控制有关,并代表人工程序和任务。在其他要求中,仔细观察每个要求都会发现它们直接或间接地对人工流程和控制施加了限制。
因此,请务必阅读并吸收有关 PCI 技术要求的其他建议,但放弃您完成的应用程序可以在工作、已实施系统的上下文之外被声明为符合 PCI 的想法。更好的方法是考虑那些与应用程序设计的技术细节没有直接关系的要求,并问问自己应用程序如何帮助客户满足这些要求。例如,您的应用程序是否可以让客户轻松“跟踪和监控对网络资源和持卡人数据的所有访问”?(要求 10)
许多应用程序供应商的立场是,要求 12,“维护解决所有人员信息安全问题的策略”,根本不适用于他们。但客户经常会回来问一些尖锐的问题,即应用程序在这个评估项目上是帮助还是伤害了他们。客户负责培训他们的员工如何预防、检测和从漏洞中恢复,以及应用程序与安全扫描器互操作的能力、配置和数据的备份或恢复到之前的时间点都是至关重要的。PCI 要求供应商发布的安全相关补丁在 90 天内或更短的时间内应用,因此客户会想知道您如何以及在何处通知他们这些事情,应用补丁的难易程度或破坏性,应用程序是否必须降级应用它们,等等。
希望合理详细的评估能够剔除所有存在明显技术错误的应用程序,例如未能使用 TLS 加密、通过 HTTP 呈现登录页面或恢复密码而不是发送重置链接。任何仅符合PCI 指南技术方面的愿望只会让新应用程序上升到商品的水平。为了在市场上区分应用程序,将其设计为帮助客户满足非应用程序直接责任的PCI 要求。
我帮助创建了Drupal PCI 合规性白皮书,它为您在尝试使您的站点合规时可能遇到的这些问题和许多其他问题提供了答案。虽然您可能没有使用 Drupal,但本文档中涵盖的原则是高级别的,并且很容易应用于 wordpress、Joomla 或任何其他电子商务 CMS。