ABACとテーブルレベルの行フィルターおよび列マスクの使い分け
Unity Catalog は、行レベルおよび列レベルのセキュリティに関して、 ABAC ポリシーとテーブルレベルの行フィルタおよび列マスクという 2 つのアプローチをサポートしています。どちらの方法も、それ自体でデータへのアクセスを許可するものではなく、既存のオブジェクトレベルの権限に加えて制限を追加するものです。オブジェクトレベルの権限（ GRANT ）を通じて、ベーステーブルへのアクセスを別途許可する必要があります。
根本的な違いは、制限がどこで定義されているかという点にある。 テーブルレベルの行フィルターと列マスクは、 ALTER TABLEを使用して個々のテーブルに直接感度制御を適用します。テーブル所有者は、管理タグ システムを必要とせずに独自のデータ保護を管理します。 テーブルの数が少ない場合は簡単ですが、各テーブルは個別に設定する必要があり、テーブルの所有者は独自のフィルターやマスクを変更または削除できます。
ABAC ポリシーは カタログ、スキーマ、またはテーブル レベルでアタッチされ、管理タグに基づいてテーブルと列を動的に照合します。 カタログレベルで定義されたポリシーは、そのカタログ内のすべてのテーブルに適用され、個々のテーブルの所有者はそれを削除、変更、または回避することはできません。ポリシーはカタログ上に存在し、クエリがランタイムに達する前にUnity Catalogによって評価されます。 これにより、上位管理者は組織全体のルールを強制し、下位管理者やオーナーがそれらを回避できないようにすることができる。
詳細比較概要
この表は、ABAC とテーブルレベルの行フィルターおよび列マスクの違いをまとめたものです。
考慮 | ABACポリシー | テーブルレベルの行フィルターと列マスク |
|---|---|---|
SQL構文 |
|
|
スコープ | ポリシーの適用範囲（カタログ、スキーマ、またはテーブル）内のすべてのテーブルとその子孫。新たにタグ付けされたテーブルは自動的にカバーされます。 | フィルタまたはマスクが設定される単一のテーブル。各テーブルは個別に設定する必要があります。 |
動的マッチング | テーブルと列は、 | 動的なマッチングは行われません。フィルターとマスクは、特定のテーブルと列に紐付けられています。 |
対象となる原則 |
| UDF 内の |
ポリシーガバナンス | ポリシーは、カタログまたはスキーマの所有者によって設定できます。上位レベルで設定されたテーブルは、所有者が上書き、変更、または削除することはできません。 | テーブルオーナーによって管理され、オーナーは自分のテーブルのフィルターやマスクを変更または削除できます。 |
サポートされていない機能 | タイムトラベル、クローン作成、 Delta Sharingなどの操作は、 |
|
効果的なポリシー |
| テーブル定義上で直接確認できます。 |
監査可能性 |
|
|
一般に、 ABAC ポリシーは 次の場合に使用します。
- 複数のテーブル、スキーマ、カタログにわたって、一貫したアクセスルールが必要です。
- あなたの組織は職務分担が明確です。たとえば、ポリシー作成者はルールを定義し、データスチュワードはデータをタグで分類します。
- データ資産が増加しており、新しいテーブルにタグが付けられた際に自動的に対象となるようにしたいと考えている。
- 特定のプリンシパルに対してタイムトラベル、 Delta Sharing 、または完全なクエリの最適化などの操作を許可するには、
EXCEPT句が必要です。
一般的に、次のような場合に テーブルレベルの行フィルターと列マスク を使用します。
- 各テーブルには厳密かつ固有のロジックがあり、他のテーブルには一般化できません。
- テーブルオーナーは、中央集権的なタグシステムを使用せず、各自でフィルターとマスクを直接管理する必要があります。
- 変更頻度の低い、小規模で安定したテーブル群をお持ちです。
ABACとテーブルレベルの行フィルターおよび列マスクを組み合わせる
ABACとテーブルレベルの行フィルターおよび列マスクは、同じテーブル上で共存できます。クエリ実行時、ポリシーはクエリ実行ユーザーごとに以下のルールに基づいて個別に評価されます。
- 適用できる行フィルターは1つのみです。
- 列ごとに解決できる列マスクは1つだけです。
Databricksは、データ出力ではなく、適用された関数を比較することによって競合を評価します。ABAC とテーブルレベルのフィルタまたはマスクの両方が、同じユーザーに対して同じ行フィルタまたは列マスク機能を適用する場合、 Databricks実行を許可します。 異なる関数を適用する場合、たとえそれらの関数が同一のデータ出力を生成する場合でも、Databricksはアクセスをブロックし、エラーを返します。
競合の解決とトラブルシューティングの詳細については、 「複数のフィルタとマスクのルール」を参照してください。
動的ビューによる行レベルおよび列レベルのセキュリティ
動的ビューでは、 current_user()やis_account_group_member()のようなID関数をビュー定義に直接埋め込むことで、行レベルおよび列レベルのセキュリティを実装することもできます。動的ビュー、行フィルター、列マスクはすべてクエリ実行時にフィルタリングまたは変換ロジックを適用しますが、管理方法、スコープ、およびユーザーへの公開方法が異なります。
機能 | 適用対象 | どのように管理されているか | 最適な用途 |
|---|---|---|---|
動的なビュー | ビュー | ビュー定義におけるSQLロジック | 複数のソーステーブルにまたがるきめ細かなアクセス制御、または共有のためにデータを再構成する機能 |
行フィルターと列マスク | 表と列 | ABAC ポリシーまたはテーブルレベルの割り当て | 新しいオブジェクトを導入することなく、行レベルおよび列レベルのアクセス制御を実現する。 |
複数のソーステーブルにまたがるきめ細かなアクセス制御が必要な場合や、共有のためにデータを再構成する必要がある場合は、動的ビューを使用してください。新しいオブジェクトを導入せずに個々のテーブルへのアクセスを制御したい場合は、行フィルターと列マスクを使用してください。
例えば、動的ビューでは、監査担当者以外にはEメール列を非表示にすることができます。
CREATE VIEW sales_redacted AS
SELECT
user_id,
CASE
WHEN is_account_group_member('auditors') THEN email
ELSE regexp_extract(email, '^.*@(.*)$', 1)
END AS email,
country,
product,
total
FROM sales_raw
動的ビューはクエリ最適化と述語プッシュダウンを完全にサポートしているため、行フィルタや列マスクよりも優れたクエリパフォーマンスを提供できます。また、ユーザーが基となるテーブルを変更することも防止します。
しかし、動的ビューにはデータガバナンスに関して2つの欠点がある。
- 監査の制限 ：動的ビューには、システムテーブルのタグやポリシー定義などの意味メタデータが欠けているため、大規模な監査が困難になります。
- プロービングに対する脆弱性 ：
SecureViewバリアがないため、ユーザーが副作用のある述語を作成してフィルタリングされた行に関する情報を推測するプロービング攻撃から保護されません。保護されたテーブルに対する述語プッシュダウンの理解を参照してください。