LinuxのJavaサービスに対する安全性を高める

Tomcat用に安全な檻を用意する

エンタープライズJavaの専門家Dennis Sosnoskiが、Javaサーバー・テクノロジーはLinuxになじむテクノロジーであるという持論を展開した後、LinuxにTomcatのJavaサーブレット・エンジンを「安全に」セットアップするためのヒントを紹介します。

Dennis Sosnoski, President, Sosnoski Software Solutions, Inc.

Photo of Dennis SosnoskiDennis Sosnoski はシアトル地域にある Java 技術のコンサルティング会社、Sosnoski Software Solutions, Inc. の創立者で、主席コンサルタントでもあり、また XML や Web サービスに関するトレーニングやコンサルティングの専門家でもあります。彼のプロとしてのソフトウェア開発経験は 30年以上に渡り、ここ数年はサーバー側の XML 技術や Java 技術に注力しています。Dennis は、全米各地で行われる会議で頻繁に講演を行っています。また、Java クラスワーキング技術を基に構築された、オープンソースの JiBX XML Data Binding フレームワークの中心開発者でもあります。



2003年 4月 01日

LinuxとJavaプラットフォームには、長い関係がありますが、いろいろと問題もありました。Javaプラットフォームというオープン・ソースのクリーン・ルーム実装しようという初期の動きは、絶えず成長を続けるコアのJava APIとの整合性を図りつつ高性能の仮想マシンを構築することにさまざまな困難が伴ったため、かなり難渋しました。ついにはJavaテクノロジーのライセンス実装がLinux向けに供給されるようになるのですが、これらの実装は、オープン・ソースではありませんでした。そのため、ほとんどのLinuxディストリビューションは、このライセンス実装を含んでいません。

こうした問題があるにもかかわらず、Javaプラットフォームには、いろいろと大きな利点があるため、Linuxでの、とくにサーバー・アプリケーションでのライセンス実装の利用は増加してきています。本稿では、まず、サーバー・アプリケーションでのJavaプラットフォームの利点を再確認した後、LinuxにJavaサービスを簡単かつ安全に配備する際の問題について考えることにします。また、実際的な例として、広く利用されているApache Software FoundationのTomcat Javaサーブレット・エンジンを、単独で動作するようにセットアップする方法を説明したいと思います。

Javaプラットフォームを使う理由

Javaプラットフォームがサーバー・ベースのビジネス・アプリケーションに広く利用されるようになってきたのには、数々の理由があります。ここでは、こうした環境で重要な理由を3つ上げておきたいと思います。クロス・プラットフォーム互換性、実行時環境の整備、および開発が容易であることの3つです。

Javaアプリケーションは、さまざまな種類のオペレーティング・システムやハードウェア・プラットフォームの間でバイナリー互換性を備えています。これは、とくに非GUIサーバー・アプリケーションの場合にそうで、一般に、実際のターゲット・システムでテストを行う必要はほとんどありません。開発者は、好みのプラットフォームでコーディングやデバッグを行うことができ、それでいて自分で直接タッチできないような環境にそれらのアプリケーションを配備することができます。

Java Virtual Machine (JVM) 環境の実行時機能は、プログラムの安全性をいろいろな面で強制的に確保します。中でも最も重要な側面の1つに、厳密な型チェック、配列の境界チェック、および自動ガーベッジ・コレクションを組み合わせることで、バッファー・オーバーラン、二重発行エラー、無効なポインターといったサーバー・コードの中でも最も破壊的な形の脆弱さを完全に防御しているということがあります。最初アプレットに利用されていた頃から発展を遂げてきたJava言語は、セキュリティー・リスクが存在するかもしれないような設備に対するきめの細かいアクセス制御が可能な洗練されたシステムを備えるようになっています。スタンドアロン・アプリケーションでの使用はオプションとなっていますが、これらのアクセス制御は、Javaサービス用の数多くのフレームワークに組み込まれています。

プログラムの安全性を確保するためのこれらの実行時の機能は、一方で、Java言語の開発のやりやすさにも寄与しています。この種の問題を正確に測定することは困難ですが、CやC++ などの言語を使用していた環境からJavaプログラミングの世界に移ってきた開発者のほとんどは、生産性が上がったと言います。これは、1つには、コンパイル時と実行時の両方で厳密な型強制が行われるとともに、メモリー管理が自動的に行われるという簡単さによるものです。また、Javaプラットフォーム用に広範な標準APIが開発されているということもあります。これらのAPIは、新しい開発者にとって大変な負担となるかもしれませんが、いちど習得してしまえば、クロス・プラットフォームをうまくサポートでき、さまざまなエンタープライズ仕様を実現できることになります。

Javaプラットフォームが適していないアプリケーションがあることも事実です。JVMアーキテクチャーに絶えず改良が加えられているにもかかわらず、Javaアプリケーションの実行速度は、同じアルゴリズムのCやC++ のアプリケーションよりも少し遅くなるのが一般的です。私の経験とテストから推測して、この速度の差は、もちろんコードの質に大きく左右されるでしょうが、ライセンスJVMで実行されるほとんどのサーバー・アプリケーションで20%から50%の間だとみています。また、これらのJVMで実行されるJavaアプリケーションは、スタンドアロン・プログラムに比べて起動時間も遅くなります。もっとも、実行期間の長いサーバー・アプリケーションの場合、通常、これが大きな問題となることはありませんが。ほとんどの場合、性能が低かったり、起動時間が長いといったことは、セキュリティーが向上し、短時間で開発を行うことができるというJavaプラットフォームの利点に比べれば、小さな代償です。

オープン・ソースの代替製品

標準的なライセンスJVM (使用は自由だが、ソースの入手は制限されている。Linux用には、Sun、IBM、BEA、およびBlackdownという団体のものがある) 以外に、Linuxには、いろいろな選択肢があります。その中には、クリーン・ルームでオープン・ソースとしてJVMを実装したものが数多くあり、その中でも、おそらく最も広く利用されているのがKaffeです (数多くのLinuxディストリビューションに含まれている製品です)。Kaffeは、かなり驚異的な製品を実現している非常に大きな意味のあるプロジェクトなのですが、現在のライセンスJVMとの互換性は限定的なものでしかありません。したがって、通常、本稿で扱うエンタープライズ型のサーバー・アプリケーションには利用できません。

同じことは、Javaプログラムのネイティブ・コード・コンパイラーを扱うオープン・ソース品についても言えます。この種の最も大きなプロジェクトは、GNU Compiler CollectionのGCJです。GCJなどのネイティブ・コード・コンパイラーを使用する場合、実行する前に、プラットフォーム独立なJavaバイト・コードがプラットフォーム固有なコードに変換されます (これに対して、JVMの中で実行させる場合、通常、JVMが実行時にバイト・コードをプラットフォーム固有なコードに変換します)。

JVMで実行されるJavaアプリケーションの起動には比較的長い時間がかかるという問題を解消するための1つの方法として、ネイティブ・コードのコンパイルには大きな可能性がありますが、このような手法を採るコンパイラーは、通常、現在の世代のライセンスJVMが示す安定的な性能には太刀打ちできません。JavaアプリケーションがJavaプラットフォームの動的な機能を利用している場合 (実行時に選択されたフィールドにアクセスしたりクラスをロードするためにリフレクションを使用するなど) には、とくに、そういうことが言えます。実装や使用されるコンパイル・オプションにもよりますが、ネイティブ・コードをコンパイルすることで、実行時の安全性を確保するためのJavaプラットフォームのいろいろな機能を脆弱なものにする可能性もあります。さらには、JavaのAPIの多くは、ライセンスの問題から、コンパイルされたネイティブ・コードで使用できないという問題もあります。これらの制約から、ネイティブ・コードのコンパイルは、現在のところ、Javaプラットフォームのサーバー・アプリケーションには不向きです。

C# の可能性

Java実行時環境と多くの点で共通性のあるもう1つの手法に、マイクロソフトのC# という言語とそれに対応する共通言語ランタイム (CLR: Common Language Runtime) があります。C# は、Java言語から派生した類縁の言語で、CLRは、いろいろなプラットフォームでC# を利用できるようにするためのものです。また、CLRは、実行時の安全性を確保するためのJVMの多くの機能も提供します (ただし、安全性の保証を大幅に低下させる抜け穴も存在しますが)。また、マイクロソフトの .Net実装では、GCJがJavaバイト・コードに対して行っていることに倣い、プリコンパイルを行ってネイティブ・コードを生成することで起動を高速化するというオプションもサポートされています。もちろん、.NetはWindowsシステム専用ですので、Linuxユーザーがその多くを直接利用できるわけではありません。

Mono Projectは、クリーン・ルーム・オープン・ソースのC# およびCLR相当品を、いろいろな系統のLinux向けに構築しようと開発を進めています。現時点では、C# コンパイラーが動くようになっており、マイクロソフトが標準化を進めるために発表しているCLRのほとんどが動作する状態になっています。といっても、性能に関しても機能に関しても、Javaプラットフォームにとって代われるほどの製品になるまでには、まだまだ先の長い話です。CLRは、Javaのコアのクラス・ライブラリーに相当する基本的な部分しか出来あがっていません。エンタープライズ・ソフトウェアの開発に使えるようになるまでには、さらに多くのAPIを補充する必要があるでしょう。

Mono Projectは、.NetのCLR以外の部分の移植作業も進めていますが、これらの移植が成功し、かつマイクロソフトが .Netのこれらの部分に対して特許を主張しないならば、そうした製品のおかげで、C# がLinuxでのサーバー・ソフトウェア開発用の確固たるプラットフォームになるための必要条件は満たされることになります。しかし、それは、ifがいくつも連なった先の話であり、そうこうしているうちに、Javaプログラム用のネイティブ・コンパイラーとオープンソースのJVMが、ライセンスされたJVMは使いたくないし限られた機能だけで十分だというユーザーに対しての、比較的安定した代替品となるでしょう。


Apache Tomcat

Javaプラットフォームの最も普遍的なサーバー・アプリケーションにApache Tomcatがあります。Tomcatは、もともとサン・マイクロシステムズから提供されたソース・コードを基に始まったオープン・ソース・プロジェクトです。Tomcatは、サンがJava Community Processを介して開発し、現在非常に広範に使用されているサーブレットやJavaServer Page (JSP) といったテクノロジーの公式参考実装 (official reference implementation) として作成されたHTTPサーバーです。本稿では、Linuxに1個のサービスとして配備されるJavaアプリケーションの例としてTomcatを取り上げます。Tomcatを動かしてみたいという方は、サイズの小さいJava Runtime Environment (JRE) ではなく、Java Development Kit (JDK) をシステムにインストールする必要があります。

HTTPサーバー・アプリケーションの構築には、サーブレットやJSPのテクノロジーが使用されます。サーブレット・テクノロジーのほうは、おおよそ、Java言語を直接、高速に呼び出せるようにカスタマイズされたCGIインターフェースに相当します。といっても、(アクセス・セキュリティー、セッション管理、スレッド処理制御など) 数多くの機能が追加されていますが。一方、JSPテクノロジーは、実行時の動作が速くなるように直接サーブレットの形にコンパイルされる動的生成HTMLページを、簡単に取扱う手段を提供します。

Tomcatは、この2つのテクノロジーだけでなく、それ以外の数多くの機能を提供します。Tomcatは、それ自体で完全に機能するWebサーバーなのですが、Linuxシステムでは、多くの場合、Webサーバーのフロント・エンドであるApacheと組み合わせて使用されます。Apacheは、静的なコンテンツのサーバー機能としては、Tomcatよりも格段に高い性能を提供します。静的なコンテンツでアクセス頻繁の高いページの比率が比較的高いWebアプリケーションの場合、フロント・エンドのApacheが、非常に有効な働きをします。しかし、多くの単純なWebアプリケーションの場合、それは過剰性能であり、Tomcatだけで充分な性能が得られます。しかも、そのほうが (少なくとも、それまでApacheを使ったことのない開発者にとって) 設定や管理がずっと簡単です。


ポートのジレンマ

Tomcatを単独で実行する場合、1つ大きな問題があります。それは、ルートとして実行しないと、標準のHTTPポート80にアクセスできないという問題です。サーバー・アプリケーションをルートとして実行するというのは、通常、行儀のよい会社では考えられないことですので、本稿では、そんな方法はまったく考えないことにします。それよりも、80以外のポートを使うという選択のほうが優れています (たとえば、Tomcatのデフォルトのポートは8080です)。その場合、テストではうまくいくことが多いのですが、あるサービスが複数のユーザーからアクセスされると、リクエストにポート番号を明示する必要があるため、URLが乱雑になることになります。また、標準以外のポートを使うということは、外部アクセスが必要な場合には、ファイアウォールを再設定する必要があるということでもあります。

xinetdによる解決策

幸い、Linuxでは、ポート80のリクエストをTomcat (や他のユーザー・モード・アプリケーション) で簡単に扱う方法がいろいろとサポートされています。よく使われるのは、xinetdを利用する方法です。xinetdは、便利なリダイレクション機能以外にも、さまざまなアクセス制御やロギングをサポートするインターネット・サービス・デーモンです。リダイレクション機能を使えば、あるポートに送られてきたリクエストを受け取り、それを別のポート、あるいは別のIPアドレスに回して処理してもらうように、システムを設定することができます。

システムでポート80のリクエストを処理できるようにTomcatをセットアップしたいのであれば、そのためのxinetdの構成ファイルを追加する必要があります。それには、xinetdが通常のパスにインストールされているものとすると、ファイルを (ユーザー・ルートとして) /etc/xinetd.dディレクトリーに追加します。リスト1は、Tomcat用の構成ファイルの例です。

リスト1. xinetdのリダイレクトの構成
# Redirects any requests on port 80 
# to port 8080 (where Tomcat is listening)
service tomcat
{
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        port            = 80
        redirect        = localhost 8080
        disable         = no
}

構成ファイルを追加したら、xinetdをリスタートして、リダイレクションを実際に有効にする必要があります。それには、Linuxのほとんどのインストールの場合、

/sbin/service xinetd restart

を、ルートとして実行します。構成ファイルを /etc/xinetd.dディレクトリーに置いておくかぎり、システムをリスタートすると、リダイレクションが自動的に起動されます。Tomcatが自動起動するようにセットアップされていないと、送られてくるリクエストは、Tomcatが起動されるまで、拒否されることになります。

iptablesによる解決策

xinetdは、リクエストのリダイレクションを行うには素晴らしい方法ですが、実際にポート間でデータを転送するためのプロセスを実行するわけですから、ある程度オーバーヘッドもかかりますLinuxカーネルの最近のバージョンは、iptablesを使って、リダイレクションをもっと上手に行う方法をサポートしています。iptablesは、もともとカーネル・コンポーネントであるという点がxinetdと異なります。そのため、xinetdによる方法で発生するオーバーヘッドを回避することができます。iptablesを扱う場合の欠点といえば、xinetdの場合よりも設定が複雑になりがちであること、および最近のバージョンのカーネルでしかサポートされていないという点です。

ここで紹介する手法を利用するには、iptablesをサポートしている2.4.x以降のカーネルを実行する必要があります。iptablesの構成やセットアップは、それだけで、優に何本かぶんの記事にできるほどのテーマですので、ここでそれを説明するつもりはありません。iptablesの使い方がよくわからない場合には、Linuxディストリビューションのマニュアルで調べてください。皆さんのシステムでiptablesが実行されているかどうかを簡単に調べるには、

/sbin/service iptables status

ルートとして実行してみてください。実行されていれば、テーブルやチェーンの一覧がコンソールに表示されるはずです。

iptablesは、パケット処理ルール用のテーブルとチェーンをいくつか使用します。送られてくるHTTPリクエストをポート80からシステム内の別のポートにリダイレクトするには、natテーブル (Network Address Translationの略) とPREROUTINGチェーンを使います。リスト2は、これを実現するためのルールを追加するときに (ルートとして) 実行するコマンドです。このルールは、ポート80宛に送られてくるパケットを、代わりのターゲット・ポート8080に変更する働きをしますので、それ以外の用途でポート8080がブロックされないかぎりは、うまく機能します。このコマンドを実行すると、送られてくるリクエストの処理がすぐに行えるようになるはずです。

リスト2. iptablesのリダイレクション・ルール
/sbin/iptables -t nat \
  -A PREROUTING -j REDIRECT -p tcp \
  --destination-port 80:80 --to-ports 8080

このルールは、システムをリスタートするまでの間有効です。このリダイレクションをずっと有効にしておきたいときは、

/sbin/service iptables save

を実行して、現在のiptablesの構成を保存する必要があります。


Tomcatの自動起動

TomcatなどのJavaサービスを実行するときのもう1つの問題に、システム立ち上げ時にアプリケーションを自動起動し、システムを終了する際にアプリケーションも自動的に終了させる (すなわち、デーモンとして実行する) には、どうすればよいかということがあります。経験豊富なLinuxユーザーなら、そのやり方はよくわかっていることでしょうが、ここでは、Linuxの経験の浅い人のために、基本的なことを押さえておきたいと思います。

これを皆さんの個人的なシステムで実行し、Tomcatのファイルやディレクトリーを、Tomcatを直接実行するときと同じようにアクセスしたいというのであれば、皆さん自身のユーザー名を使って、このセットアップを行ってもよいでしょう。しかし、一般に、デーモンとして実行されるようなものについては、別のユーザーをセットアップするのが上手いやり方です。Tomcatでそうするには、

/usr/sbin/useradd tomcat

を、ルートとして実行します。これによって、tomcat というユーザー・アカウントが作成されるとともに、Tomcatのインストールに使うことのできるホーム・ディレクトリーが /home/tomcatに作成されます。作成されたホーム・ディレクトリーは、所有者がtomcat ユーザーとなり、通常は、このユーザーだけがアクセスを許されます (もちろん、ルートは別として)。他のアカウントがTomcatのインストールにアクセスできるようにしたい場合には、許可にグループ・アクセスを含めるようにし、tomcatグループを他のアカウントに追加すればよいでしょう。

いずれにせよ、Tomcatをデーモンとして実行するためには、サービス構成ファイルを /etc/init.dディレクトリーに設ける必要があります。ファイルの名前はtomcatとしておけばよいでしょう。リスト3は、サービス構成ファイルがどんなものなのかを示す例です。このファイルでは、Tomcatが /home/tomcatにインストールされていて、サーバーの起動および終了を処理するための1対 (つい) のシェル・スクリプト・ファイル (tcstart.shおよびtcstop.sh) が同じディレクトリーに含まれているものとしています。これは、Tomcatの本当の起動スクリプトまたはシャットダウン・スクリプトを実行する前に、Tomcatが必要とする環境変数 (JAVA_HOMEやJDK_HOMEを含む) を設定しておくために必要なファイルです。

リスト3. Tomcatのサービス定義
#!/bin/bash
#
# tomcat       Starts Tomcat Java server.
#
#
# chkconfig: 345 88 12
# description: Tomcat is the server for Java servlet applications.
### BEGIN INIT INFO
# Provides: $tomcat
### END INIT INFO
# Source function library.
. /etc/init.d/functions
[ -f /home/tomcat/tcstart.sh ] || exit 0
[ -f /home/tomcat/tcstop.sh ] || exit 0
RETVAL=0
umask 077
start() {
        echo -n $"Starting Tomcat Java server: "
        daemon su -c /home/tomcat/tcstart.sh tomcat
        echo
        return $RETVAL
}
stop() {
        echo -n $"Shutting down Tomcat Java server: "
        daemon su -c /home/tomcat/tcstop.sh tomcat
        echo
        return $RETVAL
}
restart() {
        stop
        start
}
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload)
        restart
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart}"
        exit 1
esac
exit $?

以下はtcstart.shの例で、実際には、インストールに合わせて変更して使用します。

リスト4. tcstart.shの例
#!/bin/bash
export JDK_HOME=/usr/java/jdk
export JAVA_HOME=/usr/java/jdk
#run the startup script from Tomcat installation
/home/tomcat/server/bin/startup.sh

chroot: セキュリティー最高の牢獄

本物の被害妄想者なら、Java言語サービスの安全を確保するのに、さらに踏み込んだ方法を採用することもできます。これは、何らかの形でローカルなファイル・システムにアクセスできるようにするサービスの場合にとくに有効です。JVMの実行時の安全性を確保するための機能では、すでにファイル・システムにアクセスする権利を得ているアプリケーションが、ユーザーの意図したもの以外のファイルにアクセスするのを防止することはできません。Tomcatの場合、HTTPサーバーとして使用される性格上、ファイル・アクセスは不可欠です。Tomcatは、各Webアプリケーションに渡すファイルを、そのアプリケーションのディレクトリーに含まれるものだけに制限するのが普通ですが、サーブレット・アプリケーションは、この制限をすり抜けることができます。これは、TomcatがApacheなどのフロント・エンドのWebサーバーといっしょに実行されている場合でも同じです。

chrootを使えば、Tomcat (およびTomcatの下で実行されているすべてのWebアプリケーション) が、サーバー用に確保されている領域以外のものにアクセスするのを阻止することができます。chrootは、決してJavaアプリケーション専用というわけではありませんが、JVMが提供するセキュリティーに最終的なラッパーをかける手段として便利です。ここでは、chrootの考え方に不案内な人のために、そのセットアップ方法の主なところだけを紹介しておきます。

chrootの行っていることは、Javaコードの実行に使用されるJVMのサンドボックスに似ていますが、chrootのほうは、ファイル・システム自体を対象とします。chrootは、どこか指定されたところを実際上のルート・ディレクトリーとみなしてコマンドを実行します。実行されるコマンド (アプリケーションなどの他のコマンドを実行するシェル・スクリプトであってもよい) は、ファイル・システムの中の、指定された実際上のルート・ディレクトリー以下の部分にしかアクセスできません。そのコマンドにとって、ファイル・システムのそれ以外の部分は、まさに存在しないことになります。

Tomcatなどのアプリケーションがchrootを使用するためには、新しい仮想ルートに基本的なシステム・アプリケーションやライブラリー (Java JDKの実際のインストールなど) をある程度コピーしておく必要があります。そのためには、どの程度の手間をかけて必要なものを最小限に切り詰めるかで違ってきますが、大きな領域 (100メガ・バイトから1ギガ・バイト、もしくはそれ以上) が必要となったりします。セットアップ方法としては、/bin、/lib、/usr/binおよび /usr/libのディレクトリー・ツリーをJavaのインストールとともに新しいルートにコピーし、所有者兼すべてのファイルに対する唯一の書き込み権保有者として、ルートを保持するというのが一番簡単なやり方ですが、その場合、スペースの無駄も一番多くなります。ディスクの使用量を最小限に抑えたいのであれば、chroot内で必要とするコマンド (実際に必要なJavaのインストールの他、ls、rm、echo、catといった基本的なコマンドなど) およびこれらのコマンドで使用されるライブラリー (これは、lddを使って探し出すことができる) だけを選択的にコピーしてくればよいでしょう。

次に、他のディレクトリーも、正規のシステムの削減バージョンとして、いくつか作成する必要があります。たとえば、/dev/nullおよび /dev/zeroからなる /dev、/etc/passwdと /etc/groupのファイルを編集したバージョン (rootとtomcat関係の項目だけを残したもの)、それに多分hostsも入れた /etcなどです。多重プロセッサ・システムを使っている場合には、新しいルート・ディレクトリー下に /procシステムもマウントしておく必要があります。JVMは、これを使って、プロセッサー間の調整を行うからです。

最後に、chroot実行後も、ユーザーとしてtomcat を実行できるようにするためには、su コマンドに、仮想ルートで実行できるバージョンを用意する必要があるかもしれません (多くのディストリビューションでは、これを通常のコマンドで実行できないため)。それには、GNUプロジェクトからsh-utilsのソースを入手し、このソースから直接su を構築して、新しいルートの /binディレクトリーにそれをコピーすればよいでしょう。

以上のすべてのセットアップができたら、

/usr/sbin/chroot /home/tomcat /bin/su tomcat

を、ルートとして実行してみてください (新しいルート・ディレクトリーが /home/tomcatであるとしてのもの)。正しくセットアップが行われていれば、これによって、新しいルートの中でtomcat が実行されるはずです。Tomcatを起動したり、終了したりするためのスクリプトも実行してみてください。すべてうまく動作することが確認できたら、最後に、リスト3のTomcatのサービス定義を変更します。su コマンドをtcstart.shとtcstop.shのスクリプトに移動して、su の代わりにchrootを使用するようにします。また、これらのスクリプトがルートによってしか変更できないようにする必要もあります。

以上の概略からおわかりだと思いますが、これは、臆病な人向きの方法ではありません。これまでchrootを使ったことがないけれども、この方法で行ってみようと思う方なら、きっとネット上のchrootに関する文献で詳しく調べてみたいと思われるのではないでしょうか。でも、Javaのサーバー・コードを隔離するには、これこそが最善の方法であり、その結果、心の平安が得られるのであれば、努力の甲斐があるというものです。


まとめ

LinuxとJavaの2つのテクノロジーは、いずれも、ビジネス・システムの分野で市場シェアを伸ばしています。Linuxはオープン・ソースであり、Javaテクノロジーはライセンス付き提供であるという点で哲学的な差はありますが、両者は、実は調和します。Linuxは、Javaアプリケーション、とくにサーバー・タイプのアプリケーション用として、良好な配備環境を提供しますし、Javaテクノロジーは、エンタープライズ・ソフトウェア開発用の第一級の手法として確立され、認識されています。

Javaテクノロジーは、サーバー・アプリケーションによくある脆弱さの原因の多くを排除していますので、正しい対策を講じれば、Linuxで実行されるJavaサーバー・アプリケーションは、非常に高度な (ネイティブ・アプリケーションよりも高い) セキュリティーを実現することができます。Javaテクノロジーがクロス・プラットフォームという性格を備えているということは、Linuxにすぐにでも対応できるエンタープライズ向けの開発業者やアプリケーションが膨大な数に上ることを意味しています。Javaサーバー・アプリケーションは、サーバー市場で伸びつつあるLinuxのシェアに対して大きな役割を果たし始めたところであり、この傾向は、今後の両方のテクノロジーをますます促進するばかりです。

多重プロセッサー・システムでJavaをchrootする場合の問題の解決方法として /procファイル・システムを紹介してくれたMiles Sabinに謝意を表します。

参考文献

  • Apache Tomcat には、このApache Software FoundationのJava言語によるWebサーバー・プロジェクトについての詳細が示されています。
  • 著者の最近のオープン・ソースJavaテクノロジー・プロジェクトであるXMLデータ・バインディング・フレームワークのJiBX も覗いてみてください。
  • IBM HTTP Server for iSeriesには、TomcatをベースにしたサーブレットとJSPのエンジンが含まれています。
  • Tomcatに関しては、他にも以下のdeveloperWorks の記事があります。
  • WebSphere Application ServerとTomcatを比較しているIBM Redpaper もお読みください。
  • developerWorks には、IBM Developer Kit for Linux という文書もあります。
  • Linux用の最新のJavaテクノロジーは、サン・マイクロシステムズ社から入手できます。
  • Blackdown Project は、オープン・ソース・コミュニティーと商用ソフトウェア業界とが協力してできたJavaテクノロジーのライセンス実装を紹介しています。
  • GPL形式のKaffe implementation of a Java Virtual Machine では、制約のないオープン・ソースを手に入れることができます。
  • GCJ を使えば、Java言語のソース・コードまたはコンパイル済みのバイト・コードをネイティブ・マシン・コードに変換することができます。
  • Go Mono を訪れれば、C# とCommon Language Infrastructureのオープン・ソース版を試してみることができます。
  • 自分のシステムで、アクセス制御、サービス・リクエストのロギング、リクエストのリダイレクションを行ってみたいという方は、xinetd を訪れてみてください。
  • Linux 2.4でのファイアウォールの作成やネットワーク・アドレス変換 (Network Address Translation)、パケット・マングリングについては、Netfilter のサイトで調べることができます。
  • アカウント管理によってLinuxのセキュリティーを高めるための現実的な方法が、実践的Linuxセキュリティーに紹介されています。
  • developerWorks のLinuxゾーンには、他にもLinux開発者向けの参考文献が多数掲載されています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Java technology, Open source
ArticleID=230692
ArticleTitle=LinuxのJavaサービスに対する安全性を高める
publish-date=04012003