■Cloud SQL縺?BQからクエ繝?

SELECT * FROM EXTERNAL_QUERY("connection_name", "SELECT * FROM db.tbl")

BigQuery初心者を脱出したい３（CloudSQL連携クエリ・スケジュールクエリ・??
data taransfer縺?Connectionを設藹??してお縺?
保存先も同じリージョンである必要がある、RDSがosakaだ縺?BQ縺?multi region US等でな縺?osaka縺?

■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;