28

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

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

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

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

4

11 回答 11

6

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

对于 Kerberos 支持，您需要高级安全选项和最新的 JDBC 驱动程序，可能是 11g 版本。在尝试让它在 Java 中工作之前，请在 Sql*Plus 中使用“/”作为用户名和空密码进行尝试。“从双重选择用户”应该给你用户@域。您可能还会发现，在 Kerberos 配置方面，使用瘦驱动程序或 OCI 驱动程序之间存在根本区别。

于 2008-09-27T10:42:38.477 回答
5

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

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

在问题中，您提供了答案。存储密码加密并在需要时解密。显然，您必须使用对称加密算法（例如 3DES）才能解密它。确保对称密钥不是可以猜到的。

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

如果您可以确保代码安全，那么您显然也可以将密码保存在代码中。但是，您希望能够在不更改代码的情况下更改凭据的灵活性。

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

于 2008-09-24T12:24:46.237 回答
3

我建议您查看代理身份验证。这在Oracle® Database Security Guide以及Oracle® Database JDBC Developer's Guide and Reference中有记录。本质上，这允许您做的是在数据库中拥有一个仅具有连接权限的用户。用户真实数据库帐户被配置为能够以代理用户身份连接。通过 JDBC 连接的应用程序然后存储代理用户名和密码，并在连接时提供这些凭据，并在连接字符串中加上真实数据库用户的用户名。Oracle 以代理用户身份连接，然后模仿真实数据库用户，继承真实用户的数据库权限。

于 2008-09-24T13:02:14.073 回答
2

所有J2EE容器（JBOSS、Tomcat、BEA）都有连接池。1/100他们将打开许多连接，使它们保持活动状态，并将在从头开始创建连接所需的时间内将它们提供给您。

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

好消息是你不需要运行一个完整的J2EE容器来使用连接池。外部资源允许密码以明文或伪加密形式存储。

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

于 2009-05-04T21:50:37.580 回答
1

由于除了与 Oracle 交谈的 Java 和 JDBC 之外，我对您的环境并不完全清楚，因此我将对此发表看法。

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

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

于 2008-09-24T12:12:27.157 回答
1

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

于 2008-09-24T12:12:58.530 回答
1

过去一直想知道这一点。

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

就“不必费心寻找密钥或密码”而言，对属性文件进行加密可能足以让攻击者进入下一个受感染的服务器。但是，我不会依赖“我的邻居不那么安全，所以请从他那里偷走”安全！

于 2008-09-24T12:13:53.533 回答
1

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

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

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

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

但是请记住，安全性就像洋葱层，如果有人剥离了这些层来访问应用程序，那么他们就可以访问数据库连接池配置文件。他们可能会特洛伊木马应用程序来捕获用户的凭据。这就是良好的安全治理策略的用武之地。

安全治理是一个复杂的问题，需要高级管理层的承诺，因为如果您需要为您的实时平台提供这种级别的安全性，则需要付出代价。您需要将开发职责与部署、操作和用户权限管理分开。您可能还需要有安全审计员，他们拥有查看更改的完全访问权限，但无法更改配置。它远非简单，而且是高薪的专业。

于 2008-09-24T12:39:43.237 回答
0

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

于 2008-09-24T12:18:11.590 回答
0

您可以将凭据存储在任何地方，包括作为程序中的硬连线字符串或作为 Windows 注册表中的条目。但是，如果您使用非标准的东西，则由您来检索它们；我不知道有任何非纯文本的预卷解决方案。

于 2008-09-24T12:09:17.413 回答
0

除了已经提到的解决方案（Kerberos 身份验证，使用代理身份验证）之外，还有 2 个其他解决方案都可以与 JDBC 瘦驱动程序一起使用：

  1. 将密码存储在 SSO 钱包中：可以使用钱包来存储用户的密码。如果您使用 SSO 钱包，则钱包本身没有密码。SSO 钱包通常用于 SSL 的上下文中，但它们也可用于仅存储密码。
  2. 将 SSL 与用户身份验证一起使用：使用通过专有名称 (DN) 进行外部身份验证的用户配置 SSL。此用户没有密码。只要您使用具有此 DN 的证书连接 SSL，您就可以使用此用户创建会话。
于 2017-04-25T18:27:22.293 回答