高度な列レベルのセキュリティトピック¶
このトピックでは、列レベルのセキュリティマスキングポリシーに関連する2つの高度な概念についてその概要を説明します。
ロール階層。
複数の コンテキスト関数 を使用します。
コンテキスト関数およびロール階層¶
列レベルのセキュリティでは、マスキングのポリシー本文の条件で コンテキスト関数 を使用して、ユーザーにデータを表示する権限があるかどうかを強制できます。ユーザーが特定の SQL ステートメントでデータを表示できるかどうかを判断するには、次の点を考慮してください。
- 現在のセッション
CURRENT_ROLE を使用したマスキングポリシー条件では、現在のセッションで使用されているロールがターゲットになります。
- 実行中のロール
INVOKER_ROLE を使用したマスキングポリシー条件では、SQLステートメントの実行ロールがターゲットになります。
- ロール階層
ポリシー条件でロール階層が必要な場合は、 IS_ROLE_IN_SESSION を使用します。
マスキングポリシー条件で指定されたロール(例:
analyst
カスタムロール)がCURRENT_ROLEまたはINVOKER_ROLEロール階層において権限が低いロールであるかどうかを確認します。その場合、CURRENT_ROLEまたはINVOKER_ROLE関数によって返されるロールは、指定されたロールの権限を継承します。ロール階層と権限継承の詳細については、以下を参照してください。
次の表は、現在のセッション、実行中のロール、およびロール階層を対象とするマスキングポリシーの一般的なコンテキスト関数を示しています。
コンテキスト関数 |
説明 |
---|---|
CURRENT_ROLE ^ 現在のセッションで使用中のロールの名前を返します。 |
|
IS_ROLE_IN_SESSION ^ セッション内におけるユーザーの現在のロール(つまり、 CURRENT_ROLE によって返されるロール)が指定されたロールの権限を継承する場合は、 TRUE を返します。 |
|
INVOKER_ROLE ^ 実行中ロールの名前を返します。 |
|
IS_GRANTED_TO_INVOKER_ROLE ^ INVOKER_ROLE 関数によって返されたロールが引数で指定されたロールの権限を継承する場合は、 TRUE を返します。 |
|
INVOKER_SHARE ^ INVOKER_SHARE 関数が呼び出されたテーブルまたはビューに直接アクセスした共有の名前を返します。 |
CURRENT_ROLE と IS_ROLE_IN_SESSION の使用¶
CURRENT_ROLEを使用したマスキングポリシー条件では、現在のセッションがターゲットになり、SQLステートメントの実行コンテキストによる影響を受けません。
ポリシー条件でロールのアクティブ化とロール階層が必要な場合は、 IS_ROLE_IN_SESSION を使用します。
次のマスキングポリシー本文を検討してください。
case when current_role() in ('ANALYST') then val else '********' end;
特定のユーザーに、このマスキングポリシーが設定されている列のデータを表示する権限があるかどうかを確認するには、次の手順を実行します。
マスキングポリシーの条件を評価します。
指定されたロールがCURRENT_ROLE階層にあるかどうかを確認します。
検証するテストクエリを実行します。
ステップ1:マスキングポリシー条件を評価する¶
次のテーブルは、マスキングポリシー本文の条件の結果をまとめたものです。
コンテキスト |
マスクされていないデータを表示する |
マスクされたデータを表示する |
---|---|---|
CURRENT_ROLE = ANALYSTカスタムロール。 |
✔ |
|
CURRENT_ROLE は、階層内の ANALYSTカスタムロールにあります。 |
✔ |
|
CURRENT_ROLE は、 ANALYSTカスタムロール階層にありません。 |
✔ |
次に、ロールの階層を評価します。
ステップ2:指定されたロールがCURRENT_ROLE階層にあるかどうかを確認します¶
CURRENT_ROLEがANALYSTカスタムロールではないと想定して、CURRENT_ROLEがANALYSTカスタムロールに付与された権限を継承しているかどうかを確認します。
次のステートメントを実行します。
SELECT IS_ROLE_IN_SESSION('ANALYST');+-------------------------------+ | IS_ROLE_IN_SESSION('ANALYST') | +-------------------------------+ | FALSE | +-------------------------------+
SnowflakeはFALSEを返すため、CURRENT_ROLEはANALYSTカスタムロールに付与された権限を継承しません。したがって、この例のマスキングポリシー本文に基づいて、ユーザーに固定マスク値が表示されます。
ステップ3:テストクエリを実行して検証する¶
この例のマスキングポリシーがその列に適用されている列でクエリを実行し、固定マスク値がユーザーに表示されることを検証します。
USE ROLE analyst;
SELECT * FROM mydb.mysch.mytable;
INVOKER_ROLEの使用¶
INVOKER_ROLEを使用したマスキングポリシー条件では、SQLステートメントの実行コンテキストがターゲットになります。
次のテーブルは、実行コンテキストと、マスキングポリシー条件でINVOKER_ROLEが返す値をまとめたものです。
マスキングポリシーが適用されるクエリ |
INVOKER_ROLEが返す値 |
---|---|
ビュー |
所有者のロールを表示します。 |
UDF |
UDF 所有者のロール。 |
呼び出し元権限を持つストアドプロシージャ |
|
所有者権限を持つストアドプロシージャ |
ストアドプロシージャ所有者のロール。 |
タスク |
タスク所有者のロール。 |
ストリーム |
指定された ストリーム をクエリするロール。 |
テーブルの単一ビューに適用される次のマスキングポリシー本文を検討してください。
CASE WHEN INVOKER_ROLE() IN ('ANALYST') THEN val ELSE '********' END;
列でクエリを実行している特定のユーザーにデータ表示権限があるかどうかを確認するには、次の手順を実行します。
マスキングポリシーの条件を評価します。
指定されたロールがビューを所有しているかどうかを確認します。
検証するテストクエリを実行します。
ステップ1:マスキングポリシー条件を評価する¶
次のテーブルは、ビュー列に適用されたマスキングポリシー本文の条件の結果をまとめたものです。
コンテキスト |
マスクされていないデータを表示する |
マスクされたデータを表示する |
---|---|---|
ANALYST カスタムロールは、ビュー所有者ロールです。 |
✔ |
|
ANALYST カスタムロールは、ビュー所有者ロールではありません。 |
✔ |
次に、 ANALYST カスタムロールがビューを所有しているかどうかを確認します。
ステップ2: ANALYST がビューを所有しているかどうかを確認する¶
ANALYST カスタムロールがビューを所有しているかどうかを確認するには、次のステートメントを実行します。
SHOW GRANTS OF ROLE analyst;
ANALYST カスタムロールがビューを所有している場合は、ビュー列に対するクエリではマスクされていないデータが出力されます。
ANALYST カスタムロールがビューを所有していない場合は、マスクされたデータが表示されます。
ステップ3:テストクエリを実行して検証する¶
ビュー列でクエリを実行して、 ANALYST カスタムロールにマスクされたデータとマスクされていないデータのどちらが表示されるかを確認します。
USE ROLE analyst;
select * from mydb.mysch.myview;
IS_GRANTED_TO_INVOKER_ROLEの使用¶
IS_GRANTED_TO_INVOKER_ROLE関数は、条件の一部としてマスキングポリシー本文に渡すことができます。関数がTRUEと評価されると、関数引数のロールはINVOKER_ROLE階層にあります。
社会保障番号(SSNs)のビュー列に適用される次のマスキングポリシー本文を検討してください。
CASE
WHEN IS_GRANTED_TO_INVOKER_ROLE('PAYROLL') THEN val
WHEN IS_GRANTED_TO_INVOKER_ROLE('ANALYST') THEN REGEXP_REPLACE(val, '[0-9]', '*', 7)
ELSE '*******'
END;
ビュー列でクエリを実行している特定のユーザーにデータ表示権限があるかどうかを確認するには、次のステップを実行します。
マスキングポリシーの条件を評価します。
指定されたロールがビュー所有者ロール階層にあるかどうかを確認します。
検証するテストクエリを実行します。
ステップ1:マスキングポリシー条件を評価する¶
次のテーブルは、ビュー列と、ビュー列で表示するデータに適用されたマスキングポリシー本文の条件の結果をまとめたものです。
コンテキスト |
マスクされていないデータ |
部分的にマスクされたデータ |
マスクされたデータ |
---|---|---|---|
PAYROLL カスタムロールは、ビュー所有者ロール階層にあります。 |
✔ |
||
ANALYST カスタムロールは、ビュー所有者ロール階層にあります。 |
✔ |
||
PAYROLL と ANALYST のカスタムロールのいずれも、 . ビュー所有者階層にはありません。 |
✔ |
ステップ2: 指定されたロールがビュー所有者ロール階層にあるかどうかを確認する¶
PAYROLL または ANALYST のカスタムロールのいずれかがビュー所有者階層にある場合は、ビュー所有者ロールで SHOW GRANTS コマンドを実行すると、ロール階層を検証できます。例:
SHOW GRANTS TO ROLE view_owner_role;
SQL ステートメントの出力には、ビュー所有者ロールに PAYROLL または ANALYST のカスタムロールが付与されているかどうかが示されます。
ステップ3:テストクエリを実行して検証する¶
この例のマスキングポリシーがその列に適用されている列でクエリを実行し、ユーザーのビュー列にどのようにデータを表示されるかを検証します。
USE ROLE payroll;
SELECT * FROM mydb.mysch.myview;
USE ROLE analyst;
SELECT * FROM mydb.mysch.myview;
マスキングポリシーでCURRENT_ROLEとINVOKER_ROLEを組み合わせる¶
Snowflakeは、クエリを実行するセッション(つまり、 CURRENT_ROLE)とクエリを実行するオブジェクト所有者(例: ビュー所有者、 INVOKER_ROLE)で使用されているロールを区別するために、単一のマスキングポリシーの作成をサポートしています。このタイプのユースケースは、通常、マスクする値のセットと、マスクされていない値を表示できる比較的少数のオーディエンス(たとえば、ANALYSTカスタムロールを持つユーザー)を決定するよりも複雑です。
マスキングポリシーのハッシュ、暗号化、および暗号化関数¶
ハッシュ および 暗号化/チェックサム は、機密データをマスクするためのマスキングポリシーで使用できます。
これらの関数のいずれかを マスキングポリシー に実装する前に、これらの関数のユースケースに JOIN 操作が含まれるかどうかを検討することが重要です。特定のマスキングポリシーの実装では、テーブルとビューを含むクリエイティブなJOIN操作により、次の制限に基づいてマスクされた値がその実際の値にリバースエンジニアリングされる可能性があります。
実際の値(つまり入力)と、値の総数に基づくハッシュ値、暗号化値、またはチェックサム値(つまり、出力、値の範囲)は1対1の表現でないため、競合が発生する可能性があります。
1対1の表現は、入力値の総数が変換する出力値の平方根に達するまで発生する可能性が高くなります。
たとえば、ハッシュへの出力値が144の場合、最初の12値、つまり、144^(1/2)、144の平方根が一意であり、残りの132値に対して競合が発生する可能性があると予期することは妥当です。この制限とその結果が発生する可能性があるため、JOIN操作で値が使用される可能性のあるマスキングポリシーでは、ハッシュ関数、暗号化関数、またはチェックサム関数を使用しないことをお勧めします。
ちなみに
マスキングポリシーのユースケースがセキュリティ強化のために競合回避を優先する場合は、 外部トークン化 を実装します。入力値と出力値の表現は常に1対1であるため、トークン化によって競合が発生することはありません。
トークン化が不可能な場合、考えられる回避策の1つは、クエリを実行するセッションロール(つまり CURRENT_ROLE)とクエリを実行するオブジェクト所有者(つまり INVOKER_ROLE)を区別するマスキングポリシーを実装することです。
たとえば、次のマスキングポリシーは、従業員情報へのアクセスを規制するために、2つの異なるカスタムロール CSR_EMPL_INFO と DBA_EMPL_INFO を想定しています。
CASE WHEN CURRENT_ROLE() IN ('CSR_EMPL_INFO') THEN HASH(val) WHEN INVOKER_ROLE() IN ('DBA_EMPL_INFO') THEN val ELSE null END;
ポリシーがテーブルに適用されると、ポリシーはテーブルから作成されたすべてのビューに継承されます。カスタムロール DBA_EMPL_INFO がこのテーブルから作成されたビューを所有している場合(つまり、ビューに対する OWNERSHIP 権限を持っている場合)にビューをクエリすると、このカスタムロールを持つユーザーのみが実際の値を表示できます。CSR_EMPL_INFO カスタムロールを持つユーザーには、クエリがテーブルまたはビューのどちらで行われたかに関係なく、常にハッシュ値が表示されます。他のすべてのユーザーには NULL
が表示されます。