2012-07-24 167 views
1

我正在开发CMDB应用程序,我必须存储我们的安全证书(服务器用户名&密码,...)。如何将安全凭证存储在数据库中

我正在寻找最好的方式将它们安全地与这些约束存储:

  • 大多数用户将无法访问到所有凭证(取决于用户角色)
  • 我们不希望所有密码使用相同的密钥进行加密(已经尝试过:当用户离开公司时,改变密钥是一种痛苦......)
  • 事实上,我们不希望任何私钥被硬编写在应用程序源代码中,或者甚至存储在任何地方(在我们以前的版本中,私钥存储在我们的耳朵之间......)
  • 我们需要实现密码强度审计(即。从脚本中解析解密的密码)
  • 不能有任何情况,我们不能再访问我们的凭证(丢失密钥,...)=>我们不希望未经授权的人看他们,但我们不想要将它们松开=>解决此约束可能会正常导出到物理更衣室...

我不是在询问应用程序(https,...)或数据库(没有公共访问权限,。 ..)安全关心他们自己,但只涉及存储方面(甚至可能不在数据库中......?加密文件或其他...):是否有可能阻止某人,甚至可以访问应用程序代码或数据库内容(最坏的情况),能够读取解密的凭据?

我知道,我问了一些神奇的解决方案,但我想知道,如果它的存在; O)

+1

如果您的系统整体存在明显的安全漏洞,则凭证管理系统毫无价值。 – rook 2012-07-24 17:45:44

+1

简单:用户使用*自己的*密码登录并根据ACL获取访问权限。 – 2012-07-24 18:30:53

+0

@tc。当然,他们会(使用LDAP认证),但正如我所说的,我不要求应用程序方面的安全性,但存储方面。 – 2012-07-24 19:35:15

回答

2

你问做什么的一般情况下是不可能的。所有类型的现代密码学都是mechanical advantage。也就是说,他们用一个小秘密来保护更大的秘密。如果你不能保证小秘密的安全,那就没有安全感。如果您希望能够以密码为基础向某人提供密码的密码,则您实际上会向他们提供他们需要访问相关物品的秘密 - 密码。

这就是联合身份系统(Kerberos/Active Directory/etc)系统存在的原因 - 允许中央机器在不向所述用户泄露秘密的情况下对用户进行身份验证。但是使用联合身份系统需要待登录系统与身份服务之间的合作。

+0

非常好的推理来自你和链接的文章。当然,安全永远不可能是完全的,但它必须是每一层中最好的(我不会将证书存储到电子表格中,因为安全性不可能是完全的!)。这让我感到很舒服,我认为一个好的解决方案可以保持'不成文'的独特关键原则,但只与少数人共享,需要在每次应用程序重新启动时设置关键(并解决如何在线程之间共享密钥......) 。密钥仅存在于线程内存中。要查看密钥,您必须更改代码,涉及应用程序重新启动,涉及丢失密钥。 – 2012-07-25 07:51:41

+0

@GauthierDelacroix为了看看关键,你只需要附加一个调试器/转储内存。如果这太难了,你可以用泄露密钥并假装应用程序崩溃的二进制代码来替换。 – 2012-07-25 12:08:46

+0

@tc。是的,记忆可以被抛弃,但我不会去那么远。未加密的凭证也将驻留在内存中。你不能完全保护你需要显示的东西......即便如此,我认为从文件和内存中提取密钥之间存在差距...... – 2012-07-25 12:23:03

相关问题