pci开发_PCI合规性和PHP开发人员

pci开发

PCI stands for ‘Payment Card Industry’, but to many people it’s a shadowy set of standards imposed by a secret international cartel champing to bury the unwary soul with back-breaking regulations and legal woes.

PCI代表“支付卡行业”，但对许多人来说，这是由秘密的国际卡特尔集团强加的一套模糊的标准，这些国际卡特尔争先恐后地将棘手的灵魂埋葬于突破性的法规和法律困境中。

The truth of the matter is much more boring and pedestrian. In reality, PCI is a set of security guidelines drawn up by a consortium of credit card companies and industry security experts to govern how applications should behave when handling credit or debit card information. The card companies impose these standards on the banks who then impose them on those of us who operate e-commerce sites and the like.

事情的真相更加无聊和行人。 实际上，PCI是由信用卡公司和行业安全专家组成的联盟制定的一组安全准则，用于管理应用程序在处理信用卡或借记卡信息时应如何表现。 卡公司将这些标准强加给银行，然后将这些标准强加给我们经营电子商务网站等的人。

In this article we will dispel a couple of persistent myths about PCI, take a 20,000-foot look at what PCI encompasses, and then zero in on those requirements that are most closely associated with coding in general and PHP specifically.

在本文中，我们将消除关于PCI的两个固定的误解，以20,000英尺的高度看一下PCI包含的内容，然后从零开始了解与一般编码和PHP最紧密相关的那些要求。

PCI神话 (PCI Myths)

Not surprisingly, there are a number of myths surrounding the PCI standards. One such myth is they are like rules of conduct for the mafia, not written down anywhere so they can be interpreted anyway you want. That, of course, is not true. For a full statement of the PCI standards, all you have to do is go to pcisecuritystandards.org.

毫不奇怪，围绕PCI标准存在许多神话。 一个这样的神话是，它们就像黑手党的行为准则，没有在任何地方写下来，因此无论如何您都可以解释它们。 当然，这是不正确的。 有关PCI标准的完整说明，您要做的只是去pcisecuritystandards.org 。

Another myth is that PCI security standards only apply to the “big guys” like banks and major retailers. They apply to every single person who accepts card information to pay for things. If you’ve written a site in PHP for your mother to sell her famous lemon pies, you have a system that falls under the PCI guidelines.

另一个神话是，PCI安全标准仅适用于银行和主要零售商等“大人物”。 它们适用于接受卡信息付款的每个人。 如果您已经用PHP编写了一个网站来出售给母亲以出售其著名的柠檬派，那么您的系统就属于PCI准则。

A third myth is that if you follow the PCI standards then you’ll be protected from malevolent hacking and your data will stay safe. That would be nice of course, but the fact is that the PCI standards are guidelines and ideas, not specific techniques (they have to be vague to fit all architectures and platforms). Obviously, the more attention you pay to security, the smaller your chances are of being hit, but anyone can be compromised. You will be viewed, both legally and consumer-ly, better if you have at least tried to meet the PCI expectations.

第三个神话是，如果您遵循PCI标准，那么您将免受恶意黑客的攻击，并且您的数据将保持安全。 当然这会很好，但是事实是PCI标准是指南和思想，而不是特定的技术(它们必须含糊不清才能适合所有体系结构和平台)。 显然，您对安全性的关注越多，遭受攻击的机会就越小，但是任何人都可能受到损害。 如果您至少尝试满足PCI期望，那么无论从法律上还是从消费者角度，您都会得到更好的评价。

Finally, PCI is not something you do once and then breathe a deep sigh of relief. The standards calls for you to do a PCI review once a year, so this is something that is ongoing like quality assurance efforts or listening to your spouse.

最后，PCI并非您一次要做的事，然后松了一口气。 这些标准要求您每年进行一次PCI审查，因此这正在进行中，例如质量保证工作或倾听您的配偶。

The simple truth is that PCI is something that every programmer who works on an app that touches credit card data, no matter how small, needs to be aware of. Yeah, that’s why dealers only take cash.

一个简单的事实是，PCI是每一个从事处理信用卡数据的应用程序的程序员，无论其大小如何，都需要意识到这一点。 是的，这就是经销商只收取现金的原因。

PCI基础知识 (PCI Fundamentals)

The PCI standard is composed of 12 basic requirements. The standard is updated about every two years, and in between a variety of guideline documents are released that are more specific and deal with a certain subset of the PCI world. For example, in February 2013, the PCI people released a white paper discussing PCI and the Cloud. These special reports are also available from the PCI web site.

PCI标准由12个基本要求组成。 该标准大约每两年更新一次，并且在此期间发布了一系列更具体的指南文件，这些指南文件涉及PCI世界的某些子集。 例如，2013年2月，PCI人员发布了一份讨论PCI和云的白皮书。 这些特殊报告也可从PCI网站获得。

As we will see, many of the PCI requirements are more network oriented, but what is the point of talking about this stuff if you don’t walk away with at least a basic view of full PCI? The requirements are:

正如我们将看到的，许多PCI要求都是面向网络的，但是如果您至少不了解完整PCI的基本观点，那么谈论这些内容又有什么意义呢？ 要求是：

• Area 1 – Build and Maintain a Secure Network

  领域1 –建立和维护安全网络

  • Requirement 1 – Install a firewall to protect your environment.
    要求1 –安装防火墙以保护您的环境。
  • Requirement 2 – Do not use vendor default profiles or passwords.
    要求2 –不要使用供应商默认配置文件或密码。

• Area 2 – Protect Cardholder Data

  区域2 –保护持卡人数据

  • Requirement 3 – Protect Stored Cardholder Data.
    要求3 –保护存储的持卡人数据。
  • Requirement 4 – Encrypt Cardholder Data that is transmitted across open, public networks.
    要求4 –加密通过开放的公共网络传输的持卡人数据。

• Area 3 – Maintain a Vulnerability Management Program

  领域3 –维护漏洞管理程序

  • Requirement 5 – Use and regularly update anti-virus software.
    要求5 –使用并定期更新防病毒软件。
  • Requirement 6 – Develop and maintain secure systems and applications.
    要求6 –开发和维护安全的系统和应用程序。

• Area 4 – Implement Strong Access Control Mechanisms

  领域4 –实施强大的访问控制机制

  • Requirement 7 – Restrict access to Cardholder data on need-to-know basis.
    要求7 –在需要知道的基础上限制对持卡人数据的访问。
  • Requirement 8 – Assign a unique ID to each person with computer access.
    要求8 –为可以访问计算机的每个人分配唯一的ID。
  • Requirement 9 – Restrict physical access to cardholder data.
    要求9 –限制对持卡人数据的物理访问。

• Area 5 – Regularly Monitor and Test Networks.

  区域5 –定期监视和测试网络。

  • Requirement 10 – Track and monitor/log all access to network resources and cardholder data.
    要求10 –跟踪和监视/记录对网络资源和持卡人数据的所有访问。
  • Requirement 11 – Regularly test security systems and processes.
    要求11 –定期测试安全系统和流程。

• Area 6 – Maintain an Information Security Policy.

  区域6 –维护信息安全策略。

  • Requirement 12 – Maintain a policy that addresses information security.
    要求12 –维护解决信息安全问题的策略。

Some of these items are related to policy decisions, namely the decision to set up policies that spell out exactly how you make an effort to protect card information and ensure the overall security of your network and applications. Other requirements relate to the network itself and to the software that you can use to protect it. Some of them deal with the design phase of the process, how you structure and set up your app. Hardly any of the requirements deal with code at all and none of them describe specific programming techniques that are recommended to keep you safe. To keep things relatively short I’ll restrict my sarcasm and wisdom (it’s a 70:30 mix) and focus on the last two groups.

其中一些项目与策略决策有关，即建立策略的决策，这些策略明确说明了您如何努力保护卡信息并确保网络和应用程序的整体安全性。 其他要求与网络本身以及可用于保护它的软件有关。 其中一些涉及流程的设计阶段，结构和设置应用程序的方式。 几乎没有任何需求完全涉及代码，并且它们都没有描述推荐的特定编程技术，以确保您的安全。 为了使事情相对简短，我将限制我的讽刺和智慧(这是70:30的比例)，并专注于最后两个小组。

要求2 –不要对配置文件/密码使用供应商默认值 (Requirement 2 – Don’t Use Vendor Defaults for Profiles/Passwords)

In many ways this is almost a no-brainer. Security people have been telling us this since the dawn of worrying about things. But it is surprising how easy it is to just take the default account and password (especially when you first install things and everything is very ‘test’) on many of the pieces of software we use, MySQL to name just one.

在许多方面，这几乎是理所当然的。 自从担心事情开始以来，安全人员就一直在告诉我们这一点。 但是令人惊讶的是，在我们使用的许多软件中，仅使用默认帐户和密码(尤其是在您初次安装时，一切都非常“测试”)是多么容易，MySQL仅举一个例子。

The danger here is increased because the majority of us build our applications around some base pieces of software rather than doing the whole thing from scratch. It might just be a package we use to handle encryption and key storage (see below) or it might be the framework for the entire app. Either way, easy to remember, easy to implement: don’t use default accounts.

因为我们大多数人都是围绕某些基本软件构建应用程序，而不是从头开始做整个事情，所以这里的危险增加了。 它可能只是我们用来处理加密和密钥存储的软件包(请参见下文)，也可能是整个应用程序的框架。 无论哪种方式，都易于记住，易于实现：请勿使用默认帐户。

要求3 –保护存储的持卡人数据 (Requirement 3 – Protect Stored Cardholder Data)

Most of the high profile retail site hacks that I can remember involved the theft of card or other data that the site was keeping, so I would rank this as pretty much the most important part of the PCI standard.

我记得的大多数知名零售网站黑客都与盗窃该网站保存的卡或其他数据有关，因此我将其列为PCI标准中最重要的部分。

Obviously, any card data you store should be encrypted. And you need to do a good job of encrypting it. For those who know a great deal about encryption, you know that doing a good job of encrypting data means you have done a good job of managing the encryption keys.

显然，您存储的所有卡数据都应加密。 而且您需要做好加密工作。 对于那些非常了解加密的人来说，您知道做好加密数据意味着您已经做好了管理加密密钥的工作。

Key management revolves around the problem of generating, storing, and updating the keys used in the encryption process. Storing them can be a big problem because you want to make sure that someone can’t get into the system and steal the keys. Management strategies differ on how to divide and separate the key into multiple parts; if you want an introduction to key management, I would start with this whitepaper by Securosis and then go from there, although be warned that the water gets pretty deep pretty quickly.

密钥管理围绕着生成，存储和更新加密过程中使用的密钥的问题。 存储它们可能是一个大问题，因为您要确保某人无法进入系统并窃取密钥。 管理策略在如何将密钥分为多个部分方面有所不同。 如果您想要介绍密钥管理，我会从Securosis撰写的这份白皮书开始，然后再去那里，尽管会警告您水很快就会变得很深。

Of course, if you’re using a commercial product to handle encryption then you can leave the key management to them, although you want to make sure their process is solid and that it fits into your approach. Most commercial products are developed with PCI in mind and so would be built in accordance with the PCI standards, but it still doesn’t hurt to double check.

当然，如果您要使用商业产品来处理加密，则可以将密钥管理交给他们，尽管您想确保它们的过程是可靠的并且适合您的方法。 大多数商业产品都是在考虑PCI的情况下开发的，因此将根据PCI标准进行构建，但是再次检查仍然不会受到损害。

Also, the task of protecting data will become a lot easier if you minimize, or even eliminate, the amount of data you store. That is, card holder data could be anything from their name, birthday, card number, expiration date, card verification (CV) code (the three or four digits on the back or front of the card), etc. The fewer items you keep, the less you have to encrypt and the smaller your liability. Fortunately, this is one area where the PCI standard is pretty specific by specifying exactly what data you can and can’t keep. You may keep the card number (PAN – Primary Account Number), the card holder’s name, the expiration date, and the service code. If you do keep the PAN, then you must mask it if you are going to display it, with the first six and the last four digits being the maximum that you can show. You may NOT store the PIN, the CV code, or the entirety of the magnetic strip.

而且，如果您最小化甚至消除存储的数据量，保护数据的任务将变得更加容易。 也就是说，持卡人的数据可以是其名称，生日，卡号，有效期，卡验证(CV)码(卡背面或正面的三或四位数字)等任何内容。您保留的项目越少，则加密的次数越少，责任也就越小。 幸运的是，这是PCI标准非常明确的一个领域，它确切地指定了可以保留和不能保留的数据。 您可以保留卡号(PAN –主帐号)，持卡人的姓名，有效期和服务代码。 如果确实保留PAN，则如果要显示它，则必须屏蔽它，前六位和后四位是可以显示的最大值。 您可能无法存储PIN，CV代码或整个磁条。

The question you have to ask yourself during the design phase is how much of this stinkin’ data do you really want to hang on to. The only real reason to keep it is that you want to provide your customers with an easy experience the next time in. And you can hang on to the birthday so you can send them a friendly little come on about birthday time. All that data has to be encrypted and protected, so make sure you are getting some solid business use out of it.

在设计阶段，您必须问自己的问题是，您真的想保留多少这些臭气熏天的数据。 保留它的唯一真正原因是您想在下一次为客户提供轻松的体验。而且您可以坚持生日，这样就可以向他们发送有关生日的友好小礼物。 所有这些数据都必须进行加密和保护，因此请确保您已将其用于可靠的业务用途。

Requirement 4 (to encrypt any data being transmitted) is sort of part of this, but I am going to consider that part of the infrastructure and not dwell on it.

需求4(对传输的任何数据进行加密)只是其中的一部分，但我将考虑基础架构的这一部分，而不是赘述。

要求6 –开发和维护安全的系统和应用程序 (Requirement 6 – Develop and Maintain Secure Systems and Applications)

This is the requirement that is related to code. Not to specific functions or classes, but at least making sure that you follow the general security standards and try to make your stuff somewhat bullet proof. So, you simply use coding techniques, regardless of the language, that do not open your application to obvious hacks. For example, you try to prevent SQL injections by taking precautions when you accept form data, you try to block XSS, etc. For more information on avoiding some of the more common security problems, refer to some of the other articles that have been published on SitePoint (this and this plus other articles available if you search by “security”).

这是与代码有关的要求。 不是针对特定的函数或类，而是至少确保您遵循通用的安全标准，并尝试使您的内容具有防弹性。 因此，无论使用哪种语言，您都可以简单地使用编码技术，而不会使您的应用程序容易受到黑客的攻击。 例如，当您接受表单数据，尝试阻止XSS等时，通过采取预防措施来尝试防止SQL注入。有关避免某些较常见的安全问题的详细信息，请参阅其他一些已发表的文章。在SitePoint( 这个和这个加号，如果你所说的“安全”搜索可用的其他文章)。

要求7和8 –限制访问和唯一ID (Requirement 7 & 8 – Restrict Access & Unique ID)

Both of these things relate to the way you access the app and so lie somewhere between coding and design.

这两件事都与您访问应用程序的方式有关，因此介于编码和设计之间。

Requiring a unique ID for each visitor should be no problem unless – you happen to let people sign on and shop via a guest profile. I can think of a couple of sites off hand that allow you to do this, and of itself it is not evil, but the use of group profiles is dangerous and you have to take extra pains to make sure they don’t have much authority. In general, you should strive to set up unique IDs, even if the ID is not one that you save. For example, you can let people sign on as a guest but then immediately create a unique profile behind the scenes for the event.

除非每个人都需要一个唯一的ID，否则应该没问题，除非您碰巧允许人们通过访客个人资料登录并购物。 我可以想到几个可以让您执行此操作的站点，它本身并不是邪恶的，但是使用组配置文件很危险，您必须付出额外的努力以确保它们没有太多权限。 通常，即使ID不是您要保存的ID，也应努力设置唯一的ID。 例如，您可以让人们以客人身份登录，然后立即在事件的幕后创建一个唯一的个人资料。

We also want to restrict physical access to the card holder data. This might be a nod to the future when we’ll be able to shrink people down to a sub-microscopic size as in Issac Assimov’s Fantastic Voyage and inject them into the storage device to get at the 1’s and 0’s of the card data… or it may also relate to things like locked server rooms, badges for all visitors, not letting anyone get close to the backup tapes, and that sort of thing.

我们还希望限制对持卡人数据的物理访问。 当我们能够将人员缩小到亚微观尺寸(如Issac Assimov的Fantastic Voyage)并将其注入存储设备以获取卡数据的1和0时，这可能是对未来的致敬。它也可能与诸如锁定服务器机房，为所有访客提供徽章，不让任何人靠近备份磁带之类的事情有关。

要求10 –跟踪和记录对资源/数据的所有访问 (Requirement 10 – Track and Log all Access to Resources / Data )

Finally, don’t underestimate the importance of tracking and logging everything that accesses either a resource or the cardholder data… and I mean everything. Events that should be logged include signing on, signing off, data access; data updates, really anything that involves a resource or data element and you think might be useful as an audit trail or as evidence at a criminal trial. You must implement a secure log, review the log daily looking for trouble, and keep the log for one year.

最后，不要低估跟踪和记录访问资源或持卡人数据的所有内容的重要性……我的意思是所有内容。 应记录的事件包括登录，注销，数据访问； 数据更新，实际上是涉及资源或数据元素的任何内容，您认为它可能作为审核跟踪或作为刑事审判的证据很有用。 您必须实施安全日志，每天查看日志以查找故障，并将日志保存一年。

For PHP users, it would be beneficial to get familiar with the PSR-3 logging standard that has come from the PHP-FIG group and provides a uniform yet flexible way to set up your logging. Rather than get into this here, I would recommend Patrick Mulvey’s introductory article.

对于PHP用户，熟悉PHP-FIG组提供的PSR-3日志记录标准将是有益的，它提供了一种统一而灵活的方式来设置日志记录。 与其在这里讨论，不如推荐Patrick Mulvey的介绍性文章 。

摘要 (Summary)

I guess the one thing I want to really stress is that PCI is not icing. Its part of the flour of creating apps that work with credit card data. If you’re writing an app that does take in such data, it applies to you whether your clients know it or not. Most of it is above the coding level, but it is real and something you must still pay attention to.

我想我要特别强调的一件事是PCI没有结冰。 这是创建可处理信用卡数据的应用程序的一部分。 如果您编写的应用程序确实包含此类数据，则无论您的客户是否知道，它都适用于您。 它大多数都在编码级别之上，但这是真实的，您仍必须注意。

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/pci-compliance-and-the-php-developer/

pci开发