権限モデル
Microsoft Fabric には、組織内のデータへのアクセスを制御できる柔軟なアクセス許可モデルがあります。 この記事では、Fabric のさまざまな種類のアクセス許可と、それらが連携して組織内のデータへのアクセスを制御する方法について説明します。
ワークスペースは、Fabric で項目をグループ化するための論理エンティティです。 ワークスペース ロールは、ワークスペースのアクセス許可を定義します。 項目は 1 つのワークスペースに保存されますが、Fabric 全体で他のユーザーと共有できます。 Fabric アイテムを共有する場合は、アイテムを共有するユーザーに付与するアクセス許可を決定できます。 Power BI レポートなどの特定の項目では、データをさらに細かく制御できます。 アクセス許可に応じて、レポートを表示するユーザーが保持しているデータの一部のみを表示するようにレポートを設定できます。
ワークスペースのロール
ワークスペース ロールは、ワークスペースとその中のコンテンツへのアクセスを制御するために使用されます。 Fabric 管理者は、個々のユーザーまたはグループにワークスペース ロールを割り当てることができます。 ワークスペースロールは特定のワークスペースに限定され、他のワークスペース、ワークスペースが存在する容量、またはテナントには適用されません。
4 つのワークスペース ロールがあり、ワークスペース内のすべてのアイテムに適用されます。 これらのロールを持たないユーザーは、ワークスペースにアクセスできません。 これらのロールを次に示します。
ビューアー - ワークスペース内のすべてのコンテンツを表示できますが、変更することはできません。
共同作成者 - ワークスペース内のすべてのコンテンツを表示および変更できます。
メンバー - ワークスペース内のすべてのコンテンツを表示、変更、共有できます。
管理 - アクセス許可の管理を含め、ワークスペース内のすべてのコンテンツを表示、変更、共有、管理できます。
次の表は、各ロールが持つ機能の小さなセットを示しています。 詳細な一覧については、Microsoft Fabric ワークスペースロールに関する記事を参照してください。
| 機能 | 管理者 | メンバー | Contributor | ビューアー |
|---|---|---|---|---|
| ワークスペースを削除する | ✅ | ❌ | ❌ | ❌ |
| [管理者の追加] | ✅ | ❌ | ❌ | ❌ |
| メンバーを追加する | ✅ | ✅ | ❌ | ❌ |
| データを書き込む | ✅ | ✅ | ✅ | ❌ |
| 項目の作成 | ✅ | ✅ | ✅ | ❌ |
| データの読み取り | ✅ | ✅ | ✅ | ✅ |
アイテムのアクセス許可
アイテムのアクセス許可は、ワークスペース内の個々の Fabric アイテムへのアクセスを制御するために使用されます。 アイテムのアクセス許可は特定のアイテムに限定され、他のアイテムには適用されません。 アイテムのアクセス許可を使用して、ワークスペース内の個々のアイテムを表示、変更、管理できるユーザーを制御します。 アイテムのアクセス許可を使用して、ユーザーがアクセス権を持たないワークスペース内の 1 つのアイテムへのアクセス権をユーザーに付与できます。
アイテムをユーザーまたはグループと共有する場合は、アイテムのアクセス許可を構成できます。 アイテムを共有すると、デフォルトでそのアイテムの読み取りアクセス許可がユーザーに付与されます。 読み取り権限により、ユーザーはそのアイテムのメタデータを表示し、それに関連付けられているすべてのレポートを表示できます。 ただし、読み取りアクセス許可では、ユーザーは SQL または OneLake の基になるデータにアクセスできません。
Fabric アイテムによってアクセス許可が異なります。 各項目のアクセス許可の詳細については、以下を参照してください。
コンピューティングのアクセス許可
アクセス許可は、特に SQL 分析エンドポイントまたはセマンティック モデルを使用して、Fabric の特定のコンピューティング エンジン内で設定することもできます。 コンピューティング エンジンのアクセス許可により、テーブルレベルや行レベルのセキュリティなど、より詳細なデータ アクセス制御が可能になります。
SQL 分析エンドポイント - SQL 分析エンドポイントは、OneLake のテーブルへの直接 SQL アクセスを提供し、SQL コマンドを使用してセキュリティをネイティブに構成できます。 これらのアクセス許可は、SQL を介して行われたクエリにのみ適用されます。
セマンティック モデル - セマンティック モデルを使用すると、DAX を使用してセキュリティを定義できます。 DAX を使用して定義された制限は、セマンティック モデルまたはセマンティック モデルに基づいて構築された Power BI レポートを使用してクエリを実行するユーザーに適用されます。
詳細については、次の記事を参照してください。
OneLake のアクセス許可 (データ アクセス ロール)
OneLake には、OneLake データ アクセス ロールを通じて OneLake 内のファイルとフォルダーへのアクセスを管理するための独自のアクセス許可があります。OneLake データ アクセス ロールを使用すると、ユーザーはレイクハウス内にカスタム ロールを作成し、OneLake にアクセスするときに指定されたフォルダーにのみ読み取りアクセス許可を付与できます。 OneLake ロールごとに、ユーザーはユーザー、セキュリティ グループを割り当てたり、ワークスペース ロールに基づいて自動割り当てを付与したりできます。
OneLake データ アクセス制御モデルの詳細をご確認の上、攻略ガイドをご覧ください。
演算の順序
ファブリックには 3 つの異なるセキュリティ レベルがあります。 データにアクセスするには、ユーザーには、各レベルでアクセス権が必要です。 各レベルは順番に評価され、ユーザーがアクセス権を持っているかどうかが判断されます。 Microsoft Information Protection ポリシーなどのセキュリティ規則は、特定のレベルで評価され、アクセスを許可または禁止します。 ファブリック セキュリティを評価する際の操作順序は次のとおりです。
- Entra 認証: ユーザーが Microsoft Entra テナントに対して認証できるかどうかをチェックします。
- ファブリック アクセス: ユーザーが Microsoft ファブリックにアクセスできるかどうかをチェックします。
- データ セキュリティ: ユーザーがテーブルまたはファイルに対し、要求されたアクションを実行できるかどうかをチェックします。
例
このセクションでは、Fabric でアクセス許可を設定する方法の 2 つの例を示します。
例 1: チームのアクセス許可の設定
Wingtip Toys は、組織全体に 1 つのテナントと 3 つの容量を設定します。 各容量は異なるリージョンを表します。 Wingtip Toys は、米国、ヨーロッパ、アジアで事業を展開しています。 各容量には、営業部門を含む組織内の各部門のワークスペースがあります。
営業部門には、マネージャー、営業チーム リーダー、および営業チーム メンバーがあります。 Wingtip Toys では、組織全体に 1 人のアナリストも採用しています。
次の表に、営業部門の各ロールの要件と、それらを有効にするための権限の設定方法を示します。
| ロール | 要件 | セットアップ |
|---|---|---|
| 管理者 | 組織全体の営業部門のすべてのコンテンツを表示および変更する | 組織内のすべての販売ワークスペースのメンバー ロール |
| チーム リーダー | 特定のリージョンの営業部門のすべてのコンテンツを表示および変更する | リージョン内の販売ワークスペースの メンバー ロール |
| 営業チーム メンバー | ||
| アナリスト | 組織全体の営業部門のすべてのコンテンツを表示する | 組織内のすべての販売ワークスペースの閲覧者 ロール |
Wingtip には、販売メンバーごとの売上収入を一覧表示する四半期ごとのレポートもあります。 このレポートは、財務ワークスペースに保存されます。 行レベルのセキュリティを使用することで、各販売メンバーが自分の販売数値のみを表示できるようにレポートが設定されます。 チーム リーダーは、自分の地域のすべての販売メンバーの売上数値を確認でき、営業マネージャーは組織内のすべての販売メンバーの売上数値を確認できます。
例 2: ワークスペースと項目のアクセス許可
アイテムを共有したり、そのアクセス許可を変更したりしても、ワークスペース ロールは変更されません。 このセクションの例では、ワークスペースとアイテムのアクセス許可がどのように相互作用するかを示します。
Veronica と Marta は連動します。 Veronica は、Marta と共有したいレポートの所有者です。 Veronica が Marta とレポートを共有している場合、Marta は自分が持っているワークスペースの役割に関係なく、レポートにアクセスできるようになります。
たとえば、Marta には、レポートが格納されているワークスペースにビューアー ロールがあるとします。 Veronica が Marta の項目のアクセス許可をレポートから削除すると、Marta は引き続きワークスペースでレポートを表示できます。 Marta は、ワークスペースからレポートを開き、その内容を表示することもできます。 これは、Marta がワークスペースに対するビューのアクセス許可を持っているためです。
Veronica が Marta にレポートを表示させたくない場合、マルタの項目のアクセス許可をレポートから削除するだけでは不十分です。 Veronica では、ワークスペースから Marta のビューアーのアクセス許可を削除する必要もあります。 ワークスペース ビューアーのアクセス許可がないと、ワークスペースにアクセスできない Marta はレポートが存在することを確認できません。 Marta はレポートへのアクセス権がないため、レポートへのリンクを使用することもできません。
Marta はワークスペースビューアーの役割を持っていないので、Veronica が再びレポートを共有することを決定した場合、マルタはワークスペースにアクセスすることなく、Veronica 共有のリンクを使用してレポートを表示できるようになります。
例 3: Power BI アプリのアクセス許可
Power BI レポートを共有するとき、多くの場合、ユーザーは、受信者がレポートにのみアクセスでき、ワークスペース内のアイテムにはアクセスできないようにします。 このために、Power BI アプリを使用したり、レポートをユーザーと直接共有したりできます。
さらに、行レベルのセキュリティ (RLS) を使用してデータへの閲覧者のアクセスを制限し、RLS を使用すると、データの特定の部分にアクセス可能なロールを作成し、ユーザーの ID がアクセスできるもののみを返す結果を制限できます。
これは、データがセマンティック モデルにインポートされて、受信者が、アプリの一部としてこれにアクセスできるため、インポート モデルを使用する場合に正常に機能します。 DirectLake を使用すると、レポートは、レイクハウスから直接データを読み取り、レポート受信者は、レイク内のこれらのファイルにアクセスできる必要があります。 これはさまざまな方法で実行できます。
ReadDataレイクハウスに直接にアクセス許可を与えます。- データ ソースの資格情報を、シングル サインオン (SSO) から、レイク内のファイルにアクセスできる固定 ID に切り替えます。
RLS は、セマンティック モデルで定義されているため、最初にデータが読み取られ、次に、行がフィルター処理されます。
レポートが構築される SQL 分析エンドポイント内でセキュリティが定義されている場合、クエリは自動的に DirectQuery モードにフォールバックします。 このデフォルトのフォールバック動作が不要な場合は、元のレイクハウスのテーブルへのショートカットを使用して、新しいレイクハウスを作成し、新しいレイクハウスの SQL で、 RLS または OLS を定義しないようにすることができます。