ジョブは、機密データがないかコンテンツをスキャンするため、または再識別のリスクを計算するために機密データの保護により実行されるアクションです。Sensitive Data Protection は、データの検査を指示されるたびにジョブリソースを作成して実行します。
現在、Sensitive Data Protection のジョブには次の 2 つのタイプがあります。
- 検査ジョブは、基準に従って機密データがないかコンテンツを検査し、どこにどのような種類の機密データが存在するかについて要約レポートを生成します。
- リスク分析ジョブは、匿名化されたデータを分析し、そのデータが再識別される可能性に関する指標を返します。
ジョブトリガーを作成することで、Sensitive Data Protection がジョブを実行するタイミングをスケジュールできます。ジョブトリガーは、Cloud Storage バケット、BigQuery テーブル、Datastore の種類など、 Google Cloud ストレージ リポジトリをスキャンする Sensitive Data Protection のジョブの作成を自動化するイベントです。
ジョブトリガーを使用すると、各トリガーを起動する間隔を構成してスキャンジョブをスケジュールできます。前回のスキャン以降の新しい検出結果を検索してコンテンツの変更や追加を監視することや、最新の検出結果レポートの生成ができます。スケジュールされたトリガーは、1 日から 60 日の間で設定した間隔で実行されます。
ジョブトリガーを使用する場面
一般的なユースケースは次のとおりです。
- 定期的なコンプライアンス スキャンを自動化する: Cloud Storage バケットと BigQuery テーブル全体で定期的な検査スキャンをスケジュールして、新しく保存されたセンシティブ データの継続的な可視性を維持します。
- 動的ストレージの検査費用を最適化する: ジョブトリガーに期間ルールを構成して、前回のスキャン サイクル以降に追加または変更されたコンテンツのみをスキャンします。
- 本番環境データベースで進行中のデータドリフトをモニタリングする: リスク ポスチャーのレビュー用に定期的に検出結果の概要を生成して、センシティブ データのデータ漏洩の経時的な変化を追跡します。
- イベント ドリブン データ パイプラインと連携する: Cloud Storage のアップロード イベントまたは自動 ETL パイプラインのマイルストーンに応じて検査ジョブをトリガーします。
次のステップ
以下のトピックでは、ジョブおよびジョブトリガーを作成、編集、実行する方法について詳しく説明します。
- Sensitive Data Protection の検査ジョブとジョブトリガーの作成
- 再識別と開示リスクの評価(リスク分析ジョブについて説明)
さらに、次のクイック スタートも利用できます。
JobTrigger オブジェクト
ジョブトリガーは、DLP API で JobTrigger オブジェクトとして記述します。
ジョブトリガーの構成フィールド
JobTrigger には次のような構成フィールドがあります。
- トリガーの名前、表示名、説明。
Triggerオブジェクトのコレクション。それぞれScheduleオブジェクトを含み、スキャンの繰り返しが秒単位で定義されます。InspectJobConfigオブジェクト。トリガーされるジョブの構成情報が含まれます。Status列挙。トリガーが現在アクティブかどうかを表します。- タイムスタンプ フィールド。作成、更新、最終実行時間を表します。
Errorオブジェクトのコレクション。存在する場合は、トリガーがアクティブの間にエラーが発生しています。
ジョブトリガー メソッド
JobTrigger オブジェクトには、いくつかの組み込みメソッドがあります。これらのメソッドを使用すると、次のことができます。
- 新しいジョブトリガーを作成する:
projects.jobTriggers.create - 既存のジョブトリガーを更新する:
projects.jobTriggers.patch - 既存のジョブトリガーを削除する:
projects.jobTriggers.delete - 既存のジョブトリガー(構成とステータスを含む)を取得する:
projects.jobTriggers.get - 既存のジョブトリガーをすべて一覧表示する:
projects.jobTriggers.list
ジョブのレイテンシ
ジョブとジョブトリガーに対するサービスレベル目標(SLO)は保証されません。レイテンシは、スキャンするデータの量、スキャン対象のストレージ リポジトリ、スキャン対象の infoType のタイプと数、ジョブが処理されるリージョン、そのリージョンで使用可能なコンピューティング リソースなどさまざまな要因に影響を受けます。したがって、検査ジョブのレイテンシは事前に決定できません。
ジョブのレイテンシを短縮するため、次の方法を試すことができます。
- ジョブまたはジョブトリガーでサンプリングを利用できる場合は、有効にします。
不要な infoType は有効にしないでください。以下は特定のシナリオで有用ですが、これらの infoType により、リクエストの実行速度がこれらを含まないリクエストよりもはるかに遅くなる可能性があります。
PERSON_NAMEFEMALE_NAMEMALE_NAMEFIRST_NAMELAST_NAMEDATE_OF_BIRTHLOCATIONSTREET_ADDRESSORGANIZATION_NAME
infoType は常に明示的に指定します。空の infoType リストを使用しないでください。
可能であれば、処理を行う別のリージョンを使用します。
これらの手法を試してもジョブに関するレイテンシの問題が解決しない場合は、ジョブではなく content.inspect リクエストまたは content.deidentify リクエストの使用を検討してください。これらのメソッドはサービスレベル契約の対象となります。詳細については、Sensitive Data Protection のサービスレベル契約をご覧ください。
スキャンを新しいコンテンツのみに制限する
Cloud Storage または BigQuery に保存されるファイルのタイムスパンの日付を自動的に設定するジョブトリガーを構成できます。TimespanConfig オブジェクトを自動入力に設定すると、Sensitive Data Protection は、トリガーが最後に実行されてから追加または変更されたデータのみをスキャンします。
...
timespan_config {
enable_auto_population_of_timespan_config: true
}
...
BigQuery 検査については、3 時間以上経過した行のみがスキャン対象となります。このオペレーションに関連する既知の問題をご覧ください。
ファイルのアップロード時にジョブをトリガーする
Sensitive Data Protection に組み込まれているジョブトリガーのサポートに加えて、Google Cloud には Sensitive Data Protection ジョブの統合やトリガーに使用できるさまざまなコンポーネントがあります。たとえば、ファイルを Cloud Storage にアップロードするたびに、Cloud Run functions を使用して Sensitive Data Protection スキャンを開始できます。
このオペレーションの設定方法については、Cloud Storage にアップロードされたデータの分類の自動化をご覧ください。