Google PCNE: Google およびマネージド サービスへのプライベート接続 — 学習ガイド
こちらの一部です： Google Professional Cloud Network Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
概要
Googleおよびマネージドサービスへのプライベート接続は、ワークロードがパブリックIPを使用せずにGoogle API、Googleが管理するプロデューサーネットワーク、およびサードパーティサービスと通信できるようにするパターンを包含します。その目的は、トラフィックをプライベートパスに維持することで、データ漏洩リスクを低減し、コンプライアンスを簡素化し、予測可能性を向上させることです。中心的な構成要素には、Private Google Access（および制限付きエンドポイント）、Private Services Access（GoogleマネージドサービスへのプライベートIP用）、Private Service Connect（Google APIを含む、プロデューサーとコンシューマー間のプライベートサービスの公開と利用）、VPC Service Controls（データ境界）、Cloud NAT（プライベートからパブリックインターネットへのアウトバウンド）、および決定論的なエンドポイント選択のためのDNSマッピングが含まれます。
設計を成功させるには、次の3つの決定が重要です。
- どのプライベートアクセスメカニズムがサービスとセキュリティモデルに一致するか（Google APIにはPGAかPSCか、マネージドサービスやパートナーサービスにはPSAかPSCか）。
- サポートされていないサービスを壊すことなく、サービス名をプライベートターゲットに解決するためにDNSをどのように設定すべきか。
- 障害や変更が発生した場合でもトラフィックがエンドツーエンドでプライベートに保たれるように、ルーティングと境界ポリシーがどのように相互作用するか。
一般的な障害モードは、ルート選択、DNSの順序、エンドポイントのリージョン範囲、または呼び出しを暗黙的に拒否する境界ルールに起因します。名前解決、ルート、ファイアウォール、エンドポイントのヘルス、サービスポリシーの各レイヤーを検証してください。
Private Google Access、制限付きエンドポイント、およびエンドポイント選択
Private Google Access (PGA) は、外部IPを持たないVMやGKEノードが、Cloud NAT経由ではなく、VPCのデフォルトインターネットゲートウェイを介してGoogleのエニーキャストVIPを使用し、Google APIやサービスにアクセスできるようにします。これはサブネットごとに有効化されます。
エンドポイント:
- private.googleapis.com (199.36.153.8/30): すべてのGoogle APIサーフェス。
- restricted.googleapis.com (199.36.153.4/30): VPC Service Controlsと互換性のあるAPIのサブセット。サービス境界を適用する場合にこれを使用します。
DNSマッピングのアプローチ:
- デフォルトのパブリック名を維持し、クライアントがパブリックDNSにアクセスできるようにします。これはCloud NAT経由のアウトバウンドを許可する場合には機能しますが、データ漏洩の制御を弱めます。
- Cloud DNSのプライベートゾーンでgoogleapis.comの特定のAPIホスト名をオーバーライドし、CNAMEをrestricted.googleapis.com（またはprivate.googleapis.com）に向けて、サービスごとのプライベートな名前解決を強制します。 例：プライベートゾーンgoogleapis.comを作成し、storage.googleapis.com CNAME restricted.googleapis.comを追加します。
ルーティングに関する考慮事項:
- PGAは、デフォルトインターネットゲートウェイへのルートを必要とします。0.0.0.0/0をサードパーティのNGFWに送信する場合、Google APIのVIPがデフォルトインターネットゲートウェイを使用するように、明示的なホストルートを追加します。
undefined
障害モード：これらのホストルートがない場合、0.0.0.0/0のネクストホップがファイアウォールインスタンスであると、外部IPを持たないインスタンスはAPIに到達できません。
サブネットの設定:
undefined
トレードオフ:
- restricted.googleapis.comはデータ漏洩リスクを低減しますが、一部のAPIは利用できません。
- PGAトラフィックはCloud NATをバイパスするため、NATロギングには表示されません。サブネットでVPCフローログを使用してください。
オンプレミスのクライアント向けには、VPC内のネクストホップをデフォルトインターネットゲートウェイとして、Cloud VPN/Interconnect経由でオンプレミスに199.36.153.4/30や199.36.153.8/30をアドバタイズするか、あるいはPSCエンドポイント（後述）を公開し、オンプレミスのDNSをそれらのエンドポイントにマッピングすることで、Google APIへのプライベートアクセスを提供できます。
Private Services Access と Private Service Connect
Private Services Access (PSA) は、Cloud SQL (プライベート IP) や Memorystore などのサービスをホストする、Google が管理するプロデューサーネットワークへのプライベート IP 接続を提供します。VPC 内で Google が使用する RFC1918 範囲を割り当て、サービスプロデューサーネットワークへのピアリング接続を確立します。
セットアップパターン:
- VPC ピアリング用のアドレス範囲を予約する:
gcloud compute addresses create google-managed-services-range
–global –purpose=VPC_PEERING –prefix-length=24 –network=VPC - プライベート接続を確立する:
gcloud services vpc-peerings connect
–service=servicenetworking.googleapis.com –network=VPC
–ranges=google-managed-services-range - マネージドサービスをプライベート IP でプロビジョニングする。
- VPC ピアリング用のアドレス範囲を予約する:
gcloud compute addresses create google-managed-services-range
運用上の注意点:
- 範囲はすべてのインスタンスに対して十分に大きく、既存の範囲と重複してはなりません。
- ピアリングは推移的ではありません。トラフィックはピアリングされた VPC から発信される必要があります (ルーティングが許可されていれば、オンプレミスから VPC を経由して到達できます)。
- 後から範囲を変更または縮小すると中断を伴います。容量を計画してください。
Private Service Connect (PSC) は、プライベート接続を以下に拡張します:
- Google API (コンシューマーがサブネット内にプライベート IP を持つエンドポイントを作成し、DNS が API 名をそれらの IP にマッピングします)。
- サービスアタッチメントを介して公開されるパートナーおよび SaaS サービス。
- サービスアタッチメントを介して他のプロジェクトや組織にプライベートに公開される独自のサービス。
プロデューサー・コンシューマーモデル:
- プロデューサーは、内部ロードバランサーに支えられたサービスアタッチメントをリージョンに公開します。プロデューサーは、コンシューマーのプロジェクト/組織の許可リストを要求したり、接続クォータを指定したりできます。
- コンシューマーは、プロデューサーのサービスアタッチメントをターゲットとして、同じリージョンに PSC エンドポイント (転送ルール) を作成します。エンドポイントは、選択されたサブネットから IP を取得します。
設計上の制約とトレードオフ:
- PSC はリージョン単位です。コンシューマーに近いリージョンごとにデプロイします。DNS ポリシーまたは加重レコードを使用して、近くのクライアントを誘導し、フェイルオーバーを提供します。
- PSC には推移性がありません。コンシューマーはエンドポイントを介してサービスを連鎖させることはできません。
- PSC を介したエンドツーエンドで送信元 IP は保持されません。これを念頭に置いて、プロデューサー側の制御を設計します (例: ID またはアプリケーションレベルの認可に依存する)。
一般的な障害モード:
- プロデューサーの ILB のヘルスチェックが失敗すると、PSC 接続が拒否されます。
- コンシューマーエンドポイントがサービスアタッチメントとは異なるリージョンに作成される。
- プロデューサーの拒否ポリシーまたはプロジェクト許可リストの欠如により、接続がブロックされる。
- DNS がエンドポイント IP を指していない、または重複するプライベートゾーンが間違った宛先に解決される。
VPC Service Controls、境界、上り/下り、DNS マッピング
VPC Service Controls (VPC-SC) は、Google が管理するリソースの周りにサービス境界を定義し、データ漏洩を緩和します。境界内では、保護されたサービスへのリクエストはスコープ内のプロジェクトから発信され、設定されたアクセスレベルを満たす必要があります。
境界:
- 標準境界は、データをホストするプロジェクト (例: BigQuery, Cloud Storage) を保護します。
- 境界ブリッジは、本来は分離されている境界間の限定的な相互作用を許可します。
- 上り (ingress) ルールは、境界外からの特定のアクセス (例: CI/CD やモニタリングプロジェクトから) を許可します。
- 下り (egress) ルールは、呼び出し可能な外部サービスまたは Google Cloud 内のプロジェクトを制限します。
エンドポイントの選択:
- restricted.googleapis.com を使用して、API 呼び出しを VPC-SC 互換サービスに限定し、境界を認識しないパブリックエンドポイントへの意図しない呼び出しを回避します。
- Google API 向けの PSC は、トラフィックをプライベート IP 上に保持し、リージョンアフィニティを有効にすることでより強力な制御を提供しますが、認可のためには依然として境界の設定が必要です。
DNS と名前解決:
- Cloud DNS プライベートゾーンを使用してスプリットホライズン DNS を実装し、内部クライアントが API 名をプライベートターゲットに解決するようにします。
- googleapis.com 全体をワイルドカードで指定するのではなく、サービスごとのレコードまたは restricted.googleapis.com への CNAME を使用することを推奨します。ワイルドカードを使用すると、パブリックのままである必要があるサービスが破損する可能性があります。
- PSC の場合、各エンドポイントの IP を指す A レコードを公開します。環境ごとに個別のゾーンを使用して、環境間の意図しない利用を防ぎます。
落とし穴:
- Cloud NAT を使用してパブリックな googleapis.com にアクセスすると、境界ルールが下り (egress) を明示的に制約しない限り、VPC-SC の意図をバイパスする可能性があります。NAT を制限付き DNS または PSC と組み合わせてください。
- 一部の API には複数のホスト名があります (例: JSON vs XML エンドポイント)。DNS マッピングがクライアントが使用するすべての名前をカバーしていることを確認してください。
- 境界の設定ミスはフェイルクローズします (通信が拒否されます)。Access Transparency と VPC-SC のログを監視して、拒否を検出してください。
アウトバウンドパターン、ハイブリッドアクセス、トラブルシューティング
プライベートワークロードのアウトバウンドパターン:
- Google API のみ: PGA を有効にして DNS を restricted.googleapis.com にマッピングするか、Google API 用の PSC をデプロイして DNS をエンドポイントの IP にマッピングします。
- インターネットと SaaS: 外部 IP を持たないインスタンスには Cloud NAT を使用します。ピーク時の同時接続数とポート数に合わせて NAT のサイズを決定し、ポートの枯渇を監視します。
- サードパーティ NGFW との混在: NGFW をデフォルトとして維持しつつ、PGA がファイアウォールをバイパスするように、Google API のエニーキャスト VIP への特定のホストルートを追加します。Google 以外の宛先については、ポリシーに従って NGFW または Cloud NAT に送信します。
ハイブリッドクライアント（オンプレミスまたは他のクラウド）:
- Google API をプライベートに利用する場合:
- オプション A: VPC のネクストホップをデフォルトインターネットゲートウェイとして、Cloud Router からオンプレミスに 199.36.153.4/30 や 199.36.153.8/30 をアドバタイズすることで、オンプレミス向けの Private Google Access を実現します。必要に応じて、オンプレミスの DNS を restricted/private.googleapis.com にマッピングします。
- オプション B: VPC 内に Google API 用の PSC エンドポイントを作成し、エンドポイントの IP へのルーティングとオンプレミス DNS の適切なマッピングにより、Cloud VPN/Interconnect 経由で公開します。
- プライベート IP を持つ Google マネージドサービス（PSA 経由）にアクセスするには、VPC への接続（Cloud VPN/Interconnect）を確立し、RFC1918 の範囲が重複しないことを確認し、ルートを伝播させ、ファイアウォールルールで許可します。
トラブルシューティングと検証:
- DNS: クライアントから API ホスト名を
digまたはnslookupし、意図したプライベートアドレス（PSC エンドポイント IP）または restricted/private のエニーキャスト VIP に解決されることを確認します。VPC の Cloud DNS ポリシーの順序とプライベートゾーンをチェックします。 - ルーティング:
gcloud compute routes listを実行し、最も具体的なルートが意図したネクストホップ（PGA VIP の場合はデフォルトインターネットゲートウェイ、PSC の場合は内部）と一致することを確認します。 - ファイアウォール: Egress ルールがターゲット IP への TCP 443 を許可していることを確認します。PSC の背後にある負荷分散されたプロデューサーについては、ヘルスチェックのソース範囲が許可されていることを確認します。
- PGA: サブネットの設定が有効になっていること、およびカスタムのデフォルトルートが設定されている場合に 199.36.153.4/30 や 199.36.153.8/30 のホストルートが存在することを確認します。
- PSA:
gcloud services vpc-peerings listを実行し、servicenetworking ピアリングが ACTIVE であり、割り当てられた範囲が正しく、他で使用されていないことを確認します。 - PSC: コンシューマー側でエンドポイントを describe して接続ステータスを確認します。プロデューサー側では、保留中または拒否された接続と ILB のヘルス状態をチェックします。サービスアタッチメントのコンシューマー許可リストを確認します。
- Cloud NAT: NAT のロギングとメトリクスを使用して変換を確認し、ポートの割り当てや枯渇をチェックします。インスタンスが外部 IP を持っている場合、設計上 NAT をバイパスします。
実践的な問題シナリオ
Contoso Research は 2 つのリージョン（us-east1, europe-west1）で分析を実行しています。セキュリティ要件として、VM はパブリック IP を持たず、Google API はプライベートに、かつ VPC Service Controls の下で到達可能である必要があり、オンプレミスのユーザーは Cloud SQL インスタンス（プライベート IP）へのプライベートアクセスを必要とし、パートナーの SaaS はプライベートに利用する必要があります。サードパーティの NGFW がデフォルトの Egress ネクストホップです。
- Private Google Access と制限付きエンドポイントの有効化
- アクション: すべての分析用サブネットで Private Google Access を有効にします。googleapis.com 用の Cloud DNS プライベートゾーンを作成し、必要な API（BigQuery, Pub/Sub, Cloud Storage）の CNAME を restricted.googleapis.com に追加します。両方のリージョンで、199.36.153.4/30 へのホストルートをデフォルトインターネットゲートウェイに追加します。
- 理論的根拠: VM から API へのトラフィックがプライベートに保たれ、VPC-SC と互換性があり、広範なインターネット Egress を作成することなく NGFW をバイパスすることを保証します。
- VPC Service Controls ペリメータの作成
- アクション: 分析プロジェクトとデータプロジェクトをサービスペリメータ内に配置します。必要に応じて Contoso の企業ネットワーク用のアクセスレベルを追加し、必要なプロジェクト間のフローを Ingress ルールで明示的に許可します。厳密に正当化される場合を除き、ペリメータブリッジは避けます。
- 理論的根拠: Google マネージドサービスからのデータ漏洩リスクを低減し、制限付きエンドポイントの使用法と整合させます。
- Private Services Access を使用した Cloud SQL のプロビジョニング
- アクション: PSA 用に /24 を割り当て、servicenetworking を接続し、us-east1 にプライベート IP を持つ Cloud SQL インスタンスを作成します。Interconnect を介して VPC ルートをオンプレミスに伝播させ、ファイアウォールルールで許可します。
- 理論的根拠: VPC ワークロードとオンプレミスクライアントの両方から、パブリックに公開することなく、プライベートな RFC1918 での到達可能性を提供します。
- オンプレミスから Google API へのプライベートアクセスの提供
- アクション: VPC のネクストホップをデフォルトインターネットゲートウェイとして、Cloud Router からオンプレミスに 199.36.153.4/30 をアドバタイズします。オンプレミスの DNS で、同じ API ホスト名を restricted.googleapis.com にマッピングします。
- 理論的根拠: オンプレミスクライアントが同じ制限付きプライベートパスを使用できるようにし、一貫したポリシー適用を保証し、運用上の差異を最小限に抑えます。
- Private Service Connect を介したパートナー SaaS の利用
- アクション: パートナーがリージョナルなサービスアタッチメントを共有します。us-east1 と europe-west1 のサブネットに、そのアタッチメントをターゲットとする PSC エンドポイントを作成します。各リージョナルエンドポイントを指すプライベート A レコード（saas.partner.contoso）を公開し、重み付け DNS を使用してリージョナルアクセスを優先させます。
- 理論的根拠: SaaS トラフィックをプライベート IP 上に保ち、プロデューサーが強制するプロジェクト許可リストを使用し、リージョナルアフィニティによってレイテンシを改善し、パブリック Egress を回避します。
- Google 以外のインターネット Egress のために Cloud NAT を維持
- アクション: ピークフローに合わせてサイズ設定されたリージョンごとの Cloud NAT ゲートウェイをデプロイします。特定の制限付き VIP ホストルートを除き、デフォルトルートが引き続き NGFW を指していることを確認します。
- 理論的根拠: Google API トラフィックをプライベートに保ち、NGFW が中心的な可視性を維持しながら、Google 以外の宛先への制御されたアウトバウンドを許可します。
- 検証と監視
- アクション: 各クライアントタイプについて、DNS 解決、ルート選択、TLS 接続を検証します。VPC-SC ログで拒否を確認し、NAT ログで Google 以外の Egress を確認し、PSC の接続状態をチェックします。パートナーのサービスアタッチメントの背後にある ILB と Cloud SQL のヘルスおよび可用性アラートを追加します。
- 理論的根拠: データパスが設計意図と一致することを確認し、特に DNS、ルート、またはペリメータが変更された場合に、リグレッションを早期に発見します。
← Cloud DNS、サービス ディスカバリ、ハイブリッド名前解決 · すべてのドメイン · ルーティング、Network Connectivity Center、セグメンテーション →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →