我正在寻找将敏感数据存储在数据库中的最佳解决方案。 我知道这是常见问题而且我完成了我的作业（至少这是我的想法），但我想在此之前先问我做出决定。
假设：
我在考虑两个概念：
借助passlib.totp库加密数据。为了使这些数据更安全，我会将密钥保存在单独的文件中。然后从我所看到的，我可以使用这个库使用我的密钥将数据解密为纯文本。
另一个概念是在postgres的帮助下在查询请求期间加密和解密数据：
insert into demo(pw) values ( encrypt( 'data', 'key', 'aes') );
和
decrypt(pw, 'key', 'aes'), 'utf-8')
此处密钥也将存储在单独的文件中。
所以我的问题是：
答案 0 :(得分：1)
2）另一个概念是在查询请求期间借助postgres加密和解密数据：插入demo（pw）值（加密（＆＃39;数据＆＃39;，＆＃39;键＆＃39;， ＆＃39; aes＆＃39;））;并解密（pw，＆＃39; key＆＃39;，＆＃39; aes＆＃39;），＆＃39; utf-8＆＃39;）此处密钥也将存储在单独的文件中。
我不推荐这样做，因为它的方式太容易让密钥暴露在pg_stat_activity，日志等等中.PostgreSQL没有＆＃39 ;具有日志屏蔽功能，可以防止这种情况。
我强烈建议您使用app-side crypto。如果安全性至关重要，请使用加密卸载设备，因此大多数攻击者都无法进行密钥提取。或者要求管理员在应用启动时输入密码来解锁密钥，因此密钥永远不会以未加密的方式存储在磁盘上 - 然后攻击者必须从内存中窃取密钥。但即使是非显而易见的未加密密钥文件也比in-db加密，IMO更好，因为它至少将密钥与数据分开。
答案 1 :(得分：0)
最终，您的应用程序需要能够使用某种键来恢复明文密码。如果您的系统遭到入侵，您必须假设恶意用户只需找到您的密钥（无论是在数据库中还是在磁盘上），并执行与您的应用程序执行完全相同的解密。
当您的系统需要以可恢复的形式存储密码时，即通过外部系统进行身份验证时，您最多只能对该信息进行模糊处理。这就是人们在通过默默无闻来提及安全性时的意思，而且这是一个坏主意。
当您提供安全性的外观时，如果没有实际保护某些内容，那么这会使事情变得更加危险。您或其他管理系统的人可能会忽略其他重要的安全措施，因为他们认为敏感信息已经存在一层保护。如果认为保护信息的唯一方法是保护持有信息的系统，那么它可能会造成敏感信息可能更容易泄漏的社交场合。它还可以使人们相信，如果数据从数据库中被盗，那么它可能是正常的，因为它们无法对数据进行解密＆＃34;。这就是你最终要向全世界泄露凭据的责任，因为你必须假设如果你的应用程序可以获得纯文本数据，那么攻击者也可以破坏你的应用程序。
在多个系统上加密多部分密钥（例如，部分在文件系统上，部分在数据库中），可能有非常小的优势，因此获得对一个系统的访问权限的人不会＃39; t必须获得对方的访问权限。事实上，这可能会延迟攻击，或阻止懒惰的攻击者，这是合情合理的。但是，一般来说，您的应用程序所在的位置无论如何都可以访问这些内容，因此如果您的应用程序被泄露，那么您必须假设数据已被泄露。 （编辑：你在另一个评论中提到你有用户a）不应该知道存储在数据库中的密码，但是b）可以直接访问数据库。相信我，如果你这样做，其中一个用户获得所有这些密码的概率非零。沿着这条路走下去，你就会把自己的信仰放在一个错误的保护层上。）
tl; dr存储敏感数据时的可逆加密很少具有实用，真实的安全值。如果您正在尝试勾选合规性复选框，并且您没有权力推翻需要您勾选该框的链上的某个人，那么无论如何都要实施“加密”＃34;数据。但是，如果您真的想要保护您的系统，请查看其他地方：这里是龙。
答案 2 :(得分：0)
您可以查看Vault project，一个管理机密的工具：
一般秘密存储
最低限度，Vault可用于存储任何机密。 例如，Vault将是存储敏感的绝佳方式 环境变量，数据库凭证，API密钥等。
将此与当前存储这些可能的方式进行比较 文件中的明文，配置管理，数据库等 使用Vault读取或API查询这些内容会更安全。这个 保护这些秘密的明文版本以及记录 在Vault审核日志中访问。
员工凭证存储
虽然这与“一般秘密存储”重叠，但Vault很不错 用于存储员工共享以访问Web的凭证的机制 服务。审计日志机制可以让您知道什么是秘密 员工访问，当员工离开时，更容易滚动 密钥并了解哪些密钥已经滚动但尚未滚动。
Vault服务器以加密形式存储数据。可以通过命令行或REST API检索数据。服务器必须在unsealed state中才能返回解密数据 - 解封时需要特定数量的主密钥分片。重新启动服务器后，您需要再次启动它。