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