Sun Java System Web Proxy Server 4.0.4 管理ガイド

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

この章では、管理サーバーおよび Proxy Server によって処理されるデータへのアクセス制御の方法について説明します。サーバーにより処理されるすべてのデータ、またはサーバーがサービスを提供する特定の URL のアクセスを制限できます。たとえば、特定の URL へのアクセスを特定のユーザーに限定したり、特定のユーザー以外のすべてのユーザーがファイルを表示できるように指定できます。すべてのクライアントに HTTP の URL へのアクセスを許可し、FTP へは限定されたアクセスのみを許可することもできます。また、複数の内部 Web サーバーにサービスを提供している Proxy Server があり、それらのサーバーのいずれかに格納された極秘調査プロジェクトへは特定のユーザーのみがアクセスできるようにしたい場合などに、ホスト名またはドメイン名に基づいて URL を制限することもできます。

管理サーバーでアクセス制御を使用するには、分散管理を有効にして、LDAP データベースに管理グループを設定する必要があります。この章の内容は、それらの作業が済んでいることを前提としています。

この章の内容は次のとおりです。

アクセス制御とは

アクセス制御により、Proxy Server にアクセスできるユーザー、およびアクセス可能なサーバーの部分を指定することができます。サーバーへのアクセスの制御は、サーバー全体に対して、またはディレクトリ、ファイル、ファイルタイプなどのサーバーの一部に対して行うことができます。受信した要求が評価される場合、アクセス制御エントリ (Access Control Entry、ACE) と呼ばれる規則の階層に基づいてアクセスが決定されます。Proxy Server は一致するエントリを検索して、アクセスを許可するか、拒否するかを決定します。各 ACE は、サーバーが階層内の次のエントリに進むべきかどうかを指定します。ACE の集合は、アクセス制御リスト (ACL) と呼ばれます。要求を受信すると、obj.conf ファイルでアクセスの決定に使用される ACL の参照がチェックされます。デフォルトでは、サーバーには複数の ACL が含まれる 1 つの ACL ファイルがあります。

アクセスは次の内容に基づいて許可または拒否されます。

要求を送信したユーザー (ユーザー - グループ)
要求の送信元 (ホスト - IP)
要求が発生した日時 (時刻など)
使用されている接続のタイプ (SSL)

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

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

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

管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、obj.conf の ACL ファイルを手動で編集し、認証方法を SSL に変更する必要があります。

ユーザー - グループ認証は、サーバーに設定されているディレクトリサービスによって実行されます。詳細は、「ディレクトリサービスの設定」を参照してください。

ディレクトリサービスがアクセス制御の実装に使用する情報は、次のソースのいずれかから入手できます。

内部フラットファイルタイプのデータベース
外部 LDAP データベース

サーバーは、外部 LDAP ベースのディレクトリサービスを使用するとき、サーバーインスタンスに対して次のタイプのユーザーグループ認証方法をサポートします。

デフォルト
基本
SSL
ダイジェスト
その他

サーバーが内部ファイルベースのディレクトリサービスを使用するときに、サーバーインスタンスに対してサポートされるユーザー - グループ認証方法には、次のものがあります。

デフォルト
基本
ダイジェスト

ユーザー - グループ認証を設定した場合、ユーザーはアクセスする前に、ユーザー自身の認証を求められます。認証の際、ユーザーはユーザー名とパスワードの入力、クライアント証明書の使用、またはダイジェスト認証プラグインを使用することによってユーザー自身の識別情報を証明します。クライアント証明書を使用する場合、暗号化が必要になります。

デフォルト認証

デフォルト認証は、推奨される方法です。デフォルト設定では、obj.conf ファイルで指定したデフォルトの方法を使用します。obj.conf で方法が設定されていない場合は、「Basic」を使用します。「Default」を選択した場合、ACL 規則によって ACL ファイル内の方法が指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL の方法を簡単に変更できます。

基本認証

基本認証を選択した場合、サーバーにアクセスするためにユーザーはユーザー名とパスワードの入力を求められます。基本認証がデフォルトの設定です。Sun Java System Directory Server などの LDAP データベース、またはファイルにユーザーとグループのリストを作成して格納する必要があります。Proxy Server とは別のサーバールートにインストールされたディレクトリサーバー、またはリモートコンピュータにインストールされたディレクトリサーバーを使用する必要があります。

ユーザーがユーザー - グループ認証を行うリソースへアクセスしようとすると、ユーザー名とパスワードの入力を求められます。サーバーで暗号化が設定されている (SSL が有効) かどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。

注 –

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

認証に成功した場合、ユーザーには要求されたリソースが表示されます。ユーザー名またはパスワードが無効な場合は、アクセスが拒否されたことを示すメッセージが発行されます。

承認されていないユーザーから受信するメッセージはカスタマイズできます。詳細は、「アクセスが拒否された場合の応答」を参照してください。

SSL 認証

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

クライアント証明書の情報を識別情報の証明として使用する
LDAP ディレクトリで発行されたクライアント証明書を確認する (追加)

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

信頼できる CA (認証局) から発行された証明書かどうかを確認します。そうでない場合、認証は失敗し、トランザクションが終了します。クライアント認証を有効にする方法については、「セキュリティーに関する詳細設定」を参照してください。
証明書が信頼できる CA から発行されたものである場合は、certmap.conf ファイルを使用して、証明書をユーザーのエントリにマップします。証明書マッピングファイルの設定方法については、「certmap.conf ファイルの使用」を参照してください。
証明書が正しくマップされている場合は、そのユーザーに対して指定されている ACL 規則を確認します。証明書が正しくマップされている場合でも、ACL 規則によってユーザーのアクセスが拒否される可能性もあります。

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

クライアントは信頼できる CA によって発行された有効な証明書を提示する
証明書は LDAP 内の有効なユーザーにマッピングされている
アクセス制御リストで、適切に評価される

アクセス制御を使用してクライアント認証を要求する場合、Proxy Server で SSL 暗号化方式を有効にする必要があります。SSL の有効化については、第 5 章「証明書と鍵の使用」を参照してください。

SSL で認証されるリソースにアクセスするには、Proxy Server により信頼できる CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Proxy Server の certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバーで発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することができます。certmap.conf と証明書マッピングについては、第 5 章「証明書と鍵の使用」を参照してください。『Sun Java System Web Proxy Server 4.0.4 Configuration File Reference 』も参照してください。

ダイジェスト認証

Proxy Server は、LDAP ベースまたはファイルベースのいずれかのディレクトリサービスを使用して、ダイジェスト認証を行うように設定できます。

ダイジェスト認証では、ユーザーがユーザー名とパスワードをクリアテキストとして送信することなく、ユーザー名とパスワードに基づいた認証を行うことができます。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Proxy Server によって提供される情報の一部を使用するダイジェスト値を作成します。

サーバーが LDAP ベースのディレクトリサービスを使用してダイジェスト認証を行うとき、このダイジェスト値は、ダイジェスト認証プラグインを使用してサーバー側で計算され、クライアントによって提示されたダイジェスト値と比較されます。ダイジェスト値が一致した場合、ユーザーは認証されます。これが機能するには、ディレクトリサーバーがクリアテキスト形式のユーザーのパスワードにアクセスできる必要があります。Sun Java System Directory Server にはリバーシブルパスワードプラグインが組み込まれています。このプラグインは、対称暗号化アルゴリズムを使用し、暗号化された形式にしてデータを格納し、あとで元の形式に復号化することができます。データへの鍵を持っているのは Directory Server だけです。

LDAP ベースのダイジェスト認証の場合、リバーシブルパスワードプラグインと、Proxy Server に組み込まれているダイジェスト認証専用のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Proxy Server を設定するには、server-root /userdb/ 内の dbswitch.conf ファイルで、データベース定義のdigestauth プロパティーを設定します。

dbswitch.conf ファイルの例を次に示します。

directory default ldap://<host_name>:<port>
default:binddn cn=Directory Manager
default:encoded bindpw ***********
default:digestauth on

または、

directory default ldap://<host_name>:<port>/
default:binddn cn=Directory Manager
default:encoded bindpw ***********
default:digestauthstate on

サーバーは、指定されている ACL 方式に基づいて、LDAP データベースに対して認証を試みます。「ダイジェスト認証」を参照してください。ACL 方式を指定しない場合、認証が必要であればダイジェスト認証または基本認証のいずれかが使用され、認証が必要ない場合は基本認証が使用されます。

次の表は、認証データベースでサポートされる、あるいはサポートされないダイジェスト認証を示しています。

表 8–1 ダイジェスト認証チャレンジの生成


ACL 方式	認証データベースでサポートされる方式	認証データベースでサポートされない方式
デフォルト指定されていない	ダイジェストと基本	基本
基本	基本	基本
ダイジェスト	ダイジェスト	エラー

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

認証要求のヘッダーを確認します。ヘッダーが見つからない場合は、ダイジェストチャレンジに対して 401 の応答が生成され、プロセスが停止します。
認証のタイプを確認します。認証のタイプがダイジェストの場合、サーバーは次のことを実行します。
- nonce を確認します。このサーバーによって生成された、有効で新しい nonce がない場合は、401 の応答が生成されてプロセスが停止します。nonce が無効な場合は、stale=true として 401 の応答が生成され、プロセスが停止します。
  
  server-root /proxy-server_name/config/ にある magnus.conf ファイルの DigestStaleTimeout パラメータ値を変更することで、nonce の有効期限を設定できます。この値を設定するには、次の行を magnus.conf に追加します。
  
  DigestStaleTimeout seconds
  
  ここで seconds は、nonce の有効期限 (秒) です。指定されている秒数が経過すると、nonce の有効期限は切れ、ユーザーからの新しい認証が必要になります。
- レルムを確認します。一致するものが見つからない場合は、401 の応答が生成されてプロセスが停止します。
- 認証ディレクトリが LDAP ベースの場合は LDAP ディレクトリにユーザーが存在するかどうかを確認します。認証ディレクトリがファイルベースの場合はファイルデータベースにユーザーが存在するかどうかを確認します。ユーザーが見つからない場合は、401 の応答が生成されてプロセスが停止します。
- ディレクトリサーバーまたはファイルデータベースから request-digest 値を取得し、クライアントの request-digest 値と一致する値があるかを調べます。一致するものが見つからない場合は、401 の応答が生成されてプロセスが停止します。
- Authorization-Info ヘッダーを構築し、サーバーヘッダーに挿入します。

ダイジェスト認証プラグインのインストール

LDAP ベースのディレクトリサービスを使用するダイジェスト認証の場合、ダイジェスト認証プラグインをインストールする必要があります。このプラグインは、サーバー側でダイジェスト値を計算し、この値をクライアントによって提供されるダイジェスト値と比較します。ダイジェスト値が一致した場合、ユーザーは認証されます。

ファイルベースの認証データベースを使用する場合、ダイジェスト認証プラグインをインストールする必要はありません。

UNIX でのダイジェスト認証プラグインのインストール

ダイジェスト認証プラグインは、共用ライブラリと ldif ファイルで構成されています。

libdigest-plugin.lib
libdigest-plugin.ldif

UNIX でダイジェスト認証プラグインをインストールするには

始める前に

この共用ライブラリが、Sun Java System Directory Server がインストールされているのと同じサーバーコンピュータにあることを確認します。
ディレクトリマネージャーのパスワードを確認します。
/path/to へのすべての参照が、ダイジェストプラグインの共用ライブラリのインストール先に変更されるように、libdigest-plugin.ldif ファイルを修正します。

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

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

Windows でのダイジェスト認証プラグインのインストール

ダイジェストプラグインとともに Sun Java System Directory Server コンピュータが正しく起動できるようにするには、Proxy Server のいくつかの .dll ファイルを Directory Server コンピュータにコピーする必要があります。

Windows でダイジェスト認証プラグインをインストールするには

server-root \bin\proxy\bin にある Proxy Server の共用ライブラリにアクセスします。

ファイル nsldap32v50.dll、libspnr4.dll、および libplds4.dll を適切なディレクトリにコピーします。

これらのファイルを次の両方の場所にペーストします。
- \Winnt\system32
  - Sun Java System Directory Server インストールディレクトリ: server-root\bin\sldap\server

DES アルゴリズムを使用するための Sun Java System Directory Server の設定

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

DES アルゴリズムを使用するように Directory Server を設定するには

Sun Java System Directory Server コンソールを起動します。

Sun ONE Directory Server 5.1 SP1 (またはそれ以降のバージョン) のインスタンスを開きます。

Configuration タブを選択します。

プラグインの横の + 記号をクリックします。

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

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

iplanetReversiblePassword と入力します。

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

ダイジェスト認証のパスワードを設定します。

注 –

サーバーは、オブジェクトクラス iplanetReversiblePassword 内にある iplanetReversiblePassword 属性を使用します。iplanetReversiblePassword 属性でユーザーのダイジェスト認証のパスワードを使用するには、エントリに iplanetReversiblePasswordobject オブジェクトを含める必要があります。

これを行なうには、ldapmodify を使用するか、Directory Server 管理インタフェースを使用します。

ldapmodify を使用する場合—

digest.ldif ファイルを作成して、LDAP のコマンドを格納します。パスワードを追加するには、手順が 2 つあります。

オブジェクトクラスを digest.ldif に追加します。

このファイルは、次のようになっています (Directory Server ユーザーと ACL に応じて、複数の ldif ファイルがあることがあります)。

dn:uid=user1,dc=india,dc=sun,dc=com
changetype:modify
add:objectclass
objectclass:iplanetReversiblePasswordobject

dn:uid=user1,dc=india,dc=india,dc=sun,dc=com
changetype:modify
add:iplanetReversiblePassword
iplanetReversiblePassword:user1

# ldapmodify -D “cn={CN_Value}” -w <password> -a <ldif_file_name>

Sun Java System Directory Server インスタンスを再起動し、ユーザーの属性が Directory Server データベースに追加されたことを確認します。

その他の認証

アクセス制御 API を使用すると、カスタムの認証方法を作成できます。

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

管理サーバーおよびそのファイルとディレクトリに対して、特定のコンピュータを使用しているクライアントだけが利用できるように、アクセスを制限できます。そのためには、アクセスの許可または拒否を行うコンピュータのホスト名または IP アドレスを指定します。ホスト - IP 認証を使用したファイルまたはディレクトリへのアクセスは、ユーザーにはシームレスに見えます。このため、ユーザーは、ユーザー名やパスワードを入力することなく、すぐにファイルやディレクトリにアクセスできます。

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

ホスト - IP 認証では、サーバーで DNS (ドメインネームサービス) を設定する必要はありません。ホスト - IP 認証を使用する場合は、ネットワークで DNS が稼働しており、この認証を使用するようにサーバーが設定されている必要があります。DNS を有効にするには、サーバーのサーバーマネージャーにアクセスし、「Preferences」タブをクリックし、「Configure System Preferences」をクリックします。DNS の設定が表示されます。

DNS を有効にすると、サーバーで DNS 検索が強制的に実行されるため、Proxy Server のパフォーマンスが低下します。サーバーパフォーマンスへの DNS 検索の影響を小さくするには、すべての要求に対して IP アドレスを解決する代わりに、アクセス制御と CGI に対してだけ IP アドレスを解決します。この制限を設定するには、obj.conf ファイルで次の内容を指定します。

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

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

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

主要な ACL ファイルは generated-proxy-serverid .acl です。一時的な作業ファイルは genwork-proxy-serverid .acl です。管理サーバーを使用してアクセスを設定する場合は、これらの 2 つのファイルが作成されます。ただし、複雑な制約が必要な場合は、複数のファイルを作成し、server.xml ファイルから参照することができます。また、時刻や曜日を基準にしたサーバーへのアクセス制限など、ファイルを編集するだけで利用できる機能もいくつかあります。

アクセス制御ファイルとその構文については、第 18 章「ACL ファイルの構文」を参照してください。server.xml については、『Sun Java System Web Proxy Server 4.0.4 Configuration File Reference』を参照してください。

ACL ユーザーキャッシュの設定

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

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

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

クライアント証明書によるアクセス制御

サーバー上で SSL が有効になっている場合、アクセス制御とともにクライアント証明書を使用できます。特定のリソースへのアクセスにクライアント証明書が必要であることを指定する必要があります。サーバーでこの機能を有効にした場合、証明書を持つユーザーは、制限されたリソースに初めてアクセスを試みる場合にのみ、名前とパスワードを入力します。ユーザーの識別情報がいったん確立されると、サーバーはログイン名とパスワードを個々の証明書にマップします。その後、ユーザーはクライアント認証の必要なリソースにアクセスする場合、ログイン名とパスワードを入力する必要がなくなります。

ユーザーが制限されたリソースへのアクセスを試みた場合、ユーザーのクライアントはクライアント証明書をサーバーに送信し、サーバーはこれをマッピングリストと照合します。証明書がアクセス権を付与したユーザーのものである場合、リソースが提供されます。

特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。また、すべての SSL 接続にクライアント証明書を要求しても、証明書が自動的にデータベース内のユーザーにマップされないことに注意してください。このマッピングを設定するには、特定のリソースへのアクセスにクライアント証明書が必要であることを指定する必要があります。

アクセス制御のしくみ

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

次の例では、ACL ファイルのコンテンツと、アクセス制御規則を示しています。

version 3.0;
# The following "es-internal" rules protect files such
# as icons and images related to Sun Java System Web Proxy 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 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 cannot gain access to the
# directory "web" even though (in the ACL rule below) they
# can access the directory “my_stuff”. Furthermore, members
# of GroupB cannot 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
# users 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, and has been added 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");

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

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

一致する ACL が複数ある場合、サーバーは最後に一致した ACL 文を使用します。

アクセス制御の設定

この節では、アクセスの制限プロセスについて説明します。すべてのサーバーに対してグローバルアクセス制御規則を設定することも、特定のサーバーに対して個別に設定することもできます。たとえば、人事部門では、認証されたすべてのユーザーに各自の給与データを見ることを許可し、データを更新するのは人事部門の給与担当者だけに制限する ACL を作成することもできます。

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

注 –

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

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

すべてのサーバーにアクセス制御を設定するには

管理サーバーにアクセスして、「Global Settings」タブをクリックします。

「Administer Access Control」リンクをクリックします。

ドロップダウンリストから管理サーバー (proxy-admserv) を選択し、「Go」をクリックしてデータをロードし、「New ACL」(または「Edit ACL」) をクリックします。

プロンプトが表示されたら認証します。

「Access Control Rules」ページが表示されます。管理サーバーには、編集できないデフォルトアクセス制御規則が 2 行あります。

チェックマークが付いていない場合は、「Access Control Is On」チェックボックスにチェックマークを付けます。

テーブルの最下行にデフォルトの ACL 規則を追加するには、「New Line」ボタンをクリックします。

アクセス制御の制限位置を変更するには、上向きまたは下向き矢印をクリックします。

「Users/Groups」列の「Anyone」をクリックします。

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

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

グループまたはユーザーの「List」ボタンをクリックすると、選択肢のリストが表示されます。設定については、オンラインヘルプを参照してください。「ユーザーとグループの指定」も参照してください。

「From Host」列の「Anyplace」をクリックします。

下のフレームに「From Host」ページが表示されます。

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

設定については、オンラインヘルプを参照してください。「「From Host」の指定」も参照してください。

「Programs」列の「All」をクリックします。

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

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

設定については、オンラインヘルプを参照してください。「プログラムへのアクセス制限」も参照してください。

(オプション)「Extra」列の「X」をクリックして、カスタマイズした ACL 式を追加します。

下のフレームに「Customized Expressions」ページが表示されます。詳細は、「カスタマイズされた式の作成」を参照してください。

「継続」列のチェックボックスをまだ選択していない場合は、選択します。

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

(オプション) ごみ箱アイコンをクリックして、アクセス制御規則から対応する行を削除します。

(オプション)「Response When Denied」リンクをクリックし、ユーザーがアクセスを拒否されたときに受け取る応答を指定します。

下のフレームに「Access Deny Response」ページが表示されます。
1. 希望する応答を選択します。
2. 必要に応じて追加情報を指定します。
3. 「Update」をクリックします。
設定については、「アクセスが拒否された場合の応答」を参照してください。

「Submit」をクリックして新しいアクセス制御規則を ACL ファイルに保存するか、「Revert」をクリックして、ページ内の要素を変更前の値にリセットします。

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

サーバーマネージャーを使用すると、特定のサーバーインスタンスに対するアクセス制御の作成、編集、または削除を実行できます。削除する場合、ACL ファイルからすべての ACL 規則を削除しないでください。サーバーを起動するには、少なくとも 1 つの ACL 規則が含まれる ACL ファイルが 1 つ以上必要です。すべての ACL 規則を削除してサーバーを再起動すると、構文エラーが発生します。

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

サーバーマネージャーにアクセスしてサーバーインスタンスを選択し、「Preferences」タブをクリックします。

「Administer Access Control」リンクをクリックします。

次の方法のいずれかを使用して ACL を選択します。
- 「Select A Resource」: ACL を使用するリソースを表示して、アクセスを制限します。ドロップダウンリストからリソースを選択するか、「Regular Expression」をクリックして正規表現を指定します。詳細は、『Proxy Server 管理ガイド』の第 16 章「テンプレートとリソースの管理」を参照してください。
- 「An Existing ACL」: 有効なすべての ACL を表示します。
  
  このリストには、有効になっていない既存の ACL は表示されません。ドロップダウンリストから ACL を選択します。
- 「Type In The ACL Name」: 名前付き ACL を作成します。このオプションは、ACL ファイルについてよく理解している場合にだけ使用してください。名前付き ACL をリソースに適用する場合は、obj.conf ファイルを手動で編集する必要があります。詳細は、第 18 章「ACL ファイルの構文」を参照してください。

対応する「Edit」ボタンをクリックします。

「Access Control Rules」ページが表示されます。

チェックマークが付いていない場合は、「Access Control Is On」チェックボックスにチェックマークを付けます。

テーブルの最下行にデフォルトの ACL 規則を追加するには、「New Line」ボタンをクリックします。

アクセス制御の制限位置を変更するには、上向きまたは下向き矢印をクリックします。

このサーバーインスタンス用の ACL を編集するには、「Action」列でアクションをクリックします。

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

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

「Allow」または「Deny」については「アクションの設定」を参照してください。

「Users/Groups」列の「Anyone」をクリックします。下のフレームに「User/Group」ページが表示されます。

アクセスを許可するユーザーやグループを選択し、認証情報を指定して、「Update」をクリックします。

グループまたはユーザーの「List」ボタンをクリックすると、選択肢のリストが表示されます。設定については、オンラインヘルプを参照してください。「ユーザーとグループの指定」も参照してください。

「From Host」列の「Anyplace」をクリックします。

下のフレームに「From Host」ページが表示されます。

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

設定については、オンラインヘルプを参照してください。「「From Host」の指定」も参照してください。

「Rights」列の「All」をクリックします。

下のフレームに「Access Rights」ページが表示されます。

該当ユーザーのアクセス権限を指定し、「Update」をクリックします。

詳細は、「プログラムへのアクセス制限」を参照してください。

(オプション)「Extra」列の「X」をクリックして、カスタマイズした ACL 式を追加します。

下のフレームに「Customized Expressions」ページが表示されます。詳細は、「カスタマイズされた式の作成」を参照してください。

「継続」列のチェックボックスをまだ選択していない場合は、選択します。

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

(オプション) ごみ箱アイコンをクリックして、アクセス制御規則から対応する行を削除します。

ACL ファイルからすべての ACL 規則を削除しないでください。サーバーを起動するには、1 つ以上の ACL 規則が含まれる ACL ファイルが少なくとも 1 つ必要です。ACL ファイルのすべての ACL 規則を削除し、サーバーを再起動しようとすると、構文エラーになります。

(オプション)「Response When Denied」リンクをクリックし、ユーザーがアクセスを拒否されたときに受け取る応答を指定します。

下のフレームに「Access Deny Response」ページが表示されます。希望する応答を選択し、必要に応じて追加情報を指定し、「Update」をクリックします。設定については、「アクセスが拒否された場合の応答」を参照してください。

「Submit」をクリックして新しいアクセス制御規則を ACL ファイルに保存するか、「Revert」をクリックして、ページ内の要素を変更前の値にリセットします。

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

次のトピックでは、アクセス制御を設定するときに選択できるさまざまなオプションについて説明します。管理サーバーの場合は、最初の 2 行はデフォルトとして設定されていて、編集できません。

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

アクションの設定

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

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

サーバーはアクセス制御エントリ (Access Control Entry、ACE) のリストを参照して、アクセス権を決定します。たとえば、最初の ACE は通常、すべてのユーザーを拒否します。最初の ACE に「継続」が設定されている場合、サーバーはリストの 2 番目の ACE を確認し、一致している場合は、次の ACE を使用します。「継続」チェックボックスが選択されていない場合は、すべてのユーザーがリソースへのアクセスを拒否されます。サーバーは、一致しない ACE か、一致しているが継続しない ACE のどちらかに到達するまでリストを参照し続けます。一致する最後の ACE によって、アクセスが許可されるか拒否されるかが決まります。

ユーザーとグループの指定

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

Proxy Server は、Sun Java System Directory Server などの LDAP サーバー、または内部ファイルベースの認証データベースのいずれかに格納されているユーザーとグループのリストを確認します。

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

ユーザーインタフェースの「Access Control Rules」ページにある「Users/Groups」には、次の要素が表示されます。

「Anyone (No Authentication)」はデフォルト値で、すべてのユーザーがユーザー名とパスワードを入力しなくても、リソースにアクセスできることを意味します。ただし、ホスト名や IP アドレスなど、その他の設定に基づいてユーザーのアクセスが拒否される場合もあります。管理サーバーの場合、この設定は、分散管理のために指定した管理者グループ内のすべてのユーザーがページにアクセスできることを意味します。
「Authenticated People Only」
- 「All In The Authentication Database」は、データベースにエントリがあるユーザーに一致します。
- 「Only The following People」では、一致するユーザーとグループを指定します。エントリをコンマ (,) で区切るか、またはワイルドカードパターンを使用すると、ユーザーとユーザーグループの任意のリストを作成することができます。また、データベースに格納されているユーザーやグループのリストから選択することもできます。「Group」は、指定したグループ内のすべてのユーザーに一致します。「User」は、指定した個々のユーザーに一致します。管理サーバーでは、ユーザーを分散管理のために指定した管理者グループのメンバーにする必要があります。
「Prompt For Authentication」では、認証ダイアログボックスに表示されるメッセージテキストを入力します。このテキストを使用して、ユーザーが入力する必要のある項目について説明することができます。オペレーティングシステムによっては、最初の 40 文字程度しか表示されません。ほどんどのブラウザでは、ユーザー名とパスワードをキャッシュし、それらをプロンプトのテキストと関連付けます。つまり、ユーザーが同じプロンプトが表示されるサーバーの領域 (ファイルやディレクトリ) にアクセスする場合、ユーザー名とパスワードを再入力する必要がありません。逆に、さまざまな領域でユーザーに対して再認証を求めるようにする場合、そのリソースに対する ACL のプロンプトを変更する必要があります。
「認証メソッド」では、クライアントから認証情報を取得するためにサーバーが使用する方法を指定します。管理サーバーで使用できるのは、認証の基本メソッドだけです。サーバーマネージャーは、次の方法を提供します。
- 「デフォルト」では、obj.conf ファイルで指定されているデフォルトメソッドを使用します。obj.conf ファイルに設定されていない場合は「Basic」を使用します。「Default」を選択した場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL の方法を簡単に変更できます。
- 「Basic」では、HTTP メソッドを使用して、クライアントから認証情報を取得します。ユーザー名とパスワードは、サーバーで暗号化が設定されている (SSL が有効) 場合にのみ暗号化されます。それ以外の場合、ユーザー名とパスワードはクリアテキスト形式で送信され、傍受された場合は読み取られる可能性があります。
- 「SSL」では、クライアント証明書を使用してユーザーの認証を行います。このメソッドを使用するには、サーバーの SSL を有効にする必要があります。暗号化が有効になっている場合、基本メソッドと SSL メソッドを組み合わせて使用することができます。
  
  注 –
  セキュリティーを有効にできるのは、逆プロキシモードのときに限られ、順プロキシモードのときは有効にできません。
- 「Digest」では、ユーザー名とパスワードをクリアテキストとして送信することなく、ブラウザでユーザー名とパスワードに基づいて認証を行えるようにする認証メカニズムを使用します。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Proxy Server によって提供される情報の一部を使用するダイジェスト値を作成します。このダイジェスト値は、サーバー側でダイジェスト認証プラグインを使用して計算され、クライアントによって提示されたダイジェスト値と比較されます。
  
  注 –
  ダイジェスト認証では、「Prompt For Authentication」が必須のパラメータです。レルムに一致するように値を変更します (ダイジェストファイルの場合は必須)。たとえば、ダイジェストファイルですべてのユーザーがレルム test 内に存在するように設定した場合、「Prompt For Authentication」フィールドにはテキスト test が含まれるようにします。
- 「Other」では、アクセス制御 API を使用して作成するカスタムのメソッドを使用します。
「Authentication Database」では、サーバーでユーザーの認証に使用するデータベースを指定します。このオプションは、サーバーマネージャーからしか利用できません。「Default」を選択した場合、サーバーはデフォルトとして設定されているディレクトリサービス内のユーザーとグループを検索します。異なるデータベースを使用するように個々の ACL を設定する場合は、「Other」を選択し、データベースを指定します。 server-root/userdb/dbswitch.conf でデフォルト以外のデータベースと LDAP ディレクトリを指定する必要があります。カスタムデータベースにアクセス制御 API を使用する場合は、「Other」を選択し、データベース名を入力します。

「From Host」の指定

どのコンピュータから要求が送られたかに基づいて、管理サーバーへのアクセスを制限できます。

ユーザーインタフェースの「Access Control Rules」ページにある「Users and Groups」には、次の要素が表示されます。

「Anyplace」では、すべてのユーザーとシステムに対してアクセスを許可します。
「Only From」では、特定のホスト名または IP アドレスへのアクセスが制限できます。

「Only From」オプションを選択する場合は、「Host Names」フィールドまたは「IP Addresses」フィールドに、ワイルドカードパターンまたはコンマで区切ったリストを入力します。IP アドレスよりホスト名で制限する方が、より柔軟にできます。ユーザーの IP アドレスが変更された場合でも、このリストを更新する必要がありません。ただし、IP アドレスで制限する方が、より確実です。接続したクライアントの DNS 検索が失敗した場合、ホスト名による制限が使用できないためです。

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

ホスト名の場合、* は名前の構成要素全体を表している必要があります。つまり、*.example.com は許容されますが、 *users.example.com は許容されません。また、ホスト名で * を使用する場合、この記号は文字列の一番左に使用する必要があります。たとえば、*.example.com は許容されますが、users.*.com は許容されません。

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

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

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

異なるユーザーが異なる機能ドメインにアクセスするように設定することもできます。選択したいくつかの機能ドメインへのアクセス権をユーザーに与えると、そのユーザーのログイン後、アクセス権を設定した機能ドメインの管理サーバーページのみがユーザーに表示されます。

ユーザーインタフェースの「Access Control Rules」ページの「Programs」には、次の要素が表示されます。

「All Programs」では、すべてのプログラムへのアクセスを許可または拒否できます。デフォルトでは、管理者はサーバーのすべてのプログラムにアクセスできます。
「Only The Following」では、ユーザーがアクセスできるプログラムを指定できます。
- 「Program Groups」は、「Preferences」や「Global Settings」などの、管理サーバーのタブに反映され、各ページへのアクセスを表します。管理者が管理サーバーにアクセスする場合、サーバーは管理者のユーザー名、ホスト、および IP アドレスを使用して、表示できるページを決定します。
- 「Program Items」では、フィールドにページ名を入力して、プログラム内の特定のページへのアクセスを制御できます。

アクセス権の設定

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

ユーザーインタフェースの「Access Control Rules For」ページの「Rights」には、次の要素が表示されます。

「All Access Rights」はデフォルトで、すべてのアクセス権を許可または拒否します。
「Only The following Rights」では、許可または拒否するアクセス権の組み合わせを選択できます。
- 「Read」は、HTTP メソッドの GET、HEAD、POST、INDEX を含むファイルの表示をユーザーに許可します。
- 「Write」は、HTTP メソッドの PUT、DELETE、MKDIR、RMDIR、MOVE を含むファイルの変更または削除をユーザーに許可します。ファイルを削除するには、書き込み権と削除権の両方が必要です。
- 「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 ファイルについては、第 18 章「ACL ファイルの構文」を参照してください。

アクセス制御の解除

「Access Control Rules」ページのオプション「Access Control Is On」の選択を解除した場合、ACL のレコードの消去について確認するプロンプトが表示されます。「了解」をクリックすると、ACL ファイルから該当するリソースの ACL エントリが削除されます。

ACL を無効にする場合、generated-proxy- serverid.acl の各行の先頭に # 記号を使用することにより、ACL が記述された行をコメントにすることができます。

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

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

Proxy Server は、アクセスが拒否された場合、デフォルトメッセージを表示しますが、必要に応じて応答をカスタマイズできます。また、アクセス制御オブジェクトごとに異なるメッセージを作成することもできます。

管理サーバーの場合、デフォルトではユーザーは server-root/httpacl/admin-denymsg.html ファイルの「Permission Denied」メッセージを受け取ります。

アクセス拒否メッセージを変更するには

「Access Control Rules For」ページの「Response When Denied」リンクをクリックします。

希望する応答を選択し、必要に応じて追加情報を指定し、「Update」をクリックします。ユーザーがリダイレクトされた応答にアクセスできることを確認してください。

「Submit」をクリックして変更内容を保存するか、「Revert」をクリックして、ページ内の要素の値を変更前の値にリセットします。

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

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

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

サーバー全体へのアクセス制限

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

サーバー全体へのアクセスを制限するには

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

ドロップダウンリストからサーバー全体を選択し、「Select」をクリックして、対応する「Edit」ボタンをクリックします。

「Access Control Rules」ページが表示されます。

すべてへのアクセスを拒否する規則を追加します。

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

「From Host」を使用して、制限するホスト名および IP アドレスを指定します。

「Submit」をクリックして変更内容を保存します。

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

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

ディレクトリへのアクセスを制限するには

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

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

ドロップダウンリストから必要なリソースを選択し、「Edit」をクリックします。

すべての場所からのすべてのアクセスを拒否する、デフォルト値を使用した規則を作成します。

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

特定のユーザーに対してすべてのアクセス権を許可する 3 つ目の規則を作成します。

最後の 2 つの規則の「継続」の選択を解除します。

「Submit」をクリックして変更内容を保存します。

ファイルタイプへのアクセス制限

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

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

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

「Select A Resource」セクションで「Regular Expression」をクリックし、正規表現 (たとえば *.cgi) を指定します。

［編集］をクリックします。

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

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

「Submit」をクリックして変更内容を保存します。

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

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

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

指定した時間または指定した日に、サーバーに対する読み取りアクセスと削除アクセスを制限することができます。

時刻に基づきアクセスを制限するには

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

「Select A Resource」セクションのドロップダウンリストからサーバー全体を選択し、「Edit」をクリックします。

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

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

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

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

アクセスを許可する曜日と時刻を入力します。その例を次に示します。
user = "anyone" anddayofweek = "sat,sun" or(timeofday >= 1800 andtimeofday <= 600)

「Submit」をクリックして変更内容を保存します。

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

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

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

セキュリティーに基づきアクセスを制限するには

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

「Select A Resource」セクションのドロップダウンリストからサーバー全体を選択し、「Edit」をクリックします。

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

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

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

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

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

「Submit」をクリックして変更内容を保存します。

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

リソースへのアクセスのセキュリティー保護

この節では、分散管理を有効にした後、Proxy Server でアクセス制御をセキュリティー保護するために必要な追加作業について説明します。

サーバーインスタンスへのアクセスのセキュリティー保護

サーバーインスタンスへのアクセスを制御するように Proxy Server を設定するには、server-root/httpacl/*.proxy-admserv.acl ファイルを編集して、アクセス制御権限を与えるユーザーを指定します。次に例を示します。

acl "proxy-server_instance "; authenticate (user,group) { database = "default"; method = "basic"; }; deny absolute (all) user != "UserA";

IP ベースのアクセス制御の有効化

ip 属性を参照するアクセス制御エントリが、管理サーバーに関連する ACL ファイル (gen*.https-admserv.acl) にある場合は、次の手順 1、2 を実行してください。

ip 属性を参照するアクセス制御エントリが、サーバーインスタンスに関連する ACL ファイルにある場合は、その特定の ACL について次の手順 1 だけを実行してください。

IP ベースのアクセス制御を有効にするには

server-root/httpacl/gen*.proxy-admserv.acl ファイルを次のように編集し、user と group のほかに、ip を認証リストに追加します。

acl "proxy-admserv"; authenticate (user,group,ip) { database = "default"; method = "basic"; };

次のアクセス制御エントリを追加します。

deny absolute (all) ip !="ip_for_which_access_is_allowed ";

次に例を示します。

acl "proxy-admserv"; authenticate (user,group,ip) { database = "default"; method = "basic"; }; deny absolute (all) ip !="205.217.243.119";

ファイルベースの認証用 ACL の作成

Proxy Server は、ファイルベースの認証データベースの使用をサポートしています。このデータベースには、ユーザーとグループに関する情報がテキスト形式でフラットファイルに格納されます。ACL のフレームワークは、ファイル認証データベースを利用できるように設計されています。

注 –

Proxy Server は動的フラットファイルをサポートしていません。フラットファイルデータベースは、サーバーの起動時に読み込まれます。ファイルへの変更は、サーバーを再起動した場合にだけ適用されます。

この節では、ファイル認証とダイジェスト認証に基づくディレクトリサービス用 ACL を作成する方法について説明します。

ACL エントリは、database キーワードを使用してユーザーデータベースを参照できます。次に例を示します。

acl "default";    authenticate (user) {...    database="myfile";...};

server-root/userdb/dbswitch.conf ファイルには、ファイル認証データベースとその設定を定義するエントリが含まれています。次に例を示します。

directory myfiledb filemyfiledb:syntax keyfilemyfiledb:keyfile 
/path/to/config/keyfile

次の表は、ファイル認証データベースでサポートされるパラメータを示しています。

表 8–2 ファイル認証データベースがサポートするパラメータ


パラメータ	説明
`syntax`	(オプション) 値は `keyfile` または `digest` のいずれか。省略した場合のデフォルト値は `keyfile`。
`keyfile`	(`syntax=keyfile` の場合は必須) ユーザーデータを含むファイルへのパス。
`digestfile`	(`syntax=digest` の場合は必須) ダイジェスト認証用のユーザーデータを含むファイルへのパス。

注意 –

ファイル認証データベースファイルに指定可能な最大行数は 255 です。この制限を超えた場合、サーバーは起動に失敗し、エラーがログファイルに記録されます。

ファイルベースの認証データベースを使用して ACL を設定する前に、ファイルベースの認証ディレクトリサービスがすでに設定されていることを確認します。詳細は、「ディレクトリサービスの設定」を参照してください。

ファイル認証に基づくディレクトリサービス用 ACL の作成

ファイル認証に基づいてディレクトリサービス用 ACL を作成するには

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

ドロップダウンリストから ACL ファイルを選択し、「Edit」をクリックします。

「Access Control Rules For」ページで、編集する ACL エントリの「Users/Groups」リンクをクリックします。

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

認証データベースのドロップダウンリストから、鍵ファイルデータベースを指定します。

「Update」をクリックし、「Submit」をクリックして変更内容を保存します。

鍵ファイルベースのファイル認証データベースに対して ACL を設定すると、次のエントリ例のように、dbswitch.conf ファイルが ACL エントリで更新されます。
version 3.0;acl "default";authenticate (user) {prompt = "Sun Java System Proxy Server 4.0";database = "mykeyfile"; method = "basic";};deny (all) user = "anyone"; allow (all) user = "all";

ダイジェスト認証に基づくディレクトリサービス用 ACL の作成

ファイル認証データベースは、RFC 2617 に規定されているダイジェスト認証での使用に適したファイル形式もサポートしています。パスワードとレルムに基づくハッシュが格納されます。クリアテキストのパスワードは保存されません。

ダイジェスト認証に基づいてディレクトリサービス用 ACL を作成するには

サーバーインスタンスのサーバーマネージャーにアクセスします。

「Preferences」タブで、「Administer Access Control」リンクをクリックします。

ドロップダウンリストから ACL ファイルを選択し、「Edit」をクリックします。

「Access Control Rules For」ページで、編集する ACL の「Users/Groups」リンクをクリックします。

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

認証データベースのドロップダウンリストから、ダイジェストデータベースを指定します。

「Update」をクリックし、「Submit」をクリックして変更内容を保存します。

ダイジェスト認証ベースのファイル認証データベースに対して ACL を設定すると、次のエントリ例のように、dbswitch.conf ファイルが ACL エントリで更新されます。
version 3.0;acl "default";authenticate (user) {prompt = "filerealm"; database = "mydigestfile";method = "digest";}; deny (all) user = "anyone"; allow (all) user = "all";

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

アクセス制御とは

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

デフォルト認証

基本認証

SSL 認証

ダイジェスト認証

ダイジェスト認証プラグインのインストール

UNIX でのダイジェスト認証プラグインのインストール

UNIX でダイジェスト認証プラグインをインストールするには

始める前に

Windows でのダイジェスト認証プラグインのインストール

Windows でダイジェスト認証プラグインをインストールするには

DES アルゴリズムを使用するための Sun Java System Directory Server の設定

DES アルゴリズムを使用するように Directory Server を設定するには

その他の認証

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

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

ACL ユーザーキャッシュの設定

クライアント証明書によるアクセス制御

アクセス制御のしくみ

アクセス制御の設定

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

すべてのサーバーにアクセス制御を設定するには

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

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

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

アクションの設定

ユーザーとグループの指定

「From Host」の指定

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

アクセス権の設定

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

アクセス制御の解除

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

アクセス拒否メッセージを変更するには

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

サーバー全体へのアクセス制限

サーバー全体へのアクセスを制限するには

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

ディレクトリへのアクセスを制限するには

ファイルタイプへのアクセス制限

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

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

時刻に基づきアクセスを制限するには

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

セキュリティーに基づきアクセスを制限するには

リソースへのアクセスのセキュリティー保護

サーバーインスタンスへのアクセスのセキュリティー保護

IP ベースのアクセス制御の有効化

IP ベースのアクセス制御を有効にするには

ファイルベースの認証用 ACL の作成

ファイル認証に基づくディレクトリサービス用 ACL の作成

ファイル認証に基づいてディレクトリサービス用 ACL を作成するには

ダイジェスト認証に基づくディレクトリサービス用 ACL の作成

ダイジェスト認証に基づいてディレクトリサービス用 ACL を作成するには

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