
最終回 SE-PostgreSQLの実運用に向けて
海外 浩平
日本SELinuxユーザ会
2007/11/27
オープンソースだからといって、ドキュメントの整備や実運用を想定した機能の実装を怠ってはなりません。最終回ではSE-PostgreSQLの実運用を想定した機能の紹介と、気になるPostgreSQLとのパフォーマンス差について解説します。(編集部)
今回で「SE-PostgreSQLによるセキュア・データベース構築」の連載も最終回となりました。今回はシステム運用を視野に入れ、ネットワーク透過なSE-PostgreSQLの利用、バックアップとリストア、SE-PostgreSQLのパフォーマンスについてご紹介したいと思います。
ネットワーク越しのSE-PostgreSQL接続
第1回で述べたように、SE-PostgreSQLの最も重要な特徴は、データベースへのアクセス制御をOSのそれと一体化することでした。そのため、SE-PostgreSQLは接続元プロセスのセキュリティコンテキストを取得する必要があります。
これまでの連載ではすべて、SE-PostgreSQLの動作するサーバとクライアントが同一のホストで動作しているケースを前提としていました。この場合、クライアントはUNIXドメインソケットを経由してSE-PostgreSQLに接続することが可能で、互いに同一ホスト上で実行されているため、特別な設定を行うことなくSE-PostgreSQLは接続元プロセスのセキュリティコンテキストを取得することができます。
しかし、ネットワークを介して異なるホスト上のSE-PostgreSQLに接続する場合、話は単純ではありません。ローカルと同じように接続元プロセスのセキュリティコンテキストを取得するためには、“Labeled IPsec”と呼ばれる追加的なネットワーク設定が必要になります。
Labeled IPsecの設定
Labeled IPsecとは、ネットワーク経由で別のホストに接続した際に、サーバ側が接続元プロセスのセキュリティコンテキストを取得するための仕組みです。これをサポートするためにIPsecの鍵交換デーモン(racoon)に拡張が加えられており、鍵交換プロセスの際に接続相手側に自らのセキュリティコンテキストを送出するようになっています。接続相手のサーバは、これを参照することでネットワーク接続元のセキュリティコンテキストを取得することができます。
この機能はSE-PostgreSQLに固有のものではなく、SELinuxが提供している機能です。従って、Labeled IPsecを利用するためには、サーバ側だけでなくクライアント側でもSELinuxが動作している必要があることに留意してください。
| 【注1】 Fedora 8の標準セキュリティポリシーには、Labeled IPsecを利用してSE-PostgreSQLに接続するためのポリシーの一部に不備があります。sepostgresql-8.2.5-1.66 以降にはこの問題の修正が含まれていますので、サーバ側/クライアント側の双方でパッケージをアップデートしてください。 |
![]() |
| 図1 ネットワーク経由で別のホストと鍵を交換する
|
ここでは、図1のようなシンプルなサーバ/クライアント型の環境を基にLabeled IPsecの設定を行います。サーバ側のIPアドレスは192.168.1.10、クライアント側のIPアドレスは192.168.1.20とし、事前共有鍵(pre-shared key)によるIPsec通信を行います。
まず、鍵交換デーモンであるracoonの設定ファイルを編集して192.168.1.10←→192.168.1.20間の通信がIPsecによって暗号化するように設定します。
/etc/racoon/racoon.confの太字部分を以下のとおり編集してください。これはサーバ側での設定ですが、クライアント側(192.168.1.20)では逆に、remote <相手側IPアドレス> の部分に「192.168.1.10」を記述する点に留意してください。
| 【サーバ側(192.168.1.10)の racoon.conf 設定】 # Racoon IKE daemon configuration file. # See 'man racoon.conf' for a description of the format and entries. path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; path script "/etc/racoon/scripts"; sainfo anonymous { #pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } remote 192.168.1.20 { exchange_mode aggressive, main; my_identifier address; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2 ; } } #remote <IP-of-Cisco-ASA> #{ # exchange_mode main; # my_identifier fqdn "host.name.of.vpn.client"; # certificate_type x509 "client.crt" "client.key"; # ca_type x509 "ca.crt"; # mode_cfg on; # script "p1_up_down" phase1_up; # script "p1_up_down" phase1_down; # proposal # { # encryption_algorithm 3des; # hash_algorithm sha1; # authentication_method xauth_rsa_client; # dh_group 2; # } #} |
| リスト1 /etc/racoon/racoon.confの修正点(太字部分) |
次に、サーバ側/クライアント側の双方で事前共有鍵の設定を行います。事前共有鍵の設定ファイルは/etc/racoon/psk.txtですので、これを次のように編集します。
| 【サーバ側(192.168.1.10)の psk.txt 設定】 # file for pre-shared keys used for IKE authentication # format is: 'identifier' 'key' # For example: # # 10.1.1.1 flibbertigibbet # www.example.com 12345 # foo@www.example.com micropachycephalosaurus 192.168.1.20 somethingsecrettext |
| リスト2 /etc/racoon/psk.txtの修正点(太字部分) |
racoon.confと同様に、クライアント側ではIPアドレスの部分が「192.168.1.10」となることに留意してください。「somethingsecrettext」が共有鍵となりますので、サーバ側/クライアント側で共通の文字列に置き換えてください。
続いて、IPsecのセキュリティポリシーデータベース【注2】を設定します。viなどのエディタで、以下の内容のテキストファイルを作成します。ここでは、myspd.txtとします。
| spdflush; flush; spdadd 192.168.1.10 192.168.1.20 any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0" -P out ipsec esp/transport//require; spdadd 192.168.1.20 192.168.1.10 any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0" -P in ipsec esp/transport//require; |
| リスト3 myspd.txtの内容 |
| 【注2】 非常に紛らわしいですが、IPsecを適用する通信経路/暗号化方法を指定するルールのことをこのように呼んでいます。SELinuxのセキュリティポリシーとはまったく関係ありません。 |
作成したmyspd.txtを、setkeyコマンドを用いてカーネルにロードします。
| [root@masu ~]# setkey -f myspd.txt |
ここまでの設定が終わったら、サーバ側/クライアント側の双方でracoonデーモンを起動します。
| [root@masu ~]# service racoon start |
1/3 |
| Index | |
| SE-PostgreSQLの実運用に向けて | |
| Page1 ネットワーク越しのSE-PostgreSQL接続 Labeled IPsecの設定 |
|
| Page2 Labeled IPsecの動きを確認する Fallback Context の設定 ラベル情報付きバックアップ&リストア |
|
| Page3 気になるSE-PostgreSQLのパフォーマンス ユーザーの声が、次のSE-PostgreSQLを作る |
|
SE-PostgreSQLによるセキュアDB構築 バックナンバー
- 第1回 SELinuxのアクセス制御をデータベースでも
- 第2回 データベース強制アクセス制御をカスタマイズする
- 第3回 アクセス制御の実装は“巧妙”かつ“大胆”に
- 最終回 SE-PostgreSQLの実運用に向けて
| SE-PostgreSQLによるセキュアDB構築 連載インデックス |
TechTargetジャパン
- 実録、「Hardening Zero」の舞台裏 (2012/5/25)
コラムの更新頻度を落として何をやっていたかって? 「守る技術」に焦点を当てたこんなイベントを開催しました - 複雑化、巧妙化する脅威への対策は? (2012/5/23)
データ保護や標的型攻撃対策、クラウドセキュリティ……「第9回 情報セキュリティEXPO」の会場で見つけた製品を一挙に紹介 - 仮想化がはらむ新たなリスク (2012/5/17)
仮想化に伴って生じるセキュリティやパフォーマンスへの影響を慎重に考慮し、うまく制御していく方法を紹介します - 新入生も新入社員も勉強会に寄っといで! (2012/5/14)
週末ともなれば至るところでセキュリティ系勉強会やCTFなどのイベントがあり、ツイートも盛り上がりました
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -

