280 likes | 427 Views
Label-Based-Access-Control (LBAC) overview. アクセス制御. アクセス制御には強制アクセス制御( MAC: Mandatory Access Control ) 及び、任意アクセス制御( DAC: Discretionary Access Control )があります。
E N D
アクセス制御 • アクセス制御には強制アクセス制御(MAC: Mandatory Access Control)及び、任意アクセス制御(DAC: Discretionary Access Control)があります。 • DAC は、ユーザID あるいは、グループID に基づいてオブジェクトへのアクセスを制御するアクセス制御方式。(WindowsやLinux , Unixと同様)ユーザーが自分の所有するファイルやディレクトリのアクセス権(パーミッション)を自由に変更できます。また,rootユーザーは無制限にファイルやディレクトリにアクセスしたり,パーミッションの設定を変更したりできます。 • MAC は、システムのサブジェクトとオブジェクトの関連を強制的なセキュリティポリシーとして定義し、システムがそのアクセス制御方針を運用するアクセス制御方式です。ユーザーは自分の所有するファイルやディレクトリに対してもあらかじめ設定されたアクセスしか行えません。アクセス権限の変更も行えません。これはrootユーザーにも当てはまります。アクセス権限を設定・変更できるのは,セキュリティ管理者のみです。
Label-Based-Access-Control (LBAC) • ラベル・ベースのアクセス制御(LBAC)はMACをベースに実装されており、データにどのユーザーがアクセスできるかに対する制御を大きく向上させます。 LBAC を使用すると、個々の行および個々の列に対して、どのユーザーに書き込みアクセスがあり、どのユーザーに読み取りアクセスがあるのかを厳密に決定することができます。 • 行レベル でのアクセス・コントロール • 列レベル でのアクセス・コントロール この2つを組み合わせて使用することも可能です。 • LBAC 構成はセキュリティー管理者 により実行されます。セキュリティー管理者は、システム管理者により SECADM 権限が付与されているユーザーです。この権限が付与されていると、保有者はデータベースのセキュリティー関連のさまざまな構成を行うことができ、さらにはデータベース・オブジェクトの所有権を転送することもできます。たとえば、SECADM 権限を持つユーザーは、ラベル・ベースのアクセス制御 (LBAC) 機能の一部であるオブジェクトすべての作成、ドロップ、権限付与、取り消しを行えます。 SECADM だけが行えることは、SYSADM を含め、他のどの権限でも行えません。
LBAC の構成(概要) セキュリティー・ポリシー • セキュリティー管理者 (SECADM) は、セキュリティー・ポリシーを作成して LBAC システムを構成します。セキュリティー・ポリシー には、どのデータに誰がアクセスできるかを判断するために使用される基準(セキュリティー・ラベル・コンポーネント)を記述します。任意の 1 つの表を保護するために 1 つのセキュリティー・ポリシーしか使用できませんが、複数のセキュリティー・ポリシーを使用して複数の表を保護することができます。セキュリティー・ポリシーを作成した後、そのポリシーの一部であるセキュリティー・ラベル というオブジェクトを作成します。作成が完了すると、セキュリティー・ラベルを表の個々の列と行に関連付けてそこに保持されているデータを保護することができます。セキュリティー・ラベルにより保護されるデータは、保護データ と呼ばれます。セキュリティー管理者は、ユーザーにセキュリティー・ラベルを付与することにより、保護データへのアクセスを許可します。ユーザーが保護データへのアクセスを試行すると、そのユーザーのセキュリティー・ラベルが、データを保護しているセキュリティー・ラベルと比較されます。セキュリティー・ラベルには、保護ラベルによってブロックされるものと、そうでないものがあります。 • セキュリティー・ポリシー • どのセキュリティー・ラベル・コンポーネントが使用されるか • キュリティー・ラベル・コンポーネントを比較する際に、どの規則が使用されるか • ポリシーにより保護されるデータにアクセスする際に、どのオプションの動作が使用されるか • セキュリティー・ラベル・コンポーネント • セキュリティー・ラベル・コンポーネントは、組織のセキュリティー構造をモデル化するために使用します。 • セキュリティー・ラベル セキュリティー・ラベル コンポーネント セキュリティー・ラベル
警視正 警部 巡査部長 巡査 Corporate (root) Software Publishing Development Sales Support LBACの構成要素 • セキュリティー・ラベル・コンポーネント • セキュリティー・ラベル・コンポーネントは、組織のセキュリティー構造をモデル化するために使用します。 • 次の 3 つのタイプのセキュリティー・ラベル・コンポーネントがあります。 • TREE : Hierarchy (ピラミッド型の階層) • ARRAY : Ordered Set (順序集合) • SET : Set (集合) projects = {A , B , C , D } Departments = { Corporate ROOT, Publishing UNDER Corporate Software UNDER Corporate Development UNDER Software Sales UNDER Software Support UNDER Software} 階級 = { 警視正 , 警部 , 巡査部長 , 巡査 }
LBACの構成要素 • セキュリティー・ポリシー • セキュリティー・ラベルとアクセス・ルールの定義をします。 • ポリシーの一部であるセキュリティー・ラベルにおいて、どのセキュリティー・ラベル・コンポーネントが使用されるか • それらのセキュリティー・ラベル・コンポーネントを比較する際に、どのアクセス・ルールが使用されるか • 比較にはLBAC規則セットを使用します。LBAC規則セットとはセキュリティー・ラベルを比較する際に使用される事前定義された規則のセットです。※サポートされる LBAC 規則セットは、事前定義されている DB2LBACRULES だけです。 例)CREATE SECURITY POLICY mysecpolicyCOMPONENTS comp1 , comp2 WITH DB2LBACRULES • セキュリティー・ポリシーは1表に対し1つしか定義できません。
LBAC規則セット : DB2LBACRULES • Read access rules • DB2LBACREADARRAY • ユーザーの値が保護値(LBACにより保護されたデータ)よりも低い • DB2LBACREADSET • ユーザーが保持しない保護値が 1 つ以上ある • DB2LBACREADTREE • ユーザーの値がいずれも、保護値のいずれとも等しくないか、その上位でない • Write access rules • DB2LBACWRITEARRAY • ユーザーの値が保護値より高いか、保護値より低い • DB2LBACWRITESET • ユーザーが保持しない保護値が 1 つ以上ある • DB2LBACWRITETREE • ユーザーの値がいずれも、保護値のいずれとも等しくないか、その上位でない
保護値 () 保護値 () 保護値 A 保護値 A 保護値 (A,B,D) ユーザーの値 (A,B,C) ユーザーの値 (A,B,C) ユーザーの値 () ユーザーの値 A ユーザーの値 A LBAC規則セット : DB2LBACRULES • DB2LBACREADSET および DB2LBACWRITESET 規則を適用する例 ブロックされません。値は同じです。 ブロックされません。ユーザーの値にはエレメント A が含まれています。 ブロックされます。エレメント D は保護値には含まれていますが、ユーザーの値には含まれていません。 ブロックされません。空の値ではどの値もブロックされません。 ブロックされません。空の値ではどの値もブロックされません。
保護値 (Business Sales,Publishing) 保護値 (Publishing,Support) 保護値 Development 保護値 Development 保護値 Sales 保護値 () 保護値 () ユーザーの値 (Development,Software) ユーザーの値 (Support,Sales) ユーザーの値 (Publishing,Sales) ユーザーの値 Home Sales ユーザーの値 Corporate ユーザーの値 () ユーザーの値 () LBAC規則セット : DB2LBACRULES ブロックされます。エレメント 'Development' はユーザーの値の 1 つではなく、'Support' および 'Sales' のいずれも 'Development' の上位ではありません。 • DB2LBACREADTREE および DB2LBACWRITETREE 規則を適用する例 ブロックされません。エレメント 'Software' は 'Business Sales' の上位です。 Corporate Publishing Software ブロックされません。エレメント 'Publishing' は両方の値のセットに含まれています。 Development Sales Support ブロックされません。ルート値は他のすべての値の上位です。 Bussiness Sales Home Sales ブロックされます。空の値は空以外のすべての値によりブロックされます。 ブロックされません。空の値ではどの値もブロックされません。 ブロックされません。空の値ではどの値もブロックされません。
保護値 警視正 保護値 巡査 保護値 巡査部長 保護値 警部 保護値 () 保護値 () ユーザーの値 警部 ユーザーの値 警部 ユーザーの値 警部 ユーザーの値 巡査 ユーザーの値 () ユーザーの値 () LBAC規則セット : DB2LBACRULES ブロックされません。‘警部’ は ‘巡査部長' より高位にあります。 高 • DB2LBACREADARRAY 規則を適用する例 警視正 ブロックされません。値は同じです。 警部 ブロックされます。‘警視正’ は ‘警部' より高位にあります。 巡査部長 ブロックされます。空の値は空以外のすべての値によりブロックされます。 巡査 低 ブロックされません。空の値ではどの値もブロックされません。 ブロックされません。空の値ではどの値もブロックされません。
保護値 警視正 保護値 巡査 保護値 巡査部長 保護値 警部 保護値 () 保護値 () ユーザーの値 警部 ユーザーの値 警部 ユーザーの値 警部 ユーザーの値 巡査 ユーザーの値 () ユーザーの値 () LBAC規則セット : DB2LBACRULES ブロックされます。 ‘巡査部長’ は ‘警部' より下位にあります。 高 • DB2LBACWRITEARRAY 規則を適用する例 警視正 ブロックされません。値は同じです。 警部 ブロックされます。‘警視正’ は ‘警部' より高位にあります。 巡査部長 ブロックされます。空の値は空以外のすべての値によりブロックされます。 巡査 低 ブロックされません。空の値ではどの値もブロックされません。 ブロックされません。空の値ではどの値もブロックされません。
セキュリティー・ラベル • DB2はユーザー、行、列の3つのタイプのセキュリティー・ラベルを区別します • ユーザー・セキュリティー・ラベル • データベース・ユーザーに許可されるセキュリティー・ラベル • 行セキュリティー・ラベル • データベースの行に関係があるセキュリティ・ラベル • 列セキュリティー・ラベル • データベース・テーブルのデータ列に関係があるセキュリティ・ラベル • ユーザーは与えられたセキュリティー・ポリシーから以上のセキュリティー・ラベルに対し Read Access , Write Access , Read/Write Access を許可されます。 • セキュリティー・ラベルは、SQL ステートメントの CREATE SECURITY LABEL で作成します。セキュリティー・ラベルを作成する際には、以下を指定します。 • ラベルの名 • そのラベルが含まれるセキュリティー・ポリシー • セキュリティー・ポリシーに含まれる 1 つ以上のコンポーネントの値
LBAC を使用したデータの保護 • LBACを使用することで、データの行またはデータの列の一方または両方を保護することができます。表内のデータは、表を保護するセキュリティー・ポリシーの一部であるセキュリティー・ラベルによってのみ保護できます。データ保護 (セキュリティー・ポリシーの追加を含む) は、CREATE TABLE または ALTER TABLE ステートメントの実行時に追加できます。 • 行レベルで保護されたデーブル作成の例DB2SECURITYLABEL のデータ・タイプを持つ列を追加することにより、既存の表内の保護された行を許可することができます。追加するには表にセキュリティー・ポリシーが定義されていなければなりません。CREATE TABLE T1 (A DB2SECURITYLABEL, B INTEGER, C CHAR(5))SECURITY POLICY mySecPolicy
LBAC を使用したデータの保護 • 列レベルで保護されたデーブル作成の例CREATE TABLE ステートメントの SECURED WITH 列オプションを使用して表を作成するときに、列を保護することできます。追加するには表にセキュリティー・ポリシーが定義されていなければなりません。 CREATE TABLE T1 (A CHAR(8) SECURED WITH mySecLabel, B INTEGER, C CHAR(5))SECURITY POLICY mySecPolicy
LBACの定義 1. セキュリティー・ポリシー および セキュリティーラベルの定義 1.1 セキュリティー・ラベル・コンポーネントの定義 1.2 セキュリティー・ポリシーの定義 1.3 セキュリティー・ラベルの定義 2. セキュリティー・ポリシー および セキュリティーラベルを付与したテーブルの定義 3. セキュリティー・ラベルをユーザーへGrant
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';
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;
制限事項等 • View • 元表にLBAC保護が定義されているviewにアクセスする際には、元表に対する LBAC 保護が施行されます。同じビューに 2 人のユーザーがアクセスすると、それぞれの LBAC情報により異なる行が表示される場合があります。 • 参照保全制約 • LBAC読み取りアクセス規則は適用されません • 子表に対して CASCADE 操作が実行される際に LBAC 書き込み規則が適用されます。ユーザーが親を削除したものの、LBAC 書き込み規則違反となるためにどの子も削除できない場合には、エラーとなります。 • LBAC は、DAC(任意アクセス制御)により禁止されているデータへのアクセスは、決して許可しません。 • 表からの読み取りの許可がない場合には、その表からのデータの読み取りは許可されません。普通なら LBAC によってアクセスが許可されるはずの行および列に関しても同様です。 • LBAC は、保護データへのアクセスのみを制限します。無保護のデータへのアクセスには影響ありません。 • 表またはデータベースをドロップする場合、その表またはデータベースに保護データが含まれている場合であっても、LBAC 情報はチェックされません。 • データをバックアップする際には LBAC 情報はチェックされません。表のバックアップを実行できる場合、どの行がバックアップされるかについて、データの LBAC 保護により制限されることはまったくありません。また、バックアップ・メディア上のデータは LBAC により保護されません。データベース上のデータのみが保護されます。 • マテリアライズ照会表 (MQT) には適用できません • ステージング表 には適用できません • 型付き表 には適用できません • ニックネームには適用できません
複雑なアクセスコントロールはどのように定義されているか?複雑なアクセスコントロールはどのように定義されているか? 日本 表 X に対して以下のアクセス制御を実施したい • ユーザーの階層構造を定義するには • セキュリティー・ラベル・コンポーネント で定義しますCREATE SECURITY LABEL COMPONENT SLC_REGIONTREE ( ‘日本’ ROOT, ‘東日本’ UNDER ‘日本’, ‘西日本’ UNDER ‘日本’, ‘東京’ UNDER ‘東日本’, ‘大阪’ UNDER ‘西日本' ); USER A すべてのデータにRead/Writeアクセスできる USER B 東日本のデータにRead/Writeアクセスできる USER C 西日本のデータにRead/Writeアクセスできる USER D 東京のデータのみReadアクセスできる USER E 大阪のデータのみReadアクセスできる 西日本 東日本 大阪 東京
複雑なアクセスコントロールはどのように定義されているか?複雑なアクセスコントロールはどのように定義されているか? 日本 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; 西日本 東日本 大阪 東京
複雑なアクセスコントロールはどのように定義されているか?複雑なアクセスコントロールはどのように定義されているか? • 定義した複数のセキュリティー・ラベルを表に定義するには • セキュリティー・ポリシーを作成しそれを表に定義しますセキュリティー・ポリシーの定義CREATE SECURITY POLICY REGION_POLICYCOMPONENTS SLC_REGIONWITH DB2LBACRULESRESTRICT NOT AUTHORIZED WRITE SECURITY LABEL; • セキュリティー・ポリシーを表に定義CREATE TABLE X ( C1 INT C2 CHAR(10)C3 REGION_TAG DB2SECURITYLABEL ) SECURITY POLICY REGION_POLICY; このカラムにある情報で アクセス可否をチェック
実際の定義手順 1. セキュリティー・ポリシー および セキュリティーラベルの定義 1.1 セキュリティー・ラベル・コンポーネントの定義 1.2 セキュリティー・ポリシーの定義 1.3 セキュリティー・ラベルの定義 2. セキュリティー・ポリシー および セキュリティーラベルを付与したテーブルの定義 3. セキュリティー・ラベルをユーザーへGrant 表に定義 階層を定義 ユーザーにGrant ポリシーを作成 ラベルを定義
列に対するアクセス制御 Blue Page に連絡先を公開しよう でも個人携帯と住所は絶対教えない! 自分のラインと同じグループのメンバーには携帯を教えてもいいかな。。。 人事には個人情報を見られてもしかたない 人事ユーザー はすべての列に対するR/Wアクセスが可能 グループのユーザーには 個人住所以外を公開 (Read only) 社員全体に対しては個人住所および個人携帯を非公開 (Read only)
列に対するアクセス制御 人事ユーザー はすべての列に対するR/Wアクセスが可能 グループのユーザーには 個人住所以外を公開 (Read only) 社員全体に対しては個人住所および個人携帯を非公開 (Read only) • 階層の定義CREATE SECURITY LABEL COMPONENT SLC_LEVELARRAY [‘人事’,‘グループ’,‘全社員']; • セキュリティー・ポリシーの定義CREATE SECURITY POLICY LEVEL_POLICYCOMPONENTS SLC_LEVELWITH DB2LBACRULESRESTRICT NOT AUTHORIZED WRITE SECURITY LABEL;
列に対するアクセス制御 人事ユーザー はすべての列に対するR/Wアクセスが可能 グループのユーザーには 個人住所以外を公開 (Read only) 社員全体に対しては個人住所および個人携帯を非公開 (Read only) • セキュリティー・ラベルの定義CREATE SECURITY LABEL LEVEL_POLICY.人事COMPONENT LEVEL_REGION ‘人事’;CREATE SECURITY LABEL LEVEL_POLICY.グループCOMPONENT LEVEL_REGION ‘グループ’;CREATE SECURITY LABEL LEVEL_POLICY.全社員COMPONENT LEVEL_REGION ‘全社員’;
列に対するアクセス制御 • セキュリティー・ポリシーを表に定義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 • ユーザーに対しセキュリティー・ラベルをGrantgrant 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;
これまで と これから これまで と これから 東日本 東日本 関東 関東 東京 東京