如何使我的网站符合 PCI 标准

发布于 2024-09-08 18:02:08 字数 442 浏览 11 评论 0原文

假设我决定使用支付网关而不是使用他们的托管页面,而是提供我自己的信用卡详细信息表单,然后通过 xml 将数据发送到他们的后端,如 在此页面上进行了说明。那么:

  1. 我需要担心 PCI 合规性吗?如果是这样,我(我的托管公司)应该采取哪些步骤(PCI 网站)或支付网关人员
  2. 告诉我,只要我的表单采用 SSL,我的网站就会自动合规。是这样吗?

感谢您的帮助

Assuming I decide to use payment gateway and not to use their hosted page, but rather provide my own credit card details form, and then send data to their backend via xml as explained on this page. Then:

  1. do I need to worry about PCI compliance? If so what steps (PCI website) should be sorted out by me, my hosting company or payment gateway people
  2. I was told as long as my form is on SSL my site would be automatically compliant. Is that right?

Thanks for any help

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

这个俗人 2024-09-15 18:02:08

1) 如果您随时处理信用卡信息,则需要遵守 PCI 规定。您需要解决编码问题,您的主机需要处理服务器的任何硬件和软件问题,支付网关公司有很多问题需要处理(这个列表太长,无法在此列出,但您不无论如何都需要担心)。

2) 不会。SSL 将帮助您遵守 PCI 标准,但 PCI 合规性除了数据如何从用户传输到服务器之外还有更多内容。您如何处理这些数据以及如何处理这些数据也会发挥作用。例如,如果您要存储信用卡信息,则需要使用加密,而不是存储 PCI 禁止存储的值(即 CVV 号)。将此信息放入会话中算作存储。

1) If you're handling credit card information at any time you need to be PCI compliant. You need to sort out coding issues, your host needs to deal with any hardware and software issues with the server, and the payment gateway company has a lot of issues to handle (which is a list too long to list here but you don't need to worry about anyway).

2) No. SSL will help you be PCI compliant but there is more to PCI compliance then how the data is transmitted from the user to the server. What you do with that data and how you do it also come into play. For example, if you are storing credit card information you'll need to be using encryption and not storing values barred from storage by PCI (i.e. CVV numbers). Putting this information in a session counts as storage.

寒冷纷飞旳雪 2024-09-15 18:02:08

问题 1 的回答:是的,您应该更加担心 PCI 合规性。

问题 2 的回答:使用 SSL 表单收集信用卡信息可以确保数据从客户端到服务器的安全传输。因此,如果您不打算将信用卡数据存储在服务器上,这就足够了。如果您想存储信用卡数据,则需要遵守 PCI DSS 存储信用卡数据的规定。

Answer to question 1: Yes you should be worried about PCI compliance all the more.

Answer to question 2: Using SSL form to gather the Credit card information takes care of secure transmission of data from the client to your server. So that is sufficient if you don't plan on store the credit card data on your servers. If you want to store the credit card data then you need to comply with PCI DSS for storage of credit card data.

隐诗 2024-09-15 18:02:08

其他评论中未提及的一个方面是 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 要求,而这些要求不是应用程序的直接责任。

One aspect that hasn't surfaced in the other comments is that PCI-DSS is assessed against an implemented, operational system and that the most significant component in that system is human processes and controls. The premise behind "my site would be automatically compliant" includes an assumption it is possible to assess a piece of technology, taken out of context, against the PCI-DSS.

Any custom application cannot, by definition of the PCI-DSS and PA-DSS, ever be declared PCI-compliant on its own merit. Applications and hardware that are non-customizable, turnkey solutions can be assessed against the PA-DSS but even they cannot be certified as PCI compliant out of the context of an implemented system and the human controls and processes associated with it.

Requirements 2, 10, 11 and 12 are entirely concerned with system controls that are external to your application and representative of human procedures and tasks. Of the other requirements, a close look at each reveals that they either directly or indirectly impose constraints on the human processes and controls.

So definitely read and absorb the other advice concerning the technical requirements of PCI but give up the notion that your finished application can ever be declared PCI compliant outside the context of a working, implemented system. A better approach would be to consider those requirements which are not directly related to technical details of your app design and ask yourself how the app helps the customer meet those requirements. For example, does your app make it easy for the customer to "Track and monitor all access to network resources and cardholder data"? (Requirement 10)

Many application vendors take the position that requirement 12, "Maintain a policy that addresses information security for all personnel," doesn't apply to them at all. But customers often come back and ask pointy questions about whether the app helps or hurts them on this assessment item. The customer is responsible for training their staff on how to prevent, detect and recover from a breach and the capabilities of the application to interoperate with security scanners, backup of configuration and data or to restore to a prior point in time are all critical. PCI requires vendor-issued security-relevant patches to be applied within 90 days or less so customers will want to know how and where you notify them of these things, how easy or disruptive it is to apply patches, whether the app must go down to apply them, etc.

Hopefully, a reasonably detailed assessment will cull out all the apps with obvious technical errors like failing to use TLS encryption, rendering login pages over HTTP or recovering passwords rather than sending a reset link. Any aspiration to comply with just the technical aspects of the PCI guidelines merely allow a new app to rise to the level of a commodity. To differentiate the app in the marketplace, design it to help the customer meet the PCI requirements that are not the direct responsibility of the app.

凡间太子 2024-09-15 18:02:08

我帮助创建了 Drupal PCI 合规性白皮书,它提供了这些问题以及您在使用时可能遇到的许多其他问题的答案努力使您的网站合规。虽然您可能没有使用 Drupal,但本文档中涵盖的原则非常高级,并且可以轻松应用于 WordPress、Joomla 或任何其他电子商务 CMS。

I helped create the Drupal PCI Compliance white paper, which provides answers to these and a host of other questions that you may have when trying to make your site compliant. While you may not be using Drupal, the principles covered within this document are high level and easily apply to wordpress, Joomla, or any other eCommerce CMS.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文