コンテンツに移動
デベロッパー

安全なクラウド内アクセスのための 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/original_images/psc-w-vpc.max-2200x2200.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 点です。

  • コンシューマは指定された公開済みのサービスにしかアクセスできないため、プロデューサー側のポートや VM を公開しなくてよい。

  • コンシューマが独自のプライベート IP アドレスを選択できる。これはプロデューサーの IP とは別であるため、IP アドレスの重複の問題を回避できる。

詳細情報

その他のパターンについて詳しくは、ドキュメント「安全なクラウド内アクセスのためのネットワーク: リファレンス アーキテクチャ」をご確認ください。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/intra-doc_paQjTgF.gif

アーキテクチャの詳細

ネットワーキング アーキテクチャの詳細については、以下のドキュメントをご確認ください。

ご質問やご不明な点、ご意見は、私の Linkedin または Twitter(@ammettw)にご連絡ください。


- デベロッパー リレーションズ エンジニア Ammett Williams
投稿先