BigQuery グループ設計例

アクセス権の設計方法#

組織のアクセス権設計はどうするべきでしょうか。ここでは、最小考慮事項として、リスクアセスメントの紹介と権限グループの例を示すに留めます。

リスクアセスメントをしよう#

ISO/IEC 27002, ISO/IEC 27018, JIS Q 15001, GDPR を確認して、組織ごとのリスクアセスメントを行いましょう。やることは単純で、リスク分析と評価、コントロールです。個人情報は白黒決めにくい領域であることに加え、BigQuery ML のような機械学習の出力結果（個人情報でなくても）の倫理も問われることになる時代です。小さな母集団にフィットして出力自体が個人情報となる場合や、個人情報のうち性別以外全てをマスクして企業の採用可否を決めるような機械学習モデルを作ると偏見になる場合、多種多様なリスクを孕んでいます。

BigQuery の一部の情報が漏れたらどうなるか、モデルの中間出力は偏見を生まないか、リスクを思いつく限り洗い出しましょう。その上で、洗い出したリスクが回避可能か、予防低減可能か複数人で検討しましょう。リスクに関して思考停止せず、機密度合いに応じて権限を小さくできないか検討し続ける環境づくりができると良いです。

グループを活用しよう#

人にアクセス権が割り当てられている状態は、ライフサイクルが全く異なる物を同一管理しているため、健全な組織とは言い難いです。グループに権限を与え、ライフサイクルを切り離しましょう。グループにすることで、スケールアウトに強くなります。

1 つのグループに属すのではなく、複数のグループに跨って属するような運用を認めていただけると、エンジニア的に動きやすいです。プロジェクト A の管理者でありながら、プロジェクト B, C の分析担当者であったりといった縦横の組織構造がある場合に特に有効です。それ以外の場合でも、組織構造にそってグループを作って権限を与えると、権限管理者も例外処理が少なくてすみます。

プロジェクト横断の階層構造の例#

BigQuery の標準の役職ですが、組織の階層構造にそのまま当てはめることができます。管理者から順々に権限が減っていくので、Cloud IAM を用いて組織レベルやプロジェクト単位で設定するのがおすすめのレイヤになります。

役職	説明
BigQuery 管理者	プロジェクト内のすべてのリソースを管理する権限を提供します。プロジェクト内のすべてのデータを管理でき、プロジェクト内で実行されている他のユーザーのジョブもキャンセルできます。
BigQuery データ編集者	データセットのメタデータを読み取り、データセット内のテーブルを一覧表示する。データセットのテーブルを作成、更新、取得、削除する。プロジェクトまたは組織レベルで適用した場合、この役割は新しいデータセットを作成することもできます。
BigQuery データオーナー	データセットを読み取り、更新、削除する。データセットのテーブルを作成、更新、取得、削除する。プロジェクトまたは組織レベルで適用した場合、この役割は新しいデータセットを作成することもできます。
BigQuery ユーザー	プロジェクト内でジョブ（クエリを含む）を実行する権限を付与します。ユーザーの役割は、自分が所有するジョブの列挙、自分が所有するジョブのキャンセル、プロジェクト内のデータセットの列挙ができます。また、プロジェクト内に新しいデータセットを作成することもできます。作成者には新しいデータセットに対する bigquery.dataOwner 役割が付与されます。
BigQuery データ閲覧者	データセットのメタデータを読み取り、データセット内のテーブルを一覧表示する。データセットのテーブルからデータとメタデータを読み取る。プロジェクトまたは組織レベルで適用した場合、この役割はプロジェクト内のすべてのデータセットを列挙することもできます。ただし、ジョブを実行するためには追加の役割が必要です。

データセット横断の案件別アサイン構造の例#

案件など組織の縦割りに当てはまるような構造です。管理者がいるわけではなく、個別のデータに対して、作成レベルと参照レベルの人がいるような構造です。データセットレイヤの権限設定のため、共有データセットを用いて設定するのがおすすめです。

担当案件	説明
お客様 A の担当者	プロジェクト A 内のデータセット、テーブルの一覧、取得の権限を持ちます。
お客様 A の受注案件 X の担当者	プロジェクト A のデータセット X 内のテーブルの作成、更新、削除の権限を持ちます。
お客様 A の受注案件 Y の担当者	プロジェクト A のデータセット Y 内のテーブルの作成、更新、削除の権限を持ちます。

利用者ごとに振る舞いを変える、データマスキングの例#

役割横割りチームにフィットする構造です。データを触れる人間を少なくしたい時に使うイメージです。テーブルレイヤの権限設定のため、承認済みビューを用いて設定します。

チーム	説明
プライバシ検証チーム	組織内のテーブルの一覧、作成、更新、取得、削除の権限を持ちます。
EL チーム	プライバシ検証、保護作業後の承認済みビューの一覧、取得の権限を持ちます。
分析チーム	EL 時の作業列を落とした、承認済みビューの一覧、取得の権限を持ちます。

アクセス状態によって権限を変える、権限管理の例#

時限式権限やリソース名などで実行時制約をかけたい時に使います。実行時レイヤの権限設定のため Cloud IAM Conditions を使って設定します。

アカウント	説明
社外監査アカウント	BigQuery データ閲覧者の権限を 1 ヶ月間、9 時から 17 時の間だけ有効にします。
社外連携アカウント	案件の検証期間中、Storage の所定のディレクトリに BigQuery エクスポートジョブを投げる権限を持たせます。

現状を把握しよう#

組織に合ったアクセス権設計のために、誰がいつどのように使っているか調査する必要があります。BigQuery と Cloud IAM の現状分析の方法を触りだけ紹介します。

BigQuery アクセスの現状分析の進め方#

クエリログをエクスポート or ログシンクする#

この辺りを参考に、今までのクエリログを分析可能な状態にします。

Stackdriver Logging のエクスポートまたはログシンクの対象は、これくらいで十分です。

resource.type="bigquery_resource" AND
proto_payload.method_name="jobservice.jobcompleted"

誰がどのテーブルにクエリを実行しているか眺める#

ログシンクしたテーブルにこのクエリを発行すると、誰がいつ、どのテーブルを触ったのかがわかります。これで、Cloud IAM と見比べて過剰な権限が付与されていないか確認しましょう。

CREATE TEMP FUNCTION
  ADD_PROJECT_ID_IF_NEEDED(table_id STRING,
    project_id STRING)AS(CASE CHAR_LENGTH(table_id)-CHAR_LENGTH(REPLACE (table_id, ".", ""))
      WHEN 1 THEN CONCAT(project_id,'.',table_id)
      WHEN 2 THEN table_id
    ELSE
    ERROR('The format is not supported')
  END
    );
SELECT
  table_id,
  last_referenced,
  principal_email
FROM (
  SELECT
    CONCAT(project_id,'.',dataset_id,'.',table_id)table_id
  FROM
    < your-dataset >.__TABLES__)
FULL JOIN (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail principal_email,
    ADD_PROJECT_ID_IF_NEEDED(REGEXP_REPLACE(table_id, r"[\s`]", ""),
      protopayload_auditlog.servicedata_v1_bigquery.jobCompletedEvent.job.jobName.projectId)table_id,
    MAX(timestamp)last_referenced
  FROM
   < your-log-sync-dataset >.cloudaudit_googleapis_com_data_access
  INNER JOIN
    UNNEST(REGEXP_EXTRACT_ALL(LOWER(protopayload_auditlog.servicedata_v1_bigquery.jobCompletedEvent.job.jobConfiguration.query.query), r"(?:from|join)\s*(`(?:[\-\w]+\.)?\w+\.\w+`|(?:[\-\w]+\.)?\w+\.\w+\s|(?:[\-\w]+\.)?\w+\.\w+$)"))table_id
  GROUP BY
    table_id,
    principal_email)
USING
  (table_id)

Cloud IAM の現状分析の進め方#

泥臭く頑張る#

組織が拡大していく中で臭うポイントはこれです。

Cloud IAM の Web UI から過剰に付与された権限がある
メンバーがデフォルトの役割を持っている or メンバーが継承されていない

これらを見つけたら過剰な権限の剥奪と、同じ仕事をしている人をグルーピングしてデフォルトじゃない役割を作って付与できないか、継承関係にできないかを考えると良いです。