![[PolicyTool] ウィンドウのスクリーンショット](security-spec.doc.anc7.gif)
| 目次 | 前の項目 | 次の項目 | Java セキュリティーアーキテクチャー |
現状では、すべての Java 2 SDK システムコードは、SecurityManager メソッドを呼び出して、実施中のポリシーおよびアクセス制御を検査します。通常、アプレットの実行中には、セキュリティーマネージャー (SecurityManager の実装) がインストールされています。appletviewer および Netscape や Microsoft Internet Explorer などの一般的なブラウザは、セキュリティーマネージャーをインストールします。セキュリティーマネージャーは、アプリケーションの実行中に自動的にインストールされるわけではありません。ローカルファイルシステムのアプリケーションに対して、ダウンロードしたアプレットに対するのと同じセキュリティーポリシーを適用するには、アプリケーションを実行するユーザーが、次のように新しい「-Djava.security.manager」コマンド行引数 (「java.security.manager」プロパティーの値を設定する) を使って Java 仮想マシンを呼び出す必要があります。
java -Djava.security.manager SomeApp
あるいは、アプリケーション自体が、java.lang.System クラスのsetSecurityManagerメソッドを呼び出して、セキュリティーマネージャーをインストールする必要があります。特定のセキュリティーマネージャーをコマンド行で指定できます。その場合、次に示すように「-Djava.security.manager」のあとに、等号、およびセキュリティーマネージャーとして使用するクラスの名前を指定します。
java -Djava.security.manager=COM.abc.MySecMgr SomeApp
セキュリティーマネージャーが指定されない場合、デフォルトで組み込まれるセキュリティーマネージャーが使用されます (アプリケーションが別のセキュリティーマネージャーをインストールする場合を除く)。次のコードはすべて等価であり、デフォルトのセキュリティーマネージャーを使用します。
java -Djava.security.manager SomeApp
java -Djava.security.manager="" SomeApp
java -Djava.security.manager=default SomeApp
Java 2 SDK には「java.class.path」というプロパティーが含まれます。ローカルファイルシステムに格納されるものの、システムクラスとしては扱われないクラス (SDK に組み込みのクラスなど) は、このパスに置かれます。このパスのクラスは、安全なクラスローダによってロードされ、実施中のセキュリティーポリシーに従います。また、「-Djava.security.policy」コマンド行引数により、使用するポリシーファイルを指定できます。このコマンド行引数の詳細については、「デフォルトシステムおよびユーザーポリシーファイル」で説明します。基本的に、コマンド行に「-Djava.security.policy」を含めない場合、セキュリティープロパティーファイルで指定されたポリシーファイルが使用されます。
「-Djava.security.policy」コマンド行引数を使用して、アプリケーションの呼び出し時に、ポリシーファイルを追加したり、別のポリシーファイルを指定したりすることができます。たとえば、次のようにして指定します。ここで、pURL は、ポリシーファイルの位置を指定する URL です。ここから指定されたポリシーファイルがロードされ、セキュリティープロパティーファイルで指定されたすべてのポリシーファイルに追加されます。
java -Djava.security.manager -Djava.security.policy=pURL SomeApp
代わりに「==」を使って次のコマンドを記述すると、指定されたポリシーファイルだけが使用され、その他のポリシーファイルはすべて無視されます。
java -Djava.security.manager -Djava.security.policy==pURL SomeApp
アクセス制御の新しい機構は、完全に下位互換性があります。たとえば、SecurityManager 内のcheckメソッドの大部分の実装は、SecurityManager のcheckPermissionメソッドを呼び出す (デフォルトの実装では AccessController のcheckPermissionメソッドを呼び出す) ように変更されましたが、それらのメソッドはすべてサポートされています。特定の内部セキュリティーチェックは、パラメータ化される場合を除いて SecurityManager クラス内に引き続きあります。現時点では、SecurityManager を呼び出してクラスローダの存在をチェックする代わりに、AccessController を呼び出すようにシステムコードのすべてを改訂する作業は完了していません。これは、SecurityManager をサブクラス化し、
checkメソッドをカスタマイズする Sun 以外のアプリケーションが存在する可能性があるからです。そのため、デフォルトでは単にAccessController.checkPermissionを呼び出すSecurityManager.checkPermissionという新しいメソッドを追加しました。SecurityManager がアクセス制御の中心的な概念を表していることに注目すると、SecurityManager と AccessController との関係を理解できます。AccessController は、
doPrivilegedメソッドなど特殊な機能を使用して、特定のアクセス制御アルゴリズムを実装しています。SecurityManager を最新に保つことにより、下位互換性 (以前のバージョンの JDK に基づく独自のセキュリティーマネージャークラスを記述したアプリケーションとの互換性など)、および柔軟性 (セキュリティーモデルをカスタマイズして必須アクセス制御または複数レベルのセキュリティーを実装するなど) が維持されています。AccessController により、もっとも限定的なアルゴリズムを提供することによって、大部分のシナリオに対応するセキュリティーコードを記述しなければならない重荷からプログラマを解放します。アプリケーションコードで AccessController を使用することを強くお勧めします。一方、セキュリティーマネージャーの (サブクラス化による) カスタマイズは、細心の注意を払って行う必要があるため、最後の手段にすべきです。さらに、標準セキュリティーチェックを呼び出す前に常に日時をチェックするようなカスタマイズされたセキュリティーマネージャーには、適切な場合にはいつでも AccessController が提供するアルゴリズムを使用すべきです。
このセクションでは、新しいセキュリティー機能の展開を支援する 3 つのツールの使用法について簡単に説明します。これらのツールは、今後 1 つにパッケージ化される予定です。ツールの詳細については、SDK ディレクトリの次のサブディレクトリを参照してください。
/docs/technotes/tools/solaris
および
/docs/technotes/tools/windows
Windows システムでは、ディレクトリの区切り文字は、「\」になります。たとえば、Java 2 SDK が Solaris システムの「/j2sdk1.2」ディレクトリにインストールされている場合には、Solaris および Windows ユーザー用の keytool のドキュメントは、それぞれ次の場所に格納されています。
/j2sdk1.2/docs/tooldocs/solaris/keytool.html /j2sdk1.2/docs/tooldocs/windows/keytool.html
Java 2 SDK が Windows システムの「C:\j2sdk1.2」ディレクトリにインストールされている場合、Solaris および Windows ユーザー用の keytool のドキュメントは、それぞれ次の場所に格納されています。
C:\j2sdk1.2\docs\tooldocs\solaris\keytool.html C:\j2sdk1.2\docs\tooldocs\windows\keytool.html
keytool は、鍵と証明書を管理するためのユーティリティーです。keytool を使うと、自分の公開鍵と非公開鍵のペア、および関連する証明書を管理し、デジタル署名を使った自己認証 (ほかのユーザーまたはサービスに対して自分自身を認証すること) や、データの整合性と証明書に関するサービスを利用することができます。認証情報には、X.509 証明書のシーケンス (連鎖) と関連した非公開鍵 (通称「別名」によって参照される) の両方が含まれます。このツールは、証明書 (ユーザーにより「信頼されている」) も管理します。この証明書は、認証情報と同じデータベースに格納されており、「別名」によって参照されます。keytool は、鍵と証明書を「キーストア」に格納します。デフォルトのキーストア実装は、キーストアをファイルとして実装します。キーストアは、非公開鍵をパスワードで保護します。
X.509 証明書の連鎖は、証明書発行局 (Certification Authority、CA) という組織によって提供されます。アイデンティティー (CA を含む) は、その非公開鍵を使用して、オブジェクト (SSL を使用してセキュリティー設定したチャンネルなど) との関係、署名したコードのアーカイブとの関係、および発行した X.509 証明書 (CA 用) との関係を認証します。ブートストラップツールとして、-genkey コマンドを使用して生成した証明書は、証明書発行局が証明書チェーンを返すまで使用される可能性があります。
このデータベース内の非公開鍵は、不適切に公開されないように常に暗号化されて保存されます。データベースにアクセスするか、データベースを変更する場合には、パスワードが要求されます。これらの非公開鍵は、複数の単語で構成される「パスワード」を使用して暗号化されます。パスワードを忘れた場合、認証鍵を復元することはできません。
実際、キーストア内の各非公開鍵は、個々のパスワードによって保護することができます。このパスワードは、キーストアの全体的な整合性を保護するパスワードと同じである場合も、異なる場合もあります。
現在、このツールは、コマンド行でシェルプロンプトに、単に「keytool」と入力して使用するようになっています。keytool は、適切な Java クラスを実行するスクリプトで SDK に組み込まれています。
各コマンドのコマンド行オプションは、任意の順序で指定できます。不正確なオプションを入力したり、「keytool -help」と入力すると、次のようなツールの使用法の概略が出力デバイス (シェルウィンドウなど) に出力されます。
% keytool -help
KeyTool usage:
-certreq [-v] [-alias <alias>] [-sigalg <sigalg>]
[-file <certreq_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-delete [-v] -alias <alias>
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-export [-v] [rfc] [-alias <alias>] [-file <cert_file>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-genkey [-v] [-alias <alias>] [-keyalg <keyalg>]
[-keysize <keysize>] [-sigalg <sigalg>]
[-dname <distinguished_name>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>]
[-storetype <i>storetype</i>]
-help
-identitydb [-v] [-file <idb_file>] [-keystore <keystore>]
[-storepass <storepass>]
[-storetype <i>storetype</i>]
-import [-v] [-noprompt] [-alias <alias>]
[-file <cert_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-keyclone [-v] [-alias <alias>] -dest <dest_alias>
[-keypass <keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-keypasswd [-v] [-alias <alias>]
[-keypass <old_keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-list [-v | -rfc] [-alias <alias>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
-printcert [-v] [-file <cert_file>]
-selfcert [-v] [-alias <alias>] [-sigalg <sigalg>]
[-dname <distinguished_name>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>]
[-storetype <i>storetype</i>]
-storepasswd [-v] [-new <new_storepass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <i>storetype</i>]
PolicyTool は、グラフィカルユーザーインタフェース (次の図を参照) で、ユーザー (システム管理者など) によるセキュリティーポリシーの指定、生成、編集、エクスポート、またはインポートを支援するツールです。このツールは、コマンド行でpolicytoolと入力すると呼び出されます。このツールも SDK に組み込まれたスクリプトで、適切な (非公開の) 実装クラスを呼び出します。使用法および最新のスクリーンショットを含む例については、PolicyTool のドキュメントを参照してください。ドキュメントは、policytool.html ファイルに格納されており、このファイルは SDK がインストールされたディレクトリ内の次のディレクトリにあります。
/docs/technotes/tools/solaris/
または
/docs/technotes/tools/windows/
ファイル区切り文字は、Windows システムでは、バックスラッシュになります。
jarsigner ツールを使用すると、Java Archives (JAR ファイル) にデジタル署名したり、その署名を検証したりすることができます。PolicyTool と同様、このツールは keytool によって管理されるキーストアに依存しています。使用方法の概略を次に示します。
% jarsigner
使用方法: jarsigner [options] jar-file alias
jarsigner -verify [options] jar-file
[-keystore <url>] keystore file location
[-storepass <password>] password for keystore integrity
[-keypass <password>] password for private key (if different)
[-sigfile <file>] name of .SF/.DSA file
[-signedjar <file>] name of signed JAR file
[-verify] verify a signed JAR file
[-verbose] verbose output when signing/verifying
[-certs] display certificates when verbose and verifying
[-internalsf] include .SF file inside signature block
[-sectionsonly] don't compute hash of entire manifest
このツールも SDK に組み込まれたスクリプトです。このツールと既存の jar ツールのスクリプトは、将来統合されて、署名付きまたは未署名の JAR を作成する単一のコマンド行プリミティブになる可能性があります。