データレイクからデータ ウェアハウスまでのパイプラインの保護

はじめに

この記事では、データレイクからデータ ウェアハウスへのパイプラインへのデータアクセスの管理をサポートし、パイプラインのデータ流出を防ぐためのセキュリティ管理について説明します。

ここでは、パイプラインの例を使用して次のことを示します。

  • IAM 権限を構成して、データレイクからデータ ウェアハウスへのパイプラインに格納されているデータにアクセスする必要がある一連のペルソナにアクセス権を付与する。
  • ネットワーク制御を構成して、データへのアクセスパスを管理し、データ流出を防止する。
  • 組織のポリシー サービスと IAM を使用してポリシーを実装し、制御を適用する。
  • 暗号化戦略の一環として Cloud KMS を使用する。
  • パイプラインの一部として Cloud Data Loss Prevention API を使用して、機密データを分類および秘匿化(トークン化)する。
  • 監査ツールを使用して、データにアクセスしたユーザーを把握する。

アーキテクチャ

次の図は、パイプライン アーキテクチャの例を示しています。

データレイクのユースケースのアーキテクチャ

このアーキテクチャは、さまざまなデータレイクのユースケースの基本構造として使用できます。ユースケースごとに最適なアーキテクチャを見極めるには、データレイクの構築をご覧ください。

ここで説明する例は、データレイクの構築のアーキテクチャに似ていますが、異なる点もいくつかあります。このバッチ分析アーキテクチャでは、次のことも行います。

  • Cloud Data Loss Prevention(Cloud DLP)を使用します。まず、すべてのデータが Cloud DLP を使用してスキャンおよび処理されます。機密として分類されたデータは、データレイクにアップロードされる前に特定およびトークン化されます。データは、並べ替えとマイニングのワークフローを通してデータのクレンジングと絞り込みが行われ、利用できるようになります。
  • 処理済みデータ(すなわち、データ ウェアハウス)の最終的な送信先として、BigQuery と Cloud Storage の両方を使用します。
  • BigQuery と Cloud Storage に格納されたデータの Cloud データポータルと Datalab を使用したクエリをサポートします。

用語

データレイク。ネイティブ形式でデータを保存するリポジトリ。このアーキテクチャの例では Cloud Storage を使用しており、データレイクの構築データレイクとしての Cloud Storage セクションで説明しています。

データ ウェアハウス。1 つ以上の異種ソースから統合されたデータの一元的なリポジトリ。データ ウェアハウスでは、現在と過去のデータが 1 か所に保存されており、分析に使用できます。このアーキテクチャの例では、データ ウェアハウスには Cloud Storage と BigQuery の両方に格納されるデータが含まれています。これらのサービスは、従来のデータ ウェアハウス向けの一般的な設定に置き換わるものです。つまり、組織内のすべての分析データを集約するホームとして機能します。

ペルソナ

次の表に、データレイクからデータ ウェアハウスへのパイプラインに関連付けられているユーザーとサービスを示します。

ペルソナ アクティビティ
データ アップローダ Cloud Storage データレイクにデータを書き込むサービス アカウントまたはユーザー。

自動アップロードを実行するサービス アカウント。
ユーザーにより、暫定的なアップロードが行われる場合もあります。
データ閲覧者 Cloud データポータルや SAP Business Objects などのレポート作成ツールを使用して、BigQuery のレポート テーブルのデータを利用するユーザー。
データ アナリスト(SQL の知識は不要) Dataprep でデータを準備(非正規化された BigQuery テーブルの結合など)し、Google データポータルや他のツールを使用してレポートを作成するユーザー。
データ アナリスト(SQL の知識が必要) BigQuery でアドホック分析(非正規化されたテーブルを使用)を行い、BigQuery でレポート テーブルを準備し、データポータルや他のツールを使用してレポートを作成するユーザー。
データ サイエンティスト さまざまなソリューションを使用して、統計データ分析や機械学習モデルの開発など、データ サイエンス タスクを行うユーザー。

ソリューションには、AI Platform、Datalab、R Studio、SAS などがあります。

また、データ サイエンティストは、アドホックでモデルを開発することもあります。
データ エンジニア Cloud Storage と BigQuery にデータを移行するためのパイプラインを開発するユーザー。BigQuery でテーブルを作成し、データ サイエンティストが開発した ML モデルとパイプラインを実装します。Dataflow、Dataproc、Cloud Composer、Dataprep by Trifacta、およびその他のデータ サイエンス ソリューションを使用します。
運用 オーケストレーション、CI / CD、その他のツールを使用して、データ エンジニアにより開発されたものを本番環境に実装するユーザー。
R Studio や Anaconda などのサードパーティのデータ サイエンス ソリューション用に VM イメージを構築し、データ エンジニアとデータ サイエンティストが使用できる環境を提供します。データレイクとデータ ウェアハウス用の Cloud Storage バケット構造をセットアップして、BigQuery データセットを作成します。
運用主体 パイプラインの実行に使用されるサービス アカウント。

次の表では、お客様の職務上のロールおよびアクティビティが、このアーキテクチャの例のペルソナとどのように対応しているかを示します。

お客様の職務上のロール アクティビティ ペルソナ
アドホック データ アップローダ Cloud Storage に直接データをアップロードします。 データ アップローダ
データ エンジニア Cloud Storage と BigQuery へデータを移行するためのパイプラインを開発し、Cloud Storage から BigQuery にテーブルを作成して、パイプラインを運用可能にします。 データ エンジニア、
運用担当者
データ ウェアハウス ビジネス アナリスト(DW-BA) データ ウェアハウスに読み込まれたデータを表示します。 データ アナリスト、
データ閲覧者
クロスセクション ビジネス アナリスト(CS-BA)
マーケティング アナリスト
事前定義された一連のデータを、データ ウェアハウスに読み込まれた後で表示します(複数の DW-BA によるアクセスと同等です)。 データ アナリスト、
データ閲覧者
スーパー ビジネス アナリスト データレイクとデータ ウェアハウスのすべてのデータを表示し、データレイクで Dataprep などのツールを使用します。 データ アナリスト、
データ閲覧者

多くの場合、お客様の職務上のロールは上記のペルソナに直接対応するものではありません。個別のペルソナを組み合わせた職務上のロールが存在することもあります。重要なことは、アクティビティを実行するスキルを持つ担当者を割り当てることです。

アクセス制御に関するベスト プラクティス

最小権限の原則に従うことをおすすめします。このセクションでは、IAM、BigQuery、Cloud Storage におけるアクセス制御の選択肢について説明します。

IAM でアクセス権付与のポリシーを定義する

IAM を使用して、アーキテクチャを構成する Google Cloud リソースに権限を付与します。権限を付与する前に、パイプラインでユーザーが実行するアクティビティを正確に把握する必要があります。これにより、職務上の各ロールに必要なアクセス権のレベルを判断できます。

IAM のベスト プラクティス ガイダンスに従って、IAM アクセス制御ポリシーを定義します。

次の図は、サンプル アーキテクチャにおける職務上のロールが、データやサービスとどこでどのように関わるかを示しています。

職務上のロールの関わりのアーキテクチャ。

データのアップロード

データは自動プロセスを介してデータレイクにアップロードされ、場合によってはアドホック プロセスでアップロードされます。自動プロセスでできるのは、データレイクへのデータの追加のみです(つまり、データレイク内のデータの読み取り、削除、変更はできません)。

自動化されたアップロード プロセスを実行するサービス アカウントおよび、アドホック データ ローダーには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

storage.objectCreator
Cloud Storage バケット 自動アップロードを実行するサービス アカウント

アドホック データ アップローダ
(スーパー ビジネス アナリスト)
アップローダ アプリケーションにオブジェクトの作成を許可します(オブジェクトの表示、削除、上書きは許可しません)。

アーキテクチャの例では、データは指定したバケットにアップロードされます。バケットの場所は、アップローダ プロセスを呼び出すときに定義されます。アップローダ グループ(必要に応じてサービス アカウントも)を個別に作成すると、誰がどのバケットにアクセスできるかをさらに細かく分割できます。

データレイクにデータをアップロードする前に、機密データをトークン化または秘匿化する必要があります。そのためには、この記事の後半で説明する Cloud DLP API を使用します。

データ処理

データレイクはデータを未加工の形式で保存するため、データ ウェアハウスに読み込む前にデータを処理する必要が生じることがよくあります。その処理には、データのクリーニング、重複除去、変換などがあります。データ処理用の Google Cloud ツールには、Cloud Composer、Dataproc、Dataflow、BigQuery、Dataprep などが用意されています。

データ エンジニアと、Cloud Composer ジョブを実行するサービス アカウントには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

roles/composer.admin
プロジェクト データ エンジニア データ エンジニアに Cloud Composer リソースのフル コントロール権を付与します(このロールでは、バケット内のデータへの直接アクセスはできません)。

roles/composer.worker
プロジェクト Cloud Composer 実行用のサービス アカウント 関連付けられた VM 上で Cloud Composer 環境を実行するために必要な権限をサービス アカウントに付与します。

データ エンジニアは、Identity-Aware Proxy(IAP)を介して Cloud Composer のウェブ インターフェースにアクセスできます。Apache Airflow 上に構築されたワークフロー オーケストレーション サービスの Cloud Composer は、たとえば Dataproc クラスタを起動する API など、多くの API を呼び出します。Cloud Composer 環境に関連付けられたサービス アカウントには、これらのリソースを使用するための権限が必要です。少なくとも、サービス アカウントには roles/composer.worker 権限が必要です。

Dataflow サービス アカウントには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

dataflow.worker
組織 Dataflow の作業単位の実行用サービス アカウント。 Dataflow パイプラインの作業単位を実行する権限をサービス アカウントに付与します。

Dataprep を使用すると、異種の大規模なデータセットから元データを視覚的に調べて変換できます。Dataprep は、Dataflow および Cloud Composer が使用する自動化プロセスとは別に使用します。

Dataprep サービス アカウントとビジネス アナリストには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

dataprep.ServiceAgent
プロジェクト Dataprep サービス アカウント Dataprep サービス アカウントに、データセットとストレージへのアクセスと変更を行う権限および、プロジェクト内の Dataprep ジョブの実行と管理の権限を付与します。

dataprep.user
プロジェクト データ アナリスト ユーザーに Dataprep アプリケーションの実行を許可します。

データ ウェアハウス

サンプル シナリオでは、複数のデータ アナリストが、データ ウェアハウス内のデータにアクセスする異なるレベルのアクセス権を持っています。

ビジネス アナリスト

データ ウェアハウス ビジネス アナリスト(DW-BA)は、データ ウェアハウスに読み込まれたデータを閲覧します。

DW-BA には、必要とするリソースに対する次の IAM ロールが付与されています。

ロール リソース メンバー 権限


bigquery.user

プロジェクト DW-BA bigquery.dataviewer ロールで付与された権限で定義されるデータセットに対して、DW-BA にクエリの実行を許可します。

bigquery.dataviewer
BigQuery データセット DW-BA プロジェクトで bigquery.user ロールを持つ DW-BA に、指定されたデータセット内のデータに対するクエリの実行を許可します。

storage.objectviewer
バケット DW-BA フェデレーション データソースを表示する権限を付与します(データ ウェアハウスのデータは Cloud Storage と BigQuery に保存されるため)。

DW-BA は、ユーザーが管理するサービス アカウントを使用して、データ全体に対して Dataproc クラスタを起動し Hive クエリを実行できます。サービス アカウントには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限


dataproc.editor

プロジェクト DW-BA Dataproc クラスタを起動してジョブを実行する権限を付与します。これは、Cloud Storage に保存されているデータ全体に対して Hive クエリを実行するために必要です。

ファイルはすでにアップロードされているため、DW-BA が Cloud Storage にファイルをアップロードできる必要はありません。

指定されたバケットでジョブの出力を表示するために、DW-BA には次の IAM ロールが必要です。

ロール リソース メンバー 権限

storage.objectviewer
バケット DW-BA フェデレーション データソースを表示する権限を付与します。

Dataproc クラスタを起動するには、ユーザー管理のサービス アカウントを使用することをおすすめします。これにより、ジョブを開始したユーザーのアクセスが取り消された後も、長時間実行ジョブを継続できます。また、クラスタに対してきめ細かなアクセスの作成と制御ができます。

ユーザー管理のサービス アカウントには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

dataproc.worker
プロジェクト Dataproc サービス アカウント サービス アカウントに Dataproc クラスタの起動および実行を許可します。

権限をさらに細かく設定するには、Dataproc Granular IAM をご覧ください。

クロスセクション ビジネス アナリスト

このシナリオでは、クロスセクション ビジネス アナリスト(CS-BA)またはマーケティング アナリストは、データ ウェアハウスに読み込まれた定義済みのデータセットを表示できます。このアクセス権は、複数の DW-BA による閲覧と同等です。

この例では、CS-BA が表示できる Cloud Storage バケットとデータセットは同じプロジェクトにあります。

CS-BA には、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

bigquery.user
プロジェクト CS-BA bigquery.dataviewer ロールを持つデータセットに対して、CS-BA にクエリの実行を許可します。

bigquery.dataviewer
プロジェクト CS-BA CS-BA に、プロジェクト内のすべてのデータセットの列挙、データセットのメタデータの読み取り、データセット内のテーブルの出力、データセット テーブルからのデータとメタデータの読み取りを許可します。

storage.objectviewer
プロジェクト CS-BA フェデレーション データソースを表示する権限を付与します。

管理可能な数のデータセットとフェデレーション バケットを使用している場合は、DW-BA 構成を使用するだけで十分です(プロジェクト レベルで権限を付与するのではなく、バケットとデータセットごとに適切な権限を付与する必要があります)。

スーパー ビジネス アナリスト

このシナリオでは、スーパー ビジネス アナリスト(S-BA)は、データ ウェアハウスに読み込まれたデータレイク内のすべてのデータを表示できます。

S-BA には、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

bigquery.user
組織 S-BA bigquery.dataviewer ロールを持つデータセットに対して、S-BA にクエリの実行を許可します。

bigquery.user ロールでは、ユーザーは自身が作成していないデータセットに対して、データのクエリ、テーブルデータの表示、テーブル スキーマの詳細の表示は行えません。

ロール リソース メンバー 権限

bigquery.dataviewer
組織 S-BA S-BA に、プロジェクト内のすべてのデータセットの列挙、データセットのメタデータの読み取り、データセット内のテーブルの出力、データセット テーブルからのデータとメタデータの読み取りを許可します。

storage.objectviewer
組織 S-BA フェデレーション データソースを表示する権限を付与します。

S-BA は、データがデータ ウェアハウスに読み込まれるように変換するため、Dataprep を使用できます。

データ閲覧者

ビジネス アナリストも、データポータルと Datalab により生成されたレポートを使用できます。Datalab は Datalab VM サービス アカウントを使用します。ノートブックを実行してレポートを生成する前に、次の IAM ロールをビジネス アナリストとサービス アカウントに付与する必要があります。

ロール リソース メンバー 権限

iam.serviceAccountUser
サービス アカウント ビジネス アナリスト ビジネス アナリストに、Datalab インスタンスへ接続するためのアクセス権を付与します。ビジネス アナリストには、Datalab インスタンスを開始したサービス アカウントの serviceAccountUser ロールが必要です。

Datalab では、個別のユーザーに 1 つのインスタンスへのアクセス権を付与する必要があります。

Datalab インスタンスの起動に使用するサービス アカウントには、BigQuery、Cloud Storage、Dataflow へのアクセス権を付与する必要があります。サービス アカウントには、必要とするリソースに対する次の IAM ロールが必要です。

ロール リソース メンバー 権限

bigquery.user
組織 サービス アカウント bigquery.dataviewer ロールを持つデータセットに対して、Datalab サービス アカウントにクエリの実行を許可します。

bigquery.dataviewer
組織 サービス アカウント サービス アカウントに、プロジェクト内のすべてのデータセットの列挙、メタデータの読み取り、データセット内のテーブルの出力、テーブルからのデータとメタデータの読み取りを許可します。

storage.objectviewer
組織 サービス アカウント フェデレーション データソースを表示する権限を付与します。

BigQuery データセットにアクセスするため、データポータルには、適切なデータソースの認証情報が必要です。詳細については、データソースの認証情報をご覧ください。

BigQuery によるきめ細かいアクセス制御の設定

BigQuery では、たとえば、異なるレベルのアクセス権を必要とする複数のビジネス アナリストが存在する場合に、データのビューのきめ細かいアクセス制御を管理できます。次にシナリオを示します。

  • データ ウェアハウスのビジネス アナリスト(DW-BA)は、データを閲覧できます。
  • クロスセクション ビジネス アナリスト(CS-BA)またはマーケティング アナリストは、データ ウェアハウスに読み込まれた事前定義のデータセットを閲覧できます。必要となるアクセス権は、複数の DW-BA の閲覧と同等です。
  • スーパー ビジネス アナリスト(S-BA)は、データレイク内のすべてのデータ、またはデータ ウェアハウスに読み込まれたデータを閲覧できます。

IAM 権限に加え、承認済みのビューを構成する必要があります。

承認済みのビューを使用すると、基となるテーブルへのアクセス権を付与することなく、特定のユーザーおよびグループとクエリ結果を共有できます。このサンプル シナリオでは、DW-BA と CS-BA にキュレート済みビューを提供できます。ビューは、ビューによりクエリされるソースデータとは別のデータセットに作成されます。ビューに基づいて、ビジネス アナリストにデータセットへのアクセス権を付与します。

BigQuery データセットへの制限付きアクセスを実装する方法については、データ ワークロードの保護ユースケース: 特定の ID のデータへのアクセスを制限するをご覧ください。

このシナリオでは、行レベルの権限を構成する必要はありません。それでも、必要に応じて、ユーザーごとに異なる行を表示できます。特定の行を表示できるユーザーを指定するフィールドを、テーブルに追加します。次に、SESSION_USER() 関数を使用するビューを作成します。SESSION_USER() 関数からは、現在のユーザー(Google Cloud に対して認証を行うメールアドレス)が返されます。追加したフィールドに含まれるユーザーが SESSION_USER() から返された場合、そのユーザーは該当する行のデータを表示できます。

Cloud Storage 内の特定のオブジェクトへのアクセス権を付与する

通常、IAM は、バケットとその中のオブジェクトへのアクセス管理に最適です。その方法については、前述のパイプラインの例で説明しています。しかし、Cloud Storage にはもっと多くのアクセス制御メカニズムがあり、バケット内の特定のオブジェクトにアクセス権を付与する場合にパイプラインで使用できます。これを行うには、アクセス制御リストまたは署名済み URL を使用します。

組織のポリシー

組織のポリシーを使用して、サポートされているリソースに対する制限を構成できます。サポートされているリソースに対して制約を構成します。パイプラインの例に適用する制約は、次のとおりです。

  • ドメインで制限された共有。パイプラインが構成されている組織内で IAM ポリシーに追加できるユーザーを制限します。許可リストや拒否リストには、1 つ以上の Google Workspace ID または Cloud Identity お客様 ID を指定する必要があります。

    Cloud Composer を使用するには、環境を作成する前にポリシーの制約を無効にして、Cloud Composer が必要な ACL を環境の Cloud Storage バケットに適用できるようにする必要があります。環境を作成した後で、ポリシーの制約を再び有効にできます。

    ドメインで制限された共有を実装する方法については、データ ワークロードの保護ユースケース: ドメイン以外の ID によるアクセスを防ぐをご覧ください。

  • サービス アカウント キー作成の無効化。この制約を TRUE に設定することで、サービス アカウントの外部キーの作成を防ぎます。

  • バケット ポリシーのみを適用。IAM ポリシーによってのみバケット内のオブジェクトへのアクセス権が付与されるように、バケット内の Cloud Storage オブジェクトに割り当てられた ACL の評価を無効にします。

IAP を使用して ID と承認の確認を行う

Identity-Aware Proxy(IAP)は、Google Cloud でホストされ、HTTPS によりアクセスされるアプリケーションの一元的な承認レイヤを確立します。IAP により保護されているアプリケーションまたはリソースには、適正な IAM ロールを持つユーザーのみがプロキシを介してアクセスできます。ユーザーが IAP で保護されたリソースにアクセスしようとすると、IAP が認証と認可のチェックを行います。パイプラインの例では、IAP を使用して Cloud Composer のウェブ インターフェースにアクセスします。

VPC でセキュリティ境界を定義する

VPC Service Controls を構成することにより、Cloud Storage バケットや BigQuery データセットなどの Google Cloud リソースのセキュリティ境界を定義できます。Virtual Private Cloud(VPC)内でデータを制限することで、データの流出リスクを軽減できます。

オンプレミス用の限定公開の Google アクセスを使用すると、データセンターから Google Cloud への Cloud Interconnect 接続または Cloud VPN 接続を通して、オンプレミス ホストが Google API とサービスを利用できます。オンプレミス ホストには外部 IP アドレスは必要ありません。内部 RFC 1918 IP アドレスを使用します。

次のアーキテクチャの例では、限定公開の Google アクセスと VPC Service Controls で IAM の制御を補完することで、データレイクとデータ ウェアハウスを含むプロジェクトへのアクセスを制限しています。オンプレミスと Google Cloud 間で限定公開の通信が利用できない場合に備えて、データ エンジニアと運用担当者への緊急アクセスが実装されています。また、コンテキストアウェア アクセス制御も構成されています。

この構成を次のアーキテクチャ図に示します。

データ エンジニアが緊急アクセスできるアーキテクチャ。

データの流出を抑えるために VPC Service Controls を実装する方法については、アプリに対するデータの引き出しの抑制個人に対するデータの引き出しの抑制をご覧ください。

Google Cloud APIs へのマネージド アクセスを実装する方法については、Google Cloud APIs へのマネージド アクセスをご覧ください。

人、場所、時間を監査する

Cloud Audit Logs は、プロジェクト、フォルダ、組織ごとに次の 3 つの監査ログストリームで構成されます。

  • 管理アクティビティ
  • システム イベント
  • データアクセス

Google Cloud サービスによって、これらのログに監査ログエントリが書き込まれ、Google Cloud プロジェクト内で誰が、何を、どこで、いつ行ったかを調べるのに役立ちます。

管理アクティビティ ログには、リソースの構成やメタデータを変更する API 呼び出しその他の管理アクションに関するログエントリが含まれます。管理アクティビティ ログは常に有効です。管理アクティビティの監査ログは無償で、13 か月間(400 日間)保持されます。

データアクセス ログには、ユーザー提供データを作成、変更、または読み取る API 呼び出しが記録されます。データアクセス監査ログはサイズが大きくなる可能性があるため、BigQuery 以外ではデフォルトで無効になっています。

システム イベント ログには、Compute Engine によって実行されたシステム イベントに関するログエントリが記載されます。たとえば、各ライブ マイグレーションがシステム イベントとして記録されます。システム イベント監査ログは無料で使用できます。

パイプラインの例では、管理ログとデータアクセス ログの両方を監査します。次のサービスでは、アーキテクチャの例向けに構成されたデータアクセス監査ログを備えています。

監査ログの IAM ロールは、ログへのアクセスを制限するように構成されていますログのエクスポート(表示されていません)は、デフォルトの保持期間を経過してもログを照合し保持するように構成されています。シナリオ例とログのエクスポート戦略の構成方法については、Cloud Logging のエクスポートのための設計パターンをご覧ください。

個人情報データを保護する

個人を特定できる情報(PII)とは、個人の特定に関連するあらゆる情報を指しています。

Google Cloud はデフォルトで、お客様のデータを保存時に暗号化します。お客様が追加で操作を行う必要はありません。

Google Cloud のデータは、保存のためにファイルより小さい「チャンク」に分割されます。各チャンクは個別の暗号鍵を使用してストレージ レベルで暗号化されます。チャンクのデータを暗号化するための鍵は「データ暗号鍵(DEK)」と呼ばれています。Google で使用する鍵は膨大な数にのぼり、また低レイテンシと高可用性を実現する必要があるため、これらの鍵は暗号化対象のデータの近くに保存されます。DEK は「鍵暗号鍵(KEK)」を使用して暗号化(「ラップ」)されます。データを保護する DEK を保護する KEK を管理するために使用する鍵管理ソリューションは、お客様が選択できます。

機密性の高い操作の場合は、顧客指定の暗号鍵(CSEK)を使用して独自の鍵暗号鍵を生成し管理するか、Cloud KMS を使用して暗号鍵を管理することが可能です。

パイプラインの例では、Cloud DLP を使用して機密データをトークン化するときに、Cloud KMS を使用して鍵を管理する必要があります。

Cloud Data Loss Prevention(DLP)API を使用すると、強力な機密データ検査、分類、匿名化プラットフォームにプログラムからアクセスできます。

データは DLP API により処理されます。続いて、処理されたデータはシンクに書き込まれます。

データ パイプライン プロセスのアーキテクチャ。

ポリシーやコンプライアンス上の理由から、データレイクにデータを書き込む前に機密性の高いデータ項目を特定してトークン化する必要がある場合は、Cloud KMS とともに DLP API を使用できます。DLP API を使用すると、アップロード プロセスの一環として機密性の高いデータ項目をトークン化できます。トークン化を解除する(元データ項目を表示する)必要がある場合も、KMS 鍵とデータ項目を最初にトークン化したときに使用した暗号学的ハッシュを使用できます。

機密データ項目を識別してトークン化するアーキテクチャ。

トークン化 / トークン化解除プロセスの実装方法の詳細については、テキスト内の機密データの匿名化をご覧ください。

パイプライン アーキテクチャの例では、データがデータレイクにアップロードされるときに、取り込み段階で Cloud DLP を使用してデータを分類します。検出された機密データは、Cloud KMS によって管理される鍵を使用してトークン化されます。

次のステップ