我们正在使用Oracle 11.2，在Solaris 10上运行用C ++编写的服务器进程。我们的支持人员拥有自己的Oracle用户名，我们的服务器进程有一个专用的Oracle用户（让我们称之为servuser）。 / p>
出于审计目的，我们需要确保只有服务器进程使用servuser帐户进行更改，但是，支持人员也可以使用servuser访问数据库，只要他们从中执行此操作。托管服务器进程的Solaris机箱。
显而易见的解决方案是使用OS身份验证 - 为进程创建Solaris用户，并将其映射到Oracle servuser。唯一的问题是：这些服务器进程在与Oracle实例不同的主机上运行。打开远程授权是一个巨大的，众所周知的安全漏洞（只需在您的操作系统上创建自己的用户 - presto）。
我能想到的所有其他策略都不好：
将密码存储在Solaris帐户的文件中是不行的，因为支持人员可以看到它们并用于通过sqlplus连接;
加密文件并不好 - 服务器进程必须能够访问私钥，然后可供支持人员使用，然后可以解密和解密。我们回到第1步。
我想过创建一个登录触发器，检查我们是否以servuser身份连接，然后在v $ session中的Module / Program值与我们识别的值不匹配时引发异常作为有效的客户。这是一种弱保护，因为有人可以编写自己的应用程序来欺骗这些价值。
处理此方案的“官方”方式是什么？如果你在托管你的实例的同一个盒子上运行你的客户端，那么操作系统身份验证只能安全地运行，这似乎没用，IMO。但我认为我们的场景非常普遍 - 应用服务器在不同的实例上运行，但您希望确保只有他们可以使用特权帐户。
建议？
答案 0 :(得分：0)
最好的选择通常是使用secure external password store。这将涉及在服务器机器上创建存储用户名和密码的钱包。您要用于连接Oracle的密码。如果您让钱包自动登录，则服务器进程无需打开钱包或查看密码，支持人员也不需要。可以配置钱包，以便自动登录仅在服务器计算机上工作，如果有人将钱包复制到另一台机器，则使钱包或多或少无用。当然，如果您想更改存储的密码，组织中的某个人需要拥有钱包的密码，但是该人员不需要成为支持人员之一。
不太理想的是登录触发器，它检查客户端的用户名和IP地址，如果连接来自Solaris机箱以外的机器，则拒绝登录（可能除了检查模块或程序之外）。这通常有效，但总有可能有人欺骗他们的IP地址。但欺骗客户端IP地址并使其看起来像网络上的应用服务器通常会导致足够的路由问题，而攻击相对难以实现。