Video
Databricksのテスト開発環境内の機密データ存在は、GDPRやHIPPAといった規制への準拠をに反するリスクとなり得ます。このデモビデオでは、Perfore DelphixプラットフォームがDetabricks内の機密データの検出および適切なデータマスキングの実施をどのように自動化するかについて紹介します。個人情報を効率的に検出し、適切なマスキングアルゴリズムを適用しデータ分析やAI活用の用途として、機密情報をふくまない本番データ同等のデータを安全に提供する動作を確認ください。
デモで以下の内容を学習できます:
- マスキングジョブを実行するためにDatabricksノートブック内にDelphix APIの設定
- テーブルやスキーマ内のPII（個人情報）を自動的に検出する機密データ検出ジョブの実行
- 複数の異なるデータタイプに応じて特定のマスキングアルゴリズムを割当たジョブ実行結果の確認
- 安全で架空のデータを新しいカタログへ書き込む一連のマスキングワークフローの実行
- 元とマスキング後のデータセットを比較しマスキング結果を検証
- マスキングされたデータがGDPR, HIPPAおよび他の規制に対して準拠できる内容であることを確認
Databricksマスキングの動作を確認
DelphixソリューションがDatabricksのデータマスキングをどのように容易に実現するか確認する
デモビデオの文字起こし
みなさんこんにちは、私の名前はJatinder Luthraです。本日は、Perforce Delphixを使用したDatabricksデータのマウスキングについて紹介します。
別の（Snowflakeの）デモをご覧頂いた方であれば、Delphix Compliance Servicesがどいういうものかご存じかと思います。Delphix Compliance ServicesはAPIとしてのマスキングサービスで、DelphixのContinuous Complianceエンジンなどのインフラ無しに、機密データの検出とマスキングを可能とします。
Databricksのどこでマスキング済みデータを使うのでしょうか？ いくつかの異なるユースケースが存在します。まず1つめとして、テストや開発、QAといったDatabricksの非本番環境で機密情報の漏洩を防ぐために使われるケースが挙げられます。また、データサイエンスや機械学習のプロジェクトにおいて、プライバシー規制に準拠した状態でモデルを学習させるデータとしての用途もあります。加えて、パートナーやチーム間で安全にマスキング済みデータを共有するというユースケースも考えられます。
マスキング済みデータの使用は、PII（個人情報）や他の機密情報を危険にさらすことなく、AIやデータ分析BIプロセスを通じた洞察をえることができます。加えて、GDPR, HIPPAなどの規制への準拠のようなコンプライアンスや監査要件にも適合します。
それでは、デモに移りましょう。こちらはDetabricks内のJupyter Notebookです。1つのカタログがらデータを参照し、他のカタログへデータを書き込みます。このケースでは、DCS Azureソースカタログからデータを読みこみ、DCS Azureマスキング済みカタログへ書き出します。2つのカタログを見てみます。こちらがソースカタログで、こちらがマスキング済みカタログです。ソース側のprod_app_schemaとマスキング済みカタログ配下にある書き出し先のanalytics_app_schemaを使用します。
それでは、マスキングの前の検出プロセスを開始します。検出を開始する際は、メタデータ格納領域として使用する別のカタログ内にインベントリ情報を保持します。ここは現在は空の状態です。
検出プロセスを開始前のいくつかのステップを実行します。このように、いくつかの設定を行います。インポート作業やDCSクライアントの設定およびDatabricksマネージャーの設定,Databricksクライアントでローカルデータを読み込むための初期化などです。
その後、「Centralized Configuration Managment」でデモに必要な複数の異なるAPIシークレットキーを使用可能とする設定を行います。これらのシークレットキーはDatabricksシークレット内に保存されており、テナントIDやDCS APIサービスキーも含まれています。いくつかの「Helper Functions」が設定作業をサポートし、「Health Check and Metadata Viewer Configuration」などを通じて、シークレットキーがきちんと機能するか確認します。
プロセスは並列で実行したいので、検出の実行を並列処理を設定します。検出をスタートさせると、インベントリ情報を使用してどのようなデータが検出/認識されたかを確認することができます。ワークフロータイプをこのように最上位で「discovery」に切り替え、prod_app_schemaをスキャンし検出対象とします。テーブルのリストはここでは設定せず、prod_app_schemaスキーマ内の全てのテーブルがスキャン対象となります。検出ジョブを実行中です。完了まで待ち、どのようなものが検出/認識されたかインベントリー情報おｗ確認します。
それでは見てみましょう。結果はインベントリー内で全て確認できます。特定のカラムに着目します。Delphix Compliance Servicesによって機密情報として認識されたされたカラムがこちらになります。加えて、マスキングするための推奨アルゴリズムがこちらです。
割り当てられたアルゴリズムカラムをマスキング処理の指示として考えてください。マスキング処理では、この割り当てられたアルゴリズムカラムを読み取ります。指定されたアルゴリズムが何であれ、そのアルゴリズムを使用して当該列カラムデータをマスキングします。
変更を実施した後、例えば保険事業者の名前がフルネームとして識別されたたが実際は機密情報ではない場合、そのアルゴリズムを削除することができます。いくつかのアルゴリズムはそのまま使用します。個人識別番号のような特定のアルゴリズムについては、無効化することは望ましくありません。その場合は、別のアルゴリズムを使用してデータを変更します。検出結果のレビューと変更を実施したので、マスキング処理を実行する準備が整いました。
マスキング処理を実行する前に、すべてのテーブルに共通して存在するデータを確認しましょう。元のpatient_detailsテーブルには10,000行のデータが含まれています。他のテーブルも同様に10,000行ずつ存在しますが、マスキング対象のスキーマ内では空のテーブルとなっています。
それではマスキングワークフローを実行し、マスキングスキーマに移動して新しいレコードの作成を確認しましょう。
このワークフローを「masking」に変更し再実行します。マスキング処理とデータ配信が進行中です。1つのソースからデータを読み取り、マスキング処理を施した後別の場所に書き込みます。必要に応じて、インプレイスマスキングに変更することも可能です。書き込み先の情報はこちらです。マスキング済みカタログ（ターゲット）とターゲットスキーマであるanalytics_schemaが入力されています。
書き込みモードはオーバーライトで、ターゲット側で何かデータを保持していた場合でも、新しいデータを書き込む前に全削除します。今回については、ターゲットは最初から空の状態です。マスキングが完了するまで待って、データを確認します。
それでは、マスキングプロセスが完了しました。
両方のテーブルのレコード数を確認し、データが書き込まれているか確認します。書き込み先テーブルで10,000行の存在が確認できます。比較を行ってみまっしょう。personテーブルでいくつかの行IDを指定して元のテーブルとマスキング済みデータを比較します。この特定の行IDについて、ファーストネームが住所, 市, メールアドレスと共に変更されていることが確認できます。patient detailsテーブルも確認します。
ファーストネーム, ラストネーム、フルネームが確認できます。これら全てのレコードは架空化されたマスキング済みの値に変更されています。CPTデータについても同様です。インベントリー上でアルゴリズムが割り当てられた全てのカラムはマスキングされています。
vehicle dataテーブルなどのいくつかのテーブルでは、機密データを保存していないためデータは元の状態のまま書き込まれています。つまり、元のデータとマスキング後のデータは同じになります。以上で、Databricksノートブックを使用したDatabricksマスキングデモを終了します。このデモで使用したJupyter Notebookにご興味がある場合は、私のGitHubリポジトリ（mask-databricks-notebook）から入手できます。ノートブックに加えて使用方法に関する説明もそちらから入手できます。
どうもありがとうございました。次のデモでお目にかかるのを楽しみにしています。