我有一个 cronned Perl 脚本,它连接到我们的数据库并进行各种查找和完整性检查。原剧本是很久以前的人写的。我的工作是对其进行一些更改。但我真的不喜欢盯着username="foo", password="bar"
那里硬编码的参数来访问数据库。
必须有一种更安全的方法来做到这一点。我现在能想到的就是注释掉 cron 作业,删除脚本中包含密码的行,然后开始集思广益,讨论如何使这更安全。但与此同时,脚本所做的事情必须手工完成。
有任何想法吗?
我有一个 cronned Perl 脚本,它连接到我们的数据库并进行各种查找和完整性检查。原剧本是很久以前的人写的。我的工作是对其进行一些更改。但我真的不喜欢盯着username="foo", password="bar"
那里硬编码的参数来访问数据库。
必须有一种更安全的方法来做到这一点。我现在能想到的就是注释掉 cron 作业,删除脚本中包含密码的行,然后开始集思广益,讨论如何使这更安全。但与此同时,脚本所做的事情必须手工完成。
有任何想法吗?
标准方法是将凭据放入配置文件中,并尝试保护配置文件不比 perl 文件更具可读性。这会适度提高安全性;例如,代码可能在源代码控制中并且可供开发人员访问,而配置文件则不会。代码需要在 web 服务器的 cgi 根目录中,并且可能在某些错误配置下可以下载,而配置文件不需要。
雄心勃勃的方法是可逆地加密凭据并将它们放入配置文件中。当然,任何可逆加密的东西都可以被解密。BladeLogic 应用程序做到了这一点,对我来说,反编译他们的 Java 以找出解密凭证的函数并使用它来解密它们让我满意,这对我来说是微不足道的(不到 1 天)。不是针对他们的标记;这只是可逆加密游戏的名称。
另一种选择是使用基于操作系统的授权和严格限制的数据库限制。例如,限制数据库客户端用户对一组存储过程的访问,以限制滥用的可能性,并允许该用户在没有密码的情况下访问数据库。如果您在网络上进行客户端-服务器,这将不起作用,这限制了它的使用频率。此外,人们对“无密码”操作系统用户访问的看法往往比他们在随意写下密码时更加怀疑。这并不完全合乎逻辑,但有标准规定所有数据库用户都必须有密码,就是这样。
我经常将密码传递给环境变量中的脚本,这样脚本就不需要访问包含密码的安全位置。
PASSWORD=`cat passwd_file` perl_script.pl
然后脚本读取密码
my $password = $ENV{'PASSWORD'}
如果 perl 脚本放弃特权,则加分
正如其他人已经说过的,将凭据放在脚本将加载的单独文件中。在脚本中包含密码的风险包括它被暴露在肩上冲浪,它被提交到版本控制系统或配置管理系统中并且远远超出其应有的分布,在重用部分代码时意外复制到另一个位置等。
凭据文件应具有必要的最低权限。它可能不应该被配置管理系统包含或区别对待。
如果可用,请考虑使用操作系统功能来限制对凭据文件的访问而不是权限。例如,Linux 下的 AppArmor 或 SELinux 可以将凭证文件的访问权限限制为需要它的一个脚本。这只能防止无法控制合法脚本的攻击者,因此请确保运行它的用户不拥有合法脚本(这是一般建议:不要拥有运行它们的用户拥有的可执行程序)。
共识似乎是:
但我正在考虑在这些之上添加第三个控件:基于时间的(临时)访问控制在这里也可能有所帮助。限制低权限用户可以使用明文密码的时间量会在密码和任何本地攻击者之间增加另一个(尽管很小)访问控制层。
我的想法是让 root 拥有密码文件,设置为模式 0400。然后有一个根 cronjob,它在运行脚本的低权限 cronjob 之前对密码文件执行chmod 0404 。稍后在指定的时间间隔(希望在脚本运行完成之后),第二个根 cronjob 对密码文件执行 chmod 0400。这一切都假设脚本只需要密码一段时间,而不是总是。你对这个方案的想法?