IBM Database Encryption Expertを利用してデータを保護する: 第 3 回 オンライン・データの保護

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

レベル: 初級

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

2009年 2月 27日

IBM Database Encryption Expert (DEE) は、アプリケーションがファイル・システムに書き込むデータやデータベースのバックアップ・イメージを暗号化し、アクセス制御する機能を提供します。この連載では、DEEの機能やメカニズム、操作方法、いくつかのシナリオなどを紹介します。第3回は、アクセス制御と暗号化によるオンライン・データの保護機能を提供するDEE File System Agent (DEE FS Agent)について説明します。オンライン・データの暗号化のための暗号化キーの作成からポリシーの作成・適用、暗号化キー変換ユーティリティの利用法を紹介します。

DEE File System Agentとは

DEE File System Agent(DEE FS Agent)は、ユーザーやプロセスのアクセス制御や、オンライン・データの暗号化を行うためのDEE Agentです。例えば以下のような要求を実現します。

• データをデータベースに暗号化して保存したいが、データベースの定義や、データベースを利用するアプリケーションには変更を加えたくない。
• データベース全体の暗号化、あるいは一部の重要なデータが含まれるテーブルスペースのみ暗号化して保存したい。
• データベースからエクスポートしたデータを暗号化して保存しておき、あるユーザーからの参照時のみ自動的に復号したい。
• データベースから出力された監査ログやトランザクション・ログなどのファイルの参照や改竄を防ぎたい。

上記のようなことを実現するために、DEEではポリシーを使った設定を行います。DEE FS Agentが利用するポリシーのことをオンライン・ポリシーと言います。オンライン・ポリシーを利用する手順として、まず暗号化キーを作成します。オンライン・データの暗号化には対称暗号アルゴリズムが用いられ、作成時に暗号化アルゴリズムの選択が可能です。その後、オンライン・ポリシーの定義で、ファイルやディレクトリなどのリソースや、ユーザー、プロセス、時間などによるアクセス制御に関する設定、また暗号化や復号に利用する暗号化キーの指定などを行います。これらの操作はDEE Management Consoleを利用して行います。

定義したオンライン・ポリシーはDEE Management Consoleを利用して、ホストマシン(DEE FS Agentが導入されているマシン)上のディレクトリに対して適用できます。オンライン・ポリシーを適用したディレクトリのことをガード・ポイントと言います。ユーザーやプロセスがガード・ポイント下のファイルやサブ・ディレクトリに対してアクセスを試みると、DEE FS Agentに制御が移り、ポリシーに基づいてアクセスの許可・拒否、及びガード・ポイントへの入出力データの暗号化・復号を行います。そのため、アプリケーション自体に変更を加えることなく、そのアプリケーションからガード・ポイント上のファイルへの入出力データを暗号化・復号することが可能です。

オンライン・ポリシーと暗号化キーはDEE Security Server上で管理されており、DEE FS Agent側でそれを取得して利用します。図1と図2はDEE FS AgentがどのようなタイミングでDEE Security Serverからポリシーと、そのポリシーで指定された暗号化キーを取得するかを描いています。ここで、DEE Security ServerとDEE FS Agentの間はX.509証明書を使ったSSL通信が行われるため、DEE FS Agentへの暗号化キーの送信は安全に行われます。

ポリシーを新たにディレクトリに適用した時、DEE Security ServerはDEE FS Agentに対してオンライン・ポリシーと暗号化キーを送信し、DEE FS Agentはそれらをメモリ上に保持します(図1)。ポリシーはディスク上にも保存されます。これは、ガード・ポイントへ適用されているオンライン・ポリシーに変更を加えた時も同様な動作となります。ガード・ポイントへのアクセス制御を行う場合はメモリ上のポリシーと暗号化キーを利用するため、一旦DEE FS Agentがそれらの情報を受信してしまえば、DEE Security Serverが不具合などで停止してもアクセス制御は問題なく処理されます。

DEE FS Agentはデーモン・プロセスで、マシン起動時に起動され、DEE Security Serverからガード中のポリシーと暗号化キーをダウンロードしてメモリ上に保持します(図2)。この時に、不具合などによりDEE Security Serverとの通信ができない場合、DEE FS Agentはポリシーと暗号化キーのダウンロードに失敗しますが、一定時間(5秒)おきにリトライを繰り返します。この間にプロセスがガード・ポイントにアクセスすると、ディスク上に保存されているポリシーを利用してアクセス制御が行われますが、暗号化を行う場合は暗号化キーがメモリ上に無いため、そのプロセスはフリーズします。これは後述するCached on Hostタイプの暗号化キーを利用することにより、DEE Security Serverが停止したままでも処理を再開することができます。

DEE FS Agentは、ポリシーや暗号化キーのダウンロードなどのDEE Security Serverとの通信をつかさどるvmdプロセスと、ポリシーや暗号化キーの保持、暗号化・復号、アクセス制御をつかさどるsecfsdプロセスから構成されますが、本稿では特にこれらを区別せず、DEE FS Agentとしての機能や利用法を紹介します。

上に戻る

暗号化キーの作成

DEE Management Consoleのメニューから、”Keys”->“Add”と選択すると、図3のような暗号化キー（対称キー）作成画面が表示されます。この画面を用いて対称キーを作成することができます。

DEE FS Agentがサポートする暗号化方式は”3DES”, “AES128”, “AES256”の3つです。暗号アルゴリズムの強度の観点から、3DESよりもAESを利用することをお勧めします。

Key Typeコンボ・ボックスでは、”Stored on Server”と”Cached on Host”が選択でき、Unique to Hostチェック・ボックスはKey Typeで”Cached on Host”を選択したときのみ表示されます。対称キー作成時に、Key TypeとUnique to Hostを編集することで、表1のように3通りの暗号化キーの利用法を指定できます。

# vmsec passwd 
Please enter password:  <--ここでHost Passwordを入力します
OK passwd
#

図3の対称キー作成画面のKey Creation Methodでは”Generate”と”Manual Input”が選択可能です。”Manual Input”を選択した場合、暗号アルゴリズムに従って、3DESの場合は16進数で48文字(192bit)、AES128の場合は16進数で32文字(128bit)、AES256の場合は16進数で64文字(256bit)という風にそれぞれのアルゴリズムのキー長に合わせた文字を入力します。これにより、他のアプリケーションで利用していた暗号化キーと同じものを利用しての暗号化・復号が可能になります。

上に戻る

オンライン・ポリシーを使ったアクセス制御・暗号化ルールの設定

オンライン・ポリシーの定義には、Policy Composerを利用します。Policy ComposerはDEE Management Consoleのインターフェースから起動できるJava アプレットです。Policy Composerを起動するにはDEE Management Consoleのメニューから”Policies”->“Add Online Policy”と選択します。

オンライン・ポリシーはSecurity RulesとふたつのKey Rulesからなります。Key RulesにはKey Selection RulesとData Transformation Rulesがあり、Policy Composer画面の上部にはそれぞれのルールを定義するためのタブがあります。

Security Rules

Security Rulesタブではどういったアクセスに対して、何を行うかといった項目に優先順位をつけて複数設定することができます。具体的には以下の6つの項目に対して設定を行えます。

ここで、Effectのauditをルールに付加しなければ、ポリシーを評価した際のログがDEE FS AgentからDEE Security Serverに送信されず、DEE Management ConsoleのLog画面に出力されないことに注意してください。例えば、ポリシーで拒否されたユーザーがガード・ポイントにアクセスした場合、ポリシーによる評価が行われたことをログで確認するためには、Effectにauditを付加していなければいけません。また許可されたユーザーによるアクセスをログに出力する為には、さらに該当ホストのFS LogのPolicy Evaluationタイプのログレベルを、デフォルトの”ERROR”から”INFO”に変更する必要があります。ただし許可ユーザーによるアクセスまでもログしてしまうと、ログを蓄積する容量が増え続けてしまう為、運用前の動作確認をするなど、必要に応じて設定することをお勧めします。

後述の図8、図11はそれぞれユーザーアクセスがポリシーによって許可・拒否されたケースのログを示しています。

表2のResource、User、Processの項目には複数の指定が可能で、それらをまとめたSet(例えばUserであれば、複数のユーザーをまとめた”team_member”という名前のUser Set)を一つのSecurity Rule内の属性に定義して使用します。

また、Security Ruleの属性のうちEffectのみが必須となっていますが、それ以外の項目に空欄をセットした場合は全て該当するという意味になります。例えばUserが空欄であれば、ガード・ポイントに対するユーザーのアクセス制御は行われません。

図4の上部にある”Security Rule定義域”で設定したルールは”Security Rule編集ボタン”のAddボタンにより、”Security Rule登録リスト”に追加されます。図中の”Security Rule登録リスト”が示すように、複数のSecurity Ruleが設定可能で、上から順に評価されていきます。

Key Selection Rules

Key Selection Rulesでは、暗号化のための対称キーを指定します。以下の2つの項目に対して設定を行えます。

Key Selection Rulesの設定はオプションであり、Security RulesのEffectでapply_keyを定義しても、ここのKeyで暗号化キーを登録しなければデータは暗号化されません。暗号化が必要な場合は必ず暗号化キーを指定してください。

Data Transformation Rules

Data Transformation Rulesはdataxformを使った暗号化キーの変換を行う際に使用されます。Data Transformation RulesではKey Selection Rulesと同じくResourceとKeyの指定が可能です。詳しくは後述の”dataxformによる暗号化キー変換”で述べます。

上に戻る

オンライン・ポリシーの適用(ガード)

定義したオンライン・ポリシーはDEE Management Console上のGuard File System画面(図5)を利用して、ディレクトリに対して適用することができます。オンライン・ポリシーをディレクトリに適用することをガードといいます。Guard File System画面はDEE Management Consoleのメニューから”Hosts”->(ガードを行いたいホストを選択)->“Guard FS”->“Guard”を選択して表示します。

正常にガードが適用された場合、ログレベルを”INFO”にしていれば、DEE Management ConsoleのLog画面に、ガードに成功したという内容のログが出力されます(図6)。ここでsrv1.yamato.ibm.comはDEE Security Serverのホスト名を、host1.yamato.ibm.comはDEE FS Agentのホスト名を示しています。

上に戻る

ガードの効果

ガード・ポイントにアクセス許可されたユーザーでアクセスし、ガード・ポイント上のリソースに対してread/writeなどのアクションを行った場合、アクセスが許可された旨がDEE Management ConsoleのLog画面に出力されます(許可ユーザーによるアクセスをログに出力するには前述のように、Security RulesのEffectでauditを付加し、ログレベルを”INFO”に設定する必要があります)が、実際にアクセスしている端末画面には何も追加メッセージは表示されません。つまり、ガードしていない状態と全く同じようにガード・ポイント上のリソースを利用することが可能です。アプリケーションからガード・ポイント上のリソースを利用する場合も同様に、アプリケーション側で暗号化処理を考慮した処理は必要ありません。

図7はガード・ポイント “/home/v95inst1/guard”に対して、アクセス許可されたユーザー v95inst1 でアクセスし、ガード・ポイント上の暗号化されたファイルを、readしている様子です。ここで、readの際にデータを復号するようにポリシーを設定しています。

この時、図4のPolicy Composer画面で設定しているポリシーのように、”permit”ケースのSecurity RuleのEffectに”audit”を設定してあり、かつログレベルを”INFO”に設定してある場合、DEE Management ConsoleのLog画面のMessageには、Policy “sample_policy1”によってユーザー”v95inst1”がリソース“/home/v95inst1/guard/customer.del”に対して行った操作”/bin/cat”が許可“PERMIT”された旨が表示されます(図8)。図中の表の3列目のSeverityにある”I”はログレベルINFOを示しています。

リソースのreadは許可されているが、復号が行われないようにポリシーを設定していた場合は、図9のようにデータの中身を参照することはできても、データは暗号化されたままの状態で表示されます。

ポリシーでアクセス拒否されたユーザーでガード・ポイントへアクセスした場合はPermissionエラーが発生します。図10はアクセス拒否されているユーザー v95inst2 でガード・ポイントへアクセスしている様子です。このケースでは、OSで設定したガード・ポイントのディレクトリパーミッションは755で、v95inst2によるreadを許可していますが、DEEがポリシーに従ってアクセスを拒否しています。

この時、図4のPolicy Composer画面で設定しているポリシーのように、”deny”ケースのSecurity RuleのEffectに”audit”を設定してある場合、DEE Management ConsoleのLog画面にはPolicy “sample_policy1”によってユーザー”v95inst2”の操作”/bin/ls”が拒否された旨が表示されます(図 11)。図中の表の3列目のSeverityにある”E”はログレベルERRORを示しています。

上に戻る

Host Settingsによるアクセス制御

第1回でも少し触れましたが、オンライン・ポリシーで指定したSecurity Ruleの属性を基にしたアクセス制御を行う場合、オンライン・ポリシーの他にHost Settingsを設定する必要があります。Host Settingsではどのログイン方法を正規な方法として認めるか、どのプロセスをログイン方法に関わらず認めるかといった設定が行えます。例えばオンライン・ポリシーのSecurity RuleのUserで指定された許可ユーザーであってもHost Settingsの設定が正しくなされていなければ、ガード・ポイント上のリソースに対するアクセスが拒否されます。

Host Settingsの設定

DEE Management Consoleにホストを登録後 “Hosts”->(ホストを選択)->“Host Settings”を開くと、いくつかのログイン用のプロセスがリストされています。

/usr/bin/login
/usr/bin/su
/usr/sbin/sshd
/usr/sbin/ftpd
/usr/dt/bin/dtlogin

Host Settingsの設定は、これらリストされたプロセスの先頭にキーワードを付加することで行います。プロセスを追加して記述することもできます。キーワードの種類や効果はUNIXとWindowsとで異なります。本稿ではUNIXを取り上げて紹介します。Windowsに関しては参考文献にあるUser's Guideの6章「Configuring hosts」を参照ください。

UNIXではDEE FS Agentはデフォルトで、telnetやsshなどいかなる方法でログインしても、オンライン・ポリシーで明示的に許可されたユーザーや、許可されたプロセスからのガード・ポイントへのアクセスを拒否し、”User Not Authenticated”や”FAKED USER”というようなエラーをログに出力するようになっています(図12)。オンライン・ポリシーで許可されたユーザーでログインしている場合は”User Not Authenticated”というエラー、suコマンドを使って許可ユーザーになりすましている場合は”FAKED USER”というエラーが出力されます。

オンライン・ポリシーで特定の許可ユーザーを指定しないで全てのユーザーのアクセスを許可している場合はHost Settingsの設定はユーザーのアクセスに影響を与えませんが、”User Not Authenticated”はユーザーのアクセスが許可された場合であってもログに出力されます。

アクセスを許可するためには、以下のようなキーワードをHost Settings内の各プロセスの先頭に書く必要があります。本稿ではUNIXで定義可能なキーワードを記述(表4)します。Windowsではexempt、lockというキーワードが定義可能です。

例えば、telnetとsshによるログインを行うユーザーを認める場合、リスト3のようにキーワードを付加します。

|authenticator|/usr/bin/login
/usr/bin/su
|authenticator|/usr/sbin/sshd
/usr/sbin/ftpd
/usr/dt/bin/dtlogin

次に|trust|と|trustfrom|の違いを例に挙げます。例えば、バージョン9.5以前のDB2®のSystem Controllerプロセス(db2sysc)は多くの子プロセスを持つDB2の主要なプロセスですが、db2syscプロセスに対して|trust|を付加しても、その子プロセスはガード・ポイントへのアクセスを許可されず、ガード・ポイント上のDB2データベースに対して処理を行う場合、多くの子プロセスがUser Not Authenticatedエラーでアクセス拒否されます。このような場合、拒否された子プロセス全てに|trust|を付加するのではなく、db2syscプロセスに対して|trustfrom|を付加することで、その子プロセス全てのアクセスを許可することができます。（DB2 バージョン9.5以降、多くの子プロセスはdb2syscに統合されました。）

上に戻る

dataxformによる暗号化キー変換

dataxformはガード・ポイント上の暗号データに適用された暗号化キーを変換するためのユーティリティです。以下のような要件に答えます。

• 暗号化によってデータの保護を行う場合、セキュリティを維持するために定期的に暗号化キーを変更する必要がある。それに伴い、古い暗号化キーで暗号化したデータを、新しい暗号化キーで暗号化したデータへ変換する必要がある。
• 暗号化をやめたい場合、暗号化したデータを復号する必要がある。
• ガードを行う際、ガード・ポイントに暗号化を適用する前からガード対象となるディレクトリ上にあったデータを暗号化する必要がある。

dataxformではファイル・システムのガードと同様に、dataxform用のオンライン・ポリシーを作成し、暗号化適用のルールを設定しますが、通常のファイル・システムのガードに用いるオンライン・ポリシーの作成とは以下の3点が異なります。

• Security RulesのActionに”key_op”を指定する。
• Key Selection Rulesに変換前の暗号化キーを指定する。
• Data Transformation Rulesに変換後の暗号化キーを指定する。

暗号化を行わないキーとしては”clear_key”が提供されています。表5は暗号化キーの選択パターンの例を表しています。”key_A”と”key_B”はテスト用に作成した暗号化キーとします。

dataxformを実行する方法として、コマンドを発行して実行する方法と自動で実行する方法の2つがあります。以降それぞれの方法を解説していますが、いずれの場合もdataxform実行の前に、今までのオンライン・ポリシーのアンガードが、実行後に新しいオンライン・ポリシーのガードが必要になります。

コマンドを発行してdataxformを実行する方法

1. dataxform用のオンライン・ポリシーで、変換を実施したいディレクトリをガードします。

2. rootユーザーでdataxformコマンドを発行します。リスト4を参照してください。ここで、“/home/v95inst1/dxdir”はガード・ポイントのパスです。結果は/var/log/eet/eetdxf_root.logファイルでも参照可能です(リスト 5)

# dataxform --rekey --gp /home/v95inst1/dxdir
Attempting to contact the server in order to obtain setup information...
Successfully contacted server.
Checking if data transform is supported for guard point /home/v95inst1/dxdir.
Data transformation is supported on /home/v95inst1/dxdir
About to perform the requested data transform operation.
-- Be sure to back up your data.
-- Please do not access files in the guard point during the transform process.
-- Please do not attempt to terminate the application
Do you wish to continue (y/n)?y
Starting data transform of /home/v95inst1/dxdir.
　　　(中略)
Found internal file /home/v95inst1/dxdir/dataxform_auto_lock
Starting data transform of /home/v95inst1/dxdir/sample.txt.
Finished data transform of /home/v95inst1/dxdir/sample.txt.
Transformed 2 files (50 bytes) of 2 files (5 bytes) for guard point /home/v95inst1/dxdir.
Data transform for guard point /home/v95inst1/dxdir complete.
#

2009-01-14 23:06:50.198 [VMD] [INFO ] [27636] [EET4380I] Transformed 3 
files (95 bytes) of 3 files (50 bytes) for guard point /home/v95inst1/dxdir.
2009-01-14 23:06:51.197 [VMD] [INFO ] [27636] [EET4361I] Data transform for guard point 
/home/v95inst1/dxdir complete.

3. dataxform用のオンライン•ポリシーをアンガードします。

自動でdataxformを実行する方法

1. 変換を実施したいディレクトリ上にリスト6のようなdataxform用の設定ファイル(dataxform_auto_config)を作成します。dataxform_auto_configファイルの作成は、今までのオンライン・ポリシーをアンガードした後に行ってください。dataxform_auto_configの中身が暗号化されてしまうと、自動でdataxformを実行することができなくなります。

version=1 
--thd 4 --preserve_modified_time 

2. dataxform用のオンライン•ポリシーで、変換を実施したいディレクトリをガードします。

3. ガード適用後、dataxformが自動で実行されます。結果はDEE Management ConsoleのLog、及び/var/log/eet/eetdxf_root.log(リスト5と同様)で確認可能です。このとき、DEE FS Agentがガード・ポイント上にdataxform_auto_configファイルを見つけられない場合、一定時間(10秒)おきにリトライされます。この状態は、コマンドを発行してdataxformを実行する方法のステップ1も同じです。

4. dataxform用のオンライン•ポリシーをアンガードします。

dataxformの後処理

dataxform実行後、ガード•ポイント上にはdataxform_auto_lockというファイルが、またAgentのlogディレクトリ(UNIXの場合は/var/log/eet/、Windowsの場合は\Documents and Settings\All Users\Application Data\IBM\DBTOOLS\LUWEncryptionExpert\Agent\log)の下にdataxform_statusファイルが生成されます。これらはdataxform実行中・実行後の状態を記録し、同一ディレクトリに対してdataxformが多重に実行されるのを防ぐためのファイルですが、一度dataxformを行ったガード•ポイントに対して、再度異なるルールでdataxformを実行する場合はこれらのファイルを削除する必要があります。リスト 7はdataxformコマンドを使ったファイルの削除方法です。コマンドを発行してdataxformを実行する場合と同じく、rootユーザーでコマンドを発行します。

#dataxform --cleanup --gp /home/v95inst1/dxdir

上に戻る

DEE FS Agentの利用シナリオ例

シナリオ1. rootによる成りすまし防止

個人情報や機密データなどを安全に保つ為には外部からの攻撃者からの脅威に備えるだけではなく、データにアクセスする必要の無いユーザーによるデータアクセスを防ぐ必要があります。例えば、UNIXのシステムにおいて、システムの管理者(rootユーザー)とデータベースの管理者とが分かれている場合、DEEを利用することでrootユーザーによるデータの参照を防ぐ仕組みを実現できます。

DEEのオンライン•ポリシーを設定し、ガードすることでrootユーザーによるアクセスも拒否することができるようになります。しかしそれだけでは、rootユーザーがsuコマンドを利用して、アクセスが許可されているユーザーに成りすますことで、ガード・ポイントへアクセスすることができてしまいます。このようなrootユーザーによる成りすましを防止する方法としてHost Settingsの利用が考えられます。

UNIXにおいて、Host Settingsは、オンライン•ポリシーのUser Setを指定している場合、許可ユーザーがどのようなプロセスでガード・ポイントへアクセスすることができるかを設定できます。この場合はリスト8のように、ログイン・プロセスに対しては|authenticator|を付加することで許可し、suプロセス、つまり”/usr/bin/su”には|authenticator|を先頭に付加しないことで、suプロセスでログインしたユーザーのアクセスを拒否する設定になり、結果的にrootからsuを使って許可ユーザーになってからガード・ポイントにアクセスしても”FAKED USER”エラーが発生してアクセスが拒否されるように設定できます。プロセスの行頭に何も付加しない場合、そのプロセスに対するHost Settingsによるアクセス制御のデフォルトの振る舞いがアクセス拒否であることに注意してください。

|authenticator|/usr/bin/login
/usr/bin/su
|authenticator|/usr/sbin/sshd
|authenticator|/usr/sbin/ftpd
|authenticator|/usr/dt/bin/dtlogin

シナリオ2. オフライン・アーカイブ暗号化

情報ライフサイクル管理(Information Lifecycle Management)の一環として、古くなって参照・更新されなくなったデータをデータベースから削除したいが、監査目的で保管する必要があるため、アーカイブして残していくというケースがあります。中でもテープ装置などへデータを保管するオフライン・アーカイブはよく用いられますが、アーカイブしたデータのセキュリティを確保するための一つの方法として、データを暗号化してアーカイブすることが考えられます。ここではDEEを利用したオフライン•アーカイブ暗号化のシナリオを紹介します。図14は本シナリオの構成をあらわしています。

1. データベース管理者が、アーカイブ製品のアーカイブ処理機能を利用するなどしてデータを取り出し、そのデータを一旦DEE FS Agentのガード・ポイント上におきます。これを「オンライン・アーカイブデータ」とします。オンライン・アーカイブデータは、ガード・ポイント上に書き込まれる際にガード・ポイントに適用されたオンライン・ポリシーに従い、暗号化されます。
2. アーカイブデータの利用者が直接、あるいはアーカイブ製品のアーカイブ参照機能を利用してオンライン・アーカイブデータを参照しようとすると、ポリシーに従ってデータは復号され、ユーザーは正常にデータの中身を見ることができ、利用することができます。
3. データベース管理者が、テープ装置への保存機能を利用するなどして、オンライン・アーカイブデータをオフライン・アーカイブデータとして保管する際、ガード・ポイント上から取り出したデータは復号されず、暗号化された状態のまま保存されます。
4. データベース管理者が、テープ装置からの復元機能を利用するなどして、オフライン•アーカイブデータをオンラインに戻す場合は、テープに暗号化されて保存されている暗号化されたデータをそのままガード・ポイントへコピーします。
5. データベース管理者が、アーカイブ製品のインポート機能を利用するなどして、オンライン・アーカイブデータをデータベースに復元する場合、ガード・ポイントから取り出されたデータは復号され、データベースに戻されます。

以上のように、ガード・ポイント上にアクセスしたプロセスによって暗号化・復号をしたり・しなかったりというような設定は、ポリシーのSecurity Rulesを複数定義することで実現可能です。このシナリオでは例えば以下のように4つのSecurity Ruleを定義したオンライン・ポリシーを作成することが考えられます。

上に戻る

まとめ

第3回では、DEE FS Agentによるアクセス制御と暗号化によるオンライン・データの保護機能について解説しました。これによりデータベース内のデータやデータベースの設定ファイル、ログファイル、エキスポート・アーカイブファイルなどに対してOSの機能を超えたアクセス制限を実現し、またデータを暗号化して保存しておくことで、データの安全を確保することが可能になります。

参考文献

• IBM Database Encryption Expertを利用してデータを保護する：第1回　主な機能とメカニズム
  
  
• IBM Database Encryption Expertを利用してデータを保護する：第2回 主なセットアップとメンテナンス
  
  
• 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（バザール）

上に戻る