IBM Database Encryption Expertを利用してデータを保護する: 第 4 回 データベースのバックアップ・イメージの保護

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

貝嶋 創 (kaijima@jp.ibm.com), IM&Lotus開発, ソフトウェア開発研究所, IBM
大川 昌弘 (mohkawa@jp.ibm.com), IM&Lotus開発, ソフトウェア開発研究所, IBM
中嶋 剛 (gnaka@jp.ibm.com), IM&Lotus開発, ソフトウェア開発研究所, IBM

2009年 4月 17日

IBM Database Encryption Expert (DEE) は、アプリケーションがファイル・システムに書き込むデータやデータベースのバックアップ・イメージを暗号化し、アクセス制御する機能を提供します。DEE Version 1.1 Fix Pack 3では、DB2に加えて、新たにIDS (Informix Dynamic Server) がサポートされ、さらに多くのプラットフォームに対応するようになりました。この連載では、DEEの機能やメカニズム、操作方法などを紹介します。第4回は、データベースのバックアップ・イメージの保護について、機能と実際の操作方法について述べます。

はじめに

DEEによるデータベースのバックアップ・イメージの保護とは、バックアップ・イメージをアクセス制御のもと、暗号化する機能のことです。暗号化するだけではなく、バックアップ・イメージの圧縮や、バックアップ/リストアの実行を時間やユーザー名などの条件で制御することも可能です。この機能を利用することで、バックアップ・イメージの移動時や長期保存時において、盗難や紛失が発生した際にデータの安全性を確保することができます。
この機能を利用するためにホストに導入されるDEE DB Agentは、DEE1.1.3からDB2とIDSの両方のデータベースをサポートしています。ただし、一つのホストで利用できるDEE DB Agentは1種類になります。例えば、DB2のバックアップ・イメージの保護を行うDEE DB2 Agentをインストールしている場合は、IDSのバックアップ・イメージの保護を行うDEE IDS Agentのインストールはできません。
まずは、DEEが行うバックアップ・イメージの暗号化のメカニズムを解説した後に、設定/利用方法を説明します。その後、使用例として「暗号化したバックアップ・イメージのテープへのバックアップ」および「データベースのバックアップを、別の遠隔地のシステムにリストアする際のバックアップ・イメージの安全な移動方法」を紹介します。

上に戻る

機能解説

ここでは、DEEを利用するバックアップとリストアの処理の流れを解説します。

バックアップのメカニズム

本連載の第1回で述べたように、DEEはデータベースのバックアップ・イメージを暗号化するためにハイブリッド暗号方式を利用します。バックアップ・イメージの暗号化に対しては処理が高速に行える対称キー暗号方式を利用し、さらに、対称キーを非対称キー暗号方式（公開キー暗号方式）で暗号化します。図1を見ながらバックアップの流れを見ていきましょう。

1. データベースのバックアップがデータベース・サーバーで実行されると、DEE DB Agentが起動されます。
2. DEE DB Agentから実行環境に関する各種情報がDEE Security Serverに送付され、このバックアップ処理を実行可能かどうか、ユーザーが作成したポリシーに従って判定されます。ポリシーは、時間やインスタンス、データベース・エイリアスなどの条件の集合です。詳しくは、後述する「バックアップ・イメージの保護の設定と実行」で説明します。
3. データベースのバックアップが実行される場合、DEE Security Serverはバックアップの要求ごとに、バックアップ・イメージを暗号化する対称キーであるBackup Encryption Key (BEK)とバックアップ・データに付加されるDEEヘッダーを作成します。BEKにはAES128かAES256の暗号化アルゴリズムを利用できます。DEEヘッダーには、非対称キーの公開キーにより暗号化されたBEKと、SHA-2による公開キーのハッシュコードが含まれます。非対称キーは、RSA1024,RSA2048,RSA4096の非対称暗号アルゴリズムから選択します。
   BEKの暗号化を行う公開キーは、複数まとめてキー･グループとして利用します。バックアップの際には、キー･グループ中に設定された公開キーの数だけBEKの暗号化が行われ、ヘッダーに追加されていきます。異なるDEE Security Serverで作成された非対称キーの公開キーをまとめてキー・グループとしてBEKの暗号化に利用することで、異なるDEE Security Serverに登録されたDEE Agent でのデータベースのリストア(復号)を可能にすることができます。詳細については、｢シナリオ2 バックアップ・イメージの安全な移動｣を参照してください。なお、非対称キーの秘密キーは、非対称キーを作成したDEE Security Serverだけが保持するので、セキュリティ上問題はありません。
4. DEE Agentであるホストは、DEE Security Serverから送られてきたBEKを利用してバックアップ・イメージの暗号化を実行します。バックアップ処理の結果として出力されるファイルは、BEKで暗号化したデータベースのバックアップ・イメージにDEE ヘッダーが付加されたものとなります。さらに、DB2の場合はDEEのライブラリもバックアップ・イメージに組み込まれ、リストア時には自動的にそのライブラリが呼ばれます。

ちなみに、DEE AgentとDEE Security Serverの間の通信はSSLで保護されているため安全です。

リストアのメカニズム

リストアについては図2にまとめてあります。図の流れに沿って解説します。

1. データベースのリストアがデータベース・サーバーで実行されると、DEE DB Agentが起動されます。
2. DEE DB Agentが実行環境に関する各種情報とDEEヘッダーをDEE Security Serverに送付します。DEE Security Serverはこのリストア処理を実行可能かどうか、ユーザーが作成したポリシーに従って判定し、実行可能な場合は次の処理に進みます。
3. DEE Security Serverは、DEEヘッダーの公開キーのハッシュコードから非対称キーを特定し、DEE Security Serverの持つ秘密キーを利用してBEKを復号して、DEE Agentに送付します。
4. DEE DB Agentは、受け取ったBEKを利用してバックアップ・イメージを復号します。データベースのリストア・コマンドは復号されたイメージをデータベースにリストアします。

Restore処理においても、DEE AgentとDEE Security Serverの間の通信はSSLで保護されているため安全です。

上に戻る

DB2のバックアップ・イメージの保護の設定と実行

ここでは、DB2のバックアップ・イメージにDEEの保護機能を利用する際に必要なDEE Management Console上での設定および実行方法を説明します。DEE DB2 Agentを利用するための準備として、非対称キーとキー・グループを作成し、その後バックアップ・ルールとリストア・ルールを規定したポリシーを作成します。最後に、そのポリシーを利用するホストに登録する必要があります。なお、DEEの導入やDEE Management Consoleの使用法については、この連載の第1回、第2回を参照してください。

非対称キーとキー・グループの作成

まずは、バックアップ・イメージを暗号化するためのBEKを暗号化する非対称キーと、それをまとめるキー・グループを作成します。非対称キーの作成は、DEE Management Consoleのメニューから “Keys” -> “Keys” -> “Add” -> “Asymmetric” を選択します。非対称キーの暗号アルゴリズムはRSA1024、RSA2048、RSA4096の3種類から選択することができます。RSA1024については、安全性の低下が指摘されているため、RSA2048もしくはRSA4096を利用しましょう。以下の図3では、RSA2048で非対称キーを作成しています。

次に、ここで作成したキーをまとめて、キー・グループとして登録します。キー・グループには、他のDEE Security Serverで作成し、インポートされた公開キーを含めることができます。暗号化されたバックアップ・イメージは、キー・グループに含まれている公開キーに対応する秘密キーをもつDEE Security Serverであれば復号(リストア)可能です。詳細については、｢シナリオ2 バックアップ・イメージの安全な移動｣を参照してください。別のDEE Security Serverが管理するDEE Agentのホストにリストアする必要がないのであれば、先ほど作成したキーを一つだけ持つキー・グループを作成すれば十分です。必要に応じて公開キーを追加してください。
キー・グループを作成するには、DEE Management Consoleのメニューから “Keys” -> “Key Groups” -> “Add” を選択してキーを追加します。

ポリシーの作成

バックアップやリストアの実行のための条件やBEKの暗号化アルゴリズムを定義するポリシーの作成を行います。なお、第3回で説明したオンライン・データの保護とは異なり、バックアップ・イメージの保護では1つのDEE DB Agentで1つのポリシーを適用します。1つのポリシーに対して複数のルールを定義できるため、インスタンスやデータベース毎にバックアップ/リストアのルールを作成することが可能です。
ポリシーを作成するためには、DEE Management Consoleのメニューから “Policies” -> “Add Offline Policy” を選択します。
ポリシーに対して、バックアップとリストアの実行の可否を決定するルールを作成します。DB2で利用可能な条件については以下の表を参照してください。

バックアップ/リストア処理実行時には、一番上のルールから評価されます。各ルールの中で設定されているすべての条件が一致するとそのルールが使用され、”Action”で指定された動作が実行されます。Actionでは、AllowかDenyが指定でき、Allowならバックアップ・リストアを実行し、Denyならバックアップ・リストアを実行しません。条件が一致しない場合は、下のルール(次のルール)が評価されます。すべてのルールが一致しないと、バックアップ/リストアの実行は拒否（Deny)されます。

以下の図4は、backup_rule1という名前で、インスタンスv95inst1のSAMPLEというDBをAM2:00-AM4:00の間だけ、AES128のBEKとkey_group2というキー・グループを利用して暗号化を実行可能にするという条件のルールです。

登録済みホストへのポリシーの登録

DEE Management Consoleのメニューから “HOSTS” を開き、ポリシーを登録したいホストの “hostname”をクリックした後に、“GuardDB” -> “Guard” を開くと、作成済みポリシー一覧が出てきます。この画面で、先ほど作成したポリシーを選択します。登録後、Enabled がチェックされていることを確認してください。

バックアップとリストアの実行

DB2の場合は、以下のようにDB2のバックアップ・コマンドにDEE DB2 Agentのライブラリを指定します。以下は、データベースSAMPLEをバックアップする例です。紙面の都合上コマンドが2行に渡っているように見えますが、実際には1行に記述します。

# db2 backup db sample to $HOME/backup compress comprlib 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/lib/libeetdb2.so

Backup successful. The timestamp for this backup image is : xxxxx

先に述べたとおり、リストアの場合はデータベースのバックアップ・イメージにDEE DB2 Agentのライブラリが格納されているので、オプションをつける必要はありません。

# db2 restore db sample from $HOME/backup 

SQL2539W  Warning!  Restoring to an existing database that is the same as the
backup image database.  The database files will be deleted.
Do you want to continue ? (y/n) y
DB20000I  The RESTORE DATABASE command completed successfully.

以下にデータベース"sample"のバックアップ実行においてDEEのバックアップ・ポリシーのルールで拒否されたためにエラーが発生した例を示します。

# db2 backup db sample compress comprlib 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/lib/libeetdb2.so

SQL2062N  An error occurred while accessing media "libeetdb2.so".  Reasoncode: "1".

詳細はDEE Serverにログされ、DEE Management Consoleから確認することができます。DEE Management Consoleのメニューから "Log" でエラーログを確認することができます。(図5)

上記エラーログでエラー内容を確認できます。上記の例の場合、実行時間が設定された時間(AM02:00-AM04:00)ではなかったため該当するルールがなく、実行が拒否されたことがわかります。

上に戻る

IDSのバックアップ・イメージの保護の設定と実行

ここでは、IDSのバックアップ・イメージの保護機能を利用する際に必要な、DEE Management Console上での設定および実行方法を説明します。DB2の場合と同様に、DEE IDS Agentを利用するための準備として、非対称キーとキー・グループを作成し、その後バックアップ・ルールやリストア・ルールを規定したポリシーを作成してから、そのポリシーを利用するホストに登録する必要があります。

非対称キーとキー・グループの作成

非対称キーとキー・グループの作成はDB2と同じ手順で行います。DB2の内容を参照してください。

ポリシーの作成

DEE Management Consoleのメニューから “Policies” -> “Add Offline Policy” を選択します。

ポリシーに対して、実行の可否を決定するルールを作成します。IDSで利用可能な条件については以下の表を参照してください。

バックアップ/リストア処理実行時には、一番上のルールから評価されます。各ルールの中で設定されているすべての条件が一致するとそのルールが使用され、“Action”で指定された動作が実行されます。条件が一致しない場合は、下のルール(次のルール)が評価されます。すべてのルールの条件が一致しない場合は、バックアップ/リストアの実行は拒否（Deny)されます。

以下の図6は、ids_backup_ruleという名前で、Server NameとONCONFIG という2つのキーを条件に持ち、AM2:00-AM4:00の間だけ、AES256のBEKとkey_group2というキー･グループで暗号化を実行可能にするという条件のバックアップ・ルールです。

登録済みホストへのポリシーの登録

非対称キーとキー・グループの作成はDB2と同じ手順で行います。DB2の内容を参照してください。

アトリビュート・ファイルの作成

ここからは、バックアップやリストアを実行するホスト上での処理になります。
IDSではバックアップやリストアを実行するために、アトリビュート・ファイルを用意する必要があります。
DB2とIDSのポリシーの大きな違いは、ポリシーで設定したキーと値を参照する場所です。DB2用ポリシーの条件は環境変数をチェックしますが、IDS用ポリシーは、デフォルトではユーザーがそれぞれ用意するアトリビュート・ファイルに設定されているキーと値を参照します。アトリビュート・ファイルで後述するENVキーを利用することでDB2と同様に環境変数をチェックさせることができます。

アトリビュート・ファイルにおいて設定可能な項目を以下に記します。

IDSの実行サーバー名は、環境変数INFORMIXSERVERに設定されていますが、DEEを利用したバックアップにおいてチェックする"INFORMIXSERVER"の値は、デフォルトではアトリビュート・ファイルから取得されます。
例えば、ポリシーのバックアップ・ルールをINFORMIXサーバー毎に作成し、実行をコントロールしたい場合には、キー”INFORMIXSERVER”をENVの値に指定して、環境変数から読み込むように設定する必要があります。複数のキーに対する値を環境変数から読み込みたい場合は、ENVの値としてカンマ(,)区切りで指定します。

以下に、INFORMIXSERVERとSERVERNUMの値を環境変数から取得する場合のバックアップ用のアトリビュート・ファイルの内容を出力します。バックアップ用のアトリビュート・ファイルなので、“OPERATION”の値が“write”であること、バックアップ・ポリシーで条件を追加しているので、正常に動作させるために“ONCONFIG=onconfig_aixids11”という1行が追加されていることに注意してください。

ENV=INFORMIXSERVER,SERVERNUM
OPERATION=write
SERVERNUM=0
ONCONFIG=onconfig_aixids11

リストア用のアトリビュート・ファイルの内容を出力します。アトリビュート“OPERATION”が“read”であることに注意してください。また、リストア用アトリビュート・ファイルでも追加された条件があるならばそれを追記します。以下は追加条件がない場合のアトリビュート・ファイルの例です。

ENV=INFORMIXSERVER,SERVERNUM
OPERATION=read
SERVERNUM=0

なお、アトリビュートの詳細についてはDEE User’s GuideのChapter 12 “Configuring the IDS Database Backup Agent attributes file”を参照してください。

DEEとIDSのバックアップ方式の関係

DEEを利用したDBの暗号化バックアップの利用方法として、後述する、「ONCONFIGファイルのFilterに指定して利用する方法」と、「バックアップの出力をリダイレクトする方法」の2つが利用可能です。

IDSのバックアップ・コマンド、ontape/onbarにおいて利用可能な方式は以下の通りです。

ONCONFIGファイルのFilterに指定して利用する方法

IDSのONCONFIGファイルにある“BACKUP_FILTER”と“RESTORE_FILTER”に対して、DEEのライブラリを指定して、バックアップ/リストア(ontape、onbar)実行時に自動でIDSを呼び出すようにします。この方式では、各IDSサーバーのONCONFIGファイルを編集する必要がありますが、一旦FILTERに登録すると、以降のontapeやonbar実行時は自動でそのプログラムを呼び出すため、最初の設定以降DEEの存在を意識することはありません。よってこちらの方式をお勧めします。
例えば、バックアップ用アトリビュート・ファイルを/home/informix/attr.w、リストア用アトリビュート・ファイルを/home/informix/attr.r として作成した場合は以下のようにONCONFIGファイルを編集します

BACKUP_FILTER '/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f 
/home/informix/attr.w'
RESTORE_FILTER '/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f 
/home/informix/attr.r'

以下にonbarでの実行例を以下に記します。(ontapeの場合も通常の使い方と全く同じです。)

バックアップの実行と実行結果の確認の実行例です。

# onbar -b –w
# onbar -m 99

リストア実行方法も通常のonbarによるリストア・オペレーションと変わりません。以下にコールド・リストアを実行する例を表示します。

# onmode -ky
# onbar -r
# onmode –m

onbarの実行結果を確認するには、通常のonbarの実行処理と同様に、onbarの出力するログを確認する必要があります。

以下にonbar実行においてエラーが発生した場合のonbarの出力するログの例を示します。

2008-11-28 16:05:49 13340  13338 Starting Filter 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f 
/home/informix/attr.w.  13340  13338 Filter terminated.
 2008-11-28 16:05:50 13340  13338 (-43082) Writing to backup and restore filter failed 
with error 2.

FILTERでエラーが返されたことが確認できます。DEEの実行結果の詳細を確認するには、DB2の場合と同様にDEE Management Consoleのメニューから“Log”をチェックします。

バックアップの出力をリダイレクトする方法

ontapeでは、バックアップ・イメージを一つのファイルに出力することが可能です。

Filterを利用する場合にはONCONFIGファイルを編集しているためバックアップのコマンド記述に変化はありませんが、出力リダイレクトの方法を利用する場合はパイプを用いて毎回指定する必要があります。ontapeによるバックアップ・イメージの出力先を”-t”オプションを利用して標準出力に変更している点に注意してください。

バックアップ実行例は以下のようになります。まずは、バックアップが正常に行われた例を以下に示します。

# ontape –v –s –L 0 –t STDIO | 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt –f 
/home/informix/attr.w > /BackupData/backup.000

10 percent done.
100 percent done.
Please label this tape as number 1 in the arc tape sequence.
This tape contains the following logical logs:
 5
Program over.

リカバリーでは、バックアップ・イメージを復号してからontapeユーティリティに渡します。リストア実行例は以下のようになります。ここでも、アトリビュート・ファイルとしてリカバリー用のファイルを指定する必要があります。

# onmode –ky
# cat  /backup/image.000 | 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt –f 
/home/informix/attr.r | ontape –r –t STDIO –v
# onmode –m

以下にontape実行においてエラーが発生した場合に出力するログの例を示します。

# ontape -v -s -L 0 -t STDIO | 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/ids/bin/eetidsagt -f 
/home/informix/attr.w > /BackupData/backup.000

Interrupt received ...

エラーの詳細を確認する場合は、DB2の時と同様にDEE Management Consoleから”LOG”を確認してください。

上に戻る

DEE DB Agentの利用シナリオ例

シナリオ1. 暗号化したDB2バックアップ・イメージを直接テープに保存する

ここでは、DB2とIBM Tivoli Storage Manager を利用して、バックアップ・イメージをテープに暗号化して保存する方法を述べます。実行方法は非常に簡単で、DB2のバックアップ・コマンドの”use”オプションを利用してTSMを呼び出し、“comprlib”オプションを利用してDEEを呼び出すだけです。以下に実行例を示します。

# db2 backup db sample use tsm compress comprlib 
/opt/IBM/DB2TOOLS/LUWEncryptionExpert/agent/db2/lib/libeetdb2.so

Backup successful. The timestamp for this backup image is : xxxxx

テープからリストアする手順は、“use tsm”オプションをつけた通常のテープからのリストアと同様です。

# db2 restore db sample use tsm

SQL2539W  Warning!  Restoring to an existing database that is the same as the
backup image database.  The database files will be deleted.
Do you want to continue ? (y/n) y
DB20000I  The RESTORE DATABASE command completed successfully.

どちらの場合も、通常の”use tsm”オプションを利用するコマンドに、DEE呼び出しオプションをつけるだけで動作します。

シナリオ2. バックアップ・イメージの安全な移動

DEEを利用して、異なるDEEを利用しているサイトへデータベースを安全に移動することが可能です。
例えば、東京(DEE Security Server1)と大阪(DEE Security Server2)で別々のDEE Security Serverを運用していて、東京で取得したデータベースのバックアップ・イメージを大阪でもリストア(復号)可能にする場合を考えます。
DEEは、他のDEE Security Serverで作成した非対象キーの公開キーをインポートして、そのキーを利用してデータベースをバックアップすることができます。そうすると、そのキーに対応する秘密キーを保持するDEE Security Serverの管理下のホストにリストア可能となります。

処理の流れは以下の図7のようになります。

1. DEE Management Consoleのメニューから “Keys” -> “Key“ で表示されるキー一覧から作成したキーをクリックします。以下の画面が表示されるので、“Click to Export”をクリックして、公開キーをエクスポートします。
   
   図8. 公開キーのエクスポート
   
   
   
   
2. DEE Management Consoleのメニューから“Keys” -> “Key Groups” -> “Add” -> “Asymmetric”を選択し“Key Type”コンボボックスで“Public key”を選択します。“Public Key File”という新しいフィールドが出てきますので、先ほどエクスポートしたキーを指定します。
   
   図9. 公開キーのインポート
   
   
   
   

   インポートした非対称キーの公開キーと、DEE Security Server1(東京)で作成した既存の非対称キーをまとめてキー・グループを作成します。作成したキー・グループを対象となるデータベースのバックアップ・ルールに設定します。手順は通常の作成手順と変わりません。

3. データベースをバックアップします。ここも通常のDEEを利用するバックアップ手順と変わりません。
4. 出力されたバックアップ・イメージを大阪のDEE Agentに移動してリストアします。DEE Security Server2でのリストア時には、DEE Security Server2で作成した公開キーで暗号化されたBEKを自身の持つ秘密キーで復号し、そのBEKを用いてバックアップ・データを復号して、データベースをリストアします。

上に戻る

まとめ

第4回は、DEE DB Agentによるアクセス制御と暗号化によるバックアップ・イメージの保護機能について解説しました。この機能は、既存のバックアップ処理に容易に導入可能である上に、バックアップ・イメージを暗号化することにより、手軽に強固なセキュリティを確保することができます。是非一度お試しください。

参考文献

• IBM Database Encryption Expertを利用してデータを保護する：第1回 主な機能とメカニズム
  
  
• IBM Database Encryption Expertを利用してデータを保護する：第2回 主なセットアップとメンテナンス
  
  
• IBM Database Encryption Expertを利用してデータを保護する：第3回 オンライン・データの保護
  
  
• IBM Database Encryption Expertがサポートするプラットフォームやデータベースなどのシステム要件について述べられています。
  
  
• IBM Database Encryption ExpertのUser's Guideが入手できます。

著者について

		貝嶋 創は、ソフトウェア開発研究所のIM&Lotus開発に所属するソフトウェアエンジニアで、現在は主にデータベースツール製品の開発やテストを行っています。

		大川 昌弘は、ソフトウェア開発研究所のIM&Lotus開発に所属するソフトウェアエンジニアで、現在は主にデータベースツール製品の開発やテストを行っています。

		中嶋 剛は、ソフトウェア開発研究所のIM&Lotus開発に所属するソフトウェアエンジニアで、現在は主にデータベースツール製品の開発やテストに従事しています。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る