参照時に列の値を自動でマスキングする Data Redaction【#9 Oracle Databaseセキュリティ入門】

前回は、Oracle Database のアクセス制御を、基本権限と追加のセキュリティ機能に分けて整理しました。

今回扱う Oracle Data Redaction は、その中でも「データを見せすぎない」ための機能になります。表への SELECT 権限は必要だけれど、電話番号、クレジットカード番号、給与、医療情報のような値をそのままクライアントに返したくない、などという場面で活用できます。

たとえばアプリケーション画面では、電話番号を XXX-XXXX-1234 のように一部だけ表示したり、給与列を常に 0 として返したりするときがあります。保存されているデータそのものを書き換えるのではなく、問い合わせ結果を返す直前にデータベース側で値のマスキングが可能となります。

1. Data Redaction とは

Oracle Data Redaction は、問い合わせで返される列の値を実行時にリダクション、つまりマスキングする機能です。データはストレージ上では元のまま保持され、SQLの結果だけがユーザーやアプリケーションに返される直前で加工されます。

そのため、次のような特徴があります。

• 元データは変更しない
• アプリケーションに返す値だけをマスクする
• データ型やフォーマットをある程度保ったまま返却できる
• ポリシーでは、SYS_CONTEXT などを使用し、接続ユーザーやセッション情報に応じて適用条件を適用
• データベース側でマスキング処理は完結するため、アプリケーション側の実装変更を抑えやすい

アプリケーションの他にも、レポートや分析ツール、監視ツールなど、同じ本番データを参照する複数の経路において「この利用者にはマスク値を返す」などの制御を一貫させたい場合で主に活用することができます。

なお、Data Redaction で実行するマスキングは「動的データマスキング」と呼ばれるものですが、これと混同しやすいものに、テストや分析環境などのために活用する（静的）データマスキングがあります。

このデータマスキングの方式は、機密データを別の値に置き換えたデータセットを作るためのものです。たとえば、本番データを開発環境へ持ち出す前に、氏名や電話番号などの機密データを恒久的に別の値へ書き換えます。この場合、書き換え後は元の値が失われます。

一方、この Data Redaction は問い合わせ結果に対する動的なマスキングとなります。表に保存されている値は変更されず、条件に合うユーザーが参照したときのみ結果の値が伏せられます。そのため、ダッシュボードやレポートなど読み取り中心のアプリケーションに活用することができます。

2. リダクションの種類

Data Redaction では、列の性質に応じて複数のリダクション（マスキング）方式を選択できます。

※ 完全リダクションの既定値はデータ型によって変わります。たとえば NUMBER 型は 0、文字型は単一空白として返されます。また、必要に応じて DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES で既定値を変更することが可能です。

データ型によってそれぞれサポートされるリダクション機能もまた変わってきます。詳細については以下のドキュメントを参照ください
https://docs.oracle.com/cd/G47991_01/dbred/comparison-full_-partial_-and-random-redaction-based-data-types.html

3. ポリシーの仕組み

Data Redaction では、どのオブジェクトのどの列を、どの条件で、どの方式によりリダクションするかを 「Redaction ポリシー」として定義します。ポリシーは表、ビュー、マテリアライズド・ビューに対して適用でき、問い合わせの実行時、その設定に応じて結果が返される直前にリダクションが行われます。

ポリシーの作成や変更には DBMS_REDACT パッケージを使用します。最初の列に対してポリシーを作成する場合は DBMS_REDACT.ADD_POLICY を使用し、主な指定項目は次のとおりです。

expression は、リダクションを適用するかどうかを判定する条件式です。この式が TRUE を返した場合にリダクションが行われ、FALSE の場合は実データがそのまま返されます。条件には、接続ユーザー、アプリケーションが設定したセッション・コンテキスト、有効なロールなどを利用できます。

ただし、セキュリティ上の理由から、ポリシー式で利用できる関数や演算子は制限されています。代表的には SYS_CONTEXT を利用できますが、ユーザー定義関数は使用できません。

たとえば次は、SALES_APP ユーザーが HR.EMPLOYEES.SALARY を参照した場合だけ、給与列を完全リダクションする例です。

BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema => 'HR',
    object_name   => 'EMPLOYEES',
    policy_name   => 'POL_REDCT_EMP_PAY',
    column_name   => 'SALARY',
    function_type => DBMS_REDACT.FULL,
    expression    => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') = ''SALES_APP'''
  );
END;
/

注意点として、1 つのオブジェクトに定義できる Redaction ポリシーは１つのみとなります。複数列をリダクションしたい場合は、最初に ADD_POLICY でポリシーを作成し、追加列は以下のように DBMS_REDACT.ALTER_POLICY で同じポリシーに加えます。

BEGIN
  DBMS_REDACT.ALTER_POLICY(
    object_schema => 'HR',
    object_name   => 'EMPLOYEES',
    policy_name   => 'POL_REDCT_EMP_PAY',
    action        => DBMS_REDACT.ADD_COLUMN,
    column_name   => 'COMMISSION_PCT',
    function_type => DBMS_REDACT.FULL
  );
END;
/

通常、expression で指定した条件は、そのポリシーに含まれるすべての列に適用されます。列ごとに異なる条件を使いたい場合は、名前付きポリシー式を作成し、DBMS_REDACT.APPLY_POLICY_EXPR_TO_COL で対象列に適用する形で使用していきます。

また、リダクション条件を名前付きで別途切り出す「名前付きポリシー式」というものもあります。ｋこれを使用することで、異なる実行条件をもたせ、同じ表でも列ごとに異なる見せ方にすることができます。こちらの詳細については、以下を参照ください。
https://docs.oracle.com/cd/G47991_01/dbred/central-management-named-data-redaction-policy-expressions.html

5. 向いているユースケース

Data Redaction は、特に読み取り中心のアプリケーションやレポートで使いやすい機能です。
たとえば、次のような要件で活用することができます。

• コールセンター担当者には顧客の電話番号やカード番号の一部だけを見せたい
• 営業アプリケーションでは社員の給与や手数料を見せたくない
• 分析レポートでは集計結果は見せたいが、元の機密値は伏せたい
• 運用・監視ツールから表を参照する必要はあるが、個人情報は表示したくない

アプリケーション側で個別にマスキングを実装することもできますが、データベース側に寄せることで、複数の参照経路で同じ制御を適用しやすくなります。

一方で更新を行うアプリケーションで利用する場合、アプリケーションがリダクション後の値をそのまま更新してしまうことで元データを意図せず上書きする可能性があるため、注意が必要となります。

※ DML や DDL をリダクション対象列に対して行う場合、エラーによってブロックされます。
https://docs.oracle.com/cd/G47991_01/dbred/oracle-data-redaction-and-dml-and-ddl-operations.html

6. セキュリティ上及び設計の注意点

Data Redaction はあくまで返す結果に対してマスキングする機能であり、厳密な意味で「実データへのアクセスを完全に防ぐ」機能ではありません。そのため、where句などを使用することで、任意のクエリを複数回試行することでデータ値の推測などが行えてしまうリスクを持ちます。

その他、設計における注意点は次のとおりとなります。

• アドホックな問い合わせを繰り返して実値を推測する攻撃への完全な防御にはならない
• WHERE 句、並び順、件数などから値を推測できる場合がある
• SYSやSYSTEMなどの特権でログインしたユーザーには適用されない
• EXEMPT REDACTION POLICY 権限を持つユーザーはリダクションの例外になり得る
• CREATE TABLE AS SELECT や INSERT AS SELECT など、実データをポリシー外へコピーし得る操作は既定でブロックされるが、権限設計には注意が必要

したがって、Data Redaction は単独の防御策ではなく、その他のアクセス制御機能などと組み合わせて、あくまで補完する形で使っていくことを推奨します。

特に、DBA や強権限ユーザーからの保護、行レベルの認可、推論攻撃への対策、想定外 SQL の検知・ブロックは、別の機能や運用統制で補完します。

7. 26ai での強化点

Oracle AI Database 26ai では、Data Redaction の制限がいくつか緩和され、機能としてより強化が図られてています。代表的な強化点は次のとおりです。

実務上としては、既存のビューやレポート、BI、分析のためのSQLに対して Data Redaction を適用しやすくなった点が大きいといえます。従来は複雑な SQL でエラーになるケースがありましたが、既存 SQL を大きく書き換えずに適用できる場面が増えたかと思います。

このあたりの変更点や機能については以下の記事もご覧ください。

Data Redaction in Oracle Database 23ai: Built for the AI era and real-world business applications
Using Data Redaction in Oracle Database 23ai
Keep your Sensitive Data Private with Oracle Data Redaction in Oracle Database 23ai
Hands-on with Data Redaction enhancements in Oracle Database 23ai

一方で、式や集合演算の結果が完全リダクションされるなど、結果の見え方が設計意図と異なる場合があります。既存アプリケーションに適用する場合は代表的なSQLを洗い出し、事前に検証することを推奨します。

8. ライセンスについて

Oracle Data Redaction は、Oracle Advanced Security に含まれる機能です。Enterprise Editionで利用する場合は、Oracle Advanced Security オプションが必要です。

OCI なども含めると、Data Redaction が利用できる環境は以下のとおりです。

• オンプレミス
  • Oracle AI Database FREE
  • Enterprise Edition （Oracle Advanced Security オプションが必要）
• クラウド
  • Oracle Base Database Service Enterprise Edition – High Performance
  • Oracle Base Database Service Enterprise Edition – Extreme Performance
  • Exadata Database Service

参考：https://oracleapex.com/ords/features/r/dbfeatures/licenses?license_id=100

Oracle AI Database FREE でも利用できるため、機能検証や簡単な動作確認は無償環境で始めることができます。一方で、バージョンによって利用可能な機能に違いがありますので、以下のリンク等を必要に応じて確認しておきます。
https://oracleapex.com/ords/r/features/dbfeatures/home

9. まとめ

Data Redaction は、保存されているデータを変更せずに、問い合わせ結果だけを動的にマスキングする機能です。アプリケーション側の実装を大きく変えずに、ユーザーやセッション条件に応じた表示制御をデータベース側で実現できます。

一方で、Data Redaction は万能なアクセス制御ではありません。推論攻撃、強権限ユーザー、更新処理、ポリシー外へのデータコピーなどには注意が必要です。あくまで「表示時の露出を減らすレイヤー」として捉え、他のセキュリティ機能や運用統制と組み合わせて設計することが重要です。

次回は、実際に Oracle AI Database FREE を使用して、ユーザーによってデータの見え方が変わることをデモで確認してみます。