0

我们使用 Oracle 11.2，在 Solaris 10 上运行用 C++ 编写的服务器进程。我们的支持人员有自己的 Oracle 用户名，并且我们的服务器进程有一个专用的 Oracle 用户（我们称之为 servuser）。

出于审计目的，我们需要确保只有服务器进程使用 servuser 帐户进行更改，但是，支持人员也可以使用 servuser 访问数据库，只要他们是从 Solaris 主机进行的服务器进程。

对此显而易见的解决方案是使用操作系统身份验证 - 为进程创建一个 Solaris 用户，并将其映射到 Oracle servuser。唯一的问题是：这些服务器进程运行在与 Oracle 实例不同的主机上。打开远程授权是一个巨大的、众所周知的安全漏洞（只需在您的操作系统上创建您自己的用户 - presto）。

我能想到的所有其他策略都不好：

  1. 将密码存储在 Solaris 帐户的文件中是不好的，因为支持人员可以看到它们并用于通过 sqlplus 进行连接；

  2. 加密文件并不好 - 服务器进程必须有权访问私钥，然后支持人员可以使用该私钥，然后他们可以解密并且我们回到第 1 步。

  3. 我想创建一个登录触发器，检查我们是否以 servuser 身份连接，然后如果 v$session 中的模块/程序值与我们识别为有效客户端的值不匹配，则引发异常。这是一种弱保护，因为有人可以编写自己的应用程序来欺骗这些值。

处理这种情况的“官方”方式是什么？操作系统身份验证仅在您在托管实例的同一个盒子上运行客户端时才能安全地工作，这似乎毫无用处，IMO。然而我认为我们的场景很常见 - 应用服务器在单独的实例上运行，但您要确保只有它们才能使用特权帐户。

建议？

4

1 回答 1

0

最好的选择通常是使用安全的外部密码存储。这将涉及在服务器计算机上创建一个钱包，用于存储您要用于连接到 Oracle 的用户名和密码。如果您让钱包自动让您登录，则服务器进程将不需要能够打开钱包或查看密码，支持人员也不需要。可以对钱包进行配置，以便自动登录仅在服务器机器上起作用，如果有人将钱包复制到另一台机器上，则钱包或多或少无用。当然，如果您想更改存储的密码，组织中的某个人需要拥有钱包的密码，但该人无需成为支持人员之一。

不太理想的是登录触发器，它检查客户端的用户名和 IP 地址，如果连接来自 Solaris 框以外的机器（可能除了检查模块或程序之外），则拒绝登录。这通常有效，但总有可能有人欺骗他们的 IP 地址。但是，欺骗客户端 IP 地址并使其看起来像网络上的应用程序服务器通常会导致足够多的路由问题，从而使攻击相对难以实施。

于 2012-03-16T17:50:11.280 回答