機密データの表示をマスキング!Oracle Data Redactionの概要と12cR2機能強化

はじめに

昨今、頻繁にニュース等で報道されているセキュリティ・インシデントを受け、弊社でも機密情報を取り扱う基幹システムにおけるOracle Databaseセキュリティ強化のご相談を多数いただいています。相談のなかで良く頂戴する要望に、アプリケーションへの影響をできるだけ少なくしたい、運用コストの増加を可能な限り抑えたいというものがあります。

そこで、本稿では、数あるセキュリティ関連の機能から、既存システムへの影響をできるだけ少なく、かつ、運用コストの増加を可能な限り抑えて、セキュリティの向上が期待できる機能として「Oracle Data Redaction」とOracle Database 12cR2で機能強化された点をご紹介します。

杉本　順、岡野 平八郎 株式会社コーソル

※: Oracle Data RedactionはOracle Advanced Security Optionの機能です。また、Oracle Advanced Security Option は、Enterprise Editionのオプションです。

• 1. データ・リダクションとは
• 2. 12cR1までのリリースにおける課題
• 3. 12cR2におけるリダクションの新機能
• 4. まとめ

1. データ・リダクションとは

1.1. Oracle Data Redactionの紹介

これからご紹介するOracle Data Redactionは、データベースに格納されているデータには一切の変更を加えることなく、問い合わせに対して返される結果のみをリダクション(マスキング)する機能です。

具体的なOracle Data Redactionの特徴としては以下が挙げられます。

• Oracle Database単独で実装される機能であり、アプリケーションの修正は原則的に不要
• ユーザーやアプリケーションによる機密データの参照を最小限に抑える事ができる
• データ表示のみをリダクション(マスキング)しており、実データを変更しない

Oracle Data Redactionの用例としては、PCI DSS(クレジットカード業界のセキュリティ基準)などの業界規則を満たす目的などが挙げられます。具体的には、カード会員番号(PAN：Primary Account Number)のマスキング要件に対応することができます。

PCI DSS v3.0 要件:3.3

表示時にPANをマスキングして（最初の6桁と最後の4桁が最大表示桁数）、業務上の正当な必要性がある関係者だけがPAN全体を見ることができるようにする。

引用元

Payment Card Industry（PCI）データセキュリティ基準 バージョン 3.0

https://ja.pcisecuritystandards.org/_onelink_/pcisecurity/en2ja/minisite/en/docs/PCI_DSS_v3.pdf

　図1で示すようにOracle Database内にリダクションする条件を定義したリダクション・ポリシーを作成および適用することで、業務上の正当な必要性がある関係者(管理者)は、PAN全体を表示させ、オペレータは最後の4桁のみ表示(最初の12桁を’*’でリダクション)とする事ができます。

図1:Oracle Data Redactionの用例

以降で、Oracle Database Redactionの具体的な機能を紹介します。

1.2. リダクション・ポリシーの構成

Oracle Data Redactionの機能により、リダクションを行うためには、まず、リダクション・ポリシーを作成し、リダクションの条件を定義する必要があります。このリダクション・ポリシーには、リダクション対象のオブジェクト、リダクションの種類、実行する条件などを定義します。表2にリダクション・ポリシーを定義するために必要な項目と特徴を示します。

表1:リダクション・ポリシーの構成要素

リダクション・ポリシーを作成する際には、リダクションの要件に最も適したポリシーを検討しておく必要があります。また、リダクション・ポリシーの定義には制限事項があるため、その特徴を十分に把握しておくことが重要です。

1.3. Oracle Data Redactionで実現できるリダクションの種類

Oracle Data Redactionで実現できるリダクションの種類を紹介します。Oracle Data Redactionでは様々なケースに対応できるように5種類のリダクション方法が提供されています。

表2:リダクション方法の一覧

これらリダクション方法の設定は、DBMS_REDACTパッケージ・プロシージャを使用して、コマンドでリダクション・ポリシーを定義する方法と運用管理ツール(Oracle Enterprise Manager Cloud Control)より、画面操作で定義する方法が提供されています。

以降では、先に用例として挙げたPCI DSSのPANのマスキング要件をもとにコマンドによる設定例を紹介します。

1.4. リダクション・ポリシーの設定例

ここでは、図2で示すように管理者以外のユーザがクレジット会員テーブルを参照した際に、NAME列とPAN列がリダクションされるように実装してみたいと思います。

【図2:リダクション・ポリシーの設定イメージ】

まず、図2の要件(イメージ)を満たすようにクレジット会員テーブルのリダクション・ポリシーを表3のとおりに設計します。

表3:クレジット会員テーブルのリダクション・ポリシー定義

設計したリダクション・ポリシーを実装していきます。リダクションを定義するには、DBMS_REDACT.ADD_POLICYプロシージャを使用し、リダクション・ポリシーを作成します。このプロシージャを実行するためには、DBMS_REDACTパッケージに対するEXECUTE権限が必要です。リダクション・ポリシーを作成するDBユーザ(本例ではクレジット会員テーブルを所持する”ADMIN”ユーザ)に権限を付与します。

• DBMS_REDACTパッケージに対するEXECUTE権限付与

SQL> GRANT EXECUTE ON SYS.DBMS_REDACT TO ADMIN;  

ADMINユーザでDBに再接続し、リダクション・ポリシーを作成します。なお、作成時に指定できるリダクション対象列は、1つのため、先にPAN列の部分リダクションの定義を行い、後からNAME列の完全リダクション定義を追加します。

• リダクション・ポリシーの作成

SQL> BEGIN
  2    DBMS_REDACT.ADD_POLICY(
  3      object_schema       => 'ADMIN',
  4      object_name         => 'CREDIT_MEMBER',
  5      column_name         => 'PAN',
  6      policy_name         => 'CREDIT_MEMBER_POLICY',
  7      function_type       => DBMS_REDACT.PARTIAL,
  8      function_parameters => 'VVVVFVVVVFVVVVFVVVV,VVVV-VVVV-VVVV-VVVV,*,1,12',
  9      expression          => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''ADMIN''');
 10  END;
 11  /
	

このリダクション・ポリシー作成で使用したDBMS_REDACT.ADD_POLICYプロシージャのパラメータの詳細は、表4のとおりです。

表4:DBMS_REDACT.ADD_POLICYで指定するパラメータ

次に、作成したリダクション・ポリシー(CREDIT_MEMBER_POLICY)にNAME列の完全リダクションの定義を追加します。リダクション対象の列を追加する際には、DBMS_REDACT.ALTER_POLICYプロシージャを利用します。

表5:DBMS_REDACT.ALTER_POLICY文で指定するパラメータ

• 既存のリダクション・ポリシーにNAME列を追加

SQL> BEGIN
2   DBMS_REDACT.ALTER_POLICY(
3     object_schema       => 'ADMIN',
4     object_name         => 'CREDIT_MEMBER',
5     column_name         => 'NAME',
6     policy_name         => 'CREDIT_MEMBER_POLICY',
7     action              => DBMS_REDACT.ADD_COLUMN,
8     function_type       => DBMS_REDACT.FULL);
9 END;
 10 /	
	

　完全リダクションされる値は、データ型ごとに定義します。デフォルトでは、NUMBERデータ型の列はゼロ(0)で、文字データ型の列は1つのスペース( )で表示されます。ここでは、VARCHARデータ型が‘-’(ハイフン)でリダクションする設定を行います。

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを使用することにより、このデフォルト値を変更できます。

• VARCHARデータ型のデフォルト値の変更

SQL> EXEC DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES (varchar_val => '-');  

変更した内容を反映するためには、DBインスタンスの再起動が必要です。DBインスタンス再起動に必要な権限が付与されたユーザに切り替えて、再起動を行います。

• DBインスタンスの再起動

SQL> shutdown immediate  SQL> startup  

リダクション・ポリシーが定義できたら、実際に各ユーザで、クレジット会員テーブルを参照してみましょう。ここでは、事前にオペレータおよびゲストユーザが作成されており、クレジット会員テーブルへのオブジェクト参照の権限が付与されているものとします。

• オペレータ(OPERATOR)でクレジット会員テーブルを参照

SQL> SHOW USER
USER is "OPERATOR"
SQL> SELECT * FROM ADMIN.CREDIT_MEMBER;

NAME     PAN
-------- --------------------
-        ****-****-****-4444
-        ****-****-****-8888	
	

ご覧のとおり、NAME列は、’-(ハイフン)’で表示され、PAN列は最後の4桁を除き、リダクションされていることが確認できます。次に管理ユーザ(ADMIN)でクレジット会員テーブルを参照した場合の動作を確認します。

• 管理者(ADMIN)でクレジット会員テーブルを参照

SQL> SHOW USER
USER is "ADMIN"
SQL> SELECT * FROM ADMIN.CREDIT_MEMBER;

NAME     PAN
-------- --------------------
Sugimoto 1111-2222-3333-4444
Okano    5555-6666-7777-8888	
	

ポリシー式の条件(DBユーザがADMIN以外であればTRUE)を満たさないため、リダクションされずに表示されていることが確認できます。

このように、どのユーザでリダクションが行われるかどうかの判定は、ポリシー式(expression)によって制御できることを確認いただきました。このポリシー式(expression)が12cR2の新機能に大きく関連します。

以降で、これまでのリリースにおけるOracle Data Redactionの課題を踏まえ、12cR2の新機能を紹介します。

●　Point：リダクションされないケース  以下条件を満たす場合、ポリシーが作成されていてもリダクションされないため注意してください。       1.	SYSDBA権限を使用してログインしているユーザ     2.	EXEMPT REDACTION POLICYシステム権限が付与されているユーザ     3.	バックアップおよびリカバリ、Oracle Data Pumpエクスポート/インポート、Oracle Data Guard操作、レプリケーションなどの操作  

●　Point：リダクションされないケース
以下条件を満たす場合、ポリシーが作成されていてもリダクションされないため注意してください。

   1.	SYSDBA権限を使用してログインしているユーザ
   2.	EXEMPT REDACTION POLICYシステム権限が付与されているユーザ
   3.	バックアップおよびリカバリ、Oracle Data Pumpエクスポート/インポート、Oracle Data Guard操作、レプリケーションなどの操作	
	

2. 12cR1までのリリースにおける課題

ここまで、Oracle Data Redactionの機能や使い方を簡単に紹介してきましたが、以降では、1.2で紹介したリダクション・ポリシーの制限事項(表またはビューに定義できるポリシーは1つなど)に起因する12cR1までのリリースにおける課題を2つ紹介します。

2.1. ケース1：リダクション対象列ごとに異なるポリシー式の適用

1つ目のケースは、リダクション対象列ごとに異なるポリシー式を適用したい場合です。例えば、図1で紹介した構成に、以下のようなユーザ追加の要件が発生したと仮定します。

[要件]

• 　新しくゲストユーザを追加する
• 　ゲストユーザは、オペレータユーザと同様にPAN列を最後の4桁だけ表示する
• 　ゲストユーザーのみ、NAME列を全て‘-(ハイフン)’で表示する

この要件を満たすように構成するには、列ごとにDBユーザで条件分岐するポリシー式(実行条件)を定義する必要がありますが、ポリシー式には、以下制限があります。

• 　リダクション・ポリシーに指定できるポリシー式は1つのみ

また、リダクション対象列ごとに異なるポリシー式を定義したリダクション・ポリシーを複数作成すれば要件を満たせますが、「表またはビューに定義できるポリシーは1つ」の制限に抵触します。

【図3:Oracle Data Redactionの制限】

このケースの解決策の１つとして、12cR1までのリリースでは、以下の図4のようにユーザごとにビューとリダクション・ポリシーを作成し、ビューに対してポリシー式が異なるリダクション・ポリシーを設定することで実現する方法があります。

【図4:リダクション対象列ごとに異なるポリシー式を適用する方法(DB12cR1まで)】

しかしながら、この方法では、ユーザごとに参照するビューを切り替える仕組みをアプリケーションなどで実装する必要があります。これでは、アプリケーションへの影響を極小化するOracle Data Redactionのメリットが損なわれてしまいます。

このようにポリシー式(実行条件)を柔軟に定義できないことが１つ目の課題です。

2.2. ケース2：リダクション・ポリシーの変更管理

２つ目は、リダクション・ポリシーの変更管理に関する課題です。図5で示すようなリダクション・ポリシーが定義されている構成で、リダクション・ポリシーを適用するユーザの変更が生じた場合、ポリシー式の実行条件を変更する必要があります。

【図5:リダクション・ポリシー変更管理の課題】

同様な構成の表またはビューに対して、リダクション・ポリシーが適用されている場合、多数のリダクション・ポリシーを修正する必要があり、運用管理のコストが増えてしまうことが懸念されます。

これが２つ目の課題となります。

12cR2ではこれらの課題に対して、どのような解決策が用意されたのか、詳細を以降に記載したいと思います。

3. 12cR2におけるリダクションの新機能

3.1. 名前付きポリシー式

先に挙げた課題の解決につながる新機能として、12cR2では、名前付きポリシー式の機能が実装されています。

3.1.1 名前付きポリシー式とは

名前付きポリシー式は、図6で示すように複数の表およびビューの列に紐付く、ポリシー式のライブラリのようなものとなります。

【図6:名前付きポリシー式の特徴】

類似するポリシー式を持つ複数の表のリダクション対象列を名前付きポリシー式の対象列に紐付けることで、ポリシー式を共通化し、集中管理することができます。

また、リダクション・ポリシーのポリシー式との大きな違いとして、名前付きポリシー式は表単位ではなく、列単位で紐付くため、より柔軟なリダクション・ポリシーの設定が可能となります。

その他、名前付きポリシー式の特徴は以下のとおりです。

• 　同じまたは異なる表またはビューの複数の列に関連付けることができます。
• 　同じまたは異なるデータ・リダクション・ポリシー内の列に関連付けることができます。
• 　関連付けられた列のデフォルトのポリシー式をオーバーライドします。
• 　名前付きポリシー式に対して行われた更新は、式のすべての列関連付けに適用されます。
• 　複数の名前付きポリシー式を同じ列に関連付けることはできません。

この名前付きポリシー式を使用することで、先に挙げた課題に対して、どのようにして対応できるのか、次項で説明します。

3.1.2. 名前付きポリシー式による解題解決

先に挙げた課題を思い出してください。１つ目は、リダクション対象列ごとに異なるポリシー式の適用に関する課題です。この課題は、リダクション対象列ごとにDBユーザで条件分岐するようなポリシー式(実行条件)を定義できない制限に起因する内容でした。また、その解決案としてユーザごとにビューと異なるポリシー式を定義したリダクション・ポリシーを作成する方法を紹介しましたが、アプリケーションの改修が発生するデメリットがありました。

この課題は、図7で示すように名前付きポリシーを構成することで、アプリケーションの改修を行わずに解決することができます。

【図7:名前付きポリシー式による課題解決】

具体的には、図8のようにリダクション・ポリシーと名前付きポリシー式を定義します。

【図8:名前付きポリシー式の定義イメージ】

NAME列に対応する名前付きポリシー式を作成し、GUESTユーザに対してのみリダクションされるようにポリシー式を定義します。また、PAN列は、名前付きポリシー式を利用せず、リダクション・ポリシー作成時に指定したポリシー式をそのまま使います。

このようにリダクション・ポリシーと名前付きポリシーを定義することで、リダクション対象列ごとに実行条件を変更することが可能となり、アプリケーションを改修することなく課題を解決できます。

次に、リダクション対象の表やビューが増えることで、管理するポリシーが増加する二つ目の課題がありました。この課題は、図6で示したように名前付きポリシー式を１つ作成し、各リダクション・ポリシー内の列と関連づけることで対応が可能です。

名前付きポリシー式の実行条件は、リダクション・ポリシーのポリシー式より優先されることから、一度の名前付きポリシー式の修正で、複数のリダクション・ポリシーの実行条件を容易に変更・管理できるようになります。これにより、変更作業に伴うミスの軽減や管理コストの削減につながることが期待でき、運用管理コストの軽減につながります。

名前付きポリシー式の導入により、表単位ではなく、列単位による、より細かな実行条件の指定が可能となり、使い方によってはすべてのリダクション・ポリシーの実行条件を集中管理することも可能となるなど、メリットが大きいことがご理解いただけたのではないかと思います。

3.1.3 名前付きポリシー式の使い方

実際に名前付きポリシー式の作成方法を紹介します。

ここでは、「1.4.リダクション・ポリシーの設定例」で紹介した設定例をもとに「3.1.2.名前付きポリシー式による解題解決」で紹介した図7のように、オペレータはPAN列のみリダクションされ、ゲストはNAME列もリダクションされるように名前付きポリシー式を定義してみます。

まず、名前付きポリシー式を作成していきます。名前付きポリシー式は、DBMS_REDACT.CREATE_POLICY_EXPRESSIONプロシージャを使用します。ここでは、以下の内容で条件式を定義します。

表6:DBMS_REDACT.CREATE_POLICY_EXPRESSIONで指定するパラメータ

• 名前付きポリシー式の作成

SQL> BEGIN
  2   DBMS_REDACT.CREATE_POLICY_EXPRESSION(
  3     policy_expression_name  => 'EX_CREDIT_MEMBER_POLICY',
  4     expression              => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''GUEST''');
  5  END;
  6  /
	

作成した名前付きポリシー式をクレジット会員テーブルのNAME列に紐付します。紐付けにはDBMS_REDACT.APPLY_POLICY_EXPR_TO_COLを使用します。 ここでは、以下の内容を指定します。

表7:DBMS_REDACT.APPLY_POLICY_EXPR_TO_COLで指定するパラメータ

• 名前付きポリシー式をNAME列の紐付け

SQL> BEGIN
  2   DBMS_REDACT.APPLY_POLICY_EXPR_TO_COL(
  3     object_schema          => 'ADMIN',
  4     object_name            => 'CREDIT_MEMBER',
  5     column_name            => 'NAME',
  6     policy_expression_name => 'EX_CREDIT_MEMBER_POLICY');
  7  END;
  8  /	
	

これで、名前付きポリシー式(EX_CREDIT_MEMBER_POLICY)の実行条件がクレジット会員テーブルのNAME列に適用されることになります。

それでは、最後に想定どおりにオペレータ(OPERATOR)は、PAN列のみリダクションされ、ゲスト(GUEST)はNAME列とPAN列の両方がリダクションされているか確認します。

• オペレータでクレジット会員テーブルを参照

SQL> SHOW USER
USER is "OPERATOR"
SQL> SELECT * FROM ADMIN.CREDIT_MEMBER;

NAME     PAN
-------- --------------------
Sugimoto ****-****-****-4444
Okano    ****-****-****-8888
	

　オペレータは、PAN列のみリダクションされていることが確認できます。次にゲスト(GUEST)を確認します。

• ゲストでクレジット会員テーブルを参照

SQL> SHOW USER
USER is "GUEST"
SQL> SELECT * FROM ADMIN.CREDIT_MEMBER;

NAME     PAN
-------- --------------------
-        ****-****-****-4444
-        ****-****-****-8888	
	

NAME列とPAN列の両方がリダクションされており、こちらも想定どおりに動作していることが確認できます。最後に管理者(ADMIN)ユーザからの接続がリダクションされないことを確認します。

• 管理者でクレジット会員テーブルを参照

SQL> SHOW USER
USER is "ADMIN"
SQL> SELECT * FROM ADMIN.CREDIT_MEMBER;

NAME     PAN
-------- --------------------
Sugimoto 1111-2222-3333-4444
Okano    5555-6666-7777-8888	
	

以上が名前付きポリシー式の使い方となり、図7のとおりに設定が行えたことを確認しました。

3.2. その他の新機能について

12cR2における大きな変更点としては、上述した名前付きポリシー式の追加が挙げられますが、その他にも新機能が追加されていますので、簡単に紹介します。

3.2.1 リダクション結果のNULL値対応

NULLリダクションが追加されており、リダクション結果としてNULLとすることが可能になりました。リダクション・ポリシーを作成する際のfunction_typeにNULLIFYを指定します。

表8:NULLリダクションを使用する際に指定するパラメータ

リダクションの結果として、何も表示させたくない場合などに利用できます。

3.2.2. CLOB型列、NCLOB型列の正規表現リダクション対応

従来のリリースから、正規表現を使用し、メールアドレスの@以前のみリダクションするといった設定は可能でしたが、12cR2からはこの設定をCLOB型やNCLOB型の列に対しても設定できるようになりました。

3.2.3. ポリシー式の実行条件の使用可能演算子の拡張

ポリシー式の実行条件に使用できる演算子が拡張され、「AND,OR, IN, NOT IN」を含められるようになりました。

この拡張により、リダクション・ポリシーおよび名前付きポリシー式の実行条件の指定において、INを使用して複数のユーザを対象とする使い方も12c R2から実装可能になりました。

例:

expression => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') IN (''OPERATOR'',''GUEST'')');

4. まとめ

12cR1までのOracle Data Redactionと比較し、名前付きポリシー式の登場やリダクションの実行条件での使用可能文字の拡張により、リダクション対象をより細かに設定することが可能になった点をご理解頂けたと思います。

それにより、従来のリリースでの課題も緩和し、より使いやすい機能に進化したことがわかります。

本稿がOracle Database 12cR2におけるセキュリティ対策の一助けになれば幸いです。