2017年5月24日水曜日

PostgreSQL の認証とその性能

PostgreSQL の認証システムはバージョンによって大きな変更はありませんが、少しずつ強化されてきました。今回はサポートされる認証方式の特徴と比較的よく利用される認証方式の性能を簡単に紹介します。

■ PostgreSQL 認証の基本

PostgreSQL の認証はデータベースクラスタディレクトリ内にある pg_hba.conf によって行います。基本的な形式は


local      DATABASE  USER  METHOD  [OPTIONS]
host       DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
hostssl    DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
hostnossl  DATABASE  USER  ADDRESS  METHOD  [OPTIONS]

のような形式です。今回は設定方法などは詳しく解説しないので、詳しくは 第 19章クライアント認証(https://www.postgresql.jp/document/9.4/html/client-authentication.html)を参照してください。

最も単純な trust 認証の場合で、ローカルユーザに全てのデータベースへのアクセスを許可する場合は以下のようにします。


local   all  all   trust

この設定の場合、ローカルユーザはデータベース管理者ユーザ(スーパーユーザ)を含む全ての PostgreSQL ユーザとして全てのデータベースを利用できます。サーバのセキュリティが十分に確保されていない場合、セキュリティ的に脆弱な設定となるので注意が必要です。複数のユーザ/データベースを切り替えて利用する開発用のシステムなどではこの設定が便利です。

■ PostgreSQL 9.4 と 8.0 の認証方式

現在では PostgreSQL 8.0 はサポートされていないバージョンですが、どのような認証方式をサポートしていたのか比較の為に利用します。PostgreSQL 9.4 では以下の認証方式がサポートされています。

  • trust 認証
  • パスワード認証
  • GSSAPI 認証
  • SSPI 認証
  • Ident 認証
  • Peer 認証
  • LDAP 認証
  • RADIUS 認証
  • 証明書認証
  • PAM 認証

PostgreSQL 8.0 との比較では、以下の認証方式が追加されています。

  • GSSAPI 認証
  • SSPI 認証
  • Peer 認証
  • LDAP 認証
  • RADIUS 認証
  • 証明書認証

PostgreSQL 8.0 では GSSAPI 相当の Kerberos 認証がサポートされています。追加された認証方式から主に外部認証システムの認証情報を利用する方式が追加されていることが分かります。

各認証方式の概要

  • trust 認証|接続できるユーザに対して任意のユーザ名でデータベースに接続する。
  • パスワード認証|パスワードによる認証を行う。MD5 ハッシュと平文のどちらかが利用できる。
  • GSSAPI 認証|RFC 2743 の認証方式。RFC 1964 の Kerberos 認証での GSSAPI が利用できる。
  • SSPI 認証|シングルサインオンで安全な認証を行うための Windows の技術です。
  • Ident 認証|OS の ident 認証システムのユーザ名を用いて認証します。
  • Peer 認証|カーネルからクライアント上のオペレーティングシステムのユーザ名を取得し認証します。
  • LDAP 認証|認証に LDAP サーバを利用しパスワードを確認します。
  • RADIUS 認証|認証に RADIUS サーバを利用しパスワードを確認します。
  • 証明書認証|認証に SSL クライアント証明書を利用します。
  • PAM 認証|認証に PAM(Linux などで利用可能)を利用します。

各認証方式のセキュリティ

  • trust 認証|システムにアクセスできることが認証の代わりとなる。セキュリティ的には弱い。
  • パスワード認証|パスワード認証には MD5 ハッシュを用いて安全性を向上可能だが、セキュリティ的に強いとは言えない。
  • GSSAPI 認証|Kerberos 認証であるためセキュリティ的には強い。
  • SSPI 認証|Kerberos 認証の場合はセキュリティ的には強い。NTLM の場合はより脆弱になる。
  • Ident 認証|特定のユーザ ID でシステムにログインできることが認証の代わりとなる。セキュリティはシステムログインのセキュリティに依存する。
  • Peer 認証|Peer 認証は Ident 認証同様だがローカル接続でのみ利用可能である点が Ident 認証よりセキュリティ的には強い。
  • LDAP 認証|パスワード認証と同等。
  • RADIUS 認証|パスワード認証と同等。
  • 証明書認証|PostgreSQL がサポートする方式で最も強固な認証方式。
  • PAM 認証|Ident 認証と同等。

認証方式以外にクライアントとサーバの通信に SSL を利用しているかどうかもセキュリティ的には重要です。平文の場合、パスワード認証を利用するとネットワーク上に平文のパスワードが送信されます。SSL を使っている場合は安全と言えますが、使わない場合はパスワードが盗聴されるリスクが発生します。

特定のシステムにどの認証方式を用いるかはパスワードなどを保存するデータベースの場所や認証方式の安全性、SSL 利用の有無によって決めます。そして忘れてはならないのは認証方式のオーバーヘッドです。今回は一部の認証方式の簡単なベンチマークを取得してみます。

アプリケーションを作る場合、データベース接続はプーリングして出来るだけ接続と切断を繰り返さないようにします。これはデータベースへの接続には一定のオーバーヘッドが必要だからです。

■ 認証のオーバーヘッド

簡単なベンチマークで認証方式のオーバーヘッドを計測します。ベンチマークには

  • - Fedora 22 64 bit
  • - PHP 5.6 (Fedora パッケージ)
  • - PostgreSQL 9.4(Fedora パッケージ)
  • - Apache Web Server 2.4(Fedora パッケージ)

を利用します。

ベンチマークにはデータベースに接続して切断するだけの PHP スクリプトを利用します。$connect_string には各認証方式に適切な文字列を設定します。

ベンチマークスクリプト(pgtest.php)


<?php
$connect_string = 'それぞれの接続文字列';
$db = pg_connect($connect_string);
pg_close($db);

これを Apache Web Server のドキュメントルートに配置し ab コマンドを使って性能を比べます。

Apache Web Server から PostgreSQL 9.4 サーバへの接続には UNIX ドメインソケットを利用しています。

LDAP サーバはローカルネットワークの LDAP サーバを利用しています。

■ ベンチマーク

ab コマンドは以下のように実行します。


ab -c 35 -n 20000 http://localhost/pgtest.php

データベース接続のオーバーヘッドを見るために空の PHP スクリプトも実行し、ベンチマークします。ab コマンドの出力は Request per second のみ利用します。

ベンチマーク結果


空の PHP ファイル|15325.75 [#/sec]
Trust 認証|1226.96 [#/sec]
Peer 認証|1225.96 [#/sec]
パスワード認証|1222.02 [#/sec]
LDAP 認証|1216.26 [#/sec]

今回のテスト環境では、Trust/Peer/パスワード/LDAP 認証で大きな違いは確認できませんでした。違いは誤差といえる差です。しかし、PostgreSQL の認証にはかなりのオーバーヘッドがある事が分かります。

ベンチマークスクリプトに若干の変更を加え、コネクションプーリングを利用するように pg_connect() を pg_pconnect() に変更します。

ベンチマークスクリプト(pgtestp.php)


<?php
$connect_string = 'それぞれの接続文字列';
$db = pg_pconnect($connect_string);

この場合のベンチマーク結果は以下の通りです。

ベンチマーク結果


Trust 認証|14613.87 [#/sec]
Peer 認証|14582.67 [#/sec]
パスワード認証|14777.83 [#/sec]
LDAP 認証|14415.60 [#/sec]

ベンチマーク結果には多少のばらつきがありますが誤差の範囲内です。

接続がプールされていない状態、つまり最初のリクエストでは接続の為のオーバーヘッドが必要なので空の PHP ファイルに比べ若干パフォーマンスが落ちていますが、コネクションプーリングを利用した場合の性能は十分と言えます。

■ まとめ

よく利用される PostgreSQL の認証では、認証システム/サーバがボトルネックになっていなければ性能的にはあまり違いないようです。Trust 認証と他では少しは目に見える差が発生するのでは?と予想していたので意外でした。今回はクライアント証明書による認証は試しませんでしたが、証明書の確認によるオーバーヘッドは無視できない可能性が高いです。証明証認証のオーバーヘッドは別の機会に検証したいと思います。

どの認証方式を使っても PostgreSQL サーバへの接続のオーバーヘッドは無視できません。認証方式には必要とされる認証を選び、コネクションプーリングを利用した方が良いことが今回のベンチマークから分かります。

今回はそれぞれの認証方式の特徴や設定方法を詳しく解説していません。詳しくは参考 URL をご覧ください。

参考 URL

https://www.postgresql.jp/document/9.4/html/client-authentication.html

https://www.postgresql.jp/document/9.4/html/auth-methods.html

0 件のコメント:

コメントを投稿