保护内部工作人员提供的数据

Question

在我们的数据库中(为了简洁起见)，我们存储一些非常敏感的政府数据，并希望尽可能地保护这些数据。

这里有两种考虑安全性的方法：

1. 抵御外部入侵者(例如，确保符合PCI的要求)，
2. 内部入侵者的安全措施。

我的问题集中在后者。

人们认为信息的敏感性是如此之高，以至于我们面临着内部工作人员获取数据的可能性。

换句话说，我们担心内部工作人员会大量窃取数据并进行交易(只有当数据被完全窃取时才会很有趣，因为这是一个巨大的用户私有信息数据库)。

我们的应用程序以记录的方式访问DB .这被认为是很好的，因为使用逐条记录的方式访问数据工作人员是不会大量窃取信息的。

一个显而易见的解决方案是:将“DB的密钥”交给一个最信任的人。然而，我们担心的是，即使在这种情况下，有人可以拿枪指着他的头，并要求复制数据库。

我们有没有办法保护数据库，即使DBA被人用枪指着他的头，他的身体也无法窃取数据？？

。

注意:我们使用的数据库管理系统是PostgreSQL，但是我们可以很容易地切换到另一个系统，只要它提供我们正在寻找的安全保证。

Answer 1

Gun-against-the-head

需要更多的头颅。这个解线性地缩放。你需要保护的每把枪都需要一个无私的脑袋。考虑离散头的定位方法。你花在头上的工作越多，其他人花在定位枪上的工作就越多。隐藏头部以避免额外的混淆。

安全性是有头的O(n)：MySQL和石头一样安全，而岩石和PostgreSQL一样安全。这是MySQL在安全类比中所处的最佳位置。

软件栈安全

• 网络加密，使用SSL与AES密码。考虑使用openswan/strongswan使用网络身份验证来分层DB身份验证。
• 磁盘加密，使用eCryptfs
• 身份验证，使用谷胱甘肽

数据库安全

PostgreSQL支持行级安全性。我绝对建议回顾一下DDL安全文档。这保护了数据库不受应用级访问的限制。也许你所有的数据都不需要被每个应用程序读取？您甚至可以访问表中特定列的REVOKE或GRANT，请参阅文档获取更多信息(搜索列)。

特写

您也可以将加密数据存储在数据库中。这使DBA管理员完全摆脱了问题。然后，gun-against-the-head将故障点切换到最终用户。这可能是好事，也可能不是好事。当然，我更希望他们冒着枪林弹雨的风险。我只是运行它。

Answer 2

我立即想到的是SQL2016Enterprise "总是加密的"，它实时加密值，但也让SecurityOps这样的单独部门保存密钥。这样，DBA、web管理员和其他人根本就没有最终所需的加密值，而且其他人也可以拥有它。

当然，这是新的，不是傻瓜的证据。有各种各样的限制，当你决定测试的时候，你应该去看看，因为它们会随着时间的推移而改变。如果你不小心的话，你甚至可以拥有你认为是安全的数据。

但是，如果您能够正确地识别您希望在此级别上加密的列，这是一个很好的解决方案，可以查看它是否适合您的需要。我从这里复制的一些限制(当然不是全部)是：

• 使用下列数据类型之一的列: xml、时间戳/行版本、图像、ntext、文本、sql_variant、层次结构、地理、几何、别名、用户定义的类型。
• 填充柱
• 具有ROWGUIDCOL属性的列
• 字符串(varchar，char等)具有非bin2排序规则的列
• 作为非聚集索引的键的列，使用随机加密列作为密钥列(确定性加密列很好)
• 使用随机加密列作为密钥列(确定性加密列很好)作为聚集索引的键的列
• 列是包含随机和确定性加密列的全文索引的键。
• 计算列引用的列(当表达式对始终加密的数据执行不支持的操作时)
• 稀疏列集
• 由统计信息引用的列
• 使用别名类型的列
• 分区列
• 具有默认约束的列
• 使用随机加密时由唯一约束引用的列(支持确定性加密)
• 使用随机加密时的主密钥列(支持确定性加密)
• 使用随机加密或确定性加密时，如果引用列和引用列使用不同的密钥或算法，则引用外键约束中的列。
• 由check约束引用的列
• 使用更改数据捕获的表中的列。
• 表中具有更改跟踪的主键列
• 被屏蔽的列(使用动态数据掩蔽)
• 拉伸数据库表中的列。(使用始终加密的列加密的表可以启用拉伸。)
• 外部(PolyBase)表中的列(注意:支持在同一查询中使用具有加密列的外部表和表)
• 表变量中的列

配置“始终Encrpyted

否则，您可能会更好地滚动您自己的应用程序级加密支持，其中密钥管理是处理一个单独的团队，而操作系统团队无法访问。正在写入的数据将被加密，因为它正在被写入，所以仍然没有机会在中间攻击的人。