VMware Engine のセキュリティのベスト プラクティス
このドキュメントでは、Google Cloud VMware Engine の管理および構成に対して推奨されるセキュリティに関するベスト プラクティスを説明し、すでに VMware Engine をすでに使い慣れているユーザーを対象としています。使い慣れていないユーザーは、前提条件と VMware Engine のセキュリティについて学ぶことも検討してください。
VMware Engine には、セキュリティの責任共有モデルがあります。クラウドでの信頼できるセキュリティは、サービス プロバイダとしての Google とお客様との責任の共有によって達成されます。ここで紹介するベスト プラクティスに従うことで、お客様は時間を節約できるほか、エラーを防止し、障害点の影響を軽減できます。
VMware Engine のネットワーキング
以降のセクションでは、VMware Engine 環境でのネットワーキングのベスト プラクティスについて説明します。
環境のすべてのトラフィック フローを特定して把握する
VMware Engine は、VMware Engine ネットワークと VPC ピアリングを利用して、VMware Engine プライベート クラウド ネットワークから VPC ネットワークにプライベート ネットワーク接続を確立します。Google Cloud 環境の VPC からの上り（内向き）トラフィックや、オンプレミス ネットワークからの上り（内向き）トラフィックは、Google 管理のテナンシー ユニット ネットワークを通過します。
インターネット データ転送に VMware Engine のパブリック IP サービスを使用する
インターネット トラフィックは、VMware Engine のパブリック IP サービスを使用して、プライベート クラウドに直接入ることができます。あるいは、Google Cloud のパブリック ロードバランサを使用して入ることもできます。その場合、トラフィックは他の上り（内向き）トラフィックと同じようにルーティングされます。この 2 種類の方法は併用できませんのでご注意ください。Google Cloud 環境で、セントラル インスタンスまたはサービスによる URL フィルタリング、IPS / IDS、トラフィック検査など、インターネット トラフィックのカスタム制御が必要な場合は、インターネットに向かうトラフィックをご使用の VPC ネットワーク経由で転送する必要があります。
これが当てはまらない場合や、プライベート クラウド内に制御が実装されている場合は、VMware Engine に外部 IP アドレス サービスを含めることをおすすめします。また、外部アクセスルールを使用して、アプリケーションで使用しないインターネットからのトラフィック パターンは拒否することをおすすめします。
VMware Engine NSX-T のゲートウェイと分散ファイアウォールで North-South ファイアウォール ルールと East-West ファイアウォール ルールを分離する
Tier-1 論理ルーターの NSX-T で分散ファイアウォール（DFW）を構成して、仮想レイヤ 2 ドメイン間で内部トラフィックをセグメント化します。NSX DFW は、セグメント間の（内部）East-West ネットワーク トラフィックを処理するように設計されており、セグメント内の個々のインスタンス間のトラフィックを許可または拒否するファイアウォール ルールを許可します。
ネットワークのきめ細かいアクセス制御を行うには、デフォルトでインスタンス間のネットワーク トラフィックを拒否するために、DFW に制限付きのデフォルト ポリシーを適用してください。DFW を使用して、アプリケーション間やアプリケーション内のサービス間のトラフィックを明確に許可します。
NSX ゲートウェイ ファイアウォールを構成して、プライベート クラウドに出入りする North-South トラフィックを制御します。
NSX ゲートウェイ ファイアウォールは、North-South トラフィックを制御するように設計されており、別のセキュリティ ゾーンへの境界でのトラフィックの制御などのユースケースに推奨されます。プライベート クラウド全体の North-South トラフィックを整合性をもって構成する必要がある場合は、tier-0 ルーターにゲートウェイ ファイアウォールを構成します。個々の NSX-T セグメントごとに North-South トラフィックを構成する必要がある場合は、Tier-1 ルーターでゲートウェイ ファイアウォールを構成します。
NSX-T ファイアウォールに加え、VPC ファイアウォールを利用して、VMware Engine プライベート クラウドのワークロードと VPC のワークロードの間で East-West トラフィックを許可またはブロックすることをおすすめします。VMware Engine ワークロードから Compute Engine インスタンスへの上り（内向き）データ転送は、意識的に開かれたトラフィックのみが通過するようにデフォルトで制限する必要があります。
管理アプライアンスと vSphere / vSAN CIDR 範囲への下り（外向き）データ転送も、VPC ファイアウォールを使用して VPC からブロックする必要があります。ネットワーク内の信頼できるホストと IP アドレスから管理アプライアンスへの下り（外向き）データ転送のみが通過するようにします。管理用アプライアンスは NSX-T セグメント内にないため、アクセスを制限するための DFW ルールが適用されないことに注意してください。
NSX-T でゼロトラスト セキュリティの原則とマイクロセグメンテーションを適用する
NSX-T DFW を使用して、個々の仮想マシンと同じ粒度のセキュリティ セグメントでトラフィック制御を実装します。個別の VM 間のトラフィックを保護するこの原則（デフォルトで拒否する）は、多くの場合「マイクロセグメンテーション」とも呼ばれます。これは、レイヤ 3 ドメイン間のファイアウォールの従来型の実装よりもきめ細かいファイアウォールのアプローチです。
DFW は、プライベート クラウド内のすべての VMware Engine vSphere ホスト上のハイパーバイザ カーネルで有効になり、同じ NSX セグメントまたは個別の NSX セグメントにあるワークロード間のトラフィック フローを制御できます。VM との間のトラフィックを許可するファイアウォール ルールは、VM をポリシー グループに整理することによって定義できます。ポリシー グループでは、VM タグや名前の照合などの柔軟なメンバー条件を設定できます。
マイクロ セグメンテーションを使用すると、トラフィック パターンを明示的に許可する必要がある細かいトラフィック制御を備えたネットワークを実装できます。すべてのネットワーク フローが暗黙の信頼ではなく ID とデバイスの検証プロセスによって制御されるセキュリティのコンセプトは、ゼロトラスト セキュリティとも呼ばれます。
IPS / IDS 機能のために、Cloud Marketplace ポータルからサードパーティのファイアウォール アプライアンスをデプロイする
ネットワークの他の部分からプライベート クラウドへの上り（内向き）トラフィックや NSX-T ネットワーク セグメント間のトラフィックのために IDS / IPS 機能などの高度なレイヤ 7 セキュリティが必要な場合は、サードパーティのファイアウォール アプライアンスをデプロイすることを検討してください。サードパーティ アプライアンスは、Google Cloud ネットワーク内の 2 つの VPC 間のマルチ NIC アプライアンスとして、または NSX-T と統合したプライベート クラウド内にデプロイできます。
IPS / IDS、DDoS、SSL オフロードなど、さまざまな高度なセキュリティ ユースケースに使用できる一元管理されたアプライアンスを備えた VMware Engine アーキテクチャの詳細については、Cloud アーキテクチャ センターの一元管理されたアプライアンスを使用したネットワーク セキュリティのドキュメントを確認してください。
Google Cloud Armor を使用して DDoS 攻撃から VMware Engine 上のウェブサービスを保護する
上り（内向き）トラフィックをお客様の VPC 経由で VMware Engine 上のワークロードにルーティングする場合は、ハイブリッド ネットワーク エンドポイント グループ内の VMware Engine ワークロードを Cloud Service Mesh の背後に配置し、外部 HTTP(S) ロードバランサを活用することをおすすめします。どちらの設定でも、一般向けアプリケーション用に Google Cloud Armor を含めることにより、DDoS 攻撃と SQL インジェクションやクロスサイト スクリプティングなどの一般的な脆弱性を軽減できます。
Envoy プロキシによる高度なトラフィック管理や Certificate Authority Service の統合などのサービス メッシュ機能が必要な場合は、Cloud Service Mesh をおすすめします。それ以外の場合は、外部 HTTP(S) ロードバランサをおすすめします。
次のいずれかの設定で VMware Engine ワークロードをハイブリッド NEG に追加する方法については、ドキュメントをご覧ください。
インターネット アクセスなしで限定公開で Google Cloud サービスに接続する
VMware Engine のプライベート クラウド ワークロードは、限定公開の Google アクセスを使用して Cloud Storage API などの Google Cloud API にアクセスできます。下り（外向き）データ転送の費用とレイテンシが低減するため、インターネット経由でトラフィックを送信せずに、限定公開の Google アクセスを使用して Google サービスにアクセスすることをおすすめします。これにより、Google API アクセスのみが必要なワークロードについて、インターネットへのネットワーク パスが不要になります。技術的な詳細と構成手順については、限定公開の Google アクセスの詳細をご覧ください。
同様に、Cloud SQL や Memorystore インスタンスなどのサービス プロデューサー ネットワークから Google Cloud リソースにアクセスする必要がある VMware Engine のワークロードは、PSA を使用してプライベート接続を行う必要があります。詳細については、VMware Engine の PSA に関するセクションをご覧ください。
オンプレミス環境と Google Cloud 間の通信を暗号化する
オンプレミス システムと通信する必要がある VMware Engine のワークロードは、暗号化されたチャネルを介して接続する必要があります。オンプレミスのデータセンターと Google Cloud の間での転送データの暗号化には、階層化されたアプローチをおすすめします。オンプレミス システムと Google Cloud の間のリンクは、IPsec トンネルで Cloud VPN を設定するか、Interconnect の VLAN アタッチメントで組み込みの IPsec を使用して暗号化できます。また、TLS を使用して、アプリケーション コンポーネント間のアプリケーション レイヤの暗号化を有効にする必要があります。
VPC Service Controls を使用してデータの引き出しを防ぐ
Cloud Storage バケットや BigQuery データセットなどの機密性の高いリソースを VPC Service Controls の境界に配置して、VPC Service Controls でデータの引き出しのリスクを軽減することをおすすめします。境界内のデータにアクセスする必要があるワークロードも境界に配置する必要があります。具体的には、プライベート クラウドをホストする Google Cloud プロジェクトを VPC Service Controls の境界の一部にする必要があります。こうすることで、VPC Service Controls で保護されているリソースへのアクセスが可能になります。
VMware Engine プロデューサー サービス API を境界に許可するには、VPC Service Controls の構成で上り（内向き）データ転送と下り（外向き）データ転送ポリシーを構成する必要があります。設定の詳細については、VMware Engine を使用した VPC Service Controls に関するドキュメント ページをご覧ください。
VMware Engine の IAM と権限
以降のセクションでは、VMware Engine 環境におけるユーザー権限のベスト プラクティスについて説明します。プライベート クラウドがデプロイされている VMware Engine 環境と Google Cloud プロジェクト内での権限を処理することが重要です。
事前定義ロールまたはカスタムロールを使用してアクセス権を付与する
vSphere のロールと権限を管理する VMware Engine のアプローチは、他の VMware Engine 環境からの活用に使用される場合と同じ方法で活用できます。ただし、クラスタのデプロイなどのアクティビティには、Identity and Access Management（IAM）の権限が必要です。次の表に、関連するアクセス権の管理者、管理者が権限を付与する ID ソース、管理者が有効にするアクティビティの例を示します。
| プラットフォーム | コンポーネント | ID ソース | 権限を構成する場所 | アクティビティの例 |
|---|---|---|---|---|
| Google Cloud | VMware Engine ポータル | Cloud Identity | Identity and Access Management | プライベート クラウドのデプロイとキャンセル、クラスタのデプロイとキャンセルなど。 |
| VMware Engine | vCenter | LDAP | vCenter UI のホストとクラスタ、VM とフォルダ、データストア | VM の作成、VM フォルダの作成、データストア オブジェクトの作成と削除など |
| NSX-T | LDAP | NSX-T Manager UI の [ユーザーとロール] | NSX セグメントの作成、ファイアウォールの構成、ロードバランサの構成など。 | |
| vCenter | VM ゲスト オペレーティング システム | Active Directory、LDAP、ローカル ユーザーなど | ゲスト オペレーティング システム | SSH や RDP のログイン、ファイル操作など |
Google Cloud IAM には、VMware Engine ポータルに対する権限を持つ事前定義ロールが 2 つあります。
- VMware Engine サービス管理者 - Google Cloud 上の VMware Engine サービスへの完全アクセス権を付与します。
- VMware Engine サービス閲覧者 - Google Cloud 上の VMware Engine サービスへの読み取り専用アクセス権を付与します。
これらの権限は VMware Engine ポータルでの操作に関連するものであり、API や CLI での操作には関連しません。基本ロールには、VMware Engine サービスの管理の権限（オーナー、編集者）や、サービスの詳細の表示の権限（閲覧者）も含まれます。一般に、基本ロールではなく、より細分化された権限を提供する事前定義ロールを使用することをおすすめします。
API または CLI を使用してサービス アカウントを使用する VMware Engine へのプログラムからアクセスは、VMware Engine にのみ適用されるより細分化された権限が含まれているため、事前定義ロールまたはカスタムロールを使用して制限する必要があります。プログラムからのアクセスが、事前定義ロールの権限の特定のサブセットのみを必要とするタスクにのみ使用される場合は、カスタムロールを作成することをおすすめします。
組織のリソース階層での IAM ロールの割り当てに適切なロケーションを選択します。すべての VMware Engine プライベート クラウドを 1 つのプロジェクトのみで実行している場合は、プロジェクト レベルでロールを割り当てることができます。技術要件や組織要件によりプライベート クラウドが別のプロジェクトに配置される場合は、プライベート クラウドに使用されるプロジェクトに共通するフォルダ内に必要なロールを定義します。
vCenter、NSX-T、HCX 内でのみ行う必要があるアクティビティには、Cloud IAM の権限は必要ありません。これらの環境のみを運用する必要があるスタッフには、前述の IAM のロールは不要です。代わりに、vCenter と NSX-T で構成された権限を持つ LDAP ID を使用する必要があります。VMware Engine サービス管理者または VMware Engine サービス閲覧者のロールは、vCenter の強力な CloudOwner ユーザー アカウントと NSX-T の管理者ユーザー アカウントへのアクセス権を含んでいるため、極めて限定されたユーザーにのみ付与することをおすすめします。これらのユーザー アカウントは、初期設定または緊急手順にのみ使用してください。
管理者アクセスを制限して積極的に監査する
VMware Engine サービス管理者のロールは非常に強力であり、VMware Engine プライベート クラウドとそのクラスタのライフサイクルを管理する必要があるユーザーにのみ割り当てる必要があります。通常、クラスタとノードの手動追加と削除は頻繁には行われない操作で、課金やクラスタの可用性に大きな影響を与える可能性があります。このロールは組織内のごく少数のユーザーにのみ割り当ててください。
VMware Engine に使用するプロジェクトで直接、またはリソース階層の親レベルの 1 つで、VMware Engine サービス管理者のロールが割り当てられているユーザーを定期的に監査してください。この監査には、VMware Engine に関連する重要な権限を含む基本的な編集者ロールやオーナーロールなど、他のロールを含める必要があります。IAM Recommender などのサービスを使用して、過剰な権限を持つロールを特定できます。
LDAP または Active Directory の ID ソースを構成する
Active Directory などの LDAP 認証をサポートする ID プロバイダは、vCenter と NSX Manager のユーザー認証を有効にするように構成する必要があります。これは、ID ライフサイクル管理、グループ管理、パスワード管理などを一元化するためのおすすめの方法です。統合 Windows 認証では、vCenter と NSX-T の Active Directory への直接参加はサポートされていません。
組み込みサービス アカウントのパスワードをローテーションする
VMware Engine は、プライベート クラウド内の管理アプライアンス（vCenter、NSX-T、HCX など）にアクセスするための認証情報を生成します。デフォルトの vCenter サービス アカウント CloudOwner@gve.local とデフォルトの NSX-T サービス アカウント管理者のパスワードをローテーションするプロセスを確立することをおすすめします。どちらのユーザー アカウントも初期構成と緊急手順にのみ使用し、パスワードを定期的に（たとえば、60 日または 90 日ごとに）ローテーションする必要があります。同等に、サードパーティ ツールの統合に一般的に使用されるソリューション ユーザー アカウントのパスワードを定期的にローテーションします。サービス アカウントのパスワードをローテーションする頻度が高いほど、不正な行為者から見つかったときにパスワードが有効である可能性が低くなります。
VMware Engine のロギングとモニタリング
以降のセクションでは、VM ワークロードと VMware Engine インフラストラクチャ（ワークロードが使用するリソースを提供する）の両方のロギングとモニタリングに関するベスト プラクティスを紹介します。
VMware Engine のログと指標を取り込む
多くの組織では、一元管理された「一括表示」でログを収集して分析したいと考えています。Google Cloud では、Cloud Logging および Cloud Monitoring プロダクトで、ログと指標の一元管理に使用できるサービスが提供されています。VMware Engine は、スタンドアロン エージェントを使用して Cloud Monitoring と統合できます。この構成では、ESXi CPU やメモリ使用率などの指標が vCenter から Cloud Monitoring に転送されます。vCenter によって転送される指標に基づいてダッシュボードを作成するか、GitHub で公開されているサンプル ダッシュボードを使用して開始することをおすすめします。
プラットフォーム ログを収集するため、VMware Engine プライベート クラウドから一元的なログ アグリゲータに Syslog ログを転送できます。これは、vCenter と NSX-T の両方の Syslog メッセージについて行うことができます。vCenter からの Syslog メッセージの収集、保持、分析には、管理者権限を持つユーザー（または緊急ユーザー）のログインに基づくリアルタイムのアラートなど、重要なセキュリティのユースケースがあります。これは、例外的な状況でのみ実行する必要があります。Syslog メッセージを分析するには、Fluentd などの Syslog アグリゲータやスタンドアロン エージェントを構成して、メッセージを Cloud Logging にリレーする必要があります。
1 つのプロジェクトの一元化されたダッシュボードで VMware Engine のログを分析することをおすすめします。VMware Engine 環境が複数のプロジェクトにまたがっている場合は、ログシンクとモニタリング スコープを構成してプロジェクトを集約する必要があります。
ワークロード VM のロギングに Cloud Logging エージェントを使用する
VMware Engine ワークロード VM は、Logging エージェントを使用して Cloud Logging API にログを直接送信できます。Logging エージェントは Fluentd に基づいており、一般的なサードパーティのアプリケーションやシステム ソフトウェアから Cloud Logging にログをストリーミングします。VMware Engine のワークロード VM のログを収集して分析するアプローチを、Compute Engine インスタンスとオンプレミス資産のアプローチ（該当する場合）に合わせることをおすすめします。VMware Engine での Logging エージェントの使用は、Compute Engine で VM に使用されるアプローチと同じになり、両方のプラットフォームのワークロードで Cloud Logging にログが送信されす。
アクセスの透明性およびアクセス承認のポリシーと同等の機能を適用する
VMware Engine では、Google Cloud のアクセスの透明性（AxT）とアクセス承認（AxA）がサポートされていませんが、同等の機能を持つプロセスが実装されており、リクエストによって有効化できます。
アクセスの透明性と同等の機能を実現する場合は、次のような複数のログソースを検討する必要があります。
- vCenter ログ - リモート Syslog サーバー構成を使用してエクスポートできます。
- ESXi ログ - リモート Syslog 構成を使用して収集できますが、ESXi Syslog 転送を構成するには Google Cloud にサポート リクエストを提出する必要があります。
厳格な規制要件がある場合は、アクセス承認のための同等の機能を提供するポリシーを Google が実装します。このポリシーで、標準サービス オペレーションでは、アクセス サービス オペレータがアクセスを必要とする理由を記載したサポート チケットを生成する必要があります。
Google Cloud Access Approval の除外が適用されます。
VMware Engine の暗号化
以降のセクションでは、プライベート クラウドのストレージの暗号化のベスト プラクティスと、プライベート クラウドの重要なプロバイダを選択する際に考慮すべき主な要因について説明します。
vSAN の保存データの暗号化が有効になっている Google 管理の鍵プロバイダを使用する
保存データの暗号化は、vSAN ソフトウェア ベースの暗号化を使用して実装されます。VMware Engine のデフォルトでは、各 ESXi クラスタで vSAN 暗号化が有効となり、vCenter でデフォルトの鍵プロバイダが構成されます。お客様にて ESXi クラスタで vSAN 暗号化を引き続き有効にしていただく必要があります。vSAN 暗号化を無効にすると、VMware Engine の利用規約に違反します。多くの組織は、会社のポリシーの一部として保存データの暗号化を要求しているか、規制（NIST、FIPS など）によってデータの暗号化を義務付けられています。
各 ESXi ホストでは、ランダムに生成された異なるデータ暗号鍵（DEK）により、標準の AES-256 XTS モードでデータが暗号化されます。DEK は鍵暗号鍵（KEK）によって暗号化され、暗号化された形式でのみディスクに保存されます。vCenter サーバーには KEK の ID のみが保存され、KEK 自体は Cloud Key Management Service（KMS）に保存されます。KEK を保持する Cloud KMS のロケーションは選択可能です。
Google が管理するデフォルトの鍵プロバイダを使用することをおすすめします。ただし、Cloud KMS を独自に管理する必要がある場合は、サポートされているベンダーのいずれかによるサードパーティの KMIP 1.1 準拠の Cloud KMS を使用できます。どちらの場合も、鍵プロバイダを使用して、保存データと転送中の vMotion トラフィックを暗号化できます。
次の表に、デフォルトの鍵プロバイダを統合する場合とサードパーティの Cloud KMS を統合する場合の主な違いを示します。
| 鍵プロバイダ | 長所 | 短所 |
|---|---|---|
| Google が管理するデフォルトの鍵プロバイダ |
|
|
| サードパーティの Cloud KMS 鍵プロバイダ |
|
|
暗号化された VM では重複排除効率がゼロに近づくため、vSAN データストアの暗号化とともに VM レベルの暗号化を有効にすることはおすすめしません。
組織の標準に従って暗号鍵のローテーションを自動化する
VMware Engine vSphere を使用して KEK ローテーションを行う必要があります。これは、デフォルトの鍵プロバイダと外部 Cloud KMS の両方の場合に当てはまります。KEK ローテーションは、vCenter から、または vCenter API を使用して開始できます。組織の要件に応じて、KEK ローテーションの自動化を検討してください。GitHub に PowerCLI スクリプトのサンプルがあります。
VMware Engine のバックアップと障害復旧
ランサムウェア、破損、ヒューマン エラーなどの脅威からデータを保護することは重要です。さらに、ビジネス クリティカルなアプリケーションでは、データが常に仮想的に利用可能であることが必要です。これにより、突然の停止からデータを復元するための時間を短縮できます。このセクションでは、データの安全性と可用性を維持するためのバックアップと DR 戦略の効果的な設計に関連するバックアップと障害復旧の側面をすべて網羅してはおりませんが、VMware Engine 環境の適切な戦略を選択する際の重要な考慮事項を示しています。
バックアップと DR サービスを使用してワークロードをバックアップする
Google Cloud が提供するバックアップと DR サービスは、さまざまなユースケースに対応する一元管理されたネイティブ バックアップ ソリューションであり、Compute Engine や Google Cloud VMware Engine のワークロードのバックアップにも使用できます。バックアップと DR サービスは、幅広いワークロード サポート、スペース効率の良い永久増分方式バックアップ、柔軟なストレージ オプションなどの利点を備えているため、ワークロードのバックアップにはこのソリューションをおすすめします。
Google Cloud VMware Engine では、サードパーティのエージェント ベースのバックアップ ソリューションも使用できます。サードパーティのバックアップ プロダクトのライセンスをすでにお持ちの場合は、この方法をおすすめします。使用するツールに求められる要件は次のとおりです。
- アプリケーション レベルのバックアップが可能である
- アプリケーション ベンダーによる認定を受けている
- VMware Engine で vSAN 用に認定されている
- VMware Engine vStorage API for Data Protection（VADP）プロトコル標準をサポートするか、アプリケーション レベルのバックアップを作成する
どのバックアップ ソリューションを使用する場合でも、バックアップを長期間保持するための費用対効果に優れたストレージ オプションとして、Cloud Storage をおすすめします。Cloud Storage は、耐久性と費用対効果に優れたオブジェクト ストレージです。Cloud Storage バケットは、複数のリージョンにストレージ オブジェクトを自動的に複製するように構成できます。これは、マルチリージョンの Cloud トポロジに最適です。
Cloud Storage は、ライフサイクル ポリシーが事前に定義された値を超えたときに、別のストレージ階層にストレージ オブジェクトを自動的に移動させるライフサイクル ポリシーを提供するため、長期的なアーカイブにも最適です。特に費用が主な要因となる場合は、費用対効果の高いバックアップ ストレージのロケーション、および中程度から高程度の RPO のためにこのオプションを使用してください。
または、vSAN ストレージを選択して RPO を最小限に抑えることもできます。バックアップ ストレージの費用が高くなっても許容でき、Cloud Storage で RPO の要件を満たせない場合は、このストレージ オプションを使用してください。VMware Engine クラスタのサイズがストレージの制約を受けるリスクがあるため、長期的なアーカイブにはこのオプションは避けてください。
バックアップと DR サービスを使用して障害復旧を実装する
VMware Engine でアプリケーションを復元する際は、バックアップと DR サービスを使用することをおすすめします。リージョン内のシングルゾーンでの停止から本番環境ワークロードを保護するには、そのリージョンの複数のゾーンで VMware Engine を使用可能な場合は、そのリージョン内のセカンダリ ゾーンでプライベート クラウドをデプロイして運用することをおすすめします。そうでない場合は、セカンダリ リージョンでアプリケーションを復元することをおすすめします。
Google Cloud のバックアップと DR サービスに加えて、VMware Engine では VMware Engine SRM や Zerto などの DR オプションも利用できます。VMware Engine SRM と Zerto はどちらも障害復旧用に vSphere Replication を利用しており、通常は低い RPO ターゲットをサポートしています。RPO 目標が時間単位ではなく分単位の場合は、vSphere Replication ベースの DR ソリューションを検討してください。
チェックリストの概要
次のチェックリストは、VMware Engine を使用する際のセキュリティ上のベスト プラクティスをまとめたものです。
| タスク | トピック |
|---|---|
| VMware Engine ネットワーキング |
|
| VMware Engine の IAM と権限 | |
| VMware Engine のロギングとモニタリング | |
| VMware Engine の暗号化 | |
| VMware Engine のバックアップと障害復旧 |
次のステップ
- Google Cloud VMware Engine を試す。詳細については、機能、メリット、ユースケースをご覧ください。
- VMware Engine のセキュリティのコンセプトについて読む。
- Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。詳細については、Cloud アーキテクチャ センターをご覧ください。