エンタープライズ ワークロードを移行するためのネットワーク設計: アーキテクチャのアプローチ

Last reviewed 2023-11-13 UTC

このドキュメントでは、データセンターのワークロードを Google Cloud に移行する企業向けのネットワーキング アーキテクチャとセキュリティ アーキテクチャについて説明するシリーズを紹介します。これらのアーキテクチャでは、ハイブリッド環境全体の高度な接続、ゼロトラスト セキュリティ原則、管理性が重視されています。

付属のドキュメント、クラウド データ プレーンの保護のアーキテクチャで説明されているように、企業はクラウド内の接続性とセキュリティ ニーズを考慮に入れた幅広いアーキテクチャをデプロイします。Google では、これらのアーキテクチャを、リフト＆シフト、ハイブリッド サービス、ゼロトラスト分散の 3 つのアーキテクチャ パターンに分類しています。このドキュメントでは、企業が選択したアーキテクチャに応じて、さまざまなセキュリティ アプローチについて説明します。また、Google Cloud が提供するビルディング ブロックを使用して、これらのアプローチを実現する方法についても説明します。これらのセキュリティ ガイダンスは、信頼性、可用性、スケール、パフォーマンス、ガバナンスに関する他のアーキテクチャ ガイダンスと併用する必要があります。

このドキュメントは、オンプレミスのワークロードをクラウドに移行することを計画しているシステム アーキテクト、ネットワーク管理者、セキュリティ管理者を支援するためのものです。次のことを前提としています。

  • データセンターのネットワーキングとセキュリティのコンセプトに精通している。
  • オンプレミスのデータセンターに既存のワークロードがあり、それらが行う処理の内容と対象ユーザーについて理解している。
  • 移行を計画している少なくともいくつかのワークロードがある。
  • クラウド データプレーンの保護のアーキテクチャで説明しているコンセプトについて全般的に理解している。

このシリーズは、次のドキュメントで構成されています。

このドキュメントでは、3 つの主要なアーキテクチャ パターンの要点と、インフラストラクチャの作成に使用できるリソースの構成要素の概要について説明します。最後に、構成要素を組み合わせてパターンに一致する一連のリファレンス アーキテクチャを構築する方法について説明します。これらのリファレンス アーキテクチャは、独自のアーキテクチャの指針として使用できます。

このドキュメントでは、ワークロード リソースの例として仮想マシン（VM）について説明します。この情報は、Cloud SQL インスタンスや Google Kubernetes Engine ノードなど、VPC ネットワークを使用する他のリソースに適用されます。

アーキテクチャ パターンの概要

一般的に、ネットワーク エンジニアは、オンプレミスのデータセンターに物理的なネットワーキング インフラストラクチャとセキュリティ インフラストラクチャを構築することに注力してきました。

クラウド ネットワーキング構造はソフトウェア定義であるため、クラウドへの移行によりこのアプローチは変化しました。クラウドでは、アプリケーション オーナーは基盤となるインフラストラクチャ スタックの制御が制限されます。必要とされるのは、安全な境界が用意されており、ワークロードを分離するモデルです。

このシリーズでは、一般的な 3 つのアーキテクチャ パターンについて取り上げます。これらのパターンは互いをベースとしてビルドされており、厳密に選択するというより一定の範囲とみなすことができます。

リフト＆シフトのパターン

リフト&シフト アーキテクチャのパターンでは、企業のアプリケーション オーナーが、ワークロードをリファクタリングせずにクラウドにワークロードを移行します。ネットワーク エンジニアとセキュリティ エンジニアは、レイヤ 3 とレイヤ 4 の制御を使用して、VPC ネットワークのオンプレミス物理デバイスとクラウド ファイアウォール ルールを模倣したネットワーク仮想アプライアンスを組み合わせて、保護を提供します。ワークロード オーナーは VPC ネットワークにサービスをデプロイします。

ハイブリッド サービスのパターン

リフト＆シフトで構築されたワークロードは、BigQuery や Cloud SQL などのクラウド サービスへのアクセスを必要とする場合があります。通常、このようなクラウド サービスへのアクセスはレイヤ 4 とレイヤ 7 にあります。この場合、分離とセキュリティは厳密にレイヤ 3 では行えません。したがって、アクセスされるサービスとアクセスをリクエストしているサービスの ID に基づいて、サービス ネットワーキングと VPC Service Controls を使用して接続とセキュリティを提供します。このモデルでは、豊富なアクセス制御ポリシーを表現できます。

ゼロトラスト分散パターン

ゼロトラスト アーキテクチャでは、エンタープライズ アプリケーションは境界制御の範囲を超えてセキュリティの適用を拡張します。境界内では、ワークロードは IAM ID に特定の権限が付与されている場合にのみ他のワークロードと通信できます。これはデフォルトで拒否されます。ゼロトラスト分散アーキテクチャでは、信頼は ID ベースであり、各アプリケーションに適用されます。ワークロードは、一元的に発行された ID を持つマイクロサービスとして構築されます。これにより、サービスは呼び出し元を検証し、各リクエストに対して、アクセスが許可されるかどうかをポリシーに基づいて決定できます。このアーキテクチャは、一元化されたゲートウェイではなく、分散プロキシ（サービス メッシュ）を使用して実装されることが頻繁に見られます。

Identity-Aware Proxy（IAP）を構成することで、ユーザーやデバイスからエンタープライズ アプリケーションへのゼロトラスト アクセスを適用できます。IAP では、インターネットまたはイントラネットのユーザー トラフィックに ID とコンテキスト ベースの制御を提供します。

パターンの組み合わせ

ビジネス アプリケーションの構築やクラウドへの移行を行う企業は、通常、3 つすべてのアーキテクチャ パターンを組み合わせて使用します。

Google Cloud には、アーキテクチャ パターンを支えるクラウド データプレーンを実装するための構成要素として機能するプロダクトとサービスのポートフォリオが用意されています。これらの構成要素については、このドキュメントで後述します。クラウド データプレーンで提供されるコントロールとクラウド リソースを管理する管理コントロールの組み合わせにより、エンドツーエンドのセキュリティ境界の基盤が形成されます。この組み合わせによって作成される境界により、クラウド内のワークロードを管理、デプロイ、運用できます。

リソース階層と管理機能

このセクションでは、Google Cloud がリソース コンテナとして提供する管理機能の概要について説明します。このコントロールには、Google Cloud 組織のリソース、フォルダ、プロジェクトが含まれ、クラウド リソースをグループ化して階層的に編成できます。この階層的組織は、所有権構造、およびポリシーと制御を適用するアンカー ポイントを提供します。

Google の組織リソースは、階層のルートノードであり、クラウドでデプロイを作成するための基盤となります。組織リソースは、フォルダとプロジェクトを子として持つことができます。フォルダにはプロジェクトやその他のフォルダが子として含まれています。その他のクラウド リソースはすべてプロジェクトの子ノードです。

プロジェクトをグループ化する方法としてフォルダを使用します。プロジェクトは、すべての Google Cloud サービスの作成、有効化、使用の基礎となります。プロジェクトでは、API の管理、課金の有効化、共同編集者の追加と削除、権限の管理を行うことができます。

Google の Identity and Access Management（IAM）を使用すると、すべてのリソース階層レベルでロールを割り当て、アクセス ポリシーと権限を定義できます。IAM ポリシーは、階層の下位のリソースに継承されます。階層の下位にあるリソース オーナーがこれらのポリシーを変更することはできません。Identity and Access Management は、Google Kubernetes Engine におけるような名前空間やクラスタ内のオブジェクト スコープなど、さらに細かいレベルで提供される場合もあります。

Google Virtual Private Cloud ネットワークの設計に関する考慮事項

クラウドへの移行戦略を設計する際は、企業が VPC ネットワークを使用する方法を策定することが重要です。VPC ネットワークは、従来の物理ネットワークの仮想バージョンと考えられます。これは、完全に分離されたプライベート ネットワーク パーティションです。デフォルトでは、1 つの VPC ネットワークにデプロイされているワークロードやサービスは、別の VPC ネットワーク内のジョブと通信できません。このため、VPC ネットワークではセキュリティ境界を形成することでワークロードを分離できます。

クラウド内の各 VPC ネットワークは完全な仮想ネットワークであるため、それぞれに独自のプライベート IP アドレス空間があります。したがって、複数の VPC ネットワークで同じ IP アドレスを競合が生じない状態で使用できます。一般的なオンプレミス デプロイでは、RFC 1918 プライベート IP アドレス空間の大部分を使用する場合があります。一方、オンプレミスと VPC ネットワークの両方にワークロードが存在する場合は、それらのネットワークが接続またはピアリングされていない限り、異なる VPC ネットワークで同じアドレス範囲を再利用できます。このため、IP アドレス空間をすぐに使い尽くすようなことはありません。

VPC ネットワークはグローバル

Google Cloud の VPC ネットワークはグローバルです。つまり、VPC ネットワークを含むプロジェクトにデプロイされたリソースは、Google のプライベート バックボーンを使用して相互に直接通信できます。

図 1 に示すように、プロジェクトには、複数のゾーンにまたがる異なるリージョンにサブネットワークを持つ VPC ネットワークを設定できます。任意のリージョンの VM は、ローカル VPC ルートを使用して相互にプライベートで通信できます。

異なるリージョンに構成されたサブネットワークを使用した Google Cloud グローバル VPC ネットワークの実装。

図 1.異なるリージョンに構成されたサブネットワークを使用した Google Cloud グローバル VPC ネットワークの実装。

共有 VPC を使用したネットワークの共有

共有 VPC を使用すると、組織リソースは複数のプロジェクトを共通の VPC ネットワークに接続できます。これにより複数のプロジェクトは、共有ネットワークから内部 IP アドレスを使用して互いに安全に通信できます。対象の共有ネットワークのネットワーク管理者は、ネットワーク リソースに一元管理を適用します。

共有 VPC を使用する場合、1 つのプロジェクトをホスト プロジェクトとして指定し、1 つ以上のサービス プロジェクトをホスト プロジェクトに接続します。ホスト プロジェクトの VPC ネットワークは、共有 VPC ネットワークといいます。サービス プロジェクトの適格リソースは、共有 VPC ネットワーク内のサブネットを使用できます。

サブネットやルートなどのネットワーク リソースの管理を集中化するためネットワーク管理者やセキュリティ管理者が必要となる場合、企業は通常、共有 VPC ネットワークを使用します。それに加えて、共有 VPC ネットワークを使用すると、アプリケーション チームと開発チームは、サービス プロジェクトを使用して VM インスタンスを作成および削除し、指定のサブネットにワークロードをデプロイできます。

VPC ネットワークを使用して環境を分離する

VPC ネットワークを使用して環境を分離することにはいくつかの利点がありますが、いくつかの欠点も考慮する必要があります。このセクションでは、これらのトレードオフに対処し、分離を実装する一般的なパターンについて説明します。

環境を分離する理由

VPC ネットワークは分離ドメインとなるため、多くの企業は環境やビジネス ユニットを別々のドメインに保持するために使用しています。VPC レベルでの分離を行う一般的な理由は次のとおりです。

  • 各 VPC ネットワークは組織的に意味のある区別が可能なため、企業は 1 つの VPC ネットワークと別の VPC ネットワーク間でデフォルトの拒否通信を確立したいと考えている。詳細については、このドキュメントで後述する VPC ネットワーク分離の一般的なパターンをご覧ください。
  • 既存のオンプレミス環境、買収、または別のクラウド環境へのデプロイが原因で、企業は重複した IP アドレス範囲を持つ必要がある。
  • 企業は、ネットワークの完全な管理コントロールを企業の一部に委任したいと考えている。

環境を分離することのデメリット

VPC ネットワークと分離された環境を作成することには、いくつかのデメリットがあります。複数の VPC ネットワークを使用すると、複数のネットワークにわたって存在するサービスをマッピングする際の管理オーバーヘッドが増加する可能性があります。このドキュメントでは、この複雑さを管理するために使用できる手法について説明します。

一般的な VPC ネットワーク分離パターン

VPC ネットワークを分離するための一般的なパターンには、次のようなものがあります。

  • 開発環境、ステージング環境、本番環境を分離する。このパターンでは、企業は開発環境、ステージング環境、本番環境を完全に分離します。実質的に、この構造ではアプリケーションの複数の完全なコピーが維持され、各環境間で段階的にロールアウトされます。このパターンでは、VPC ネットワークがセキュリティ境界として使用されます。開発者には、日常業務を行うため、開発環境の VPC ネットワークに対する高度なアクセス権が付与されています。開発が完了すると、エンジニアリングの本番環境チームまたは QA チームが変更をステージング環境に移行できます。ステージング環境では、統合された方法で変更をテストできます。変更をデプロイする準備が整うと、変更は本番環境に送信されます。
  • ビジネス ユニットを分離する。一部の企業では、ビジネス ユニット間に高度な分離を課すことを必要とする場合があります。これには、特に買収された部門や、高度な自律性と分離を必要とする部門が該当します。このパターンでは、企業は多くの場合、ビジネス ユニットごとに VPC ネットワークを作成し、その VPC のコントロールをビジネス ユニットの管理者に委任します。企業は、このドキュメントの後半で説明する手法を使用して、企業全体にまたがるサービスを公開するか、複数のビジネス ユニットにまたがるユーザー向けアプリケーションをホストします。

分離環境を作成するための推奨事項

VPC ネットワークは、企業の管理境界やセキュリティ境界に沿ったできるだけ広いドメインを持つように設計することをおすすめします。ファイアウォールなどのセキュリティ コントロールを使用すると、同じ VPC ネットワーク内で実行されているワークロード間で分離を強化できます。

組織の分離戦略の設計と構築の詳細については、以下をご覧ください。VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャおよび Google Cloud エンタープライズ基盤のブループリント内のネットワーキングをご覧ください。

クラウド ネットワーキングの構成要素

このセクションでは、ネットワーク接続、ネットワーク セキュリティ、サービス ネットワーキング、サービス セキュリティの重要な構成要素について説明します。図 2 は、これらの構成要素が相互にどのように関連しているかを示しています。各行にリストされている 1 つ以上のプロダクトを使用できます。

クラウドのネットワーク接続とセキュリティの領域における構成要素。

図 2.クラウドのネットワーク接続とセキュリティの領域における構成要素。

以降のセクションでは、各構成要素と、各要素で使用できる Google Cloud サービスについて説明します。

ネットワーク接続

ネットワーク接続要素は、階層のベースに存在します。Google Cloud リソースをオンプレミス データセンターまたは他のクラウドに接続する役割を担います。ニーズに応じて、これらのプロダクトのいずれか 1 つが必要になるか、すべてのプロダクトを使用してさまざまなユースケースに対処することが必要な場合が考えられます。

Cloud VPN

Cloud VPN を使用すると、リモートの支店や他のクラウド プロバイダを IPsec VPN 接続を介して Google VPC ネットワークに接続できます。2 つのネットワーク間で送受信されるトラフィックは、一方の VPN ゲートウェイで暗号化された後、もう一方の VPN ゲートウェイで復号されるため、インターネットを通過する際にデータを保護できます。

Cloud VPN を使用すると、Cloud Interconnect に必要な物理相互接続をプロビジョニングするオーバーヘッドが発生することなく、オンプレミス環境と Google Cloud 間の接続を有効にできます（次のセクションで説明します）。準拠するアーキテクチャがあれば、最大 99.99% の可用性という SLA 要件を満たす HA VPN をプロビジョニングできます。ワークロードに低レイテンシや高帯域幅が必要ない場合は、Cloud VPN の使用を検討できます。たとえば、Cloud VPN はミッション クリティカルでないユースケースや、他のクラウド プロバイダへの接続を拡張する場合に適しています。

Cloud Interconnect

Cloud Interconnect は、Google Cloud へのエンタープライズ クラスの専用接続を提供します。VPN やインターネット上り（内向き）を使用する場合と比較して、スループットと信頼性に優れたネットワーク パフォーマンスを実現できます。Dedicated Interconnect は、ルーターから Google のネットワークに直接物理的に接続します。Partner Interconnect は、広範なパートナー ネットワークを介して専用接続を提供します。パートナーは、Dedicated Interconnect よりも幅広い範囲などの帯域幅オプションを提供する場合があります。Cross-Cloud Interconnect は、VPC ネットワークから他のクラウド プロバイダへの専用直接接続を提供します。Dedicated Interconnect では、Google が接続しているコロケーション施設に接続する必要がありますが、Partner Interconnect はその必要はありません。Cross-Cloud Interconnect を使用すると、要件を満たすロケーションを選択して接続を確立できます。Cloud Interconnect により、オンプレミス ネットワークまたは他のクラウド ネットワークと VPC ネットワークとの間のトラフィックが公共のインターネットを通過しないようになります。

適切なアーキテクチャをプロビジョニングすると、最大 99.99% の可用性の SLA 要件を満たすように Cloud Interconnect 接続をプロビジョニングできます。Cloud Interconnect を使用して、すべてのトラフィックをプライベートな状態で保持しながら、低レイテンシ、高帯域幅、予測可能なパフォーマンスを必要とするワークロードに対応することを検討できます。

ハイブリッド用の Network Connectivity Center

Network Connectivity Center は、オンプレミスと他のクラウド ネットワーク間のサイト間接続を提供します。この処理は Google のバックボーン ネットワークを使用して行われ、サイト間で信頼性の高い接続を実現します。

また、VM またはサードパーティ ベンダーのルーター アプライアンスを論理スポーク アタッチメントとして構成することで、既存の SD-WAN オーバーレイ ネットワークを Google Cloud に拡張できます。

ルーター アプライアンス VPN、または Cloud Interconnect ネットワークをスポーク アタッチメントとして使用して、VPC ネットワーク内のリソースにアクセスできます。Network Connectivity Center を使用すると、オンプレミス サイト、他のクラウドでのプレゼンス、Google Cloud 間の接続を統合し、すべて 1 つのビューで管理できます。

VPC ネットワーク用の Network Connectivity Center

Network Connectivity Center では、多くの VPC ネットワーク間のメッシュを作成することもできます。このメッシュは、Cloud VPN または Cloud Interconnect を使用してオンプレミスまたは他のクラウドに接続できます。

VPC ネットワーク ピアリング

VPC ネットワーク ピアリングを使用すると、同じプロジェクトまたは同じ組織リソースに属しているかどうかにかかわらず、異なる VPC ネットワーク内のワークロードは Google VPC ネットワークに接続して内部的に通信できるようになります。トラフィックは Google のネットワーク内に留まり、公共のインターネットを経由することはありません。

VPC ネットワーク ピアリングでは、ピアリングするネットワークの IP アドレスが重複していないことが必要です。

ネットワーク セキュリティ

ネットワーク セキュリティ ブロックは、ネットワーク接続ブロックの上にあります。IP パケットの特性に基づいてリソースへのアクセスを許可または拒否します。

VPC ファイアウォール ルール

VPC のファイアウォール ルールは特定のネットワークに適用されます。VPC ファイアウォール ルールを使用すると、指定した構成に基づいて、VM インスタンスとの接続を許可または拒否できます。有効な VPC ファイアウォール ルールは常に適用され、構成、オペレーティング システム、VM が完全に起動したかどうかに関係なくインスタンスを保護します。

すべての VPC ネットワークは、分散ファイアウォールとして機能します。ファイアウォール ルールはネットワーク レベルで定義されますが、接続はインスタンスごとに許可または拒否されます。VPC ファイアウォール ルールはインスタンスと他のネットワーク間だけでなく、同じネットワーク内の個別のインスタンス間にも存在すると考えられます。

階層型ファイアウォール ポリシー

階層型ファイアウォール ポリシーを使用すると、企業全体で一貫したファイアウォール ポリシーを作成して適用できます。これらのポリシーには、接続を明示的に拒否または許可するルールが含まれています。階層型ファイアウォール ポリシーは、組織リソースの全体または個々のフォルダに割り当てられます。

Packet Mirroring

Packet Mirroring は、VPC ネットワーク内に存在する特定のインスタンスのトラフィックのクローンを作成し、コレクタに転送して確認します。パケット ミラーリングでは、ペイロードとヘッダーを含むすべてのトラフィックとパケットデータをキャプチャします。上り（内向き）トラフィックと下り（外向き）トラフィックの両方、上り（内向き）トラフィックのみ、下り（外向き）トラフィックのみ、のいずれかにミラーリングを構成できます。ミラーリングはネットワークではなく VM インスタンスで行われます。

ネットワーク仮想アプライアンス

ネットワーク仮想アプライアンスを使用すると、オンプレミス環境のコントロールと一致するセキュリティとコンプライアンスのコントロールを仮想ネットワークに適用できます。これを行うには、Google Cloud Marketplace で入手可能な VM イメージを、それぞれが異なる VPC ネットワークに接続している複数のネットワーク インターフェースを持つ VM にデプロイし、さまざまなネットワーク仮想機能を実行します。

仮想アプライアンスの一般的なユースケースは次のとおりです。

  • 次世代ファイアウォール（NGFW）。NGFW は、VPC のファイアウォール ルールでは利用できない機能を提供する VM として実行される、一元化された一連のファイアウォールで構成されています。NGFW プロダクトの代表的な機能には、ディープ パケット インスペクション（DPI）とアプリケーション レイヤでのファイアウォール保護があります。一部の NGFW は、このリストで後述するように、TLS / SSL トラフィック検査やその他のネットワーキング機能も提供します。
  • 侵入検知システム / 侵入防止システム（IDS / IPS）。ネットワーク ベースの IDS は、悪質な可能性のあるトラフィックを可視化します。侵入を防止するため、IPS デバイスは悪意のあるトラフィックが宛先に到達しないようにブロックできます。
  • セキュアウェブ ゲートウェイ（SWG）。SWG は、企業がインターネットとの間で送受信されるトラフィックに企業ポリシーを適用できるようにすることで、インターネットからの脅威をブロックします。この対策には、URL フィルタリング、悪意のあるコードの検出、アクセス制御を使用します。
  • ネットワーク アドレス変換（NAT）ゲートウェイ。NAT ゲートウェイは IP アドレスとポートを変換します。たとえば、この変換により IP アドレスの重複を回避できます。Google Cloud はマネージド サービスとして Cloud NAT を提供していますが、このサービスはインターネットに送信されるトラフィックにのみ使用できます。オンプレミスや他の VPC ネットワークに送信されるトラフィックには使用できません。
  • ウェブ アプリケーション ファイアウォール（WAF）。WAF は、ウェブ アプリケーションに送信される悪意のある HTTP(S) トラフィックをブロックするように設計されています。Google Cloud では、Google Cloud Armor セキュリティ ポリシーを介して WAF 機能を提供します。正確な機能は WAF ベンダーによって異なるため、何が必要かを判断することが重要です。

Cloud IDS

Cloud IDS は侵入検知サービスで、ネットワーク上の侵入、マルウェア、スパイウェア、コマンド&コントロール攻撃の脅威を検出します。Cloud IDS は、ミラーリングされたトラフィックを受信する VM を含む Google 管理のピアリング ネットワークを作成することで動作します。ミラーリングされたトラフィックは Palo Alto Networks の脅威対策技術によって検査され、高度な脅威検出が行われます。

Cloud IDS は、サブネット内トラフィックを完全に可視化して、VM 間の通信をモニタリングし、ラテラル ムーブメントを検出できるようにします。

Cloud NAT

Cloud NAT は、アプリケーションのソフトウェア定義型のフルマネージド ネットワーク アドレス変換をサポートしています。外部 IP アドレスを持たない VM からのインターネット接続トラフィック向けの、送信元ネットワーク アドレス変換（送信元 NAT または SNAT）が有効になります。

ファイアウォール インサイト

ファイアウォール インサイトにより、ファイアウォール ルールを理解して最適化できます。ファイアウォール ルールの使用状況に関するデータが提供されるため、構成の誤りを確認し、より厳格化できるルールを特定することが可能です。また、ML を使用して今後のファイアウォール ルールの使用量が予測されるため、制限が緩すぎるルールを削除するか、厳格化するかについて、情報に基づいた意思決定ができます。

ネットワーク ロギング

複数の Google Cloud プロダクトを使用して、ネットワーク トラフィックのロギングと分析を行うことができます。

ファイアウォール ルールロギングにより、ファイアウォール ルールの効果を監査、検証、分析できます。たとえば、トラフィックを拒否するように設計されたファイアウォール ルールが意図したとおりに機能しているかどうかを判別できます。ファイアウォール ルールのロギングは、特定のファイアウォール ルールによって影響を受ける接続数を判別する必要がある場合にも役立ちます。

ファイアウォール ルールに一致する接続をログに記録する必要がある場合、そのファイアウォール ルールに対してファイアウォール ルールロギングを個別に有効にします。ルールの動作（許可または拒否）や方向（上り、内向きまたは下り、外向き）に関係なく、あらゆるファイアウォール ルールに任意でファイアウォール ルールのロギングを有効にできます。

VPC フローログは、VM インスタンスで送受信されたネットワーク フローのサンプルを記録します（Google Kubernetes Engine（GKE）ノードとして使用されたインスタンスを含む）。これらのログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析、費用の最適化に使用できます。

サービス ネットワーキング

サービス ネットワーキング ブロックは、リクエストの送信先（DNS、Service Directory）を教える検索サービス、および正しい場所（Private Service Connect、Cloud Load Balancing）へのリクエスト受け付けを提供します。

Cloud DNS

ワークロードにはドメイン名を使用してアクセスします。Cloud DNS は、ドメイン名を世界中のあらゆる場所にある IP アドレスに低レイテンシで変換する機能を備えています。Cloud DNS は、一般公開ゾーンと限定公開マネージド DNS ゾーンの両方を提供します。一般公開マネージド ゾーンは、公共のインターネットを通して表示され、限定公開ゾーンは、指定した 1 つ以上の VPC ネットワークでのみ表示されます。

Cloud Load Balancing

Google Cloud 内では、ロードバランサは非常に重要なコンポーネントです。トラフィックをさまざまなサービスに転送して、速度と効率性を確保し、内部と外部の両方のトラフィックについてグローバルにセキュリティを確保します。

Google のロードバランサは、複数のクラウドまたはハイブリッド環境間でトラフィックを転送し、スケーリングすることもできます。このため、Cloud Load Balancing は、アプリケーションの場所やホストされている場所の数に関係なく、アプリケーションをスケーリングできる「玄関口」となっています。Google では、グローバルとリージョン、外部と内部、レイヤ 4 とレイヤ 7 など、さまざまな種類のロード バランシングを提供しています。

Service Directory

Service Directory を使用すると、サービス インベントリを管理して、サービスを公開、検出、接続するための安全な単一の場所を提供できます。すべてのオペレーションは ID ベースのアクセス制御によって支えられています。名前付きサービスとそれらのエンドポイントを登録できます。登録は、手動で行うことができます。または、Private Service Connect、GKE、Cloud Load Balancing とのインテグレーションを使用して行うこともできます。サービス ディスカバリは、明示的な HTTP API と gRPC API を使用するか、Cloud DNS を使用して行うことができます。

サービス メッシュ: Anthos Service Mesh と Traffic Director

Anthos Service Mesh と Traffic Director はどちらも、サービス メッシュ アーキテクチャのトラフィック管理とセキュリティ ポリシーの豊富なセットを有効にすることで、複雑な分散アプリケーションを簡単に実行できるように設計されています。これらのプロダクトの主な違いは、サポート対象の環境、対応する Istio API、グローバル ロード バランシング機能にあります。

Anthos Service Mesh は、Google Cloud とオンプレミスの両方で、マネージド Istio プロダクトを利用する Kubernetes ベースのリージョン デプロイとグローバル デプロイに最適です。

Traffic Director は、Google Cloud 全体でグローバルにデプロイされた、正常性と負荷を考慮したサービスを使用するネットワーキングのユースケースに最適です。Traffic Director は、サイドカーまたはゲートウェイとして機能する Envoy プロキシを使用するか、プロキシレス gRPC ワークロードを使用してワークロードを管理します。

次の表は、Traffic Directory と Anthos Service Mesh の機能をまとめたものです。

Anthos Service Mesh Traffic Director
デプロイタイプ Kubernetes VM、Kubernetes
環境 Google Cloud、オンプレミス、マルチクラウド Google Cloud、オンプレミス、マルチクラウド
デプロイのスコープ リージョンおよび連携リージョン グローバル
API サーフェス Istio サービス ルーティング（Kubernetes Gateway モデル）
ネットワーク接続 Envoy サイドカー Envoy サイドカー、プロキシレス gRPC
バックエンドの健全性に基づくグローバルなロード バランシング はい（Kubernetes に基づく） はい
バックエンドの負荷に基づくグローバルなロード バランシング × はい
ワークロード mTLS のマネージド ID（ゼロトラスト） はい はい（GKE のみ）

Google は、BeyondProd アーキテクチャを使用して、エンドツーエンドのゼロトラスト分散アーキテクチャ環境を構築する方法をさらに詳しく説明しています。BeyondProd では、ネットワーク境界とサービスの認証と認可に加えて、信頼できるコンピューティング環境、コードの出所、デプロイのロールアウトが、安全な分散ゼロトラスト サービス アーキテクチャの達成において、どのような役割を果たすかについて詳しく説明します。ゼロトラスト アプローチを採用する場合は、ネットワークだけでなく、これらの懸念事項も考慮する必要があります。

Private Service Connect

Private Service Connect は、単一のエンドポイントを介して VPC ネットワーク間でワークロードにアクセスできるようにすることで、サービスの抽象化を行います。これにより、ネットワーク全体またはワークロード自体ではなく、サービスのみをコンシューマに公開するクライアントサーバー モデルで 2 つのネットワークが通信できるようになります。サービス指向のネットワーク モデルを使用すると、ネットワーク管理者はサブネットや VPC ではなくネットワーク間で公開するサービスを評価できるため、ファースト パーティかサードパーティ サービス（SaaS）かを問わずプロデューサー コンシューマ モデルでサービスを使用できるようになります。

Private Service Connect を使用すると、コンシューマ VPC はプライベート IP アドレスを使用して Google API または別の VPC のサービスに接続できます。

Private Service Connect をオンプレミス ネットワークに拡張して、Google API または別の VPC ネットワーク内のマネージド サービスに接続するエンドポイントにアクセスできます。Private Service Connect を使用すると、レイヤ 4 またはレイヤ 7 でサービスを使用できます。

レイヤ 4 で Private Service Connect を使用するには、プロデューサーは Private Service Connect に固有のサブネットを 1 つ以上作成する必要があります。これらのサブネットは NAT サブネットとも呼ばれます。Private Service Connect は、Private Service Connect サブネットの一つから選択された IP アドレスを使用してソース NAT を実行し、リクエストをサービス プロデューサーに転送します。このアプローチでは、コンシューマとプロデューサー間で重複する IP アドレスを使用できます。

レイヤ 7 では、内部アプリケーション ロードバランサを使用して Private Service Connect バックエンドを作成できます。内部アプリケーション ロードバランサにより、URL マップを使用して、使用可能なサービスを選択できます。詳細については、Private Service Connect バックエンドについてをご覧ください。

プライベート サービス アクセス

プライベート サービス アクセスは、VPC ネットワークと Google またはサードパーティが所有するネットワーク間のプライベート接続です。サービスを提供する Google またはサードパーティは、サービス プロデューサーと呼ばれます。プライベート サービス アクセスでは、VPC ネットワーク ピアリングを使用して接続を確立するため、プロデューサー VPC ネットワークとコンシューマ VPC ネットワークが相互にピアリングされている必要があります。これは、単一のプライベート IP アドレスをサブネットに投影できる Private Service Connect とは異なります。

プライベート接続を使用すると、VPC ネットワーク内の VM インスタンスとアクセスするサービスで、内部 IP アドレスを使用して排他的に通信できるようになります。VM インスタンスは、インターネット アクセスまたは外部 IP アドレスがなくても、プライベート サービス アクセスを介してサービスにアクセスできます。Cloud VPN または Cloud Interconnect を使用してオンプレミス ホストがサービス プロデューサーのネットワークにアクセスできるようにすることで、プライベート サービス アクセスをオンプレミス ネットワークまで拡張することもできます。プライベート サービス アクセスを使用してサポートされている Google マネージド サービスの一覧については、Virtual Private Cloud ドキュメントのサポートされているサービスをご覧ください。

サーバーレス VPC アクセス

サーバーレス VPC アクセスを使用すると、Cloud Run、App Engine、Cloud Functions などのサーバーレス環境でホストされているサービスから VPC ネットワークに直接接続できます。サーバーレス VPC アクセスを構成すると、サーバーレス環境で内部 DNS と内部 IP アドレスを使用して VPC ネットワークにリクエストを送信できます。これらのリクエストに対するレスポンスも仮想ネットワークを使用します。

サーバーレス VPC アクセスは、サーバーレス環境からサーバーレス VPC アクセス コネクタ経由で送信されたリクエストに対するレスポンスである場合にのみ、VPC ネットワークからサーバーレス環境に内部トラフィックを送信します。

サーバーレス VPC アクセスには次の利点があります。

  • VPC ネットワークに送信されたリクエストは、インターネットに公開されることはありません。
  • サーバーレス VPC アクセスを介した通信は、インターネット経由の通信よりもレイテンシが低くなります。

サービスのセキュリティ

サービス セキュリティ ブロックは、個別のパケットの特性だけでなく、リクエスト元の ID またはパケット パターンのより高度な理解に基づいて、リソースへのアクセスを制御します。

DDoS / WAF 用の Google Cloud Armor

Google Cloud Armor はウェブ アプリケーション ファイアウォール（WAF）であり、また分散型サービス拒否攻撃（DDoS）を軽減するサービスで、さまざまな種類の脅威からウェブ アプリケーションを防御するのに役立ちます。このような脅威には、DDoS 攻撃、クロスサイト スクリプティング（XSS）や SQL インジェクション（SQLi）などのウェブベースの攻撃、不正行為や自動化ベースの攻撃などがあります。

Google Cloud Armor は、Google のグローバル エッジで受信リクエストを検査します。それには、一般的なウェブ攻撃をスキャンするウェブ アプリケーション ファイアウォール ルール、および優れたトラフィック モデルを構築して不正なトラフィックを検出する高度な ML ベースの攻撃検出システムが組み込まれています最後に、Google Cloud Armor は Google reCAPTCHA Enterprise と統合されており、エンドポイント テレメトリーとクラウド テレメトリーの両方を使用して、高度な不正行為と自動化ベースの攻撃を検出して阻止します。

Identity-Aware Proxy（IAP）

Identity-Aware Proxy（IAP）は、Google Cloud で稼働しているか、いずれかのハイブリッド ネットワーキング テクノロジーを使用して Google Cloud に接続されているクラウドベースのアプリケーションと VM に対し、コンテキストアウェア アクセス制御を提供します。IAP はユーザー ID を検証し、さまざまなコンテキスト属性に基づいて、ユーザー リクエストが信頼できるソースから発信されているかどうかを判断します。IAP は、企業ユーザーからの SSH / RDP アクセス用の TCP トンネリングもサポートしています。

VPC Service Controls

VPC Service Controls を使用すると、Cloud Storage や BigQuery などの Google Cloud サービスからデータが漏洩するリスクを軽減できます。VPC Service Controls を使用すると、承認された環境からのみ Google Cloud サービスが使用されるようにできます。

VPC Service Controls を使用して、サービス アカウントと VPC ネットワークなどの特定のクラウドネイティブな ID 構造へのアクセスを制限することで、指定したサービスのリソースとデータを保護する境界を作成できます。境界が作成されると、境界内からリクエストが送信されない限り、指定した Google サービスへのアクセスは拒否されます。

コンテンツ配信

コンテンツ配信ブロックは、アプリケーションとコンテンツの配信の最適化を制御します。

Cloud CDN

Cloud CDN は、Google のグローバル エッジ ネットワークを使用してユーザーに最も近いポイントからコンテンツを配信することで、静的コンテンツを高速化します。これによりウェブサイトとアプリのレイテンシを短縮できます。

Media CDN

Media CDN は Google のメディア配信ソリューションであり、高スループットの下り（外向き）ワークロード用に構築されています。

オブザーバビリティ

オブザーバビリティ ブロックは、ネットワークを可視化し、トラブルシューティング、文書化、調査、問題のトラブルシューティングに使用できる分析情報を提供します。

Network Intelligence Center

Network Intelligence Center は、ネットワーク オブザーバビリティのさまざまな側面に対処する複数のプロダクトで構成されています。プロダクトごとに焦点が異なり、管理者、アーキテクト、実務担当者にネットワークの健全性と問題について通知するための豊富な分析情報を提供します。

リファレンス アーキテクチャ

次のドキュメントでは、さまざまなタイプのワークロード（クラウド内、インターネット接続、ハイブリッド）のリファレンス アーキテクチャについて説明しています。これらのワークロード アーキテクチャは、このドキュメントの前の各セクションで概要を説明した構成要素とアーキテクチャ パターンを使用して実現されたクラウド データプレーン上に構築されています。

リファレンス アーキテクチャを使用すると、クラウドでワークロードを移行または構築する方法を設計できます。ワークロードはクラウド データプレーンによって支えられ、このアーキテクチャを使用します。これらのドキュメントではリファレンス アーキテクチャの一部を紹介していますが、最も一般的なシナリオは網羅しています。

クラウド データプレーンを保護するためのアーキテクチャで説明されているセキュリティ アーキテクチャ パターンと同様に、実際のサービスではこれらの設計を組み合わせて使用する場合があります。以下のドキュメントでは、各ワークロードの種類と各セキュリティ アーキテクチャに関する考慮事項について説明しています。

次のステップ