gmi*_*ile 3 security database-design
在我们的数据库（为简洁起见是 DB）中，我们存储了一些非常敏感的政府数据，并希望尽可能保护这些数据。
这里有两种考虑安全性的方法：
我的问题集中在后者。
信息的敏感性被认为如此之高，以至于我们面临着内部员工极有可能接触到这些数据的可能性。
换句话说，我们担心内部员工可以批量窃取数据并进行交易（数据只有在完全被盗时才有意义，因为它是人们私人信息的巨大数据库）。
我们的应用程序以逐条记录的方式访问数据库。这被认为是好的，因为使用逐条记录方式访问数据人员不会大规模窃取信息。
一个显而易见的解决方案是：将“数据库的钥匙”交给一个最值得信赖的人。然而，我们担心的是，即使在这种情况下，有人也可以用枪指着他的头并要求制作 DB 的副本。
有什么办法可以保护数据库，这样即使 DBA 用枪指着他的头，他也无法窃取数据？
注意：我们使用的数据库管理系统是 PostgreSQL，但如果它提供我们正在寻求的安全保证，我们可以轻松切换到另一个。
需要更多的头。该解决方案线性扩展。你需要防范的每一把枪都需要一个无私的头脑。考虑离散头定位的方法。你花在头部定位上的工作越多，其他人花在定位枪上的工作就越多。隐藏头部以进行额外的混淆。
安全是 O(n)有：MySQL 与岩石一样安全，它与 PostgreSQL 一样安全。这是 MySQL 曾经处于的安全类比中的最佳位置。
PostgreSQL 支持行级安全。我绝对建议查看DDL 安全文档。这可以保护数据库免受无限制的应用程序级别访问。也许您的所有数据都不需要被每个应用程序读取？您甚至REVOKE可以GRANT访问或访问表中的特定列，请参阅文档了解更多信息（搜索列）。
您也可以将加密数据存储在数据库中。这让 DBA 管理员完全摆脱了这个问题。然后将gun-against-the-head故障点切换到最终用户。这可能是也可能不是一件好事。当然，我更喜欢他们冒枪对抗头部的风险。我只是运行它。