DB2 for i の RCAC、第1部：行アクセス権
ハッカーの世界では、あらゆるデータ資産は盗難や改ざんに対して脆弱です。データ保護はコストがかかりますが、ハッキングされる方がさらにコストが高くつきます。IBMの行列アクセス制御を実行してください。ビジネスがセキュリティー、特にデータベース・セキュリティーを制御する効果的なツールを求めている中で、RCACは重要なツールです。
RCAC によってデータベース・セキュリティー管理者は、データベースのデータを閲覧できるユーザーの管理を、引き締めることができます。さらによいことに、アプリケーションを変更せずに、これら多くのセキュリティー対策を実装できます。DB2 の各種バージョン、Postgre SQL、Oracle、SQL Server (Azure v12 および SQL Server 2016 を現在プレビュー中)、また他のデータベース・エンジンも、何らかの形で行のセキュリティーを実装できるため、喜ばしいことに IBM i で利用できます。このヒントでは、行アクセス・セキュリティーについてご紹介します。
前提条件は以下のとおりです。
1.IBM i 7.2 が必要です。
2.IBM Advanced Data Security for i (5770SS1 オプション 47) ライセンス・プログラム (無償) をインストールする必要があります。7.2 については、この製品にはメディア・ラベル i72_B_GROUP3_04.iso が付きます。
このライセンス・プログラムがインストールされていない場合、以下のような見苦しいエラーが表示されます。
SQL 状態:560CR
メッセージ:[SQL7056] Database support not available for reason 3. (データベース・サポートは理由 3 には利用できません。)
原因.....:必要なライセンス・プログラムがインストールされていません。
理由コードは 3 です。1 - IBM XML Toolkit for i (5733XT2) または International Components
for Unicode (5770-SS1) がインストールされていません。2 - Java Developer Kit 5.0 (5770JV1)、またはJ2SE 5.0 32 bit (5770JV1)、または J2SE 5.0 64 bit (5770JV1)、ポータブル・アプリ・ソリューション環境 (5770-SS1) がインストールされていません。3 - IBM Advanced Data Security for i (5770SS1 オプション 47) がインストールされていません。
リカバリー...:必要なライセンス・プログラムが正しくインストールされていることを確認してください。
もう一度要求をしてみてください。
3.1 人以上のユーザーをデータベース・セキュリティー管理者に指名します。この役割に属するユーザー・プロファイルは、他のユーザーに行データのアクセス権を割り当てることができますが、設定されていない限り、必ずしもデータを見ることはできません。
データベース・セキュリティー管理者
データベース・セキュリティー管理者の定義は Change Function Usage (CHGFCNUSG) IBM i OS コマンドで実施します。以下の例では、プロファイル QSECOFR を、データベース・セキュリティー管理者に割り当てます。これによって QSECOFR は、行 (および列) セキュリティー制限を課すことができます。しかし、いったん行アクセス権のセキュリティーがオンになると、この権限を持っていても QSECOFR は、(*ALLOBJ 権限があっても) データを見ることはできません。QSECOFR は許可が得られた場合のみ、データを見ることができます。これは利害の分離であり (データベース・セキュリティー管理者は必ずしもデータを見る必要がないため)、システムをセキュアに保つのに役立ちます。
CHGFCNUSG FCNID(QIBM_DB_SECADM) USER(QSECOFR) USAGE(*ALLOWED)
複数のユーザーまたはグループのプロファイルを、データベース・セキュリティー管理者特権として割り当てることができます。これらの特権は、 Display Function Usage (DSPFCNUSG) コマンドを使用して、ホスト端末で確認できます。
DSPFCNUSG FCNID(QIBM_DB_SECADM)
表の行へのアクセスを制限する
顧客データ表のサンプル QIWS.QCUSTCDT に機密情報が含まれており、できるだけ行に細かくアクセスしなければならないとしましょう (一部のユーザーはある特定の行を見ることができますが、他のユーザーはできません)。さらにこれはすべて、表にアクセスするレガシー・アプリケーションを変更せずに行います。ここで、行アクセス権が救いの手を差し伸べることができます。
最初のステップとして、表の行アクセス制御をアクティブにするため、以下の ALTER TABLE ステートメントを使用します。
ALTER TABLE QIWS.QCUSTCDT ACTIVATE ROW ACCESS CONTROL;
行アクセス制御は、以下のようにほぼ同様に無効にできます。
ALTER TABLE QIWS.QCUSTCDT DEACTIVATE ROW ACCESS CONTROL;
当然、ALTER TABLE ステートメントが実行中は、表は使用できません。しかし、いったん表で行アクセス制御がアクティブになると、表に排他的にアクセスしなくても (次に示す) 定義済みの各セキュリティー権限をオン/オフできます。
行アクセス制御が有効になると、データベース・セキュリティー管理者は新しい CREATE PERMISSION ステートメントを使用して、どの条件で特定の表の行にアクセスできるか定義することができます。また、権限ルールは時刻、行内の列の値などに基づいて作成できるとしても、通常は、表の行にアクセスする権限は、ユーザーまたはグループのプロファイルに基づいて作成されています。
この例では、表 QIWS.QCUSTCDT の行は、ユーザー・プロファイル WEBUSER および APPUSER の下で接続されたデータベース (ネイティブ I/O を含む) にのみアクセスできるように、権限が作成されています。
CREATE PERMISSION QCUSTCDT_QPGMR ON QIWS.QCUSTCDT
FOR ROWS
WHERE CURRENT_USER IN ('WEBUSER','APPUSER')
ENFORCED FOR ALL ACCESS ENABLE
CREATE PERMISSION ステートメントの WHERE 節は、どの行にアクセスできるかという環境を決定するルールを指定します。他のユーザー・プロファイルがこの表に対してクエリーまたは DML ステートメントを実行すると、ゼロ行が返されるか、または影響を受けます。レガシー・アプリケーションが引き続き機能できるようにするデータが照会される場合、セキュリティー関連のエラー・メッセージはスローされません。権限は表にのみ割り当てられ、ビュー、別名、または一時表には割り当てることができない点に注意してください。
ユーザー・プロファイルに基づくルールは維持することが難しいため、以下のようにグループ・プロファイルのメンバーシップもテストできます。
CREATE PERMISSION QIWS.QCUSTCDT_QPGMR
ON QIWS.QCUSTCDT
FOR ROWS WHERE
(VERIFY_GROUP_FOR_USER(CURRENT_USER, 'QPGMR') = 1)
ENFORCED FOR ALL ACCESS ENABLE
このインスタンスでは (SESSION_USER、USER、または CURRENT_USER のいずれかの特殊レジスターをたまたま利用できるだけの) VERIFY_GROUP_FOR_USER 関数を使用して、現行ユーザーが QPGMR グループ・プロファイルのメンバーかどうかテストします。この関数は、要求されたユーザーが指定したグループのメンバーの場合 1 を返し、メンバーでない場合は 0 を返します。SESSION_USER および USER は同じ値、すなわち DB2 に接続されたユーザー・プロファイルを報告します。CURRENT_USER は似ていますが、現在の借用権限プロファイルを返す点が異なります。どのユーザー特殊レジスターを渡すかという選択は、借用権限がアクセス権に影響するかどうかによって異なります。SYSTEM_USER 特殊レジスター (ジョブ・ユーザーと同義) は、この関数とともに使用できません。
VERIFY_GROUP_FOR_USERも、複数のグループ・メンバーシップを同時にテストすることができます。この例では、QPGMR グループまたはAPPPROFILE グループに属するユーザーはすべての行にアクセスできます。
CREATE OR REPLACE PERMISSION QIWS.QCUSTCDT_GROUPS
ON QIWS.QCUSTCDT
FOR ROWS WHERE
( VERIFY_GROUP_FOR_USER(CURRENT_USER, 'QPGMR','APPPROFILE') = 1 )
ENFORCED FOR ALL ACCESS ENABLE
同じ表に複数のアクセス権を割り当てることができます。例えば、任意のユーザー・プロファイルが「取るに足らない」顧客の顧客エントリーを確認できる場合 (信用限度が 1000 以下の場合)、以下のアクセス権も適用できます。
CREATE OR REPLACE PERMISSION QIWS.QCUSTCDT_LOW_CREDIT
ON QIWS.QCUSTCDT
FOR ROWS WHERE CDTLMT<=1000
ENFORCED FOR ALL ACCESS ENABLE
これで、データ読み取り権を持つすべてのユーザー・プロファイルが、信用限度 (CDTLMT) が $1,000 以下のすべての行を見ることができるようになります。
行が DB2 によりアクセスされると、表のすべての行アクセス権定義が (OR 演算子で) 評価されるため、1 つ以上のルールで特定のユーザー (または他の基準) にアクセス権が与えられる場合は必ず、行にアクセスできます。または、以下の場合に、すべての条件を組み合わせることができます。
CREATE OR REPLACE PERMISSION QIWS.QCUSTCDT_ACCESS
ON QIWS.QCUSTCDT
FOR ROWS WHERE
CURRENT_USER IN ('WEBUSER','APPUSER')
OR ROWS WHERE CDTLMT<=1000
ENFORCED FOR ALL ACCESS ENABLE
しかし、個別にアクセス権を定義すると、アクセス権を細かく有効または無効にすることが、簡単にできなくなります。例えば、QPGMR プロファイル・ルールが、月末またはある保守時間枠中の唯一許可されたアクセス権の場合、アクセス権を意のままに簡単に有効にしたり、無効にしたりできます。
CREATE PERMISSION QCUSTCDT_QPGMR ON QIWS.QCUSTCDT
FOR ROWS WHERE
( VERIFY_GROUP_FOR_USER(CURRENT_USER, 'QPGMR') = 1 )
ENFORCED FOR ALL ACCESS DISABLE
これらの例で明確になったように、行アクセス権はユーザーまたはグループのプロファイル以外の条件でも許可できます。表 ADVWORKS.CUSTOMER 内では、顧客は顧客タイプの列で店舗または個人として分類されます。以下のように、ユーザーは、過去 30 日間で更新された「個人」の顧客および店舗の顧客の行に常にアクセスできるよう、アクセス権を作成することができます。
CREATE OR REPLACE PERMISSION ADVWORKS.CUSTOMER_INDIVIDUALS
ON ADVWORKS.CUSTOMER
FOR ROWS WHERE MODIFIEDDATE>=CURRENT_DATE - 30 DAYS
OR CUSTOMERTYPE='I'
ENFORCED FOR ALL ACCESS ENABLE
その他の利点として、以下のようにアクセス権定義でグローバル変数を使用して、任意の日数にデータ・アクセスを制限できます。
CREATE OR REPLACE VARIABLE ADVWORKS.MODIFIEDDAYS INT DEFAULT 7
CREATE OR REPLACE PERMISSION ADVWORKS.CUSTOMER_INDIVIDUALS
ON ADVWORKS.CUSTOMER
FOR ROWS WHERE MODIFIEDDATE>=CURRENT_DATE -
ADVWORKS.MODIFIEDDAYS DAYS
OR CUSTOMERTYPE='I'
グローバル変数の内容を制御することで、アプリケーションはアクセス可能な行を動的に制御できます。しかし、これによってセキュリティー・ホールの可能性とアプリケーションの汎用性という昔ながらの板挟みが生まれます。しかし、一般的に、適切なユーザーがすべての行を見ることができるような環境があるはずです。
*ALLOBJ は適用しない
データベース・セキュリティー管理者機能を備えたユーザー・プロファイルは、行アクセス権で保護されたデータに、自動的にはアクセスできません。例えば、(上記の例のように) 表 QIWS.QCUSTCDT が現行ユーザーが WEB_USER か APP_USER チェックする単一の行アクセス権で制限されている場合、QSECOFR で以下のクエリーを実行すると、QSECOFR に *ALLOBJ 特殊権限があっても、デフォルトでゼロ行を返します。
SELECT * FROM QIWS.QCUSTCDT
有効になった行アクセス権の問題を調査する
開発者およびアプリケーション・ユーザーに、行アクセス権について指導することが大切です。ERP レポート 2 件 (ネイティブ RPG I/O ベースのものと SQL ベースのもの) が一致しなくなっているという苦情を開発者に渡す、ヘルプ・デスクを想像してみてください (また、根本原因は RPG プログラムと SQL プログラムが異なるユーザーの下で動作していることによる、行アクセス権制限の差です)。行アクセス権はアプリケーション・レベルでは作動しないため、RCAC を考慮しないと、開発者は多大な時間を費やしてデータが一致しなくなった理由を解明せざるを得なくなる可能性があります。
以下のように、あるパーティションで定義された行アクセス権についていくつかの方法で解明します。
1.System i Navigator のデータベース・ノードでは、求めるスキーマを詳しく調べ、「行アクセス権」ノードの下のエントリーを調査する。
2.SYSCONTROLS カタログ・ビュー (「R」の CONTROL_TYPE of 'R' は行アクセス権を示す)
行アクセス権と DML
行アクセス権の効果は、 SELECT ステートメントを使用した場合のみ現れますが、アクセス権は、 INSERT、MERGE、UPDATE、DELETE などのデータ変更言語 (DML) ステートメントにも適用されます。例えば、上記の単一のアクセス権 QCUSTCDT_LOW_CREDIT の下であるユーザーが行にアクセスしている場合、信用限度が $1,000 以下の行のみアクセスおよび操作できます。ユーザーが信用限度が $1,000 を超える行を挿入しようとすると、DB2 は以下のエラーをスローします。
メッセージ ID ......: SQ20471
メッセージ:...: INSERT or UPDATE does not satisfy row permissions. (INSERT または UPDATE は行アクセス権を満たしません。)
原因.....: QIWS の QCUSTCDT に対して行アクセス制御が実施されています。
その結果、その表で行を挿入または行を更新しようとすると結果生じる行が、表で定義された行アクセス権に従っているかどうか確認されます。INSERT または UPDATE は実行できませんでした。
結果生じる行が、QIWS の QCUSTCDT に対して 1 つ以上の行アクセス権を満たすことができなかったためです。
リカバリー...: 挿入または変更しようとしているデータが、行アクセス権に定義されたルールに従うよう変更してください。
このシナリオでは、新しいエラー条件を処理するようアプリケーションを変更しなければならない例を示します。
RCAC およびその他のセキュリティー
RCAC (特に、行アクセス権) の実装は、アプリケーションおよびデータベース・オブジェクトのセキュリティーを、責任を持って確保するための代替手段ではありません。代わり映えのしない通常のデータベースおよびアプリケーションの権限も適用されます。行アクセス権は、ユーザーを一片の表データにさらに制限する 1 つの方法ですが、それでも、ユーザーが完全にデータを表示または変更できるかどうか制御する必要があります。
パフォーマンス
行アクセス権の定義により、DB2 が行カウントを首尾よく正確に見積もることができない場合、行アクセス権の実装によってパフォーマンスの問題が発生するおそれがある点に注意してください。アクセス権関数は慎重に定義し、パフォーマンスへの影響を評価してください。
結論
行アクセス権は、必ずしもアプリケーションを変更しなくても、データを効果的に保護する手段を提供します。このセキュリティーは、データベース・エンジンで処理されるため、回避する手段はありません。データが、ネイティブ I/O、Query/400、ODBC、JDBC、OLE DB などを経由した、 SQL アクセスのいずれで要求されていても関係ありません。今後のヒントでは、行アクセス権のあるトリガーおよび関数、また列マスクの実装についてお話しします。
