読者から読者へ: フィールド中のFieldproc
7.1の新しいツールで列情報を暗号化
クレジット・カード番号、社会保障番号、その他の機密情報について心配になりませんか。もうイライラする必要はありません。IBMのリリース7.1ではfieldprocという新しいツールが提供されており、列情報の暗号化を容易にしてくれます。
本質的にfieldprocはレコード・レベルではなくフィールド・レベルで実装されているおなじみのデータベースのトリガです。一言で言うとその動作原理は次の通りです。テーブルを作成して (そうです、テーブルでなくてはなりません。残念ながらfieldprocはCRTPFでは利用できません。) 、以下の例のように「fieldproc」というパラメータを付けてプログラムを呼び出すように指定します。
コマンド・ラインから次のように入力します。
- STRSQL
以下のように入力してテーブルを作成します。
- CREATE TABLE DATA/TableName (
- ColumnName CHAR (128) CCSID 0037 NOT NULL WITH DEFAULT
- fieldproc QKLIB/FPENC('TableName','ColumnName'))
次に列を暗号化し、そして一部を復号化するためのプログラムを作成します。以上です。これくらい本当に簡単なのです。 さて、fieldprocはどのようにして暗号化/復号化を行うのでしょうか。列にデータを追加した時、fieldprocプログラムに新しい列データが渡されます。fieldprocはこのデータを暗号化し、平文ではなく同じ列に書き戻しますので元のデータはもう保存されておらず暗号化されたデータが保存されています。この列のデータを表示しようとすると、fieldprocプログラムに暗号化されたデータが渡されて復号化され呼び出し元のプログラムに返されます。
暗号化について詳しい方はここにちょっとした問題があることにお気づきになったかも知れません。つまり、暗号化されたデータは平文よりも長くなっているということです。ではfieldprocは暗号化されたデータをどのようにして同じフィールドに保存しなおしているのでしょうか。別にしかけはありません。同じフィールドに保存し直すことはできないのです。「fieldproc」パラメータで列を作成するときはビジネス・データを保存するのに十分な長さを用意するだけでなく、暗号化されたビジネス・データを保存するのに十分な長さを確保しなければなりません。暗号化されたデータを保存するのに必要な実際のフィールドのサイズは特定の暗号化スキーマに依存します。たとえば(図―1の呼び出しCに示されている通り)DESが実装されている場合、平文のテキストのサイズよりも大きい最初の8の倍数に丸めておく必要があります。たとえば、暗号化したいデータの最大サイズが10文字の長さである場合、暗号化されたデータに合うサイズは16文字の長さが必要となります。
もう少し詳しく見てみましょう。上記の例では「fieldproc」によりfieldprocプログラムに渡すパラメータのリストを指定することができる点に注意してください。これによりfieldprocプログラムが呼び出されているテーブルや列(それ以外の方法では提供できない情報)をfieldprocに正確に知らせることができ、その列固有のアクションを実行することができるようにします。たとえば、同じfieldprocプログラムを使って1つの権限リストを設定してクレジット・カード情報を表示したり、別の権限リストを設定して社会保障番号を表示したりすることができます。もちろん好きなスキーマを使っていていただいてかまいませんが、私はテーブル名の後に列名を続け手渡すという標準化を行っています。
fieldprocプログラムの中を見てみましょう。fieldprocプログラムは本稿の冒頭にあるリンクからダウンロードすることができます。(図―1に関して述べている箇所はすべてfieldprocプログラムの詳細についてですので、ダウンロードして理解していただければ一番わかりやすいでしょう。)パラメータは全部で8個あり、QSYSINC/QRPGLESRC、SQLFPで定義されています。簡単に説明すると以下のとおりです。funcodeはプログラムに対して列データを暗号化しているのか復号化しているのかを知らせます。DS_Optには「fieldproc」で指定したパラメータが入っています(われわれの例の場合テーブル名と列名になります)。DS_DeTypは平文データのサイズを指定します。DeCodDtaには平文データが入っています。DS_EnTypは暗号化されたデータのサイズを指定します。EnCodDtaには暗号化されたデータが入っています。Sqlstateはエラー・コードです。SqMsgはエラー・テキストです。
fieldprocプログラムは非常にわかりやすいプログラムですが、xGetOptParmとxGetFieldAttrという2つのサブルーチンはもう少し説明が必要です。XGetOptParmはDS_Optパラメータを入力として受け取って構文を解析し、テーブル名と列名を抽出します。残念ながらIBMの開発者はQSYSINC/QRPGLESRC.SQLFPデータ構造がパラメータを渡すためのものであると十分には記述していませんでしたので、渡されたデータにアクセスするには若干の調整が必要となります。 SQLFPLフィールドには渡された各パラメータ(われわれの例の場合テーブル名用に1つ、列名用に1つ)のデータ構造が含まれていますが、 このフィールドはわずか1バイトのフィールドとして定義されています。(おそらくこれを使う人などいないと彼らは考えたのでしょう。) 渡されたパラメータ情報を受け取るために私はこのフィールドを500バイトに拡張しました(図―2の呼び出しB)。(図―2に関して述べている箇所はすべてfieldprocプログラムのデータ構造の詳細についてですので、ダウンロードして理解していただければ一番わかりやすいでしょう。) 同様に、SQLFPD01は渡された各パラメータの中身を定義するデータ構造ですが、このフィールドもまた1バイトで定義されています。私はこれを100バイトに拡張しました(図―2の呼び出しA)。
xGetFieldAttrsdffdeは列固有のコードを格納しておくフィールドです。上記の例では列に対して「fieldproc」パラメータを128バイトとして指定しました。しかしビジネス・データが32バイトを超えることはないのでこれでは多過ぎです。したがってここではビジネス・データだけが暗号化されるように入力パラメータ長を32バイトとしました(図―1の呼び出しA)。128バイトすべてを暗号化しようとする場合は、暗号化されたデータが128バイトよりも長くなってしまい、fieldprocが機能しなくなることに注意してください。またこのルーチン中ではデータを参照できるユーザーの権限リストを設定しました(図―1の呼び出しB)。もっと良い方法として、権限リストをデータベース・ファイル中に置くという方法もあるかもしれませんが、その場合はfieldprocプログラムに対するセキュリティだけでなく、このファイルに対するセキュリティにも対処しなければなりません。権限を与えられていないユーザーがこのデータへアクセスしようとすると、列データがすべてアスタリスクで満たされた状態で値が返されます。実際、権限を与えられてないユーザーがテーブル上でCPYFを実行しようとすると、新しいファイルでは「fieldproc」で保護されている列がアスタリスクで満たされたものとなります。
もちろんここで焦点を当てているのはfieldprocですが、fieldprocを効果的に使用するために中心となる暗号化ルーチンについて少しだけ触れておきましょう。fieldprocプログラムはIBMの強力な暗号サービス用APIを利用しており、そのプロトタイプは「inclcsapi」と「inclerror」のお手本のプログラムに含まれています。(これらはともに上記のリンクからダウンロード可能です。) 実際に実現したいセキュリティのレベルは暗号化キーをどれくらいうまく制御しているかに大きく依存しているということを忘れずにおいてください。fieldprocプログラムでは説明を簡単にするために暗号化キー(図－1の呼び出しD)は単純にハードコードされていますが、もっと良い解としては本稿の主旨からは外れてしまいますが、念入りに考え抜かれたキーの管理ソリューションとなります。
もう1つの変化球はこちらです。fieldprocプログラムをデバッグすることはできません。ええと、少なくとも今まで慣れ親しんできた方法ではデバッグができません。というのも、fieldprocはトリガ・プログラムとしては2番目のスレッドで実行されるためです。fieldprocプログラムをデバッグするには2つのセッションが必要です。1つ目のセッションを「fieldprocセッション」と呼び、2つ目のセッションを「デバッグ・セッション」と呼びましょう。まずfieldprocセッションでCHGJOB DFTWAIT(600)と入力してデバッグ中にジョブがタイムアウトにならないようにします。次にデバッグ・セッションではSTRSRVJOBと入力すると同時にジョブ名、ジョブ番号、fieldprocセッションのユーザーを指定してサービス・ジョブを作成します。またデバッグ・セッションではSTRDBG FPENC (またはfieldprocプログラムの名前)を入力してプログラムのソースを表示させ、ここにブレークポイントを追加することができます。ここでfieldprocセッションに戻って作成したfieldprocパラメータを含んだテーブルにアクセスすると、デバッグ・セッションは設定したブレークポイントでfieldprocプログラムを表示します。とてもスムーズですね。
以上です。QSYSINC/QRPGLESRCとSQLFPを変更してパラメータを渡すのに必要なフィールドを拡張し、テーブルに「fieldproc」キーワードを追加してxGetFieldAttrサブルーチンを実際のフィールド長と権限リストで修正しておけば、監査委員を日没まで寄せつけずにおくことができます。
