2008-08-14 94 views
8

因此,我们的Web服务器应用程序需要连接到数据库,并且其他一些应用程序具有在启动时执行的启动脚本。在启动脚本/配置文件中存储数据库密码的最佳方式是什么?

什么是存储的名称的最佳方式/密码为这些应用中,

  • 的安全性,例如方面或许我们不希望系统管理员知道数据库密码
  • 可维护性,例如,使密码更改时易于更改配置等。

Windows和Linux解决方案都很赞赏!

回答

1

纯文本?如果他们在你的服务器上,我希望服务器足够安全,不允许未经授权的访问。如果人们可以在服务器上访问你的配置文件,那么早就出现了问题。

+0

遵循这一策略会导致错失深度构建防御的机会。 – 2010-05-25 09:34:07

1

澄清:在安全性,可维护性(例如,如果登录需要改变,可我后来发现它,等)方面

@lomax:也许我可能不希望每个人都可以访问到物理服务器(例如系统管理员)查看密码。

谢谢!

0

您可以在您的二进制文件中烘焙对称加密密钥,并在启动时让该二进制文件从磁盘上的文件读取加密的用户名/密码。

但是,这并不比混淆更多,因为您的代码可能存储在某个源代码仓库中。

我会建议你更好地控制使用防火墙和专用网络泡泡在物理和网络上访问您的服务器,并将密码以明文(或base-64编码)存储在磁盘上将权限锁定到您的Web应用程序的运行用户。

您也可以锁定数据库服务器,只接受来自您的Web应用程序机器的IP连接。

最终,您的问题是您的数据库密码(您的数据库用户名/密码对)需要通过Web应用程序进行编程式无人值守使用。

3

我同意lomaxx:如果有人已经在服务器上或有广泛的访问权限(如系统管理员),游戏已经结束了。所以这个想法是使用一个你信任的服务器,它对你想要的程度是安全的。具体做法是:

  • 你需要信任的系统管理员
  • 你需要相信别人谁在运行代码在同一服务器上(这就是为什么共享主机是一大禁忌对我来说)

除此之外,环境变量似乎是为存储这些类型的凭据一个流行的选择,因为这意味着访问源只(例如,通过牺牲开发框)不直接揭示它,也可以是很好本地化为每个服务器(开发,测试等)。

+0

可以想象,Web服务器中的一个缺陷可能允许攻击者使服务器提供一个配置文件,但仍然不允许完全访问服务器。出于这个原因,并且因为建立纵深防御通常是一个好主意,您不应该将敏感数据存储在非加密状态。 – 2010-05-25 09:36:20

1

在大多数情况下,我认为在纯文本文件中混淆密码就足够了(例如,与base64)。您无法完全保护已存储的密码,使其无法通过root用户访问确定的系统管理员,因此完全没有必要尝试。然而,简单的混淆可以防止意外地向肩上冲浪者透露密码。

一个更复杂的方法是设置了,要么一个专门的安全密码服务器:

  • 提供了密码解密服务
  • 实际上是由其他较安全的服务器上存储的使用密码

根据所使用的网络协议,这可能无法防止使用tcpdump的恶意系统管理员。而且它也可能无法通过调试器保护确定的系统管理员。那时候,可能是时候看看Kerberos票了。

5

PostgreSQL在文档中为这种情况提供了一个nice solution。本质上,您使用ssh将计算机上的端口连接到远程计算机上的PostgreSQL服务器端口。这有三个验证阶段:

  1. 限制对本地端口的访问,例如只允许特定用户连接到本地端口。
  2. 使用ssh作为特定用户设置PostgreSQL主机的无密码连接。
  3. 允许用户ssh连接作为无本地密码的PostgreSQL访问。

这会降低安全性,以确定您的用户帐户是否安全,您的ssh配置是否正常,并且您不需要任何密码。

编辑:我应该补充说,这将适用于侦听TCP/IP端口的任何数据库。它恰好在PostgreSQL中描述。你会希望iptables(或者相当于Linux)来执行端口限制。见this

相关问题