静的データマスキングと動的データマスキングは、どちらも機微なカラムを保護しますが、作用する瞬間が異なります。静的マスキングはデータを一度だけ書き換え、サニタイズされたコピーを作ります。動的マスキングは読み取り時にクエリ結果を書き換え、ソースはそのままにします。誤った方を選ぶと、実際の 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 を含めて。
ネイティブ DDM は、存在する場合でもエンジンごとに異なります: Oracle、SQL Server、BigQuery、Snowflakeはそれぞれ独自のものを持ちます。MySQLとPostgreSQLは持ちません。Bytebase はそのすべてに同じポリシーを適用します。
このチュートリアルで Bytebase Dynamic Data Masking を試せます。