STEP 48：セキュリティとアクセス管理

ホーム > BIツール入門 > STEP 48

🔐 STEP 48: セキュリティとアクセス管理

データを守りながら、必要な人に必要な情報を届けよう！

📋 このステップで学ぶこと

  • BIツールにおけるセキュリティの重要性
  • ユーザー権限設定の基本
  • 行レベルセキュリティ（RLS）の実装
  • コンテンツの共有と公開設定
  • コンプライアンス対応
  • 監査ログの活用

ゴール：適切なセキュリティ設計で、安全かつ効率的なデータ共有環境を構築できるようになる

🔐 1. BIツールにおけるセキュリティの重要性

なぜセキュリティが重要なのか

BIツールは企業の重要なデータを扱います。適切なセキュリティ設計がなければ、情報漏洩や不正アクセスのリスクが高まります。「見せたい人に見せたい情報だけ」を届けることが、BIセキュリティの基本です。

⚠️ セキュリティ事故の影響
リスク 具体例 影響
情報漏洩 顧客データ、売上情報の流出 信用失墜、損害賠償
不正アクセス 権限外のデータ閲覧 コンプライアンス違反
データ改ざん レポートの不正編集 意思決定の誤り
内部不正 退職者によるデータ持ち出し 競合への情報流出
📊 セキュリティの3つの柱 
【BIセキュリティの3つの柱】

1. 認証（Authentication）
   └─ 「誰がアクセスしているか」を確認
   ├─ ユーザーID/パスワード
   ├─ シングルサインオン（SSO）
   ├─ 多要素認証（MFA）
   └─ Active Directory連携

2. 認可（Authorization）
   └─ 「何にアクセスできるか」を制御
   ├─ ロール（役割）ベースの権限
   ├─ コンテンツレベルの権限
   ├─ 行レベルセキュリティ（RLS）
   └─ 列レベルセキュリティ

3. 監査（Audit）
   └─ 「誰が何をしたか」を記録
   ├─ アクセスログ
   ├─ 操作履歴
   ├─ ダウンロード記録
   └─ 変更履歴
📊 TableauとPower BIのセキュリティ機能比較
機能 Tableau Power BI
認証 Tableau認証、AD、SAML、OpenID Azure AD、Microsoft 365
行レベルセキュリティ ユーザーフィルター、計算フィールド DAXによるRLS
権限レベル サイト、プロジェクト、ワークブック ワークスペース、アプリ、レポート
監査ログ 管理ビュー、監査ログ アクティビティログ、監査ログ
データ暗号化 転送中・保存時暗号化 転送中・保存時暗号化

👥 2. ユーザー権限設定の基本

権限設計の考え方

権限設計は「最小権限の原則」に基づいて行います。必要最小限の権限だけを付与し、業務に必要ない情報へのアクセスは制限しましょう。

💡 最小権限の原則

Principle of Least Privilege（PoLP）

ユーザーには、業務遂行に必要な最小限の権限のみを付与します。
「見せる必要がないものは見せない」がセキュリティの基本です。

📊 Tableauの権限体系 
【Tableau Serverの権限階層】

サイトレベル（最上位）
├─ サイト管理者
│  └─ サイト全体の管理権限
│
├─ プロジェクトレベル
│  ├─ プロジェクトリーダー
│  │  └─ プロジェクト内の管理権限
│  └─ パブリッシャー
│     └─ コンテンツの公開権限
│
└─ コンテンツレベル（最下位）
   ├─ ワークブック
   ├─ データソース
   └─ ビュー

【サイトロール一覧】

┌────────────────────────────────────────┐
│ ロール           │ 権限               │
├────────────────────────────────────────┤
│ サイト管理者     │ すべての管理機能   │
│ Creator          │ 作成・公開・閲覧   │
│ Explorer         │ 編集・閲覧         │
│ Viewer           │ 閲覧のみ           │
│ Unlicensed       │ アクセス不可       │
└────────────────────────────────────────┘

【権限設定手順】

ステップ1: プロジェクト作成
├─ コンテンツ > プロジェクト > 新しいプロジェクト
├─ 名前: 営業部ダッシュボード
└─ 説明: 営業部門専用

ステップ2: 権限設定
├─ プロジェクト > ・・・ > 権限
├─ グループ/ユーザーを追加
└─ 権限テンプレートを選択
   ├─ プロジェクトリーダー
   ├─ パブリッシャー
   ├─ インタラクター
   └─ ビューア

ステップ3: 権限のロック
├─ プロジェクト権限をロック
└─ 子コンテンツに継承
📊 Power BIの権限体系 
【Power BIの権限階層】

テナントレベル（最上位）
├─ Power BI管理者
│  └─ テナント全体の設定
│
├─ ワークスペースレベル
│  ├─ 管理者
│  ├─ メンバー
│  ├─ 共同作成者
│  └─ 閲覧者
│
└─ コンテンツレベル（最下位）
   ├─ レポート
   ├─ ダッシュボード
   └─ データセット

【ワークスペースロール一覧】

┌────────────────────────────────────────────┐
│ ロール     │ できること                    │
├────────────────────────────────────────────┤
│ 管理者     │ すべて + メンバー管理         │
│ メンバー   │ 作成・編集・削除・共有        │
│ 共同作成者 │ 作成・編集（削除・共有不可）  │
│ 閲覧者     │ 閲覧のみ                      │
└────────────────────────────────────────────┘

【権限設定手順】

ステップ1: ワークスペース作成
├─ ワークスペース > 新しいワークスペース
├─ 名前: 営業部レポート
└─ 説明: 営業部門専用ワークスペース

ステップ2: メンバー追加
├─ ワークスペース > アクセス
├─ メールアドレスまたはグループを入力
└─ ロールを選択
   ├─ 管理者
   ├─ メンバー
   ├─ 共同作成者
   └─ 閲覧者

ステップ3: コンテンツ共有
├─ レポート > 共有
├─ 相手を指定
└─ 権限を設定
   ├─ □ 受信者に再共有を許可
   ├─ □ 基になるデータセットの使用許可
   └─ □ レポートのコピー作成を許可
📊 典型的な権限設計パターン
役割 Tableau Power BI 権限内容
システム管理者 サイト管理者 Power BI管理者 全体設定、ユーザー管理
BI開発者 Creator メンバー レポート作成・公開
パワーユーザー Explorer 共同作成者 レポート編集・分析
一般ユーザー Viewer 閲覧者 閲覧・フィルター操作
経営層 Viewer 閲覧者 ダッシュボード閲覧

🔒 3. 行レベルセキュリティ（RLS）の実装

RLSとは

行レベルセキュリティ（Row-Level Security）は、同じレポートでもユーザーごとに表示されるデータを制限する機能です。例えば、営業担当者が自分の担当地域のデータだけを見られるようにできます。

📊 RLSのイメージ 
【同じレポートでも見えるデータが異なる】

売上レポート
┌──────────────────────────────────────────┐
│                                          │
│  [地域]  [売上]  [利益]                  │
│                                          │
└──────────────────────────────────────────┘

東京営業部の田中さんがアクセス:
┌──────────────────────────────────────────┐
│  東京    ¥100M   ¥20M                    │
│  （東京のデータのみ表示）                │
└──────────────────────────────────────────┘

大阪営業部の佐藤さんがアクセス:
┌──────────────────────────────────────────┐
│  大阪    ¥80M    ¥15M                    │
│  （大阪のデータのみ表示）                │
└──────────────────────────────────────────┘

営業本部長の鈴木さんがアクセス:
┌──────────────────────────────────────────┐
│  東京    ¥100M   ¥20M                    │
│  大阪    ¥80M    ¥15M                    │
│  名古屋  ¥60M    ¥10M                    │
│  （全地域のデータが表示）                │
└──────────────────────────────────────────┘
📊 Tableau でのRLS実装 
【方法1: ユーザーフィルター】

ステップ1: 権限テーブル作成
┌────────────────────────────────┐
│ ユーザー名  │ 地域             │
├────────────────────────────────┤
│ tanaka     │ 東京             │
│ sato       │ 大阪             │
│ suzuki     │ 東京,大阪,名古屋 │
└────────────────────────────────┘

ステップ2: データソースに結合
├─ 売上データと権限テーブルを結合
└─ 地域フィールドで結合

ステップ3: ユーザーフィルター作成
├─ サーバー > ユーザーフィルターの作成
├─ フィールド: 地域
├─ ユーザーごとに値を選択
└─ すべてのユーザーに適用

─────────────────────────────

【方法2: 計算フィールド（推奨）】

ステップ1: 権限テーブル作成（同上）

ステップ2: 計算フィールド作成
名前: アクセス許可
計算式:
IF CONTAINS([許可地域], [地域])
   OR USERNAME() = "suzuki"  // 管理者
THEN TRUE
ELSE FALSE
END

ステップ3: データソースフィルター設定
├─ データ > データソースフィルター
├─ アクセス許可 = TRUE
└─ すべてのシートに適用

─────────────────────────────

【方法3: ISMEMBEROF関数（グループベース）】

計算フィールド:
地域フィルター = 
IF ISMEMBEROF("東京営業部") THEN [地域] = "東京"
ELSEIF ISMEMBEROF("大阪営業部") THEN [地域] = "大阪"
ELSEIF ISMEMBEROF("営業本部") THEN TRUE
ELSE FALSE
END

メリット:
├─ グループ単位で管理
├─ AD連携で自動化
└─ メンテナンスが容易
📊 Power BIでのRLS実装 
【基本的なRLS設定】

ステップ1: ロールの作成
├─ Power BI Desktop
├─ モデリング > ロールの管理
├─ 「新規」をクリック
└─ ロール名: 東京営業部

ステップ2: DAXフィルター定義
テーブル: 売上
DAXフィルター:
[地域] = "東京"

ステップ3: 追加ロール作成
├─ 大阪営業部: [地域] = "大阪"
├─ 名古屋営業部: [地域] = "名古屋"
└─ 営業本部: （フィルターなし＝全データ）

─────────────────────────────

【動的RLS（ユーザー名ベース）】

ステップ1: 権限テーブル作成
UserPermissions テーブル:
┌────────────────────────────────────────┐
│ UserEmail              │ Region       │
├────────────────────────────────────────┤
│ tanaka@company.com     │ 東京         │
│ sato@company.com       │ 大阪         │
│ suzuki@company.com     │ ALL          │
└────────────────────────────────────────┘

ステップ2: リレーションシップ作成
├─ UserPermissions[Region] → Sales[Region]
└─ クロスフィルター方向: 両方向

ステップ3: DAXフィルター定義
ロール名: DynamicRLS
テーブル: UserPermissions
DAXフィルター:
[UserEmail] = USERPRINCIPALNAME()
|| [Region] = "ALL"

─────────────────────────────

【Power BI Serviceでの設定】

ステップ1: レポートを公開

ステップ2: データセットの設定
├─ ワークスペース > データセット
├─ ・・・ > セキュリティ
└─ ロールにメンバーを追加

ステップ3: メンバー割り当て
├─ 東京営業部ロール
│  └─ tanaka@company.com
├─ 大阪営業部ロール
│  └─ sato@company.com
└─ 営業本部ロール
   └─ suzuki@company.com

ステップ4: テスト
├─ 「ロールとしてテスト」
├─ ロールを選択
└─ データが正しくフィルターされるか確認
💡 RLS設計のベストプラクティス
ポイント 推奨 避けるべき
権限テーブル 別テーブルで管理 ハードコード
グループ活用 ADグループで管理 個人単位で設定
テスト 各ロールで動作確認 本番公開後に確認
パフォーマンス シンプルなフィルター 複雑なDAX計算
管理者権限 明示的に設定 暗黙の全権限

📤 4. コンテンツの共有と公開設定

共有方法の選択

レポートの共有方法は複数あります。セキュリティ要件と利便性のバランスを考えて、適切な方法を選択しましょう。

📊 共有方法の比較
共有方法 セキュリティ 利便性 用途
ワークスペース 🟢 高 🟡 中 チーム内での共同作業
アプリ 🟢 高 🟢 高 部門への配布
直接共有 🟡 中 🟢 高 個別ユーザーへの共有
埋め込み 🟡 中 🟢 高 社内ポータルへの組み込み
Web公開 🔴 低 🟢 高 一般公開（機密データNG）
📊 Tableauでの共有設定 
【Tableau Serverでの共有】

方法1: プロジェクト権限
├─ プロジェクト > 権限
├─ グループ/ユーザーを追加
├─ 権限テンプレートを選択
└─ 保存

方法2: 個別コンテンツ共有
├─ ワークブック > 共有
├─ リンクをコピー
└─ メールで送信

方法3: サブスクリプション（自動配信）
├─ ビュー > サブスクリプション
├─ 受信者を追加
├─ スケジュール設定（毎日、毎週等）
└─ 形式選択（PDF、画像、CSV）

─────────────────────────────

【Tableau Publicでの公開】

ステップ1: Tableau Publicにサインイン
ステップ2: サーバー > Tableau Publicに保存
ステップ3: ビジュアライゼーションを公開
ステップ4: 埋め込みコードを取得

⚠️ 注意: 機密データは絶対に公開しない！
   └─ Tableau Publicは誰でも閲覧可能
📊 Power BIでの共有設定 
【Power BI Serviceでの共有】

方法1: ワークスペースアクセス
├─ ワークスペース > アクセス
├─ ユーザー/グループを追加
├─ ロールを選択
└─ 保存

方法2: 直接共有
├─ レポート > 共有
├─ 受信者のメールアドレス入力
├─ 権限オプション設定
│  ├─ □ 受信者に再共有を許可
│  ├─ □ 基になるデータセットの使用許可
│  └─ □ レポートのコピー作成を許可
└─ 送信

方法3: アプリとして配布
├─ ワークスペース > アプリを作成
├─ 含めるコンテンツを選択
├─ アクセス許可を設定
├─ 対象者を指定
│  ├─ 組織全体
│  ├─ 特定のユーザー/グループ
│  └─ セキュリティグループ
└─ アプリを発行

方法4: サブスクリプション（自動配信）
├─ レポート > サブスクライブ
├─ サブスクリプション名入力
├─ 受信者を追加
├─ 頻度設定（毎日、毎週、データ更新時）
├─ 時間を指定
└─ 保存

─────────────────────────────

【Webに公開（注意！）】

ステップ1: レポート > ファイル > Webに公開
ステップ2: 埋め込みコードを生成
ステップ3: Webサイトに埋め込み

⚠️ 警告:
├─ 認証なしで誰でもアクセス可能
├─ 機密データは絶対に使用禁止
├─ 管理者がテナント設定で無効化可能
└─ 社内ポリシーを必ず確認
⚠️ 共有時のセキュリティチェックリスト
チェック項目 確認内容
□ データの機密性 個人情報、財務情報、営業秘密が含まれていないか
□ 共有先の確認 必要な人だけに共有されているか
□ 再共有の制限 受信者が他者に共有できない設定か
□ ダウンロード制限 データのエクスポートが制限されているか
□ 有効期限 アクセス期限が設定されているか
□ RLSの適用 行レベルセキュリティが正しく機能しているか

📋 5. コンプライアンス対応

主要な規制・ガイドライン

BIツールで扱うデータは、様々な法規制やガイドラインの対象となる可能性があります。特に個人情報を扱う場合は、適切な対策が必要です。

📊 主要な規制とBIでの対応
規制 対象 BIでの対応
個人情報保護法 日本国内の個人情報 アクセス制限、匿名化、ログ管理
GDPR EU域内の個人データ 同意管理、データ削除対応、移転制限
SOX法 上場企業の財務データ アクセスログ、変更履歴、監査対応
HIPAA 米国の医療情報 暗号化、アクセス制御、監査証跡
PCI DSS クレジットカード情報 マスキング、暗号化、アクセス制限
📊 データ保護の実装方法 
【データマスキング】

目的: 機密データを隠蔽しながら分析可能に

例1: クレジットカード番号
元データ: 4111-2222-3333-4444
マスク後: ****-****-****-4444

例2: 電話番号
元データ: 090-1234-5678
マスク後: 090-****-****

例3: メールアドレス
元データ: tanaka@company.com
マスク後: t*****@c*****.com

─────────────────────────────

【Tableauでのマスキング】

計算フィールド:
マスク電話番号 = 
LEFT([電話番号], 4) + "****-****"

マスクメール = 
LEFT([メール], 1) + "*****@" + 
RIGHT([メール], LEN([メール]) - FIND("@", [メール]))

─────────────────────────────

【Power BIでのマスキング】

DAX計算列:
マスク電話番号 = 
LEFT([電話番号], 4) & "****-****"

マスクメール = 
LEFT([メール], 1) & "*****@" & 
RIGHT([メール], LEN([メール]) - SEARCH("@", [メール]))

─────────────────────────────

【データ匿名化】

方法1: 一般化
├─ 年齢: 35歳 → 30-39歳
├─ 住所: 東京都渋谷区 → 東京都
└─ 日付: 2025/01/15 → 2025年1月

方法2: 仮名化
├─ 氏名: 田中太郎 → User001
├─ ID: 12345 → ハッシュ値
└─ 可逆的な変換（復元可能）

方法3: 匿名化
├─ 個人を特定できないように加工
├─ 不可逆的な変換
└─ 統計的な分析のみ可能

📊 6. 監査ログの活用

監査ログの重要性

監査ログは「誰が、いつ、何をしたか」を記録します。セキュリティインシデントの調査、コンプライアンス対応、利用状況の把握に不可欠です。

📊 記録される主なアクティビティ
カテゴリ 記録内容
アクセス ログイン/ログアウト、レポート閲覧、ダッシュボードアクセス
コンテンツ操作 作成、編集、削除、公開、共有
データ操作 データセット更新、エクスポート、ダウンロード
管理操作 ユーザー追加/削除、権限変更、設定変更
📊 Tableauの監査ログ 
【管理ビューの活用】

アクセス方法:
├─ Tableau Server/Cloud
├─ サイト > 状態
└─ 管理ビューを選択

主要な管理ビュー:
1. ユーザーごとのトラフィック
   └─ 誰が何回アクセスしたか

2. ビューごとのトラフィック
   └─ どのレポートが人気か

3. データソースの使用状況
   └─ どのデータが使われているか

4. サーバーの使用状況
   └─ 負荷状況の確認

─────────────────────────────

【詳細監査ログの取得】

Tableau Server:
├─ tabadmin get logs
└─ PostgreSQLリポジトリから抽出

Tableau Cloud:
├─ 管理 > 監査
└─ アクティビティログをダウンロード

ログの内容:
├─ タイムスタンプ
├─ ユーザー名
├─ アクション種類
├─ 対象コンテンツ
├─ IPアドレス
└─ 結果（成功/失敗）
📊 Power BIの監査ログ 
【アクティビティログの確認】

方法1: Power BI管理ポータル
├─ 管理ポータル > 監査ログ
├─ Microsoft 365コンプライアンスセンターへリンク
└─ Power BIアクティビティを検索

方法2: Microsoft 365監査ログ
├─ compliance.microsoft.com
├─ 監査 > 監査ログの検索
├─ アクティビティ: Power BI
├─ 日付範囲を指定
└─ 検索実行

─────────────────────────────

【記録されるアクティビティ例】

ViewReport: レポート閲覧
ExportReport: レポートエクスポート
ShareReport: レポート共有
CreateDashboard: ダッシュボード作成
DeleteReport: レポート削除
RefreshDataset: データセット更新
AddGroupMembers: グループメンバー追加
ChangeGatewayCreds: ゲートウェイ資格情報変更

─────────────────────────────

【PowerShellでのログ取得】

# Power BI管理モジュールのインストール
Install-Module -Name MicrosoftPowerBIMgmt

# ログイン
Login-PowerBI

# アクティビティログの取得
Get-PowerBIActivityEvents `
    -StartDateTime "2025-01-01T00:00:00" `
    -EndDateTime "2025-01-31T23:59:59" `
    | Export-Csv "ActivityLog.csv"

─────────────────────────────

【利用状況メトリック】

Power BI Premium/Pro機能:
├─ ワークスペース > 利用状況メトリックレポート
├─ 閲覧者数、閲覧回数
├─ 人気のレポート
├─ 利用トレンド
└─ ユーザー別利用状況
💡 監査ログ活用のベストプラクティス
活用目的 確認すべきポイント
セキュリティ監視 不審なアクセス、大量ダウンロード、営業時間外のアクセス
コンプライアンス 機密データへのアクセス履歴、権限変更の記録
利用状況把握 人気コンテンツ、未使用レポート、アクティブユーザー
トラブルシューティング エラー発生時の操作履歴、問題の再現

📝 STEP 48 のまとめ

✅ このステップで学んだこと
  • セキュリティの3本柱：認証、認可、監査の重要性
  • ユーザー権限：最小権限の原則に基づく設計
  • 行レベルセキュリティ：ユーザーごとにデータを制限
  • 共有設定：セキュリティと利便性のバランス
  • コンプライアンス：法規制に対応したデータ保護
  • 監査ログ：アクセス履歴の記録と活用
💡 セキュリティ設計チェックリスト
カテゴリ チェック項目
認証 □ SSO設定 □ MFA有効化 □ パスワードポリシー
認可 □ ロール設計 □ RLS設定 □ 共有制限
データ保護 □ マスキング □ 暗号化 □ バックアップ
監査 □ ログ有効化 □ 定期レビュー □ アラート設定
🎯 最重要ポイント

セキュリティは「後付け」では不十分です。設計段階から「誰に何を見せるか」を明確にし、最小権限の原則に基づいて権限を付与しましょう。

特に行レベルセキュリティ（RLS）は、同じレポートでユーザーごとに表示データを制限できる強力な機能です。適切に設計することで、セキュリティを確保しながら効率的なデータ共有が可能になります！

📝 実践演習

演習 1 基礎

営業部門向けのレポートで、各営業担当者が自分の担当地域のデータのみ閲覧できるようにRLSを設定してください。

【Power BIでのRLS設定】

ステップ1: 権限テーブルの作成

UserPermissions テーブル:
┌────────────────────────────────────────┐
│ UserEmail              │ Region       │
├────────────────────────────────────────┤
│ tanaka@company.com     │ 東京         │
│ sato@company.com       │ 大阪         │
│ yamada@company.com     │ 名古屋       │
│ manager@company.com    │ ALL          │
└────────────────────────────────────────┘

ステップ2: リレーションシップの設定

  1. UserPermissions[Region] と Sales[Region] を結合
  2. クロスフィルター方向: 両方向

ステップ3: ロールの作成

モデリング > ロールの管理 > 新規

ロール名: SalesRLS
テーブル: UserPermissions
DAXフィルター:
[UserEmail] = USERPRINCIPALNAME()
|| [Region] = "ALL"

ステップ4: テスト

  1. モデリング > ロールとして表示
  2. SalesRLSロールを選択
  3. 「他のユーザー」に tanaka@company.com を入力
  4. 東京のデータのみ表示されることを確認

ステップ5: メンバーの割り当て（Service）

  1. Power BI Serviceでデータセットを開く
  2. セキュリティをクリック
  3. SalesRLSロールにメンバーを追加
  4. 全営業担当者を追加
演習 2 応用

以下の要件を満たすセキュリティ設計を行ってください：経営層は全データ、部長は自部門のデータ、一般社員は自チームのデータのみ閲覧可能

【階層型RLSの設計】

ステップ1: 権限階層テーブルの作成

UserHierarchy テーブル:
┌─────────────────────────────────────────────────────┐
│ UserEmail           │ Role    │ Dept   │ Team     │
├─────────────────────────────────────────────────────┤
│ ceo@company.com     │ Exec    │ ALL    │ ALL      │
│ cfo@company.com     │ Exec    │ ALL    │ ALL      │
│ sales_mgr@co.com    │ Manager │ 営業部 │ ALL      │
│ dev_mgr@company.com │ Manager │ 開発部 │ ALL      │
│ tanaka@company.com  │ Staff   │ 営業部 │ 東京チーム│
│ sato@company.com    │ Staff   │ 営業部 │ 大阪チーム│
└─────────────────────────────────────────────────────┘

ステップ2: DAXフィルターの作成

ロール名: HierarchyRLS
テーブル: UserHierarchy
DAXフィルター:

[UserEmail] = USERPRINCIPALNAME()

ステップ3: データテーブルへのフィルター適用

テーブル: Sales
DAXフィルター:

VAR CurrentUser = 
    LOOKUPVALUE(
        UserHierarchy[Role],
        UserHierarchy[UserEmail],
        USERPRINCIPALNAME()
    )
VAR CurrentDept = 
    LOOKUPVALUE(
        UserHierarchy[Dept],
        UserHierarchy[UserEmail],
        USERPRINCIPALNAME()
    )
VAR CurrentTeam = 
    LOOKUPVALUE(
        UserHierarchy[Team],
        UserHierarchy[UserEmail],
        USERPRINCIPALNAME()
    )
RETURN
    CurrentUser = "Exec"
    || (CurrentUser = "Manager" && 
        (CurrentDept = "ALL" || [Department] = CurrentDept))
    || (CurrentUser = "Staff" && 
        (CurrentTeam = "ALL" || [Team] = CurrentTeam))

結果

ユーザー 閲覧可能範囲
CEO 全データ
営業部長 営業部の全データ
田中（東京チーム） 東京チームのデータのみ
チャレンジ 発展

個人情報を含むデータを扱うBIシステムのセキュリティ設計書を作成してください。認証、認可、データ保護、監査の各観点を含めてください。

【BIシステムセキュリティ設計書】

1. 概要

システム名: 顧客分析ダッシュボード
対象データ: 顧客情報（氏名、住所、購買履歴）
ユーザー数: 約100名
規制対応: 個人情報保護法

2. 認証設計

【認証方式】
├─ Azure AD SSO（シングルサインオン）
├─ 多要素認証（MFA）必須
└─ 条件付きアクセス
   ├─ 社内ネットワーク: MFAスキップ
   └─ 社外アクセス: MFA必須

【パスワードポリシー】
├─ 最小文字数: 12文字
├─ 複雑性: 英大小・数字・記号必須
├─ 有効期限: 90日
└─ 履歴: 過去10回分は再利用禁止

【セッション管理】
├─ タイムアウト: 30分
├─ 同時ログイン: 禁止
└─ 強制ログアウト: 可能

3. 認可設計

【ロール定義】
┌────────────────────────────────────────────┐
│ ロール     │ 権限                          │
├────────────────────────────────────────────┤
│ 管理者     │ 全権限                        │
│ 分析者     │ 全データ閲覧（個人情報除く）  │
│ 営業担当   │ 担当顧客のみ                  │
│ 経営層     │ 集計データのみ                │
└────────────────────────────────────────────┘

【行レベルセキュリティ】
├─ 営業担当: 担当顧客フィルター
├─ 地域別: 担当地域フィルター
└─ 経営層: 集計ビューのみアクセス

【列レベルセキュリティ】
├─ 氏名: 分析者以上のみ
├─ 住所: 営業担当・管理者のみ
├─ 電話番号: 営業担当・管理者のみ
└─ 購買履歴: 全員（匿名化後）

4. データ保護設計

【暗号化】
├─ 保存時: AES-256暗号化
├─ 転送時: TLS 1.2以上
└─ キー管理: Azure Key Vault

【データマスキング】
├─ 氏名: 山田**（姓のみ表示）
├─ 住所: 東京都***（都道府県のみ）
├─ 電話番号: 090-****-****
└─ メール: y****@***.com

【データ匿名化】
├─ 分析用ビュー: 個人特定不可
├─ 年齢: 年代表示（30代等）
└─ 地域: 都道府県レベル

【バックアップ】
├─ 頻度: 日次
├─ 保持期間: 30日
└─ 保管場所: 別リージョン

5. 監査設計

【ログ取得】
├─ アクセスログ: 全アクセス記録
├─ 操作ログ: 全操作記録
├─ エクスポートログ: ダウンロード記録
└─ 管理ログ: 設定変更記録

【ログ保持期間】
├─ オンライン: 90日
├─ アーカイブ: 7年
└─ 法的要件対応

【監視・アラート】
├─ 大量ダウンロード: 即時アラート
├─ 営業時間外アクセス: 日次レポート
├─ 権限変更: 即時アラート
└─ ログイン失敗: 5回でロック

【定期レビュー】
├─ 週次: アクセス状況確認
├─ 月次: 権限棚卸し
├─ 四半期: セキュリティ監査
└─ 年次: 外部監査

6. インシデント対応

【対応フロー】
1. 検知: 監視システムまたは報告
2. 初動: アクセス遮断、証拠保全
3. 調査: 影響範囲の特定
4. 報告: 経営層・法務・広報
5. 対応: 是正措置の実施
6. 再発防止: 原因分析、対策実施

【連絡体制】
├─ 第一報: 15分以内
├─ 状況報告: 1時間ごと
└─ 完了報告: 対応完了後24時間以内

❓ よくある質問

Q1: RLSはパフォーマンスに影響しますか？
はい、影響する可能性があります。

影響を最小化するコツ：
✓ シンプルなフィルター条件を使用
✓ 権限テーブルは小さく保つ
✓ インデックスを活用
✓ 複雑なDAX計算を避ける

パフォーマンステスト：
本番適用前に、各ロールでパフォーマンスをテストしましょう。
Q2: 外部ユーザーとレポートを共有できますか？
はい、可能ですが制限があります。

Power BI：
– Azure AD B2Bで外部ユーザーを招待
– 管理者がテナント設定で許可必要
– Premium Per Userライセンスが必要な場合あり

Tableau：
– ゲストユーザーライセンスを付与
– サイト管理者が許可設定
– コンテンツごとに権限設定

注意：機密データは外部共有を避けましょう。
Q3: ダウンロードを禁止できますか？
はい、設定で制限できます。

Power BI：
– テナント設定 > エクスポート設定
– ワークスペース単位で制限可能
– Excel/CSV/PDFエクスポートを個別に制御

Tableau：
– サイト設定 > ダウンロード許可
– プロジェクト/ワークブック単位で制限
– 画像のみ許可等の細かい設定可能

注意：スクリーンショットは防げないため、機密データは表示自体を制限しましょう。
Q4: 監査ログはどのくらい保持すべきですか？
法規制と社内ポリシーに従いましょう。

一般的な目安：
– 通常業務: 90日〜1年
– コンプライアンス対応: 3〜7年
– 金融業界: 7〜10年

Power BI：
– 標準: 90日
– 長期保存: Azure Log Analyticsに転送

Tableau：
– 標準: 設定による
– 長期保存: 外部SIEMに転送
Q5: SSOを導入するメリットは何ですか？
セキュリティと利便性の両方が向上します。

セキュリティ面：
✓ 一元的なユーザー管理
✓ パスワードポリシーの統一
✓ 退職者の即時アクセス停止
✓ MFAの一括適用

利便性面：
✓ 1つのID/パスワードで全システムアクセス
✓ パスワード忘れの削減
✓ ログイン手間の軽減

導入推奨：Azure AD/Okta/OneLoginなどと連携しましょう。
← 前のステップ
STEP 47: パフォーマンス最適化のベストプラクティス 次のステップへ →
STEP 49: 実践プロジェクト1 – 売上分析ダッシュボード
📝

学習メモ

BIツール入門 - Step 48

💾 自動保存 · 0文字
📋 過去のメモ一覧 ▼
#artnasekai #学習メモ
LINE
ホーム
BIツール入門（Tableau・Power BI）