🔐 STEP 44: Power BIのセキュリティ設計
データを守り、適切なアクセス制御を実現しよう！
📋 このステップで学ぶこと
- Power BIのセキュリティ階層と多層防御
- 行レベルセキュリティ（RLS）の設定
- ロールの作成とユーザー割り当て
- 動的セキュリティ（USERNAME関数）
- オブジェクトレベルセキュリティ（OLS）
- セキュリティのテストと監査
ゴール：適切なアクセス制御を設計し、データを安全に管理できるようになる
🔐 1. Power BIのセキュリティ階層
多層防御でデータを守る
Power BIでは、複数の層でセキュリティを設定します。ワークスペース、レポート、データセット、行、列それぞれのレベルで適切なアクセス制御を行い、データを安全に管理しましょう。
📊 7つのセキュリティレベル
| レベル | 対象 | 主な設定内容 |
|---|---|---|
| 1. テナント | 組織全体 | 外部共有の許可/禁止、カスタムビジュアルの制限 |
| 2. ワークスペース | ワークスペース単位 | 管理者、メンバー、共同作成者、閲覧者の権限 |
| 3. レポート | 個別レポート | 閲覧権限、エクスポート許可、再共有の許可 |
| 4. データセット | データセット単位 | ビルド権限、読み取り権限、再共有権限 |
| 5. 行レベル（RLS） | データの行 | ユーザーごとに見えるデータを制限 ⭐最重要 |
| 6. 列レベル（OLS） | テーブル・列 | 機密列の非表示（Premium専用） |
| 7. データソース | 接続先 | ゲートウェイ認証、DB権限、接続文字列の暗号化 |
💡 セキュリティ設計の原則
| 原則 | 推奨 | 避けるべき |
|---|---|---|
| 最小権限 | 必要最小限の権限のみ付与、デフォルトは「閲覧のみ」 | 全員に管理者権限 |
| 職務分離 | 開発者と利用者を分ける、承認プロセスの導入 | 1人ですべてを担当 |
| 深層防御 | 複数の層でセキュリティ設定、RLS+ワークスペース権限 | 1つのセキュリティに依存 |
| 定期レビュー | 四半期ごとに権限見直し、退職者のアクセス削除 | 一度設定したら放置 |
| 監査とログ | アクセスログの確認、異常なアクティビティの検知 | ログを見ない |
⚠️ セキュリティリスクと対策
| リスク | 影響 | 対策 |
|---|---|---|
| 不適切な共有 | 機密情報漏洩 | RLS設定、共有制限、再共有禁止 |
| 過剰な権限 | データ改ざん | 最小権限の原則、閲覧者ロール基本 |
| 外部公開 | パブリック流出 | 「Webに公開」機能の禁止 |
| 認証情報漏洩 | 不正アクセス | MFA有効化、定期的なパスワード変更 |
| 退職者のアクセス | 情報持ち出し | オフボーディング手順の徹底 |
🛡️ 2. 行レベルセキュリティ（RLS）
RLSとは
同じレポートでも、ユーザーによって表示されるデータが異なるようにする機能です。営業担当者Aさんは自分の顧客だけ、Bさんは自分の顧客だけが見える、といった制御ができます。
✅ RLSが必要なシーン
| データ種類 | アクセス制御の例 | 目的 |
|---|---|---|
| 営業データ | 担当者→自分の顧客、マネージャー→チーム全体、役員→全社 | 営業秘密の保護 |
| 人事データ | 一般社員→自分のみ、部門長→自部門、人事部→全社員 | プライバシー保護 |
| 財務データ | 店舗長→自店舗、エリアMgr→担当エリア、CFO→全社 | 経営情報の管理 |
| 顧客データ | サポート→担当顧客、地域担当→地域内、マーケ→全顧客 | 個人情報保護 |
| プロジェクト | メンバー→参加PJのみ、PM→担当PJ全体、PMO→全PJ | 機密性保持 |
📊 RLSの設定手順（Power BI Desktop）
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | 「モデリング」タブをクリック | リボンメニューから選択 |
| 2 | 「ロールの管理」をクリック | ロール管理画面が開く |
| 3 | 「作成」ボタンをクリック | 新しいロールを作成 |
| 4 | ロール名を入力（例：営業担当者） | 分かりやすい名前を付ける |
| 5 | フィルターを適用するテーブルを選択 | 例：売上テーブル |
| 6 | DAXフィルター式を入力 | 下記参照 |
| 7 | 「保存」をクリック | ロールが作成される |
💡 基本的なRLSフィルター式（入力するDAX）
[担当者] = USERPRINCIPALNAME()
意味：「担当者」列の値が、ログインユーザーのメールアドレスと一致する行のみ表示
※モバイルでは横スクロールできます
📊 ユーザーへのロール割り当て（Service側）
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | Power BI Serviceでワークスペースを開く | レポートを公開済みのワークスペース |
| 2 | データセット（🗄️）の「…」メニュー | レポートではなくデータセットを選択 |
| 3 | 「セキュリティ」を選択 | セキュリティ設定画面が開く |
| 4 | ロールを選択（例：営業担当者） | Desktopで作成したロールが表示 |
| 5 | メンバー欄にメールアドレスを入力 | Enterキーで追加、複数可能 |
| 6 | 「保存」をクリック | 割り当て完了 |
📊 動的セキュリティ（ユーザー権限テーブル）
より柔軟な制御が可能です。1ユーザーが複数店舗を担当するケースに対応できます。
ユーザー権限テーブルの例：
| メールアドレス | 店舗コード | 説明 |
|---|---|---|
| sato@example.com | S001 | 佐藤さん：店舗1担当 |
| sato@example.com | S002 | 佐藤さん：店舗2も担当（複数） |
| tanaka@example.com | S003 | 田中さん：店舗3担当 |
| manager@example.com | * | マネージャー：全店舗（ワイルドカード） |
💡 動的RLSのフィルター式（入力するDAX）
[メールアドレス] = USERPRINCIPALNAME()
適用テーブル：ユーザー権限テーブル
動作：リレーションシップ経由で売上テーブルもフィルターされる
👥 3. ロールの設計パターン
組織階層に基づくロール設計
組織の階層構造に合わせて、段階的なデータアクセス権限を設計します。
✅ 階層型ロールの設計例
| ロール名 | フィルター条件 | 対象ユーザー |
|---|---|---|
| 営業担当者 | [担当者] = USERPRINCIPALNAME() | 個々の営業担当 |
| 営業所長 | [営業所] = 階層テーブル経由 | 営業所全体を管理 |
| 部長 | [部門] = 階層テーブル経由 | 部門全体を管理 |
| 本部長・役員 | なし（全データ閲覧） | 経営層 |
📊 階層テーブルの例
| 部門 | 営業所 | 所長メール | 部長メール |
|---|---|---|---|
| 東日本営業部 | 東京営業所 | tokyo@ex.com | east@ex.com |
| 東日本営業部 | 横浜営業所 | yokohama@ex.com | east@ex.com |
| 西日本営業部 | 大阪営業所 | osaka@ex.com | west@ex.com |
| 西日本営業部 | 福岡営業所 | fukuoka@ex.com | west@ex.com |
📊 複数条件のフィルター式（入力するDAX）
時期と地域の組み合わせ：
[日付] >= DATE(2025, 10, 1)
&& [日付] < DATE(2026, 1, 1)
&& [地域] IN {"東京", "神奈川", "埼玉"}
機密レベルによる制限：
// 一般社員ロール
[機密度] IN {"Public", "Internal"}
// 管理職ロール
[機密度] IN {"Public", "Internal", "Confidential"}
※モバイルでは横スクロールできます
💡 除外パターンのフィルター式（入力するDAX）
| シナリオ | フィルター式 |
|---|---|
| テストデータ除外 | [環境] <> "Test" |
| VIP顧客除外 | NOT([顧客ランク] = "VIP") |
| 確定データのみ | [ステータス] = "確定" |
🧪 4. セキュリティのテスト
公開前の確認が重要
RLSを設定したら、必ず公開前にテストしましょう。意図したデータだけが表示されることを確認します。
📊 Desktop内でのテスト手順
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | 「モデリング」タブをクリック | リボンメニューから |
| 2 | 「ロールとして表示」をクリック | テストモードが開く |
| 3 | テストしたいロールにチェック | 例：営業担当者 |
| 4 | 「その他のユーザー」にチェック | テスト用メールを入力するため |
| 5 | メールアドレスを入力 | 例：sato@example.com |
| 6 | 「OK」をクリック | フィルターが適用される |
| 7 | レポートでデータを確認 | 期待通りフィルターされているか |
| 8 | 「表示の停止」で元に戻る | テスト終了 |
✅ テストチェックリスト
| カテゴリ | 確認項目 |
|---|---|
| 基本フィルター | 各ロールで正しいデータが表示される、他ユーザーのデータが見えない |
| 集計値 | SUM、AVG等の集計が正しい、フィルター後の合計が一致 |
| リレーションシップ | 関連テーブルもフィルターされる、ルックアップが機能する |
| 計算メジャー | DAXメジャーが正しく動作、タイムインテリジェンスが機能 |
| ビジュアル | スライサーが動作、クロスフィルターが機能、ドリルダウンが動作 |
| エクスポート | Excelエクスポートで正しいデータ、基になるデータが保護されている |
| エッジケース | データがゼロの場合、新規ユーザーの場合、ロール未割り当ての場合 |
⚠️ ロール未割り当てユーザーへの対策
| 問題 | 対策 |
|---|---|
| デフォルト動作 | ロールに割り当てられていないユーザーは全データが見える！ |
| 全員をロールに追加 | 漏れのない運用（管理コストは高い） |
| デフォルト制限ロール | フィルター「1 = 0」で何も表示されないロールを作成し全員追加 |
| ワークスペース制限 | データセットへのアクセス自体を制限（RLSと組み合わせ） |
🔍 5. オブジェクトレベルセキュリティ（OLS）
OLSとは
RLSは「行」を制限、OLSは「列やテーブル」を制限します。給与情報の列を一般社員から隠すなど、機密性の高い項目を保護できます。⚠️ Premium専用機能です。
📊 RLSとOLSの比較
| 項目 | RLS（行レベル） | OLS（列レベル） |
|---|---|---|
| 制限対象 | データの行 | テーブル・列 |
| 用途 | 担当データのみ表示 | 機密項目を隠す |
| ライセンス | Pro可能 | Premium必須 |
| 設定方法 | Desktop標準機能 | Tabular Editor（外部ツール） |
| 例 | 営業担当の顧客のみ表示 | 給与列を非表示 |
📊 OLSの活用例（人事データ）
| 列名 | 一般社員 | 部門長 | 人事部 |
|---|---|---|---|
| 社員番号 | ✅ 表示 | ✅ 表示 | ✅ 表示 |
| 氏名 | ✅ 表示 | ✅ 表示 | ✅ 表示 |
| 部署 | ✅ 表示 | ✅ 表示 | ✅ 表示 |
| 給与 | ❌ 非表示（OLS） | ❌ 非表示（OLS） | ✅ 表示 |
| 評価 | ❌ 非表示（OLS） | ❌ 非表示（OLS） | ✅ 表示 |
💡 RLSとOLSの組み合わせ例
| ユーザー | RLS（行） | OLS（列） |
|---|---|---|
| 一般社員 | 自分の1行のみ | 給与・評価は非表示 |
| 部門長 | 自部門の全社員 | 給与・評価は非表示 |
| 人事部 | 全社員（制限なし） | すべて表示（制限なし） |
📊 6. 監査とコンプライアンス
監査ログの活用
Power BI管理ポータルから、誰がいつ何をしたかを確認できます。定期的なログ確認で不正アクセスを検知しましょう。
📊 監査ログで確認できる情報
| アクティビティ | 説明 |
|---|---|
| ViewReport | レポート閲覧 |
| ExportReport | レポートのエクスポート |
| ShareReport | レポートの共有 |
| CreateReport | 新規レポート作成 |
| UpdateDataset | データセット更新 |
| DeleteReport | レポート削除 |
✅ 定期レビュースケジュール
| 頻度 | チェック内容 |
|---|---|
| 週次 | 異常なアクティビティ（深夜アクセス、大量エクスポート）の検知 |
| 月次 | アクセス統計の確認、不要なアクセス権限の削除 |
| 四半期 | 権限の適切性レビュー、退職者のアクセス確認 |
| 年次 | セキュリティポリシー見直し、コンプライアンス監査 |
📊 コンプライアンス対応
| 規制 | Power BIでの対応 |
|---|---|
| GDPR | 個人データの最小化、RLSでアクセス制御、データ保持期間管理 |
| 個人情報保護法 | 適切なアクセス制御、漏洩防止措置、安全管理措置 |
| SOX法 | 職務分離、アクセスログ保管、変更管理プロセス |
| 業界固有 | 医療（HIPAA）、金融（金商法）、公共（情報公開法） |
📝 STEP 44 のまとめ
✅ このステップで学んだこと
- セキュリティ階層：7つのレベルで多層防御
- RLS：ユーザーごとに見えるデータを制限（最重要）
- ロール設計：組織階層に応じた柔軟な制御
- テスト：「ロールとして表示」で公開前確認
- OLS：機密列の非表示（Premium専用）
- 監査：アクティビティログで不正検知
💡 最重要ポイント
セキュリティは「後から追加」ではなく「最初から設計」すべきです！
データ漏洩は企業の信頼を失墜させる重大インシデント。RLSを適切に設定し、定期的な監査とレビューで、データを確実に守りましょう。
特に行レベルセキュリティ（RLS）は、Power BIセキュリティの要です。必ず設定してください！
📝 実践演習
演習 1
基礎
営業データを使って、基本的なRLSを設定してください。「営業担当者」ロールを作成し、USERPRINCIPALNAME()関数を使って、ログインユーザーの担当データのみが表示されるようにしてください。
【基本的なRLS設定】
ステップ1：サンプルデータ準備
| 日付 | 商品 | 金額 | 担当者 |
|---|---|---|---|
| 2025/11/01 | 商品A | 50,000 | sato@example.com |
| 2025/11/02 | 商品B | 80,000 | sato@example.com |
| 2025/11/03 | 商品C | 60,000 | tanaka@example.com |
ステップ2：RLSロール作成
| 1 | 「モデリング」タブ→「ロールの管理」 |
| 2 | 「作成」をクリック |
| 3 | ロール名：営業担当者 |
| 4 | 売上テーブルを選択 |
フィルター式：
[担当者] = USERPRINCIPALNAME()
ステップ3：テスト
| 1 | 「ロールとして表示」をクリック |
| 2 | 「営業担当者」と「その他のユーザー」にチェック |
| 3 | メール：sato@example.com を入力 |
| 4 | 佐藤さんの2行のみ表示されることを確認 |
演習 2
応用
階層的なロールを設定してください。「営業担当者」ロール（自分のデータのみ）と「営業マネージャー」ロール（チーム全体のデータ）を作成し、適切にフィルター条件を設定してください。
【階層的RLS設計】
ステップ1：チーム管理テーブルを追加
| チーム | マネージャーメール |
|---|---|
| 東京チーム | manager_tokyo@ex.com |
| 大阪チーム | manager_osaka@ex.com |
ステップ2：リレーションシップ作成
売上データ[チーム] ←→ チーム管理[チーム]（両方向クロスフィルター）
ステップ3：ロール作成
| ロール名 | テーブル | フィルター式 |
|---|---|---|
| 営業担当者 | 売上データ | [担当者] = USERPRINCIPALNAME() |
| 営業マネージャー | チーム管理 | [マネージャーメール] = USERPRINCIPALNAME() |
| 役員 | - | なし（全データ閲覧） |
動作確認：
- sato@ex.com → 佐藤さんのデータのみ
- manager_tokyo@ex.com → 東京チーム全員のデータ
- ceo@ex.com → 全データ
演習 3
発展
動的セキュリティを実装してください。ユーザー権限テーブルを作成し、1人のユーザーが複数の店舗を担当できる柔軟なRLSを設計してください。ワイルドカード（全データアクセス）にも対応してください。
【高度な動的RLS】
ステップ1：ユーザー権限テーブル作成
| メールアドレス | 店舗コード | 説明 |
|---|---|---|
| sato@ex.com | TK001 | 佐藤：店舗1担当 |
| sato@ex.com | TK002 | 佐藤：店舗2も担当 |
| tanaka@ex.com | OS001 | 田中：大阪店舗担当 |
| manager@ex.com | * | マネージャー：全店舗 |
ステップ2：リレーションシップ作成
売上データ[店舗コード] ←→ ユーザー権限[店舗コード]（多対多、両方向）
ステップ3：RLSフィルター式
[メールアドレス] = USERPRINCIPALNAME()
適用テーブル：ユーザー権限テーブル
ステップ4：ワイルドカード対応（計算テーブル）
「*」を持つユーザーを全店舗に展開する計算テーブルを作成
動作確認：
| ユーザー | 権限設定 | 表示店舗 |
|---|---|---|
| sato@ex.com | TK001, TK002 | 東京の2店舗 |
| tanaka@ex.com | OS001 | 大阪1店舗 |
| manager@ex.com | *（ワイルドカード） | 全店舗 |
メリット：
- 1ユーザーが複数店舗を担当可能
- Excelで権限を簡単管理
- 権限変更はデータ更新だけ（レポート再公開不要）
❓ よくある質問
Q1: RLSを設定したのにすべてのデータが見えます。なぜですか？
ワークスペースの管理者・メンバーはRLSが適用されません。
RLSが適用されないユーザー：
RLSが適用されないユーザー：
- ワークスペースの管理者
- ワークスペースのメンバー
- ワークスペースの共同作成者
- ワークスペースの閲覧者
- レポート/データセットを直接共有されたユーザー
- アプリの配布先ユーザー
Q2: USERPRINCIPALNAME()が機能しません。空白が返されます。
よくある原因と対処法：
原因1：ゲストユーザー
外部ユーザーは異なる形式（user_example.com#EXT#@contoso.onmicrosoft.com）になります。データにゲスト形式のメールを格納してください。
原因2：Power BI Embedded環境
埋め込みではUSERNAME()を使用してください。USERPRINCIPALNAME()は空白になります。
原因3：Desktop内のテスト
「その他のユーザー」のチェック忘れやメールアドレス未入力が原因です。
原因1：ゲストユーザー
外部ユーザーは異なる形式（user_example.com#EXT#@contoso.onmicrosoft.com）になります。データにゲスト形式のメールを格納してください。
原因2：Power BI Embedded環境
埋め込みではUSERNAME()を使用してください。USERPRINCIPALNAME()は空白になります。
原因3：Desktop内のテスト
「その他のユーザー」のチェック忘れやメールアドレス未入力が原因です。
Q3: RLSを設定するとパフォーマンスが悪化しました。
最適化テクニック：
シンプルなフィルター式：複雑なDAXは避け、計算テーブルを事前作成
データモデルの最適化：リレーションシップを適切に設定、不要な列を削除
ユーザー権限テーブルの設計：行数を最小限に、多対多リレーションを避ける
パフォーマンスアナライザーでDAXクエリ時間を確認し、RLS有無で比較してください。
シンプルなフィルター式：複雑なDAXは避け、計算テーブルを事前作成
データモデルの最適化：リレーションシップを適切に設定、不要な列を削除
ユーザー権限テーブルの設計：行数を最小限に、多対多リレーションを避ける
パフォーマンスアナライザーでDAXクエリ時間を確認し、RLS有無で比較してください。
Q4: ロールを複数割り当てるとどうなりますか？
OR条件（和集合）で動作します。
例：ユーザーAに2つのロールを割り当て
- ロール1：[地域] = "東京"
- ロール2：[地域] = "大阪"
結果：東京 OR 大阪のデータが表示される（両地域が見える）
推奨設計：1ユーザー1ロールが基本。複数担当は動的RLSで対応してください。
例：ユーザーAに2つのロールを割り当て
- ロール1：[地域] = "東京"
- ロール2：[地域] = "大阪"
結果：東京 OR 大阪のデータが表示される（両地域が見える）
推奨設計：1ユーザー1ロールが基本。複数担当は動的RLSで対応してください。
Q5: 機密データを完全に隠すにはどうすればいいですか？
多層防御で対応します：
レベル1（RLS）：行レベルでデータを制限
レベル2（OLS）：給与や評価など機密列を非表示（Premium）
レベル3（レポート）：エクスポート禁止、再共有禁止
レベル4（ワークスペース）：閲覧者ロールのみ
レベル5（データソース）：機密列除外ビューをPower BIに接続
複数のセキュリティ層を組み合わせることで、万全の対策になります。
レベル1（RLS）：行レベルでデータを制限
レベル2（OLS）：給与や評価など機密列を非表示（Premium）
レベル3（レポート）：エクスポート禁止、再共有禁止
レベル4（ワークスペース）：閲覧者ロールのみ
レベル5（データソース）：機密列除外ビューをPower BIに接続
複数のセキュリティ層を組み合わせることで、万全の対策になります。
学習メモ
BIツール入門 - Step 44
📋 過去のメモ一覧
▼