構成ファイル (またはその他の標準的な読み取り可能な場所) でユーザー名/パスワード情報を提供せずに、Oracle への JDBC 接続をセットアップすることは可能ですか?
通常、アプリケーションには、データベースに接続するためのセットアップ パラメータを含む構成ファイルがあります。一部の DBA は、構成ファイル内のユーザー名とパスワードが平文であることに問題を抱えています。
これは Oracle と JDBC では不可能だと思いますが、確認が必要です...
考えられる妥協策は、構成ファイル内のパスワードを暗号化し、接続をセットアップする前に復号化することです。もちろん、復号化キーは同じ構成ファイルにあるべきではありません。これは、許可されていないユーザーが構成ファイルを誤って開いた場合にのみ解決します。
OS ユーザーの資格情報を使用し、OS ユーザーを外部で識別されたデータベースに追加できる Kerberos を試すことができます。重大なセキュリティ上の問題があった古い方法ではなく、必ず Kerberos を使用してください。
Kerberos をサポートするには、高度なセキュリティ オプションと最新の JDBC ドライバー (おそらく 11g バージョン) が必要です。Java で動作させる前に、'/' をユーザー名と空のパスワードとして使用して Sql*Plus で試してください。「デュアルからユーザーを選択」すると、user@domain が表示されます。また、Kerberos 構成に関しては、thin ドライバーと OCI ドライバーの使用には根本的な違いがあることに気付くかもしれません。
データベースが脆弱になるため、資格情報なしでデータベースに接続できるようにしたくないことは間違いありません。
これは一般的な問題です。外部システムへのアクセスに必要な資格情報をどのように保存すればよいですか? WebLogic にはこの問題を解決するための資格マッパーがあり、(暗号化された) 資格は組み込み LDAP に格納されます。多くの Oracle 製品は、資格情報を Oracle ウォレットに格納する資格情報ストア機能を使用します。
質問では、あなたが答えを提供しました。パスワードを暗号化して保存し、必要なときに復号化します。明らかに、復号化できるように、3DES などの対称暗号化アルゴリズムを使用する必要があります。対称キーが推測できるものでないことを確認してください。
トリックは、暗号化/復号化に必要な対称キーを保持する場所です。OS によって保護されたファイルに配置することも、コード内に保持することもできますが、その場合はコードを安全に保つ必要があります。同じキーを生成する手法を使用し、アルゴリズムが十分に安全である場合は、キーを生成することもできます。
コードを安全に保つことができれば、明らかにコード内にパスワードを保持することもできます。ただし、コードを変更せずに資格情報を変更できるという柔軟性が必要です。
このソリューションにさらにレイヤーを追加することもできます。構成ファイルを (別のキーで) 暗号化し、その中のパスワードを暗号化して、ハッカーに 2 つのキーを発見させることができます。PKI を使用したさらに安全な方法は他にもありますが、セットアップが難しくなります。
プロキシ認証を検討することをお勧めします。これは、 『Oracle®Database Security Guide』および 『Oracle®Database JDBC Developer's Guide and Reference』に記載されています。基本的に、これにより可能になるのは、接続権限のみを持つユーザーをデータベースに含めることです。ユーザーの実際のデータベースアカウントは、プロキシユーザーとして接続できるように構成されています。次に、JDBCを介して接続するアプリケーションは、プロキシのユーザー名とパスワードを格納します。接続時にこれらの資格情報を提供する場合は、接続文字列に実際のデータベースユーザーのユーザー名を加えます。Oracleはプロキシ・ユーザーとして接続し、実際のデータベース・ユーザーを模倣して、実際のユーザーのデータベース権限を継承します。
すべてのJ2EEコンテナー ( JBOSS、Tomcat、BEA ) には接続プールがあります。彼らは多くの接続を開き、それらを維持し、最初から作成するのにかかる時間1/100内にそれらを提供します.
さらに、JBOSSすべての接続情報が外部ファイルに保存されるなど、優れた機能もあります。接続情報を変更した場合、つまり、テストDBから本番DB に切り替えた場合、アプリケーションには新しいプールから動的に接続が供給されます。
J2EE幸いなことに、接続プールを使用するためだけに完全なコンテナーを実行する必要はありません。外部リソースを使用すると、パスワードをプレーンテキストまたは疑似暗号化で保存できます。
Tomcat の組み込み接続プールの使用に関するガイドについては、Apache commons-dbcp を参照してください。
Java と JDBC が Oracle と話している以外の環境については完全に明確ではないので、それについて話します。
Java EE アプリについて話している場合は、アプリ サーバーで接続プールとデータ ソースをセットアップできる必要があります。その後、アプリケーションは、そのレベルで接続を処理する接続プールと通信します。
接続プールとデータ ソースは資格情報を保持し、保護します。
私の知る限り、jdbc 接続のユーザー名/パスワードはプレーン テキストとして保存する必要があります。この可能性のあるリスクを制限する 1 つの方法は、ユーザーの権限を制限して、指定されたアプリケーション データベースのみを、事前定義されたホストからのみ使用できるようにすることです。IMO、これは攻撃者を非常に制限します。攻撃者は、元のアプリケーションが存在する同じホストからのみ un/pw を使用でき、元のアプリケーションのデータベースを攻撃するためだけに使用できます。
これは以前から疑問に思っていました。
解決策は確かに、システムにアクセスできる人の数を実際に減らすためにサーバーとネットワーク レベルで適切なネットワーク セキュリティを確保すること、およびデータベースの資格情報を持っていることで、最小限のアクセス許可を持つデータベース アカウントにのみアクセスできるようにすることです。アプリケーションを実行するために必要です。
プロパティ ファイルの暗号化は、「鍵やパスフレーズを探す手間がかからない」という点で、攻撃者を次の侵害されたサーバーに侵入させるのに十分な抑止力になる可能性があります。ただし、「私の隣人は安全性が低いので、彼から盗んでください」というセキュリティには依存しません。
重要なアプローチは 2 つありますが、どちらもシステムの設計に大きな影響を与えるため、大幅な書き換えなしに一方から他方へ移行することは容易ではありません。選択する前に、会社のセキュリティ ガバナンス ポリシーが何であるかを理解する必要があります。
1) すべてのユーザーは、アプリケーションによって使用されているサービスに対して、アプリケーションを介して運ばれる資格情報を持っています。あなたの場合、Oracleデータベースはそれらのユーザー資格情報を使用してデータベースに接続します。欠点は、すべてのユーザーが各セキュア サービスの資格情報を必要とすることです。これは合理的な安全なアプローチですが、ユーザーの資格情報を提供および維持するためにかなりの追加作業が必要になります。データベース管理者は、ユーザー資格情報を積極的に管理する必要がありますが、これは会社のセキュリティ ガバナンス ポリシーに反する可能性があります。
2) アプリケーション データベースの資格情報は、Secure LDAP などの安全なディレクトリ サービスに保存されます。アプリケーションは、ユーザーの資格情報を使用してディレクトリ サービスにアクセスします。ディレクトリ サービスは、アクセスされているサービスに適切な資格情報を返します。
どちらの場合も、適切な操作のみを実行するようにデータベース資格情報を制限する必要があります。認証情報は、ビジネス プロセスの要件を反映する必要があります。定義されたビュー/テーブルからの選択、他のビューへの挿入は許可されますが、テーブルの作成、更新、削除は許可されません。2 番目のアプローチでは、注文処理、会計、人事などの主要なビジネス プロセスごとに個別の資格情報を使用します。
ただし、セキュリティはタマネギの層のようなものであることを覚えておいてください。誰かがアプリケーションにアクセスするために層を取り除いて、DB 接続プールの構成ファイルにアクセスできるようにした場合です。アプリケーションをトロイの木馬で攻撃して、ユーザーの資格情報を取得する可能性があります。ここで、優れたセキュリティ ガバナンス ポリシーの出番です。
セキュリティ ガバナンスは、上級管理職の関与が必要な複雑な問題です。ライブ プラットフォームにこのレベルのセキュリティが必要な場合、コストがかかるからです。開発の責任を、展開、運用、およびユーザー権限管理から分離する必要があります。また、変更を表示するための完全なアクセス権はあるが構成を変更する権限がないセキュリティ監査者が必要になる場合もあります。それは単純ではなく、高給の専門性です。
資格情報は、プログラムに組み込まれた文字列や Windows レジストリのエントリなど、どこにでも保存できます。ただし、非標準のものを使用する場合は、それらを取得するのはあなた次第です。プレーンテキストではない事前に展開されたソリューションについては知りません。
データベース サーバーによって信頼されている既知の中間層コンポーネント/サービス (プロキシ) に対して証明書を使用して JDBC クライアントが認証する Oracle のプロキシ認証を試すことができます。私はそれを試したことがないので、それが簡単にできるかどうかはわかりません。