DLP プロキシを使用して機密データを含むデータベースにクエリを実行するアーキテクチャの例

このドキュメントでは、Cloud Data Loss Prevention(Cloud DLP)を使用して、Google Cloud データベースに保存された機密データがユーザーに公開されるリスクを軽減しつつ、意味のあるデータを照会できるようにする方法を説明します。

機密データは企業のあらゆる箇所に存在する可能性があります。収集、処理、共有されるデータには、外部および内部のポリシーや規制の対象となる個人情報(PII)などの情報が含まれている可能性があります。機密データへのアクセスを制限する適切なセキュリティ制御に加えて、以下の手法を使用して使用中のデータを保護することもできます。匿名化は、データ マスキングバケット化トークン化などの手法を使用して、データの実用性とプライバシーのバランスを取るのに役立ちます。

トークン化により、機密データがトークンと呼ばれるサロゲート値に置き換えられます。トークンは、データがクエリまたは表示されるときに、元の(生)機密値を表します。このプロセスは、仮名化または代理置換とも呼ばれます。トークン化の概念は、金融や医療などの業界で広く使用されており、使用中のデータのリスクを軽減し、コンプライアンスの範囲を削減して、機密データが不必要にユーザーやシステムに公開されるのを最小限に抑えるのに役立ちます。

Cloud DLP では、機密データの分類と匿名化を一括で、リアルタイムで行うことができます。分類とは、機密情報を識別し、その種類を判別するプロセスです。このドキュメントでは、これらの匿名化手法を使用できる場所と、プロキシを使用してこれらのタスクを実行する方法について説明します。

次の図は、このドキュメントで説明するシナリオを示しています。

Cloud Storage に保存され、ETL を介して取り込まれて、ユーザーによってクエリが実行されるデータのアーキテクチャ。

  • データは Cloud Storage に保存されています。たとえば、パートナーから受信したデータなどです。
  • データは、抽出、変換、読み込み(ETL)プロセスによって SQL データベースに取り込まれます。
  • このデータベース内のデータは、ユーザーによってクエリされ、分析が行われます。

このシナリオでは、クエリから返される結果は生データであるため、機密データが表示され、クエリを実行するユーザーに PII データが公開される可能性があります。機密データの不正なクエリを監査して防止するように、アプリケーションを設計する必要があります。

DLP プロキシのアーキテクチャ

PII データを保護する方法の 1 つとして、検索結果を解析して検査するサービスを介してすべてのクエリと結果を渡し、所見をログに記録するか、Cloud DLP を使用して結果を匿名化してから、要求されたデータをユーザーに戻す方法があります。このドキュメントでは、このサービスを DLP プロキシと呼びます。

DLP プロキシ アプリケーションは、入力として SQL クエリを受け入れ、そのクエリをデータベースで実行し、Cloud DLP を結果に適用してから、データを要求しているユーザーに返します。

次の図は、DLP プロキシ アプリケーションのアーキテクチャを示しています。

データ変換コマンドを使用する DLP プロキシアプリのアーキテクチャ。

Cloud DLP では、検査するデータのタイプと、検査結果やデータ構造(フィールド名など)に基づいてそのデータを変換する方法を詳細に構成できます。構成の作成と管理を簡素化するには、Cloud DLP テンプレートを使用します。DLP プロキシ アプリケーションは、inspect テンプレートと de-identify テンプレートの両方を参照します。

テンプレートを使用すると、Cloud DLP で構成情報を作成して保持できます。テンプレートは、検査の目的や匿名化の方法などの構成情報をリクエストの実装から分離するのに役立ちます。テンプレートの詳細については、Cloud DLP テンプレートをご覧ください。

Cloud Audit Logs は、このアーキテクチャで使用される Google Cloud の統合ロギング サービスです。まず、Cloud Audit Logs は、DLP API に対する呼び出しの監査証跡を提供します。監査ログエントリには、API 呼び出しを行ったユーザー、実行された Cloud プロジェクト、リクエストの詳細(リクエストの一部としてテンプレートが使用されたかなど)に関する情報が含まれています。次に、アプリケーションの構成ファイルを使用して監査を有効にすると、Cloud Audit Logs によって検査結果の概要が記録されます。

Cloud Key Management Service(Cloud KMS)は、クラウド サービス用の暗号鍵を管理できる Google Cloud のクラウドホスト型鍵管理サービスです。

トークン化日付シフトの Cloud DLP メソッドでは、暗号を使用して置換値が生成されます。これらの暗号方法では、鍵を使用して一貫性のある方法で値を暗号化して参照整合性を維持するか、元に戻す方法でトークン化を解除します。この鍵は、呼び出し時に Cloud DLP に直接提供することも、Cloud KMS を使用してラップすることもできます。Cloud KMS で鍵をラップすると、別のアクセス制御と監査のレイヤが提供されるため、本番環境でのデプロイに適しています。

本番環境の構成では、最小権限の原則を使用して権限を割り当てる必要があります。次の図は、この原則の例を示しています。

3 つのペルソナとその権限を持つ本番環境構成。

上の図は、一般的な本番環境の構成で、生データに対する異なるロールとアクセス権を持つ 3 つのペルソナを示しています。

  • インフラストラクチャ管理者: プロキシをインストールして構成し、Cloud DLP プロキシがインストールされているコンピューティング環境にアクセスできるようにします。
  • データ アナリスト: DLP プロキシに接続するクライアントにアクセスします。

  • セキュリティ管理者: データの分類、Cloud DLP テンプレートの作成、Cloud KMS の構成を行います。

Cloud KMS を使用したデータの暗号化と復号の詳細については、データの暗号化と復号をご覧ください。ラップされた鍵の使用について詳しくは、deindentification.java コードサンプルをご覧ください。

このドキュメントで使用する DLP プロキシの場合、この情報はすべて Cloud DLP 匿名化テンプレートで構成されます。

監査、マスキング、トークン化による PII の保護

このシナリオでは、PII が公開されるリスクを軽減するために実装できる戦略は 2 つあります。

データベースに保存された元データ

アプリケーションで元データがデータベースに保存される場合、DLP プロキシを使用して、機密情報の監査を自動的に検査して生成することで、ユーザーに返される結果を処理できます。または、次の図に示すように、クエリ結果をリアルタイムでマスクすることもできます。

クエリ結果がリアルタイムでマスクされるアーキテクチャ。

この構成では、DLP プロキシに接続する SQL クライアントを使用する必要があります。アプリで監査を有効にすると、検査結果の概要を含むログが Cloud Audit Logs で作成されます。この概要は、クエリで返された機密情報の種類を示します。

匿名化された形式で保存されたデータ

元データを保存しない場合、次の図に示されているように、データベースに対する ETL プロセス中に匿名化変換を実行することで、匿名化された形式またはマスクされた形式でアプリケーションのデータを保存できます。

ETL プロセス中にクエリ結果がマスクされるアーキテクチャ。

上の図は、データが検査されて、マスクされてから、データベースに取り込まれる基本的なフローを示しています。ユーザーがこのデータに対してクエリを実行すると、データベースに直接アクセスできる場合でも、マスクされたバージョンしか表示できません。

マスクされていないデータがユーザーに表示されるようにする場合は、次の図に示すように、データのマスク解除を行う権限を持つ DLP プロキシのインスタンスに接続できるクライアントを使用する必要があります。

クライアントを使用して DLP プロキシに接続し、マスクされていないデータを表示するアーキテクチャ。

上の図は、クライアントを使用して DLP プロキシに接続し、マスクされていないデータがクライアントに表示されるようにする方法を示しています。

次のステップ