如何最好地加密/解密 SQL Server 数据以防止开发人员查看?

8
这是一个有趣的问题,我正在寻找一个能让它可行的模式。
我正在为一个学校系统构建智能客户端应用程序。它将包含有关学生的信息,包括他们的报告卡、病假等等。它将生成学生级别的报告,包括他们的报告卡,每个报告都有老师的非常个人化的评论。该应用程序将通过Web服务从远程服务器检索数据。
因此,数据相当机密。我将在数据库中对其进行加密,并在检索时解密-没有问题。
问题是,我和我的团队应该真正永远不会看到生产纯文本数据。这就出现了一个有趣的问题,用于调查生产错误!我们想要打开与用户相同的记录,以查看他们所看到的内容。但如果我们这样做,就违反了保密性。
我的想法是这样的,它并不完美。
第一,在存储在数据库中之前加密数据,在UI上解密它。没有什么新鲜的东西。
第二,在UI中放置一个机制来混淆特权数据。(即,姓名和教师叙述是特权的;年级不是。)我不会加密它,而是混淆它-即使是简单的键移位也足够了。原因是,这些报告充满了文本。如果我加密一个段落并在报告中显示结果,那么它将成为一堵大写字符的固定墙,看起来与原始文本毫不相似。如果我对字母字符进行键移位,它将是难以阅读的,但仍然看起来像段落、句子、项目列表等。这样做将更容易看出哪里出了问题,而不会增加视觉复杂性。
第三,在配置设置中放置此UI混淆,仅适用于例如SysAdmin角色的成员,而不适用于教师或SchoolAdmin。在开发过程中,我将此配置设置为False,并使用虚假纯文本进行开发。对于生产,我们将其设置为True,从那时起,我们只能看到混淆的文本。
最后,对于那些绝对必须看到学生记录的纯文本的情况,我们在UI中具有覆盖设置,可以推翻配置设置,并呈现纯文本。我们在人类层面上管理这个-通知学校行政当局,在这个日期和这个原因下,我们需要看到这个学生的记录等等。签名被签署,同意被得到,律师们正在争吵中,反复洗涤。
您认为怎么样?我觉得这一定是经过深思熟虑的。如果可能,请帮助我改进这个计划。
4个回答

2

我曾经在一个类似的团队中遇到过这样的问题,我们不得不使用大量的模拟数据。生产总是充满了猜测。没有人被允许知道任何密码。

编辑

如果你想要完全安全,你应该让外部公司处理数据,这将使他们处于保护数据的位置,并保证如果出现错误,你不会被起诉。这只是我的个人意见。


听起来这是我需要走的路。我可能只需要告诉客户:“有一些问题我无法直接解决。”我们可以设置一些测试学生,并且不对他们进行加密/解密操作。如果在真实学生中出现问题,解决方案将要求他们在测试学生的记录中重新创建该问题。他们可能不喜欢额外的工作,但这是我们共同承担的维护机密性的一部分负担。 - TomK

1

一般来说,我的处理方法如下:

SQL Server 有加密功能 - 透明加密(在查询中可以看到解密后的数据,不适合您的情况)或基于密钥的加密,其中用户帐户具有密钥的 ACL。使用此方法,在 SQL 服务器本身上创建 X509 证书,然后生成具有适当 ACL 的对称密钥。在存储过程内,您可以打开对称密钥以将未加密的数据返回给应用程序。当然,您应该通过安全方式连接到 SQL - 您可以在 SQL 服务器上放置 X509 证书以保护连接。

现在,您面临密钥管理问题。您可以为应用程序创建一个特定的 Windows 帐户,并配置一个随机强密码,一旦配置了应用程序池,即可丢弃该密码,然后将该 NT 帐户添加到 SQL 中(如果您处于域环境中,则很容易进行操作,工作组必须在 IIS 和 SQL 服务器上镜像帐户)。对于调试,您需要另一个具有密钥访问权限的帐户。此帐户的密码应采用“破玻璃”设置-存储在可审计的位置,或者密码的一半由两个或更多人共享,这些人必须达成共识并进行正式签署表明需要它(然后一旦使用后就会更改)。

这里有一个关于SQL加密的介绍链接, 但它并没有涵盖ACLs。MSDN有一个完整的章节,其中也涵盖了认证器和各种可用选项。

或者您可以选择使用加密Web服务,调用它来加密数据,返回一个GUID引用和密文。这样密钥可以存储在受保护的数据库中,并且解密函数可以根据每个帐户进行保护。同样,您需要拥有一个紧急访问账户。当客户不感到自信管理SQL加密时,我会采取这种方法。


非常感谢您提供如此详尽的答案!由于这是一个相对较小的项目,且客户规模较小,我认为我会避开这条路。但我可以看出,对于我的一些大客户来说,这可能是正确的选择。 - TomK

0
实际上,在用户界面不需要解密数据。 SQL Server 有工具可以为您进行实时加密。如果有人需要查看明文,则可以将其放入一个角色中,该角色将授予他们该权限(并在完成后删除)。
但是,如果查看数据会违反保密性,那么显然您永远无法查看生产数据。唯一的解决方案是使用带有混淆数据或完全随机数据的数据副本。

我可能不得不使用虚假数据,甚至是虚假学生,并让教师在虚假学生记录中重新创建问题。关于SQL Server加密,是的,我正在研究,但我不喜欢我看到的。我预计将所有解密代码放入存储过程中,这意味着明文通过Web服务传输到UI。虽然这些不是NORAD的发射代码,但我宁愿将加密/解密保持接近UI。 - TomK

0

你一定要有的一件事是不可变的审计追踪。每当有人访问任何机密数据时,都会创建一个审计记录。在像系统管理员请求访问他们通常不应查看的报告数据的情况下,将记录异常。

客户端应该制定业务流程,定期审查审计日志中的任何异常。这既可以作为滥用系统的威慑力,也可以在事后进行调查,如果有人走了极端。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接