SQL Server 2008 + PCI 合规性？与 PCI 以及对称密钥有关！
我以前从未处理过 PCI 合规性问题。我一直在阅读他们的文档，其中说我需要保护信用卡号、到期日期和持卡人姓名。永远不会存储安全代码。
在他们的文档中，它只是说“保护”。这是说我需要加密数据库中的这 3 列吗？我以为只有数字才是需要加密的数据。不管怎样，我都同意。
如果我需要加密所有三列，我是否共享一个证书并拥有 3 个对称密钥，或者我只需要每个证书 1 个，并且该对称密钥用于所有 3 列？我问的原因是在关于加密列的 BoL 文档中，密钥是根据他们正在加密的列专门命名的。
感谢您的帮助！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您存储 PAN（卡号），那么它绝对必须加密。
如果您存储持卡人姓名、到期日期、发行号（并且它们可以链接到 PAN），那么它们应该被加密，但是（我的理解）这并不是绝对必要的。 PCI-DSS 仅规定 PAN 至少必须加密。
CV2/AVS/CSC 代码无法在授权后存储，理想情况下您想证明它根本没有存储（例如 - 仅在执行授权时保留在内存中）
关于证书/密钥 - 您可以只使用一把密钥所有卡相关数据的加密。最佳实践是不要将密钥用于多种用途，因此，如果您有其他（与卡无关的）加密数据，请使用单独的密钥。
最困难的部分是你没有真正详细提到的部分——那就是密钥管理。为了满足 PCI 要求，密钥必须存储在与数据库不同的物理盒子上，并且您需要能够至少每年更改一次密钥。 SQL 2008 通过可扩展密钥管理 (EKM) 支持这
一点。最好与独立的 QSA（合格安全评估员）讨论，为了满足 PCI 合规性，您有时需要让他们参与。您的 QSA 将能够就此类问题为您提供指导，并且最终您应该遵循他/她的建议才能满足合规性。
值得一提的是，大多数人很快就会意识到 PCI 合规性会带来多大的负担，并希望通过使用第三方支付网关来最大程度地减轻这种负担。大多数支付网关将允许您执行授权/结算并将卡详细信息存储在其（已符合 PCI 标准）服务器上。然后，如果您需要对该卡执行进一步的收费/退款，您只需存储引用这些付款详细信息的 TokenId。
不管怎样，祝你好运！
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!
来自规范：https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
我认为这强烈建议你不要
From the specification: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
I think this strongly suggests that you should