動的データマスキングは、読み取り時に機微なカラムを書き換えます。選ぶべきは製品ではなく、どこで強制するかです。経路を間違えると、アナリストにはマスクされたデータが表示される一方で、アプリケーションの接続は平文のまま読み取ってしまいます。どの呼び出し元をカバーすべきか、そしていくつのエンジンにまたがるかで選びます。
エンジンの中か、経路の上か。
マスキングは 2 つの場所のいずれかで強制されます。エンジンの中。そこではそのデータベースへの全接続に対して結果を書き換えます。あるいはデータベースの手前にある単一のアクセス経路の上 — アプリケーションの経路、人間の経路、ダッシュボードの経路 — そこではその経路だけに対して結果を書き換えます。
この 2 つは正反対の方向にトレードオフします。エンジンでの強制は、呼び出し元には広く、エンジンには狭い。全接続をマスクしますが、その 1 つのデータベースに限られます。経路での強制はその逆です。1 つの呼び出し元をマスクしますが、フリート内のすべてのエンジンにまたがれます。
つまり 2 つのことが変わります — そのアプローチがどの呼び出し元をマスクするか、そしていくつのエンジンにまたがるか。両方を満たす単一のアプローチはありません。だからこそ、これらのアプローチは競合するのではなく組み合わさるのです。
読み取りをマスクする 5 つの場所
| アプローチ | マスクする呼び出し元 | エンジンの範囲 | バイパス経路 | アンマスクの監査証跡 |
|---|---|---|---|---|
| エンジンネイティブ DDM | そのエンジンへの全接続（アプリ含む） | 単一エンジン | — | エンジンごと、まちまち |
| データベース内（ビュー／関数／RLS） | そのエンジン上の全 SQL 呼び出し元 | 単一エンジン | 別のコード経路 | 自前で用意 |
| アプリケーション／API レイヤー | アプリ自身のレスポンス | アプリ依存 | 直接 SQL、BI ツール、psql | アプリのログのみ |
| BI／セマンティックレイヤー | そのツールのユーザー | そのツールのみ | 直接 SQL、他の BI ツール | ツール固有 |
| Bytebase | 人による随時アクセス経路（SQL Editor 経由） | 全エンジン | アプリの直接接続 | 中央集約、組み込み |
エンジンネイティブの動的データマスキング
マスキングはエンジンの中で動作します。SQL Server はマスク型ときめ細かな UNMASK を備えています。Snowflake はカラムにバインドされたマスキングポリシーを持ちます。Oracle には Data Redaction があります。BigQuery、MySQL Enterprise、そして PostgreSQL Anonymizer 拡張が残りをカバーします。エンジンは、ロールに応じて全接続に対し結果を書き換えます。
強制がエンジンの中にあるため、他のどれも捕捉できない呼び出し元を捕捉します。アプリケーション自身のサービスアカウントです。その接続は常時稼働で、たいてい過剰な権限を持ちます。ネイティブ DDM は、コード変更なしにこれをマスクします。
限界は到達範囲です。1 つのエンジン、1 つの機能セット。Postgres、MySQL、Snowflake を並べて運用すれば、3 つの構文と 3 つの監査フォーマットを持つ 3 つのマスキングモデルを維持することになります。ポリシーはフリート全体には引き継がれません。
データベース内で手作り
ネイティブ機能がなければ、チームは自前で作ります。current_user を使った CASE によるマスクビュー、SECURITY DEFINER 関数、カラムロジックと組み合わせた行レベルセキュリティ。これはネイティブ DDM と同じく、そのエンジン上の全 SQL 呼び出し元に届きます。
代償は脆さです。2 つ目のコード経路がこれを破ります — ビューではなくベーステーブルへのクエリ、CASE が考慮していないロール、プランナの変更で漏れる関数。ロジックも、テストも、あらゆるエッジケースも、自分たちで抱えることになります。
アプリケーション／API レイヤー
アプリケーションでマスクします。ロールを意識したシリアライザ、API でのフィールドレベル認可、データがサービスを離れる前のリダクション処理。データベースは実際の値を返し、アプリがユーザーに何を見せるかを決めます。
これはアプリ経由のアクセスを、そしてアプリ経由のアクセスだけを保護します。直接 SQL、BI ツール、psql セッション — いずれもマスクされずに読み取ります。さらにポリシーはサービス間に分散し、1 つのカラムのルールは、それを読むコードベースの数だけ存在することになります。
BI／セマンティックレイヤー
クエリがモデリングレイヤーを離れる時点でマスキングを強制します。Looker の access_filter、dbt セマンティックレイヤー、Cube。ダッシュボードのユーザーにはマスクされたフィールドが表示されます。
到達範囲はそのツールで止まります。別の BI ツール、エクスポートジョブ、あるいは直接クエリは、マスクされていないソースを読み取ります。露出がダッシュボードだけなら有用ですが、そうでなければ不十分です。
Bytebase
上記の 4 つのアプローチは、異なる側面から同じ隙間を残します。ネイティブ DDM はポリシーをエンジンごとに分断します。手作りのマスキングは、自分たちで保守するビューや関数にポリシーを散らします。アプリケーションと BI のマスキングは、コードベースやツールに散らします。どれも、何が機微で誰が読んでよいかを定める、単一のガバナンスされた場所ではありません。
Bytebase は、人間の経路における、その場所です。アナリスト、DBA、サポートエンジニア、データサイエンティストは SQL Editor を通じてクエリします。結果は、接続されたすべてのエンジンにわたり、ロールに応じてカラム単位の粒度でマスクされて返ります。1 つのポリシーモデルで、すべてのデータベースを。
そしてポリシーには、エンジンが備えていないワークフローが伴います。リクエスト。承認。監査。実際の値が必要な閲覧者はリクエストを起票し、承認者はスコープと時間枠を指定して許可します。その許可と、マスク解除されたすべてのクエリは、1 つの監査ログに記録されます。ポリシー自体は Bytebase Terraform プロバイダーを通じてコードとして構成されます。ルールは 1 つのソースからバージョン管理され、レビューされ、デプロイされます — 各エンジンのコンソールにクリックで入力するのでも、各ビューに手書きするのでも、各サービスに複製するのでもありません。ネイティブ DDM はマスクで止まります。リクエストフロー、監査証跡、そして Policy as Code が、その上に乗ります。
限界は経路です。マスキングは Bytebase を通る読み取りに適用されます。自身の接続文字列でデータベースに直接接続するアプリケーションは、Bytebase をバイパスして平文を読み取ります。これは人間のアクセス制御であって、アプリケーションのアクセス制御ではありません。
制御を呼び出し元に合わせる
経路を選べば、アプローチはおのずと決まります。
過剰な権限を持つアプリケーションのサービスアカウントや、アプリ経由でクエリする開発者が心配ですか？ 制御は、アプリが読み取る場所 — エンジン、またはアプリケーションレイヤー — に置きます。
本番を随時クエリする人間 — アナリスト、DBA、サポート、オンコール — が心配ですか？ 制御は人間の経路に置きます。Bytebase は、アプリケーションの接続には触れずに、アンマスクの監査証跡とともに、すべてのエンジンにわたってこれをマスクします。
機微なデータの露出がダッシュボードの中だけですか？ BI レイヤーがそれをカバーします。
問いは、どのツールが最良かではありません。どの呼び出し元をマスクするか、です。
2 つの経路。2 つの制御。
ほとんどの環境では、2 つの呼び出し元が同時に動いています。アプリケーションはサービスアカウントで接続し、ログオフしません。人間は調査・デバッグ・レポートのために接続します。異なる呼び出し元、異なる経路 — そして 1 つの制御で両方をカバーできることはまれです。
ネイティブ DDM はアプリケーションの経路を塞ぎます。サービスアカウントを含め、そのエンジンへの全接続をマスクします。Bytebase は人間の経路を塞ぎます — ネイティブ DDM が一度に 1 つのエンジンしかカバーできない随時クエリです — そして、誰が・何を・どこでマスク解除したかを記録します。
両方を併用し、ポリシーの一貫性を保ちます。アプリケーションに対してマスクされたカラムが、アナリストには読めてしまう、ということがあってはなりません。2 つの制御が 2 つの呼び出し元を保護します。その背後にあるポリシーは、1 つとして読めるべきです。
ポリシーを一度だけ定義する
何が機微かを、ツール単位ではなくカラム単位・ロール単位で決めます。そしてその定義を、人々が実際に使う経路に適用します。まずはデータマスキングのドキュメントから、フリート全体にカラム単位のポリシーを設定しましょう。