第2回　Webサイト設計時の考慮点を知ろう

樫山友一
2002/3/5

---

　前回「Webサイトの構成とJ2EEサーバ」では、J2EEを用いて開発されるWebサイトがクライアント／サーバシステムの場合とどのように違うのかを説明し、その概要を解説しました。今回は、J2EEベースのWebサイトの開発をスタートするときに要件としてまとめておく事項をセキュリティの観点も交えながら解説します。

Webサイト開発時に必要な情報

　Webサイトの開発プロジェクトでは、コンピュータ構成やプラットフォーム（オペレーティングシステムなど）を決めるうえで、必要とされる項目を以下に挙げます。これらの項目は、J2EEアプリケーション・サーバを利用するか否かや、どのベンダのJ2EEアプリケーション・サーバ製品を利用するかといった判断基準にもなります。

(1)アクセス数

　実際にどのくらいのユーザーがページにアクセスするのかです。通常は、ページビュー（時間当たりのページの参照数）などで表します。これは、設計時のハードウェアの見積もりやテストの段階で負荷をどのくらいかけるかといった指標となるので、なるべく正確に見積もることが必要です。

図1 Webサイトへのアクセス数

(2)データ量

　Webサイトの扱うデータ量です。1回のアクセスで使用するデータの量が多い場合は、アプリケーション・サーバで利用するメモリの量が問題となることがあります。実際にデータベースに入るデータの量と一定時間の間にどのくらいの量のデータが参照されるのかを明らかにしておく必要があります。

図2 Webサイトで扱うデータ量

(3)信頼性

　規模とは少し視点が異なりますが、結果としてWebサイトの構成が大きくなることがあるので、ここで記述しておきます。Webサイトのサービスの停止時間がどのくらい許されるかを明らかにすることから始まります。夜の間サービスを止めてもよいとか、停止は24時間許されないなど、ビジネス的な視点での仕様から決まってきます。

サーバの構成

　以上のようなことからいくつかの視点でサーバの構成を考えてみましょう。構成は、前述した項目と密接に関係してきます。特にJ2EEアプリケーション・サーバの構成と合わせて考えることが重要です。

(1)サーバ自体のセキュリティの視点からの構成

　まず、一般的なJ2EEアプリケーション・サーバの構成を考えてみましょう。通常J2EEアプリケーション・サーバは、HTTPサーバと一体になっています。中には、HTTPサーバにApache（ http://www.apache.org）を利用しているものもありますが、インストールした状態では、ApacheはJ2EEアプリケーション・サーバの一部となっています。図3に構成の概要を示します。

図3　一般的なJ2EEアプリケーション・サーバの構成

　通常は、Servlet／JSPコンテナ、EJBコンテナ、HTTPサーバがセットでインストールされます。Servlet／JSPはHTTP経由でしかアクセスできませんが、EJBはRMIでアクセスすることが可能です。また、J2EEアプリケーション・サーバを管理するためのインターフェイスがそれぞれの製品に依存した形で利用できるようになっています。よって、J2EEアプリケーション・サーバにはHTTP以外にさまざまなインターフェイスが利用できるようになっており、これをそのままファイアウォールの外に出すことはとても危険です（たとえ、HTTPのポートだけを開放していたとしても）。そこで、インターネットで利用するためにはいくつかの利用形態が考えられます。

関連記事 Webアプリケーションにおけるサーバ・サイドJavaの効果的な利用 前編／後編（Java Solution）

　最初に最も単純な構成から考えてみましょう。図4にその構成を示します。ファイアウォール（1）は、インターネットからのアクセスであるHTTPのみを通過させます。J2EEアプリケーション・サーバにネットワークのインターフェイスを2つ用意して、一方をファイアウォール（1）からの通信に、一方をファイアウォール（2）を通過する通信に利用します。Webサイトでは通常データベースを利用するのでデータベースは、一番セキュリティレベルの高い位置に配置します。ファイアウォール（2）では、J2EEアプリケーション・サーバのアドレスからのアクセスだけを通過させるような設定やデータベースへのアクセスのプロトコルのみを通すような設定をしておきます。より単純な場合は、ファイアウォール（2）を省略することもあります。

図4　サーバ構成（1）

　どちらの場合も、J2EEアプリケーション・サーバのコンピュータ自体がハッキングされてしまったような場合は、データベースを直接参照されてしまいます。そのためにより高いセキュリティを実現するための方式を図5に示します。ファイアウォール（1）とファイアウォール（2）の間はDMZ（Demilitarized Zone）と呼ばれる領域となります。これは、企業内のLANとインターネットの間に当たる領域で、インターネットへ向けてのサービスを行うサーバが配置されます。この構成では、ファイアウォール（2）の内側は企業内のLANにすることができるため、J2EEアプリケーション・サーバやデータベース・サーバのメンテナンスを社内のLANから行うことができます。

　ファイアウォール（１）は、DMZに配置されるサーバがサービスを行うためのプロトコルだけを通過させます。ファイアウォール（2）は、DMZに配置されたサーバからLANへのアクセスが必要なプロトコルのみを通過させます。また、J2EEアプリケーション・サーバへのアクセスをHTTPサーバからに限定しておけば、DMZ内のHTTPサーバに侵入されたような場合でも、重要なデータが入っているデータベースへのアクセスはできないので2重の防御を行うことが可能です。メンテナンスの面からも有利な点があります。J2EEアプリケーション・サーバ製品の管理やメンテナンスをするためのプロトコルやポート番号が分けられている場合があります。その場合は、社内のLANからだけ管理のためのアクセスを許可することができます。

図5　サーバ構成（2）

関連記事 ファイアウォールの基礎 第1回（Security&Trust）

(2)信頼性とパフォーマンスを重視したクラスタ構成

　大規模なWebサイトや信頼性が重視されるWebサイトでは、クラスタ構成を取ることが一般的になっています。では、J2EEアプリケーション・サーバのクラスタとはどのようなものなのでしょうか？ 図6にその概要を示します。インターネットからのアクセスは、一度HTTPサーバで受けられ、その後ろにあるJ2EEアプリケーション・サーバに投げられます（通常このHTTPサーバをプロキシと呼びます）。プロキシは、設定されたアルゴリズムに従い、処理をJ2EEアプリケーション・サーバに振り分けます（このアルゴリズムには、ランダムや重み付けなどがありますがJ2EEアプリケーション製品により利用できるものが異なります）。プロキシは、J2EEアプリケーション・サーバが処理を行うことができるかを知る機能があるため、もし1台のJ2EEアプリケーション・サーバが停止していた場合には、処理を稼働しているJ2EEアプリケーション・サーバに振り分けることができます。そのために、障害でJ2EEアプリケーション・サーバが停止しても、Webサイトとしては処理を続行することが可能です。

関連記事 止まらないWebシステム構築の基礎知識　第1回（Java Solution）

　また、クラスタをサポートしているJ2EEアプリケーション・サーバは、HTTPのセッションもフェイルオーバー（障害があったサーバから処理を引き継ぐこと）が可能なので、ログインを必要とするショッピングサイトのような場合でも、J2EEアプリケーション・サーバの障害をユーザーから隠すことが可能です。

図6　J2EEアプリケーション・サーバのクラスタ

　また、パフォーマンスの点からも有利です。Webサイトの内容にもよりますが、通常データベースよりもJ2EEアプリケーション・サーバでの処理の方が負荷が高くなる傾向にあります。よって、複数のJ2EEアプリケーション・サーバに処理を分散することができれば、Webサイト全体としてのパフォーマンスが上がります。クラスタ構成は、前述のDMZのサーバ構成と相性が良い構成です。プロキシは通常のHTTPサーバと同じ動作をするのでプロキシをDMZに配置することにより、セキュリティ的にも強く、信頼性、パフォーマンスともに良い構成を取ることが可能です。

J2EEの視点でのセキュリティ

　ここまでは、J2EEアプリケーション・サーバをどのように配置するとセキュリティ的に有利になるかの解説をしましたが、ここからはJ2EEアプリケーション・サーバ自体がどのようなセキュリティの機能を持っているかを解説します。開発するアプリケーションのセキュリティポリシーは開発の早い段階で決めておく必要があります。これは、設計にも影響を及ぼすからです。

(1)オペレーティングシステム、Javaのレベルでのセキュリティ

　J2EEアプリケーション・サーバ自体の前に、オペレーティングシステムやJava自体のセキュリティについて考えましょう。オペレーティングシステムのセキュリティは、WindowsとUNIXでは設定の方法が異なりますし、UNIXでもベンダごとに設定の方法は違います。この解説はとても膨大になってしまうために、ここでは割愛させていただきます。特に、DMZに配置されるコンピュータに関しては、セキュリティレベルの高い設定が要求されるので、注意が必要です。

　Javaのセキュリティの機能で、J2EEアプリケーション・サーバの構成と直接関係するものは、Java VMの起動時に指定するセキュリティのポリシーファイルです。ここでは、ディレクトリやファイル単位でのアクセスコントロールを行うことができます。具体的には、あるディレクトリ配下だけ書き込みの権限をJ2EEアプリケーション・サーバに与えるといったアクセスコントロールや、J2EEアプリケーション・サーバが外部プログラムを起動するような場合の制限を付けることができます。

(2)ログイン制御

　Webサイトでも個人情報を扱うようなサイトでは、ログインを必要とします。通常のログインは、ユーザーIDとパスワードによって行われるため、WebサイトではユーザーIDとパスワードをデータベースに保存して管理する必要があります。J2EEアプリケーション・サーバには、このログインのためのユーザーIDとパスワードの管理を外部のシステムと連携させるようなしくみを持った製品があります。具体的に連携させるものとしては以下のようなものが挙げられます。

• LDAP
• Windowsのユーザー管理
• UNIXのユーザー管理
• データベースにあるユーザーIDとパスワードとの連携

図7　パスワードのチェックのしくみ

(3)コンポーネント単位でのセキュリティ

　J2EEアプリケーション・サーバは、コンポーネントやアプリケーションといった単位で内部のセキュリティをコントロールすることが可能です。実際に、セキュリティの対象となる単位を以下に示します。

　実際には、それぞれにロールといわれる名前を登録します。各ユーザーはロールに属していて、そのロールに属しているユーザーだけがコンポーネントやアプリケーションを利用することができます。

URL	特定のURLや、URLにある文字列を含むページにロールを割り当てることが可能です
EJB	EJBごとにロールを割り当てることが可能です
Webアプリケーション	Webアプリケーションごとにロールを割り当てることが可能です
EAR (Enterprise Archive)	EARは、EJBやWebアプリケーションを1つのアプリケーションとしてまとめるための仕様です。EARにするとWebアプリケーションとEJBで1つのアプリケーションの境界を設定することが可能です。EARごとにロールを割り当てることが可能です

　上記のようにコンポーネントやアプリケーションごとにロールを設定すれば、複数のアプリケーションを1つのJ2EEアプリケーション・サーバ内に同居させたり、ユーザーのレベルや権限を設定して、それぞれに参照できるデータや処理を制限するといったセキュリティをかけることが可能になります。

　このようにセキュリティの構成は、J2EEアプリケーション・サーバ内の構成にかかわってきます。よって、早い段階でどのようなポリシーでWebサイト内のページに制限を加えるかを考えておく必要があります。

◆

　今回は、J2EEアプリケーション・サーバを用いた開発をスタートする場合に、何を明らかにしておけばよいのか明らかにした後、サーバの構成やセキュリティについてはどのように考えればよいのかを解説しました。次回は、実際にJ2EEアプリケーション・サーバを用いた開発の最初のステップに入ります。

プロフィール

樫山友一（かしやま ゆういち） 大手電機メーカー研究所でオブジェクト指向によるシステム開発に従事する。1996年よりJavaへの取り組みをはじめ、J2EEアプリケーションサーバを活用したWebシステム構築のコンサルタントとして多数のプロジェクトを手掛ける。 2001年3月にイーズ・コミュニケーションズ株式会社の設立に参加し、最高技術責任者に就任。 著書に「わかりやすいUML入門」、「Webサイトがわかる本」（いずれもオーム社）がある。

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）