データ ウェアハウスの BigQuery への移行: データ ガバナンス

このドキュメントは、オンプレミスのデータ ウェアハウスの BigQuery への移行について説明するシリーズの一部です。このドキュメントは、必要となるデータ ガバナンスやデータ制御の理解に役立つ情報を提供します。

移行についてのシリーズは、次のように構成されています。

はじめに

データ ガバナンスは、取得から、その使用および廃棄に至るまでのライフサイクルにわたって、データを管理するための原則に則ったアプローチです。データ ガバナンス プログラムによって、データ アクティビティに関わるポリシー、手順、責任、制御の概要が明確に示されます。このプログラムによって、情報の収集、維持、使用、配布に際して、組織のデータに関する整合性とセキュリティ ニーズの両方を確実に満たすことができます。また、従業員のデータの検出や使用の能力を最大化します。

データの取り込みからデータを使用した有益な知見や情報の獲得に至るまで、いかなる組織においてもデータの管理とガバナンスが最重要事項であると考えられます。

3 つの主要要素を中心に据えたデータ ガバナンスの手法を構築することをおすすめします。

  • 人々によるデータポリシーの定義、それへの同意、および施行を可能にするフレームワーク。
  • オンプレミス システム、クラウド ストレージ、データ ウェアハウス プラットフォームのすべてのデータアセットの制御、監視、および管理運営のための効果的なプロセス
  • データポリシーのコンプライアンスを監督および管理するための適切なツールとテクノロジー

次のセクションでは、Gartner の Data Governance Across the Data Lake Reference Architecture に基づいたデータ ガバナンス フレームワークと、その実装を可能にするツールとテクノロジーについて説明します。ガバナンスによって満たされるビジネスニーズとデータ ガバナンスの運用化に必要なプロセスに関する解説については、クラウドのデータ ガバナンスの原則とベスト プラクティスに関するホワイト ペーパーをご覧ください。

データアクセス管理

従来、企業は境界セキュリティに依存して内部リソースを保護していました。境界セキュリティは、卵の殻のセキュリティまたは城と堀のセキュリティとも呼ばれ、脅威は壁の外側にのみ存在し、境界壁の内側にあるものはすべて信頼できると想定されます。しかし、攻撃者が内部ネットワークへのアクセスを獲得すると、ほとんど妨げられることなく他のシステムへの移動、貴重なデータアセットの探索が可能になり、企業にとってコストのかかる結果となることから、この想定は正しくないことが証明されています。

攻撃者は、脆弱性や、従業員がインストールしたマルウェア、ソーシャル エンジニアリングなどの手段を通して内部ネットワークへのアクセスを獲得します。ただし、境界セキュリティ モデルに穴を開ける悪意のある外部エージェントだけが脅威であるわけではありません。信頼できる従業員であっても、内部ネットワークのアセットが適正に保護されていなければ、故意または無意識のうちにデータの変更、削除、または流出を発生させることがあります。

また、エンタープライズ ネットワークの進化により、境界セキュリティがますます複雑なものになってきていることも無視できません。たとえば、次のような状況では、境界セキュリティを適用するのが困難になります。

  • 従業員が、クライアント サイト、空港、自宅など、信頼できないネットワークからリモートで作業する必要がある場合。
  • ベンダー、パートナー、請負業者がデータリソースへのより直接的なアクセスを必要とする場合。
  • 会社のシステムの一部がクラウドに存在する場合。

既存のオンプレミスのエンタープライズ データ ウェアハウスから移行する場合、現状のアプローチでクエリへのアクセスやデータの表示をユーザーに許可すると、周到性に欠ける、複雑で維持費が嵩む、などの問題が生じるおそれがあります。BigQuery などのクラウドデータ ウェアハウスでは、セキュリティ フレームワークがマネージド サービス パッケージの一部となっているため、これに移行することで十全なセキュリティが提供されると同時に、お客様サイドではメンテナンスの負担を軽減できます。

この章の残りの部分では、Google Cloud および BigQuery でデータアクセス管理を実現する方法を紹介し、詳細を説明します。その目的は、エンタープライズ データ ウェアハウスへの移行によって、このセキュリティ フレームワークから何が得られるかについての概要を紹介することです。

リソース管理

ワークロードを Google Cloud に移動するには、Google Cloud のすべてのリソースを管理する構造や各プロダクトに固有のガイドラインに従う必要があります。

Google Cloud のリソースはすべて階層構造になっています。最下位レベルには、BigQuery データセット、Cloud Storage バケット、Compute Engine 仮想マシンなどの基本的なコンポーネントがあります。これらの下位レベルのリソースは、プロジェクトと呼ばれる論理コンテナにグループ化されます。プロジェクトは、すべての Google Cloud サービスの使用、課金の管理、プロジェクトのリソースに対するロールと権限の割り当てのための基盤を形成します。プロジェクトは、社内の異なる複数の部門やチームに対応するフォルダにグループ化されます。階層の最上位には、所属する会社を表す組織ノードがあり、複数のフォルダが格納されます。詳細については、リソース階層のドキュメントをご覧ください。

Google Cloud の観点から見ると、BigQuery データセットはリソース階層の最下位レベルに存在します。BigQuery の観点から詳細を見ると、データセットはテーブルとビューへのアクセスの整理と制御に使用される上位レベルのコンテナです。原則的に、データセットは従来の OLTP や OLAP 環境のデータベースまたは名前空間と似ています。作成するときには、データセットのロケーションを選択します。クエリは同じロケーションにあるデータセットのみを参照できるため、データセットの初期作成時およびクエリの設計時はロケーションを考慮することが重要です。

セキュリティ フレームワーク

Google の BeyondCorp イニシアチブでは、ゼロトラスト セキュリティに基づくセキュリティ フレームワークが確立されます。このフレームワークでは、動的アクセス制御の原則により、リソースへのアクセスを望むユーザーやデバイスについて次のように定義されます。

  1. 認証情報で認証する必要がある。
  2. 当該リソースへのアクセスの許可を受ける必要がある。
  3. 暗号化を使用して通信する必要がある。

これらの要件は、ユーザー、デバイスのネットワークの場所に関係なく、企業のイントラネット内、公共の Wi-Fi から、飛行機上のいずれであっても従う必要があります。

この記事の以降のセクションでは、BeyondCorp で規定される原則を含む、データアセットへのアクセスを管理するためのコンセプトとベスト プラクティスについて説明します。また、この記事では、データの引き出しに対する保護手段として境界セキュリティ オーバーレイを実装する方法についても説明します。

認証と認可

認証とは、BigQuery とやり取りするクライアントの ID を判定および検証するプロセスを指します。認可とは、検証された ID が BigQuery やそのデータセットとやり取りする際の権限を判定するプロセスを指します。すなわち、認証は誰であるか、認可は何ができるかが確認されます。

ID

Google Cloud では、Cloud Identity が組み込みの ID プロバイダです。オンプレミスのデータ ウェアハウスから移行する場合は、Microsoft Active Directory などの既存の ID プロバイダと Cloud Identity との連携を検討してください。このようにすることで、既存の ID プロバイダを次のタスクの処理に引き続き使用できます。

  • ユーザーとグループのプロビジョニングと管理。
  • シングル サインオンのセットアップ。
  • 多要素認証の構成。

BigQuery のユーザーは人間の場合もあれば、BigQuery クライアント ライブラリまたは REST API を使用して通信する人間以外のアプリケーションである場合もあります。これらのアプリケーションでは、人間以外のユーザーを表すための特殊な Google ID であるサービス アカウントを使用して自己証明する必要があります。

Cloud Identity は、Identity and Access Management(IAM)と呼ばれる大規模なプロダクトの主要部分の 1 つです。

認証を受けたユーザーについて、BigQuery やそのデータセットとやり取りするために必要な権限が付与されているかどうかを判定する必要があります。

アクセス管理

認証に加えて、IAM では、BigQuery やそのデータセットに対する具体的な権限が付与された ID を認可するための集中管理が提供されます。IAM を使用すると、BigQuery のセキュリティ ポリシーを組織全体で管理し、プロジェクト レベルのアクセス権よりも粒度の細かなレベルで、BigQuery リソースに対するアクセス権を付与できます。

IAM では、権限によって、リソースに対して行うことができる操作が決まります。ただし、これらの権限を、Google ID(ユーザー、サービス アカウント、Google グループ、Google Workspace または Cloud Identity ドメイン)に直接割り当てることはできません。その代わりに、ロール(権限のコレクション)を Google ID に割り当て、ポリシー(JSON または YAML ファイルで宣言)を使用して、以下のいずれかの Google Cloud リソースレベルで、こうしたバインディングを適用します。

  • 組織
  • フォルダ
  • プロジェクト
  • リソースレベル(BigQuery データセット)

BigQuery ロールは、前述のリソースレベルのいずれかで次のようにバインドできます。

  • プロジェクト レベルでは、ユーザーに adminmetadataViewerjobUser のロールを付与できます。
  • BigQuery データセット リソースレベルでは、ユーザー(またはビュー)に dataEditordataOwner、または dataViewer のロールを付与できます。

承認済みビューは、基になるテーブルへのアクセスを許可することなく特定のユーザーと結果を共有するクエリとして定義されます。承認済みビューを使用すると、テーブル、列セルといったリソースの下位レベルでアクセスを制限できます。

IAM を使用すると、ID に基づいて認証と認可を管理できます。また、BigQuery のようにパブリック エンドポイントを持つサービスの周囲にセキュアな境界も作成できます。このアクセス制御方法の詳細は、ネットワーク セキュリティに関するセクションをご覧ください。

実装方法

移行作業の際には、多くの場合、オンプレミスのアプリケーションを BigQuery に接続する必要が生じます。アクセスが必要となるのは次の例のような場合です。

  • BigQuery にデータを読み込むオンプレミスのデータ パイプライン。
  • BigQuery に対するクエリまたはデータの抽出を行う、オンプレミスのレポート、分析、その他のビジネス アプリケーション

BigQuery のデータにアクセスするには、アプリケーションは認証情報を取得して API リクエストとともに送信する必要があります。オンプレミスのアプリケーションまたはその他のパブリック クラウドから BigQuery API とやり取りする際は、有効期間の短い認証情報も長い認証情報も使用できます。

BigQuery クライアントは、サービス アカウントまたはユーザーの認証情報を使用して認証を受ける必要があります。クライアントの認証後は、アクセス トークンか、アクセスキーを BigQuery API に渡す必要があります。次に、これらの認証情報がチェックされ、クライアントに対して適切な承認が与えられ、BigQuery とのやり取りに十分な IAM 権限がクライアントに確実に付与されるようにします。

有効期間が短い認証情報

有効期間が短い認証情報は、作成したときに指定された短い期間(OAuth2.0OpenID の場合は最大 1 時間、JWT の場合は最大 12 時間)の後に自動的に期限が切れます。サービス アカウントキーの管理を避けたい場合、または Google Cloud サービスに期限付きの許可を発行したい場合は、有効期間が短い認証情報を使用します。

以下の種類の認証情報は、短期の有効期間をリクエストできます。

  • OAuth 2.0 アクセス トークン
  • OpenID Connect ID トークン
  • 自己署名 JSON ウェブトークン(JWT)
  • 自己署名バイナリ オブジェクト(blob)

有効期間が短い認証情報を使用すると、オンプレミスのサービスが BigQuery と通信する際に、Cloud Identity ID が必要なくなります。Google Cloud Identity ID は有効期間が短い認証情報を取得する必要がありますが、トークンを使用しているアプリケーションやサービスは Google Cloud ID を必要としません。

有効期間が長い認証情報

有効期間が長い認証情報(サービス アカウントの秘密キー、更新トークン付き OAuth 2.0 アクセス トークンなど)は、削除されるか取り消されるまで BigQuery へのアクセスが許可されます。サービス アカウントの秘密鍵は、作成されると永続化するため更新する必要はありません。OAuth 2.0 アクセス トークンは、有効期限が切れても、関連付けられた更新トークンを使って有効期間が長い認証情報として使用できます。この更新トークンを使用すると、更新トークンがアクティブである限り、(再認証の必要なしで)新しいアクセス トークンをリクエストできます。このプロセスは、Google の OAuth 2.0 Playground で説明されています。

有効期間の延長を考慮すると、リモート クライアント マシンやワーカーノードでは、この認証情報を慎重に管理する必要があります。権限のあるユーザーのみにアクセスを制限する安全な場所に保存することをおすすめします。認証情報をコード リポジトリに保存しないでください。コードにアクセスできる人はだれでも、ユーザーの鍵へのアクセスが可能であるため、ユーザーのデータへのアクセスも可能になります。認証情報が漏洩した場合は、サービス境界を使用して、外部からの迷惑アクセスのリスクを緩和できます。

有効期間が長い認証情報の保存におすすめの戦略は次のとおりです。

  • 鍵管理サービス(KMS)がある(またはない)クラウド ストレージ
  • セキュアなオンプレミス ストレージ
  • サードパーティ製の秘密管理ソリューション

サービス アカウントの秘密鍵は、個々のサービス アカウントに属する暗号署名付きの JWT です。署名付きの JWT は署名なしトークンとして直接使用されるため、Google の承認サーバーへのネットワーク リクエストは不要です。鍵は自動的に期限切れにならず、リークされてもアクセスが取り消されることがないため、鍵を定期的にローテーションすることはセキュリティ上のベスト プラクティスです。このプロセスでは、新しい鍵を生成し、承認されたすべてのユーザーとサービスが新しい鍵にアクセスできるようにして、古い鍵を削除する必要があります。鍵のローテーションにより、鍵が不正使用された場合に、漏洩が検出されていなくても、不正使用された鍵の BigQuery へのアクセスが自動的に取り消されます。

非匿名の BigQuery リクエスト

プライベート サービス アカウントキーと更新トークンの両方が、サービス アカウントを使用した認証をサポートしています。複数のユーザーとアプリケーションが同じサービス アカウントにアクセスできる場合があります。したがって、それらのリクエストは、ユーザーやアプリケーションが識別されないため匿名になります。ただし、BigQuery などの Google Cloud リソースへのアクセスは、リクエストを開始したそれぞれのユーザーに関連付ける必要があると、多くの企業顧客から要求されています。この場合、Google Cloud Token Broker または OAuth 2.0 ユーザーの 3-legged フロー(3LO)を使用して、サービス アカウントではなくエンドユーザーの代理として認証できます。

Google Cloud Token Broker は、Hadoop ワークロードのエンドツーエンド Kerberos セキュリティと IAM 統合を実現します。オンプレミス環境では、すべての ID は、Kerberos を使用してオンプレミスのキー配布センター(KDC)で認証します。KDC は、その ID(つまり「プリンシパル」)を、Active Directory や Open LDAP などの唯一の正確な情報源と同期します。Google Cloud Token Broker は、Kerberos ID を Google Cloud Identities にマップし、認証された Kerberos プリンシパルが BigQuery などの Google Cloud リソースにアクセスできるようにします。Kerberos プリンシパルが承認されている場合、Google Cloud Token Broker は、有効期間が長い更新トークンを使用してアクセス トークンを生成します。そのアクセス トークンが、暗号化されてクライアントに渡されます。これにより、クライアントはこのアクセス トークンを使用して、Kerberos プリンシパルに関連付けられた API リクエストを作成できます。

Kerberos とともに Google Cloud Token Broker を使用すると、以下のメリットがあります。

  • Google Cloud へのすべてのリクエストが、リクエストを開始した個別のユーザーに関連付けられる。
  • 有効期間が長い認証情報がクライアント マシンやワーカーノードに保存されない。
  • 既存のオンプレミスのセキュリティ システムとユーザー ワークフローに対する変更の必要性が限定的である。

非匿名の API リクエストは、OAuth 2.0 ユーザーの 3-legged シナリオでも使用されます。2-legged フローでは、アプリケーションがサービス アカウントの認証情報を直接保持し、そのサービス アカウントの代理として BigQuery API を呼び出します。しかし、3-legged フローの場合、リソースの所有者が BigQuery リソースの認証情報を直接共有することなく、それらのリソースに対するクライアント アクセスを許可して、ユーザーの代理としてリクエストが行われます。これにユーザーの同意が要求される場合もあります。ユーザーの認証の後に、認証コードをアクセス トークンおよび更新トークンと交換できます。

ネットワーク セキュリティ

仮想プライベート クラウド ネットワークは物理ネットワークに似ていますが、Google Cloud で仮想化されます。ネットワーク レベルでファイアウォール ルールを定義して、仮想マシン インスタンスとの間のトラフィックを制御します。ただし、BigQuery や Cloud Storage などの API ベースのサービスでは、ファイアウォール ルールを定義できません。これらの種類のサービスでは、トラフィックの制御に Google Virtual Private Cloud(VPC)Service Controls を使用できます。

VPC では、BigQuery や Cloud Storage などのパブリック エンドポイントを持つ Google API ベースのサービスの周囲に、サービス境界が定義されます。サービス境界は、境界内のリソースと境界外のリソース間のデータの上り / 下りを制限することにより、データ引き出しのリスクを軽減します。これらの制御を正しく実装すると、不正なネットワークはデータやサービスにアクセスできなくなり、データを不正な Google Cloud プロジェクトにコピーできなくなります。境界内では引き続き自由な通信が可能ですが、境界を越えた通信は制限されます。

VPC Service Controls は、IAM アクセス制御と組み合わせて使用することをおすすめします。IAM では詳細な ID ベースのアクセス制御が提供されますが、VPC Service Controls ではより広範なコンテキスト ベースの境界セキュリティを使用できます。

コンテキストアウェア アクセス制御

公共のインターネットからサービス境界内のリソースへの API リクエストは、その境界のアクセスレベルに従って、許可または拒否されます。リクエストは、IP 範囲やユーザー / サービス アカウント ID などのクライアント コンテキストに従って分類されます。たとえば、有効な認証情報を持つ BigQuery API リクエストが信頼できないネットワークから送信された場合、次の図に示すように、VPC ネットワークやサービス境界へのリクエストからのアクセスが拒否されます。

有効な認証情報からの BigQuery API リクエストでも、信頼されていないネットワークからであれば、VPC ネットワークおよびサービス境界へのアクセスが拒否される場合がある。

サービス境界

VPC のサービス境界は、Google Cloud 組織レベルで構成されるため、セキュリティ ポリシーを集中管理できます。その組織やサービス(BigQuery API など)内の複数のプロジェクトを個々の境界に割り当てることができます。同じサービス境界内のプロジェクトとデータは、すべてのアクションが境界内にある限り、データを柔軟に処理、変換、およびコピーできます。次の図は、サービス境界の使用方法を示しています。

同じサービス境界内でデータを処理、変換、およびコピーする。

異なる複数のサービス境界の Google Cloud リソースの間で通信する必要がある場合(たとえば、あるプロジェクトおよびサービス境界の BigQuery と別の境界の Compute Engine との間)、組織レベルで境界ブリッジを作成できます。境界ブリッジを使用すると、Google Cloud リソース間の通信が複数のサービス境界間で可能になります。Google Cloud プロジェクトが所属できるサービス境界は 1 つのみですが、複数の境界ブリッジの一部になることは可能です。

ハイブリッド環境でのデータアクセス

オンプレミスとクラウドのハイブリッド環境では、オンプレミス ネットワーク用の限定公開の Google アクセスを構成して、サービス境界とオンプレミス環境の間の非公開通信を許可できます。これにより、オンプレミス環境から BigQuery データセットへのアクセスが可能になります。これらのリクエストは、Google Cloud との非公開接続を介して送信する必要があり、この接続は、ルートベースの VPN または Cloud Interconnect 接続のいずれかになります。この場合リクエストは公共のインターネットを通過しません。

この構成により、サービス境界がオンプレミス ネットワークから Google Cloud サービスに格納されたデータに拡張され、機密データが非公開に保たれます。この非公開通信の構成は、restricted.googleapis.com 上の API に対してのみ使用できます。次の図は、この構成の例を示しています。

オンプレミスのネットワークから Google Cloud サービスに格納されているデータにサービス境界を拡張する。

暗号化

オンプレミスのエンタープライズ データ ウェアハウスと比較して、Google Cloud と BigQuery でデータがどのように保存および転送されるかを確認する際は、セキュリティ フレームワークを再検討してみると効果的です。

BeyondCorp の動的アクセス制御の原則では、すべてのアクセスを暗号化する必要があると述べられています。したがって、データ保護の方法として暗号化を実施して、万一データが漏洩した場合に備えて、保存中または転送中のデータが読み取り可能にならないようにすることが不可欠です。このようにすることで、データを保護するための防御層が暗号化によって追加されます。

保存時の暗号化

Google Cloud はデフォルトで、データを保存時に暗号化します。お客様が追加で操作を行う必要はありません。Advanced Encryption Standard(AES)は、アメリカ国立標準技術研究所(NIST)が推奨するデータ暗号化の方法として使用されています。

BigQuery データセットのデータは、ディスクに書き込まれる前にいくつかのチャンクに分割されます。各チャンクは、一意のデータ暗号鍵(DEK)で暗号化されます。異なる鍵を使用することにより、非常にまれな DEK の不正使用が発生したとしても、「影響範囲」は、そのデータチャンク内に限定できます。これらの鍵は、一意の鍵暗号鍵(KEK)を使用して暗号化されます。暗号化された DEK は関連データの近くに保存されますが、KEK は Cloud Key Management Service(KMS)に一元的に保存されます。この鍵管理の階層的な方法は、エンベロープ暗号化と呼ばれます。詳細は、保存時の暗号化の記事の鍵管理に関するセクションをご覧ください。

次の図は、保存時の暗号化の仕組みを示しています。

保存データの暗号化

デフォルトでは、すべての鍵が Google によって管理されます。ただし、鍵を自分で管理することもできます。この手法は、顧客管理の暗号鍵(CMEK)と呼ばれます。この手法では、対称暗号鍵の作成、ローテーション、自動ローテーション、および破棄に Cloud KMS が使用されます。BigQuery で CMEK を使用する方法の詳細ついては、Cloud KMS 鍵によるデータの保護をご覧ください。

転送データの暗号化

Google Cloud では、Google または Google の代理者が管理する物理的な境界の外側をデータが移動する際に、転送中のすべてのデータが暗号化され、認証の対象になります。これらの境界内で転送中のデータは認証の対象となりますが、暗号化されるとは限りません。

転送中のデータを暗号化すると、接続が確立され認証された後に、次のような方法によって潜在的な攻撃者からデータを保護できます。

  • 第三者によって公共に提供されている、ネットワークの下位レイヤを信頼する必要をなくす。
  • 通信がインターセプトされた場合に、攻撃者によるデータへのアクセスを防止する

上位レベルの転送中の暗号化では、データは送信前に暗号化され、その後エンドポイントの認証が行われます。データが宛先に到達すると、データの復号と検証が行われます。言うまでもありませんが、使用されるセキュリティ方式は、保護される接続の種類によって異なります。このセクションでは、暗号化の使用による BigQuery との接続の保護を中心に説明します。

BigQuery は Google Cloud サービスであるため、ユーザーやアプリケーションがリクエストを送信すると、そのリクエストはまず Google フロントエンド(GFE)と呼ばれるグローバル分散システムに到達します。GFE は、着信 HTTP(S)、TCP、および TLS プロキシのトラフィックを終了し、DDoS 攻撃対策を提供します。また、トラフィックの任意のサービスへのルーティングと負荷分散を行います。

Google Cloud サービスとの間のトラフィックでは、追加のセキュリティ対策を講じる必要がある場合があることを考慮する必要があります。これらの手段は、アップストリームのプロセスとダウンストリームのプロセスを移行するときに重要になります。たとえば、ユーザーまたはアプリケーションから Google Cloud でホストされるカスタム アプリケーションへのリクエストは、いくつかの方法でルーティングできます。一般に、Cloud Load Balancing を使用している場合は、トラフィックが GFE を通過するため、このルートは前のカテゴリに分類されます。また、Cloud VPN を使用している場合は、接続が IPsec によって保護されます。一方、外部 IP アドレスやネットワーク ロードバランサの IP アドレスを使用したり、Cloud Dedicated Interconnect を介して VM に直接接続したりしている場合、デフォルトでは接続が暗号化されません。したがって、TLS などのセキュリティ プロトコルの使用を強くおすすめします。

Google Cloud が各接続フローの転送中の暗号化を処理する方法の詳細については、Google Cloud での転送データの暗号化をご覧ください。

暗号消去

Google がデフォルトで提供する暗号化に加えて、必要に応じて、アプリケーションに独自の暗号化を適用できます。たとえば、テーブル内の特定の列のデータマスキングや暗号消去が必要な場合です。

暗号消去(別名、暗号シュレディング)は、暗号化に使用された鍵を削除することによりデータを復元不可能にするプロセスです。データは復号できなくなるため、事実上削除されます。

暗号化されたデータ全体ではなく鍵のみが削除されるため、この削除方法は高速で永続的であり、次のような場合に一般的に使用されます。

  • 暗号化されたディスク、電話、データベース レコードなど、暗号化されたデータのサイズが鍵よりもはるかに大きい場合。
  • たとえば、多くのリポジトリに分散しているデータや変更不可能なストレージに存在するなど、暗号化されたデータの削除がコストがかかりすぎる、複雑である、または実行不可能である場合。

BigQuery には、鍵の作成AEAD 暗号化のコンセプトを使用したクエリ内のデータの暗号化復号の機能が用意されています。

データの検出

組織の規模を問わず、利用できるデータ量、種類、速度が拡大しています。このようなデータの急増から次のような複数の課題が生じています。

  • データの散在化の進行、整理が行き届かない、複数のデータ リポジトリに複製されている場合が多いなどの原因により、検出が困難になっている。
  • なんらかのデータを見つけたとしても、データの発生元、それが本当に探しているものに相当するか、ビジネス上の意思決定に十分な信頼性があるのかを明確にできない。
  • データの管理も難しい。データの所有者、データへのアクセス権を持つユーザー、データへのアクセス権を取得するプロセスが不明確である。

メタデータは、データを記述する属性で構成され、前述の疑問に答えるものです。メタデータの収集は、図書館のカードカタログの作成に似ています。図書館ではかつて、著者、出版年、版、トピックなどが記載された物理的なカードがすべての書籍に作成されていました。書籍のように、データには、所有者、発生元、処理日、品質評価などの属性のセットを添付することもできます。

従来、企業は、スプレッドシート、Wiki ページ、社内開発システム、サードパーティ ソフトウェアなど、いくつかの方法を使用してメタデータのキャプチャや整理をしようとしていました。一般に、手入力の必要性、学芸員による管理やメンテナンス、システムの互換性と範囲が課題になります。また、最終的な課題として、多くの場合はデータの検出とメタデータの収集が、人から人へと受け継がれる個人的な経験に依存した有機的なプロセスとなり、組織の成長に向けたスケーリングができないことが挙げられます。このような状況では、グループの外部にいるアナリストが、アクセス可能なデータを見つけ、その意義を理解することは困難です。

これらの内部的な課題に加えて、企業は、一般データ保護規則(GDPR)、バーゼル銀行監督委員会の諸原則 239(BCBS239)、医療保険の相互運用性と説明責任に関する法律(HIPAA)などによる、データに関するトラッキング、保護、報告を求める規制およびコンプライアンス要件の強化に直面しています。

Data Catalog はこれらの顧客ニーズに対応する Google Cloud のレスポンスと呼べるものです。これは、組織における Google Cloud 内のデータの検出、分類、理解を実現する、完全なマネージド / スケーラブル メタデータ管理サービスです。

Data Catalog のアーキテクチャは以下に基づいています。

  • メタデータ ストア: Cloud Spanner 上に構築された、すべてのメタデータ エントリを格納するためのグローバルに分散された強力な一貫性のあるデータベース。
  • リアルタイムおよびバッチ同期: 技術的なメタデータの自動取り込み。
  • Google 検索インデックス: Gmail と Google ドライブの検索強化と同じ技術を利用し、アクセス制御リスト(ACL)が組み込まれたスケーラブルでパフォーマンスに優れたシステムです。

Data Catalog によって、すべてのデータアセットに対するビューが統一されます。したがって、堅固なデータ ガバナンス プロセスを構築するための基盤となります。

次の図は、Data Catalog が BigQuery、Pub/Sub、および Cloud Storage に、メタデータ検索、およびデータ損失防止機能を提供するアーキテクチャを示す簡略図です。それぞれの機能については、後のセクションで説明します。

Data Catalog を使用した簡素化されたアーキテクチャにより、メタデータ、検索、およびデータ損失の防止を提供する。

メタデータ

適切なデータの検出と意思決定の推進を実現することが、データ検出プロセスの中核をなします。図書館の例えのように、本を見つけるには利用可能な図書館の本に関するメタデータが必要ですが、ビッグデータの世界では、検出を可能にするためにデータアセットに関するメタデータも必要です。

Data Catalog では、BigQuery、Pub/Sub、および Cloud Storage からメタデータを自動的に取り込むことができます。また、テクニカルとビジネスの 2 種類のメタデータ タイプが区別されます。

一方、テクニカル メタデータには、テーブル名、列名、説明、作成日などの情報が含まれます。このタイプのメタデータは、ソースシステムにすでに存在します。Data Catalog では、これらのアセットが作成されるたびに、テクニカル メタデータがインデックスに自動的に取り込まれ、その際に新しいデータアセットを手動で登録する必要はありません。

一方、データアセットには、列に個人を特定できる情報(PII)が格納されているかどうか、データアセットの所有者が誰であるか、削除期限や保持期限の日付、およびデータ品質スコアなど、暗黙的なビジネス コンテキストが関連付けられています。このタイプのメタデータは、ビジネス メタデータと呼ばれます。

ユーザーの役割が異なると、必要となるビジネス コンテキストのサブセットもそれぞれに異なるため、ビジネス メタデータはテクニカル メタデータよりも複雑です。たとえば、データ アナリストは ETL ジョブのステータスに関心を持ちます。ステータスには、正常に実行されたかどうか、処理された行数、エラーや事前警告が発生したかどうか、などがあります。これとは異なり、プロダクト マネージャーは、公開であるか非公開であるか、データがライフサイクル上のどこに位置するか(本番、テスト、QA の各環境)、データの完全性と品質など、データの分類に注目します。

このような複雑さに対処するため、Data Catalog では、ビジネス メタデータをテンプレートとしてグループ化できます。テンプレートは、属性と呼ばれるメタデータの Key-Value ペアのグループです。テンプレートのセットは、メタデータのデータベース スキーマに似ています。

メタデータタグは、テーブルと列の両方に適用できるテンプレートのインスタンスです。これらのタグを列に適用すると、ユーザーは、たとえば、特定の列に PII が含まれているかどうか、非推奨とされているかどうか、特定の数量の計算にどの式が使用されたか、などを判別できます。本質的に、ビジネス メタデータは、有意義な方法でデータを使用するために必要なコンテキストを提供します。

次の図は、サンプルの顧客テーブル(cust_tbl)とその列に付加されたいくつかのビジネス メタデータのタグを示しています。

サンプルの顧客テーブル。

Data Catalog には、直感的なユーザー インターフェースに加えて、技術ユーザーがメタデータに一括して注釈を付けたり取得するための API も用意されています。サポートされている言語は、Python、Java、および NodeJS です。この API を使用すると、メタデータ タスクをスケーリングできるだけでなく、プログラムで Data Catalog と統合することもできます。これにより、Data Catalog をバックエンドの一部として使用するカスタムのエンタープライズ アプリケーションを構築できます。

データアセットにメタデータを追加することはデータ検出の基礎ではありますが、それだけではまだ機能の半分にすぎません。もう半分は、テクニカル メタデータとビジネス メタデータの両方を使用して適切な結果を返す堅牢な検索機能を通じてアセットを検出する機能です。

Data Catalog では、ソースからのメタデータのすべてがインデックスに登録され、ユーザー フレンドリーな UI とプログラムによる統合のための API の両方から使用できるようにします。Google 検索のスタイルでは、メタデータと照合されるキーワードを使用することで機能を果たします。さらに、パワーユーザー向けのファセット検索も提供されます。ファセット検索では、直感的なフィルタと修飾された述語を使用して、テーブル、データセット、ファイル内のみの検索や、プロジェクト、組織、特定の Google Cloud プロダクト内のみの検索などを行うことで結果を絞り込むことができます。

Data Catalog の UI では、検索頻度の高い BigQuery テーブルの一覧も表示されます。この機能により、テーブルの詳細、スキーマ、BigQuery コンソールに簡単にすばやくアクセスできます。

アクセス制御

ユーザーがメタデータを検索して、データアセットを発見できるようにすることで、生産性、独立性、および取り組みを強化できます。ただし、ユーザーのすべてがあらゆるメタデータにアクセスできるわけではありません。適切なユーザーに適切なデータへのアクセス権があれば、従業員は各自のロールに関連するデータアセットのサブセットに集中でき、メタデータやデータの流出を防ぐことができます。

Data Catalog は IAM と統合され、どのユーザーが検索で選択されたデータアセットを見つけるか、アセットのビジネス メタデータを作成できるかを制御できます。

テクニカル メタデータの場合は、自動取り込みによってタグ付けされるデータに付与される権限セットと同じものがメタデータに適用され、アクセス許可の管理が簡素化されます。ユーザーにデータに対するアクセス権があれば、抽出されたテクニカル メタデータにもアクセスでき、Data Catalog の検索でデータアセットを見つけることができます。この方法は、データアセットが登録され、権限セットが個別に付与されるのを待つのとは異なり、手動の介入を必要としない実用的なデフォルトを提供します。

ビジネス メタデータの場合は、メタデータにアクセスできるユーザーまたはユーザー グループを定義します。これらのユーザーのなかには、メタデータとデータの両方にアクセスできるユーザー、どちらか一方のみにアクセスできるユーザー、どちらにもアクセスできないユーザーが存在します。

  • メタデータにアクセスできない場合、Data Catalog の検索でデータアセットを見つけることはできません。
  • メタデータにはアクセスできるが、データにはアクセスできない場合、データアセットを見つけることはできますが、データを読み取ることはできません。この機能により、ユーザーは基になるデータを公開することなく、有効なデータセットを発見できるため、セキュリティを損なうことなく組織のデータアセットの使いやすさが向上します。その後、ユーザーはデータ所有者にアクセス許可を要求できます。この要求は、ビジネスのユースケース、データの機密性、およびその他の要因に応じて承認または拒否されます。

このセクションでは、Data Catalog を IAM と統合して、メタデータに対するアクセス制御を実施する方法を紹介しました。さらに、ユーザーに Data Catalog のロールを付与することにより、Data Catalog プロダクト自体にアクセスできるユーザーを制御できます。データアセットへのアクセスを制御するには、IAMVPC Service Controls を組み合わせて使用します。詳細については、Data Catalog IAM のドキュメントをご覧ください。

リネージ

データ ウェアハウスでいう「リネージ」とは、データアセットが発生源から使用先に至るまでのパスを指します。データアセットの発生源は、第三者から提供される市場データなどの外部ソースや、顧客トランザクションを格納するリレーショナル データベースなどの内部ソースです。データアセットの使用先は、ダッシュボード、レポート、または API として公開されるデータフィードです。

これらすべてのユースケースで、使用先で提示されるデータが元のデータに適用されている変換を正確に反映していると確信できることが重要です。データ コンシューマが入手したデータを信頼できること、規制当局による報告データの検証と理解が可能であること、および内部関係者がビジネス プロセスとデータ処理パイプラインの相互関係のギャップを特定できることが重要です。

どのデータをキャプチャする必要があるかは、ビジネスケースの範囲によって異なります。元のデータソース、データ所有者、データアセットが変換されるビジネス プロセス、または変換時に関係するアプリケーションとサービスなどのメタデータを含めることができます。

こうした情報のキャプチャを手動で行うと、エラーが発生しやすく重要なビジネスケースでは基準化できません。したがって、プログラムの観点から、データのリネージにアプローチすることをおすすめします。

  • ビジネスまたは規制のニーズを満たすためにキャプチャするメタデータ属性のセットを決定します。
  • ビジネス メタデータをキャプチャするテンプレートを作成します。データカタログでは、doublestringbooleandatetimeenum といった 5 つのデータ型がサポートされ、これらを組み合わせて豊富なタグを作成できます。この最後のデータ型は、カスタム値のセットを使用して、データ変換の段階、または類似の列挙値を記述できます。
  • Data Catalog API を使用して、データ パイプラインの各関連ステップで関連するリネージ メタデータを記録します。

Data Catalog の代わりとして、CDAP の Google のマネージド バージョンである Cloud Data Fusion を使用してもデータ変換を実装できます。Cloud Data Fusion は、単一の制御された環境にデータ処理環境をカプセル化し、データセットおよびフィールド レベルでリネージを自動的に記録できるようにします。詳細については、オープンソースのリネージに関する CDAP のドキュメントをご覧ください。

データの分類と管理

エンタープライズ データ ウェアハウスでは、取り込まれるデータの量、速度、種類によって、データの分類と管理に課題が生じる可能性があります。

データ分類は、異なる複数の特性を使用して、データを種類、フォーム、カテゴリごとに分類するプロセスです。適切なガバナンス ポリシーを各種のデータに適用するには、データの効果的な分類が可能であることが不可欠です。

たとえば、ビジネス ドキュメントのコンテンツに応じて、非セキュア、機密、などの機密レベルで分類できます。これらは種類ごとに、管理に関する特定のポリシーなどを設定できます。たとえば、機密文書の場合、特定のユーザー グループのみにアクセスを可能にし、7 年間保存する必要があります。

データ管理には、考慮すべきいくつかの側面があります。

  • データ変更の管理: データのディメンションが変更されたときの影響を制御します。頻繁には変更されませんが、更新されたディメンションに対してファクト テーブルのデータの正確性が失われる場合があるため、変更により波及的な影響が生じる可能性があります。
  • 参照データの管理: 組織全体のすべてのシステムで参照データの正確性と整合性が保持されたビューを使用できるようにします。
  • 保存および削除: ユーザーがデータを変更または削除できないようにする方法、およびデータを自動的に期限切れにする方法。

BigQuery に移行する際は、Cloud Data Loss Prevention(DLP)などのデータ分類の自動化機能を活用してください。以下のセクションでは、Google Cloud でこれらのデータ分類と管理の課題に対処する際に利用できる機能と手法を紹介します。

データ損失防止

多くの組織で保持されているテーブルにはそれぞれ数百の列が含まれ、そうしたテーブルの数は数千に上ります。そうしたテーブルでは、列に Column_5 のように適切性に欠け、内容を示唆するものでもない名前が付けられていても、PII(個人を特定できる情報)が含まれる場合があります。実際にそのようなケースでは、PII を識別してそのデータに対してポリシーを適用することが困難になります。

Cloud DLP は、強力なデータ検査、データ分類、およびデータ匿名化プラットフォームを利用する手段を提供します。DLP API はデータを自動的にスキャンして、データカタログ タグを作成し、機密データを識別します。既存の BigQuery テーブル、Cloud Storage バケット、データ ストリームに対する利用が可能です。

Cloud DLP は、データをスキャンして、メール、クレジット カード番号、社会保障番号などの PII を識別し、99% などの信頼レベルで報告することで、大量のデータを自動的に処理できます。次のように操作することで、ETL / ELT パイプラインでの PII 認識を効率化できます。

  • 検疫バケットにデータを取り込みます。
  • Cloud DLP を実行して PII を識別します。これは、データセット全体をスキャンするか、データをサンプリングすることで実行できます。DLP API は、パイプラインの変換ステップや Cloud Functions などのスタンドアロン スクリプトから呼び出すことができます。この記事では、後者を使用した例を紹介します。
  • データをデータ ウェアハウスに移動します。

Cloud DLP には、パターン、形式、チェックサムを識別する 100 以上の検出項目がすでに定義されています。Cloud DLP には、マスキング、トークン化、仮名化、日付シフトなどをはじめとする、データを匿名化するツールのセットも存在します。また、辞書や正規表現を使用してカスタム検出項目も作成できます。「ホットワード」ルールを追加して検出結果の精度を高め、除外ルールを設定して誤検知の数を減らすことができます。

Cloud DLP を使用すると、データの分類や、適切な人への適切なアクセスの提供が可能になるため、データ ガバナンスが向上します。

マスターデータ管理

マスターデータは、組織全体で使用されるデータであり、参照データとも呼ばれます。マスターデータ アセットの一般的な例には、顧客、プロダクト、サプライヤー、場所、およびアカウントなどがあります。マスターデータ管理(MDM)は、組織全体でマスターデータが正確であり、整合性が保持されていることを確実にする一連の手順です。

さまざまなシステムや部門が適切に機能し、相互に通信 / 交流するには、データの正確性と整合性が重要になります。これらが損なわれると、同じエンティティに対して、組織の部門ごとに異なるレコードが設定され、高コストのエラーが発生するおそれがあります。たとえば、クライアントが自社のウェブサイト上でアドレスを更新したときに、請求部門が別のクライアント リポジトリからデータを読み取ると、以降の請求がこのクライアントに届かなくなってしまう可能性があります。

MDM においては、信頼できるシステムが特定のマスターデータ アセットの信頼できる情報ソースになります。理想的には、そのアセットの信頼できるシステムから、組織内の他のシステムがマスターデータを取り込むようにします。ただし、次のシナリオで説明するように、これは常に可能とは限りません。

信頼できるシステムとの直接通信

このシナリオの場合、システムは特定のマスターデータ アセットを管理している信頼できるシステムと直接的な通信を行います。信頼できるシステムはマスターデータの作成と更新を行いますが、組織内の他のシステムは常に信頼できる各システムからそのデータを取り込みます。

商品の会社全体の信頼できるシステムとして使用される商品情報管理(PIM)システム。

たとえば、上の図では、商品情報管理(PIM)システムが全社的に商品に関して信頼できるシステムになっています。顧客管理(CRM)システムなどの他システムが顧客マスターデータを必要とする場合は、PIM からデータを取得します。会社の顧客などのデータアセットについては、CRM システム自体が信頼できるシステムになる場合もあります。

この理想的なシナリオでは、複雑な変換パイプラインを必要とすることなく、それぞれの信頼できるシステムにマスターデータ アセットを保管できます。消費側のシステムがマスターデータの特定のサブセットのみを必要とする場合、または提供形式とは異なる形式でデータを必要とする場合、そのシステムがそのフィルタリングや変換を管理します。

単一ソースからのゴールデン コピー

このシナリオでは、消費側システムは信頼できるシステムと直接通信できません。これらの制限の背後にある理由は、たとえば次のようにさまざまです。

  • 信頼できるシステムに、組織全体からの大量のリクエストの処理に十分な容量または可用性がない場合。
  • システム間の通信が、セキュリティ ポリシーによって制限されているか、インフラストラクチャの制約によって実行不可能な場合。

これらの制限を打開するには、データ ウェアハウスを使用することで、マスターデータを消費側システムで使用できるようにします。クラウドに移行する際は、あらかじめ BigQuery によってリポジトリが提供されます。このリポジトリは、可用性に優れ高レベルの同時実行性に対応し、IAM ルールに従って組織内で広範にアクセスできます。したがって、BigQuery はゴールデン コピーをホストとして最有力候補になります。

ELT データ パイプラインを作成して、信頼できるシステムからマスターデータを読み取り、それをデータ ウェアハウスに読み込んでから、消費側に配布することをおすすめします。ETL パイプラインよりも ELT パイプラインの方をおすすめするのは、同じマスターデータ アセットに対するニーズが、消費側のシステムごとに異なる可能性があるためです。このため、最初はアセットを変更せず、まずデータ ウェアハウスに読み込み、次に各消費側システムに専用の変換を作成するという手順が合理的です。Google Cloud では、Dataflow を使用して、BigQuery にネイティブに接続できるパイプラインを作成できます。その後、Cloud Composer を使用して、これらのパイプラインをオーケストレートできます。

信頼できるシステムは、データアセットの正確な情報源として保持され、データ ウェアハウスにコピーされたマスターデータは、「ゴールデン コピー」と呼ばれます。データ ウェアハウスは、信頼できるシステムにはなりません。

信頼できるシステムは、データアセットの信頼できるソースであり続ける。

たとえば、上の図で、CRM システムは PIM システムのプロダクト データを直接リクエストできません。PIM システムからデータを抽出して、データ ウェアハウスにコピーします。変換を実行して、他のシステムに配信する ETL パイプラインを作成します。その他のシステムのうちの 1 つが CRM システムです。

システムがバッチで、または分析目的でマスターデータを取得する場合、BigQuery はゴールデン コピーの理想的な保管場所になります。ただし、マスターデータへのアクセスの大部分が単一行のルックアップを行うシステムから発生している場合、Cloud Bigtable など、これらの条件に応じて最適化される別のリポジトリを検討できます。両方のリポジトリを使用してバランスを取ることもできます。最もトラフィックの多いものがゴールデン コピーを保持します。常にゴールデン コピーのシステムからデータを抽出し、他のリポジトリと同期することをおすすめします。これを行うには、データ パイプラインを使用します。

複数ソースからのゴールデン コピー

これまでのシナリオでは、特定のマスターデータ アセットに対して 1 つの信頼できるシステムを使用していました。しかし実務では、組織内の複数のシステムを使用して、同一アセットの複数の異なる特性を保持する場合があります。たとえば、PIM システムが、寸法、重量、原産地など、商品情報の技術面およびロジスティクス面の正確な情報ソースになる場合があります。一方、色、販売チャネル、価格、季節性など、販売関連の商品情報の正確な情報ソースには、商品カタログ管理システムが使用される場合があります。また、以前は MDM の一部ではなかったシステムや、買収や合併によって組織に組み込まれたシステムなど、同じアセットに対して重複する属性を持つ異なるシステムが使用されることも一般的です。

このようなケースでは、次の図に示すように、複数のソースからのマスターデータをデータ ウェアハウスに保存されている統一的なゴールデン コピーにマージする、非常に複雑なパイプラインが必要になります。データは前のセクションの説明と同様の方法で消費側システムに配信されます。データ ウェアハウスが信頼できるシステムではなく、マスターデータのゴールデン コピーがあるリポジトリであることに変わりはありません。

複数ソースからのマスターデータを、データ ウェアハウスに保存された統一的なゴールデン コピーにマージする複雑なパイプライン。

Cloud Dataflow では、Directed Acyclic Graph(DAG)で表される複雑なパイプラインを構築するツールとして、Dataflow が適切に位置付けられています。このパイプラインによって、データが複数のソースから読み取られ、マージされた結果が BigQuery に書き込まれます。もう 1 つのオプションとして、Cloud Data Fusion などのビジュアル ツールを使用してパイプラインを作成する方法もあります。Cloud Data Fusion には、データソースやデータシンク用の多くのプラグインが用意されています。

変化が緩やかなディメンション

スタースキーマまたはスノーフレーク スキーマディメンション テーブルの属性は、変更されないか、まれにしか変更されないと想定されています。変更されない属性は、オリジナル属性と呼ばれます。このような例としては、生年月日やオリジナルのクレジット スコアがあります。属性の変更頻度が低い場合、その属性が属するディメンションは変化が緩やかなディメンション(SCD)と呼ばれます。SCD が変更されると、ファクト テーブルにある既存のデータは、SCD の以前のバージョンを参照する必要があります。したがって、SCD の履歴を保持する手段が必要です。

データ ウェアハウスを移行するときは、SCD の処理方法を組み込むか、既存の方法の改善を検討してください。

  • スキーマと Data Transfer フェーズでスキーマを進化させて、SCD が確実に考慮されるようにする。
  • パイプラインの移行段階で、バックフィルの出力の再計算、ロジックの変更による再処理、リネージの追跡などのシナリオで SCD 履歴を保持し、再現可能な方法で使用していることを確認します。

従来の SCD 処理方法

SCD の変更を処理する従来の方法は、SCD タイプ 0~6 と呼ばれています。そのうちで最も一般的な方法は、SCD タイプ 2 です。この方法では、ディメンション テーブルに追加の列を作成して履歴データを追跡します。追加される列は、サロゲートキーと、バージョン、有効期間の開始 / 終了日、現在の日付に現在行を示すフラグを付加したもののいずれかです。この手法やその他の手法を BigQuery に適用する方法について詳しくは、変更の処理をご覧ください。

Functional Data Engineering

SCD を処理するもう一つの方法は、Apache Airflow の作成者である Maxime Beauchemin の記事 Functional Data Engineering で紹介されています。この記事では、データ パイプラインを 1 つの DAG 内で組織化される決定論的タスクとべき等タスクのコレクションで構成することで、ディレクショナルな相互依存関係が反映されるようにしたパラダイムを提案します。

出力が入力のみに依存し、ローカルやグローバルの状態には依存しない場合、タスクは決定論的であるため、関数型プログラミングのコンセプトに従います。タスクは、同じ入力パラメータを使用した複数回の実行が可能で、同じ出力が生成される場合、つまりほかに副作用を生じない場合に、べき等と見なされます(コンピューティングにおけるこの例は、REST PUT 操作です)。タスクの実行は、タスクのインスタンスと呼ばれます。入力が異なるタスク インスタンスは、同じ出力テーブルの異なるパーティションにデータを書き込みます。

タスクの入力の 1 つはディメンションであるため、Beauchemin は、ETL の実行がトリガーされるたびにディメンション スナップショットを作成することを推奨しています。ディメンション スナップショットは、ETL の実行に必要なすべてのディメンション行とタイムスタンプを複製します。ディメンション テーブルは、さまざまな時点でスナップショットのコレクションになります。これらのスナップショットは、SCD の変更履歴を保持して、タスク インスタンスを再実行し、一貫性のある再現可能な出力を取得します。

この方法は、SCD タイプ 2 などの SCD を処理する従来の方法とは異なります。比較的安価なストレージの使用を追加するだけで、代理キーと追加の列を管理する複雑さを回避し、エンジニアリング時間を短縮します。この記事では、2 つの方法が共存できることを認めています。

BigQuery での SCD の処理

BigQuery は、ディメンション テーブルを含むスタースキーマとスノーフレーク スキーマをサポートしています。したがって、前述の 2 つの方法のいずれも適用できます。

BigQuery はさらに一歩進んで、ネストされたフィールドと繰り返しフィールドのネイティブ サポートによりスキーマの非正規化を促進します。これらのフィールドは、イベント発生時の属性が重要な場合に、ファクト テーブルで使用できます。また、ディメンション テーブルで使用して、ディメンション行全体ではなく、属性の変更に対してのみタイプ 2 またはスナップショット アプローチで履歴値を記録することもできます。

データの保持と削除

特定の状況では、ユーザーが BigQuery のデータを変更または削除できないようにすることが必要な場合があります。これらの操作を許可する権限を含むロールからユーザーを除外することにより、この制限を実現できます。このようなロールとしては、bigquery.dataOwnerbigquery.dataEditorbigquery.admin があります。また、別のオプションとしては、特定の編集権限と削除権限を含まないカスタムの IAM ロールを作成するという方法もあります。

電子記録の保存に関する規制を満たす必要がある場合、代わりに Cloud Storage にデータをエクスポートして、一定の記録保持規制への対処が可能なバケットロック機能を使用することをおすすめします。

その他の状況では、一定期間の経過後にデータを自動的に削除する必要がある場合があります。BigQuery は、構成可能な有効期限を通じてこのニーズを満たすことができます。有効期限は、データセットテーブル、または特定のテーブル パーティションに適用できます。不要なデータを期限切れとすることは、費用管理やストレージ最適化のための手段です。詳細については、BigQuery のベスト プラクティスをご覧ください。Google Cloud でのデータ削除に関するより広範な概要については、このドキュメントのページをご覧ください。

Google Cloud のお客様は、規制の適用対象となりうると判断した場合、お客様が契約する弁護士と対応する規制当局の監督の下で、特定の要件に対するコンプライアンス評価を独自に完了する必要があります。

データ品質管理

データ品質管理プロセスには次が含まれます。

  • 検証用のコントロールを作成する。
  • 品質のモニタリングとレポート作成を有効にする。
  • インシデントの重大度のレベルを評価するトリアージ プロセスをサポートする。
  • 根本原因の分析とデータの問題に対する救済策の推奨を有効にする。
  • データのインシデントを追跡する。

データ品質要件はデータ コンシューマごとに異なる場合があるため、データ検証とモニタリング プロセスをサポートする手法やツールだけでなく、データ品質に対する期待値についても文書化しておくことが重要です。適切なデータ品質管理プロセスを確立することで、信頼性の高いデータを分析に提供できます。

品質メタデータ

データ ウェアハウスは、意思決定者に管理された膨大な量のデータへのアクセスを提供します。ただし、データ ウェアハウス内のすべてのデータを等しく扱う必要はありません。

  • 意思決定のコンテキストでは、高品質のデータが意思決定に大きな影響を与え、低品質のデータが影響を小さくする必要があります。
  • データ品質モニタリングのコンテキストでは、データがデータ ウェアハウスに到達する前であっても、低品質データを使用して自動または手動アラートをトリガーし、それを生成しているプロセスを検証できます。

さらに、組織の部署ごとに、データ品質のしきい値が異なる場合があります。たとえば、低品質のデータは開発やテストには完全に使用できますが、財務やコンプライアンスには使用できないと見なされることになります。

このセクションでは、意思決定者に提供するメカニズムとしてメタデータを提示し、提示されたデータの評価に必要なコンテキストの処理について説明します。

構造と形式

メタデータは、データを修飾するためにデータに添付される構造化された情報です。データ品質のコンテキストでは、メタデータを使用することで、正確性、鮮度、完全性などの関連属性を収集できます。

データ品質メタデータ(DQM)でキャプチャされるセマンティクスと属性の明細は、修飾するビジネス コンテキストによって異なります。企業全体で標準の属性セットを採用して、コミュニケーションと管理を容易にすることを強くおすすめします。選択する一連の属性は、ISO/IEC 25012:2008 データ品質モデルなどの業界標準、データ管理協会(DAMA)のデータ品質評価の主要な次元などのデータ技術者の推奨事項から導出できます。

DQM を保存して、意思決定者に提示する形式も重要な考慮事項です。適合する形式が意思決定タスクごとに異なる場合があります。たとえば、Moges などは、DQM として以下の形式をコンパイルしてリストしています。

  • N レベル序数: 優れた、良い、平均などの有限の値のセット。
  • 範囲: 0~100 などの下限と上限のある数値スケール。序数よりも高い柔軟性で品質レベルを表現。
  • 確率: 0~1 スケールのデータ品質。データの一部が正しい確率を示す。
  • グラフィカル: 品質レベルを示す色などの視覚的なキュー。

クラウド内の品質メタデータ

従来、企業においては、共有された知識に頼り、整合性のある DQM リポジトリの維持管理を行ってはいませんでした。そうした知識は、スプレッドシート、イントラネットのページ、アドホックなデータベースのテーブルなど、複数の孤立したリポジトリで収集されている場合があります。このようなバラバラの DQM のソースを、検出、検索、理解、および維持しようとすると、コラボレーションが妨げられ、意思決定支援の価値を上回る負担となる場合がありました。

Data Catalog は、メタデータを集中管理する方法を提供します。

  • ビジネス メタデータとも呼ばれるカスタムのメタデータタグは、標準定義の一環として選択したデータ品質属性をサポートし、それらをビジネス コンテキストごとにカスタマイズできる論理テンプレートにグループ化します。
  • 順序属性を表すカスタムの列挙型、およびさまざまなグラフィカル表現に使用できる範囲、確率、数値を表す double 型および文字列型をサポートしています。これらのメタデータ値にアクセスするには、Data Catalog UI を使用するか、意思決定者向けのカスタム アプリケーションを構築できる API およびクライアント ライブラリを使用します。
  • アップストリーム プロセスで Data Catalog API を使用できます。特定のソースのデータ品質がしきい値を下回ると、プロセスによって低品質データにタグが付けられ、BigQuery に到達する前にアラートをトリガーします。データ自体は、Cloud Storage の検疫バケットに送信され、必要に応じて修復および再処理が行われます。

DQM の考慮事項

DQM が存在しない場合、意思決定者は低品質のデータを使用し、不適切な意思決定を行う可能性が高くなります。実際には、DQM を追加すると、選択肢を生成するために吸い上げる情報の量が多くなり、意思決定者を圧倒してしまい、決定の適時性と品質の双方に悪影響を及ぼす場合があります。

したがって、意思決定者に対して、DQM のセマンティクスとベスト プラクティスのトレーニングを実施することが重要です。Moges などは、DQM とトレーニングを提供することは、低品質のデータを使用するとその結果が重大な影響を及ぼすタスクに有益であることを示唆しています。ただし、DQM は、高効率が必要なタスクや、人員が適切にトレーニングされていない場合には逆効果になる場合があります。

監査

組織においては、システムを監査して、設計どおりに機能していることを確認できることが必要になります。モニタリング、監査、およびトラッキングを利用すれば、セキュリティ チームがデータの収集、脅威の特定を行い、ビジネス上の損害または損失をもたらす前にそれらの脅威に対処できます。定期的な監査を実行することが重要です。これらの監査は、コントロールの有効性をチェックして、脅威を迅速に軽減し、全体的なセキュリティの健全性を評価するためです。監査は、外部監査人による規制遵守の実証にも必要になる場合があります。

健全なデータアクセス制御を確認する最初のステップは、Google Cloud プロジェクトと個々の BigQuery データセットに関連付けられているユーザーとグループを定期的に監査することです。これらのユーザーは、所有者や管理者である必要があるか、それとも、限定的なロールで十分対応できる職務であるかなどについて監査します。また、プロジェクトの IAM ポリシーを変更する権限が誰に付与されているかを監査することも重要です。

ログを分析する 2 番目のステップは、「誰が、何を、いつ、どこで行ったのか」という疑問を明らかにすることです。質問への回答には、BigQuery データとメタデータを使用します。

  • データの場合、BigQuery にはデフォルトで Cloud Logging に 2 つの不変のログストリームである、管理アクティビティとデータアクセスの監査ログが含まれています。
  • メタデータの場合、Data Catalog によって両方の監査ロギング ストリームもサポートされますが、BigQuery とは異なり、データアクセスのロギングは手動で有効にする必要があります。

管理アクティビティ ログには、リソースの構成、メタデータを変更するログコールなどの管理アクションのログエントリが収録されます。たとえば、BigQuery データセットへの読み取りアクセスを新しいユーザーに許可するなど、新しいサービス アカウントの作成や IAM アクセス許可の変更は、管理アクティビティ ログに記録されます。

データ アクセスログには、ユーザーが提供するデータを作成、変更、または読み取るユーザー認証 API 呼び出しが記録されます。データアクセス ログには、たとえばユーザーが BigQuery データセットに対するクエリを行ったか、クエリ結果をリクエストしたかなどが記録されます。サービス アカウントではなくユーザーにクエリを割り当てると、データアクセスの監査が容易になります。

両種のログに、指定した特定の条件下でトリガーされる Cloud Monitoring アラートを作成できます。これらのアラートは、トリガーされると、メール、SMS、サードパーティ サービス、さらにはカスタム URL への Webhook などの複数のチャネルを介した通知を送信できます。

監査ログには機密情報が含まれている可能性があるため、ログへのアクセスを制限する必要があります。IAM ロールを使用して、監査ログへのアクセスを制限できます。

また、次に示す理由により、Cloud Logging から BigQuery データセットへの BigQuery 監査ログのエクスポートを検討する必要があります。

  • Cloud Logging での監査ログのログ保持期間には期限がある。BigQuery や Cloud Storage など、別の安全なストレージの場所にエクスポートすることで、長期の保存期間を確保できる。
  • BigQuery では、ログに対して SQL クエリを実行すると、複雑なフィルタリングの実行が可能になり、分析に利用できる。
  • さらに、データポータルなどの可視化ツールを使用してダッシュボードを作成できる。

詳細については、Google Cloud Audit Logs を使用する操作のベスト プラクティスに関するブログ記事をご覧ください。

次のステップ