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

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

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

注

ポリシーの作成とエンジン間モデルについては、OneLake の行レベルのセキュリティと 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 のセキュリティ管理が有効であることを示します。

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

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

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

Policy	Spark から返されるもの	メモ
RLS のみ	すべての列。ただし、RLS ルールで許可されている行のみ。	行のフィルター処理は、ビットマップスタイルまたは削除ベクタースタイルのフィルター処理を使用してセキュリティコンテキストで適用されます。ユーザーはフィルターロジックを観察できません。
CLS のみ	許可されている列のみ。すべての行。	`SELECT *` は成功し、少なくとも 1 つの列が許可されている場合は許可された列を返します。列が許可されていない場合、Spark はクエリに失敗します。
同じロールの RLS + CLS	許可された行が許可された列に変換される。	両方のルールが同じロールに属している限りサポートされます。
ロール A の RLS、ロール B の CLS (同じユーザー)	クエリは失敗します。	OneLake と Fabric プラットフォームレイヤーでは、2 つのロールのメンバーであるユーザーをサポートしていません。1 つは RLS を定義し、もう 1 つは CLS を定義します。行レベルのセキュリティと列レベルのセキュリティを参照してください。
デルタ以外のオブジェクト	アクセスがブロックされました。	OneLake および Fabric プラットフォームレイヤーは、RLS と CLS を Delta Parquet テーブルにのみ適用します。セキュリティで保護されたロール内の他のオブジェクトはブロックされます。

正規の作成規則と 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プラットフォームの運用の一部です。

スクリーンショットプレースホルダー: ユーザーのノートブックセッションと共に SparkSecurityControl ジョブを示す監視ハブ。

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

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 を使用します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-29