静的か動的かに入る前に、どちらのマスキングにも共通することがあります。機微なカラムを隠し、不適切な人が実際の PII を見ないようにするという点です。両者が異なるのは、作用する瞬間です。静的マスキングはデータを一度だけ書き換え、サニタイズされたコピーにします。動的マスキングは読み取り時にクエリ結果を書き換え、ソースには一切触れません。このたった 1 つの違いがほぼすべてを決め、誤った方を選ぶと、実際の PII をテスト環境に漏らすか、本番を誰が読むかを制御できなくなります。
静的データマスキング
静的データマスキング（SDM）は、データセットのサニタイズされたコピーを生成します。ジョブが本番を読み取り、機微なカラムを変換し（置換、シャッフル、ハッシュ、NULL 化）、結果を新しい場所に書き込みます。マスキングはバイトに焼き込まれます。元の値に戻る経路はありません。
SDM の本質は、データを本番の境界の外へ安全に持ち出すことです。開発、テスト、ステージング、デモ、トレーニング、CI フィクスチャ。データを使う人が実際の値を見る必要のない、あらゆる場所です。コピーには実際の PII が含まれないため、自由に配布できます。
データそのものをマスクすることから、2 つのことが導かれます。第一に、保護がデータとともに移動します。マスク済みデータセットのバックアップやレプリカも同じくマスクされているので、どこへコピーしても安全なままです。第二に、コストはコピー時に一度だけ払います。コピーに対するクエリは、クエリごとのオーバーヘッドなしにフルスピードで動作します。
欠点もまた構造的です。コピーは作られた瞬間に古くなり、更新するにはジョブを再実行するしかありません。そしてマスクされた出力は、形式と参照整合性を保たなければ、テストデータとして役に立ちません。マスクされた SSN も SSN らしく見える必要があり、外部キーはマスク済みテーブル間で整合していなければなりません。
動的データマスキング
動的データマスキング（DDM）は読み取り時にマスクします。保存されたデータはそのままです。カラム上のポリシーが各プリンシパルに何を見せるかを決め、エンジン（またはその前段のレイヤー）が、適切なロールを持たない者に対して結果を書き換えます。
DDM は本番のために作られています。同じライブの行を、ロールごとに異なるビューで見せます。アナリストは部分マスク、DBA は平文、契約者は完全マスクを見ます。適切なロールを付与すれば、同じクエリが実際の値を返します。データは常にそこにあり、アクセスが何を表示するかを決めます。
同じ 2 つの性質が反転します。変換は読み取り時に起きるのであって、保存時ではないので、バックアップやレプリカは実際の値を保持します。マスキングはデータとともに移動しません。つまり、すべての読み取り経路がポリシーを強制しなければならず、さもないとその経路が平文を漏らします。そしてコストはクエリごとに払います。マスキングはすべての SELECT で実行されるからです。重いポリシーは、その一つひとつにレイテンシを加えます。
主なリスクはここから素直に導かれます。特権ロール、あるいはマスキングレイヤーを迂回する直接接続は、平文を見ます。カバレッジは、実際に強制した読み取り経路の範囲までしか及びません。
並べて比較
| 静的データマスキング | 動的データマスキング | |
|---|---|---|
| 適用タイミング | 一度、コピー時 | 毎クエリ、読み取り時 |
| 保存データ | 恒久的に改変（コピー） | 変更なし |
| 可逆性 | 不可 | 可、ロールまたは付与による |
| 環境 | 非本番（開発・テスト・ステージング） | 本番 |
| バックアップとレプリカ | マスク済み、保護がデータとともに移動 | 平文、変換は読み取り時 |
| パフォーマンスコスト | 一度だけ（コピー時） | 毎クエリ |
| 主な用途 | 安全なテストデータ | ロールベースのアクセス制御 |
| 主なリスク | 古いデータ、参照整合性の破壊 | 特権ロールや直接接続によるバイパス |
チームが最も見落としがちな行はバックアップです。静的マスキングはコピーを保護しますが、動的マスキングは保護しません。だから要件が「このデータセットに実際の PII を含めない」であれば、動的マスキングだけではその基準を満たせません。保存されたデータは依然として実物です。
ツールとソリューション
静的マスキングはバッチジョブとして動作するため、ツールはテストデータやデータパイプラインの世界に属します。Perforce Delphix、Informatica Persistent Data Masking、IBM InfoSphere Optim、Oracle Data Masking and Subsetting Pack、Tonic.ai などです。
動的マスキングは読み取り時に動作するため、エンジンの中、またはその前段のレイヤーに存在します。
- ネイティブのエンジン DDM: SQL Server、Oracle、Snowflake、BigQuery は同梱しています。MySQL と PostgreSQL は同梱していません。
- エンジンの前段: クエリ経路上の Bytebase、そして Immuta や Satori のようなアクセスガバナンスプラットフォーム。
使い分け
データが本番を離れるときは静的を使います。下位環境のリフレッシュ、オフショアチームへのデータ提供、CI フィクスチャの構築、デモの収録。利用者はそもそも実際の値を保持すべきではありません。
データが本番に留まり、異なるユーザーが同じ行の異なるビューを必要とするときは動的を使います。ライブデータへのロールベースアクセスです。
そして正直なところ、よくある最終形は両方です。ステージングを静的マスキングで本番からリフレッシュし、残る本番のクエリには動的マスキングを実行します。両者は異なる問題を解決するので、どちらか一方を選んで終わりにはできません。
代表的な静的ワークフローは非本番リフレッシュです。開発・テスト・ステージングを本番から定期的に再構築し、コピー時に機微なカラムをマスクして、実際の PII が下流に流れ込まないようにします。形式と関係を保ち、データがコードを実際に動かせるようにします。
規制対象のエステートでは、両者は同じ本番データベースから並行して動作します。動的マスキングは本番のライブ読み取りを保護します。スケジュールされた静的マスキングジョブが、すべての非本番環境に安全なデータを供給します。
Bytebase の位置づけ
Bytebase は動的マスキングを行い、静的マスキングは行いません。Bytebase Dynamic Data Masking は人間のクエリ経路を統制します。クエリは SQL Editor を経由し、結果はポリシーに従ってエディタから出る前にマスクされます。1 つのポリシーモデルが、フリート内のすべてのエンジンに適用されます。ネイティブ DDM をまったく持たない MySQL と PostgreSQL を含めてです。
ここは正確に述べる価値があります。誠実な境界線だからです。Bytebase がマスクするのは、自身を通って流れる読み取り、つまり人間とエージェントのアドホックなクエリ経路です。独自の接続文字列でデータベースに直結するアプリケーションは Bytebase を迂回し、平文を見ます。ネイティブのエンジン DDM はエンジンの内側で強制されるので、アプリのものを含むすべての接続をカバーしますが、その 1 つのエンジンに限られます。実際に誰から守ろうとしているのかに合った制御を選んでください。
ネイティブ DDM は、存在する場合でもエンジンごとに異なり、MySQL と PostgreSQL にはまったくありません。Bytebase はそのすべてに同じポリシーを適用します。
結局のところ、マスキングはストレージの問題ではなくポリシーの問題です。静的か動的かが決めるのは、いつ強制するか、それだけです。
このチュートリアルで Bytebase Dynamic Data Masking を試せます。
Further Readings
- What is Dynamic Data Masking
- Static Data Masking Tools
- Dynamic Data Masking Best Practices
- Oracle Dynamic Data Masking
- SQL Server Dynamic Data Masking
- BigQuery Dynamic Data Masking
- Snowflake Dynamic Data Masking and Alternatives
- MySQL Dynamic Data Masking
- PostgreSQL Dynamic Data Masking