第8回：最後の砦！データ保護戦略（暗号化とVPC-SC）
はじめに
お疲れ様です。SKYこと関谷です。
前回の第7回では、ログの集中管理と監視アラートについて学びました。
Cloud Logging と Cloud Monitoring で重要な事象を自動検知する仕組みを構築し、「何が起きているか把握する」基盤が完成しました。
そして、ここまでの7回で、 組織構造、IAM、VPC、ファイアウォール、Shared VPC、組織のポリシー、ログ管理と監視 という多層防御を積み重ねてきました。
しかし、重要な問いが浮かび上がります。
もしこれらすべてをすり抜けて、データそのものに不正アクセスされた場合、どうなるのでしょうか。
適切な権限を持つ管理者アカウントが侵害された場合や、内部関係者が意図的にデータを持ち出そうとした場合、IAM もファイアウォールも組織のポリシーも防げません。正当な権限を使った正当なアクセスだからです。ログには記録が残りますが、データが持ち出された後では手遅れです。
本回では、この「最悪のシナリオ」に備える最後の砦、データ保護戦略について解説します。
暗号化 と VPC Service Controls（VPC-SC） という二つの仕組みを学び、データそのものと、データへのアクセス経路の両方を守る方法を理解していきましょう。
暗号化は、データが盗まれても読めないようにする技術です。Google Cloud ではデフォルトで全データが暗号化されていますが、さらに強固な保護には、顧客管理の暗号鍵（ CMEK ） と Cloud KMSで暗号鍵そのものを自分たちで管理できます。
VPC Service Controls は、プロジェクトやサービスを仮想的な壁で囲み、 境界外へのデータ持ち出しを物理的に防ぎます。
正当な権限を持っていても、境界を越えた通信は許可されません。
本回では、なぜこれらの技術が必要なのか、どのように機能するのか、そしてどのように実装すればよいのかを、できるだけ分かりやすく解説します。
それでは、Google Cloud におけるデータ保護の世界へ、一緒に踏み出していきましょう。
ブログシリーズその他の執筆
本編
番外編
第３回では紹介しなかった関連機能の説明です
8-1. データの暗号化：重要資産を守る最後の鍵
データ保護戦略の第一の柱は暗号化です。IAM やファイアウォールをすり抜けてデータが盗まれた場合、最後に守ってくれるのが暗号化です。
暗号化とは何か？なぜ必要なのか？
暗号化とは、データを特殊な鍵を使って読めない形に変換する技術です。万が一盗まれても、鍵がなければ内容を読めません。Google Cloud のセキュリティモデルでは、暗号化は多層防御の最後の層として、「データそのもの」を守ります。
Google によるデフォルト暗号化の仕組み
Google Cloud では、利用者が何も設定しなくても、すべてのデータが自動的に暗号化 されています。Cloud Storage、BigQuery、Compute Engine など、すべてのサービスで保存前にデータが暗号化されます（保存時の暗号化）。
また、ネットワーク上を移動するデータも TLS などで暗号化 されています（転送中の暗号化）。
暗号化
| 暗号化の種類 | 適用されるタイミング | 対象となるデータ | 利用者の設定 | 使用される鍵 |
|---|---|---|---|---|
| 保存時の暗号化（Encryption at Rest） | データがストレージに保存される時 | Cloud Storage、BigQuery、Compute Engine ディスク、Cloud SQL など、すべての保存データ | 不要（自動） | Google 管理の暗号鍵（GMEK） |
| 転送中の暗号化（Encryption in Transit） | データがネットワーク上を移動する時 | インターネット経由の通信、Google Cloud 内部の通信 | 不要（自動） | TLS などの標準プロトコル |
| 使用中の暗号化（Encryption in Use） | データがメモリ上で処理される時 | Confidential VM などの特殊な環境 | 必要に応じて有効化 | ハードウェアベースの暗号化 |
なぜ顧客管理の暗号鍵（CMEK）が必要なのか？
デフォルト暗号化では、暗号鍵は Google が管理しています（GMEK） 。
しかし、より高度なセキュリティ要件やコンプライアンス要件に対応するため、暗号鍵そのものを自分たちで管理したい場合があります。
例えば、金融機関や医療機関では規制により「暗号鍵の管理者を明確にする」ことが求められます。また、「Google 社の従業員であっても、自社の許可なくデータにアクセスできないようにしたい」という要望もあります。このような場合に使用するのが、顧客管理の暗号鍵（CMEK） です。
CMEK を使用すると、暗号鍵の作成、ローテーション、無効化、削除を利用者自身が管理できます。
暗号鍵を無効化すれば、その鍵で暗号化されたデータは誰も復号化できません。
また、データ主権への対応として、暗号鍵を特定のリージョンに配置し、法規制に準拠した運用も可能です。
GMEKとCMEK
| 比較項目 | GMEK（Google 管理） | CMEK（顧客管理） |
|---|---|---|
| 鍵の管理者 | 利用者 | |
| 設定の必要性 | 不要（自動） | 必要 |
| 鍵のローテーション | Google が自動実行 | 利用者が制御可能 |
| 鍵の無効化 | 不可 | 可能 |
| 鍵の保管場所 | Google のインフラ | Cloud KMS（利用者が管理） |
| コスト | 無料 | Cloud KMS の利用料金が発生 |
| 適用範囲 | すべてのデータ（デフォルト） | 利用者が指定したリソースのみ |
| コンプライアンス対応 | 基本的なセキュリティ要件 | 高度なコンプライアンス要件（金融、医療など） |
Cloud KMS の役割：暗号鍵の金庫
顧客管理の暗号鍵を実現するのが、 Cloud KMS（Cloud Key Management Service） です。Cloud KMS は、暗号鍵を安全に保管し、管理するための専用サービスです。
Cloud KMS では、暗号鍵は「鍵（キー, Key）」という単位で管理され、「キーリング（Key Ring）」という論理的なグループにまとめられます。
重要な特徴は、暗号鍵そのものが Cloud KMS の外に出ることはない ということです。暗号鍵は常に Cloud KMS という「金庫」の中に安全に保管されたまま、その機能だけを外部に提供します。
Cloud KMS は IAM と統合されており、第3回で学んだ「最小権限の原則」を適用できます。
また、すべての操作は監査ログに記録され、第7回で学んだログ集約の仕組みに統合されます。
Cloud KMS を利用した暗号・復号化
暗号鍵のライフサイクル管理
暗号鍵は作成されてから、使用され、最終的には無効化または破棄されるまで、いくつかの状態を遷移します。
「有効（Enabled）」状態では、鍵を使ってデータを暗号化・復号化できます。セキュリティのベストプラクティスとして、暗号鍵は定期的にローテーション（更新）すべきです。
Cloud KMS では、90日ごとに自動的に新しい鍵を生成する等の 自動ローテーション を設定できます。
「無効化（Disabled）」状態では、新しいデータの暗号化はできませんが、既に暗号化されたデータの復号化は可能です。
「破棄予定（Scheduled for Destruction）」状態では、暗号化も復号化も一切できず、24時間後に実際に破棄されます。また、一度破棄された鍵は、二度と復元できません。
鍵のライフサイクル
| 鍵の状態 | 新しいデータの暗号化 | 既存データの復号化 | 説明 | 主な用途 |
|---|---|---|---|---|
| 有効（Enabled） | 可能 | 可能 | 鍵が正常に機能している状態 | 通常の運用 |
| 無効化（Disabled） | 不可 | 可能 | 一時的に新しい暗号化を停止 | セキュリティインシデント調査中の一時停止 |
| 破棄予定（Scheduled for Destruction） | 不可 | 不可 | 24時間後に完全に破棄される | 鍵を完全に削除する前の猶予期間 |
| 破棄済み（Destroyed） | 不可 | 不可 | 鍵が完全に削除され、復元不可 | 鍵が不要になった、またはコンプライアンス要件 |
CMEK の実装における注意点
CMEK 実装時の主な注意点は以下の通りです。
鍵の管理責任が利用者に移るため、鍵を誤って破棄するとデータは二度と復号化できません。適切なバックアップ戦略が必要です。Cloud KMS の利用には追加のコストが発生し、暗号化・復号化のパフォーマンスに若干の影響が出る可能性があります。
IAM 権限の設定では、暗号鍵を使用する権限（roles/cloudkms.cryptoKeyEncrypterDecrypter）と、鍵を管理する権限（roles/cloudkms.admin）を必ず分離します。
また、CMEK はすべての Google Cloud サービスで利用できるわけではない ため、事前に対応状況を確認してください。
CMEKへの対応状況は、必ず下記の公式情報をご確認ください。
8-2. データ漏えいの脅威：IAM だけでは防げないリスク
前節で暗号化の仕組みを理解しました。しかし、暗号化だけではデータ保護は完全ではありません。この節では、正当な権限を持つ人によるデータ持ち出しの問題について解説します。
IAM で制御できる範囲とその限界
第3回で学んだ IAM は「誰が」「どのリソースに」「何をするか」を制御する強力な仕組みです。しかし、IAM には重要な限界があります。
しかし、正当な権限を持つ人のアクセスは、IAM では制御できません。
データベース管理者が BigQuery のデータセットに閲覧権限を持っている場合、この管理者が悪意を持ってデータをエクスポートし、外部のサービスに転送しようとしても、IAM はこれを防げません。「データを読み取る」という正当な権限を持っているからです。
これらはすべて、正当な権限を使った正当な操作です。
第7回で学んだログには記録が残りますが、データが持ち出された後では手遅れです。
IAM制御と限界
| シナリオ | IAM による制御 | IAM の限界 |
|---|---|---|
| 権限のない外部者がデータにアクセスしようとする | 可能（アクセスを拒否） | - |
| 権限のない内部者がデータにアクセスしようとする | 可能（アクセスを拒否） | - |
| 正当な権限を持つ管理者が業務としてデータにアクセスする | 可能（アクセスを許可） | - |
| 正当な権限を持つ管理者が意図的にデータを外部に持ち出す | 不可（正当な操作のため） | データの持ち出し先を制御できない |
| 正当な権限を持つ開発者が誤って本番データを開発環境にコピーする | 不可（正当な操作のため） | データのコピー先を制御できない |
| アカウントが侵害され、攻撃者が正当な権限を使ってアクセスする | 不可（正当な認証情報のため） | 通常のアクセスと区別できない |
内部関係者による脅威：意図的と偶発的
データ漏えいの脅威は、外部の攻撃者だけではありません。内部関係者による脅威は、「意図的なもの」と「偶発的なもの」の二つがあります。
-
意図的な脅威：
悪意を持った内部関係者 が自らの利益のためにデータを持ち出すケースです。退職前の従業員が顧客リストを持ち出す、金銭目的で機密情報を売却する、といったケースがあります。通常の業務活動を装って実行されるため、発見が非常に困難です。 -
偶発的な脅威：
悪意はない ものの、誤操作や不注意によってデータ漏えいが発生するケースです。開発者が本番データベースを開発環境にコピーする、管理者が機密データを誤って公開設定の Cloud Storage バケットにアップロードする、といったケースがあります。 利便性や効率性を優先するあまり、セキュリティポリシーを軽視してしまう ことが原因です。
どちらのケースも、IAM や暗号化だけでは防ぐことができません。正当な権限を持つ人が、正当な方法でアクセスしているためです。
データの移動経路を考える
データ漏えいのリスクを理解するには、データがどのような経路で移動するかを考える必要があります。
組織内での移動には、開発環境から本番環境へのデータコピー、プロジェクト間でのデータ共有、BigQuery から Cloud Storage へのエクスポートなどがあります。組織外への移動には、外部パートナー企業との共有、分析のための外部ツールへのエクスポート、外部のストレージサービスへのバックアップなどがあります。個人デバイスへの移動には、ローカル PC へのダウンロード、個人のクラウドストレージへのアップロード、個人のメールアドレスへの送信などがあります。
これらすべての移動経路において、IAM は 「そのユーザーがデータにアクセスできるか」は制御できますが、「データをどこに移動できるか」は制御できません。
データの移動経路
従来のアプローチの限界
これまで、内部関係者によるデータ持ち出しを防ぐために、様々なアプローチが試みられてきました。
-
厳格なアクセス制御：
できるだけ少ない人にだけデータへのアクセス権限を付与するアプローチです。（最小権限の原則に従ったアプローチ）
重要な対策ですが、ビジネスの要求と衝突することがあります。 -
詳細なログ監視：
すべての操作をログに記録し、異常なアクティビティを検知するアプローチです。
重要ですが、リアルタイムでの検知は困難で、データが持ち出された後では手遅れです。 -
データマスキングや匿名化：
機密性の高いデータをマスクして影響を最小限にするアプローチです。
有効ですが、すべてのデータに適用できるわけではなく、データの有用性が低下する場合もあります。
これらの従来のアプローチは有効ですが、単独では内部関係者によるデータ持ち出しを完全に防ぐことはできません。必要なのは、データの移動経路そのものを制御する、より根本的なアプローチです。
必要なのは「境界」による防御
内部関係者によるデータ持ち出しを効果的に防ぐには、「境界（Perimeter, ペリメーター）」 という概念が重要です。
境界とは、データが存在すべき領域と、存在すべきでない領域を明確に分ける仮想的な壁です。
新しいアプローチは、データそのものの周りに境界を設けて、データが存在するプロジェクトやサービスを境界で囲み、その境界を越えたデータの移動を制御します。
正当な権限を持つ人であっても、境界の外にデータを持ち出すことはできません。
この境界による防御は、アイデンティティベースではなく コンテキストベースの制御、デフォルト拒否の原則、最小権限の原則の拡張 という特徴を持ちます。この境界による防御を実現するのが、次の 8-3 で学ぶ VPC Service Controls です。
8-3. 境界で守る：VPC Service Controls とは
前節で、IAM だけでは正当な権限を持つ内部関係者によるデータ持ち出しを防げないことを学びました。必要なのは、データの移動経路そのものを制御する「境界」による防御です。この節では、VPC Service Controls について解説します。
VPC Service Controls の基本概念
VPC Service Controls（VPC-SC）は、Google Cloud のプロジェクトやサービスの周りに仮想的な境界（ サービス境界：Service Perimeter ）を設ける仕組みです。
最も重要な特徴は、正当な権限を持つユーザーであっても、境界を越えたデータの移動を物理的にブロックできることです。例え、BigQuery 管理者などが境界内のデータセットにアクセスする権限を持っていても、そのデータを境界外のプロジェクトやサービスにエクスポートすることはできません。
IAM は「誰が」を制御しますが、VPC Service Controls は「どこへ」を制御 します。
VPC Service Controls は、第4回で学んだ VPC とは異なる概念です。
VPC はネットワークレイヤーでの通信制御ですが、VPC Service Controls は API レイヤーでのアクセス制御 です。
セキュリティ対策方法毎の制御対象
| セキュリティ制御 | 制御対象 | 主な質問 | 制御レイヤー | 正当な権限を持つ内部者への対応 |
|---|---|---|---|---|
| IAM（第3回） | アイデンティティと権限 | 「誰が」アクセスできるか | アプリケーション | 制御できない |
| ファイアウォール（第4回） | ネットワーク通信 | 「どこから」通信できるか | ネットワーク | 制御できない |
| 組織のポリシー（第6回） | リソース設定 | 「何を」作成・設定できるか | リソース管理 | 一部制御可能 |
| 暗号化（8-1） | データの読み取り | データを「読めるか」 | データ | 制御できない（鍵を持てば読める） |
| VPC Service Controls（8-3） | データの移動経路 | データを「どこへ」移動できるか | API | 制御可能 |
サービス境界（Service Perimeter）の仕組み
サービス境界は、保護したいプロジェクトと Google Cloud サービスを論理的に囲む仮想的な壁です。
サービス境界を作成すると、次のような制御が可能になります。境界内のリソースから境界外のリソースへのアクセスはブロックされます。境界外のリソースから境界内のリソースへのアクセスもブロックされます。境界内のリソース同士のアクセスは許可されます。
重要なのは、これらの制御が IAM 権限とは独立して機能することです。IAM で十分な権限を持つユーザーであっても、サービス境界によってブロックされた操作は実行できません。
サービス境界の主な構成要素は、保護対象プロジェクト（境界内に含めるプロジェクトのリスト）、制限対象サービス（境界の制御を受ける Google Cloud サービスのリスト）、アクセスレベル（境界へのアクセスを許可する条件） です。
サービス境界の例
イングレスポリシーとエグレスポリシー
サービス境界を越える通信の API アクセスを細かく制御するために、「イングレスポリシー（Ingress Policy）」と「エグレスポリシー（Egress Policy）」 という二つのポリシーを設定できます。
イングレスポリシーは、境界外から境界内へのアクセスを制御します。デフォルトでは、境界外からのすべてのアクセスはブロックされますが、イングレスポリシーで例外を定義できます。例えば、オンプレミス環境から VPN 経由で境界内の BigQuery にアクセスする場合、特定の VPN の IP アドレス範囲からのイングレスを許可します。
エグレスポリシーは、境界内から境界外へのアクセスを制御します。デフォルトでは、境界内からのすべての外向き通信はブロックされますが、エグレスポリシーで例外を定義できます。例えば、境界内のデータ分析結果を外部パートナー企業と共有する場合、特定のサービスアカウントから特定の境界外プロジェクトへのエグレスを許可します。
両ポリシーは、デフォルト拒否の原則に基づいています。明示的に許可されたアクセスだけが通過でき、それ以外はすべてブロックされます。
イングレスポリシーとイグレスポリシー
| ポリシータイプ | 制御する方向 | デフォルトの動作 | 主な用途 | 設定例 |
|---|---|---|---|---|
| イングレスポリシー（Ingress Policy） | 境界外 → 境界内 | すべてブロック | 外部からの必要なアクセスを許可 | オンプレミスから VPN 経由での BigQuery アクセスを許可 |
| エグレスポリシー（Egress Policy） | 境界内 → 境界外 | すべてブロック | 境界内から外部への必要なアクセスを許可 | 特定のサービスアカウントから外部パートナーへのデータ共有を許可 |
アクセスレベル（Access Level）の活用
アクセスレベルは、アクセスを許可する条件を定義 するもので、イングレスポリシーやエグレスポリシーと組み合わせて使用します。
アクセスレベルでは、IP アドレス、リージョン、デバイスポリシー（組織が管理するデバイスのみ）、サービスアカウントなど、様々な属性に基づいて条件を設定 できます。
例えば、「日本国内からのアクセスで、かつ組織が管理するデバイスからのアクセスで、かつ特定の IP アドレス範囲からのアクセス」という複数の条件を組み合わせた制御が可能です。
アクセスレベルは、複数のサービス境界で再利用できるため、管理が効率化されます。
VPC-SC のアクセスレベル
VPC Service Controls の実装パターン
VPC Service Controls を実装する際の代表的なパターンを紹介します。
単一境界パターンは、組織全体の本番環境プロジェクトをすべて一つのサービス境界で囲むアプローチです。設定が簡単で管理も容易ですが、本番環境内でのデータ移動は自由になります。
環境別境界パターンは、本番環境、開発環境、検証環境など、環境ごとに別々のサービス境界を作成するアプローチです。環境間のデータ移動を厳格に制御できます。
データ分類別境界パターンは、機密性のレベルに応じて境界を分けるアプローチです。高機密データを扱うプロジェクトとそれ以外で境界を分けます。
ビジネスユニット別境界パターンは、部門やビジネスユニットごとに独立したサービス境界を作成し、部門間でのデータ共有を制御します。
データ分類別境界パターン
| 実装パターン | 境界の分け方 | メリット | デメリット | 適した組織 |
|---|---|---|---|---|
| 単一境界パターン | 本番環境全体を一つの境界で囲む | 設定が簡単、管理が容易 | 本番環境内でのデータ移動は自由 | 小規模〜中規模の組織 |
| 環境別境界パターン | 本番、開発、検証など環境ごとに境界を作成 | 環境間のデータ移動を厳格に制御 | 環境間の連携設定が必要 | 環境分離を重視する組織 |
| データ分類別境界パターン | 機密性のレベルに応じて境界を分ける | データの重要度に応じた段階的な制御 | データ分類の定義と管理が必要 | コンプライアンス要件が厳しい組織 |
| ビジネスユニット別境界パターン | 部門やビジネスユニットごとに境界を作成 | 部門のデータ主権を保持 | 境界の数が増え、管理が複雑化 | 大規模な組織、複数事業を持つ企業 |
VPC Service Controls の実装における注意点
実装時の主な注意点は以下の通りです。
VPC Service Controls を有効化すると、既存の業務フローに影響を与える可能性があります。本番環境に適用する前に、「ドライランモード（Dry Run Mode）」で影響範囲を把握 し、必要なポリシーを設定してから適用してください。
すべての Google Cloud サービスが VPC Service Controls に対応しているわけではありません。使用するサービスが対応しているか、事前に Google Cloud 社公式情報で最新情報の確認が必要です。
VPC Service Controls を設定すると、Google Cloud Console からの操作も制御されます。管理者が常にアクセスできるよう、適切なイングレスポリシーとアクセスレベルを設定してください。
第6回で学んだ組織のポリシーと組み合わせることで、より強固なセキュリティを実現できます。
設定は、組織全体のセキュリティポリシーと整合性を保つ必要があります。
8-4. 【具体的な方法】データ保護の二段構え
前節までで、暗号化と VPC Service Controls という二つの強力な防御機構を学びました。この節では、これら二つを組み合わせた包括的なデータ保護戦略について解説します。
データ保護の二層アプローチ
データを真に守るには、「データそのもの」と「データへのアクセス経路」の両方を保護する必要があります。
暗号化（Cloud KMS）は、データそのものを守ります。
万が一データが盗まれても、暗号鍵がなければ読めません。しかし、暗号鍵を持つ正当な管理者がデータを持ち出した場合、暗号化だけでは防げません。
VPC Service Controls は、データへのアクセス経路を守ります。
正当な権限を持つ管理者であっても、境界を越えたデータの移動は物理的にブロックされます。しかし、境界内でのデータアクセスは自由であり、境界内にいる攻撃者からデータを保護することはできません。
この二つを組み合わせることで、攻撃者が境界内に侵入しても暗号化でデータは保護され、暗号鍵を入手してもデータを境界外に持ち出せない多層的な防御が実現します。
データアクセス経路と VPC-SC の効果
| 脅威シナリオ | 暗号化（Cloud KMS）の効果 | VPC Service Controls の効果 | 組み合わせた効果 |
|---|---|---|---|
| 物理ストレージの盗難 | 保護可能（データは暗号化されている） | 効果なし | 暗号化で保護 |
| ネットワーク通信の傍受 | 保護可能（転送中の暗号化） | 効果なし | 暗号化で保護 |
| 境界外からの不正アクセス | 効果なし（境界に到達する前の問題） | 保護可能（境界でブロック） | VPC-SC で保護 |
| 境界内の正当なユーザーによるデータ持ち出し | 効果なし（暗号鍵を持っている） | 保護可能（境界を越えられない） | VPC-SC で保護 |
| 境界内の攻撃者によるデータ読み取り | 保護可能（暗号鍵がなければ読めない） | 効果なし（境界内にいる） | 暗号化で保護 |
| アカウント侵害による不正操作 | 部分的に保護（鍵の権限による） | 保護可能（境界外への持ち出しをブロック） | 両方で多層保護 |
Cloud KMS と VPC Service Controls の統合
Cloud KMS 自体も VPC Service Controls によって保護できます。Cloud KMS を制限対象サービスとしてサービス境界に含めることで、境界外から Cloud KMS の鍵にアクセスすることや、境界内の鍵を使って境界外のデータを暗号化・復号化することを防ぎます。
例えば、本番環境のサービス境界に Cloud KMS を含め、本番環境用の暗号鍵を配置します。開発者が開発環境から本番環境の暗号鍵にアクセスしようとしても、VPC Service Controls によってブロックされます。
Cloud KMS と VPC-SC の統合例
実装手順：本番環境のデータ保護
本番環境のデータを保護する具体的な実装手順を紹介します。
ステップ1：Cloud KMS の設定
本番環境専用のプロジェクトにキーリングと暗号鍵を作成し、ローテーション期間を90日に設定します。IAM 権限を適切に設定し、最小権限の原則を徹底します。
ステップ2：データの暗号化
作成した暗号鍵を使って、BigQuery のデータセット、Cloud Storage のバケット、Compute Engine のディスクを暗号化します。
ステップ3：VPC Service Controls の設定
サービス境界を作成し、本番環境のプロジェクトと Cloud KMS のプロジェクトを境界内に含めます。制限対象サービスとして、BigQuery、Cloud Storage、Compute Engine、Cloud KMS を指定します。
ステップ4：イングレス・エグレスポリシーの設定
必要なアクセスを許可するため、イングレス・エグレスポリシーを設定します。オンプレミス環境からの VPN アクセスや、外部パートナーとの特定のデータ共有を定義します。
ステップ5：ドライランモードでのテスト
実際にブロックする前に、ドライランモードでログを確認し、正当な業務活動が誤ってブロックされないことを確認します。
ステップ6：本番適用と監視
十分なテストを経て本番適用し、継続的に監査ログを監視します。
データ保護手順
実践的なユースケース
ユースケース1：金融機関の顧客データ保護
顧客データを含むすべての BigQuery データセットを CMEK で暗号化し、本番環境プロジェクトをサービス境界で囲みます。分析チームは境界内でのみデータにアクセスでき、個人の PC や外部ツールへのエクスポートはブロックされます。
ユースケース2：医療機関の患者記録管理
患者記録を含むすべての Cloud Storage バケットを CMEK で暗号化し、医療記録システムのプロジェクトをサービス境界で囲みます。医師や看護師は組織が管理するデバイスから VPN 経由でのみアクセスでき、アクセスレベルでデバイスポリシーと IP アドレスを制限します。
ユースケース3：グローバル企業のデータ主権対応
国ごとにサービス境界を作成し、日本のデータは日本リージョン、EU のデータは EU リージョンに配置します。暗号鍵もそれぞれのリージョンの Cloud KMS に配置し、国境を越えたデータ移動を物理的に防ぎます。
運用上のベストプラクティス
定期的な権限レビュー、鍵のローテーションの自動化、ドライランモードの継続的な活用、包括的なログ監視、インシデント対応手順の整備、定期的なセキュリティ評価を実施します。
運用ベストプラクティス
| ベストプラクティス | 実施内容 | 推奨頻度 | 重要度 |
|---|---|---|---|
| 定期的な権限レビュー | Cloud KMS と VPC-SC の権限確認、不要な権限の削除 | 月次 | 高 |
| 鍵のローテーション | Cloud KMS の自動ローテーション確認、手動ローテーション実施 | 90日ごと | 高 |
| ドライランモードの活用 | 設定変更前の影響確認 | 変更時毎回 | 高 |
| 包括的なログ監視 | 監査ログのリアルタイム監視とアラート設定 | 常時 | 高 |
| インシデント対応訓練 | データ漏えい対応のシミュレーション | 四半期ごと | 中 |
| 定期的なセキュリティ評価 | 設定の見直し、新しい脅威への対応確認 | 四半期ごと | 中 |
コストとセキュリティのバランス
Cloud KMS の利用には料金が発生するため、本当に保護が必要なデータ（個人情報、機密情報など）を明確にし、それらだけを CMEK で暗号化することを検討します。推奨されるアプローチは、最も機密性の高いデータから段階的に実装していくことです。
コストとセキュリティのバランスを評価する際は、データ漏えいが発生した場合のコスト（罰金、訴訟費用、ブランド価値の低下）も考慮します。
8-5. まとめ
ここまで、データ保護戦略という「最後の砦」について学んできたことをまとめます。
本回で学んだことの振り返り
この回では、これまで構築してきたセキュリティの土台をすべてすり抜けた場合に備える、最後の防御層について解説してきました。
-
8-1：
データの暗号化について学びました。Google Cloud では、すべてのデータが自動的に暗号化されています（GMEK）。さらに高度な要件には、Cloud KMS を使った CMEK により、暗号鍵そのものを管理できます。 -
8-2：
IAM だけでは防げないリスクについて学びました。正当な権限を持つ内部関係者によるデータ持ち出しは、IAM では制御できません。データの移動経路そのものを制御する境界による防御が必要です。 -
8-3：
VPC Service Controls について学びました。プロジェクトやサービスの周りに仮想的な境界を設け、正当な権限を持つユーザーであっても、境界を越えたデータの移動を物理的にブロックできます。 -
8-4：
暗号化と VPC Service Controls を組み合わせた包括的なデータ保護戦略を学びました。Cloud KMS で「データそのもの」を暗号化し、VPC Service Controls で「データへのアクセス経路」を制御することで、真に堅牢なデータ保護が実現できます。
各節のつながり
これまでの回との繋がり
本回で学んだデータ保護戦略は、これまでの回で構築してきたセキュリティの土台と密接に繋がっています。
第2回のリソース階層は、サービス境界の設計と Cloud KMS プロジェクトの配置に影響します。第3回の IAM は、Cloud KMS の暗号鍵への権限管理と、VPC Service Controls のポリシーで使用するサービスアカウントの制御に使われます。第4回と第5回の VPC は、ネットワークレイヤーでの防御であり、VPC Service Controls の API レイヤーでの防御と組み合わせることで多層的なセキュリティが実現します。第6回の組織のポリシーは、予防的なセキュリティ対策であり、データ保護戦略と組み合わせることで二重の防御を構築できます。第7回のログ管理と監視は、Cloud KMS と VPC Service Controls の監査ログを収集し、データ保護が適切に機能していることを確認するために不可欠です。
本回とこれまでの回のつながり
| 回 | 主なテーマ | データ保護戦略との関連性 |
|---|---|---|
| 第1回 | セキュリティの全体像 | 多層防御の最後の層として、データ保護が位置づけられる |
| 第2回 | 組織とリソース階層 | サービス境界の設計、Cloud KMS プロジェクトの配置 |
| 第3回 | IAM による権限管理 | Cloud KMS と VPC-SC の権限管理、最小権限の原則の適用 |
| 第4回 | VPC とファイアウォール | ネットワークレイヤー（VPC）と API レイヤー（VPC-SC）の組み合わせ |
| 第5回 | Shared VPC | ネットワーク基盤の一元化とデータ境界の一元化の類似性 |
| 第6回 | 組織のポリシー | 予防（組織のポリシー）と防御（暗号化・VPC-SC）の組み合わせ |
| 第7回 | ログ管理と監視 | Cloud KMS と VPC-SC の監査ログ収集と監視 |
実践へ向けて：最初の一歩
データ保護戦略の実装は、段階的に進めていくことが現実的です。
最初に、最も機密性の高いデータを特定します。個人情報、機密情報、規制対象データがどのプロジェクト、どのサービスに保存されているかを洗い出します。次に、これらのプロジェクトに Cloud KMS による暗号化を適用します。運用に慣れてから徐々に範囲を広げていきます。
暗号化が安定したら、VPC Service Controls のサービス境界を作成します。最初は単一境界パターンから始め、ドライランモードで十分にテストしてから本番適用します。そして、実際に運用しながら徐々に最適化していきます。
大切なのは、完璧を目指すのではなく、まず始めることです。動き出すための検討に時間をかけ過ぎるのではなく、優先順位が高いものから素早く適用していく、小さく始めて徐々に成長させていく。これが実践的なアプローチです。
AI を活用した高度なセキュリティ
次の第9回では、「AI 警備と実践シナリオで総仕上げ！」というテーマで、シリーズを総括します。
AI を活用した Security Command Center Premium による脅威と脆弱性の自動発見、Cloud Security Operations による組織全体のセキュリティ運用、そして実践シナリオとして、これまでの第1回から第8回で学んだセキュリティ要素が実際のシステムでどのように使われているかをマッピングします。
全9回のシリーズも、次回でいよいよ最終回です。これまで積み重ねてきた知識を、AI という新しい要素と実践シナリオで統合し、Google Cloud のセキュアな土台作りを完成させましょう。
それでは、最終回の第9回も、ぜひ楽しみにしていてください。長文お疲れ様でした！
8-6. 参照情報
この本回の執筆にあたり、以下の Google Cloud 公式ドキュメントおよび公式ブログを参照しました。データ保護戦略について、より詳しく学びたい方は、これらの公式情報源をご確認ください。
暗号化とデフォルト暗号化に関する公式ドキュメント
Encryption at Rest in Google Cloud
Encryption best practices
Google-managed encryption keys
Cloud KMS に関する公式ドキュメント
Cloud Key Management Service documentation
Customer-managed encryption keys (CMEK)
Creating keys
Key rotation
Key versions
IAM permissions for Cloud KMS
VPC Service Controls に関する公式ドキュメント
VPC Service Controls overview
Creating service perimeters
Ingress rules
Egress rules
Access levels
Dry run mode
Supported services
データ保護の統合に関する公式ドキュメント
Using CMEK with VPC Service Controls
Protecting data in BigQuery
Customer-managed encryption keys for Cloud Storage
Customer-managed encryption keys for Compute Engine
セキュリティとコンプライアンスに関する公式ドキュメント
Data residency and sovereignty
Security best practices
Compliance resource center
Audit logging for Cloud KMS
Audit logging for VPC Service Controls
実装例とアーキテクチャパターンに関する公式ドキュメント
Data governance and protection architecture
Best practices for financial services
Healthcare and life sciences solutions
Implementing data protection incrementally
Discussion