SQL Server 2008 + PCI合规性？适用于PCI，以及对称键！ [英] SQL Server 2008 + PCI Compliance? Pertains to PCI, as well as Symmetric keys!

问题描述

之前我从来没有必须处理PCI合规性。我一直在阅读他们的文档，它说我需要保护信用卡号码，到期日期和持卡人的姓名。没有存储安全代码。

在他们的文档中，它只是说保护。这个说法我需要加密我的数据库中的这3列吗？我认为只有数字是需要加密的数据。无论哪种方式，我都很好。

如果我需要加密所有三列，我是否共享一个证书，并有3个对称密钥，否则我只需要1个在所有3列上使用该对称密钥？我所要求的原因是在BoL文档中加密列，该密钥在他们加密的列之后具体命名。

感谢所有的帮助！

解决方案

如果您存储PAN（卡号），那么绝对必须加密。

如果您存储持卡人姓名，到期日期，发行号码（并且可以链接到PAN），那么他们应该加密，但（我的理解）是它不是绝对必要的。 PCI-DSS仅说明PAN必须加密。

CV2 / AVS / CSC代码不能保存在后授权中，最理想的是你想证明它根本没有存储（例如 - 只在执行授权时保存在内存中）

关于证书/密钥 - 您只需使用一个密钥对所有卡相关的加密数据。最佳做法是不要将密钥用于多个目的，因此，如果您有其他（非卡相关）数据被加密，则使用单独的密钥。

最困难的部分是你没有真正提到的细节 - 这是关键管理。为了满足PCI要求，密钥必须存储在数据库的单独物理框上，您需要至少每年更改密钥的能力。 SQL 2008支持可扩展密钥管理（EKM）

所有这些要点都与独立的QSA（合格安全评估员）进行了最佳讨论，您将在某些时候需要涉及以满足PCI符合性。您的QSA将能够指导您提出这样的问题，最终指导您遵守的建议，以满足合规性。

值得一提的是大多数人很快意识到PCI合规性的负担是多少，并且通过使用第三方支付网关来减少这种负担。大多数支付网关将允许您执行授权/结算并将卡的详细信息存储在其（已经是PCI兼容的）服务器上。然后，您只需要存储一个TokenId，如果您需要在该卡上执行进一步的费用/退款，则可以参考这些付款细节。

祝你好运！

I've never had to deal with PCI compliance before. I've been reading their documentation and it says I need to protect the credit card number, expiration date and the card holder's name. No storage of security codes ever.

In their documentation, it just says protect. Is this saying I need to encrypt these 3 columns in my database? I thought only the number was the data that needed to be encrypted. Either way, I'm fine with.

If I need to encrypt all three columns, do I share one certificate and have 3 symmetric keys, or will I only need 1 of each, with that symmetric key being used on all 3 columns? The reason I ask is in the BoL documentation on encrypting a column, the key is named specifically after the column they are encrypting.

Thanks for all the help!

解决方案

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!

这篇关于SQL Server 2008 + PCI合规性？适用于PCI，以及对称键！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！