暗号化を用いた動的データマスキング

このチュートリアルでは、Netezza Performance Serverで暗号化を使用してダイナミック・データ・マスキングを構成し、使用する方法を説明します。

ダイナミック・データ・マスキングは、フィールドやテーブル・カラムのようなデータベース・オブジェクト内の機密データを、権限のないユーザーからマスキングすることで、不正アクセスを防ぐのに役立ちます。 マスキング・ルールが適用されるのはクエリ結果のみで、データベース内のデータは影響を受けないため、このデータへのアクセスが必要な他のアプリケーションでも使用できる。

このタスクについて

このチュートリアルでは、以下のスキーマ例を使用します:

このタスクで使用するスキーマ

customer_nameと'customer_addressは、マスクと暗号化が必要な機密カラムである。 これらのテーブルにアクセスできる(つまり、'SELECT権限を持っている)ユーザーのうち、'ACCOUNTSロールを持つユーザーだけが、2つの機密カラムの閲覧を許可されている。 他のユーザーに対しては、これらの値は暗号化によってマスクされる。

これを行う標準的な方法は、基礎となるテーブルへのアクセスを制限し、ユーザーの役割に応じて値を変更するビューをテーブルの上に重ねることである。 これを行うには、まず基礎となるテーブルの名前を変更し、元のテーブル名を使用して、アクセス権を持つロールに基づいて機密カラムの暗号化された値を投影するビューを作成します。

手順

  1. 暗号化キーを定義する:

    これは1回だけのステップだ。

    管理者だけが権限とアクセス権を持つ別のテーブルを作成し、マスキングに使用する暗号化キーを設定する。 データベース管理者として:
    create table encryption_keys (key varchar(30)); 
    insert into encryption_keys values('<your key value goes here>');
  2. ベース・テーブルの名前を変更して準備し、その上にマスキング・ビューを作成する。
    データベース管理者として:
    alter table customers rename to customers_table;
    create or replace view customers as
    select
    customer_id,
    case when current_role = 'ACCOUNTS' then customer_name
    else encrypt(customer_name, (select encryption_keys.key)) end as customer_name,
    case when current_role = 'ACCOUNTS' then customer_address
    else encrypt(customer_address, (select encryption_keys.key)) end as customer_address,
    customer_state,
    customer_zip
    from customers_table;
    ヒント:暗号化を使ってデータをマスキングする代わりに、同じ手順で単純なマスキングやデータを完全に隠すこともできる:
    
    CREATE VIEW customers AS 
    SELECT customer_id, 
           CASE WHEN current_role = 'ACCOUNTS' THEN customer_name 
                ELSE '*****' -- this could be NULL if the column was not (VAR)CHAR
           END AS customer_name,
           CASE WHEN current_role = 'ACCOUNTS' THEN customer_address
                ELSE '*****'
           END AS customer_address,
           customer_state,
           customer_zip
    FROM "$customers_base";
    しかし、暗号化を使ってマスキングすることの利点は、必要であれば、例えばこのテーブルの暗号化されたカラムと別のテーブルの暗号化されたカラムを結合しても、行の関係を維持できることです。 カラムが単にマスクされていたり、NULLとして扱われていたりすると、これは不可能である。
  3. 選択したユーザに「ACCOUNTSロールを付与する。

    このステップでは、ユーザのサブセットに「ACCOUNTSロールを引き受ける特権を許可する。 例えば、ユーザー「alice、「bob、「clarkグループにおいて、「alice」と「bobACCOUNTSロールの権限を必要とする。

    create role accounts;
    grant list on accounts to alice, bob;
    次に、customers(マスクされたビュー)とorders(テーブル)に対してクエリを実行する権限を付与します。
    grant select on  customers, orders  to  public, accounts;

    この時点で、ダイナミック・マスキングはセットアップされ、使用する準備が整った。

結果

ユーザー「alice」が、州コード別に分類された合計「order_amountレポートを必要としているとします:
select
sum(order_amount) as total,
customer_state
from customers inner join orders using (customer_id)
group by customer_state;
合計 CUSTOMER_STATE
10750.01 ニューヨーク
2000.00 テキサス
99.99 XX

アリスは CUSTOMERS (マスクされたビュー) にアクセスできます。 customer_idカラムは暗号化されておらず、ORDERSテーブルとの結合に使用される。 customer_stateカラムは暗号化されておらず、(州ごとの)ロールアップに使用される。 しかし、'customer_nameと'customer_addressは微妙だ。 もし彼女がそれを見ることを選択しても、暗号化されている:

select * from customers order by customer_id;
CUSTOMER_ID 顧客名 顧客アドレス CUSTOMER_STATE カスタマー・ジップ
10031 &J.&#+RXV /u/%9$,1WZJ\*?<1L3- テキサス 90210
21451 INR0-F50_0 1U*"\(7H"V;3S%NH0]!= ['T ニューヨーク 55555
43918 I_*$)VM0X0 0U+;!="XWV;#T&^Y#F#=8[ ニューヨーク 98765
60844 M>6%(7Q0Y@ -T+#!9$@9T+#T6L(5L0 ニューヨーク 55554
80008 H>F0*F]0Y@ 1L>B4*7<#U:WN&Z,JISI7YS< XX 0
Aliceが暗号化されていない列にアクセスする必要がある場合、Aliceには暗号化されていないソースデータを見ることができる'ACCOUNTSロールの権限が与えられている:
set role accounts;
select * from customers order by customer_id;
CUSTOMER_ID 顧客名 顧客アドレス CUSTOMER_STATE カスタマー・ジップ
10031 マークF 234 メイン・ストリート テキサス 90210
21451 クラーク・K 1 メトロポリス・アベニュー ニューヨーク 55555
43918 ブルース・W 1600 ゴッサムレーン ニューヨーク 98765
60844 ピーター・P 500フィフス・アヴェニュー ニューヨーク 55554
80008 ダイアナ・P テミスキラ島 XX 0