このドキュメントは、データセンターのワークロードを Google Cloud に移行する企業向けのネットワーキング アーキテクチャとセキュリティ アーキテクチャについて説明するシリーズの一部です。
このシリーズは、次のドキュメントで構成されています。
- エンタープライズ ワークロードを移行するためのネットワーク設計: アーキテクチャのアプローチ
- 安全なクラウド内アクセスのためのネットワーキング: リファレンス アーキテクチャ（このドキュメント）
- インターネットに接続するアプリケーションの配信のためのネットワーキング: リファレンス アーキテクチャ
- ハイブリッドおよびマルチクラウドのワークロードのネットワーキング: リファレンス アーキテクチャ
クラウド内のユースケースのワークロードは VPC ネットワークに存在し、Google Cloud の他のリソースに接続する必要があります。BigQuery など、クラウドでネイティブに提供されるサービスを使用する場合があります。セキュリティ境界は、ファイアウォール、VPC Service Controls、ネットワーク仮想アプライアンスなど、さまざまな自社（1P）機能とサードパーティ（3P）機能によって提供されます。
多くの場合、これらのワークロードは複数の Google Cloud VPC ネットワークにまたがるため、VPC ネットワーク間の境界を保護する必要があります。このドキュメントでは、これらのセキュリティと接続のアーキテクチャについて詳しく説明します。
リフト＆シフト アーキテクチャ
クラウド内のユースケースの最初のシナリオは、既存のワークロードをそのままクラウドに移行するリフト&シフト アーキテクチャです。
ファイアウォール
ファイアウォール ルールを構成すると、安全な境界を確立できます。ネットワーク タグを使用して、VM のコレクションにきめ細かいファイアウォール ルールを適用できます。タグは、VM の作成時に VM の tags フィールドに追加した文字列で構成される任意の属性です。タグは、VM を編集して後で割り当てることもできます。Google Cloud ファイアウォール ルールでトラフィックを管理する方法の実装ガイドラインについては、エンタープライズ基盤ブループリントのネットワーク ファイアウォール ポリシーをご覧ください。
ファイアウォールのロギングを使用して、ファイアウォール ルールの設定の効果を監査および検証することもできます。
VPC フローログを使用してネットワーク フォレンジックを行ったり、ログをストリーミングして SIEM と統合したりできます。このシステム全体で、リアルタイムのモニタリング、イベントの相関、分析、セキュリティ通知を提供できます。
図 1 は、ファイアウォール ルールが VM タグを使用して、VPC ネットワーク内の VM 間のトラフィックを制限する方法を示しています。
図 1: ネットワーク タグを使用してきめ細かい下り（外向き）制御を適用するネットワーク ファイアウォール構成。
ネットワーク仮想アプライアンス
ネットワーク仮想アプライアンス（NVA）は、複数のネットワーク インターフェースを持つ VM です。NVA を使用すると、複数の VPC ネットワークに直接接続できます。VM には、ウェブ アプリケーション ファイアウォール（WAF）やセキュリティ アプリケーション レベルのファイアウォールなどのセキュリティ機能を実装できます。特に図 2 に示すように、ハブスポーク構成を使用している場合は、NVA を使用して VM 間トラフィックのセキュリティ機能を実装できます。
図 2. 共有 VPC ネットワークで一元化されたネットワーク アプライアンス構成。
Cloud IDS
Cloud Intrusion Detection System（Cloud IDS）を使用すると、VPC ネットワーク内のサブネットからのトラフィックをミラーリングすることで、ネイティブのセキュリティ検査とロギングを実装できます。Cloud IDS を使用すると、ネットワーク レイヤとアプリケーション レイヤでさまざまな脅威を検査し、モニタリングして分析できます。Google Cloud プロジェクトに関連付けられた VPC ネットワークに Cloud IDS エンドポイントを作成します。これらのエンドポイントは、Google Cloud ネットワーク スタックに組み込まれているパケット モニタリング機能を使用して、そのネットワークとの上り（内向き）トラフィックと下り（外向き）トラフィック、VPC 内のネットワーク トラフィックをモニタリングします。Cloud IDS プロセスをホストするサービス プロデューサー プロジェクト（Google 管理のプロジェクト）に接続するには、限定公開サービス アクセスを有効にする必要があります。
図 3 に示すように、ハブアンドスポーク アーキテクチャを使用している場合、各スポークからのトラフィックを Cloud IDS インスタンスにミラーリングできます。
図 3. 限定公開サービス アクセスを使用する VPC トラフィックをミラーリングするための Cloud IDS 構成。
Cloud IDS は、追加のステップを使用して、VPC Service Controls のサービス境界で保護できます。VPC Service Controls のサポートに関する詳細は、サポートされているプロダクトをご覧ください。
VPC ネットワーク ピアリング
複数の VPC ネットワークにまたがるアプリケーションの場合、同じ Google Cloud プロジェクトに属しているか、同じ組織リソースに属しているかにかかわらず、VPC ネットワーク ピアリングで VPC ネットワーク間の接続が可能です。この接続により、トラフィックは Google のネットワーク内にとどまるため、パブリックなインターネットを経由することはありません。
リフト&シフト アーキテクチャで VPC ネットワーク ピアリングを使用するには、2 つのモデルがあります。1 つは「純粋な」ハブ アンド スポーク アーキテクチャです。もう 1 つは推移性を備えたハブ アンド スポーク アーキテクチャで、1 つのスポークからのトラフィックが別のスポークに到達できます。以降のセクションでは、これらのさまざまなアーキテクチャで VPC ネットワーク ピアリングを使用する方法について説明します。
ハブアンドスポーク アーキテクチャ
ハブアンドスポーク アーキテクチャは、VPC ネットワーク ピアリングを使用する VPC 接続の一般的なモデルです。このモデルは、企業が一般的なサービスのセット（ロギングや認証など）にアクセスする必要があるさまざまなアプリケーションを所有している場合に便利です。このモデルは、ハブを通過してネットワークを出るトラフィックに対して共通のセキュリティ ポリシー セットを実装する必要がある場合にも役立ちます。純粋なハブアンドスポーク モデルでは、スポーク間のトラフィック交換（推移的トラフィックとして知られる）は許可されません。図 4 は、VPC ネットワーク ピアリングを使用してスポークをハブに接続する純粋なハブアンドスポーク アーキテクチャを示しています。ハブアンドスポーク ネットワークを構築するための実装ガイドラインについては、エンタープライズ基盤ブループリントのハブアンドスポーク ネットワーク トポロジをご覧ください。
ただし、VPC レベルの分離が必要ない場合は、共有 VPC アーキテクチャを使用できます。これにより、Google Cloud を使い始めたばかりの一部の企業にとってよりシンプルなモデルを実現できる可能性があります。
図 4. VPC ネットワーク ピアリングを使用してネットワーク分離と非推移的接続を使用する、ハブ アンド スポーク ネットワーク アーキテクチャ。
推移性を備えたハブアンドスポーク
推移性を備えたハブアンドスポーク（スポークからのトラフィックがハブを介して他のスポークに到達可能）を有効にするには、VPC ネットワーク ピアリングを使用するいくつかのアプローチがあります。フルメッシュ トポロジでは VPC ネットワーク ピアリングを使用できます。これにより、すべての VPC ネットワークが、アクセスする必要がある他のすべての VPC ネットワークとダイレクトにピアリングされます。
また、NVA を使用してハブとスポークを接続することもできます。NVA は、VPC スポークからのトラフィックのネクストホップとして使用される内部ロードバランサの背後に配置されます。図 5 に、この両方のオプションを示します。
また、VPN を使用して、ハブ VPC ネットワークとスポーク VPC ネットワークを接続することもできます。この配置により、スポーク間接続全体のネットワーク到達性が可能になり、ハブ VPC ネットワーク全体での推移性が実現します。
図 5. Cloud VPN を使用してネットワークの分離と推移的な接続を行う、ハブ アンド スポーク ネットワーク構成。
共有 VPC
共有 VPC を使用すると、ホスト プロジェクトのサブネット、ルート、ファイアウォールなどのネットワーク リソースを一元管理できます。このレベルの制御では、ネットワーク管理タスクをネットワーク管理者とセキュリティ管理者に委任できるため、ネットワーク管理、監査、およびアクセス制御に対して最小限の権限というセキュリティのベスト プラクティスを実装できます。VM の作成と管理機能をインスタンス管理者に割り当てるには、サービス プロジェクトを使用します。サービス プロジェクトを使用すると、VM 管理者にはインスタンスの作成と管理のみが許可され、共有 VPC ネットワークでネットワークに影響する変更は許可されません。
たとえば、さらに分離を行うためには、2 つのホスト プロジェクトにある 2 つの VPC ネットワークを定義し、各ネットワークに複数のサービス プロジェクト（1 つは本番環境用、もう 1 つはテスト用）を接続します。図 6 は、別々のプロジェクトを使用して本番環境をテスト環境から分離するアーキテクチャを示しています。
VPC ネットワークを構築するためのベスト プラクティスについては、VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャをご覧ください。
図 6. 複数の分離されたホストとサービス プロジェクト（テスト環境と本番環境）を使用する共有 VPC ネットワーク構成。
ハイブリッド サービスのアーキテクチャ
ハイブリッド サービスのアーキテクチャには、マルチ VPC 環境でサービスを接続して保護できる追加のクラウドネイティブ サービスが用意されています。これらのクラウドネイティブ サービスは、リフト&シフト アーキテクチャで使用可能な機能を補完し、VPC セグメント化された環境を大規模に簡単に管理できます。
Private Service Connect
Private Service Connect を使用すると、ある VPC ネットワークでホストされているサービスを別の VPC ネットワークで公開できます。サービスが同じ組織リソースでホストされている必要はありません。Private Service Connect を使用すると、別の組織リソースに接続している場合でも、別の VPC ネットワークからサービスをプライベートに利用できます。
Private Service Connect を使用するには、Google API にアクセスする方法と、他の VPC ネットワークでホストされているサービスにアクセスする方法があります。
Private Service Connect を使用して Google API にアクセスする
Private Service Connect を使用する場合は、図 7 に示すように、VPC ネットワークの一部である Private Service Connect エンドポイントを使用して Google API を公開できます。
図 7.VPC ネットワーク限定公開の Private Service Connect エンドポイントを使用して Google API にトラフィックを送信する Private Service Connect の構成。
ワークロードは、Private Service Connect エンドポイントを使用して、グローバル Google API のバンドルにトラフィックを送信できます。また、Private Service Connect バックエンドを使用して 1 つの Google API にアクセスし、ロードバランサのセキュリティ機能を API サービスに拡張できます。図 8 は、この構成を示しています。
図 8. Private Service Connect バックエンドを使用して Google API にトラフィックを送信する Private Service Connect の構成。
VPC ネットワーク間またはエンティティ間の Private Service Connect の使用
Private Service Connect では、サービス プロデューサーは、同じ組織リソースまたは別のリソースに含まれる別の VPC ネットワーク内のサービス ユーザーにサービスを提供することもできます。サービス プロデューサー VPC ネットワークは複数のサービス ユーザーをサポートできます。ユーザーは、ユーザーの VPC ネットワークにある Private Service Connect エンドポイントにトラフィックを送信することで、プロデューサー サービスに接続できます。エンドポイントは、そのトラフィックを公開サービスを含む VPC ネットワークに転送します。
図 9. サービス アタッチメントを介してマネージド サービスを公開し、エンドポイントを介してサービスを使用する Private Service Connect 構成。
VPC サーバーレス アクセス コネクタ
VPC サーバーレス アクセス コネクタは、サーバーレス環境と VPC ネットワーク間のトラフィックを処理します。Google Cloud プロジェクトでコネクタを作成するときに、コネクタを特定の VPC ネットワークとリージョンに接続します。送信ネットワーク トラフィックにコネクタを使用するように、サーバーレス サービスを構成します。サブネットまたは CIDR 範囲を使用してコネクタを指定できます。コネクタを介して VPC ネットワークに送信されるトラフィックは、図 10 に示すように、サブネットまたは指定した CIDR 範囲から発信されます。
図 10. VPC ネットワーク内の内部 IP アドレスを使用して Google Cloud サーバーレス環境にアクセスするためのサーバーレス VPC アクセス コネクタの構成。
サーバーレス VPC アクセス コネクタは、Cloud Run、Cloud Run functions、App Engine スタンダード環境をサポートするすべてのリージョンでサポートされています。詳細については、VPC サーバーレス アクセス コネクタの使用について、サポートされているサービスとサポートされているネットワーク プロトコルのリストをご覧ください。
VPC Service Controls
VPC Service Controls を使用すると、インターネットからの、またはセキュリティ境界の一部ではないプロジェクトからの未承認アクセスを防ぐことで、Cloud Storage や BigQuery などのサービスからのデータの引き出しを防ぐことができます。たとえば、人的ミスや誤った自動化により、Cloud Storage や BigQuery などのサービスに IAM ポリシーが正しく設定されていないシナリオについて考えてみましょう。その結果、これらのサービス内のリソースは一般公開されます。その場合、データが漏洩するリスクがあります。これらのサービスが VPC Service Controls の境界の一部として構成されている場合、IAM ポリシーでアクセスを許可しても、リソースに対する上り（内向き）アクセスはブロックされます。
VPC Service Controls では、ID タイプ（サービス アカウントまたはユーザー）やネットワーク送信元（IP アドレスまたは VPC ネットワーク）などのクライアント属性に基づいて境界を作成できます。
VPC Service Controls は、次のセキュリティ リスクを軽減するのに役立ちます。
- ●盗まれた認証情報を使用した無許可のネットワークからのアクセス
- ●悪意のある内部関係者や感染コードによるデータの引き出し
- ●IAM ポリシーの構成ミスによるプライベート データの偶発的な公開
図 11 は、VPC Service Controls を使用してサービス境界を確立して、これらのリスクを軽減する方法を示しています。
図 11. プライベート アクセス サービスを使用して、ハイブリッド環境に拡張された VPC サービス境界。
上り（内向き）ルールと下り（外向き）ルールを使用すると、図 12 に示すように 2 つのサービス境界間の通信を有効にできます。
図 12. サービス境界間の通信用に上り（内向き）ルールと下り（外向き）ルールを構成する。
VPC Service Controls のデプロイ アーキテクチャに関する推奨事項については、サービス境界の設計と構築をご覧ください。VPC Service Controls でサポートされているサービスの一覧については、サポートされているプロダクトと制限事項をご覧ください。
ゼロトラスト分散型アーキテクチャ
ネットワーク境界のセキュリティ制御は必要ですが、最小権限と多層防御のセキュリティ原則をサポートするには十分ではありません。ゼロトラスト分散アーキテクチャは、セキュリティ適用のためにネットワーク境界エッジ上に構築されますが、ネットワーク境界エッジに依存しません。分散アーキテクチャとして、これらはサービスごとにセキュリティ ポリシー、強力な認証、Workload Identity が適用されるマイクロサービスで構成されています。
ゼロトラスト分散アーキテクチャは、Cloud Service Mesh と Cloud Service Mesh によって管理されるサービスとして実装できます。
Cloud Service Mesh
Cloud Service Mesh は、サービス セキュリティを使用して、GKE クラスタ内にゼロトラスト分散アーキテクチャ マイクロサービス メッシュを提供するように構成できます。このモデルでは、Envoy サイドカーまたはプロキシレス gRPC を備えた GKE サービスで、ID、証明書、認可ポリシーはすべて、Cloud Service Mesh、Workload Identity、Certificate Authority Service、IAM のすべてによって管理されます。プラットフォームによって証明書の管理と安全な命名が提供され、すべてのサービス通信が mTLS トランスポート セキュリティの対象となります。図 13 は、この構成のクラスタを示しています。
図 13. Cloud Service Mesh を使用する単一クラスタのゼロトラスト分散アーキテクチャ メッシュ。
認可ポリシーは、サーバーが受信リクエストや RPC を認可する方法を指定します。認可ポリシーは、リクエストを送信したクライアントの ID、ホスト、ヘッダー、その他の HTTP 属性などのさまざまなパラメータに基づいて、受信リクエストや RPC を許可または拒否するように構成できます。gRPC と Envoy に基づくメッシュで認可ポリシーを構成するための実装ガイドラインをご覧ください。
図 13 では、アーキテクチャは単一クラスタとフラットなネットワーキング（共有 IP アドレス空間）で構成されています。通常、ゼロトラスト分散アーキテクチャでは、分離、ロケーション、スケールのために複数のクラスタが使用されます。
クラスタがフリートでグループ化されている複雑な環境では、複数のクラスタでマネージド ID を共有できます。その場合、Private Service Connect を使用して、独立した VPC ネットワーク間のネットワーク接続を構成できます。このアプローチは、このドキュメントの後半で説明するハイブリッド ワークロード アクセスのマルチクラスタ ネットワーク接続に似ています。
Cloud Service Mesh によるトラフィックの処理方法をきめ細かく制御する方法については、高度なトラフィック管理の概要をご覧ください。
Cloud Service Mesh
Cloud Service Mesh は、すぐに使用できる mTLS ゼロトラスト分散アーキテクチャ マイクロサービス メッシュ（Istio の基盤上に構築）を提供します。メッシュは、統合フローを使用して設定します。GKE では、Google 管理のデータとコントロール プレーンを備えたマネージド Cloud Service Mesh がサポートされています。Google Distributed Cloudisesl や GKE Multi-cloud などの他の環境に適したクラスタ内コントロール プレーンも使用できます。Cloud Service Mesh は、Istio ベースの認可ポリシーモデルを使用して、ID と証明書を管理します。
Cloud Service Mesh は、フリートを使用してマルチクラスタ サービスのデプロイ構成と ID を管理します。Cloud Service Mesh と同様に、ワークロードがフラットな（または共有）VPC ネットワーク接続環境で動作している場合、ファイアウォール構成以外に特別なネットワーク接続要件はありません。アーキテクチャが、別の VPC ネットワークまたはネットワーク環境（Cloud Interconnect 接続上など）にまたがる複数の Cloud Service Mesh クラスタを含む場合、East-West ゲートウェイなども必要です。Cloud Service Mesh のネットワーキングのベスト プラクティスは、GKE ネットワーキングのベスト プラクティスで説明されているものと同じです。
Cloud Service Mesh は Identity-Aware Proxy（IAP）と連携します。IAP では、きめ細かいアクセス ポリシーを設定できます。これにより、ユーザー ID、IP アドレス、デバイスの種類など、元のリクエストの属性に基づいてワークロードへのユーザー アクセスを制御できます。このレベルの制御により、エンドツーエンドのゼロトラスト環境が実現します。
Cloud Service Mesh を使用する場合は、GKE クラスタの要件を考慮する必要があります。詳細については、「GKE への単一プロジェクトのインストール」の要件セクションをご覧ください。
次のステップ
- インターネットに接続するアプリケーション配信のためのネットワーキング: リファレンス アーキテクチャ。
- ハイブリッドおよびマルチクラウドのワークロードのネットワーキング: リファレンス アーキテクチャ。
- Google Cloud への移行。ワークロードを Google Cloud に移行するプロセスを計画、設計、実装する際に役立つ可能性があります。
- Google Cloud のランディング ゾーンの設計。ランディング ゾーン ネットワークを作成するためのガイダンスを説明しています。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。