BigQueryのセキュリティ対策手順

16 minute read

風音屋アドバイザーの山田雄（@nii_yan）です。データ活用においてセキュリティ対策が最重要トピックであることは言うまでもありません。風音屋でBigQueryの導入支援を行うにあたって、どのようなセキュリティ対策を行っているのかをご紹介します。

この記事の全体像

この記事は2つのパートに分かれています。

最初に、BigQuery導入プロジェクトを始めるにあたって、セキュリティ観点でどのようなコミュニケーションが必要になるかを説明します。
次に、一般的な情報セキュリティ対策である「抑止」「予防」「検知」「回復」の4つの観点にもとづいて、どのようなシステム設計、オペレーション設計が必要になるのかを説明します。

キックオフ

BigQuery導入プロジェクトのキックオフに向けて準備します。「関係者に声をかける」「クラウドについて知ってもらう」「Google Cloud Platform（以下、GCP）について知ってもらう」「システム構成の雛形を描く」という手順で進めます。

1. 関係者に声をかける

最初にプロジェクト体制を整えます。リスクマネジメントの分野では3つのディフェンスラインが存在します。

1線：業務部門。業務やシステムを設計、運用します。データ活用部門（例：デジタルマーケティング部門）や情報システム部門が該当します。
2線：内部統制。リスク管理の規定を作り、モニタリングします。セキュリティ部門や法務部門が該当します。
3線：内部監査。 1線、2線とは独立した立場で現状を把握し、改善を促します。

1線の方々には、社内で指摘されてから事後的に対応するのではなく、予防的に働きかけることがトラブル防止に繋がることを伝えます。データを扱う以上、セキュリティやガバナンスを軽視するわけにはいきません。一見遠回りのようですが、早期に関係者を巻き込んでいただくことで、結果的に環境構築・運用が容易になります。

2. クラウドのセキュリティについて説明する

新規導入では「クラウドでオンプレミスと同等のデータ保護は可能か」と相談いただくことがあります。その場合は一般的なクラウドストレージのセキュリティについて説明します。

cloud_security

ゆずたそさんが風音屋の法人化前に作った図で、書籍『データマネジメントが30分でわかる本』にも掲載されています。

利用者制限や権限管理の機能を使えばアクセスに制限をかけることが可能です。
オンプレミス環境のように閉域網を擬似的に作ってデータの移動を制限することも可能です。
監査ログの収集・管理のためのマネージドサービスが提供されています。「誰がどのデータにアクセスしたのか」「誰がどの設定を変更したのか」を追跡できます。
作業ミスによる障害発生の可能性はゼロではありませんが、それはオンプレミスのサーバでも同じことです。同じ労力・コストであれば「自動化しやすい」「作業ミスを減らしやすい」「設定内容をチェックしやすい」という点がクラウドの強みです。

なお、BigQueryのようなPaaS（下図の右から3番目）では、インフラの保護はGCPが責任を負い、利用者はコンテンツやアクセスポリシーに専念せよと述べられています。

responsibility

「[Cloud OnAir] Google Cloud でセキュアにアプリケーションを開発しよう」資料より

オンプレミスだとこの緑色の領域を全て自分たちで構築、保守、運用しなければいけません。コスト、人員、期間、作業ミスといったリスクがあることを踏まえると、かなりの投資になります。

また、システム構築時に何らかの認証が必要であれば、認証の取得も必要になります。 GCPであれば公式ドキュメント「コンプライアンス状況」に記載されているように、世界中のセキュリティ標準を満たしている環境を即座に利用できます。

総じてクラウドサービスのほうが迅速に要件を満たせると言えるでしょう。

この項目の説明内容は@yoshimura_datamさん、@RyoMa_0923さん、@int_ttさん、@mic_psmさんにアドバイスをいただきました。

3. GCP公式ドキュメントを案内する

公式ドキュメント「エンタープライズ企業のベストプラクティス」は全員に一読してもらいましょう。 ID管理、アクセス制御、ネットワーク、監査ログといったセキュリティ担保で重要となる概念、機能が紹介されています。

4. システム構成の雛形を描く

データやツールの利用実態を把握して、BigQuery導入後のシステム構成を描きます。マーケティングツール、マルチクラウドDWH、SaaS型のBIツール、SaaS型のETL/ELTツールなど、周辺システムは多岐に渡ります。全体像を整理しておかないと「GCPのセキュリティは担保したのに他の環境でデータが丸見えになってしまう」といった事態になりかねません。

4つのセキュリティ対策

無事にプロジェクトを開始できたら、セキュリティの要件定義に進みます。一般的な情報セキュリティ対策は「抑止」「予防」「検知」「回復」の4つの観点で考えることが可能です。それぞれの観点についてBigQueryのセキュリティ対策要件を定義します。

1. 抑止

セキュリティ違反をしないように人間に働きかけて抑止します。

この項目の説明内容は書籍書籍『データマネジメントが30分でわかる本』著者の1人であるhase-ryoさんにアドバイスをいただきました。

1-1. 社内規定をもとに方針を決める

社内規定に沿うように1線（業務部門）と2線（内部統制）が協力して方針を決めます。

① 2線が既存のセキュリティ規約を1線に案内します。

② 1線は①を踏まえて実施方針を検討します。実施方針に迷う点、実情と社内規定がマッチしていない点があれば、2線に相談します。

③ 2線が相談に回答します。必要に応じて社内規定の見直しを検討します。

④ 1線、2線の両方が合意できるまでやり取りを繰り返します。

1-2. BigQuery利用時の規約を策定する

1-1をもとにBigQuery利用における規約を策定します。

1-1で2線が提示する社内規定は会社全体に向けたものです。特定のシステム（例：BigQuery）に限定しているとは限りません。
1-2で作る規約はBigQueryの利用者や管理者に向けたものです。

主に以下のような観点を記載します。

与件（関連規定）
- 法令：個人情報保護法、金融商品取引法（インサイダー規制）、電気通信事業法（通信の秘密）、GDPR
- 認証基準：PCI DSS、Pマーク
- 契約事項：利用規約、各取引先との契約書
- 社内規則：情報管理規定、セキュリティ細則
データの機密性レベル
- 社外公開
- NDAの範囲内で共有
- 社外秘
- 限定共有：プロジェクトメンバー、特定の役職・部署
データの規制カテゴリ
- PII（個人識別情報）
- PHI（個人健康情報）
- インサイダー情報（財務データなど）
- 競争上の優位性に関わる情報
- 契約上の制限に抵触する情報
- 企業秘密に関わる情報
- 公開している情報
アクセス制御の詳細
- 2-3, 2-4の内容（後述）
インシデント発生時のオペレーショナルレベル
- 土日祝日を問わずに緊急対応
- 営業日に通常案件を止めて優先対応
- 営業日に通常案件と同じように対応
メタデータの管理方法
- 上記の内容をどこでメタデータとして管理するか
- 誰がいつどこにメタデータを記入するか
- 誰がいつどうやってメタデータを監査するか

1-3. 規約を社内に周知する

BigQueryの利用者向けドキュメントに、1-1で作った規約へのURLを張っておきましょう。「BigQueryで何ができるのか」「SQLを書くときの注意点」といった項目に加えて「データのセキュリティについて」という項目を設けることをオススメします。 GoogleFormで簡易的な社内テストを作っておいて、そのテストを通過しないとBigQueryのアクセス権限を付与しない、といった運用ルールを設けるとさらに安全です。

2. 予防

セキュリティ違反ができないようにシステムを設定して予防します。

この項目の説明内容は『実践的データ基盤の処方箋』著者の1人である@tetsuroitoさんにアドバイスをいただきました。

2-1. データを暗号化する

BigQueryはデフォルトでデータが暗号化されています。 GCPが自動生成する暗号化キーの代わりに、利用者が独自にキーを発行して暗号化の際に指定することも可能です。

2-2. ホワイトリスト形式でデータを連携する

1線のチーム内レビューだけではなく、2線・3線の担当者がレビューできるようにETLの仕組みを作りましょう。

新規にデータを連携するときに SELECT * を使わずにカラムを明示する。
カラム説明、サンプリングデータ、タギング（PII有無など）といったメタデータを入力する。
SQLやYAMLで設定ファイルを管理したり、GUIのデータカタログで参照できるようにする。

AWS LambdaやCloud DataflowでETLのプログラムを書いてしまうと、プログラムの挙動を1つ1つ説明しないといけないので手間です。 SQLファイルを読み込んでプログラムを実行するなり、Input/Outputを確認できるようにテストコードを整備するといった工夫が考えられます。

2-3. Firewallを設定する

BigQueryではVPC Service Control（VPC SC）と呼ばれる機能を用いて、以下の組み合わせで設定を行います。

IPアドレス（例：特定のVPN）
アカウント
アクション（例：閲覧のみ許諾）
ingress / egress

クレデンシャルが漏洩してアカウントが乗っ取られるようなケースで有効な対応策となります。社内ネットワークやVPNのみ通信を許可すれば、外部からの接続を防ぐことができます。また、VPNへの接続をVDI（仮想デスクトップ）やMDM導入済みのPC端末に絞れば、作業端末から外部へのデータ持ち出しの対抗策となります。

BigQueryで個人情報を扱う場合はVPC-SCの導入を検討することになるでしょう。 GCPのプロジェクトオーナーでもVPC SCの設定は変更できないので、強固なセキュリティを実現できます。そのぶんVPCの取り扱いは難易度が高く、初期導入時は1つ1つの動作確認に時間がかかってしまう点にご注意ください。

2-4. アクセスを認可する

GCPではIdentity and Access Management（IAM）と呼ばれる機能を用いて、以下の組み合わせで設定を行います。

アカウント：GoogleWorkspaceドメイン、GoogleGroup、担当者のメールアドレス、ServiceAccount
アクション：作成、追加、閲覧、編集、削除
対象データ：組織 > フォルダ > プロジェクト > データセット > テーブル > 行 / 列
設定場所：IAM 管理画面、BigQuery UI、Data Catalog、Terraform、Cloud Deployment Managerなど

Googleアカウントにログインできる端末をVDI（仮想デスクトップ）やMDM導入済みのPC端末に絞れば、作業端末から外部へのデータ持ち出しの対抗策となります。

上記を設定するために以下を決める必要があります。

利用者の権限：誰が、どのデータに対して、どのようなアクションを行えるのか（オブジェクトのCRUD）
管理者の権限：誰が、どこで、そのルールをシステムに反映するのか（ユーザー権限のCRUD）

セキュリティ観点では「最小権限の原則」に準拠することが望ましいとされています。必要な人にだけ、必要な時にだけ、必要な場所でだけ、必要な権限だけを付与するという考え方です。

Appendix. IAM設定の具体例

公開されている事例だと@kusuwadaさんの記事「中規模プロジェクトでのGCP権限管理(アクセス制御)ベストプラクティス」が分かりやすいので、該当箇所を紹介します。

役割	管理方法	備考	権限の例
iam manager(GoogleGroupのオーナー)	専用Googleアカウント※1	各メンバーに対して、役割を変更させる権限を持つアカウント。役割のアサインに責任を持つ人のみで共有し、役割の変更(Groupへの追加・削除)はこのアカウントで実施する。	(GCP IAMなし)
owner(プロジェクトのオーナー)	専用Googleアカウント※2	プロジェクトリーダー、もしくはそれ相当の人でのみ共有するアカウント。普段は使用しない。	project owner
pi(顧客の個人情報(PI)にアクセス)	GoogleGroup		project.browser, storage.admin, bigquery.admin
operator(システム管理者)	GoogleGroup		project.browser, appengine.appAdmin, appengine.serviceAdmin, custom.bigqueryList
monitor(システム監視者)	GoogleGroup	普段はprojectメンバーはこのgroupにのみ所属する。	project.browser, appengine.appViewer, custom.appengineMonitor
developer(開発者)	GoogleGroup	開発用環境にのみ作成。比較的自由になんでもできる権限を付与する。	project.editor
その他、顧客企業やパートナー企業向けの役割	GoogleGroup	役割を分けるべき単位ごとにGroupを作成し、管理する。	適宜

事業ドメインや組織規模によって最適な設計は変わるので、内容をそのまま真似するのではなく、あくまで参考とするのがよいと思います。他の風音屋アドバイザーが「IAMとデータ構成の設計パターン」や「Terraformのサンプルコード」を用意しているので、どこかで紹介できればと思います。

Appendix. 異動や退職の注意点

担当者が異動・退職したり組織体制が変わるときに、権限が外れるような仕組みが必要です。

システムの工夫：GoogleGroup単位で権限を管理するとメンバーの追加や削除が容易になります。
オペレーションの工夫：社内に既にある「異動マニュアル」「退職マニュアル」に権限変更の手順を記載してもらいましょう。

また、所属はそのままでも案件が落ち着いてデータを見る必要がなくなることもあります。利用頻度が減ったアカウントをリスト抽出したり、定期的な棚卸しをカレンダーに入れておけると、いっそう安全です。

Appendix. 管理者権限の注意点

管理者権限については特に注意が必要です。クレデンシャル漏洩で管理者アカウントが乗っ取られてしまうと、一般アカウントの乗っ取りに比べて大きな被害が生じます。管理者アカウントは権限範囲が広いため、他の不正なアカウントに権限を付与したり、正規のアカウントが削除されてしまうことも考えられます。

デフォルトでは管理者権限を渡さないようにして、管理者の人数を制限しておきましょう。先進的な取り組みとしては「全ての権限をTerraformで管理して、GitHubのPull Requestで権限変更を依頼し、管理者はマージするだけ」という会社もあります。

Appendix. システム連携時の注意点

ETLツールやCI/CDなど何らかのアプリケーションからBigQuery・GCSにアクセスするときは、個人アカウントの権限ではなくService Accountで行います。

Service Accountのクレデンシャル（アクセスキーA）はKMS（Key Management Store）と呼ばれるシステムに置き、他の場所では持たないのが安全です。アクセスキーAとは別にKMSへのアクセスキーBを発行します。アクセスキーBの設定で、特定インスタンスや特定IP経由でしかKMSにアクセスできないようにします。仮にアクセスキーBが漏洩したとしても、該当のインスタンスに侵入されなければ、KMSにアクセスできません。アクセスキーAはKMSの中にしか存在しないため、BigQueryやGCSにアクセスすることはできません。

GitHub Actionsなど、GCPの外側でシステムを動かす場合は、Workload Identity Federationの利用を検討します。詳しくは公式ドキュメント「Workload Identity 連携の使用に関するベストプラクティス」を参照してください。

Appendix. table.export権限

BigQueryにはテーブルの全件エクスポートに関する「table.export」と呼ばれる権限があります。残念ながら「table.export」をOFFにしても SELECT * を実行するだけでデータを持ち出せてしまうのでご注意ください。 BIツールやPC端末でデータを閲覧できるということは、少なくともそこまではデータを持ち出せるということになります。

3. 検知

セキュリティ違反が起きたときに速やかに検知できるようにします。

この項目の説明内容はdatatech-jpを一緒に運営している@syou6162さんにアドバイスをいただきました。

3-1. CISベンチマークによる自動チェック

GCPではSecurity Command Centerにてリスク検知の結果がコンソールに表示されます。例えば「Public dataset」「Public bucket ACL」という検出機能タイプではBigQueryやGCSのデータが一般公開されていないことをチェックします。

検知内容はCISベンチマークというコンプライアンス基準に準拠しています。公式ドキュメント「脆弱性に関する検出」に説明があります。ルールをカスタマイズしたい場合は、Cloud Asset Inventoryや監査ログなどを組み合わせて独自で検知の仕組みを作ることになります。

リスク検知後はCloud Asset Inventoryで「該当データへのアクセス権を持つ人の一覧」や「該当アカウントが持つ権限の一覧」を確認できます。

3-2. DLPによる自動チェック

意図せずPII（個人識別情報）が混入していないかをチェックする方法としてCloud DLPというサービスが挙げられます。全件データをスキャンすると費用が過剰になってしまうので、利用時にはデータをサンプリングするのがよいでしょう。公式ドキュメント「サンプリングを使用したBigQueryに含まれる機密データの検査」に記載があります。ただ、DLPは100%の精度ではありませんし、検知であって予防ではないので、単体ではセキュリティ担保にならない点に注意してください。

3-3. 定期監査

どれだけシステムやルールを整備しても「ルールが守られていない」「忘れられる」「無意識のうちに違反してしまう」といったインシデントは水面下で起きます。 3線（内部監査）の担当者と協力して、定期的に監査を行うようにスケジュールを確保しましょう。

3-4. 監査ログ

GCPの操作内容をデータアクセス監査ログ（以下、監査ログ）として保存できます。

監査ログを見れば「誰がどのデータにアクセスしたのか」「誰がどの設定を変更したのか」を追跡できます。
はじめに適用した設定が適切なものであれば、その後に不自然な変更がなされてないことを監査ログで担保できます。

デフォルトの設定から以下を変更しておきましょう。

監査ログの保存期間を伸ばす。30日でCloud Loggingのログが消えてしまうため、GCSやBigQueryに監査ログを自動エクスポートする。
GCSバケットやBigQueryデータセットのアクセス権限を変更して、監査ログの変更・削除をできないようにする。

設定変更の方法は公式ドキュメント「監査ログの保存とルーティング」を参照してください。

4. 回復

セキュリティインシデントの発生時には、あるべき状態に速やかに回復できるようにします。

4-1. インシデント対応フロー

何らかの被害を受けた状態、または被害を受ける可能性がある状態をインシデントと呼びます。

外部攻撃：マルウェア感染や不正アクセスなど。
内部不正：悪意を持った従業員によるデータの持ち出しなど。
規定違反：個人情報の閲覧権限の設定ミスなど。

あらかじめインシデントの対応フローを決めておきましょう。インシデントを検知したら速やかに関係者にエスカレーションを行えるようにしておくとよいですね。

incident_report

ゆずたそさんの「Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops」から引用。

Appendix. 影響範囲の調査

業務やシステムがBigQueryに依存していると、データの復旧や削除で予期せぬ影響が起きてしまうかもしれません。監査ログを活用してBigQueryの利用状況を調査できるようにしておきましょう。

Appendix. ポストモーテム

インシデント対応後には振り返りが大事です。ポストモーテム（事後検証報告書）を作って、組織の学びに活かしましょう。

4-2. データの復旧

BigQueryにはタイムトラベルと呼ばれるバックアップ機能があります。公式ドキュメント「タイムトラベル期間を構成する」によると、デフォルト期間は7日となっています。残念ながらバックアップ期間の延長はできません。

7日より前まで復旧したいとのことであれば、BigQueryのテーブルスナップショット機能などでバックアップを定期的に作成しておきましょう。 GCPブログ「BigQueryのテーブルスナップショットで、スピーディで簡単かつ経済的なデータのバックアップが可能に」という紹介記事があります。

4-3. データの削除

不適切なデータが混入した場合はGCPに問い合わせて完全削除を依頼します。データの復旧ができたり、監査ログに記録されるため、GCPユーザー側では完全削除は出来ません。

自社にとってのベストを見つけよう

BigQueryのセキュリティ対策について「キックオフ前に関係者に伝える内容」「要件定義で決める内容」を紹介しました。

極端なことを言ってしまうと、従業員が悪意を持ってスマートフォンでPCモニターを撮影すれば、簡単に情報を流出できてしまいます。そういった経路まで完全に遮断するには、オフィスの入室時に持ち物を検査したり、データアクセスの専用部屋を物理的に用意しなければいけません。どこまでコストをかけてどこまでセキュリティを守るのかは企業によって異なります。全てを100点にするのではなく、自社にとってのベストを見つけ出すのがよいと思います。

風音屋では他のアドバイザーたちと毎日のようにディスカッションしながら企業のパターンに応じたベストプラクティスを模索しています。興味のある方はぜひお問い合わせしてください。

参考資料

Twitter Facebook LinkedIn