VMware Engine のセキュリティのベスト プラクティス
このドキュメントでは、すでに VMware Engine を使い慣れているユーザーを対象として、Google Cloud VMware Engine の管理と構成において推奨されるセキュリティのベスト プラクティスを説明します。使い慣れていないユーザーは、前提条件と VMware Engine のセキュリティについて学ぶことを検討してください。
VMware Engine にはセキュリティに関する責任共有モデルがあります。信頼できるクラウド セキュリティは、サービス プロバイダである Google とお客様との責任の共有によって実現します。ここで紹介するベスト プラクティスに従うことで、お客様は時間を節約できるほか、エラーを防止し、障害点の影響を軽減できます。
環境のすべてのトラフィック フローを特定して把握する
プライベート クラウドのワークロードと管理インターフェースを保護するには、環境のすべてのトラフィック フローを特定して把握することが重要です。VMware Engine の主要なトラフィック フローの一覧については、VMware Engine のプライベート クラウド ネットワーキングのドキュメントをご覧ください。
VMware Engine は、プライベート サービス アクセス（PSA）を利用して、VMware Engine プライベート クラウド ネットワークからご使用の VPC ネットワークへのプライベート ネットワーク接続を実現します。Google Cloud 環境の VPC から、またはオンプレミス ネットワークからの受信トラフィックは、Google 管理のサービス プロデューサー ネットワークを通過します。
インターネットからの上り（内向き）トラフィックに VMware Engine のパブリック IP サービスを使用する
インターネット トラフィックは、VMware Engine のパブリック IP サービスを使用して、プライベート クラウドに直接入ることができます。あるいは、Google Cloud のパブリック ロードバランサを使用して入ることもできます。この場合、トラフィックは、他の上り（内向き）トラフィックと同様に、プライベート サービス アクセス経由でルーティングされます。この 2 種類の方法は併用できませんのでご注意ください。Google Cloud 環境で、セントラル インスタンスまたはサービスによる URL フィルタリング、IPS / IDS、トラフィック検査など、インターネット トラフィックのカスタム制御が必要な場合は、インターネットに向かうトラフィックをご使用の VPC とサービス プロデューサーの共有 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 ワークロードを Traffic Director の背後に配置するか、外部 HTTP(S) ロードバランサを活用することをおすすめします。どちらの設定でも、一般向けアプリケーション用に Google Cloud Armor を含めることにより、DDoS 攻撃と SQL インジェクションやクロスサイト スクリプティングなどの一般的な脆弱性を軽減できます。
Envoy プロキシによる高度なトラフィック管理や Certificate Authority Service の統合などのサービス メッシュ機能が必要な場合は、Traffic Director をおすすめします。それ以外の場合は、外部 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 で保護されているリソースへのアクセスが可能になります。
VPC Service Controls の構成で上り（内向き）トラフィックと下り（外向き）トラフィックのポリシーを構成し、VMware Engine のプロデューサー サービス API が境界内にアクセスできるようにする必要があります。設定の詳細については、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 サービス管理者のロールが割り当てられているユーザーを定期的に監査してください。これは、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 にリレーする必要があります。
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 暗号化は常に有効にしておく必要があり、無効にすると 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 サービスを使用することをおすすめします。リージョン内の 1 つのゾーンでのサービス停止から本番環境ワークロードを保護するため、リージョンの複数のゾーンで 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 アーキテクチャ センターをご覧ください。