行フィルターと列マスク

このページでは、行フィルターと列マスクを使用してテーブル内の機密データをフィルター処理するためのガイダンスを提供します。

行フィルターとは何ですか?

行フィルターを使用すると、カスタム ロジックに基づいて、ユーザーがテーブル内でアクセスできる行を制御できます。クエリ時に、行フィルターは条件を評価し、それを満たす行のみを返します。これは、行レベルのセキュリティを実装するために一般的に使用されます (たとえば、特定の地域、部門、またはアカウントのレコードにユーザーを制限するなど)。

行フィルターは SQL ユーザー定義関数 (UDF) として定義され、SQL UDF にラップされた場合は Python または Scala ロジックを組み込むこともできます。行フィルターは、テーブルごとに適用することも、管理タグを使用して ABAC ポリシーを通じて一元的に適用することもできます。

列マスクとは何ですか?

列マスクは、ユーザーが誰であるかに応じて、特定の列に表示される値を制御します。クエリ時に、マスクは列への各参照をマスキング関数の結果に置き換えます。これにより、SSN や電子メールなどの機密データを、ユーザーの ID や役割に基づいて編集または変換できます。

各列には 1 つのマスクを含めることができます。マスクは SQL UDF として定義され、オプションで Python または Scala ロジックをラップでき、マスクされる列と同じ型の値を返す必要があります。列マスクは、たとえば、複数の属性に基づいて動作を変えるために、他の列を入力として受け取ることもできます。

行フィルターと同様に、列マスクはテーブルごとに適用することも、ABAC ポリシーを使用して一元的に管理することもできます。これらはクエリ時に動作し、標準の SQL、ノートブック、ダッシュボードとシームレスに統合されます。

動的ビューとフィルターとマスクのどちらを使用する必要があるか?

動的ビュー、行フィルター、列マスクはすべて、クエリ時にフィルター処理または変換ロジックを適用できますが、管理、スコープ、およびユーザーへの公開方法が異なります。

機能	適用対象	管理	命名の影響	最適な用途...
動的ビュー	ビュー	SQL ロジック	新しいオブジェクト名を作成します。	フィルター処理されたデータの共有または複数のテーブルにまたがる
行フィルター	テーブル	ABAC またはマッピング テーブル	テーブル名は変更されません	ユーザー タグまたはデータ タグに関連付けられた行レベルのアクセス制御
列マスク	テーブル/列	ABAC またはマッピング テーブル	テーブル名は変更されません	ID に基づく機密列データの編集

• 動 的ビューは 、1 つ以上のソース テーブルにまたがる読み取り専用レイヤーが必要な場合、特にデータ共有や複数の入力にロジックを適用する場合に使用します。
• 行フィルターと列マスク は、テーブル名を変更したり、新しいオブジェクトを導入したりせずに、ロジックをテーブルに直接適用する場合に使用します。これらは、ABAC ポリシー (推奨) を使用して管理することも、テーブルで手動で管理することもできます。

完全な比較については、「 アクセス制御方法の比較」を参照してください。

フィルターとマスクの適用方法

行フィルターと列マスクは、主に次の 2 つの方法で実装できます。

• ABAC ポリシーの使用 (ベータ版): 管理されたタグと再利用可能なポリシーを使用して、フィルターとマスクを一元的に適用します。このアプローチは、カタログとスキーマ間で拡張され、テーブルごとの構成の必要性を減らします。ABAC ポリシーは、上位レベルの管理者が定義でき、テーブル所有者が上書きできないため、手動のテーブルレベルポリシーよりも安全であり、一元的なアクセス制御を適用するのに役立ちます。また、ABAC ポリシーのフィルタリングおよびマスキング ロジックは、テーブル固有の UDF よりも効率的に評価されるため、多くの場合、パフォーマンスが向上します。Databricks では、ほとんどのユース ケースで ABAC を使用することをお勧めします。ABAC を使用してフィルターとマスクを適用するには、「 Unity Catalog 属性ベースのアクセス制御 (ABAC)」を参照してください。

• テーブルごとの手動割り当て : 個々のテーブルと列に関数を直接割り当てることで、フィルターとマスクを適用します。このメソッドでは、マッピング テーブルまたはその他のカスタム ロジックを使用できます。きめ細かいテーブル固有の制御が可能ですが、スケーリングと保守が困難になります。詳細については 情報、 行フィルターと列マスクを手動で適用するを参照してください。

パフォーマンスに関する推奨事項

行フィルターと列マスクは、フィルター処理およびマスク操作の前にユーザーが基本テーブルの値の内容を表示できないようにすることで、データの可視性を制御します。一般的なユースケースでは、クエリに対する応答のパフォーマンスが良好です。あまり一般的ではないアプリケーションでは、クエリ エンジンがクエリ パフォーマンスを最適化するか、フィルター処理またはマスクされた値からの情報漏洩を防ぐかを選択する必要がある場合、クエリ パフォーマンスに多少の影響を与えることを犠牲にして、常に安全な決定を下します。このパフォーマンスへの影響を最小限に抑えるには、次の推奨事項を適用します。

• 単純なポリシー関数を使用する: 式が少ないポリシー関数は、多くの場合、より複雑な式よりもパフォーマンスが優れています。 マッピング テーブルと式サブクエリの使用を避け、代わりに単純な CASE 関数を使用してください。
• 関数の引数の数を減らす: これらの列がクエリで使用されていない場合でも、Databricks はポリシー関数の引数によって生成されたソース テーブルへの列参照を最適化できません。これらのテーブルからのクエリのパフォーマンスが向上するため、引数の少ないポリシー関数を使用します。
• AND 結合が多すぎる行フィルターを追加しないでください。 各テーブルでは最大 1 つの行フィルターの追加しかサポートされないため、一般的な方法は、複数の必要なポリシー関数をANDと組み合わせることです。ただし、接続詞を追加するたびに、この表の他の場所で言及され、パフォーマンスに影響を与える可能性のあるコンポーネント (マッピング テーブルなど) が接続詞に含まれる可能性が高くなります。パフォーマンスを向上させるには、接続詞を少なくします。
• これらのテーブルからのテーブル ポリシーおよびクエリでエラーをスローできない決定論的な式を使用します。ANSI 除算など、一部の式では、提供された入力が有効でない場合、エラーがスローされることがあります。このような場合、SQL コンパイラは、フィルタリングやマスキング操作の前に値に関する情報を明らかにする「ゼロ除算」などのエラーの可能性を回避するために、これらの式 (フィルターなど) を含む操作をクエリ プランのあまり下の方に押し出さないようにする必要があります。try_divideなど、エラーをスローしない決定論的な式を使用します。
• テーブルに対してテスト クエリを実行してパフォーマンスを測定します。 行フィルターまたは列マスクを使用して、テーブルに予想されるワークロードを表す現実的なクエリを作成し、パフォーマンスを測定します。ポリシー関数に小さな変更を加え、フィルタリングおよびマスキング ロジックのパフォーマンスと表現力のバランスが適切に取れるまで、その効果を観察します。

その他のベスト プラクティスと UDF の例については、 「ABAC ポリシーの UDF のベスト プラクティス」を参照してください。

制限事項

• 12.2 LTS より前の Databricks Runtime バージョンでは、行フィルターまたは列マスクはサポートされません。これらのランタイムは安全に失敗します。つまり、これらのランタイムからテーブルにアクセスしようとしても、データは返されません。
• Delta Sharingプロバイダーは、行レベルのセキュリティまたは列マスクを持つテーブルを共有できません。 ただし、 Delta Sharing受信者は、行フィルターと列マスクを共有テーブルとフォーリン テーブルにのみ適用できます。ストリーミング テーブルやマテリアライズドビューには適用できません。
• カタログ Iceberg REST Unity REST API を使用して、行フィルターや列マスクを持つテーブルにアクセスすることはできません。
• ビューに行レベルのセキュリティまたは列マスクを適用することはできません。
• タイムトラベルは、行レベルのセキュリティまたは列マスクでは機能しません。
• ポリシーを持つテーブル内のファイルへの、パスベースのアクセスはサポートされていません。
• 元のポリシーに戻る循環依存性を持つ行フィルターまたは列マスクポリシーはサポートされていません。
• 行レベルのセキュリティまたは列マスクを持つテーブルでは、ディープ クローンおよびシャロー クローンはサポートされません。
• MERGE ステートメントは、ネスト、集計、ウィンドウ、制限、または非決定論的関数を含む行フィルターまたは列マスク ポリシーを持つテーブルをサポートしません。
• Delta Lake APIはサポートされていません。

専用アクセスモードの制限

Databricks Runtime 15.3 以前の専用アクセス コンピュート リソースからは、行フィルターまたは列マスクを備えたテーブルにアクセスできません。 ワークスペースでサーバレス コンピュートが有効になっている場合は、 Databricks Runtime 15.4 LTS以降で専用アクセス モードを使用できます。 ただし、Databricks Runtime 15.4 ～ 16.2 では読み取り操作のみがサポートされます。書き込み操作 ( INSERT 、 UPDATE 、 DELETEを含む) には DBR 16.3 以上が必要であり、 MERGE INTOなどのサポートされているパターンを使用する必要があります。

詳細については、専用コンピュートのきめ細かいアクセス制御を参照してください。