所以,我们来设置场景.公司A是PCI兼容的,并且具有https服务,其中显示了关于支付处理的一些功能. B公司不合规,但其网站安全.
以下是该方案的步骤.
B的网站通过服务器端代码联系A的webservice.此服务发回加密的验证令牌.
> B将此令牌注入包含用于接受信用卡信息的表单的页面.
>用户在B的网站上输入信用卡信息.
>表单信息与令牌一起通过ajax调用发送到A的webservice.
> A的Web服务处理数据并返回状态(已批准/拒绝/ etc)
问题是,由于javascript直接从用户的机器到A公司的兼容服务器,是否符合PCI？我非常有兴趣知道这个舞台上的专家怎么想.
解决方法
PCI DSS(支付卡行业数据安全标准)具有“范围界定”的概念 – 确定哪些系统属于PCI伞.
您是商户还是软件供应商？
如果PAN(主帐号)长信用卡号码从未发送到您的网站,那么您的网站通常不在PCI范围之下. – 假设你是商人.如果您是软件供应商,那么您的软件可能在PA-DSS的范围内(见下文).
PAN转移您的服务器
旧的想法是,PAN将被发送到您的网站(通过浏览器表单提交),然后您的网站将转而发送到支付网关(例如Authorize.Net).在这种情况下,PAN从不存储在您的服务器上,但是已经转移了您的服务器.这意味着您的商家系统不会处于PCI DSS范围之下,因为它们从未存储过PAN.但是那些日子已经很快结束了,或者已经消失了. (这取决于您的收购方/商户帐户供应商对PCI有多凶猛).
控制您的网页由于您的网页没有传输任何PAN到您的服务器,您不在PCI范围.但是你怎么知道有人没有改变你的网页将PAN传输回你的服务器(或其他地方,使用JSONP技术)？答案是,您需要确保自己没有人会篡改您的付款表单页面.
你如何确定这一点取决于你.您可以使用PCI技术或其他技术.这是您内部计算机安全和审计的问题.
付款应用数据安全标准(PA-DSS)如果您将sw销售给商家,那么它可能在PA-DSS标准的范围之内.见standard.
PCI是政治性的,而不是技术性记住,PCI的范围取决于你.如果您是一个足够大的商家,那么您还需要与QSA(合格的安全评估员)合作,他们会审核并确定您的PCI合规性和范围规划.
QSA肯定有可能说,由于您控制您的网页,因为它可能被某人损坏,因此需要在PCI之下.但这将是一个有力的论据.毕竟,你可以说任何互联网商家的每个网页都需要在PCI下,因为任何网页都可能被破坏,要求人们做PAN,然后用它做坏事.另一方面,这正是Visa正在用来增加公司特许经营者的PCI范围的一种观点. Article.
PCI认证不是一个借口还要注意,即使您符合PCI标准,卡协会保留踢您的权利,如果您有一个突破.所以你想确保你是一个比任何其他人更坚定的目标.
添加：关于范围的更多信息从上面可以看出,一个关键问题是哪些系统是在PCI Scope中或之外. PCI理事会现在有一个特别兴趣小组(SIG)来研究这个整个问题,即PCI的范围是甚么.我的猜测是,他们会希望信封增长,而不是收缩.
添加：您和您的律师之间您的方案开始在客户的浏览器上完成PAN处理. PAN永远不会到达您的系统,甚至不会瞬间.所以我的解释是你不在Merchant PCI DSS范围之内.但是,您是签署PCI合规声明的人,这是您与您的收单方之间的合约.所以由你和你的律师来解释PCI DSS标准,而不是我.
底线您不应该将PAN数据存储在系统上.你甚至不应该让它运行你的系统.来自Authorize.Net和Braintree的新的支付网关协议支持无中转技术.根据您信用卡交易量的不同,PCI合规性有所不同,从自我管理的清单到巨大的项目.
对于更多的PCI战争故事,请查看StorefrontBacktalk博客及其PCI coverage.
原文地址：https://www.jb51.cc/ajax/154154.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
