Database 如何在数据库中存储安全凭据

我正在开发一个类似CMDB的应用程序，在那里我必须存储我们的安全凭据（服务器用户名和密码等）

我正在寻找最好的方法来安全地存储这些约束：

• 大多数用户将无法访问所有凭据（取决于用户角色）
• 我们不希望所有密码都使用相同的密钥加密（已经尝试过：当用户离开公司时，更改密钥会很痛苦…）
• 事实上，我们不希望任何私钥硬写在应用程序源中，甚至存储在任何地方（在我们以前的版本中，私钥存储在我们的耳朵之间…）
• 我们需要实现密码强度审计（即从脚本解析解密的密码）
• 在任何情况下，我们都不能再访问我们的凭据（丢失的密钥，…）=>我们不希望未经授权的人员查看凭据，但我们也不希望丢失凭据=>此约束的解决方案可以定期导出到物理锁柜中

我不是问应用程序（https…）或数据库（无公共访问…）本身的安全问题，而是只问存储端（甚至可能不在数据库中…？加密文件或其他东西…）：是否可能阻止某人访问应用程序代码或数据库内容（最坏情况），能够读取解密的凭据吗

---

我知道我在寻求一些神奇的解决方案，但我想知道它是否存在；o）

你要求做的事情的一般情况是不可能的。所有类型的现代密码学都是安全的。也就是说，他们用一个小秘密来保守一个大秘密。如果你不能保守这个小秘密，就没有安全可言。如果你想在一个密码一个密码的基础上给某人提供密码，你实际上是在给他们一个秘密——密码——这是他们访问相关项目所需要的

---

这正是联邦身份系统（Kerberos/Active Directory等）存在的原因——允许中央计算机对用户进行身份验证，而不向所述用户泄露机密。但是使用联合身份系统需要登录到的系统和身份服务之间的合作。

如果您的系统整体上存在明显的安全缺陷，则凭证管理系统毫无价值。很简单：用户使用自己的密码登录，并根据ACL获得访问权。@tc。当然他们会（使用LDAP auth），但正如我所说的，我不要求应用程序端的安全性，而是要求存储端的安全性。@Rook我完全不同意，但对更高级别的信任并不是一种安全最佳实践……每个服务都应该使用您的身份验证/授权服务器来决定用户是否有访问权限。如果你的意思是存储外部服务的密码（例如，公司的twitter帐户），那么系统似乎足够复杂，人们只需将它们粘贴到文本文件中。你和链接文章中的推理非常好。当然，安全性永远不可能是全面的，但它必须是每一层中最好的（我不会将凭证存储到电子表格中，因为安全性不可能是全面的！）。让我感到欣慰的是，一个好的解决方案可能是保留“未写入”的唯一密钥原则，但只与少数人共享，需要在每次应用程序重启时设置密钥（并解决如何在线程之间共享密钥…）。密钥仅存在于线程内存中。要查看密钥，您必须更改代码，包括重新启动应用程序，包括松开密钥。@GauthierDelacroix要查看密钥，您只需附加一个调试器/转储内存。如果这太难了，你可以用一个泄露密钥的二进制文件替换它，然后假装应用程序崩溃。@tc。是的，内存可以被转储，但我不会尝试走那么远。未加密的凭据也将保存在内存中。你不能完全保护你需要展示的东西。。。即便如此，我认为从文件中提取密钥和从内存中提取密钥之间还是有差距的。。。