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

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

Snowflake 動的データマスキング (DDM) は、認可されていないロールに対してクエリ結果を書き換えます。平文はテーブルにそのまま残ります。ロールベースの述語が、何をユーザーに届けるかを決めます。ポリシーはカラム単位で定義され、読み取り時に評価されます。

Snowflake のシンプルなマスキングポリシー:

-- Create a masking policy for email addresses
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;

-- Apply the masking policy to a column
ALTER TABLE customers
MODIFY COLUMN email SET MASKING POLICY email_mask;

限界#

モデルはきれいです。ギャップが現れるのは請求書と運用 2 日目です。

1. エディション制限とコスト#

DDM は Column-level security の一部で、Enterprise エディションまたは Business Critical の背後にゲートされています。Standard には一切ありません。価格への影響は次のとおりです。

Standard エディションのフリートが DDM を有効にするには、クレジット単価が 50% 増加します。この増加はマスク対象のクエリだけでなく、すべてのワークロードに及びます。

2. スケール時のポリシー管理#

DDM はスケール時に 3 つの運用上のギャップにぶつかります。ポリシーが乱立します。機微カラムごとに 1 つずつで、集約はありません。Snowsight には DDM の UI が無いため、すべてのポリシーが SQL の中に存在します。ポリシー編集や免除付与には、組み込みの監査証跡がありません。

-- Example of policy complexity with multiple roles and conditions
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 動的データマスキングの代替#

エディション制限を回避する代替が 2 つあります。

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

データベースビューは Standard エディションでマスキングを実現します。ビューがベーステーブルをラップします。テーブルではなくビューにアクセスを付与し、ロールベースのロジックとマスキング関数はビューの SELECT の中に置きます。

-- Create a masked view for customer data
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;

• 長所: エディション制限なし。Standard で動く。
• 短所: バリエーションが増えるたびにビューの数が増えます。そして強制力はありません。ベーステーブルに SELECT 権限を持つ者は、誰でも平文を見られます。

2. Bytebase#

Snowflake は DDM を Enterprise (クレジット +50%) または Business Critical (+100%) の背後にゲートします。Standard には一切ありません。Bytebase の動的データマスキングは、同じマスキングモデルを Standard でも Enterprise でも、エディションのアップグレードなしに適用します。

仕組み。クエリは Bytebase の SQL Editor を経由します。Bytebase は結果をユーザーに返す前にマスクします。Snowflake の MASKING POLICY オブジェクトは使われず、ウェアハウス内部は何も変わりません。ポリシーは Web UI、Terraform、または REST API で管理します。

ポリシーモデル。3 つのレイヤー、固定の優先順位:マスキング免除 > グローバルマスキングルール > カラムマスキング。

• グローバルマスキングルール。ワークスペースレベル。ルールは上から下へ評価され、最初に一致したものが勝ちます。マッチ条件は環境、プロジェクト、データベース、データ分類にまたがります。1 つのルールで、フリート内のすべての Snowflake アカウントと、その隣にある Postgres・MySQL クラスターをカバーします。
• カラムマスキング。グローバルルールが適用されない特定カラムに対する、プロジェクトレベルのオーバーライド。
• マスキング免除。指名されたユーザーが、期限付きの Query または Export 免除を受け取ります。サービスアカウントは対象外です。すべての付与がログに残ります。すべてのアクセスがログに残ります。

ワークフロー。リクエスト。レビュー。承認。 免除リクエスト、ポリシー編集、付与の判断は、SQL 実行そのものと並んで記録される第一級の監査イベントです。

強制の境界。ここは正直に伝えるべき部分です。マスキングが適用されるのは、SQL Editor を経由してルーティングされたクエリだけです。サービスアカウントや Snowflake への直接接続 (BI ツール、アプリケーションコード、スケジュールジョブ) は、Bytebase を完全にバイパスします。Bytebase がカバーするのは人間のクエリ経路であり、サービス → ウェアハウスのトラフィックではありません。サービスアカウントも統制する必要がある場合は、ネイティブ DDM が引き続き正しいツールです。

Bytebase が適する場面:

• マスキングのためだけに Enterprise への +50% アップグレードを正当化できない、Standard エディションのフリート。
• Snowflake が Postgres、MySQL、SQL Server と並んで存在するマルチエンジンのフリート。1 つのポリシーモデルで、すべてのエンジンを。
• クエリアクセスに対する承認ワークフローと監査証跡を必要とするチーム。ネイティブ DDM は、カラム書き換えの上にこれらを提供しません。

比較#

結局はトレードオフです。Snowflake DDM はすべてのアクセス経路をカバーしますが、その代償は Enterprise へのアップグレードです。Bytebase はその一部のコストで人間のクエリ経路をカバーし、同じモデルを Snowflake と並ぶ Postgres、MySQL、SQL Server へ拡張します。Standard 上で、マルチエンジンのフリートで、あるいは承認ワークフローが重要な場面では、Bytebase はネイティブ DDM を置き換えるのではなく補完します。