第11回 ユーザー認証によるアクセス制限(データベース認証編)
一志 達也<ichishi@pochi.tis.co.jp>
TIS株式会社
2001/12/7
PostgreSQLを使ったデータベース認証の設定
先に紹介したとおり、PostgreSQLを使ってデータベース認証を行うにはmod_auth_pgsqlを入手する必要がある。
入手先:http://www.giuseppetanzilli.it/mod_auth_pgsql/
2001年12月現在の最新バージョンは0.9.11だが、バージョンに大きな隔たりがなければLinxuディストリビューションなどのCD-ROMからインストールするのもいいだろう。
対応するPostgreSQLのバージョンは7.xとなっているが、こちらはたいていの場合問題ないだろう。ちなみに、PostgreSQLの2001年12月現在の最新バージョンは7.1.3である。ApacheとPostgreSQLは、Linux環境にあらかじめインストールしておく必要がある。この手順については、筆者が以前に執筆したPHP4での開発に必要なものを用意するが役に立つと思う。
■apxsを使ったインストール
ここでは、「apxs」と呼ばれるプログラムを使ったインストール方法を解説する。apxsを使うことで、mod_auth_pgsqlは「DSO」と呼ばれる形式のモジュールとしてコンパイルされる。この方法であれば、Apacheが導入済みの環境でもApacheを再コンパイルすることなくインストールできる。
Apacheをまだ導入していない環境であったり、再コンパイルしても構わないというのであれば、別の道を選ぶことも可能だ。その場合、mod_auth_pgsqlはApacheのスタティック・モジュールとして導入される。しかし、それは面倒であまり一般的とはいい難い方法である。ApacheとPostgreSQLを導入し、稼働確認も済ませたうえで必要なモジュールをDSOで組み込む方が簡単だからだ。DSOで組み込めるモジュールは、無理せずDSOを利用することをお勧めする。
| コラム DSOのメリット |
| Apacheのモジュールには、大きく分けて2つの方式がある。1つは、Apacheのコンパイル時にモジュールを組み込んでしまう方式。もう1つは、必要に応じて実行時にモジュールをダイナミックに組み込む方式である。
後者のように動作するモジュールをDSO形式と呼ぶ。モジュールを容易に組み込むために用意された方法である。パフォーマンスなどを厳密に追求すれば若干の差があるのかもしれないが、使い勝手を考えればDSOを使う方が有利であろう。 問題は、Apacheのインストール時にDSOをサポートするモードにしているかどうかだ。これは、apxsファイルの存在を確認するのが恐らく最も手っ取り早い。Apacheのバイナリディレクトリ(/usr/local/apache/binなど)に、apxsという名前のファイルがあるかどうかを確認してほしい。 |
■ソースコードの展開とコンパイル
ソフトウェアのインストール方法は、この連載をはじめ、Linux Squareフォーラムの多くの記事で取り上げられている。そこで、mod_auth_pgsqlのインストール手順については簡単な紹介にとどめる。
1.ソースコードの展開
tarコマンドやgzipコマンドを使って、入手したソースコードを展開する。
$ tar -xvzf mod_auth_pgsql-0.9.11.tar.gz |
2.生成されたディレクトリへの移動
$ cd mod_auth_pgsql-0.9.11 |
3.INSTALLの参照
インストール手順の確認のため、INSTALLファイルの内容を確認しておく。
$ less INSTALL |
4.configureの実行
INSTALLファイルのインストール手順に従って、configureを実行する。以下の例は、Apacheが/usr/local/apache、PostgreSQLが/usr/local/pgsqlにインストールされているものとする。
$ ./configure \ |
5.モジュールのコンパイル
以下のコマンドでコンパイルを行う。
$ /usr/local/apache/bin/apxs \ |
6.モジュールのインストール
コンパイルしたモジュールをインストールする。この作業のみ、rootユーザーでなくては行えない。
# /usr/local/apache/bin/apxs \ |
7.確認
一般ユーザーに戻り、Apacheの設定ファイル(httpd.conf)の内容を確認する。以下のような行が自動的に追加されているはずである。
LoadModule auth_pgsql_module libexec/mod_auth_pgsql.so |
8.Apacheの再起動
■httpd.conf(.htaccess)の設定
インストールできたら、httpd.conf(または .htaccess)の設定を行おう。本来ならデータベースを先に用意するべきだが、説明の都合上こちらを先にする。
これらのファイルの設定は、前回説明したようにディレクトリ別のセキュリティ設定に用いられる。ここでは、httpd.confに/usr/local/apache/htdocsで公開されているコンテンツへのアクセス制限を設定する方法を紹介する。
<Directory "/usr/local/apache/htdocs/"> |
これは、ごく単純なデータベース認証を設定した例である。簡単に説明すると、
Auth_PG_host 127.0.0.1 |
はデータベースがローカルホスト(127.0.0.1)にインストールされていること、
Auth_PG_port 5432 |
でポートが5432であることを指定している。次に、
Auth_PG_database test |
はデータベース名が「test」で、
Auth_PG_user postgres |
データベースへのアクセスには、ユーザー「postgres」とパスワード「pg_password」を用いる。
Auth_PG_pwd_table user_data |
この3行では、テーブル名が「user_data」であり、その「user_name」フィールドをユーザー名、passwdフィールドをパスワードとして扱うことを指定している。この場合、user_dataテーブルに含まれるデータに一致すれば、アクセス権を持つユーザーとして認証する。このように、mod_auth_pgsqlではユーザー名とパスワードを含むテーブル名やフィールド名は自由に決定できる。
悩ましいのは、PostgreSQLへアクセスするユーザー名とパスワードをここに記述している点である。ユーザー名とパスワードを書いてしまうのでは、データベースのセキュリティを低くしてしまう。解決策の1つは、user_dataテーブル(認証に使うテーブル)にnobodyユーザーでアクセスできるように権限設定することだ。そうすれば、設定ファイルにユーザー名とパスワードを書かなくても(省略しても)、ちゃんとデータを読み取ることができるようになる。しかし、今度はだれでもデータを読み取れることになる。何とも悩ましいところだが、筆者はnobodyユーザーに権限を与える方法を勧める。なぜなら、そこに格納するパスワードは、次に紹介するように暗号化することも可能だからだ。
■PostgreSQLへのユーザー登録
設定が済んだら、データベースにユーザーを準備しよう。先に説明したとおり、ユーザーを登録するテーブルやフィールドの名称は自由に決めて構わない。とにかく、1つのテーブルにユーザー名とパスワードに当たるフィールドがあればいいのだ。
ここでは、先の例になぞらえてuser_dataテーブルを作成しよう。そして、nobodyユーザーに権限を与え、データを登録してみる。
1.nobodyユーザーの作成
PostgreSQLにnobodyユーザーを登録していなければ、以下の手順でユーザー登録を行う。
$ createuser nobody |
ただし、データベースを作る権限は与えない方がいい。
Shall the new user be allowed to create
databases? (y/n) n |
新規ユーザーを作る権限も与えない方がいい。
Shall the new user be allowed to create
more new users? (y/n) n |
2.testデータベースに接続し、user_dataテーブルを作成する
$ psql test |
3.user_dataテーブルに、nobodyユーザーのみに参照権限を与える
test=# grant select on user_data to
nobody; |
4.ユーザーを登録する
test=# insert into user_data(user_name,
passwd) values('ichishi','xxj31ZMTZzkVA'); |
後は手順4を繰り返し、必要なだけユーザーを登録すればいい。ポイントは、パスワードのフィールドに格納している意味不明な文字列だろう。この文字列は、CRYPT方式で暗号化されたパスワードである。
mod_auth_pgsqlは、デフォルトでCRYPT方式で暗号化されたパスワードを採用している。このほかに MD5形式で暗号化されたパスワードを用いることも可能だが、その場合は
Auth_PG_hash_type MD5 |
という行をhttpd.conf(または.htpasswd)に設定する必要がある。逆に、パスワードを暗号化しないのであれば、
Auth_PG_encrypted off |
という行をhttpd.conf(または .htpasswd)に設定する。
CRYPT方式で暗号化されたパスワードは、意外に簡単に作成できる。Perlがインストールされているなら、以下のようにするのが簡単だ。
$ perl -e 'print crypt("password",
"xx");' |
上記の「xx」は、自由に決めた2文字の英数字を入れること。同じ文字列を暗号化する場合でも、この2文字の英数字によって結果が変化するようになっている。また、暗号化したパスワードの先頭の2文字は、ここで指定した2文字と一致するようになっている。
ここまで説明すれば、後は想像に難くないだろう。ユーザーが入力したパスワードを検査する際、先頭の2文字を読み取って入力したパスワードを暗号化するのである。一度暗号化した文字列は、決して元に戻すことはできない。少なくとも、そんなアルゴリズムは紹介されていない。パスワードを暴くには、適当な文字列を暗号化して、一致するものを探すしかないのである。しかし、これが弱点となる。
つまり、辞書に載っているような単語であれば、それを暗号化した辞書を作るのは簡単だ。従って、簡単な文字列の場合、暗号化した後の文字列さえ分かれば比較的容易に破られてしまう。この弱点を補うには、辞書に載っているような単語をパスワードにしないようにするしかない。
| コラム 暗号、過信は禁物 |
| ここで紹介しているCRYPT方式のように、英数字2文字でできるパターンは (26×2+10)2=3844 26×2:英大文字+小文字、10:数字 しかない。2万語の辞書を3844パターンで暗号化すると7688万通りで、決して天文学的数字ではない。普通のコンピュータでも簡単に暗号データベースを作成できてしまう。 |
■グループを使ったセキュリティ設定
次は、グループでの認証を行う方法である。これには、ユーザーを管理するテーブルのほかに、グループを管理するテーブルが必要となる。
mod_auth_pgsqlの仕様的には、同じテーブルでユーザーとグループを管理することもできる。しかし、この場合は1人のユーザーが複数のグループに所属するような管理が難しい。RDBの設計上も、こうした設計は冗長なものと見なされる。従って、グループを柔軟に管理しやすいよう、複数のテーブルを作成する方法をお勧めする。
| user_name | passwd | group_name | user_name | ||
| ichishi |
…
|
Admin | ichishi | ||
|
…
|
…
|
Tech | ichishi | ||
|
…
|
…
|
…
|
…
|
||
| user_dataテーブル | group_dataテーブル | ||||
上のようなテーブルを作成した場合、グループ名はgroup_nameフィールドに格納される。その中のAdminグループにのみアクセス権限を与えるのであれば、次のように設定すればよい。
<Directory "/usr/local/apache/htdocs/"> |
■より高度なセキュリティ設定
mod_auth_pgsqlにはほかにもディレクティブが存在する。その中で重要と思われるのが「Auth_PG_pwd_whereclause」と「Auth_PG_grp_whereclause」である。これは、Auth_PG_pwd_tableもしくはAuth_PG_grp_tableで指定したテーブルに、さらに条件を付け加えるために用いられる。
例えば、user_dataテーブルに登録されたユーザーで、なおかつlocationフィールドが TOKYOのユーザーだけを認証するとしよう。その場合、
Auth_PG_pwd_whereclause "and location='TOKYO'" |
となる。このように、「""」で条件を囲み、その条件の先頭には「and」を付け加える。同様に、グループを登録したテーブルに含まれる列に対して特定の条件を付け加えたいのであれば、Auth_PG_grp_whereclauseを使えばよい。
■監査(ログを取る)
mod_auth_pgsqlは、PostgreSQLを使って独自にアクセスログを収集できる。ログは、認証に成功した際にログ用テーブルに記録される。記録できるのは、ユーザー名、時刻、リクエストしたURI、クライアントのIPアドレス、パスワード(平文)となっている。
通常、パスワードを記録することはないと思われるが、場合によっては制限されたコンテンツに対してだれがどこからいつアクセスしたかを記録したいこともあるだろう。その際は、以下のように設定すればよい。
<Directory "/usr/local/apache/htdocs/"> |
この設定例では、log_dataテーブルの各フィールドにユーザー、時刻、URI、IPアドレスが記録される。注意点は、やみくもに記録したのではディスクを無駄に消費するだけになるということである。ログを記録するのであれば、その運用についてもルールを定め、定期的にデータをクリーニングするなどの手段を用意しなければならない。
◆
ほかのデータベースでも、基本的な流れやできることに大差はない。これを参考に、ほかのデータベースを使ってみるのもよいだろう。
次回は、SSLを使ってHTTP通信を暗号化する設定を紹介する。
|
2/2
|
|
| Index | |
| ApacheによるWebサーバ構築 | |
| データベース認証のメリット メンテナンス性の高さ より強固なセキュリティの確保 |
|
| データベース認証に利用できるデータベース | |
| PostgreSQLを使った認証の設定 apxsを使ったインストール ソースコードの展開とコンパイル httpd.conf(.htaccess)の設定 PostgreSQLへのユーザー登録 グループを使ったセキュリティ設定 より高度なセキュリティ設定 監査(ログを取る) |
|
| 連載 ApacheによるWebサーバ構築 |
| Linux Squareフォーラム サーバ構築・運用関連記事 |
| 連載:Heartbeatでかんたんクラスタリング(連載中) オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します |
|
| 特集:Apache 2.2でWebサイトをパフォーマンスアップ! 最新安定版Apache 2.2は、何が変わったのか? 最新のApacheを新機能の使い方とともに解説する |
|
| 連載:実用 Apache 2.0運用・管理術(全8回) 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える |
|
| 連載:実用
BIND 9で作るDNSサーバ(全15回) 本連載では、BIND 9の構築/運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく |
|
| 連載:実用qmailサーバ運用・管理術(全14回) 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで |
|
| 特集:Samba
3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する |
|
|
TechTargetジャパン
- 新しい記事も入っていて安心しました (2012/2/7)
Linux Squareのアクセスランキングを公開します。定番の記事ばかりでなく、連載中の記事もよろしくお願いいたします - エラーメッセージをどう扱うか? (2012/2/2)
今回は、スクリプト実行時にエラーが発生したことを知らせるメッセージの扱い方を説明します - ファイルのアップロードを制限する (2012/1/30)
HTTPクライアントがアップロードしてくるファイルの扱いについて解説します。そもそも受け入れる必要があるのか? ということのほかにも、いろいろ設定が必要です - OSに付属するシェルスクリプトを読んで技術を盗む (2012/1/27)
シェルスクリプトマスターに近づくには、他人から技術を盗まなければならない。OS付属のスクリプトから技術を盗もう
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -
