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 つの関数種別#

-- payroll ロール以外の全員に対して salary カラムを完全リダクション。
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;
/

-- SSN を部分リダクション — 末尾 4 桁を表示し、先頭 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;
/

-- 既存ポリシーにカラムを追加（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 に対して評価されます:

-- アプリケーションスキーマ以外の全員をマスク。
expression => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''APP_USER'''

-- 接続時にアプリが設定するアプリケーションコンテキスト外の全員をマスク。
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 を試せます。