クラウド ID、リソース階層、ランディング ゾーン ネットワークを設計してオンボーディングするときは、Google Cloud のランディング ゾーンの設計に記載されている設計推奨事項とエンタープライズ基盤のブループリントに記載されている Google Cloud セキュリティのベスト プラクティスを考慮してください。選択したデザインを、次のドキュメントに照らし合わせて検証してください。
- VPC 設計のためのおすすめの方法とリファレンス アーキテクチャ
- Google Cloud ランディング ゾーンのリソース階層を決定する
- Google Cloud アーキテクチャ フレームワーク: セキュリティ、プライバシー、コンプライアンス
次に示す一般的なベスト プラクティスも考慮してください。
ハイブリッドまたはマルチクラウドのネットワーク接続性オプションを選択するときは、ビジネスとアプリケーションの要件（SLA、パフォーマンス、セキュリティ、コスト、信頼性、帯域幅など）を考慮してください。詳細については、Network Connectivity プロダクトの選択と他のクラウド サービス プロバイダを Google Cloud に接続するためのパターンをご覧ください。
複数の VPC を使用するのではなく Google Cloud での共有 VPC を使用します（このことが実際のリソース階層設計の要件に沿っていて適切である場合）。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。
アカウントと組織の計画に関するベスト プラクティスに従います。
該当する場合は、環境間に共通の ID を確立します。これでシステムが環境の境界を越えて安全に認証を行うことができます。
ハイブリッド セットアップでアプリケーションを社内ユーザーに安全に公開するために、および要件に最も適したアプローチを選択するために、推奨される方法に従って Google Cloud と既存の ID 管理システムを統合する必要があります。
- ハイブリッド環境で従業員ユーザーを認証するパターンもご覧ください。
オンプレミスとクラウドの環境を設計するときは、IPv6 アドレッシングを早くから検討するとともに、どのサービスでサポートされるかを考慮に入れてください。詳細については、Google Cloud での IPv6 の概要をご覧ください。この記事では、ブログの執筆時点でサポートされていたサービスがまとめられています。
VPC ファイアウォール ルールを設計、デプロイ、管理するときに、次のことができます。
- ファイアウォール ルールを VM に適用する方法を厳密に制御する必要がある場合は、ネットワーク タグに基づくフィルタリングではなくサービス アカウントに基づくフィルタリングを使用します。
- 複数のファイアウォール ルールをグループ化するときは、ファイアウォール ポリシーを使用します。これで、すべてを一度に更新できます。ポリシーを階層化することもできます。階層型ファイアウォール ポリシーの仕様と詳細については、階層型ファイアウォール ポリシーをご覧ください。
- 外部 IPv4 と外部 IPv6 のトラフィックを特定の地理的位置またはリージョンに基づいてフィルタリングする必要があるときに、ファイアウォール ポリシーの中で位置情報オブジェクトを使用します。
- ファイアウォール ポリシールールの脅威インテリジェンスを使用すると、脅威インテリジェンス データ（既知の悪意のある IP アドレスなど）に基づいて、またはパブリック クラウド IP アドレス範囲に基づいてトラフィックを許可またはブロックするという方法で、ネットワークを保護することができます。たとえば、自分のサービスが特定のパブリック クラウドのみと通信する必要がある場合に、そのパブリック クラウド IP アドレス範囲からのトラフィックを許可できます。詳細については、ファイアウォール ルールのベスト プラクティスをご覧ください。
クラウドとネットワークのセキュリティを設計するときは常に、多層セキュリティのアプローチを使用する必要があります。具体的には、次のような追加のセキュリティ レイヤを検討してください。
- Google Cloud Armor
- Cloud Intrusion Detection System
- Cloud Next Generation Firewall IPS
- ファイアウォール ポリシールールの脅威インテリジェンス
これらの追加レイヤによって、さまざまな脅威のフィルタリング、検査、モニタリングをネットワーク レイヤとアプリケーション レイヤで行い、分析と防止に利用することができます。
ハイブリッド セットアップで DNS 解決をどこで行うかを決定するときは、2 つの権威 DNS システムを使用することをおすすめします。一つはプライベート Google Cloud 環境用、もう一つはオンプレミス環境内の既存の DNS サーバーによってホストされるオンプレミス リソース用です。詳細については、DNS 解決を実行する場所を選択するをご覧ください。
可能であれば、アプリケーションの公開は常に API を通して行い、これには API ゲートウェイまたはロードバランサを使用します。Apigee などの API プラットフォームを検討することをおすすめします。Apigee は、バックエンド サービス API の抽象化またはファサードとしての役割を果たすものであり、さらにセキュリティ、レート制限、割り当て、分析の機能も備えています。
API プラットフォーム（ゲートウェイまたはプロキシ）とアプリケーション ロードバランサは相互に排他的ではありません。時には、API ゲートウェイとロードバランサを併用することによって、API トラフィックの管理と分散を大規模に行うための堅牢でセキュリティに優れたソリューションを実現できる可能性があります。Cloud Load Balancing API ゲートウェイを使用すると、次のことを達成できます。
Apigee と Cloud CDN を使用して高パフォーマンス API をデリバリーすることによって、次のことを実現します。
- レイテンシを短縮する
- API をグローバルにホストする
トラフィックのピークシーズンに可用性を高める
詳細については、Apigee と Cloud CDN を使用した高パフォーマンス API のデリバリーについての YouTube の動画をご覧ください。
高度なトラフィック管理を実装します。
Google Cloud Armor を DDoS 対策、WAF、ネットワーク セキュリティ サービスとして使用して API を保護します。
複数のリージョンにあるゲートウェイ間の効率的なロード バランシングを管理します。詳細については、PSC と Apigee を使用して API を保護し、マルチリージョン フェイルオーバーを実装することについての動画をご覧ください。
使用する Cloud Load Balancing プロダクトを決定するには、まず、ロードバランサが処理するトラフィック タイプを決定する必要があります。詳細については、ロードバランサを選択するをご覧ください。
Cloud Load Balancing を使用するときは、そのアプリケーション処理能力最適化の機能を使用してください（該当する場合）。このようにすると、グローバルに分散したアプリケーションで発生する可能性のある、処理能力の課題にある程度対処できます。
- レイテンシに関する詳しい解説については、ロード バランシングによるアプリケーション レイテンシの最適化をご覧ください。
Cloud VPN では環境間のトラフィックが暗号化されますが、Cloud Interconnect を使用するときは、接続レイヤで転送中のトラフィックを暗号化するために、MACsec を使用するか、Cloud Interconnect を介した HA VPN を使用する必要があります。詳細については、Cloud Interconnect 経由のトラフィックを暗号化するにはどうすればよいですか？をご覧ください。
- TLS を使用するサービスレイヤ暗号化も検討してください。詳細については、転送データの暗号化に関するコンプライアンス要件を満たす方法を決定するをご覧ください。
VPN ハイブリッド接続を通過する必要のあるトラフィックが、単一の VPN トンネルでサポートできる量よりも多い場合は、アクティブ / アクティブの HA VPN ルーティング オプションの使用を検討してください。
- 長期的なハイブリッドまたはマルチクラウド セットアップのアウトバウンド データ転送量が多い場合は、Cloud Interconnect または Cross-Cloud Interconnect を検討してください。これらの接続オプションは、接続パフォーマンスの最適化に役立つとともに、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を縮小できる可能性があります。詳しくは、Cloud Interconnect の料金をご覧ください。
Google Cloud のリソースに接続するときに、Cloud Interconnect、ダイレクト ピアリング、キャリア ピアリングのいずれかの選択を考えている場合は、Google Workspace のアプリケーションにアクセスする必要がなければ Cloud Interconnect を使用することをおすすめします。詳細については、ダイレクト ピアリングと Cloud Interconnect の機能比較とキャリア ピアリングと Cloud Interconnect の機能比較をご覧ください。
クラウドでホストされているシステムに対応するために十分な IP アドレス空間を、既存の RFC 1918 IP アドレス空間から確保します。
技術的な制限が理由で現在の IP アドレス範囲を維持する必要がある場合は、次の方法を取ることができます。
オンプレミス ワークロードの内部 IP アドレスは、そのワークロードを Google Cloud に移行する間も同じものを使用します。これにはハイブリッド サブネットを使用します。
Google Cloud のリソース用に、お客様が所有するパブリック IPv4 アドレスをプロビジョニングして使用します。これには Google へのお客様所有 IP アドレス持ち込み（BYOIP）を使用します。
ソリューションの設計の要件として、Google Cloud ベースのアプリケーションをパブリックのインターネットに公開することが求められている場合は、インターネットに接続するアプリケーションの配信のためのネットワーキングでご紹介している設計推奨事項を検討してください。
該当する場合は、Private Service Connect エンドポイントを使用します。これで Google Cloud やオンプレミスの、またはその他のハイブリッド接続を使用するクラウド環境のワークロードが、Google API または公開サービスにプライベート アクセスできるようになります。これには内部 IP アドレスが使用され、粒度の高い管理が可能です。
Private Service Connect を使用するときは、次のことを制御する必要があります。
- 誰が Private Service Connect のリソースをデプロイできるか。
- 接続をコンシューマーとプロデューサーの間で確立できるかどうか。
- どのネットワーク トラフィックにその接続へのアクセスを許可するか。
詳細については、Private Service Connect のセキュリティをご覧ください。
ハイブリッドとマルチクラウドのアーキテクチャにおいて堅牢なクラウド セットアップを実現するには:
- さまざまなアプリケーションにどの程度の信頼性が求められるかについての評価を、すべての環境にわたって包括的に実施します。このことは、可用性とレジリエンスの目標達成に役立ちます。
- 利用するクラウド プロバイダの信頼性能力と設計原則を理解します。詳細については、Google Cloud インフラストラクチャの信頼性をご覧ください。
クラウド ネットワークの可視性とモニタリングは、信頼性の高い通信を維持するために不可欠です。Network Intelligence Center を利用すると、単一のコンソールでネットワークの可視性、モニタリング、トラブルシューティングを管理できます。