この記事は、VV Yixiao によるHuawei クラウド コミュニティ「GaussDB (DWS) セキュリティ管理のデータ非感作化の原則と使用方法の紹介」から共有されたものです。
1 はじめに
- 対象バージョン：8.2.0以降
GaussDB (DWS) 製品のデータ非感作機能は、データベース製品がデータ セキュリティ機能を内部化して統合するための重要な技術的進歩です。指定されたユーザーの範囲内で列レベルの機密データの非感作機能を提供します。これには、柔軟性、効率性、透明性、使いやすさなどの利点があります。製品のデータ セキュリティ機能が大幅に強化され、機密データの信頼性の高い保護が実現します。 。
ビッグデータ時代の到来により、従来のビジネスの運営モデルが破壊され、新たな生産の可能性が刺激されました。データは重要な生産要素および情報の伝達手段となっており、データの流れには高次の価値のある情報も隠されています。データ管理者やデータ処理者にとって、データフローの価値をいかに最大化するかがデータマイニングの本来の目的であり、意義です。しかし、一連の情報漏洩事件の発覚により、データセキュリティに対する注目がさらに高まっています。国や地域は、ユーザーのプライバシー保護を法的に保護するために、データセキュリティとプライバシー保護に関連する法律や規制を徐々に確立および改善しています。データ セキュリティとプライバシー保護を技術レベルで強化し、データ ウェアハウス製品自体に対するより多くの機能要件を提示する方法も、データ セキュリティを構築する最も効果的な方法です。
GaussDB (DWS) 製品バージョン 8.1.1 は、指定されたユーザー範囲内の列レベルの機密データの感度を下げる機能を提供するデータの感度を解除する機能をリリースします。これには、柔軟性、効率、透明性、使いやすさという利点があり、機能が大幅に強化されます。製品のデータ セキュリティ機能。
2. データの非感作の概念
データ マスキングは、その名前が示すように、機密データを保護することです。漏洩した場合に社会や個人に重大な被害を及ぼす可能性のあるデータは、一般的な機密データです。氏名、ID 番号、住所、携帯電話番号、電子メール アドレスなどの個人を特定できる情報は、営業許可番号、税務登録証明書、従業員の給与、IP アドレス、MAC などのデバイス情報などの情報を開示するのに適していません。住所、銀行カード番号、保護されている健康情報、知的財産権などはすべて機密情報です。この機密情報は、個人データの信頼できる保護を実現するために、非感作ルールによって変形されます。業界の一般的な感度解除ルールには、置換、再配置、暗号化、切り捨て、マスキングが含まれており、ユーザーは必要な感度解除アルゴリズムに基づいて感度解除ルールをカスタマイズすることもできます。
一般に、データの匿名化を適切に実装するには、次の 2 つの原則に従う必要があります。1 つ目は、匿名化後のアプリケーションに対して、重要な情報を保持するように努めることです。2 つ目は、ハッカーによるクラッキングを最大限に防ぐことです。
データの非感作は、静的データの感作と動的データの感作に分けられます。静的データの感度解除は、データが抽出され、感度が解除された後、自由なアクセス、読み取りおよび書き込みのためにダウンストリーム リンクに送信され、データは実稼働環境から分離されます。実稼働データベースのセキュリティを確保しながら、ビジネス ニーズを満たします。動的データの非感作は、機密データにアクセスするときにリアルタイムで非感作処理を実行し、さまざまな役割、さまざまな権限、およびさまざまなデータ型に応じてさまざまな非感作スキームを実装できるため、返されたデータが利用可能で安全であることが保証されます。
2.1 DWS の動的データの感度解除
GaussDB (DWS) のデータ非感作機能は、ビジネス アプリケーション層での高依存性と高コストの非感作という問題点を放棄し、データの非感作をデータベース製品自体のセキュリティ機能に組み込み、完全で安全、柔軟性、透明性のあるセキュリティ機能を提供します。のセット。フレンドリーなデータ非感作ソリューションであり、動的データ非感作に属します。ユーザーは機密フィールドを特定した後、ターゲット フィールドに基づいて組み込みのマスキング関数をバインドすることにより、マスキング ポリシーを作成できます。リダクションポリシーには、テーブルオブジェクトと多対一の関係があります。マスキング戦略には、テーブル オブジェクト、有効条件、マスクされた列とマスクされた関数のペアの 3 つの主要な要素が含まれます。これは、テーブル オブジェクト上のすべてのマスクされた列のコレクションであり、異なるデータ特性に基づいて異なるマスキング関数を使用できます。効果的な条件と非感作カラムと非感作関数のペアに応じて、同じテーブルに戦略を設定することもできます。有効条件が true の場合にのみ、クエリ ステートメントによって機密データの機密化がトリガーされます。このプロセスは SQL エンジンに組み込まれており、運用環境のユーザーには透過的で見えません。
サードパーティのエージェントの感度解除ツールとデータ ウェアハウス DWS の感度解除エンジンの比較
- サードパーティのプロキシ ツールは、ユーザーとデータ ウェアハウス クラスター間の転送ステーションであり、ベースの外部にあるプラグインの感度解除ツールであり、生成環境に直接参加することはできず、複雑なシナリオを処理するのは困難です。
- DWS は、データ ウェアハウス ベースとストレージ エンジンおよび SQL エンジンの間の直接対話に基づいた制限解除エンジンであり、クエリ実行プロセス中にリアルタイムで制限解除を実行し、制限解除の結果がユーザーに直接返されます。
- エージェントの感度解除ツールは静的な感度解除であり、DWS の感度解除エンジンは動的な感度解除です。
DWS動的減感エンジンの利点
- 良好なベースシナジー。非感作エンジンは、データ ウェアハウス ベースのさまざまな側面を実行し、事前に設定された非感作戦略に基づいて SQL エンジンの解析、再書き込み、最適化、および実行に参加します。脱感作プロセスはユーザーには見えません。
- ポリシーは構成可能です。お客様は、独自のビジネス シナリオに基づいて機密データを識別し、ビジネス テーブルの指定された列に対する機密保護解除戦略を柔軟に事前設定できます。
- 戦略は拡張可能です。この製品には、最も一般的な減感効果をカバーできる減感機能が組み込まれており、ユーザー定義の減感機能もサポートされています。
- データの可用性。データベース内の元の機密データは操作に参加し、データベースを離れるとき (結果が返されたとき) にのみ機密性が解除されます。
-
データアクセスは制御されます。匿名化ポリシーが有効になる条件下では、元の機密データはユーザーに表示されません。
-
すべてのシーンデータが漏洩することはありません。塩基相互作用により、機密データ伝送リンクの漏洩の潜在的なリスクを軽減できます。
より安全で信頼性が高く、さまざまな潜在的な悪意のあるフィッシング シナリオを完全に特定し、効果的な保護を提供します。
3. データの感度解除の使用方法
動的データの感度解除は、クエリ ステートメントの実行中に有効な条件が満たされるかどうかに基づくリアルタイムの感度解除プロセスです。検証条件は通常、現在のユーザーの役割の判断に基づきます。機密データの表示範囲は、ユーザーごとに事前に設定されています。システム管理者は最高の権限を持ち、いつでもどのテーブルのどのフィールドも参照できます。制限されたユーザーの役割を特定することは、非感作戦略を作成するための最初のステップです。
機密情報は、実際のビジネス シナリオとセキュリティの次元によって異なります。自然人を例に挙げると、銀行システムにおける個人ユーザーの機密フィールドには、顧客としての名前、ID 番号、携帯電話番号、電子メール アドレスなどが含まれます。企業システムでは銀行カード番号、有効期限、支払いパスワードなどが含まれる場合があり、医療システムでは給与、学歴などが含まれる場合があります。医療情報なども含まれます。したがって、特定のビジネス シナリオにおける機密分野を特定して整理することが、非感作戦略を作成するための 2 番目のステップとなります。
この製品には、一連の共通の減感機能インターフェイスが組み込まれており、さまざまなデータ型およびデータ特性のパラメータを指定して、さまざまな減感効果を実現できます。減感機能は以下の 3 つの内蔵インターフェースを使用でき、カスタム減感機能もサポートしています。 3 つの組み込みの感度低下関数は、ほとんどのシナリオで感度低下の影響をカバーできます。カスタムの感度低下関数を使用することはお勧めできません。
-
MASK_NONE: 感度解除なし、内部テストのみ。
-
MASK_FULL: 固定値まで完全に感度を下げます。
-
MASK_PARTIAL: 指定したマスキング文字を使用して、マスキング範囲内のコンテンツを部分的にマスクします。
異なる減感カラムでは、異なる減感機能を使用できます。たとえば、携帯電話番号は通常、下 4 桁を表示し、先頭の数字を「*」に置き換えます。金額は一律に 0 などの固定値で表示されます。減感カラムにバインドする必要がある減感関数を決定することは、減感戦略を作成する 3 番目のステップです。
会社の従業員テーブル emp、テーブルの所有者ユーザー alice、ユーザー matu と july を例として、データの非感作化の使用プロセスを簡単に紹介します。このうち、テーブル emp には、従業員の名前、携帯電話番号、電子メール、ペイカード番号、給与、その他の個人データが含まれています。ユーザーのアリスは人事マネージャーであり、ユーザーのマトゥとジュライは一般の従業員です。
テーブル、ユーザー、およびテーブル emp に対するユーザーの表示権限がすべて設定されていることを前提としています。
1. 匿名化ポリシーマスク_emp を作成します。これにより、Alice のみがすべての従業員情報を表示できるようになり、Matu と July は給与カード番号と給与に表示されなくなります。フィールド Card_no は数値タイプであり、MASK_FULL は固定値 0 に完全に感度を解除するために使用され、フィールド Card_string は文字タイプであり、MASK_PARTIAL は指定された入出力形式に従って元のデータを部分的に感度を解除するために使用されます。フィールド給与は数値タイプであり、最後から 2 番目の桁より前のすべての桁値を部分的に鈍化するために数値 9 が使用されます。
postgres=# CREATE REDACTION POLICY マスク_emp ON emp WHEN (current_user != 'alice') ADD COLUMN カード番号 WITH マスク_フル(カード番号)、 ADD COLUMN カード文字列 WITH マスク_部分(カード文字列, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12), ADD COLUMN 給与 WITH Mask_partial(salary, '9', 1, length(salary) - 2);
matu と july に切り替えて、従業員テーブル emp を表示します。
postgres=> SET ROLE matu PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; ID |名前 |電話番号 |カード番号 |カード文字列 |メール |給与 |誕生日 ----+------+-------------+----------+-------------- -------+----------------------+-----------+------ --------------- 1 |アニー | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00 2 |ボブ | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00 3 |シシ | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3行) postgres=> SET ROLE july PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; ID |名前 |電話番号 |カード番号 |カード文字列 |メール |給与 |誕生日 ----+------+-------------+----------+-------------- -------+----------------------+-----------+------ --------------- 1 |アニー | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00 2 |ボブ | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00 3 |シシ | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3行)
2. 仕事の調整のため、matu は会社の採用業務に参加するために人事部門に入り、すべての従業員情報も閲覧できるようになり、ポリシーの有効条件が変更されました。
postgres=> ALTER REDACTION POLICY マスク_emp ON emp WHEN(current_user NOT IN ('alice', 'matu'));
ユーザー matu と july に切り替えて、従業員テーブル emp を再度表示します。
postgres=> SET ROLE matu PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; ID |名前 |電話番号 |カード番号 |カード文字列 |メール |給与 |誕生日 ----+------+-------------+---------------------+----- ----------+----------------------+---------- --+--------------------- 1 |アニー | 13420002340 | 1234123412341234 | 1234-1234-1234-1234 | [email protected] | 10000.0000 | 1999-10-02 00:00:00 2 |ボブ | 18299023211 | 3456345634563456 | 3456-3456-3456-3456 | [email protected] | 9999.9900 | 1989-12-12 00:00:00 3 |シシ | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3行) postgres=> SET ROLE july PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; ID |名前 |電話番号 |カード番号 |カード文字列 |メール |給与 |誕生日 ----+------+-------------+----------+-------------- -------+----------------------+-----------+------ --------------- 1 |アニー | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00 2 |ボブ | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00 3 |シシ | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00 (3行)
3. 従業員情報の電話番号、電子メール、誕生日もプライベート データです。mask_emp マスキング ポリシーを更新し、3 つのマスキング列を追加します。
postgres=> ALTER REDACTION POLICY Mask_emp ON emp ADD COLUMN Phone_no WITH Mask_partial(phone_no, '*', 4);
postgres=> ALTER REDACTION POLICY Mask_emp ON emp ADD COLUMN email WITH Mask_partial(email, '*', 1, Position('@' in email));
postgres=> 編集ポリシーを変更します。mask_emp ON emp 列を追加します。誕生日 WITH Mask_full(birthday);
ユーザー july に切り替えて、従業員テーブル emp を表示します。
postgres=> SET ROLE july PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; ID |名前 |電話番号 |カード番号 |カード文字列 |メール |給与 |誕生日 ----+------+-------------+----------+-------------- -------+----------------------+-----------+------ --------------- 1 |アニー | 134********* | 0 | ####-####-####-1234 | ********163.com | 99999.9990 | 1970-01-01 00:00:00 2 |ボブ | 182********* | 0 | ####-####-####-3456 | ***********qq.com | 9999.9990 | 1970-01-01 00:00:00 3|シシ | 155******** | | | **************sina.com | | 1970-01-01 00:00:00 (3行)
4. ユーザー対話のしやすさを考慮して、GaussDB (DWS) は、ユーザーがより多くの感度解除情報を直接表示できるようにするシステム ビュー redaction_policies および redaction_columns を提供します。
postgres=> SELECT * FROM redaction_policies;
オブジェクトスキーマ |オブジェクト所有者 |オブジェクト名 |ポリシー名 |式 |有効にする |ポリシーの説明
----------+--------------+---------------+----- --------+-----------------------------------+----- ---+--------------------
パブリック |アリス |従業員 |マスク_emp | ("current_user"() = 'july'::name) | t |
(1行)
postgres=> redaction_columns からオブジェクト名、列名、関数情報を選択します。
オブジェクト名 |列名 |関数情報
-------------+---------------+---------------------- -------------------------------------------------- -----------------------------
従業員 |カード番号 |マスク_フル(カード番号)
従業員 |カード文字列 |マスク_部分(カード文字列, 'VVVVFVVVVFVVVVVFVVVV'::テキスト, 'VVVV-VVVV-VVVV-VVVV'::テキスト, '#'::テキスト, 1, 12)
従業員 |メール |マスク_部分(電子メール, '*'::テキスト, 1, "位置"(電子メール, '@'::テキスト))
従業員 |給与 |マスク_部分(給与, '9'::テキスト, 1, (長さ((給与)::テキスト) - 2))
従業員 |誕生日 |マスク_フル(誕生日)
従業員 |電話番号 |マスク_部分(電話番号, '*'::テキスト, 4)
(6行)
5. ある日突然、社内で社員情報を共有できるようになったら、empテーブルのマスキングポリシーmask_empを削除するだけです。
postgres=> 削除ポリシーのマスク_emp ON emp;
使用法の詳細については、GaussDB (DWS) 製品ドキュメントを参照してください。
4. 目に見えないデータの感度を下げる
データ機密化機能を使用すると、機密データが処理および計算されて出力される場合があります。この場合、非感作データをデータベース内の計算に使用すると、集計関数やフィルター条件などの条件によって、非感作データ自体がクエリ結果に影響を与えるため、この現象に対処するために非感作データが使用されます。 . ミンは目に見えないものとして数を数える能力を導入します。いわゆる不可視とは、元の機密データが処理計算に参加するためにデータベース内で使用され、機密データがデータベースから出荷されるときにのみ機密性が解除されることを意味します。計算可能な非表示関数を使用するには、スイッチenable_redactcol_computable=onを設定する必要があります。
現在、処理計算への機密データの直接参加をサポートするシナリオは次のとおりです。
-
SELECT nullif(salary, 1) FROM emp 射影列式 nullif;
-
SELECT 電子メール LIKE '%.com' FROM emp 射影列 LIKE 式
-
SELECT to_days(birth) FROM david.emp 射影列関数 to_days;
-
SELECT count(*) FROM emp;
-
SELECT * FROM emp WHERE Cardid IS NOT NULL;
-
SELECT name, avg(salary) * 12 FROM emp GROUP BY name (名前は感度を下げたフィールド)
-
SELECT (SELECT給与+10 FROM emp ORDER BY id LIMIT 1);
-
2 つのテーブルは関連付け条件として機密フィールドを使用します。
-
CTE 式の投影柱
出荷時にデータの感度解除をトリガーするシナリオは次のとおりです。
-
テーブルクエリ
-
クエリの表示
-
DML RETURNING 句
-
コピーエクスポート
-
GDSテーブルのエクスポート
-
カーソル…フェッチ
-
ストアド プロシージャ定義では、マスクされたテーブルを使用してストアド プロシージャをクエリします。
4.1 減感作戦略の継承
INSERT/UPDATE/MERGE INTO/CREATE TABLE AS ステートメントの場合、サブクエリが機密フィールドに対する射影操作である場合、機密情報を含む新しいテーブルにソース テーブルと同じ情報が含まれるように、機密化された継承がトリガーされます。この戦略では、ソース テーブルから新しいテーブルに機密データを挿入し、新しいテーブルに対してクエリを実行することで、機密データの漏洩の問題を回避します。さらに、マスキング ポリシーの継承はテーブル ディメンション アクティビティに属し、継承アクティビティではマスキング ポリシーが現在のセッションまたはサブクエリ部分のロール条件下で有効になるかどうかは考慮されません。
非感作戦略を継承する最初のステップは、機密リネージ分析を実行することです。DML ステートメントを実行すると、ソース表のサブクエリ部分とそのターゲット射影列が走査されます。ターゲットの射影列は非感作フィールドです。ソース テーブルを使用してターゲット テーブルのデータを挿入/更新する場合、ソース テーブルの機密データが公開されるリスクがあると考えられます。
マスキング戦略を継承する場合、最初に、トラバーサルでマークされたソース テーブルの機密情報から、ターゲット テーブルに適用するマスキング戦略情報とマスキング フィールド情報を生成します。次に、システム組み込みはポリシー作成ステートメントを生成し、それをシステム テーブル pg_redaction_policy/pg_redaction_column に書き込みます。組み込みの非感作ポリシーの名前は「inherited_rp」です。最後に、システム テーブルのメタデータ継承マーク フィールドを true に設定します。
INSERT 実行セッション/ユーザーがトリガー条件を満たしている場合、RETURNING 句を使用して挿入結果が出力されると、返された結果は感度が解除され、ログ情報「親編集ポリシー/列」にポリシー継承のソースが記録されることに注意してください。 。
非感作ポリシーの継承動作の導入により、いくつかの非感作ポリシーの競合シナリオが発生します。たとえば、SELECT ステートメント クエリのターゲット列は、元の機密フィールドではなく、機密フィールドの複雑な式です。この場合、式は最初に計算されてから、機密性が解除されます。 SETOP セット操作の 2 つのサブブランチは、同じターゲット列に対して異なる感度解除効果を使用します。この時点で、外側のステートメントのターゲット列の感度解除結果を定義するにはどうすればよいですか?複数の INSERT/UPDATE 操作の機密リネージ分析では、同じターゲット列のソース表プロジェクション列が異なる非感作効果を採用し、ソース表ポリシーの有効条件も異なる場合があります。この場合、非感作ポリシーはどのように継承されるべきですか。 ?
これらの競合シナリオでは、ユーザーの機密データを漏洩から保護することが、元の特性を持たない機密データの感作解除効果よりも優先されるという原則に基づいて、感作解除効果の競合が発生した場合、それは一般的なレベルにアップグレードされます。減感効果マスク_フル。 Mask_full は、あらゆるデータ型をカバーできる完全なマスキング関数であり、式の戻り値の型にのみ焦点を当てており、マスクされたデータが漏洩しないようにすることができます。ただし、マスクされた結果は、その特性を表すことはできません。元のデータのため、マスクされた結果が読みにくくなります。さらに、長さやカウントなどの関数式の場合、計算結果は元のデータの特性や情報を公開しないため、ユーザーが手動で非感作関数を設定できるように ALTER FUNCTION ... [NOT] MASKED 構文が提供されています。ホワイトリスト。
4.2 悪意のあるフィッシングに対する保護
特定の機密情報が既知であるため、複数のヒューリスティック照合を通じて、目に見えるユーザー情報が逆に裏付けられ、ユーザーの個人データが盗まれます。等価性判断の形式で式を支援するフィルター条件または射影操作を使用して、機密情報をヒューリスティックに照合します。既知の定数値や等価・類似等価判定式を利用してユーザーの個人データを抽出するこれらの行為は、悪意のある試みです。
postgres=> SELECT name FROM emp WHERE name in('张三');
情報: ターゲット列 {"name"} の結果はマスクされています。
名前
------
開ける*
(1行)
上記の例で示したように、ユーザーの名前情報は匿名化されていますが、クエリ条件はユーザー「Zhang San」に対するものであるため、「Zhang*」に匿名化されていても、ここでの匿名化は簡単に判断できます。機密情報は「Zhang San」であり、Zhang San のユーザー情報が漏洩するリスクにつながります。
この問題に対応して、私たちは「悲観主義」モデルを採用しました。一定の同等性の判断は悪意のあるアービトラージのリスクを伴う可能性があるため、次のような例を禁止します。
postgres=> SELECT name FROM emp WHERE name in('张三');
エラー: リダクション列 "name" は、const 値との等価条件で参照できません。
ヒント: 詳細を確認するには、EXPLAIN コマンドを使用してください。
定数を使用した悪意のあるアービトラージが禁止されるシナリオは次のように要約されます。
1. 定数等価判定式、複合式、非感作フィールドの等価式
2. 名前フィールドが感度を下げられたフィールドであり、現在のセッションがポリシーのトリガー条件を満たしていると仮定すると、ステートメントには次の (ただし、これらに限定されない) 特性があり、悪意のあるアービトラージのリスクがあり、実行は禁止されます。
• 名前 = 「張三」
• 名前 = 'Zhang San' または 名前 = '李思'
• 名前（「Zhang San」、「李思」）
• CASE 名 WHEN '张三' THEN true …
• CASE WHEN 名前が ('张三', '李思') THEN …
• アドバンストパッケージ dbms_output.put_line
3. ステートメントを実行すると、次のエラーが報告されます。 エラー: リダクション列 "name" は、const 値との等価条件で参照できません。
5. データ非感作化の実装原理
GaussDB (DWS) データの感度を下げる機能は、SQL エンジンの既存の実装フレームワークに基づいており、制限されたユーザーによるクエリ ステートメントの実行中に、外部の世界には認識されないリアルタイムの感度を下げる処理を可能にします。内部実装については上の図に示されています。リダクション ポリシーは、オプティマイザーのクエリ書き換えフェーズ中に、ベース テーブルのリダクション列が関係する場合に、TargetList の各 TargetEntry がスキャンされます。非感作ルールが有効になる (つまり、非感作ポリシーの有効条件が満たされ、有効化される) と、この時点で、非感作対象の Var オブジェクトがこの TargetEntry に含まれていると判断されます。 pg_redaction_column を走査して、対応する非感作列バインディングを見つけます。特定の非感作関数は、対応する FuncExpr で置き換えることができます。上記のクエリ ツリーの書き換え後、オプティマイザは新しい実行プランを自動的に生成し、エグゼキュータは新しいプランに従って実行され、クエリ結果は機密データに対して敏感になりません。
元のステートメントと比較して、データの感度を解除してステートメントを実行すると、データの感度を解除する論理処理が追加されるため、必然的にクエリに追加のオーバーヘッドが生じます。このコストは主に、テーブルのデータ サイズ、ターゲット列のクエリに含まれるマスクされた列の数、マスクされた列で使用されるマスキング関数の 3 つの要素によって影響を受けます。
次の図に示すように、単純なクエリ ステートメントの場合は、tpch テーブル customer を例にして上記の要素をテストします。
図 (a) および (b) では、ベース テーブルの顧客は、フィールドのタイプと特性に基づいて MASK_FULL 非感作関数または MASK_PARTIAL 非感作関数のいずれかを使用します。 MASK_FULL は、任意の長さとタイプの元のデータを固定値に鈍化するだけなので、出力結果は元のデータとは大きく異なります。図 (a) は、さまざまなデータ スケールにおける、感度を下げたシナリオと感度を下げていないシナリオにおける単純なクエリ ステートメントの実行時間を示しています。実線のアイコンは非感作シナリオを表し、白抜きのアイコンは制限されたユーザー、つまり感作解除シナリオを表します。データ サイズが大きくなるほど、感度を下げた場合のクエリ時間と元のステートメントの差が大きくなることがわかります。図 (b) は、クエリに含まれるマスクされた列の数が 10 倍のデータ スケールでのステートメント実行パフォーマンスに与える影響を示しています。マスクされた列が 1 つ含まれる場合、マスクを使用したクエリは元のステートメントよりも遅くなります。この列では MASK_PARTIAL 部分マスク関数が使用されていることがわかります。クエリ結果は結果の形式と結果の内容の長さのみを変更します。これは、「感度を解除してステートメントを実行すると、それに応じてパフォーマンスが低下する」という理論上の推測と一致します。クエリに含まれるマスクされた列の数が増加するにつれて、感度を下げたシナリオが実際に元のステートメントよりも高速に実行されることがわかりました。複数列シナリオでマスクされた列に関連付けられたマスキング関数をさらに追跡すると、MASK_FULL マスキング関数を使用してマスクされた列のおかげで、出力結果セットが元のデータと比較して大幅に時間を節約できることがわかりました。 -column クエリの効率が向上します。データ マスキングを使用した単純なクエリは実際にははるかに高速です。
上記の推測をサポートするために、マスクされたすべての列で MASK_PARTIAL を使用して元のデータを部分的にマスクし、元のデータの外部からの読み取り可能性をマスク結果に保持できるようにしました。したがって、図 © に示すように、マスクされた列がすべて部分マスク関数に関連付けられている場合、データ マスクを使用したステートメントは元のステートメントよりも約 10% 悪化します。理論的には、この劣化は許容範囲内です。上記のテストは単純なクエリ ステートメントのみを対象としています。ステートメントが集計関数や複雑な式操作を含むほど複雑な場合、このパフォーマンスの低下はより明らかになる可能性があります。
6. まとめ
GaussDB (DWS) 製品のデータ非感作機能は、データ セキュリティ機能を内部化および統合するためのデータベース製品にとって重要な技術的進歩です。主に次の 3 つの側面をカバーします。
データの非感作戦略のためのシンプルで使いやすい一連の構文。
一般的なプライベート データの感度解除効果をカバーする、柔軟に構成された一連の組み込みの感度解除機能。
完全で便利な非感作戦略アプリケーション ソリューションにより、実行中の元のステートメントのリアルタイムで透過的かつ効率的な非感作が可能になります。
全体として、このデータ非感作機能は、顧客のビジネス シナリオのデータ非感作要件を完全に満たし、一般的なプライベート データの非感作効果をサポートし、機密データの信頼性の高い保護を実現できます。
【暖かいリマインダー】使用中にご不明な点がございましたら、いつでもお気軽にご連絡いただき、フィードバックをお願いいたします。
クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~
高校生が成人式として独自のオープンソースプログラミング言語を作成―ネットユーザーの鋭いコメント： アップル、M4チップ RustDeskをリリース 不正行為横行で国内サービス停止 雲峰氏がアリババを辞任。将来的には、Windows プラットフォームの タオバオ (taabao.com) で独立したゲームを制作する予定です。Web バージョンの最適化作業を再開し、 プログラマの目的地、 Visual Studio Code 1.89 が最も一般的に使用される Java LTS バージョンである Java 17 をリリースします。Windows 10 には、市場シェアは70%、Windows 11は減少し続けるOpen Source Daily | GoogleはオープンソースのRabbit R1を支持、Microsoftの不安と野心;