0

Oracle 11.2 を使用し、サーバー プロセスは C++ で記述され、Solaris 10 で実行されます。サポート担当者は独自の Oracle ユーザー名を持ち、サーバー プロセス専用の Oracle ユーザー (servuser と呼びましょう) を持っています。

監査の目的で、サーバー プロセスのみが servuser アカウントを使用して変更を行うようにする必要がありますが、サポート担当者が servuser を使用してデータベースにアクセスすることは、ホストしている Solaris ボックスから行う限り許容されます。サーバープロセス。

これに対する明らかな解決策は、OS 認証を使用することです。つまり、プロセス用の Solaris ユーザーを作成し、それを Oracle servuser にマップします。これに関する唯一の問題: これらのサーバー プロセスは、Oracle インスタンスとは別のホストで実行されます。リモート認証を有効にすることは、よく知られた巨大なセキュリティ ホールです (OS で独自のユーザーを作成するだけです - プレスト)。

私が考えることができる他のすべての戦略は良くありません：

  1. パスワードを Solaris アカウントのファイルに保存するのはよくありません。サポート担当者がそれらを見て、sqlplus 経由で接続するために使用できるからです。

  2. ファイルを暗号化するのは良くありません.サーバープロセスは秘密鍵にアクセスする必要があり、サポートスタッフが利用できるようになり、サポートスタッフが復号化してステップ1に戻ります.

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

このシナリオを処理する「公式」の方法は何ですか? OS 認証は、インスタンスをホストしている同じボックスでクライアントを実行している場合にのみ安全に機能しますが、これはかなり役に立たないようです, IMO. それでも、私たちのシナリオは非常に一般的だと思います。アプリ サーバーは別のインスタンスで実行されていますが、特権アカウントのみを使用できるようにしたいと考えています。

提案？

4

1 に答える 1

0

通常、最善の選択肢は、安全な外部パスワード ストアを使用することです。これには、Oracle への接続に使用するユーザー名とパスワードを格納するウォレットをサーバー マシンに作成することが含まれます。ウォレットに自動的にログインさせる場合、サーバー プロセスはウォレットを開いたり、パスワードを表示したりする必要がなく、サポート担当者も同様です。ウォレットは、自動ログインがサーバー マシンからのみ機能するように構成することができ、誰かがウォレットを別のマシンにコピーした場合、ウォレットは多かれ少なかれ役に立たなくなります。もちろん、保存されたパスワードを変更したい場合に備えて、組織内の誰かがウォレットのパスワードを持っている必要がありますが、その人がサポート スタッフの 1 人である必要はありません。

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

于 2012-03-16T17:50:11.280 に答える