CREATE PERMISSION

CREATE PERMISSION ステートメントは、現行サーバーで行アクセス制御のための行の許可を作成します。これは search-condition の結果に基づいて 表内の使用可能な行を決定します。

呼び出し

このステートメントは、アプリケーション・プログラムに組み込むことも、 あるいは対話式に実行することもできます。 これは、動的に準備できる実行可能ステートメントです。

権限

このステートメントの許可 ID には、セキュリティー管理者権限 がなければなりません。 管理権限を参照してください。

構文

構文図を読む構文図をスキップする
>>-CREATE--+------------+--PERMISSION--permission-name--ON--table-name--+--------------------------+-->
           '-OR REPLACE-'                                               | .-AS-.                   |   
                                                                        '-+----+--correlation-name-'   

>--FOR ROWS WHERE--search-condition--ENFORCED FOR ALL ACCESS---->

   .-DISABLE-.   
>--+---------+-------------------------------------------------><
   '-ENABLE--'   

説明

OR REPLACE
行権限の定義が現行サーバー上に存在している場合に、その定義を置換するために指定します。 既存の定義は、新しい定義がカタログ内で置換される前に、効率的にドロップされます。
permission-name
行アクセス制御の行の許可の名前を指定します。暗黙的または明示的修飾子も含め、この名前は、現行サーバーに既に存在している列マスクまたは行の許可と同じ名前にすることはできません。permission-nameQIBM で始まってはなりません。

SQL 名が指定されている場合、許可は、暗黙的または明示的修飾子で 指定しているスキーマ内に作成されます。

システム名が指定されている場合、許可は、修飾子で指定しているスキーマ内に作成されます。 修飾されておらず、デフォルトの スキーマがない場合、許可は table-name と同じスキーマに作成されます。

permission-name の スキーマ名は、table-name のスキーマ名と同じでなければなりません。

table-name
列権限を作成する対象の表を指定します。この名前は、現行サーバーに存在する表を示すものでなければなりません。宣言済み一時表、 QTEMP 内の表、分散表、ビュー、論理ファイル、メンバー別名、読み取りトリガーのあるファイル、またはカタログ表を 示すものであってはなりません。
correlation-name
表を指定するために search-condition 内で使用できる相関名を指定します。
FOR ROWS WHERE
行の許可が作成されることを指定します。行の許可は、表の行にアクセスできる検索条件を指定します。
search-condition
表の行について真、偽、または不明となる条件を指定します。
search-condition は、WHERE 文節の検索条件に使用される規則に従います。また、以下のものは、いずれも参照してはなりません。
  • 行の許可が定義される表
  • 宣言済みグローバル一時表
  • 変数 (ホスト変数、SQL 変数、SQL パラメーター、またはトリガー遷移変数)
  • パラメーター・マーカー
  • NOT SECURED として定義されているユーザー定義関数
  • 非 deterministic 関数または外部アクションを持つ関数
  • OLAP 指定
  • ROW CHANGE 式
  • シーケンス参照
  • SELECT 文節内の * または name.*
  • QTEMP 内の表
  • メンバー別名
  • 分散表
  • 読み取りトリガーのあるファイル
  • 複数フォーマット論理ファイル
  • リモート・オブジェクト
  • 上記のいずれかを含んでいるビュー
ENFORCED FOR ALL ACCESS
行の許可がこの表のすべての参照に適用されることを指定します。この表で行アクセス制御がアクティブになっている場合、データ操作ステートメントでこの表が参照されていると、DB2® は表のアクセスを制御するため、行の許可を暗黙に適用します。SELECT などのフェッチ操作で表が参照される場合、行の許可の適用によって、フェッチ操作を要求したユーザーが取得できる行のセットが決まります。 INSERT などのデータ変更操作で表が参照される場合、行の許可の適用によって、データ変更操作を要求したユーザーが、すべての変更対象行を挿入または更新できるかどうかが決まります。
ENABLE または DISABLE
行アクセス制御で行の許可を有効または無効に初期設定することを指定します。
DISABLE
行アクセス制御で行の許可を無効にすることを指定します。表の行アクセス制御が活動化されている かどうかに関係なく、行の許可は無効なままになります。これはデフォルトです。
ENABLE
行アクセス制御で行の許可を有効にすることを指定します。この表の行アクセス制御が現在アクティブになっていない場合、行の許可は、表の行アクセス制御がアクティブになった時点で有効になります。表の行アクセス制御 が現在アクティブになっている場合、行の許可は直ちに有効になります。

注意

前提条件: 許可 を作成するためには、IBM® Advanced Data Security がインストールされている必要があります。

行の許可の適用方法および 特定のステートメントへの影響: 行アクセス制御を活動化する方法と、行の許可がどのように適用されるのかについては、 ACTIVATE ROW ACCESS CONTROL 節が指定された ALTER TABLE ステートメントの説明を 参照してください。 行の許可の適用によるフェッチ操作への影響については、副選択の説明を参照してください。行の許可の適用によるデータ変更操作への影響については、データ変更ステートメントを参照してください。

表の行アクセス制御がアクティブになる前に作成する行権限: CREATE PERMISSION ステートメントは独立したステートメントであり、これを使用して、表の行アクセス制御がアクティブになる前に行権限を作成できます。 唯一の要件は、権限の作成前に表と列が存在していることです。 1 つの表に対して、複数の行権限を作成できます。

行権限の定義は DB2 カタログに格納されます。 権限の作成対象となる表への従属関係と、当該の定義で参照されるその他のオブジェクトへの従属関係が記録されます。 行アクセス制御のために、行権限を使用可能または使用不可なものとして作成できます。 使用可能に設定された行権限は、ACTIVATE ROW ACCESS CONTROL 節が指定された ALTER TABLE ステートメントを使用して表の行アクセス制御をアクティブにすると、初めて有効になります。 表の行アクセス制御がアクティブになっても、使用不可に設定されている行権限は引き続き無効です。 ALTER PERMISSION ステートメントを使用して、ENABLE と DISABLE を切り替えることができます。

表の行アクセス制御をアクティブにした後に、データ操作ステートメントで表が参照されるときに、その表に定義されたすべての使用可能な行権限が DB2 によって暗黙的に適用されて、その表へのアクセスが制御されます。

表の行アクセス制御がアクティブになった後に作成する行権限: 使用可能に設定された行権限は、コミットされるとすぐに有効になります。 したがって、データ操作ステートメントで表が参照されている場合、有効な行の許可はすべて、そのステートメントに暗黙に適用されます。表の行アクセス制御がアクティブになっても、無効な行の許可はすべて引き続き無効です。

行アクセス制御または列アクセス制御が施行されている表を行権限定義内で参照している場合、カスケード効果はない: 行権限定義で、行アクセス制御または列アクセス制御が現在施行されている表と列を参照することがあります。 行の許可の作成対象の表がデータ操作ステートメントで参照される場合、このような表のアクセス制御は無視されます。

許可の DECRESULT オプション: 許可の DECRESULT オプション は、常に最大精度 63、最大位取り 63、および最小除算位取り 0 を使用します。

例 1: 行の許可 SALARY_ROW_ACCESS 内のセキュアなユーザー定義関数 ACCOUNTING_UDF は、列 SALARY の機密データを処理します。表 EMPLOYEE の行アクセス制御がアクティブになった後に、会計士の Paul が、年収 100,000 ドルの従業員 (EMPNO 123456) の給与を取り出します。ユーザー定義関数 ACCOUNTING_UDF の出力値に応じて、Paul に対してこの行が表示される場合と表示されない場合があります。

CREATE PERMISSION SALARY_ROW_ACCESS ON EMPLOYEE
   FOR ROWS WHERE VERIFY_GROUP_FOR_USER(SESSION_USER,'MGR','ACCOUNTING') = 1
                  AND
                  ACCOUNTING_UDF(SALARY) < 120000
   ENFORCED FOR ALL ACCESS
   ENABLE;

COMMIT;

ALTER TABLE EMPLOYEE
ACTIVATE ROW ACCESS CONTROL;

COMMIT;

SELECT SALARY FROM EMPLOYEE
   WHERE EMPNO = 123456;
例 2: 銀行の現金出納係は、所属支店の顧客のデータのみにアクセスできます。 すべての現金出納係に対し、2 次許可 ID として TELLER が割り当てられています。顧客サービス担当者は、銀行の全顧客のデータにアクセスできます。すべての顧客サービス担当者に対し、2 次許可 ID として CSR が割り当てられています。 セキュリティー管理者権限を持つ者が定義したこれらのアクセス規則に従って、行員のグループごとに行の許可が 作成されます。表 CUSTOMER の行アクセス制御がアクティブになった後、各グループがアクセスできる行セットを 制御するため、SELECT ステートメントで両方の行の許可の検索条件がこのステートメントにマージされ、 論理 OR 演算子で結合されます。
CREATE PERMISSION TELLER_ROW_ACCESS ON CUSTOMER
   FOR ROWS WHERE VERIFY_GROUP_FOR_USER(SESSION_USER,'TELLER') = 1
                  AND
                  BRANCH = (SELECT HOME_BRANCH FROM INTERNAL_INFO
                            WHERE EMP_ID = SESSION_USER)
   ENFORCED FOR ALL ACCESS
   ENABLE;

COMMIT;

CREATE PERMISSION CSR_ROW_ACCESS ON CUSTOMER
   FOR ROWS WHERE VERIFY_GROUP_FOR_USER(SESSION_USER,'CSR') = 1
   ENFORCED FOR ALL ACCESS
   ENABLE;

COMMIT;

ALTER TABLE CUSTOMER
   ACTIVATE ROW ACCESS CONTROL;

COMMIT;

SELECT * FROM CUSTOMER;