Subscribe
Share
Share
Embed
ワークスペース1つで4つの境界線が生まれます。セキュリティ、コスト、リージョン、ライフサイクル。設定したのはそのうち1つだけ。Fabricで「読み取り専用」が実際に何を意味するのか、OneLakeセキュリティが共同作成者を制限できない理由、そしてロール昇格のたびに静かに起きるセキュリティ変更を掘り下げます。
Episode 36 • 2026-10-02 Duration: 9:54
ワークスペース1つで4つの境界線が生まれます。セキュリティ、コスト、リージョン、ライフサイクル。設定したのはそのうち1つだけ。Fabricで「読み取り専用」が実際に何を意味するのか、OneLakeセキュリティが共同作成者を制限できない理由、そしてロール昇格のたびに静かに起きるセキュリティ変更を掘り下げます。
The Fabric Friday video on this topic: https://youtu.be/tpePwivxtzk
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
このポッドキャストは AI によって生成されています。どちらの音声も合成です。Matthias はクローン音声、Fabia は設計された AI 共同ホストです。
Brand design based on fabricperiodictable.com.
Microsoft Fabric のア���キテクチャ意思決定。匿名化された実際の顧客シナリオ、コストのリアリズム、反論を含む。Fabric Friday の録画に合わせた週刊エピソード。AIにより生成。
読み取り専用が守れないもの
Episode 36 | 2026-10-02
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: Fabricでワークスペースを作成します。クリック1つ。4つの境界線が生まれますが、あなたが選んだのはそのうち1つだけです。
[00:12] Matthias: セキュリティは分かりやすいですね。ほかに何が起きたんですか？
[00:14] Fabia: ワークスペースは容量に配置されました。これがコスト境界とリージョン境界を同時に決めています。ライフサイクルは、Gitを接続するまで保留です。
[00:18] Matthias: つまり……ワークスペースそのものが分割点なんですね。4つの境界線を、1つのオブジェクトが担っている。
[00:22] Fabia: ドキュメントでは「分割」という言葉を使っています。ワークスペースがデータレイクを個別のコンテナに分割する。分割された時点で、そのコンテナがすべてを引き受けます。
[00:27] Matthias: 今日はそこを掘り下げます。ワークスペースをロックダウンしたつもりで、実はできていない。そういうチームに何度も出会ってきたので。
[00:31] Fabia: まずビューアーの意味から整理しましょう。誰もが読み取り専用と捉えていますが、ドキュメントでは2つの別々の権限に分かれています。ビューアーはSQL 分析エンドポイント経由でテーブルをクエリできます。これがReadDataです。同じビューアー、同じテーブルでも、SparkやOneLake API経由ではアクセス拒否になります。こちらはReadAllで、ビューアーには付与されていません。
[00:44] Matthias: 同じバイト列なのに、経路が変わるだけで許可と拒否が分かれるんですか？
[00:46] Fabia: SQL 分析エンドポイントはゲートの役割を果たします。行レベルのセキュリティやオブジェクトレベルのルールが出口で適用される。SparkはParquetファイルを直接開くので、そのゲートを通りません。SQLの読み取り権限はフィルタされたビューを与え、Sparkの読み取り権限はファイルそのものを与えます。
[00:56] Matthias: 利用者がSparkを必要とするなら、ビューアーでは足りない。次のロールは—
[00:59] Fabia: —共同作成者です。書き込み権限が付いてきます。読み取りから書き換えへ、一気に飛んでしまう。
[01:02] Matthias: 落差が大きすぎますね。
[01:03] Fabia: その落差を埋めるために、OneLakeセキュリティが存在します。
[01:05] Matthias: 私なら、利用者にはSQL 分析エンドポイントを勧めます。これは判断の問題です。Sparkが必要だからと共同作成者を渡した瞬間、セキュリティ境界を利便性と引き換えにしてしまう。元に戻すのは簡単ではありません。
[01:12] Fabia: 動画では、2つ目のID——ビューアー——が同じSparkノートブックを実行して、Deltaログで403が返ります。
[01:16] Matthias: そこで管理者が共同作成者に昇格させると？
[01:17] Fabia: 同じノートブック、同じセル、同じテーブル。10行が返ってきます。
[01:19] Matthias: ロールを1つ変えただけで、壁が消えた。
[01:20] Fabia: コミュニティから質問が届いています。「チームに共同作成者を付与して、機密フォルダをOneLakeセキュリティで制限しました。なぜ適用されないのですか？」
[01:26] Matthias: この設計、アーキテクチャレビューの半分くらいで見かけます。図面上ではすごく合理的に見えるんですよね。
[01:29] Fabia: ドキュメントは明確に書いています。管理者、メンバー、共同作成者のロールはOneLakeへの書き込み権限を自動的に付与し、OneLakeセキュリティの読み取り権限を上書きします。
[01:35] Matthias: つまりOneLakeセキュリティが効くのはビューアーだけということですか？
[01:37] Fabia: OneLakeセキュリティのロールは許可だけです。拒否はありません。ビューアーは暗闇からスタートします。すべてのフォルダが非表示の状態です。ロールが必要なフォルダだけを見えるようにしていく。共同作成者はすでにすべてへの書き込み権限を持っています。許可しかできないシステムでは、取り消すものがありません。
[01:48] Matthias: ということは、みんなが真っ先に思いつく設計——共同作成者に機密フォルダの制限を組み合わせる——これはシステムが表現できない形なんですね。
[01:52] Fabia: 逆にしてください。既定をビューアーにして、OneLakeセキュリティで必要なフォルダだけを上方向に許可する。LakehouseにはDefaultReaderロールが付属していて、編集できます。
[01:58] Matthias: どのレビューでも私はこの方針を推します。まずビューアー、上方向に許可。絶対に成立しない構成のデバッグに何週間も費やしたチームを見てきました。ドキュメントにはっきり書いてあります。書き込み権限を読み取り制限で絞ることはできません。
[02:06] Fabia: 動画のデモがそれを証明しています。共同作成者のIDでは機密フォルダが見えます。ビューアーに変更すると、許可されたフォルダだけが開きます。
[02:11] Matthias: 権限を取り上げて、初めてセキュリティが機能し始める。
[02:13] Fabia: ドキュメントに、これをさらに深刻にする事実が書かれています。
[02:15] Matthias: どう深刻になるんですか？
[02:15] Fabia: Power BIのセマンティック モデルにおける行レベルのセキュリティは、ユーザーがビューアーロールを持つ場合にのみ適用されます。
[02:20] Matthias: え、共同作成者に昇格させたら——レポートを直してもらうだけのつもりで——
[02:22] Fabia: その人に適用されていた行フィルタが無効になります。何の通知もなく。
[02:24] Matthias: ロール変更をセキュリティイベントとしてレビューする人はいません。チケットが通って、誰もフラグを立てない。
[02:28] Fabia: チケットには「編集アクセスを付与」と書いてあります。「行レベルのセキュリティを解除」とは書いていません。
[02:31] Matthias: これは本当に眠れなくなる問題です。Sparkの403はすぐ発覚します。何かが壊れて、チケットが上がる。でも行レベルのセキュリティの問題は無音です。データは露出し、レポートは正常に見え、エラーも出ない。何か月もそのまま運用される可能性があります。
[02:40] Fabia: セキュリティは1つ目の境界です。コスト境界は別の問題を提起します。誰があなたのワークスペースを別の容量に移動できるのか。
[02:44] Matthias: それは何によって決まりますか？
[02:45] Fabia: SKUの種類です。PまたはEMの容量管理者は、ワークスペースを名前で検索して取得できます。ワークスペースロールは不要です。FまたはAの場合、管理者はそのワークスペースのワークスペース管理者でもある必要があります。
[02:52] Matthias: PremiumからFabricへの移行中は、両方のルールが同時に有効になるんですか？
[02:54] Fabia: しかも古い方が緩いんです。PとEMはFabricの権限モデルより前から存在しています。
[02:57] Matthias: これは動画ではデモしていません。Premium容量と、テナントにいない2人目の管理者が必要になるので。
[03:01] Fabia: 結論としては、自社環境にどの容量タイプが残っているか確認してください。
[03:03] Matthias: それに移動もただではないですよね。ジョブがキャンセルされて—
[03:05] Fabia: —リージョンをまたぐ場合、残るのは7種類のアイテムだけです。それ以外は先に削除が必要です。再作成できるまで最大1時間かかります。
[03:09] Matthias: リージョンをまたぐ再割り当ては、バックアップ手順と再構築時間を含めた移行プロジェクトとして扱ってください。
[03:13] Matthias: さて、ここでこのエピソード自身のアドバイスに反論します。ビューアー既定は正しい出発点で、それは間違いありません。でも、コスト圧力のある8人のチームで全員がノートブックを作っている場合、フォルダごとにOneLakeセキュリティのロールを管理するのは継続的なガバナンス業務です。誰もメンテナンスしなければ、ロールはずれていきます。
[03:24] Fabia: それはもっともです。チーム全員が書き込みを必要としていて、ワークスペースに機密データがないなら、全員を共同作成者にする方が正直でシンプルです。
[03:29] Matthias: 危険なのは、全員が見るべきではないデータがあるワークスペースで「全員共同作成者」と決めてしまうケースです。
[03:32] Fabia: ドキュメントは別の方法を示しています。ワークスペースを分割する。機密データはビューアーベースのセキュリティで保護された専用ワークスペースに置く。開発者は開発用ワークスペースで共同作成者になる。実際に必要な境界線で分割してください。
[03:40] Fabia: 知っておくべき上限があります。ワークスペースあたり1000アイテムで、子アイテムも含まれます。LakehouseにはSQL 分析エンドポイントが付随します。
[03:45] Matthias: 以前は既定のセマンティック モデルも付いてきませんでしたか？
[03:47] Fabia: 既定のセマンティック モデルの自動作成は2025年9月に廃止されました。現在Lakehouseは2アイテムです。3と書いてある情報は古いです。
[03:52] Matthias: それと、権限変更は次回サインインまで反映されません。オフボーディングでは、この隙間を計画に組み込む必要があります。
[03:56] Fabia: アクセスの取り消しは、付与より遅いんです。
[03:57] Matthias: 今日の要点はこうです。すべてのワークスペースはデータレイクを切り分ける断面であり、断面には結果が伴います。セキュリティ、コスト、リージョン、ライフサイクル。選んだかどうかに関わらず、4つすべてを決めているんです。
[04:04] Fabia: クエリパターンを見れば分かります。ビューアーとOneLakeセキュリティで足りるのか、ワークスペースの分割が必要なのか。
[04:08] Matthias: そして、誰かに先を越される前に容量タイプを確認してください。
[04:10] Fabia: 今この瞬間も、誰かが同僚をレポート修正のために共同作成者に昇格させています。そして行フィルタが静かに退いている。
[04:15] Matthias: 今の話でヒヤッとした方は、LinkedInでDMしてください。Matthias Fallandで見つかります。
[04:18] Fabia: また来週の金曜日に。
[04:19] Matthias: ロールの割り当てを確認してからですよ。
---
End of episode. ~04:20 estimated.