GCS Amplitude
GCS Amplitude

認証、承認、アクセス制御

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

(Following line optional)

Optional line:

if ((user == "John") ||

((Group == "admin")

&& (ldap-group contains auth'ed_user)

&& ((ldap-attribute dept == "sales")

|| (file-group contains auth'ed_user))))

then

auth_granted

else

auth_denied

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

があります。 この 2 つのモジュールは認証モジュールに共通なコアディレクティブを 実装しています。modauthzcore

はホスト名、IP アドレスや リクエストの特徴に基づいたアクセス制御を行いますが、 認証プロバイダのシステムの一部ではありません。 modaccess との後方互換性のため、 新しいモジュールの modauthz_host

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

ファイルを用いるのであれば、 これらのファイルに認証用のディレクティブを置けるように サーバの設定をしないといけないでしょう。これは

ディレクティブでは、ディレクトリ毎の設定ファイル中に置くことのできる ディレクティブを、もしあれば、指定します。AllowOverride

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

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

の両方が httpd バイナリに静的に組み込み済みであるか、apache2.conf 設定ファイルで動的にロードされるかして、httpd に組み込まれていなければ なりません。これらの二つのモジュールは、設定ファイルのなかで非常に 重要でウェブサーバの認証と承認で使用されるコアディレクティブと その機能を提供しています。modauthzcore

まずはじめに、パスワードファイルを作ります。 どの認証プロバイダを使うかによって、パスワードファイル生成の手順は 大きく異なります。ここでの例では、手始めにテキストパスワードファイルを 使います。

このパスワードファイルは、ウェブからアクセスできる場所に 置くべきではありません。他の人がパスワードファイルを ダウンロードできないようにするためです。例えば、 /usr/local/apache/htdocs

でドキュメントを 提供しているのであれば、パスワードファイルは /usr/local/apache/passwd

を使います。このコマンドは Apache をどこにインストールしようとも、 インストールディレクトリの htpasswdbin

ディレクトリ以下に置かれます。サードバーティ製のパッケージで インストールした場合は、実行パスの中で見つかるでしょう。

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

Re-type new password: mypassword

Adding password for user rbowen

がパスの中に入っていない場合は、 もちろん、実行するためにプログラムまでのフルパスを タイプする必要があります。デフォルトのインストール状態であれば、 htpasswd/usr/local/apache/bin/htpasswd

次に、サーバがパスワードを要求するように設定して、 どのユーザがアクセスを許されているかをサーバに知らせなければ なりません。 apache2.conf

ファイルを使用するかで 設定します。例えば、ディレクトリ /usr/local/apache/htdocs/secret

か apache2.conf 中の セクションに 配置して、次のディレクティブを使うことができます。

ディレクティブはどういう認証方法でユーザの認証を行うかを 選択します。最も一般的な方法は AuthTypeBasic

で実装されています。しかしながら、 これは気を付けるべき重要なポイントなのですが、 Basic 認証はクライアントからサーバへ、 パスワードを暗号化せずに送ります。ですからこの方法は、 modauthbasic

と組み合わせない状態では、 特に機密性の高いデータに対しては用いるべきでは ありません。 Apache ではもう一つ別の認証方法: mod_sslAuthType Digest

で実装されていて、もっと安全です。 最近のクライアントは Digest 認証をサポートしているようです。modauthdigest

領域中で 一度認証されれば、同一サーバ上で "Restricted Files"

プログラムで作成したり操作したりできます。 dbmmanageApache モジュールデータベース中にあるサードパーティー製の モジュールで、その他多くのタイプの認証オプションが 利用可能です。

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

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

GroupName: rbowen dpitts sungo rshersey

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

AuthName "By Invitation Only"

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

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

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

で file の代わりに、AuthBasicSourcedbm

テキストファイルの代わりに dbm ファイルを選択する場合は、たとえば次のようにします。

AuthLDAPURL ldap://ldaphost/o=yourorg

この例では、まず file プロバイダがユーザ認証を試みます。 認証できなかった場合には、ldap プロバイダが呼び出されます。 組織で複数の認証格納方法を使っている際などに、 この方法を使って認証のスコープを拡大できます。 もうひとつのシナリオは、ひとつの認証タイプと異なる承認を 組み合わせる方法でしょう。たとえば、パスワードファイルで認証して、 ldap ディレクトリで承認を行うといった場合です。

認証プロバイダを複数実装できるように、承認方法も複数使用できます。 この例では file グループ承認と ldap グループ承認を使っています。

ディレクティブを使って AND/OR ロジックで指定し、設定ファイルで 承認の処理順番の制御ができるようになっています。 これらのディレクティブをどのように使えるか、網羅した例をご覧ください。

ディレクティブは単にどの承認手法が使われるかを指定するだけではなく、 それらの呼び出し順序も指定できるようになりました。 複数の承認手法があるとき、その呼び出し順は、設定ファイルの Require

ディレクティブを使って、承認手法がいつ呼び出され、アクセスが許可された際に どの手続きが適用されるか指定することができます。 たとえば、次の承認ブロックのロジックを見てみましょう:

Require ldap-group cn=mygroup,o=foo

ディレクティブは OR 操作として扱われます。つまり、もし指定した承認手法の ひとつでも合格すれば、承認されます。 Require

ブロックで囲むとAND 操作となり、全ての承認手法で合格しなければ許可されません。

ユーザ名とパスワードによる認証は全体の一部分でしかありません。 誰がアクセスしてきたかといった情報以外の条件を使いたい、 とよく思うことでしょう。 たとえば、どこからアクセスしてきているか、といった具合です。

を使うと、リクエストを送信してきているマシンのホスト名や IP アドレス といった、ホストベースでのアクセス制御ができます。ip

で 指定されます。これらのディレクティブは承認プロバイダを登録し、 リクエスト処理の承認段階で呼び出されます。たとえば:Reject

ここで、address は IP アドレス (あるいは IP アドレスの 一部) か :

ここで domain_name は FQDN (あるいはドメイン名の一部) で、必要であれば複数のアドレスやドメイン名を書くことができます。

このディレクティブが有効な範囲のコンテンツに対しては、 そのアドレスからアクセスしてきても見ることができません。 もしマシン名がわかっていて IP アドレスよりもそちらで 指定したいのであれば、そのマシン名が使えます。

また、特定のドメインからのアクセス全てをブロックしたい場合は、 IP アドレスの一部や、ドメイン名が指定できます :

Reject ip 192.168.205

Reject host phishers.example.com moreidiots.example

を使って、アクセスに合格する前段階で、全ての

は必要なくなりました。 とはいうものの、古い設定ファイルでの後方互換性を提供するため、 これらのディレクティブは Satisfy

ディレクティブは リクエスト処理中でそれ自身を呼び出すことによって、これらの 2 つの処理段階を結びつけようとします。 現在は、これらのディレクティブは Satisfy

に移動し、 新しい認証ディレクティブと古いアクセス制御ディレクティブを混ぜて使うことは 難しくなっています。この問題のため、modaccesscompat

モジュールを ロードすることがとても重要で、必須になっています。 modauthzdefault

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

Apache HTTP サーバ バージョン 2.4

認証、承認、アクセス制御

翻訳済み言語: en | fr | ja | ko | tr

関連するモジュールとディレクティブ

認証と承認の処理に関連する 3 種類のモジュールがあります。 それぞれ少なくともひとつずつ必要です。

はじめに

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

準備

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

動作させる

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

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

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

パスワードの保存形式を変える

プレーンテキストでパスワードを保存する方法には上記の問題があり、 データベースのような別の場所にパスワードを保存したいと思う かもしれません。

複数のプロバイダを使用する

認証承認アーキテクチャに基づいている新しいプロバイダを使うと、 認証承認の方法をひとつに縛る必要がなくなります。 いくつものプロバイダを組み合わせて、自分の望みの挙動にできます。 次の例では file 認証プロバイダと ldap 認証プロバイダを 組み合わせています。

単純な承認のその先

承認の方法は、ひとつのデータソースを見て一回だけチェックするのと比べて、 ずっと多彩な適用方法ができます。 承認処理の適用順序や制御、選択ができるようになりました。

追加情報

これら全てがどのように動作するかについて もっと多くの情報が書かれている mod_auth_basic と mod_authz_host の文書も読むとよいでしょう。 ディレクティブを使うと、特定の認証設定が簡単に書けるようになります。