権限設計の基本:誰が何を見られるか
Stage 5 — 第1章 | データマネジメント入門 推定学習時間:40〜50分 | 難易度:★★★☆☆
この章で学ぶこと
品質と SSOT 以前に、見る権限 がありません。 さくら商事では、CS 担当が顧客の 購買履歴全文 を見られ、委託先 BI ベンダーに メールアドレス列 がマスクなしで渡っていました。
データセキュリティ(Data Security)は DAMA 11 領域の 1 つ。 本章では RBAC(Role-Based Access Control) と行/列レベル、PII マスキングの基本を学びます。
この章を終えると、こんなことができるようになります:
- RBAC と最小権限の原則を説明できる
- 行レベル・列レベルセキュリティの 使い分け を説明できる
- PII(Personally Identifiable Information)とマスキングの基本を説明できる
- 委託先・CS・分析チームの 権限設計 を具体例で説明できる
1. 「この列、見ていいですか?」
CS の新人が Slack で質問しました。
「返金対応で、顧客の 全注文履歴と住所 見たいんですが、BigQuery の権限足りますか?」
同じ週、委託 BI ベンダーに dim_customer 全列 export が依頼されました。
DPO(Data Protection Officer 相当)のレビューは 後回し でした。
DPO 相当・法務
「メール・電話・住所は PII。目的とマスクなしでは渡せません。」
2. 権限の層
権限は 何段階か に分けて設計します。
IdP(Identity Provider)→ ロール → オブジェクト → 行 → 列 → 委託先
次の図は、さくら商事が 権限設計の会話 をするための層モデルです。
「BigQuery 権限ください」だけでは不十分。 どのマートのどの列を、何の目的で までセットで聞きます。
3. RBAC と最小権限
RBAC = ユーザーに ロール を付け、ロールに 権限セット を紐づける方式。
| ロール | さくら商事の権限例 |
|---|---|
analyst_finance |
mart_finance 読取、PII 列マスク |
analyst_marketing |
mart_marketing 読取 |
cs_agent |
自担当チケット関連行のみ |
de_platform |
Bronze/Silver 書込、本番 OLTP 非接触 |
vendor_bi_readonly |
Gold マスク済みビューのみ |
3.1 最小権限(Least Privilege)
| 原則 | 実践 |
|---|---|
| 必要な最小だけ | CS に全顧客履歴は不要 |
| 期限付き | 委託先はプロジェクト期間のみ |
| 目的限定 | 「返金対応のため」等を記録 |
| 定期レビュー | 退職・異動で即剥奪 |
Stage 1 の 廃棄(退職者アカウント)と直結します。
4. 行レベル・列レベル
| 方式 | 制御単位 | 向く場面 |
|---|---|---|
| 行レベル(Row-Level Security) | 行 | CS は自部門顧客のみ |
| 列レベル(Column-Level Security) | 列 | メールを hash 列に置換 |
| マスクビュー | 列の表示変換 | 委託先向け export |
4.1 さくら商事の例
-- マスクビュー(概念)
CREATE VIEW mart_customer_masked AS
SELECT
customer_id,
SHA256(email) AS email_hash, -- 生メール非表示
city,
total_orders
FROM dim_customer;
| 利用者 | オブジェクト |
|---|---|
| 経理 | dim_customer(契約上 PII 可) |
| マーケ | mart_customer_masked |
| 委託 BI | mart_customer_masked + 契約 DPA |
5. PII の基本
PII = 個人を特定しうる情報(氏名、メール、電話、住所、IP 等)。
| 対応 | 内容 |
|---|---|
| 分類 | PII 列をカタログにタグ |
| 最小収集 | 生成段階で不要 PII を取らない(Stage 1) |
| マスク / 仮名化 | 分析用は hash、token |
| 利用目的 | 返金対応 vs マーケ分析で権限分離 |
| 委託 | DPA、持出し禁止、ログ |
現場メモ
「社内だから大丈夫」は 通用しません。 内部不正・誤送信・ログ流出は日常茶飯事レベルで起きます。
6. 委託先・ツール連携
| リスク | 対策 |
|---|---|
| CSV 持出し | ビュー経由、ダウンロード禁止 |
| Looker 全社公開 | フォルダ権限 + セマンティックレイヤー |
| AI チャットに貼る | PII 禁止ポリシー(Stage 5-3 へ) |
体系コラム:カリキュラム上の位置づけ
| 項目 | 内容 |
|---|---|
| Stage / 章 | Stage 5 — 第1章「アクセス制御の基礎」 |
| 今回の論点 | データの 層別権限(RBAC、行・列、PII) |
| DAMA 領域 | データセキュリティ、データプライバシー |
| ライフサイクル | 保存(誰が触れるか)と廃棄(アカウント停止) |
| 前章との接続 | 分析前チェックリスト — 「見ていい列か」を 権限設計 で裏付ける |
| 次章への伏線 | ガバナンスの実践 — 権限を 規程と運用 で回す |
コラム:よくある誤解 —「権限は IT が全部決める」
CS の鈴木さん(別部署)が「顧客メール見たい」と Slack で聞いてきたとき、基盤の鈴木さんは即 grant しませんでした。利用目的・期間・最小列 をオーナー(佐藤さん経由)に確認する——これがデータマネジメント的アクセス制御です。
よくある誤解は「DB 管理者が権限表を持っていれば十分」というもの。行レベル・列レベル、委託先へのビュー経由配布、退職当日のアカウント停止は 業務オーナーと DPO の判断 が必要です。
もう一つは「匿名化すれば全部 OK」という幻想。郵便番号 + 購買履歴の組み合わせは再識別可能です。さくら商事では PII 列ツールを禁止し、必要なら 集計済み mart のみ を開放する方針にしました。
まとめ
| 層 | キーワード |
|---|---|
| RBAC | ロールで束ねる |
| 行/列 | 細かく絞る |
| PII | 分類・マスク・目的 |
| 委託 | 最小 + 期限 + 契約 |
この章のキーメッセージ:
権限は IT が ON にするスイッチ ではなく、利用目的とリスクに応じた設計 です。 「見たい」ではなく「業務上必要な最小」で聞いてください。
次に読む
- 前章(Stage 4): 分析前チェックリスト
- 次章: ガバナンスを回す
- 関連: 誰が何を担うか
確認問題
問題 1
CS 担当に全顧客の dim_customer 読取を付与しようとした。
最小権限の観点で最も適切 なのはどれですか。
A. 全行・全列 OK
B. 返金対応に必要な行・列のみ、PII はマスク or 限定列
C. 権限不要(社内だから)
D. 本番 OLTP を直接見せる
正解: B
解説: 目的限定 + 行/列最小化 が原則です。A/C は過剰、D は OLTP/OLAP 分離違反です。
問題 2
委託 BI ベンダーに email 生列付き export を渡そうとした。
最も適切な対応 はどれですか。
A. そのまま渡す
B. マスクビュー + DPA + 期限付き read-only ロール
C. 全社 Slack に upload
D. PII は問題ないので無視
正解: B
解説: 委託先は 外部扱い。マスク・契約・期限がセットです。
問題 3
「RBAC ロール analyst を全員に付ければ管理が楽」と提案された。
データマネジメント上の懸念 として最も適切なのはどれですか。
A. 問題ない。1 ロールが最善
B. 部門・用途差が失われ、PII 過剰アクセスと監査不能になる
C. ロールは 100 個必要
D. RBAC は使えない
正解: B
解説: 楽さのための 権限の平坦化 は内部漏えいリスクを増やします。
用語メモ(この章)
| 用語 | 意味(この章での使い方) |
|---|---|
| RBAC | ロールに基づくアクセス制御 |
| 行/列レベルセキュリティ | 行・列単位の閲覧制限 |
| PII | 個人を特定しうる情報 |
| 最小権限 | 業務に必要な最小のアクセスのみ |
| DPA | 委託先とのデータ処理契約 |