動的データマスキング (DDM) とは

動的データマスキング (DDM) は、保存データを変えずに、アプリケーションやユーザーへ返すデータベースレコードを動的に変換することで、機微データをリアルタイムに保護します。

DDM は静的データマスキング (SDM) と対比されます。SDM が元データの恒久的かつ非可逆な改変コピーを作るのに対し、DDM はアクセス時にリアルタイムにデータを変換します。この動的アプローチにより、クエリ実行中に機微データを保護しつつ、保存データには手を加えません。

動的データマスキング vs 静的データマスキング: いつ使うか#

静的データマスキング (SDM) は、開発/テスト環境向けに本番データのサニタイズされたコピーを作ります。DDM は別物で、本番でデータをリアルタイムにマスクし、各ユーザーが見るものを役割と権限に応じて制御します。保存データはそのまま。

動的データマスキングを難しくしているもの#

DDM は各ユーザーが見るものについてリアルタイムに判断する必要があります。複雑さは関係する変数の多さから来ます。

• ユーザーロールと ID — DBA は素のデータを、アナリストは部分マスクを、外部委託は完全マスクを見る。同じクエリでも実行者によって結果が異なる。
• 一時的アクセス — オンコールエンジニアは本番インシデント調査のためアンマスクされたアクセスを必要とし、その後失効する。
• カラム単位の粒度 — email カラムは部分マスク、phone カラムは完全マスク、同じテーブルでも違うことがある。
• 複数 DB と環境 — 本番のマスキングルールはステージングと異なる。MySQL、PostgreSQL、Oracle を走らせていれば、それぞれが別の (または存在しない) ネイティブ DDM 対応を持つ。
• マスキングアルゴリズムの選択 — 部分マスクはデバッグ用途でデータを役立つ形に保つ (john@****) が、コンプライアンスには完全マスクやハッシュが必要。間違ったアルゴリズムでは、露出しすぎか役に立たなさすぎになる。
• 性能 — マスキングはすべてのクエリでランタイムに走る。雑な DDM 層はすべての SELECT に遅延を加える。

動的データマスキングを備える DB#

主要な商用 DB は DDM をサポートしますが、最も普及している 2 つのオープンソース DB である MySQL と PostgreSQL はそのままでは DDM をサポートしません。対応している DB では、DDM は拡張 SQL 構文で公開されます。Snowflake の例:

CREATE OR REPLACE MASKING POLICY email_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
    ELSE '*********'
  END;

-- テーブルカラムにマスキングポリシーを適用
ALTER TABLE IF EXISTS user_info MODIFY COLUMN email SET MASKING POLICY email_mask;

DB エンジンはマスキングのプリミティブだけを提供します。組織全体 — 複数 DB、環境、ユーザーロールを横断 — のマスキングポリシーを総合的に設定するのは、依然として大きな課題です。DB 固有のガイドは MySQL のデータマスキングと PostgreSQL のデータマスキングを参照。Snowflake は Snowflake 動的データマスキングと代替を参照してください。

Bytebase の動的データマスキングの扱い#

Bytebase は DB ネイティブの機能に依存せず、アプリケーション層で DDM を実装します。Bytebase の SQL Editor を通るすべてのクエリは、定義したポリシーに基づいてリアルタイムにマスクされます。これは、ネイティブ DDM を持たない MySQL や PostgreSQL でとくに価値があります。

対応 DB#

Bytebase の DDM は MySQL、PostgreSQL、Oracle、TiDB ほかで動きます — エンジンがネイティブ DDM を持つかに関係なく、同じマスキングポリシーがすべてに適用されます。

マスキングの設定方法#

Bytebase は 3 レベルのポリシーシステムを採ります。

1. グローバルマスキングルール — ワークスペース管理者が、名前パターンに合うカラム (例: すべての DB の ssn や email カラム) に一括でマスクを適用
2. カラム単位マスキング — プロジェクトオーナーが特定のテーブルカラムにマスクを設定
3. マスキング免除 — 必要なときに特定ユーザーへアンマスクされたアクセスを付与

優先順位: 免除 > グローバルルール > カラムマスキング。

ポリシーはセマンティックタイプを中心に整理します — カラムを分類 (例: 「PII-email」「PII-phone」) し、そのタイプにマスキングアルゴリズムを紐付ける。1 つのセマンティックタイプを変えれば、紐付くすべてのカラムのマスキングが更新されます。

マスキングアルゴリズム#

組み込みアルゴリズム 5 種:

Infrastructure as Code#

マスキングポリシーは Bytebase の Terraform プロバイダーで管理できます — セマンティックタイプ、グローバルルール、カラムマスキングを HCL で定義し、環境横断で適用。

提供形態#

動的データマスキングは Enterprise プランで利用できます。DDM は Bytebase の広範なデータベースアクセス制御機能の一部で、ロールベースアクセス、Just-in-Time アクセス、監査ログも含みます。

FAQ#

動的データマスキングとは？

動的データマスキング (DDM) は、ユーザーロールとポリシーに基づき、保存データを変えずにクエリ結果をリアルタイムに変換して機微データを保護します。恒久的なサニタイズコピーを作る静的データマスキングと異なり、DDM はクエリ実行中にマスキングをオンザフライで適用します。

どの DB がネイティブで動的データマスキングをサポートするか？

Oracle、SQL Server、BigQuery、Snowflake は組み込み DDM を持ちます。MySQL と PostgreSQL はネイティブでは DDM をサポートしません。Bytebase は MySQL、PostgreSQL、Oracle、TiDB ほかにアプリケーション層 DDM を提供し、エンジン横断で同じポリシーを使えます。

Bytebase は MySQL と PostgreSQL の DDM をどう実装するか？

クエリが Bytebase の SQL Editor を通るときに、アプリケーション層でマスキングを適用します。DB の拡張、ビュー、プラグインは不要です。マスキングポリシーは Bytebase に中央定義し、接続されたすべての DB に一貫適用されます。

動的データマスキングと静的データマスキングの違いは？

静的データマスキング (SDM) は、非本番環境で使うために本番データの恒久的に改変したコピーを作ります。動的データマスキング (DDM) はクエリされる際にデータをオンザフライで変換し、元データは変えません。SDM は dev/test 環境向け、DDM は本番のアクセス制御向けです。