Web サーバー上に存在するリソースは、認証、承認、アクセス制御など、いくつかのセキュリティーサービスおよび機構を使って保護できます。この章では、Web Server へのアクセスを制御するためにサポートされているいくつかの機構について説明します。
認証とは、識別情報を確認するためのプロセスのことです。承認とは、ある制限されたリソースへのアクセスをあるアイデンティティーに許可することを意味しますが、それらの制限はアクセス制御機構によって実現されます。認証と承認は、さまざまなセキュリティーモデル (Web アプリケーションセキュリティー、htaccess、認証レルムなど) やサービスを使って実現できます。
管理サーバーにアクセスできるユーザー
それらのユーザーがアクセスできるアプリケーション
Web サイト上のファイルまたはディレクトリにアクセスできるユーザー
アクセス制御は、サーバーの全体、サーバーの一部、Web サイト上のファイルやディレクトリのいずれに対しても行えます。アクセスを許可または拒否するには、アクセス制御エントリ (ACE) と呼ばれる規則の階層を作成します。作成された ACE のコレクションは、アクセス制御リスト (ACL) と呼ばれます。
サーバーにはデフォルトで、複数の ACL を含む ACL ファイルが 1 つあります。サーバーは、受信要求に使用する仮想サーバーを決定したあと、その仮想サーバー用に構成された ACL の有無をチェックします。現在の要求に当てはまる ACL が見つかった場合、サーバーはそれらの ACL の ACE を評価することで、そのアクセスを許可すべきかどうかを決定します。
アクセスの許可または拒否は、次の情報に基づいて行われます。
サーバーは、あるページの要求を受信すると、ACL ファイル内の規則を使ってそのアクセスを許可すべきかどうかを決定します。規則は、要求を送信しているコンピュータのホスト名や IP アドレスを参照できます。また、規則が LDAP ディレクトリに格納されているユーザーやグループを参照するように設定することもできます。
一致する ACL が複数ある場合、サーバーは最後に一致した ACL 文を使用します。uri ACL が最後に一致する文であるため、default ACL は無視されます。
上の図は、Web Server でのアクセス制御の処理手順を示したものです。ユーザーエージェント (クライアント) が Web Server にアクセスします。Web Server が obj.conf ファイル内の PathCheck 指令を実行します。Web Server が HTTP 401 (認証されない) をクライアントに返します。クライアントがユーザーに認証を要求します。クライアントがブラウザの場合、ログインダイアログボックスが表示されます。ユーザーがログイン情報を入力します。Web Server が内部 check-acl 関数を実行します。Web Server がユーザーの資格情報を検証し、要求を処理します。
特定のユーザーまたはグループに対して、Web サーバーへのアクセスを制限することができます。ユーザー - グループのアクセス制御を設定した場合、サーバーにアクセスする前に、ユーザーはユーザー名とパスワードの入力を求められます。サーバーは、クライアント証明書内の情報をディレクトリサーバーのエントリと比較します。
管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、ACL ファイルを手動で編集し、認証方法を SSL に変更する必要があります。
ユーザー - グループ認証は、Web Server がユーザーグループデータベース内のエントリを読み取ることによって実行されます。ディレクトリサービスがアクセス制御の実装に使用する情報は、次のソースのいずれかから入手できます。
内部フラットファイルタイプのデータベース
外部 LDAP データベース
サーバーは、外部 LDAP ベースのディレクトリサービスを使用するとき、サーバーインスタンスに対して次のタイプのユーザーグループ認証方法をサポートします。
デフォルト
基本
SSL
ダイジェスト
その他
サーバーが内部ファイルベースのディレクトリサービスを使用するときに、サーバーインスタンスに対してサポートされるユーザー - グループ認証方法には、次のものがあります。
デフォルト
基本
ダイジェスト
ユーザー - グループ認証では、ユーザーがサーバーにアクセスしたり、Web サイト上のファイルやディレクトリにアクセスしたりするには、まず自身を認証する必要があります。認証を行う場合、ユーザーは、ユーザー名とパスワードを入力したりクライアント証明書を使用したりすることで、自身の身元を確認します。クライアント認証は、SSL 通信でのみ必要です。
デフォルト認証は、推奨される方法です。「標準」設定では、server.xml ファイル内のデフォルトの方法が使用されます。ただし、server.xml に設定が含まれていない場合は「基本」が使用されます。「デフォルト」を選択した場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「標準」を選択すれば、obj.conf ファイル内で 1 行編集することですべての ACL の方法を簡単に変更できます。
基本認証では、ユーザー名とパスワードを入力しないと、Web サーバーまたは Web サイトにアクセスできません。これがデフォルトの設定です。一連のユーザーとグループを作成し、それらを Sun Java System Directory Server などの LDAP データベース内またはファイル内に格納する必要があります。ディレクトリサーバーは、Web サーバーとは異なるサーバールートにインストールされたものか、リモートマシンにインストールされたものを使用する必要があります。
ユーザーが、管理サーバー内や Web サイト上のユーザー - グループ認証が必要なリソースにアクセスしようとすると、ユーザー名とパスワードの入力を求めるダイアログボックスが Web ブラウザによって表示されます。サーバーで暗号化が設定されているかどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。
SSL 暗号化なしで基本認証を使用する場合、暗号化されていないユーザー名とパスワードがネットワークを経由して送信されます。ネットワークパケットは傍受される可能性があり、ユーザー名とパスワードが不正に知られてしまう可能性があります。基本認証は、SSL 暗号化またはホスト - IP 認証、あるいはその両方と組み合わせるのがもっとも効果的です。ダイジェスト認証を使えばこの問題を回避できます。
サーバーは、次の 2 つの方法で、セキュリティー証明書付きのユーザーの識別情報を確認できます。
クライアント証明書の情報を識別情報の証明として使用する
LDAP ディレクトリで発行されたクライアント証明書を確認する (追加)
クライアントの認証で証明書の情報を使用するようにサーバーを設定した場合、サーバーは次の処理を実行します。
まず、証明書が信頼できる CA からのものであるか確認します。そうでない場合、認証は失敗し、トランザクションが終了します。
証明書が信頼できる認証局 (CA) からのものである場合、certmap.conf ファイルを使ってその証明書をユーザーのエントリにマップします。
証明書が正しくマップされている場合は、そのユーザーに対して指定されている ACL 規則を確認します。証明書が正しくマップされている場合でも、ACL 規則によってユーザーのアクセスが拒否される可能性もあります。
特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバーを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書のみを提示する必要があります。SSL の方法を使ってユーザーとグループを認証するようにサーバーのアクセス制御を設定した場合、クライアントで次のことが必要になります。
信頼できる CA から発行された有効な証明書を提供する
証明書は LDAP 内の有効なユーザーにマッピングされている
アクセス制御リストで、適切に評価される
アクセス制御でクライアント認証を要求する場合、Web サーバーの SSL 暗号化方式を有効にする必要があります。
SSL で認証されるリソースにアクセスするには、Web サーバーが信頼している CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Web サーバーの certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバーで発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することができます。
SSL 認証方法の場合にのみ、certmap.conf ファイルを変更する必要があります。なぜなら、この方法では、LDAP ディレクトリに基づいて証明書がチェックされるからです。サーバーへのすべての接続に対してクライアント認証を要求する場合は、その必要はありません。クライアント証明書を使用することを選択する場合、magnus.conf の AcceptTimeout 指令の値を増やすべきです。
サーバーは、LDAP ベースまたはファイルベースのいずれかのディレクトリサービスを使用して、ダイジェスト認証を行うように設定できます。
ダイジェスト認証を使えば、ユーザー名とパスワードを平文として送信することなしに、ユーザー名とパスワードに基づく認証を行えます。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Web Server によって提供される情報の一部を使用するダイジェスト値を作成します。
サーバーが LDAP ベースのディレクトリサービスを使用してダイジェスト認証を行うとき、このダイジェスト値は、ダイジェスト認証プラグインを使用してサーバー側で計算され、クライアントによって提示されたダイジェスト値と比較されます。ダイジェスト値が一致した場合、ユーザーは認証されます。これが機能するには、ディレクトリサーバーが平文形式のユーザーのパスワードにアクセスできる必要があります。Sun Java System Directory Server にはリバーシブルパスワードプラグインが組み込まれています。このプラグインは、対称暗号化アルゴリズムを使用し、暗号化された形式にしてデータを格納し、あとで元の形式に復号化することができます。データへの鍵を持っているのは Directory Server だけです。
LDAP ベースのダイジェスト認証の場合、リバーシブルパスワードプラグインと、サーバーに組み込まれているダイジェスト認証専用のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Web サーバーを構成するには、dbswitch.conf 内のデータベース定義の digestauth プロパティーを設定します。
ACL 方式を指定しない場合、認証が必要であればダイジェスト認証または基本認証のいずれかが使用され、認証が必要ない場合は基本認証が使用されます。これが推奨される方法です。
表 7–1 ダイジェスト認証要求の生成
ACL 方式 |
認証データベースでダイジェスト認証がサポートされている |
認証データベースでダイジェスト認証がサポートされていない |
---|---|---|
「標準」 指定されていない |
ダイジェストと基本 |
基本 |
「基本」 |
基本 |
基本 |
「ダイジェスト」 |
ダイジェスト |
エラー |
method = digest を含む ACL を処理する場合、サーバーは次のようにして認証を試みます。
Authorization 要求ヘッダーをチェックします。見つからない場合は、ダイジェスト要求に対して 401 の応答が生成され、プロセスが停止します。
認証のタイプを確認します。認証のタイプがダイジェストの場合、サーバーは次のことを実行します。
ノンスをチェックします。このサーバーによって生成された、有効で新しい nonce がない場合は、401 の応答が生成されてプロセスが停止します。期限切れの場合は、stale=true で 401 応答が生成され、処理が停止します。
ノンスの有効期間を構成するには、終了タイムアウト magnus.conf ファイル内のパラメータ DigestStaleTimeout の値を変更します。このファイルは server_root/https-server_name /config/ にあります。 この値を設定するには、次の行を magnus.conf に追加します。
ここで seconds は、nonce の有効期限 (秒) です。指定されている秒数が経過すると、nonce の有効期限は切れ、ユーザーからの新しい認証が必要になります。
レルムをチェックします。これが一致しない場合は、401 応答が生成され、処理が停止します。
認証ディレクトリが LDAP ベースの場合は LDAP ディレクトリにユーザーが存在するかどうかを確認します。認証ディレクトリがファイルベースの場合はファイルデータベースにユーザーが存在するかどうかを確認します。見つからない場合は、401 応答が生成され、処理が停止します。
ディレクトリサーバーまたはファイルデータベースから要求ダイジェスト値を取得し、クライアントの要求ダイジェストと一致するかどうかをチェックします。一致しない場合は、401 応答が生成され、処理が停止します。
Authorization-Info ヘッダーを構築し、サーバーヘッダーに挿入します。
管理サーバーまたは Web サイト上のファイルとディレクトリに対して、特定のコンピュータを使用しているクライアントだけが利用できるように、アクセスを制限できます。許可または拒否するコンピュータのホスト名または IP アドレスを指定します。ワイルドカードパターンを使えば、複数のコンピュータやネットワーク全体を指定できます。ホスト - IP 認証経由でのファイルやディレクトリへのアクセスは、ユーザーにはシームレスに感じられます。このため、ユーザーは、ユーザー名やパスワードを入力することなく、すぐにファイルやディレクトリにアクセスできます。
ある特定のコンピュータを複数のユーザーが使用する可能性があるため、ホスト - IP 認証は、ユーザー - グループ認証と組み合わせると、より効果的です。両方の認証方法が使用されている場合、アクセス時にユーザー名とパスワードが必要になります。
ホスト - IP 認証の場合、サーバー上で DNS を構成する必要はありません。ホスト - IP 認証を使用することを選択した場合、ネットワーク内で DNS を稼働させ、その DNS を使用するようにサーバーを構成する必要があります。
DNS を有効にすると、サーバーで DNS 検索が強制的に実行されるため、サーバーのパフォーマンスが低下します。サーバーパフォーマンスへの DNS 検索の影響を減らすには、すべての要求で IP アドレスを解決するのではなく、アクセス制御および CGI でのみ IP アドレスを解決するようにします。それには、obj.conf ファイル内の AddLog fn="flex-log" name="access" に iponly=1 を追加します。
AddLog fn="flex-log" name="access" iponly=1
サーバーはデフォルトで、ユーザーおよびグループ認証の結果を ACL ユーザーキャッシュに書き込みます。ACL ユーザーキャッシュの有効期間を制御するには、magnus.conf ファイル内の ACLCacheLifetime 指令を使用します。キャッシュ内のエントリが参照されるたびにその継続時間が計算され、ACLCacheLifetime に基づいてチェックされます。継続時間が ACLCacheLifetime に等しいかそれより大きい場合、そのエントリは使用されません。デフォルト値は 120 秒です。この値を 0 (ゼロ) に設定すると、キャッシュが無効になります。この値に大きな値を使用する場合、LDAP エントリを変更するたびにサーバーの起動が必要となる可能性があります。たとえば、この値を 120 秒に設定した場合は、サーバーと LDAP ディレクトリの同期が 2 分間にわたって取られない可能性があります。LDAP ディレクトリが頻繁に変更される可能性が低い場合にだけ、大きな値を設定します。
magnus.conf の ACLUserCacheSize パラメータを使用すると、キャッシュ内に保存できるエントリの最大数を設定できます。このパラメータのデフォルト値は 200 です。新しいエントリはリストの先頭に追加されます。キャッシュが最大サイズに達すると、リストの末尾のエントリは新しいエントリを作成するために再利用されます。
また、magnus.conf に含まれるパラメータである ACLGroupCacheSize を使用して、ユーザーエントリごとにキャッシュできるグループメンバーシップの最大数を設定することもできます。このパラメータのデフォルト値は 4 です。残念ながら、グループ内のユーザーの非メンバーシップはキャッシュに書き込まれないため、要求が発生するたびに数回の LDAP ディレクトリアクセスが発生します。
ACL ファイルの指令の詳細については、『NSAPI Developer’s Guide』を参照してください。
CLI 経由で ACL キャッシュのプロパティーを設定するには、次のコマンドを実行します。
wadm> set-acl-cache-prop --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 property=value |
CLI リファレンスの set-acl-cache-prop(1) を参照してください。
設定できる有効なプロパティーは、次のとおりです。
enabled — サーバーがファイルの内容とメタ情報をキャッシュに書き込むかどうかを示します。デフォルト値は true です。
max-age — ファイルの内容とメタ情報をキャッシュ内に保持する最大時間 (秒)。値の範囲は 0.001 から 3600 までです。
max-groups-per-user — サーバーがメンバーシップ情報をキャッシュに書き込む対象となるグループの、1 ユーザーあたりの最大数。値の範囲は 1 から 1024 までです。
max-age — 認証情報をキャッシュ内に保持する最大時間 (秒)。値の範囲は 0.001 から 3600 までです。
サーバーは、ローカルに格納されたアクセス制御リスト (ACL) を使用することで、認証と承認をサポートします。ACL は、あるユーザーがあるリソースに対してどのようなアクセス権限を持つかを記述します。たとえば、ある ACL のエントリを使って、John という名前のユーザーに、特定のフォルダ misc に対する read アクセス権を許可することができます。
この節では、Web サイト上のファイルやディレクトリへのアクセスを制限するための手順について説明します。すべてのサーバーに対してグローバルアクセス制御規則を設定することも、特定のサーバーに対して個別に設定することもできます。たとえば、人事部門であれば、すべての認証済みユーザーが自分の給与データを参照できるが、そのデータを更新する機能へのアクセスは人事部門の給与担当者のみに制限するような ACL を作成できます。
サーバーがサポートするコア ACL では、3 種類の認証が使えます。 基本、SSL、およびダイジェストです。
アクセス制御の設定を編集するには、次のタスクを実行します。
「構成」タブをクリックし、構成を選択します。
「セキュリティー」サブタブ>「アクセス制御」サブタブをクリックします。
「ACL を追加」ボタンをクリックして新しい ACL を追加するか、既存の ACL をクリックして設定を編集します。
次の節では、新しい ACL を構成に追加する手順について説明します。
「構成」タブをクリックし、構成を選択します。
「アクセス制御」サブタブ>「アクセス制御リスト (ACL)」サブタブをクリックします。
「新規」ボタンをクリックして新しい ACL を追加します。
下記のパラメータを設定します。
表 7–2 ACL パラメータ
CLI の使用
CLI 経由で ACL を追加するには、次のコマンドを実行します。
wadm> set-acl --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --vs=config1_vs_1 --config=config1 --aclfile=aclfile1 |
CLI リファレンスの set-acl(1) を参照してください。
この節では、選択された構成に対して新しいアクセス制御エントリ (ACE) を追加するプロセスについて説明します。
「構成」タブをクリックし、構成を選択します。
「アクセス制御」サブタブ>「アクセス制御リスト (ACL)」サブタブをクリックします。
「新規」ボタンをクリックします。
「アクセス制御エントリ (ACE)」の「新規」ボタンをクリックします。
次の ACE パラメータを設定します。
表 7–3 ACE パラメータ
サーバーは、.htaccess 動的構成ファイルをサポートします。.htaccess ファイルを有効にするには、ユーザーインタフェースを使用するか、構成ファイルを手動で変更します。
.htaccess ファイルは、サーバーの標準アクセス制御と組み合わせて使用できます。標準アクセス制御は常に、PathCheck 指令の順序にかかわらず、あらゆる .htaccess アクセス制御の前に適用されます。ユーザー - グループ認証が「基本」の場合、標準アクセス制御と .htaccess アクセス制御の両方を使ってユーザー認証を要求しないでください。サーバーの標準アクセス制御経由で SSL クライアント認証を使用し、さらに .htaccess ファイル経由で HTTP「基本」認証を要求することは可能です。
.htacess ファイルを使用可能にすると、サーバーはリソースを提供する前に、.htaccess ファイルを確認します。サーバーはリソースと同じディレクトリおよびそのディレクトリの親ディレクトリで .htaccess ファイルを検索します。この検索はドキュメントのルートまで続けられます。たとえば「Primary Document Directory」が /sun/server/docs に設定されているときに、クライアントが /sun/server/docs/reports/index.html を要求すると、サーバーは /sun/server/docs/reports/.htaccess および /sun/server/docs/.htaccess を確認します。
サーバーの「Addtional Document Directories」および「CGI Directory」機能で、管理者は代わりのドキュメントルートを定義できます。代わりのドキュメントルートが存在すると、.htaccess ファイルの処理に影響します。たとえば、サーバーの「Primary Document Directory」が /sun/server/docs に設定されていて、CGI プログラムが /sun/server/docs/cgi-bin/program.cgi にあるとします。CGI を「File Type」として有効にした場合、クライアントが CGI プログラムに要求を発行すると、サーバーは /sun/server/docs/.htaccess と /sun/server/docs/cgi-bin/.htaccess の両方の内容を評価します。しかし、「CGI Directory」として /sun/server/docs/cgi-bin を設定すると、サーバーは /sun/server/docs/cgi-bin/.htaccess は検査しますが、/sun/server/docs/.htaccess は検査しません。これは、「CGI Directory」で /sun/server/docs/cgi-bin を指定したことで、代替のドキュメントルートとしてマークされたためです。
サービス拒否 (DoS) 攻撃とは、サーバーの悪意のあるユーザーが故意に、正当なユーザーのサービス利用を妨害しようとすることです。そのような攻撃は、次の操作によって実現されます。
ある特定の Web リソースに対する要求を、サーバーに継続的に送信する
Web Server は、要求の発生頻度が非常に高い場合に、頻繁にアクセスされる URI を監視して要求を拒否することにより、DoS 攻撃を検出できます。
次の各節では、仮想サーバーレベルで DoS 攻撃を防ぐ方法について説明します。
今回、サーバーを調整することでサービス拒否攻撃を防止できるようになりました。具体的には、要求の制限を構成し、仮想サーバーごとの最大接続数を監視します。これらの値のいくつかを構成すると、サーバーのパフォーマンスに影響が及ぶ可能性があります。
サーバーの要求の制限を構成するには、「構成」>「仮想サーバー」>「サーバー設定」>「要求の制限」をクリックします。次の表に記載したパラメータを構成します。
表 7–4 要求の制限の構成
パラメータ |
説明 |
---|---|
要求の制限 |
この仮想サーバーで要求の制限を有効化/無効化します。要求の制限オプションはデフォルトで無効になっています。 |
最大接続数 |
この仮想サーバーで許可する最大同時接続数。 |
最大 RPS |
1 クライアントに許可される 1 秒あたりの最大要求数。 |
RPS 計算間隔 |
秒あたりの平均要求数 (RPS) が計算される時間間隔。デフォルト値は 30 秒です。 |
継続条件 |
ブロックされた要求タイプが再度サービスを受けられるようになるために満たす必要のある条件を決定します。 サイレンス — サービスが再開するには、拒否された要求の数が後続の期間内でゼロまで落ちる必要があります。 しきい値 — サービスが再開するには、拒否された要求の発生頻度が低下して RPS のしきい値を下回る必要があります。 デフォルト値は「しきい値」です。 |
エラーコード |
ブロックされた要求に使用する HTTP 状態コード。デフォルトのコードは、HTTP 503 (サービス利用不可) です。 |
属性の監視 |
省略可能な監視対象の要求属性。 |
CLI の使用
CLI 経由でサーバーへの要求を制限するには、次のコマンドを実行します。
wadm> enable-request-limits --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --vs=config1_vs_1 |
CLI リファレンスの enable-request-limits(1) を参照してください。
最大同時接続数を制限できます。処理中の要求が少なくとも指定された数だけ存在している状態で、一致する要求が受信されると、その要求は拒否されます。要求が拒否されるのはその特定の期間内だけである点に注意してください。同時要求数が低下してこの制限を下回るようになると、新しい要求が処理されます。