是否可以在不在配置文件（或任何其他标准可读位置）中提供用户名/密码信息的情况下设置与Oracle的JDBC连接？
通常，应用程序具有包含用于连接到数据库的设置参数的配置文件。有些DBA在配置文件中以明文形式显示用户名和密码这一事实存在问题。
我不认为Oracle和JDBC可以做到这一点，但我需要一些确认......
可能的折衷方案是在配置文件中加密密码并在设置连接之前对其进行解密。当然，解密密钥不应该在同一个配置文件中。这只会解决未经授权的用户意外打开配置文件的问题。
答案 0 :(得分：6)
您可能希望尝试Kerberos，它可以使用操作系统用户的凭据，并将操作系统用户添加到外部标识的数据库中。确保使用Kerberos，而不是使用旧方法，这有严重的安全问题。
对于Kerberos支持，您需要高级安全选项和最新的JDBC驱动程序，可能是11g版本。在尝试使用Java工作之前，请在Sql * Plus中使用'/'作为用户名和空密码进行试用。 “从双重选择用户”应该给你用户@域。您还可能会发现在使用精简或OCI驱动程序时，Kerberos配置之间存在根本区别。
答案 1 :(得分：5)
您绝对不希望能够在没有凭据的情况下连接到数据库，因为这会使数据库容易受到攻击。
这是一个普遍问题，如何存储访问外部系统所需的凭据？ WebLogic有一个凭据映射器来解决此问题，其中凭据（加密）存储在嵌入式LDAP中。许多Oracle产品使用凭证存储工具在Oracle钱包中存储凭据。
在问题中，您提供了答案。存储密码加密并在需要时解密。显然你必须使用对称加密算法，如3DES，这样你就可以解密它。确保对称密钥不是可以猜到的东西。
诀窍在于保留en / de-cryption所需的对称密钥。您可以将其放在通过操作系统保护的文件中，也可以将其保存在代码中，但是您需要保护代码的安全。如果您使用将生成相同密钥的技术并且算法相当安全，您也可以生成密钥。
如果您可以保持代码安全，您显然也可以在代码中保留密码。但是，您希望能够灵活地更改凭据而无需更改代码。
您也可以为此解决方案添加更多图层。您可以加密配置文件（使用不同的密钥）以及其中的密码，使黑客发现2个密钥。使用PKI还有其他更安全的方法，但它们很难设置。
答案 2 :(得分：3)
我建议您研究代理身份验证。这在Oracle® Database Security Guide以及Oracle® Database JDBC Developer's Guide and Reference中有记录。基本上，这允许您做的是让数据库中的用户只具有连接权限。用户真实数据库帐户配置为能够作为代理用户进行连接。您的应用程序通过JDBC连接然后存储代理用户名和密码，并在连接提供这些凭据时，在连接字符串中加上真实数据库用户的用户名。 Oracle以代理用户身份连接，然后模仿真实数据库用户，继承真实用户的数据库权限。
答案 3 :(得分：2)
所有J2EE个容器（ JBOSS ， Tomcat ， BEA ）都有连接池。他们将打开一些连接，让它们保持活着，并在1/100 th 从头开始创建一个连接时将它们交给你。
此外，它们还具有很酷的功能，例如，在JBOSS中，所有连接信息都存储在外部文件中。如果您更改连接信息，即从测试切换到生产数据库，您的应用程序将动态地从新池中提供连接
好消息是，您不需要运行完整的J2EE容器来使用连接池。外部资源允许密码以明文或伪加密的形式存储。
有关使用Tomcat的内置连接池的指南，请参阅apache commons-dbcp：
答案 4 :(得分：1)
由于我对您的环境并不完全清楚，除了Java＆amp; JDBC与Oracle交谈我会对此发表意见。
如果您正在谈论Java EE应用程序，您应该能够在应用程序服务器上设置连接池和数据源，然后您的应用程序将与处理该级别连接的连接池进行通信。
连接池和数据源保存并保护凭据。
答案 5 :(得分：1)
据我所知，jdbc连接用户名/密码需要以纯文本形式存储。限制可能的风险的一种方法是限制用户的权限，以便只能使用给定的应用程序数据库，并且只能使用预定义的主机。 IMO，这会极大地限制攻击者：他只能使用原始应用程序所在的同一主机中的un / pw，而只能攻击原始应用程序的数据库。
答案 6 :(得分：1)
过去曾想过这个。
解决方案当然包括在服务器和网络级别具有适当的网络安全性，以真正减少可以访问系统的人数，并且使数据库凭据仅允许访问裸设备的数据库帐户应用程序运行所需的最小权限。
加密属性文件可能足以阻止“无法找到密钥或密码短语”以让攻击者进入下一个受感染的服务器。我不会依赖“我的邻居不那么安全，所以从他那里偷走”然而安全！
答案 7 :(得分：1)
有两种关键方法，它们都对系统的设计产生了重大影响，因此在没有重大改写的情况下从一个移动到另一个并不容易。在选择之前，您需要了解公司的安全治理策略。
1）每个用户都拥有通过应用程序携带的凭据，用于应用程序正在使用的服务;在您的情况下，Oracle数据库使用这些用户凭据连接到数据库。缺点是每个用户都需要每个安全服务的凭据。这是一种合理的安全方法，但也需要大量的额外工作来提供和维护用户凭据。您的数据库管理员需要主动管理用户凭据，这可能与您公司的安全治理策略背道而驰。
2）应用程序数据库凭证存储在安全目录服务上，例如，安全的LDAP。应用程序使用用户的凭据访问目录服务。目录服务返回正在访问的服务的适当凭据。
在这两种情况下，都应限制数据库凭据以仅执行适当的操作。凭证应该反映业务流程的要求，例如;它们允许从定义的视图/表中选择，插入到其他视图/表中，但不允许创建，更新或删除表。在第二种方法中，为每个主要业务流程使用单独的凭证，例如，订单处理，会计，人力资源等
但请记住，安全性就像是洋葱层，如果有人剥离了层来访问应用程序，那么他们就可以访问数据库竞争池配置文件。他们可能会将应用程序特洛伊木马程序捕获用户的凭据。这是一个良好的安全治理政策的来源。
安全治理是一个复杂的问题，需要高级管理层的承诺，因为如果您的实时平台需要这种级别的安全性，则需要付出代价。您需要将开发职责与部署，运营和职责分开。用户权限管理。您可能还需要拥有安全审核员，他们具有查看更改的完全访问权限，但无法更改配置。它远非简单而且是高薪专业。
答案 8 :(得分：0)
您可以将凭据存储在任何位置，包括作为程序中的硬连线字符串或Windows注册表中的条目。如果你使用非标准的东西，你可以自己检索它们;我不知道任何非明文的预卷解决方案。
答案 9 :(得分：0)
您可以尝试使用Oracle的代理身份验证，其中JDBC客户端使用证书来对照数据库服务器信任的已知中间层组件/服务（代理）进行身份验证。我从来没有尝试过，所以我不知道这是否容易。
答案 10 :(得分：0)
除了已经提到的解决方案（Kerberos身份验证，使用代理身份验证）之外，还有其他两个解决方案都可以使用JDBC瘦驱动程序：