Label-Based-Access-Control (LBAC) overview

®

IBM Software Group

© 2006 IBM Corporation

Label-Based-Access-Control (LBAC) overview

IBM Software Group | DB2 information management software

2

アクセス制御

アクセス制御には強制アクセス制御（ MAC: Mandatory Access Control ）及び、任意アクセス制御（ DAC: Discretionary Access Control ）があります。

DAC は、ユーザ ID あるいは、グループ ID に基づいてオブジェクトへのアクセスを制御するアクセス制御方式。（ Windows や Linux , Unix と同様）ユーザーが自分の所有するファイルやディレクトリのアクセス権（パーミッション）を自由に変更できます。また， root ユーザーは無制限にファイルやディレクトリにアクセスしたり，パーミッションの設定を変更したりできます。

MAC は、システムのサブジェクトとオブジェクトの関連を強制的なセキュリティポリシーとして定義し、システムがそのアクセス制御方針を運用するアクセス制御方式です。ユーザーは自分の所有するファイルやディレクトリに対してもあらかじめ設定されたアクセスしか行えません。アクセス権限の変更も行えません。これは root ユーザーにも当てはまります。アクセス権限を設定・変更できるのは，セキュリティ管理者のみです。


3

Label-Based-Access-Control (LBAC)

ラベル・ベースのアクセス制御（ LBAC ）は MAC をベースに実装されており、データにどのユーザーがアクセスできるかに対する制御を大きく向上させます。 LBAC を使用すると、個々の行および個々の列に対して、どのユーザーに書き込みアクセスがあり、どのユーザーに読み取りアクセスがあるのかを厳密に決定することができます。行レベル　でのアクセス・コントロール列レベル　でのアクセス・コントロール

　　この２つを組み合わせて使用することも可能です。

LBAC 構成はセキュリティー管理者により実行されます。セキュリティー管理者は、システム管理者により SECADM 権限が付与されているユーザーです。この権限が付与されていると、保有者はデータベースのセキュリティー関連のさまざまな構成を行うことができ、さらにはデータベース・オブジェクトの所有権を転送することもできます。たとえば、 SECADM 権限を持つユーザーは、ラベル・ベースのアクセス制御 (LBAC) 機能の一部であるオブジェクトすべての作成、ドロップ、権限付与、取り消しを行えます。 SECADM だけが行えることは、 SYSADM を含め、他のどの権限でも行えません。


4

LBAC の構成（概要）セキュリティー管理者 (SECADM) は、セキュリティー・ポリシーを作成し

て LBAC システムを構成します。

セキュリティー・ポリシーには、どのデータに誰がアクセスできるかを判断するために使用される基準（セキュリティー・ラベル・コンポーネント）を記述します。任意の 1 つの表を保護するために 1 つのセキュリティー・ポリシーしか使用できませんが、複数のセキュリティー・ポリシーを使用して複数の表を保護することができます。セキュリティー・ポリシーを作成した後、そのポリシーの一部であるセキュリティー・ラベルというオブジェクトを作成します。

作成が完了すると、セキュリティー・ラベルを表の個々の列と行に関連付けてそこに保持されているデータを保護することができます。

セキュリティー・ラベルにより保護されるデータは、保護データと呼ばれます。セキュリティー管理者は、ユーザーにセキュリティー・ラベルを付与することにより、保護データへのアクセスを許可します。ユーザーが保護データへのアクセスを試行すると、そのユーザーのセキュリティー・ラベルが、データを保護しているセキュリティー・ラベルと比較されます。セキュリティー・ラベルには、保護ラベルによってブロックされるものと、そうでないものがあります。

セキュリティー・ポリシーどのセキュリティー・ラベル・コンポーネントが使用されるかキュリティー・ラベル・コンポーネントを比較する際に、どの規則が使用されるかポリシーにより保護されるデータにアクセスする際に、どのオプションの動作が使用されるか

セキュリティー・ラベル・コンポーネントセキュリティー・ラベル・コンポーネントは、組織のセキュリティー構造をモデル化

するために使用します。

セキュリティー・ラベル

セキュリティー・ポリシー

セキュリティー・ラベルコンポーネント

セキュリティー・ラベル


5

セキュリティー・ラベル・コンポーネントセキュリティー・ラベル・コンポーネントは、組織のセキュリティー構造をモデル化

するために使用します。次の 3 つのタイプのセキュリティー・ラベル・コンポーネントがあります。

TREE : Hierarchy ( ピラミッド型の階層 )

ARRAY : Ordered Set ( 順序集合 )

SET : Set ( 集合 )

projects = { A , B , C , D }

LBAC の構成要素

Corporate (root)

Publishing Software

Development Sales Support

警視正

警部

巡査部長

巡査

階級 = { 警視正 , 警部 , 巡査部長 , 巡査 }

Departments = { Corporate ROOT, Publishing UNDER Corporate Software UNDER Corporate Development UNDER Software Sales UNDER Software Support UNDER Software}


6

LBAC の構成要素セキュリティー・ポリシー

セキュリティー・ラベルとアクセス・ルールの定義をします。ポリシーの一部であるセキュリティー・ラベルにおいて、どのセキュリ

ティー・ラベル・コンポーネントが使用されるかそれらのセキュリティー・ラベル・コンポーネントを比較する際に、どのアク

セス・ルールが使用されるか– 比較には LBAC 規則セットを使用します。

LBAC 規則セットとはセキュリティー・ラベルを比較する際に使用される事前定義された規則のセットです。※サポートされる LBAC 規則セットは、事前定義されている DB2LBACRULES だけです。

例 )CREATE SECURITY POLICY mysecpolicyCOMPONENTS comp1 , comp2 WITH DB2LBACRULES

セキュリティー・ポリシーは 1 表に対し 1 つしか定義できません。


7

LBAC 規則セット : DB2LBACRULES

Read access rules DB2LBACREADARRAY

ユーザーの値が保護値（ LBAC により保護されたデータ）よりも低い DB2LBACREADSET

ユーザーが保持しない保護値が 1 つ以上ある DB2LBACREADTREE

ユーザーの値がいずれも、保護値のいずれとも等しくないか、その上位でない

Write access rules DB2LBACWRITEARRAY

ユーザーの値が保護値より高いか、保護値より低い DB2LBACWRITESET

ユーザーが保持しない保護値が 1 つ以上ある DB2LBACWRITETREE

ユーザーの値がいずれも、保護値のいずれとも等しくないか、その上位でない


8

LBAC 規則セット : DB2LBACRULES DB2LBACREADSET および DB2LBACWRITESET 規則を適用する例

保護値 Aユーザーの値 A

保護値 (A,B,D)

ブロックされません。値は同じです。

ブロックされません。ユーザーの値にはエレメント A が含まれています。

ブロックされます。エレメント D は保護値には含まれていますが、ユーザーの値には含まれていません。

ブロックされません。空の値ではどの値もブロックされません。


ユーザーの値 (A,B,C)

ユーザーの値 (A,B,C)

ユーザーの値 A

ユーザーの値 ()

保護値 A

保護値 ()

保護値 ()


9

LBAC 規則セット : DB2LBACRULES DB2LBACREADTREE および DB2LBACWRITETREE 規則を適用する例

ユーザーの値(Support,Sales)

ブロックされます。エレメント 'Development' はユーザーの値の 1 つではなく、 'Support' および 'Sales' のいずれも 'Development' の上位ではありません。

ブロックされません。エレメント 'Software' は 'Business Sales' の上位です。

ユーザーの値(Development,Software)

ユーザーの値(Publishing,Sales)

ユーザーの値Corporate


保護値(Business Sales,Publishing)

保護値Development

Corporate

Publishing Software

Development Sales Support

BussinessSales

HomeSales

ユーザーの値Home Sales 保護値 ()

ユーザーの値 () 保護値 ()

保護値Development

保護値(Publishing,Support)

保護値Sales

ブロックされません。エレメント 'Publishing' は両方の値のセットに含まれています。

ブロックされません。ルート値は他のすべての値の上位です。

ブロックされます。空の値は空以外のすべての値によりブロックされます。




10

LBAC 規則セット : DB2LBACRULES DB2LBACREADARRAY 規則を適用する例

ユーザーの値　警部




保護値　巡査部長警視正

警部

巡査部長

巡査

ユーザーの値　巡査保護値 ()


保護値　巡査

高

低

保護値　警部

保護値　警視正

ブロックされません。‘警部’ は ‘巡査部長 ' より高位にあります。


ブロックされます。‘警視正’ は ‘警部 ' より高位にあります。





11

LBAC 規則セット : DB2LBACRULES DB2LBACWRITEARRAY 規則を適用する例





警視正

警部

巡査部長

巡査

ユーザーの値　巡査保護値 ()


保護値　巡査

高

低

保護値　警部

保護値　警視正

ブロックされます。 ‘巡査部長’ は ‘警部 ' より下位にあります。


ブロックされます。‘警視正’ は ‘警部 ' より高位にあります。




保護値　巡査部長


12

セキュリティー・ラベル DB2 はユーザー、行、列の 3 つのタイプのセキュリティー・ラベルを区別しま

すユーザー・セキュリティー・ラベル

データベース・ユーザーに許可されるセキュリティー・ラベル行セキュリティー・ラベル

データベースの行に関係があるセキュリティ・ラベル列セキュリティー・ラベル

データベース・テーブルのデータ列に関係があるセキュリティ・ラベル

ユーザーは与えられたセキュリティー・ポリシーから以上のセキュリティー・ラベルに対し Read Access , Write Access , Read/Write Access を許可されます。

セキュリティー・ラベルは、 SQL ステートメントの CREATE SECURITY LABEL で作成します。セキュリティー・ラベルを作成する際には、以下を指定します。ラベルの名そのラベルが含まれるセキュリティー・ポリシーセキュリティー・ポリシーに含まれる 1 つ以上のコンポーネントの値


13

LBAC を使用したデータの保護 LBAC を使用することで、データの行またはデータの列の一方また

は両方を保護することができます。表内のデータは、表を保護するセキュリティー・ポリシーの一部であるセキュリティー・ラベルによってのみ保護できます。データ保護 ( セキュリティー・ポリシーの追加を含む ) は、 CREATE TABLE または ALTER TABLE ステートメントの実行時に追加できます。

行レベルで保護されたデーブル作成の例

DB2SECURITYLABEL のデータ・タイプを持つ列を追加することにより、既存の表内の保護された行を許可することができます。追加するには表にセキュリティー・ポリシーが定義されていなければなりません。

CREATE TABLE T1 (A DB2SECURITYLABEL, B INTEGER, C CHAR(5))

SECURITY POLICY mySecPolicy


14

LBAC を使用したデータの保護列レベルで保護されたデーブル作成の例

CREATE TABLE ステートメントの SECURED WITH 列オプションを使用して表を作成するときに、列を保護することできます。追加するには表にセキュリティー・ポリシーが定義されていなければなりません。

CREATE TABLE T1 ( A CHAR(8) SECURED WITH mySecLabel, B INTEGER,

C CHAR(5))SECURITY POLICY mySecPolicy


15

LBAC の定義

1. セキュリティー・ポリシー　および　セキュリティーラベルの定義

1.1 セキュリティー・ラベル・コンポーネントの定義

1.2 セキュリティー・ポリシーの定義

1.3 セキュリティー・ラベルの定義

2. セキュリティー・ポリシー　および　セキュリティーラベルを付与したテーブルの定義

3. セキュリティー・ラベルをユーザーへ Grant


16

LBAC の定義 ( 例 )

セキュリティー・ポリシー　および　セキュリティーラベルの定義セキュリティー・ラベル・コンポーネントの定義

CREATE SECURITY LABEL COMPONENT SLC_TESTARRAY {'CORP','AP','JP'};

セキュリティー・ポリシーの定義

CREATE SECURITY POLICY TEST_POLICYCOMPONENTS SLC_TESTWITH DB2LBACRULES;

セキュリティー・ラベルの定義

CREATE SECURITY LABEL TEST_POLICY.CORPCOMPONENT SLC_TEST 'CORP';

CREATE SECURITY LABEL TEST_POLICY.APCOMPONENT SLC_TEST 'AP';

CREATE SECURITY LABEL TEST_POLICY.JPCOMPONENT SLC_TEST 'JP';


17

LBAC の定義 ( 例 ) cont’d

セキュリティー・ポリシー　および　セキュリティーラベルを付与したテーブルの定義

CREATE TABLE TEST (C1 INTEGER,C2 VARCHAR(5),C3 INTEGER,C3_TAG DB2SECURITYLABEL)SECURITY POLICY TEST_POLICY;

セキュリティー・ラベルをユーザーへ Grant

GRANT SECURITY LABEL TSET_POLICY.CORPTO USER corp_user FOR ALL ACCESS;

GRANT SECURITY LABEL TSET_POLICY.APTO USER ap_user FOR ALL ACCESS;

GRANT SECURITY LABEL TSET_POLICY.JPTO USER jp_user FOR ALL ACCESS;


18

制限事項等 View

元表に LBAC 保護が定義されている view にアクセスする際には、元表に対する LBAC 保護が施行されます。同じビューに 2 人のユーザーがアクセスすると、それぞれの LBAC情報により異なる行が表示される場合があります。

参照保全制約 LBAC 読み取りアクセス規則は適用されません子表に対して CASCADE 操作が実行される際に LBAC 書き込み規則が適用されます。

ユーザーが親を削除したものの、 LBAC 書き込み規則違反となるためにどの子も削除できない場合には、エラーとなります。

LBAC は、 DAC( 任意アクセス制御 ) により禁止されているデータへのアクセスは、決して許可しません。表からの読み取りの許可がない場合には、その表からのデータの読み取りは許可されません。普通なら LBAC

によってアクセスが許可されるはずの行および列に関しても同様です。 LBAC は、保護データへのアクセスのみを制限します。無保護のデータへのアクセスには影響

ありません。表またはデータベースをドロップする場合、その表またはデータベースに保護データが含まれ

ている場合であっても、 LBAC 情報はチェックされません。データをバックアップする際には LBAC 情報はチェックされません。

表のバックアップを実行できる場合、どの行がバックアップされるかについて、データの LBAC 保護により制限されることはまったくありません。また、バックアップ・メディア上のデータは LBAC により保護されません。データベース上のデータのみが保護されます。

マテリアライズ照会表 (MQT) には適用できませんステージング表には適用できません型付き表には適用できませんニックネームには適用できません


19

複雑なアクセスコントロールはどのように定義されているか？

USER A すべてのデータに Read/Write アクセスできるUSER B 東日本のデータに Read/Write アクセスできるUSER C 西日本のデータに Read/Write アクセスできるUSER D 東京のデータのみ Read アクセスできるUSER E 大阪のデータのみ Read アクセスできる

日本

西日本東日本

大阪東京

ユーザーの階層構造を定義するにはセキュリティー・ラベル・コンポーネント　で定義します

CREATE SECURITY LABEL COMPONENT SLC_REGIONTREE (

‘日本’ ROOT,‘東日本’ UNDER ‘日本’ ,‘西日本’ UNDER ‘日本’ ,‘東京’ UNDER ‘東日本’ ,‘ 大阪’ UNDER ‘西日本 '

);

表 X に対して以下のアクセス制御を実施したい


20

複雑なアクセスコントロールはどのように定義されているか？

USER A すべてのデータに Read/Write アクセスできるUSER B 東日本のデータに Read/Write アクセスできるUSER C 西日本のデータに Read/Write アクセスできるUSER D 東京のデータのみ Read アクセスできるUSER E 大阪のデータのみ Read アクセスできる

日本

西日本東日本

大阪東京

「 USER A はすべてのデータに Read/Write アクセスできるを定義する」　には「すべてのデータへのアクセス」を　セキュリティー・ラベルで定義します

CREATE SECURITY LABEL REGION_POLICY.日本COMPONENT SLC_REGION ‘日本’ ;

「すべてのデータに Read/Write アクセスできる」を USER A にマッピングします

grant security label region_policy.日本 to user JAPAN_USER for all access;


21

複雑なアクセスコントロールはどのように定義されているか？定義した複数のセキュリティー・ラベルを表に定義するには

セキュリティー・ポリシーを作成しそれを表に定義します


CREATE SECURITY POLICY REGION_POLICYCOMPONENTS SLC_REGIONWITH DB2LBACRULESRESTRICT NOT AUTHORIZED WRITE SECURITY LABEL;

セキュリティー・ポリシーを表に定義

CREATE TABLE X (C1 INTC2 CHAR(10)C3 REGION_TAG DB2SECURITYLABEL) SECURITY POLICY REGION_POLICY;

このカラムにある情報でアクセス可否をチェック


22

実際の定義手順

1. セキュリティー・ポリシー　および　セキュリティーラベルの定義

1.1 セキュリティー・ラベル・コンポーネントの定義

1.2 セキュリティー・ポリシーの定義

1.3 セキュリティー・ラベルの定義

2. セキュリティー・ポリシー　および　セキュリティーラベルを付与したテーブルの定義

3. セキュリティー・ラベルをユーザーへ Grant

階層を定義ラベルを定義ポリシーを作成

表に定義ユーザーに Grant


23

列に対するアクセス制御社員番号氏名部署 PHS番

号個人住所個人携帯

1234 野間 IM Tech 070- 千葉県 090-

5678 竹下 IM Sol 070- 東京都 080-

Blue Page に連絡先を公開しよう

でも個人携帯と住所は絶対教えない！

自分のラインと同じグループのメンバーには携帯を教えてもいいかな。。。

人事には個人情報を見られてもしかたない

人事ユーザー　はすべての列に対する R/W アクセスが可能グループのユーザーには　個人住所以外を公開 (Read only)社員全体に対しては個人住所および個人携帯を非公開 (Read only)


24

列に対するアクセス制御

階層の定義

CREATE SECURITY LABEL COMPONENT SLC_LEVELARRAY [‘ 人事’ ,‘ グループ’ ,‘全社員 '];


CREATE SECURITY POLICY LEVEL_POLICYCOMPONENTS SLC_LEVELWITH DB2LBACRULESRESTRICT NOT AUTHORIZED WRITE SECURITY LABEL;



25

列に対するアクセス制御

セキュリティー・ラベルの定義

CREATE SECURITY LABEL LEVEL_POLICY. 人事COMPONENT LEVEL_REGION ‘ 人事’ ;

CREATE SECURITY LABEL LEVEL_POLICY. グループCOMPONENT LEVEL_REGION ‘ グループ’ ;

CREATE SECURITY LABEL LEVEL_POLICY.全社員COMPONENT LEVEL_REGION ‘全社員’ ;



26

列に対するアクセス制御セキュリティー・ポリシーを表に定義

CREATE TABLE T1 ( 社員番号 CHAR(10) SECURED WITH 全社員 ,氏名 CHAR(10) SECURED WITH 全社員 ,部署 CHAR(10) SECURED WITH 全社員 ,PHS番号 CHAR(10) SECURED WITH 全社員 ,個人住所 CHAR(10) SECURED WITH 人事 ,個人携帯 CHAR(10) SECURED WITH グループ )

SECURITY POLICY LEVEL_POLICY

ユーザーに対しセキュリティー・ラベルを Grant

grant security label level_policy.全社員 to user GUEST for read access;grant security label level_policy. グループ to user IM_USER for read access; grant security label level_policy. 人事 to user HR_USER for all access;


27

　　　これまで　　　　　　　　　と　　　　　　これから

東日本

関東

東京

東日本

関東

東京

Label-Based-Access-Control (LBAC) overview

Documents

Transcript of Label-Based-Access-Control (LBAC) overview