PostgreSQL データベースにおけるトータル・セキュリティー

先制攻撃に対する事前対策

最近の Web ベースのアプリケーションで何よりも大きな問題となっているのは、データベースのセキュリティーです。データベースをしっかりと管理していなければ、自社の機密情報漏洩の危険が生じるだけでなく、さらに悪い場合には重要な顧客の機密情報漏洩の危険が生じることにすらなりかねません。この記事を読んで、PostgreSQL データベースを保護するために適用できるセキュリティー対策を学んでください。

Robert Bernier, PostgreSQL Business Intelligence Analyst, Medio Systems

Robert Bernier は、新しい媒体検索技術を先導する会社、Medio Systems のPostgreSQL ビジネス・インテリジェンス・アナリストです。彼は、携帯電話、ウォール・ストリート、科学研究センター、米国防衛省の請負業者、米国アイビー・リーグおよび大学の IT 部門など、さまざまな業界のリーダーの PostgreSQL コンサルタントを務めました。PostgreSQL の擁護者である彼は、Sys-Admin、Hakin9、PHP Solutions だけでなく、PHPbuilder.com、PHP Magazine、Linux Weekly News、O’Reilly Web ポータルをはじめとするオンライン・サイトでも執筆活動を行っています。また、『BSD Hacks』および『Multimedia Hacks』の 2 冊にも貢献しました。彼は、世界中の会議や見本市、トレーニング・セッションで PostgreSQL の素晴らしい機能を紹介するために使われている pg-live (http://pg-live.info) の保守者でもあります。



2009年 11月 17日

はじめに

クラッカーが企業のデータベースにアクセスしたという報道はよく目にしますが、クラッキングのほとんどを思春期前の若者が作成していた時代はもはや過去のものです。今やデータ収集は大きなビジネスとなっており、企業というインフラストラクチャーの中では専任のエキスパートがこの問題に取り組んでいるほどです。問題は、不正なアクセスをどのように防ぐかではありません (不正なアクセスは防ぎようがありません)。不正なアクセスが行われたときに、その影響をどれだけ小さくできるかということです。

定義

ハッカー — ハッカーは、通常では真似できないまでのレベルで技術を理解することによって、情報を調査し、照会し、探り出します。仲間うちでハッカーと呼ばれるのは名誉なことです。それは、悪いことをしているという意味からではなく、類まれなる専門知識を持っていることを意味するからです。

クラッカー — 荒らし行為、クレジット・カード詐欺、なりすまし、著作権侵害などの違法行為を目的とした悪意のあるハッカーのことです。

この記事では、PostgreSQL (別名 Postgres) データベース・サーバーの保護という難題を取り上げます。PostgreSQL は強力なオープンソースのオブジェクト・リレーショナル・データベース・システムで、そのアーキテクチャーには信頼性、データ保全性、そして正確さにおいて定評があります。Linux®、UNIX®、Windows® をはじめとする主要なオペレーティング・システムのすべてで実行できる PostgreSQL は ACID に完全に準拠しており、外部キー、結合、ビュー、トリガー、そしてストアード・プロシージャーを (複数言語で) 完全にサポートします。

この記事で使用するサンプル・コードは必ずダウンロードしてください。


理想的なアドミニストレーター

UNIX の壮大な伝統のなか、PostgreSQL はそのすべてにおいて UNIX を補完するように設計されました。そんな PostgreSQL の持てる限りの力を利用するには、平均的なデータベース管理者 (DBA) に通常期待される以上の知識が必要です。

手短に言うと、理想的な PostgreSQL の DBA には以下のバックグラウンドが求められます。

  • リレーショナル理論について豊富な知識を持ち、SQL-92、SQL-99、および SQL:2003 のそれぞれに精通していること。
  • ソース・コード (できれば C) を読むことができ、Linux でソース・コードをコンパイルできること。
  • システムを管理する能力を持ち、System-V の UNIX または Linux を使い慣れていること。
  • IT 関連の専門店に通常置かれているような各種のハードウェア商品を必要に応じて保守できること。TCP の OS 層を理解し、ネットワークのサブネット化、ファイアウォールのチューニングなどに対応できること。

多くの DBA は、データベース自体を管理し、監視し、調整するスキルしか持っていません。けれども PostgreSQL は OS のユーティリティーにも依存するように作成されています。上記の分野すべてに優れた DBA は稀な存在ですが、PostgreSQL の DBA にとっては、OS のユーティリティーに関する知識を身につけることが、より短い時間でより多くのことを達成する手段となります。


アクセス特権について

考え得る攻撃経路を理解しようと思ったら、データベースのロールが実行可能な内容について知ることが最も重要なことです。データへのアクセスを制御するにはまず、ロールに対してアクセス権を付与したり、無効にしたりしなければなりません。

ロール、そして権限および特権の付与

デフォルトの権限および特権を持つ一般のロールはどれほど安全なのでしょうか。ユーザー・アカウントを作成するには、以下のコマンドのいずれかを使用することができます。

  • SQL 文の CREATE USER
  • SQL 文の CREATE ROLE
  • Postgres コマンドライン・ユーティリティーの createuser

ユーザー・アカウントを作成する上記 3 つの方法の振る舞いはそれぞれに異なり、デフォルトの権限および特権はまったく違った内容になります。

一般のロールを持つユーザーは通常、以下の操作を実行することができます。

  • 任意のデータベースにアクセスする (データ・クラスターが pg_hba.conf に記述されたデフォルトの認証ポリシーを使用する場合)。
  • アクセス可能な任意のデータベースの PUBLIC スキーマにオブジェクトを作成する。
  • 一時セッションでセッション (一時) オブジェクトを作成する (スキーマ pg_temp_? など)。
  • ランタイム・パラメーターを変更する。
  • ユーザー定義関数を作成する。
  • 他のユーザーが PUBLIC スキーマに作成したユーザー定義関数を実行する (ただしそのユーザー定義関数が、その関数を使用しようとするユーザーにアクセス特権が与えられたオブジェクトだけを使用して対話する場合)。

ユーザーに許可される操作を知るのは重要ですが、それと同じく、一般ユーザーがデフォルトでは実行できない操作を理解することも重要です。以下の操作は一般ユーザーには許可されません。

  • データベースやスキーマを作成する。
  • 他のユーザーを作成する。
  • 他のユーザーが作成したオブジェクトにアクセスする。
  • ログインする (CREATE ROLE 文の場合のみ)。

スーパーユーザーの権限および特権

一般ユーザーはスーパーユーザーの機能として定義された権限および特権を行使することはできませんが、一般ユーザーでも、デフォルトの権限および特権によってかなりの面倒を起こすことができます。

このセクションでは、一般ユーザーが操ることのできる攻撃経路について説明します。

オブジェクトにアクセスする

極めて一般的で、しかも安全でない方法は、PostgreSQL を Web サーバーへのバックエンドとして使用することです。開発者は、INSERTUPDATE、および DELETE コマンドだけを使用してデータを操作させる意図で一般ユーザーを作成しますが、一般ユーザーでも、権限を与えられていないアクションを実行することは不可能ではありません。それは、PUBLIC スキーマは誰でも利用できるためです。例えばユーザーは、PUBLIC スキーマのテーブルに対してデータ・マイニングをすることができます。さらに、PUBLIC スキーマのテーブルにルールやトリガーを追加したり、データを保存したりしてテーブルを変更することすら可能であり、そうして変更したテーブルを利用することができます。

忘れてならないのは、セキュリティーが侵害されたユーザー・アカウントを通じて、そのユーザー・アカウントが所有するオブジェクトに対してあらゆる操作を実行できるという事実です。

この脅威に対抗するのは簡単で、一般ユーザー・アカウントには何も所有させたり、作成させたりしなければよいだけの話です。リスト 1 に、テーブルをセキュアにする方法を示します。

リスト 1. テーブルをセキュアにする
postgres=# SET SESSION AUTHORIZATION postgres;
SET
postgres=# CREATE ROLE user1 WITH LOGIN UNENCRYPTED PASSWORD '123';
CREATE ROLE
postgres=# CREATE SCHEMA user1 CREATE TABLE t1(i int);
CREATE SCHEMA
postgres=# INSERT INTO user1.t1 VALUES(1);
INSERT 0 1
postgres=# GRANT USAGE ON SCHEMA user1 TO user1;
GRANT
postgres=# SELECT I FROM user1.t1;
 i
---
 2
(1 row)

postgres=# SET SESSION AUTHORIZATION user1;
SET
postgres=> SELECT I FROM user1.t1;
ERROR:  permission denied for relation t1
postgres=> SET SESSION AUTHORIZATION postgres;
SET
postgres=# GRANT SELECT ON user1.t1 TO user1;
GRANT
postgres=# SET SESSION AUTHORIZATION user1;
SET
postgres=> SELECT I FROM user1.t1;
 i
---
 2
(1 row)

リスト 2 に、PUBLIC スキーマへのアクセスを禁止する例を示します。

リスト 2. user1 のロールがエンティティーを作成できないようにする
postgres=> SET SESSION AUTHORIZATION postgres;
SET
postgres=# REVOKE ALL PRIVILEGES ON SCHEMA PUBLIC FROM user1;
REVOKE
postgres=# SET SESSION AUTHORIZATION user1;
SET

The error message of "ERROR:  permission denied for schema user1" means that this 
   defensive measure works:

postgres=> CREATE TABLE X();
ERROR:  permission denied for schema user1

他のユーザーの制御下にあるオブジェクトにアクセスする

リスト 3 に示す攻撃経路は、ユーザーが PUBLIC スキーマへのアクセス権を持っていることを前提とします (例えば、GRANT USAGE ON SCHEMA PUBLIC TO user1)。この攻撃は以下の仮定の下、功を奏します。

  • デフォルトでは、すべてのユーザーにクラスター内の任意のデータベースへの接続が許可されること。
  • 配置されたクラスターではユーザーに、PUBLIC スキーマでの新規エンティティーの作成およびすべてのエンティティーの操作が許可されること。
  • 一般ユーザー・アカウントにはシステム・カタログへのアクセス権があること。そうでなければ、ユーザー・アカウントが適切に機能しないこと (PostgreSQL サーバーの振る舞いに本質的に関連)。
リスト 3. テーブルに関する情報を収集する
postgres=> SELECT * FROM user1.t2;
ERROR:  permission denied for relation t2
postgres=> insert into user1.t2 values(10);
ERROR:  permission denied for relation t2
postgres=>
postgres=> \d
        List of relations
 Schema | Name | Type  |  Owner
--------+------+-------+----------
 user1  | t1   | table | postgres
 user1  | t2   | table | postgres
(2 rows)

postgres=> \d t?
        Table "user1.t1"
 Column |  Type   | Modifiers
--------+---------+-----------
 i      | integer |

        Table "user1.t2"
 Column |  Type   | Modifiers
--------+---------+-----------
 i      | integer |

一般ユーザーはテーブルにはアクセスできないものの、テーブルに関する情報を集めることはできます。

リスト 4 では、ユーザー・アカウント user1 が、ユーザー・アカウントのリストとそれぞれのプロパティーを取得しています。一般ユーザーは、パスワード自体にはアクセスすることができません。

リスト 4. ユーザー・アカウントのプロパティーを取得する
postgres=> select * from pg_user;
 usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
----------+----------+-------------+----------+-----------+----------+----------
postgres | 10 | t | t | t | ******** | |
 user1 | 18770 | f | f | f | ******** | |
(2 rows)

このように、すべてのユーザーはデフォルトで、クラスターの定義とスキーマを調べられるようになっています。

リスト 5 は、システム・カタログに対してクエリーを実行することで、クラスター全体の定義スキーマに関する情報を収集するスクリプトです。この脅威は、スーパーユーザーがシステム・カタログを変更 (あるいはハッキング) することによって軽減することができます。

リスト 5. クラスター全体の定義を抽出する
#!/bin/bash
psql mydatabase << _eof_
set search_path=public,information_schema,pg_catalog,pg_toast;
\t
\o list.txt
SELECT n.nspname||'.'||c.relname as "Table Name"
FROM pg_catalog.pg_class c
 JOIN pg_catalog.pg_roles r ON r.oid = c.relowner
 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','')
ORDER BY 1;
\q
_eof_

for i in $( cat list.txt ); do
 psql -c "\d $i"
done

ユーザー定義関数を作成してアクセスする

関数は信頼できる言語による関数か、信頼できない言語による関数かのどちらかです。信頼できる手続き型言語は、データベースのコンテキスト内で命令 (テーブルや索引の作成、データの追加や削除など) を実行します。信頼できない手続き型言語は、信頼できる手続き型言語による機能を実行できるだけでなく、データベース外部にも働きかけることが可能です。例えば、ディレクトリーの内容を表示したり、ファイルを作成または削除したりするなどです。あるいはシステム・プロセスを呼び出すことや、さらには他のホストに対するソケット接続を作成することもできます。

リスト 6. 手続き型言語をデータベースに追加して user1 が再びアクセスできるようにする
postgres=# create language plpgsql;
CREATE LANGUAGE
postgres=# create language plperlu;
CREATE LANGUAGE
postgres=# create language plperl;
CREATE LANGUAGE
postgres=> SET SESSION AUTHORIZATION postgres;
SET
postgres=# GRANT USAGE ON SCHEMA PUBLIC TO user1;
GRANT
リスト 7. 信頼できる手続き型言語と信頼できない手続き型言語
postgres=# select lanname as language, lanpltrusted as trusted from pg_language;
 language | trusted
----------+---------
 internal | f
 c        | f
 sql      | t
 plperlu  | f
 plperl   | t
(5 rows)

テーブルとは異なり、他のユーザーの関数を呼び出す際には、一般ユーザー・アカウントに特別な許可は必要ありません。これは、ユーパーユーザーによって作成された関数を呼び出す場合にも当てはまります。

リスト 8. スーパーユーザーの関数を呼び出す
postgres=# SET SESSION AUTHORIZATION postgres;
SET
postgres=# CREATE OR REPLACE FUNCTION public.f1 (
postgres(# OUT x text
postgres(# ) AS
postgres-# $body$
postgres$# select 'hello from f1()'::text;
postgres$# $body$
postgres-# LANGUAGE SQL;
CREATE FUNCTION
postgres=# SET SESSION AUTHORIZATION user1;
SET
postgres=>
postgres=> SELECT * FROM f1();
 x
-----------------
 hello from f1()
(1 row)

リスト 9 に記載する関数は、スーパーユーザーが plperlu (信頼できない手続き型言語) を使用して作成したものです。この関数はディレクトリーの内容を返す関数ですが、user1 でもこの関数を呼び出すことができます。一般ユーザーが信頼できる関数と信頼できない関数の両方を呼び出すことができるという脅威を軽減するのに最善の方法は、一般ユーザーの特権を無効にして関数へアクセスできないようにすることです。

リスト 9. 権限のないユーザーによる関数の不正利用
postgres=> SET SESSION AUTHORIZATION postgres;
SET
postgres=# CREATE OR REPLACE FUNCTION public.f2 (
postgres(# OUT x text
postgres(# ) AS
postgres-# $body$
postgres$# # output the root directory contents into standard output
postgres$# # notice the use of the single back ticks
postgres$# $a = `ls -l / 2>/dev/null`;
postgres$# $message = "\nHere is the directory listing\n".$a;
postgres$# return $message;
postgres$# $body$
postgres-# LANGUAGE PLPERLU;
CREATE FUNCTION
postgres=# SET SESSION AUTHORIZATION user1;
SET
postgres=> SELECT * FROM f2();
 x
----------------------------------------------------------------------------

 Here is the directory listing
 total 120
 drwxr-xr-x 2 root root 4096 Aug 29 07:03 bin
 drwxr-xr-x 3 root root 4096 Oct 11 05:17 boot
 drwxr-xr-x 3 root root 4096 Nov 26 2006 build
 lrwxrwxrwx 1 root root 11 Aug 22 2006 cdrom -> media/cdrom
 drwxr-xr-x 15 root root 14960 Oct 12 07:35 dev
 drwxr-xr-x 118 root root 8192 Oct 12 07:36 etc
(1 row)
リスト 10. user1 とグループ PUBLIC に対する保護
postgres=# SET SESSION AUTHORIZATION postgres;
SET
postgres=# REVOKE ALL ON FUNCTION f2() FROM user1, GROUP PUBLIC;
REVOKE
postgres=# SET SESSION AUTHORIZATION user1;
SET
postgres=> SELECT * FROM f2();
ERROR: permission denied for function f2
postgres=>

リスト 11 には、機密情報の収集が関わってきます。

リスト 11. 関数のソース・コードを取得する
postgres=> SET SESSION AUTHORIZATION user1;
SET
postgres=> select prosrc as "function f3()" from pg_proc where proname='f3';

 function f3()
---------------
# output the root directory contents into standard output
# notice the use of the single back ticks
 $a = `ls -l / 2>/dev/null`;
 $message = "\nHere is the directory listing\n".$a;
 return $message;
(1 row)

ソース・コードを隠すには、以下の方法があります。

  • 関数をモジュールとしてそのネイティブ言語環境 (C、Perl、Python など) で作成し、ホストのハード・ドライブに保管します。その上で、このモジュールを呼び出すための、抽象化されたユーザー定義関数を PostgreSQL で作成します。
  • ソース・コードをテーブル内に作成し、必要に応じて動的に関数を作成することを検討します。
  • ユーザー定義関数をクラスター内の別のデータベースに作成し、権限を付与されたユーザー・アカウントが dblink モジュールを使用してその関数を呼び出すようにします。

SECURITY DEFINER を使用する

SECURITY DEFINER は、関数を作成したユーザーの特権を使用して、その関数を実行します。したがって、ユーザーは通常では使用できないテーブルにでもアクセスすることができます。

例えばリスト 12 に示すように、スーパーユーザー postgres が Postgres スキーマに 2 つの列を持つテーブルを作成したとします。一般ユーザー user1 は SECURITY DEFINER パラメーターを使って関数を呼び出し、入力値に基づく値を取得します。

リスト 12. テーブルと関数の作成
postgres=# SET SESSION AUTHORIZATION postgres;
SET
postgres=# CREATE TABLE postgres.t4(x serial,y numeric);
NOTICE: CREATE TABLE will create implicit sequence "t4_x_seq" for serial column "t4.x"
CREATE TABLE
postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));
INSERT 0 1
postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));
INSERT 0 1
postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));
INSERT 0 1
postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));
INSERT 0 1
postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));
INSERT 0 1
postgres=# CREATE OR REPLACE FUNCTION public.f4 (
postgres(# IN a int,
postgres(# OUT b numeric
postgres(# ) RETURNS SETOF numeric AS
postgres-# $body$
postgres$# select y from postgres.t4 where x=$1 limit 1;
postgres$# $body$
postgres-# LANGUAGE SQL SECURITY DEFINER;
CREATE FUNCTION

リスト 13 に示すように、ユーザー・アカウント user1 は目的とする情報にアクセスできるようになります。

リスト 13. 関数呼び出しによってテーブルにアクセスする非特権ロール
postgres=# SET SESSION AUTHORIZATION user1;
SET
postgres=> SELECT b as "my first record" FROM f4(1);
 my first record
-----------------
 0.379
(1 row)

postgres=> SELECT b as "my second record" FROM f4(2);
 my second record
------------------
 0.200
(1 row)

PostgreSQL パスワードのクラッキング

DBMS では、効果的なパスワード管理がセキュリティーの鍵となります。承認されたパスワード・ポリシーを強制するのは DBA の仕事です。パスワードは、パターンが認識できないように任意に選択された英数字で構成されていなければなりません。一般的な慣例では、パスワードは 6 文字以上で構成し、頻繁に変更することが求められます。

PostgreSQL のユーザー・アカウントとパスワード

PostgreSQL ユーザー・アカウント・セキュリティー・ポリシーの中心となるのは、ユーザーのアカウントを作成および管理する以下の SQL コマンドです。

  • CREATE ROLE
  • ALTER ROLE
  • DROP ROLE

以下の SQL 文は、旧式のユーザー・アカウント管理に属します (これらの文も有効ですが、ユーザーをロールとして管理する新しい手法を使用してください)。

  • CREATE GROUP
  • ALTER GROUP
  • DROP GROUP
  • CREATE USER
  • ALTER USER
  • DROP USER

パスワードは暗号化されずに保管されるか、暗号化して保管されます。暗号化されないパスワードは平文のまま保管され、スーパーユーザーが読み取ることができます。パスワードを暗号化するには、パスワードの MD5 ハッシュを生成して保管する必要があります。MD5 ハッシュは解読することができません。ログイン時にパスワードの妥当性を確認するには、ハッシュ関数によってパスワードを暗号化し、それをデータ・クラスターに保管されているデータと比較します。

以下は、パスワードを作成および管理する場合の呼び出しの例です。

  • パスワードを設定せずにアカウントを作成する場合:

    CREATE ROLE user1 WITH LOGIN;

  • 暗号化されていないパスワードを設定してアカウントを作成する場合:

    CREATE ROLE roger WITH LOGIN UNENCRYPTED PASSWORD '123'

  • アカウントを変更して暗号化されたパスワードを割り当てる場合:

    ALTER ROLE user1 WITH ENCRYPTED PASSWORD '123'

スーパーユーザーがカタログ・テーブル pg_shadow に対して SQL クエリーを実行すると、ユーザーのアカウント名とパスワードが返されます。このコードをリスト 14 に記載します。

リスト 14. カタログからユーザーのパスワードを取得する
postgres=# select usename as useraccount,passwd as "password" from pg_shadow where
length(passwd)>1 order by usename;

 useraccount | password
-------------+-------------------------------------
 user1 | md5173ca5050c91b538b6bf1f685b262b35
 roger | 123
(2 rows)

リスト 15 に、パスワードが 123 に設定された user1 の MD5 ハッシュを生成する方法を示します。

リスト 15. MD5 パスワードを生成する
postgres=# select 'md5'||md5('123user1') as "my own generated hash", 
                  passwd as "stored hash for user1"  
           from pg_shadow where usename='user1';

 my own generated hash | stored hash for user1
-------------------------------------+-------------------------------------
 md5173ca5050c91b538b6bf1f685b262b35 | md5173ca5050c91b538b6bf1f685b262b35
(1 row)

ここに、もう 1 つの恐ろしい事実があります。それは、鉄壁のように強固なパスワード・ポリシーを強制できるメカニズムは、PostgreSQL にはほとんどないという事実です。

セキュリティー上の制約としては以下の内容が考えられます。

  • スーパーユーザーは、パスワードに使用する最小文字数を強制することはできません。
  • 構成設定には、パスワードの保管方法 (暗号化しないで保管するか、MD5 ハッシュとして暗号化して保管するか) に関するデフォルト・パラメーターがありますが、スーパーユーザーがユーザーに対し、特定の保管方法を使用するように強制することはできません。
  • ユーザー・アカウントに有効期間を設けるためのメカニズムはありません。
  • クラスターのクライアント認証構成ファイル pg_hba.conf で接続方法が PASSWORD または MD5以外に設定されている場合、ユーザー・アカウントのパスワードの有効期間を制御するメカニズムは無効になります。
  • スーパーユーザーまたは postgresql.conf ファイルでデフォルト構成設定によって設定されたユーザー・ランタイム・パラメーターが ALTER ROLE 文によって変更されると、ユーザー・アカウントの所有者が自由にこのパラメーターを変更できるようになります。
  • ユーザー・アカウントのパスワードが暗号化されている場合、ユーザー・アカウントの名前が変更されるとパスワードが消去されます。
  • ユーザー・アカウントを誰が変更したかも、ユーザー・アカウントがいつ変更されたかも追跡することはできません。

几帳面な DBA は、データベース・システムのシステム・カタログを注意深くマメに編集することで、それだけの効果を得られるはずです。

これらのユーザー・アカウントとパスワードのセキュリティー上の制約は、悪用するには絶好のチャンスとなるため、別の記事をまるまる使って説明するだけの価値があるほどです。

パスワードをクラックする

強い型付けをされたパスワードを強制するというのは立派な目標ですが、誰かがそのパスワードをクラックするまでは、その強度を判断しようがありません。パスワードのクラッキング・ユーティリティーは、以下の 2 つの方法を基本とします。

総当たり攻撃
これは、ハッシュを系統的にテストする方法です。最初は短い文字から始め、文字数を増やしながら暗号解読を試みます。この方法は、短いパスワードに適しています。
辞書攻撃
この攻撃ではソーシャル・エンジニアリング手法を使用します。出発点は、クラッキング・ユーティリティーで使用される単語の辞書です。その後、辞書に載っている単語の組み合わせを生成し、取得したハッシュに対してテストします。この攻撃は、記憶しやすい文字列と文字の組み合わせからなる長い文字列のほうが、でたらめに選んだ文字からなる比較的短い文字列よりは安全だという誤った観念を利用します。

パスワードの強度と使用されているハードウェアによっては、ほんの数秒でパスワードをクラックできることもあれば、何ヶ月もかかる場合もあります。

DBA の関心事は、6 文字未満のパスワードを識別することです。

MDCrack というコマンドライン・ユーティリティーは、総当たり攻撃を使用してパスワードをテストします。この Windows バイナリーは、Linux でも Wine を使用すれば有効に機能します。

wine MDCrack-sse.exe --help と入力すると、構成オプションが返されます。以下に、いくつかのオプションが記載されています。

Usage: MDCrack [options...] --test-hash|hash
       MDCrack [options...] --bench[=PASS]
       MDCrack [options...] --resume[=FILENAME]|--delete[=FILENAME]
       MDCrack [options...] --help|--about

コマンドライン上で実行される最も単純なコマンドは、wine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH です。ここで、$USERNAME はユーザー名、$MD5_HASH は pg_shadow カタログ・テーブル内の MD5 ハッシュです。

MDCrack は以下のようにセッション・モードで実行できるので、クラッキング操作をいったん停止して、後から続けることもできます。

リスト 16. セッション・モードで実行中の MDCrack
# start session
wine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH\
 --session=mysessionfile.txt

# resume using the last session mode
wine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH\
 --resume=mysessionfile.txt

デフォルトの文字セットは、abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ です。このデフォルトの文字セットに含まれていない文字がパスワード候補に含まれていると、プロセスがハングすることになるので、その場合には任意の英数字の組み合わせに変更して構いません。例えば、制御文字と句読点を含めるなどです。

文字セットの調整はコマンドラインで行います。$CHARSET 変数が、実際に使用される文字セットを表します。

wine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH --charset=$CHARSET

以下に示すのは、Postgres のパスワード 123 をクラックする場合のコマンドの一例です。MD5 ハッシュ値 md5173ca5050c91b538b6bf1f685b262b35 の最初の 3 文字を無視し、コマンドライン上で以下のコマンドを実行することで、パスワードを割り出すことができます (ヒント: 文字列 Collision found を grep 検索します)。このパスワードのクラッキングにかかる時間は約 0.32 秒です。

wine MDCrack-sse.exe --algorithm=MD5 --append=user1 173ca5050c91b538b6bf1f685b262b35\
| grep "Collision found"

リスト 17 に、システム・カタログ pg_shadow 内のパスワードをクラックする例を示します。

リスト 17. パスワードをクラックする
wine MDCrack-sse.exe --algorithm=MD5 --append=user1 \
`psql -t -c "select substring(passwd,4) from pg_shadow where usename='user1';"` \
| grep "Collision found"

認証モデル

悪い事態が起こる可能性を説明したところで、今度は物事を適切に進めるために行えることを探ります。認証の話はとても広範囲にわたるので、ここではその基本についてだけ説明します。

認証が済んでいる場合、Postgres クラスターへのアクセスは以下の手段によって制御されます。

  • UNIX ドメイン・ソケット
  • Ident サーバー認証
  • LDAP サーバー認証
  • PAM
  • Kerberos
  • SSL

UNIX ドメイン・ソケット

UNIX ドメイン・ソケットとは、多くの点でファイルと似ている双方向の通信パイプのことです。サーバーはドメイン・ソケットを作成し、クライアントがファイルシステムを介してそのファイルを開くまで待機します。以下は、典型的な PostgreSQL ドメイン・ソケットの一例です。

リスト 18. 典型的なドメイン・ソケット
robert@wolf:~$ ls -la /tmp|grep PGSQL
srwxrwxrwx 1 robert robert 0 2007-10-15 12:47 .s.PGSQL.5432
-rw-------  1 robert robert   33 2007-10-15 12:47 .s.PGSQL.5432.lock

ファイル名の後にポート番号が追加されることに注意してください。サーバーを再構成して別の TCP/IP ポートに常駐させると、ドメイン・ソケットの名前も変わることになります。

postgresql.conf 構成ファイルの以下の 3 つのパラメーターが、ドメイン・ソケットのアクセス権を制御します。

  • unix_socket_directory (ファイルのパス)
  • unix_socket_group (ユーザー・グループ)
  • unix_socket_permissions (0777 にデフォルト設定)

ドメイン・ソケットが置かれる場所は、Linux ディストリビューションによって以下のように異なります。

  • PostgreSQL ソース・コードは /tmp ディレクトリーにドメイン・ソケットをインストールして保管します。
  • BSD は /tmp ディレクトリーにドメイン・ソケットを配置します。
  • RedHat 系は /tmp ディレクトリーにドメイン・ソケットを配置します。
  • Debian 系は postgresql アカウントにだけアクセス権が与えられる /var/run/postgresql にドメイン・ソケットを配置します。

ドメイン・ソケットには奇妙な点がいくつかあります。以下の例に含まれる意味合いを考えてみてください。

sudo

sudo は、ユーザーが他のユーザー (通常はスーパーユーザー、または root) のセキュリティー特権を使ってプログラムを実行できるようにする強力なコマンドで、さまざまに構成して使用することができます。これは Windows の runas コマンドに相当します。

robert (スーパーユーザー) のホーム・ディレクトリーに、認証方法を trust に設定したクラスターを作成するとします。けれどもサーバーの起動時には、ドメイン・ソケットのアクセス権は robert 以外のログインしか許可していません。

ユーザー robert が TCP を使ってログインすると、ドメイン・ソケットでログインが拒否されます。一方、robertnobody に対して sudo を実行した後は、ドメイン・ソケットを介してログインできるようになります。

以下の例は、クラッカーがスーパーユーザーになることで引き起こす損害を軽減する、ファイルへのアクセス権の多様性を明らかにしています。

リスト 19. アクセス権
robert@wolf:~$ initdb -A trust -U postgres ~/data

robert@wolf:~$ pg_ctl -D ~/data/ -l ~/logfile.txt \
-o "-c unix_socket_permissions=007 -c unix_socket_directory=/tmp" start
server starting

robert@wolf:~$ psql -h localhost -U postgres -c "select 'superuser:this works' as msg"
         msg
----------------------
 superuser:this works
(1 row)

robert@wolf:~$ psql -h /tmp -U postgres -c "select 'superuser:this fails' as msg"
psql: could not connect to server: Permission denied
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

robert@wolf:~$ sudo su nobody
[sudo] password for robert:

$ psql -h localhost -U postgres -c "select 'nobody:this works' as msg"
        msg
-------------------
 nobody:this works
(1 row)


$ psql -h /tmp -U postgres -c "select 'nobody:this still works' as msg"
           msg
-------------------------
 nobody:this still works
(1 row)

Ident

誰がポート X から接続を開始し、ポート Y に接続しているのかという単純な質問に答えるのが、Ident サーバーです。PostgreSQL サーバーのコンテキストでは、Ident サーバーが DBMS に対し、ログインを試行しているユーザー・アカウントの ID を通知します。PostgreSQL がこの答えを受け取ると、DBA が該当する構成ファイルに設定したルール・セットに従ってログインの許可を与えたり、ログインを拒否したりします。

PostgreSQL の Ident サーバー認証メカニズムは、ホスト固有の Ident サーバーを使用して PostgreSQL のユーザー・アカウントと UNIX のユーザー・アカウントをマッピングすることによって機能します。

以下の例で前提としているのは、PostgreSQL ではすべての UNIX ユーザー・アカウントが PostgreSQL のユーザー・アカウントにマッピング済みであり、PostgreSQL でのアカウント名と同じアカウント名を使用する限り、任意のデータベースにログインできるということです。ログインが失敗するのは、UNIX ユーザー名が PostgreSQL サーバーにユーザー・アカウントとして存在しない場合、あるいは別の PostgreSQL ユーザー・アカウント名を使用してログインが試行された場合です。

例えば、ホストに SSH 接続しているとします (ssh -l robert wolf)。

リスト 20. ログインの失敗および成功
robert@wolf:~$ psql -U robert robert
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

robert@wolf:~$ psql -U postgres robert
psql: FATAL:  Ident authentication failed for user "postgres"

-- This works, su to become the UNIX user account postgres

PostgreSQL は以下の 2 つのファイルを使用して、Ident サーバーによる認証済みユーザーのすべてのログイン・セッションを管理し、制御します。

pg_hba.conf
1 行で定義されたレコードを使用してアクセスを制御します。
pg_Ident.conf
Ident サービスをユーザー・アカウントの認証に使用するときに活躍します。例えば、METHOD は pg_hba.conf ファイル内で Ident として識別されます。
リスト 21. 単純な構成例
Example 1: A LOCALHOST connection enforces unix account robert to access database robert 
exclusively.  There is no authentication on UNIX domain sockets.

(pg_hba.conf)
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD    OPTION
  host    all         all         127.0.0.1/32        Ident     mymap
  local   all         all                             trust
(pg_Ident.conf)
# MAPNAME     Ident-USERNAME    PG-USERNAME
  mymap       robert            robert


Example 2: A domain socket connection enforces unix account robert to access any database 
as pg account robert; unix account postgres can access any database as user robert.

(pg_hba.conf)
# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD    OPTION
  local   all         all                             Ident     mymap
  host    all         all         127.0.0.1/32        trust

(pg_Ident.conf)
# MAPNAME     Ident-USERNAME    PG-USERNAME
  mymap       robert            robert
  mymap       postgres          robert


Example 3: A domain socket connection enforces that unix account can connect to any 
database with its postgres database namesake using the
keyword "sameuser".  pg_Ident.conf is not necessary here. Local host 
connections via TCP-IP are rejected.

(pg_hba.conf)
# TYPE  DATABASE                USER        CIDR-ADDRESS          METHOD    OPTION
  local   template0,template1    all                             Ident     sameuser
  host    all                    all         127.0.0.1/32        reject

Ex4: (all users can connect with their own user names only to the databases postgres 
and robert)

(pg_hba.conf)
# TYPE  DATABASE                USER        CIDR-ADDRESS          METHOD    OPTION
  local   template0,template1    all                             Ident     sameuser

以下の注意点に気を付けてください。

  • 構成の変更は、ファイルをリロードするのと同時に有効になります (例えば、pg_ctl -D mycluster reload)。
  • さまざまな構成設定が原因で、思うような動作にならない可能性があります。その場合はログを参照し、うまく行かない原因となっている構成メッセージを調べてください。
  • Ident が設計および実装されたのは、マシン自体がセキュアであると考えられていた頃のことです。認証を要求するリモート・サーバーはすべて怪しいと考えてください。
  • Ident サーバーはローカル・ホスト接続の認証にのみ使用されます。

データの暗号化

イントラネット内には、自分の情報をうっかりクラッカーに曝してしまう落とし穴がさまざまに潜んでいます。

試しにデータを傍受してみましょう。例えば、ローカル・ホスト (192.168.2.64) でコマンド tcpdump -i eth0 -X -s 3000 host 192.168.2.100 and port 5432 を実行するとします。

次にリモート・ホスト (192.168.2.100) で、自分のローカル・ホストの PostgreSQL サーバーに接続します。このサーバーは既にポート 5432 をリッスンしているので、コマンド psql -h 192.168.2.64 -p 5432 -U postgres postgres を実行します。ここで、スーパーユーザー・アカウント postgres のパスワードを変更するため、コマンド ALTER USER postgres WITH ENCRYPTED PASSWORD 'my_new_password'; を実行します。

リスト 22. 傍受したデータ・ダンプでパスワードを判別する
16:39:17.323806 IP wolf.56336 > laptop.postgresql: P 598:666(68) ack 470 win 3068
<nop,nop,timestamp 9740679 9589666>
 0x0000: 4500 0078 4703 4000 4006 6d88 c0a8 0264 E..xG.@.@.m....d
 0x0010: c0a8 0240 dc10 1538 6a4f 7ada 6a71 e77c ...@...8jOz.jq.|
 0x0020: 8018 0bfc 1a9d 0000 0101 080a 0094 a187 ................
 0x0030: 0092 53a2 5100 0000 4341 4c54 4552 2055 ..S.Q...CALTER.U
 0x0040: 5345 5220 706f 7374 6772 6573 2057 4954 SER.postgres.WIT
 0x0050: 4820 454e 4352 5950 5445 4420 5041 5353 H.ENCRYPTED.PASS
 0x0060: 574f 5244 2027 6d79 5f6e 6577 5f70 6173 WORD.'my_new_pas
        0x0070:  7377 6f72 6427 3b00                      sword';.

ポート転送を使用した SSH トンネル

IP 転送とは、インターネット・パケットをあるホストから別のホストに転送するトンネリング技術です。IP 転送を使うことで、psqlpgadmin、さらには openoffice などの PostgreSQL クライアントまでもが SSH 接続によってリモート Postgres サーバーに接続することができます。

ここで、以下の質問について考えてみてください。

  • リモート PostgreSQL サーバー上に psql クライアントが存在しない場合は、どうなるのでしょう?
  • 使用しているワークステーションとリモート・ホストとの間でデータをアップロード、またはダウンロードしなければならない場合は、どうなるのでしょう?
  • データベース・クライアントが、psql クライアントでは対応しきれないタスクや、psql クライアントではまったく対応できないタスクを実行できることから、そのデータベース・クライアントを使用しなければならない場合、どうすればよいのでしょう?
  • チームがファイアウォールで保護されたデータベースにリモートから接続できるようにネットワークをトンネリングする場合は、どのようにすればよいのでしょう?

上記のような場合には、クライアント (ローカル・ホスト) をリモート・ホスト (192.168.2.100) に接続し、ワークステーションのポート 10000 にプロキシー接続を作成します。ポート 10000 に接続したクライアントは、ssh -L 10000:localhost:5432 192.168.2.100 により、ポート 5432 でリッスンするリモート・ホストの PostgreSQL サーバーに転送されます。

上記のコマンドに -g オプションを追加すると (ssh -g -L 10000:localhost:5432 192.168.2.100)、他のホストも転送接続を利用できるようになるため、トンネルは Postgres 接続用の即席 VPN (Virtual Private Network) に変身します。

トンネルに関しては以下の注意事項があります。

  • データベース・クライアントとサーバーは、それぞれがローカル・ホストと通信していると思い込みます。
  • 必ず、TCP/IP を使用したローカル接続に対して適切な認証が行われるように pg_hba.conf ファイルを構成してください。
  • 1024 よりも下位のポートは、root によって排他的に制御されます。
  • SSH セッションには、PostgreSQL/SSH サーバー上に存在するユーザー・アカウントが必要です。

SSL 暗号化によるセッション

PostgreSQL との暗号化セッションでは、サーバーを --with-openssl オプションでコンパイルする必要があります。Linux distro バイナリーにはこの関数があります。psqlpgadmin などのクライアントにも暗号化セッションに必要な機能があります。

サーバーを確認するには、以下のように pg_config コマンドライン・ユーティリティーを使用します。

pg_config --configure

PostgreSQL サーバーを暗号化セッションに対応させる方法は以下のとおりです。

  1. OpenSSL コマンドライン・ツールの openssl を使用して、自己署名サーバー鍵 (server.key) と証明書 (server.crt) を作成します。
    1. サーバー鍵を作成します (openssl genrsa -des3 -out server.key 1024)。
    2. パスフレーズを削除します (openssl rsa -in server.key -out server.key)。
    3. サーバーの自己署名証明書を作成します (openssl req -new -key server.key -x509 -out server.crt)。
  2. server.key と server.crt の 2 つのファイルをデータ・クラスターのディレクトリーにインストールします。
  3. postgresql.conf ファイルを編集し、名前付きペアを設定します (ssl = on)。
  4. サーバーを再起動します。
    リスト 23. 正常に接続された SSL 暗号化セッション
    robert@wolf:~$ psql -h 192.168.2.100 -U robert
    Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
    
    Type: \copyright for distribution terms
     \h for help with SQL commands
     \? for help with psql commands
     \g or terminate with semicolon to execute query
     \q to quit
    
    SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
    
    robert=#

暗号化セッション・リクエストに対して、サーバーは常に最初に接続をテストします。ただし、このサーバーの振る舞いは、認証ファイル pg_hba.conf を編集することによって、制御することができます。クライアント・サイドで、クライアント (psql) のデフォルトの振る舞いとして暗号化セッションを使用するかどうかを制御するには、環境変数 PGSSLMODE を定義します。

SSL 暗号化に関するクライアントの振る舞いには 6 つのモードがあります (このうち 2 つの新しいモードは PostgreSQL V8.4 のみが対応しています)。

モード説明
disable暗号化されない接続のみを試行する。
allow最初に暗号化されない接続を試行し、接続できなかった場合には SSL 接続を試行する。
preferallow とは反対に、最初に SSL 接続を試行し、次に暗号化されない接続を試行する。
requireクライアントは暗号化された SSL 接続のみを試行する。
verify-caSSL 接続、および信頼できる CA によって署名が付けられた有効なクライアント証明書を使用する。
Verify-fullSSL 接続、信頼できる CA によって署名が付けられた有効なクライアント証明書を使用し、サーバーのホスト名と証明書のホスト名が一致することを条件とする。

例えば、export PGSSLMODE=prefer のように定義します。

SSL 証明書

SSL の認証では、クライアントとサーバーが、疑う余地のない資格情報を持つサード・パーティーによって署名が付けられた証明書を交換します。このサード・パーティーは、認証局 (CA) として知られています。サーバーまたはクライアントは、他方から正式な証明書を受け取らなかった場合、接続を拒否します。

詳細な設定はいろいろとありますが、SSL 証明書を使用して PostgreSQL で認証を行うように設定すること自体は簡単です。

postgresql.conf を編集して ssl=on を設定します。サーバー・サイドの認証には、以下のファイルがサーバーのデータ・クラスターに置かれている必要があります。

  • server.key
  • server.crt (CA が署名したファイル)
  • root.crt (クライアント認証を検証するファイル)
  • root.crl (証明書失効リストが含まれるファイル。オプション)

root.crt ファイルには、承認済み CA 証明書のリストが含まれています。このリストは、特定のディストリビューションに使用できる証明書をすべて網羅していなければなりません。証明書を追加することは可能です。

root.crl ファイルは、CA が署名した証明書のリストが含まれているという点で、root.crt と似ています。ただし、これらの証明書は、接続する権利が失効されたクライアントのものです。root.crl ファイルが空の場合、認証プロセスには干渉しません。

クライアント・サイドの認証には、以下のファイルがクライアントのホーム・ディレクトリー (~/.postgresql) に置かれている必要があります。

  • postgresql.key
  • postgresql.crt
  • root.crt (サーバー認証を検証するファイル)
  • root.crl (証明書失効リストが含まれるファイル。オプション)

サーバーの root.crt と同じく、クライアントの root.crt ファイルにも信頼できるサード・パーティー CA によって署名が付けられたサーバー証明書のリストがあります。最後に挙げた root.crl はオプションで、サーバー証明書を失効させる場合に使用します。

証明書を取得するには、クライアントとサーバーの両方が証明書要求 (client.csr および server.csr) を CA に送信する必要があります。証明書は、クライアントとサーバーがそれぞれの秘密鍵を生成してからでないと作成することができません。秘密鍵を生成し、証明書を作成する方法は以下のとおりです。

openssl req -new -newkey rsa:1024 -nodes -keyout client.key -out client.csr
openssl req -new -newkey rsa:1024 -nodes -keyout server.key -out server.csr

openssl ユーティリティーは、必要に応じて上記以外の方法でも実行することができます。例えばこのユーティリティーを使用して、証明書に有効期間を設定することも、自己署名証明書を使ってサーバーおよびクライアントの証明書を生成して CA を不要にすることもできます。

クライアント証明書とサーバー証明書を生成するには以下の 3 つの方法があります。

  • 信頼できる CA によって client.csr および server.csr に署名してもらう。
  • openssl の perl ユーティリティー CA.pl を使用して CA になる。
  • 自己署名証明書を作成し、サーバーとクライアントの root.crt ファイルに追加する。

CA.pl で使用できるコマンドを以下に要約します。

  • CA.pl -newca (新規 CA を作成)
  • CA.pl -newreq (秘密鍵を使用して証明書要求を作成)
  • CA.pl -signreq (自分で作成した CA で証明書要求に署名を付与)

オープンソースの純粋主義者には、いつでも「無料」で証明書を生成できる http://www.cacert.org があります。

リスト 24. 証明書の例
-----BEGIN CERTIFICATE-----
MIIC9TCCAl6gAwIBAgIJAMuhpY+o4QR+MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQxFDASBgNVBAMTC0NvbW1vbiBOYW1lMB4XDTA3MDIxMjEy
MjExNVoXDTA3MDMxNDEyMjExNVowWzELMAkGA1UEBhMCQVUxEzARBgNVBAgTClNv
bWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEUMBIG
A1UEAxMLQ29tbW9uIE5hbWUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKA4
nX/eBKsPJI1DmtH2wdJE9uZf+IRMUWYrAEDL4F6NEuo2+BsIoOBKS/rrV77Itet9
kduJCQ6k/z2ouAVb4muXpJALDjJpYBXt9wqZf+2p1n9dqDw1rCWBjXIdhOcA3DDv
u0Ig1FUfm8GS97evxM5IJBECRnK/5JZroXCRSHcpAgMBAAGjgcAwgb0wHQYDVR0O
BBYEFElEWNUCV+61itXp86czrDe35vjrMIGNBgNVHSMEgYUwgYKAFElEWNUCV+61
itXp86czrDe35vjroV+kXTBbMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1T
dGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMRQwEgYDVQQD
EwtDb21tb24gTmFtZYIJAMuhpY+o4QR+MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN
AQEFBQADgYEAaFzbUmXcWVzqaVeEpZkNwF/eVh110qIUUxXGdeKZGNXIyK67GCUY
SG/IFkZ/hrGLeqElLrdmU0mHd2Enq2IuvhxnsOVTTickjKospJvlHPYSumkXx0Xp
zey9PhjLh1chpxNGTATKb8ET8YZvBRrDHl/EMPIjLd62iSR/ugFe8go=
-----END CERTIFICATE-----

自己署名証明書を生成したら、それらの証明書を適切な場所にコピーし、root.crt を編集します。クライアント証明書はサーバーの root.crt に保存し、サーバーの証明書はクライアントの root.crt に保存します。

サーバーの再起動時にログ・メッセージをモニターし、すべてが適切に構成されていることを確認します。

サーバーのデフォルトの振る舞いでは、まだ暗号化を使用していますが、このデフォルトの振る舞いは postgresql.conf ファイル内の名前と値のペアを編集し、ssl_ciphers='NULL' にしてからサーバーを再起動することで無効にすることができます。しかし、ssl_ciphers を NULL に設定すると暗号化が無効になってしまうため、無効にするかどうかは慎重に検討して決定してください。


まとめ

この記事では、PostgresSQL データベース・サーバーを保護するための基本を学びました。このトピックについてはまだ多くの題材がありますが、1 つの記事で取り上げられる内容は限られています。現在、PostgreSQL について書かれた記事は、まだ十分なものではありません。今後、PostgreSQL のセキュリティーに関するさらに多くの記事を目にできるよう、皆さんもご協力下さい。


ダウンロード

内容ファイル名サイズ
Sample codeos-postgresecurity-listings_src_code.zip10KB

参考文献

学ぶために

製品や技術を入手するために

  • IBM ソフトウェアの試用版を使用して、次のオープンソース開発プロジェクトを革新してください。ダウンロード、あるいは DVD で入手できます。
  • IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=548876
ArticleTitle=PostgreSQL データベースにおけるトータル・セキュリティー
publish-date=11172009