所以首先,我知道,我应该对SSH使用密钥身份验证。无需向我解释。
这里的问题是我有一堆(大)服务器,并且我需要有一个脚本来连接每个服务器。
我会尽可能使用密钥认证,但是不可能在每台服务器上都使用(我对此没有控制权)。因此,使用SSH进行登录,或者有时进行telnet。
因此,对于某些人,我只是将密码存储在数据库中,而我的脚本会在需要时使用它。问题是,这样做似乎并不安全。有没有办法使它更安全些?
喜欢一些特定的存储方式吗?
所以首先,我知道,我应该对SSH使用密钥身份验证。无需向我解释。
这里的问题是我有一堆(大)服务器,并且我需要有一个脚本来连接每个服务器。
我会尽可能使用密钥认证,但是不可能在每台服务器上都使用(我对此没有控制权)。因此,使用SSH进行登录,或者有时进行telnet。
因此,对于某些人,我只是将密码存储在数据库中,而我的脚本会在需要时使用它。问题是,这样做似乎并不安全。有没有办法使它更安全些?
喜欢一些特定的存储方式吗?
Answers:
如果您的脚本可以连接到任何这些服务器,则有权访问该脚本(或对该脚本运行所在的计算机具有特权的访问权)的任何人都可以连接到任何这些服务器。
如果脚本需要自主运行,则所有选择都将关闭。答案是否定的,在这种环境下没有绝对安全的密码存储方式。有没有绝对安全的和实际做任何事情的方式。
与其尝试避免不可避免的情况,不如将注意力集中在纵深防御上。
毫无疑问,您应该充分保护密码。这通常意味着将它们保存在与脚本分开的文件中,并配置限制性文件系统权限。从安全的角度来看,这就是您可以在此方面做的所有事情。
当然,其他措施也可能使过程变得晦涩难懂。加密密码将使攻击者需要搜索解密密钥。使用某种受操作系统保护的存储通常可以防止其他用户访问您的密钥(因此,与文件系统权限相比,它没有任何优势,除了攻击和使用很复杂之外)。这些措施将延迟攻击,但最肯定不能阻止针对坚定的攻击者的攻击。
现在,让我们暂时将密码视为公共密码。您可以采取什么措施减轻损失?
一个古老且经过测试的解决方案是限制这些凭据可以做什么。在UNIX系统上,执行此操作的一个好方法是为脚本设置一个单独的用户,并限制该用户在访问服务器和被访问服务器上的功能。您可以在SSH级别,shell级别或可能使用诸如SELinux之类的强制访问控制机制来限制用户功能。
您可能还需要考虑的是将脚本逻辑移到服务器中。这样,您将获得一个较小的界面,该界面更易于控制,尤其是...
监控器。始终监视对服务器的访问。优选地,日志认证和执行到仅附加日志的命令。例如,不要忘记使用监视脚本文件的更改auditd
。
当然,如果您无法控制服务器,那么其中许多机制就没有用,就像您的问题所暗示的那样。如果是这种情况,我建议您与管理服务器的人员联系,并让他们知道您的脚本和潜在的安全隐患。
最简洁的答案是不。
长答案是:不,没有完全安全的方法。(这包括环境变量,可以由服务器上的其他人访问。)最接近的是将它们以某种加密格式存储-keepass,GPG加密文件或类似的东西。但是在某些时候,您需要解密密码,以便脚本可以使用它,这时您将很容易受到攻击。
换句话说,您需要对运行脚本的服务器,网络和目标服务器上的深度安全性进行认真研究。
您可以使用第二个密码对数据库中的密码进行加密,然后将此密码存储在单独的(第3台)计算机上,并且具有一个系统,在该系统中,需要从db密码输入密码的脚本首先连接该第3台计算机以获取解密密码,使用从第三台计算机获得的密码解密db中的密码,并且可以正常工作。
当然,这并没有真正增加任何额外的安全性,具有足够特权的攻击者也可以只向第三台计算机请求密码。
但是关键是,第三方可以控制第三台计算机,例如您的老板或安全员,或者由第三方控制您无法控制的服务器。
这样,您可以告诉他们,如果他们遇到问题,如果您辞职并且他们不信任替换您的家伙,或者他们只是希望您的脚本停止访问其计算机,则他们可以在3号拔掉插头机器,您的脚本将不再有权访问密码。