このドキュメントでは、Sensitive Data Protection を使用して、Google Cloud データベースに保存されたセンシティブ データがユーザーに公開されるリスクを軽減しつつ、意味のあるデータをクエリできるようにする方法を説明します。
機密データは企業のあらゆる箇所に存在する可能性があります。収集、処理、共有されるデータには、外部および内部のポリシーや規制の対象となる個人情報（PII）などの情報が含まれている可能性があります。機密データへのアクセスを制限する適切なセキュリティ制御に加えて、以下の手法を使用して使用中のデータを保護することもできます。匿名化は、データ マスキング、バケット化、トークン化などの手法を使用して、データの実用性とプライバシーのバランスを取るのに役立ちます。
トークン化により、機密データがトークンと呼ばれるサロゲート値に置き換えられます。トークンは、データがクエリまたは表示されるときに、元の（生）機密値を表します。このプロセスは、仮名化または代理置換とも呼ばれます。トークン化の概念は、金融や医療などの業界で広く使用されており、使用中のデータのリスクを軽減し、コンプライアンスの範囲を削減して、機密データが不必要にユーザーやシステムに公開されるのを最小限に抑えるのに役立ちます。
機密データの保護を使用すると、機密データの分類と匿名化を一括で、リアルタイムで行うことができます。分類とは、機密情報を識別し、その種類を判別するプロセスです。このドキュメントでは、これらの匿名化手法を使用できる場所と、プロキシを使用してこれらのタスクを実行する方法について説明します。
次の図は、このドキュメントで説明するシナリオを示しています。
- データは Cloud Storage に保存されています。たとえば、パートナーから受信したデータなどです。
- データは、抽出、変換、読み込み（ETL）プロセスによって SQL データベースに取り込まれます。
- このデータベース内のデータは、ユーザーによってクエリされ、分析が行われます。
このシナリオでは、クエリから返される結果は生データであるため、機密データが表示され、クエリを実行するユーザーに PII データが公開される可能性があります。機密データの不正なクエリを監査して防止するように、アプリケーションを設計する必要があります。
DLP プロキシのアーキテクチャ
PII データを保護する方法の一つとして、検索結果を解析、検査してログに記録するか、要求されたデータをユーザーに戻す前に機密データの保護を使用して結果を匿名化するサービスを介してすべてのクエリと結果を渡す方法があります。このドキュメントでは、このサービスを DLP プロキシと呼びます。
DLP プロキシ アプリケーションは、入力として SQL クエリを受け入れ、そのクエリをデータベースで実行し、機密データの保護を結果に適用してから、データを要求しているユーザーに返します。
次の図は、DLP プロキシ アプリケーションのアーキテクチャを示しています。
機密データの保護では、検査するデータのタイプと、検査結果やデータ構造（フィールド名など）に基づいてそのデータを変換する方法を詳細に構成できます。構成の作成と管理を簡素化するには、Sensitive Data Protection のテンプレートを使用します。DLP プロキシ アプリケーションは、inspect テンプレートと de-identify テンプレートの両方を参照します。
テンプレートを使用すると、Sensitive Data Protection で構成情報を作成して保持できます。テンプレートは、検査の目的や匿名化の方法などの構成情報をリクエストの実装から分離するのに役立ちます。テンプレートの詳細については、Sensitive Data Protection のテンプレートをご覧ください。
Cloud Audit Logs は、このアーキテクチャで使用される Google Cloud の統合ロギング サービスです。まず、Cloud Audit Logs は、Cloud Data Loss Prevention API（Sensitive Data Protection の一部）に対して行われた呼び出しの監査証跡を提供します。監査ログエントリには、API 呼び出しを行ったユーザー、実行された Google Cloud プロジェクト、リクエストの詳細（リクエストの一部としてテンプレートが使用されたかなど）に関する情報が含まれています。次に、アプリケーションの構成ファイルを使用して監査を有効にすると、Cloud Audit Logs によって検査結果の概要が記録されます。
Cloud Key Management Service（Cloud KMS）は、クラウド サービス用の暗号鍵を管理できる Google Cloud のクラウドホスト型鍵管理サービスです。
Sensitive Data Protection のトークン化と日付シフトのメソッドでは、暗号を使用して置換値を生成します。これらの暗号方法では、鍵を使用して一貫性のある方法で値を暗号化して参照整合性を維持するか、元に戻す方法でトークン化を解除します。この鍵は、呼び出し時に Sensitive Data Protection に直接提供することも、Cloud KMS を使用してラップすることもできます。Cloud KMS で鍵をラップすると、別のアクセス制御と監査のレイヤが提供されるため、本番環境でのデプロイに適しています。
本番環境の構成では、最小権限の原則を使用して権限を割り当てる必要があります。次の図は、この原則の例を示しています。
上の図は、一般的な本番環境の構成で、生データに対する異なるロールとアクセス権を持つ 3 つのペルソナを示しています。
- インフラストラクチャ管理者: プロキシをインストールして構成し、機密データの保護のプロキシがインストールされているコンピューティング環境にアクセスできるようにします。
データ アナリスト: DLP プロキシに接続するクライアントにアクセスします。
セキュリティ管理者: データの分類、機密データの保護のテンプレートの作成、Cloud KMS の構成を行います。
Cloud KMS を使用したデータの暗号化と復号の詳細については、データの暗号化と復号をご覧ください。
このドキュメントで使用されている DLP プロキシの場合、この情報はすべて、機密データの保護の匿名化テンプレートで構成されています。
監査、マスキング、トークン化による PII の保護
このシナリオでは、PII が公開されるリスクを軽減するために実装できる戦略は 2 つあります。
データベースに保存された元データ
アプリケーションで元データがデータベースに保存される場合、DLP プロキシを使用して、機密情報の監査を自動的に検査して生成することで、ユーザーに返される結果を処理できます。または、次の図に示すように、クエリ結果をリアルタイムでマスクすることもできます。
この構成では、DLP プロキシに接続する SQL クライアントを使用する必要があります。アプリで監査を有効にすると、検査結果の概要を含むログが Cloud Audit Logs で作成されます。この概要は、クエリで返された機密情報の種類を示します。
匿名化された形式で保存されたデータ
元データを保存しない場合、次の図に示されているように、データベースに対する ETL プロセス中に匿名化変換を実行することで、匿名化された形式またはマスクされた形式でアプリケーションのデータを保存できます。
上の図は、データが検査されて、マスクされてから、データベースに取り込まれる基本的なフローを示しています。ユーザーがこのデータに対してクエリを実行すると、データベースに直接アクセスできる場合でも、マスクされたバージョンしか表示できません。
マスクされていないデータがユーザーに表示されるようにする場合は、次の図に示すように、データのマスク解除を行う権限を持つ DLP プロキシのインスタンスに接続できるクライアントを使用する必要があります。
上の図は、クライアントを使用して DLP プロキシに接続し、マスクされていないデータがクライアントに表示されるようにする方法を示しています。
次のステップ
- データの管理: トークン化により、プライバシーを犠牲にすることなくデータを使用可能にする方法。
次の機密データの保護の技術ドキュメントを確認する。
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。