Oracle の動的データマスキング

SSN、クレジットカード、メール、住所。これらのカラムはサポート、分析、開発のためにクエリ可能であり続けなければなりませんが、広範な平文アクセスは答えではありません。データマスキングが答えです。GDPR、HIPAA、PCI などのワークロードでは、マスキングは法的要件でもあります。

Oracle Database は Data Redaction を Advanced Security オプションの一部として同梱しています。（Oracle は別途、非本番クローン向けの静的マスキングである Data Masking and Subsetting Pack も販売していますが、本記事の対象外です。）Bytebase Dynamic Data Masking はその前段に位置します。すべての Oracle デプロイメントで、そしてフリート内のあらゆる他エンジンでも、1 つのポリシーモデルが適用され、申請・レビュー・承認が組み込まれています。本記事で両者を比較します。

Oracle Data Redaction#

Data Redaction は Oracle Database Enterprise Edition に Advanced Security オプション（ASO） を加えた構成で GA です（追加ライセンスが必要）。11.2.0.4 で導入され、12c、18c、19c、21c、23ai までサポートされています。Standard Edition と Express Edition には含まれません。Oracle Autonomous Database は ASO を含みます。Database@AWS、@Azure、@Google Cloud も同じオンプレミスのライセンス体系に従います。

ポリシーは DBMS_REDACT.ADD_POLICY を使ってカラムごとに定義します。サーバーは、ポリシー式が TRUE と評価されるセッションに対してクエリ結果を書き換えます。ディスク上のデータは変更されません。

5 つの関数種別#

-- Full redaction on a salary column for everyone except the payroll role.
BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema => 'HR',
    object_name   => 'EMPLOYEES',
    column_name   => 'SALARY',
    policy_name   => 'salary_redact',
    function_type => DBMS_REDACT.FULL,
    expression    => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''PAYROLL_USER''');
END;
/

-- Partial redaction on SSN: show last 4 digits, mask first 5.
BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema       => 'HR',
    object_name         => 'EMPLOYEES',
    column_name         => 'SSN',
    policy_name         => 'ssn_redact',
    function_type       => DBMS_REDACT.PARTIAL,
    function_parameters => DBMS_REDACT.REDACT_US_SSN_F5,
    expression          => '1=1');
END;
/

-- Add a column to an existing policy (12.2+).
BEGIN
  DBMS_REDACT.ALTER_POLICY(
    object_schema => 'HR',
    object_name   => 'EMPLOYEES',
    policy_name   => 'salary_redact',
    action        => DBMS_REDACT.ADD_COLUMN,
    column_name   => 'COMMISSION_PCT',
    function_type => DBMS_REDACT.FULL);
END;
/

12.2 より前は、各テーブルは 1 つのリダクションポリシー に制限されていました。12.2 以降は、ALTER_POLICY ... ADD_COLUMN により単一のポリシーで複数カラムをカバーできます。テーブルごとのポリシーオブジェクトは 1 つのままですが、それぞれ独自の関数種別を持つ多数のカラムを保持できます。

権限とポリシー式#

モデルを統制するのは 2 つの権限です:

• EXECUTE ON DBMS_REDACT はポリシーの作成・変更に必要です。セキュリティ担当者に付与します。
• EXEMPT REDACTION POLICY はデータベース内のすべてのリダクションポリシーをバイパスします。セッションは実際の値を見られます。付与は最小限にし、変更を監査してください。

expression パラメータは、セッションにリダクションを適用するかどうかを制御します。実行時コンテキスト、通常は SYS_CONTEXT に対して評価されます:

-- Mask everyone except the application schema.
expression => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''APP_USER'''

-- Mask everyone outside an application context set by the app on connect.
expression => 'SYS_CONTEXT(''APP_CTX'',''role'') != ''ANALYST'''

SYS および SYSDBA を持つユーザーは実際のデータを見られ、リダクションは適用されません。EXEMPT REDACTION POLICY を付与されたユーザーも同様です。これらを持つ者を制限し、付与の変更はすべて Unified Audit に記録してください。

Data Redaction がしないこと#

• SYS、SYSDBA、EXEMPT REDACTION POLICY 保有者を止める。 彼らは実際の値を見られます。これらを持つ者を制限してください。
• アドホックな推測を防ぐ。 SELECT を持ち免除を持たないユーザーは、依然として述語で探りを入れられます。WHERE salary BETWEEN 99999 AND 100001 はリダクションされた 0 を返しますが、どの行が一致したかは露見します。Database Vault と監査を併用してください。
• DML に適用する。 INSERT、UPDATE、MERGE は基となる値に対して動作します。リダクションされた SELECT と UPDATE を持つセッションは、依然としてカラムを上書きできます。
• Data Pump エクスポートを保護する。 expdp はテーブルを直接読み取るため、リダクションは適用されません。DATAPUMP_EXP_FULL_DATABASE を持つ者は平文をエクスポートできます。非本番クローンには Oracle Data Masking and Subsetting Pack を使ってください。
• RMAN バックアップを保護する。 バックアップは物理ブロックのコピーであり、リダクションはクエリ時の変換です。
• 内部 SQL に適用する。 Oracle 内部（パース、オプティマイザ）が発行する再帰 SQL は実際の値を見ます。
• あらゆるカラム種別をカバーする。 仮想カラム（12.2 より前）、仮想カラムから参照されるカラム、一部の XMLType 構成、Oracle Text でインデックスされたカラム、Editioning View 配下のカラムには制約があります。バージョン別の Restrictions on Oracle Data Redaction ページを確認してください。
• Database Vault のレルムと自動的に組み合わさる。 両者は重なり合い、順序が重要です。Database Vault はテーブルに誰がアクセスできるかをゲートし、リダクションは何を見るかを変換します。この順序で両方を構成してください。
• 行をフィルタする。 Data Redaction はカラムレベルで動作します。行レベルの制御には Virtual Private Database（VPD）または Real Application Security を使ってください。

Bytebase Dynamic Data Masking#

ネイティブ Data Redaction には文書化された 2 つの隙があります。EXEMPT REDACTION POLICY 保有者と SYSDBA は平文を見られます。SELECT のみのユーザーは範囲述語で基となる値を推測できます。どちらも同じ設計に由来します。リダクションはエンジン内部で結果を書き換えますが、権限と述語はその書き換えの上流で動きます。隙を塞ぐには、結果だけでなくクエリそのものを統制する必要があります。

Bytebase Dynamic Data Masking はクエリを統制します。クエリは Bytebase の SQL Editor を経由し、Bytebase は結果をエディタから出る前にマスクします。バックエンドのインスタンスで SYSDBA や EXEMPT REDACTION POLICY を持っていてもポリシーをバイパスできません。アドホックな推測はアクセス判断になります。Query 権限の付与は組み込みのワークフローである 申請・レビュー・承認 を通り、すべてのステップが監査されます。

ポリシーは固定の優先順位で評価される 3 つのレイヤーから構成されます: マスキング例外 > グローバルマスキングルール > カラムマスキング。

1. グローバルマスキングルール。 ワークスペース単位。ルールは上から評価され、最初に一致したものが勝ちます。一致条件は環境、プロジェクト、データベース、データ分類にまたがります。一致するたびに Semantic Type が適用され、それがマスキングアルゴリズム（full、partial、MD5、range、カスタム）を選びます。

2. カラムマスキング。 プロジェクト単位のオーバーライド。グローバルルールが該当しない特定カラムに適用します。

3. マスキング例外。 指名されたユーザーが特定のデータベースまたはテーブルに対して期限付きの Query または Export 例外を受けます。サービスアカウントは対象外です。すべての付与とすべてのアクセスが記録されます。

マスキングは伝播します。カラムがマスクされると、そのポリシーは依存するすべてのビューと派生構造に及びます。マスク済みカラム上の式もマスクされたままです。

ポリシーは GitOps でコード化することもできます。

マスキングの決定は監査ログに記録されます。SQL 実行エントリは、マスクされたカラム、Semantic Type、一致したルールというカラム単位のマスキングメタデータを、ユーザー、送信元 IP、ステートメント、行数とともに記録します。例外の付与、例外の行使、ポリシーの編集はファーストクラスの監査イベントです。アクセス判断と強制の証跡は同じレコードに収まります。

ひとつ明確にしておきたいのは、強制の境界です。Bytebase は SQL Editor を経由するクエリをマスクします。Oracle に直接到達するトラフィックはバイパスし、そこはネイティブ Data Redaction がカバーします。パターンは対称です。データベースではネイティブリダクション、承認と監査が要る人間のクエリ経路では Bytebase。1 つのポリシーが Oracle Database EE、SE、Autonomous Database、Database@AWS / @Azure / @Google Cloud、AWS RDS for Oracle に適用されます。

比較#

選び方#

• ASO を既にライセンス済みの単一 Oracle デプロイメントで、クライアントを問わずマスキングを強制する必要がある場合。 Data Redaction を使います。エンジン内、全読み取り経路で動作し、免除されていないユーザーに対して JDBC、OCI、SQL*Plus セッションを等しくマスクする唯一の選択肢です。Database Vault と併用して DBA をリダクション対象カラムから締め出し、Unified Audit で権限付与を記録します。
• Standard Edition、または ASO の予算がない場合。 ネイティブ Data Redaction は利用できません。人間のクエリ経路には Bytebase を使い、直接接続には別のプロセスを用意します（機微なテーブルへの SELECT 付与を制限し、その付与を監査する）。
• 混在フリートで、Oracle を Postgres、MySQL、SQL Server、Snowflake と併用する場合。 Bytebase を使います。1 つのポリシーモデル、すべてのエンジン、すべてのアンマスクに監査付きの付与、アクセスログと同じ場所に記録されます。
• 両方。 データベースでは Data Redaction が直接接続、JDBC、EXEMPT を持たないユーザーのエクスポートをカバーします。Bytebase は人間のクエリ経路を SQL Editor 経由で統制し、承認と監査を提供します。両者は組み合わさります。

このチュートリアルで Bytebase Dynamic Data Masking を試せます。