GCP Cloud IAM と BigQuery のデータセット、テーブル、View へのアクセス制御を確認してみた

2020.01.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、みかみです。

GCP & BigQuery 勉強中です。

データを取り扱う以上、個人情報の閲覧可能な範囲など、セキュリティには当然十分に気を付ける必要があります。

BigQuery ではどの単位でどうやってアクセス権を指定できるのかという観点から、Cloud IAM と BigQuery のアクセス制御について確認してみました。

やりたいこと

  • GCP の Cloud IAM はどんなものか確認したい
  • BigQuery に Cloud IAM でアクセス制御できるかためしてみたい
  • BigQuery ではテーブル単位でアクセス制御できるのか知りたい

GCP の IAM

GCP の Cloud IAM は、AWS の IAM と同じようなサービスと考えてよいのかな?

Google Cloud Platform(GCP)に備わっている Cloud IAM を使用すると、誰(ID)がどのリソースに対するどのようなアクセス権限(役割)を持つかを定義することで、アクセス制御を管理できます。

Cloud IAM では、メンバーに対してアクセス権を付与します。メンバーには次のタイプがあります。

・Google アカウント
・サービス アカウント
・Google グループ
・G Suite ドメイン
・Cloud Identity ドメイン

認証されたメンバーがリソースにアクセスしようとすると、Cloud IAM はリソースの Cloud IAM ポリシーをチェックして、アクションが許可されているかどうかを確認します。

権限によって、リソースに対して許可されているオペレーションが決まります。

ユーザーには権限を直接割り当てるのではなく、1 つ以上の権限を含む役割を割り当てます。

役割は権限のコレクションです。権限をユーザーに直接割り当てることはできないため、代わりに役割をユーザーに付与します。役割をユーザーに付与する際には、その役割に含まれているすべての権限がユーザーに付与されます。

誰がどの種類のアクセス権を持つかを定義するステートメントの集合である「Cloud IAM ポリシー」を作成することによって、ユーザーに役割を付与できます。ポリシーはリソースにアタッチされ、そのリソースがアクセスされると常にアクセス制御が強制されます。

ふむふむ。 AWS の IAM とほぼ同じと考えてよさそうです。

さらに GCP ではリソースの階層の概念があるので、

Cloud IAM ポリシーを、リソース階層の任意のレベル(組織レベル、フォルダレベル、プロジェクト レベル、リソースレベル)で設定できます。各リソースは親リソースのポリシーを継承します。組織レベルで設定されたポリシーはすべての子プロジェクトに自動的に継承され、プロジェクト レベルで設定されたポリシーはすべての子リソースに継承されます。特定のリソースに対して有効なポリシーは、そのリソースに設定されたポリシーとリソース階層の上位から継承されるポリシーを組み合わせたものです。

とのこと。ふむふむ。

では、実際に試してみます。

Cloud IAM で GCP のプロジェクトやサービスにアクセス制限してみる

まず、プロジェクトへのアクセス件がないユーザーでアクセスしてみると・・・

もちろんアクセスできません。

GCP コンソールの IAM の画面から、アクセス許可したいプロジェクトにユーザーを追加してプロジェクトの参照者の役割を付与します。

再度アクセスすると、ちゃんとプロジェクトを参照できるようになりました。

ですが、この状態では BigQuery のデータを閲覧できません。。

「BigQyery データ閲覧者」の役割を追加してみると・・・

無事、データが見れるようになりました。

今回はプルダウン選択だけで指定できる「事前定義済みの役割」を付与してみましたが、「カスタムの役割」で必要な権限だけを指定して、もっと細かい制限もできるそうです。

BigQuery の データセットやテーブルへのアクセス制御

続いて、BigQuery データへのアクセスについて、もう少し詳細確認してみます。

現時点では、テーブル、ビュー、列、行に対する権限を付与することはできません。データセットは、BigQuery でのアクセス制御をサポートする最下位レベルのリソースです。

なんと。。 Redshift や 他の RDB のように、GRANTでテーブル毎に権限付与みたいなことはできないんですね(知らなんだ@@;

ということは、データ種別ごとにユーザーの権限変更したい場合は、あらかじめデータセットを分けておかないといけないのですね。

データセットへのアクセス件を付与するには?

データセットの作成時にアクセス制御を適用するには、datasets.insert API メソッドを呼び出します。

Cloud Console、従来の BigQuery ウェブ UI、コマンドライン ツールでデータセットを作成している間は、アクセス制御を適用できません。

データセットの作成後は、次の方法でデータセットにアクセス制御を適用できます。

・Cloud Console または従来の BigQuery ウェブ UI を使用する
・bq update CLI コマンドを使用する
・datasets.patch API メソッドを呼び出す
・クライアント ライブラリを使用する

また、bigquery.datasets.create 権限を持つユーザーがデータセットを作成すると、そのデータセットに対する bigquery.dataOwner アクセス権がユーザーに付与されます。

ふむふむ。

データセットへのアクセスを許可してみる

先ほど Cloud IAM の確認で使用したユーザーで、BigQuery のデータを閲覧できない状態に戻して確認してみます。

今は、データセットが2つある状態です。

1つのデータセットにだけ、BigQuery のコンソールの「共有データセット」から、アクセス許可するメンバーを「BigQuery データ閲覧者」として追加します。

追加したメンバーでアクセスしてみると・・・

期待通り、許可したデータセットにだけ、アクセスできるようになりました。

データ閲覧の権限しかないので、テーブル作成しようとしてみるとちゃんとエラーになることも確認できました。

続いて、自分で作成したデータセットに対する権限も確認してみます。

データセットを作成するために、ユーザーに「BigQuery データ編集者」の役割を付与したうえで、新しいデータセットを作成してみます。

自分で作成したデータセットならばオーナー権限が付与されるので、アクセス可能でテーブルも作成できますが、許可していないデータセットには引き続きアクセス不可であることが確認できました。

まとめ(わかったこと)

  • GCP の Cloud IAM と AWS の IAM は同じ位置付けと考えてよさそう
  • Cloud IAM の「事前定義済みの役割」で、必要な権限を簡単にユーザーに付与することができる
  • Cloud IAM のポリシーはリソース階層に従って継承されるので、権限管理が楽にできそう
  • BigQuery ではテーブルやViewの単位でアクセス制御できない
  • BigQuery はデータセット単位までしかアクセス制御できないので、保持するデータ種別ごとにデータセットを分けるなどの設計が必要になりそう

参考