このトピックでは、PolarProxyが提供する動的データマスキング機能の概要について説明します。
前提条件
PolarProxyのバージョンはV2.4.12以降である必要があります。 PolarProxyの現在のバージョンを表示してアップグレードする方法の詳細については、「マイナーバージョンの更新」をご参照ください。
データマスキングソリューション
レポートの生成、データの分析、開発およびテスト活動の実行、またはその他のデータベース関連の操作を第三者に許可する場合は、本番環境のデータベースから最新の顧客データをリアルタイムで取得する必要があります。 個人情報の開示を避けるために、データは第三者に提供される前にマスクされなければなりません。 Alibaba Cloudは、動的データマスキングと静的データマスキングのデータマスキングソリューションを提供しています。 PolarProxyは動的データマスキングを使用します。
データマスキングソリューション | 説明 | 利点 | 制限 |
動的データマスキング | アプリケーションがデータクエリリクエストを開始すると、PolarDBはクエリされた機密データをマスクしてから、PolarDBがデータをアプリケーションに返します。 これを実現するには、データを照会する前に、データベースアカウント、データベース名、およびデータマスクが必要なテーブルまたは列を指定する必要があります。 |
| ミラーデータベースと比較して、運用データベースのクエリのパフォーマンスは少し低くなります。これは、PolarProxyが運用データベースの機密データをリアルタイムでマスクするためです。 |
静的データマスキング | PolarProxyは、本番データベース内のすべてのデータをミラーデータベースにエクスポートし、エクスポート中に機密データを暗号化またはマスクします。 | アプリケーションは、本番データベースではなくミラーデータベースからデータをクエリします。 その結果、データマスキングは、本番データベースへのアクセスを必要とするサービスには影響しません。 |
|
制御ポリシー機能の動作
PolarDBコンソールでデータマスキングルールを設定した後、コンソールはこれらのルールをPolarProxyに書き込みます。 アプリケーションがデータマスキングルールで指定されたアカウントを使用してデータベースに接続し、指定された列を照会すると、PolarProxyはデータベースから照会されたデータをマスクし、マスクされたデータをクライアントに返します。 
上の図は、次のデータマスキングルールを示しています。
データマスキングルールは、
testAccアカウントを使用してデータベースからデータを照会する場合にのみ有効になります。PolarProxyは、
name列とage列で照会されるデータのみをマスクします。
クエリ結果の列がマスクされている場合、その列のすべての値がマスクされます。 SELECT * FROM t1文を実行し、t1テーブルにname列とage列が含まれている場合、クエリ結果のこれら2つの列の値はマスクされます。
アプリケーションでtestAccアカウントを使用してデータベースに接続し、テーブルのname、age、およびhoby列のデータをクエリすると、PolarProxyはname列とage列のデータをマスクし、マスクされたデータとhoby列のマスクされていないデータを返します。
PolarProxyは、さまざまなタイプのデータをマスクするためにさまざまな方法を使用します。 次の表に、データのマスキング方法を示します。
データ型 | データマスキング方法 | 例 |
整数データ型: TINYINT、SMALLINT、MEDIUMINT、INT、およびBIGINT | PolarProxyは、生データのデータ型で定義された形式でランダムな値を返します。 |
|
10進データ型: Decimal、FLOAT、およびDOUBLE |
| |
日付と時刻のデータ型: Date、time、DATETIME、TIMESTAMP、YEAR |
| |
その他のデータ型 | PolarProxyは、データをアスタリスク (*) に置き換えます。 |
|
考慮事項
動的データマスキング機能は、クラスターエンドポイントにのみ適用されます。 クラスターエンドポイントは、デフォルトのクラスターエンドポイントとカスタムクラスターエンドポイントで構成されます。 プライマリエンドポイントを使用してデータベースに接続し、データベースからデータをクエリする場合、動的データマスキング機能は有効になりません。 クラスターエンドポイントを表示する方法の詳細については、「エンドポイントとポート番号の表示」をご参照ください。
クエリ結果にマスクする必要があるデータが含まれていて、1行のサイズが16 MBを超える場合、クエリセッションは終了します。
たとえば、
personテーブルのname列とdescription列のデータをクエリします。 このテーブルでは、name列の機密データをマスクする必要があります。description列の行のデータのサイズが16 MBを超えています。 この場合、SELECT name, description FROM personステートメントを実行すると、クエリセッションが閉じられます。機密データをマスクする列が関数の入力パラメーターの値として使用されている場合、データのマスクは有効になりません。
たとえば、
name列の機密データをマスクするためのデータマスキングルールが作成されます。SELECT CONCAT(name, '') FROM personステートメントを実行しても、アプリケーションはname列の生の値を読み取ることができます。機密データをマスクする列をUNION演算子と一緒に使用すると、データマスクが有効にならない場合があります。
たとえば、
name列の機密データをマスクするためのデータマスキングルールが作成されます。SELECT hobby FROM person UNION SELECT name FROM personステートメントを実行しても、アプリケーションはname列の生の値を読み取ることができます。
動的データマスキング機能の有効化
詳細については、「データマスキングルールの管理」をご参照ください。
付録: クラスターのパフォーマンスへの影響
動的データマスキング機能は、次のシナリオでクラスターのパフォーマンスに影響します。
この例では、クラスターの1秒あたりの読み取り専用クエリ (QPS) を使用して、パフォーマンスの違いを示します。
シナリオ | パフォーマンスへの影響 | |
アカウントがデータマスキングルールに含まれているかどうか | クエリがデータマスキングルールにヒットするかどうか | |
任意 | 任意 | データマスキングは、アカウントによるクエリには影響しません。 これにより、クラスターのパフォーマンスは影響を受けません。 |
可 | 任意 | PolarProxyは、結果セット内の列定義データのみを分析し、クエリ結果の生データをマスクしません。 これにより、約6% の性能オーバーヘッドが生じる。 動的データマスキング機能を有効にすると、読み取り専用QPSは約6% 減少します。 |
可 | PolarProxyは、結果セット内の列定義データを分析し、クエリ結果の生データをマスクします。 この場合、パフォーマンスのオーバーヘッドは結果セットのサイズに基づいています。 クエリ結果の行数が多いほど、パフォーマンスのオーバーヘッドが大きくなります。 単一の行のクエリ結果が返される場合、約6% のパフォーマンスオーバーヘッドが発生します。 | |