柔軟なセキュリティー

(1)

6. 柔軟なセキュリティー

- 新しい行および列のアクセス制御機能

本資料掲載事項は、ある特定の環境・使用状況においての正確性がIBMによって確認されていますが、すべての環境において同様の結果が得られる保証はありません。これらの技術を自身の環境に適用する際には、自己の責任において十分な検証と確認を実施いただくことをお奨めいたします。

(2)

内容

(3)

RCAC

(4)

行および列のアクセス制御機能のポジション

• この機能が必要となる背景

• VIEWやアプリケーションロジックで制限を

行っている

• ただし、DATAACCESS権限を持っている

ユーザーであれば、VIEWやアプリケーション

ロジックの制限をバイパスして参照が可能

現状

• マネージャーが自分の部下のデータのみを見

れるように、確実に制限したい！

• 許可されていないユーザーに対し、口座情報

や電話番号、カード番号といった情報を確実

にマスキングしたい！

要件

(5)

行および列のアクセス制御機能概要

• 機能特徴

• データセキュリティの新しいレイヤー

• 行、列、またはその組合せで、

以下のアクセス制御を実現

• 行に対する参照可否の権限設定

• 列に対するマスキング

• ユーザー、ロール、グループを利用

• お客様にとっての価値

• より詳細なアクセス制御が可能

• より強固なアクセス制御が可能

• 実装が容易

• アプリケーションからは透過的に利用可能

(6)

CUSTID

EMPNAME

CUSTNAME

ACCOUNT

BALANCE

001 MARY

SALLY

0123-88888

100000

002 MARY

MICHAEL

1123-99999

5000

003 PETER

EMILY

2123-77777

0 ACCOUNT が

‘XXXX-XXXXX’

に見える

担当顧客の

情報だけ見える

JOHN

全ての情報が見える

ADAM

アクセス制御を行う

データは見えない

アクセス制御のイメージ

(7)

アクセス制御の作成方法と手順

• 行レベルのアクセス制御(CREATE PERMISSION)

• 誰が、どの行にアクセスできるか

• 列レベルのアクセス制御(CREATE MASK)

• 列（データ）に対して、誰に、どのようなマスキングを行うか

create permission cust on db2admin.sales for rows where

( verify_role_for_user(SESSION_USER,‘ACCOUNTANT’)=1 ) OR

( verify_role_for_user(SESSION_USER,‘CUSTOMER’) =1 ) enforced for all access enable

alter table db2admin.sales activate row access control

create mask account_mask on db2admin.sales for column account return case when verify_role_for_user(SESSION_USER,'ACCOUNTANT')=1

then 'XXXX-XXXXX‘ else account

end enable

(8)

Note：

• 作成されたアクセス制御に関してはカタログ表に保存される

• SYSCAT.CONTROLS

• SYSCAT.CONTROLSDEP

• アクセス制御の有効/無効については、SYSCAT.TABLES表に保存されている

• CONTROL列

• ブランク

• 何のアクセス制御も有効になっていない

• C

• 列のアクセス制御のみ有効（MASK）

• R

• 行のアクセス制御のみ有効（PERMISSION）

• B

• 行および列のアクセス制御が有効

(9)

Note：SYSCAT.CONTROLS

データ・タイデータ・列のスケ

列名プ・スキーマタイプ名長さール NULL --- --- --- --- --- --- CONTROLSCHEMA SYSIBM VARCHAR 128 0 いいえ CONTROLNAME SYSIBM VARCHAR 128 0 いいえ OWNER SYSIBM VARCHAR 128 0 いいえ OWNERTYPE SYSIBM CHARACTER 1 0 いいえ TABSCHEMA SYSIBM VARCHAR 128 0 いいえ TABNAME SYSIBM VARCHAR 128 0 いいえ COLNAME SYSIBM VARCHAR 128 0 いいえ CONTROLID SYSIBM INTEGER 4 0 いいえ CONTROLTYPE SYSIBM CHARACTER 1 0 いいえ ENFORCED SYSIBM CHARACTER 1 0 いいえ IMPLICIT SYSIBM CHARACTER 1 0 いいえ ENABLE SYSIBM CHARACTER 1 0 いいえ VALID SYSIBM CHARACTER 1 0 いいえ RULETEXT SYSIBM CLOB 2097152 0 いいえ TABCORRELATION SYSIBM VARCHAR 128 0 いいえ QUALIFIER SYSIBM VARCHAR 128 0 いいえ FUNC_PATH SYSIBM CLOB 2048 0 いいえ COLLATIONSCHEMA SYSIBM VARCHAR 128 0 いいえ COLLATIONNAME SYSIBM VARCHAR 128 0 はい COLLATIONSCHEMA_ORDERBY SYSIBM VARCHAR 128 0 いいえ COLLATIONNAME_ORDERBY SYSIBM VARCHAR 128 0 はい CREATE_TIME SYSIBM TIMESTAMP 10 6 いいえ ALTER_TIME SYSIBM TIMESTAMP 10 6 いいえ REMARKS SYSIBM VARCHAR 254 0 はい

(10)

Note：

select substr(controlname,1,40)controlname, substr(tabname,1,10)tabname, substr(OWNER,1,10)owner, substr(COLNAME,1,10)colname, controltype as type, enable,implicit,

substr(ruletext,1,100)ruletext from syscat.controls

CONTROLNAME TABNAME OWNER COLNAME TYPE ENABLE IMPLICIT --- --- --- --- ---- --- --- CUST CUSTOMER TAKAYA R Y N SYS_DEFAULT_ROW_PERMISSION__CUSTOMER CUSTOMER SYSIBM R Y Y ACCOUNT_MASK CUSTOMER TAKAYA ACCOUNT C Y N PARTROW PARTTBL TAKAYA R Y N SYS_DEFAULT_ROW_PERMISSION__PARTTBL PARTTBL SYSIBM R Y Y PART_MASK PARTTBL TAKAYA C2 C Y N

RULETEXT

--- ( verify_role_for_user(SESSION_USER,'ACCOUNTANT')=1 ) OR 1 = 0

case when verify_role_for_user(SESSION_USER,'ACCOUNTANT')=1 ( verify_role_for_user(SESSION_USER,'ACCOUNTANT')=1 ) OR 1 = 0

(11)

Note：

• 権限をACTIVATEすると、SYS_DEFAULT_* のアクセス制御が自動的に内部的に作

成される。

• それらは、RULE_TEXTで、「(1=0)」となっている。

• （1=0）という条件は、他の行レベルのアクセス制御が作成されてACTIVATEされるまで

そのデータは誰にも見せないというもの(NOACCESS)。

• これにより、不本意なデータ公開を防いでいる。

• 後述で、アクセス制御が有効になっているパーティション表からパーティションをデタッ

チすると、デタッチされた表に「(1=0)」のアクセス制御が自動的に適用される。

• 表をデタッチすることで、データが公開されることを防いでいる。

(12)

Note：SYSCAT.CONTROLDEP

>db2 describe table syscat.controldep

データ・タイデータ・列のスケ

列名プ・スキーマタイプ名長さール NULL --- --- --- --- --- --- DSCHEMA SYSIBM VARCHAR 128 0 いいえ DNAME SYSIBM VARCHAR 128 0 いいえ DTYPE SYSIBM CHARACTER 1 0 いいえ BTYPE SYSIBM CHARACTER 1 0 いいえ BSCHEMA SYSIBM VARCHAR 128 0 いいえ BMODULENAME SYSIBM VARCHAR 128 0 はい BNAME SYSIBM VARCHAR 128 0 いいえ BMODULEID SYSIBM INTEGER 4 0 はい BCOLNAME SYSIBM VARCHAR 128 0 はい

9 レコードが選択されました。

(13)

Note：

select substr(dname,1,20)dname, dtype,btype,

substr(bname,1,10)bname, substr(bcolname,1,20)bcolname from syscat.controldep

DNAME DTYPE BTYPE BNAME BCOLNAME

--- --- --- --- --- CUST y C DBAUTH GRANTEE

CUST y C DBAUTH SECURITYADMAUTH CUST y C CUSTOMER EMPNAME

PARTROW y C DBAUTH GRANTEE

PARTROW y C DBAUTH SECURITYADMAUTH PARTROW y C PARTTBL C1

ACCOUNT_MASK 2 C CUSTOMER ACCOUNT PART_MASK 2 C PARTTBL C2 CUST y V DBAUTH - CUST y T CUSTOMER - PARTROW y V DBAUTH - PARTROW y T PARTTBL - SYS_DEFAULT_ROW_PERM y T CUSTOMER - SYS_DEFAULT_ROW_PERM y T PARTTBL - ACCOUNT_MASK 2 T CUSTOMER - PART_MASK 2 T PARTTBL - 16 レコードが選択されました。

(14)

Note：SYSCAT.TABLESのCONTROL

select substr(tabname,1,10)tabname,control from syscat.tables where tabname='CUSTOMER' TABNAME CONTROL

--- --- CUSTOMER B

alter table customer deactivate column access control

select substr(tabname,1,10)tabname,control from syscat.tables where tabname='CUSTOMER‘ TABNAME CONTROL

--- --- CUSTOMER R

alter table customer deactivate row access control

--- --- CUSTOMER

alter table customer activate column access control

--- --- CUSTOMER C

(15)

アクセス制御の動き

• 基本ルール

• SELECTできないデータはUPDATE/DELETEできない

• エラーにはならず、あたかもデータが存在しないような振る舞いをする

(SQL0110W)

• SELECTできないデータはINSERTできない

• エラー(SQL20471N)になる。詳細はテスト結果を参照。

• UPDATE後にSELECTできなくなるデータはUPDATEできない

• エラー (SQL20471N)になる。詳細はテスト結果を参照。

• マスキングは結果を表示する際に行われる

• DB2が内部的に行う処理はマスキングされない

• ORDER BY

• GROUP BY

• HAVING

• SELECT DISTINCT

• ORDER BY

• 例えば、ORDER BYで指定されたカラムがマスキングされていた場合、指

定されたカラムのオリジナルデータで order by されるが、ユーザに表示す

る際にはデータはマスキングされる

(16)

アクセス制御が無視される動作

• DB2が内部的に行う処理ではアクセス制御は無視される

• EXPLAIN表への挿入

• EVENTモニター表への挿入

• MQTのリフレッシュ

• MQTのステージング表への挿入

• Temporal履歴表への挿入

• AS OFクエリーでの Temporal履歴表へのアクセス

• Query reroute optimization でMQTにアクセス

• 主キー、ユニークキー、チェック制約のスキャン

• RIスキャン

(17)

Note：

• 例えば、RI制約で親表からデータをDELETEすると子表からもデータを

DELETEする必要がある(cascade deleteの場合)。

もし、子表からDELETEする表がアクセス制御で参照不可能であっても、削除

される。

USER1

親表子表 DELETE

cascade delete

USER1には見えない

データでも削除可能

(18)

Note：テスト結果

create table ptbl(c1 int, c2 int not null unique, c3 char(10));

create table ctbl(c1 int, c2 int references ptbl(c2) on delete cascade, c3 char(10)); insert into ptbl values(1,1,'PDATA');

insert into ctbl values(1,1,'CData'); insert into ctbl values(10,1,'CData'); >db2 select * from ctbl C1 C2 C3 --- --- --- 1 1 CData 10 1 CData 2 レコードが選択されました。

>db2 "create permission delperm on ctbl for rows where c1=10 enforced for all access enable“ DB20000I SQL コマンドが正常に完了しました。

>db2 alter table ctbl activate row access control DB20000I SQL コマンドが正常に完了しました。 >db2 select * from ctbl C1 C2 C3 --- --- --- 10 1 CData RCACが有効になっているため、 1行しか参照できていない

(19)

Note：テスト結果

>db2 delete from ptbl where c2=1

DB20000I SQL コマンドが正常に完了しました。 >db2 select * from ctbl

C1 C2 C3

--- --- ---

0 レコードが選択されました。

>db2 alter table ctbl deactivate row access control DB20000I SQL コマンドが正常に完了しました。 >db2 select * from ctbl C1 C2 C3 --- --- --- 0 レコードが選択されました。ユーザーには(1,1,’CData’)は参照できないデータだが、cascade delete により削除されるデータは子表からエラーなく削除されたこのDELETEにより、子表から (1,1,’CData’)が削除される

(20)

自動的に行レベルのアクセス制御が引継がれる操作

• アクセス制御が有効になっている表に対するMQTの作成

• アクセス制御が有効になっている表に対して作成されたMQTのス

テージング表の作成

• MQTの元表に対するアクセス制御の有効化

• アクセス制御が有効になっているTemporal表の履歴表の作成

• 履歴表が存在するTemporal表のアクセス制御の有効化

• アクセス制御が有効になっているパーティション表からデタッチした表

• 下線の表が引き継がれる対象となる表

(21)

Note：

• ただし、同じアクセス制御が引き継がれるわけではない

• データ漏れを防ぐためNO ACCESSのアクセス制御が作成される

• 同じアクセス制御を行いたければ再度アクセス制御を定義し、

(22)

Note：テスト結果

• アクセス制御が有効になっているパーティション表からデタッチした場合

【SYSCAT.CONTROLS】

CONTROLNAME TABNAME OWNER COLNAME TYPE ENABLE IMPLICIT RULETEXT

--- --- --- --- ---- --- --- --- PARTR PARTTBL TAKAYA R Y N ( verify_role_for_ SYS_DEFAULT_ROW_PERMISSION__PARTTBL PARTTBL SYSIBM R Y Y 1 = 0

PARTC PARTTBL TAKAYA C3 C Y N case when verify_ro 3 レコードが選択されました。

【SYSCAT.CONTROLDEP】

--- --- --- --- --- PARTR y C PARTTBL C1 PARTC 2 C PARTTBL C3 PARTR y T PARTTBL - SYS_DEFAULT_ROW_PERM y T PARTTBL - PARTC 2 T PARTTBL - 5 レコードが選択されました。

パーティション表のCOLUMNとROWのRCACが定義されている

(23)

Note：テスト結果

alter table parttbl detach partition q5 into table dettbl

DB20000I SQL コマンドが正常に完了しました。【SYSCAT.CONTROLS】

CONTROLNAME TABNAME OWNER COLNAME TYPE ENABLE IMPLICIT RULETEXT

--- --- --- --- ---- --- --- --- PARTR PARTTBL TAKAYA R Y N ( verify_role_for_ SYS_DEFAULT_ROW_PERMISSION__PARTTBL PARTTBL SYSIBM R Y Y 1 = 0

PARTC PARTTBL TAKAYA C3 C Y N case when verify_ro

SYS_DEFAULT_ROW_PERMISSION__DETTBL DETTBL SYSIBM R Y Y 1 = 0

【SYSCAT.CONTROLDEP】

--- --- --- --- --- PARTR y C PARTTBL C1 PARTC 2 C PARTTBL C3 PARTR y T PARTTBL - SYS_DEFAULT_ROW_PERM y T PARTTBL - PARTC 2 T PARTTBL - SYS_DEFAULT_ROW_PERM y T DETTBL -

select * from dettbl C1 C2 C3 --- --- --- 0 レコードが選択されました。

（1=0）のアクセス制御だけ作られる

（1=0）とは、他にアクセス制御を定義する、も

しくはアクセス制御をDEACTIVATEしないと

誰も見れないというもの

誰もデタッチした表からデータを見ることはできない。

見るためには、デタッチした表のRCACをDEACTIVATEする、

もしくは新たにRCACをデタッチ表に対して作成する

(24)

ユーティリティとの互換性

• EXPORT

• アクセス制御が有効となる

• Exportしたユーザに応じてExportされる件数が異なる

• IMPORT

• アクセス制御が有効となる

• 権限の無いデータをINSERTしようとするとエラーになる

• LOAD

• アクセス制御は無視される

• db2look

• アクセス制御の定義を出力可能

SQL20471N INSERT または UPDATE ステートメントは、結果の行が行の許可を満たさないため失敗しました。SQLSTATE=22542

(25)

EXPLAIN と NORCAC

• EXPLAINにNORCACオプションが追加された

• オプション無し

• アクセス制御を追加したSQL文に書き換え、実行される

• アクセス制御の定義によってはアクセスプランも変わる

• NORCAC有り

• アクセス制御がないものとして実行される

(26)

Note：

• NORCAC指定無し(RCACを含めたExplain)

• SET CURRENT EXPLAIN MODE EXPLAIN

• 実行SQL：select * from customer

• NORCAC指定有り(RCACを含めないExplain)

• SET CURRENT EXPLAIN MODE EXPLAIN

NORCAC

• 実行SQL：select * from customer

SELECT Q1."CUSTID" AS "CUSTID", Q1."EMPNAME" AS "EMPNAME", Q1."CUSTOMER" AS "CUSTOMER", Q1."ACCOUNT" AS "ACCOUNT", Q1."BALANCE" AS "BALANCE" FROM TAKAYA.CUSTOMER AS Q1

SELECT Q3."CUSTID" AS "CUSTID", Q3."EMPNAME" AS "EMPNAME", Q3."CUSTOMER" AS "CUSTOMER", $INTERNAL_FUNC$() AS "ACCOUNT", Q3."BALANCE" AS "BALANCE" FROM TAKAYA.CUSTOMER AS Q3 WHERE (((VERIFY_ROLE_FOR_USER(3, $INTERNAL_FUNC$(), USER, 'ACCOUNTANT') = 1) OR

((VERIFY_ROLE_FOR_USER(3, $INTERNAL_FUNC$(), USER, 'CUSTOMER') = 1) AND (Q3."EMPNAME" = USER))) OR ($INTERNAL_FUNC$() = (SELECT Q1."GRANTEE" FROM SYSIBM.SYSDBAUTH AS Q1 WHERE (Q1."SECURITYADMAUTH" = 'Y'))))

(27)

権限に関する考慮点

• CREATE PERMISSION/MASK にはSECADM権限が必要

• ALTER TABLEにてアクセス制御を有効にするためには

SECADM権限 AND (DBADM権限 OR ALTER特権)が必要

• SECADM権限を持つユーザーにDBADM権限を付与するとオール

マイティになるので注意

• 以下の操作は従属するパッケージを無効にする

• アクセス制御のActivate/Deactivate

• アクセス制御のCreate/Drop/Alter

先に、アクセス制御を作成するようにしましょう

(28)

Note：

• SECADM権限なしでALTER TABLE ACTIVATE/DACTIVATEしようとする

と以下のようなエラーになる

• SECADM権限のみでALTER TABLE ACTIVATE/DACTIVATEしようとする

と以下のようなエラーになる

> db2 alter table takaya.customer deactivate row access control

DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQL ステートメントとして処理されました。 SQL 処理中に、次のエラーが返されました。 SQL0551N "DB2ADMIN" は、オブジェクト "TABLE" で処理 "ALTER ACCESS CONTROL“ を実行する必要な権限または特権を持っていません。 SQLSTATE=42501

> db2 alter table takaya.customer deactivate row access control

DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQL ステートメントとして処理されました。 SQL 処理中に、次のエラーが返されました。 SQL0551N "DB2ADMIN" は、オブジェクト "TAKAYA.CUSTOMER" で処理 "ALTER TABLE“ を実行する必要な権限または特権を持っていません。 SQLSTATE=42501

(29)

考慮点 (1/3)

• アクセス制御を定義できるのは表のみ

• 以下は対象外

• ニックネーム

• 作成済み一時表

• 宣言済み一時表

• ビュー

• シノニム

• 型付き表

• 別名

• カタログ表

(30)

考慮点 (2/3)

• アクセス制御定義内では以下のオブジェクトは参照できない

• 作成済みのグローバル一時表または宣言済みのグローバル一時表

• ニックネーム

• 表関数

• メソッド

• パラメーター・マーカー

• 非セキュアとして定義されているユーザー定義関数

• 非決定論的である、または外部アクションを持つ関数や式

(ROW CHANGE 式、シーケンス式など)

• XMLQUERY スカラー関数

• XMLEXISTS 述部

• OLAP 指定

• SELECT 文節内の * または name.*

• 疑似列

• SELECT 節を指定しない集約関数

(31)

考慮点 (3/3)

• 以下のデータに関してはマスキングを行えない

• XML

• LOB

• 生成列

• アクセス制御が定義されている表に対してUDFやトリガーを作

成する場合は、SECURE属性が必要

• SQL20470N

(32)

Note：トリガーのテスト例

• アクセス制御されている表に対してSECURED指定の無いトリガーを作成使

用とした場合

• トリガーにより更新される表に対してユーザの許可が無い場合

DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQL ステートメントとして処理されました。 SQL 処理中に、次のエラーが返されました。 SQL20470N “TRIGGER” の “TAKAYA.SEC_INSTRIG“ がセキュアなものとして定義されておらず、”TABLE” の “TAKAYA.CUSTOMER“ がそれに依存しているため、CREATE または ALTER ステートメントが失敗しました。

LINE NUMBER=3. SQLSTATE=428H8

> db2 “insert into takaya.t1 values(‘222’,‘PETER’)“

DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQL ステートメントとして処理されました。 SQL 処理中に、次のエラーが返されました。 SQL0723N トリガー ”TAKAYA.SEC_INSTRIG2” のトリガー SQL ステートメントでエラーが発生しました。エラーに関して戻された情報には、SQLCODE “-20471”、 SQLSTATE “22542” およびメッセージ・トークン “” が含まれています。 SQLSTATE=09000 SQL20471N INSERT または UPDATE ステートメントは、結果の行が行の許可を満たさないため失敗しました。

(33)

LBACとの比較



LBACのセキュリティモデル

USの政府機関や情報機関を対象とした、ラベルベースのセキュリティーモ

デル。例えばUS 国防総省やその関連機関のように、データあるいは組織

に対して、アクセスコントロールを明確に階層定義できるようなモデル。



RCACのセキュリティーモデル

より一般的なユーザーにも利用可能となるよう、データあるいは組織に対す

る階層構造を必要としないセキュリティーモデル。



LBACとRCAC

LBACは非常に強固なセキュリティーモデル。

そのため設計や構築において多少手間がかかる。

対して、RCACはより容易に望むセキュリティモデルを実現できる。

(34)

参考資料

• DB2 best practices: A practical guide to implementing row and column access

control

• http://www.ibm.com/developerworks/data/bestpractices/rcac/index.html

• 行および列のアクセス制御 (RCAC) の概要

• http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.s

ec.doc/doc/c0057423.html

• SYSCAT.CONTROLS

• http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.sql.ref.d

oc/doc/r0059052.html

• SYSCAT.CONTROLDEP

• http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.sql.ref.d

oc/doc/r0059051.html

• CREATE/ALTER TABLE、CREAT/ALTER PERMISSION、CREATE/ALTER

MASKにも様々な記載あり（マニュアル）

(35)

まとめ

RCAC

• 新しいセキュリティー･モデル

• 容易に行、列、その組合せでアクセス制御が可能

–

行のフィルタリング

–

列のマスキング

• アプリケーションからは透過的に実装可能

(36)

(37)

シンプル・シナリオ

• 登場人物

• ADAM

• セキュリティー管理者

• 権限の管理を行う

• JOHN

• 管理者

• 全てのデータを見ることができる

• BOB

• 経理担当

• 支払い残高のみを管理する

• 顧客の口座番号などはマスキングされ

る

• MARY

• 販売会社の顧客担当者

• 自分の支払い金額の残高のみ参照で

きる権限を持っている

• 役割（ロール）

• CUSTOMER

• 顧客担当者 ⇒ MARY

• 自分が担当する顧客の支払い金額の残

高のみ参照できる権限を持っている

• ACCOUNTANT

• 経理 ⇒ BOB

• 口座番号がマスキングされる

• MANAGER

• 管理者 ⇒ JOHN

• 全てのデータを見ることができる

(38)

CUSTID

EMPNAME

CUSTNAME

ACCOUNT

BALANCE

001 MARY

SALLY

0123-88888

100000

002 MARY

MICHAEL

1123-99999

5000

003 PETER

EMILY

2123-77777

0 ACCOUNT が

‘XXXX-XXXXX’

に見える

担当顧客の

情報だけ見える

JOHN

全ての情報が見える

ADAM

アクセス制御を行う

データは見えない

シンプル・シナリオ概要図

(39)

シンプル・シナリオ実行結果（1/12）

(40)

シンプル・シナリオ実行結果（2/12）

• 権限の付与

C:¥labscript¥rcac>db2 -tvf 01crtuser.sql connect to rcacdb user Administrator using データベース接続情報

＜省略＞

grant secadm,dbadm on database to user adam DB20000I SQL コマンドが正常に完了しました。

select substr(grantor,1,10)grantor, substr(grantee,1,10)grantee, connectauth, CREATETABAUTH, dbadmauth, securityadmauth from syscat.dbauth

GRANTOR GRANTEE CONNECTAUTH CREATETABAUTH DBADMAUTH SECURITYADMAUTH --- --- --- --- --- --- SYSIBM ADMINISTRA N N Y Y

SYSIBM PUBLIC Y Y N N ADMINISTRA ADAM N N Y Y 3 レコードが選択されました。

(41)

シンプル・シナリオ実行結果（3/12）

• ロールの作成

C:¥labscript¥rcac>db2 -tvf 02crtrole.sql connect to rcacdb user adam using

データベース接続情報＜省略＞

create role ACCOUNTANT

DB20000I SQL コマンドが正常に完了しました。 create role CUSTOMER

DB20000I SQL コマンドが正常に完了しました。 create role MANAGER

DB20000I SQL コマンドが正常に完了しました。 grant role ACCOUNTANT to user BOB

DB20000I SQL コマンドが正常に完了しました。 grant role CUSTOMER to user MARY

DB20000I SQL コマンドが正常に完了しました。 grant role MANAGER to user JOHN

(42)

シンプル・シナリオ実行結果（4/12）

• テスト表の作成とデータの挿入

C:¥labscript¥rcac>db2 -tvf 03crttbl.sql connect to rcacdb user db2admin using ＜省略＞

create table sales(custid char(3), empname char(10), customer char(10), account char(10), balance int)

DB20000I SQL コマンドが正常に完了しました

insert into sales values('001','MARY','SALLY','0123-88888',100000) DB20000I SQL コマンドが正常に完了しました。

insert into sales values('002','MARY','MICHAEL','0124-99999',5000) DB20000I SQL コマンドが正常に完了しました。

insert into sales values('003','PETER','EMILY','0125-33333',0) DB20000I SQL コマンドが正常に完了しました。

select * from sales

CUSTID EMPNAME CUSTOMER ACCOUNT BALANCE --- --- --- --- --- 001 MARY SALLY 0123-88888 100000 002 MARY MICHAEL 0124-99999 5000

(43)

シンプル・シナリオ実行結果（5/12）

• 行のフィルタリング

C:¥labscript¥rcac>db2 -tvf 04crtrcac.sql connect to rcacdb user adam using

＜省略＞

create permission cust on db2admin.sales for rows where ( verify_role_for_user(SESSION_USER,‘ACCOUNTANT’)=1 ) OR ( verify_role_for_user(SESSION_USER,‘CUSTOMER’) =1 AND db2admin.sales.empname=SESSION_USER ) OR ( verify_role_for_user(SESSION_USER,'MANAGER')=1 ) enforced for all access enable

DB20000I SQL コマンドが正常に完了しました。

alter table db2admin.sales activate row access control DB20000I SQL コマンドが正常に完了しました。

表にアクセスしたユーザーのロールがCUSTOMERの場合は、“SALES表のEMPNAME ＝アクセスしたユーザー” の行のみ表示する。

(44)

シンプル・シナリオ実行結果（6/12）

• 列のマスキング

create mask account_mask on db2admin.sales for column account return case when verify_role_for_user(SESSION_USER,'ACCOUNTANT')=1

then 'XXXX-XXXXX‘ else account end enable

DB20000I SQL コマンドが正常に完了しました。

alter table db2admin.sales activate column access control DB20000I SQL コマンドが正常に完了しました。

表にアクセスしたユーザーのロールがACCOUNTANTの場合はSALES表のACCOUNT列を’XXXX-XXXXX’で表示する。

その他のロールに対しては、マスキングは行わない。

(45)

シンプル・シナリオ実行結果（7/12）

• テスト表へのアクセス権限

C:¥labscript¥rcac>db2 -tvf 05grant.sql connect to rcacdb user adam using

＜省略＞

grant select on db2admin.sales to role CUSTOMER DB20000I SQL コマンドが正常に完了しました。 grant update on db2admin.sales to role CUSTOMER DB20000I SQL コマンドが正常に完了しました。 grant insert on db2admin.sales to role CUSTOMER DB20000I SQL コマンドが正常に完了しました。 grant delete on db2admin.sales to role CUSTOMER DB20000I SQL コマンドが正常に完了しました。 grant select on db2admin.sales to role MANAGER DB20000I SQL コマンドが正常に完了しました。＜省略＞

grant select on db2admin.sales to role ACCOUNTANT DB20000I SQL コマンドが正常に完了しました。

(46)

シンプル・シナリオ実行結果（8/12）

• データの参照

• 各ユーザーが全て同じSQLを実行。ロール別に列フィルタリングや

マスキングが行われているため、同じSQLを実行しても、ユーザー

に応じて見えるデータが異なる。

C:¥labscript¥rcac>db2 -tvf 06runsql.sql connect to rcacdb user john using

＜省略＞

select * from db2admin.sales

CUSTID EMPNAME CUSTOMER ACCOUNT BALANCE --- --- --- --- --- 001 MARY SALLY 0123-88888 100000 002 MARY MICHAEL 0124-99999 5000 003 PETER EMILY 0125-33333 0 3 レコードが選択されました。

管理者のJOHNがSALES表に

対して「SELECT * 」を実行。

管理者のため、全てのデータ

を見ることができる。

(47)

シンプル・シナリオ実行結果（9/12）

• データ参照

connect to rcacdb user mary using ＜省略＞

CUSTID EMPNAME CUSTOMER ACCOUNT BALANCE --- --- --- --- --- 001 MARY SALLY 0123-88888 100000 002 MARY MICHAEL 0124-99999 5000 2 レコードが選択されました。

顧客担当のMARYがSALES表に

対して「SELECT * 」を実行。

MARYは自分が担当する顧客の

情報しか見れない。

(48)

シンプル・シナリオ実行結果（10/12）

• データ参照

connect to rcacdb user bob using ＜省略＞

CUSTID EMPNAME CUSTOMER ACCOUNT BALANCE --- --- --- --- --- 001 MARY SALLY XXXX-XXXXX 100000 002 MARY MICHAEL XXXX-XXXXX 5000 003 PETER EMILY XXXX-XXXXX 0 3 レコードが選択されました。

経理担当のBOBがSALES表に対

して「SELECT * 」を実行。

BOBは顧客の口座番号を見ること

は許されていないため、

ACCOUNT列が「XXXX-XXXXX」

にマスキングされている。

(49)

シンプル・シナリオ実行結果（11/12）

• データの更新

• PERMISSIONを作成するだけで、許可の無いデータに対して更新ができ

なくなる

• 例では、MARYが自分の担当する顧客データを表に挿入することはできる

が、自分の顧客以外のデータを挿入しようとした場合や、自分の顧客以外

のデータを更新した場合にエラーになる。

C:¥labscript¥rcac>db2 -tvf 07insert.sql connect to rcacdb user mary using

＜省略＞

insert into db2admin.sales values(‘020’,‘MARY’,‘SAM’,‘0125-33666’,9000) DB20000I SQL コマンドが正常に完了しました。

insert into db2admin.sales values('010','PETER','SCOTT','0125-33444',500)

DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQLステートメントとして処理されました。 SQL 処理中に、次のエラーが返されました。SQL20471N INSERT または UPDATE ステートメントは、結果の行が行の許可を満たさないため失敗しました。 SQLSTATE=22542

自分の顧客情報はINSERT可能

PETER担当の顧客情報はINSERT

(50)

シンプル・シナリオ実行結果（12/12）

update db2admin.sales set empname='MARY' where custid='003‘

SQL0100W FETCH、UPDATE または DELETE の対象となる行がないか、または照会の結果が空の表です。 SQLSTATE=02000

CUSTID EMPNAME CUSTOMER ACCOUNT BALANCE --- --- --- --- --- 001 MARY SALLY 0123-88888 100000 002 MARY MICHAEL 0124-99999 5000 020 MARY SAM 0125-33666 9000 3 レコードが選択されました。

柔軟なセキュリティー

6. 柔軟なセキュリティー

- 新しい行および列のアクセス制御機能

内容

RCAC

行および列のアクセス制御機能のポジション

• この機能が必要となる背景

• VIEWやアプリケーションロジックで制限を

行っている

• ただし、DATAACCESS権限を持っている

ユーザーであれば、VIEWやアプリケーション

ロジックの制限をバイパスして参照が可能

現状

• マネージャーが自分の部下のデータのみを見

れるように、確実に制限したい！

• 許可されていないユーザーに対し、口座情報

や電話番号、カード番号といった情報を確実

にマスキングしたい！

要件

行および列のアクセス制御 機能概要

• 機能特徴

•

データセキュリティの新しいレイヤー

•

行、列、またはその組合せで、

以下のアクセス制御を実現

•

行に対する参照可否の権限設定

•

列に対するマスキング

•

ユーザー、ロール、グループを利用

• お客様にとっての価値

•

より詳細なアクセス制御が可能

•

より強固なアクセス制御が可能

•

実装が容易

•

アプリケーションからは透過的に利用可能

CUSTID

EMPNAME

CUSTNAME

ACCOUNT

BALANCE

001

MARY

SALLY

0123-88888

100000

002

MARY

MICHAEL

1123-99999

5000

003

PETER

EMILY

2123-77777

0

ACCOUNT が

‘XXXX-XXXXX’

に見える

担当顧客の

情報だけ見える

JOHN

全ての情報が見える

ADAM

アクセス制御を行う

データは見えない

アクセス制御のイメージ

アクセス制御の作成方法と手順

• 行レベルのアクセス制御(CREATE PERMISSION)

•

誰が、どの行にアクセスできるか

• 列レベルのアクセス制御(CREATE MASK)

•

列（データ）に対して、誰に、どのようなマスキングを行うか

Note：

行および列のアクセス制御機能概要