|
JAVA Developer 2003年10月号より転載
Javaがこれまで成長してきた過程で、Java2になったときが最も大きな変化を遂げたとき、ということができます。そのときに見られたおそらく最大の変化は、Java全体のセキュリティモデルが一新されたことではないでしょうか。
Javaのセキュリティモデルは非常に柔軟で信頼性の高いものです。しかし、その全貌を理解したうえで利用しなければ、柔軟性も信頼性も価値を発揮できません。
本稿で取り上げるセキュリティというのは、いわゆるJava2プラットフォームセキュリティのうち、ポリシー駆動モデルの部分に関するものです。
●構成する要素
このセキュリティを構成するのは、具体的にはパーミッションクラスが中心となります。また、そのパーミッションクラスを適用するルールをセキュリティポリシーと呼びます。
・パーミッションクラス
パーミッションクラスはパッケージごとに提供されることの多い、そのパッケージへのアクセス権を管理するクラスです。
詳しくは後述しますが、たとえばファイルI/Oに関していえば、java.ioパッケージに属するFilePermissionというクラスが担当します。これはJ2SE SDKの中にあらかじめ提供されているクラスで、ディレクトリやファイルなどのターゲットと、「書き込み」「削除」といったアクションの2種類のパラメータを与えてインスタンス化することにより、ファイルシステムに対するアクセス権を設定できるようになっています。
このパーミッションクラスは必要に応じて自分で提供することも可能です。自作アプリケーション固有のリソースがあれば、それを保護するためのセキュリティ（パーミッション）は、デフォルトで提供されているものの組み合わせによって実現するか、あるいはパーミッションクラスを自作することによって提供できます。
・セキュリティポリシー
パーミッション適用のルールセットは、どのプログラムに対してどのパーミッションを適用するのか、という設定も細かく可能です。この組み合わせがセキュリティポリシーで、単なる設定の集まったテキストファイルです。
簡単にいえば、Java2になったときにこのようなセキュリティが自由に設定できる枠組みが取り入れられ、設定ファイルとほんの少しの追加コードにより、それまでと比べ物にならないほど柔軟なセキュリティが利用できるようになりました。
本稿で取り上げるのは、このアーキテクチャの理解とポリシーの書き方、Tomcatにおける実践です。
●利用する局面
このようなセキュリティは、どのようなケースで利用すればよいのでしょうか。現実にTomcatを利用しているユーザーの多くは、プラットフォームセキュリティなど意識せずに使っている人が多いと思います。
ここではいくつかの典型例を紹介しましょう。
（1）ユーザーに不特定コードの実行を許可するケース
（2）挙動のわからないプログラムを実行させるケース
（3）RMIを利用するケース
（1）のケースは、たとえばあなたがホスティング業者で、利用者を募ってサーブレットコンテナを利用させるようなサービスを提供していることを想像すると理解しやすいでしょう。ユーザーがなにげなく作ったリスト1のような単純なJSPで、コンテナが終了してしまっては運用の妨げになってしまいます。
|
リスト1 なにげなく作ってみたJSP
|
<%@ page contentType="text/html; charset=Shift_JIS" %>
<%
System.exit(0);
%>
|
ユーザーにこのようなコードを使わないようにお願いしたうえで、ユーザーが約束を守ってくれることを祈るしかないというのでは運用はままならないでしょう。ユーザーコードの挙動を制限したほうがいいでしょう。
（2）のケースは、たとえばオープンソース製品のサンプルを実行させてみるときに、勝手にファイルシステムを破壊されないようにする目的などが相当します。
（3）のRMI（Remote Method Invocation）は、分散環境を実現するAPIセットで、ネットワーク上のマシンから未知のコードを入手してきて実行します。RMIの利用にはセキュリティの設定が必須になります。
●従来のモデルからの進歩
Javaはその登場当初の利用形態としてアプレットがクローズアップされました。インターネットからダウンロードしてきた実行可能ファイルをマシン上で実行させるというのは、見るからに危険そうな行為です。
当初のセキュリティモデルは非常にシンプルで、
・ダウンロードしてきたクラスファイルは全面的に信用できない
・ローカルに最初からあるクラスファイルは全面的に信用できる
という、極端なものでした（図1）。アプレットではローカルファイルにアクセスできないといった話題に聞き覚えのある方もいるのではないでしょうか。
図1 当初の極端なセキュリティモデル
しかし、用途によってはローカルに置いたプログラムの動作の一部としてアプレットを使うこともありますので、このような極端なセキュリティモデルではシステムが構築できません。そのため、Java2になったときの改善点として、
・より細かくセキュリティレベルを設定できる
・対象とするコード（クラスファイル）を細かく設定できる
といった機能が盛り込まれました。
これにより、「どのコードに」「どんなセキュリティ」を設定するか、といった制御ができるようになったのです。
そのため、セキュリティを使う以上、基本的に「コードの実行は危険である」というスタンスを理解しておいてください。設定をはじめると、あれやこれやと許可する作業が続きますが、面倒だからといって不要なものまで許可してしまうと、その1か所のおかげですべての苦労が水の泡となってしまう可能性があります。
図2 Java2のセキュリティモデル
関連リンク
 JAVA Developer
定期購読のご案内
バックナンバー販売協力店
|
JAVA Developer 10月号
大特集
再入門 J2SE
特集2 Oracle9i Application Server
［特別企画］
・例外処理のメカニズム
・データベース移行術（２）
「Oracle→DB2編」
・Tomcatで試すJava2セキュリティ
|
| 
