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 mulai 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. Mengikuti praktik terbaik ini dapat membantu Anda 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 lingkunganGoogle Cloud Anda atau dari jaringan lokal melintasi jaringan unit tenant yang dikelola Google.

Menggunakan Layanan IP Publik VMware Engine untuk transfer data internet

Traffic internet dapat memasuki 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 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, Anda harus merutekan traffic yang ditujukan ke 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.

Aturan firewall north-south dan east-west terpisah di gateway dan firewall terdistribusi di VMware Engine NSX

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

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

Konfigurasi 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 private cloud secara konsisten, konfigurasi firewall gateway di router tier-0. Jika Anda perlu mengonfigurasi traffic utara-selatan untuk setiap segmen NSX, konfigurasikan firewall gateway di router tingkat 1.

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

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

Menerapkan prinsip Keamanan Zero Trust dan segmentasi mikro di NSX

Gunakan NSX DFW untuk menerapkan kontrol traffic bagi segmen keamanan yang sekecil mesin virtual individual. Prinsip melindungi traffic antar-VM yang ditolak secara default ini juga sering disebut sebagai "Mikro-segmentasi", yang merupakan pendekatan yang lebih terperinci untuk firewalling daripada penerapan firewall konvensional antar-domain Layer 3.

DFW diaktifkan di kernel hypervisor pada semua host vSphere VMware Engine di cloud pribadi Anda dan dapat mengontrol aliran 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 di mana pola traffic harus diizinkan secara eksplisit. Konsep keamanan yang mengontrol semua alur jaringan dengan proses verifikasi identitas dan perangkat, bukan kepercayaan implisit, juga sering disebut Keamanan Zero Trust.

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

Jika Anda memerlukan keamanan Layer 7 tingkat lanjut, termasuk kemampuan IDS/IPS untuk traffic masuk ke cloud pribadi dari jaringan Anda lainnya atau di antara segmen jaringan NSX Anda, pertimbangkan untuk men-deploy perangkat firewall pihak ketiga. Alat pihak ketiga dapat di-deploy sebagai alat multi-NIC di antara dua VPC di jaringan Anda atau di dalam private cloud dengan integrasi dengan NSX. Google Cloud

Untuk mempelajari arsitektur VMware Engine dengan peralatan terpusat secara mendalam, yang dapat digunakan untuk berbagai kasus penggunaan keamanan tingkat lanjut, seperti IPS/IDS, DDoS, pemindahan SSL, dan lainnya, lihat dokumen keamanan jaringan menggunakan peralatan terpusat di Pusat Arsitektur Cloud.

Menggunakan Google Cloud Armor untuk membantu 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 hybrid di belakang Cloud Service Mesh dan manfaatkan load balancer HTTP(S) eksternal. Dengan penyiapan ini, Anda dapat menyertakan Google Cloud Armor untuk aplikasi yang menghadap 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 Certificate Authority Service, 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 Google Cloud Layanan 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 mengirimkan traffic melalui internet karena hal ini mengurangi biaya dan latensi transfer data keluar. Hal ini juga menghilangkan kebutuhan akan 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 Google Cloud resource dari jaringan produsen layanan seperti instance Cloud SQL atau Memorystore harus terhubung secara pribadi menggunakan PSA. Untuk mengetahui informasi selengkapnya, buka bagian tentang PSA untuk VMware Engine.

Enkripsi 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 mengenkripsi data dalam pengiriman antara pusat data lokal Anda 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 menggunakan TLS.

Membantu 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. Penting untuk menangani izin dalam lingkungan VMware Engine dan project tempat cloud pribadi di-deploy. Google Cloud

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 lakukan 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, dan contoh aktivitas yang diizinkan oleh pengelola akses.

Platform Komponen Sumber identitas Tempat untuk mengonfigurasi izin Contoh aktivitas
Google Cloud Portal VMware Engine Cloud Identity Identity and Access Management Deployment dan pembatalan cloud pribadi, deployment dan pembatalan cluster, misalnya.
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 LDAP "Pengguna dan Peran" di UI NSX Manager Pembuatan segmen NSX, konfigurasi firewall, konfigurasi load balancer, misalnya.
vCenter Sistem Operasi Tamu VM Active Directory, LDAP, Pengguna Lokal, misalnya Sistem Operasi Tamu Login SSH atau RDP, operasi file, misalnya

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

  • Admin Layanan VMware Engine - memberikan akses penuh ke layanan VMware Engine di Google Cloud.
  • VMware Engine Service Viewer - memberikan akses hanya baca 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 untuk melihat detail layanan (Viewer). Secara umum, sebaiknya Anda menggunakan peran yang telah ditetapkan, bukan peran dasar, karena peran tersebut memberikan izin yang lebih terperinci.

Akses terprogram ke VMware Engine menggunakan akun layanan yang menggunakan API atau CLI harus dibatasi menggunakan peran bawaan atau peran kustom karena peran tersebut mencakup 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 bawaan, sebaiknya buat peran khusus.

Pilih lokasi yang sesuai untuk penetapan peran IAM dalam hierarki resource organisasi Anda. Jika Anda menjalankan semua cloud pribadi VMware Engine dalam satu project, peran hanya 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 sama dengan project yang digunakan untuk cloud pribadi Anda.

Izin Cloud IAM tidak diperlukan untuk aktivitas yang hanya perlu dilakukan di dalam vCenter, NSX, 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. Sebaiknya berikan peran VMware Engine Service Admin atau VMware Engine Service Viewer hanya kepada sejumlah kecil pengguna karena peran ini memberikan akses ke akun pengguna CloudOwner yang canggih untuk vCenter dan akun pengguna administrator untuk NSX. Akun pengguna ini hanya boleh digunakan untuk penyiapan awal atau prosedur darurat.

Membatasi dan mengaudit akses administrator secara aktif

Peran Admin Layanan VMware Engine sangat berkuasa dan hanya boleh diberikan kepada pengguna yang perlu mengelola siklus proses cloud pribadi VMware Engine dan cluster mereka. Biasanya, penambahan atau penghapusan cluster dan node secara manual adalah tindakan yang tidak sering terjadi dan dapat berdampak besar pada penagihan atau ketersediaan cluster. Hanya tetapkan peran ini kepada beberapa 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 atau di salah satu tingkat induk hierarki resource. Audit ini harus mencakup peran lain, seperti peran Editor dan Pemilik dasar yang mencakup izin penting terkait VMware Engine. Anda dapat menggunakan layanan seperti pemberi rekomendasi peran IAM untuk membantu mengidentifikasi peran yang memiliki terlalu banyak 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 ke vCenter dan NSX ke Active Directory untuk autentikasi Windows terintegrasi tidak didukung.

Merotasi sandi akun layanan bawaan

VMware Engine membuat kredensial untuk mengakses appliance pengelolaan di cloud pribadi (seperti vCenter, NSX, dan HCX). Sebaiknya Anda membuat proses untuk merotasi sandi akun layanan vCenter default CloudOwner@gve.local dan administrator akun layanan NSX default. Kedua akun pengguna hanya boleh digunakan untuk konfigurasi awal dan prosedur darurat, serta sandinya harus diubah secara rutin (misalnya, setiap 60 atau 90 hari). Atau, ganti sandi akun pengguna solusi secara rutin yang biasanya digunakan untuk mengintegrasikan alat pihak ketiga. Semakin sering Anda merotasi sandi akun layanan, semakin kecil kemungkinan sandi tersebut masih valid saat ditemukan oleh pihak tidak bertanggung jawab.

Logging dan Pemantauan VMware Engine

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

Menyerap log dan metrik VMware Engine

Banyak organisasi ingin mengumpulkan dan menganalisis log dalam "Single Pane of Glass" yang 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 penggunaan CPU dan memori ESXi ke Cloud Monitoring. Sebaiknya buat dasbor berdasarkan metrik yang diteruskan oleh vCenter, atau mulai dengan beberapa dasbor contoh yang telah dipublikasikan di GitHub.

Untuk mengumpulkan log platform, cloud pribadi VMware Engine dapat meneruskan log Syslog ke pengumpul log terpusat. Hal ini dapat dilakukan untuk pesan Syslog vCenter dan NSX. Pengumpulan, penyimpanan, dan analisis 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, pengumpul Syslog seperti Fluentd atau agen Standalone harus dikonfigurasi untuk meneruskan pesan ke Cloud Logging.

Sebaiknya analisis log dari VMware Engine di dasbor pusat dalam satu project. Jika lingkungan VMware Engine Anda mencakup beberapa project, Anda juga perlu 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 workload di kedua platform mengirimkan lognya 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 menyediakan kemampuan yang setara untuk persetujuan akses. Dalam kebijakan ini, operasi layanan standar memerlukan pembuatan tiket dukungan dengan alasan mengapa operator layanan memerlukan akses.

Google Cloud Pengecualian Persetujuan Akses 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 Google-owned and managed key yang diaktifkan untuk enkripsi vSAN dalam penyimpanan

Enkripsi data dalam penyimpanan diimplementasikan 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 mengaktifkan enkripsi vSAN di cluster ESXi mereka dan menonaktifkan enkripsi vSAN merupakan pelanggaran terhadap persyaratan layanan untuk VMware Engine. Banyak organisasi mewajibkan enkripsi saat istirahat 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 dibuat secara acak. DEK dienkripsi menggunakan Kunci Enkripsi Kunci (KEK) dan hanya disimpan di disk dalam bentuk terenkripsi. Server vCenter hanya menyimpan ID KEK, bukan 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 mengelola Cloud KMS sendiri, Anda dapat menggunakan Cloud KMS yang kompatibel dengan KMIP 1.1 pihak ketiga dari salah satu vendor yang didukung. Dalam kedua kasus tersebut, penyedia kunci dapat digunakan untuk mengenkripsi data dalam penyimpanan dan traffic vMotion dalam pengiriman.

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

Penyedia utama Kelebihan Kekurangan
Penyedia Google-owned and managed key default
  • Kesederhanaan: Di-deploy "langsung digunakan" tanpa pengelolaan vendor dan tanpa beban operasional
  • Dukungan end-to-end oleh Google
  • Metode paling sederhana untuk merotasi 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 SaaS KMS
  • Kemungkinan ketersediaan lebih rendah

Perhatikan bahwa sebaiknya Anda tidak mengaktifkan enkripsi tingkat VM bersama dengan enkripsi datastore vSAN karena efisiensi penghapusan duplikasi 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 baik untuk penyedia kunci default maupun 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 bisnis mengandalkan data Anda yang tersedia hampir setiap saat, sehingga Anda hanya memiliki sedikit waktu untuk memulihkan data dari gangguan mendadak. Bagian ini tidak berisi cakupan lengkap dari semua aspek pencadangan dan pemulihan 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 Anda 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 beban kerja di Compute Engine dan VMware Engine. Google Cloud Layanan Pencadangan dan DR adalah satu-satunya solusi yang direkomendasikan Google untuk pencadangan beban kerja karena menawarkan manfaat seperti dukungan spektrum luas untuk beban kerja, pencadangan yang efisien ruang, pencadangan inkremental selamanya, dan opsi penyimpanan yang fleksibel.

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

  • Pencadangan ini menyediakan pencadangan tingkat aplikasi
  • Mereka disertifikasi oleh vendor aplikasi
  • VM ini disertifikasi oleh VMware Engine untuk vSAN
  • Mereka mendukung standar protokol VMware Engine vStorage API for Data Protection (VADP) atau melakukan pencadangan tingkat aplikasi

Apa pun solusi pencadangan yang Anda pilih, sebaiknya gunakan Cloud Storage sebagai opsi penyimpanan hemat biaya untuk retensi jangka panjang cadangan. Cloud Storage adalah penyimpanan objek yang sangat tahan lama dan hemat biaya. Bucket Cloud Storage dapat dikonfigurasi untuk mereplikasi objek penyimpanan secara otomatis 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 pakainya melebihi nilai yang telah ditentukan sebelumnya. Gunakan opsi ini untuk lokasi dan media penyimpanan cadangan yang hemat biaya dengan 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 pengarsipan jangka panjang, karena ada risiko ukuran cluster VMware Engine menjadi terikat penyimpanan.

Menerapkan pemulihan dari bencana dengan Layanan Pencadangan dan DR

Sebaiknya pulihkan aplikasi di VMware Engine menggunakan Layanan Pencadangan dan DR. Untuk membantu melindungi workload produksi Anda dari pemadaman layanan satu zona di dalam region, sebaiknya deploy dan operasikan cloud pribadi di zona sekunder 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 and 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 berikutnya