結合ポリシー¶

結合ポリシーの作成¶

最も単純な結合ポリシーでは、ユーザーは常にテーブルやビューを他のテーブルやビューに結合する必要があります。言い換えると、結合指定のない単一テーブルに対するクエリは許可されません。例えば、 jp1 というポリシーを作成します：

CREATE JOIN POLICY jp1
  AS () RETURNS JOIN_CONSTRAINT -> JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE);

このコマンドの完全な構文と JOIN_CONSTRAINT 関数については、 CREATE JOIN POLICY をご覧ください。

テーブルまたはビューへの結合ポリシーの適用¶

結合ポリシーを作成したら、それを特定のテーブルやビューに割り当てて実装します:

• テーブルまたはビューが既に存在する場合は、 ALTER TABLE または ALTER VIEW コマンドを使用します。

• 新規のテーブルまたはビューには、 CREATE TABLE または CREATE VIEW コマンドを使用します。

どちらの場合でも、 JOIN POLICY パラメーターを指定して、結合ポリシー自体を識別します。例えば、次のコマンドはポリシー jp をテーブル join_table に割り当てます:

CREATE OR REPLACE TABLE join_table (
  col1 INT,
  col2 VARCHAR,
  col3 NUMBER )
  JOIN POLICY jp1;

オプションで、特定の結合列を使用するように結合を制限したい場合は、 ALLOWED JOIN KEYS パラメーターを指定します。特定の列に対する結合の制限 をご参照ください。

テーブルやビューに割り当てられる結合ポリシーは、常に1つだけです。結合ポリシーの置換 をご参照ください。

いくつかのクエリを実行して、結合ポリシーをテストします。¶

以下のクエリを実行すると、 jp1 ポリシーがテーブル join_table に適用された場合の動作を確認できます。このテーブルを読み込む必要はありません。空のテーブルでも十分に動作を確認できます。

結合なしでクエリを実行すると、予期せぬエラーが返されます:

SELECT * FROM join_table;

506037 (23001): SQL compilation error: Join Policy violation, please contact the policy admin for details

col1 に対して内部結合を明示的に定義したクエリでは、次の結果が返ります:

SELECT * FROM join_table jt1 INNER JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;

+------+------+------+------+------+------+
| COL1 | COL2 | COL3 | COL1 | COL2 | COL3 |
|------+------+------+------+------+------|
+------+------+------+------+------+------+

col2 に対して明示的に内部結合を定義したクエリで、次の結果が返ります:

SELECT * FROM join_table jt1 INNER JOIN join_table_2 jt2 ON jt1.col2=jt2.col2;

+------+------+------+------+------+------+
| COL1 | COL2 | COL3 | COL1 | COL2 | COL3 |
|------+------+------+------+------+------|
+------+------+------+------+------+------+

特定の列に対する結合の制限¶

結合ポリシーの動作をさらにテストするには、テーブルからポリシーをデタッチ（設定解除）し、 ALLOWED JOIN KEYS パラメーターを含む DDL で join_table を再作成します。

ALTER TABLE join_table UNSET JOIN POLICY;

DROP JOIN POLICY jp1;

CREATE JOIN POLICY jp1
  AS () RETURNS JOIN_CONSTRAINT -> JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE);

CREATE OR REPLACE TABLE join_table (
  col1 INT,
  col2 VARCHAR,
  col3 NUMBER )
  JOIN POLICY jp1 ALLOWED JOIN KEYS (col1);

ここで、 col2 を結合列として、前のクエリをもう一度実行します。col2 は許可された結合キーではないため、クエリが失敗します。

SELECT * FROM join_table jt1 INNER JOIN join_table_2 jt2 ON jt1.col2=jt2.col2;

506038 (23001): SQL compilation error: Join Policy violation, invalid join condition with reason: Disallowed join key used.

同じクエリを、 jt1.col1=jt2.col1 を結合条件として実行すると成功します。これらの2つのテーブルの自然結合は、 col1 と col2 を結合しようとするため失敗します。

結合ポリシーの表示と説明¶

SHOW JOIN POLICIES と DESCRIBE JOIN POLICY のコマンドを使用すると、アカウントの既存の結合ポリシーに関する基本情報を取得できます。結合ポリシーの詳細情報については、 結合ポリシーの監視 をご覧ください。

SHOW JOIN POLICIES;

+-------------------------------+------+---------------+----------------+-------------+--------------+---------+-----------------+---------+
| created_on                    | name | database_name | schema_name    | kind        | owner        | comment | owner_role_type | options |
|-------------------------------+------+---------------+----------------+-------------+--------------+---------+-----------------+---------|
| 2024-12-04 15:15:49.591 -0800 | JP1  | POLICY1_DB    | POLICY1_SCHEMA | JOIN_POLICY | POLICY1_ROLE |         | ROLE            |         |
+-------------------------------+------+---------------+----------------+-------------+--------------+---------+-----------------+---------+

DESCRIBE JOIN POLICY jp1;

+------+-----------+-----------------+----------------------------------------+
| name | signature | return_type     | body                                   |
|------+-----------+-----------------+----------------------------------------|
| JP1  | ()        | JOIN_CONSTRAINT | JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE) |
+------+-----------+-----------------+----------------------------------------+

条件付き結合ポリシーの作成と適用¶

ポリシー管理者は、結合ポリシーの SQL 式を定義して、クエリを実行するユーザーの役割などの要素に基づいて、さまざまなクエリにさまざまな制限を適用できます。この戦略により、1人のユーザーは制限なくテーブルをクエリし、他のユーザーには結合を使用するように要求できます。

たとえば、次の結合ポリシーでは、 ACCOUNTADMIN、 FINANCE_ROLE、 または HR_ROLE のロールを持つユーザーにはテーブルへの無制限のアクセス権を付与しますが、他のすべてのユーザーは結合を指定する必要があります。

CREATE JOIN POLICY my_join_policy
  AS () RETURNS JOIN_CONSTRAINT ->
    CASE
      WHEN CURRENT_ROLE() = 'ACCOUNTADMIN'
          OR CURRENT_ROLE() = 'FINANCE_ROLE'
          OR CURRENT_ROLE() = 'HR_ROLE'
        THEN JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE)
      ELSE JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE)
    END;

Copy

Tip

条件付きポリシーで CURRENT_ROLE などのコンテキスト関数を使用する場合、次のストラテジーを使用できます。

• コンテキスト関数は文字列を返すので、それを使った比較では大文字と小文字が区別されます。大文字小文字を区別せずに比較する場合は、 LOWER を使って文字列をすべて小文字に変換することができます。

• POLICY_CONTEXT 関数は、コンテキスト関数が特定の値を返すときに、ポリシー本体が正しい値を返しているかどうかを評価するのに役立ちます。POLICY_CONTEXT関数は、1つ以上のコンテキスト関数の指定値に基づいてクエリ結果をシミュレートします。

結合のないクエリは失敗します。¶

結合ポリシーを join_table に割り当てると、結合のない単純なクエリは失敗します。以下のクエリはエラーを返します。

SELECT col1, col2 FROM join_table;

WHERE 句の結合は禁止されている¶

join_table （エイリアス jt1） が結合制約付きテーブルの場合、次の WHERE 句の結合はエラーを返します:

SELECT *
  FROM join_table jt1, join_table_2 jt2
  WHERE jt1.col1=jt2.col1;

左と右の外部結合はテーブルの順序に依存する¶

次の例を実行すると、 join_table （エイリアス jt1） が結合制約テーブルである場合の外部結合の動作を確認できますます。最初のクエリはエラーを返します。

SELECT * FROM join_table jt1
  LEFT OUTER JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;

2番目のクエリは結果を返します。

SELECT * FROM join_table jt1
  RIGHT OUTER JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;

2つの結合制約付きテーブルの結合はサポートされていない¶

join_table と join_table_2 の両方に結合ポリシーが割り当てられている場合、次の結合クエリはエラーを返します:

SELECT * FROM join_table jt1 JOIN join_table_2 jt2 ON jt1.col1=jt2.col1;

UNION セット演算子は使用できませんが、 INTERSECT 演算子は使用できます。¶

これらの例では、 join_table には結合ポリシーがありますが、 join_table_3 にはありません。UNION クエリは失敗しますが、同様の INTERSECT クエリは成功しました。

SELECT * FROM JOIN_TABLE
UNION
SELECT * FROM JOIN_TABLE_3;

SELECT * FROM JOIN_TABLE
INTERSECT
SELECT * FROM JOIN_TABLE_3;

EXCEPT の動作はクエリブロックの順序に依存する¶

EXCEPT の動作はクエリブロックの順序に依存します。最初のクエリは、最初に結合制約付きのテーブルから選択し、エラーを返します。

SELECT * FROM JOIN_TABLE
EXCEPT
SELECT * FROM JOIN_TABLE_3;

2番目のクエリは成功します。

SELECT * FROM JOIN_TABLE_3
EXCEPT
SELECT * FROM JOIN_TABLE;

結合制約付きテーブルのビューも保護付きになる¶

join_table に結合ポリシー jp1 が割り当てられているとします。テーブルにビューを作成します:

CREATE VIEW join_table_view AS
  SELECT * FROM join_table;

ここで、結合を指定せずにビューをクエリします：

SELECT * FROM join_table_view;

join_table のポリシーに違反するため、クエリは失敗します。ビューのクエリには結合が含まれていなければなりません。ビューでの結合ポリシーの動作の詳細については、 ビューおよびマテリアライズドビュー をご参照ください。

結合ポリシーの変更¶

ALTER JOIN POLICY コマンドを使用して、結合ポリシールールを変更できます。ポリシーの名前を変更したり、コメントを変更したりもできます。

結合ポリシーを変更する前に、 DESCRIBE JOIN POLICY コマンドまたは GET_DDL 関数を実行して、ポリシーの現在の SQL 式を確認します。

たとえば、次のコマンドを実行して、結合ポリシー jp3 の SQL 式を更新すると、結合が不要になります:

ALTER JOIN POLICY jp3 SET BODY -> JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE);

結合ポリシーの置換¶

結合ポリシーの置き換えに推奨される方法として、 ALTER TABLE ステートメントで FORCE パラメーターを使用し、1 つのコマンドで既存のポリシーをでタッチして新しいポリシーを割り当てます。この方法により、保護にギャップが残らないように、古いポリシーをアトミックに置き換えることができます。

たとえば、すでに結合制約が設定されているテーブルに新しい結合ポリシーを割り当てるには、次のようにします。

ALTER TABLE join_table SET JOIN POLICY jp2 FORCE;

1つのステートメントでテーブルまたはビューからポリシーを（ UNSET JOIN POLICYを使用して）デタッチし、 別のステートメントで新しいポリシーを（ SET JOIN POLICYを使用して）設定することもできます。この方法を選択した場合、2つの演算子の間で結合ポリシーによって暫定的にテーブルが保護付きになることはありません。この間にクエリが機密データにアクセスする可能性があります。

結合ポリシーのデタッチ¶

テーブルまたはビューから結合ポリシーを切り離すには、 ALTER TABLE または ALTER VIEW コマンドの UNSET JOIN POLICY 句を使用します。オブジェクトに複数のポリシーを適用することはできないため、ポリシーには名前は不要です。例:

ALTER VIEW join_view UNSET JOIN POLICY;

結合ポリシーの監視¶

結合ポリシーの使用状況は、次の方法で監視します:

• 共有 SNOWFLAKE データベースのAccount Usageスキーマで、 JOIN_POLICIES ビューをクエリします。このビューは、Snowflakeアカウント内にあるすべての結合ポリシーの カタログ です。

• POLICY_REFERENCES Information Schema テーブル関数をクエリして、結合ポリシー参照を特定し、現在どのテーブルとビューにポリシーが適用されているかを調べます。

SELECT policy_name, policy_body, created
  FROM SNOWFLAKE.ACCOUNT_USAGE.JOIN_POLICIES
  WHERE policy_name='JP2' AND created LIKE '2024-11-26%';

+-------------+----------------------------------------------------------+-------------------------------+
| POLICY_NAME | POLICY_BODY                                              | CREATED                       |
|-------------+----------------------------------------------------------+-------------------------------|
| JP2         | CASE                                                     | 2024-11-26 11:22:54.848 -0800 |
|             |           WHEN CURRENT_ROLE() = 'ACCOUNTADMIN'           |                               |
|             |             THEN JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE) |                               |
|             |           ELSE JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE)    |                               |
|             |         END                                              |                               |
+-------------+----------------------------------------------------------+-------------------------------+

ポリシー管理のベストプラクティス¶

結合ポリシーの作成とそのポリシーのテーブルへの割り当ては、マスキング、投影、集計などの他のポリシーを作成して割り当てる場合と同じ、一般的なプロシージャで行う必要があります。

1. 集中管理アプローチを使用している場合は、ポリシーを管理するためのカスタムロール （join_policy_admin など）を作成します。または、既存のロールを使用できます。

2. このロールに、結合ポリシーを作成および割り当てる権限を付与します。

3. 結合ポリシーを作成します。

4. ポリシーを割り当てるテーブルを作成または変更し、列の結合を許可します （ALLOWED JOIN KEYS）。

5. テーブルに対する結合クエリと非結合クエリをテストします。

テーブルに対するクエリを成功させるには、そのデータを別のテーブルやビューに結合し、許可された列で結合する必要があります。

アクセス制御管理タスク

1. 結合ポリシーを管理するカスタムロールを作成します。既存のロールを再利用することもできます。

   USE ROLE USERADMIN;
   
   CREATE ROLE join_policy_admin;
   

   Copy

2. スキーマに結合ポリシーを作成し、Snowflakeアカウントのテーブルまたはビューにポリシーを割り当てる権限を join_policy_admin カスタムロールに付与します。

   このステップでは、結合ポリシーが privacy.join_policies という名前のデータベースとスキーマに保存され、このデータベースとスキーマがすでに存在していることを前提としています。

   GRANT USAGE ON DATABASE privacy TO ROLE join_policy_admin;
   GRANT USAGE ON SCHEMA privacy.join_policies TO ROLE join_policy_admin;
   
   GRANT CREATE JOIN POLICY
     ON SCHEMA privacy.join_policies TO ROLE join_policy_admin;
   
   GRANT APPLY JOIN POLICY ON ACCOUNT TO ROLE join_policy_admin;
   

   Copy

   join_policy_admin ロールを1人以上のユーザーに割り当てることができるようになりました。

   結合ポリシーを操作するために必要な権限の情報については、 結合ポリシーの管理 （このトピック内）をご参照ください。

結合ポリシー管理タスク

• 結合ポリシーを作成します:

  USE ROLE join_policy_admin;
  USE SCHEMA privacy.join_policies;
  
  CREATE OR REPLACE JOIN POLICY jp1
    AS () RETURNS JOIN_CONSTRAINT -> JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE);
  

  Copy

その他のポリシー¶

このセクションでは、結合ポリシーが マスキングポリシー、 行アクセスポリシー、 集計ポリシー、 および 投影ポリシー などの他のポリシーとどのように相互作用するかについて説明します。

結合制約付きテーブルに他のポリシーを関連付けることができます。テーブルに対する正常なクエリは、すべてのポリシーの要件を満たす必要があります。

行アクセスポリシーが結合制約付きテーブルに割り当てられている場合、行アクセスポリシーに基づいてクエリ結果から除外された行は、結合結果の計算時に含まれません。

マスキングポリシー、行アクセスポリシー、集計ポリシー、投影ポリシーの本体では、その列を含め、結合制約付きテーブルを参照できません。

ビューおよびマテリアライズドビュー¶

結合ポリシーは、ビューとマテリアライズドビューの両方に割り当てることができます。結合ポリシーがビューに適用されると、基になるテーブルは結合制約を受けなくなります。このベーステーブルは、引き続き制限なくクエリできます。

結合制約付きテーブルからビューを作成できるかどうかは、ビューのタイプに応じて異なります。

• 1つ以上の結合制約付きテーブルから通常のビューを作成できますが、そのビューに対するクエリでは、それらのベーステーブルの制約を満たす方法でデータを結合する必要があります。テーブルにビューを作成することで、保護されたテーブルの結合ポリシーを回避することはできません。ビューに対するクエリでは、テーブルのポリシーが尊重され、強制されます。例については、 結合制約付きテーブルのビューも保護付きになる をご参照ください。

• 結合制約付きテーブルまたはビューに基づいてマテリアライズドビューを作成することはできません。また、マテリアライズドビューの基になるテーブルまたはビューに結合ポリシーを割り当てることもできません。

クローンされたオブジェクト¶

次のアプローチは、クローンされたデータベースまたはスキーマに格納されているクローンされたテーブルまたはビューの SELECT 権限を持つユーザーからデータを保護するのに役立ちます。

• 個別の結合ポリシーオブジェクトのクローニングはサポートされていません。

• データベースをクローニングすると、データベース内のすべての結合ポリシーがクローニングされます。

• スキーマのクローニングにより、スキーマ内のすべての結合ポリシーがクローニングされます。

• クローンされたテーブルは、ソーステーブルと同じ結合ポリシーにマップされます。

  • テーブルがその親スキーマのコンテキストでクローンされるときに、同じ親スキーマの結合ポリシーへの参照（つまり、ローカル参照）がソーステーブルにあると、クローンされたテーブルはクローンされた結合ポリシーへの参照を持つようになります。

  • ソーステーブルが別のスキーマの結合ポリシー（つまり、外部参照）を参照している場合、クローンされたテーブルは外部参照を保持します。

詳細については、 CREATE <オブジェクト> ... CLONE をご参照ください。

複製¶

結合ポリシーとその割り当ては、データベース複製と複製グループを使用して複製することができます。

データベース複製 の場合は、次のいずれかの条件に該当すると、複製操作に失敗します。

• プライマリデータベースはEnterprise（またはそれ以上）のアカウントにあり、ポリシーを含んでいるが、下位エディションには、複製の承認されたアカウントが1つ以上ある。

• プライマリデータベースに含まれるテーブルまたはビューには、別のデータベースにあるポリシーへの ダングリングリファレンス がある。

複製グループ で複数のデータベースを複製すると、データベース複製のダングリングリファレンス動作を回避できます。

結合ポリシー権限¶

Snowflakeは、結合ポリシーオブジェクトで以下の権限をサポートしています。

スキーマ内のオブジェクトに対して操作を実行するには、親データベースとスキーマに対する USAGE 権限が必要です。スキーマに対する 任意の権限を付与されたロールは、そのロールがスキーマを解決できることに注意してください。たとえば、スキーマに対するCREATE権限を付与されたロールは、そのスキーマにオブジェクトを作成できますが、そのスキーマに対するUSAGE*も*付与されている必要はありません。

詳細については、 DDL コマンド、操作、および権限の概要 をご参照ください。

結合ポリシー DDL リファレンス¶

Snowflakeは、結合ポリシーを作成および管理するために次の DDL コマンドをサポートしています。

• CREATE JOIN POLICY

• ALTER JOIN POLICY

• DESCRIBE JOIN POLICY

• DROP JOIN POLICY

• SHOW JOIN POLICIES

DDL コマンド、操作、および権限の概要¶

以下のテーブルは、結合ポリシー権限と DDL 操作の関係をまとめたものです。

スキーマ内のオブジェクトに対して操作を実行するには、親データベースとスキーマに対する USAGE 権限が必要です。スキーマに対する 任意の権限を付与されたロールは、そのロールがスキーマを解決できることに注意してください。たとえば、スキーマに対するCREATE権限を付与されたロールは、そのスキーマにオブジェクトを作成できますが、そのスキーマに対するUSAGE*も*付与されている必要はありません。

Snowflakeは、オブジェクトに結合ポリシーを作成および設定するためのさまざまな権限をサポートしています。

1. join_policy_admin カスタムロールが すべての テーブルに結合ポリシーを作成および設定する集中型の結合ポリシー管理アプローチの場合は、次の権限が必要です。

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE join_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE join_policy_admin;
   GRANT CREATE JOIN POLICY ON SCHEMA mydb.schema TO ROLE join_policy_admin;
   GRANT APPLY ON JOIN POLICY ON ACCOUNT TO ROLE join_policy_admin;
   

   Copy

2. ハイブリッド型管理アプローチでは、単一のロールに CREATE JOIN POLICY 権限があり、結合ポリシーに一貫した名前が付けられ、個別のチームまたはロールに特定の結合ポリシーの APPLY 権限があります。

   たとえば、カスタムロール finance_role には、ロールが所有するテーブルおよびビューに結合ポリシー cost_center を設定する権限を付与します（つまり、ロールにはテーブルまたはビューの OWNERSHIP 権限があります）。

   USE ROLE securityadmin;
   GRANT CREATE JOIN POLICY ON SCHEMA mydb.schema TO ROLE join_policy_admin;
   GRANT APPLY ON JOIN POLICY cost_center TO ROLE finance_role;
   

   Copy