はじめのProfessional Cloud Data Engineer認定取得講座㉛Datastream、BigQuery のデータマスキング、Sensitive Data Protection活用ガイドについて説明します！

今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。

今回は、Datastream、BigQuery のデータマスキング、Sensitive Data Protection活用ガイドについて説明します！

ぜひ、最後までご覧いただけると嬉しいです！

Datastream

Datastream は、Google Cloud が提供するサーバーレスの「変更データ キャプチャ（CDC）」および「レプリケーション」サービスです。

従来のバッチ処理（1日1回データを転送するETL）とは異なり、Datastream はオンプレミスや他のクラウドにあるデータベース（Oracle, MySQL, PostgreSQL など）で発生した変更（INSERT, UPDATE, DELETE）をほぼリアルタイムで検出し、Google Cloud の宛先（BigQuery, Cloud Storage, Spanner, Cloud SQL）にデータを同期し続けます。

主なメリット

• サーバーレス (管理不要)：Datastream の最大のメリットです。Kafka のようなメッセージ キューや Dataflow のような処理エンジンのためのインフラを一切プロビジョニング（構築・管理）する必要がありません。Google がすべて自動でスケーリングします。
• リアルタイム性：ソースデータベースで発生した変更を、数秒から数分のレイテンシで宛先に反映できます。これにより、常に最新のデータに基づいた分析やアプリケーション動作が可能になります。
• シンプルさ：設定は GUI ベースで非常にシンプルです。複雑なパイプラインのコーディングは不要です。

Datastream の仕組み：「バックフィル」と「CDC」

Datastream のストリーム（データ転送）は、大きく2つのフェーズで動作します。

1. バックフィル (Backfill)：ストリームを開始すると、Datastream はまず、ソースデータベースの既存の全データ（スナップショット）を宛先にコピーします。これが「バックフィル」です。
2. CDC (変更データ キャプチャ)：バックフィルが完了すると、Datastream は CDC モードに移行します。ソースデータベースのトランザクションログ（Oracle の Redo ログ、MySQL の Binlog など）を監視し、バックフィル以降に発生したすべての変更（INSERT, UPDATE, DELETE）をキャプチャし、宛先にリアルタイムでストリーミングし続けます。

宛先への書き込みモード

Datastream は、宛先（特に BigQuery）に対して、主に2つの書き込みモードを提供します。これはユースケースに応じて選択します。

1. マージ

• 動作：BigQuery の MERGE ステートメントのように動作します。
  • INSERT：ソース側で新しい行が挿入されると、宛先にも新しい行が挿入されます。
  • UPDATE：ソース側で既存の行が更新されると、宛先の対応する行も上書き更新されます。
  • DELETE：ソース側で行が削除されると、宛先の対応する行も削除されます（オプション）。
• ユースケース：「現在の最新の状態」だけを BigQuery で保持したい場合に最適です。BI ダッシュボードでの参照などに使われます。

2. 追加専用

• 動作：すべての変更履歴を「新しい行」として追記していきます。
  • INSERT：新しい行として挿入されます。
  • UPDATE：古い値の行と新しい値の行が、両方とも宛先に挿入されます。
  • DELETE：削除された行の情報が、新しい行として挿入されます。
• ユースケース：「いつ、データがどう変わったか」：という変更履歴全体を分析したい場合に最適です。監査や時系列分析に使われます。

主なユースケース

Datastream は、これらの特徴を活かして、以下のようなシナリオで活躍します。

• リアルタイム分析基盤 (vs バッチETL)：オンプレミスの Oracle や MySQL のトランザクション データを、BigQuery にリアルタイム同期します。これにより、分析チームは常に最新の（数分遅れの）データで BI レポートや機械学習モデルの推論を実行できます。
• データベースのレプリケーションと移行：オンプレミスのデータベース（例：Oracle, MySQL）から、Cloud SQL (PostgreSQL, MySQL) や Cloud Spanner へ、ダウンタイムを最小限に抑えながらデータをレプリケーション（移行）するために使用します。
• データレイクへの取り込み：すべてのデータベース変更履歴（CDC）を、未加工のまま Cloud Storage にJSONまたは Avro 形式で保存し、データレイクの「生データ」として活用します。

Datastreamのまとめ

Datastream は、データベースの変更をリアルタイムで取り込み、BigQuery などの宛先へ自動同期できるサーバーレス CDC サービスです。バックフィルと CDC を組み合わせることで、既存データのコピーから継続的な変更反映までを一貫して実行できます。用途に応じて「マージ」と「追加専用」を選択でき、最新状態の保持から変更履歴の蓄積まで幅広く対応します。インフラ管理不要で設定も簡単なため、分析基盤のリアルタイム化や DB 移行、データレイク構築に最適な選択肢となります。Datastream を活用すれば、最新データを活かした迅速な意思決定が可能になります。

BigQuery のデータマスキング

BigQuery の動的データマスキングは、機密性の高い列データ（例：個人情報、財務情報）を、ユーザーのアクセスレベルに応じてリアルタイムで隠す（マスクする）セキュリティ機能です。

これは、データそのものを変更するのではなく、クエリ（SELECT）が実行された瞬間に、そのユーザーにどのデータを見せるべきかを判断し、動的にデータを変換します。

これにより、アナリストや開発者は機密データそのものにアクセスすることなく、テーブルの構造や非機密データを使った分析作業を行うことが可能になります。

仕組み：「ポリシータグ」と「マスキングルール」

BigQuery のデータマスキングは、主に2つのコンポーネントで機能します。

1. ポリシータグ (Policy Tags)
   • これは、Data Catalog サービスを使用して作成する「機密ラベル」です。
   • まず、「PII（個人情報）」や「機密レベル: 高」といったタグを作成します。
   • 次に、BigQuery テーブルのスキーマ（列）に対して、これらのタグを割り当てます（例：email 列に PII タグを付与）。
2. データポリシー (Data Policies) ／マスキングルール
   • 次に、「PII タグが付いた列」にアクセスしようとしたときに、どのような処理を行うかを定義します。
   • マスキングルールとは、データをどのように隠すかの定義です（例：NULL 化、ハッシュ化、デフォルト値への置換など）。
   • データポリシーは、「誰が」このルールを適用されるかを定義します。特定のユーザーグループ（例：analyst-group@...）に対して、「PII タグが付いた列には NULL 化マスキングを適用する」といったポリシーを作成します。

アクセス権限の2つのレベル

この仕組みにより、ユーザーは2種類のアクセス権のどちらかを持つことになります。

• マスクされた読み取り
  • データポリシーによってマスキングが適用されるユーザー（例: analyst-group）。
  • このユーザーが SELECT email FROM ... を実行すると、NULL やハッシュ値（例：sg172y...）など、マスクされた結果を受け取ります。
• きめ細かい読み取り
  • データポリシーの対象外であり、マスキングが免除されるユーザー（例：admin-group）。
  • このユーザーが同じクエリを実行すると、hajime@example.com のような生のデータを受け取ります。

他の機能との互換性（注意点）

データマスキングは強力ですが、他の BigQuery 機能と併用する際には注意が必要です。

• 行レベルのセキュリティ：互換性があります。行レベルのフィルタリングが適用された後、その結果に対してデータマスキングが適用されます。
• コピージョブ／スナップショット：互換性がありません。テーブルのコピーやスナップショットを作成するには、全データへの「きめ細かい読み取り（フルアクセス）」権限が必要です。
• ワイルドカード テーブルクエリ：互換性がありません。table_* のようなクエリを実行するには、全データへのフルアクセス権限が必要です。
• BI Engine：互換性がありますが、データマスキングが有効なクエリは BI Engine によって高速化されません。これにより、Looker Studio などのダッシュボードの表示が遅くなる可能性があります。

BigQuery のデータマスキングのまとめ

BigQuery の動的データマスキングは、ユーザー権限に応じて機密データをリアルタイムに制御できる強力なセキュリティ機能です。ポリシータグとマスキングルールを組み合わせることで、個人情報などの機密列を安全に扱いながら、業務に必要な分析作業を継続できます。マスクされた読み取りとフルアクセスを明確に分けられるため、最小権限の原則を効率よく実現できます。一方、コピーやスナップショット、ワイルドカードクエリなど一部機能とは併用制限がある点は要注意です。適切に設計すれば、データ利活用とセキュリティを両立した安全な分析基盤を構築できます。

Sensitive Data Protection活用ガイド

企業のデータ活用が進む中で、最も頭を悩ませるのが「個人情報（PII）」や「機密情報」の管理です。知らない間にCloud StorageやBigQueryの中に、クレジットカード番号やメールアドレスが含まれたファイルが紛れ込んでいることがあります。

今回は、Google Cloudのマネージドサービスである Sensitive Data Protection（旧称：Cloud Data Loss Prevention / Cloud DLP） を使用して、ストレージ内の機密データを効率的に検査・発見する方法について解説します。

Sensitive Data Protection とは？

Sensitive Data Protection は、Google Cloud 上（および外部）のデータに対して、機密情報の 「検出（検査）」 、「分類」 、「匿名化（マスキング）」 を行うフルマネージドサービスです。

特に「ストレージ検査機能」を使用すると、サーバーを立てたり複雑なスクリプトを書いたりすることなく、大量のデータセットをスキャンしてリスクを可視化できます。

1. 何を検査できるのか？（対象ストレージ）

Sensitive Data Protection は、以下のGoogle Cloudストレージサービスに保存されているデータを直接スキャンできます。

• Cloud Storage：テキストファイル、CSV、画像（OCR機能により画像内の文字も検査可能）、PDF、Excelなど。
• BigQuery：テーブル内のデータを列単位・行単位でスキャン。
• Datastore：エンティティ内のプロパティをスキャン。

2. どうやって検出するのか？（InfoType）

検出の核となるのが 「InfoType（情報タイプ）」 です。 Google Cloudには、あらかじめ世界中の機密情報のパターンが定義されています。

• グローバル：クレジットカード番号、メールアドレス、IPアドレス、URLなど。
• 日本固有：マイナンバー、運転免許証番号、パスポート番号など。

これらを選択するだけで検査が可能です。また、自社固有の社員番号やプロジェクトコードなどを検出したい場合は、正規表現や辞書を使って「カスタムInfoType」を作成することもできます。

3. 検査ジョブの仕組み

ストレージの検査は「検査ジョブ（Inspection Job）」を作成して実行します。運用に合わせて2つの実行モードがあります。

A. 即時実行（ワンショット）

「現在のバケットの状態を確認したい」場合に使用します。一度だけスキャンを実行し、結果を出力します。

B. スケジュール実行（ジョブトリガー）

「毎日増え続けるデータを監視したい」場合に使用します。

• 定期的に実行（例：24時間ごと）。
• 増分スキャン：前回スキャン以降に変更・追加されたファイルだけを検査対象にすることで、コストと時間を大幅に節約できます。

4. コストとパフォーマンスの最適化（サンプリング）

ペタバイト級のデータをすべて検査すると、コストも時間もかかります。そこで、Sensitive Data Protectionには効率的なスキャンオプションが用意されています。

• サンプリング：「全ファイルの10%だけチェックする」「先頭の100行だけチェックする」といった設定が可能です。全体的なリスク傾向を把握するだけであれば、サンプリングで十分なケースが多くあります。
• 含める／除外するファイル：特定の拡張子やパスだけを対象にする、または除外することができます。

5. 検査結果の活用方法（アクション）

検査を行って「終わり」ではありません。検出結果（どこに、何件、どのような機密情報があったか）を以下のアクションで活用できます。

1. BigQueryへ保存：検出結果をBigQueryのテーブルに保存します。これにより、Looker Studioなどで「機密情報の分布ダッシュボード」を作成し、可視化することができます。 (※元データそのものではなく、「ファイルAにクレジットカード番号が3件あった」という統計情報が保存されます)
2. Pub/Subへの通知：検査完了時や特定のリスクが見つかった際にPub/Subへメッセージを送信します。これをトリガーにしてCloud Functionsを動かし、「管理者にSlack通知を送る」「該当ファイルを自動的に隔離バケットへ移動する」といった自動化ワークフローが構築できます。
3. Data Catalog (Dataplex) へのタグ付け：検出結果に基づき、BigQueryのテーブルなどに自動で「機密」タグを付与し、アクセス制御に利用することができます。

Sensitive Data Protection活用ガイドのまとめ

Sensitive Data Protection は、大量のストレージに潜む機密情報を自動検出し、リスクを可視化できる強力なサービスです。InfoType による高度なパターン認識と、カスタム定義による柔軟な拡張性により、企業固有の情報も漏れなく検査できます。検査ジョブは即時・定期どちらにも対応し、サンプリング設定でコスト最適化も容易です。検出結果は BigQuery や Pub/Sub、Data Catalog へ連携でき、監視・可視化・自動化まで一貫した運用を実現します。適切に活用することで、データ利活用とセキュリティ強化を両立した安全なクラウド基盤を構築できます。

まとめ

今回は、下記３点について説明しました。

1. Datastream
2. BigQuery のデータマスキング
3. Sensitive Data Protection活用ガイド

Datastream・データマスキング・Sensitive Data Protection は、Google Cloud 上でのデータ活用とセキュリティを同時に強化するための主要サービスです。Datastream はリアルタイム同期によって最新データ分析を可能にし、データマスキングは権限に応じて機密情報を安全に取り扱える環境を提供します。さらに Sensitive Data Protection を併用することで、ストレージ内の機密データを自動検出し、継続的なリスク管理が実現できます。これらを組み合わせれば、運用負荷を抑えながらも高度なデータ保護と利活用を両立した基盤を構築できます。Google Cloud を活用したセキュアかつ実践的なデータプラットフォーム設計の参考になれば幸いです。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！