■BigQueryの列レベル・行レベルのセキュリティ

個人情報や機微情報を隠す
BigQuery の行レベルのセキュリティの概要  |  Google Cloud
行レベルなら同じテーブルを使うので同じダッシュボード/Appが使える（AuthorizedViewの方が柔軟だが）
データ マスキングの概要  |  BigQuery  |  Google Cloud
列レベルアクセス権以外にもマスクの種類があり、ハッシュだったり先頭4文字や末尾４文字等で共通文字化としてマスク化できる

BQ画面＞左ナビのポリシータグ

　ポリシータグを作成（組織単位で一括一覧表示）

　　タグは階層化できるので、全ユーザタグ＞管理者タグ＞社長タグ

　スキーマ＞Addポリシータグ

　　タグが付いていればプレビューで見れない

　　select * except(tag_column)にする必要がある

　　メタデータは見れる（カラム名、型

　ポリシータグ画面＞対象ポリシー選択＞情報パネルで権限者一覧

　　fine-grained readerを付与するとselect *ができるようになる

　　　社長タグに社長だけ権限付ける等

※APIを有効にし、ポリシーを有効にする必要がある

authorized viewを設定するとそのviewを対象とする権限だけ必要で権限をさかのぼり付与しなくていい（通常のviewは参照元の権限も必要）

　この権限移譲は閲覧権限のみで編集権限等は含まない

被参照の元テーブル側に許可するview名を設定する
　参照権限は緩くなるが、編集権限は厳しくなる（設定するビューは変更しない前提で承認する形）

■Authorized系にはメリットとデメリット
ビューにて閲覧対象を絞ることができソース全体は閲覧させないことができる、絞れる
　普通のビューは元データへの権限が必要で見せたくないデータへも権限が必要になる場合がある
２) Authorized viewを設定するデメリット

一度設定してしまえばソース側での権限付与依頼が不要となり被参照側で許可不許可の判断ができなくなる、誰にデータ閲覧権限を付与しているか把握できず管理が機能しなくなる一面がある

将来に置かれるソース側のデータの閲覧も許可することになり不用意に閲覧が可能となってしまう

terraformでAuthorized view設定が剥がれてしまう危険性

ビューを編集するにあたりAuthorized viewを外す必要がある、あるいはソースにもEditor権限
　すぐにビューを変更することができなくなる（ビューを一旦削除することはできる）
３）authorized datasetを設定するデメリット
設定時は良いかもしれないが、将来的に意図しないデータがDS入った場合も閲覧を許してしまう
↓
データセットは細かく作成してアクセスレベル設定し普通のビューを使う
ソース全体を閲覧させられない場合にAVを使うメリットがでる
　情報漏洩リスクはどちらも多段ビューで同じ感じ、だがビュー作成でAV設定が生きているバグがデカい

Asset inventoryをBQにダンプしたデータからクエリする
WITH

  projects AS (

    SELECT

      resource.data AS rsc,

      ancestor_path

    FROM

      prj.cloud_asset_inventory.cloud_asset_inventory_org_resource_now

    WHERE

      asset_type = 'cloudresourcemanager.googleapis.com/Project'

  ),

  projects_info AS (

    SELECT

      JSON_EXTRACT_SCALAR(rsc, '$.projectId') AS projectid,

      JSON_EXTRACT_SCALAR(rsc, '$.lifecycleState') AS lifecycleState,

      ancestor_path

    FROM

      projects

  ),

  projects_efficient AS (

    SELECT

      *

    FROM

      projects_info

    WHERE

      NOT REGEXP_CONTAINS(ancestor_path, "folders/apps-script")

  ),

  projects_num_adm_mgr AS (

    SELECT

      REPLACE(name, '//cloudresourcemanager.googleapis.com/projects/', '') AS project_num,

      REPLACE(b.role, 'organizations/1234567/roles/', '') AS role_value,

      STRING_AGG(REPLACE(m, 'user:', ''), ', ') AS member_value

    FROM

      prj.cloud_asset_inventory.cloud_asset_inventory_org_iam_policy_now,

      UNNEST(iam_policy.bindings) AS b,

      UNNEST(b.members) AS m

    WHERE

      asset_type = 'cloudresourcemanager.googleapis.com/Project'

      AND (role LIKE '%Project_Admin%' OR role LIKE '%Project_Manager%')

    GROUP BY

      project_num,

      role_value

  ),

  projects_adm_mgr AS (

    SELECT

      JSON_EXTRACT_SCALAR(resource.data, '$.projectId') AS project,

      projects_num_adm_mgr.role_value,

      projects_num_adm_mgr.member_value

    FROM

      projects_num_adm_mgr

    LEFT JOIN

      prj.cloud_asset_inventory.cloud_asset_inventory_org_resource_now AS res

    ON

      projects_num_adm_mgr.project_num = REPLACE(res.name, '//cloudresourcemanager.googleapis.com/projects/', '')

  )

SELECT

  projects_efficient.projectid,

  projects_efficient.lifecycleState,

  CONCAT(projects_efficient.projectid, ', ', projects_adm_mgr.role_value) AS role_value,

  projects_adm_mgr.member_value

FROM

  projects_efficient

LEFT OUTER JOIN

  projects_adm_mgr

ON

  projects_efficient.projectid = projects_adm_mgr.project

ORDER BY

  lifecycleState DESC,

  projectid;