OneLakeのセキュリティは、誰がOneLakeのデータにアクセスできるか、そしてそのデータに対してどのような行動を取れるかを決める役割ベースのシステムです。 データアクセス制御モデルを理解することで、ユーザーに必要なアクセスだけを付与できるため、敏感なデータを保護しつつ、適切な人が対応できるようにできます。
この記事では、OneLakeのセキュリティロールの構造、ワークスペースやアイテム権限との統合、OneLakeがあなたのデータへのアクセスをどのように適用・解決するか、そして注意すべき制限について説明します。
OneLake セキュリティ ロール
OneLakeのセキュリティは、ロールベースアクセス制御(RBAC)モデルを用いてOneLakeのデータアクセスを管理しています。 OneLakeのセキュリティ体験において、各役割には以下の要素があります:
- 権限: 読み取りや書き込みなどのデータに対して役割が付与する権限。
- タイプ: 役割の種類。 OneLakeのセキュリティは、メンバーが役割内のデータにアクセスできるGrantロールのみをサポートしています。 アクセスを奪う拒否ロールはサポートしていません。
- 役割内のデータ: 役割がアクセスを許可するテーブル、フォルダー、またはスキーマ。 また、テーブルに対して行レベルおよびカラムレベルのセキュリティでデータアクセスを定義することもできます。
- 役割のメンバー:役割に割り当てられたMicrosoft Entraの識別子、例えばユーザー、グループ、または非ユーザー識別子。 Microsoft Entraグループを割り当てると、OneLakeのセキュリティはそのグループのすべてのメンバーにその役割を付与します。
OneLakeのセキュリティはデフォルトでの拒否モデルを採用しているため、ユーザーはOneLakeのセキュリティロールが明示的にアクセスを許可しない限り、データにアクセスできません。 一部の Fabric アイテムには、ワークスペースのアクセス許可に基づいてユーザーに基本的なアクセス権を付与する既定のロールが設定されています。
アクセス許可とサポートされている項目
OneLakeのセキュリティロールは以下の権限をサポートしています:
-
読む： テーブルからデータを読み取り、関連付けられているテーブルと列のメタデータを表示する機能をユーザーに付与します。 SQLの用語で言えば、この権限は
VIEW_DEFINITIONとSELECTの両方に相当します。 詳細は 「メタデータセキュリティ」をご覧ください。 -
ReadWrite: ユーザーがテーブルやフォルダ内のデータを読み書きし、関連するテーブルや列のメタデータを閲覧する機能を提供します。 SQLの用語で言えば、この権限は
ALTER、DROP、UPDATE、INSERTに相当します。 詳細については、 ReadWrite権限を参照してください。
以下の Fabric アイテムに対して OneLake セキュリティロールを作成できます:
| 布製品 | サポートされているアクセス許可 |
|---|---|
| レイクハウス | 読み取り、読み取り/書き込み |
| Azure Databricks ミラーリングされたカタログ | 読み取り |
| ミラー化されたデータベース | 読み取り |
| ミラーカタログ | 読み取り |
読み書きアクセス許可
ReadWrite権限を使って、読み取り専用ユーザーにアイテム内の特定のデータへの書き込み権限を与えます。
ReadWriteは、Viewerワークスペースの役割を持つユーザーなど、アイテムに対してRead 権限を持つユーザーにのみ適用されます。 ReadWriteをワークスペース管理者、メンバー、または貢献者に割り当てても影響はありません。なぜなら、これらのワークスペースの役割はすでに書き込み権限を持っているからです。
ReadWriteは読み取り権限によって付与されるすべての権限を含み、選択されたオブジェクトとその内容に対して書き込みアクセス権も付与します。 例えば、フォルダのReadWrite権限は、フォルダとその中のデータの両方に書き込みアクセス権を与えます。
ReadWrite権限を持つユーザーは以下の操作を行うことができます:
- フォルダやテーブルを作成、削除、または名前を変更することができます。
- ファイルをアップロードまたは編集してください。
- ショートカットを作成、削除、または名前変更。
ユーザーはSparkノートブック、OneLakeファイルエクスプローラー、またはOneLake APIを通じて書き込み操作を行うことができます。 Fabricはシングルエンジンの書き込みのみをサポートしているため、ReadWrite権限を持つユーザーはOneLakeを通じてのみそのデータに書き込みできます。 すべてのクエリエンジンは一貫して読み取り操作を強制し続けます。
ReadWrite権限を付与するOneLakeセキュリティロールには、行レベルのセキュリティ(RLS)や列レベルのセキュリティ(CLS)制約を含めることはできません。
OneLake のセキュリティとワークスペースのアクセス許可
ワークスペースの役割はOneLakeにおけるデータの最初のセキュリティ境界です。 彼らはコントロールプレーンを管理し、Fabricのアイテムや権限の作成・管理を行い、ワークスペース内のすべてのアイテムに適用します。 各ワークスペースロールが付与する特定のOneLake権限については、「 ワークスペースロールでアクセス権を付与する」をご覧ください。 ワークスペースの役割について詳しく知りたい方は、「Fabricのワークスペースにおけるロール」をご覧ください。
コントロールプレーンへのアクセスを超えて、ワークスペースロールはOneLakeのセキュリティデフォルトロールを通じてデータ項目へのアクセスも提供できます。 (デフォルトロールはビューワーにのみ適用されます。管理者、メンバー、貢献者の役割は書き込み権限を通じて権限が昇格されているためです。)デフォルトロールは、Fabricが新しいアイテムごとに自動的に作成する通常のOneLakeセキュリティロールです。 特定のワークスペースまたはアイテムのアクセス許可を持つユーザーに、そのアイテム内のデータへの既定のレベルのアクセス権が付与されます。 たとえば、Lakehouse アイテムには DefaultReader ロールがあり、ReadAll 権限を持つユーザーは lakehouse 内のデータを表示できます。 このデフォルトのアクセスにより、新たに作成されたアイテムを扱うユーザーは基本的なレベルのアクセス権を得られます。 すべてのデフォルトロールはメンバー仮想化機能を使用しており、その役割のメンバーは必要な権限を持つワークスペース内のユーザーとなります。 たとえば、レイクハウスに対する ReadAll 権限を持つすべてのユーザー
以下の表は標準的なデフォルトロールを示しています。 アイテムにはそのアイテムタイプにのみ適用される専門的なデフォルトロールがある場合もあります。
| 布製品 | ロール名 | 許可が下りました | 割り当てられたメンバー |
|---|---|---|---|
| レイクハウス | DefaultReader |
読み取り | ReadAll アクセス許可を持つすべてのユーザー |
| Azure Databricks ミラーリングされたカタログ | DefaultReader |
読み取り | 読み取りアクセス許可を持つすべてのユーザー |
| ミラーカタログ | DefaultReader |
読み取り | 読み取りアクセス許可を持つすべてのユーザー |
| ミラー化されたデータベース | DefaultReader |
読み取り | ReadAll アクセス許可を持つすべてのユーザー |
Fabricアイテムのデフォルトロールを変更または削除することで、そのメンバーグループのユーザーのアクセス権を変更できます。
エンジンとユーザーによるデータへのアクセス
OneLakeのセキュリティはデフォルトで最小権限アクセスです。 一部のストレージレベルの操作ではRLSやCLSを強制できないため、安全にフィルタリングできない場合、OneLakeはユーザーが見ることを許されないデータを公開するリスクを避けるためにクエリを完全にブロックします。 クエリがフィルタリングされるかブロックされるかは、アクセス経路(サポートされるクエリエンジンか直接ユーザーアクセスか)に依存します。
RLSおよびCLSフィルタリングをサポートするエンジンおよびそれぞれの要件については、「 OneLakeセキュリティで保護されたデータの読み取り」を参照してください。
範囲と執行
このセクションでは、OneLake セキュリティ ロールが特定のスコープへのアクセスを許可する方法、そのアクセスのしくみ、および複数のロールとアクセスの種類にわたってアクセスを解決する方法について詳しく説明します。
テーブル レベルのセキュリティ
OneLakeはすべてのテーブルをフォルダとして表現しますが、FabricのOneLakeセキュリティおよびクエリエンジンの観点から見ると、すべてのフォルダがテーブルというわけではありません。 有効なテーブルであるためには、フォルダーが以下の条件を満たす必要があります:
- フォルダはアイテムの
Tables/ディレクトリに存在します。 スキーマが有効なアイテムの場合は、そのフォルダーも有効なスキーマ フォルダー内にある必要があります。 - フォルダにはテーブルメタデータに対応するJSONファイルを備えた
_delta_logフォルダーが含まれています。 - フォルダには子ショートカットは含まれていません。
テーブルにRLSやCLSを設定すると、テーブルのフォルダがこれらの条件を満たさない場合、OneLakeはアクセスを拒否します。 RLSやCLSがない場合、OneLakeはこれらの条件を満たさないフォルダをフォルダとして扱い、フォルダレベルのセキュリティを適用します。
行レベルと列レベルのセキュリティ
ロール内では、行レベルのセキュリティとカラムレベルのセキュリティを用いて、テーブルの特定の行や列へのアクセスを制限できます。 各コントロールが何をするのか、またOneLakeがどのようにそれを強制しているのかについては、 OneLakeの「テーブル、カラム、行レベルのセキュリティ」をご覧ください。 ユーザーが複数の役割に属している場合にRLSやCLSがどのように解決するかについては、「 複数のOneLakeセキュリティロールの評価」をご覧ください。
メタデータのセキュリティ
OneLake セキュリティの読み取りアクセス許可は、テーブル内のデータとメタデータへのフル アクセスを許可します。 テーブルにアクセスできないユーザーの場合、データは公開されません。 このルールは、カラムレベルのセキュリティや、ユーザーがテーブル内の列を認識・表示しないかどうかにも適用されます。 しかし、OneLakeのセキュリティはテーブルのメタデータがアクセス可能でないことを保証するものではありません。 特定のエラーメッセージや体験では、列名が表示されることがあります。
フォルダーのアクセス許可の継承と移動
フォルダ権限は階層に二方向に影響します:
- 継承: フォルダに付与された権限は、そのファイルやサブフォルダに下位に適用されます。
- トラバーサルとリスト: ユーザーが子項目に権限を持つ場合、OneLakeのセキュリティは親フォルダをリストアップ・トラバースすることで、アクセス可能なデータを発見しナビゲートできるようにします。 トラバーサルは兄弟ファイルやフォルダへのアクセスを許可しません。
OneLakeの湖畔ハウスの階層を考えてみましょう:
Tables/
──── (empty folder)
Files/
────folder1
│ │ file11.txt
│ │
│ └───subfolder11
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
│
└───folder2
│ file21.txt
に対するsubfolder11権限を付与するロール Role1 を作成します。 継承により、そのロールのメンバーは file111.txt と subfolder111 内のすべてを読むことができます。 メンバーはsubfolder11に到達するためにfolder1を見て移動できますが、file11.txtはsubfolder11の兄弟姉妹であるため、Filesの兄弟姉妹であるためTablesを見ることはできません。
Files/
│
└───folder1
│ │
│ └───subfolder11 <-- READ
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
別の役割Role2作成し、folder2に読み込み権限を与えます。 相続を通じて、会員は file21.txtを読むことができます。 メンバーは folder2 を渡り、 Files に到達できますが、その子孫や folder1 を見ることはできません。
Files/
│
└───folder2 <-- READ
│ file21.txt
ショートカットの場合、挙動は少し異なります。 外部データソースへのショートカットはフォルダと同じように動作します。 しかし、他のOneLake店舗へのショートカットには特殊な挙動があります。 ショートカットのターゲット アクセス許可によって、OneLake ショートカットへのアクセスが決まります。 ショートカットをリストアップする際、OneLakeはターゲットアクセスを確認するための連絡を一切行いません。 その結果、ディレクトリをリストアップすると、OneLakeはターゲットへのアクセスに関わらずすべての内部ショートカットを返します。 アクセスチェックはショートカットを開こうとすると評価され、必要な権限を持つデータだけが表示されます。
ショートカット
OneLakeのセキュリティは、OneLakeの内外でデータを保護するためのショートカットと連携しています。 ショートカットは2つの認証モードのいずれかを使用します。
- パススルー: ショートカットはクエリユーザーの身元を利用してターゲットにアクセスします。 OneLakeからOneLakeへのショートカットではパススルーがデフォルトです。
- 委任: ショートカットは設定済みの接続識別子または認証情報を用いてターゲットにアクセスします。 OneLakeからOneLakeへのショートカットは委任認証を使用でき、外部システムへのショートカットは常に委任認証を使用します。
ショートカットを作成するには、ショートカットが作成された経路とターゲットパスの両方に権限が必要です。 各ショートカットタイプの作成およびアクセス要件については、 OneLakeショートカットセキュリティをご覧ください。
パススルー ショートカットでの OneLake セキュリティ
ユーザーが OneLake間のパススルーショートカットを通じてデータにアクセスすると、OneLakeは発信者の身分を利用してターゲットパスへのアクセスを許可します。 ユーザーの実質的なアクセスは、ショートカットパスとターゲットパスの両方の権限によって制約されます。
注
クエリエンジンの識別とショートカット認証は別々の設定です。 パススルーショートカットは通常、発信者の身元を使ってターゲットにアクセスします。 しかし、Direct Lake over SQLやSQL分析エンドポイントを委任されたアイデンティティモードで使うPower BIセマンティックモデルは、消費者アイテムやデータソースの所有者アイデンティティを利用します。 この動作はショートカットの認証モードの設定を変えません。 エンドツーエンドのユーザーアイデンティティパススルーには、OneLakeよりDirect Lakeを使用するか、SQL分析エンドポイントをユーザーのアイデンティティアクセスモードに設定してください。
OneLakeのセキュリティ権限をOneLake間のショートカットに直接定義することはできません。 ショートカットを含むフォルダの権限は、ターゲットパスの権限と結合されます。 対象アイテムがOneLakeセキュリティをサポートしている場合、ユーザーはOneLakeセキュリティロールを通じてアクセスする必要があります。 もしターゲットアイテムがOneLakeのセキュリティをサポートしていない場合、ユーザーはターゲットアイテムに対してFabric ReadAll権限が必要です。 ユーザーはショートカットを通じてターゲットアイテムのデータにアクセスするために、対象アイテムに対してFabric Read権限だけを必要としません。
委任されたショートカットにおける OneLake のセキュリティ
委任ショートカットは、発信者のIDの代わりに設定された接続IDや認証情報を用いてターゲットにアクセスします。 OneLakeのセキュリティは、発信者がその接続を通じてアクセスできる内容を制限します。
委任された OneLake ショートカット
OneLake から OneLake への委任されたショートカットでは、呼び出し元ユーザーには、ショートカット パスに対する自身のアクセス権と、ターゲット パスに対する構成済み接続 ID のアクセス権の共通部分のみが表示されます。 カラムレベルのセキュリティ(CLS)は両方のパスでサポートされています。 ターゲットパスでは行レベルのセキュリティ(RLS)がサポートされていますが、ショートカットパス上でRLSを定義することはできません。
委譲された外部ショートカット
ADLS、Amazon S3、Dataverseなどの外部システムへのショートカットは、設定済みの接続認証情報を使って外部ソースにアクセスします。 OneLakeのセキュリティは、その認証情報で付与されたアクセスの上に適用されます。
例えば、user1 が Amazon S3 バケット内のフォルダーへのレイクハウス ショートカットを作成し、user2 がレイクハウスからそのショートカットにアクセスするとします。 User2は、設定されたS3接続認証情報がソースにアクセスでき、OneLakeのセキュリティがuser2にショートカットパスへのアクセスを許可している場合にのみS3データにアクセスできます。
OneLakeは外部ショートカット全体や選択されたサブパスへのセキュリティアクセスを許可できます。 フォルダの権限は、ショートカット内のフォルダを含むすべてのサブフォルダに再帰的に継承されます。 別のOneLakeショートカットを通じて外部ショートカットに到達したユーザーも、元の外部ショートカットに適用されたOneLakeセキュリティによって承認されなければなりません。
SparkやOneLakeのAPI直接呼び出しを通じて外部ショートカットにアクセスする場合も、その外部ショートカットを含むアイテムに対してFabric Read権限が必要です。 この許可は外部システムとの接続を安全に解決するために必要です。
複数のOneLakeセキュリティ役割を評価する
ユーザーは複数のOneLakeセキュリティロールに所属することができます。 OneLakeは、これらのロールによって付与されたアクセス権を統合し、ユーザーがアクセスできるデータを決定する 効果的なロールを形成します。 OneLakeは段階的に効果的な役割を評価します。
各役割内でのアクセスを解決します
OneLakeはまず各役割を独立して解決します。 役割内では、ユーザーは以下の3つのセキュリティコンポーネントすべてで許可されたデータのみにアクセスできます。
- オブジェクトレベルのセキュリティ(OLS)は、その役割がアクセスできるテーブルやフォルダを決定します。
- 行レベルのセキュリティ(RLS)は、役割がアクセスできるテーブルの行を制限します。
- カラムレベルのセキュリティ(CLS)は、役割がアクセスできるテーブルのどの列を制限します。
3つすべての要素が適用されるため、OneLake はそれらの共通部分を適用します。 例えば、Role1がTable1へのアクセスを許可し、その行と列を制限した場合、Role1の解決されたアクセスは次のようになります:
Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS
交差記号(∩)は、ユーザーがその役割においてOLS、RLS、CLSによって許可されたアクセスのみを受け取ることを示します。
役割間でのアクセスを統合する
各役割を解決した後、OneLakeはユニオンモデル、つまり最も制限の少ないモデルを用いて役割を統合します。 ユニオンシンボル(∪)は、いかなる役割によってもアクセスが認められたものが実効的な役割の一部となることを意味します。 Role1がTableAへのアクセスを許可し、Role2がTableBへのアクセスを許可した場合、両方の役割に属するユーザーが両方のテーブルにアクセスできます。
2つの役割について、実効的な役割は次の通りです:
Effective role = Role1 ∪ Role2
複数のロールが同じテーブルへのアクセスを許可する場合、行レベルのセキュリティルールが OR オペレーターと組み合わさります。 例えば、 city = 'Redmond' と city = 'New York' を city = 'Redmond' OR city = 'New York'として結合させる述語。
列レベルのセキュリティルールもユニオンとして結合されますが、SQL分析エンドポイントでは例外です。 SQL分析エンドポイントでは、CLSにより厳格な否定意味論が使われています。 もしどの役割でもカラムが隠れている場合、エンドポイントはそのカラムへのアクセスをブロックします。 その結果、エンドポイントはすべてのユーザーロールにまたがるCRS許容リストと交差し、ユニオンとしてまとめられません。
重要
同じ役割内でRLSとCLSのルールを同時に適用しておくべきです。 OneLakeは、2つのロールが異なる列セットを許可し、どちらの役割もそのテーブルにRLSを適用するロールの組み合わせをサポートしていません。 例えば、ユーザーはRole1(c1とc2の列といくつかの行のサブセット)や、Role2(c2とc3の列)に属することはできません。
ショートカットとターゲットアクセスを組み合わせる
ショートカットの場合、OneLakeはショートカットの位置とショートカットターゲットでの役割を別々に評価します。 対象ロールはショートカットの場所では推定ロールになります。 OneLakeはショートカットロールからの結合アクセスと推定ターゲットロールからの結合アクセスを交差させます。 このステップにより、ショートカット地点で継承されたアクセスがターゲットの制限を上書きするのを防ぎます。
2つのショートカットロールと2つの推論されたターゲットロールの場合、実効アクセスは次の通りです:
Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)
この式では、 ShortcutRole1 と ShortcutRole2 はショートカット位置における役割を表します。
InferredRole1
InferredRole2はショートカットターゲットから推定される対応する役割です。 各ロールはOLS、RLS、CLSの各コンポーネントから解決され、その後OneLakeがこれらの役割を統合します。
OneLake のセキュリティの制限事項
B2B ゲスト ユーザーに OneLake セキュリティ ロールを割り当てる場合は、Microsoft Entra 外部 ID で B2B の外部コラボレーション設定を構成する必要があります。 ゲストユーザーアクセス設定を「ゲストユーザーと同じメンバーと同じアクセス権を持つ(最も包括的)」に設定してください。
OneLake セキュリティのロールに配布リストを追加した場合、SQL 分析エンドポイントはリストのメンバーを解決してアクセスを強制することはできません。 その結果、ユーザーはSQL分析エンドポイントにアクセスする際に役割のメンバーでないように見えます。 SQLセマンティックモデルのDirect Lakeもこの制限の対象となります。
Sparkノートブックは環境が3.5以上で、Fabric 1.3のランタイムを使う必要があります。
非スキーマのレイクハウスはRLSやCLSで保護されたテーブルのデータプレビューをサポートしていません。 OneLakeセキュリティを備えたスキーマ対応のレイクハウスを使用してください。
OneLakeのセキュリティはAzure Data ShareやPurview Data Shareでは機能しません。 詳細については、「 Azure Data Share」を参照してください。
以下の表は、OneLakeのセキュリティ役割の制限を示しています。
シナリオ 制限 ファブリック項目あたりの OneLake セキュリティ ロールの最大数 アイテムあたり250役(注参照) OneLake セキュリティ ロールあたりのメンバーの最大数 ロールあたり 500 ユーザーまたはユーザー グループ OneLake セキュリティ ロールあたりのアクセス許可の最大数 ロールあたり 500 のアクセス許可 注
アイテムあたりの役割を1,000まで増やすこともできます。 引き上げを要求するには、 Azure サポートにお問い合わせください。
待ち時間
ロール定義の変更が適用されるまでに約 5 分かかります。
OneLake セキュリティ ロールのユーザー グループに対する変更は、OneLake が更新されたユーザー グループにロールのアクセス許可を適用するまでに約 1 時間かかります。 一部のファブリック エンジンには独自のキャッシュ レイヤーがあるため、すべてのシステムでアクセスを更新するために余分な時間が必要になる場合があります。