Oracleに接続する必要のあるサーバー・プロセスを認証する安全な方法

Question

Oracle 11.2を使用しています。サーバー・プロセスはSolaris 10で動作するC++で記述されています。サポート担当者は独自のOracleユーザー名を持ち、私たちのサーバプロセスのために（それをservuserと呼ぶ）。

監査の目的で、サーバープロセスのみが変更を行うためにservuserアカウントを使用するようにする必要がありますが、サポート担当者はservuserを使用してdbにアクセスすることもできますサーバープロセスをホストするSolarisボックス。

明白な解決策は、OS認証を使用することです。プロセスのSolarisユーザーを作成し、それをOracleサービス・ユーザーにマップします。これらのサーバー・プロセスは、Oracleインスタンスとは別のホスト上で実行されます。遠隔認可を有効にすることは、巨大でよく知られたセキュリティホールです（あなた自身のOSをあなたのOS上に作成する - プレスト）。私は考えることができる

すべての他の戦略には良いではない：サポート担当者がそれらを参照してsqlplusを経由して接続するために使用できるよう、Solarisのアカウントのファイルでパスワードを保存する

1. は、無意味です。サーバプロセスはその後、サポートスタッフに利用できるようになる秘密鍵へのアクセス権を持っていなければならないだろうし、我々は戻って、ステップ1

   でいる&を解読することができ -

2. は、ファイルを暗号化しても良いことないだろう

3. 私は、servuserとして接続しているかどうかを確認するログオントリガーを作成し、v $ sessionのModule/Programの値が有効であると識別した場合に例外を発生させることを考えましたクライアント。これは弱い保護です。誰かがこれらの値を偽る独自のアプリを書く可能性があるからです。

このシナリオを処理する「公式」な方法は何ですか？ OS認証は、あなたのインスタンスをホストしているのと同じボックスでクライアントを実行している場合にのみ安全に動作しますが、むしろ役に立たないIMOと思われます。しかし私は、シナリオが非常に一般的だと思うでしょう - アプリのサーバーは別々のインスタンスで実行していますが、権限のあるアカウントしか使用できないようにしたいと考えています。

提案？

Answer 1

最も良い選択肢は、一般にsecure external password storeです。これには、サーバー・マシンにウォレットを作成し、Oracleに接続するために使用するユーザー名&のパスワードを格納する必要があります。ウォレットが自動的にログインするようにすると、サーバー・プロセスはウォレットを開く機能やパスワードを表示する機能を持つ必要はなく、サポート担当者はどちらの機能も必要としません。ウォレットは、自動ログインがサーバー・マシンからしか機能しないため、誰かがそれを別のマシンにコピーした場合にウォレットを無駄にするように構成できます。もちろん、保管されたパスワードを変更したい場合に備えて、組織内の誰かがウォレットのパスワードを持っている必要がありますが、その人がサポートスタッフの1人である必要はありません。

クライアントのユーザ名とIPアドレスをチェックし、接続がSolarisボックス以外のマシンから来た場合（おそらくモジュールやプログラムのチェックに加えて）ログインを拒否するログイントリガーがあまり理想的ではありません。これは一般的には機能しますが、誰かが自分のIPアドレスを偽ってしまう可能性が常にあります。しかし、クライアントのIPアドレスを偽装し、ネットワーク上のアプリケーションサーバーのように見せかけると、一般的に十分なルーティングの問題が発生し、攻撃は比較的難しくなります。