我在这里阅读了很多类似的问题,但没有一个与我的情况完全相同。
以前,用户输入大量信息,包括SSN,配偶SSN和CC数据。当用户完成该过程时,信息被推送到PDF上,压缩(然后加密),然后FTP回到我们的服务器。除了SSN和CC之外,我们保存了数据库中的所有内容,这些内容在会话死亡时被删除。
现在,我们需要将该信息保存到数据库以及用户A完成后,用户B需要进入并注销表单的某些情况。用户B完成后,将创建文件并删除SSN / CC数据。这意味着数据必须在几分钟到一个月内存在于我们的数据库中。有一个设定的到期日期,我将从数据库中删除数据并重新开始。注意:我没有使用CC数据实际收取费用,因此我无法将其交给像Authorize.net或Paypal这样的第三方。
解释说,我需要知道加密这些东西并保护它的最佳方法。我使用用户的GUID作为密钥在我的代码中执行AES,或者只是SQL Server 2005列加密并将解密功能限制为Web用户。
我喜欢AES,因为它让少数拥有数据库访问权限的人使用网络用户的密码来获取所有的CC数据。他们可以访问源代码并可以复制解密方法,但至少比运行一些查询要困难一些。
不幸的是,我没有时间推进不存储CC数据的方法,但我对下一个版本有一些想法。我必须在本周做出选择并实施加密。
答案 0 :(得分:2)
我不明白如何在应用程序代码中使用AES加密与用户GUID,因为对称密钥将保护数据不被具有数据库访问权限的人解密。在大多数系统中,用户ID GUID也不会以明文形式存储在数据库中吗?如果是这样,任何有权访问数据库的人都可以通过传递等效的解密函数来解密任何数据。
根据应用程序服务器连接到数据库服务器的方式,SQL Server中的内置列加密功能应该是一个很好的解决方案。如果使用集成身份验证,则可以避免为应用程序用户提供明文密码。通过使用可用的访问控制来保护加密密钥,您可以对其进行设置,以便其他任何用户(甚至可能不是DBA)都可以从数据库中任意解密数据。
2008年6月,我发表了关于在SQL Server 2005和2008中使用加密功能的演示文稿here
以下是该演示文稿中的示例代码,其中概述了如何完成此操作,以便只有相应的用户才能查看解密的数据:
- 为数据库创建主密钥,这将用于加密数据库中的每个其他密钥,然后由服务主密钥加密
CREATE MASTER KEY ENCRYPTION BY password = 'MasterKey1$'
- 为用户创建证书,用于保护自己的对称密钥 - 创建对称密钥以加密数据,因为它们更快,并且没有基于密钥大小的固有数据大小限制
CREATE CERTIFICATE data_cert AUTHORIZATION data WITH SUBJECT = 'Data Cert'
- 请注意,您也可以使用此处的ENCRYPTION BY PASSWORD选项来防止不知道密码的DBA打开证书,从而无法解密数据
- 为每个用户创建对称密钥以保护其数据 - 请注意,如果在XP上运行SQL Server,AES算法不可用,则必须使用3DES
CREATE SYMMETRIC KEY data_key WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE data_cert
- 请注意,您也可以在此使用ENCRYPTION BY PASSWORD,以防止不知道密码的DBA打开此密钥
- 授予对称密钥的权限,以便只有正确的用户才能访问它们
GRANT VIEW DEFINITION ON SYMMETRIC KEY::data_key TO [DOMAIN\ApplicationServiceAccount]
这为您提供了一个对称密钥,只能由相应的用户打开,以用于加密/解密表中的数据。您还可以获得数据库引擎中加密最佳实践功能的好处,例如使用唯一初始化向量加密的每个单元以及SQL Server中的密钥管理功能,使您可以定期轻松更改密钥。
答案 1 :(得分:0)
您是否已查看Payment Card Industry要求?
使用用户的GUID作为AES密钥似乎不合规。