是否可以在不向配置文件(或者任何其他标准可读位置)提供用户名/密码信息的情况下，建立与Oracle的JDBC连接？

通常，应用程序具有一个配置文件，该文件包含用于连接数据库的设置参数。一些DBA的问题在于，用户名和密码在配置文件中为明文形式。

我认为这在Oracle和JDBC中是不可能的，但是我需要一些确认...

可能的折衷办法是在设置连接之前对配置文件中的密码进行加密并对其进行解密。当然，解密密钥不应位于同一配置文件中。这只会解决未经授权的用户意外打开配置文件的问题。

解决方案

我们可以将凭据存储在任何位置，包括作为程序中的固定字符串或者Windows注册表中的条目。但是，如果我们使用非标准的东西，则取决于我们来检索它们；我不知道有没有明文形式的预发布解决方案。

由于除了Java和JDBC与Oracle对话之外，我对环境还不太清楚，因此我将对此进行说明。

如果我们正在谈论Java EE应用程序，则应该能够在应用程序服务器上设置连接池和数据源，然后应用程序将与在该级别处理连接性的连接池进行对话。

连接池和数据源保存并保护凭据。

据我所知jdbc连接用户名/密码需要存储为纯文本。限制其潜在风险的一种方法是限制用户的权限，以便只能使用给定的应用程序数据库，并且只能使用预定义的主机。 IMO，这将极大地限制攻击者：他只能使用原始应用程序所在主机上的un / pw，并且只能攻击原始应用程序的数据库。

过去一直对此感到疑惑。

该解决方案肯定是这样一种解决方案，其中包括在服务器和网络级别上具有适当的网络安全性，以真正减少可以访问系统的人员的数量，并使数据库凭据仅以最小的权限就可以访问数据库帐户该应用程序运行所必需的。

属性文件的加密可能足以阻止"攻击者找到密钥或者密码短语"，从而使攻击者进入其下一个受到破坏的服务器。我不会依靠"我的邻居安全性较差，所以请从他那里窃取"安全性！

我们可以尝试Oracle的代理身份验证，其中JDBC客户端使用证书针对数据库服务器信任的已知中间层组件/服务(代理)进行身份验证。我从来没有尝试过，所以我不知道这样做是否容易。

我们绝对不希望在没有凭据的情况下连接到数据库，因为这会使数据库容易受到攻击。

这是一个普遍的问题，如何存储访问外部系统所需的凭据？ WebLogic有一个凭据映射器可以解决此问题，其中凭据(已加密)存储在嵌入式LDAP中。许多Oracle产品使用凭证存储功能，该功能将凭证存储在Oracle钱包中。

在问题中，我们提供了答案。存储加密的密码，并在需要时解密。显然，我们必须使用对称加密算法(例如3DES)才能对其进行解密。确保对称密钥不是可以猜测的东西。

诀窍是在其中保留加密/解密所需的对称密钥。我们可以将其放入通过操作系统保护的文件中，也可以将其保存在代码中，但随后需要确保代码的安全。如果我们使用的技术可以产生相同的密钥，并且算法相当安全，那么我们也可以生成密钥。

如果可以确保代码安全，那么显然也可以在代码中保留密码。但是，我们需要能够在不更改代码的情况下更改凭据的灵活性。

我们也可以在此解决方案中添加更多层。我们可以加密配置文件(使用其他密钥)以及其中的密码，使黑客发现2个密钥。还有其他使用PKI的更安全的方法，但是它们很难设置。

有两种关键方法，它们都对系统的设计产生重大影响，因此，不进行大量重写就很难从一种方法迁移到另一种方法。在选择之前，我们需要了解公司安全管理策略是什么。

1)每个用户都有通过应用程序携带的，由应用程序使用的服务的凭据；在情况下，Oracle数据库使用这些用户凭据连接到数据库。缺点是每个用户都需要每个安全服务的凭据。这是一种合理的安全方法，但是还需要重要的额外工作来提供和维护用户凭据。数据库管理员将需要主动管理用户凭据，这可能与我们公司的安全管理策略背道而驰。

2)应用程序数据库凭证存储在安全目录服务中，例如安全的LDAP。应用程序使用用户凭据访问目录服务。目录服务返回正在访问的服务的适当凭据。

在这两种情况下，都应将数据库凭据限制为仅执行适当的操作。凭证应反映业务流程的要求，例如；它们允许从已定义的视图/表中选择，插入其他视图/表中，但不能创建，更新或者删除表。在第二种方法中，为每个主要业务流程使用单独的凭据，例如订单处理，会计，人力资源等

但是请记住，如果有人剥离了访问应用程序的层，以便他们可以访问数据库保护池配置文件，则安全性就像洋葱的层一样。他们可能可以对应用程序进行特洛伊木马捕获用户凭据。这是一个好的安全管理策略的来源。

安全治理是一个复杂的问题，需要高级管理人员做出承诺，因为如果实时平台需要这种级别的安全性，则需要付出一定的代价。我们需要将开发职责与部署，运营和用户权限管理区分开来。我们可能还需要有安全审核员，他们可以完全查看更改，但无权更改配置。它远非简单，而且是高薪专业。

我建议我们研究代理身份验证。这是在Oracle中记录的吗？数据库安全指南以及Oracle？数据库JDBC开发人员指南和参考。本质上，这允许我们执行的操作是在数据库中拥有一个仅具有连接特权的用户。用户的实际数据库帐户配置为能够作为代理用户连接。然后，通过JDBC连接的应用程序将存储代理用户名和密码，并且在连接时提供这些凭据，并在连接字符串中加上真实数据库用户的用户名。 Oracle以代理用户身份连接，然后模仿真实数据库用户，从而继承真实用户的数据库特权。

我们可能需要尝试使用Kerberos，它可以使用OS用户的凭据并将OS用户添加到外部标识的数据库中。确保我们使用的是Kerberos，而不是旧的方法，因为它存在严重的安全问题。

为了获得Kerberos支持，我们需要高级安全性选项和最新的JDBC驱动程序(可能是11g版本)。在尝试使其在Java中工作之前，请在Sql * Plus中使用" /"作为用户名和空密码进行尝试。 "从双重选择用户"应为我们提供user @ domain。我们可能还会发现，在配置Kerberos时，使用精简驱动程序或者OCI驱动程序有根本的区别。

所有的" J2EE"容器(JBOSS，Tomcat，BEA)都有连接池。他们将打开许多连接，使它们保持活动状态，并在从头开始创建连接的第1/100个时间中将它们提供给我们。

此外，它们还具有很酷的功能，例如，在" JBOSS"中，所有连接信息都存储在一个外部文件中。如果更改连接信息，即从测试数据库切换到生产数据库，则将动态向应用程序提供来自新池的连接

好消息是，我们不必仅使用连接池就运行完整的J2EE容器。外部资源允许以明文或者伪加密的形式存储密码。

有关使用Tomcat的内置连接池的指南，请参见apache commons-dbcp：

• http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html