在搜索SE、PCI基础、drupal.org、AWS资源和阅读Drupal PCI合规白皮书之后,我很难找到一个让我对这个问题感到非常舒服的非常直截了当的答案。
我想我只是想从以前设置过eCommerce环境的人那里得到一些确认或否认。也许这是因为我考虑过了(我真的不想让一家小企业承担不必要的责任),也许是因为环境不同,所以很难说。
我想确保使用Drupal和现场支付网关(Authorize.net)创建一个与PCI兼容的环境。在我们的谅解备忘录中,将由网站所有者最终写下他们的业务流程,并接受SAQ (推荐的,因为他们应该符合Visa/Mastercard的4级标准)来表示他们符合PCI标准,但是由于我正在构建站点,我想确保他们不会有任何问题。
只要我们..。
这是PCI兼容环境的配方吗?我忘了什么东西了吗?
我的第二个但相关的问题是-使用Drupal和Authorize.net (现场处理)是否意味着业务应该使用:
或
我知道Drupal Commerce通过设计提供“没有持卡人的数据存储”,但我非常不清楚‘所有支付处理功能完全外包’和‘商家重新定向到第三方兼容的服务提供商进行处理’之间的区别。
谢谢你的想法!
发布于 2016-10-03 21:15:44
免责声明:记住,我既不是律师,也不是PCI QSA。
在做了更多的研究之后,我确信在authorize.net AIM中使用Drupal (这是商业启动配置文件附带的授权模块使用的方法)几乎在所有情况下都应该直接进入SAQ-D (不要通过go,不要收取200美元)。
这意味着您需要上述所有的东西,以及更多的管理和政策在您的终端(或客户端)。对于一家小公司来说,如果没有一个定制项目的巨额预算,这是不可行的。
为了减少使用Authorize.net的CDE的范围,需要集成SIM (离地表单生成)来使用SAQ-A,或者使用DPM (直接post)来使用SAQ-EP。这假设你可以说是的全部资格,即只接受在线付款,没有POS等。后者提供更多的定制,但更多的工作。
这个模块看起来将允许您在Drupal中这样做,但我没有做过测试或验证。
看起来,较小的预算客户应该简要介绍PCI (总是),并计划使用诸如Authorize.net SIM或Paypal之类的非现场方法,其中表单是由CC处理组织的服务器生成的,并且从不触及您的环境。这样,您的环境应该超出范围,并进行适当的配置。
下面是一个来自authorize.net开发论坛的线程(尽管很旧),它具有一些我认为非常有用的通用的、可伸缩的配置洞察力。
下面是另一个(1岁)白皮书),它为AWS上的PCI遵从性提供了一个框架。其中有些部分不适用于仅适用于Drupal服务器,但仍然是有趣和良好的。
还有更多的想法还是欢迎的。
https://drupal.stackexchange.com/questions/216374
复制相似问题