Google Cloud ランディング ゾーン ネットワーク設計を実装する

Last reviewed 2023-09-11 UTC

このドキュメントでは、Google Cloud ランディング ゾーンのネットワーク設計を決定するを確認した後で、選択したネットワーク設計を実装する手順とガイダンスを示します。まだ Google Cloud のランディング ゾーンの設計を確認していない場合は、オプションを選択する前に確認してください。

ここで説明する手順は、組織のランディング ゾーンのネットワーク設計の作成に関与するネットワーク エンジニア、アーキテクト、技術系の実務担当者を対象としています。

ネットワーク設計オプション

選択したネットワーク設計に基づいて、次のいずれかを作成します。

作成オプション 1: 各環境の共有 VPC ネットワーク

「Google Cloud ランディング ゾーンのネットワーク設計を決定する」で各環境の共有 VPC ネットワークを作成することを選択した場合は、次の手順を実施します。

次の手順に沿って、ランディング ゾーンの単一のインスタンスを作成します。複数のランディング ゾーン(たとえば、開発用に 1 つと本番環境用に 1 つ)が必要な場合は、ランディング ゾーンごとに手順を繰り返します。

組織のポリシーを使用して外部アクセスを制限する

インターネットへの直接アクセスは、インターネットを直接アクセスせざるを得ないリソースのみに制限することをおすすめします。外部アドレスのないリソースであっても、限定公開の Google アクセスを通じて多くの Google API やサービスにアクセスできます。限定公開の Google アクセスは、サブネット レベルで有効になっており、公共のインターネットから隔離されていても、リソースが主要な Google サービスとやりとりできます。

ユーザビリティのため、Google Cloud のデフォルト機能では、適切な IAM 権限が付与されたユーザーである限り、どのユーザーでもあらゆるプロジェクト内でリソースを作成できます。セキュリティを強化するために、意図せずにインターネットにアクセスする可能性があるリソースタイプに対しては、デフォルトの権限が使用されないよう制限することをおすすめします。このようにすれば、特定のプロジェクトに限って、これらのリソースの作成を許可できます。組織のポリシーの作成と管理の手順を用いて、次の制約を設定します。

IP アドレスの種類に基づいてプロトコル転送を制限する

プロトコル転送では、外部 IP アドレスを使用した転送ルールのリソースが確立され、トラフィックを VM に転送できるようになります。

[IP アドレスの種類に基づいてプロトコル転送を制限する] 制約は、組織全体に適用される、外部 IP アドレスを使用した転送ルールが作成されないようにします。外部転送ルールを使用することが承認されたプロジェクトの場合、フォルダまたはプロジェクトのレベルで制約を変更できます。

この制約を構成するには、次の値を設定します。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: カスタム
  • ポリシータイプ: 拒否
  • カスタム値: IS:EXTERNAL

VM インスタンスに対して許可されている外部 IP を定義する

デフォルトでは、個々の VM インスタンスは外部 IP アドレスを取得できます。これにより、インターネットとの送信と受信の両方の接続が可能になります。

[VM インスタンスに対して許可されている外部 IP を定義する] 制約を適用すると、VM インスタンスで外部 IP アドレスを使用できなくなります。個々の VM インスタンスで外部 IP アドレスを必要とするワークロードの場合、フォルダまたはプロジェクトのレベルで制約を変更して個々の VM インスタンスを指定します。または、関連するプロジェクトの制約をオーバーライドできます。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: すべて拒否

VPC 外部 IPv6 の使用を無効にする

[VPC 外部 IPv6 の使用を無効にする] 制約を True に設定すると、VM インスタンスの外部 IPv6 アドレスを設定した VPC サブネットを構成できなくなります。

  • 適用先: カスタマイズ
  • 適用: オン

デフォルト ネットワークの作成を無効にする

新しいプロジェクトが作成されると、デフォルトの VPC が自動的に作成されます。これは、特定のネットワーク構成または大規模なエンタープライズ ネットワークとの統合を必要としない迅速なテストに役立ちます。

[デフォルトのネットワークの作成をスキップする] 制約を構成して、新しいプロジェクトのデフォルトの VPC 作成を無効にします。必要に応じて、プロジェクト内にデフォルト ネットワークを手動で作成できます。

  • 適用先: カスタマイズ
  • 適用: オン

ファイアウォール ルールを設計する

ファイアウォール ルールによって、定義した構成に基づいて、VM へのまたは VM からのトラフィックを許可または拒否できます。階層型ファイアウォール ポリシーは組織とフォルダのレベルで実装され、ネットワーク ファイアウォール ポリシーはリソース階層の VPC ネットワーク レベルで実装されます。これらがまとまって、ワークロードを保護するうえで重要な機能を提供します。

ファイアウォール ポリシーが適用される場所に関係なく、ファイアウォール ルールを設計、評価する際は、次のガイドラインに従ってください。

  • 最小権限(マイクロセグメンテーションとも呼ばれる)の原則を実装します。デフォルトでは、すべてのトラフィックをブロックし、必要な特定のトラフィックのみを許可します。これには、各ワークロードに必要なプロトコルとポートのみにルールを制限することも含まれます。
  • ファイアウォールの動作に関する可視性を確保するために、ファイアウォール ルールのロギングを有効にし、ファイアウォール インサイトを使用します。
  • ファイアウォール ルールの優先度を割り振る際の番号付け方法を定義します。たとえば、インシデント対応時に必要となるルール用に、各ポリシーに一連の小さい数値を予約しておくことをおすすめします。また、より具体的なルールが一般的なルールよりも優先されるようにして、具体的なルールが一般的なルールによってシャドーイングされないようにすることもおすすめします。次の例は、ファイアウォール ルールの優先度に対して考えられるアプローチを示しています。

ファイアウォール ルールの優先度の範囲

目的

0~999

インシデント対応用に予約済み

1,000~1,999

常にブロックされるトラフィック

2,000~1,999,999,999

ワークロード固有のルール

2,000,000,000~2,100,000,000

キャッチオール ルール

2,100,000,001~2,147,483,643

予約済み

階層型ファイアウォール ポリシーを構成する

階層型ファイアウォール ポリシーを使用すると、組織全体で一貫したファイアウォール ポリシーを作成して適用できます。階層型ファイアウォール ポリシーの使用例については、階層型ファイアウォール ポリシーの例をご覧ください。

階層型ファイアウォール ポリシーを定義して、次のネットワーク アクセス制御を実装します。

  • TCP 転送用の Identity-Aware Proxy(IAP)。TCP 転送用の IAP は、TCP ポート 22 と 3389 の IP 範囲 35.235.240.0/20 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーによって許可されます。
  • Cloud Load Balancing のヘルスチェック。ヘルスチェックに使用される広く知られた範囲を使用できます。
    • ほとんどの Cloud Load Balancing インスタンス(内部 TCP / UDP ロード バランシング、内部 HTTP(S) ロード バランシング、外部 TCP プロキシ ロード バランシング、外部 SSL プロキシ ロード バランシング、HTTP(S) ロード バランシングなど)では、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16 と 130.211.0.0/22 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーを定義します。
    • ネットワーク ロード バランシングでは、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16、209.85.152.0/22、209.85.204.0/22 からの上り(内向き)トラフィックを許可することで、レガシー ヘルスチェックを有効にするセキュリティ ポリシーを定義します。

共有 VPC 環境を構成する

共有 VPC の設計を実装する前に、サービス プロジェクトでサブネットを共有する方法を決定します。サービス プロジェクトは、ホスト プロジェクトに接続します。サービス プロジェクトで使用できるサブネットを決定するには、ホスト プロジェクトまたは個々のサブネットに IAM 権限を割り当てます。たとえば、サービス プロジェクトごとに異なる専用のサブネットを使用するか、サービス プロジェクト間で同じサブネットを共有するかを選択できます。

  1. 共有 VPC 用の新しいプロジェクトを作成します。このプロセスの後の方で、このプロジェクトをホスト プロジェクトにして、サービス プロジェクトと共有するネットワークとネットワーク リソースを格納します。
  2. ホスト プロジェクトで Compute Engine API を有効にします
  3. プロジェクトで共有 VPC を構成します
  4. ホスト プロジェクト内でカスタムモードの VPC ネットワークを作成します。
  5. ワークロードをデプロイするリージョンにサブネットを作成します。サブネットごとに、限定公開の Google アクセスを有効にして、外部 IP アドレスを持たない VM インスタンスが Google サービスにアクセスできるようにします。

Cloud NAT を構成する

特定のリージョンのワークロードが、たとえばソフトウェア パッケージやアップデートをダウンロードするなど、送信インターネット アクセスを必要とする場合は、次の手順を実施します。

  1. ワークロードにインターネットへの送信アクセスが必要となるリージョンに Cloud NAT ゲートウェイを作成します。必要に応じて、特定のサブネットからの送信接続のみを許可するように、Cloud NAT 構成をカスタマイズできます。
  2. 少なくとも、ゲートウェイで ERRORS_ONLY をログに記録できるように、Cloud NAT ロギングを有効にします。Cloud NAT によって実行された変換のログを含めるには、各ゲートウェイが ALL をログに記録するように構成します。

ハイブリッド接続を構成する

ランディング ゾーンへのハイブリッド接続を提供するには、Dedicated Interconnect、Partner Interconnect、または Cloud VPN を使用できます。以下の手順によって、この設計オプションに必要な最初のハイブリッド接続リソースが作成されます。

  1. Dedicated Interconnect を使用する場合は、次の手順を実施します。Partner Interconnect または Cloud VPN を使用する場合は、これらの手順をスキップできます。
    1. 物理相互接続ポートごとに別々のプロジェクトを作成します。
    2. プロジェクトで Compute Engine API を有効にします。
    3. Dedicated Interconnect 接続を作成します。
  2. VPC ネットワークで、ハイブリッド接続を終端するリージョンごとに、次のようにします。
    1. 2 つの Dedicated または Partner の VLAN アタッチメントを、エッジ アベイラビリティ ゾーンごとに 1 つ作成します。このプロセスの一環として Cloud Router を選択し、BGP セッションを作成します。
    2. ピア ネットワーク(オンプレミスまたは他のクラウド)のルーターを構成します。

ワークロード プロジェクトを構成する

ワークロードごとに別々のサービス プロジェクトを作成します。

  1. 共有 VPC に対してサービス プロジェクトの 1 つとして機能する新しいプロジェクトを作成します。
  2. サービス プロジェクトで Compute Engine API を有効にします。
  3. プロジェクトをホスト プロジェクトに接続します。
  4. ホスト プロジェクト内のすべてのサブネットまたはホスト プロジェクト内の一部のサブネットへのアクセスを構成します。

オブザーバビリティを構成する

Network Intelligence Center は、クラウド ネットワーキング環境をモニタリング、トラブルシューティング、可視化する包括的な方法を提供します。それを使用して、設計が目的のインテントで確実に機能するようにします。

次の構成により、ロギングと指標の分析に対応できます。

  • 接続テストを実行する前に、Network Management API を有効にする必要があります。API を直接使用する場合、または Google Cloud CLI あるいは Google Cloud コンソールを使用する場合は、この API を有効にする必要があります。
  • ファイアウォール インサイトを使用してタスクを実行するには、Firewall Insights API を有効にする必要があります。

次のステップ

これで、このネットワーク設計オプションの初期構成が完了しました。これらの手順を繰り返して、ランディング ゾーン環境の追加インスタンス(ステージング環境や本番環境など)を構成することも、引き続き Google Cloud ランディング ゾーンのセキュリティを決定する手順に沿うこともできます。

作成オプション 2: 一元管理されたアプライアンスを使用するハブアンドスポーク トポロジ

「Google Cloud ランディング ゾーンのネットワーク設計を決定する」で一元管理されたアプライアンスを使用するハブアンドスポーク トポロジを作成する場合は、次の手順を実施します。

次の手順に沿って、ランディング ゾーンの単一のインスタンスを作成します。複数のランディング ゾーン(たとえば、開発用に 1 つと本番環境用に 1 つ)が必要な場合は、ランディング ゾーンごとに手順を繰り返します。

組織のポリシーを使用して外部アクセスを制限する

インターネットへの直接アクセスは、インターネットを直接アクセスせざるを得ないリソースのみに制限することをおすすめします。外部アドレスのないリソースであっても、限定公開の Google アクセスを通じて多くの Google API やサービスにアクセスできます。限定公開の Google アクセスは、サブネット レベルで有効になっており、公共のインターネットから隔離されていても、リソースが主要な Google サービスとやりとりできます。

ユーザビリティのため、Google Cloud のデフォルト機能では、適切な IAM 権限が付与されたユーザーである限り、どのユーザーでもあらゆるプロジェクト内でリソースを作成できます。セキュリティを強化するために、意図せずにインターネットにアクセスする可能性があるリソースタイプに対しては、デフォルトの権限が使用されないよう制限することをおすすめします。このようにすれば、特定のプロジェクトに限って、これらのリソースの作成を許可できます。組織のポリシーの作成と管理の手順を用いて、次の制約を設定します。

IP アドレスの種類に基づいてプロトコル転送を制限する

プロトコル転送では、外部 IP アドレスを使用した転送ルールのリソースが確立され、トラフィックを VM に転送できるようになります。

[IP アドレスの種類に基づいてプロトコル転送を制限する] 制約は、組織全体に適用される、外部 IP アドレスを使用した転送ルールが作成されないようにします。外部転送ルールを使用することが承認されたプロジェクトの場合、フォルダまたはプロジェクトのレベルで制約を変更できます。

この制約を構成するには、次の値を設定します。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: カスタム
  • ポリシータイプ: 拒否
  • カスタム値: IS:EXTERNAL

VM インスタンスに対して許可されている外部 IP を定義する

デフォルトでは、個々の VM インスタンスは外部 IP アドレスを取得できます。これにより、インターネットとの送信と受信の両方の接続が可能になります。

[VM インスタンスに対して許可されている外部 IP を定義する] 制約を適用すると、VM インスタンスで外部 IP アドレスを使用できなくなります。個々の VM インスタンスで外部 IP アドレスを必要とするワークロードの場合、フォルダまたはプロジェクトのレベルで制約を変更して個々の VM インスタンスを指定します。または、関連するプロジェクトの制約をオーバーライドできます。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: すべて拒否

VPC 外部 IPv6 の使用を無効にする

[VPC 外部 IPv6 の使用を無効にする] 制約を True に設定すると、VM インスタンスの外部 IPv6 アドレスを設定した VPC サブネットを構成できなくなります。

  • 適用先: カスタマイズ
  • 適用: オン

デフォルト ネットワークの作成を無効にする

新しいプロジェクトが作成されると、デフォルトの VPC が自動的に作成されます。これは、特定のネットワーク構成または大規模なエンタープライズ ネットワークとの統合を必要としない迅速なテストに役立ちます。

[デフォルトのネットワークの作成をスキップする] 制約を構成して、新しいプロジェクトのデフォルトの VPC 作成を無効にします。必要に応じて、プロジェクト内にデフォルト ネットワークを手動で作成できます。

  • 適用先: カスタマイズ
  • 適用: オン

ファイアウォール ルールを設計する

ファイアウォール ルールによって、定義した構成に基づいて、VM へのまたは VM からのトラフィックを許可または拒否できます。階層型ファイアウォール ポリシーは組織とフォルダのレベルで実装され、ネットワーク ファイアウォール ポリシーはリソース階層の VPC ネットワーク レベルで実装されます。これらがまとまって、ワークロードを保護するうえで重要な機能を提供します。

ファイアウォール ポリシーが適用される場所に関係なく、ファイアウォール ルールを設計、評価する際は、次のガイドラインに従ってください。

  • 最小権限(マイクロセグメンテーションとも呼ばれる)の原則を実装します。デフォルトでは、すべてのトラフィックをブロックし、必要な特定のトラフィックのみを許可します。これには、各ワークロードに必要なプロトコルとポートのみにルールを制限することも含まれます。
  • ファイアウォールの動作に関する可視性を確保するために、ファイアウォール ルールのロギングを有効にし、ファイアウォール インサイトを使用します。
  • ファイアウォール ルールの優先度を割り振る際の番号付け方法を定義します。たとえば、インシデント対応時に必要となるルール用に、各ポリシーに一連の小さい数値を予約しておくことをおすすめします。また、より具体的なルールが一般的なルールよりも優先されるようにして、具体的なルールが一般的なルールによってシャドーイングされないようにすることもおすすめします。次の例は、ファイアウォール ルールの優先度に対して考えられるアプローチを示しています。

ファイアウォール ルールの優先度の範囲

目的

0~999

インシデント対応用に予約済み

1,000~1,999

常にブロックされるトラフィック

2,000~1,999,999,999

ワークロード固有のルール

2,000,000,000~2,100,000,000

キャッチオール ルール

2,100,000,001~2,147,483,643

予約済み

階層型ファイアウォール ポリシーを構成する

階層型ファイアウォール ポリシーを使用すると、組織全体で一貫したファイアウォール ポリシーを作成して適用できます。階層型ファイアウォール ポリシーの使用例については、階層型ファイアウォール ポリシーの例をご覧ください。

階層型ファイアウォール ポリシーを定義して、次のネットワーク アクセス制御を実装します。

  • TCP 転送用の Identity-Aware Proxy(IAP)。TCP 転送用の IAP は、TCP ポート 22 と 3389 の IP 範囲 35.235.240.0/20 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーによって許可されます。
  • Cloud Load Balancing のヘルスチェック。ヘルスチェックに使用される広く知られた範囲を使用できます。
    • ほとんどの Cloud Load Balancing インスタンス(内部 TCP / UDP ロード バランシング、内部 HTTP(S) ロード バランシング、外部 TCP プロキシ ロード バランシング、外部 SSL プロキシ ロード バランシング、HTTP(S) ロード バランシングなど)では、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16 と 130.211.0.0/22 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーを定義します。
    • ネットワーク ロード バランシングでは、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16、209.85.152.0/22、209.85.204.0/22 からの上り(内向き)トラフィックを許可することで、レガシー ヘルスチェックを有効にするセキュリティ ポリシーを定義します。

VPC 環境を構成する

トランジット VPC ネットワークとハブ VPC ネットワークは、ワークロードのスポーク VPC ネットワークとオンプレミスまたはマルチクラウド ネットワークとの間の接続を可能にするネットワーキング リソースを提供します。

  1. トランジットおよびハブ VPC ネットワークの新しいプロジェクトを作成します。両方の VPC ネットワークが同じプロジェクトの一部となり、仮想ネットワーク アプライアンスを使用して接続をサポートします。
  2. プロジェクトで Compute Engine API を有効にします。
  3. カスタムモードのトランジット VPC ネットワークを作成します。
  4. トランジット VPC ネットワークで、仮想ネットワーク アプライアンスをデプロイする予定のリージョンにサブネットを作成します。
  5. カスタムモードのハブ VPC ネットワークを作成します。
  6. ハブ VPC ネットワークで、仮想ネットワーク アプライアンスをデプロイする予定のリージョンにサブネットを作成します。
  7. グローバルまたはリージョンのネットワーク ファイアウォール ポリシーを構成して、ネットワーク仮想アプライアンスに上り(内向き)と下り(外向き)のトラフィックを許可します。
  8. 仮想ネットワーク アプライアンス用のマネージド インスタンス グループを作成します。
  9. トランジット VPC 用の内部 TCP / UDP ロード バランシング リソースを構成します。このロードバランサは、仮想ネットワーク アプライアンスを介してトランジット VPC からハブ VPC にトラフィックをルーティングするために使用されます。
  10. ハブ VPC 用の内部 TCP / UDP ロード バランシング リソースを構成します。このロードバランサは、仮想ネットワーク アプライアンスを介してハブ VPC からトランジット VPC にトラフィックをルーティングするために使用されます。
  11. ハブ VPC 用の Google API 対応 Private Service Connect を構成します。
  12. VPC ルートを変更し、ネットワーク仮想アプライアンスを介してすべてのトラフィックを送信します。
    1. ネクストホップ default-internet-gateway を持つ 0.0.0.0/0 ルートをハブ VPC から削除します。
    2. 宛先 0.0.0.0/0 とハブ VPC 内のロードバランサ用の転送ルールのネクストホップを使用して、新しいルートを構成します。

Cloud NAT を構成する

特定のリージョンのワークロードが、たとえばソフトウェア パッケージやアップデートをダウンロードするなど、送信インターネット アクセスを必要とする場合は、次の手順を実施します。

  1. ワークロードにインターネットへの送信アクセスが必要となるリージョンに Cloud NAT ゲートウェイを作成します。必要に応じて、特定のサブネットからの送信接続のみを許可するように、Cloud NAT 構成をカスタマイズできます。
  2. 少なくとも、ゲートウェイで ERRORS_ONLY をログに記録できるように、Cloud NAT ロギングを有効にします。Cloud NAT によって実行された変換のログを含めるには、各ゲートウェイが ALL をログに記録するように構成します。

ハイブリッド接続を構成する

ランディング ゾーンへのハイブリッド接続を提供するには、Dedicated Interconnect、Partner Interconnect、または Cloud VPN を使用できます。以下の手順によって、この設計オプションに必要な最初のハイブリッド接続リソースが作成されます。

  1. Dedicated Interconnect を使用する場合は、次の手順を実施します。Partner Interconnect または Cloud VPN を使用する場合は、これらの手順をスキップできます。
    1. 物理相互接続ポートごとに別々のプロジェクトを作成します。
    2. プロジェクトで Compute Engine API を有効にします。
    3. Dedicated Interconnect 接続を作成します。
  2. VPC ネットワークで、ハイブリッド接続を終端するリージョンごとに、次のようにします。
    1. 2 つの Dedicated または Partner の VLAN アタッチメントを、エッジ アベイラビリティ ゾーンごとに 1 つ作成します。このプロセスの一環として Cloud Router を選択し、BGP セッションを作成します。
    2. ピア ネットワーク(オンプレミスまたは他のクラウド)のルーターを構成します。
    3. ハブ VPC とワークロード VPC のサブネット範囲を対象に、Cloud Router でカスタムルート アドバタイズを構成します。

ワークロード プロジェクトを構成する

ワークロードごとに別々のスポーク VPC を作成します。

  1. ワークロードをホストするための新しいプロジェクトを作成します。
  2. プロジェクトで Compute Engine API を有効にします。
  3. 次の設定を使用して、ワークロードのスポーク VPC とハブ VPC 間の VPC ネットワーク ピアリングを構成します。
    • ハブ VPC でカスタムルートのエクスポートを有効にします。
    • ワークロードのスポーク VPC でカスタムルートのインポートを有効にします。
  4. ワークロードをデプロイするリージョンにサブネットを作成します。サブネットごとに限定公開の Google アクセスを有効にして、内部 IP アドレスのみを持つ VM インスタンスが Google サービスに到達できるようにします。
  5. Google API 用の Private Service Connect を構成します。
  6. ハブ VPC 内の仮想ネットワーク アプライアンスを介してすべてのトラフィックをルーティングするには、ワークロードのスポーク VPC からネクストホップ default-internet-gateway を持つ 0.0.0.0/0 ルートを削除します。
  7. グローバルまたはリージョンのネットワーク ファイアウォール ポリシーを構成して、ワークロードに上り(内向き)と下り(外向き)のトラフィックを許可します。

オブザーバビリティを構成する

Network Intelligence Center は、クラウド ネットワーキング環境をモニタリング、トラブルシューティング、可視化する包括的な方法を提供します。それを使用して、設計が目的のインテントで確実に機能するようにします。

次の構成により、ロギングと指標の分析に対応できます。

  • 接続テストを実行する前に、Network Management API を有効にする必要があります。API を直接使用する場合、または Google Cloud CLI あるいは Google Cloud コンソールを使用する場合は、この API を有効にする必要があります。
  • ファイアウォール インサイトを使用してタスクを実行するには、Firewall Insights API を有効にする必要があります。

次のステップ

これで、このネットワーク設計オプションの初期構成が完了しました。これらの手順を繰り返して、ランディング ゾーン環境の追加インスタンス(ステージング環境や本番環境など)を構成することも、引き続き Google Cloud ランディング ゾーンのセキュリティを決定する手順に沿うこともできます。

作成オプション 3: アプライアンスを使用しないハブアンドスポーク トポロジ

「Google Cloud ランディング ゾーンのネットワーク設計を決定する」でアプライアンスを使用しないハブアンドスポーク トポロジを作成する場合は、次の手順を実施します。

次の手順に沿って、ランディング ゾーンの単一のインスタンスを作成します。複数のランディング ゾーン(たとえば、開発用に 1 つと本番環境用に 1 つ)が必要な場合は、ランディング ゾーンごとに手順を繰り返します。

組織のポリシーを使用して外部アクセスを制限する

インターネットへの直接アクセスは、インターネットを直接アクセスせざるを得ないリソースのみに制限することをおすすめします。外部アドレスのないリソースであっても、限定公開の Google アクセスを通じて多くの Google API やサービスにアクセスできます。限定公開の Google アクセスは、サブネット レベルで有効になっており、公共のインターネットから隔離されていても、リソースが主要な Google サービスとやりとりできます。

ユーザビリティのため、Google Cloud のデフォルト機能では、適切な IAM 権限が付与されたユーザーである限り、どのユーザーでもあらゆるプロジェクト内でリソースを作成できます。セキュリティを強化するために、意図せずにインターネットにアクセスする可能性があるリソースタイプに対しては、デフォルトの権限が使用されないよう制限することをおすすめします。このようにすれば、特定のプロジェクトに限って、これらのリソースの作成を許可できます。組織のポリシーの作成と管理の手順を用いて、次の制約を設定します。

IP アドレスの種類に基づいてプロトコル転送を制限する

プロトコル転送では、外部 IP アドレスを使用した転送ルールのリソースが確立され、トラフィックを VM に転送できるようになります。

[IP アドレスの種類に基づいてプロトコル転送を制限する] 制約は、組織全体に適用される、外部 IP アドレスを使用した転送ルールが作成されないようにします。外部転送ルールを使用することが承認されたプロジェクトの場合、フォルダまたはプロジェクトのレベルで制約を変更できます。

この制約を構成するには、次の値を設定します。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: カスタム
  • ポリシータイプ: 拒否
  • カスタム値: IS:EXTERNAL

VM インスタンスに対して許可されている外部 IP を定義する

デフォルトでは、個々の VM インスタンスは外部 IP アドレスを取得できます。これにより、インターネットとの送信と受信の両方の接続が可能になります。

[VM インスタンスに対して許可されている外部 IP を定義する] 制約を適用すると、VM インスタンスで外部 IP アドレスを使用できなくなります。個々の VM インスタンスで外部 IP アドレスを必要とするワークロードの場合、フォルダまたはプロジェクトのレベルで制約を変更して個々の VM インスタンスを指定します。または、関連するプロジェクトの制約をオーバーライドできます。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: すべて拒否

VPC 外部 IPv6 の使用を無効にする

[VPC 外部 IPv6 の使用を無効にする] 制約を True に設定すると、VM インスタンスの外部 IPv6 アドレスを設定した VPC サブネットを構成できなくなります。

  • 適用先: カスタマイズ
  • 適用: オン

デフォルト ネットワークの作成を無効にする

新しいプロジェクトが作成されると、デフォルトの VPC が自動的に作成されます。これは、特定のネットワーク構成または大規模なエンタープライズ ネットワークとの統合を必要としない迅速なテストに役立ちます。

[デフォルトのネットワークの作成をスキップする] 制約を構成して、新しいプロジェクトのデフォルトの VPC 作成を無効にします。必要に応じて、プロジェクト内にデフォルト ネットワークを手動で作成できます。

  • 適用先: カスタマイズ
  • 適用: オン

ファイアウォール ルールを設計する

ファイアウォール ルールによって、定義した構成に基づいて、VM へのまたは VM からのトラフィックを許可または拒否できます。階層型ファイアウォール ポリシーは組織とフォルダのレベルで実装され、ネットワーク ファイアウォール ポリシーはリソース階層の VPC ネットワーク レベルで実装されます。これらがまとまって、ワークロードを保護するうえで重要な機能を提供します。

ファイアウォール ポリシーが適用される場所に関係なく、ファイアウォール ルールを設計、評価する際は、次のガイドラインに従ってください。

  • 最小権限(マイクロセグメンテーションとも呼ばれる)の原則を実装します。デフォルトでは、すべてのトラフィックをブロックし、必要な特定のトラフィックのみを許可します。これには、各ワークロードに必要なプロトコルとポートのみにルールを制限することも含まれます。
  • ファイアウォールの動作に関する可視性を確保するために、ファイアウォール ルールのロギングを有効にし、ファイアウォール インサイトを使用します。
  • ファイアウォール ルールの優先度を割り振る際の番号付け方法を定義します。たとえば、インシデント対応時に必要となるルール用に、各ポリシーに一連の小さい数値を予約しておくことをおすすめします。また、より具体的なルールが一般的なルールよりも優先されるようにして、具体的なルールが一般的なルールによってシャドーイングされないようにすることもおすすめします。次の例は、ファイアウォール ルールの優先度に対して考えられるアプローチを示しています。

ファイアウォール ルールの優先度の範囲

目的

0~999

インシデント対応用に予約済み

1,000~1,999

常にブロックされるトラフィック

2,000~1,999,999,999

ワークロード固有のルール

2,000,000,000~2,100,000,000

キャッチオール ルール

2,100,000,001~2,147,483,643

予約済み

階層型ファイアウォール ポリシーを構成する

階層型ファイアウォール ポリシーを使用すると、組織全体で一貫したファイアウォール ポリシーを作成して適用できます。階層型ファイアウォール ポリシーの使用例については、階層型ファイアウォール ポリシーの例をご覧ください。

階層型ファイアウォール ポリシーを定義して、次のネットワーク アクセス制御を実装します。

  • TCP 転送用の Identity-Aware Proxy(IAP)。TCP 転送用の IAP は、TCP ポート 22 と 3389 の IP 範囲 35.235.240.0/20 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーによって許可されます。
  • Cloud Load Balancing のヘルスチェック。ヘルスチェックに使用される広く知られた範囲を使用できます。
    • ほとんどの Cloud Load Balancing インスタンス(内部 TCP / UDP ロード バランシング、内部 HTTP(S) ロード バランシング、外部 TCP プロキシ ロード バランシング、外部 SSL プロキシ ロード バランシング、HTTP(S) ロード バランシングなど)では、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16 と 130.211.0.0/22 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーを定義します。
    • ネットワーク ロード バランシングでは、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16、209.85.152.0/22、209.85.204.0/22 からの上り(内向き)トラフィックを許可することで、レガシー ヘルスチェックを有効にするセキュリティ ポリシーを定義します。

ハブ VPC 環境を構成する

ハブ VPC は、ワークロード スポーク VPC ネットワークとオンプレミスまたはマルチクラウドのネットワーク間の接続を可能にするネットワーク リソースを提供します。

  1. ハブ VPC ネットワーク用の新しいプロジェクトを作成します。
  2. プロジェクトで Compute Engine API を有効にします。
  3. カスタムモードのハブ VPC ネットワークを作成します。
  4. ハブ VPC 用の Google API 対応 Private Service Connect を構成します。

ハイブリッド接続を構成する

ランディング ゾーンへのハイブリッド接続を提供するには、Dedicated Interconnect、Partner Interconnect、または Cloud VPN を使用できます。以下の手順によって、この設計オプションに必要な最初のハイブリッド接続リソースが作成されます。

  1. Dedicated Interconnect を使用する場合は、次の手順を実施します。Partner Interconnect または Cloud VPN を使用する場合は、これらの手順をスキップできます。
    1. 物理相互接続ポートごとに別々のプロジェクトを作成します。
    2. プロジェクトで Compute Engine API を有効にします。
    3. Dedicated Interconnect 接続を作成します。
  2. VPC ネットワークで、ハイブリッド接続を終端するリージョンごとに、次のようにします。
    1. 2 つの Dedicated または Partner の VLAN アタッチメントを、エッジ アベイラビリティ ゾーンごとに 1 つ作成します。このプロセスの一環として Cloud Router を選択し、BGP セッションを作成します。
    2. ピア ネットワーク(オンプレミスまたは他のクラウド)のルーターを構成します。
    3. ハブ VPC とワークロード VPC のサブネット範囲を対象に、Cloud Router でカスタムルート アドバタイズを構成します。

ワークロード プロジェクトを構成する

ワークロードごとに別々のスポーク VPC を作成します。

  1. ワークロードをホストするための新しいプロジェクトを作成します。
  2. プロジェクトで Compute Engine API を有効にします。
  3. 次の設定を使用して、ワークロードのスポーク VPC とハブ VPC 間の VPC ネットワーク ピアリングを構成します。
    • ハブ VPC でカスタムルートのエクスポートを有効にします。
    • ワークロードのスポーク VPC でカスタムルートのインポートを有効にします。
  4. ワークロードをデプロイするリージョンにサブネットを作成します。サブネットごとに限定公開の Google アクセスを有効にして、内部 IP アドレスのみを持つ VM インスタンスが Google サービスに到達できるようにします。
  5. Google API 用の Private Service Connect を構成します。

Cloud NAT を構成する

特定のリージョンのワークロードが、たとえばソフトウェア パッケージやアップデートをダウンロードするなど、送信インターネット アクセスを必要とする場合は、次の手順を実施します。

  1. ワークロードにインターネットへの送信アクセスが必要となるリージョンに Cloud NAT ゲートウェイを作成します。必要に応じて、特定のサブネットからの送信接続のみを許可するように、Cloud NAT 構成をカスタマイズできます。
  2. 少なくとも、ゲートウェイで ERRORS_ONLY をログに記録できるように、Cloud NAT ロギングを有効にします。Cloud NAT によって実行された変換のログを含めるには、各ゲートウェイが ALL をログに記録するように構成します。

オブザーバビリティを構成する

Network Intelligence Center は、クラウド ネットワーキング環境をモニタリング、トラブルシューティング、可視化する包括的な方法を提供します。それを使用して、設計が目的のインテントで確実に機能するようにします。

次の構成により、ロギングと指標の分析に対応できます。

  • 接続テストを実行する前に、Network Management API を有効にする必要があります。API を直接使用する場合、または Google Cloud CLI あるいは Google Cloud コンソールを使用する場合は、この API を有効にする必要があります。
  • ファイアウォール インサイトを使用してタスクを実行するには、Firewall Insights API を有効にする必要があります。

次のステップ

これで、このネットワーク設計オプションの初期構成が完了しました。これらの手順を繰り返して、ランディング ゾーン環境の追加インスタンス(ステージング環境や本番環境など)を構成することも、引き続き Google Cloud ランディング ゾーンのセキュリティを決定する手順に沿うこともできます。

作成オプション 4: Private Service Connect を使用してコンシューマ プロデューサー モデルでサービスを公開する

「Google Cloud のランディング ゾーンのネットワーク設計を決定する」に説明されている、ランディング ゾーンに Private Service Connect を使用してコンシューマ プロデューサー モデルでサービスを公開するオプションを選択した場合は、次の手順を実施します。

次の手順に沿って、ランディング ゾーンの単一のインスタンスを作成します。複数のランディング ゾーン(たとえば、開発用に 1 つと本番環境用に 1 つ)が必要な場合は、ランディング ゾーンごとに手順を繰り返します。

組織のポリシーを使用して外部アクセスを制限する

インターネットへの直接アクセスは、インターネットを直接アクセスせざるを得ないリソースのみに制限することをおすすめします。外部アドレスのないリソースであっても、限定公開の Google アクセスを通じて多くの Google API やサービスにアクセスできます。限定公開の Google アクセスは、サブネット レベルで有効になっており、公共のインターネットから隔離されていても、リソースが主要な Google サービスとやりとりできます。

ユーザビリティのため、Google Cloud のデフォルト機能では、適切な IAM 権限が付与されたユーザーである限り、どのユーザーでもあらゆるプロジェクト内でリソースを作成できます。セキュリティを強化するために、意図せずにインターネットにアクセスする可能性があるリソースタイプに対しては、デフォルトの権限が使用されないよう制限することをおすすめします。このようにすれば、特定のプロジェクトに限って、これらのリソースの作成を許可できます。組織のポリシーの作成と管理の手順を用いて、次の制約を設定します。

IP アドレスの種類に基づいてプロトコル転送を制限する

プロトコル転送では、外部 IP アドレスを使用した転送ルールのリソースが確立され、トラフィックを VM に転送できるようになります。

[IP アドレスの種類に基づいてプロトコル転送を制限する] 制約は、組織全体に適用される、外部 IP アドレスを使用した転送ルールが作成されないようにします。外部転送ルールを使用することが承認されたプロジェクトの場合、フォルダまたはプロジェクトのレベルで制約を変更できます。

この制約を構成するには、次の値を設定します。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: カスタム
  • ポリシータイプ: 拒否
  • カスタム値: IS:EXTERNAL

VM インスタンスに対して許可されている外部 IP を定義する

デフォルトでは、個々の VM インスタンスは外部 IP アドレスを取得できます。これにより、インターネットとの送信と受信の両方の接続が可能になります。

[VM インスタンスに対して許可されている外部 IP を定義する] 制約を適用すると、VM インスタンスで外部 IP アドレスを使用できなくなります。個々の VM インスタンスで外部 IP アドレスを必要とするワークロードの場合、フォルダまたはプロジェクトのレベルで制約を変更して個々の VM インスタンスを指定します。または、関連するプロジェクトの制約をオーバーライドできます。

  • 適用先: カスタマイズ
  • ポリシーの適用: 置換
  • ポリシーの値: すべて拒否

VPC 外部 IPv6 の使用を無効にする

[VPC 外部 IPv6 の使用を無効にする] 制約を True に設定すると、VM インスタンスの外部 IPv6 アドレスを設定した VPC サブネットを構成できなくなります。

  • 適用先: カスタマイズ
  • 適用: オン

デフォルト ネットワークの作成を無効にする

新しいプロジェクトが作成されると、デフォルトの VPC が自動的に作成されます。これは、特定のネットワーク構成または大規模なエンタープライズ ネットワークとの統合を必要としない迅速なテストに役立ちます。

[デフォルトのネットワークの作成をスキップする] 制約を構成して、新しいプロジェクトのデフォルトの VPC 作成を無効にします。必要に応じて、プロジェクト内にデフォルト ネットワークを手動で作成できます。

  • 適用先: カスタマイズ
  • 適用: オン

ファイアウォール ルールを設計する

ファイアウォール ルールによって、定義した構成に基づいて、VM へのまたは VM からのトラフィックを許可または拒否できます。階層型ファイアウォール ポリシーは組織とフォルダのレベルで実装され、ネットワーク ファイアウォール ポリシーはリソース階層の VPC ネットワーク レベルで実装されます。これらがまとまって、ワークロードを保護するうえで重要な機能を提供します。

ファイアウォール ポリシーが適用される場所に関係なく、ファイアウォール ルールを設計、評価する際は、次のガイドラインに従ってください。

  • 最小権限(マイクロセグメンテーションとも呼ばれる)の原則を実装します。デフォルトでは、すべてのトラフィックをブロックし、必要な特定のトラフィックのみを許可します。これには、各ワークロードに必要なプロトコルとポートのみにルールを制限することも含まれます。
  • ファイアウォールの動作に関する可視性を確保するために、ファイアウォール ルールのロギングを有効にし、ファイアウォール インサイトを使用します。
  • ファイアウォール ルールの優先度を割り振る際の番号付け方法を定義します。たとえば、インシデント対応時に必要となるルール用に、各ポリシーに一連の小さい数値を予約しておくことをおすすめします。また、より具体的なルールが一般的なルールよりも優先されるようにして、具体的なルールが一般的なルールによってシャドーイングされないようにすることもおすすめします。次の例は、ファイアウォール ルールの優先度に対して考えられるアプローチを示しています。

ファイアウォール ルールの優先度の範囲

目的

0~999

インシデント対応用に予約済み

1,000~1,999

常にブロックされるトラフィック

2,000~1,999,999,999

ワークロード固有のルール

2,000,000,000~2,100,000,000

キャッチオール ルール

2,100,000,001~2,147,483,643

予約済み

階層型ファイアウォール ポリシーを構成する

階層型ファイアウォール ポリシーを使用すると、組織全体で一貫したファイアウォール ポリシーを作成して適用できます。階層型ファイアウォール ポリシーの使用例については、階層型ファイアウォール ポリシーの例をご覧ください。

階層型ファイアウォール ポリシーを定義して、次のネットワーク アクセス制御を実装します。

  • TCP 転送用の Identity-Aware Proxy(IAP)。TCP 転送用の IAP は、TCP ポート 22 と 3389 の IP 範囲 35.235.240.0/20 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーによって許可されます。
  • Cloud Load Balancing のヘルスチェック。ヘルスチェックに使用される広く知られた範囲を使用できます。
    • ほとんどの Cloud Load Balancing インスタンス(内部 TCP / UDP ロード バランシング、内部 HTTP(S) ロード バランシング、外部 TCP プロキシ ロード バランシング、外部 SSL プロキシ ロード バランシング、HTTP(S) ロード バランシングなど)では、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16 と 130.211.0.0/22 からの上り(内向き)トラフィックを許可するセキュリティ ポリシーを定義します。
    • ネットワーク ロード バランシングでは、ポート 80 と 443 に対して IP 範囲 35.191.0.0/16、209.85.152.0/22、209.85.204.0/22 からの上り(内向き)トラフィックを許可することで、レガシー ヘルスチェックを有効にするセキュリティ ポリシーを定義します。

VPC 環境を構成する

トランジット VPC は、ワークロードのスポーク VPC ネットワークとオンプレミスまたはマルチクラウドのネットワーク間の接続を可能にするネットワーク リソースを提供します。

  1. トランジット VPC ネットワーク用の新しいプロジェクトを作成します。
  2. プロジェクトで Compute Engine API を有効にします。
  3. カスタムモードのトランジットの VPC ネットワークを作成します。
  4. ハブ VPC またはオンプレミス環境で実行するサービスを公開する予定の各リージョンに Private Service Connect サブネットを作成します。IP アドレス指定プランの決定の際は、Private Service Connect サブネットのサイズ設定を検討してください。
  5. Google Cloud で実行しているワークロードに公開するオンプレミス サービスごとに、内部 HTTP(S) または TCP プロキシ ロードバランサを作成し、Private Service Connect を使用してサービスを公開します。
  6. トランジット VPC 用の Google API 対応 Private Service Connect を構成します。

ハイブリッド接続を構成する

ランディング ゾーンへのハイブリッド接続を提供するには、Dedicated Interconnect、Partner Interconnect、または Cloud VPN を使用できます。以下の手順によって、この設計オプションに必要な最初のハイブリッド接続リソースが作成されます。

  1. Dedicated Interconnect を使用する場合は、次の手順を実施します。Partner Interconnect または Cloud VPN を使用する場合は、これらの手順をスキップできます。
    1. 物理相互接続ポートごとに別々のプロジェクトを作成します。
    2. プロジェクトで Compute Engine API を有効にします。
    3. Dedicated Interconnect 接続を作成します。
  2. VPC ネットワークで、ハイブリッド接続を終端するリージョンごとに、次のようにします。
    1. 2 つの Dedicated または Partner の VLAN アタッチメントを、エッジ アベイラビリティ ゾーンごとに 1 つ作成します。このプロセスの一環として Cloud Router を選択し、BGP セッションを作成します。
    2. ピア ネットワーク(オンプレミスまたは他のクラウド)のルーターを構成します。

ワークロード プロジェクトを構成する

ワークロードごとに別々の VPC を作成します。

  1. ワークロードをホストするための新しいプロジェクトを作成します。
  2. プロジェクトで Compute Engine API を有効にします。
  3. カスタムモードの VPC ネットワークを作成します。
  4. ワークロードをデプロイするリージョンにサブネットを作成します。サブネットごとに限定公開の Google アクセスを有効にして、内部 IP アドレスのみを持つ VM インスタンスが Google サービスに到達できるようにします。
  5. Google API 用の Private Service Connect を構成します。
  6. 別の VPC またはオンプレミス環境から取り込むワークロードごとに、Private Service Connect コンシューマ エンドポイントを作成します。
  7. 別の VPC またはオンプレミス環境用に生成するワークロードごとに、サービスの内部ロードバランサとサービス アタッチメントを作成します。IP アドレス指定プランの決定の際は、Private Service Connect サブネットのサイズ設定を検討してください。
  8. サービスにオンプレミス環境から到達可能でなければならない場合は、トランジット VPC に Private Service Connect コンシューマ エンドポイントを作成します。

Cloud NAT を構成する

特定のリージョンのワークロードが、たとえばソフトウェア パッケージやアップデートをダウンロードするなど、送信インターネット アクセスを必要とする場合は、次の手順を実施します。

  1. ワークロードにインターネットへの送信アクセスが必要となるリージョンに Cloud NAT ゲートウェイを作成します。必要に応じて、特定のサブネットからの送信接続のみを許可するように、Cloud NAT 構成をカスタマイズできます。
  2. 少なくとも、ゲートウェイで ERRORS_ONLY をログに記録できるように、Cloud NAT ロギングを有効にします。Cloud NAT によって実行された変換のログを含めるには、各ゲートウェイが ALL をログに記録するように構成します。

オブザーバビリティを構成する

Network Intelligence Center は、クラウド ネットワーキング環境をモニタリング、トラブルシューティング、可視化する包括的な方法を提供します。それを使用して、設計が目的のインテントで確実に機能するようにします。

次の構成により、ロギングと指標の分析に対応できます。

  • 接続テストを実行する前に、Network Management API を有効にする必要があります。API を直接使用する場合、または Google Cloud CLI あるいは Google Cloud コンソールを使用する場合は、この API を有効にする必要があります。
  • ファイアウォール インサイトを使用してタスクを実行するには、Firewall Insights API を有効にする必要があります。

次のステップ

これで、このネットワーク設計オプションの初期構成が完了しました。これらの手順を繰り返して、ランディング ゾーン環境の追加インスタンス(ステージング環境や本番環境など)を構成することも、引き続き Google Cloud ランディング ゾーンのセキュリティを決定する手順に沿うこともできます。

次のステップ