“处理信用卡数据”是如何进行的？定义（PCI）？
如果我有一个 Web 应用程序，并且我收到 Web 浏览器通过 HTTPS 的 POST 请求传输的信用卡数据，并立即打开到远程 PCI 兼容卡处理器的套接字 (SSL) 以转发数据并等待响应，我是吗？允许这样做吗？或者这是否通过我的应用程序接收数据并将其转发已经成为“处理信用卡数据”的主题？
如果我创建一个显示在客户端浏览器中的 iframe 以输入抄送数据，并且该 iframe 通过 HTTPS 将数据发布到远程卡处理器（直接！），这是否已经是处理信用卡数据的情况？即使我的应用程序代码“不接触”任何事件处理程序输入的数据？
我对“信用卡数据处理”的定义感兴趣。什么时候开始成为cc数据处理应用程序？有人可以向我指出 PCI-DSS 标准中明确定义何时开始“成为处理应用程序”的部分吗？
谢谢，
If i have a web application and i receive credit card data transmitted via a POST request by a web browser over HTTPS and instantly open a socket (SSL) to a remote PCI compilant card processor to forward the data and wait for a response, am i allowed to do that? or is this receiving the data with my application and forwarding it already subject of "processing credit card data"?
if i create an iframe that is displayed in a client browser to enter cc data and this iframe posts the data via HTTPS to remote card processor (directly!) is this already a case of processing credit card data? even if my application code 'doesnt touch' the entered data with any event handlers?
i'm interested in the definition "credit card data processing". when does it start to be a cc data processing application? can somebody maybe point me to that section in PCI-DSS standard that clearly defines when you start to 'be a processing application'?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
即使您自己没有对数据进行任何操作，您也可以传输数据。因此，您确实符合 PCI 合规规则。
PCI DSS v .2.1，第 5 页，在 PCI DSS 适用性信息下：
例如，PCI DSS 第 4.1 节要求在通过公共/开放网络传输时进行加密，您已在两端使用 SSL 和 HTTPS 覆盖了这些网络。
但不仅仅涉及直接处理卡数据的要求。还有用户身份验证控制，例如 PCI DSS 第 8.x 节，特别是针对有权访问持卡人数据或管理功能的用户。
虽然有些部分可以忽略，因为您不存储卡数据，但还有其他部分涉及网络安全、防火墙、防病毒、访问控制、监控和跟踪、测试等。
You transmit the data, even if you don't do anything with it yourself. Therefore, you do fall under PCI compliance rules.
PCI DSS v .2.1, Page 5, under PCI DSS Applicability Information:
PCI DSS section 4.1, for example, requires encryption when transmitting over public/open networks, which you have covered with SSL and HTTPS at both ends.
But there's not just the requirements concerning direct dealings with card data. There's also user authentication controls, such as in PCI DSS section 8.x, particularly for users with access to cardholder data or administrative capabilities.
While there are sections you can ignore since you don't store the card data, there are other sections that deal with things like network security, firewalls, antivirus, access control, monitoring and tracking, testing, etc.
这是一个很好的问题，我很想听到一些权威的答案——要么来自直接代表 PCI-DSS 的人，要么至少来自有权接触 PCI 成员的 QSA。
我的不权威答案是，托管 iframe 的 Web 服务器将在 PCI 范围内，并且您将被归类为服务提供商。这是基于我对 PCI 标准的解释，其中 词汇表 指出：
*1。您显然不是支付卡品牌（例如 Visa），也不是商家（您向其提供此服务）
*2.这很明显是你的角色，提供服务
*3.不幸的是，我认为您不符合此排除条件，因为您可以访问应用程序层数据。
好消息是，您所采取的方法可能是减轻头痛的最佳方法。
理想情况下，您可以对该服务器进行分段，以便对更广泛（内部）网络的访问受到严格限制。确保网络服务器提供的唯一“应用程序”是此 iframe（即，不要从服务器运行任何其他网页）。确保服务器/iframe/等生成的日志记录不包含任何卡相关数据
不幸的是，我相信这确实意味着在处理网络交易时需要涉及 QSA。
Its a good question, and I'd love to hear some authoritative answers - either from someone directly representing the PCI-DSS or at least a QSA with access to PCI members.
My unauthoritative answer would be that the webserver that hosts the iframe would be in scope for PCI, and you'd be classed as a service provider. This is based on my interpretation of the PCI standard, where the glossary states:
*1. You're clearly not a payment card brand (such as Visa), neither are you a merchant (to whom you're providing this service)
*2. This is pretty clearly your role, as providing a service
*3. Unfortunately, I dont think you meet this exclusion, as you have access to application layer data.
The good news is that the approach you've taken is probably the best you can do to minimise your headaches.
Ideally then you'd segment this server so that access to a wider (internal) network is very restricted. Ensure that the only 'application' the webserver provides is this iframe (ie, dont run any other webpages from the server). Ensure that the logging that the server/iframe/etc generate doesnt contain any card related data
Unfortunately I belive it does mean that a QSA needs to be involved, as you are processing web transactions.
像黑客一样思考 - 如果黑客获得了对您网站/服务器的访问权限，他们是否会以 iframe 进入恶意支付网关的方式对其进行篡改。有些 QSA（PCI 审计员）会坚持认为这在范围内，并且围绕网站的一切（开发、支持、测试、运营）都需要以符合 PCI 的方式进行。
Think like a hacker - if a hacker gained access to your site/server, could they tamper it in such a way that the iframe goes to a malicious payment gateway. There are QSAs (PCI auditors) who will insist this is in scope and everything revolving around the website (development, support, testing, operations) needs to be conducted in a PCI compliant fashion.
很简单 - 如果 CC # 位于服务器上的任何位置，甚至只是内存，那么您正在处理它并遵守这些 PCI 要求。
Simple - if the CC # is ever anywhere on your server, even just memory, then you are processing it and subject to those PCI requirements.