如何避免存储使用JDBC连接到Oracle的凭据？

是否可以设置到Oracle的JDBC连接，而不在配置文件（或任何其他标准可读位置）中提供用户名/密码信息

通常，应用程序有一个配置文件，其中包含连接到数据库的设置参数。一些DBA在配置文件中的用户名和密码是明文的这一事实上存在问题

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

---

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

您可以将凭据存储在任何位置，包括作为程序中的硬连线字符串或Windows注册表中的条目。但是，如果你使用了一些非标准的东西，就由你自己来取回它们；我不知道有哪种预推出的解决方案不是纯文本的。

因为除了Java和JDBC与Oracle对话之外，我对您的环境不太清楚，所以我将对此进行讨论

如果您谈论的是Java EE应用程序，那么您应该能够在应用程序服务器上设置连接池和数据源，然后您的应用程序与处理该级别连接的连接池进行对话

---

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

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

过去曾对此感到奇怪

解决方案当然包括在服务器和网络级别提供适当的网络安全性，以真正减少可以访问系统的人数，并且数据库凭据只提供对数据库帐户的访问，而该数据库帐户的访问权限仅为应用程序运行所需的最低权限

---

对属性文件进行加密可能足以起到威慑作用，因为“不必费心寻找密钥或密码短语”，攻击者可以进入下一个受损的服务器。然而，我不会依赖“我的邻居不太安全，所以请从他那里偷东西”的安全

您可以尝试Oracle的代理身份验证，其中JDBC客户端使用证书对数据库服务器信任的已知中间层组件/服务（代理）进行身份验证。但我从未尝试过，因此我不知道这是否容易做到。

您肯定不希望在没有凭据的情况下连接到数据库，因为这会使数据库易受攻击

这是一个常见问题，如何存储访问外部系统所需的凭据？WebLogic有一个凭证映射器来解决这个问题，其中凭证（加密）存储在嵌入式LDAP中。许多Oracle产品使用凭证存储设施将凭证存储在Oracle wallet中

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

诀窍在于保留加密/解密所需的对称密钥。你可以把它放在一个通过操作系统保护的文件中，也可以把它保存在代码中，但是你需要保证代码的安全。如果您使用的技术将生成相同的密钥，并且算法相当安全，那么您也可以生成密钥

如果你能保证代码的安全，那么显然你也能在代码中保留密码。但是，您希望能够在不更改代码的情况下灵活地更改凭据

---

您还可以向该解决方案添加更多层。您可以加密配置文件（使用不同的密钥）以及其中的密码，使黑客发现2个密钥。还有其他使用PKI的更安全的方法，但它们很难设置。

有两种关键方法，它们都对系统的设计有重大影响，因此不进行重大重写就不容易从一种方法移动到另一种方法。在选择之前，您需要了解公司的安全治理策略

1） 每个用户都有应用程序正在使用的服务的凭据，这些凭据通过应用程序进行传输；在您的情况下，Oracle数据库使用这些用户凭据连接到数据库。缺点是每个用户都需要每个安全服务的凭据。这是一种合理的安全方法，但也需要大量额外工作来提供和维护用户凭据。您的数据库管理员需要主动管理用户凭据，这可能与您公司的安全治理策略背道而驰

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

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

但是请记住