背景
データベースの共同開発において、機密データの管理は企業とユーザーにとって極めて重要です。近年、データセキュリティ法や個人情報保護法などの法律・規制が施行されたことで、国と社会全体のプライバシーデータセキュリティに対する認識はますます高まっています。操作監査とプライバシーデータの保護は一層重要となり、データベース共同開発ツールの選定における重要な評価指標となっています。
プライバシーデータには通常、ユーザーの身分証番号、携帯電話番号、自宅住所などの機密情報が含まれており、これらは業務の正常な運営を支える不可欠な基礎データです。ユーザーデータの漏洩を防ぐためには、業務データベースへのアクセスを厳格に制限する必要があります。しかし、アクセスを完全に制限すると協働効率が低下する可能性もあり、これは懸念される問題です。そのため、エンタープライズレベルのデータベース開発シナリオに直面した際、私たちは真剣に考える必要があります：どのようにして安全かつコンプライアンスに則った方法で内部データ漏洩リスクを積極的に予防し、ユーザーのプライバシーデータを最も厳格に保護するか？本記事では、プライバシーデータの保護と安全コンプライアンスに焦点を当て、ODCの設計思想と解決策を紹介します。
シナリオの概要
企業では、運用保守、開発、データ分析などの業務を行う際に、通常はデータベースクエリ操作を実行する必要があります。これらのデータベースには、業務上必要でありながら分離できない機密データが含まれている可能性があり、そのようなデータを直接クエリするとプライバシー漏洩のリスクが生じるおそれがあります。一方で、アクセスを過度に厳しく制限すると、作業効率が低下する可能性があります。このような状況下で、データマスキング技術が役立ちます。SQLクエリやデータエクスポートなど、データが外部に出るシナリオにおいて、機密データをマスキング処理してから出力することで、データベースへのアクセス可能性を確保しつつ、プライバシーデータを露出させません。
直感的な例を挙げて説明しましょう。データベースに「student」という名前のテーブルがあり、すべての学生の基本情報が記録されていると仮定します。今、学生の年齢を集計したいのですが、住所や連絡先などの機密情報を明かしたくありません。この場合、SQLクエリを実行した後の「student」テーブルの結果は以下のようになります。このようなデータマスキング技術は、効率的で柔軟なワークフローを確保するだけでなく、いかなる時でも機密情報のプライバシーとセキュリティを最大限に保護します。
ODCは機密データの保護を最優先事項とし、企業に信頼できる全方位の機密データ保護を提供し、ユーザーのデータのセキュリティとコンプライアンスを確保します。データベースへのアクセスは、通常、機密データを取得する主要な手段であり、場合によっては唯一の手段です。データベースクエリ段階で機密データをマスキング処理できれば、それがデータ取引の第一層の防御線となり、データの安全性を最大限に保障します。
同時に、データプライバシー保護機能により、セキュリティ管理者は必要に応じて機密データルールとマスキングアルゴリズムを設定し、機密データの絶対的な安全性を確保できます。設定後は、データベース管理者（DBA）や開発者であっても直接機密データにアクセスできなくなるため、データ漏洩のリスクを大幅に低減できます。この厳格なデータプライバシー保護メカニズムにより、企業の機密情報はいかなる時でも最大限に保護されます。
ODCのデータベース共同開発プロセスでは、ユーザーは直接データベースにアクセスしてデータクエリを実行することはできません。データを確認するには、以下の方法のいずれかを利用する必要があります：
- データベースオブジェクト管理ページでテーブルデータを確認する。
- エクスポートチケットを提出し、データをファイルにエクスポートしてから確認する。
- データベース変更チケットを提出し、変更タスク内でSELECTステートメントを実行して、実行結果セットを確認する。
- SQLウィンドウでSELECTステートメントを実行し、結果セットを確認する。
方法1と方法2では、データマスキングの実装は比較的容易です。ユーザーがどのデータベーステーブルの列にアクセスしているかが明確にわかっているため、機密列をマスキング処理するだけで済みます。しかし、方法3と方法4では、ユーザーがさまざまな複雑なSQLクエリを入力できるため、ユーザーが実際にどのデータを照会しているかを正確に特定することは困難です。これが、動的マスキングが静的マスキングよりも困難な理由です。
特筆すべきは、ODCのデータマスキングがすべてのデータ外部出力シナリオをカバーしており、OceanBaseデータベースのすべてのSQL構文をサポートしている点です。MySQL互換モードでもOracle互換モードでも、ODCはデータマスキングソリューションを提供できます。
以下では、実際のビジネスシナリオを通じて、ODCを使用して全方位の機密データ保護を実現する方法を体験します。
技術的背景
まず、ODCに関連するいくつかの重要な用語を理解しておきましょう。理解を容易にするため、本記事では以下の用語を事前に定義します：
機密列：データベーステーブル内で機密データを格納する列。
デマスキングアルゴリズム：機密データに対してデマスキング処理を行うアルゴリズム。
識別ルール：データベースの特定の列を機密列としてマークするためのマッチング条件です。ODCはこのルールに合致する列を自動的に機密列として認識できます。
技術アーキテクチャ
次に、機能の観点から、製品設計レベルでODCのデータマスキングの実装原理を紹介します。技術的な詳細にご興味のある方は、ODCのオープンソースコミュニティにぜひお越しください。ODCのオープンソースエコシステムを共に築きましょう。
データマスキングを実現するためには、主に以下の2つの問題を解決する必要があります：
データベース内のどの列が機密データかをどのように特定するか？
機密データに対してどのようなマスキング処理を適用するか？
最初の問題を解決するために、機密列という概念を導入しました。データベース内で機密データを格納する物理列を機密列としてマークすることで、データが外部に出力される際、機密列に関連するすべてのデータが機密データと見なされます。2番目の問題については、フルマスキングとセミマスキングの方法を含む21種類の異なるデータマスキングアルゴリズムを提供しており、英語の氏名、携帯電話番号、メールアドレス、身分証明書番号、住所、車両番号、IPアドレスなど、一般的な機密データ型を網羅しています。
ドメインモデル
ODCはマルチ組織アーキテクチャを採用しており、V4.2.0からプロジェクトベースの管理モードが導入されました。異なる組織間のリソースとデータは完全に分離され、同一組織内の複数のプロジェクトは同じデータソースを共有できます。そのため、データマスキングを実現するために、以下のような製品設計を行いました：
マスキングアルゴリズム
同一組織内では同一のマスキングアルゴリズムセットを共有し、プロジェクト内のすべてのメンバーがマスキングアルゴリズムを確認したり、マスキング効果をテストしたりできます。アントグループは、プライバシーコンピューティングおよび機密データ保護の分野で常にトップクラスに位置しています。そのため、アントグループのマスキング規範を参考に、以下の21種類のマスキングアルゴリズムを提供し、ほとんどのアプリケーションシナリオをカバーしています。
機密データ管理
実際、データが機密であるかどうかは、具体的に保存されている内容に関連しており、通常はプロジェクト内のメンバーだけがどの列をマスキングする必要があるかを把握しています。そのため、機密データ（すなわち機密列）をプロジェクトレベルで管理し、プロジェクト管理者またはDBAが責任を持って管理します。マスキング結果が期待通りになるようにし、誤判断を避けるために、ユーザーはマスキングが必要なデータ列を自ら機密列として追加できます。手動で機密列を追加するには、まず機密列が属するデータソース、データベース、テーブル、列を順に選択し、追加します。データソース内でマスキング処理が必要な列が多数ある場合は、自動スキャンの方法を使用することを推奨します。機密列の位置と基本的な属性に基づいて適切な識別ルールを作成し、自動スキャンタスクを開始するだけです。
ユーザーのニーズを最大限に満たすために、ODCは機密列の識別ルールを設定する3つの方法をサポートしています。それぞれ以下のとおりです：
パス：機密列が存在するデータベース、テーブル、列に基づいてマッチングします。この方法は最もシンプルで直接的ですが、ユーザーのほとんどのニーズを満たせます。
正規表現：正規表現に基づき、データベース名、テーブル名、列名、列の備考に基づいてマッチングします。この方法は、機密列が複数のデータベースに分散しており、一括で追加する必要があるシナリオに適しています。
スクリプト：Groovyスクリプトに基づくマッチングです。この方法は非常に柔軟で、広範囲のフィルタリングや、特に細かい粒度のカスタマイズ可能なマッチングルールを実現できるため、強く推奨されます。Groovyの構文に5分ほど慣れれば、楽しく識別ルールを作成できます。
例えば、あるデータソース内のすべてのemailという名前の列を機密列に設定したい場合、以下のスクリプト識別ルールを記述するだけです：
そして、それを使用してスキャンするだけです（たった3ステップ）：
ビジネスシナリオの例
検証データの準備
検証を開始する前に、まずODCを使用して2つのデータテーブルを作成します：データテーブル1（employee_info）とデータテーブル2（employee_salary）です。
CREATE TABLE test.employee_info ( id int NOT NULL COMMENT '従業員ID', name varchar(32) NULL COMMENT '従業員名', email varchar(64) NULL COMMENT '従業員メールアドレス', address varchar(128) NULL COMMENT '従業員住所', CONSTRAINT pk_id PRIMARY KEY (id) ) DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_general_ci; CREATE TABLE test.employee_salary ( id int NOT NULL COMMENT '従業員ID', salary float(10) NULL COMMENT '従業員給与', CONSTRAINT pk_id PRIMARY KEY (id) ) DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_general_ci;シミュレーションデータを挿入しました。以下は元のテーブルデータの例です。
説明
以下のデータはシミュレーションデータであり、実在のユーザー情報は含まれていません。
デマンティング処理を行う列を機密列リストに追加します。表示されるデータ列が少ないため、手動で追加する方法で設定します：
シナリオ検証
次に、さまざまなデータ出庫シナリオにおいて、ODCがどのようにユーザーのデータマスキング処理を支援できるかを検討します。
シナリオ1：Webインターフェースでテーブルデータを表示し、機密フィールドをマスキングしてから表示する
データベースオブジェクトツリーでemployee_infoテーブルのデータを表示すると、テーブル内の機密列データがマスキング処理されていることが確認できます。
シナリオ2：データをファイルにエクスポートし、機密データをマスキング処理する
次に、機密列を含むテーブルをCSVファイルにエクスポートしてみましょう。
エクスポートしたCSVファイルの内容を確認すると、機密列も同様にマスキング処理されていることがわかります。
シナリオ3：SELECTクエリの実行時、どんなSQL構文でもデータマスキングを回避できない
前述のように、動的データマスキングの核心的な課題は、多様な複雑なSQL構文の中で機密列を正確に特定することです。以下では、ODCの動的データマスキングがSQL構文をどの程度サポートしているか、段階的に検証します。
まずはシンプルな単一テーブルクエリです：
ご覧のように、機密データであるemail列とaddress列は正常にマスキングされています。次に、組み込み関数、CASE WHEN、およびJOINとUNIONクエリをテストします：
これらのクエリもODCの動的データマスキングで対応できます。結果セットの3列すべてが正常にマスキングされており、その理由を順に分析します。まず、id列は機密データではありませんが、UNION演算を行うaddress列が機密データであるため、結果セットのcase_id列はマスキングが必要です。同様に、name列は機密列ではありませんが、CONCAT()関数を使用してsalary列と連結しているため、concat(t1.name, '-', salary)列もマスキングが必要です。最後に、email列とname列の結合結果も自然とマスキングが必要です。
さらに、複数層のネストされたサブクエリをテストします：
同様に、FROM句やSELECT句に現れるサブクエリ、関連サブクエリであっても非関連サブクエリであっても、ODCは適切に対処できます。
既にほとんどのSQLクエリを処理できるようになりましたが、ODCはそれに満足していません。ODCは再帰CTEと非再帰CTEの構文もサポートしており、再帰CTE内で発生する機密列の伝播も処理できます：
上記の例で、なぜcte_id列もマスキングされたのか疑問に思われるかもしれません。これは、Recursive CTEの機密データ「感染」問題によるものです。最初の再帰では、CONCAT(cte_email, cte_name)演算により、cte_name列に機密データが含まれるようになり、cte_name列が機密列に変わります。2回目の再帰では、CONCAT(cte_name, cte_id)演算により、cte_id列も機密データに「感染」します。その結果、ODCは結果セットの3列すべてに対してマスキング処理を行いました。
その他のシナリオ
データベース変更とSQLウィンドウでのクエリは、本質的に大きな違いはなく、どちらもSQL文を実行して結果を出力します。したがって、SQLウィンドウでサポートされている動的データマスキング機能は、データベース変更チケットにも同様に適用されます。
ストアドプロシージャ、パッケージ、トリガー、カスタム関数については、現在のところ、機密データへのアクセスを動的に遮断する適切な方法は見つかっていません。しかし、これが機密データ管理の有効性に影響を与えるわけではありません。上記の4種類のデータベースオブジェクトが機密データにアクセスする前提は、まずそれらを作成することですが、ODC V4.2.0では、これらのデータベースオブジェクトのCREATE権限とPLのデバッグおよび実行権限をすべて管理下に置いています（下図のSQLウィンドウ仕様参照）。該当する権限のないユーザーは、これらの「危険な」操作を実行できません。したがって、ODCの機密データ管理機能は、あらゆる面で完全な閉ループを形成しています。