Snowflake 動的データマスキング (DDM) と代替

Snowflake 動的データマスキング#

Snowflake 動的データマスキング (DDM) は、データの別マスクコピーを作らずに機微データをリアルタイムにマスクできるセキュリティ機能です。個人識別情報 (PII) などの機微データを保護しつつ、認可されたユーザーにはデータの有用性を保ちます。

DDM はカラム単位でマスキングポリシーを適用し、ユーザーのロールと権限に基づいてオンザフライにデータを変換します。これにより、人間ユーザーやサービスごとに異なるアクセスレベルを許しつつ、機微データを守れます。

簡単なマスキングポリシーを作って適用する例:

-- メールアドレス向けマスキングポリシーを作成
CREATE OR REPLACE MASKING POLICY email_mask AS (val STRING)
RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() IN ('ADMIN', 'DATA_ANALYST') THEN val
    ELSE REGEXP_REPLACE(val, '.+@', '*****@')
  END;

-- カラムにマスキングポリシーを適用
ALTER TABLE customers
MODIFY COLUMN email SET MASKING POLICY email_mask;

限界と課題#

Snowflake DDM は強力なセキュリティを提供しますが、いくつか重要な考慮点と限界があります。

1. Enterprise エディション必須とコスト影響#

Column-level security の一部である Snowflake DDM は、Enterprise エディション以上でのみ利用できます。価格に大きく影響します。

Standard を使っている組織が DDM を有効化するには Enterprise へのアップグレードが必要で、結果として全ワークロードで計算コストが 50% 増加します。このコスト増はマスク対象だけでなく、Snowflake 利用全体に及びます。

2. ポリシー管理の複雑さ#

Snowflake DDM をスケールさせて運用するのは大きな課題があります — 機微カラムでのポリシー乱立、ポリシー変更を追跡する適切なプロセスや監査証跡の欠如、そして Snowsight UI のサポートが無いことです。チームは複雑なマスキングポリシーをすべて SQL コマンドで管理することになり、ポリシー数が増えるほど維持とガバナンスが難しくなります。

-- 複数ロールと条件でのポリシー複雑性の例
CREATE OR REPLACE MASKING POLICY customer_pii_mask AS (val STRING)
RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() = 'DATA_OWNER' THEN val
    WHEN CURRENT_ROLE() = 'ANALYST_SENIOR' AND
         CURRENT_WAREHOUSE() = 'ANALYTICS_WH' THEN val
    WHEN CURRENT_ROLE() = 'CUSTOMER_SERVICE' AND
         CURRENT_TIME() BETWEEN '09:00'::TIME AND '17:00'::TIME THEN
         CONCAT(LEFT(val, 3), '***', RIGHT(val, 2))
    WHEN CURRENT_ROLE() IN ('ANALYST_JUNIOR', 'INTERN') THEN '***MASKED***'
    ELSE NULL
  END;

Snowflake 動的データマスキングの代替#

Snowflake DDM の制限とコストを踏まえて、組織は機微データ保護の代替アプローチを検討することがよくあります。

1. データベースビュー#

データベースビューは、Enterprise エディションを必要とせずにデータマスキングを実装するコスト効率の良い方法です。ビューにはロールベースのロジックとマスキング関数を組み込み、クエリレベルで機微データを保護できます。

-- 顧客データのマスク済みビュー
CREATE OR REPLACE VIEW customers_masked AS
SELECT
    customer_id,
    customer_name,
    CASE
        WHEN CURRENT_ROLE() IN ('ADMIN', 'DATA_ANALYST')
        THEN email
        ELSE REGEXP_REPLACE(email, '.+@', '*****@')
    END AS email,
    CASE
        WHEN CURRENT_ROLE() = 'FINANCE_ADMIN'
        THEN credit_card_number
        WHEN CURRENT_ROLE() = 'CUSTOMER_SERVICE'
        THEN CONCAT('****-****-****-', RIGHT(credit_card_number, 4))
        ELSE '****-****-****-****'
    END AS credit_card_number,
    registration_date
FROM customers;

• 長所: 追加ライセンス不要。すべての Snowflake エディションで動く。
• 短所: マスキングポリシーよりも管理が複雑になりがち — ビューが乱立し、強制力に欠ける。

2. Bytebase#

Bytebase はデータベース DevSecOps プラットフォームで、Snowflake を含む複数 DB システムにわたって動的データマスキング機能を提供します。

Bytebase DDM の仕組み

ミドルウェアアーキテクチャ

Snowflake のネイティブ DDM と異なり、Bytebase は Snowflake のデータマスキング機能に依存せず、ユーザーと Snowflake の間のミドルウェアとして動作します。すべての DB クエリを受け取り、結果を返す前にマスキングルールを適用します。

ポリシーの構成

ユーザーは Bytebase の Web UI で直感的にマスキングポリシーを設定するか、Terraform プロバイダーと REST API でプログラマティック (Infrastructure as Code) に構成できます。

クエリ実行

ユーザーが Bytebase の SQL Editor を通してデータを照会すると、プラットフォームが設定済みのマスキングポリシーをリアルタイムに自動適用し、下層 DB の構造を変えずに機微データを保護します。

長所:

• Snowflake Enterprise エディションへのアップグレードに比べ、通常 10% 程度の費用に抑えられる。
• UI ベースのマスキングポリシー構成と免除付与の管理。Terraform プロバイダーと API 統合もサポート。
• Snowflake 以外も含む複数 DB システムに、同じワークフローでマスキングポリシーを構成できる。

短所:

• マスキングは、ユーザーが Bytebase の SQL Editor を通してクエリしたときにのみ強制される。
• 人 → DB の経路だけをカバーし、サービス → DB の接続は強制しない。

比較#

Snowflake のネイティブ DDM が最も網羅的なカバレッジを提供しますが、コスト、管理性、人のアクセスパターン保護のバランスを取りたい組織には、Bytebase が最適な妥協点になり得ます。