SQL Server 2008 + PCI Compliance? Pertains to PCI, as well as Symmetric keys!

那年仲夏 提交于 2019-11-30 16:04:57

If you store the PAN (card number) then it absolutely must be encrypted.

If you store cardholder name, expiry date, issue number (and they can be linked to the PAN), then they should be encrypted, but (my understanding) is that its not absolutely necessary. PCI-DSS only states that at a minimum the PAN must be encrypted.

The CV2/AVS/CSC code cannot be stored post authorization, and ideally you'd want to prove that it isnt stored at all (eg - only kept in memory whilst performing authorization)

Regarding certificates/keys - you could just use one key for encryption of all card related data. Best practice is to not use keys for multiple purposes, so if you have other (non card related) data that is encrypted, then use a seperate key for that.

The most difficult part is one you havent really mentioned in detail - and thats key management. To meet PCI requirements the key must be stored on a seperate physical box to the database, and you need the ability to change the key at least annually. SQL 2008 supports this with Extensible Key Management (EKM)

All of these points are best discussed with an independant QSA (Qualified Security Assessor) who you will at some point need to involve regardless in order to meet PCI compliance. Your QSA will be able to guide you on questions such as this, and ultimately its his/her advice that you should follow in order to meet compliance.

Its worth mentioning that most people soon realise how much of a burden PCI compliance can be, and look to minimize that burden by using a 3rd party payment gateway. Most payment gateways will allow you to perform authorization/settlement and store the card details on their (already PCI compliant) servers. You then only need store a TokenId that references those payment details should you need to perform further charges/refunds on that card.

Good luck either way!

From the specification: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Requirement 3: Protect stored cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.

I think this strongly suggests that you should

  1. not store unless you have to
  2. if you have to, store a part if you can
  3. if you store anything, encrypt it.
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!