[z/OS]

IBM HTTP Server V5.3 for z/OS: 第 4 部: 基本構成

IBM® HTTP Server V5.3 for z/OS® の各種機能は、IBM HTTP Server で使用可能ですが、実装は異なります。2 つの Web サーバーの基本構成の主な違いについて説明します。

部および章は、IBM HTTP Server V5.3 for z/OS の資料「 z/OS HTTP Server 計画、インストールと使用の手引き」(資料番号 SC88-9004-09) の部および章に対応しています。

ファイルの提供方法

IBM HTTP Server は静的ファイルを提供したり、CGI スクリプト・ファイルを実行したりすることができます。これらのファイルは、デフォルトのディレクトリーまたは指定したディレクトリーに置くことができます。各種ディレクティブを使用して、これらのファイルを提供できます。 「Directory」セクションを使用して、ディレクティブをまとめてグループ化したり、特定のディレクトリーに適用するように指定したりします。

デフォルトでは、静的ファイルは、install_root/htdocs ディレクトリーに置かれます。Alias ディレクティブで代替ディレクトリーを指定して、代替ディレクトリーを Web アドレス・プレフィックスにマップできます。 次に、「Directory」セクションを作成またはコピーし、代替ディレクトリーを指すように設定できます。例えば、install_root/htdocs デフォルト・ディレクトリーを指定している Directory ディレクティブをコピーし、デフォルト・ディレクトリーから install_root/static ディレクトリーに変更できます。

デフォルトでは、CGI スクリプトは、install_root/cgi-bin/ ディレクトリーから実行されます。ScriptAlias ディレクティブで代替ディレクトリーを指定して、代替ディレクトリーを Web アドレス・プレフィックスにマップできます。 次に、「Directory」セクションを作成またはコピーし、代替ディレクトリーを指すように設定できます。例えば、install_root/cgi-bin/ デフォルト・ディレクトリーを指定している Directory ディレクティブをコピーし、デフォルト・ディレクトリーから install_root/cgi2 ディレクトリーに変更できます。

ディレクティブについて詳しくは、Apache HTTP Server の資料を参照してください。

ディレクトリー・リストの提供方法

デフォルト httpd.conf ファイルでは DirectoryIndex ディレクティブが index.html に設定されているため、IBM HTTP Server は、ディレクトリー要求に対してディレクトリー・インデックス・ファイル index.html を提供します。DirectoryIndex ディレクティブを別のファイルに設定して、IBM HTTP Server がそのファイルを提供するようにすることができます。また、Indexes 引数を指定した Options ディレクティブを新規または既存の「Directory」セクションに追加して、Web サーバーがそのディレクトリーの情報を返すようにすることもできます。 Indexes 引数の前に + を含めると、「Directory」セクションは、他の Options ディレクティブに設定された引数を継承します。DirectoryIndex ディレクティブと Options ディレクティブのどちらも設定されていない場合は、Web サーバーは 403 エラーを返します。

ディレクティブについて詳しくは、Apache HTTP Server の資料を参照してください。

サーバーの構成方法

EBCDIC 構成ファイルを更新するだけで、IBM HTTP Server を管理できます。

デフォルト IBM HTTP Server 構成ファイルは install_root/conf/httpd.conf です。 出荷時のデフォルトを確認するかまたはそのデフォルトに戻す場合は、install_root/conf/httpd.conf.default ファイルを参照してください。

バックアップするファイル

以下のファイルを定期的にバックアップしてください。
  • 構成ファイル。デフォルトでは、install_root/conf/httpd.conf ファイルです
  • 環境変数ファイル。install_root/bin/envvars ファイルです
  • Secure Sockets Layer (SSL) ファイル。以下のファイルなど。
    • 鍵データベース・ファイル。拡張子は kdb です
    • stash ファイル。拡張子は sth です
    • 要求データベース・ファイル。拡張子は rdb です
    • 証明書取り消しリスト・ファイル。拡張子は crl です
    • 証明書ファイル。拡張子は arm です
  • install_root/bin/htpasswd コマンドなどのコマンドからの出力。アクセス制御に使用できます
  • 手動で編集したグループ・リスト
  • HTTP 要求で提供される任意のコンテンツ。HTML ファイル、イメージ、Java™ スクリプト、カスケーディング・スタイル・シート、CGI スクリプトなど

暗号化サポート

米国政府および米国外の政府は、暗号化に使用される製品を規制しており、鍵サイズを厳格に制限しない限りその輸出を禁止しています。米国政府によるその輸出法の更新や米国外の政府によるその輸入ルールの更新に伴い、サポートされる鍵の長さおよび暗号の仕様は変更されることがあります。

IBM HTTP Server では、SSL 暗号仕様のトピックにリストされている SSL 暗号がサポートされます。

ハードウェア暗号化

ハードウェア暗号化を使用して、クライアントとサーバー間の SSL セッションのパフォーマンスを改善することができます。Web サーバーのパフォーマンスで得られる最大の利点は、断然 SSL ハンドシェークにおいてです。ハンドシェークは非対称の鍵と関数を使用します。Web サーバーは RSA テクノロジーを使用して、非対称機能を実装しています。ハードウェア暗号化なしで SSL を実装した場合、非対称関数は、対称関数よりもはるかに時間がかかります。そのため、Web サーバーでハードウェア暗号化を実装する場合には、非対称マスター鍵を適切にセットアップしてください。 Integrated Cryptographic Services Facility (ICSF) ソフトウェアを使用して、パフォーマンス向上を利用できるようにします。非対称マスター鍵は、Web サーバーの RSA 鍵と同じではありません。

Data Encryption Standard (DES) 暗号仕様および Triple-DES 暗号仕様は対称鍵を使用して、データ伝送を処理します。 データ伝送は、ハードウェアで高速化する場合も、しない場合もあります。データ伝送がハードウェアの方が高速なのか、ソフトウェアの方が高速なのかは、データ・ストリームのサイズによって異なります。SSL は、比較的小さいデータ・ストリームを送信します (通常、4K バイト以下)。小さいデータ・ストリームの場合、ソフトウェアの方が高速である傾向があります。ミッドレンジ・ストリームの場合、ハードウェアの方が高速な場合も、ソフトウェアの方が高速な場合もあります。非常に大きなストリームの場合、ハードウェアの方が高速です。

ハードウェア暗号化を実装する場合は、以下の事項に留意してください。
  • Web サーバーは、SSL ハンドシェークに RSA テクノロジーを使用します。ハンドシェークは非対称機能であり、RSA 公開鍵と秘密鍵のペアを使用します。RSA 鍵はソフトウェアでもハードウェアでも生成できます。
  • RSA 鍵をソフトウェアで生成する場合は、RACF® コマンドまたは gskkyman ユーティリティーを使用します。
  • RACF コマンドを定義して、CSFSERV 一般リソース・クラスのプロファイルに対してユーザー ID および Web サーバー ID を許可します。CSFSERV 一般リソース・クラスは、ICSF ソフトウェアの使用を制御します。

ハードウェア暗号化の実装方法については、該当するマニュアルを参照してください。例えば、IBM サポート・ポータルにある「z/OS Processor Resource/Systems Management Planning Guide」を参照してください。さらに、z/OS Internet Library から入手できる「z/OS Cryptographic Services ICSF Administrator's Guide」および「z/OS Cryptographic Services ICSF System Programmer's Guide」も参照してください。

Web サーバー暗号化でハードウェア暗号化が使用されているかどうかの確認方法

ICSF は、暗号化ハードウェアへのソフトウェア・インターフェースです。以下のチェックリストを使用して、Web サーバーがハードウェア暗号化を使用して動作しているかどうかを判別します。
  • ユーザー ID および Web サーバー ID が ICSF にアクセスできることを確認します。
  • ICSF 開始タスクがアクティブであることを確認します。
  • ICSF TSO パネルから以下のタスクのいずれか、または両方を実行して、ICSF が正常に動作していることを確認します。
    • ICSF で PKA マスター鍵が定義されていることを確認します。
    • PKA マスター鍵を正常に生成します。

セキュア・サーバーをセットアップするためのチェックリスト

Transport Layer Security (TLS) を使用可能にする場合は、conf/httpd.conf.default ファイルの SSL 仮想ホストの例を使用します。例には、Listen ディレクティブ、SSLEnable ディレクティブ、および mod_ibm_ssl モジュールなど、TLS を使用可能にするために必要なエレメントが含まれています。

IBM HTTP Server は CMS SSL 鍵ストア・ファイル (拡張子は kdb) を使用します。gskkyman ユーティリティーまたは RACF RACDCERT コマンドを使用して、 鍵ストア・ファイルを作成および管理できます。
重要: z/OS と分散プラットフォームとでこれらの鍵ストア・ファイルを共有しないでください。

Web サーバーが使用する暗号化レベルのデフォルト順序の変更方法

SSLCipherSpec ディレクティブを使用して、暗号化レベルの順序を制御できます。IBM HTTP Server は常に優先順位の順序を強制します。SSL ディレクティブに関するトピックで SSLCipherSpec ディレクティブについて参照してください。

サーバー・リソースの保護のセットアップ方法

以下のステップは、IBM HTTP Server V5.3 for z/OS の資料「z/OS HTTP Server 計画、インストールと使用の手引き」に記載されています。各ステップに関連付けられた情報は、IBM HTTP Server でそのステップを実行するために必要な情報です。
  • ステップ 1. サーバーで保護をアクティブ化する。

    IBM HTTP Server はリソースへのアクセスを制限する共通モジュールをデフォルトでロードするため、このステップでは、ユーザーが行う操作はありません

  • ステップ 2. サーバーが受け入れる要求を指定する。

    構成セクションを使用して、保護関連の構成ディレクティブを囲みます。Apache HTTP Server の資料の構成セクションを参照してください。

    階層ファイル・システム (HFS) のリソースの場合、<Directory> ディレクティブおよび <DirectoryMatch> ディレクティブを使用して、保護ディレクティブを囲みます。プラグインが提供するリソースなど、HFS 内に存在しないその他のリソースの場合、<Location> ディレクティブおよび <LocationMatch> ディレクティブを使用します。

  • ステップ 3. 使用する保護オプションを決定する。
    IBM HTTP Server には、以下に示す、選択可能なさまざまな保護メカニズムが用意されています。
    • mod_authz_host モジュールを使用したホスト・ベースのアクセス制御。mod_authz_host モジュールは、個別の IP アドレスまたはサブネットを許可または拒否します。
    • さまざまなモジュールの相互運用により、ユーザー ID およびパスワード認証が行われます。これらの機能には、ファイル・データベースおよび LDAP の HTTP 基本認証、HTTP ダイジェスト認証、SSL クライアント証明書認証が含まれます。
    • さまざまなモジュールの相互運用により、許可が提供されます。これらの機能には、グループ、Lightweight Directory Access Protocol (LDAP)、および SSL クライアント証明書が含まれます。
    サーバーは、ホスト・ベースのアクセス制御をまず検査して、要求を処理します。次に、認証およびアクセス制御を検査します。 Satisfy ディレクティブが any に設定されている場合、要求は、ホスト・ベースのアクセス制御か許可のいずれかの要件を満たすだけでかまいません。Require 許可ディレクティブのいずれかに一致すると、アクセスは許可されます。ただし、複数の Require ディレクティブの一致に基づいてアクセスを認可することはできません。
    注意:
    <Limit> ディレクティブおよび <LimitExcept> ディレクティブを使用して、保護メソッドを個別の HTTP 要求メソッドに制限できますが、このアプローチは注意深くテストしてください。
  • ステップ 4. 保護セットアップを作成する。

    ユーザーおよびグループ・パスワード・ファイルに照らして、IBM HTTP Server パスワードを検査できます。ただし、ローカル・システムに照らして IBM HTTP Server パスワードを検査する場合は、AuthBasicProvider SAF ディレクティブを指定します。 オプションとして、SAFRunAs ディレクティブを指定することで、要求を提示する SAF ユーザー ID を変更できます。

    仮想ホスト・ベースで SSL クライアント認証を要求する場合は、SSLCLientAuth required ディレクティブを指定します。SSLClientAuthRequire ディレクティブは、サーバーが保護リソースへのアクセスを許可する前にクライアント証明書に照らして検証する必要がある属性値または属性値のグループを指定する場合に使用します。

    以下の例をガイドとして使用して、保護セットアップを作成します。

    • 以下のように、Order、allow、および deny の各ディレクティブを使用して、リソースへのアクセスを制御します。
      Alias /my-app /opt/my-app/htdocs
      
      <Directory /opt/my-app/htdocs>
         # Allow requests that match the allow directives. Then, deny requests that match the deny directives. 
         # Then, deny requests that do not match the allow or deny directives.
         Order allow,deny
         # Allow access only to those users from the local host.
         Allow from 127.0.0.1
      </Directory>
    • order、allow、および deny の各ディレクティブを使用して、リソースへのアクセスを制御します。さらに、ユーザーがユーザー ID とパスワードを指定してリソースにアクセスできるようにするために、基本認証を使用します。ユーザー ID とパスワードが含まれているファイルを指定します。
      <Directory /opt/my-app/htdocs/members-only>
           Order allow,deny
           Allow from 127.0.0.1
           # Add HTTP basic authentication.
           AuthType Basic
           AuthBasicProvider file
           AuthName "Login with your example.com user ID."
           # Use the htpasswd utility in the <install_root>/bin/htpasswd file to maintain the passwords.
           # Store the userid and password file in a directory other than the one that it is protecting.
           AuthUserFile /opt/my-app/users.passwd
           Require valid-user
        </Directory>
    • ユーザー ID administrator のみがリソースにアクセスできるようにします。
      <Directory /opt/my-app/htdocs/admin>
           ...
           Require user administrator
        </Directory>
    • ユーザー・グループ admins のみがリソースにアクセスできるようにします。ユーザー・グループが含まれているファイルを指定します。
      <Directory /opt/my-app/htdocs/admin>
           ...
           # text file with multiple group-name: member1 member2... lines
           # Store the group file in a directory other than the one that it is protecting.
           AuthzGroupFile /auth/groups
           Require group admins
        </Directory>
    • ローカル・ホストが管理者と同様にリソースにアクセスできるようにします。
        <Directory /opt/my-app/htdocs/admin>
           ...
           Require group admins
           Satisfy any
           Order allow,deny
           Allow from 127.0.0.1
        </Directory>
  • ステップ 5. 個別ファイルへのアクセスを制限する。

    <Directory> ディレクティブまたは <DirectoryMatch> ディレクティブの内側に <Files> ディレクティブまたは <FilesMatch> ディレクティブをネストすることで、ユーザーがアクセスするファイルを制限できます。

ユーザー名、グループ名、およびアドレス・テンプレートの指定のルール

独自の許可用 Apache モジュールを作成しない限り、ユーザー名とアドレスの組み合わせ (bob@192.168.1.1 や steve@192.168.2.2 など) に基づいてアクセスを許可することはできません。

保護セットアップでのグループ・ファイルの使用

IBM HTTP Server のグループ・ファイルは、グループ名からユーザーのリストへのマッピングに過ぎません。ネストした定義を使用したり、アドレス仕様を含めたりすることはできません。

アクセス制御リスト・ファイル

IBM HTTP Server には、アクセス制御リスト・ファイルはありません。リソースへのアクセスを制限するには、.htaccess ファイルを使用できます。ただし、.htaccess ファイルを使用するとサーバーがスローダウンするため、httpd.conf ファイルを更新できる場合は、.htaccess ファイルを使用しないでください。代替手段として、<Directory> ディレクティブにディレクティブを含め、すべてのディレクティブを httpd.conf ファイルに入れます。


トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=ihs-dist&topic=rihs_dgwbconfig
ファイル名:rihs_dgwbconfig.html