博報堂テクノロジーズでインフラエンジニア・ITアーキテクトをしている森です。
当社でのクラウド活用事例を元に、エンタープライズ向けナレッジをご紹介していきます。
はじめに
Analytics Hub による BigQuery のデータ共有は便利なサービスで、当社でも利用しています。
ただし、エンタープライズで利用する場合はセキュリティ面で留意すべき点もあり、当社での事例を参考としてご紹介します。
Analytics Hub による BigQuery のデータ共有について
近年のエンタープライズにおけるデータ共有のアーキテクチャとして、フルメッシュ型よりも中央集権的なデータ基盤（マスターデータ）を導入したハブアンドスポーク型を取り入れることが多くなっているのではないでしょうか。
私のチームで扱っているマスターデータについても、ハブアンドスポーク型を採用して個別システムへ展開を行っています。マスターデータを管理する基盤では、データウェアハウス（DWH）として優れたサービスである BigQuery を採用しています。そして、ハブである個別システムへのデータ共有として、BigQuery のマネージドな機能で Analytics Hub の機能を使っています。（Snowflake に詳しい方は Secure Data Sharing に類する機能だと考えて頂くとイメージしやすいです。）
Analytics Hub でのデータ共有のイメージを以下の図に記載します。具体的な操作手順などは、Google Cloud 公式ドキュメントなどでも詳しく説明されているためそちらをご参照ください。
① BigQuery の共有対象のデータセットで Listing を作成する。 作成した Listing に対して Subscribe 権限を 対象のGoogleアカウントへ付与する
② Subscribe 権限を付与された人（Googleアカウント）は、他の Google Cloud プロジェクトへ Subscribe する
③ Subscribe したプロジェクトの BigQuery にて Linkedデータセット として（参照権限のあるGoogleアカウントであれば）参照できる
流れとしては以上のようなシンプルなものですが、エンタープライズで実現する場合、セキュリティまわりで留意すべき重要なポイントがあります。
それらについて、具体的に2点を掘り下げてご紹介します。
ポイント① Analytics Hub での共有（Listing）と権限付与
Analytics Hub でのデータ共有は、特定の 【Googleアカウント】へSubscribe権限を付与することでデータ共有を行います。このとき、共有先の Google Cloud プロジェクトを指定することはできません。権限を付与された【Googleアカウント】は、権限のある任意の Google Cloud プロジェクトへ Subscribe することができます。
一方、【Googleアカウント】は「組織」に縛られず、複数の「組織」への権限を保持することもできます。これらの仕様により、権限があれば、共有元のデータセットのプロジェクトが所属する組織とは、”別の組織”に Subscribe することができるのです。これは便利である反面、セキュリティ上の注意しなければならないのです。
具体例
具体例を挙げて説明します。例えば、Googleアカウント（ht-gurumo@ht.co.jp）があるとします。このGoogleアカウントは以下の2つの組織のEditor権限を有しているとします。
- 組織１：ht.co.jp
- プロジェクト：ht-infra-master-data ← Analytics Hub でのデータ共有するマスターデータが置かれているプロジェクト
- データセット：ht-dev-sharing
- データセット：ht-prd-sharing
- プロジェクト：ht-infra-master-data ← Analytics Hub でのデータ共有するマスターデータが置かれているプロジェクト
- 組織２：gurumo.co.jp
- プロジェクト：gurumo-sandbox
組織１：ht.co.jp の プロジェクト：ht-infra-master-data に 共有したい BigQuery の データセット（ht-dev-sharing／ht-prd-sharing）があり、当該データセットの所有者が、Googleアカウント（ht-gurumo@ht.co.jp）を指定して共有（Listing）を行います。
次に、Googleアカウント（ht-gurumo@ht.co.jp）にて、コンソール上で任意のプロジェクトを指定、 [Explorer]ペインから [+Add data]を選択 - 右下の[Sharing(Analytics Hub)] を選択 - 左メニューチェックボックス[Private]を選択します。すると、Googleアカウント（ht-gurumo@ht.co.jp）へ権限付与されている共有（Listing）されたデータの一覧が表示されます。
Subscribe したいデータを選択して進めると、Subscribe 先のプロジェクト選択画面が表示されます。
共有元のプロジェクトによらず、Googleアカウント（ht-gurumo@ht.co.jp）が権限を保持している組織/プロジェクトが一覧に表示され選択することができます。
多くの人がGoogleアカウントをプライベートで利用しているように、そういった会社管理外のGoogleアカウントへ権限を付与してしまえば、会社管理外の「組織」にデータが共有することができてしまいます。この点によく留意して権限付与を行う必要があります。
一方、抑止が働く要素としては、”IAM以外の大概の操作ができる”ものとして扱われているEditorロールにおいて、Subscribeする権限（analyticshub.dataExchanges.subscribe）を保持していません。GoogleアカウントへOwnerロールもしくはSubscribe権限（analyticshub.dataExchanges.subscribe）を含む明示的なロールを付与する必要があります。
ポイント② Analytics Hub による BigQuery のデータ共有 と VPC Service Controls の関係
VPC Service Controls とは
エンタープライズシステムで、Google Cloud を利用する場合は、セキュリティ設計の一環として VPC Service Controls を検討・採用することが多いと思います。私たちのチームでもプロダクト用途の環境には原則採用しています。VPC Service Controls を入れることで、当該プロジェクトへのアクセスは、ホワイトリストに登録したもののみアクセスを許可できます。ホワイトリストとは具体的に以下のようなものが指定できます。
- 接続元を特定のIPに制限
- 接続元を特定のGoogleアカウントに制限
- 接続元を特定のGoogle Cloud プロジェクトへ制限
- 宛先のAPIを特定のものに制限
Analytics Hub による BigQuery のデータ共有 と VPC Service Controls の関係
盲点になりがちですが、Analytics Hub による BigQuery のデータ共有に VPC Service Controls の設定が影響します。VPC Service Controls が適用された環境で Analytics Hub による BigQuery のデータ共有を行う場合、ホワイトリスト登録が必要です。通常 VPC Service Controls の穴あけは行きの通信の向きで穴あけすれば、戻りの通信の考慮は不要です。しかし、ややこしいことに、Subscribe は戻りの穴あけも必要な仕様となっています。（図の①②だけでは不足で、③④の穴あけが必要。）
よって、穴あけ設定箇所としては、Publisher側とSubscriber側で合わせて4箇所の許可が必要になります。
なお、①～④でいずれも、許可が必要なAPIは以下の2つです。
- bigquery.googleapis.com
- analyticshub.googleapis.com
ホワイトリスト登録の方針
ホワイトリスト登録する方針の単位として大きく【ユーザ単位】及び【プロジェクト単位】が2つあります。
【ユーザ単位】の方針
ユーザ単位をGoogleアカウント個別で許可を行う設計とした場合、大規模な組織では複数の人からの要望が発生することが想定され、都度追加許可の必要が生じます。一方で、影響範囲などのリスクからネットワークの変更（の一環である VPC Service Controls ）はなるべく変更作業を控えたいものです。また前述の通り データ共有の権限付与をGoogleアカウント単位で行っているため、ここでも管理すると権限管理の箇所が2箇所となってしまい、よい設計といえません。【ユーザ単位】はGoogleアカウント個別ではなく [Any User account] で許可するのがよいでしょう。
【プロジェクト単位】の方針
前述の通り、Analytics Hub の機能で共有先のプロジェクトを絞ることができません。権限を付与したGoogleアカウントが不適切だった場合にリスクヘッジの役割は果たせる可能性があります。デメリットは本来 Analytics Hub で設定すべき制限を VPC Service Controls に分散してすることで、設計が分かりづらくなります。
権限を付与するGoogleアカウントを組織の Google Workspaceで払い出したものに限定するなどルールを厳格化することで、Analytics Hubとの通信においては【プロジェクト単位】に制限を設けない形もアリだと考えています。私のチームではこの点はケースバイケースで判断しています。
以下は【ユーザ単位】【プロジェクト単位】で制限を行わずに穴あけした場合の、Publisherプロジェクト側設定例です。
おわりに
Analytics Hub による BigQuery のデータ共有はとても有用な機能ですが、エンタープライズ環境では本記事で紹介したような点を考慮することで、よりセキュリティを高めて活用することができます。
本記事が参考になれば幸いです。