前へ
目次
索引
DocHome
次へ
|
| iPlanet Application Server 管理者ガイド |
第 5 章 iPlanet Application Server の保護
この章では、iPlanet Application Server セキュリティを実装する方法について説明します。
セキュリティについて
アプリケーションセキュリティを実装するには、アプリケーション開発者とサーバ管理者の協力が必要です。アプリケーション開発者は、実装するセキュリティレベルを決定し、そのレベルをアプリケーションに実装する責任があります。サーバ管理者は、アプリケーションを使うユーザおよびグループを管理する責任があります。管理者には、アプリケーション内のアプリケーションコンポーネントへの認証を管理する責任もあります。J2EE 標準コンポーネントを使う Java アプリケーションでは、ロールを介して認証が実装されます。ロールは、iPlanet Application Server Deployment Tool を使って配置時に作成され、iPlanet Application Server Administration Tool により管理されます。Deloyment Tool の詳細は、このツールに付属のオンラインヘルプシステムを参照してください。C++ アプリケーションでは、LDAP に保存されたアクセスコントロールリストを介して認証が実装され、iASAT によって管理されます。
この章では、ユーザおよびグループを設定する方法と、設定されたユーザおよびグループを使ってアプリケーションを保護する方法について説明します。ユーザエントリが iPlanet Directory Server にどのように保存され、iPlanet Console および LDIF を使ってどのように管理されるかについても説明します。この節には次のトピックがあります。
このマニュアルの内容
このマニュアルの内容
この章では、iPlanet Console を使ったユーザおよびグループの管理方法に加えて、iPlanet Application Server のインスタンスに関連する Directory Server の設定時に実行が必要な基本的起動タスクについて説明します。iPlanet Directory Server および iPlanet Console の詳細は、各製品のマニュアルを参照してください。iPlanet Application Server のインスタンスにインストールされた Directory Server のマニュアルは、次の場所にあります。
iASInstallDir/manual/en/slapd/
iPlanet Console のマニュアルは、次の iPlanet の Web サイトで入手可能です。
http://docs.iplanet.com/docs/manuals/console.html
LDAP とは
iPlanet Application Server の各インスタンスは、Directory Server を使って、ユーザおよびグループについての情報を含む共有サーバ情報を保存します。Directory Server は Lightweight Directory Access Protocol (LDAP) バージョン 2 および 3 をサポートしています。LDAP は TCP/IP 上で動作するオープンディレクトリアクセスプロトコルです。グローバルなサイズおよび多数のエントリに拡張できます。Directory Server を使うと、すべてのアプリケーションサーバがネットワーク経由でアクセスできるディレクトリ情報の単一のセントラルリポジトリに、企業の情報を保存できます。iPlanet Directory Server は iPlanet Application Server の各インスタンスとともにインストールされます。
iPlanet Application Server に設定可能な Directory Server のタイプは、次のとおりです。
マスタ LDAP サーバ: マスタデータを維持する LDAP サーバ
Consumer LDAP サーバ: マスタ LDAP サーバによって維持されるデータのコピーが保存される LDAP サーバ。iPlanet Application Server に対して複数の Consumer LDAP サーバを設定できる
プライマリ LDAP サーバ: 設定情報について iPlanet Application Server に設定される最初の LDAP サーバ
バックアップ LDAP サーバ: iPlanet Application Server に設定されるセカンダリ LDAP サーバ。プライマリ LDAP サーバが失敗した場合に、iPlanet Application Server はこのサーバに接続する。iPlanet Application Server に対して複数のバックアップ LDAP サーバを設定できる
iPlanet Console とは
iPlanet Console はスタンドアロン Java アプリケーションです。Directory Server に登録されているすべてのリソースおよびアプリケーションを検索して、グラフィカルインターフェイスに表示します。iPlanet Console はすべてのサーバから独立して機能し、企業に接続されているすべてのコンピュータまたはワークステーションから使うことができます。iPlanet Console は iPlanet Application Server の各インスタンスとともにインストールされます。iPlanet Console を使って iPlanet Application Server のユーザおよびグループを管理します。また、iPlanet Application Server のローカルインスタンス(iPlanet Console と同じマシンにインストールされた iPlanet Application Server のインスタンス) の場合のみ、iPlanet Application Server Administration Tool を起動することもできます。iPlanet Application Server のリモートインスタンスは、コマンドラインまたは Windows NT の「スタート」メニューから起動する必要があります。
ユーザおよびグループの保存と管理
作成する各ユーザおよびグループについて指定する情報は、Directory Server に保存されます。Directory Server に保持された情報は、アプリケーションが複数のサーバによってサポートされているときは、すべてのアプリケーションサーバに共有されます。.
セキュリティの実装
iPlanet Console による Directory Server へのエントリの追加
iPlanet Console を使ったデータベースエントリの変更
セキュリティの実装
アプリケーションへのアクセスにユーザ名とパスワードの認証が必要な場合、ユーザ名とパスワードは Directory Server に保存されていなければなりません。アプリケーションは、ユーザ認証を行うアプリケーションコンポーネント (通常は Servlet) を呼び出すことによって、ユーザ認証プロセスを起動します。そのあと、ユーザのログイン権限は、Directory Server に保存されたユーザリストと照合して確認されます。
認証プロセスはユーザ名とパスワードに基づいてアプリケーションへのアクセスを確認します。認証を実装するには、アプリケーションのすべてのユーザに関して、ユーザ名とパスワードを保持するユーザプロファイルを作成する必要があります。この手順については、「iPlanet Console による Directory Server へのエントリの追加」で説明します。
ユーザの認証が成功すると、アプリケーションの種類に従って特定のアプリケーションコンポーネント実装にアクセスします。アプリケーションの種類には、J2EE 標準コンポーネントを使う Java アプリケーションと C++ アプリケーションを使う Java アプリケーションがあります。
J2EE アプリケーションの認証
アプリケーションセキュリティを確保するアプリケーションコンポーネントへのアクセスは、配置記述子 XML ファイルに定義された宣言ロール情報に従います。セキュリティは、J2EE によって提供される isCallerInRole() のようなセキュリティ API を使って、開発時にプログラムで定義することもできます。詳細については、『iPlanet Application Server 開発者ガイド』を参照してください。
C++ アプリケーションの認証
アプリケーションセキュリティを確保するアプリケーションコンポーネントへのアクセスは、iPlanet Application Server Administration Tool にあるアクセスコントロールリストを使い、宣言によって管理されます。iPlanet Application Server の各インストールに含まれる LDAP JDK を使うことにより、開発時にセキュリティをプログラムで定義することもできます。詳細については、『iPlanet Application Server 開発者ガイド』を参照してください。
iPlanet Console による Directory Server へのエントリの追加
iPlanet Directory Server のユーザエントリおよびグループエントリを作成するには、iPlanet Console を使用します。ユーザエントリには、ディレクトリ内の個人またはオブジェクトについての情報があります。1 つのグループは、共通の属性を共有するすべてのユーザで構成されます。たとえば、ある部署のユーザすべてを同じグループに所属させることができます。
識別名 (DN) とは何か
Directory Server では、企業の各ユーザおよび各グループは、識別名 (DN) によって表されます。DN は識別属性を含むテキスト文字列です。ディレクトリ内のユーザおよびグループのデータベースを変更するときには必ず DN を使います。たとえば、ディレクトリエントリを作成または変更するとき、アクセスコントロールを設定するとき、およびメールやパブリッシングなどのアプリケーションに関するユーザアカウントを設定するときは、毎回 DN 情報を指定する必要があります。iPlanet Console のユーザおよびグループのインターフェイスは、DN の作成や変更に役立ちます。次に iPlanet Communications Corporation の社員の DN の例を示します。
uid=doe,e=doe@iplanet.com,cn=John Doe,o=Sun Microsystems,c=US
この例の各等号 (=) の前の略語には、次の意味があります。
DN には、さまざまな名前-値ペアが含まれている場合があります。これらは、LDAP をサポートするディレクトリの証明書サブジェクトおよびエントリの両方の識別に使われます。
SSL 認証と識別名
iPlanet Application Server の SSL 相互認証では、X509 SSL クライアント証明書内にある識別名を使用します。アプリケーションサーバは、有効なクライアント証明書が提示されると、そこに含まれるサブジェクト DN を調べて、そのクライアントの認証に使用する候補フィールドを探します。iPlanet Application Server は、以下のフィールドを一意性の順に探し、選択した証明書の属性の値と一致する uid フィールドを持つ Directory Server エントリを検索します。
cn
iPlanet Console を使ってユーザエントリを作成するには
ユーザセキュリティは、アプリケーションのユーザが小人数の場合に最適です。アプリケーションにアクセスする各ユーザに関するユーザプロファイルを作成する必要があります。ユーザを作成するには、Directory Server 管理者または必要なパーミッションを持つユーザである必要があります。
iPlanet Console を使って iPlanet Directory Server に新しいユーザエントリを作成するには、次の手順を実行します。
Windows の場合
「User ID」テキストフィールドに、iPlanet Application Server インストール時に指定したユーザ名を入力します。
- Windows の「スタート」メニューから「プログラム」>「iPlanet Server Products」>「IPlanet Console 5.0」の順にクリックします。
- Solaris の場合
- iASInstallDir パスに移動し、次のコマンドを入力します。
- ./startconsole
- 「IPlanet Console」ログインダイアログボックスが表示されます。
「Password」フィールドに、iPlanet Application Server のインストール時に iPlanet Console Administration Server に対して指定したパスワードを入力します。次の図のように、iPlanet Console のメインウィンドウが表示されます。
- ユーザおよびグループの作成方法については、iPlanet Console 5.0 に含まれるマニュアルを参照してください。
iPlanet Console を使ったデータベースエントリの変更
ユーザまたはグループデータを変更する前に、まずユーザおよびグループの検索機能を使ってユーザまたはグループエントリをユーザディレクトリで検索する必要があります。次に、メニューツールバーから操作を選択してエントリを変更できます。実行する操作は「Search」リストのすべてのユーザに適用されます。詳細は、「iPlanet Console」のマニュアルを参照してください。
LDIF による Directory Server へのエントリの追加
Directory Server は、LDAP Data Interchange Format (LDIF) を使って、ディレクトリおよびディレクトリエントリをテキストフォーマットで記述します。LDIF は通常、ディレクトリデータベースを最初にビルドしたり、多数のエントリをまとめてディレクトリに追加したりするときに使います。適切な LDIF 更新ステートメントとともに ldapmodify コマンドを使って、エントリを追加または編集することもできます。LDIF を使ってデータベースにエントリを追加するには、LDIF ファイルにエントリを定義したあとに、Directory Server から LDIF ファイルをインポートします。
LDIF エントリの書式化
LDIF は、空白行によって区切られた 1 つまたは複数のディレクトリエントリから構成されます。LDIF エントリは、オプションのエントリ ID、必須の識別名、1 つまたは複数のオブジェクトクラス、および複数の属性定義から構成されます。LDIF で表されるディレクトリエントリの基本書式は次のとおりです。
attribute type[;subtype]:attribute value
attribute type[;subtype]:attribute value
DN と 1 つ以上のオブジェクトクラス定義を指定する必要があります。さらに、そのエントリに関して定義するオブジェクトクラスに必要なすべての属性が含まれている必要があります。他の属性およびオブジェクトクラスはすべてオプションです。オブジェクトクラスおよび属性はどのような順序でも指定できます。コロンのあとの空白もオプションです。標準オブジェクトクラスおよび属性については、次のサイトの iPlanet Directory Server のマニュアルを参照してください。
http://docs.iplanet.com/docs/manuals/directory.html
ldapmodify によるデータベースエントリの変更
既存の Directory Server データベース内のエントリを変更するには、ldapmodify コマンドラインユーティリティを使います。ldapmodify では、入力した識別名およびパスワードを使って、指定されたサーバへのコネクションを開き、指定されたファイルに含まれている LDIF 更新ステートメントに基づいてエントリを変更します。ldapmodify では LDIF 更新ステートメントを使うので、ldapdelete によって実行可能なすべてのことを実行できます。Directory Server のコマンドラインユーティリティのほとんどは 1 か所に保存されています。それらのユーティリティは次のディレクトリにあります。<iASInstallDir>/bin/slapd/server
コマンドラインツール ldapdelete、ldapmodify、および ldapsearch は次のディレクトリに保存されています。
次の例は、LDIF ファイルにユーザを追加するためのコマンドです。
ldapmodify -h myserverhost -p 389 -D "Directory Manager" -w admin -a -f MyUsersFile
プログラムによるエントリの作成
iPlanet Application Server の各インストールに含まれる LDAP JDK を使うアプリケーション内では、プログラムでエントリを作成することもできます。詳細は、『開発者ガイド (Java)』を参照してください。
アプリケーションコンポーネントへのアクセスに対する認証の設定
アプリケーションコンポーネントへのアクセスに対する認証は、アプリケーションの種類によって異なります。
Java アプリケーション (J2EE 標準コンポーネントを使う) では、ロールを介して認証が設定される。「ロールベースの認証の設定 (J2EE アプリケーションの場合)」を参照してください。
この節には次のトピックがあります。C++ アプリケーションでは、認証はアクセスコントロールリストのパーミッションによって設定される。「アクセス制御リスト認証の設定 (C++ アプリケーションの場合)」を参照してください。
ロールベースの認証の設定 (J2EE アプリケーションの場合)
ロールベースの認証の設定 (J2EE アプリケーションの場合)
アプリケーションコンポーネントのロールが、モジュール内のすべてのアプリケーションコンポーネントにグローバルに設定されます。Administration Tool から、ロールをアプリケーションモジュールに追加して、ロールに属するユーザおよびグループを設定できます。要求者があらかじめ定義されたロールのメンバーである場合は、モジュール内のすべてのアプリケーションコンポーネントにアクセスできます。ユーザがロールのメンバーでない場合は、アプリケーションがユーザにログインし直すように指示したり、アプリケーションを終了するように要求したり、またはアプリケーションの異なる部分を割り当てたりできます。
EJB および Servlets に関するロールの管理
配置されたアプリケーションのロールを管理するには、iPlanet Application Server Administration Tool (iASAT) を使う必要があります。ロールを管理するときに、個々のユーザをメンバーとしてロールに追加しないで、ユーザが属するグループを指定してグループだけをロールに追加できます。これは、個々のユーザベースのセキュリティを使っている場合に有効です。ユーザが変更されたときに更新されたユーザの管理情報をロールに保存できます。たとえば、Web バンクアプリケーションのユーザを作成して、その後あるユーザがすべてのアカウントを閉じる場合は、グループおよびすべてのロールからユーザを削除するのではなく、該当するグループだけからそのユーザを削除する必要があります。
注 Servlets および EJB のロールは、配置前の配置記述子 XML ファイルに作成されます。詳細は、Deployment Tool に付属されているオンラインヘルプを参照してください。
iASAT ツールバーの「アプリケーション」をクリックして「アプリケーション」ウィンドウを開きます。
「アプリケーション」ウィンドウの左側のペインで、アプリケーションが配置された iPlanet Application Server インスタンスを展開します。
次の図のように、アプリケーションフォルダを開き、Servlet または EJB アイコンを強調表示します。
「アプリケーション」ウィンドウの右側のペインで「ロール」タブをクリックして、この EJB/Servlet に対してすでに定義されているロールとロールメンバーを調べます。
管理するロールを強調表示し、ウィンドウの下にある「ロールを編集」ボタンをクリックします。
ロールにグループおよびユーザを追加するには、次の手順を実行します。
ロールからグループまたはユーザを削除するには、「ロール内のユーザ/グループ」ボックス内のユーザまたはグループを強調表示し、左矢印ボタンをクリックします。
アクセス制御リスト認証の設定 (C++ アプリケーションの場合)
アクセス制御リスト (ACL) を使うと、ユーザおよびグループにパーミッションを設定できます。パーミッションは、読み込みや書き込みなど、ユーザが実行を許可されるアクションに関連付けられています。iPlanet Application Server には、デフォルトのパーミッションがありますが、ユーザ独自のアプリケーションに固有のパーミッションおよび ACL を作成することもできます。ACL の情報は、ユーザが行うアクションに対して現在のユーザまたはグループのパーミッションを確認するために、アプリケーションによって使われます。
ユーザがあるパーミッションを持っていない場合は、アプリケーションがユーザにログインし直すように指示したり、アプリケーションを終了するように求めたり、あるいはアプリケーションの異なる部分を割り当てたりできます。
アクセス制御リストの作成
アクセス制御リスト (ACL) を作成して管理するには、iASAT を使う必要があります。ACL を作成するときに、個々のユーザを ACL にメンバーとして追加せずに、ユーザが属するグループを作成してグループだけを ACL に追加することができます。これは、個々のユーザベースのセキュリティを使っている場合に有効です。ユーザが変更されたときに更新されたユーザの管理情報を ACL に保存できます。たとえば、イントラネットアプリケーションのユーザを作成して、その後あるユーザが退職する場合は、グループおよびすべての ACL からユーザを削除するのではなく、該当するグループだけからそのユーザを削除する必要があります。
iASAT ツールバーの「セキュリティ」をクリックして「セキュリティ」ウィンドウを開きます。
「新規」をクリックします。次の図のように、「新規アクセス制御リスト」ダイアログボックスが表示されます。
「アクセス制御リスト」テキストフィールドに ACL の名前を入力します。
ACL にユーザまたはグループを追加するには、「ユーザまたはグループの追加」ボタンをクリックします。
- 他の ACL と区別できる名前を付けます。
ACL に追加するユーザまたはグループ、あるいはその両方を選択します。
「OK」をクリックします。
- 「ユーザフィルタ」テキストボックスに文字列を入力することによって、結果セットに表示されるユーザのリストをフィルタできます。たとえば、「F」で始まるユーザ ID だけを表示するには、「ユーザフィルタ」テキストボックスに「F*」と入力し、そのテキストボックスの右側にある「ユーザフィルタ」ボタンをクリックします。フィルタ条件と一致するユーザ ID が下のリストボックスに表示されます。ユーザフィルタはグループではなくユーザだけに適用されます。
ACL に新しいパーミッションを追加するには、「新規パーミッション」をクリックします。
新しいパーミッションを入力します。
「OK」をクリックします。
- パーミッションは、ユーザまたはグループが特定のアプリケーションまたはアプリケーションの一部に対して持っているアクセスのレベルを定義します。
アクセス制御リストの変更
次の ACL プロパティを変更することができます。システムからグループを削除することもできます。
iASAT ツールバーの「セキュリティ」をクリックして「セキュリティ」ウィンドウを開きます。
変更するアクセス制御リストを強調表示します。
「変更」をクリックします。「アクセス制御リストの変更」ダイアログボックスが表示されます。
新しいユーザまたはグループを追加するには、「ユーザまたはグループの追加」ボタンをクリックします。「ユーザまたはグループの追加」ダイアログボックスが表示されます。
ACL に追加する 1 つまたは複数のグループを選択します。
「OK」をクリックします。
- 「ユーザフィルタ」テキストボックスに文字列を入力することによって、リストに表示されるユーザをフィルタできます。たとえば、「F」で始まるユーザ ID だけを表示するには、「ユーザフィルタ」テキストボックスに「F*」と入力し、そのテキストボックスの右側にある「ユーザフィルタ」ボタンをクリックします。フィルタ条件と一致するユーザ ID が下のリストボックスに表示されます。ユーザフィルタはグループではなくユーザだけに適用されます。
「アクセス制御リストの変更」ウィンドウで「新規パーミッション」をクリックして新しいパーミッションを作成します。
「パーミッション」テキストフィールドに Read や Write などの新しいパーミッションを入力し、「OK」をクリックします。
「アクセス制御リストの変更」ウィンドウで、パーミッションの隣りにあるチェックボックスのオン/オフを切り替えることによって、グループのパーミッションを編集できます。
Web サーバと Application Server 間の暗号化の有効化
Web サーバと Application Server 間のトラフィックを暗号化するかどうかを選択できます。Executive Server (KXS) ではサーバ間のトラフィックを管理します。クレジットカード情報を収集する Servlets やログイン Servlets など、高度なセキュリティが必要なコンポーネントの暗号化を有効にしなければならない場合があります。コンポーネントは、128 ビットキーおよび RSA BSafe 3.0 ライブラリを使って暗号化されるので、情報が安全に転送されます。この節では、KXS ログで暗号化の詳細を確認する方法と、暗号化の cryptext キーの作成方法について説明します。
Web サーバと Application Server 間の暗号化を有効にするには
Web サーバと Application Server 間の暗号化を有効にするには
Web サーバと Application Server 間のトラフィックの暗号化を有効にするには、次の手順を実行します。
iPlanet レジストリエディタを開きます。
次のキーを開きます。
- (「iPlanet レジストリエディタについて」を参照)。
EnableEncryption=0 のような値が表示されます。デフォルトでは、暗号化は無効になっています。暗号化を有効にするには、この値を EnableEncryption=D に変更します。D は内部 128 ビットデータタイプ文字列を意味します。これで暗号化が有効になりました。
- SOFWARE/iPlanet/Application Server/6.5/CCSO/Security/
暗号化ログメッセージを確認するには
KXS ログファイルで暗号化ログメッセージを確認するには、次の手順を実行します。
iPlanet レジストリエディタを開きます。
このキーを作成すると、暗号化ログメッセージが KXS ログに記録されます。
次のキーを開きます。
- (「iPlanet レジストリエディタについて」を参照)。
「編集」メニューから「値を追加」を選択します。次の図のように、「値を追加」ダイアログボックスが表示されます。
- SOFWARE/iPlanet/Application Server/6.5/CCSO/Security/
個々の J2EE コンポーネントの暗号化を有効にするには
JSP や Servlets などの個々の J2EE コンポーネントの暗号化を有効にするには、次の手順を実行します。EJB については暗号化を有効にできません。
コンポーネントの暗号化を有効にするアプリケーションの ias-web.xml ファイルを開きます。
暗号化が有効になっていて機能していることを確認するには、KXS ログを開いて、次のようなメッセージを検索します。暗号化を有効にする Servlet または JSP を検索して選択します。
コンポーネントの <encrypt>false</encrypt> タグを選択します。false を true に変更します。
[11/Jan/2001 19:58:43:0] info:CRPT-001:Encrypting 2309 bytes, keysize = 128 bits
[11/Jan/2001 19:58:43:5] info:NSAPICLI-012:plugin reqstart, tickct: 1903570535
[11/Jan/2001 19:58/:43:5] info:NSAPICLI-009:plugin reqexit:Os+.12995s. (198114 0537)
[11/Jan/2001 19:58:52:2] info:CRYPT-004:Decrypting 1897 bytes, keysize = 128 bits
コンポーネントの暗号化を有効にすると、iPlanet レジストリで暗号化を無効に設定しても暗号化が行われます。
ファイアウォールを使ったセキュリティ
iPlanet Application Server は通常、Web サーバおよびクライアントデータベースアプリケーションとともに配置されます。このような場合、プロセス間通信は非常にレベルが高いため、データの完全性およびセキュリティの問題が非常に重要になります。アプリケーションサーバ間、Web サーバ間、およびアプリケーションサーバで実行するクライアントアプリケーション間の円滑で安全な通信を確保するために、システムのセキュリティコンポーネントがファイアウォールによって区切られる場合があります。この節では、ファイアウォールで保護された環境で iPlanet Application Server を効果的に計画して配置する方法について説明します。この節には次のトピックがあります。
ネットワークセキュリティの基本
iPlanet Application Serverアーキテクチャ
注 このマニュアルに記載されているアドレスおよびポート番号は、すべてデフォルト値です。これらの値は、対応するレジストリに保存されている値の変更によって、インストール時、またはその後に変更される場合があります。変更された場合は、対応する変更をファイアウォール設定パラメータに適用する必要があります。
ネットワークセキュリティの基本
企業のローカルエリアネットワーク (LAN) などの専用ネットワークは、インターネットなどの公衆網に直接接続されるのではなく、アクセスを制御するファイアウォールを通過します。公衆網へのアクセスは、特定のマシンの承認されたポート番号で承認されたプロトコルを使って制御されます。
ファイアウォールの種類
ファイアウォールには種類があり、それぞれに長所と短所があります。ファイアウォールは、1 つの種類のマシンで構成されるとはかぎりません。通常、存在している他のマシンを必要とします。これらの他のシステムは、基本的なトラフィック転送を行うように設定されることはありますが、ファイアウォール機能を提供するように設定されている場合とそうでない場合があります。次の節では、3 つの主要なファイアウォールについて説明します。
ルータ
ルータは高速かつ簡単なファイアウォールであり、比較的低価格です。基本的に、ルータは 2 つのネットワークの間に置かれ、それらのネットワーク間のコネクションを中継します。設定パラメータは、個々の IP アドレスまたはある範囲の IP アドレスとのコネクションを許可または拒否するように指定できます。より高度なバージョンのルータでは、データを検査して、使われているセキュリティプロトコル、およびそのセキュリティプロトコルがアドレス指定されているポート番号を調べます。制御は特定のプロトコルを使うコネクションで実行され、特定のポート (フィルタ) に転送されます。
ルータはそのタスク専用に構築されたマシンであり、通常 UNIX オペレーティングシステムが動作する、複数のネットワークインターフェイスを持つコンピュータを使って実装できます。汎用マシンを専用ルータとして使う長所は、ルータがプロキシサーバも実行できることです。
プロキシサーバ
プロキシサーバは通常、データアクセスがプロキシサーバだけを通過するように、何らかの形のルータと一緒に使われます。プロキシサーバは、ファイヤフォールにまたがるマシンに置かれるか、またはプロキシサーバと専用ネットワークの間に他のルータを持つ、非武装地帯 (DMZ) と呼ばれる小さな専用ネットワーク上でプライマリルータの後ろに置かれます。後者は一般的な配置です。一般的に、プロキシシステムは余分な装備をすべて除いた基本的なシステムです。標準のユーザアプリケーションがほとんどなく、さまざまなプロトコルのプロキシサーバとして機能するプログラムだけがあります。プロキシサーバは、専用ネットワーク内で一部のクライアントのサーバとして機能するように設計されています。たとえば、HTTP プロキシサーバは、専用ネットワーク上の Web ブラウザに関するかぎり HTTP サーバとして動作します。ブラウザは HTTP プロキシサーバに接続し、ドキュメントのリクエストを送信します。その結果、HTTP プロキシサーバはブラウザとして機能し、ドキュメントが要求されたサーバに接続します。リモート HTTP サーバはプロキシサーバを認識しません。HTTP プロキシサーバは要求されたドキュメントを受信すると、専用ネットワーク上のユーザのブラウザに渡す前に、ウィルスがないかどうかドキュメントをスキャンします。HTTP プロキシサーバがドキュメントをブラウザに渡す前に実行するアクションは、HTTP プロキシサーバで指定できます。これによって追加のセキュリティが有効になり、情報の質および安全性も保証されます。
ステートフルインスペクションファイアウォール
一般的になってきたファイアウォールの形態は、単に情報を転送するのではなく情報パッケージのコンテンツも検査するマシンです。取得した情報を使って、より高いレベルのプロトコルを決定できます。これによって、アプリケーションプロトコルのレベルまで拡張可能です。通信プロトコルが確立されると、プロトコルが新しいステートを入力するまで、システムではステートテーブルを使って、どの操作を許可するかを決定します。たとえば、受信した telnet コネクションが送信先マシンのポート番号 23 に転送される TCP/IP (Transmission Control Protocol/Internet Protocol) コネクションであると仮定します。telnet サーバは、telnet クライアントによって接続されるポート番号を使って応答します。ステートフルインスペクションファイアウォールシステムは、ステートが開いている telnet を認識し、返されたデータに、クライアントによって接続されるポート番号があるかどうかを調べます。ホスト (コネクションを開始したマシン) がコネクションを送信先ポートに転送すると、ステートフルインスペクションファイアウォールシステムによってコネクションが許可されます。標準以外のポートへの他のランダムなコネクションは通常拒否されます。
ステートフルインスペクションファイアウォールは、すべてのデータを調べる必要がないため高速です。このファイアウォールは、指定されたプロトコルを処理するために特別に作成する必要のあるプロキシサーバと違って、汎用的なセキュリティに使うことができます。新しいプロトコルのプロキシの作成には、長時間かかる可能性があります。ステートフルインスペクションファイアウォールシステムを使うと、適切なステートトランザクションおよびアクションを決定する新しいプロトコルを監視するだけで、新しいステートテーブルをすばやく簡単に作成できます。
次の節では、iPlanet Application Server のアーキテクチャと iPlanet Application Server 内の通信方法について説明します。
iPlanet Application Serverアーキテクチャ
iPlanet Application Server は複数のモジュールから構成されます。基本コンポーネントは Executive Server (KXS) です。Executive Serverはアプリケーションのコンポーネントを作成し、負荷の監視および均衡を iPlanet Application Server の他のインスタンスとともにセッションデータごとに管理します。アプリケーションコードは KXS によって作成されるマルチスレッドプロセスで動作します。プロセスには、C++ Server (KCS) と Java Server (KJS) の 2 つの種類があります。
システムは Administration Server (KAS) によって管理されます。Web サーバは iPlanet Application Server と同じマシンにインストールされることもありますが、通常は、別のマシンにインストールされます。
Web サーバと iPlanet Application Server 間の通信には、iPlanet Application Server と直接通信する Web サーバにあるプラグインを使います。iPlanet Application Server の複数のインスタンスがインストールされている場合、プラグインではロードバランスシステムによって選択された iPlanet Application Server と通信します。使用している Web サーバがプラグインを使うことができない場合、通信モジュールは CGI (Common Gateway Interface) アプリケーションとして呼びだされることがあります。これは iPlanet Application Server とのコネクションを確立します。CGI モデルの使用は効率的でないので、通常は最後の手段として使われます。
また、OCL (Object Constraint Language) を使う方法もあります。OCL は CORBA を使って必要なサービスを検索し、iPlanet Application Server を介してそれらのサービスと通信します。これは、IIOP (Internet Inter-Object Protocol) コネクションについて標準化されたセキュリティがないため、イントラネットだけにお勧めします。
次の節では、ファイアウォールの構成方法と、サーバ、アプリケーション、およびセキュリティプロトコル間の通信方法について説明します。
プロセス間通信プロトコル
サーバ、アプリケーション、およびセキュリティプロトコルの間のプロセス間通信は、さまざまな方法で行われます。関連する通信リンクおよびプロトコルは次のとおりです。
エフェメラルポート
エフェメラルポートは、クライアントからサーバへのリクエストに応じて作成される匿名ポートです。UDP (User Datagram Protocol) の場合、これらは返信データグラムに使われるポート番号になります。TCP/IP の場合は、クライアントからのリクエストに応じてサーバで作成されるコネクションのポート番号になります。エフェメラルポートは現在使われておらず、予約された範囲 (0-1023) 外のポートにすることができます。通常、エフェメラルポートは、範囲 (1024-5000)から割り当てています。ただし、一部のシステム、特に Solaris では、別の範囲にあるエフェメラルポート番号を割り当てます。多くのコネクションを持つ大規模なシステムでは、ポート番号の制限された範囲が不十分な場合があるという認識から、通常、エフェメラルポートとして 32768 より大きなポート番号を割り当てることができます。
エフェメラルポートを使用できるファイアウォールではエフェメラルポートについて、使われている値を確認することと、適切な範囲が確実に有効になっていることが重要です。この範囲は通常、現在の Solaris システムでは >32768、Windows システムでは 1023 〜 5000 です。
Transmission Control Protocol/Internet Protocol (TCP/IP)
次の表に示すように、さまざまな種類のトラフィックを送る複数の TCP/IP コネクションがあります。表に示されているアドレスおよびポートはデフォルト値です。
これらの通信チャネルの大部分は複数の種類のデータ転送に使われます。データ転送は同じ TCP/IP コネクション上で多重化されます。
プラグインをサポートしていない Web サーバが使われている場合、KXS との通信は小さな CGI アプリケーションを通過します。
CGI と KXS の間の通信に使われるポートは固定されていませんが、次のように割り当てられます。
したがって、4 つの KJS エンジンと 1 つの KCS エンジンがインストールされている場合、CGI ポートはポート番号 10824 に設定されます。これは、iPlanet Application Server インストール時のデフォルトの CGI ポート番号 10819+3 です。
Web サーバの TCP/IP 通信は、HTTP または HTTPS (Secure HTTP) のどちらを使うかによって、ポート 80 または 443 に割り当てられます。
IP マルチキャスト
複数の iPlanet Application Server インスタンスがある場合、iPlanet Application Server では、2 つの IP マルチキャストチャネルを使って次の通信タスクを処理します。KXS チャネルのトラフィックは重くなる可能性があり、システム負荷によって増加します。次の表は KXS チャネルのデフォルトのアドレスを示しています。
マルチキャスト
アドレス
Port
注 1 つの TCP/IP チャネルでの内部サーバデータの多重化は、Kiva Communications Protocol (KCP) と呼ばれる場合があります。このプロトコルは内部データ転送だけを意味します。
User Datagram Protocol (UDP)
Web コネクタプラグインでは UDP を使います。ping プロトコルを使って、Web コネクタプラグインが現在関連付けられている KXS プロセスがまだ接続されているかどうかを確認します。KXS 内で実行中のスレッドが ping に応答します。ping に対するレスポンスは KXS が実行中であることを示します。レスポンスがない場合は、代替の KXS に切り替えるためにフェールオーバーを開始することを示します。次の表は、デフォルトの UDP ポートの指定を示しています。
UDP が許容されない場合は、Web コネクタプラグインの iPlanet レジストリを変更すると ping を停止できます。ping リクエストへのレスポンスを無効にするには、次の手順を実行します。
iPlanet レジストリを開始します。
UDP の ping をオフにすると、現在選択されている iPlanet Application Server が失敗して、TCP/IP コネクションタイムアウトまで遅延が発生する可能性があります。TCP/IP 設定パラメータによって異なりますが、これには数分かかる場合があります。
次のキーを開きます。
- (「iPlanet レジストリエディタについて」を参照)。
DisableEcho キーを変更します。値を 1 に設定します。
- SOFTWARE/iPlanet/Application Server/6.5/CCS0/CONN/
ヒント iPlanet レジストリで値を変更するには、次の手順を実行します。
ネットワークで UDP が無効になっている場合は、動作する Web コネクタプラグインの Web コネクタプラグインレジストリで ping を無効にする必要があります。UDP ping は、CGI インターフェイスではなく Web サーバプラグインだけで使われます。
次の表に、iPlanet Application Server コンポーネントのプロトコル、アドレス、および目的をまとめます。
データチャネルの暗号化
Web コネクタプラグインと KXS 間で実行される通信を暗号化できます。暗号化を行うときは、同じポートとアドレスが継続して使われますが、データ転送が暗号化されます。安全な暗号を使うデータ暗号化に関連するオーバーヘッドのため、絶対的なニーズに基づいて使うことをお勧めします。「Web サーバと Application Server 間の暗号化の有効化」を参照してください。
iPlanet Application Server でのファイアウォールの設定
この節では、いくつかの一般的なファイアウォール設定と、正しく機能するためのパラメータ設定について検討します。これらの例では、iPlanet Application Server 実装内へのファイアウォールの合理的な配置を示します。iPlanet Application Server インスタンス (KXS/KJS/KCS プロセスグループである iPlanet Application Server インスタンス) 間にファイアウォールを置くことは可能ですが、お勧めしません。そのようなファイアウォールを実装する場合は、ファイアウォールを越えて IP を許可する IGMP (Internet Group Management Protocol) を実装することが重要です。
iPlanet Application Server インスタンス間にファイアウォールを置くことはお勧めしませんが、環境によっては iPlanet Application Server マシン間に IP マルチキャストトラフィックの高速専用ネットワークを実装することをお勧めします。
iPlanet Application Server システムは LAN 速度で動作するネットワーク用に設計されているので、iPlanet Application Server インスタンスをWAN (広域ネットワーク) 全体に分散させると、パフォーマンスの問題が発生する場合があります。
単独のファイアウォール
最も簡単で一般的なファイアウォール構成は、Web サーバとインターネットの間にファイアウォールを 1 つ置くものです。ファイアフォールが 1 つの設定は単純です。適切にポート 80 や HTTPS 443 への HTTP コネクションを許可するようにファイアウォールを設定する必要があります。返されるデータが 1024 よりも大きいポートにあるため、これらのポートを送信 (返信) コネクションに開く必要があります。
この設定は簡単であることが利点です。最大の短所は防御が 1 つしかないことです。ファイアウォールが破られると、専用ネットワーク内にある各マシンのセキュリティが唯一の防御になります。
次の表は、ファイアウォールを正しく機能させるためのプロトコルとポートの設定を要約したものです。
Web サーバをファイアウォールの外側で実行しなければならない場合があります。
この設定によって Web サーバマシンはインターネットに公開されるため、お勧めできません。前の例のように、防御が 1 つしかありません。外部 Web サーバは通常、保護されたネットワーク内ででの安全性しかないので、有害な攻撃の第一の標的となります。
このファイアウォール設定では、次の表のように、Web コネクタプラグイン TCP/IP データコネクションおよび UDP ping コネクションを許可する必要があります。
プロトコル
方向
Port
理由
注 使用している Web サーバで Web コネクタプラグインを使用できない場合は、KXS との通信に CGI アプリケーションが使われます。インストール時にデフォルトで割り当てられた CGI ポートは、10819 + (KCS/JKS インスタンスの数) です。
二重のファイアウォール - DMZ 設定
この設定は、多くの企業が DMZ を介して提携先や顧客に専用ネットワークへの制限されたアクセスを解放するにつれて一般的になってきています。この設定で提供されるセキュリティは、前に示した単独のファイアウォールの例よりもはるかに改善されています。各ファイアウォールおよび DMZ でアクティビティをアクティブに監視する二重レイヤの保護によって、内部ネットワークへの侵入のための試みがほとんど検出されます。
この場合、外側のファイアウォールは、上の例のように HTTP および HTTPS トランザクションを許可するように設定する必要があります。内側のファイアウォールは、Web サーバプラグインがファイアウォールの後ろの iPlanet Application Server サーバと通信できるように設定する必要があります。
KXS インスタンスと通信する Web プラグインで使われるデフォルトのポートは 10818 です。同様に、フェールオーバーのキープアライブ ping に使われるデフォルトの UDP ポートは 9610 です。これを変更するには、ファイアウォール設定の適切な変更が必要です。次の表は、KXS ポートと UDP ポートのデフォルトのポート番号を示します。
三重のファイアウォール - データベース保護を持つ DMZ
企業の設定には、データベースが自社のネットワーク内にあるものもあります。この設定では、もっとも重要な会社のリソース、つまり企業データベース内に保存されているデータを重点的に保護します。LAN とデータベースシステム間のファイアウォールでは、外部だけでなく内部の脅威からも保護します。
データベースへのコネクションでは、ODBC (Open DataBase Connectivity)、JDBC (Java DataBase Connectivity)、データベースベンダーから供給されたコネクタライブラリなどの標準的なアクセスメカニズムを使います。データベースへのコネクションは他のアプリケーションと同じなので、データベース保護レイヤのファイアウォール設定は、使用している特定のデータベースへのアクセスに必要な標準設定に従います。
前へ 目次 索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最新更新日 2002 年 3 月 6 日