「認証」とは、誰かが自分は誰であるかを主張した場合に、 それを確認するための全過程を指します。「承認」とは、 誰かが行きたい場所に行けるように、あるいは欲しい情報を 得ることができるようにするための全過程を指します。
もし機密の情報や、ごくごく少数グループの人向けの情報を ウェブサイトに置くのであれば、この文書に書かれている テクニックを使うことで、そのページを見ている人たちが 望みの人たちであることを確実にできるでしょう。
この文書では、多くの人が採用するであろう、 ウェブサイトの一部分を保護する「一般的な」 方法についてカバーしています。
データが本当に機密なのであれば、認証に加えてさらに
この文書で取り扱われるディレクティブは、
メインサーバ設定ファイル (普通は
.htaccess
ファイル) かで用います。
.htaccess
ファイルを用いるのであれば、
これらのファイルに認証用のディレクティブを置けるように
サーバの設定をしないといけないでしょう。これは
認証について話を進めているので、次のような
そうでなく、メインサーバ設定ファイルの中に 直接置くのであれば、当然ながらそのファイルへの書き込み 権限を持っていなければならないでしょう。
また、どのファイルがどこに保存されているか知るために、 サーバのディレクトリ構造について少し知っておく 必要があるでしょう。 これはそんなに難しくないので、この文書中で ディレクトリ構造について知っておく必要がある場面では、 明らかになるようにします。
では、サーバ上のあるディレクトリをパスワードで保護する 基本手順を示します。
まずはじめに、パスワードファイルを作ります。 どの認証プロバイダを使うかによって、パスワードファイル生成の手順は 大きく異なります。ここでの例では、手始めにテキストパスワードファイルを 使います。
このパスワードファイルは、ウェブからアクセスできる場所に
置くべきではありません。他の人がパスワードファイルを
ダウンロードできないようにするためです。例えば、
/usr/local/apache/htdocs
でドキュメントを
提供しているのであれば、パスワードファイルは
/usr/local/apache/passwd
などに置いた方が良いでしょう。
ファイルを作るためには、Apache 付属の bin
ディレクトリ以下に置かれます。サードバーティ製のパッケージで
インストールした場合は、実行パスの中で見つかるでしょう。
ファイルを作るには、次のようにタイプしてください。
もし /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/htdocs/secret> セクションに
配置して、次のディレクティブを使うことができます。
個々のディレクティブについて見てみましょう。
Basic
で、これは AuthType Digest
をサポートしています。
この方法は
例えば、"Restricted Files"
領域中で
一度認証されれば、同一サーバ上で "Restricted Files"
Realm としてマークされたどんな領域でも、クライアントは
自動的に同じパスワードを使おうと試みます。
このおかげで、複数の制限領域に同じ realm を共有させて、
ユーザがパスワードを何度も要求される事態を
防ぐことができます。もちろん、セキュリティ上の理由から、
サーバのホスト名が変わればいつでも必ず、
クライアントは再びパスワードを尋ねる必要があります。
file
なので、今回の場合は無くても構いません。
最後に、
上記のディレクティブは、ただ一人 (具体的にはユーザ名
rbowen
の誰か) がディレクトリに
入れるようにします。多くの場合は、複数の人が
入れるようにしたいでしょう。ここで
もし複数の人が入れるようにしたいのであれば、 グループに属するユーザの一覧の入っている、グループ名のついた グループファイルを作る必要があります。このファイルの 書式はきわめて単純で、お好みのエディタで生成できます。 ファイルの中身は次のようなものです。
一行にスペース区切りで、グループに所属するメンバーの 一覧をならべるだけです。
既に存在するパスワードファイルにユーザを加える場合は、 次のようにタイプしてください。
以前と同じ応答が返されますが、新しいファイルを
作るのではなく、既にあるファイルに追加されています。
(新しいパスワードファイルを作るには -c
を使います。)
ここで次のようにして .htaccess
ファイルを
修正する必要があります。
これで、グループ GroupName
にリストされていて、
password
ファイルにエントリがある人は、
正しいパスワードをタイプすれば入ることができるでしょう。
もっと特定せずに複数のユーザが入れるようにする、 もう一つの方法があります。グループファイルを作るのではなく、 次のディレクティブを使えばできます。
require user rbowen
行でなく、上記を使うと、
パスワードファイルにリストされている人であれば誰でも
許可されます。
単にパスワードファイルをグループ毎に分けておくことで、
グループのような振る舞いをさせることもできます。
このアプローチの利点は、Apache は二つではなく、
ただ一つのファイルだけを検査すればよいという点です。
欠点は、たくさんのパスワードファイルを管理して、その中から
Basic 認証が指定されている場合は、 サーバにドキュメントをリクエストする度に ユーザ名とパスワードを検査しなければなりません。 これは同じページ、ページにある全ての画像を リロードする場合であっても該当します (もし画像も保護されたディレクトリから来るのであれば) 。 予想される通り、これは動作を多少遅くします。 遅くなる程度はパスワードファイルの大きさと比例しますが、 これは、ファイルを開いてあなたの名前を発見するまで ユーザ名のリストを読まなければならないからです。 そして、ページがロードされる度にこれを行わなければ なりません。
結論としては、一つのパスワードファイルに置くことのできる ユーザ数には実質的な限界があります。 この限界はサーバマシンの性能に依存して変わりますが、 数百のエントリを越えたあたりから速度低下が見られると予期されています。 その時は他の認証方法を考慮に入れた方が良いでしょう。
プレーンテキストでパスワードを保存する方法には上記の問題があり、 データベースのような別の場所にパスワードを保存したいと思う かもしれません。
dbm
あるいは dbd
を格納形式として選べます。
テキストファイルの代わりに dbm ファイルを選択する場合は、たとえば次のようにします。
この他のオプションも存在します。詳細に関しては
認証承認アーキテクチャに基づいている新しいプロバイダを使うと、 認証承認の方法をひとつに縛る必要がなくなります。 いくつものプロバイダを組み合わせて、自分の望みの挙動にできます。 次の例では file 認証プロバイダと ldap 認証プロバイダを 組み合わせています。
この例では、まず file プロバイダがユーザ認証を試みます。 認証できなかった場合には、ldap プロバイダが呼び出されます。 組織で複数の認証格納方法を使っている際などに、 この方法を使って認証のスコープを拡大できます。 もうひとつのシナリオは、ひとつの認証タイプと異なる承認を 組み合わせる方法でしょう。たとえば、パスワードファイルで認証して、 ldap ディレクトリで承認を行うといった場合です。
認証プロバイダを複数実装できるように、承認方法も複数使用できます。 この例では file グループ承認と ldap グループ承認を使っています。
承認をより細かく制御したい場合は、
承認の方法は、ひとつのデータソースを見て一回だけチェックするのと比べて、 ずっと多彩な適用方法ができます。 承認処理の適用順序や制御、選択ができるようになりました。
承認がどのような順序で適用されているか、また、それをどのように制御するかは、
これまで混乱を招いていました。
Apache 2.2 ではプロバイダベースの認証メカニズムが導入され、
承認処理から認証処理とサポート機能とが切り分けられました。
これによるひとつの効果として、
認証モジュールのロード順やモジュール自体の順序に依存することなく、
指定した順番で認証プロバイダが呼び出せるよう、
設定できるようになりました。
このプロバイダメカニズムは承認処理でも導入されています。
つまり、
追加で導入された
デフォルトでは
ユーザ名とパスワードによる認証は全体の一部分でしかありません。 誰がアクセスしてきたかといった情報以外の条件を使いたい、 とよく思うことでしょう。 たとえば、どこからアクセスしてきているか、といった具合です。
承認プロバイダ
これらプロバイダの扱いは
ここで、address は IP アドレス (あるいは IP アドレスの 一部) か :
ここで domain_name は FQDN (あるいはドメイン名の一部) で、必要であれば複数のアドレスやドメイン名を書くことができます。
たとえば、スパムメッセージを送信してくる誰かを拒否したい場合、 次のようになります :
このディレクティブが有効な範囲のコンテンツに対しては、 そのアドレスからアクセスしてきても見ることができません。 もしマシン名がわかっていて IP アドレスよりもそちらで 指定したいのであれば、そのマシン名が使えます。
また、特定のドメインからのアクセス全てをブロックしたい場合は、 IP アドレスの一部や、ドメイン名が指定できます :
上記の例では
認証プロバイダベースの機構があるため、以前使用されていたディレクティブ
これらのディレクティブの抱えていた問題のひとつに、承認の設定行とアクセス制御の設定行の
関係がとてもあいまいだったことが挙げられます。
これら全てがどのように動作するかについて
もっと多くの情報が書かれている
アクセス制御の方法も、 関連するトピックがたくさん記載されていますので、ご覧ください。