| 目次 | 前の項目 | 次の項目 | JDBCTM ガイド: 入門 |
信頼できないアプレットに対するこのような制限は、非常に面倒なものです。しかしこれらは一般的なアプレットセキュリティモデルに従うもので、他に良い方法はありません。
ただしアプレットの場合と同様に、信頼できない sun.sql.Driver クラスがなんらかの理由でリモートソースからロードされた場合は、同じソースからロードされたコード以外にはそのドライバを使用しないものとします。
第 3 章で説明したように、DBMS に依存しない JDBC ネットドライバ用の公開プロトコルの標準規格を Java ソフトウェアが提案するなら、セキュリティの考慮はプロトコルを選択する際の重要な要素になります。
これらの規則は、ドライバがアプレットとしてダウンロードされる場合には必要ありません。その理由は、アプレットドライバは、標準的なセキュリティマネージャによって不正な接続の作成を阻止されるからです。しかし忘れてならないのは、「良くできた」ドライバの場合、ユーザがそのドライバをローカルディスクにインストールする可能性があり、そのときにはそのドライバが Java 環境の中の「信頼できる」部分に入ってしまうということです。また、そのドライバが外からアクセスするアプレットによって誤用されないようにする必要があります。このような理由で、すべての JDBC ドライバの開発者が基本的なセキュリティ規則に従うことが奨励されています。
これらの規則はすべて、接続を開く時点で適用されます。この時点でドライバと Virtual Machine は、現在の呼び出し元が指定されたデータベースへの接続を許可されているかどうかを確認します。接続が開かれたあとは、それ以上の確認は必要ありません。
しかし、JDBC ドライバが 1 つの TCP 接続を複数の異なるデータベース接続の間で共有しようとする場合、各呼び出し元が目的のデータベースへのアクセスを本当に許可されているかどうかを確認することは、ドライバの責任になります。たとえば、あるマシンへの TCP 接続をアプレット A のために開いた場合、アプレット B がこの接続を共有することを自動的に許可することを意味するのではありません。アプレット B はそのマシン対して一切のアクセス権を持っていない可能性があります。
したがって JDBC ドライバは、既存の TCP 接続の再使用を許可する前に、現在の呼び出し元がそのマシンへの接続を許可されているかどうかを、セキュリティマネージャで確認する必要があります。これは、次のコードで行います。
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkConnect(hostName, portNumber);
}
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(fileName);
}
TCP 接続の場合と同様、ドライバがこれらのセキュリティ問題を考慮する必要があるのは、ファイル資源が複数の呼び出し元スレッドによって共有されており、ドライバが信頼できるコードとして実行中の場合だけです。
このような状況では、ドライバは「最悪のケース」のセキュリティを想定し、目的のアクセスが無害であることをドライバが確信しない限り、ダウンロードしたアプレットに対しデータベースアクセスをすべて拒否する必要があります。
たとえば、JDBC-ODBC ブリッジが ODBC データソース名の意味をチェックして、そのアプレットが接続を開くことを許可されているマシン上の、データベースを参照する ODBC データソース名だけの使用をアプレットに許可するとします (5.4.1 を参照)。しかし、一部の ODBC データソース名からは、ドライバが目的のデータベースのホスト名を判断できないので、ダウンロードされたアプレットがこれらのデータソースにアクセスするのを拒否しなければならない場合があります。
現在の呼び出し元が信頼できるアプリケーションまたはアプレットかどうか (つまり、任意のデータベースアクセスを許可されているかどうか) を判断するために、JDBC ドライバはその呼び出し元が任意のファイルへの書き込みを許可されているかどうかを調べます。
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkWrite("foobaz");
}