OneLake セキュリティ (RLS および CLS) の Spark サポート

Fabric Spark は OneLake セキュリティと統合されるため、ユーザーが Spark ノートブックと Spark ジョブ定義から lakehouse Delta テーブルを読み取るときに、OneLake で 1 回定義された行レベルセキュリティ (RLS) ポリシーと列レベル セキュリティ (CLS) ポリシーが一貫して適用されます。 ユーザーは引き続き標準の Spark SQL または DataFrame クエリを記述します。Spark では結果が透過的にフィルター処理されるため、各ユーザーはアクセスが許可されている行と列のみが表示されます。

この記事では、適用アーキテクチャ、データ準備フロー、ユーザー エクスペリエンス、サポートされるシナリオと制限など、Spark と OneLake セキュリティ の連携について 説明します。

概念の概要

• 単一の真理の源。 RLS ルールと CLS 列リストは、OneLake セキュリティ ロールを使用して lakehouse で 1 回定義されます。 Spark はポリシーを保存または複製しません。
• エンジンに依存しない効果的なアクセス。 OneLake は、許可された列や RLS 行フィルター メタデータなど、要求するユーザーの事前計算された 有効なアクセスを 返します。 Spark は、クエリ時にその有効なアクセスを使用します。
• デルタのみのフィルター処理。 OneLake および Fabric プラットフォーム レイヤーは、RLS と CLS を Delta Parquet テーブルにのみ適用します。 ルールが適用されたデルタ以外のオブジェクトは、Spark によってフィルター処理されるのではなく、プラットフォームによってブロックされます。
• 特権ロールはバイパスされます。 OneLake および Fabric プラットフォームの動作として、ワークスペース Admin、Member、および Contributor ロールは RLS または CLS によって制限されません。 フィルター処理は 、ビューアー と、OneLake セキュリティ ロールを介してアクセス権を付与されたユーザーに適用されます。

Spark が OneLake セキュリティを適用する方法

ユーザーがセキュリティで保護された lakehouse テーブルにアクセスするクエリを送信すると、Spark は、ユーザーのクエリと、そのユーザーの OneLake セキュリティ有効アクセスを組み合わせた実行プランを準備します。 強制 は、 ユーザー コードのフィルター後のステップとしてではなく、実行中に行われるため、代替 API やパスベースの読み取りではバイパスできません。

二コンテキスト実行モデル

Fabric Spark では、次の 2 つの実行コンテキストを使用して、ポリシーの評価をユーザー コードから分離します。

• ユーザー コンテキスト。 ユーザーの ID を使用して、ユーザーのノートブックまたは Spark ジョブ定義を実行します。 このコンテキストはクエリを計画し、フィルター処理された出力を使用しますが、セキュリティで保護されたテーブルに直接フィルター処理されていないアクセス権を持つことはありません。
• システム (セキュリティ) コンテキスト。 OneLake に対するユーザーの有効なアクセスを解決し、基になる Delta ファイルを読み取り、RLS 行フィルターと CLS プロジェクションを適用し、ユーザーが表示できる行と列のみを返す、特権を持つMicrosoftマネージド コンテキスト。

システム コンテキストは、ユーザーのノートブック セッションと共に実行されるジョブとしてSparkSecurityControlに表示されます。 ジョブ名と監視経験は、Fabricプラットフォーム動作です。 これらのジョブは想定されており、OneLake のセキュリティ管理が有効であることを示します。

セキュリティで保護されたテーブルのクエリ フロー

1. ユーザーは Spark ノートブックでクエリを実行します (たとえば、 SELECT * FROM lakehouse.sales)。
2. Spark は、Lakehouse カタログを介してテーブルを解決し、OneLake セキュリティが有効になっていることを検出します。
3. Spark は、OneLake から現在のユーザーの 有効なアクセスを 要求します。 応答には、許可された列リスト (CLS) と RLS 行フィルターメタデータが含まれます。
4. システム セキュリティ コンテキストは Delta ファイルを読み取り、許可された列のみを投影し、実行時にビットマップ スタイルまたは削除ベクター スタイルの行フィルター処理を使用して RLS を適用します。
5. フィルター処理された結果はユーザー コンテキストに戻され、既にフィルター処理されたデータに対するユーザーのクエリ (結合、集計、セキュリティ保護されていないターゲットへの書き込みなど) が完了します。

ポリシーの種類ごとに何が起こるか

正規の作成規則と RLS 式の構文については、 行レベルのセキュリティ と 列レベルのセキュリティに関する 記事を参照してください。

Spark がユーザーのデータを準備する方法

OneLake セキュリティは、データ コンシューマーに対して透過的に設計されています。 ユーザーは既に知っている API を引き続き使用し、Spark はポリシーの解決とフィルター処理を自分の代わりに処理します。

Spark SQL

-- Returns only rows and columns the current user is authorized to see.
SELECT product_category, SUM(amount) AS total
FROM sales.transactions
GROUP BY product_category;

PySpark DataFrame

df = spark.read.table("sales.transactions")
df.filter("region = 'EMEA'").groupBy("product_category").sum("amount").show()

どちらの例でも、DataFrame に読み込まれる transactions テーブル データは既に OneLake セキュリティによってフィルター処理されています。 後続の変換は、フィルター処理されたデータに対してのみ動作します。

ファイルへの直接アクセスがブロックされている

ダイレクトパスアクセスでは、Lakehouseカタログポリシーの解決プロセスがバイパスされます。 テーブルで OneLake セキュリティが有効になっている場合、OneLake および Fabric プラットフォーム レイヤーは、特権のないユーザーに対して次のパターンをブロックします。

• spark.read.format("delta").load("abfss://...")
• DeltaTable.forPath(spark, "abfss://...")
• OneLake REST/SDK は、セキュリティで保護されたテーブルの Tables/<table> フォルダーに対して読み取ります。

ユーザーは、Spark が有効なアクセスを解決して適用できるように、lakehouse テーブル名 ( spark.read.table("lakehouse.table") や Spark SQL など) を介してセキュリティで保護されたテーブルにアクセスする必要があります。

ユーザー エクスペリエンス

• 透過的なフィルター処理。 クエリの書き換えや特別な構文は必要ありません。 同じノートブックは、異なるロールを持つユーザーに対して機能し、ロール固有のデータを返します。
• エンジン間で一貫した結果。 Spark に適用されるのと同じ RLS ルールと CLS プロジェクションは、SQL 分析エンドポイント、Direct Lake 上に構築されたセマンティック モデル、および承認されたサードパーティ エンジンにも適用されます。 OneLake セキュリティ統合の概要を参照してください。
• 特権ロールはすべてを見ることができます。 OneLake と Fabric プラットフォームの動作として、ワークスペース Admin、 Member、および Contributor ユーザーは、パイプラインの開発、テーブルのメンテナンス (OPTIMIZE、VACUUM)、トラブルシューティングに役立つフィルター処理されていないデータを引き続き表示します。
• モニタリング。 監視ハブに表示される SparkSecurityControl ジョブは、ポリシーの適用を実行するシステム コンテキストに対応します。 ジョブ名と監視ハブのエントリは、Fabricプラットフォームの運用の一部です。

パフォーマンスに関する考慮事項

• RLS 行のフィルタリング。 RLS は、ビットマップ スタイルまたは削除ベクター スタイルのフィルター処理と、サポートされている場合はネイティブ実行エンジンを使用してデルタ スキャンの近くに適用されます。 この設計により、ユーザー コンテキストで具体化される行が最小限に抑えられます。
• 列のプルーニング CLS 列リストは、ユーザーのプロジェクションと組み合わされます。 差分ストレージから読み取されるのは、交差部分だけです。
• 有効なアクセス キャッシュ。 Spark は、クエリごとにポリシーと有効なアクセス メタデータをキャッシュし、クエリの実行が停止したときにクリーンアップします。
• パーティションおよび統計の使用。 Standard Delta パーティションの排除とデータスキップは RLS 行フィルター処理で引き続き適用されるため、パーティション テーブルに対するクエリは効率的なままです。

サポートされているシナリオ

• Lakehouse カタログ (<lakehouse>.<table>) を使用して、Spark ノートブックや Spark ジョブ定義で Lakehouse の Delta テーブルを読み取ります。
• セキュリティで保護されたテーブルに対する Spark SQL および PySpark/Scala DataFrame API。
• セキュリティで保護されたテーブルでの結合、集計、およびダウンストリーム変換。
• セキュリティで保護されたソースからセキュリティで保護されていない出力への書き込み。 セキュリティで保護されたレイクハウスの外部に書き込まれた出力テーブルには、書き込みユーザーが読み取ることが許可された既にフィルター処理されたデータのみが含まれます。
• ショートカットを使用して、ソースの lakehouse に OneLake セキュリティが有効な場合、ワークスペース間の lakehouse にアクセスできます。

制限事項

Spark の OneLake セキュリティ RLS と CLS は、 OneLake の全体的なセキュリティ制限を継承します。 注目すべき動作と制限は次のとおりです。

• Spark RLS/CLS の実装では、サービス プリンシパルはサポートされていません。行レベルおよび列レベルのセキュリティ ポリシーでは、ユーザー ID のみが評価されます。 ワークスペース ID を使用してノートブックを実行すると、ワークスペース ID 自体に RLS/CLS は適用されず、ノートブック コンテキスト内でクエリを実行する個々のユーザーに対してのみ適用されます。
• OneLake および Fabric プラットフォーム レイヤーは、RLS と CLS を Delta parquet テーブルにのみ適用します。 セキュリティで保護されたロール内のデルタ以外のオブジェクトはブロックされます。
• OneLake および Fabric プラットフォーム レイヤーは、特権のないユーザーのセキュリティで保護されたテーブルに対する直接パス読み取り (abfss://、DeltaTable.forPath) をブロックします。
• OneLake および Fabric プラットフォーム レイヤーでは、2 つのロールのメンバーであるユーザーがサポートされていません。1 つは RLS を定義し、もう 1 つは影響を受けるテーブルの CLS を定義します。
• OneLake および Fabric プラットフォームの動作として、ワークスペース Admin、Member、および Contributor ロールは RLS と CLS をバイパスします。
• セキュリティで保護されたソースからのセキュリティ対策がない出力への書き込みはサポートされており、すでにフィルター処理されたデータ上で動作します。 セキュリティで保護されたターゲットへの書き込み (INSERT/UPDATE/DELETE/MERGE) は、RLS または CLS の対象となるユーザーではサポートされない場合があります。では、セキュリティで保護されたテーブルへの ETL 書き込みに特権 ID を使用します。

関連するコンテンツ

• OneLake セキュリティの概要
• OneLake の行レベルのセキュリティ
• OneLake の列レベルのセキュリティ
• OneLake セキュリティ統合の概要
• lakehouse のワークスペース ロール
• Lakehouse の共有とアクセス許可の管理
• Fabric Spark のセキュリティ