初出：SoftwareDesign 2001/11月号
特集 差がつくPostgreSQLパワーアップテクニック
『PostgreSQL＋Kerberosでセキュアなデータベース』
くわむらじゅん
juk@yokohama.email.ne.jp
急に涼しくなって、あの夏バテは何だったのかと不思議に思う秋の夜長とな
りました。窓の外からは高速道路の音に負けじとコオロギが鳴いています。気
のせいか車の風切音が心なし淋しくも聞こえます。中途半端な趣の書き出しと
なってしまいましたが、部屋の中は(ちょっと汗ばむ)心持ち暖かです。
この夏は、心やさしい松岡先輩や本誌でもおなじみの佐賀井様こじま様のお
かげでDualronなるものを体験することができました。いまさらと言って笑っ
ておられる方もいらっしゃるでしょうが、私にとってはさしたる目的もなく型
落ちのHP Vectra XWを買って以来の念願のDual CPUでした。結局、Vectra XW
用のPentium Proは、ほり出し物（さしたる目的もないのに出せる金額の）は
見つけられずじまいであきらめていました。聞くところによると、大きなマト
リックスを扱う数値計算では、並列化してPentiumIIIのSMPを使ってもメモリー
I/Oがボトルネックになるため、シングルのPentiumIVを使った方が早いそうで
す。とは言え日常的に使うには少し速くなるようで、今回のデュアル構成となっ
たA300@450MHzの心持ち速くなった感じがします。このマザーボードは温度セ
ンサーなどもあるようですので、時間ができたらlm_sensorsやrrdtoolなどで
少し遊んでみようかと思ったりもしています[*] 。
[*]
http://www.netroedge.com/~lm78/
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
● インターネットの落し穴
さて、自宅からあちこちログインして作業をしていると、セキュリティのこ
とが心配になることがあります。特に、インターネット越しにリモートサーバ
に繋いで使っているときに、ふと、今自分の使っている端末(kterm)は、SSHで
リモートログインしていたかなと心配になったりします。サーバ管理者にとっ
て、リモートサーバのメンテにSSHを使ってログインし、psqlを動かして
PostgreSQLのデータを操作することはよくあることだと思います。PostgreSQL
はいくつかの認証方式をサポートしていて、インターネット越しに、直接
PostgreSQLのバックエンドサーバにアクセスすることも可能です。使い方を間
違えるとパスワードや大切な情報がインターネットの途中経路で丸見えになっ
てしまいます。
最近は、組織内のLAN であってもパスワードをそのまま流すことは危なくなっ
てきています。端末が個人レベルで管理されるようになってきたということは、
同時に、誰もが管理者権限でもってNIC(LANカード)を通過するパケットを拾っ
て見ることが可能だということになります。先頃、ある会社で同僚のパスワー
ドを使って成り済ましてメールを読んだり勝手に送信するなどしていやがらせ
をしていたOLが、不正アクセス禁止法違反容疑で逮捕され、電気通信事業法違
反（通信の秘密の侵害）の疑いでも追送検されたそうです。asahi.comをはじ
め各誌Webサイトで実名入り掲載されたためご存知の人も多いかと思います。
理由はともあれ、そのまま刑が確定すると２つの罪で前科がついてしまいます。
これまたインターネットの簡単にいろいろなことができてしまうという悪い方
の例になりそうです。記事ではパスワードを推定して偶然一致したように書か
かれてありましたが、LANを流れるパケットを拾うことのできる環境があれば、
推定しなくてもずばりそのものを手に入れることも可能なことと思います。
● PostgreSQLのアクセス制御
話題がそれてインターネットのダークサイドへと進んでしまいましたが、こ
の辺りで軌道修正しまして、では、PostgreSQLではどういう対策を施せるのか
ということを見てゆきたいと思います。
もしかすると、PostgreSQLに格納したデータはもしかすると誰でもアクセス
できるのではないかと心配している方もいらっしゃるかもしれません。SQLレ
ベルでは、テーブルへのアクセス権をGRANT で授与し、REVOKEで剥奪すること
が可能です。psql フロントエンドプログラムで簡単な使い方のヘルプを見る
ことができます。
--
postgres=# \h GRANT
Command: GRANT
Description: Grants access privilege to a user, a group or all users
Syntax:
GRANT privilege [, ...] ON object [, ...]
TO { PUBLIC | GROUP group | username }
postgres=# \h REVOKE
Command: REVOKE
Description: Revokes access privilege from a user, a group or all users.
Syntax:
REVOKE privilege [, ...]
ON object [, ...]
FROM { PUBLIC | GROUP groupname | username }
--
リスト1 GRNATとREVOKEの使い方ヘルプ
リスト1 では object にテーブルやインデックスの名前、privilege に
{SELECT,INSERT,UPDATE,DELETE,RULE}の組合せ、もしくは ALLを権限として指
定できます。他のデータベースユーザに対する保護はこれで可能ですが、その
データベースユーザとしてアクセスされないということが条件となります。
PostgreSQLのバックエンドサーバへのアクセス制御は$PGDATA/pg_hba.confと
いうファイルに記述します。HBAはホストベースの認証(host-based
authentication)のことで、pg_hba.conf には、バックエンドサーバに接続す
るソケットの種類とホスト毎にに決められた認証のしかたを記述します。この
場合、認証はデータベースサーバがユーザの身元を確認することで、データベー
スユーザはUNIXのログインユーザとは異なります。PostgreSQLデータベースサー
バは、ホストのオペレーティングシステムの管理するユーザとは別に、独自の
ユーザ管理をしています。ソケットの種類にはUNIXドメインソケットとINETド
メインソケットとSSL(Secure Socket Layer)とがあり、それぞれ以下のような
レコード指定ができます。UNIXドメインソケットはlocalという記述で始まり
ます。
--
local DATABASE AUTHTYPE [AUTH_OPTION]
--
INETソケットはhostという記述で始まります。
--
host DATABASE IP_ADDRRESS ADDR_MASK AUTHTYPE [AUTH_OPTION]
--
SSLはhostsslという記述で始まります。
--
hostssl DATABASE IP_ADDRESS ADDR_MASK AUTHTYPE [AUTH_OPTION]
--
ここで、DATABASEはデータベース名ですべてのデータベースを示すときはall
と記述することができ、接続ユーザと同じ名前のときはsameuserと記述できま
す。
INETソケットを利用するためには バックエンドサーバを -i オプションで
起動するか、$PGDATA/postgresql.conf に
--
tcpip_socket = true
--
の記述をして起動します。
SSLを利用するには、バックエンドサーバがSSLをサポートできるように構築
しておきます(OpenSSLが必要)。そして、バックエンドサーバを -l オプショ
ンで起動するか、$PGDATA/postgresql.confに
--
tcpip_socket = true
ssl = true
--
の記述をして起動します。SSLを使うとセッションがすべて暗号化されます。
ただし、クライアントもSSLをサポートする必要があります。
IP_ADDRESSとADDR_MASKとにはIPアドレスとアドレスをグループ化するIPマス
クを指定します。一致するかどうかを判定するルールは、
(actual-IP_ADDRESS xor IP_ADDRESS-field) and ADDR_MASK-field
が０になればIPアドレスがレコードの対象として一致したことになります。
AUTHTYPEには認証方法の種類を、
{trust,password,crypt,ident,krb4,krb5,reject}
から選んで記述し、種類によってはAUTH_OPTION引数を指定します。このうち、
ネットワーク越しで使って安全なものはcrypt,krb4,krb5です。crypt は簡単
なハッシュをかけてパスワードをそのまま流さないようにしますし、krb4と
krb5はKerberos認証でパスワードのかわりに安全なチケットが使われます。
trustはネットワークに繋がないでテストするとき以外では使うべきではあり
ませんし、identはクライアントのホストを全面的に信頼しなければならない
ので、安全とは言い切れません。rejectを指定するとまったく接続をさせませ
ん。
ただし、SSLを使うとセッションが暗号化されますので、平文パスワードも
気兼ねなく流すことができます。セッションの暗号化のためには、SSLをサポー
トしなくても、SSHの用意がサーバマシンとクライアントにあれば可能です。
サーバ側にsshdが走っていれば、クライアントはsshコマンドを使って暗号化
したトンネルにポート転送を行なえます。たとえば、
ssh -L 3333:foo.com:5432 joe@foo.com
のようにしますと、ローカルの3333ポートをリモート(foo.com)の5432にSSH経
由で転送します。したがって、このトンネルを開通した後に、PostgreSQLのク
ライアントたとえばpsqlを使って、
psql -h localhost -p 3333 template1
のようにローカルの3333ポートにアクセスします。
● PostgreSQLのセキュリティ
SSLもしくはSSHのトンネルを利用して暗号化セッションを張ると、多少暗号
化によるオーバーヘッドはあるものの、かなり安全に利用することが可能にな
ります。使い勝手を考えるとやはりSSLオプションで接続するのが便利です。
もう少し欲を言えば、接続の度にいちいちパスワードを入力しないでも接続
できないものかと思います。PostgreSQLに限らず、他のサービスも利用したい
場合に、最初に１度パスワードを入力すれば、その日の内くらいはパスワード
を入力しなくても、次々と別のサービスを利用できると便利です。１度ログイ
ンするだけでいろいろなサービスを利用できるシステムをシングル・サインオ
ンと言ったりしますが、Kerberos を使えばこれを可能にできます。
かつて、安全と考えられた小規模LANでは接続しようとするクライアントが
自己申告するホスト名だけを頼りに認証するBSD系r*コマンドを重宝がり使っ
ていましたが、Kerberosを使うことによってそれと同等の使い勝手を、安全と
は言えないネットワークにおいても、安全に確保することができます。また、
SSHのようにパスワード入力を省くためにリモートホスト毎に鍵を生成して置
おく必要はありませんし、しかも、パスワードの変更をホスト毎に行なわなく
ても、1度の変更で済ませられます。したがって、Kerberosを導入した環境で
は、一般のユーザもその利便性を苦無く享受することができます。
Kerberosはユーザの認証の他に、実装レベルによってはセッションの暗号化
までもできるのですが、PostgreSQLへの実装にはセッションの暗号化は含まれ
ません。セッションの暗号化は既に述べたようにSSLで提供されます。ここで
は、SSLとKerberosを組み込んだPostgreSQLサーバの作り安全で使い勝手の良
いデータベースサーバの作り方について簡単に説明します。
まず、SSLとKerberosのライブラリを用意しますが、SSLにはOpenSSLを
KerberosにはKTH-KRBを使うことにします。OpenSSLはオープンソースで開発さ
れているSSLで[*]、KTH-KRBはKerberos4の国際版です[*]。
[*] http://www.openssl.org/
[*] http://www.pdc.kth.se/kth-krb/
いずれも、通常の、
./configure; make; make install
でインストールできるはずです。デフォルトのインストール先ディレクトリは、
OpenSSLが/usr/local/ssl、KTH-KRBが/usr/athenaとなります。OpenSSLと
KTH-KRBが、それぞれ、デフォルトの場所にうまくインストールされていると
すると、PosrgreSQLの configure を走らせるときに、以下のオプションを加
えます。
--with-openssl=/usr/local/ssl
--with-krb4=/usr/athena
利用可能ななKerberosのバージョンには4と5とがあるのですが、ここでは、
より基本的なKerberos4を方を使います。さらに、
--with-krb-srvnam=NAME
で、Kerberosのサービスプリンシパルの名前をNAMEに指定することもできまが、
デフォルトはpostgresです。
● PostgreSQLのSSL設定
SSLモードで起動されたpostmasterは$PGDATAディレクトリを捜してプライベー
ト鍵server.keyと証明書server.crtを読み込みます。もし、プライベート鍵が
パスフレーズで保護されている場合は、postmasterはパスフレーズが入力され
るまでは動き出しません。実際に製品として使うには CA (世界共通の認証局
もしくは地元認証局)の署名付き証明書を使うべきですが、ここでは、自筆署
名の証明書を作ることにします。サーバのプライベート鍵と証明書の生成は、
次のOpenSSLコマンドで行ない（/usr/local/ssl/binへコマンドパスを通して
おきましょう）、OpenSSLからの質問に答えます。このとき、"Common Name"
にマシンのホスト名、"challenge password" には何も入れないでリターンし
てかまいません。(リスト2-[1])
このままでは、起動の度にパスフレーズを入力しなくてはなりません。パス
フレーズ入力を省くためには署名の暗号を解除しておきます。この作業には次
のOpenSSLコマンドを実行します。(リスト2-[2])
証明書を自筆署名の証明書に変換します。(リスト2-[3])
鍵と証明書とをPostgreSQLが読み込む所定の場所へコピーします。(リスト
2-[4])
最後に、既に述べたバックエンドサーバ起動時のSSL接続オプションと、HSB
の記述とを忘れずに行ないます。
--
[1] openssl req -new -text -out cert.req
Using configuration from /usr/local/ssl/openssl.cnf
Generating a 1024 bit RSA private key
.....++++++
..++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase: XXXXXXXXXXXXXXXXXXX <=
Verifying password - Enter PEM pass phrase: XXXXXXXXXXXXXXXXXXX <=
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP <=
State or Province Name (full name) [Some-State]:Yokohama <=
Locality Name (eg, city) []:Aoba <=
Organization Name (eg, company) [Internet Widgits Pty Ltd]:JPUG <=
Organizational Unit Name (eg, section) []:Plamo <=
Common Name (eg, YOUR name) []:penpen <= ホスト名を
Email Address []:juk@yokohama.email.ne.jp <=
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <= なし
An optional company name []: <=
[2] openssl rsa -in privkey.pem -out cert.pem
read RSA key
Enter PEM pass phrase: XXXXXXXXXXXXXXXXXXX <= 証明書をつくったときの
writing RSA key パスフレーズ
[3] openssl req -x509 -in cert.req -text -key cert.pem -out cert.cert
Using configuration from /usr/local/ssl/openssl.cnf
[4] cp cert.pem $PGDATA/server.key; cp cert.cert $PGDATA/server.crt
--
リスト2 OpenSSLで証明書を作成する例
● PostgreSQLのKerberos設定
ここでは、ひととおりKerberosの設定について触れますが、紙面の都合上、
PostgreSQLの設定に特有のこと以外はかなり大雑把な説明となります。詳しく
は技術評論社から出版されます「ファイアウォール＆ネットワークセキュリティ
実戦テクニック」をご参照下さるようお願い致します。
--
（注）
タイトル：ファイアウォール＆ネットワークセキュリティ実戦テクニック
著者：複数（技術評論社第2編集部 編）
B5変形／416ページ
発行日：11/1/2001
定価：2,800円
ISBN4-7741-1313-1
--
Kerberosの設定について説明する前に、Kerberos について概要を説明して
おきます。KerberosはMIT(マサチューセッツ工科大学) のProject Athena(ア
テネ・プロジェクト)で、ギリシャ神話に出てくる冥界の番犬の名前を付けら
れ、キャンパスネットワークの認証システムとして開発されました。バージョ
ン4になってはじめてMIT 以外にも公開されましたが、輸出規制のため米国と
カナダ以外の国ではDES(Data Encryption Standard)暗号モジュールの外され
たBonesというコードが持ち出されました。Bonesは国際版のDES を付け加えた
eBonesとなり、KTH（ストックホルム王立研究所）でKTH-KRBとして改良されて
きました。最新のバージョンは5です。2000年に米国政府が輸出規制緩和政策
を発表してから、Microsoft Windows2000とRedHat Linux には、MIT
Kerberos5がバンドルされています。現在、KTHでもKerberos5の国際版である
Heimdalの開発が進んでいます[*]。
[*] http://204.193.246.62/public.nsf/docs/60D6B47456BB389F852568640078B6C0
[*] http://www.microsoft.com/windows2000/techinfo/howitworks/security/kerberos.asp
[*] http://www.jp.redhat.com/manual/Doc71/RHDOCS/rhl-rg-ja-7.1/ch-kerberos.html
[*] http://www.pdc.kth.se/heimdal/
Kerberos 認証システムの構成は、サーバへのチケットを含む証明書を発行
する鍵発行局(KDC: Key Distribution Center)と、そのKDCが管理する複数の
クライアントおよびサーバアプリケーションを含むレルム(Realm)とからなり
ます。Kerberos ではクライアントとサーバアプリケーションを総称してプリ
ンシパル(Principals)と呼びます（図）。
+--- Realm ---------------------------------------+
| /principal \ |
| / KDC \ \(FTP Server/ |
| \(AS,TGS)/ |
| /principal \ |
| \(Telnet Server/ |
| |
| /principal \ |
| \KPOP Server/ |
| /principal\ |
| \(User) / /principal \ |
| \(CVS Server)/ |
| |
| /principal\ /principal \ |
| \(psql) / \(postmaster)/ |
| |
+-------------------------------------------------+
図 Kerberosのレルム
レルムは１つのKDCの管理領域でレルム名を持ちます。レルム名は便宜上ドメ
インネームシステム(DNS)のドメイン名を大文字で表記するのが一般的です。
名前の話のついでにプリンシパル名についても説明しておきます。各プリンシ
パルはプライマリ名、インスタンス名、レルム名からなるプリンシパル名を持
ちます。
プライマリ名.インスタンス@レルム名
のように表記されます。ユーザの場合、プライマリ名にはログイン名を使い、
インスタンスは持ちませんが、管理ユーザにはrootやadminといったインスタ
ンスを付け加えます。サービスプリンシパルの名前は、プライマリ名にサービ
ス名(/etc/servicesに登録されているような)、インスタンスにサービスが走
るマシンのホスト名を与えます。
Kerberosでは、「信頼のおける第三者機関」(Trusted Third Party)による
認証モデルをベースにパスワードのかわりにチケットを用いて認証を行ないま
すが、チケットが他人によって再利用されるのをを防ぐために
TGT:Ticket-Granting Ticket（チケット認可チケット）という、整理券のよう
なものを採用しています。TGTを身近な例で説明すると、印鑑登録証明書の交
付申請に提示する印鑑登録証のようなものです。このため、実際のKDCは、TGT
を発行する認証サーバ(AS:Authentication Server)と実際のサービスチケット
を発行するチケット認可サーバ (TGS: Ticket Granting Server)とからなりま
す。（図）
--------------------------------------------------
┌──────────────────┐
│┌───┐ ＫＤＣ ┌───┐│
││ ＡＳ │ │ＴＧＳ││
│└───┘ ,─→└───┘│
└─↑ ｜──────／──／ ────┘
(1)│ ｜(2) (3)／ ／(4)
│ ↓ ＴＧＴ ／ ／ サービスチケット
┌──────┐←─' (5)┌──────┐
│クライアント│────→│サーバ │
│(psql) │ │(postmaster)│
└──────┘ └──────┘
(1) ＴＧＴの要求
(2) ＴＧＴの入手
(3) ＴＧＴを提出してサービスチケットを要求
(4) サービスチケット入手
(5) サービスチケットを提出しサービスを要求
--------------------------------------------------
図 第三者機関による安全な認証
ここでは、KTH-KRBを使った説明をしますが、KTH-KRBについては、
http://www.rccm.co.jp/~juk/krb/
に拙訳文書もあります。
(1) KDCの設定
Kerberosを使い始めるには、まず、KDCに使うコンピュータを決めます。
Kerberosでは全てのプリンシパルの鍵をKDCにあるKerberosデータベース(KDB)
で一括管理するため、KDCにするコンピュータは絶対的なセキュリティが必要
です。KDCに使うコンピュータにKerberosをインストールしたら、構成ファイ
ルを作ります。/etc/krb.confはローカル・レルム名の定義とKerberosサーバ
の指定をし、/etc/krb.realmsはレルムに属するホストを定義します。
例えば、kdc.yokohama.jpをKDCにして、yokohama.jp ドメインのすべてのホ
ストをこのレルムに属するホストとして定義するには次のように記述します。
krb.conf:
--
YOKOHAMA.JP
YOKOHAMA.JP kdc.yokohama.jp admin server
--
krb.realms:
--
.yokohama.jp YOKOHAMA.JP
--
次に、/etc/servicesファイルにKerberosに必要なサービスの記載を追加し、
/etc/inetd.confにも適宜追加修正を行ないます。それから、KDBを初期化
(kdb_init)し、鍵をキャッシュファイルに保存(kstash)します。必要なユーザ
プリンシパルとサービスプリンシパルを登録します(kdb_edit)。あるいは、管
理ユーザを登録して、Kerberosのアクセス制御リスト(ACL)に加えておきます
(/var/kerberos/admin_acl.*)。管理ユーザを登録しておくと、いちいち、KDC
にログインしなくてもユーザ登録等の管理をkadmin コマンドから行なえます。
ここでは、後の説明のために、
jaco.admin@YOKOHAMA.JP
という管理ユーザプリンシパルを登録してあることにします。
あとは、Kerberos認証サーバとkadmind管理サーバを自動起動するようにス
クリプトを追加すれば、KDCのできあがりです。
(2) クライアントの設定
フロントエンドすなわち（たとえばpsql）を実行するホストにKerberosのを
インストールし、Kerberosの構成ファイル/etc/krb.confと/krb.realmsを設定
します。この内容はKDCの内容と同じでかまいません。次にKerberosに必要な
サービスを/etc/services に追加します。PostgreSQL を利用する場合は、次
のようにpostgresというサービスも入れておきます。
--
postgres 5432/tcp # Reserve for PostgreSQL
--
(3) サーバの設定
アプリケーションサーバをインストールするホストにもKerberosをインストー
ルし、クライアントと同じように基本的なKerberosの設定を行ないます。さら
に、サービスの鍵をサービス鍵テーブル(/etc/srvtab)に保存する必要があり
ます。たとえば、postmasterを走らせるホストをplutoとすると、ksrvutil コ
マンドを使えば次のようにサービスのKDCへの登録とサービス鍵の取得とを行
なえます。
--
# ksrvutil -p jaco.admin get
Name [rcmd]: postgres
Instance [pluto]:
Realm [YOKOHAMA.JP]:
Is this correct? (y,n) [y]
Add more keys? (y,n) [n]
Password for jaco.admin@YOKOHAMA.JP:
Added postgres.pluto@YOKOHAMA.JP
Old keyfile in /etc/srvtab.old.
--
こうして、srvtabファイルを設定できましたが、ここで、postmasterがオペレー
ティングシステムのroot権限ではなくpostmaster の実行ユーザと同じアカウ
ントで実行されることに注意しなくてはなりません。すなわち、/etc/srvtab
ファイルは所有者のみアクセス可能な600のファイルパーミッションで作られ
るため、postmasterには読むことができないということです。これを解決する
ためには、/etc/srvtabをPostgreSQL管理ユーザのグループに属性を変え、グ
ループに読出しの許可を与えます。たとえば、そのグループを postgres とす
ると、
--
# chgrp postgres /etc/srvtab
# chmod g+r /etc/srvtab
# ls -l /etc/srvtab
-rw-r----- 1 root postgres ... /etc/srvtab
--
のようにファイル属性を変更しておきます。
● PostgreSQLのHBAの設定
PostgreSQLのアクセス制御ファイル($PGDATA/pg_hba.conf)の設定をします。
次の例は、
1) UNIXドメインソケット経由はオペレーティングシステムのローカ
ルユーザ名と同じデータベースへ、
2) INETドメインソケット経由のアクセスはローカルネットワーク
（ここでは、192.168.1.0/ 255.255.255.0）から crypt 認証で全
てのデータベースへ、
3) SSLソケット経由のアクセスはどこからでもKerberos4認証で、と
いう条件で作ってみました。
pg_hba.confの例
--
local sameuser trust
host all 192.168.1.0 255.255.255.0 crypt
hostssl all 0.0.0.0 0.0.0.0 krb4
--
postmasterを起動する際に -i と -l オプションを忘れないようにしましょ
う。もしくは、同等の記述を$PGDATA/postgresql.confにしておきます。
● psqlでのアクセス
psqlからアクセスする際に、認証は HBA の記述にしたがって自動的に切り
替わります。Kerberos 認証を使うための特別のオプションは不要になってい
ます。ただし、Kerberos認証を行なう際は、psqlプログラムを実行する前に
kinit かkauthコマンドでTGTを取得しておきます。その後は、8時間以内(デフォ
ルト)はパスワードを再び入力する必要もなく、何度でも接続を行なえます。
チケットの様子を見るために時々klistコマンドを実行してみて下さい。最後、
その日の作業が終了したときには、kdestroyコマンドですべてのチケットを破
棄しておくように心がけましょう。もうひとつ、Kerberosの世界ではホストマ
シン同士の時間の同期も必要です。時刻のずれが５分(デフォルト)以内になる
よう、定期的に同期をとるようにしましょう。図.はSSLセッションでKerberos
認証をした例ですが、Kerberos認証を行なったことはklistコマンドチケット
の状態を見て確認できます。
図. SSLセッションでのKerberos認証の例
--
earth$ psql -h pluto
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
SSL enabled connection. Chiper: DES-CBC3-SHA, bits: 168
jaco=# \q
earth$ klist
Ticket file: /tmp/tkt1037
Principal: juk@YOKOHAMA.JP
Issued Expires Principal
Sep 19 09:00:07 Sep 19 19:00:07 krbtgt.YOKOHAMA.JP@YOKOHAMA.JP
Sep 19 08:58:30 Sep 19 18:58:30 postgres.pluto@YOKOHAMA.JP
--
● まとめ
SSLとKerberosを使って安全で使い勝手の良いPostgreSQLのセキュリティに
ついて述べてきましたが、Kerberosの導入はやはりハードルが高いと思わせて
しまったかもしれません。しかし、PostgreSQLだけでなく、その他のサービス
も同じKerberos認証にすると、ユーザにとって使い勝手が良くなるだけでなく、
管理者も最初のハードルさえ乗り越えれば、管理の手間が少なくて済むように
なります。今回は、KTH-KRBというKerberos4を材料に説明をしましたが、今後、
Windows 2000やRedHat Linuxなどを含めたレルムの構築を考えるにあたって
Kerberos5は非常に興味があります。KTHでもHeimdalというKerberos5が開発中
で入手可能ですので、興味ある方は是非触ってみて下さい。
そんな折、シンクラボという会社がKerberosのメーリングリストを立ち上げ
てくれました。参加の仕方は、http://www.sync-labo.co.jp/ から参照できる
「Kerberos認証」のページにあります。これから、面白くなりそうなKerberos
について、是非お話をしましょう。
参考文献
「PostgreSQL7.1日本語マニュアル」、http://osb.sra.co.jp/PostgreSQL/Manual/
"KTH-KRB Kerberos4 from KTH", Johan Danielsson and Assar Westerlund
「PostgreSQLのインストール」OPEN DESIGN 2001-08, p18, 稲葉香理（CQ出版）
「KERBEROSネットワーク認証システム」、ブライアン・タン（ピアソンエデュケーション）、ISBN：4-89471-146-X