GOOGLE CLOUD データ基盤コース

見せる範囲を設計する — IAM・列・部署プロジェクト

データセット、列、部署への配布を別のレイヤーで守ると、PIIを抱えたデータ基盤でも分析を止めずに共有できます。

TL;DR

  1. IAM はデータセットを開けるかを決める。
  2. ポリシータグは同じテーブルのPII列だけを拒否またはマスクする。
  3. BigQuery Sharing はコピーせず、部署プロジェクトにリンクドデータセットとして届ける。

01三層で守る

「テーブルを読める」と「PIIを見せる」は同じ権限ではない。

BigQueryの統制と共有の三層で守る図
IAMでデータセットの入口を制御し、Authorized Viewで公開する形を絞り、ポリシータグでemail等の列を制御する。

IAMでデータセットの入口を制御し、Authorized Viewで公開する形を絞り、ポリシータグでemail等の列を制御する。

02ポリシータグの効き方

タグを付けると、Ownerであってもタグ権限なしには列を読めない。

BigQueryの統制と共有のポリシータグの効き方図
high（認証情報）・medium（直接識別子）・low（準識別子）の分類を置き、Fine-Grained ReaderまたはMasked Readerを明示して付ける。

high（認証情報）・medium（直接識別子）・low（準識別子）の分類を置き、Fine-Grained ReaderまたはMasked Readerを明示して付ける。

要点：タグを付けると、Ownerであってもタグ権限なしには列を読めない。

03部署へ配る

共有先の自由と、中央データの統制を両立させる。

BigQueryの統制と共有の部署へ配る図
データチームはExchangeでマートを公開し、営業等は自分のプロジェクトでSubscribeする。データはコピーされず更新は反映され、クエリ課金は利用側に発生する。

データチームはExchangeでマートを公開し、営業等は自分のプロジェクトでSubscribeする。データはコピーされず更新は反映され、クエリ課金は利用側に発生する。

結論

  1. まず公開するマートを整え、rawへの直接アクセスを最小化する。
  2. 列レベルはPIIの分類と実行主体の権限をセットで設計する。
  3. Sharingはデータ複製ではなく、独立した分析環境への参照配布。