From ac02e96bf4bfb3b0c49e4c9072ecb62b1e7b1adc Mon Sep 17 00:00:00 2001 From: Yoshiki Hayashi Date: Fri, 28 Nov 2003 22:23:48 +0000 Subject: [PATCH] Convert to XML. Submitted by: Hiroaki KAWAI git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101914 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/howto/auth.xml.ja | 373 ++++++++++++++++++++++++++++++++ docs/manual/howto/auth.xml.meta | 2 +- 2 files changed, 374 insertions(+), 1 deletion(-) create mode 100755 docs/manual/howto/auth.xml.ja diff --git a/docs/manual/howto/auth.xml.ja b/docs/manual/howto/auth.xml.ja new file mode 100755 index 0000000000..3434cc0fb0 --- /dev/null +++ b/docs/manual/howto/auth.xml.ja @@ -0,0 +1,373 @@ + + + + + + +How-To / チュートリアル + +認証、承認、アクセス制御 + + +

「認証」とは、誰かが自分は誰であるかを主張した場合に、 + それを確認するための全過程を指します。「承認」とは、 + 誰かが行きたい場所に行けるように、あるいは欲しい情報を + 得ることができるようにするための全過程を指します。

+
+ + + +
はじめに +

もし機密の情報や、ごくごく少数グループの人向けの情報を + ウェブサイトに置くのであれば、この文書に書かれている + テクニックを使うことで、そのページを見ている人たちが + 望みの人たちであることを確実にできるでしょう。

+ +

この文書では、多くの人が採用するであろう、 + ウェブサイトの一部分を保護する「一般的な」 + 方法についてカバーしています。

+
+ +
準備 +

この文書で取り扱われるディレクティブは、 + メインサーバ設定ファイル (普通は + Directory + セクション中) か、あるいはディレクトリ毎の設定ファイル + (.htaccess ファイル) かで用います。

+ +

.htaccess ファイルを用いるのであれば、 + これらのファイルに認証用のディレクティブを置けるように + サーバの設定をしないといけないでしょう。これは + AllowOverride + ディレクティブで可能になります。 + AllowOverride + ディレクティブでは、ディレクトリ毎の設定ファイル中に置くことのできる + ディレクティブを、もしあれば、指定します。

+ +

認証について話を進めているので、次のような + AllowOverride + ディレクティブが必要になるでしょう。

+ + + AllowOverride AuthConfig + + +

そうでなく、メインサーバ設定ファイルの中に + 直接置くのであれば、当然ながらそのファイルへの書き込み + 権限を持っていなければならないでしょう。

+ +

また、どのファイルがどこに保存されているか知るために、 + サーバのディレクトリ構造について少し知っておく + 必要があるでしょう。 + これはそんなに難しくないので、この文書中で + ディレクトリ構造について知っておく必要がある場面では、 + 明らかになるようにします。

+
+ +
動作させる +

では、サーバ上のあるディレクトリをパスワードで保護する + 基本手順を示します。

+ +

パスワードファイルを作る必要があります。 + このファイルは、ウェブからアクセスできる場所に + 置くべきではありません。他の人がパスワードファイルを + ダウンロードできないようにするためです。例えば、 + /usr/local/apache/htdocs でドキュメントを + 提供しているのであれば、パスワードファイルは + /usr/local/apache/passwd + などに置いた方が良いでしょう。

+ +

ファイルを作るためには、Apache 付属の htpasswd + を使います。このコマンドは Apache をどこにインストールしようとも、 + インストールディレクトリの bin + ディレクトリ以下に置かれます。ファイルを作るには、次のように + タイプしてください。

+ + + htpasswd -c /usr/local/apache/passwd/passwords rbowen + + +

htpasswd は、パスワードを要求し、その後 + 確認のためにもう一度入力するように要求してきます。

+ + + # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mypassword
+ Re-type new password: mypassword
+ Adding password for user rbowen +
+ +

もし htpasswd がパスの中に入っていない場合は、 + もちろん、実行するためにプログラムまでのフルパスを + タイプする必要があります。私のサーバであれば、 + /usr/local/apache/bin/htpasswd + にプログラムが置かれています。

+ +

次に、サーバがパスワードを要求するように設定して、 + どのユーザがアクセスを許されているかをサーバに知らせなければ + なりません。 httpd.conf を編集するか + .htaccess ファイルを使用するかで + 設定します。例えば、ディレクトリ + /usr/local/apache/htdocs/secret + を保護したい場合は、 + /usr/local/apache/htdocs/secret/.htaccess + か httpd.conf 中の <Directory + /usr/local/apache/apache/htdocs/secret> セクションに + 配置して、次のディレクティブを使うことができます。

+ + + AuthType Basic
+ AuthName "Restricted Files"
+ AuthUserFile /usr/local/apache/passwd/passwords
+ Require user rbowen +
+ +

個々のディレクティブについて見てみましょう。 + AuthType + ディレクティブはどういう認証方法でユーザの認証を行うかを + 選択します。最も一般的な方法は Basic + で、これは mod_auth_basic + で実装されています。しかしながら、 + これは気を付けるべき重要なポイントなのですが、 + Basic 認証はクライアントからブラウザへ、 + パスワードを暗号化せずに送ります。ですから、 + この方法は特に機密性の高いデータに対しては用いるべきでは + ありません。 Apache ではもう一つ別の認証方法: + AuthType Digest をサポートしています。 + この方法は mod_auth_digest + で実装されていて、もっと安全です。 + ごくごく最近のクライアントしか Digest + 認証をサポートしていないようです。

+ +

AuthName + ディレクティブでは、認証に使う Realm (訳注: 領域) + を設定します。Realm は大きく分けて二つの機能を提供します。 + 一つ目は、クライアントがパスワードダイアログボックスの + 一部としてユーザにこの情報をよく提示する、というものです。 + 二つ目には、クライアントが与えられた認証領域に対してどのパスワードを + 送信すれば良いのかを決定するために使われる、という機能です。

+ +

例えば、"Restricted Files" 領域中で + 一度認証されれば、同一サーバ上で "Restricted Files" + Realm としてマークされたどんな領域でも、クライアントは + 自動的に同じパスワードを使おうと試みます。 + このおかげで、複数の制限領域に同じ realm を共有させて、 + ユーザがパスワードを何度も要求される事態を + 防ぐことができます。もちろん、セキュリティ上の理由から、 + サーバのホスト名が変わればいつでも必ず、 + クライアントは再びパスワードを尋ねる必要があります。

+ +

AuthUserFile + ディレクティブは htpasswd で作った + パスワードファイルへのパスを設定します。 + ユーザ数が多い場合は、リクエスト毎のユーザの認証のための + プレーンテキストの探索が非常に遅くなることがあります。 + Apache ではユーザ情報を高速なデータベースファイルに + 保管することもできます。 + mod_auth_dbm モジュールが + AuthDBMUserFile + ディレクティブを提供します。これらのファイルは dbmmanage + プログラムで作成したり操作したりできます。 + Apache + モジュールデータベース中にあるサードパーティー製の + モジュールで、その他多くのタイプの認証オプションが + 利用可能です。

+ +

最後に、Require + ディレクティブが、サーバのこの領域にアクセスできるユーザを + 指定することによって、プロセスの承認部分を提供します。 + 次のセクションでは、Require + ディレクティブの様々な用法について述べます。

+
+ +
+複数の人が入れるようにする +

上記のディレクティブは、ただ一人 (具体的にはユーザ名 + rbowen の誰か) がディレクトリに + 入れるようにします。多くの場合は、複数の人が + 入れるようにしたいでしょう。ここで + AuthGroupFile + の登場です。

+ +

もし複数の人が入れるようにしたいのであれば、 + グループに属するユーザの一覧の入っている、グループ名のついた + グループファイルを作る必要があります。このファイルの + 書式はきわめて単純で、お好みのエディタで生成できます。 + ファイルの中身は次のようなものです。

+ + + GroupName: rbowen dpitts sungo rshersey + + +

一行にスペース区切りで、グループに所属するメンバーの + 一覧をならべるだけです。

+ +

既に存在するパスワードファイルにユーザを加える場合は、 + 次のようにタイプしてください。

+ + + htpasswd /usr/local/apache/passwd/password dpitts + + +

以前と同じ応答が返されますが、新しいファイルを + 作るのではなく、既にあるファイルに追加されています。 + (新しいパスワードファイルを作るには -c + を使います。)

+ +

ここで次のようにして .htaccess ファイルを + 修正する必要があります。

+ + + AuthType Basic
+ AuthName "By Invitation Only"
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthGroupFile /usr/local/apache/passwd/groups
+ Require group GroupName +
+ +

これで、グループ GroupName にリストされていて、 + password ファイルにエントリがある人は、 + 正しいパスワードをタイプすれば入ることができるでしょう。

+ +

もっと特定せずに複数のユーザが入れるようにする、 + もう一つの方法があります。グループファイルを作るのではなく、 + 次のディレクティブを使えばできます。

+ + + Require valid-user + + +

require user rbowen 行でなく、上記を使うと、 + パスワードファイルにリストされている人であれば誰でも + 許可されます。 + 単にパスワードファイルをグループ毎に分けておくことで、 + グループのような振る舞いをさせることもできます。 + このアプローチの利点は、Apache は二つではなく、 + ただ一つのファイルだけを検査すればよいという点です。 + 欠点は、たくさんのパスワードファイルを管理して、その中から + AuthUserFile + ディレクティブに正しいファイルを参照させなければならない点です。

+
+ +
起こりえる問題 +

Basic 認証が指定されている場合は、 + サーバにドキュメントをリクエストする度に + ユーザ名とパスワードを検査しなければなりません。 + これは同じページ、ページにある全ての画像を + リロードする場合であっても該当します + (もし画像も保護されたディレクトリから来るのであれば) 。 + 予想される通り、これは動作を多少遅くします。 + 遅くなる程度はパスワードファイルの大きさと比例しますが、 + これは、ファイルを開いてあなたの名前を発見するまで + ユーザ名のリストを読まなければならないからです。 + そして、ページがロードされる度にこれを行わなければ + なりません。

+ +

結論としては、一つのパスワードファイルに置くことのできる + ユーザ数には実質的な限界があります。 + この限界はサーバマシンの性能に依存して変わりますが、 + 数百のエントリを越えたあたりから速度低下が見られると予期されています。 + その時は他の認証方法を考慮に入れた方が良いでしょう。

+
+ +
もっと巧みに制御できない +? +

ユーザ名とパスワードによる認証は認証の一つの方法に過ぎません。 + しばしば誰であるかということとは違う何かに基づいて、 + 入れるようにしたくなることもあるでしょう。 + 例えばその人がどこから来ているかといったことです。

+ +

Allow と + Deny + ディレクティブを使って、ドキュメントを要求してきたマシンの + ホスト名やホストアドレスに基づいて許可不許可を制御できます。 + Order + ディレクティブはこの二つと連携して動作し、Apache + にどの順番でフィルタを適用するかを知らせます。

+ +

これらのディレクティブの使い方は次のようになります。

+ + + Allow from address + + +

ここで、address は IP アドレス + (または IP アドレスの一部)、あるいは完全修飾ドメイン名 + (またはドメイン名の一部) です。 + 必要であれば複数のアドレスやドメイン名を指定できます。

+ +

例えば、もし誰かが掲示板を攻撃していて、 + その人を閉め出したいのであれば、 + 次のようにすることができます。

+ + + Deny from 205.252.46.165 + + +

このアドレスから来る人は、このディレクティブの範囲内の + コンテンツを見ることができないません。もし IP + アドレスの代わりにマシン名があれば、それを使えます。

+ + + Deny from host.example.com + + +

ドメイン全体からのアクセスを防ぎたければ、 + 単にアドレスやドメイン名の一部を指定することができます。

+ + + Deny from 192.101.205
+ Deny from cyberthugs.com moreidiots.com
+ Deny from ke +
+ +

Order を使うことで、 + Deny と + Allow の組み合わせで + 入っても良いグループが本当に確実に限定できているようにできます。

+ + + Order deny,allow
+ Deny from all
+ Allow from dev.example.com +
+ +

Allow + ディレクティブを単純に列挙するのでは望みの動作をしないでしょう。 + なぜなら、全ての人が入れるということに加えて、 + 指定したホストからの人が入れるようにするからです。 + やりたいことは、指定した人たちだけが入れるように + することです。

+
+ +
追加情報 +

これら全てがどのように動作するかについて + もっと多くの情報が書かれている mod_auth と + mod_access + の文書も読むとよいでしょう。

+
+ +
+ diff --git a/docs/manual/howto/auth.xml.meta b/docs/manual/howto/auth.xml.meta index 8c00489d6c..981b2cd863 100644 --- a/docs/manual/howto/auth.xml.meta +++ b/docs/manual/howto/auth.xml.meta @@ -7,6 +7,6 @@ en - ja + ja -- 2.40.0