Google Cloud プライベートクラウド ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
1. はじめに
1.1. 本レポートの目的と対象読者
本レポートは、Google Cloud Platform (GCP) 上で、従来のプライベートクラウドが持つ「独立性」「セキュリティ」「制御性」といった特性を高度に実現する環境を構築したいと考える、クラウドエンジニア、ソリューションアーキテクト、ITインフラストラクチャマネージャーを対象としています。
GCPの各種サービスとネットワーク機能を組み合わせることで、共有インフラストラクチャ上で論理的に隔離された、セキュアかつスケーラブルなプライベート環境を設計・実装するための実践的なガイドを提供します。
1.2. Google Cloudにおける「プライベートクラウド環境」の概念とメリット
従来の「プライベートクラウド」は、通常オンプレミスに設置され、単一組織が専用で構築・運用する環境を指します。これにより、高度な制御、カスタマイズ、データセキュリティが実現される一方、従来のIT環境と同様の費用とリソース制約が伴います 。これに対し、「パブリッククラウド」は、Google Cloudのようにサードパーティのプロバイダが所有・運用するマルチテナント環境で、リソースやサービスが多数の顧客間で共有されます 。
Google Cloudにおける「プライベートクラウド環境」の構築とは、物理的なオンプレミス環境を指すのではなく、パブリッククラウドの共有インフラストラクチャ上に、Virtual Private Cloud (VPC) などの機能を活用し、あたかも専用環境であるかのように論理的に隔離され、高度なセキュリティと制御を可能にするアーキテクチャを指します 。このアプローチは、従来のプライベートクラウドが提供するデータプライバシー、セキュリティ、カスタマイズの高度な制御といった利点を維持しつつ、パブリッククラウドがもたらす柔軟性、スケーラビリティ、そしてマネージドサービスの恩恵を享受できる点で優れています 。特に、物理インフラのキャパシティ制約から解放され、運用管理の負担を軽減できる可能性が高まります。
Google Cloud上で「プライベートクラウド的」な環境を構築する際、その本質は物理的な所有から論理的な制御とマネージドサービスの活用へと移行します。これは、従来のプライベートITに内在する物理インフラの管理やキャパシティの制約といった負担を取り除きながら、制御とセキュリティという重要な利点を享受できることを意味します。この文脈での「カスタマイズ」は、物理的なハードウェアレベルから、ソフトウェア定義のネットワーキングやマネージドサービスの構成レベルへとシフトします。利用者は、Googleが提供する堅牢なインフラストラクチャ上で、自社の要件に合わせた柔軟なネットワーク設計とリソース配置が可能となり、これにより、従来のオンプレミス環境では困難であった迅速な拡張性や高可用性を実現できます。
参考記事:
- クラウド コンピューティングの種類とは https://cloud.google.com/discover/types-of-cloud-computing?hl=ja
- プライベート クラウドとは https://cloud.google.com/discover/what-is-a-private-cloud?hl=ja
Google Cloud プライベートクラウド環境 ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
2. ネットワーク基盤の設計と構築
2.1. Virtual Private Cloud (VPC) ネットワークの基本
VPCネットワークは、Google Cloudにおけるクラウドベースのリソースとサービスに対して、グローバルでスケーラブルかつ柔軟なネットワーク機能を提供します 。VPCネットワークは、物理ネットワークと同様に機能しますが、Google Cloud内で仮想化されています。
2.1.1. VPCネットワークのグローバル性とリージョンサブネット
VPCネットワークはグローバルなリソースであり、データセンター内のリージョンレベルの仮想サブネット群で構成され、これらはグローバルな広域ネットワーク(WAN)を介して接続されています 。各VPCネットワークはGoogle Cloud内で論理的に相互に隔離されており、これにより他の組織のワークロードから自身の環境を分離できます 。
サブネットはリージョン固有のオブジェクトであり、リソースを配置するリージョンによって利用可能なサブネットが決まります 。Compute EngineのVMインスタンスやGoogle Kubernetes Engine (GKE) のクラスタは、VPCネットワークがなければ作成できません 。VMインスタンスを作成する際には、インスタンスのゾーンを選択し、そのゾーンの親リージョンにサブネットを含むネットワークを選択する必要があります 。
2.1.2. IPアドレス計画のベストプラクティスと枯渇対策
IPアドレス計画は、プライベートクラウド環境の基盤となる重要な要素です。各サブネットにはプライマリIPv4範囲を定義し、必要に応じてセカンダリIP範囲を作成することで、単一のVMインスタンス上で複数のサービスに異なる内部IPアドレスを割り当てることが可能です(エイリアスIP範囲) 。これにより、IPアドレスの効率的な利用と、ネットワーク設計の柔軟性が向上します。
IPアドレス枯渇への対策として、以下の点が推奨されます。まず、将来的な拡張を見越して、RFC 1918アドレス以外のIP範囲や、より大きなCIDRブロック(例: /16)を事前に確保することが重要です 。また、IPv4アドレスの枯渇問題を軽減するために、IPv4とIPv6の両方をサポートするデュアルスタックサブネットの利用を検討すべきです 。GKEクラスタの場合、ノードにはサブネットのプライマリIP範囲、PodとServiceには異なるセカンダリIP範囲を使用するため、これらのIPアドレス範囲の重複を避け、慎重な計画が必要です 。特に、VPCネイティブクラスタはエイリアスIPアドレス範囲を使用し、IPアドレスの枯渇リスクを低減し、ルーティング上限に達する可能性を低くするため推奨されます 。
以下の表は、IPアドレス計画の推奨事項と枯渇対策をまとめたものです。
項目 | 推奨事項 | 枯渇対策 |
---|---|---|
IPアドレス範囲の選定 | 将来の拡張を考慮し、十分なサイズのCIDRブロック(例: /16)を確保する 。 | RFC 1918アドレス以外のIP範囲の利用を検討する 。 |
サブネットの構成 | 各リージョンに適切なサブネットを配置し、プライマリIP範囲を定義する 。 | 複数のサービスに異なる内部IPアドレスを割り当てるエイリアスIP範囲を活用する 。 |
IPv6の活用 | IPv4とIPv6の両方に対応するデュアルスタックサブネットの利用を検討する | IPv4の枯渇リスクを軽減し、将来的なネットワーク要件に対応する 。 |
GKEクラスタ | ノード、Pod、Serviceにそれぞれ固有のIPアドレス範囲を割り当て、重複を避ける 。 | VPCネイティブクラスタの利用を推奨し、エイリアスIPによるIPアドレス管理を効率化する 。 |
重複の回避 | オンプレミスや他のクラウド環境との接続を考慮し、IPアドレス範囲の重複を厳格に回避する 。 | ネットワーク全体のIPアドレス設計を簡素化し、ルーティング問題を未然に防ぐ 。 |
モニタリング | IPアドレスの使用状況を継続的にモニタリングし、早期に枯渇の兆候を検出する 。 | 必要に応じてIPアドレス範囲の拡張や再設計を計画する 。 |
RFC 1918で定義されているプライベートIPアドレス範囲:
- クラスA: 10.0.0.0 から 10.255.255.255 (10.0.0.0/8)
- クラスB: 172.16.0.0 から 172.31.255.255 (172.16.0.0/12)
- クラスC: 192.168.0.0 から 192.168.255.255 (192.168.0.0/16)
特殊な用途のアドレス範囲:
- RFC 6598: 共有アドレス空間
(100.64.0.0/10)
キャリアグレードNAT (CGN) 予約 - RFC 5737: ドキュメント用
(192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) - RFC 2544: ベンチマークテスト用
(198.18.0.0/15) - ループバックアドレス
(127.0.0.0/8) - リンクローカルアドレス
(169.254.0.0/16) - マルチキャストアドレス
(224.0.0.0/4)
Google CloudにおけるRFC 1918以外のアドレス帯の利用について
Google CloudのVPC(Virtual Private Cloud)ネットワークでは、原則としてRFC 1918で定義されたプライベートIPアドレス範囲をサブネットに割り当てて利用します。しかし、特定のシナリオやサービスにおいては、RFC 1918以外のアドレス帯も利用可能です。
プライベートで使用されるパブリックIP (PUPI: Privately Used Public IP) 範囲:
Google Kubernetes Engine (GKE) などで大量のIPアドレスが必要な場合に、特定のパブリックIPアドレス範囲をプライベートネットワーク内で利用できるようにする機能です。これらのアドレスは、VPC内部でのみ使用され、インターネットにルーティングされることはありません。
Filestoreなどの一部サービス:
RFC 1918以外のクライアントからの接続をサポートする場合があります。
注意点:
RFC 1918以外のアドレス帯をプライベートネットワーク内で使用する際には、意図しないルーティングの競合やセキュリティ上の問題が発生する可能性があるため、十分な理解と注意が必要です。特に、インターネット上のパブリックIPアドレスと重複する範囲をプライベートで利用すると、通信障害の原因となることがあります。
通常、企業や家庭内ネットワークを構築する際には、RFC 1918のプライベートIPアドレス範囲を使用することが推奨されます。
2.1.3. ルーティングと転送ルール
VPCネットワークにおけるルーティングは、VMインスタンスやVPCネットワークが、内部またはGoogle Cloud外部の目的地へトラフィックをどのように送信するかを指示します 。各VPCネットワークには、サブネット間のトラフィックルーティングや、インターネットへのトラフィック送信のためのシステム生成ルートがデフォルトで含まれています 。特定の宛先へトラフィックを誘導するために、カスタム静的ルートを作成することも可能です 。
一方、転送ルールは、IPアドレス、プロトコル、ポートに基づいて、VPCネットワーク内のGoogle Cloudリソース(ターゲットインスタンス、ロードバランサーのターゲット、従来のVPNゲートウェイなど)にトラフィックを誘導します 。これにより、外部からのトラフィックをネットワーク内の特定の目的地へ、またはネットワーク内部からのトラフィックを特定の内部リソースへ、細かく制御できます。
2.2. ファイアウォールルールの設定とセキュリティゾーン設計
ファイアウォールルールは、VPCネットワークのセキュリティを確保するための不可欠な要素です。各VPCネットワークには分散型仮想ファイアウォールが実装されており、これを設定することで、どのパケットをどの目的地に送信できるかを制御できます 。
2.2.1. ファイアウォールルールの基本、優先度、コンポーネント
すべてのVPCネットワークには、デフォルトで2つの暗黙的なファイアウォールルールが存在します。これらはすべての受信接続を拒否し、すべての送信接続を許可します 。カスタムファイアウォールルールを作成する際には、以下の主要なコンポーネントを設定します 。
- 名前: プロジェクト内で一意の名前。
- ネットワーク: ルールを適用するVPCネットワーク。
- 優先度: 0から65535までの整数で、小さいほど優先度が高い(デフォルトは1000) 。複数のルールが競合する場合、優先度の高いルールが適用されます。
- トラフィックの方向: 受信(内向き)または送信(外向き)のいずれかを選択します 。
- 一致したときのアクション: トラフィックを「許可」するか「拒否」するかを決定します 。
- ターゲット: ルールを適用するインスタンスを指定します。ネットワーク内のすべてのインスタンス、特定のターゲットタグを持つインスタンス、または特定のサービスアカウントに関連付けられたインスタンスを選択できます 。
- 送信元/宛先: ルールの方向に応じて、パケットの送信元または宛先となるIPアドレス範囲(IPv4またはIPv6のCIDR表記)を指定します 。
以下の表は、ファイアウォールルールの主要コンポーネントと設定例をまとめたものです。
コンポーネント | 説明 | 設定例 |
---|---|---|
名前 | プロジェクト内で一意のルール名。 | allow-ssh-from-internal |
ネットワーク | ルールを適用するVPCネットワーク。 | my-private-vpc |
優先度 | ルールの適用順序(小さいほど高優先度)。 | 100 (デフォルトは 1000 ) |
トラフィックの方向 | 上り(内向き) または 下り(外向き) 。 | 上り(内向き) |
一致したときのアクション | トラフィックを 許可 または 拒否 。 | 許可 |
ターゲット | ルールを適用するVMインスタンス。 | 指定されたターゲットタグ (web-server ) |
送信元/宛先フィルタ | トラフィックの送信元または宛先のIPアドレス範囲。 | 送信元IPアドレス範囲: 10.0.0.0/8 |
プロトコルとポート | 許可または拒否するプロトコルとポート。 | tcp:22 |
2.2.2. 最小権限の原則とベストプラクティス
ファイアウォールルールを設計する上での最も重要な原則は、最小権限の原則を実装することです。これは、デフォルトですべてのトラフィックをブロックし、必要な特定のトラフィックのみを許可することを意味します 。また、ルールを必要なプロトコルとポートのみに制限することで、攻撃対象領域を最小化できます 。
特定のVMインスタンスにルールを制限するためには、VMのサービスアカウントを指定するか、ターゲットタグを使用することが推奨されます 。IPアドレスに基づいてルールを作成する必要がある場合は、管理の複雑さを軽減するためにルール数を最小限に抑えるべきです 。ファイアウォールルールロギングを有効にすることで、ルールが意図したとおりに使用されているかを確認し、潜在的な問題を診断できます 。
2.2.3. ネットワークセグメンテーションと多層防御の実現
ネットワークセグメンテーションは、ネットワークを業務要件やセキュリティ要件に応じて複数のセグメントまたはサブネットに分割し、それぞれを小さなネットワークとして機能させる設計方法を指します 。VPCネットワークは、論理的な分離によって強固なセキュリティを実現し、IPアドレス範囲の定義やサブネットの作成を通じて高い柔軟性を提供します 。
このアプローチは、アプリケーションやサービス間の通信を規制・管理し、きめ細かいセキュリティポリシーでラテラルムーブメント(横方向の移動)を封じ込めるマイクロセグメンテーションを可能にします 。これにより、攻撃者がネットワークに侵入した場合でも、トラフィックを正確に制御しやすくなります 。例えば、Webアプリケーションのフロントエンド、バックエンド、データベースを別々のサブネットに配置し、それぞれに適切なアクセス制御を設定することで、多層的な防御を実現できます 。Google Cloudのセキュリティ戦略は、多層防御とゼロトラスト原則に基づいており、Identity and Access Management (IAM)、データ損失防止、ワークロードセキュリティ、脅威検出と対応など、複数のレイヤーで保護を強化します 。

ファイアウォールルール例:最小権限の原則
名前: allow-web-to-db
- 優先度: 100
- 方向: 下り(外向き)
- アクション: 許可
- ターゲット: サービスアカウント web-sa
- 宛先IP範囲: 10.20.1.0/24
- プロトコルとポート: tcp:3306 (MySQL)
→ 意図: web-server-01からdb-server-01へのDB通信のみを許可
名前: deny-all-ingress (暗黙的な拒否ルールはデフォルトで存在)
- 優先度: 65535 (最低)
- 方向: 上り(内向き)
- アクション: 拒否
- ターゲット: すべてのインスタンス
- 送信元IP範囲: 0.0.0.0/0
- プロトコルとポート: すべて
→ 意図: 外部からの不要な通信をブロック
参考記事:
- Virtual Private Cloud (VPC) overview https://cloud.google.com/vpc/docs/overview
- Google Cloud Skills Boost https://www.cloudskillsboost.google/?locale=ja
- サブネット https://cloud.google.com/vpc/docs/subnets?hl=ja
- VPC ネットワークの作成と管理 https://cloud.google.com/vpc/docs/create-modify-vpc-networks?hl=ja
- Amazon VPCのIPv4アドレス範囲を決める際のベストプラクティス https://business.ntt-east.co.jp/content/cloudsolution/ih_column-185.html
- GKE にプライベートで使用されるパブリック IP アドレスを構成する https://cloud.google.com/kubernetes-engine/docs/how-to/configuring-privately-used-public-ips-for-gke?hl=ja
- VPC ファイアウォール ルール https://cloud.google.com/firewall/docs/using-firewalls?hl=ja
Google Cloud プライベートクラウド環境 ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
3. プライベート接続オプション
Google Cloudでプライベートクラウド環境を構築する際、オンプレミス環境や他のクラウドサービス、さらにはGoogleのマネージドサービスとのセキュアなプライベート接続は不可欠です。
3.1. オンプレミス/他クラウド環境とのセキュアな接続
3.1.1. Cloud VPN (高可用性HA VPN)
Cloud VPNは、IPsec VPN接続を介して、オンプレミスネットワークまたは他のピアネットワークをVPCネットワークに安全に拡張するサービスです 。これにより、ネットワーク間で転送されるトラフィックが暗号化され、データの安全性が確保されます 。
特に高可用性HA VPNは、単一リージョン内で99.99%のサービス可用性SLAを提供し、ミッションクリティカルなアプリケーションに適しています 。HA VPNゲートウェイは2つのインターフェースを持ち、それぞれに独自のパブリックIPアドレスが自動的に割り当てられます 。高可用性を実現するためには、両方のHA VPNゲートウェイインターフェースでVPNトンネルを構成し、動的ルーティング(BGP)を使用する必要があります 。Cloud VPNはサイト間IPsec VPN接続のみをサポートし、クライアントからゲートウェイへの接続シナリオはサポートしていません 。
3.1.2. Cloud Interconnect (Dedicated, Partner, Cross-Cloud)
Cloud Interconnectは、オンプレミスネットワークとGoogleネットワーク間の直接的な物理接続を提供することで、パブリックインターネットを経由しないセキュアで高性能な接続を実現します 。これにより、トラフィックの喪失や中断のリスクが低減され、レイテンシが改善されます 。
- Dedicated Interconnect: ユーザーのオンプレミスネットワークとGoogle VPCネットワークの間に専用の物理接続を確立します。10Gbpsまたは100Gbpsのイーサネット接続をサポートし、大容量のデータ転送に適しています 。
- Partner Interconnect: サポートされているサービスプロバイダを介してオンプレミスネットワークとVPCネットワークを接続します。データセンターがDedicated Interconnectの接続拠点に物理的に接続できない場合や、10Gbps未満の接続が必要な場合に有用です。50Mbpsから50GbpsまでのVLAN接続をサポートします 。
- Cross-Cloud Interconnect: 他のクラウドプロバイダのネットワークとGoogleネットワークの間に直接物理接続を提供し、クラウド間での大量データの低レイテンシ転送を可能にします 。
Cloud Interconnectは、冗長構成により99.9%または99.99%のSLAを提供します 。例えば、99.99%の可用性を実現するには、少なくとも2つの都市圏にわたる4つ以上のVLANアタッチメントと、異なるリージョンに配置された2つのCloud Routerが必要となります 。Google CloudはECMP(Equal-Cost Multi-Path)を使用して、冗長接続間で送信トラフィックを均等に分散します 。
以下の表は、Cloud InterconnectとCloud VPNのSLAと冗長構成の比較をまとめたものです。
接続タイプ | 提供帯域 | Google Cloudへの接続方法 | SLA | 冗長構成の推奨事項 | 冗長構成の推奨事項 |
---|---|---|---|---|---|
Cloud VPN | 最大3Gbps | パブリックインターネット上のIPsec VPN接続 | 99.9% または 99.99% (条件付き) | HA VPNゲートウェイの2つのインターフェースを、それぞれ異なるIPアドレスを持つピアゲートウェイに接続し、BGPによる動的ルーティングを構成 。 | |
Dedicated Interconnect | 10Gbps または 100Gbps | Googleロケーションでの光ファイバーケーブルによる直接接続 | 99.9% または 99.99% | 99.9%:少なくとも1つの都市圏で2本以上のInterconnect回線を異なるエッジアベイラビリティドメインに接続 。 | 99.99%:2つ以上の異なるGoogle Cloudリージョンに少なくとも2つのCloud Routerを配置し、冗長な接続を構成 。 |
Partner Interconnect | 50Mbps~50Gbps | Googleパートナーのプロバイダを経由した接続 | Googleとプロバイダー間で99.9% または 99.99% | 99.9%:1つの都市圏でサービスプロバイダー経由で2つのエッジアベイラビリティドメインに接続 | 99.99%:2つの都市圏でサービスプロバイダー経由でそれぞれの2つのエッジアベイラビリティドメインに接続し、異なるリージョンにCloud Routerを配置、VPCネットワークでグローバルルーティングを有効化 。 |
Cross-Cloud Interconnect | 10Gbps または 100Gbps | 他のクラウドのネットワークとGoogleネットワーク間の直接物理接続 | SLAの言及なし (物理接続の可用性は高い) | 冗長構成はDedicated Interconnectと同様の考慮が必要 。 |
3.2. Google Cloudサービスへのプライベートアクセス
Google CloudのマネージドサービスやAPIに、VPCネットワークからプライベートにアクセスするための複数のオプションが存在します。
3.2.1. 限定公開のGoogleアクセス (Private Google Access: PGA)
限定公開のGoogleアクセスは、外部IPアドレスを持たないVMインスタンスが、インターネットを経由せずにGoogle APIとサービス(例: Cloud Storage、BigQuery、Cloud Logging)の外部IPアドレスにアクセスできるようにする機能です 。通常、外部IPを持たないVMはインターネットアクセスができませんが、PGAを有効にすることで、Googleの内部ネットワークを経由して安全にGoogleサービスのエンドポイントへアクセスできるようになります 。この機能はサブネット単位で設定され、セキュリティの向上が期待できます 。
3.2.2. プライベートサービスアクセス (Private Service Access: PSA)
プライベートサービスアクセスは、VPCネットワークとGoogleがホストするマネージドサービス(例: Cloud SQL、Memorystore、Filestore)のVPCネットワークとの間に、VPCネットワークピアリング接続を確立することで、プライベートな接続を可能にする機能です 。この接続は、サービスプロデューサーのネットワークがユーザー専用に作成されるため、他の顧客と共有されません 。PSAを利用するためには、サービスプロデューサーのVPCネットワークで使用されるIPアドレス範囲を事前に割り振る必要があります 。これにより、IPアドレスの衝突を防ぎ、インターネットを介さずにサービスにアクセスできるため、セキュリティとネットワークパフォーマンスが向上します 。ただし、PSAはIPv6アドレス範囲の使用をサポートしていません 。
3.2.3. Private Service Connect (PSC)
Private Service Connectは、Google API、他のVPCでホストされている公開サービス、およびSaaSサービスに対して、より柔軟なプライベート接続オプションを提供します 。PSCを使用すると、内部IPアドレスを持つVMからGoogle APIにアクセスしたり、特定のIPアドレスとリージョンにローカルトラフィックを誘導したり、サポートされているロードバランサーを通じてGoogle APIトラフィックを集中させ、独自の証明書、セキュリティポリシー、可観測性を適用したりすることができます 。PSCはVPCピアリングを必要とせず、エンドポイントとサービスアタッチメントを通じてサービス中心のプライベート接続を実現します 。これにより、機密性の高いAPIやカスタムIPアドレス指定が必要なシナリオに最適であり、セキュリティ、スケーラビリティ、柔軟性を兼ね備えたサービス公開が可能です 。

3.2.4. 各プライベート接続オプションの比較と選択基準
Google Cloudには、VPCネットワークからGoogle APIやマネージドサービスにアクセスするための複数のプライベート接続オプションが存在し、それぞれ異なるユースケースと特性を持っています。
以下の表は、限定公開のGoogleアクセス(PGA)、プライベートサービスアクセス(PSA)、Private Service Connect(PSC)の主要な違いを比較したものです。
特徴 | 限定公開のGoogleアクセス (PGA) | プライベートサービスアクセス (PSA) | Private Service Connect (PSC) |
主な接続対象 | Google API / サービス (公開エンドポイント) | Google 管理のサービス (Cloud SQL, Memorystore, Filestoreなど) | Google API / 他VPCサービス / SaaS |
接続性 | Google 内部ルーティング | VPC ネットワークピアリング | エンドポイント & サービスアタッチメント |
接続先IPアドレス | Google 公開IP (内部ルーティング経由) | 専用プライベートIP (ピアリング経由) | PSCエンドポイントIP (内部IP) |
IPアドレス管理 | 不要 | IP範囲の予約が必要 | エンドポイントのIP確保 (重複に注意) |
VPCピアリングの要否 | 不要 | 必要 | 不要 |
IPv6サポート | サポート | 未サポート | サポート (エンドポイント経由のGoogle APIアクセス) |
ユースケース例 | 外部IPなしのVMからCloud Storageへのアクセス | VMからCloud SQLへのアクセス | VMからサービス/Google APIへの限定アクセス、サードパーティサービスへの接続 |
選択基準としては、接続したいサービスのタイプ、IPアドレス管理の複雑さ、VPCピアリングの有無、および特定のセキュリティ要件によって最適なオプションが異なります。Google APIへのシンプルなプライベートアクセスにはPGAが適しており、Googleマネージドサービスへのプライベート接続にはPSAが一般的です。より柔軟なサービス間接続やサードパーティサービスへのアクセス、またはきめ細かいIPアドレス制御が必要な場合にはPSCが強力な選択肢となります。

図の構成:
- 左右の分離: 左側にオンプレミス環境、右側にGoogle Cloud Platformを配置し、異なる環境を明確に区別しています。
- 主要な接続コンポーネント: オンプレミスのルータ/VPN GW、Google Cloud側のCloud VPN Gateway (HA VPN) やVLAN Attachment、Cloud Routerをシンプルなボックスで表現しています。
- 接続の種類: VPNトンネルと専用線/パートナー接続の2種類の接続パスを明示し、それぞれの特徴を簡潔なラベルで示しました。
- VPCの表現: Google Cloud内にVPCネットワークを包含する形で示し、その中にサブネットやCloud Routerが存在することを表現しています。
Google Cloud プライベートクラウド環境 ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
4. プライベート環境で利用可能な主要リソースと構成
Google Cloud上でプライベートクラウド環境を構築する際、VPCネットワーク内で様々なGoogle Cloudリソースをセキュアにデプロイし、利用することが可能です。
4.1. Compute Engine (VMインスタンス)
Compute Engineは、Googleのインフラストラクチャ上で仮想マシン(VM)インスタンスを実行できるサービスです。プライベートクラウド環境では、これらのVMに外部IPアドレスを付与せず、内部IPアドレスのみで運用することがセキュリティのベストプラクティスとされます 。
4.1.1. 外部IPアドレスを持たないVMの作成とアクセス方法 (Identity-Aware Proxy: IAPの活用)
外部IPアドレスを持たないVMインスタンスは、インターネットからの直接的な攻撃対象領域を大幅に縮小します 。このようなVMへのアクセスは、通常、Cloud VPNやCloud Interconnectを介したオンプレミスネットワークからの接続、またはCloud Load Balancingの利用によって可能になります 。
しかし、運用管理の観点からは、Identity-Aware Proxy (IAP) のTCP転送機能が非常に有用です 。IAPは、VMに外部IPアドレスがなくても、SSHやRDPなどの対話型サービスへのアクセスを保護します 。これにより、インターネットにVMを公開することなく、セキュアなリモートアクセスを実現できます。IAPは、OAuth同意画面の構成やOAuth認証情報の作成、IAPアクセス権の設定といった手順を経て有効化されます 。
また、外部IPを持たないVMがインターネットへのアウトバウンド接続を必要とする場合は、Cloud NATサービスを利用できます 。Cloud NATは、VMの内部IPアドレスをパブリックIPアドレスに変換し、インターネットへの送信接続を可能にしますが、外部からの受信接続は許可しません。

4.1.2. 静的内部IPアドレスの割り当て
VMインスタンスに割り当てられる内部IPアドレスは、デフォルトでは一時的なもの(エフェメラル)ですが、静的内部IPアドレスを予約することで、VMの削除・再作成後も同じIPアドレスを継続して使用できます 。これは、アプリケーションの構成やDNSレコードの一貫性を保つ上で非常に重要です。静的内部IPアドレスは、IPv4またはIPv6で予約可能であり、サブネットのIP範囲から手動で指定することも、システムに自動割り当てさせることもできます 。
4.2. Google Kubernetes Engine (GKE)
GKEは、コンテナ化されたアプリケーションをデプロイ、管理、スケーリングするためのマネージドサービスです。プライベートクラウド環境では、GKEの限定公開クラスタを利用することで、ノードとPodをインターネットから隔離し、セキュリティを強化できます。
4.2.1. 限定公開クラスタの構成とコントロールプレーンアクセス制御
限定公開クラスタは、ノードが内部IPアドレスのみを持つVPCネイティブクラスタの一種であり、デフォルトでノードとPodがインターネットから隔離されます 。これにより、攻撃対象領域が大幅に減少します 。
コントロールプレーン(Kubernetesマスター)へのクライアントアクセスは、以下の3つの方法で制御できます 。
- パブリックエンドポイントへのクライアントアクセス権のない限定公開クラスタ: クラスタノードは限定公開され、コントロールプレーンのパブリックエンドポイントへのクライアントアクセスは無効になります。GKEはクラスタ管理目的でコントロールプレーンのパブリックエンドポイントにアクセスできます 。
- パブリックエンドポイントへのアクセスが制限された限定公開クラスタ: パブリックエンドポイントへのアクセスを、承認されたIPアドレス範囲に制限します。これにより、特定のネットワーク(例: オンプレミスネットワーク、管理用VPC)からのみコントロールプレーンにアクセス可能となります 。
- パブリックエンドポイントへ無制限にアクセス可能な限定公開クラスタ: 任意のIPアドレスでコントロールプレーンにアクセスできますが、セキュリティ要件に応じて承認済みネットワークを設定しない場合、セキュリティリスクが高まります 。
限定公開クラスタを作成すると、共有VPCを使用している場合を除き、限定公開のGoogleアクセスが自動的に有効になります 。これにより、ノードがGoogle APIやサービスにアクセスできるようになります。
4.2.2. Pod/Service IPアドレス範囲の設計
GKEのVPCネイティブクラスタでは、IPアドレスの割り当てにエイリアスIPアドレス範囲を使用します 。具体的には、ワーカーノードのIPアドレスにはサブネットのプライマリIP範囲を使用し、PodのIPアドレスとServiceのCluster IPアドレスには、同じサブネットの異なるセカンダリIP範囲を使用します 。この設計により、IPアドレスの枯渇を防ぎ、ルーティングの複雑さを軽減できます 。
4.3. サーバレスサービス (Cloud Functions, Cloud Run)
Cloud FunctionsやCloud Runといったサーバレスサービスは、通常、VPCネットワークの外部で動作しますが、Serverless VPC Access Connectorを利用することで、VPC内部のリソース(例: Compute EngineのVM、Cloud SQLデータベース)にプライベートにアクセスできるようになります 。
4.3.1. Serverless VPC Access Connectorの利用
Serverless VPC Access Connectorは、サーバレス環境とVPCネットワーク間のブリッジとして機能します 。コネクタを経由することで、サーバレスサービスからのトラフィックがVPCネットワーク内にルーティングされ、内部IPアドレスを使用してVPC内のリソースと通信できます 。
コネクタを作成する際には、VPCネットワーク内に専用の/28
サブネットが必要となります 。このサブネットは、VMやロードバランサーなどの他のリソースでは使用できません 。コネクタは、トラフィック量に応じてインスタンス数を自動的にスケールアップしますが、トラフィックが減少してもスケールダウンしない点に留意が必要です 。コネクタのファイアウォールルールを設定することで、コネクタVMがVPCネットワークリソースにアクセスできる範囲を制限することも可能です 。
4.4. マネージドデータベース/ストレージサービス (Cloud SQL, Cloud Storage, Filestore, Cloud Spanner)
Google Cloudの多くのマネージドサービスは、プライベートIP接続をサポートしており、これによりVPCネットワーク内のリソースからインターネットを経由せずにアクセスできます。
4.4.1. プライベートIP接続の構成と利用例
- Cloud SQL: フルマネージドのリレーショナルデータベースサービスであるCloud SQLは、プライベートIP接続をサポートしています 。VPCネットワークとCloud SQLインスタンスの間にプライベート接続(Private Service AccessのVPCネットワークピアリング)を確立することで、VPC内のVMインスタンスから内部IPアドレスを使用してデータベースにアクセスできます 。これにより、データベースがパブリックIPアドレスを持たなくなり、セキュリティが強化されます 。オンプレミスからのアクセスが必要な場合は、VPNトンネルやCloud Interconnectを介してVPCネットワークに接続することで、プライベートアクセスが可能です 。
- Cloud Storage: オブジェクトストレージサービスであるCloud Storageは、限定公開のGoogleアクセス(PGA)を有効にすることで、外部IPアドレスを持たないVMインスタンスからプライベートにアクセスできます 。これにより、インターネットにデータを公開することなく、ストレージサービスを利用できます。
- Filestore: フルマネージドのNFSファイルストレージサービスであるFilestoreは、VPCネットワークピアリングおよびプライベートサービスアクセスを介して接続できます 。これにより、VPC内のCompute Engine VMやGKEクラスタから高性能なファイルストレージにプライベートにアクセスし、機械学習ワークロードなどのパフォーマンスを向上させることができます 。
- Cloud Spanner: グローバル分散型リレーショナルデータベースであるCloud Spannerも、プライベート接続オプションを介してアクセス可能です 。Private Service Connect (PSC) を利用することで、内部IPアドレスを持つVMからSpannerを含むGoogle APIやサービスにアクセスし、トラフィックの集中化やセキュリティポリシーの適用が可能になります 。
これらのサービスへのプライベート接続は、データがGoogle Cloudの内部ネットワーク内に留まることを保証し、データプライバシーとセキュリティを向上させます。
Google Cloud プライベートクラウド環境 ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
5. セキュリティと運用管理
プライベートクラウド環境の構築において、ネットワーク設定とリソースの配置だけでなく、包括的なセキュリティ対策と効率的な運用管理体制を確立することが不可欠です。
5.1. VPC Service Controlsによるデータ漏洩対策
VPC Service Controlsは、Google Cloudリソース、機密データ、ネットワークの周囲に隔離の境界(サービス境界)を作成することで、データ漏洩のリスクを軽減するサービスです 。サービス境界は、承認されたネットワーク以外からの機密データへのアクセスを制限し、リソースへのアクセスを許可されたIPアドレス、ID、信頼できるクライアントデバイスからのみに制限します 。
5.1.1. サービス境界の作成、アクセスレベル、入出ルール
サービス境界を構成すると、境界内部のリソース間では自由に通信できますが、デフォルトでは境界外部からのGoogle Cloudサービスへの通信はすべてブロックされます 。これにより、Cloud StorageバケットやBigQueryデータセットなどのデータがVPC内部に制限され、データの流出が防止されます 。
境界外からの保護されたリソースへのアクセスを制御するために、アクセスレベルと入出(Ingress/Egress)ルールを使用します 。
- アクセスレベル: IPアドレスやユーザーIDなどの様々な基準に基づいて、リクエストが処理されるために満たす必要がある条件を定義します 。サービス境界に複数のアクセスレベルを追加した場合、いずれかの条件を満たすリクエストが許可されます 。
- 入出ルール: 境界外のAPIクライアントから境界内のリソースへのアクセス(入)や、境界内のAPIクライアントまたはリソースから境界外のリソースへのアクセス(出)を許可するために使用されます 。これにより、特定のプロジェクト、アクセスレベル、VPCネットワークからのアクセスを許可したり、特定のサービスへのアクセスを制限したりする、きめ細やかな制御が可能です 。
5.1.2. 共有VPCとの連携
VPC Service Controlsは、共有VPC環境と連携して利用できます 。共有VPCネットワークに属するプロジェクトを含むサービス境界を作成する場合、そのネットワークをホストするプロジェクトも同じ境界に含まれている必要があります 。これにより、組織全体で共通のネットワークリソース(サブネット、ルート、ファイアウォール)に対する集中管理を維持しつつ、サービスプロジェクト管理者にインスタンスの作成と管理などの責任を委任できます 。これは、大規模な組織において、ネットワーク管理とサービス開発の責任を分離しながら、一貫したセキュリティポリシーを適用する上で特に有効です 。

図の構成:
- 境界の表現:囲み線で「サービス境界」を表現し、その内側に保護されたリソースを配置しています。
- アクセス制御: 境界の内と外からのアクセスがどのように制御されるか(Ingress/Egress Rule)を矢印とラベルで示しました。
- 拒否の強調: 「アクセス拒否 (デフォルト) X」という表現で、境界外からの不正なアクセスがブロックされることを強調しています。
- ミニマルなリソース: Cloud Storage、BigQuery、Compute Engineなど、データ保護の対象となる代表的なサービスを例として挙げています。
5.2. Identity and Access Management (IAM) の強化
Identity and Access Management (IAM) は、Google Cloudリソースへのアクセス制御を一元管理するための仕組みであり 、プライベートクラウド環境のセキュリティ基盤を形成します。
5.2.1. 組織ポリシーと条件付きIAMの適用
組織ポリシーは、組織レベルやフォルダレベルでリソースの使用方法に一律の制約を課す機能です 。これを使用することで、ドメインに基づいたリソース共有の制限、IAMサービスアカウントの使用制限、新しく作成されるリソースの物理的なロケーション制限などを実現できます 。これにより、組織全体のセキュリティとコンプライアンスを強化し、統制を効かせやすくなります 。
条件付きIAMは、IAM許可ポリシーにおいて、特定の条件が満たされた場合にのみプリンシパルにアクセス権を付与する機能です 。例えば、特定のIPアドレス(企業のネットワークなど)からのアクセスに限定して権限を与えることや、一時的なアクセス権を付与することが可能です 。条件は、リクエストのタイムスタンプ、リソースのタイプや名前、使用されているGoogle Cloudサービス、リソースにアタッチされたタグなど、様々な属性に基づいて定義できます 。これにより、よりきめ細かく、コンテキストに応じたアクセス制御を実現し、セキュリティを強化できます。
5.2.2. カスタムロールとサービスアカウントのベストプラクティス
Google Cloudでは、事前定義されたロールに加えて、特定の要件に合わせて権限を細かく定義できるカスタムロールを作成できます 。これにより、最小権限の原則を厳格に適用し、不要な権限の付与を防ぐことが可能になります。
サービスアカウントは、VMインスタンスやアプリケーションがGoogle Cloud APIにアクセスする際に使用する特別なアカウントです。サービスアカウントを安全に運用するためのベストプラクティスには、以下の点が挙げられます 。
- 単一目的のサービスアカウントを作成する: 各サービスアカウントに特定のタスクに必要な最小限の権限のみを付与し、その目的を明確にします。
- デフォルトのサービスアカウントへの自動的なロール付与を使用しない: デフォルトで付与される広範な権限は、本番環境のワークロードにはリスクが高いため、無効化し、必要な権限を明示的に付与します。
- サービスアカウントキーの作成を制限する: サービスアカウントキーは有効期限が長く、漏洩のリスクが高いため、他に有効な方法がない場合にのみ使用し、キーの作成を組織ポリシーで制限することを検討します。
- 特権サービスアカウントが割り当てられたコンピューティングリソースへのアクセスを制限する: シェルアクセスを制限し、メタデータサーバーへのアクセスを選択したユーザーとプロセスに限定します。
5.3. ロギング、モニタリング、セキュリティ監視
プライベートクラウド環境の健全性とセキュリティを維持するためには、継続的なロギング、モニタリング、およびセキュリティイベント分析が不可欠です。
5.3.1. VPC Flow LogsとCloud Audit Logsによる可視化
- VPC Flow Logs: VMインスタンスから送受信されるネットワークフローを記録します 。これらのログは、ネットワークモニタリング、フォレンジック、リアルタイムセキュリティ分析、さらには費用最適化にも利用できます 。サブネット単位で有効化でき、集計間隔やメタデータの含否などを調整可能です 。
- Cloud Audit Logs: Google Cloudリソース内での管理アクティビティ、データアクセス、ポリシー拒否、システムイベントを記録する監査ログを提供します 。これにより、「誰が、何を、どこで、いつ行ったか」といったセキュリティ、監査、コンプライアンスに関する情報が可視化されます。データアクセス監査ログはデフォルトで無効になっているため、明示的に有効にする必要があります 。
5.3.2. Cloud Monitoringによるアラート設定とセキュリティイベント分析
Cloud Monitoringは、Google Cloud、AWS、オンプレミスシステムなど、様々なソースからメトリック、イベント、メタデータを収集し、それらをダッシュボード、チャート、アラートとして可視化します 。
Cloud Monitoringを活用することで、VPC Flow LogsやCloud Audit Logsから収集されたログデータに基づいて、特定のセキュリティイベントに対するアラートを設定できます 。例えば、特定のIPアドレスからの異常なアクセス試行、不審なポートスキャン、データ転送量の急増などを検知し、即座に担当者に通知することが可能です。Cloud Loggingに取り込まれたログデータは、BigQueryを活用したログ分析で利用可能であり、SQLを使用して高度な分析を行い、セキュリティイベントの相関分析や脅威ハンティングに役立てることができます 。
以下の表は、Cloud Audit Logsの主要な監査ログの種類と特性をまとめたものです。
監査ログの種類 | 説明 | 記録設定 | 課金 |
管理アクティビティ監査ログ | リソースの構成やメタデータを変更するAPI呼び出しや操作のログ。例: VMインスタンスの作成、IAM権限の変更 。 | 常に記録され、設定不可 。 | なし 。 |
データアクセス監査ログ | リソースの構成やメタデータを読み取るAPI呼び出し、ユーザーが開始したデータ作成/変更/読み取りAPI呼び出しのログ 。 | デフォルトで無効。明示的な有効化が必要 。 | あり 。 |
ポリシー拒否監査ログ | セキュリティポリシー違反により、ユーザーまたはサービスアカウントへのアクセスが拒否された際のログ 。 | デフォルトで有効。除外フィルタで保存を制御可能 。 | あり 。 |
システムイベント監査ログ | Google Cloudシステムがリソース構成を変更した際のログ 。 | 常に記録され、設定不可 。 | なし 。 |
Google Cloud プライベートクラウド環境 ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
6. 設計上の考慮事項とベストプラクティス
Google Cloudでセキュアなプライベートクラウド環境を構築する際には、技術的な設定だけでなく、システム全体の設計原則と運用戦略を考慮することが重要です。
6.1. 高可用性とスケーラビリティの確保
プライベートクラウド環境は、ビジネスの継続性を支えるために高い可用性とスケーラビリティを備えている必要があります。
- 冗長性と容量計画: トラフィック量を慎重に試算し、十分な余裕を持った帯域幅を設定することが不可欠です 。特に、Cloud InterconnectやCloud VPNのようなハイブリッド接続においては、障害発生時のフェイルオーバーに備え、正副系共に均衡な容量を持つ冗長構成(Active/Activeなど)を採用することが強く推奨されます 。
- マルチリージョン/マルチゾーンデプロイメント: アプリケーションの信頼性を高めるために、単一障害点(SPOF)を排除し、複数のリージョンやゾーンにリソースを分散配置する設計を検討します 。これにより、特定のリージョンやゾーンで障害が発生した場合でも、サービスを継続できます。
6.2. コスト最適化戦略
クラウド環境の運用においては、コストの最適化も重要な考慮事項です。
- VPC内部通信の活用: 同一VPCネットワーク内のリソース間の通信は無料であるため、可能な限り内部通信を活用することで、データ転送コストを削減できます 。
- Cloud Interconnectによる費用削減: 大量のデータ転送が必要な場合、Cloud Interconnectはパブリックインターネット経由のデータ転送と比較して、アウトバウンドデータ転送費用を削減できる可能性があります 。
- ロギングの最適化: Cloud Loggingの料金は、ログの取り込み量と保持期間によって発生します 。不要なログを除外フィルタで排除したり、ログの保持期間を適切に設定したりすることで、ロギングコストを管理できます 。
6.3. ハイブリッド/マルチクラウドアーキテクチャの原則
Google Cloud Well-Architected Frameworkは、安全で効率的、復元性が高く、高パフォーマンスで費用対効果に優れたクラウドトポロジを設計および運用するための推奨事項を提供しており、これはハイブリッドクラウドやプライベートクラウドのデプロイメントにも関連します 。
主要な設計原則には、以下の点が挙げられます 。
- 変化に対応する設計: ユーザーのニーズやシステムの変化に迅速に対応できるよう、開発プロセスと本番環境プロセスを構築します。
- アーキテクチャの文書化: システムのアーキテクチャを明確に文書化し、共通の言語と標準を確立します。
- 設計の簡素化とフルマネージドサービスの利用: 複雑さを避け、可能な限りフルマネージドサービスを利用して運用管理の労力を最小限に抑えます。
- アーキテクチャの分離: アプリケーションコンポーネントを独立して動作できる小さなサービスに分離し、柔軟性と独立した管理を可能にします。
- ステートレスアーキテクチャの使用: アプリケーションの信頼性とスケーラビリティを向上させるために、ステートレスな設計を優先します。
6.4. 多層防御とゼロトラストセキュリティモデルの実現
プライベートクラウド環境のセキュリティは、単一の対策に依存するのではなく、複数の防御層を組み合わせる多層防御のアプローチによって強化されます 。
ゼロトラストセキュリティモデルは、ネットワークの内部か外部かにかかわらず、デフォルトでは何も信頼しないことを意味します 。このモデルでは、アクセス制御をネットワーク境界から個々のユーザーやデバイスに移行し、「常に検証し、常に最小限の特権アクセスを付与する」という原則に基づきます 。
具体的には、以下の実践が推奨されます。
- マイクロセグメンテーション: ネットワーク内部でも、アプリケーションとサービス間の通信を規制・管理し、きめ細かいセキュリティポリシーでラテラルムーブメントを封じ込めます 。
- インターネット接続サービスの保護: 必要な場合を除き、インターネットからクラウドへのアクセスを制限し、やむを得ない場合はDDoS対策、ウェブアプリケーションファイアウォール(WAF)ポリシー、ID認識型アクセス制御、リアルタイムモニタリング、ロギング、アラート発信を組み合わせます 。
- セキュアな接続の確保: オンプレミス、クラウド、または複数のクラウド環境間の接続を保護し、プライベートアクセスオプションを活用して重要なワークフローへの影響を回避します 。
これらの対策を組み合わせることで、攻撃者がネットワークに侵入した場合でも、被害の拡大を最小限に抑え、規制遵守を強化することが可能となります。
Google Cloud プライベートクラウド環境 ネットワーク設計とリソース活用
Google Cloud プライベートクラウド環境
Google Cloud プライベートクラウド
7. まとめと推奨事項
Google Cloud上でプライベートクラウド環境を構築することは、従来のオンプレミス環境が提供する高度な制御とセキュリティを維持しつつ、パブリッククラウドの持つ無限の拡張性、柔軟性、そしてマネージドサービスの恩恵を享受するための戦略的なアプローチです。本レポートでは、その実現に向けたネットワーク設定、利用可能なリソース、およびセキュリティ・運用管理のベストプラクティスを詳細に解説しました。
主要な推奨事項は以下の通りです。
- VPCネットワークを基盤とする論理的隔離の徹底: VPCネットワークのグローバル性とリージョンサブネットを活用し、IPアドレス計画を綿密に行うことで、論理的に隔離されたセキュアなネットワーク基盤を構築します。将来的なIPアドレス枯渇を避けるため、十分なIP範囲の確保とIPv6の活用を検討してください。
- 多層防御のセキュリティモデルの実装: ファイアウォールルールによる最小権限の原則の適用、ネットワークセグメンテーションによるマイクロセグメンテーションの実現、そしてVPC Service Controlsによるデータ漏洩対策を組み合わせ、包括的な多層防御戦略を導入します。
- セキュアなプライベート接続の確立: オンプレミスや他のクラウド環境との接続には、Cloud VPN (HA VPN) やCloud Interconnect (Dedicated/Partner/Cross-Cloud) を利用し、高可用性と冗長性を確保します。Google Cloudのマネージドサービスへのアクセスは、限定公開のGoogleアクセス、プライベートサービスアクセス、Private Service Connectの中から、サービスの特性と要件に合致する最適なオプションを選択します。
- プライベート環境向けリソース構成の最適化: Compute Engineの外部IPなしVMとIAPによるアクセス、GKE限定公開クラスタのコントロールプレーンアクセス制御、サーバレスVPCアクセスコネクタによるサーバレスサービスとVPCの連携、そして各種マネージドデータベース/ストレージサービスのプライベートIP接続を積極的に活用し、攻撃対象領域を最小化します。
- IAMの強化と継続的な監視: 組織ポリシーと条件付きIAMを活用してアクセス制御を厳格化し、カスタムロールとサービスアカウントのベストプラクティスを徹底します。VPC Flow LogsとCloud Audit Logsによる継続的なロギングと、Cloud Monitoringによるアラート設定を通じて、セキュリティイベントをリアルタイムで監視し、迅速な対応体制を確立します。
これらの要素を統合的に設計・運用することで、Google Cloud上に、ビジネス要件を満たすセキュアで信頼性の高いプライベートクラウド環境を構築することが可能となります。
コメントを残す