デベロッパー

安全なクラウド内アクセスのための 2 つのネットワーキングパターン - ネットワーキングアーキテクチャ

2023年1月19日

https://storage.googleapis.com/gweb-cloudblog-publish/images/networking_2022.max-2500x2500.jpg

Google Cloud Japan Team

※この投稿は米国時間 2023 年 1 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

以前の記事「クラウドネットワーキングの 6 つの構成要素」で、クラウドネットワーキングの要素をわかりやすく分類してご紹介しました。このモデルは、ネットワーク接続、ネットワークセキュリティ、サービスネットワーキング、サービスセキュリティ、コンテンツ配信、オブザーバビリティで構成されています。

今回の記事では、安全なクラウド内アクセスのための 2 つのシンプルなネットワーキングの手法について取り上げます。ドキュメント「安全なクラウド内アクセスのためのネットワーク: リファレンスアーキテクチャ」で、このトピックについて詳しく説明しています。今回の記事でご紹介する 2 つの手法を知っておくことで、このトピックに取り組みやすくなるでしょう。

安全なクラウド内アクセスの目的

クラウド内通信は、Virtual Private Cloud（VPC）内のさまざまなワークロードで、Google Cloud 内の他のリソースに接続する必要がある際に使われます。これらのリソースは複数の VPC にまたがっていることもあります。クラウド内通信の安全を確保することで、懸念事項を分離し、脆弱性を切り離し、安全な境界を確立できます。

安全な通信を実現するには、ネイティブツールまたはサードパーティの機能を利用します。組織がそれぞれのセキュリティコンプライアンスのニーズとワークロードの種類に応じて構成します。

パターン

ドキュメント「安全なクラウド内アクセスのためのネットワーク: リファレンスアーキテクチャ」ではいくつかのパターンが紹介されていますが、中でも興味深いのは以下の 2 つです。

ネットワーク仮想アプライアンス（NVA）
Private Service Connect（PSC）

どちらの設計にも VPC、ファイアウォールルール、適切な IAM 権限が必要です。それぞれについて詳しく見ていきましょう。

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

一元化された VM アプライアンスを用意して、トラフィックを経由させることが必要になる場合があります。その一般的なユースケースは、サードパーティの次世代ファイアウォール、IDS、WAF、NAT、透過型プロキシです。

以下の設計は、複数の NIC に接続された共有 VPC の NVA を示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/network-virtual-appliance.max-2200x2200.png

この設計の構成要素は以下のとおりです。

共有 VPC

共有 VPC は、ホストプロジェクトとサービスプロジェクトの形で設定されます。

VM アプライアンス - IP 転送が有効になった状態でホストプロジェクトに配置され、複数のネットワークインターフェースカード（nic0～nic4）があります。
サブネット - ホストの共有 VPC 内に構成済みのプライベート IP アドレス範囲を持つ複数のサブネットがあります。VM アプライアンスには、各サブネットに接続するための個別の NIC があります。

サービスプロジェクト

サービスプロジェクトは共有 VPC のサブネットに接続します。

サービスプロジェクトのリソース - サービスプロジェクト管理者が、アクセス権のあるサブネットに VM を作成します。
ネクストホップルーティング - ネクストホップルートを next-hop-instance 名または next-hop-address IP を使用して設定する必要があります。

パブリック接続

ホストプロジェクトは以下のように外部接続します。

VM アプライアンス - ネットワーク境界サブネットに接続された NIC があり、パブリック仮想 IP（VIP）も設定されています。

この設計により、VM アプライアンスの各 NIC に接続されたサービスプロジェクト VPC 間のトラフィックをフィルタ、検査できます。

Private Service Connect

Private Service Connect を使用すると、VPC の内部 IP のみを介して、Google、Google Cloud または外部ロケーションに存在するサービスに接続できます。いくつかのパターンがありますが、ここでは内部ロードバランサを介したコンシューマ接続とプロデューサー接続を取り上げます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/psc-w-vpc.max-2200x2200.max-1900x1900.png

プロデューサーネットワーク

プロデューサーネットワークの構成は以下のとおりです。

マネージドインスタンスグループ（MIG）- 10.101.0.0/16 のアドレス範囲を割り当てられたサブネット 202 のアプリケーション VM サーバーの自動スケーリングとプロビジョニングを行います。
内部ロードバランサ（ILB）- 1 つの内部 IP アドレスを介してサービスを公開します。接続先は MIG バックエンドです。ILB の場合、Envoy プロキシを実行するためのプロキシネットワークが必要です。
Private Service Connect、サービスアタッチメント - サービスをリージョンに公開します。サービスアドレスを持つユーザーすべてを選ぶか、特定のユーザーを選択することで、アクセスできるユーザーを制御できます。

コンシューマネットワーク

プロデューサーネットワークの構成は以下のとおりです。

クライアントはサブネット 101 に配置されます。この例ではクライアントは VM です。
Private Service Connect のエンドポイントはサブネット 102 に配置されます。内部 IP アドレス（10.100.7.9）が割り当てられているため、プロデューサーネットワークで作成され、アドバタイズされたサービスアタッチメントに接続できます。この接続が確立されると、PSC のエンドポイントに割り当てられたプライベート IP をポイントするだけで、クライアントはいつでもサービスにアクセスできます。
Service Directory - 図には示されていませんが、PSC のエンドポイントの設定時に Service Directory 名前空間が作成されます。名前を介してサービスを解決できるように、この名前空間を Cloud DNS のプライベートゾーンにリンクできます。

この設計によりインターネットへの公開が制限され、複雑な構成が不要になります。この主なメリットは以下の 2 点です。