🔐 BigQuery 承認済みビュー

Authorized Views: データアクセス制御の強力な仕組み

📖 承認済みビューとは

承認済みビュー（Authorized Views）は、基となるテーブルへの直接アクセス権限がないユーザーでも、ビューを通じて特定のデータにアクセスできるようにする仕組みです。

🎯 核心概念

ビューに「基となるテーブルからデータを読み取る権限」を与え、 ユーザーには「そのビューを使う権限だけ」を付与します。 これにより、テーブル全体へのアクセスを許可せずに、必要なデータのみを公開できます。

❌ 通常のビュー（承認なし）
👤
ユーザー（アナリスト）
ビューにアクセス
↓ クエリ実行
👁️
通常のビュー
SELECT * FROM sensitive_table
WHERE department = 'Sales'
↓ 基のテーブルを参照
🗄️
sensitive_table
❌ アクセス権なし
⛔ アクセス拒否
ユーザーは基のテーブルへの権限が必要
✅ 承認済みビュー
👤
ユーザー（アナリスト）
ビューにアクセス
↓ クエリ実行
✅
承認済みビュー
✓ ビューへの権限あり
SELECT * FROM sensitive_table
WHERE department = 'Sales'
↓ 承認されたアクセス
🗄️
sensitive_table
✓ ビューが代理アクセス
✅ アクセス成功
ビューが承認されているため、データ取得可能

🏗️ アーキテクチャと動作の仕組み

👥 ユーザー層
👤
営業チーム
機密テーブル: ✗
営業ビュー: ✓
👤
マーケチーム
機密テーブル: ✗
マーケビュー: ✓
↓↓
👁️ ビュー層（承認済み）
sales_view
WHERE department='Sales'
承認済み
marketing_view
WHERE department='Marketing'
承認済み
🔐 承認メカニズム: ビューが基のテーブルへのアクセス権を持つ
🗄️ データ層
employee_data（機密テーブル）
全社員の給与、個人情報、評価データ
直接アクセス不可
🔑 重要ポイント:

⚙️ 設定手順

📋 承認済みビューの作成ステップ

1
基となるテーブルを準備
機密データを含むテーブルを作成または既存のテーブルを特定
2
ビューを作成
必要なデータのみを公開するSQLクエリでビューを定義
3
ビューを承認済みビューとして設定
基のテーブルのアクセス制御でビューを承認
4
ユーザーにビューへのアクセス権を付与
ユーザーやグループにビューの閲覧権限を付与

💻 実装例

-- Step 1: 基のテーブル（機密データ） CREATE TABLE `project.dataset.employee_data` ( employee_id INT64, name STRING, department STRING, salary INT64, performance_rating FLOAT64, ssn STRING ); -- Step 2: 承認済みビューの作成（営業部門のみ） CREATE VIEW `project.dataset.sales_employee_view` AS SELECT employee_id, name, department, performance_rating -- 給与やSSNは除外 FROM `project.dataset.employee_data` WHERE department = 'Sales'; -- Step 3: ビューを承認済みビューとして設定 (gcloudコマンド) -- 基のテーブルのデータセットに対してビューを承認
# Step 3: gcloudコマンドで承認 bq update --dataset \ --add_authorized_view project:dataset.sales_employee_view \ project:dataset # または、Terraformでの設定例 resource "google_bigquery_dataset_access" "authorized_view" { dataset_id = "dataset" project = "project" view { project_id = "project" dataset_id = "dataset" table_id = "sales_employee_view" } } # Step 4: ユーザーにビューへのアクセス権を付与 bq add-iam-policy-binding \ --member='group:sales-team@company.com' \ --role='roles/bigquery.dataViewer' \ project:dataset.sales_employee_view
⚠️ 注意事項:

🎯 実際のユースケース

📊 部門別データアクセス制御

シナリオ: 全社員データを含むテーブルがあるが、各部門には自部門のデータのみアクセスさせたい

-- 営業部門用ビュー CREATE VIEW sales_dept_view AS SELECT * FROM all_employees WHERE department = 'Sales'; -- マーケティング部門用ビュー CREATE VIEW marketing_dept_view AS SELECT * FROM all_employees WHERE department = 'Marketing';

効果: 各部門は自部門のデータのみ閲覧可能。他部門のデータや全社データへのアクセスは不可。

🔒 個人情報の隠蔽

シナリオ: 顧客データを分析チームに提供したいが、個人を特定できる情報（PII）は見せたくない

-- 匿名化された顧客データビュー CREATE VIEW anonymized_customer_view AS SELECT HASH(customer_id) AS customer_hash, -- IDをハッシュ化 age_range, -- 年齢は範囲で提供 prefecture, -- 都道府県レベルまで purchase_amount, purchase_date FROM customer_master -- 名前、住所、電話番号、メールアドレスは除外

効果: 分析に必要なデータは提供しつつ、個人を特定できる情報は保護。

💰 給与データの段階的公開

シナリオ: 経営層には全社員の給与データ、マネージャーには自チームのみ、一般社員には自分のみ

-- マネージャー用: 自チームの給与データ CREATE VIEW manager_team_salary_view AS SELECT e.employee_id, e.name, e.salary, e.team_id FROM employee_data e WHERE e.team_id IN ( SELECT team_id FROM manager_mapping WHERE manager_email = SESSION_USER() ); -- 経営層用: 全社員の給与データ（集計込み） CREATE VIEW executive_salary_view AS SELECT department, COUNT(*) AS employee_count, AVG(salary) AS avg_salary, MIN(salary) AS min_salary, MAX(salary) AS max_salary FROM employee_data GROUP BY department;

効果: 役職に応じて適切な粒度でデータアクセスを制御。

🌐 クロスプロジェクトデータ共有

シナリオ: 本番環境のデータを分析環境に共有したいが、直接アクセスは許可したくない

-- 本番プロジェクト内で分析用ビューを作成 -- production-project.prod_dataset CREATE VIEW analytics_safe_view AS SELECT order_id, DATE(order_timestamp) AS order_date, -- タイムスタンプは日付に丸める product_id, quantity, ROUND(price, -2) AS price_range -- 価格は100円単位に丸める FROM orders WHERE order_status = 'completed'; -- 完了した注文のみ -- 分析プロジェクトのユーザーにビューへのアクセス権を付与

効果: 本番テーブルへの直接アクセスを防ぎ、必要なデータのみを安全に共有。

✨ メリット

🔐 きめ細かいアクセス制御

🛡️ セキュリティの向上

⚙️ 管理の簡素化

🚀 柔軟性

⚠️ 制限事項と注意点

項目 制限内容 対処法
プロジェクト制約 ビューと基のテーブルは同じプロジェクトにある必要がある 異なるデータセットは可能。クロスプロジェクトの場合はデータ転送を検討
パフォーマンス ビューは実行時にクエリが評価されるため、複雑なビューは遅い マテリアライズドビューの使用を検討
ネストの制限 承認済みビューの上に別の承認済みビューを作ることは非推奨 シンプルな階層構造を維持する
外部テーブル 外部テーブル（GCS、Driveなど）には承認済みビューを使用できない データをBigQueryにインポートする
データの整合性 基のテーブルが変更されるとビューの結果も変わる スナップショットやマテリアライズドビューで固定
🔍 セキュリティ上の注意:

🆚 他の方法との比較

方法 メリット デメリット 適用場面
承認済みビュー ・きめ細かい制御
・SQLで柔軟に定義
・動的フィルタリング可能 		・同一プロジェクト制約
・ビュー実行時のコスト 		部門別アクセス制御
PII隠蔽
行・列レベルの制御
行レベルセキュリティ
(Row-Level Security)		 ・テーブルに直接設定
・ビュー不要
・ポリシーベース管理 		・複雑な条件の設定が難しい
・BigQuery Enterprise以上が必要 		ユーザーごとの動的フィルタ
マルチテナント環境
列レベルセキュリティ
(Column-Level Security)		 ・列単位での制御
・Policy Tagsで管理
・Data Catalog連携 		・行のフィルタリング不可
・設定が複雑 		機密列の保護
PII列のマスキング
データセット権限 ・シンプル
・管理が簡単 		・データセット全体が対象
・きめ細かい制御不可 		部門別データセット分離
シンプルな権限管理

💡 ベストプラクティス

✅ 推奨される設計

  • ビュー名に目的を明記（sales_view、anonymized_viewなど）
  • WHERE句で確実にフィルタリング
  • 必要な列のみをSELECT
  • 定期的な権限レビュー
  • ドキュメント化（何を隠蔽しているか記録）

❌ 避けるべき設計

  • SELECT * でのビュー定義
  • WHERE句なしの単純なビュー
  • 過度にネストしたビュー
  • 承認を乱発（必要最小限に）
  • テストなしの本番適用
-- ✅ 良い例: 明確な目的とフィルタリング CREATE VIEW sales_team_customer_view AS SELECT customer_id, company_name, industry, contract_value, DATE(created_at) AS signup_date FROM customers WHERE assigned_team = 'Sales' AND status = 'active' AND contract_value > 0; -- ❌ 悪い例: フィルタなしで全データ公開 CREATE VIEW all_data_view AS SELECT * FROM sensitive_table;

📚 まとめ

🎓 承認済みビューの本質

承認済みビューは、BigQueryにおける強力なデータガバナンスツールです。 適切に設計・運用することで、セキュリティを保ちながら必要なデータを効率的に共有できます。