背景・目的
先日、BigQueryを試してみたという記事で、BigQuery(以降、BQと呼びます)上でクエリを実行してみましたが、BQのデータセキュリティについて整理してみます
まとめ
下記に特徴を整理します。
| 特徴 | 説明 |
|---|---|
| データガバナンスとは | 取得〜廃棄までのライフサイクルにおいての、データ管理のための原則 |
| データガバナンスプログラム | データアクティビティに関わるポリシー、手順、責任、制御の概要が明確に示される。 3つの主要要素がある ・人々によるデータポリシーの定義、同意、施工を可能にするフレームワーク ・オンプレミスシステムクラウドストレージ、DWHのすべてのデータセットの制御、監視、管理運営プロセス ・データポリシーのコンプライアンスを監督および管理するための適切なツールとテクノロジー |
| GCPのリソース管理 | ・全て階層構造になっている |
| リソース管理の最下位レベル | ・BQデータセット ・Cloud Storageバケット ・Compute Engine VM |
| 論理コンテナ | 下位レベルのリソースをグループ化する |
概要
データ セキュリティとデータ ガバナンスの概要を元に整理します。
データ ガバナンスは、取得から、その使用および廃棄に至るまでのライフサイクルにわたって、データを管理するための原則に則ったアプローチです。データ ガバナンス プログラムによって、データ アクティビティに関わるポリシー、手順、責任、制御の概要が明確に示されます。このプログラムによって、情報の収集、維持、使用、配布に際して、組織のデータに関する整合性とセキュリティ ニーズを確実に満たすことができます。また、従業員がデータの探索と活用を最大限に行えるようにします。
データの取り込みからデータを使用した有益な知見や情報の獲得に至るまで、いかなる組織においてもデータの管理とガバナンスが最重要事項であると考えられます。
3 つの主要要素を中心に据えたデータ ガバナンスの手法を構築することをおすすめします。
- 人々によるデータポリシーの定義、それへの同意、および施行を可能にするフレームワーク。
- オンプレミス システム、クラウド ストレージ、データ ウェアハウス プラットフォームのすべてのデータアセットの制御、監視、および管理運営のための効果的なプロセス。
- データポリシーのコンプライアンスを監督および管理するための適切なツールとテクノロジー。
- データガバナンスとは、取得〜廃棄までのライフサイクルにおいての、データ管理のための原則
- データガバナンスプログラムにより、データアクティビティに関わるポリシー、手順、責任、制御の概要が明確に示される
- 3つの主要要素
- 人々によるデータポリシーの定義、同意、施工を可能にするフレームワーク
- オンプレミスシステムクラウドストレージ、DWHのすべてのデータセットの制御、監視、管理運営プロセス
- データポリシーのコンプライアンスを監督および管理するための適切なツールとテクノロジー
データアクセス管理
従来、企業は境界セキュリティに依存して内部リソースを保護していました。境界セキュリティは、卵の殻のセキュリティまたは城と堀のセキュリティとも呼ばれ、脅威は壁の外側にのみ存在し、境界壁の内側にあるものはすべて信頼できると想定されます。しかし、攻撃者が内部ネットワークへのアクセスを獲得すると、ほとんど妨げられることなく他のシステムへの移動、貴重なデータアセットの探索が可能になり、企業にとってコストのかかる結果となることから、この想定は正しくないことが証明されています。
- 以前は、セキュリティの境界に依存して内部リソースを保護してきた。しかし一度破られると、自由にやられていた
攻撃者は、脆弱性や、従業員がインストールしたマルウェア、ソーシャル エンジニアリングなどの手段を通して内部ネットワークへのアクセスを獲得します。ただし、境界セキュリティ モデルに穴を開ける悪意のある外部エージェントだけが脅威であるわけではありません。信頼できる従業員であっても、内部ネットワークのアセットが適正に保護されていなければ、故意または無意識のうちにデータの変更、削除、または流出を発生させることがあります。
- 脆弱性やマルウェアなどから、内部NWのへのアクセスを獲得する
- 従業員でも、故意、無意識のうちにデータの変更、削除、流出を発生させることがある
また、エンタープライズ ネットワークの進化により、境界セキュリティがますます複雑なものになってきていることも無視できません。たとえば、次のような状況では、境界セキュリティを適用するのが困難になります。
- 従業員が、クライアント サイト、空港、自宅など、信頼できないネットワークからリモートで作業する必要がある場合。
- ベンダー、パートナー、請負業者がデータリソースへのより直接的なアクセスを必要とする場合。
- 会社のシステムの一部がクラウドに存在する場合。
- 境界セキュリティは複雑なものになっている
- 従業員がクライアント、サイト、空港、自宅など信頼できないNWからリモートで作業する
- ベンダー、パートナー、請負がデータリソースへの直接的なアクセス
- 会社のシステムの一部がクラウドに存在する
リソース管理
Google Cloud でワークロードを設定するには、Google Cloud のすべてのリソースを管理する構造や各プロダクトに固有のガイドラインに従う必要があります。
Google Cloud のリソースはすべて階層構造になっています。最下位レベルには、BigQuery データセット、Cloud Storage バケット、Compute Engine 仮想マシンなどの基本的なコンポーネントがあります。これらの下位レベルのリソースは、プロジェクトと呼ばれる論理コンテナにグループ化されます。プロジェクトは、すべての Google Cloud サービスの使用、課金の管理、プロジェクトのリソースに対するロールと権限の割り当てのための基盤を形成します。プロジェクトは、社内の異なる複数の部門やチームに対応するフォルダにグループ化されます。階層の最上位には、所属する会社を表す組織ノードがあり、複数のフォルダが格納されます。詳細については、リソース階層のドキュメントをご覧ください。
- GCPのリソースは全て階層構造になっている
- 最下位レベル
- BQデータセット
- Cloud Storageバケット
- Compute Engine VM
- 下位レベルのリソースは、プロジェクトと呼ばれる論理コンテナにグループ化される
- プロジェクトは、下記の基盤を形成
- GCPサービスの使用
- 課金の管理
- プロジェクトのリソースに対するロールと権限の割当
- プロジェクトは、社内の異なる複数の部門、チームに対応するフォルダにグループ化される
- 階層の最上位
- 所属する会社を表す組織ノード
- 複数のフォルダが格納される
Google Cloud の観点から見ると、BigQuery データセットはリソース階層の最下位レベルに存在します。BigQuery の観点から詳細を見ると、データセットはテーブルとビューへのアクセスの整理と制御に使用される上位レベルのコンテナです。基本的には、従来のオンライン トランザクション処理（OLTP）環境やオンライン分析処理（OLAP）環境のデータベースまたは名前空間と似ています。作成するときにデータセットのロケーションを選択します。クエリは、同じロケーションにあるデータセットのみを参照できます。したがって、最初にデータセットを作成してクエリを設計する際には、ロケーションを考慮することが重要です。
- BQデータセットはリソースの最下位
- データセット
- テーブルとビューへのアクセスの整理と制御に使用される
- 従来のOLTPとOLAPのDBと名前空間と類似している
- 作成時にデータセットのロケーションを選択する
- クエリ
- 同じロケーションにあるデータセットのみ参照する
- 最初にデータセットを作成してクエリを設計する際にはロケーションの考慮が必要
セキュリティ フレームワーク
Google の BeyondCorp イニシアチブでは、ゼロトラスト セキュリティに基づくセキュリティ フレームワークが確立されます。このフレームワークでは、動的アクセス制御の原則により、リソースへのアクセスを望むユーザーやデバイスについて次のように定義されます。
- GoogleのBeyondCorpイニシアチブ
- ゼロトラストセキュリティに基づくセキュリティフレームワークが確立される
- 動的アクセス制御の原則により、リソースへのアクセスを望むユーザやデバイスについて定義されている
- 認証情報で認証する必要がある。
- 当該リソースへのアクセスの許可を受ける必要がある。
- 暗号化を使用して通信する必要がある。
- 認証情報で認証
- 当該リソースへのアクセス許可
- 暗号化
これらの要件は、ユーザー、デバイスのネットワークの場所に関係なく、たとえば、企業のイントラネット内、公共の Wi-Fi からや、飛行機上のいずれであっても従う必要があります。
このドキュメントの以降のセクションでは、BeyondCorp で規定される原則を含む、データアセットへのアクセスを管理するためのコンセプトとおすすめの方法について説明します。また、この記事では、データの引き出しに対する保護手段として境界セキュリティ オーバーレイを実装する方法についても説明します。
認証と認可
認証とは、BigQuery とやり取りするクライアントの ID を判定および検証するプロセスを指します。認可とは、検証された ID が BigQuery やそのデータセットとやり取りする際の権限を判定するプロセスを指します。すなわち、認証は誰であるか、認可は何ができるかが確認されます。
- 認証とは、BQとやりとりするクライアントIDを判定、検証するプロセス
- 認可とは、検証されたIDを判定がBQやそのデータセットとやり取りする際の権限を判定するプロセス
- 認証は、誰であるか、認可とは何ができるか
ID
Google Cloud では、Cloud Identity が組み込みの ID プロバイダです。オンプレミスのデータ ウェアハウスから移行する場合は、Microsoft Active Directory などの既存の ID プロバイダと Cloud Identity との連携を検討してください。このようにすることで、既存の ID プロバイダを次のタスクの処理に引き続き使用できます。
- Cloud Identityが組み込みのIDプロバイダ
- 既存のIDプロバイダとの連携もできる
- ユーザーとグループのプロビジョニングと管理。
- シングル サインオンのセットアップ。
- 多要素認証の構成。
BigQuery のユーザーは人間の場合もあれば、BigQuery クライアント ライブラリまたは REST API を使用して通信する人間以外のアプリケーションである場合もあります。これらのアプリケーションでは、人間以外のユーザーを表すための特殊な Google ID であるサービス アカウントを使用して自己証明する必要があります。
Cloud Identity は、Identity and Access Management（IAM）と呼ばれる大規模なプロダクトの主要部分の 1 つです。
認証を受けたユーザーについて、BigQuery やそのデータセットとやり取りするために必要な権限が付与されているかどうかを判定する必要があります。
- BQユーザは、人間の場合、BQクライアントライブラリ、REST APIを使用するアプリケーションなどがある
- アプリケーションでは、特殊なGoogle IDであるサービスアカウントを使用して事故証明する必要がある
- Cloud Identityは、IAMと呼ばれる大規模な主要部分の1つ
- 認証を受けたユーザについて、BQやそのデータセットとやり取りするために必要な権限が付与されているか判定する必要がある
アクセス管理
認証に加えて、IAM では、BigQuery やそのデータセットに対する具体的な権限が付与された ID を認可するための集中管理が提供されます。IAM を使用すると、BigQuery のセキュリティ ポリシーを組織全体で管理し、プロジェクト レベルのアクセス権よりも粒度の細かなレベルで、BigQuery リソースに対するアクセス権を付与できます。
- BQやそのデータセットに対する具体的な権限が付与されたIDを認可するための集中管理
- IAMを使用すると、BQのセキュリティポリシーを組織全体で管理する
- プロジェクトアクセス権よりも粒度の細かなレベル管理できる
IAM では、権限によって、リソースに対して行うことができる操作が決まります。ただし、これらの権限を、Google ID（ユーザー、サービス アカウント、Google グループ、Google Workspace または Cloud Identity ドメイン）に直接割り当てることはできません。その代わりに、ロール（権限のコレクション）を Google ID に割り当て、ポリシー（JSON または YAML ファイルで宣言）を使用して、以下のいずれかの Google Cloud リソースレベルで、こうしたバインディングを適用します。
- 組織
- フォルダ
- プロジェクト
- リソースレベル（BigQuery データセット）
- IAMでは、GoogleIDではなく、ロールをGoogle IDに割り当てポリシーを使用してリソースにアクセスする
- ロールをGoogle IDに割り当てて、ポリシーを使用して下記のリソースにアクセスする
- 組織
- フォルダ
- プロジェクト
- リソースレベル（BigQuery データセット）
テーブルとビューの IAM
BigQuery では、テーブルやビューなどのデータセットのリソースへの完全アクセス権を付与しなくても、データセット内の特定の種類のリソースにロールを個別に割り当てることができます。テーブルレベルの権限により、データまたはビューにアクセスできるユーザー、グループ、サービス アカウントが決まります。
- データセット内の特定の種類のリソースにロールを個別に割り当てることができる
- テーブルレベルの権限により、データまたはビューにアクセスできるユーザ、グループ、サービスアカウントが決まる
ルーティンやモデルなどの個別のリソースにロールを適用することはできません。
または、承認済みビューを使用すると、基になるテーブルに対するアクセス権を付与せずに、特定のユーザーにクエリ結果へのアクセス権を付与できます。承認済みビューを使用すると、テーブル、列、行、セルといったリソースの下位レベルでアクセスを制限できます。列レベルのセキュリティおよび行レベルのセキュリティでは、どちらの形式もデータ分類が承認済みのビューよりも推奨されますが、ニーズと状況によってどちらのメソッドが使用に最適かが決まります。
エンドポイントの IAM
IAM を使用すると、ID に基づいて認証と認可を管理できます。また、BigQuery のようにパブリック エンドポイントを持つサービスの周囲にセキュアな境界も作成できます。このアクセス制御方法の詳細は、ネットワーク セキュリティに関するセクションをご覧ください。
- IAMを使用するとIDに基づいて認証と認可を管理できる
- BQのようなパブリックエンドポイントを持つサービスの周囲にセキュアな境界を作成できる
実装方法
移行作業の際には、多くの場合、オンプレミスのアプリケーションを BigQuery に接続する必要が生じます。アクセスが必要となるのは次の例のような場合です。
- BigQuery にデータを読み込むオンプレミスのデータ パイプライン。
- BigQuery に対するクエリまたはデータの抽出を行う、オンプレミスのレポート、分析、その他のビジネス アプリケーション。
ネットワーク セキュリティ
Virtual Private Cloud ネットワークは物理ネットワークに似ていますが、Google Cloud で仮想化されます。ネットワーク レベルでファイアウォール ルールを定義して、仮想マシン インスタンスとの間のトラフィックを制御します。ただし、BigQuery や Cloud Storage などの API ベースのサービスでは、ファイアウォール ルールを定義できません。これらの種類のサービスでは、トラフィックの制御に Google Virtual Private Cloud（VPC）Service Controls を使用できます。
- VPCネットワークは、Google Cloudで仮想化される
- NWレベルでファイアウォールルールを定義して、仮想マシンインスタンスとの間のトラフィックを制御する
- BQやCloud StorageなどのAPIベースのサービスはFWルールを定義できない
- トラフィックの制御には、VPC Service Controlsが使用できる
VPC では、BigQuery や Cloud Storage などのパブリック エンドポイントを持つ Google API ベースのサービスの周囲に、サービス境界が定義されます。サービス境界は、境界内のリソースと境界外のリソース間のデータの上り / 下りを制限することにより、データ引き出しのリスクを軽減します。これらの制御を正しく実装すると、不正なネットワークはデータやサービスにアクセスできなくなり、データを不正な Google Cloud プロジェクトにコピーできなくなります。境界内では引き続き自由な通信が可能ですが、境界を越えた通信は制限されます。
- VPCでは、BQやCloud Storageなどのパブリックエンドポイントを持つGoogle APIベースのサービスの周囲にサービス境界が定義される
- サービス境界は、境界内外のリソース間のデータの上り、行を制限することでデータの引き出しのリスクを軽減する
VPC Service Controls は、IAM アクセス制御と併用することをおすすめします。IAM では詳細な ID ベースのアクセス制御が提供されますが、VPC Service Controls ではより広範なコンテキスト ベースの境界セキュリティを使用できます。
- VPC Service Controlsは、IAMアクセス制御との併用を推奨
コンテキストアウェア アクセス制御
公共のインターネットからサービス境界内のリソースへの API リクエストは、その境界のアクセスレベルに従って、許可または拒否されます。リクエストは、IP 範囲やユーザー / サービス アカウント ID などのクライアント コンテキストに従って分類されます。たとえば、有効な認証情報を持つ BigQuery API リクエストが信頼できないネットワークから送信された場合、次の図に示すように、VPC ネットワークやサービス境界へのリクエストからのアクセスが拒否されます。
- 公共のインターネットからサービス境界内のリソースへのAPIリクエストは、その境界のアクセスレベルに従い、許可/拒否される
- 例えば、BQ APIリクエストが信頼できないNWから送信された場合、アクセス拒否される
サービス境界
VPC のサービス境界は、Google Cloud 組織レベルで構成されるため、セキュリティ ポリシーを集中管理できます。その組織やサービス（BigQuery API など）内の複数のプロジェクトを個々の境界に割り当てることができます。同じサービス境界内のプロジェクトとデータは、すべてのアクションが境界内にある限り、データを柔軟に処理、変換、およびコピーできます。次の図は、サービス境界の使用方法を示しています。
- VPCサービス境界は、Google Cloud組織レベルで構成される
異なる複数のサービス境界の Google Cloud リソースの間で通信する必要がある場合（たとえば、あるプロジェクトおよびサービス境界の BigQuery と別の境界の Compute Engine との間）、組織レベルで境界ブリッジを作成できます。境界ブリッジを使用すると、Google Cloud リソース間の通信が複数のサービス境界間で可能になります。Google Cloud プロジェクトが所属できるサービス境界は 1 つのみですが、複数の境界ブリッジの一部になることは可能です。
- 異なる複数のサービス境界のリソース間で通信する必要がある場合、組織レベルで境界ブリッジを作成できる
考察
今回、BQのデータセキュリティを中心にデータガバナンスについて整理しました。
次回以降は、実際に環境を作って試してみます。
参考