Praktik terbaik untuk keamanan VMware Engine

Dokumen ini menjelaskan praktik terbaik keamanan yang direkomendasikan untuk mengelola dan mengonfigurasi Google Cloud VMware Engine dan ditujukan bagi pengguna yang sudah terbiasa dengan VMware Engine. Jika Anda adalah pemula, sebaiknya mulailah dengan mempelajari prasyarat dan keamanan VMware Engine.

VMware Engine memiliki model tanggung jawab bersama untuk keamanan. Keamanan tepercaya di cloud dicapai melalui tanggung jawab bersama pelanggan dan Google sebagai penyedia layanan. Dengan mengikuti praktik terbaik ini, Anda dapat menghemat waktu, mencegah error, dan mengurangi dampak titik kegagalan.

Jaringan VMware Engine

Bagian berikut memperkenalkan praktik terbaik untuk jaringan di lingkungan VMware Engine.

Mengidentifikasi dan memahami semua alur traffic lingkungan Anda

VMware Engine memanfaatkan jaringan VMware Engine dan peering VPC untuk menghubungkan koneksi jaringan pribadi dari jaringan cloud pribadi VMware Engine ke jaringan VPC Anda. Traffic masuk dari VPC di lingkungan Google Cloud Anda atau dari jaringan lokal melintasi jaringan unit sewa yang dikelola Google.

Menggunakan Layanan IP Publik VMware Engine untuk transfer data internet

Traffic internet dapat masuk ke cloud pribadi secara langsung menggunakan Layanan IP Publik VMware Engine. Atau, traffic internet dapat masuk menggunakan load balancer publik di Google Cloud. Dalam hal ini, traffic akan dirutekan seperti traffic masuk lainnya. Perhatikan bahwa opsi ini saling eksklusif. Jika kontrol kustom diperlukan untuk traffic internet, seperti pemfilteran URL, IPS/IDS, atau pemeriksaan traffic yang disediakan oleh instance atau layanan pusat di lingkungan Google Cloud, Anda harus merutekan traffic yang terikat internet melalui jaringan VPC.

Jika hal ini tidak berlaku untuk Anda atau Anda telah menerapkan kontrol dalam cloud pribadi, sebaiknya sertakan layanan alamat IP eksternal di VMware Engine. Selain itu, sebaiknya gunakan aturan akses eksternal untuk menolak pola traffic dari internet yang tidak berlaku untuk aplikasi Anda.

Memisahkan aturan firewall utara-selatan dan timur-barat di gateway dan firewall terdistribusi di VMware Engine NSX-T

Konfigurasikan firewall terdistribusi (DFW) di NSX-T pada router logis tingkat 1 untuk menyegmentasikan traffic internal di antara domain virtual lapisan 2 Anda. NSX DFW dirancang untuk menangani traffic jaringan timur-barat (internal) antar-segmen dan mengizinkan aturan firewall yang mengizinkan dan menolak traffic antar-instance di dalam segmen.

Untuk kontrol akses jaringan yang terperinci, pastikan untuk menerapkan kebijakan default yang dibatasi di DFW untuk menolak traffic jaringan antar-instance secara default. Gunakan DFW untuk mengizinkan traffic secara khusus antara aplikasi dan antara layanan di dalam aplikasi Anda.

Konfigurasikan firewall gateway NSX untuk mengontrol traffic utara-selatan yang masuk dan keluar dari cloud pribadi.

Firewall gateway NSX dirancang untuk mengontrol traffic utara-selatan dan direkomendasikan untuk kasus penggunaan seperti mengontrol traffic di perimeter ke zona keamanan lain. Jika Anda perlu mengonfigurasi traffic north-south untuk seluruh cloud pribadi secara konsisten, konfigurasikan firewall gateway di router tingkat 0. Jika Anda perlu mengonfigurasi traffic utara-selatan untuk setiap segmen NSX-T, konfigurasikan firewall gateway di router tingkat 1.

Selain firewall NSX-T, sebaiknya gunakan firewall VPC untuk mengizinkan dan memblokir traffic east-west antara workload di cloud pribadi VMware Engine dan workload di VPC. Transfer data masuk ke instance Compute Engine dari workload VMware Engine harus dibatasi secara default dengan hanya traffic yang dibuka secara sadar.

Transfer data keluar ke perangkat pengelolaan serta ke rentang CIDR vSphere/vSAN juga harus diblokir dari VPC menggunakan Firewall VPC. Hanya buka transfer data keluar ke perangkat pengelolaan dari host dan alamat IP tepercaya di dalam jaringan Anda. Perlu diperhatikan bahwa appliance pengelolaan tidak berada di dalam segmen NSX-T, sehingga aturan DFW tidak berlaku untuk membatasi akses.

Menerapkan prinsip Keamanan Zero Trust dan segmentasi mikro di NSX-T

Gunakan DFW NSX-T untuk menerapkan kontrol traffic untuk segmen keamanan yang terperinci seperti setiap virtual machine. Prinsip perlindungan traffic antar-VM yang ditolak secara default ini sering kali juga disebut sebagai "Segmentasi Mikro", yang merupakan pendekatan yang lebih terperinci untuk firewall daripada penerapan firewall konvensional di antara domain Lapisan 3.

DFW diaktifkan di kernel hypervisor di semua host vSphere VMware Engine di cloud pribadi Anda dan dapat mengontrol alur traffic antara beban kerja yang berada di segmen NSX yang sama atau terpisah. Aturan firewall untuk mengizinkan traffic ke dan dari VM dapat ditentukan dengan mengatur VM ke dalam grup kebijakan, yang dapat memiliki kriteria keanggotaan yang fleksibel seperti pencocokan nama atau tag VM.

Segmentasi mikro memungkinkan Anda menerapkan jaringan dengan kontrol traffic yang sangat detail, tempat pola traffic harus diizinkan secara eksplisit. Konsep keamanan yang mengontrol semua alur jaringan dengan proses verifikasi identitas dan perangkat, bukan kepercayaan implisit, sering kali juga disebut Keamanan Zero Trust.

Men-deploy appliance firewall pihak ketiga dari portal Cloud Marketplace untuk kemampuan IPS/IDS

Jika Anda memerlukan keamanan lapisan 7 lanjutan, termasuk kemampuan IDS/IPS untuk traffic masuk ke cloud pribadi dari seluruh jaringan atau di antara segmen jaringan NSX-T, pertimbangkan untuk men-deploy perangkat firewall pihak ketiga. Appliance pihak ketiga dapat di-deploy sebagai appliance multi-NIC antara dua VPC di jaringan Google Cloud Anda atau di dalam cloud pribadi dengan integrasi dengan NSX-T.

Untuk mempelajari lebih lanjut arsitektur VMware Engine dengan peralatan terpusat, yang dapat digunakan untuk berbagai kasus penggunaan keamanan lanjutan, seperti IPS/IDS, DDoS, pemindahan SSL, dan lainnya, lihat keamanan jaringan dokumen menggunakan peralatan terpusat di Cloud Architecture Center.

Menggunakan Google Cloud Armor untuk melindungi layanan web di VMware Engine dari serangan DDoS

Jika Anda merutekan traffic masuk ke workload di VMware Engine melalui VPC pelanggan, sebaiknya tempatkan workload VMware Engine dalam grup endpoint jaringan campuran di belakang Cloud Service Mesh dan manfaatkan load balancer HTTP(S) eksternal. Kedua penyiapan tersebut memungkinkan Anda menyertakan Google Cloud Armor untuk aplikasi yang ditampilkan kepada publik, sehingga memitigasi serangan DDoS dan kerentanan umum seperti injeksi SQL atau pembuatan skrip lintas situs.

Jika Anda memerlukan fitur Service Mesh seperti pengelolaan traffic lanjutan menggunakan proxy Envoy atau integrasi Layanan Otoritas Sertifikasi, sebaiknya gunakan Cloud Service Mesh. Dalam semua kasus lainnya, sebaiknya gunakan load balancer HTTP(S) eksternal.

Ikuti dokumentasi tentang cara menambahkan workload VMware Engine ke NEG Hybrid dalam salah satu penyiapan berikut:

Terhubung ke Layanan Google Cloud secara pribadi tanpa akses internet

Workload cloud pribadi VMware Engine dapat mengakses Google Cloud API seperti Cloud Storage API menggunakan Akses Google Pribadi. Sebaiknya Anda menggunakan Akses Google Pribadi untuk mengakses layanan Google tanpa mengirim traffic melalui internet karena mengurangi biaya dan latensi transfer data keluar. Hal ini juga menghilangkan kebutuhan jalur jaringan ke internet untuk beban kerja yang hanya memerlukan akses Google API. Ikuti pembahasan mendalam tentang Akses Google Pribadi untuk mengetahui detail teknis dan langkah-langkah konfigurasi selengkapnya.

Demikian pula, beban kerja VMware Engine yang perlu mengakses resource Google Cloud dari jaringan produsen layanan seperti instance Cloud SQL atau Memorystore harus terhubung secara pribadi menggunakan PSA. Untuk informasi selengkapnya, buka bagian PSA untuk VMware Engine.

Mengenkripsi komunikasi antara lingkungan lokal Anda dan Google Cloud

Workload di VMware Engine yang perlu berkomunikasi dengan sistem lokal harus terhubung melalui saluran terenkripsi. Sebaiknya gunakan pendekatan berlapis untuk enkripsi dalam pengiriman antara pusat data lokal dan Google Cloud. Link antara sistem lokal dan Google Cloud dapat dienkripsi dengan menyiapkan Cloud VPN dengan tunnel IPsec atau dengan menggunakan IPsec bawaan pada lampiran VLAN Interconnect. Selain itu, enkripsi lapisan aplikasi harus diaktifkan di antara komponen aplikasi yang menggunakan TLS.

Melindungi data Anda dari pemindahan data yang tidak sah menggunakan Kontrol Layanan VPC

Sebaiknya mitigasi risiko pemindahan data yang tidak sah menggunakan Kontrol Layanan VPC dengan menempatkan resource sensitif Anda seperti bucket Cloud Storage dan set data BigQuery ke dalam perimeter Kontrol Layanan VPC. Workload yang perlu mengakses data di dalam perimeter juga harus ditempatkan ke dalam perimeter. Secara khusus, project Google Cloud yang menghosting cloud pribadi harus menjadi bagian dari perimeter Kontrol Layanan VPC untuk mengakses resource yang dilindungi oleh Kontrol Layanan VPC.

Anda perlu mengonfigurasi kebijakan transfer data masuk dan keluar dalam konfigurasi Kontrol Layanan VPC untuk mengizinkan API layanan produsen VMware Engine masuk ke perimeter. Untuk panduan mendetail tentang penyiapan, ikuti halaman dokumentasi kami tentang Kontrol Layanan VPC dengan VMware Engine.

IAM dan izin VMware Engine

Bagian berikut memperkenalkan praktik terbaik untuk izin pengguna di lingkungan VMware Engine. Anda harus mengelola izin dalam lingkungan VMware Engine dan project Google Cloud tempat cloud pribadi di-deploy.

Menggunakan peran bawaan atau peran kustom untuk memberikan akses

Pendekatan VMware Engine untuk mengelola peran dan izin vSphere dapat dimanfaatkan dengan cara yang sama seperti yang biasa Anda manfaatkan dari lingkungan VMware Engine lainnya. Namun, aktivitas seperti men-deploy cluster memerlukan izin di Identity and Access Management (IAM). Tabel berikut mencantumkan pengelola akses yang relevan, sumber identitas yang diberi izin oleh pengelola akses tersebut, dan contoh aktivitas yang diaktifkan oleh pengelola akses tersebut.

Platform Komponen Sumber identitas Tempat untuk mengonfigurasi izin Contoh aktivitas
Google Cloud Portal VMware Engine Cloud Identity Identity and Access Management Misalnya, deployment dan pembatalan cloud pribadi, deployment dan pembatalan cluster.
VMware Engine vCenter LDAP Host dan cluster, VM dan folder, datastore di UI vCenter Pembuatan VM, pembuatan folder VM, pembuatan dan penghapusan objek datastore, misalnya
NSX-T LDAP "Pengguna dan Peran" di UI NSX-T Manager Misalnya, pembuatan segmen NSX, konfigurasi firewall, konfigurasi load balancer.
vCenter Sistem Operasi Tamu VM Misalnya, Active Directory, LDAP, Pengguna Lokal Sistem Operasi Tamu Login SSH atau RDP, operasi file, misalnya

Di Google Cloud IAM, ada dua peran bawaan dengan izin ke portal VMware Engine:

  • VMware Engine Service Admin - memberikan akses penuh ke layanan VMware Engine di Google Cloud.
  • VMware Engine Service Viewer - memberikan akses baca saja ke layanan VMware Engine di Google Cloud.

Izin ini terkait dengan tindakan di portal VMware Engine dan tidak terkait dengan tindakan di API atau CLI. Perhatikan bahwa peran dasar juga mencakup kemampuan untuk mengelola layanan VMware Engine (Pemilik, Editor) atau melihat detail layanan (Pelihat). Secara umum, sebaiknya gunakan peran bawaan, bukan peran dasar, karena peran bawaan memberikan izin yang lebih terperinci.

Akses terprogram ke VMware Engine menggunakan akun layanan menggunakan API atau CLI harus dibatasi menggunakan peran standar atau peran kustom karena menyertakan izin yang lebih terperinci yang hanya berlaku untuk VMware Engine. Jika akses terprogram hanya digunakan untuk tugas yang hanya memerlukan subset izin tertentu dari peran yang telah ditetapkan, sebaiknya buat peran kustom.

Pilih lokasi yang sesuai untuk penetapan peran IAM dalam hierarki resource organisasi Anda. Jika Anda menjalankan semua cloud pribadi VMware Engine dalam satu project, hanya peran yang dapat ditetapkan di tingkat project. Jika ada persyaratan teknis atau organisasi yang menyebabkan cloud pribadi Anda berada di project terpisah, tentukan peran yang diperlukan dalam folder yang umum untuk project yang digunakan untuk cloud pribadi Anda.

Izin IAM Cloud tidak diperlukan untuk aktivitas yang hanya perlu dilakukan di dalam vCenter, NSX-T, atau HCX. Staf yang hanya perlu mengoperasikan lingkungan ini tidak memerlukan peran IAM yang tercantum sebelumnya. Sebagai gantinya, mereka harus menggunakan identitas LDAP dengan izin yang dikonfigurasi di vCenter dan NSX-T. Sebaiknya berikan peran VMware Engine Service Admin atau VMware Engine Service Viewer hanya kepada sejumlah pengguna yang sangat terbatas karena peran ini memberikan akses ke akun pengguna CloudOwner yang canggih untuk vCenter dan akun pengguna administrator untuk NSX-T. Akun pengguna ini hanya boleh digunakan untuk penyiapan awal atau prosedur darurat.

Membatasi dan secara aktif mengaudit akses administrator

Peran VMware Engine Service Admin sangat canggih dan hanya boleh ditetapkan kepada pengguna yang perlu mengelola siklus proses cloud pribadi VMware Engine dan clusternya. Biasanya, penambahan atau penghapusan cluster dan node secara manual adalah tindakan yang tidak sering terjadi dan dapat berdampak tinggi pada penagihan atau ketersediaan cluster. Hanya tetapkan peran ini kepada sedikit orang di organisasi Anda.

Pastikan untuk mengaudit secara rutin siapa yang telah diberi peran Admin Layanan VMware Engine, baik secara langsung di project yang digunakan untuk VMware Engine maupun di salah satu tingkat induk hierarki resource. Audit ini harus mencakup peran lain, seperti peran Editor dan Pemilik dasar yang mencakup izin penting yang terkait dengan VMware Engine. Anda dapat menggunakan layanan seperti pemberi rekomendasi peran IAM untuk membantu mengidentifikasi peran yang terlalu memiliki hak istimewa.

Mengonfigurasi sumber identitas LDAP atau Active Directory

Penyedia identitas yang mendukung autentikasi LDAP, seperti Active Directory, harus dikonfigurasi untuk mengaktifkan autentikasi pengguna untuk vCenter dan NSX Manager. Ini adalah praktik yang direkomendasikan untuk memiliki pengelolaan siklus proses identitas pusat, pengelolaan grup, pengelolaan sandi, dan lainnya. Perhatikan bahwa bergabung langsung vCenter dan NSX-T ke Active Directory untuk autentikasi Windows terintegrasi tidak didukung.

Memutar sandi akun layanan bawaan

VMware Engine menghasilkan kredensial untuk mengakses appliance pengelolaan di cloud pribadi (seperti vCenter, NSX-T, dan HCX). Sebaiknya buat proses untuk merotasi sandi akun layanan vCenter default CloudOwner@gve.local dan administrator akun layanan NSX-T default. Kedua akun pengguna hanya boleh digunakan untuk konfigurasi awal dan prosedur darurat, serta sandinya dirotasi secara berkala (misalnya, setiap 60 atau 90 hari). Demikian pula, ubah sandi akun pengguna solusi secara rutin yang biasanya digunakan untuk integrasi alat pihak ketiga. Makin sering Anda memutar sandi akun layanan, makin kecil kemungkinan sandi tersebut masih valid saat pihak tidak bertanggung jawab menemukannya.

Logging dan Pemantauan VMware Engine

Bagian berikut memperkenalkan praktik terbaik untuk logging dan pemantauan workload VM dan infrastruktur VMware Engine, yang menyediakan resource yang digunakan workload.

Mengambil log dan metrik VMware Engine

Banyak organisasi ingin mengumpulkan dan menganalisis log di "Single Pane of Glass" terpusat. Di Google Cloud, produk Cloud Logging dan Cloud Monitoring menyediakan layanan yang dapat digunakan untuk pengelolaan log dan metrik secara terpusat. VMware Engine dapat diintegrasikan dengan Cloud Monitoring menggunakan agen mandiri. Dalam konfigurasi ini, vCenter meneruskan metrik seperti CPU ESXi dan penggunaan memori ke Cloud Monitoring. Sebaiknya buat dasbor berdasarkan metrik yang diteruskan oleh vCenter, atau mulai menggunakan beberapa contoh dasbor yang telah dipublikasikan di GitHub.

Untuk mengumpulkan log platform, cloud pribadi VMware Engine dapat meneruskan log Syslog ke agregator log terpusat. Hal ini dapat dilakukan untuk pesan Syslog vCenter dan NSX-T. Mengumpulkan, mempertahankan, dan menganalisis pesan Syslog dari vCenter memiliki kasus penggunaan keamanan yang penting, seperti pemberitahuan real-time berdasarkan login pengguna administratif (atau pengguna darurat), yang hanya boleh dilakukan dalam keadaan luar biasa. Untuk menganalisis pesan Syslog, agregator Syslog seperti Fluentd atau agen Mandiri perlu dikonfigurasi untuk meneruskan pesan ke Cloud Logging.

Sebaiknya analisis log dari VMware Engine di dasbor terpusat dalam satu project. Jika lingkungan VMware Engine Anda mencakup beberapa project, Anda juga harus menggabungkan project dengan mengonfigurasi sink log dan cakupan pemantauan.

Menggunakan agen Cloud Logging untuk logging VM workload

VM workload VMware Engine dapat mengirim log langsung ke Cloud Logging API, menggunakan agen Logging. Agen Logging didasarkan pada fluentd dan melakukan streaming log dari aplikasi pihak ketiga umum dan software sistem ke Cloud Logging. Sebagai praktik terbaik, selaraskan pendekatan untuk mengumpulkan dan menganalisis log untuk VM workload di VMware Engine dengan pendekatan untuk instance Compute Engine dan aset lokal Anda (jika berlaku). Penggunaan agen Logging di VMware Engine cocok dengan pendekatan yang digunakan untuk VM di Compute Engine sehingga beban kerja di kedua platform mengirim log ke Cloud Logging.

Menerapkan kemampuan yang setara dari kebijakan Transparansi Akses dan Persetujuan Akses

Meskipun VMware Engine tidak mendukung transparansi akses (AxT) dan persetujuan akses (AxA) di Google Cloud, kami telah menerapkan proses dengan kemampuan yang setara yang dapat diaktifkan berdasarkan permintaan.

Untuk kesetaraan transparansi akses, Anda perlu mempertimbangkan beberapa sumber log, termasuk:

  • Log vCenter - dapat diekspor menggunakan konfigurasi server syslog jarak jauh.
  • Log ESXi - log ini dapat dikumpulkan menggunakan konfigurasi syslog jarak jauh, tetapi Anda harus mengajukan permintaan dukungan ke Google Cloud untuk mengonfigurasi penerusan syslog ESXi.

Jika Anda memiliki persyaratan peraturan yang ketat, kami menerapkan kebijakan untuk memberikan kemampuan yang setara untuk persetujuan akses. Dalam kebijakan ini, operasi layanan standar memerlukan tiket dukungan yang dibuat dengan alasan mengapa operator layanan akses memerlukan akses.

Pengecualian Persetujuan Akses Google Cloud berlaku.

Enkripsi VMware Engine

Bagian berikut memperkenalkan praktik terbaik untuk enkripsi penyimpanan di cloud pribadi, dan faktor pendorong yang perlu dipertimbangkan saat memilih penyedia kunci untuk cloud pribadi Anda.

Menggunakan penyedia kunci yang dikelola Google yang diaktifkan untuk enkripsi vSAN dalam penyimpanan

Enkripsi data dalam penyimpanan diterapkan menggunakan enkripsi berbasis software vSAN. Secara default, VMware Engine mengaktifkan enkripsi vSAN di setiap cluster ESXi dan mengonfigurasi penyedia kunci default di vCenter. Google mewajibkan pelanggan untuk tetap mengaktifkan enkripsi vSAN di cluster ESXi mereka dan menonaktifkan enkripsi vSAN merupakan pelanggaran terhadap persyaratan layanan untuk VMware Engine. Banyak organisasi mewajibkan enkripsi saat dalam penyimpanan sebagai bagian dari kebijakan perusahaan mereka atau diwajibkan oleh peraturan untuk mengenkripsi data (misalnya, NIST, FIPS).

Setiap host ESXi mengenkripsi data menggunakan mode XTS AES-256 standar dengan Kunci Enkripsi Data (DEK) yang berbeda dan dihasilkan secara acak. DEK dienkripsi menggunakan Kunci Enkripsi Kunci (KEK) dan hanya disimpan di disk dalam bentuk terenkripsi. Server vCenter hanya menyimpan ID KEK, tetapi tidak menyimpan KEK itu sendiri yang disimpan di Cloud Key Management Service (KMS). Anda dapat memilih lokasi Cloud KMS tempat KEK Anda disimpan.

Sebaiknya gunakan penyedia kunci default yang dikelola Google. Namun, jika Anda diwajibkan untuk mengelola Cloud KMS sendiri, Anda dapat menggunakan Cloud KMS yang mematuhi KMIP 1.1 pihak ketiga oleh salah satu vendor yang didukung. Dalam kedua kasus tersebut, penyedia kunci dapat digunakan untuk mengenkripsi data saat tidak digunakan dan traffic vMotion dalam pengiriman.

Tabel berikut menyoroti perbedaan utama antara penyedia kunci default dan integrasi Cloud KMS pihak ketiga:

Penyedia kunci Kelebihan Kekurangan
Penyedia kunci yang dikelola Google default
  • Kesederhanaan: Di-deploy "out of the box" tanpa pengelolaan vendor dan tanpa beban operasional
  • Dukungan menyeluruh oleh Google
  • Metode termudah dari kemampuan untuk memutar DEK/KEK adalah persyaratan utama
  • Tanpa biaya tambahan
  • Redundansi zona bawaan untuk ketersediaan tinggi
  • Tidak dapat membawa materi kunci Anda sendiri (BYOK)
  • KEK disimpan dan dikelola di infrastruktur Google. Pengelola Kunci Eksternal (EKM) tidak didukung.
Penyedia kunci Cloud KMS pihak ketiga
  • Kontrol penuh atas data terenkripsi dan kunci enkripsi
  • Kunci yang didukung hardware dapat disimpan di perangkat HSM
  • Kompleksitas dan overhead operasional tambahan
  • Biaya tambahan
  • Kemungkinan latensi tambahan, terutama dalam kasus KMS SaaS
  • Kemungkinan ketersediaan lebih rendah

Perhatikan bahwa sebaiknya jangan aktifkan enkripsi tingkat VM bersama dengan enkripsi datastore vSAN karena efisiensi penghapusan duplikat mendekati nol untuk VM terenkripsi.

Mengotomatiskan rotasi kunci enkripsi sesuai dengan standar organisasi Anda

Anda bertanggung jawab atas rotasi KEK menggunakan VMware Engine vSphere. Hal ini berlaku untuk penyedia kunci default dan Cloud KMS eksternal. Rotasi KEK dapat dimulai dari vCenter atau menggunakan API-nya. Pertimbangkan untuk mengotomatiskan rotasi KEK sesuai dengan persyaratan organisasi Anda. Anda dapat menemukan contoh skrip PowerCLI di GitHub.

Pencadangan dan pemulihan dari bencana (disaster recovery) VMware Engine

Penting untuk melindungi data Anda dari ancaman seperti ransomware, kerusakan, dan kesalahan manusia. Selain itu, aplikasi penting bagi bisnis mengandalkan data Anda yang tersedia secara virtual setiap saat, sehingga Anda hanya memiliki sedikit waktu untuk memulihkan data dari penghentian layanan mendadak. Bagian ini tidak berisi cakupan lengkap semua aspek pencadangan dan pemulihan dari bencana yang relevan untuk mendesain strategi pencadangan dan DR secara efektif agar data Anda tetap aman dan tersedia, tetapi berisi pertimbangan utama saat memilih strategi yang tepat untuk lingkungan VMware Engine Anda.

Mencadangkan workload menggunakan Backup and DR Service

Dengan Layanan Pencadangan dan DR, Google Cloud menawarkan solusi pencadangan bawaan yang dikelola secara terpusat yang dapat digunakan untuk berbagai kasus penggunaan, termasuk pencadangan workload di Compute Engine dan Google Cloud VMware Engine. Layanan Pencadangan dan DR adalah solusi tunggal yang direkomendasikan Google untuk pencadangan beban kerja, karena menawarkan manfaat seperti spektrum dukungan beban kerja yang luas, pencadangan inkremental yang hemat ruang dan berkelanjutan, serta opsi penyimpanan yang fleksibel.

Google Cloud VMware Engine juga mendukung penggunaan solusi pencadangan berbasis agen pihak ketiga. Anda dapat memilih opsi ini jika sudah memiliki lisensi untuk produk pencadangan pihak ketiga. Prasyarat untuk jenis alat ini mencakup hal berikut:

  • Pencadangan ini menyediakan pencadangan tingkat aplikasi
  • Aplikasi tersebut disertifikasi oleh vendor aplikasi
  • Keduanya disertifikasi oleh VMware Engine untuk vSAN
  • API ini mendukung VMware Engine vStorage API untuk standar protokol Perlindungan Data (VADP) atau mengambil pencadangan tingkat aplikasi

Apa pun solusi pencadangan pilihan Anda, sebaiknya gunakan Cloud Storage sebagai opsi penyimpanan hemat biaya untuk retensi cadangan jangka panjang. Cloud Storage adalah penyimpanan objek yang sangat tahan lama dan hemat biaya. Bucket Cloud Storage dapat dikonfigurasi untuk otomatis mereplikasi objek penyimpanan di beberapa region, yang ideal untuk topologi Cloud multi-regional.

Cloud Storage juga ideal untuk pengarsipan jangka panjang karena menyediakan kebijakan siklus proses untuk memindahkan objek penyimpanan secara otomatis ke tingkat penyimpanan lain setelah masa aktifnya melebihi nilai yang telah ditentukan. Gunakan opsi ini untuk lokasi penyimpanan cadangan yang hemat biaya dan RPO sedang hingga tinggi, terutama jika biaya adalah faktor pendorong.

Atau, Anda dapat memilih penyimpanan vSAN untuk meminimalkan RPO. Gunakan opsi penyimpanan ini jika biaya yang lebih tinggi untuk penyimpanan cadangan dapat diterima dan persyaratan RPO tidak dapat dipenuhi dengan Cloud Storage. Hindari opsi ini untuk penyimpanan arsip jangka panjang, karena ada risiko ukuran cluster VMware Engine menjadi terbatas penyimpanan.

Mengimplementasikan disaster recovery dengan Layanan Pencadangan dan DR

Sebaiknya pulihkan aplikasi di VMware Engine menggunakan Layanan Pencadangan dan DR. Untuk melindungi workload produksi Anda dari pemadaman layanan satu zona di dalam region, sebaiknya deploy dan operasikan cloud pribadi di zona sekunder di dalam region jika VMware Engine tersedia di lebih dari satu zona di region tersebut. Jika tidak, sebaiknya pulihkan aplikasi Anda di region sekunder.

Selain Google Cloud Backup dan DR, VMware Engine kompatibel dengan opsi lain untuk DR seperti VMware Engine SRM dan Zerto. VMware Engine SRM dan Zerto mengandalkan replikasi vSphere untuk pemulihan dari bencana yang umumnya mendukung target RPO yang lebih rendah. Jika target RPO Anda adalah menit, bukan jam, pertimbangkan solusi DR berdasarkan replikasi vSphere.

Ringkasan checklist

Checklist berikut merangkum praktik terbaik keamanan untuk menggunakan VMware Engine.

Tugas Topik
Jaringan VMware Engine
IAM dan Izin VMware Engine
Logging dan Pemantauan VMware Engine
Enkripsi VMware Engine
Pencadangan dan Pemulihan dari Bencana (Disaster Recovery) VMware Engine

Langkah selanjutnya