このドキュメントは、データセンターのワークロードをGoogle Cloudに移行する企業向けのネットワーキング アーキテクチャとセキュリティ アーキテクチャについて説明するシリーズの一部です。
このシリーズは、次のドキュメントで構成されています。
- エンタープライズ ワークロードを移行するためのネットワーク設計: アーキテクチャのアプローチ
- 安全なクラウド内アクセスのためのネットワーキング: リファレンス アーキテクチャ(このドキュメント)
- インターネットに接続するアプリケーションの配信のためのネットワーキング: リファレンス アーキテクチャ
- ハイブリッドおよびマルチクラウドのワークロードのネットワーキング: リファレンス アーキテクチャ
クラウド内のユースケースのワークロードは VPC ネットワークに存在し、 Google Cloudの他のリソースに接続する必要があります。BigQuery など、クラウドでネイティブに提供されるサービスを使用する場合があります。セキュリティ境界は、ファイアウォール、VPC Service Controls、ネットワーク仮想アプライアンスなど、さまざまな自社(1P)機能とサードパーティ(3P)機能によって提供されます。
多くの場合、これらのワークロードは複数の Google CloudVPC ネットワークにまたがるため、VPC ネットワーク間の境界を保護する必要があります。このドキュメントでは、これらのセキュリティと接続のアーキテクチャについて詳しく説明します。
リフト&シフト アーキテクチャ
クラウド内のユースケースの最初のシナリオは、既存のワークロードをそのままクラウドに移行するリフト&シフト アーキテクチャです。
Cloud NGFW
Cloud Next Generation Firewall を構成すると、安全な境界を確立できます。タグ、サービス アカウント、ネットワーク タグを使用して、きめ細かいファイアウォール ルールを VM に適用できます。 Google Cloud ファイアウォール ルールでトラフィックを管理する方法の実装ガイドラインについては、エンタープライズ基盤ブループリントのネットワーク ファイアウォール ポリシーをご覧ください。
ファイアウォール ルールロギングを使用して、ファイアウォール ルールの設定の効果を監査および検証することもできます。
VPC フローログを使用してネットワーク フォレンジックを行ったり、ログをストリーミングして SIEM と統合したりできます。このシステム全体で、リアルタイムのモニタリング、イベントの相関、分析、セキュリティ通知を提供できます。
図 1 は、ファイアウォール ルールがネットワーク タグを使用して、VPC ネットワーク内の VM 間のトラフィックを制限する方法を示しています。
図 1: ネットワーク タグを使用してきめ細かい下り(外向き)制御を適用するネットワーク ファイアウォール構成。
ネットワーク仮想アプライアンス
ネットワーク仮想アプライアンス(NVA)は、ウェブ アプリケーション ファイアウォール(WAF)やセキュリティ アプリケーション レベルのファイアウォールなどのセキュリティ機能を備えた VM です。複数のネットワーク インターフェースを持つ NVA を使用して、VPC ネットワーク間のブリッジを構築できます。特に図 2 に示すように、ハブスポーク構成を使用している場合は、NVA を使用して VPC ネットワーク間のセキュリティ機能トラフィックを実装できます。
図 2. 共有 VPC ネットワークで一元化されたネットワーク アプライアンス構成。
Cloud IDS
Cloud Intrusion Detection System(Cloud IDS)を使用すると、VPC ネットワーク内のサブネットからのトラフィックをミラーリングすることで、ネイティブのセキュリティ検査とロギングを実装できます。Cloud IDS を使用すると、ネットワーク レイヤとアプリケーション レイヤでさまざまな脅威を検査し、モニタリングして分析できます。Cloud IDS エンドポイントは、 Google Cloud VPC ネットワークに作成します。これらのエンドポイントは、 Google Cloud ネットワーク スタックに組み込まれているパケット モニタリング機能を使用して、そのネットワークとの上り(内向き)トラフィックと下り(外向き)トラフィック、VPC 内のネットワーク トラフィックをモニタリングします。Cloud IDS プロセスをホストするサービス プロデューサー プロジェクト(Google 管理のプロジェクト)に接続するには、プライベート サービス アクセスを有効にする必要があります。
図 3 に示すように、ハブアンドスポーク アーキテクチャを使用している場合、各スポークからのトラフィックを Cloud IDS インスタンスにミラーリングできます。
図 3. プライベート サービス アクセスを使用する VPC トラフィックをミラーリングするための Cloud IDS 構成。
Cloud IDS は、追加のステップを使用して、VPC Service Controls のサービス境界で保護できます。VPC Service Controls のサポートに関する詳細は、サポートされているプロダクトをご覧ください。
Network Connectivity Center
Network Connectivity Center は、ハブと呼ばれる一元管理リソースに接続されているリソース間のネットワーク接続を簡素化するオーケストレーション フレームワークです。Network Connectivity Center は、次のタイプのネットワークをサポートしています。
- Google Cloud VPC ネットワーク
- Cloud Interconnect または HA VPN を使用するオンプレミス ネットワークと他のクラウド ネットワーク
- VM によってアンカーされた暗号化された接続
Network Connectivity Center は、アーキテクチャのコントロール プレーンです。ネットワークへの接続はスポークと呼ばれます。Network Connectivity Center を使用すると、フルメッシュ トポロジまたはハブ アンド スポーク トポロジでネットワークを接続できます。
VPC ネットワーク ピアリング
複数の VPC ネットワークにまたがるアプリケーションの場合、同じ Google Cloud プロジェクトに属しているか、同じ組織リソースに属しているかにかかわらず、VPC ネットワーク ピアリングで VPC ネットワーク間の接続が可能です。この接続により、トラフィックは Google のネットワーク内にとどまるため、パブリックなインターネットを経由することはありません。
ハブ アンド スポーク アーキテクチャは、VPC 接続の一般的なモデルです。このモデルは、企業が一般的なサービスのセット(ロギングや認証など)にアクセスする必要があるさまざまなアプリケーションを所有している場合に便利です。このモデルは、ハブを通過してネットワークを出るトラフィックに対して共通のセキュリティ ポリシー セットを実装する必要がある場合にも役立ちます。VPC ネットワーク ピアリングを使用してハブアンドスポーク アーキテクチャを設定するガイダンスについては、VPC ネットワーク ピアリングを使用した Cross-Cloud Network の VPC 間の接続をご覧ください。
共有 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 構成。
プライベート サービス アクセス
サービス プロデューサーがサービス コンシューマにサービスを提供するには、Private Service Connect を使用することをおすすめします。ただし、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 下り(外向き)
ダイレクト VPC 下り(外向き)を使用すると、Cloud Run サービスはサーバーレス VPC アクセス コネクタを設定せずに 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 は、すぐに使用できる 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 アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。