前へ     目次     索引     DocHome     次へ     
iPlanet Web Server, Enterprise Edition 管理者ガイド



第 8 章   サーバへのアクセス制御


この章では、Administration Server や、Web サイト上に配置されたファイルやディレクトリへのアクセスを制御するためのさまざまな方法について説明します。たとえば、Administration Server については、マシンにインストールされているすべてのサーバを完全に制御できるユーザや、1 台以上のサーバを部分的に管理できるユーザを指定できます。Administration Server でアクセス制御を使用するには、分散管理を有効にして、LDAP データベースに管理グループを設定する必要があります。この章では、すでに分散管理を構成していて、LDAP データベースにユーザとグループを定義していることを前提としています。

第 5 章「Web サーバのセキュリティ」で説明されている Web サーバのセキュリティについても、確認する必要があります。

この章は、次の節で構成されています。



アクセス制御とは

アクセス制御を使用すると、次の内容を指定できます。

  • iPlanet Web Administration Server にアクセスできるユーザ

  • ユーザがアクセスできるプログラム

  • Web サイト上のファイルやディレクトリにアクセスできるユーザ

サーバ全体やサーバの一部、または Web サイトのファイルやディレクトリへのアクセスを制御できます。アクセス制御エントリ (ACE) と呼ばれる規則の階層を作成します。これによって、アクセスを許可したり拒否したりすることができるようになります。各 ACE は、サーバが階層内の次の ACE を確認する必要があるかどうかを指定します。作成する ACE の集合は、アクセス制御リスト (ACL) と呼ばれます。

デフォルトでは、サーバには、複数の ACL が含まれる 1 つの ACL ファイルがあります。iPlanet Web Server は、受信する要求に使用する仮想サーバを指定したあと、その仮想サーバに対して ACL が構成されているかどうかを確認します。現在の要求に適用される ACL が見つかった場合、iPlanet Web Server は ACL に含まれる ACE を評価し、アクセスを許可するか拒否するかを決定します。

次の内容を基準にして、アクセスを許可または拒否します。

  • 要求を送信したユーザ (ユーザ-グループ)

  • 要求の送信元 (ホスト- IP)

  • 要求が発生した日時 (たとえば、時刻)

  • 使用されている接続のタイプ (SSL)


ユーザ-グループのアクセス制御の設定

特定のユーザまたはグループに対して、Web サーバへのアクセスを制限することができます。ユーザ-グループのアクセス制御を設定すると、ユーザはユーザ名とパスワードを入力しないと、サーバへのアクセス権を取得できなくなります。サーバは、クライアント証明書の情報またはクライアント証明書自体を、ディレクトリサーバのエントリと比較します。

Administration Server では、基本認証だけを使用します。Administration Server でクライアント認証を要求する場合、obj.conf の ACL ファイルを手動で編集し、認証メソッドを SSL に変更する必要があります。

サーバインスタンスに対するユーザ-グループ認証メソッドには、次の内容が含まれます。なお、( ) 内は画面上の表示を示しています。

  • デフォルト (Default)

  • 基本 (Basic)

  • SSL (SSL)

  • ダイジェスト (Digest)

  • その他 (Other)

これらすべてのメソッドで、ディレクトリサーバが必要です。

ユーザ-グループ認証の場合、ユーザは自分自身の認証を行わないと、Administration Server、および Web サイト上のファイルやディレクトリにアクセスできません。クライアント証明書、またはダイジェスト認証プラグインを使用して認証を行う場合、ユーザはユーザ名とパスワードを入力することによって識別情報を証明します。クライアント証明書を使用する場合は、暗号化が必要です。暗号化とクライアント証明書については、第 5 章「Web サーバのセキュリティ」を参照してください。


デフォルト認証 (Default)

デフォルト認証は、優先されるメソッドです。デフォルト設定では、obj.conf ファイルで指定したデフォルトメソッドを使用します。obj.conf でメソッドが設定されていない場合は、「基本」メソッドを使用します。「Default」チェックボックスにチェックマークを付けた場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL のメソッドを簡単に変更できます。


基本認証 (Basic)

基本認証では、Web サーバまたは Web サイトにアクセスするユーザに対して、ユーザ名とパスワードを要求します。これがデフォルトの設定です。iPlanet Directory Server などの LDAP データベースにユーザとグループのリストを作成して格納する必要があります。ここでは Web サーバではなく、別のサーバルートにインストールされているディレクトリサーバ、またはリモートマシンにインストールされているディレクトリサーバを使用する必要があります。

Administration Server 内、または Web サイト上のユーザ-グループ認証が設定されているリソースにユーザがアクセスした場合、Web ブラウザにユーザ名とパスワードの入力を求めるダイアログボックスが表示されます。サーバに対する暗号化が設定されているかどうかに応じて、サーバはこの情報を暗号化された状態、または暗号化されていない状態で受信します。

注

SSL 暗号化なしで基本認証を使用する場合、暗号化されていないユーザ名とパスワードがネットワークを経由して送信されます。ネットワークパケットは不正に読み取られる可能性があり、ユーザ名とパスワードが不正に知られてしまう可能性があります。基本認証は、SSL 暗号化とホスト- IP 認証のどちらかまたはその両方と組み合わせた場合にもっとも効果的です。ダイジェスト認証を使用しても、この問題を回避できます。


ユーザがサーバに対して自分自身の認証を行う場合、次のダイアログが表示されます。

図 8-1    ユーザ名とパスワードのプロンプトの例

「OK」をクリックすると、次の内容が表示されます。

  • iPlanet Web Administration Server へのアクセスに対する認証を受けている場合は、「Server Administration」ページ

  • Web サイトにログインしている場合は、要求されたファイルまたはディレクトリのリスト

  • ユーザ名またはパスワードが無効な場合は、アクセスが拒否されたことを示すメッセージ

認証を受けていないユーザが「Access Denied Response」ページで受信するアクセス拒否メッセージは、カスタマイズすることができます。


SSL 認証 (SSL)

サーバは、次の 2 つの方法で、セキュリティ証明書付きのユーザの識別情報を確認できます。

  • クライアント証明書の情報を識別情報として使用する

  • LDAP ディレクトリで発行されたクライアント証明書を確認する (追加)

クライアントの認証で証明書の情報を使用するようにサーバを設定した場合、サーバは次の処理を実行します。

  • まず、証明書が信頼できる CA から発行されたものであるかどうかを確認します。そうでない場合、認証は失敗し、トランザクションが終了します。クライアント証明書を有効にする方法については、「クライアント認証を要求する」を参照してください。

  • 証明書が信頼できる認証局/認証機関 (CA) から発行されている場合は、certmap.conf ファイルを使用して、証明書をユーザのエントリにマッピングします。証明書マッピングファイルの設定方法については、「certmap.conf ファイルの使用」を参照してください。

  • 証明書が正しくマッピングされている場合は、そのユーザに対して指定されている ACL 規則を確認します。証明書が正しくマッピングされている場合でも、ACL 規則によってユーザのアクセスが拒否される可能性もあります。

特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書を提示するだけで済みます。ユーザとグループの認証に SSL メソッドを使用するようにサーバのアクセス制御を設定した場合、クライアントでは次の内容をすべて満たすことが必要です。

  • 信頼できる CA によって発行された有効な証明書を提示する

  • 証明書は LDAP 内の有効なユーザにマッピングされている

  • アクセス制御リストで、適切に評価する

アクセス制御を使ってクライアント認証を要求する場合、Web サーバでは SSL 符号化方式を有効にする必要があります。SSL を有効にする方法については、 第 5 章「Web サーバのセキュリティ」を参照してください。

SSL で認証されるリソースへのアクセス権を得るには、Web サーバで信頼されている CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバのクライアント証明書を比較するように Web サーバの certmap.conf ファイルが構成されている場合、クライアント証明書はディレクトリサーバ内で発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバのエントリだけを比較するように、certmap.conf ファイルを構成することもできます。たとえば、ブラウザ証明書のユーザ ID および電子メールアドレスとディレクトリサーバのエントリだけを比較するように、 certmap.conf ファイルを構成することができます。certmap.conf と証明書のマッピングの詳細は、第 5 章「Web サーバのセキュリティ」を参照してください。


注

LDAP ディレクトリに対する証明書が確認されるため、SSL 認証メソッドだけは certmap.conf ファイルの修正を必要とします。サーバへの接続のすべてに対してクライアント認証を要求するメソッドでは、この必要はありません。使用するクライアント証明書を選択する場合は、magnus.conf の AcceptTimeout 指令の値を大きくする必要があります。



ダイジェスト認証 (Digest)

ダイジェスト認証では、ユーザがユーザ名とパスワードをプレーンテキスト形式 (暗号化されていない形式) で送信することなく、ユーザ名とパスワードに基づいた認証を行うことができます。ブラウザは、ユーザのパスワードと Web サーバによって提供される情報の一部を使用し、MD5 アルゴリズムを使ってダイジェスト値を作成します。このダイジェスト値は、サーバ側でもダイジェスト認証プラグインを使用して計算し、クライアントによって提示されたダイジェスト値と比較します。ダイジェスト値が一致する場合、ユーザは認証を受けたものと見なします。

このように機能させるためには、ディレクトリサーバをプレーンテキスト形式の (暗号化されていない) ユーザパスワードにアクセスできるようにする必要があります。iPlanet Directory Server 5.0 には、対称暗号化アルゴリズムを使用してデータを暗号化した形式で格納し、あとから復号化して元の形式に戻すことができるリバーシブルパスワードプラグインが組み込まれています。データへの鍵を持っているのは Directory Server だけです。

ダイジェスト認証の場合は、リバーシブルパスワードプラグインと、iPlanet Web Server 6.0 に組み込まれているダイジェスト認証に固有のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Web サーバを構成するには、dbswitch.conf でデータベース定義の digestauth プロパティを設定します。

表 8-1 に示すように、サーバは指定されている ACL メソッドに基づいて LDAP データベースに対して認証を試行します。ACL メソッドを指定しないと、サーバは認証が要求された場合にダイジェスト認証または基本認証のどちらかを使用し、認証が要求されない場合には基本認証を使用します。基本認証が使用されるのは、これが優先されるメソッドのためです。


表 8-1    ダイジェスト認証要求の生成 

ACL メソッド

認証データベースによってサポートされるダイジェスト認証

認証データベースによってサポートされないダイジェスト認証

「デフォルト」

指定なし  

ダイジェストと基本  

基本  

「基本」  

基本  

基本  

「ダイジェスト」  

ダイジェスト  

エラー  

method = digest を指定して ACL を処理する場合、サーバは次の内容を実行して認証を試行します。

  • 認証要求のヘッダーを確認します。見つからない場合は、ダイジェスト要求に対して 401 の応答が生成され、プロセスが停止します。

  • 認証のタイプを確認します。認証のタイプがダイジェストの場合、サーバは次の内容を実行します。

    • nonce を確認します。このサーバによって生成された、有効で新しい nonce がない場合は、401 の応答が生成されてプロセスが停止します。無効な場合は、stale=true として 401 の応答が生成されてプロセスが停止します。

    • 領域を確認します。領域が一致しない場合は、401 の応答が生成され、プロセスが停止します。

    • LDAP ディレクトリにユーザが存在しているかどうかを確認します。見つからない場合は、401 の応答が生成されてプロセスが停止します。

    • ディレクトリサーバから要求-ダイジェスト値を取得し、クライアントの要求-ダイジェスト値と一致することを確認します。一致しない場合は、401 の応答が生成され、プロセスが停止します。

    • 認証情報ヘッダーを構築し、サーバヘッダーに挿入します。


UNIX でのダイジェスト認証プラグインのインストール
ダイジェスト認証プラグインは、次の両方に存在する共用ライブラリで構成されます。

  • libdigest-plugin.lib

  • libdigest-plugin.ldif

UNIX でダイジェスト認証プラグインをインストールするには、次の手順を実行します。

  1. この共用ライブラリが、iPlanet Directory Server がインストールされているのと同じサーバマシンにあることを確認します。

  2. Directory Manager のパスワードを確認します。

  3. /path/to へのすべての参照を、ダイジェストプラグインの共用ライブラリのインストール先に参照先が変更されるように、libdigest-plugin.ldif ファイルを修正します。

  4. プラグインをインストールするには、次のコマンドを入力します。

    % ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif


NT でのダイジェスト認証プラグインのインストール
ダイジェストプラグインとともに iPlanet Directory Server を正常に起動できるようにするには、iPlanet Web Server がインストールされている場所にある .dll ファイルを iPlanet Directory Server のサーバマシンにいくつかコピーする必要があります。

NT でダイジェスト認証プラグインをインストールするには、次の手順を実行します。

  1. 次の場所にインストールされている iPlanet Web Server の共用ライブラリにアクセスします。

    [server_root]\bin\https\bin

  2. 次のファイルをコピーします。

    • nsldap32v50.dll

    • libspnr4.dll

    • libplds4.dll

  3. これらのファイルを次の両方の場所にペーストします。

    • \Winnt\system32

    • iPlanet Directory Server のインストールディレクトリ
      [server_root]\bin\sldap\server


DES アルゴリズムを使用するように iPlanet Directory Server を設定する
DES アルゴリズムは、ダイジェストパスワードが格納されている属性を暗号化するために必要です。

DES アルゴリズムを使用するように iPlanet Directory Server を設定するには、次の手順を実行します。

  1. iPlanet Directory Server Console を起動します。

  2. iDS 5.0 のインスタンスを開きます。

  3. 「Configuration」タブを選択します。

  4. プラグインの横にある + 記号をクリックします。

  5. DES プラグインを選択します。

  6. 「Add」を選択して新しい属性を追加します。

  7. 「iplanetReversiblePassword」と入力します。

  8. 「Save」をクリックします。

  9. iPlanet Directory Server のインスタンスを再起動します。
    注 iplanetReversiblePassword 属性でユーザのダイジェスト認証のパスワードを設定するには、エントリに iplanetReversiblePasswordobject オブジェクトが含まれている必要があります。



その他の認証 (Other)

アクセス制御 API を使用すると、カスタム認証メソッドを作成できます。


ホスト- IP のアクセス制御の設定

Administration Server、または Web サイトのファイルやディレクトリに対して、特定のコンピュータで動作しているクライアントだけが利用できるように、アクセスを制限できます。そのためには、アクセスの許可または拒否を行うコンピュータをホスト名または IP アドレスで指定します。ワイルドカードパターンを使用して、複数のコンピュータまたはネットワーク全体を指定することができます。ホスト- IP 認証を使用したファイルまたはディレクトリへのアクセスは、シームレスにユーザに表示されます。このため、各ユーザは、ユーザ名やパスワードを入力することなく、すぐにファイルやディレクトリにアクセスできます。

特定のコンピュータであっても複数のユーザが使用しているため、ホスト- IP 認証は、ユーザ-グループ認証と組み合わせるとより効果的です。両方の認証メソッドが使用される場合は、アクセスするときにユーザ名とパスワードが要求されます。

ホスト- IP 認証では、サーバが動作しているマシンで DNS を構成する必要はありません。ただし、ホスト- IP 認証を使用する場合は、ネットワーク上で DNS が稼働していて、この認証方式を使用するようにサーバが構成されている必要があります。サーバに対して DNS を有効にするには、 Server Manager の「Preferences」タブにある「Performance Tuning」ページを使用します。

DNS を有効にすると、サーバで DNS ルックアップを実行する必要があるため、iPlanet Web Server のパフォーマンスが低下します。サーバパフォーマンスに対する DNS ルックアップの影響を小さくするには、すべての要求に対して IP アドレスを解決する代わりに、アクセス制御と CGI に対してだけ IP アドレスを解決します。このためには、obj.conf ファイルの AddLog fn="flex-log" name="access" を iponly=1 にします。

AddLog fn="flex-log" name="access" iponly=1


アクセス制御ファイルの使用

Administration Server または Web サイト上のファイルやディレクトリに対してアクセス制御を使用する場合、拡張子が .acl のファイルに設定が格納されます。アクセス制御ファイルは server_install/httpacl ディレクトリに格納されます。server_install はサーバがインストールされている場所です。たとえば、/usr/iPlanet/Servers にサーバをインストールした場合、Administration Server とサーバ上で構成されている各サーバインスタンスの両方の ACL ファイルが、/usr/iPlanet/Servers/httpacl/ に格納されます。

主要な ACL ファイルの名前は generated-https-server-id.acl で、一時的な作業ファイルは genwork-https-server-id.acl という名前です。server-id はサーバ ID を示します。iPlanet Administration Server を使用してアクセスを構成する場合は、これらの 2 つのファイルが作成されます。ただし、複雑な制約が必要な場合は、複数のファイルを作成し、server.xml ファイルから参照することができます。また、時刻や曜日を基準にしたサーバへのアクセス制限など、ファイルを編集することによって利用可能になる機能もいくつかあります。

また、.acl ファイルを手動で作成して編集し、API を使用してアクセス制御をカスタマイズすることもできます。アクセス制御 API の使用の詳細は、『プログラマーズガイド』を参照してください。

アクセス制御ファイルとその構文については、付録 C「ACL ファイルの構文」を参照してください。


ACL ユーザキャッシュの構成

デフォルトでは、iPlanet Web Server によるユーザとグループの認証の結果が、ACL ユーザキャッシュに保存されます。magnus.conf ファイルの ACLCacheLifetime 指令を使用して、ACL ユーザキャッシュを有効にする期間を制御することができます。キャッシュ内のエントリが参照されるたびに、その経過時間が計算され、ACLCacheLifetime に対してチェックされます。経過時間が ACLCacheLifetime と同じか、それよりも長い場合、そのエントリは使用されません。デフォルト値は 120 秒です。値を 0 (ゼロ) に設定すると、キャッシュが無効になります。この値に大きな値を使用する場合は、LDAP エントリを変更するたびに iPlanet Web Server の起動が必要となる可能性があります。たとえば、この値を 120 秒に設定した場合は、iPlanet Web Server と LDAP の同期が 2 分間に渡ってとられない可能性があります。LDAP ディレクトリが頻繁に変更される可能性が低い場合にだけ、大きな値を設定します。

magnus.conf の ACLUserCacheSize パラメータを使用すると、キャッシュ内に保存できるエントリの最大数を構成できます。このパラメータのデフォルト値は 200 です。新しいエントリがリストの先頭に追加され、キャッシュが最大サイズに達すると、新しいエントリを作成するために、このリストの最後のエントリが再利用されます。

また、magnus.conf に含まれるパラメータである ACLGroupCacheSize を使用して、ユーザエントリごとにキャッシュできるグループメンバーの最大数を設定することができます。このパラメータのデフォルト値は 4 です。ただし、グループのメンバーではないユーザはキャッシュされず、要求ごとに何回か LDAP ディレクトリにアクセスすることになります。

ACL ファイルの指令の詳細は、『NSAPI プログラマーズガイド』を参照してください。



アクセス制御の実行方法


サーバはページへの要求を受け取ると、ACL ファイルの規則を使用して、アクセスを許可するか拒否するか判断します。規則は、要求を送信しているコンピュータのホスト名や IP アドレスを参照できます。また、規則が LDAP ディレクトリに格納されているユーザやグループを参照するように設定することもできます。

たとえば、次の ACL ファイルには、Administration Server (admin-serv) に対する 2 つのデフォルトエントリと、「admin-reduced」グループ内のユーザが Administration Server の「Preferences」タブにアクセスできるようにするための追加エントリがあります。

version 3.0;
# The following "es-internal" rules protect files such
# as icons and images related to iPlanet Web Server.
# These "es-internal" rules should not be modified.
  acl "es-internal";
  allow (read, list, execute,info) user = "anyone";
  deny (write, delete) user = "anyone";
# The following "default" rules apply to the entire document
# directory of iPlanet Web Server. In this example, the rules
# are set up so that "all" users in the directory server are
# allowed to read, execute, list, and get information.
# The "all" users are not allowed to write to or delete any files.
# All clients that accesses the document directory of the web
# server will be required to submit a username and password
# since this example is using the "basic" method of
# authentication. A client must be in the directory server
# to gain access to this default directory since "anyone"
# not in the directory server is denied, and "all" in the
# directory server are allowed.
  acl "default";
  authenticate (user,group) {
     database = "default";
     method = "basic";
  };
  deny (all)
  (user = "anyone");
  allow (read,execute,list,info)
  (user = "all");
# The following rules deny access to the directory "web"
# to everyone not in the directory server and deny everyone
# in the directory server who is not in GroupB.
# Only the users in GroupB are allowed read, execute, list,
# and info permissions. GroupA can not gain access to the
# directory "web" even though (in the ACL rule below) they
# can access the directory "my_stuff". Furthermore, members
# of GroupB can not write or delete files.
  acl "path=/export/user/990628.1/docs/my_stuff/web/";
  authenticate (user,group) {
     database = "default";
     method = "basic";
  };
  deny (all)
  (user = "anyone");

  allow (read,execute,list,info)
  (group = "GroupB");

# The following rule denies everyone not in the directory
# server and denies everyone in the directory server except
# user with the ID of "SpecificMemberOfGroupB". The ACL rule
# in this setting also has a requirement that the user
# connect from a specific IP address. The IP address setting
# in the rule is optional; it has been added to for extra
# security. Also, this ACl rule has a Customized prompt
# of "Presentation Owner". This Customized prompt appears
# in the username and password dialog box in the client's
# browser.

  acl "path=/export/user/990628.1/docs/my_stuff/web/presentation.html" ;
  authenticate (user,group) {
     database = "default";
     method = "basic";
     prompt = "Presentation Owner";
  };
  deny (all)
  (user = "anyone" or group = "my_group");
  allow (all)
  (user = "SpecificMemberOfGroupB") and
  (ip = "208.12.54.76");

# The following ACL rule denies everyone not in the directory
# server and everyone in the directory server except for
# GroupA and GroupB access to the directory "my_stuff"
  acl "path=/export/user/990628.1/docs/my_stuff/";
  authenticate (user,group) {
     database = "default";
     method = "basic";
  };
  deny (all)
  (user = "anyone");
  allow (read,execute,list,info)
  (group = "GroupA,GroupB");

たとえば、ユーザが次の URL を要求する場合、http://server_name/my_stuff/web/presentation.html

iPlanet Web Server はまず、サーバ全体へのアクセス制御を確認します。サーバ全体への ACL が認証の処理を続行するように設定される場合、サーバは my_stuff ディレクトリへの ACL を確認します。ACL が存在する場合、サーバは ACL 内の ACE を確認し、次のディレクトリに移動します。このプロセスは、アクセスを拒否する ACL が見つかるまで、または要求された URL の最後の ACL (この場合は、ファイル presentation.html) に達するまで続行します。

Server Manager を使用してこの例のアクセス制御を設定するには、このファイルだけを対象とした ACL の作成のほか、ファイルへ誘導する各リソースの ACL を作成することができます。つまり、1 つはサーバ全体用、１ つは my_stuff ディレクトリ用、1 つは my_stuff/web ディレクトリ用、1 つはファイル用です。



アクセス制御の設定


この節では、Web サイト上のファイルまたはディレクトリに対して、アクセスを制限するための手順を説明しています。すべてのサーバに対してグローバルアクセス制御規則を設定することも、特定のサーバに対して個別に設定することもできます。たとえば、人材管理部門を対象に、認証を受けているすべてのユーザに各自の給与計算データを参照することは許可して、データを更新できるのは人材管理部門の給与計算担当者だけに制限する ACL を作成することができます。

Administration Server によって、すべてのサーバに対してグローバルにアクセス制御を設定することができます。次の節「アクセス制御オプションの選択」では、各オプションについて詳しく説明します。

注 グローバルアクセス制御を作成するには、分散管理を構成して有効にしておく必要があります。



グローバルなアクセス制御の設定

すべてのサーバに対してグローバルにアクセス制御を作成したり編集したりするには、次の手順を実行します。

  1. Administration Server にアクセスして、「Global Settings」タブをクリックします。

  2. 「Restrict Access」リンクをクリックします。

  3. ドロップダウンリストから管理サーバ (https-admserv) を選択します。

  4. 次のどちらかをクリックします。

    • 「Create ACL」

    • 「Edit ACL」

    「Access Control Rules for uri=/https-admserv/bin/*」ページが表示されます。

図 8-2    「Access Control Rules」ページ

Administration Server には、編集できないデフォルトアクセス制御規則が 2 行あります。

  1. チェックマークが付いていない場合は、「Access control is on」チェックボックスにチェックマークを付けます。

  2. グローバル ACL の作成や編集をするには、「Action」列で「Deny」をクリックします。

    下のフレームに「Allow/Deny」ページが表示されます。

図 8-3    「Allow/Deny」ページ

  1. デフォルトで選択されていない場合は「Allow」を選択し、「Update」をクリックします。

  2. 「Users/Groups」列の「anyone」をクリックします。

    下のフレームに「User/Group」ページが表示されます。

図 8-4    「User/Group」ページ

  1. アクセスを許可するユーザやグループを選択し、「Update」をクリックします。

    「Group」と「User」の「List」をクリックすると、選択肢のリストが表示されます。

  2. 「From Host」列の「anyplace」をクリックします。

  3. アクセスを許可するホスト名と IP アドレスを入力してから、「Update」をクリックします。

  4. 「Programs」列で「All Programs」をクリックします。

図 8-5    「Programs」

  1. 「Program Groups」を選択するか、または「Program Items」フィールドにアクセスを許可する特定のファイル名を入力し、「Update」をクリックします。

  2. (省略可能) 「Extra」列の「x」をクリックして、カスタマイズした ACL 式を追加します。

  3. デフォルトとして選択されていない場合は、「Continue」列にチェックマークを付けます。

    サーバは次の行を評価してから、そのユーザがアクセスを許可されているかどうかを判断します。複数の行を作成する場合は、より一般的な制限からより特殊な制限へと処理を行います。

  4. (省略可能) 別の URL または URI にユーザを誘導することを拒否する場合、「Response」をクリックします。

  5. 絶対 URL または相対 URI へのパスを入力し、「update」をクリックします。

  6. 「Submit」をクリックして、新しいアクセス制御規則を ACL ファイルに保存します。
    注 「Revert」をクリックすると、作成したすべての設定が削除されます。



サーバインスタンスに対するアクセス制御の設定

Server Manager を使用すると、特定のサーバインスタンスに対するアクセス制御の作成、編集、または削除を実行できます。

注 削除する場合、ACL ファイルからすべての ACL 規則を削除しないでください。サーバを起動するには、最小限の ACL 規則が含まれる ACL ファイルが少なくとも 1 つ必要です。すべての ACL 規則を削除してサーバを再起動すると、構文エラーが発生します。


サーバインスタンスに対してアクセス制御を作成するには、次の手順を実行します。

  1. Server Manager にアクセスし、ACL を作成または編集するサーバインスタンスを選択します。

  2. Server Manager の「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 「Option」列で、次のいずれかを選択します。

    • 「Add」を選択して、ACL ファイルの場所を入力します。

    • 「Edit」を選択し、ドロップダウンメニューから ACL ファイルを選択します。

    • ドロップダウンメニューから「Delete」を選択し、ACL ファイルを選択します。

「Access Control List Management」ページに、次の 3 つのオプションが表示されます。

図 8-6    「Access Control List Management」ページ

  1. 次のいずれかを選択します。

    • リソースを選択し、ファイルまたはディレクトリのワイルドカードパターン (*.html など) を指定し、制限するディレクトリまたはファイル名を選択するか、またはファイルやディレクトリを参照します。

    • 有効にしたすべての ACL のリストから選択する既存の ACL を選びます。有効にしていない既存の ACL は、このリストに表示されません。

    • ACL 名を入力すると、名前付きの ACL を作成できます。このオプションは、ACL ファイルについての知識が豊富な場合にだけ使用します。名前付きの ACL をリソースに適用する場合、手動で obj.conf を編集する必要があります。

表 8-2 では、使用できるリソースワイルドカードについて説明します。


表 8-2    サーバリソースのワイルドカード 

リソースのワイルドカード

意味

デフォルト  

インストール時に作成される名前付き ACL。LDAP ディレクトリ内のユーザだけがドキュメントを発行できるように、書き込みアクセスを制限する  

サーバ全体  

1 組の規則によって、稼働中の仮想サーバを含めた Web サイト全体へのアクセスが定義される。仮想サーバへのアクセスを制限するには、そのドキュメントルートのパスを指定すること  

/usr/iplanet/server4/docs/cgi-bin/*  

cgi-bin ディレクトリ内のすべてのファイルとディレクトリへのアクセスを制御する。絶対パスを指定する必要がある。Windows NT では、パスにドライブ文字を含める必要がある  

uri="/sales"  

ドキュメントルートの sales ディレクトリへのアクセスを制御する。URI を指定するには、名前付き ACL を作成すること  

  1. 「Edit Access Control」をクリックします。

    「Access Control Rules for: server instance」が、 表示されます。

図 8-7    「Access Control Rules」ページ

  1. チェックマークが付いていない場合は、「Access control is on」チェックボックスにチェックマークを付けます。

  2. このサーバインスタンス用の ACL を作成したり編集したりするには、「Action」列で「Deny」をクリックします。

    下のフレームに「Allow/Deny」ページが表示されます。

図 8-8    「Allow/Deny」ページ

  1. デフォルトで選択されていない場合は「Allow」を選択し、「Update」をクリックします。

  2. 「Users/Groups」列の「anyone」をクリックします。

    下のフレームに「User/Group」ページが表示されます。

図 8-9    「User/Group」ページ

  1. アクセスを許可するユーザやグループを選択し、「Update」をクリックします。

    「Group」と「User」の「List」をクリックすると、選択肢のリストが表示されます。

  2. 「From Host」列の「anyplace」をクリックします。

  3. アクセスを許可するホスト名と IP アドレスを入力し、「Update」をクリックします。

  4. 「Rights」列で「all」をクリックします。

図 8-10    「Access Rights」ページ

  1. 次のどちらかを選択し、「Update」をクリックします。

    • 「All Access Rights」

    • 「Only the following rights」をクリックし、このユーザに適したすべての権利にチェックマークを付けます。

  2. (省略可能) 「Extra」列の「x」をクリックして、カスタマイズした ACL 式を追加します。

  3. デフォルトとして選択されていない場合は、「Continue」列にチェックマークを付けます。

    サーバは次の行を評価してから、ユーザがアクセスを許可されているかどうかを判断します。複数の行を作成する場合は、より一般的な制限からより特殊な制限へと処理を行います。

  4. (省略可能) 別の URL または URI の内容をユーザに対して表示することを拒否する場合、「Response」をクリックします。

  5. 絶対 URL または相対 URI へのパスを入力し、「update」をクリックします。

  6. 「Submit」をクリックして、新しいアクセス制御規則を ACL ファイルに保存します。
    注 「Revert」をクリックすると、作成したすべての設定が画面を表示した時点の内容に戻ります。


  7. 目的の各サーバインスタンスに対して上記のすべての手順を繰り返し、アクセス制御を確立します。

  8. 完了したら、「Apply」をクリックします。

  9. 「hard start /restart」または「dynamically apply」を選択します。

また、仮想サーバごとに ACL 設定を有効にすることもできます。この実行方法については、「仮想サーバのアクセス制御リストの編集」を参照してください。



アクセス制御オプションの選択


次の節では、アクセス制御を設定するときに選択できる個々のオプションについて説明します。Administration Server の場合は、最初の 2 行はデフォルトとして設定されていて、編集できません。


アクションの設定

要求がアクション制御規則と一致する場合にサーバが実行するアクションを指定できます。

  • 「Allow」は、ユーザまたはシステムが、要求されたリソースにアクセスできることを意味します

  • 「Deny」は、ユーザまたはシステムが、要求されたリソースにアクセスできないことを意味します

サーバはアクセス制御式 (access control expressions、ACE) のリストを参照して、アクセス権を指定します。たとえば、最初の ACE は通常、すべてのユーザを拒否します。最初の ACE に「continue」が設定されている場合、サーバはリストの 2 番めの ACE を確認し、一致している場合は、次の ACE を確認します。「continue」チェックボックスにチェックマークが付いていない場合は、すべてのユーザがリソースへのアクセスを拒否されます。サーバは、一致しない ACE か、一致していても「continue」チェックボックスにチェックマークが付いていない ACE のどちらかに達するまでリストを参照します。一致する最後の ACE によって、アクセスが許可されるか拒否されるかが決まります。


ユーザとグループの指定

ユーザとグループの認証が行われる場合、ユーザがアクセス制御規則で指定されているリソースにアクセスするには、ユーザ名とパスワードを入力する必要があります。

iPlanet Web Server は、iPlanet Directory Server などの LDAP サーバに格納されているユーザとグループのリストを確認します。

データベース内のすべてのユーザに対してアクセスを許可または拒否することも、ワイルドカードパターンを使用して特定のユーザに対してアクセスを許可または拒否することも、アクセスを許可または拒否する対象をユーザとグループのリストから選択することもできます。

  • 「Anyone (No Authentication)」はデフォルト値で、すべてのユーザがユーザ名とパスワードを入力することなく、リソースにアクセスできることを意味します。ただし、ホスト名や IP アドレスなど、その他の設定に基づいてユーザのアクセスが拒否される場合もあります。Administration Server の場合、このオプションは、分散管理によって指定した管理者グループ内のすべてのユーザがページにアクセスできることを意味します。

  • 「Authenticated people only」

    • 「All in the authentication database」は、データベースにエントリがあるユーザに一致します。

    • 「Only the following people」では、一致するユーザとグループを指定できます。エントリをコンマ (,) で区切るか、またはワイルドカードパターンを使用すると、ユーザとユーザグループの任意のリストを作成することができます。また、データベースに格納されているユーザやグループのリストから選択することもできます。「Group」は、指定したグループ内のすべてのユーザに一致します。「User」は、指定した個々のユーザに一致します。Administration Server では、ユーザを分散管理のために指定した管理者グループのメンバーにする必要があります。

  • 「Prompt for authentication」では、「authentication」ダイアログボックスに表示されるメッセージテキストを入力できます。このテキストを使用して、ユーザが入力する必要のある内容を説明することができます。オペレーティングシステムによっては、プロンプトに最初の約 40 文字が表示されます。Netscape Navigator と Netscape Communicator では、ユーザ名とパスワードがキャッシュに保存され、プロンプトのテキストと関連付けられます。同じプロンプトがあるファイルやディレクトリにユーザがアクセスする場合は、ユーザ名とパスワードをもう一度入力する必要はありません。特定のファイルやディレクトリに対してユーザが再び認証を受けるようにしたい場合、そのリソースの ACL に対するプロンプトを変更する必要があるだけです。

  • 「Authentication Methods」では、クライアントから認証情報を取得するためにサーバで使用するメソッドを指定します。Administration Server で使用できるのは、認証の基本メソッドだけです。

    • 「Default」では、obj.conf ファイルで指定したデフォルトメソッドを使用します。obj.conf でメソッドが設定されていない場合は、「Basic」メソッドを使用します。「Default」チェックボックスにチェックマークを付けた場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL のメソッドを簡単に変更できます。

    • 「Basic」では、HTTP メソッドを使用して、クライアントから認証情報を取得します。ユーザ名とパスワードが暗号化されるのは、サーバ側で暗号化するように設定されている場合だけです。

    • 「SSL」では、クライアント証明書を使用してユーザの認証を行います。このメソッドを使用するには、サーバ側で SSL を有効にする必要があります。暗号化するように設定されている場合は、基本メソッドと SSL メソッドを組み合わせて使用することができます。

    • 「Digest」では、ユーザ名とパスワードをプレーンテキストとして送信することなく、ブラウザでユーザ名とパスワードに基づいて認証を行えるようにする認証機構を使用します。ブラウザは MD5 アルゴリズムを使用して、ユーザのパスワードと Web サーバによって提供される情報の一部を使用するダイジェスト値を作成します。このダイジェスト値は、サーバ側でダイジェスト認証プラグインを使用して計算され、クライアントによって提示されたダイジェスト値と比較されます。

    • 「Other」では、アクセス制御 API を使用して作成するカスタム認証メソッドを使用します。

  • 「Authentication Database」では、サーバでユーザの認証に使用するデータベースを選択します。このオプションを使用できるのは、Server Manager を使用する場合だけです。「Default」を選択した場合、サーバは LDAP ディレクトリ内のユーザとグループを検索します。複数のデータベースを使用するように個々の ACL を構成する場合、「Other」を選択し、ドロップダウンリストでデータベースを選択します。デフォルト以外のデータベースと　LDAP　ディレクトリは、server_root/userdb/dbswitch.conf ファイルで指定されている必要があります。Oracle や Informix などのカスタムデータベースにアクセス制御 API を使用する場合は、「Other」を選択し、データベース名を入力します。


「From Host」の指定

どのコンピュータから要求されたかに基づいて、Administration Server や Web サイトへのアクセスを制限できます。

  • 「Anyplace」では、すべてのユーザとシステムに対してアクセスを許可します。

  • 「Only from」では、特定のホスト名または IP アドレスへのアクセスを制限できます。

「Only from」オプションを選択する場合は、「Host Names」フィールドまたは「IP アドレス」フィールドに、ワイルドカードパターンまたはカンマで区切ったリストを入力します。ホスト名に基づく制限は、IP アドレスに基づく制限よりも柔軟性があります。ユーザの IP アドレスが変更された場合でも、このリストを更新する必要はありません。ただし、IP アドレスによる制限には、より高い信頼性があります。これは、接続されているクライアントを対象とした DNS 検索に失敗した場合、ホスト名によるアクセス制限が機能しなくなるためです。

コンピュータのホスト名または IP アドレスと一致するワイルドカードパターンとして使用できるのは、* というワイルドカード表記だけです。たとえば、特定のドメイン内のすべてのコンピュータに対してアクセスを許可または拒否する場合、*.iplanet.com のように、ドメイン内のすべてのホストが該当するワイルドカードパターンを入力します。Administration Server にアクセスしているスーパーユーザに対しては、その他のユーザとは異なるホスト名と IP アドレスを設定することもできます。

ホスト名については、* が名前のコンポーネント全体を表現していなくてはなりません。つまり、*.iplanet.com は許容されますが、*users.iplanet.com は許容されません。また、ホスト名で * を使用する場合、この記号が文字列の一番左に配置される必要があります。たとえば、*.iplanet.com は許容されますが、users.*.com は許容されません。

IP アドレスについては、* がアドレスのバイト全体を表現していなくてはなりません。たとえば、198.95.251.* は許容されますが、198.95.251.3* は許容されません。IP アドレスで * を使用する場合、この記号が文字列の一番右に配置される必要があります。たとえば、198.* は許容されますが、198.*.251.30 は許容されません。


プログラムへのアクセス制限

プログラムへのアクセスを制限できるのは、Administration Server だけです。プログラムへのアクセス制限を適用すると、特定のユーザだけが「Server Manager」ページを参照し、そのサーバを構成できるように制限できます。たとえば、一部の管理者に対して Administration Server の「Users & Groups」セクションを構成することを許可するものの、「Global Settings」へのアクセスは拒否するように制限することができます。

  • 「All Programs」では、すべてのプログラムへのアクセスを許可または拒否できます。デフォルトでは、管理者はサーバのすべてのプログラムにアクセスできます。

  • 「Only the following Program Groups」では、ユーザのアクセスを許可するプログラムを指定できます。ドロップダウンリストからプログラムを選択します。Control キーを押しながらグループをクリックすると、複数のプログラムグループを選択できます。アクセスを制限できるプログラムグループは、次のとおりです。

    • None (デフォルト)

    • Servers

    • Preference

    • Global Settings

    • Users & Groups

    • Security

    • Cluster Mgmt

    リストに表示されたプログラムグループは、Administration Server のタブに反映されます。たとえば、「Preferences」や「Global Settings」などのタブに反映され、各ページへのアクセスを表します。管理者が Administration Server にアクセスする場合、サーバは管理者のユーザ名、ホスト、および IP を使用して、参照できるページを特定します。

  • 「Program Items」では、「Program Items」フィールドにページ名を入力して、プログラムの特定のページへのアクセスを制御することができます。

    ページ名を調べるには、Administration Server の左側のフレームに表示されるリンクにポインタを置き、ブラウザの下部にあるステータスバーに表示されるテキストを参照します。テキストの中で、最後に出現する %2b よりもあとの部分がページ名です。

    たとえば、iPlanet Directory Server を管理しているユーザに「Configure Directory Service」のページへのアクセスを許可する場合、そのユーザ (ホスト、IP など) だけに適用される規則を設定し、「Program Items」フィールドに「dsconfig」と入力します。

図 8-11    ページ名/プログラムアイテム


アクセス権の設定

サーバインスタンスに対するアクセス権を設定できるのは、Server Manager を使用した場合だけです。アクセス権は、Web サイトのファイルやディレクトリへのアクセスを制限します。すべてのアクセス権の承認または拒否に加えて、一部のアクセス権の承認または拒否を行うための規則を指定することもできます。たとえば、ユーザに対してファイルへの読み取り専用アクセスを許可することができます。この設定では、ユーザは情報を参照することはできますが、ファイルを変更することはできません。

  • 「All Access Rights」はデフォルトで、すべてのアクセス権を承認または拒否します。

  • 「Only the following rights」では、 許可、または拒否するアクセス権の組み合わせを選択できます。

    • 「Read」は、ユーザにファイルの参照を許可します。これには、GET、HEAD、POST、および INDEX の HTTP メソッドが含まれます。

    • 「Write」は、ユーザにファイルの変更や削除を許可します。これには PUT、DELETE、MKDIR、MDIR、および MOVE の HTTP メソッドが含まれます。ファイルを削除するには、書き込み権と削除権の両方が必要です。

    • 「Execute」は、ユーザに CGI プログラム、Java アプレット、エージェントなどのサーバ側アプリケーションの実行を許可します。

    • 「Delete」は、書き込み権を持つユーザにファイルやディレクトリの削除を行う権限を与えます。

    • 「List」は、ユーザに index.html ファイルが存在しないディレクトリ内のファイルリストへのアクセスを許可します。

    • 「Info」は、ユーザに URI、たとえば http_head についての情報の取得を許可します。


カスタマイズされた式の作成

ACL には、カスタマイズした式を入力できます。このオプションは、ACL ファイルの構文や構造をよく理解している場合にだけ選択してください。ACL ファイルを編集するか、カスタマイズした式を作成する場合にだけ使用できる機能がいくつかあります。たとえば、時刻、曜日、またはその両方を基準として、サーバへのアクセスを制限することができます。

次のカスタマイズされた式で、時刻や曜日によってアクセスを制限する方法を示します。この例では、LDAP ディレクトリに 2 つのグループがあることを前提としています。「regular」グループは、月曜日から金曜日までの午前 8 時から午後 5 時までアクセスできます。「critical」グループは、いつでもアクセスできます。

allow (read)
{
   (group=regular and dayofweek="mon,tue,wed,thu,fri");
   (group=regular and (timeofday>=0800 and timeofday<=1700));
   (group=critical)
}

有効な構文と ACL ファイルについては、付録 C「ACL ファイルの構文」と「obj.conf での ACL ファイルの参照」を参照してください。


アクセス制御の解除

「Access control is on」チェックボックスのチェックマークを外した場合、ACL 内のレコードを消去するかどうかを確認するプロンプトが表示されます。「OK」をクリックすると、サーバは ACL ファイルから該当するリソースの ACL エントリを削除します。

ACL を無効にしたい場合、generated-https-server-id.acl ファイルの各行の先頭に # 記号を挿入することによって、ACL が記述された行をコメントアウトします。

Administration Server からアクセス制御を作成し、特定のサーバインスタンスに対して有効に設定し、ほかのサーバに対しては無効 (デフォルト) のままにしておくことができます。たとえば、Administration Server から「Server Manager」ページへのアクセスをすべて拒否することができます。デフォルトでは、ほかのサーバに対して、分散管理は有効にアクセス制御は無効に設定されます。管理者は Administration Server を構成することはできませんが、ほかのサーバにアクセスして構成することはできます。


注 このアクセス制御は、管理者グループのユーザに対して、分散管理のために設定されます。Administration Server はまず、ユーザ (スーパーユーザを除く) が管理者グループのメンバーであることを確認してから、アクセス制御規則を評価します。



アクセスが拒否された場合の応答

アクセスが拒否された場合、iPlanet Web Server はデフォルトメッセージ「FORBIDDEN. Your client is not allowed access to the restricted object.」を送信します。別の応答メッセージを選択することもできます。また、アクセス制御オブジェクトごとに異なるメッセージを作成することもできます。

特定の ACL に送信されるメッセージを変更するには、次の手順を実行します。

  1. 「ACL」ページの「Response when denied」リンクをクリックします。

  2. 下のフレームの「Respond with the following」チェックボックスにチェックマークを付けます。

  3. 絶対 URL または相対 URI へのパスを入力し、「update」をクリックします。

    ユーザにリダイレクト先の URL または URI へのアクセス権があることを確認します。

  4. 「Update」をクリックします。

  5. 上部フレームの「Submit」をクリックし、アクセス制御規則を送信します。



サーバの一部へのアクセス制御

この節では、Web サーバとその内容に対して一般的に使用されているアクセス制限について説明します。各制限の手順では、実行する必要のある操作を詳細に説明しています。ただし、「サーバインスタンスに対するアクセス制御の設定」で説明している手順も、すべて実行する必要があります。

この節で説明する制限を次に示します。


サーバ全体に対するアクセス制限

呼び出されたグループ内のユーザに対して、サブドメイン内のコンピュータからサーバへのアクセスを許可したい場合があります。たとえば、ある会社のある部署のサーバで、ネットワークの特定のサブドメインにあるコンピュータからのアクセスだけをユーザに対して許可したい場合です。

サーバインスタンスに対するアクセス制御の設定の節で説明した手順を使用して、次の操作を実行します。

  1. Server Manager を使用して、サーバインスタンスを選択します。

  2. 「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 編集する ACL ファイルを選択します。

  5. サーバリソース全体を選択し、「Edit Access Control」をクリックします。

  6. すべてのアクセスを拒否する、新しい規則を追加します。

  7. 特定のグループへのアクセスを許可する、別の新しい規則を追加します。

  8. アクセスを許可するコンピュータのホスト名として、ワイルドカードパターンを入力します。

    たとえば、「*.employee.iplanet.com」と入力します。

  9. 「Continue」チェックボックスのチェックマークを外します。

  10. 変更を送信して適用します。


ディレクトリ (パス) へのアクセス制限

グループの所有者によって制御されているディレクトリおよびサブディレクトリにある、ファイルやアプリケーションの読み取りまたは実行をグループ内のユーザに許可することができます。たとえば、プロジェクトマネージャは、参照するプロジェクトチームのステータス情報を更新できます。

サーバのディレクトリへのアクセスを制限するには、サーバインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。

  1. Server Manager を使用して、サーバインスタンスを選択します。

  2. 「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 編集する ACL ファイルを選択します。

  5. 「Pick a Resource」セクションを参照して、アクセスを制限するディレクトリを選択します。

    サーバのドキュメントルート内のディレクトリが表示されます。選択すると、「Editing」ドロップダウンリストにディレクトリへの絶対パスが表示されます。


    注

    サーバルート内のすべてのファイルが表示されるようにする場合は、「Options」をクリックし、ディレクトリと「List files」チェックボックスにチェックマークを付けます。


  6. 「Edit Access Control」をクリックします。

  7. 新しい規則を作成し、デフォルト設定をそのまま使用して、すべての場所からのすべてのアクセスを拒否します。

  8. 特定のグループのユーザに対して、読み取り権と実行権だけを許可する別の新しい規則を作成します。

  9. 3 行目を作成し、特定のユーザに対してすべてのアクセス権を許可します。

  10. 2 行目と 3 行目の「Continue」チェックボックスのチェックマークを外して、「Update」をクリックします。

  11. 変更を送信して適用します。

ファイルまたはディレクトリへの絶対パスが docroot ディレクトリに作成されます。ACL ファイルのエントリは、次のようになります。acl "path=d:\iPlanet\suitespot\docroot1\sales/";


URI (パス) へのアクセス制限

URI を使用して、Web サーバ上のシングルユーザのコンテンツへのアクセスを制御することができます。URI は、サーバのドキュメントルートディレクトリを始点とした、相対的なパスとファイル名です。サーバのコンテンツのすべて、または一部 の名前(たとえば、ディスクのボリューム名) を頻繁に変更したり削除したりする場合、URI を使用すると簡単です。また、ほかにドキュメントルートがある場合にも、URI を使用するとアクセス制御を簡単に行えます。

URI へのアクセスを制限するには、サーバインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。

  1. Server Manager を使用して、サーバインスタンスを選択します。

  2. 「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 「ACL name」セクションの「Type」に、アクセスを制限する URI を入力します。

    次に例を示します。uri=/my_directory

  5. 「Edit Access Control」をクリックします。

  6. すべてのユーザに対して読み取りアクセスを許可する、新しい規則を作成します。

  7. ディレクトリの所有者に対してアクセスを許可する、別の規則を作成します。

  8. 1 番目の規則と 2 番目の規則の両方の「Continue」チェックボックスのチェックマークを外します。

  9. 「Submit and Apply your changes」をクリックします。

ドキュメントルートに対して相対的な URI へのパスが作成されます。ACL ファイルのエントリは、次のようになります。

uri=/my_directory


ファイルタイプに対するアクセス制限

ファイルのタイプに基づいて、サーバまたは Web サイトへのアクセスを制限することができます。たとえば、特定のユーザだけに、サーバで実行されるプログラムの作成を許可することができます。すべてのユーザがプログラムを実行できますが、作成や削除を実行できるのはグループ内の指定されたユーザだけです。

アクセスできるファイルタイプを制限するには、サーバインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。

  1. Server Manager を使用して、サーバインスタンスを選択します。

  2. 「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 「Pick a resource」セクションで「Wildcard」をクリックし、ワイルドカードパターンを入力します。

    たとえば、「*.cgi」と入力します。

  5. 「Edit Access Control」をクリックします。

  6. すべてのユーザに対して読み取りアクセスを許可する、新しい規則を作成します。

  7. 指定されたグループだけに読み取りアクセスと削除アクセスを許可する、別の規則を作成します。

  8. 変更を送信して適用します。

ファイルタイプの制限については、両方の「Continue」チェックボックスのチェックマークを付けたままにします。ファイルが要求されると、サーバはまず、ACL のファイルタイプを確認します。

Pathcheck 関数は obj.conf 内に作成されます。この関数には、ファイルまたはディレクトリのワイルドカードパターンが含まれる場合あります。ACL ファイルのエントリは、次のようになります。

acl "*.cgi";


時刻に基づくアクセス制限

指定した日の指定した時間に、サーバに対する読み取りアクセスと削除アクセスを制限することができます。この制限を使用して、ファイルがアクセスされている可能性がある勤務時間中には、ユーザがファイルを変更したり削除したりできないようにすることができます。

時刻を基にしてアクセスを制限するには、サーバインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。

  1. Server Manager を使用して、サーバインスタンスを選択します。

  2. 「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 「Pick a Resource」ドロップダウンリストから「entire server」を選択し、「Edit Access Control」をクリックします。

  5. すべてのユーザに対して読み取り権と実行権を許可する、新しい規則を作成します。

    これは、ユーザがファイルやディレクトリの追加、更新、または削除を行いたい場合にはこの規則が適用されず、サーバは該当する別の規則を検索することを意味します。

  6. すべてのユーザに対して読み取り権と削除権を拒否する、別の規則を作成します。

  7. 「X」リンクをクリックして、カスタマイズされた式を作成します。

  8. アクセスを許可する曜日と時刻を入力します。

    次に、その例を示します。
    user = "anyone" and
    dayofweek = "sat,sun" or
    (timeofday >= 1800 and
    timeofday <= 600)

    カスタム式を作成すると、「Unrecognized expressions」メッセージが「Users/Groups」フィールドと「From Host」フィールドに表示されます。

  9. 変更を送信して適用します。

カスタマイズした式にエラーがあると、エラーメッセージが生成されます。修正してから、もう一度送信してください。


セキュリティに基づくアクセス制限

iPlanet Web Server 6.0 では、1 つのサーバインスタンスに SSL を使用する待機ソケットと SSL を使用しない待機ソケットを構成することができます。セキュリティに基づく制限を使用すると、セキュリティ保護されたチャネルを経由して送信する必要のあるリソースを保護できます。

セキュリティに基づいてアクセスを制限するには、サーバインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。

  1. Server Manager を使用して、サーバインスタンスを選択します。

  2. 「Preferences」タブを選択します。

  3. 「Restrict Access」リンクをクリックします。

  4. 「Pick a Resource」ドロップダウンリストから「entire server」を選択して、「Edit Access Control」をクリックします。

  5. すべてのユーザに対して読み取り権と実行権を許可する、新しい規則を作成します。

    これは、ユーザがファイルやディレクトリの追加、更新、または削除を行う場合にはこの規則が適用されず、サーバは該当する別の規則を検索することを意味します。

  6. すべてのユーザに対して書き込み権と削除権を拒否する、別の規則を作成します。

  7. 「X」リンクをクリックして、カスタマイズされた式を作成します。

  8. 「ssl="on"」と入力します。

    次に、入力例を示します。
    user = "anyone" and ssl="on"

  9. 変更を送信して、適用します。

カスタマイズした式にエラーがあると、エラーメッセージが生成されます。修正してから、もう一度送信してください。



動的アクセス制御ファイルの使用


サーバのすべてのコンテンツが 1 人のユーザによって管理されることはほとんどありません。このため、iPlanet Web Server へのアクセス権を与えることなく、一般ユーザが必要な構成を行えるように、構成オプションのサブセットへのアクセスを許可することが必要な場合があります。構成オプションのサブセットは、動的構成ファイルに保存されます。

この節で説明する内容を次に示します。


.htaccess ファイルの使用

iPlanet Web Server は、動的構成ファイルである .htaccess をサポートします。ユーザインタフェースから、または構成ファイルを手動で変更することによって、.htaccess ファイルを有効にすることができます。.htaccess をサポートするファイルは、server_root/plugins/htaccess ディレクトリにあります。これらのファイルには、.htaccess ファイルと、.nsconfig ファイルを .htaccess ファイルに変換するためのスクリプトを使用できるようにするプラグインが含まれています。

.htaccess ファイルは、サーバの標準アクセス制御と組み合わせて使用することができます。標準アクセス制御は、PathCheck 指令の順序に関係なく、必ず .htaccess アクセス制御の前に適用されます。ユーザ-グループ認証が「基本」の場合、ユーザ認証には標準アクセス制御と .htaccess アクセス制御の両方は必要ありません。標準サーバアクセス制御を経由して SSL クライアント認証を使用でき、.htaccess ファイルを経由して HTTP「基本」認証を要求することもできます。

この節では、次の内容について説明します。


ユーザインタフェースからの .htaccess の有効化

.htaccess を使用するように iPlanet Web Server を設定するには、次の手順を実行します。

  1. Server Manager にアクセスし、.htaccess を有効にするサーバインスタンスを選択します。

  2. 画面の一番上にある「Class Manager」リンクをクリックします。

  3. 「Content Mgmt」タブを選択します。

  4. 「.htaccess Configuration」リンクをクリックします。

  5. 次の方法で、編集するサーバを選択します。

    • ドロップダウンリストからサーバ全体または特定のサーバを選択します。

    • 「Browse」をクリックして、編集するディレクトリやファイルを選択します。

    • 「Wildcard」をクリックして、編集するワイルドカードパターンを選択します。

  6. 「Yes」を選択して、.htaccess を有効にします。

  7. .htaccess 構成を追加するファイル名を入力します。

  8. 「OK」をクリックします。

  9. 完了したら、「Apply」をクリックします。

  10. 「hard start /restart」または「dynamically apply」を選択します。


magnus.conf からの .htaccess の有効化

.htaccess を使用するサーバを手動で有効にするにはまず、プラグインを読み込んで初期化してから起動するように、サーバの magnus.conf ファイルを修正する必要があります。

  1. server_root/https-server_name/config ファイルの magnus.conf を開きます。

  2. ほかの Init 指令のあとに、必要な行を追加します。

    • UNIX/Linux の場合は、次の行を追加します。

      Init fn="load-modules" funcs="htaccess-init,htaccess-find"
      shlib="      server_root/plugins/htaccess/htaccess.so" NativeThread="no"
      Init fn="htaccess-init"

    • Windows NT の場合は、次の行を追加します。

      Init fn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register"
      shlib="      server_root/plugins/htaccess/htaccess.dll" NativeThread="no"
      Init fn="htaccess-init"

    • HP の場合は、次の行を追加します。

      Initfn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register" shlib="<server_root>/plugins/htaccess/htaccess.sl" NativeThread="no"

      Init fn="htaccess-init"

  3. (省略可能) 最後の行を次のように編集します。

    Init fn="htaccess-init"[groups-with-users=yes]

  4. 「File」の「Save」をクリックします。

  5. obj.conf を開きます。

  6. オブジェクトの最後の指令として、PathCheck 指令を追加します。

    1. 仮想サーバによって管理されるすべてのディレクトリに対して .htaccess ファイルの処理を有効にするには、object.conf ファイルのデフォルトオブジェクトに PathCheck 指令を追加します。

      <Object name="default">

      ...

    PathCheck fn="htaccess-find"

    </Object>

    .htaccess の処理をオブジェクトの最後の PathCheck 指令にする必要があります。

    1. サーバ上の特定のディレクトリを対象とした .htaccess ファイルの処理を有効にするには、magnus.conf 内の対応する定義に PathCheck 指令を配置します。

  7. .htaccess ファイルに .htaccess 以外の名前を付けるには、次の形式を使用して PathCheck 指令でファイル名を指定する必要があります。

    PathCheck fn="htaccess-find" filename="filename"
    注 次に Administration Server を使用するとき、手動で修正が行われたことを知らせる警告メッセージが表示されます。「Apply」をクリックすると、変更が有効になります。


それ以降のサーバへのアクセスは、指定されたディレクトリでの .htaccess によるアクセス制御の対象となります。たとえば、.htaccess ファイルへの書き込みアクセスを制限するには、対象ファイルの構成スタイルを作成し、その構成スタイルに対してアクセス制御を適用します。詳細は、第 17 章「構成スタイルの適用」を参照してください。


既存の .nsconfig ファイルの .htaccess ファイルへの変換

iPlanet Web Server 6.0 には、旧バージョンで使用していた既存の .nsconfig ファイルを .htaccess ファイルに変換するための htconvert プラグインが組み込まれています。iPlanet Web Server 6.0 では、.nsconfig ファイルがサポートされていません。このため、これまで .nsconfig ファイルを使用していた場合は、.htaccess ファイルに変換する必要があります。

htconvert は有効になっている場合、pfx2dir 指令と document-root 指令に対して、指定された server.xml ファイルを検索します。検出された各 .nsconfig ファイルは、.htaccess ファイルに変換されます。構成によっては、複数の obj.conf ファイルを変換できます。

注 既存の .htaccess ファイルがある場合、htconvert によって htaccess.new ファイルが生成され、警告メッセージが表示されます。.htaccess と .htaccess.new がすでに存在している場合、新しいファイルは .htaccess.new.new という名前になります。つまり .new は繰り返し追加されます。


現在、htconvert プラグインは RestrictAccess 指令と RequireAuth 指令、および <Files> ラッパーだけをサポートしています。<Files*> 以外の <Files> がある場合は、警告メッセージが表示され、スクリプトはディレクトリ内のすべてのファイルへのアクセスが制御されるように動作します。

ファイルを変換するには、コマンドプロンプトで、使用しているシステムの Perl へのパス、プラグインスクリプトへのパス、server.xml ファイルへのパスを入力します。次に例を示します。

server_root\install\perl server_root/plugins/htaccess/htconvert server_root/https-server_name/config/server.xml

すべての .nsconfig ファイルが .htaccess ファイルに変換されますが、変換元のファイルが削除されることはありません。

groups-with-users オプションによって、多数のユーザをグループとして処理できます。多数のユーザがグループのメンバーとなっている場合は、次の手順を実行します。

  1. ユーザファイルの書式を修正して、ユーザがメンバーとなっているすべてのグループのリストを表示します。

    username:password:group1,group2,group3,...groupn

  2. AuthGroupFile 指令を修正して、AuthUserFile と同じファイルを指定します。

また、次のように実行することもできます。

  1. AuthGroupFile 指令全体を削除します。

  2. magnus.conf ファイルの Init fn=htaccess-init 行に、次の内容を追加します。

    groups-with-users="yes"


htaccess-register の使用

htaccess-register は、認証メソッドを独自に作成するための新しい関数です。Apache と同様に、外部認証モジュールを作成し、htaccess-register を使用して .htaccess モジュールに組み込むことができます。server_root/plugins/nsapi/htaccess に 2 つのサンプルモジュールがあります。

外部モジュールを使用すると、1 つまたは複数の新しい指令を作成できます。たとえば、認証のためのユーザデータベースを指定できます。ただし、指令を <Limit> タグまたは <LimitExcept> タグで囲むことはできません。


.htaccess ファイルの例

次の内容は、.htaccess ファイルの例です。
<Limit> GET POST
order deny,allow
deny from all
allow from all
</Limit>
<Limit> PUT DELETE
order deny,allow
deny from all
</Limit>
AuthName mxyzptlk.kawaii.com
AuthUserFile /server_root/mxyz-docs/service.pwd
AuthGroupFile /server_root/mxyz-docs/service.grp


サポートされる .htaccess 指令

このバージョンでは、次の .htaccess 指令がサポートされます。


allow


構文
Allows from host。host は次のいずれかです。

  • すべてのクライアントホストからのアクセスを許可する場合、host は all

  • DNS ホスト名のすべてまたは最後の部分

  • IP アドレス全体またはその一部

<Limit> または <LimitExcept> で囲む必要はありませんが、通常は囲まれています。


効果
指定したホストに対してアクセスを許可します。通常、<Limit> タグで囲まれています。


deny


構文
Deny from host。host は次のいずれかです。

  • すべてのクライアントホストからのアクセスを拒否する場合、host は all

  • DNS ホスト名のすべてまたは最後の部分

  • IP アドレス全体またはその一部

<Limit> タグまたは <LimitExcept> タグで囲む必要はありませんが、通常は囲まれています。


効果
指定したホストに対してアクセスを拒否します。通常、<Limit> タグで囲まれています。


AuthGroupFile


構文
AuthGroupFile filename。filename は、groupname: user user という形式でグループ定義が含まれるファイルの名前です。

<Limit> タグまたは <LimitExcept> タグで囲むことはできません。


効果
指定されたグループファイルが、require group 指令で参照されるグループ定義で使用されることを示します。AuthGroupFile 指令で指定されたファイル名が AuthUserFile 指令で指定されたファイル名と同じである場合、このファイルには次の形式でユーザとグループが含まれると想定されることに注意してください。

username:DES-encrypted-password:comma-separated-list-of-groups


AuthUserFile


構文
AuthUserFile filename。次のように指定します。

  • filename は、次の形式でユーザ定義が含まれるファイルの名前 username:password

  • username はユーザのログイン名で、password は DES で暗号化されたパスワード

<Limit> タグまたは <LimitExcept> タグで囲むことはできません。


効果
指定されたユーザファイルが、require user 指令または require valid-user 指令で参照されるユーザ名で使用されることを示します。

obj.conf の Init fn=htaccess-init 指令で groups-with-users=yes を使用したり、同じファイル名で AuthGroupFile 指令を指定したりすると、そのファイルが次の形式であると想定されることに注意してください。

username:DES-encrypted-password:comma-separated-list-of-groups


AuthName


構文
AuthName authentication realm。authentication realm は、ユーザ認証の要求に関連付けられる認証領域を指定する文字列です。

<Limit> タグまたは <LimitExcept> タグで囲むことはできません。


効果
authentication realm 文字列は、通常、クライアント側のユーザ名とパスワードのプロンプトに表示されます。クライアントのユーザ名とのパスワードのキャッシングに影響を与える場合があります。


AuthType


構文
AuthType Basic。<Limit> タグや <LimitExcept> タグで囲むことはできません。


効果
ユーザ認証メソッドとして、現在サポートされている唯一のメソッドである HTTP 基本認証を指定します。


<Limit>


構文
<Limit method method ...>

allow, deny, order, or require directives

</Limit>

method は GET、POST、PUT などの HTTP メソッドです。ここでは、Web サーバが理解できるあらゆるメソッドを使用できます。


効果
指定された HTTP メソッドを使用する要求だけに、タグで囲まれている指令が適用されます。


<LimitExcept>


構文
<LimitExcept method method ...>

allow, deny, order, or require directives

<LimitExcept>

method は GET、POST、PUT などの HTTP メソッドです。ここでは、Web サーバに対して使用できるすべてのメソッドを使用できます。


効果
指定された HTTP メソッドと一致しないタイプの要求に限って、タグで囲まれている指令が適用されます。


order


構文
Order ordering。ordering は次のいずれかです。

  • allow、deny

  • deny、allow

  • mutual-failure

必ずしも <Limit> または <LimitExcept> で囲む必要はありませんが、通常は囲まれています。


効果

  • allows、denies、evaluates は指令を許可し、そのあと、指令を拒否する

  • denies、allows、evaluates は指令を拒否し、そのあと、指令を許可する

  • mutual-failure は順序に関係なく、allow 指令と deny 指令の両方でリストに表示されているホストに対するアクセスを拒否する


require


構文

  • requires group groupname groupname

  • requires user username username

  • requires valid-user

<Limit> または <LimitExcept> で囲む必要はありませんが、通常は囲まれています。


効果

  • requires group は、認証を受けるユーザが、指定したグループのいずれかのメンバーであることを要求する

  • requires user は、認証を受けるユーザが、指定したユーザのいずれかであることを要求する

  • requires valid-user は、認証されたユーザを要求する


.htaccess セキュリティに関する注意事項

デフォルトでは、サーバによる HTTP PUT のサポートが無効になっています。Class Manager の「Content Mgmt」の「Remote File Manipulation」ページを使用して、HTTP PUT を有効にすることができます。.htaccess ファイルが保存されているディレクトリへの PUT アクセスを許可する場合、このファイル自体の置換も許可することになるため、細心の注意が必要です。アクセスを制限することによって、ディレクトリ内のすべてのファイルに対する PUT アクセスを防止することができます。「ディレクトリ (パス) へのアクセス制限」を参照してください。



仮想サーバへのアクセス制御


iPlanet Web Server 6.0 のアクセス制御についての情報は、各仮想サーバの ACL ファイルと、ドキュメントディレクトリの .htaccess ファイルから入手できます。.htaccess システムは iPlanet Web Server 4.x から変更されていません。

server.xml ファイルには、特定の標準 iPlanet Web Server 6.x ACL ファイルに関連付けられた ID を定義する、1 つまたは複数の ACLFILE タグが含まれています。次に例を示します。

<ACLFILE id="standard" file="standard.acl">

アクセス制御を使用する仮想サーバの場合は、「aclids」プロパティに 1 つまたは複数の ACL ファイル ID への参照を作成する必要があります。次に、その例を示します。

<VS aclids="standard">

この構成では、複数の仮想サーバで同じ ACL ファイルを共有することができます。仮想サーバに対するユーザ-グループ認証を要求する場合は、その定義に 1 つまたは複数の USERDB タグを追加する必要があります。このような USERDB タグは、ACL ファイル内のデータベース名と dbswitch.conf 内の実際のデータベースを関連付けます。

次の例では、「database」属性のない ACL を dbswitch.conf の「default」データベースにマッピングします。

<VS>

   <USERDB id="default" database="default"/>

</VS>


仮想サーバからデータベースへのアクセス

dbswitch.conf ファイルで、ユーザ認証データベースをグローバルに定義できます。このファイルは、サーバの起動時に読み込まれます。

dbswitch.conf 内の LDAP URL の baseDN は、データべースへのすべてのアクセスのグローバルルートを定義します。これによって、下位互換が維持されます。最新のインストールでは、baseDN が空白になります。

dcsuffix は dbswitch.conf 内の LDAP データベースの新しい属性で、iPlanet LDAP スキーマに従って DC ツリーのルートを定義します。これは、LDAP URL の baseDN に対する相対位置になります。dcsuffix 属性が存在する場合、LDAP データベースは iPlanet LDAP スキーマに準拠し、動作の一部が変更されます。iPlanet LDAP スキーマの詳細と例については、『NSAPI プログラマーズガイド』の第 8 章にある「iPlanet LDAP スキーマ」を参照してください。

仮想サーバごとに、ディレクトリの 1 つを指定する 1 つまたは複数の USERDB ブロックを定義できます。また、追加情報を定義することもできます。USERDB ブロック ID は、ACL のデータベースパラメータから参照することができます。仮想サーバに USERDB ブロックがない場合、ユーザまたはグループを基準にした ACL は失敗します。

USERDB タグは、ACL のデータベース属性と dbswitch.conf の間の間接参照の追加層を定義します。間接参照のこの層では、仮想サーバの管理者がアクセスするデータベースをサーバ管理者が完全に制御するために必要な保護を追加します。

USERDB の指令の詳細は、『NSAPI プログラマーズガイド』の第 8 章にある「ユーザデータベースの選択」を参照してください。


ユーザインタフェースでの LDAP データベースの指定

dbswitch.conf で 1 つまたは複数のユーザ認証データベースを定義すると、Class Manager を使用して、各仮想サーバが認証のためにどのデータベースを使用するかを構成できるようになります。また、Class Manger を使用して、仮想サーバでの認証のために dbswitch.conf での設定に対して新しく作成したデータベース定義を追加することができます。

LDAP データベースまたは仮想サーバで使用するデータベースを指定するには、次の手順を実行します。

  1. Server Manager にアクセスし、「Virtual Server Class」タブを選択します。

  2. 「Tree View of the Server」のリストで、仮想サーバクラスのリンクをクリックし、LDAP データベースを指定します。

  3. 表示されていない場合は、「Virtual Servers」タブを選択します。

  4. 「ACL Settings」リンクをクリックします。

  5. 「Select a Setting」ドロップダウンリストから「ACL Settings」を選択します。

    「ACL Settings for Virtual Servers」ページが表示されます。

  6. 表示されていない場合は、「Option」列のドロップダウンリストから「Edit」を選択します。

  7. 編集している仮想サーバの「Database」列でドロップダウンリストからデータベース設定を選択します。

  8. 「OK」をクリックします。

  9. 「Edit ACL Files」ウィンドウを閉じます。

  10. 「Apply」をクリックします。

  11. 「dynamically apply」を選択します。


仮想サーバのアクセス制御リストの編集

仮想サーバの ACL は、仮想サーバがあるサーバインスタンスに対して作成されます。仮想サーバの ACL 設定は、サーバインスタンスに対して作成される ACL 設定のデフォルトとなります。ただし、各仮想サーバのアクセス制御は Class Manager から編集できます。また、このメソッドを使用して、新しく作成された ACL ファイルを仮想サーバに追加します。

仮想サーバの ACL 設定を編集するには、次の手順を実行します。

  1. Server Manager にアクセスし、「Virtual Server Class」タブを選択します。

  2. 「Tree View of the Server」のリストから、LDAP データベースを指定したい仮想サーバクラスのリンクをクリックします。

  3. 表示されていない場合は、「Virtual Servers」タブを選択します。

  4. 「ACL Settings」リンクをクリックします。

  5. 変更する仮想サーバの「Option」フィールドのドロップダウンリストから「Edit」または「Delete」を選択します。

  6. 「ACL File」フィールドの「Edit」リンクをクリックすると、使用できる ACL ファイルが表示されます。

  7. 仮想サーバに追加または削除する 1 つまたは複数の ACL ファイルを選択します。

    仮想サーバには複数のドキュメントルートが存在する場合があるため、複数の ACL ファイルが存在する可能性があります。

  8. ドロップダウンリストから、ACL リストに関連付けるデータベースを選択します。

  9. (省略可能) BaseDN を入力します。

  10. 変更が終わったら、「OK」をクリックします。

  11. 「Apply」をクリックします。

  12. 「dynamically apply」を選択します。


前へ     目次     索引     DocHome     次へ     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated October 17, 2001