ソフトウェア > Lotus > Lotus Developer Domain >

Iris Today Archives

ドミノ Rnext で Web アプリケーションを作る：ファイルのアクセスと保護

by John Chamberlain
レベル：ビギナー
対象：Domino Rnext
原文の掲載：2002年1月2日

Iris Today Archivesの原文（英語）

インデックス

	Web サイト・ルールの簡単な概説
	組み込み済みディレクトリー・ルール
	ディレクトリー・ルールの作成
	ファイル保護文書の設定
	組み立て
	ファイル保護文書の安全性

ご注意：

この記事は、ノーツ Rnext ベータ・プログラムで計画・開発されている機能を紹介します。したがって、最終的な機能や UI と、記事中に紹介されるものは異なる可能性があります

以前の Iris Today の記事、ドミノ Rnext で Web アプリケーションを作る：Web サイト・ルールでは、Web サイト・ルール文書（Web Site Rule document）について紹介しました。この文書は、ドミノ・ディレクトリーの新しいサーバー/インターネット・サイトで有効となる文書タイプです。[Redirection（リダイレクト）]、[Substitution（置換）] のルールを作成する際の文書の使用方法についても紹介しました。

この記事では、Web サイト・ルールのもうひとつ別のタイプ、すなわちディレクトリー・ルールについて紹介します。Web アプリケーションに、HTML ファイル、イメージ・ファイル、ファイル・システム・リソースといった多くのファイルが含まれている場合、これらのリソースを整理するのにディレクトリー・ルールを使用することができます。ディレクトリー・ルールでは、サーバーがどこに置かれていても、別のマシンであっても、Web アプリケーションで、これらのサーバーやマシン上のディレクトリーにアクセスできます。

またこの記事では、ファイル保護文書（file-protection documents）があるファイル・ディレクトリーへのアクセス制御方法についても紹介します。これは、新しいインターネット・サイト・ビューへ引き継がれる R5 機能です。R5 では、ファイル保護文書は全サーバーで適用できます。しかし、Rnext では、全ての Web サイト自体で、ファイル保護スキーマーを持つようになります。ですが、ファイル保護文書については、ドミノ・データベース・セキュリティー・モデルと同等のセキュリティー・レベルを提供できません。提供できない理由と、各セキュリティー・スキーマーについて説明します。

ドミノ Rnext を使って Web サイトを立ち上げようとしている全てのシステム管理者や、Web マスターの方々にとって、この記事は役に立つ内容になっています。この記事は、ドミノ・ディレクトリーと管理作業に慣れている方を想定しています。先に紹介した記事の他に、Iris Today の記事、ドミノ Rnext で Web アプリケーションを作る：Web サイト・アドレッシングのチュートリアルも参考になります。この記事では、ドミノ Rnext の Web サイトの基本設定について説明しています。

Web サイト・ルールの簡単な概説

前回の記事では、Web サイト・ルール文書の基本を全て紹介しました。簡単に概説しますと、Web サイト・ルールとは、ドミノ・ディレクトリーの [Server] - [Internet Sites] ビューで定義した Web サイトへの返答文書のことです。サイト用の Web サイト・ルールを作成するには、Web サイト文書を開き、[Web Site（Web サイト）] アクション・ボタンをクリックし、[Create Rule（ルールの作成）] を選択します。すると、新しい Web サイト・ルール文書が開かれます。

Web Site Rule document

[Description（説明）] フィールドには、ルールの説明や識別用の任意のテキストを入力できます。

[Type of rule（ルールのタイプ）] フィールドのデフォルト値は、この記事を説明するために、Directory（ディレクトリー）になっています。

[Incoming URL pattern] フィールドには、ブラウザーから送られる URL を照合するため、テンプレート、もしくはパターンを指定できます。このパターンには、ワイルド・カード文字として、1つあるいは複数のアスタリスク（*）を使うことができます。例えば、/*/catalog/*.htm というパターンは、/petstore/catalog/food.htm や /clothing/catalog/thumbnails.htm といったパターンとマッチします。
Substitution（置換）ルールのパターンのように、ディレクトリー・ルールのパターンでは、少なくとも1つのワイルド・カードを含む必要があります。パターンに1つのワイルド・カードが含まれていない場合、Rnext では、内部的に /* が追加されるようになります。例えば、/shop というパターンを指定すると、このパターンは、Rnext では /shop/* として処理されます。

Rnext では、Web サイト・ルール文書の残りのフィールドは、パターンにマッチする URL の処理方法を指定するのに使用します。前回の記事で説明した [Redirection（リダイレクト）] と [Substitution（置換）] ルールにより、Rnext では、要求が処理される前に受信 URL が別の URL に変形されます。[Directory（ディレクトリー）] ルールは、全く別の用途に使われます。1つのディレクトリー・ルールは、1つの URL パターンに1つのファイルを割り当てます。Web サーバーが、パターンにマッチする URL を受信すると、サーバーは、URL がディレクトリーのリソースを要求していると見なします。

上に戻る

組み込み済みディレクトリー・ルール

ディレクトリー・ルールの詳細を紹介する前に、既に組み込まれているいくつかの機能を見ていきましょう。Rnext Web サーバーをインストールすると、たくさんのファイル・リソースを持つディレクトリーが、自動的に作成されます。これらのデフォルト・ディレクトリーには、Web サイト文書の [Configuration（設定）] タブで定義されたあるルールに従って、直接リソースが割り当てられています。

Default directory rules

次のような3つディレクトリーがあります。

HTML ページのような画像でないファイルのためのディレクトリーは、[HTML directory（HTML ディレクトリー）] フィールドで指定します。
GIF のような画像イメージ・ファイルのためのディレクトリーは、[Icon directory（アイコン・ディレクトリー）] フィールドで指定します。
CGI プログラムのためのディレクトリーは、[CGI directory（CGI ディレクトリー）] フィールドで指定します。

Web サーバーが起動されると、これらのディレクトリーに URL パターンを割り付ける内部ルールが自動的に作成されます。サイト管理者の場合、このルールより優先して制御を行えますが、完全にこれらを無効にすることはできません。

画像でないファイルのデフォルト・ディレクトリーは、 C:\Lotus\Domino\Data\domino\html といったように data ディレクトリーの下に作成されます（この記事の中では、特にことわらない限り、一貫して Windows マシンへの Rnext サーバーのデフォルト・インストールを前提として説明しています）。Web サイト文書の [HTML directory（HTML ディレクトリー）] フィールドのデフォルト値は、このディレクトリーを指すことになります（実際は data ディレクトリーからの相対パス domino/html を指定しています）。任意にこのフィールドを変更して、別のディレクトリーを指定できます。しかし、このディレクトリーに割り当てられた、/* にハードコード化された URL パターンを変更することはできません。このルールによって、全 URL の代替処理が行われるので、この URL パターンはハードコード化されています。すなわち、URL をどのようにしても解析できなかったとき、このディレクトリーの読み出し可能なファイルを1つ指定するようになっています。例えば、/welcome.html という URL は、C:\Lotus\Domino\Data\domino\html\welcome.html というファイルを指定しています。そして、/product/specs/widget.htm という URL は、 C:\Lotus\Domino\Data\domino\html\product\specs\widget.htm を指定しています。

Web サイト文書の [Icon directory（アイコン・ディレクトリー）] フィールドでは、（GIF ファイルのような）画像ファイル用のデフォルト・ディレクトリーを指定します。画像ファイルは、C:\Lotus\Domino\Data\domino\icons に作成されます。この URL パターンは、[Icon URL path（アイコン URL パス）] フィールドで定義します。デフォルト・パターンは、/icons です。ここでは、ディレクトリーも URL パターンのどちらも変更しないよう強くお勧めします。というのは、ナビゲーション・アイコンや、ビュー・コラム・アイコンや、その他ドミノ・データベース返答で使われるイメージといった GIF ファイルの標準セットと共に、このディレクトリーが、あらかじめロードされているからです。

Web サイト文書の [CGI directory（CGI ディレクトリー）] フィールドでは、CGI プログラム用のデフォルト・ディレクトリーを指定します。プログラムは、C:\Lotus\Domino\Data\domino\cgi-bin に作成されます。この URL パターンは、[CGI URL path（CGI URL パス）] フィールドで定義します。デフォルト・パターンは、/cgi-bin です。必要に応じて、ディレクトリーとパターンを変更できます。

Web サイトにおいて、この3つのディレクトリーで十分な場合、これに関する設定は完了です。そうでない場合、個々のディレクトリーに対応するルールを作成して、必要に応じた数のディレクトリーを追加できます。

上に戻る

ディレクトリー・ルールの作成

ディレクトリー・ルールは、2つのタイプのリソースのロケーションを割り当てるためだけに使うことができるということを理解してください。2つのタイプとは、（HTML ファイルと画像ファイルのような）直接読み込めるファイルと、ロードされてオペレーティング・システムによって起動される実行プログラム（CGI プログラム）のことです。ディレクトリー・ルールは、ドミノ・データベースやサーブレットのような、この他のタイプのリソースのロケーションを割り当てるのに使うことはできません。これらのリソース自体の中に、ロケーションを指定するルールがあります。

ディレクトリー・ルールを作成するには、まず、（上述したように）新しい Web サイト・ルール文書を作成します。そして、[Description（説明）] フィールドに説明を入力し、[Type of rule（ルールのタイプ）] フィールドに、Directory（ディレクトリー）が設定されていることを確認します。[Incoming URL pattern（受信 URL パターン）] フィールドに、テンプレートあるいはパターンを設定します。対象ディレクトリーと対応させるため、このフィールドの設定は、ブラウザーから送られる URL にマッチするよう設定します。

[Target server Directory（対象サーバー・ディレクトリー）] フィールドの設定
[Target server directory（対象サーバー・ディレクトリー）] フィールドに、割り当てられたファイル・ディレクトリー・パスを設定します。相対パスあるいはフルパスを指定します。UNIX でのスラッシュの使用も、Windows でのバックスラッシュ（\ マーク）の使用も心配いりません。両方の区切り文字が、全てのプラットフォームで有効です。

相対パスは、ドライブ名とスラッシュで始めることはできません。相対パスはつねに、Domino\data ディレクトリーからの相対パスとして処理されています。例えば、C:\Lotus\Domino\Data\Websites\pages は、Website\pages として設定します。

Domino\data ディレクトリーの下のディレクトリーに割り当てたくない場合には、フルパスを指定します。ディレクトリーは、サーバーへアクセスできるファイル・システムに置くことができます。経験的に、オペレーティング・システムのコマンド・プロンプトで表示できるディレクトリーの場合、そのディレクトリーは、Rnext でアクセスできます。ディレクトリー・ルールは、Windows UNC パスもサポートしています（例えば、\\server-2\pages です）。しかし、サーバー・マシンに、すでに正しいアクセス・レベルで割り当てられた UNC 共有がある時には、Rnext Web サーバーは、既存の UNC マップを使用しているので、新しいものを使用し始めることはできません。

[Access level（アクセス・レベル）] フィールドの設定
Web サイト・ルール文書の最後のフィールドは、[Access level（アクセス・レベル）] フィールドです。次のような2つの選択肢があります。

Read access（読み込みアクセス）とは、ディレクトリーからファイルを読み込むことを、ブラウザーのユーザーに許可することです。ユーザーが、ディレクトリーのファイルを要求した場合、Rnext では、ブラウザーへファイルの内容を送り返します。Read access（読み込みアクセス）は、HTML ファイル、画像イメージ・ファイル、ダウンロード・ファイルやその他のファイルがあるディレクトリー用のものです。
Execute access（実行アクセス）とは、ディレクトリーの CGI プログラムをロードして起動することを、ブラウザーのユーザーに許可することです。Rnext が、出力を CGI プログラムからブラウザーへ中継することになります。Execute access（実行アクセス）は、CGI ディレクトリー専用のものです。

正しいアクセスを選択することは大変重要なことです。CGI プログラムがあるディレクトリーだけが、Execute access（実行アクセス）のマークをつけることができます。その他全てのディレクトリーは、Read access（読み込みアクセス）になります。もし、誤ったアクセス・レベルを指定すると、予期せぬ結果が起こることになります。間違って CGI ディレクトリーに対し Read access（読み込みアクセス）のマークを付けた場合、ブラウザーのユーザーが CGI プログラムの URL を送信すると、Rnext はそれを実行するのではなく、プログラムのソース・コードを送り返します。これは、重大なセキュリティー違反となります。

アクセス・レベルは、指定したディレクトリー配下の全サブディレクトリーにも引き継がれるということを覚えておいてください。例えば、ある CGI ディレクトリーに対し Execute access（実行アクセス）を指定すると、ルールでは、このディレクトリー配下の全サブディレクトリーにも Execute access（実行アクセス）を適用します。

また、同じディレクトリーに CGI プログラムと一般のファイルを混ぜて置くといった扱いにくいことはしないでください。ディレクトリー・ルールにより、URL パスを割り当てるので、1つのディレクトリーに全ファイルを置き、異なる URL パスを指定した2つのルールを作成したとします。ルールの1つは、Read access（読み込みアクセス）にし、もうひとつは、Execute access（実行アクセス）にします。例えば、/read-dir と /cgi-dir といったようにパスを指定します。これには、大きな落とし穴があります。悪意のあるユーザーが、CGI プログラムのソース・コード（http://dominoinc.com/cgi-dir/account.pl）をダウンロードしようとする場合、このユーザーが行うことは、URL を http://dominoinc/read-dir/account.pl に置き換えることだけです。

ディレクトリー・ルールでは、オペレーティング・システムから与えられるファイル・アクセスの権限を変更できないということを覚えておいてください。Rnext サーバー自体が、管理者が指定したユーザー・アカウントの下で起動され、その指定されたユーザー・アカウントに応じて、ファイルとディレクトリーへアクセスするようになっています。したがって、Web サーバーがアクセスする全ファイルへのアクセスは、Rnext アカウントのアクセス・レベルを正確に設定する必要があります。つまり、CGI プログラムには Execute access（実行アクセス）を、CGI プログラム以外の全ファイルには Read access（読み込みアクセス）を指定します。

例：別なボリューム・ファイルへのアクセス
数千もの HTML ファイルと JPEG イメージがある製品カタログを持つ Web サイトを設定するとします。Web サーバー・マシン上のこの教材カタログ全てを保持するよりむしろ、ふつうは、大きなファイル・サーバーにこれを置いておくほうを選ぶでしょう。ファイル・サーバーのディスク・サブ・システムは、ドライブ「F」として、Web サーバー・マシン上に割り当てられます。2つのディレクトリー・ルールを設定すれば、ディスク上のディレクトリーにアクセスできます。HTML ファイル用のディレクトリー・ルールの設定を下記に紹介します。

Description:	HTML pages on file server（ファイル・サーバーの HTML ページ）
Type of rule:	Directory
Incoming URL pattern:	/catalog/pages
Target server directory:	f:\web-storage\html
Access level:	Read

例 2:data ディレクトリーの外にあるディレクトリーの有効化と保護
おそらく Web 設計者は、ツリー構成のディレクトリーにある多くの HTML ページを管理しています。Web アプリケーションのこのツリー構成のディレクトリーの1つにアクセスしなければならないとします。目的のディレクトリーが、Domino\data ディレクトリーの階層構造の外にあるので、下記のようなディレクトリー・ルールを作成することになります。

Description:	HTML pages on file server（ファイル・サーバーの HTML ページ）
Type of rule:	Directory
Incoming URL pattern:	/catalog/pages
Target server directory:	f:\web-storage\html
Access level:	Read

イメージ用の設定は次のようになります。

Description:	Images and graphics on file server （ファイル・サーバーのイメージと画像）
Type of rule:	Directory
Incoming URL pattern:	/pic
Target server directory:	f:\web-storage\images
Access level:	Read

これらのルールにより、ユーザーの要求する URL は次のようになります。

http://dominoinc.com/shop/catalog/pages/trucks.htm

その結果、Rnext は、ファイル f:\web-storage\html\trucks.htm を返します。trucks.htm に /pic/axle.jpg へのイメージ・リンクがある場合、Rnext は、 f:\web-storage\images\axle.jpg を返すことになります。

ファイル保護文書の設定の記事の後、さらにディレクトリー・ルールのいくつかの例を紹介します。

上に戻る

ファイル保護文書の設定

ファイル保護文書は、アクセス制御リスト（ACL）とディレクトリーあるいはファイルを関連づけています。ブラウザーのユーザーが、ファイルを読み込むか実行しようとする URL を送信するときはいつでも、そのファイルへのパスは、ファイル保護文書で照合されます。一致した時には、ブラウザーのユーザーの証明書が、ACL で確認されます。ユーザーが、ACL に無い場合、アクセスは拒否され、サーバーは、401 エラー（Unauthorized（権限無し））を返します。

ファイル保護文書は、ディレクトリー・ルールが割り当てられた HTTP 要求にだけ適用されます。ルールには、上述した Web サイト文書の組み込み済みディレクトリー・ルールと、管理者が定義した追加のディレクトリー・ルールの両方のルールが含まれています。ファイル保護文書は、ドミノ・データベース要求（データベース・ファイル名かまたはレプリカ ID で始まる要求）には適用されません。データベース ACL、つまり文書の [Author（作成者）] フィールドと [Reader（読者）] フィールドなどのデータベースから派生したメカニズムに従って、データベース要求のアクセス制御は完全に処理されています。

1つだけわずかな制限があります。デフォルトのアイコン・ディレクトリーにファイル保護を適用できないとうことです。アイコン・ディレクトリーには、つねにアクセスする必要があるイメージ・ファイルが存在するので、Rnext はアイコン・ディレクトリーを指定しているファイル保護文書を無視します。

ファイル保護文書を作成するには、Web サイト文書を開き、[Web Site（Web サイト）] アクション・ボタンをクリックし、[Create File Protection（ファイル保護の作成）] を選択します。すると、新しい Web サイト・ファイル保護文書が開かれます。

Web Site File Protection document

[Description（説明）] フィールドには、文書を説明する任意のテキストを入力できます。

[Directory or file path（ディレクトリーあるいはファイル・パス）] フィールドには、保護しようとするパスを入力します。パスの設定は、上述したディレクトリー・ルールの Web サイト・ルール文書にある [Target server Directory（対象サーバー・ディレクトリー）] フィールドの設定と同じ規則です。つまりパスは、フルパスか、data ディレクトリーからの相対パスか、Windows UNC パスのいずれかにしなければなりません。

ファイル保護文書では、ディレクトリーを URL へ割り当てていないということにも十分注意してください。サーバーのデフォルト・ディレクトリーの下にないディレクトリーを使用したい場合、ディレクトリーを URL パスへ割り当てるために、まずディレクトリー・ルールを作成する必要があります。そして次に、そのディレクトリーを保護するためにファイル保護文書を作成します。

ディレクトリーに定義した保護は、そのサブディレクトリー全てに引き継がれます。複数のファイル保護文書が1つの要求されたパスにマッチしているときには、最も限定した保護が優先されます。例えば、ユーザーが、c:\website\pages\welcome.htm ファイルを要求し、2つのファイル保護文書（1つは c:\website で、もう1つは c:\website\pages が設定されている）があった場合、c:\website\pages が使用されます。したがって、ユーザーは c:\website へのアクセスは拒否されますが、　c:\website\pages へのアクセスは許可され、要求は受け入れられることになります。管理者にとってやっかいなことになるので、このような保護の重複設定は避けるべきです。

ファイル保護文書は、特定のファイルも指定できます。例えば、HTML ページ用の c:\website\pages ディレクトリーがあり、その中の特定の salaries.htm ページだけを保護する必要がある場合、ファイル保護文書に c:\website\pages\salaries.htm というファイル・パスを指定できます。ワイルド・カード文字はサポートされていません。ですから、この方法で保護したいファイル毎に、異なるファイル保護文書を作成する必要があります。しかし、同じディレクトリーに保護するオブジェクトと、保護しないオブジェクトを混在させることは、非常に管理エラーを起こしやすく危険なことです。（ファイルを個々に保護することは、絶対に避けたほうが良いでしょう。代わりに、保護するオブジェクトを保護しようとするディレクトリーに移して、そのディレクトリー全体を保護することをお勧めします。）

アクセス制御リスト・フィールドを更新するには、[Set/Modify Access Control List（アクセス制御リストの設定/更新）] ボタンをクリックします。すると次のようなダイアログ・ボックスが表示されます。

ACL dialog box

ダイアログ・ボックスの先頭に、この ACL の名前のリストがあります。直接ダイアログ・ボックスを編集することはできません。代わりに、[Name（名前）] フィールドに名前を入力して、適切なアクセス・レベルを選択して（前章で紹介した内容です）、[Add（追加）] ボタンをクリックします。[Name] フィールドには、フィールドの右側にドロップダウン・ボタンもあります。このボタンをクリックすると、代表的な名前が表示されたダイアログ・ボックスが展開されます。このダイアログ・ボックスから個人のアドレス帳のエントリーを選択できます。

ACL エントリーは、一般のドミノ ACL ルールに従っています。1つのエントリーには、名前、グループ、あるいは特別な識別子の -Default- （デフォルト）を用いることができます。-Default- は、どんなエントリーにも一致しない全ユーザーと、Anonymous（匿名）に適用できます。Anonymous は、ユーザー証明書がまったくない要求を行うときに使われます。名前のエントリーは、（Joe Smith/dominoinc というように）階層化されています。ファイル保護 ACL とその他の ACL では、重要な違いが1つあります。それは、ファイル保護 ACL ではワイルド・カード文字がサポートされていないということです。例えば、ドミノ株式会社という組織の全ユーザーにマッチさせるために、*/dominoinc を使うことはできません。

全ての ACL エントリーに対してアクセス・レベルを割り当てる必要があります。保護されているディレクトリーにアクセス要求した場合、アクセス・レベルが、どの HTTP 方式が許可されるているのかを示しています。3つのアクセス・レベルが下記にあります。

Read/Execute access（読み込み/実行　アクセス）は、GET メソッドと HEAD メソッドを使用している要求だけを許可します。（HEAD メソッドは、GET メソッド用な処理を行いますが、返答のヘッダーだけをサーバーに送り返し、返答の本文は送り返しません。）要求により、（例えば、http://dominoinc.com/welcome.htm のような）ファイル読み込みか、または、（http://dominoinc.com/cgi-bin/search.pl?product=widget のような）CGI プログラムの実行が行えます。保護されたパスが、ディレクトリー・ルールで指定された場合、ディレクトリー・ルールはそれ以降の要求を制限するということに注意してください。例えば、ディレクトリー・ルールで、Read access（読み込みアクセス）が指定された場合、たとえファイル保護文書に Read/Execute access（読み込み/実行　アクセス）が指定されていても、ユーザーはディレクトリーから CGI プログラムを実行できません。
Write/Read/Execute access（書き込み/読み込み/実行　アクセス）は、GET メソッドと HEAD メソッドに加えて、POST メソッドを使用している要求だけを許可します。Rnext Web サーバーは、直接的なファイル・システムへのファイルのアップロードをサポートしていません（データベースへのファイルのアップロードはサポートしています）。ですから、ファイル・システム要求で POST メソッドを共通して利用するときだけ、CGI プログラムへ（フォームのような）データを送ることができます。
No Access（アクセス無効）は文字通り、保護されているディレクトリーのファイルの要求は、401 エラー（Unauthorized（権限無し））により拒否されます。
新しいファイル保護文書を作成したとき、デフォルト ACL には、No Access 用の -Default- エントリー・セットがあります。言い換えれば、どんな要求を行っても、ディレクトリーにアクセスできないということです。最も効果的なセキュリティーにするには、リストの -Default- エントリーをそのままに保持し、アクセスを許可するユーザーに対してのみ指定したエントリーを追加することです。（リストからエントリーを削除するには、削除するエントリーをハイライト表示させ、[Clear（クリア）] ボタンをクリックしてください。）

CGI プログラムを保護しようとする場合、Rnext が、CGI プログラム・ファイルそのものにファイル保護を適用していることを覚えておいてください。CGI プログラムが起動されているときに、CGI プログラムが他のファイルにアクセスするときには、Rnext は介在せず、これらのファイルのファイル保護を確認できません。

上に戻る

組み立て

ディレクトリーのアクセスと保護の例をいくつか見て、設計に慣れていきましょう。

例 1:デフォルト CGI ディレクトリーの保護
これまで紹介したように Web サーバーはつねに、デフォルト CGI ディレクトリーに対して内部ルールを適用しています。ですから、ディレクトリー・ルールを作成する必要はありません。しかし、ファイル保護文書を作成すると、さらに、このディレクトリーにあるプログラムへのアクセスを制限することができます。CGI ディレクトリーは、Domino\data ディレクトリーの下に置かれるので、ファイル保護文書に相対パスを使うことができます。CGI プログラムのいくつかがフォームの処理を行う場合、POST アクセスを許可しておく必要があります。デフォルト CGI ディレクトリー用のファイル保護文書の設定例を下記に示します。RegisteredUsers グループへのアクセスを制限している例です。

Description:	Only registered users can run CGI programs （登録ユーザーだけが、CGI プログラムを起動できます。）
Directory or file path:	domino\cgi-bin
Access control list:	-Default- -(No Access) RegisteredUsers -(POST and GET)

Description:	HTML pages for shopping catalog（ショッピング・カタログの HTML ページ）
Type of rule:	Directory
Incoming URL pattern:	/catalog
Target server directory:	c:\external\website\catpages
Access level:	Read

さらに、Web ユーザーの2つのグループにだけ、このディレクトリーへのアクセスを許可したいとします。2つのグループとは、登録された外部ユーザーと、（階層 ID がある）Web サイト管理者です。したがって、下記のような設定を持つファイル保護文書作成することになります。

Description:	Shopping catalog pages（ショッピング・カタログ・ページ）
Directory or file path:	c:\external\website\catpages
Access control list:	-Default- -(No Access) RegisteredUsers -(GET) jsmith/admin/dominoinc -(GET) rjohnson/admin/dominoinc -(GET)

これらの文書を決まったところに置けば、認証済みユーザーが次のような要求を送ることで、カタログ・ページにアクセスできます。

http://dominoinc.com/catalog/books.htm

そして、それは c:\external\website\catpages\books.htm へ割り当てられます。

例 3:Windows UNC パス
サーバー・マシンが、追加 CGI プログラムがある UNC 共有を割り当てているとします。ブラウザー・ユーザーがこのディレクトリーにアクセスできるようにするために、ディレクトリー・ルールによりディレクトリーを割り当てる必要があります。

Description:	CGI directory on UNC share（UNC 共有にある CGI ディレクトリー）
Type of rule:	Directory
Incoming URL pattern:	/scripts
Target server directory:	\\bighost\drive-c\web\cgi
Access level:	Execute

全ての認証済みユーザーが、これらの CGI プログラムを実行できるようにしたいときには、下記のようなファイル保護文書を作成します。ここではおそらく共通して、No Access とは違うものに対して -Default- をセットすることになります。

Description:	Protection for UNC share（UNC 共有の保護）
Directory or file path:	\\bighost\drive-c\web\cgi
Access control list:	-Default- -(GET) Anonymous -(No Access)

これで、認証済みユーザーは、次のような要求を送ることで、CGI プログラムを実行できます。

http://dominoinc.com/scripts/buy.pl

そして、\\bighost\drive-c\web\cgi\buy.pl がこれに割り当てられます。

上に戻る

ファイル保護文書の安全性

ファイル保護文書を使用する際に、ファイル保護 ACL が、データベース ACL ほど安全ではないということを理解しておくことが非常に重要です。というのは、ドミノ・データベースのセキュリティー・モデルでは、アクセス制御が、データベース・オブジェクト自体のプロパティーになっているからです。しかし、ファイル保護文書では、アクセス制御とリソースへのパスが関連付けられていますが、リソース自体には関連付けられていません。ドミノでなくオペレーティング・システムがリソースを所有しているので、ドミノでは直接ファイル・システム・リソースにアクセス制御を置くことはできません。前述したように、これと同様の理由で、ディレクトリー・ルールを、オペレーティング・システムのファイル・アクセス許可より優先することはできません。

ドミノ・データベースのオブジェクトへのアクセスは、完全にドミノによって制御されています。オペレーティング・システムが関与しない限り、ドミノ・データベースは単なるファイルにすぎません。しかし、実際のところ、データベース・ファイルが、さまざまなオブジェクトのかなり複雑なコンテナであるということを、ドミノは認識しています。ドミノだけが、データベース・ファイルの内容の解析の仕方を把握しています。したがってドミノが、データベース・オブジェクトへのアクセスと、データベース・オブジェクトへのパスも完全に制御しています。例えばある特別な文書に、GoodGuy と呼ばれるグループのアクセスだけを許可している Reader（読者）リストがあるとします。ドミノ URL 文法では、名前と UNID によってオブジェクトへのアクセスを許可しています。ですから、ドミノ URL 文法では、下記のこれらのいずれの URL からも、この文書を要求することができるようにしています（文法は、全ての可能性を排除してはいません）。

http://dominoinc.com/products.nsf
/byname/widget?opendocument
http://dominoinc.com/products.nsf
/b86a878b9ae5ee0d85256ad8000813a6?opendocument
http://dominoinc.com/products.nsf
/8a6d147cf55a7fd385256658007aacf1/widget?opendocument
http://dominoinc.com/8fa345bc02abd5f7/0
/b86a878b9ae5ee0d85256ad8000813a6?opendocument

GoodGuy グループに属していない Joe BadGuy という人が、この文書を読み込みたいとします。この人は、まず上記の URL の全てを試してみます。これは成功するでしょうか。いいえ成功しません。ドミノが、URL を解析しているので、サーバーはこれらの URL 全てが同じ文書を指していることを認識しています。そして、Reader（読者）リストは、文書のプロパティーそのものなので、Joe BadGuy の要求は拒否されます。

状況は、Web サイト・ファイル保護を適用することでかなり違ったものになります。ドミノは、ファイルとディレクトリーを所有していません。オペレーティング・システムが所有しています。ですから、ドミノが、ファイル・システム・オブジェクトに、直接アクセス制御を置くことはできません。ドミノが実行できる処理の全ては、ファイル・システム・オブジェクトへのパスを制御することです。

例えば、URL パス /shop/* を　c:\website\shopping ディレクトリーへ割り当てたディレクトリー・ルールを作成したとします。このディレクトリーへのアクセスを制限したいときには、c:\website\shopping をもつ ACL を指定したファイル保護文書を作成します。こうして、ユーザーが、 http://dominoinc.com/shop/welcome.html という URL を送信すると、ドミノはディレクトリー・ルールを使用して、実際上要求されたファイルを c:\website\shopping\welcome.html と決定します。ドミノはそれから、ファイル保護文書の対応リストを確認し、c:\website\shopping を検索し、そして ACL に対するユーザー証明書を確認します。ここで重要な点は、welcome.html ファイルへのパスが、ファイル保護文書で指定されたパスと一致しているということです。それゆえ、ACL が適用されています。

問題:ファイル・システム・オブジェクトへの代替パス
しかし、この方式には重大な問題があります。先にも述べたように、ドミノ・データベースからオブジェクトを要求するとき、ACL がオブジェクトのプロパティーなので、オブジェクトへのパス指定方法については問題はありません。しかし、Web サイト・ファイル保護を用いると、ACL はパスのプロパティーになります。そのため、オブジェクトへのパスが1つでなく複数ある場合、悪意のあるユーザーはファイル保護を回避することができます。ドミノでなくオペレーティング・システムが、最終的にパスの指定と解析を管理しているので、ドミノ（あるいは類似のいずれの Web サーバー）は、全体としてどのくらいの数の代替パスが、ある時点で同時に存在しているか把握できません。Rnext は、代替パスのこの欠点を補う最も良い処理をしています。しかし、いつも Rnext が把握していない別のパスが存在しているということになります。

代替パスの最も馴染みやすい例としては、パス・ナビゲーション順序を入れることです。 Windows と Unix の両方のプラッとフォームでは、カレント・ディレクトリー・レベルを表すのに、パスの中でシングル・ドット（ . ）を使用しています。そしてダブル・ドット（ .. ）は、親ディレクトリー・レベルを表します。デフォルト cgi-bin ディレクトリーにファイル保護文書を設定したとします。するとこれは下記のような設定になります。

Description:	Only registered users can run CGI programs（登録ユーザーだけが、CGI プログラムを起動できます。）
Directory or file path:	domino\cgi-bin
Access control list:	- Default- -(No Access) RegisteredUsers -(POST and GET)

ユーザーが、 account.pl という CGI プログラムを起動させたい場合、ユーザーは次のような URL を送信することになります。

http://dominoinc.com/cgi-bin/account.pl

この URL は、Rnext では次のファイルを指していると解釈されます。

C:\Lotus\Domino\Data\domino\cgi-bin\account.pl

このパスは明らかに、ファイル保護ルールと一致しています。ですから次に、Rnext はプログラムを起動する前に、ユーザーが RegisteredUser グループのメンバーかどうかを確認します。

しかし、悪意のあるユーザーは、account.pl に何とかアクセスしようとします。まずこの人が試すことは、URL でパス・ナビゲーション順序を使ってみることです（歴史的に、多くの Web アプリケーションは、このタイプの攻撃に弱いことが証明されています）。そのため、この人は次のような URL を送信します。

http://dominoinc.com/html/../cgi-bin/./account.pl

ですが、望ましいことに Rnext は、これを次のようなパスと解釈します。

hoping that Rnext will interpret the path as:

C:\Lotus\Domino\Data\domino\html\..\cgi-bin\.\account.pl

これは同じファイルを指していますが、一語一語とってみると、ファイル保護ルールに一致していません。この攻撃は成功しているのでしょうか。一見、成功しているようですが、URL を受信したときには、Rnext はただちに全てのパス・ナビゲーション順序を簡略化するので実は成功していません。ですから、要求処理が実行される前に、/html/../cgi-bin/./account.pl という受信 URL パスは、/cgi-bin/account.pl に簡略化されます（詳細は、Iris Today の記事、ドミノ Rnext で Web アプリケーションを作る：Web サイト・ルールを参照してください）。　　

代替パスのもう1つの例は、Windows 特有の問題です。元の MS-DOS オペレーティング・システムとの互換性を保つために、8文字より長いファイル名や、3文字より長い拡張子を持つファイルには、Windows は自動的に MS-DOS 用の別名を作成します。例えば、c:\website\pages\productlist.htm というファイルには、c:\website\pages\produc~1.htm という別名を作成します。ということは、c:\website\pages\productlist.htm のためのファイル保護文書を作成したとき、攻撃者は、http://dominoinc/pages/produc~1.htm という URL を要求すれば保護文書を回避できるのでしょうか。再度のこの攻撃はずる賢いものですが、しかし、Rnext はそれほど無能ではありません。Windows プラットフォームでは、Rnext では、想定される MS-DOS 用の別名のためのファイル保護文書を、自動的に確認しています。

代替パスのこれらの攻撃例は、よく知られていますし文書通知されています。しかし残念なことに、文書通知されていないパス文法や、オペレーティング・システムが異様な応答解析するといったことが、時々報告されています。Rnext のファイル保護機能や、オペレーティング・システムに依存する Web サーバーあるいは Web アプリケーションにとって、パスを解析する際に、これは本当に重大な実際問題となっています。OS 販売元が、しばしば何度もパッチをリリースしているので、この問題は最近ますます深刻になっています。OS パッチには、新しいパス文法の弱点をさらけ出しているものもあります。それゆえ、最も良い処置はリリース時のその時点で、Rnext と R5 の最新のリリースを適用することです。最新のリリースが、よく知られているパスの弱点を補います。リリース後にはどんなときでも、攻撃者が Rnext ファイル保護を回避できるような新しい OS の弱点が発見されることがあります。OS 販売元が、弱点を修正するパッチをたとえ発行したとしても、パッチを実際ダウンロードするサイト管理者に問題はなお、委ねられていることになります。

ファイル・リソースを安全に保つより良い方法
ファイル・リソースを安全に保つファイル保護に代わるものとは何でしょうか。R5 では、HTML ファイルとイメージ・ファイルをデータベース・ページか文書に呼び出すか、またあるいは、直接的な添付ファイルとしました。この方法では、データベース ACL と、文書の [Reader（読者）] フィールドの両方かあるいはどちらか一方を使用してリソースを安全に保てました。

Rnext は、次のようなさらに良い解決方法を提供しています。ファイル、イメージ、スタイル・シートの各リソースのために、新しいデータベース・オブジェクト・タイプを追加しました。ドミノ・デザイナーか WebDAV が有効なクライアントを使用して、ディスク・ファイルからこれらのオブジェクトを作成できます。オブジェクトは、OpenFileResource のような新しい URL コマンドを使うと、Web アプリケーションの中でアクセスできます。オブジェクトはデータベースに在るので、データベース ACL の全ての機能を活用して、そのオブジェクトへのアクセスを制御できます。例えば、ファイル保護文書を使わずに、HTML ファイルのディレクトリーへのアクセスを制御したい場合、この目的用に作成したデータベースにファイルを移動させます。Windows の File Explorer のような WebDAV が有効なクライアントを使用しているときには、1回のドラッグ＆ドロップ操作で、全てのディレクトリーをデータベースに移動させます。それから、データベース ACL を設定して Web ユーザーに適切なアクセス権を与えます。サーバーをクラスタ構成にしている場合には、さらにもうひとつ大きな効果が得られます。というのは、オブジェクトは、データベースの複製化に関わっているので、リソースの状態は自動的に全クラスタで同じ状態になるよう維持されます。

上に戻る

最後に

これまでのことを要約して、Rnext ファイル保護機能の安全な使用について、アドバイスをいくつかここで紹介します。

ファイル保護文書は、捜しものを見つけるためにサイトに迷い込んで来る好奇心の強い訪問者のような、軽い攻撃に対しては十分な防御手段となります。正規の検索エンジンとマナーを守る Web 検索者に対しても保護は十分安全です。これらのクライアントは全て、共通の文書通知されたパス文法を使用しているからです。

しかし、オペレーティング・システムの弱点やパッチが入っていないシステムを不当に利用できる攻撃者に対しては、ファイル保護文書は信頼のおける保護手段ではありません。したがって、（クレジット・カード番号や競合情報、個人ファイルなどの）サイト上の全ての機密データは、適切な ACL を用いてドミノ・データベースに保存しておくべきです。ファイル・システムに機密情報を保存してはいけません。このような情報保護するのに、ファイル保護文書を用いるべきではありません。

著者について
ジョン・チェンバレンは、Rnext ドミノ Web サーバー・チームのシニア・ソフトウェア・エンジニアです。

上に戻る