【総まとめ】実践シナリオ：セキュアなウェブアプリケーション基盤
はじめに
お疲れ様です。SKY こと関谷です。
本 Blog series の全9回を通して Google Cloud のセキュリティに関する多くの要素を学んできました。
しかし、「それぞれの技術は理解できたけれど、実際のシステムではどう組み合わせるの？」という疑問をお持ちの方もいらっしゃるでしょう。
そこで総まとめとして、実際のウェブアプリケーション基盤を例にとって、これまで学んだすべてのセキュリティ要素がどこでどのように使われるか を見ていきましょう。
ブログシリーズその他の執筆
本編
番外編
第３回では紹介しなかった関連機能の説明です
シナリオ：EC サイトのセキュアな基盤構築
ある企業が、顧客向けの EC（Electronic Commerce：電子商取引）サイトを Google Cloud 上に構築するとします。このシステムは以下のような要件を持っています：
- ユーザー向け Web サイト： 商品閲覧、カート機能、決済機能
- 管理者向け管理画面： 在庫管理、注文管理、顧客情報管理
- データベース： 顧客情報、注文履歴、決済情報を保存
-
セキュリティ要件：
- クレジットカード情報を扱うため PCI DSS 準拠が必要
- 個人情報保護のため不正アクセスを確実に防止
- 監査対応のため操作ログを長期保存
- 本番環境と開発環境を明確に分離
典型的な 3 層アーキテクチャ（フロントエンド層、アプリケーション層、データベース層）で構成される、よくあるシステムですね。では、このシステムにこれまで学んだセキュリティ要素をどう適用するか、順を追って見ていきましょう。
システム全体構成図
まず、完成形のシステム構成図を見てみましょう。この図には、第1〜8回で学んだすべてのセキュリティ要素が含まれています。
一見複雑に見えますが、これまで学んだ要素が整然と配置されていることが分かります。
では、各セキュリティ要素がどのように機能しているか、第1回から順番に振り返りながら見ていきましょう。
第1回の要素：責任共有モデルと多層防御の実践
責任共有モデルの適用
このシステムでは、責任共有モデル を明確に意識した設計になっています：
Google が責任を持つ範囲（"雲の下"）：
- データセンターの物理セキュリティ
- ネットワークインフラの保護
- Cloud SQL や Compute Engine のハードウェア・ソフトウェアの脆弱性対策
利用者が責任を持つ範囲（"雲の上"）：
- IAM によるアクセス制御（誰が何にアクセスできるか）
- ファイアウォールルールの設定（どの通信を許可するか）
- データの暗号化（機密情報をどう守るか）
- ログの監視とインシデント対応（異常をどう検知するか）
この図では、利用者が責任を持つべき「雲の上」の部分を、これまで学んだ技術で適切に保護しています。
多層防御（Defense in Depth）の実装
多層防御 の考え方も、このシステム全体に貫かれています。仮に 1 つの防御層が突破されても、次の層が攻撃を食い止める設計です：
| 防御層 | 実装要素 | 役割 |
|---|---|---|
| 第 1 層：境界防御 | Cloud Load Balancing + Cloud Armor | DDoS 攻撃や不正アクセスをエッジでブロック |
| 第 2 層：ネットワーク | ファイアウォールルール | 不要な通信を遮断、内部セグメンテーション |
| 第 3 層：アクセス制御 | IAM + サービスアカウント | 最小権限の原則で不正操作を防止 |
| 第 4 層：データ保護 | CMEK 暗号化 + VPC Service Controls | データそのものと経路の両方を保護 |
| 第 5 層：検知と対応 | Security Command Center + Cloud Logging | 異常を素早く発見し対応 |
攻撃者が仮に外部から侵入を試みても、複数の防御層を突破しなければ機密データにたどり着けない仕組みです。
第2回の要素：組織構造とリソース階層
フォルダによる環境分離
図の最上位には「組織（Organization）」があり、その下に以下のフォルダ構造を設けています：
組織
├── 本番環境フォルダ
│ ├── Shared VPC ホストプロジェクト
│ ├── Web サービスプロジェクト
│ └── データプロジェクト
├── 開発環境フォルダ（図では省略）
│ └── （本番と同様の構造）
└── 共通サービスフォルダ
├── ログ集約プロジェクト
└── セキュリティ監視プロジェクト
この構造により、以下のメリットが得られます：
環境分離の徹底： 本番環境と開発環境を物理的に分離し、開発中のミスが本番に影響しないようにします。
共通サービスの一元化： ログ集約やセキュリティ監視は全環境で共通なので、専用のフォルダにまとめることで管理が効率化されます。
権限管理の簡素化： フォルダ単位で IAM ポリシーを設定できるため、「本番環境フォルダには限られた人だけがアクセス可能」「開発環境は開発チーム全員がアクセス可能」といった制御が容易です。
プロジェクト命名規則の実践
各プロジェクトには、誰が見ても理解できる命名規則を適用しています：
-
prod-network-001：本番環境のネットワーク（Shared VPC ホスト） -
prod-web-001：本番環境の Web サービス -
prod-data-001：本番環境のデータベース -
common-logging-001：共通のログ集約 -
common-security-001：共通のセキュリティ監視
環境（prod/dev）、用途（network/web/data）、通し番号が一目で分かるため、誤操作のリスクが減ります。
第3回の要素：IAM による厳格なアクセス制御
最小権限の原則
このシステムでは、すべてのリソースに対して必要最小限の権限のみを付与しています：
人間のユーザー：
- 開発者：開発環境プロジェクトの
roles/editor（編集者）のみ。本番環境は閲覧のみ可能 - 運用担当者：本番環境プロジェクトの
roles/viewer（閲覧者）＋特定の操作権限のみ - セキュリティ管理者：ログ集約プロジェクトとセキュリティ監視プロジェクトの管理者権限
サービスアカウント：
- フロントエンド（Cloud Run）：Cloud SQL への接続権限のみ
- アプリケーション（Compute Engine）：Cloud SQL への接続権限と Cloud Storage の読み書き権限のみ
- ログ転送用サービスアカウント：Cloud Logging への書き込み権限のみ
例えば、フロントエンドのサービスアカウントは「データベースに接続する」という目的のためだけに存在し、それ以外の操作（VM の起動、IAM の変更など）は一切できません。
Google グループによる効率的な管理
個人のユーザーアカウントに直接ロールを割り当てるのではなく、Google グループ経由で権限を管理 しています：
prod-web-developers@example.com
├─ taro@example.com
├─ hanako@example.com
└─ jiro@example.com
↓
開発環境プロジェクトの roles/editor を付与
新しい開発者が入社したら、このグループに追加するだけで適切な権限が自動的に付与されます。退職時もグループから削除するだけで、すべてのプロジェクトからのアクセス権が一括で取り消されます。
第4回の要素：VPC とファイアウォールによるネットワーク制御
カスタム VPC の構築
このシステムでは、デフォルト VPC は使わず、カスタム VPC を作成 しています。理由は以下の通りです：
- サブネットの IP レンジを計画的に設計できる（将来の拡張を見越して）
- 不要なデフォルトファイアウォールルールが存在しない（セキュリティリスクの削減）
- 他のプロジェクトとの VPC ピアリングや VPN 接続が容易
ファイアウォールルールの設計思想
「デフォルト拒否、必要最小限のみ許可」 という原則に従い、以下のルールを設定しています：
優先度 1000: すべての ingress（受信）トラフィックを拒否
優先度 1100: Cloud Load Balancing からフロントエンドへの HTTPS（443）を許可
優先度 1200: フロントエンドからアプリケーションへの内部通信（8080）を許可
優先度 1300: アプリケーションから Cloud SQL への通信（3306）を許可
このように、必要な通信経路だけを選択的に許可 することで、攻撃者が侵入できる経路を最小限に抑えます。
また、IP アドレスではなく ネットワークタグ （例：frontend、application、database）を使ってファイアウォールルールを定義しているため、VM の IP アドレスが変わってもルールの修正が不要です。
外部 IP なしでの運用
セキュリティをさらに高めるため、すべての VM に外部 IP アドレスを付与していません。では、どうやってインターネットやGoogle API と通信するのでしょうか？
Private Google Access：
- Cloud SQL、Cloud Storage、Cloud KMS などの Google API への通信は、Private Google Access を有効化することで、インターネットを経由せず Google のプライベートネットワーク経由で行われます。
Cloud NAT：
- どうしても外部のサーバー（例：決済代行サービスの API）にアクセスする必要がある場合は、Cloud NAT を経由させます。これにより、VM に外部 IP を付与することなく、安全に外部通信できます。
外部 IP がないため、インターネットから直接 VM に攻撃を仕掛けることができません。これは非常に強力なセキュリティ対策です。
第5回の要素：Shared VPC による一元管理
ネットワーク管理の集中化
このシステムでは、Shared VPC を採用しています。
ホストプロジェクト： prod-network-001
- VPC ネットワーク、サブネット、ファイアウォールルール、Cloud NAT などをすべて管理
サービスプロジェクト： prod-web-001、prod-data-001
- ホストプロジェクトの VPC を利用して、Compute Engine や Cloud SQL をデプロイ
このアーキテクチャのメリット
セキュリティポリシーの一貫性：
- ファイアウォールルールは 1 箇所（ホストプロジェクト）で管理されるため、Web サービスプロジェクトとデータプロジェクトで矛盾したルールが設定される心配がありません。
IP アドレス管理の効率化：
- すべてのサブネットが 1 つの VPC 内にあるため、IP アドレスの重複を気にする必要がなく、計画的にアドレス空間を設計できます。
権限分離：
- ネットワーク管理者（ホストプロジェクトの管理者）とアプリケーション開発者（サービスプロジェクトの管理者）を分けることで、「開発者が誤ってファイアウォールルールを変更してしまう」といったリスクを防げます。
第6回の要素：組織のポリシーによるガードレール
全社レベルでの制約
組織のポリシーを組織ルートまたはフォルダレベルで設定することで、プロジェクト管理者でも変更できないルール を強制しています。
このシステムで設定している主な組織のポリシー：
| ポリシー | 設定内容 | 目的 |
|---|---|---|
constraints/compute.vmExternalIpAccess |
外部 IP の割り当てを禁止 | VM への直接攻撃を防止 |
constraints/iam.disableServiceAccountKeyCreation |
サービスアカウントキーの作成を禁止 | キーの漏洩リスクを排除 |
constraints/gcp.resourceLocations |
日本リージョン（asia-northeast1）のみ許可 |
データ主権とコンプライアンス要件を遵守 |
constraints/sql.restrictPublicIp |
Cloud SQL のパブリック IP を禁止 | データベースへの外部からのアクセスを遮断 |
これらのポリシーは、IAM で強力な権限を持つユーザーでも上書きできません 。例えば、開発者が「デバッグのために一時的に VM に外部 IP を付けたい」と思っても、組織のポリシーで禁止されていれば実行できません。
フォルダ単位での柔軟な運用
一方で、開発環境フォルダでは一部のポリシーを緩和することも可能です：
- 本番環境フォルダ：すべての制約を厳格に適用
- 開発環境フォルダ：外部 IP の禁止は解除（開発者が自由に検証できるように）
このように、環境に応じて適切なバランスを取る ことができます。
第7回の要素：ログ集約と監視
すべてのログを 1 箇所に
このシステムでは、ログ集約プロジェクト （common-logging-001）を設けて、組織内のすべてのプロジェクトからログを集約しています。
集約されるログの種類：
- 管理アクティビティログ： 「誰が IAM ロールを変更したか」「誰が VM を削除したか」
- データアクセスログ： 「誰が Cloud SQL のどのテーブルを参照したか」
- システムイベントログ： 「VM が起動した」「ディスク容量が逼迫している」
- アクセスログ： 「どの IP からどの URL にアクセスがあったか」
これらのログは、Cloud Logging の ログシンク 機能を使って、BigQuery に長期保存されます。BigQuery を使うことで：
- SQL を使った柔軟なログ分析が可能
- 数年分のログを保管してもコストが比較的安い
- コンプライアンス要件（「5 年間のログ保持」など）を満たせる
プロアクティブな監視とアラート
受動的にログを保存するだけでなく、Cloud Monitoring を使って能動的に異常を検知します。
このシステムで設定している主なアラート：
セキュリティ関連：
- IAM ポリシーの変更を検知したら、セキュリティ管理者にメール通知
- 複数回のログイン失敗を検知したら、アカウントロック＋通知
- 新しいファイアウォールルールが作成されたら通知
運用関連：
- VM の CPU 使用率が 80% を超えたら通知
- Cloud SQL の接続数が上限に近づいたら通知
- SSL 証明書の有効期限が 30 日を切ったら通知
これらのアラートにより、問題が大きくなる前に対処 できます。
第8回の要素：データ保護の最終防衛線
Cloud KMS による暗号化
このシステムでは、特に機密性の高いデータベース（顧客情報、決済情報）に対して、顧客管理の暗号鍵（CMEK） を使用しています。
通常、Cloud SQL はGoogle が管理する鍵で自動的に暗号化されますが、CMEK を使うことで：
- 鍵の管理を自社でコントロール： 必要に応じて鍵をローテーション（定期的に変更）できる
- 鍵へのアクセスを厳格に制限： 鍵を使える人・サービスを明示的に指定できる
- コンプライアンス要件を満たす： 「暗号鍵は自社で管理すること」という要件に対応できる
仮にデータベースのバックアップが何らかの理由で外部に流出しても、暗号鍵がなければデータを復号（読み取り）できません。
VPC Service Controls によるデータ境界
さらに強力な保護として、VPC Service Controls（VPC-SC） を設定しています。これは、データプロジェクト（prod-data-001）とログ集約プロジェクト（common-logging-001）を サービス境界 という「見えない壁」で囲む仕組みです。
この壁により、以下のような保護が実現します：
シナリオ 1：内部関係者による持ち出し防止
- ある従業員が IAM で Cloud SQL への読み取り権限を持っていたとします
- しかし、VPC-SC により「境界の外からのアクセスは拒否」されているため、自宅や社外のネットワークからはデータベースにアクセスできません
- 仮に権限を悪用しようとしても、物理的に社内ネットワーク（または VPN）からしかアクセスできないため、不正な持ち出しが困難になります
シナリオ 2：意図しないデータコピーの防止
- 開発者が「本番データベースを開発環境にコピーしたい」と考えたとします
- しかし、VPC-SC により境界を超えたデータコピーは自動的にブロックされます
- これにより、意図せずセキュリティレベルの低い環境に機密データが流出するリスクを防ぎます
IAM だけでは防げないリスク を、VPC-SC が補完する形で多層防御を実現しています。
第9回の要素：AI による継続的な脅威検知
Security Command Center の 3 つのエディション
このシステムでは、Security Command Center が常時すべてのリソースを監視し、脅威や脆弱性を自動検知します。組織の規模やセキュリティ要件に応じて 3 つのエディションが用意されています。
| エディション | 対象環境 | 主な機能 | 適している組織 |
|---|---|---|---|
|
Standard （無料） |
GCP のみ | ・設定ミス検知 ・IAM 可視化 ・資産インベントリ |
・小規模チーム ・開発環境 ・コスト重視 |
| Premium | GCP のみ | Standard + ・実行時脅威検知 ・コンテナ/VM 脅威検知 ・コンプライアンスレポート ・攻撃経路分析 |
・GCP 本番環境 ・中〜大規模企業 ・PCI-DSS 等の コンプライアンス要件 |
| Enterprise | GCP + AWS + Azure |
Premium + ・マルチクラウド統合監視 ・SIEM/SOAR 統合 ・AI 自動調査 ・Attack Surface Management |
・マルチクラウド環境 ・大企業 ・高度なセキュリティ 運用チーム |
段階的導入の推奨パス：
- Standard で基礎固め → 2. Premium で脅威検知強化 → 3. Enterprise でマルチクラウド対応
実際のシステムでの活用例
今回の EC サイトでは Enterprise エディション を採用しています。理由は：
- 将来のマルチクラウド展開を見据えて
- 決済情報を扱うため高度な脅威検知が必要
- PCI DSS 準拠のため包括的なレポートが必要
Enterprise により以下を自動検知：
設定ミス： 公開バケット、過度に広いファイアウォールルール、暗号化されていないディスク
実行時の脅威： 不審な外部通信、異常なデータダウンロード、通常と異なる時間帯の管理者操作
攻撃経路： 攻撃者がリソースに到達可能な経路をシミュレーション
これらは AI と機械学習 により、未知の脅威も検知できます。
将来への拡張：Google Security Operations
さらに高度な運用が必要になったら、Google Security Operations（9-4で詳しく紹介）への移行を検討できます。マルチクラウド + オンプレミス環境の統合分析、AI エージェントによる完全自動調査、ペタバイト規模のログ管理が可能になります。
構築の順序とポイント
実際にこのようなシステムを構築する場合、どのような順序で進めればよいでしょうか？推奨される手順を示します。
- フェーズ 1：土台の整備（第2回、第6回の内容）
1. 組織の作成と初期設定
2. フォルダ構造の設計（本番/開発/共通サービス）
3. プロジェクト命名規則の策定
4. 組織のポリシーの設定（外部 IP 禁止など）
ポイント： 後から変更するのが大変なので、最初に時間をかけて設計しましょう。特に組織のポリシーは、設定後に既存リソースと矛盾が生じないよう、リソース作成前に適用することが重要です。
- フェーズ 2：ネットワークの構築（第4回、第5回の内容）
1. Shared VPC ホストプロジェクトの作成
2. カスタム VPC とサブネットの設計
3. ファイアウォールルール（デフォルト拒否）の設定
4. Cloud NAT、Private Google Access の有効化
ポイント： サブネットの IP レンジは後から変更できないので、将来の拡張を見越して余裕を持った設計を。また、ファイアウォールルールは「まず全拒否、次に必要な通信だけ許可」の順で設定しましょう。
- フェーズ 3：IAM の設計（第3回の内容）
1. Google グループの作成（役割別、環境別）
2. カスタムロールの作成（必要に応じて）
3. サービスアカウントの作成と権限付与
4. 最小権限の原則に基づく IAM ポリシーの設定
ポイント： 個人に直接ロールを割り当てず、必ずグループ経由で。サービスアカウントは用途ごとに分け、「1 つのサービスアカウントに複数の役割を持たせない」ことが重要です。
- フェーズ 4：ログとモニタリングの整備（第7回の内容）
1. ログ集約プロジェクトの作成
2. 組織レベルのログシンクの設定
3. BigQuery データセットの作成（長期保存用）
4. Cloud Monitoring のアラート設定
ポイント： リソースをデプロイする前にログ基盤を整えておくことで、「いつ、誰が、何をしたか」の記録を漏れなく残せます。特に管理アクティビティログとデータアクセスログは必須です。
- フェーズ 5：アプリケーションのデプロイ
1. サービスプロジェクトの作成と Shared VPC への接続
2. データベース（Cloud SQL）のデプロイ
3. アプリケーション（Compute Engine / Cloud Run）のデプロイ
4. ロードバランサーと SSL 証明書の設定
ポイント： この段階では、すでにセキュリティの「ガードレール」が敷かれているため、安心してリソースをデプロイできます。組織のポリシーにより、危険な設定は自動的に拒否されます。
- フェーズ 6：データ保護の強化（第8回の内容）
1. Cloud KMS 鍵の作成
2. Cloud SQL での CMEK 有効化
3. VPC Service Controls の境界設定
4. アクセステストと動作確認
ポイント： VPC Service Controls は既存のアクセスパターンに影響するため、ドライランモード （実際にはブロックせず、ログだけ記録するモード）でテストしてから本番適用しましょう。
- フェーズ 7：継続的な改善（第9回の内容）
1. Security Command Center の有効化と設定
2. 検出された脅威・脆弱性への対応
3. 定期的なセキュリティレビュー
4. インシデント対応手順の整備
ポイント： セキュリティは「一度設定したら終わり」ではありません。Security Command Center の推奨事項を定期的に確認し、継続的に改善していくことが重要です。
このシリーズを通じて学んだこと
最後に、このシリーズで学んだ核心をまとめましょう。
セキュリティは「後付け」ではなく「設計」
オンプレミスの時代は、「まずシステムを作って、後からセキュリティ対策を追加する」というアプローチが一般的でした。しかしクラウドでは、最初から適切なガードレールを設計することで、将来のリスクとコストを大幅に削減 できます。
このシリーズで学んだ要素（組織構造、IAM、ネットワーク、ポリシー、ログ、暗号化）は、すべて「後から追加するもの」ではなく、システムの土台として最初に整えるべきもの です。
多層防御の重要性
「ファイアウォールがあるから安全」「IAM で制御しているから大丈夫」という単層の防御では不十分です。複数の防御層を組み合わせることで、1 つが突破されても次の層が守る「 多層防御 」の考え方が、現代のセキュリティの基本です。
今回のシステム構成図を見ると、攻撃者がデータベースにたどり着くまでに、以下の障壁を突破しなければなりません：
- Cloud Armor（DDoS 対策）
- ファイアウォールルール（ネットワーク制御）
- IAM（アクセス制御）
- VPC Service Controls（境界保護）
- CMEK 暗号化（データ保護）
これだけの層を突破するのは、攻撃者にとって非常に困難です。
責任共有モデルの実践
Google Cloud が提供するのは「セキュアなインフラストラクチャ」ですが、それを適切に設定・運用するのは利用者の責任です。このシリーズで学んだ知識を使って、「雲の上」の部分を確実に守ることができます。
AI の活用で運用負荷を軽減
Security Command Center や Google Security Operations のような AI を活用したツールにより、「脅威の検知」「ログの分析」「インシデント対応」といった従来は専門家の手作業だった業務が、大幅に自動化されます。
これにより、少人数のチームでも高度なセキュリティ運用が可能になります。
最後に
お疲れ様でした！
Blog series 全9回と本総まとめを通じて、Google Cloud のセキュリティに関する基本的な部分を包括的に解説してきました。
既存のプロジェクトに組織のポリシーを 1 つ追加する、IAM のロールを見直す、ログ集約を設定する…どんな小さな改善でも、セキュリティは確実に向上します。
そして、セキュリティは「一人で抱え込む」ものではありません。チーム全体で知識を共有し、協力する必要があります。
以上、全9回（と番外編）に渡る解説の中、読破いただいた方、誠にありがとうございました。
もちろん、必要な部分をご確認いただいた方にも少しでもお役に立てましたら幸いです。
それでは、次回の執筆もどうかご確認よろしくお願いいたします。
Discussion