CREATE PERMISSION ステートメント
CREATE PERMISSION ステートメントは、現行サーバーで行アクセス制御のための行の許可を作成します。
呼びかけ CREATE PERMISSION
このステートメントは、アプリケーション・プログラムに組み込むか、あるいは対話式に発行することができます。 これは、DYNAMICRULES RUN動作が有効になっている場合にのみ、動的に準備できる実行可能なステートメントです。 詳細は、「Authorization IDs and dynamic SQL」 を参照してください。
承認 CREATE PERMISSION
以下に定義する特権セットには、次に示す権限が含まれていなければなりません。
- SECADM 権限
SECADM 権限では、任意のスキーマに行権限を作成できます。 権限定義内でその他のオブジェクトを参照するために必要なその他の特権はありません。 例えば、表からデータを取り出すための SELECT 特権や、ユーザー定義関数を呼び出すための EXECUTE 特権は必要ありません。
特権セット:
アプリケーション・プログラムにこの ステートメントを組み込む場合、特権セットは、パッケージの所有者が持つ特権となります。 このステートメントが動的に準備される場合、特権セットは、プロセスの SQL 許可 ID が持つ特権セットとなります。 ただし、ROLE AS OBJECT OWNER AND QUALIFIER 文節で定義されているトラステッド・コンテキスト内でプロセスが実行されている場合、特権セットは、有効なロールが持つ特権セットとなります。
構文 CREATE PERMISSION
説明の対象: CREATE PERMISSION
- 許可名
- 行アクセス制御の行の許可の名前を指定します。 この名前 (暗黙修飾子または明示修飾子を含む) には、現行サーバーに既に存在する行の許可または列マスクを指定しないでください。
- ON テーブル名
- 行権限を作成する対象の表を指定します。 この名前は、現行サーバーに存在する表を示すものでなければなりません。 以下のオブジェクトを指定することはできません。
- 補助表
- 作成済みまたは宣言済みの一時表
- ビュー
- カタログ表
- 別名
- シノニム
- マテリアライズ照会表の定義で直接または間接的に参照される、マテリアライズ照会表または表
- XML 列のために暗黙的に作成された表
- 期間が含まれている表
- 履歴表
- アクセラレーターのみの表
- アーカイブ可能な表
- アーカイブ表
- セキュリティー・ラベル列が含まれている表。
- 相関名
- 表を示すために search-condition 内で使用できます。 相関名については、「相関名」 を参照してください。
- FOR ROWS WHERE
- 行権限が作成されることを示します。 行権限は、表の行にアクセスできる検索条件を指定します。
- 検索条件
- 表の行について真、偽、または不明となる条件を指定します。 search-condition は、副選択の WHERE 文節の検索条件に使用される規則に従います。 また、検索条件では以下のオブジェクトのいずれも参照してはなりません。
- リモート・オブジェクト
- 行の許可が定義される表
- セキュリティー・ラベル列が含まれている表
- 作成済みのグローバル一時表または宣言済みのグローバル一時表
- 補助表
- XML 列のために暗黙的に作成された表
- コレクション派生表 (UNNEST)
- 表関数
- ホスト変数、SQL 変数、SQL パラメーター、またはトリガー遷移変数
- 非セキュアとして定義されているユーザー定義関数
- 非 deterministic 関数または外部アクションが含まれている関数
- パラメーター・マーカー
- FIELDPROC を使用して定義されている列
- LOB 列、または LOB に基づく特殊タイプ列
- XML 列
- XMLEXISTS 述部
- OLAP 仕様
- ROW CHANGE 式
- シーケンス参照
- SELECT 文節内の選択リストの表記:
*またはname.* - 期間指定が含まれている表参照。
- 前述のいずれかの制限が定義に含まれるビュー。
テーブルの符号化スキームは、 検索条件の評価に使用される。 Unicode 列が入っている EBCDIC 表を除く、複数のコード化スキーム評価を必要とする表および言語エレメントを search-condition で参照してはなりません。 これらの言語要素の文字列については、符号化スキームとCCSIDの規則を参照のこと。
行アクセス制御または列アクセス制御がアクティブな表を search-condition で参照している場合、これらの表のアクセス制御はカスケードされません。
- ENFORCED FOR ALL ACCESS
- 行権限がこの表のすべての参照に適用されるよう指定します。 テーブルに対して行アクセス制御が有効になっている場合、データ操作文でテーブルが参照されると、 Db2 は暗黙的に行権限を適用してテーブルへのアクセスを制御します。 SELECT などのフェッチ操作で表が参照される場合、行権限の適用により、フェッチ操作を要求したユーザーが取得できる行セットの内容が決まります。 INSERT などのデータ変更操作で表が参照される場合、行の許可の適用によって、データ変更操作を要求したユーザーが、すべての変更対象行を挿入または更新できるかどうかが決まります。
- DISABLE または ENABLE
- 行アクセス制御で行の許可を有効または無効にすることを指定します。
- DISABLE
- 行アクセス制御で行の許可を無効にすることを指定します。 表で行アクセス制御がアクティブにされたかどうかに関係なく、行の許可は無効になります。
DISABLE がデフォルトです。
- ENABLE
- 行アクセス制御で行権限を使用可能にするよう指定します。 表の行アクセス制御が現在アクティブになっていない場合、行権限は、表の行アクセス制御がアクティブになるときに有効になります。 表の行アクセス制御が現在アクティブになっている場合、行の許可は直ちに有効になり、この表を参照するすべてのパッケージと動的キャッシュ・ステートメントは無効になります。 詳細は、「パッケージが無効になる変更 」を参照してください。
注釈 CREATE PERMISSION
- 行の許可の適用方法と行の許可による特定のステートメントへの影響:
- 行アクセス制御をアクティブにする方法と行の許可の適用方法については、ACTIVATE ROW ACCESS CONTROL 文節を指定した ALTER TABLE ステートメントを参照してください。 行の許可の適用によるフェッチ操作への影響については、副選択の説明を参照してください。 行の許可の適用によるデータ変更操作への影響については、データ変更ステートメントを参照してください。
- 行アクセス制御が表でアクティブになる前に作成された行の許可:
- CREATE PERMISSION ステートメントは独立したステートメントであり、このステートメントを使用して、表の行アクセス制御をアクティブにする前に行の許可を作成することができます。 唯一の要件は、権限の作成前に表と列が存在していることです。 1 つの表に対して、複数の行権限を作成できます。
行権限の定義は、 Db2 カタログに保存されています。 権限の作成対象となる表への従属関係と、当該の定義で参照されるその他のオブジェクトへの従属関係が記録されます。 パッケージや動的キャッシュ・ステートメントは無効になりません。 行アクセス制御のために、行権限を使用可能または使用不可なものとして作成できます。 使用可能に設定された行権限は、ACTIVATE ROW ACCESS CONTROL 節が指定された ALTER TABLE ステートメントを使用して表の行アクセス制御をアクティブにすると、初めて有効になります。 表の行アクセス制御がアクティブになっても、使用不可に設定されている行権限は引き続き無効です。 ALTER PERMISSION ステートメントを使用して、ENABLE と DISABLE を切り替えることができます。
テーブルに対して行アクセス制御が有効化された後、そのテーブルがデータ操作文で参照された場合、テーブルに対して定義された有効な行権限はすべて、 Db2 によって暗黙的に適用され、テーブルへのアクセスが制御されます。
ヒント : テーブルの行アクセス制御を有効化する前に、テーブルを参照するパッケージや動的キャッシュ文が無効化されることを複数回回避するために、行権限を作成します。 - 表の行アクセス制御がアクティブになった後で作成される行の許可:
- 有効に設定されている行の許可は、コミット後に直ちに有効になります。 表を参照するパッケージと動的キャッシュ・ステートメントはすべて無効になります。 その後、データ操作ステートメントで表が参照されると、使用可能な行権限はすべて、そのステートメントに暗黙的に適用されます。 表の行アクセス制御がアクティブになっても、無効な行の許可はすべて引き続き無効です。
- 行アクセス制御または列アクセス制御が適用されている表が行の許可の定義で参照される場合、カスケード効果は発生しない:
- 行の許可の定義が、行アクセス制御または列アクセス制御が現在適用されている列と表を参照することがあります。 行権限の作成対象の表がデータ操作ステートメントで参照される場合、このような表のアクセス制御は無視されます。
- 複数のカラムマスクと行の権限が同じ環境変数を共有
- 単一の表に対して、複数の列マスクと行の許可を作成できます。 これらの列マスクと行の許可は同じ環境変数セットを使用する必要があります。 このような環境変数は、表に対して最初の列マスクまたは行の許可が作成される時点で決定します。
カタログ表 SYSENVIRONMENT に、環境変数のリストが含まれています。 複数の列マスクと行の許可において同一である必要がある環境変数を次の表に示します。
表 1. SYSIBM.SYSENVIRONMENT の環境変数 SYSENVIRONMENT 列として示される環境変数 説明 静的 create ステートメント 動的 create ステートメント 複数の列マスクと行の許可において同一である必要がある ENVID 環境の内部 ID Db2 による割り当て Db2 による割り当て はい CURRENT_SCHEMA 表やビューなどの非修飾オブジェクトを修飾するために使用される修飾子。 など。 パッケージ所有者 CURRENT_SCHEMA 特殊レジスターの値 はい PATHSCHEMAS ユーザー定義関数やユーザー定義データ型用のCAST関数などの修飾されていないオブジェクトを修飾するために使用されるスキーマパス。 PATH バインド・オプション CURRENT_PATH 特殊レジスターの値 はい application_
encoding_
ccsidアプリケーション環境の CCSID ENCODING バインド・オプション CURRENT APPLICATION ENCODING SCHEME 特殊レジスター はい オリジナル_
エンコーディング_
CCSIDステートメント・テキスト・ストリングのオリジナル CCSID CCSID(n) プリコンパイラー・オプション、または DSNTIPF インストール・パネルの EBCDIC CCSID DSNTIPF インストール・パネルの DEF ENCODING SCHEME に基づく CCSID はい DECIMAL_POINT 小数点の標識 COMMA または PERIOD プリコンパイラー・オプション、あるいは DSNTIPF インストール・パネルの DECIMAL POINT IS DSNTIPF インストール・パネルの DECIMAL POINT IS はい MIN_DIVIDE_SCALE 最小除算位取り DSNTIP4 インストール・パネルの MINIMUM DIVIDE SCALE DSNTIP4 インストール・パネルの MINIMUM DIVIDE SCALE はい STRING_DELIMITER COBOL ストリング定数で使用されるストリング区切り文字 APOST プリコンパイラー・オプション、または DSNTIPF インストール・パネルの STRING DELIMITER DSNTIPF インストール・パネルの STRING DELIMITER いいえ sql_
string_
区切り文字定数で使用される SQL ストリング区切り文字 APOSTSQL プリコンパイラー・オプション、または DSNTIPF インストール・パネルの SQL STRING DELIMITER DSNTIPF インストール・パネルの SQL STRING DELIMITER はい MIXED_DATA 混合 DBCS データを使用します DSNTIPF インストール・パネルの MIXED DATA DSNTIPF インストール・パネルの MIXED DATA はい decimal_
算術CURRENT PRECISION と、10 進演算で両方のオペランドの精度が 15 以下であるときに使用される規則。 DEC(15) または DEC(31) プリコンパイラー・オプション、あるいは DSNTIP4 インストール・パネルの DECIMAL ARITHMETIC DSNTIP4 インストール・パネルの DECIMAL ARITHMETIC はい DATE_FORMAT 日付形式 DATE プリコンパイラー・オプション、または DSNTIP4 インストール・パネルの DATE FORMAT DSNTIP4 インストール・パネルの DATE FORMAT はい TIME_FORMAT 時刻形式 TIME プリコンパイラー・オプション、または DSNTIP4 インストール・パネルの TIME FORMAT DSNTIP4 インストール・パネルの TIME FORMAT はい FLOAT_FORMAT 浮動小数点形式 FLOAT (S390 | IEEE) プリコンパイラー・オプションまたはデフォルトの FLOAT S390 デフォルトの FLOAT S390 いいえ HOST_LANGUAGE ホスト言語 HOST プリコンパイラー・オプション、または DSNTIPF インストール・パネルの LANGUAGE DEFAULT DSNTIPF インストール・パネルの LANGUAGE DEFAULT いいえ CHARSET 文字セット CCSID(n) プリコンパイラー・オプション、または DSNTIPF インストール・パネルの EBCDIC CCSID DSNTIPF インストール・パネルの EBCDIC CCSID いいえ FOLD FOLD は、HOST_LANGUAGE が C または CPP である場合にのみ適用可能です。 それ以外の場合、FOLD はブランクです。 HOST(C(FOL D) プリコンパイラー・オプションまたはデフォルトの NO FOLD デフォルトの NO FOLD いいえ ROUNDING DECFLOAT データに対して算術計算およびキャスト演算が実行される場合に使用される丸めモード. ROUNDING バインド・オプション CURRENT DECFLOAT ROUNDING MODE 特殊レジスター はい 注意: データ共有環境において、グループの各メンバに個別のDSNHDECPモジュールが提供されている場合、各環境変数のDSNHDECP設定は、データ共有グループのすべてのメンバで同じである必要があります。そうでない場合、複数の列マスクまたは行権限が作成された際にエラーが発生する可能性があります。 - COBOL アプリケーションで静的 CREATE PERMISSION ステートメントに指定される通常の SQL ID:
- CREATE PERMISSION ステートメントが COBOL アプリケーションの静的ステートメントである場合、行の許可の定義で使用される通常の SQL ID は、COBOL ワードの名前指定に関する規則に準拠していてはなりません (DSNH20474、 理由コード 14)。 Db2 SQL リファレンスの「SQL 識別子」のトピックで説明されているように、SQL 識別子の命名規則に従う必要があります。 例えば、COBOL ワード 1ST-TIME は、行の許可の定義では通常の SQL ID として使用できません。FIRST_TIME に変更するか、または区切り文字で囲んでください。
- 行の許可の適用後のデータ操作ステートメントのコード化スキームと CCSID:
データ操作文の符号化スキームとCCSIDは、行アクセス制御のために Db2 によって暗黙的に適用される行パーミッションの影響を受けない。 Unicode 列が入っている EBCDIC 表を除くターゲット表または参照先の表では、その表のコード化スキームおよび CCSID を使用して行の許可の定義が評価されます。 Unicode 列が入っている EBCDIC 表を除くターゲット表または参照先の表では、複数のコード化スキームの規則を使用して行の評価の定義が評価されます。
- Db2 の制限事項への配慮:
- データ操作文がすでにステートメント内でいくつかの Db2 制限に近づいている場合、有効化された行権限や有効化された列マスクが作成されるほど、制限に影響を与える可能性が高くなることに注意する必要があります。 例えば、このような列マスクと行の許可が原因で、ステートメントが、ソートを必要とし、集約関数 (MULTIPLE DISTINCT および GROUP BY) を評価する照会操作の列の最大合計長 (32600 バイト) を超える可能性があります。 これは、データ操作ステートメントで表が参照される場合に、有効な列マスク定義と行の権限の定義が暗黙にこのステートメントにマージされるためです。 ステートメントの制限については、SQL リファレンスの「 Db2 for z/OS® 」を参照してください。
- 保留定義変更に関する制約事項は、以下のとおりです。
- 許可が、定義変更を保留している表で定義されているか、またはそれらの表を参照している場合、CREATE PERMISSION は許可されません。
例 CREATE PERMISSION
- 例 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 が割り当てられています。 SECADM 権限により定義されているアクセス規則に基づいて、銀行内の各担当者グループに対して行の許可が作成されます。 表 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;
