背景
データベースの共同開発において、機密データの管理は企業とユーザーにとって極めて重要です。近年、データセキュリティ法や個人情報保護法などの法律・規制が施行されたことにより、国家や社会全体でプライバシーデータの安全性への関心が高まっています。操作監査とプライバシーデータの保護はますます重要になり、データベース共同開発ツールの選定における重要な評価指標となっています。
プライバシーデータには通常、ユーザーの身分証番号、携帯電話番号、自宅住所などの機密情報が含まれており、これらは業務の正常な運営を支える不可欠な基礎データです。ユーザーデータの漏洩を防ぐためには、業務データベースへのアクセスを厳しく制限する必要があります。しかし、アクセスを完全に制限すると協働効率が低下する可能性があり、これは懸念される問題です。そのため、エンタープライズレベルのデータベース開発シナリオに直面した際、私たちは真剣に考える必要があります：どのようにして安全かつコンプライアンスに則った方法で内部データ漏洩のリスクを積極的に予防し、ユーザーのプライバシーデータを最も厳格に保護するか？本記事では、プライバシーデータの保護と安全コンプライアンスに焦点を当て、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番目の問題についてですが、中国語/英語の氏名、携帯電話番号、メールアドレス、身分証明書番号、住所、車両番号、IPアドレスなど、一般的な機密データ型をカバーするために、フルマスキングとセミマスキングの方法を含む21種類の異なるデータマスキングアルゴリズムを提供しています。
ディメンションモデル
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：画面上でテーブルデータを確認し、機密フィールドをマスクしてから表示する
データベースオブジェクトツリーで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_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の機密データ管理機能は、あらゆる面で完全な閉ループを形成しています。