我想知道您使用什么技术来存储应用程序的数据库凭据。我特别关心java webapps,但我认为没有必要将问题限制在这个范围内。
需要考虑的事情:
您是否使用属性文件、xml 配置等?
它是捆绑到您的应用程序中(即在 jar 文件中)还是单独存储在某个文件系统中?
密码是否加密?如果是这样,您使用什么加密方案?
我想知道您使用什么技术来存储应用程序的数据库凭据。我特别关心java webapps,但我认为没有必要将问题限制在这个范围内。
需要考虑的事情:
您是否使用属性文件、xml 配置等?
它是捆绑到您的应用程序中(即在 jar 文件中)还是单独存储在某个文件系统中?
密码是否加密?如果是这样,您使用什么加密方案?
由于您将问题留给平台,我将添加 .NET 应用程序的数据库凭据存储在 web.config 文件中。从 2.0 及更高版本开始,有一个特定的 ConnectionStrings 部分允许更轻松地以编程方式访问连接字符串。
除了默认情况下 IIS 自动阻止对 web.config 文件的直接请求之外,您还可以使用 IIS 命令来加密 web.config 文件的 ConnectionString 部分。这种加密是特定于机器的,增加了它的优势,当你访问它时,.NET 运行时也会动态解密连接字符串,所以你的应用程序不需要额外的编码来使用它。
使用 Java,数据库连接池应该由容器传递到 webapps。这是在 WEB-INF/web.xml 中可声明为资源的标准。这同样适用于邮件会话和其他可能因安装而异的外部资源。查找 JNDI 以获取更多信息)
这样做的好处是应用程序并不关心如何实际连接到外部的任何东西。它不会看到任何密码,因为容器本身会使用它们。
在 tomcat 中,这可以从 conf/Catalina/localhost/ 、 conf/server.xml 中的上下文文件(例如)配置,或者 - 最好仅用于开发环境,从 webapps META-INF/context.xml 配置。其他环境有自己的配置位置或应用程序。
密码的加密实际上取决于容器。Tomcat 以明文形式存储它们,但应用程序本身不会看到它。我不知道其他环境中的机制。
在 Microsoft 堆栈上,事情可能非常好。
您在 Active Directory 中创建一个几乎没有权限的网络用户帐户。您将 IIS 配置为以该用户身份运行您的 webapp。您授予该用户对磁盘上的 Web 文件夹和文件的读取权限。您将 SQL Server 配置为授予该用户对所需表的读/写权限。在连接字符串中,您指示 db 客户端以当前运行 webapp 的用户帐户进行连接。
只有一个实际的用户帐户,尽管它在多个地方都可见。此用户帐户的权限极其有限。即使加密,也不会在任何地方存储密码。无需在代码中进行任何配置即可使其正常工作(这一切都在设置权限中)。
取决于应用服务器。
我通常使用 JNDI 查找数据源,因此凭据存储在处理连接池的应用服务器上。除了 JNDI 名称之外,无需以这种方式在配置中添加任何内容。
是的,密码在 WebLogic 上已加密。
在 Tomcat 上,事情可能很冒险。连接信息在 META-INF/context.xml 中,表示密码的纯文本。我这样做只是为了开发,从不在生产中。
在 Django 中,凭据在您的settings.py
配置文件中。由于这通常不会保存在您的/var/www/
目录树中,因此非常安全。
此外,单个 Django 应用程序可以用于(和重用)同一主机上的许多网站或 Web 服务器,每个网站或 Web 服务器都有自己不同的设置。因此settings.py
配置不与应用程序捆绑在一起,而是应用程序的单个部署的一部分。
对于 asp.net:
我将全局参数(例如连接字符串和存储库路径)存储在注册表中,然后在 web.config 中存储对注册表条目的引用。
主要原因是我经常发现我必须编写一个独立的可执行文件来运行需要访问相同参数的后台任务和其他自动化功能。因此,将真正全球化的所有东西都放在一个易于访问的地方可以让生活更轻松。
其中哪些是保存 Web 应用程序数据库凭据的好地方?在源代码的单独文件中 在 Web 服务器主机上的单独文件中 在数据库中 无。永远不应存储数据库凭据
如前所述,没有指定平台,并使用早期答案中的一些想法:
我正在考虑一个容器化的应用程序。您可以将数据库的密码存储在容器中的文件中。您的应用程序的第一步是建立数据库连接,甚至在侦听 Web 请求之前。数据库连接成功后,带有凭据的文件将被删除,包含这些凭据的变量也将被删除。因此,当您开始为请求提供服务时,唯一剩下的就是从此刻开始使用的开放数据库句柄。如果由于任何原因数据库连接丢失,您只需退出并等待重新启动容器,凭证文件将再次出现。