セキュアなBigQueryの 運用方法 July Tech Festa 2021 株式会社リクルート データ推進室　山田 雄 #JTF2021 #JTF2021_C

Hobby & Ability ビール/日本酒/ゴルフ/トミカ/子育て 山田　雄(Yamada Yu) @nii_yan 社会人歴 20年ぐらい データエンジニア/セキュリティエンジニア (データ/セキュリティ基盤の開発・運用) AWS/GCP/BigData/Mail/Hadoop...

BigQueryの責任共有モデル 出典:https://www.slideshare.net/GoogleCloudPlatformJP/cloud-onair-google-cloud-platform-2018222

BigQueryの責任共有モデル 出典:https://www.slideshare.net/GoogleCloudPlatformJP/cloud-onair-google-cloud-platform-2018222 BigQueryでユーザ側 の責任範囲

監査ログ

デフォルトで保存される日数 ログの永続化検討 ログのタイプ 保存日数 管理アクティビティ 400日 データアクセス 30日 システムイベント 400日 ポリシー拒否 30日

デフォルトで保存される日数 ログの永続化検討 ログのタイプ 保存日数 管理アクティビティ 400日 データアクセス 30日 システムイベント 400日 ポリシー拒否 30日 BigQueryの監査ログはDefaultだと30日で削除されてしまうの で、永続化を検討

データアクセスログは30日で削除されるため、 バックアップ用にBigQueryに保存する設定を行う。 データセット名は任意 他のプロジェクトにデータアクセスログを集約させ る場合はこちらの手順はスキップ ログ保存のためデータセットをBigQueryに作成

BigQuery データアクセスログの保存設定 シンク名は任意 エクスポート先は前前 ページで作ったデータ セットを指定 BigQueryを選択 注)プロジェクト内でBigQueryに対する操作を行ってない (ログが無い)場合、BigQueryが選択出来ません 何かしら操作をしてからシンク設定をしてください

権限による制御

BigQueryの権限制御は基本的にIAMを使用します ・権限制御範囲 org->folder->project->dataset->table->colum/row 特権での閲覧理由(監査など)が無い限り、 project単位またはdataset単位での権限付与がおすすめ projectをどの単位で作るかはこちらのベストプラクティスを参照 エンタープライズ企業のベスト プラクティス IAMによる権限制御

権限付与は人単位で行うと、運用工数が上がるため Googleグループを使用してグループ単位で権限を付与 IAMによる権限制御 dataset A dataset B dataset C 分析者 グループ 営業 グループ 管理者 グループ

複数のdatasetの特定のテーブルのみ閲覧したい場合は、 承認済みviewを使用する　 通常のviewだと、元テーブルに対しての閲覧権限が必要となる。 承認済みview Table1 Table2 Table3 Table4 datasetA datasetB datasetC View1 View4 承認済み viewを作成 新規 グループ datsetCに対する 権限を付与

テーブル単位での閲覧権限付与時のtips テーブルレベルでのみ権限をつけると、GUIのエクスプローラでは発見出来ず、 直接テーブル名まで入れるとクエリが出来る テーブル構造などをGUIで見ることも出来ない

IAMより細かい制御をしたい時に設定可能 時刻やリソース名でアクセス出来るリソースを絞る事が出来る BigQueryが対応しているのは時刻のみ ・20時以前のみアクセス出来る設定例 { "expression": "request.time.getHours(\"Asia/Tokyo\") <= 20", "title": "テスト", "description": "" } IAM Condition

GUI/API/SQLで権限付与が可能 いつ誰に何を付与したという記録を残すためにも、IaCなどでの 付与を推奨 terraformを使う場合、 google_project_iam_policyの取り扱いに注意 google_project_iam_policy内で宣言していないIAMはすべて 消えます 権限付与方法

ネットワークでの制御

IAMで制御をかけても、BigQueryにアクセス出来るサービスア カウントのクレデンシャル漏洩したら外部からアクセス出来 てしまう 悪意ある内部からのデータ持ち出しも可能 BigQueryでネットワークレベルの制限をかけたい場合には VpcServiceControlsを使用する さらにセキュリティを高めるために

VpcServiceControlsの概要 VpcServiceControls(以下vpc-sc)は BigQueryやGCSといった、 vpc+fwでは制限をかけられない プロダクトに対して、 IPやIDでのアクセス制限をかけられ るサービス ingress/egress双方の制限が可能 機密データありプロジェクト vpc-sc BigQuery Cloud Storage Firewall Compute Engine

2021/4にingress/egressそれぞれ別にruleを設定出来る機能が GAとなった ingress/egress rules ProjectA vpc-sc ProjectB vpc Compute Engine Cloud Storage 特定のプロジェクトから、 特定のAPIのみ叩くことを許可す るといった設定が可能に

project(11111)の test@...から、 project(22222)の GCSのAPIに対して getとcreateが可能 ingress/egress rules 設定例

ingress/egress fromプロジェクトの概念 ingress/egressで許可されたプロジェクト内の ネットワークからしか通信は出来ない ProjectA vpc-sc ProjectB vpc Compute Engine Cloud Storage ユーザがローカル PCから gcloud config set project しても通信は通らない

ingress/egress BigQueryの場合 BigQueryを使用した通信許可の場合、一方向の通信であっても、 双方向のAPI許可設定が必要となる ProjectA vpc-sc ProjectB vpc BigQuery Cloud Storage BigQueryからGCSへの 書き込み設定をする場合は ingress/egress双方で 下記の許可が必要(一部抜粋) - method: google.storage.buckets.testIamPermissions - method: google.storage.objects.delete - method: google.storage.buckets.get - method: google.storage.objects.create serviceName: storage.googleapis.com

VpcServiceControlsによる防御出来るパターン ・意図せぬIAMの設定 ・クレデンシャルの漏洩などによる外部からのアクセス ・内部犯による外部へのデータの持ち出し等 アクセス境界の作成、編集には専用の権限(AccessContextManager)が必要 (プロジェクトオーナーでも変更は不可能)

VpcServiceControlsの注意点 ● 境界内で使えるサービスは限られる ○ 新しいサービスは基本使えない ○ 制限を把握した上での設計が必要 ≠ 一般的なクラウド設計 ● 境界内で使えるサービスにおいても制限事項あり →利便性とのトレードオフが多く、 　　 vpc-scを使うと一般的なGCPとは別物になると考えたほうが良い 金融など絶対にデータを守りたい場合にはあっているが、 まずはvpc-sc以外での防御方法がないか吟味を行い どうしても使わないといけない場合のみvpc-scの選択を行う

GCPの静的外部IPアドレスは、解放すると即座に他のプロジェ クトで使われる可能性があります。 そのため、IPの解放タイミングには注意してください。 ✕ IPアドレス解放→vpc-scの設定変更 ○ vpc-scの設定変更→IPアドレス解放 IPについての取り扱い注意点

監査

BigQueryは権限設定で意図せず、 データをpublic公開してしまう場合があります データがpublic公開されている場合は以下のコマンドで 検知が可能 gcloud asset search-all-iam-policies \ --scope organizations/ORGANIZATION_NUMBER \ --query "policy:(allAuthenticatedUsers OR allUsers)" またはSecurityCommandCenterのGUI上でも確認が可能です public公開の検知

BigQueryは権限設定で個人のGmailアカウントなどにも閲覧権 限をつけることが出来ます こちらは組織ポリシーで、組織のドメイン以外には権限付与を 許可しないといった設定が可能です 組織ポリシーを使わない場合は、CloudAssetInventoryなどを 使用して権限を持っているアカウント一覧を抽出し、閲覧許可 をしていいドメインのみになっているかの監査が必要です 自組織以外のドメインからのアクセス

BigQueryのデータに意図せず機密情報が入ってないか、 Cloud Data Loss Prevention(DLP)を使用して確認することが 出来ます infoType 検出器リファレンス (リファレンスに無い場合は独自の辞書を追加可能) 個人情報検知 GUIからの確認方法

Tips

gcloud asset search-all-iam-policies \ --scope='projects/PROJECT_NAME' \ --query='policy : "USER_ACCOUNT" ' 呼び出しにはcloudasset.assets.searchAllIamPolicies 権限が必要 自分の権限の確認方法 CloudAssetInventoryのIAMポリシーの検索を使用することで、 一括で取得可能

gcloud asset analyze-iam-policy \ --project=PROJECT_NAME \ --full-resource-name='//bigquery.googleapis.com/projects/PROJECT_NAME/datasets/ DATASET_NAME/tables/TABLE_NAME' \ --permissions='bigquery.tables.get' \ --expand-groups テーブルにアクセス出来る人の確認方法 CloudAssetInventoryのPolicyAnalyzerを使用することで、 一括で取得可能

まとめ

まとめ IDでのアクセス制御とネットワークでの制御の大きく2つを 紹介させていただきました 他にもデータライフサイクルの管理や、余剰な権限の監査など やったほうが良いことは多くあります 会社や組織によってやるべき対策はそれぞれ違うと思いますの で、うまく組み合わせて安心・快適なBigQueryライフを送りま しょう

We Are Hiring! https://recruit-saiyo.jp/technology/