Halaman ini diterjemahkan oleh Cloud Translation API.

Praktik terbaik untuk keamanan VMware Engine

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

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

Networking VMware Engine

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

Mengidentifikasi dan memahami semua arus lalu lintas di 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 tenancy yang dikelola Google.

Gunakan Public IP Service VMware Engine untuk transfer data internet

Traffic internet dapat masuk ke cloud pribadi secara langsung menggunakan Public IP Service dari VMware Engine. Atau, traffic internet dapat masuk menggunakan load balancer publik di Google Cloud. Dalam hal ini, lalu lintas dirutekan seperti lalu lintas 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 terhubung ke internet melalui jaringan VPC.

Jika hal ini tidak berlaku untuk Anda atau Anda memiliki kontrol yang diimplementasikan dalam cloud pribadi Anda, 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 utara-selatan dan timur-barat yang terpisah pada gateway dan firewall terdistribusi di VMware Engine NSX-T

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

Untuk kontrol akses jaringan yang mendetail, pastikan Anda 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 dalam aplikasi Anda.

Konfigurasikan gateway firewall 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 utara-selatan 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 individual, konfigurasikan firewall gateway di router tingkat 1.

Selain firewall NSX-T, sebaiknya gunakan firewall VPC untuk mengizinkan dan memblokir traffic timur-barat 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 peralatan pengelolaan serta ke rentang CIDR vSphere/vSAN harus diblokir dari VPC juga menggunakan Firewall VPC. Hanya transfer data keluar terbuka menuju peralatan pengelolaan dari host dan alamat IP tepercaya di dalam jaringan Anda. Penting untuk diperhatikan bahwa peralatan pengelolaan tidak berada di dalam segmen NSX-T dan dengan demikian, aturan DFW tidak berlaku untuk membatasi akses.

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

Gunakan NSX-T DFW untuk menerapkan kontrol traffic untuk segmen keamanan yang mendetail seperti virtual machine individual. Prinsip melindungi traffic antara masing-masing VM yang ditolak secara default ini sering kali disebut juga 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 pada semua host vSphere VMware Engine di cloud pribadi Anda dan dapat mengontrol aliran traffic antar beban kerja yang berada di segmen NSX yang sama maupun 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 terperinci di mana pola traffic harus diizinkan secara eksplisit. Konsep keamanan ketika semua alur jaringan dikontrol oleh proses verifikasi identitas dan perangkat, bukan kepercayaan implisit, sering juga disebut Keamanan Zero Trust.

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

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

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

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

Jika Anda mengarahkan traffic masuk ke workload di VMware Engine melalui VPC pelanggan, sebaiknya tempatkan workload VMware Engine di grup endpoint jaringan hybrid di belakang Cloud Service Mesh dan manfaatkan load balancer HTTP(S) eksternal. Dengan salah satu penyiapan, Anda dapat menyertakan Google Cloud Armor untuk aplikasi yang ditampilkan ke publik, 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 kasus lainnya, sebaiknya gunakan load balancer HTTP(S) eksternal.

Ikuti dokumentasi tentang cara menambahkan workload VMware Engine ke NEG Hybrid dengan salah satu setelan 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 gunakan Akses Google Pribadi untuk mengakses layanan Google tanpa mengirim traffic melalui internet karena cara ini mengurangi latensi dan biaya transfer data keluar. Hal ini juga menghilangkan kebutuhan akan jalur jaringan ke internet untuk workload yang hanya memerlukan akses Google API. Ikuti pembahasan mendalam tentang Akses Google Pribadi untuk mengetahui detail teknis dan langkah-langkah konfigurasi lainnya.

Demikian pula, workload 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 tentang 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 Anda dan Google Cloud. Link antara sistem lokal dan Google Cloud dapat dienkripsi dengan menyiapkan Cloud VPN dengan tunnel IPsec atau menggunakan IPsec bawaan pada lampiran VLAN di Interconnect. Selain itu, enkripsi lapisan aplikasi harus diaktifkan antar-komponen aplikasi menggunakan TLS.

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

Sebaiknya kurangi 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. Beban kerja yang perlu mengakses data di dalam perimeter juga harus ditempatkan di 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 di konfigurasi Kontrol Layanan VPC untuk mengizinkan API layanan produsen VMware Engine ke perimeter. Untuk panduan terperinci 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 memperhatikan izin dalam lingkungan VMware Engine dan project Google Cloud tempat cloud pribadi di-deploy.

Gunakan peran bawaan atau peran khusus untuk memberikan akses

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

Platform	Komponen	Sumber identitas	Tempat 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, serta datastore di UI vCenter	Pembuatan VM, pembuatan folder VM, pembuatan dan penghapusan objek datastore, misalnya
VMware Engine	NSX-T	LDAP	"Pengguna dan Peran" di UI Pengelola NSX-T	Misalnya pembuatan segmen NSX, konfigurasi firewall, dan konfigurasi load balancer.
vCenter	Sistem Operasi Tamu VM	Active Directory, LDAP, Local Users, 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:

VMware Engine Service Admin - 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 berhubungan dengan tindakan di portal VMware Engine dan tidak berhubungan dengan tindakan di API atau CLI. Perhatikan bahwa peran dasar juga dapat mencakup kemampuan untuk mengelola layanan VMware Engine (Pemilik, Editor) atau melihat detail layanan (Viewer). Umumnya, sebaiknya gunakan peran bawaan, 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 khusus karena mencakup izin 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, hanya peran yang dapat ditetapkan di level project. Jika ada persyaratan teknis atau organisasi yang menyebabkan cloud pribadi Anda ditempatkan 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-T, atau HCX. Staf yang hanya perlu mengoperasikan lingkungan ini tidak memerlukan peran IAM yang telah 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 tersebut memberikan akses ke akun pengguna CloudOwner yang andal untuk vCenter dan akun pengguna administrator untuk NSX-T. Akun pengguna ini hanya boleh digunakan untuk penyiapan awal atau prosedur darurat.

Membatasi dan mengaudit akses administrator secara aktif

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 secara manual cluster dan node adalah tindakan yang jarang terjadi dan dapat berdampak tinggi pada penagihan atau ketersediaan cluster. Tetapkan peran ini hanya kepada sedikit orang di organisasi Anda.

Pastikan untuk secara rutin mengaudit siapa yang telah diberi peran VMware Engine Service Admin, baik secara langsung pada project yang digunakan untuk VMware Engine maupun pada salah satu level induk hierarki resource. Audit ini harus mencakup peran lain, seperti peran dasar Editor dan Pemilik yang mencakup izin penting terkait VMware Engine. Anda dapat menggunakan layanan seperti pemberi rekomendasi peran IAM untuk membantu mengidentifikasi peran yang terlalu 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. Praktik ini direkomendasikan untuk memiliki pengelolaan siklus proses identitas terpusat, pengelolaan grup, pengelolaan sandi, dan lainnya. Perhatikan bahwa menggabungkan secara langsung dengan vCenter dan NSX-T ke Active Directory untuk autentikasi Windows terintegrasi tidak didukung.

Merotasi sandi akun layanan bawaan

VMware Engine menghasilkan kredensial untuk mengakses peralatan 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 sandi mereka dirotasi secara rutin (misalnya, setiap 60 atau 90 hari). Secara rutin, ganti sandi akun pengguna solusi yang biasa digunakan untuk integrasi alat pihak ketiga secara setara. Semakin sering Anda memutar sandi akun layanan, semakin kecil kemungkinan sandi tersebut masih valid saat pihak tidak bertanggung jawab menemukannya.

Logging dan Monitoring VMware Engine

Bagian berikut memperkenalkan praktik terbaik untuk logging dan pemantauan beban kerja 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" terpusat. Di Google Cloud, produk Cloud Logging dan Cloud Monitoring menyediakan layanan yang dapat digunakan untuk pengelolaan log dan metrik terpusat. VMware Engine dapat diintegrasikan dengan Cloud Monitoring menggunakan agen mandiri. Dalam konfigurasi ini, vCenter meneruskan metrik seperti penggunaan memori dan CPU ESXi ke Cloud Monitoring. Sebaiknya buat dasbor berdasarkan metrik yang diteruskan oleh vCenter, atau untuk memulai dengan 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 baik untuk pesan vCenter maupun NSX-T Syslog. Mengumpulkan, menyimpan, 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 situasi tertentu. 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 pusat 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 resource yang lancar dan mengalirkan log dari aplikasi pihak ketiga dan software sistem yang umum 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 estate lokal Anda (jika berlaku). Penggunaan agen Logging di VMware Engine cocok dengan pendekatan yang digunakan untuk VM di Compute Engine sehingga workload pada kedua platform mengirim log mereka ke Cloud Logging.

Menerapkan kemampuan yang setara pada 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 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. Namun, Anda perlu mengajukan permintaan dukungan ke Google Cloud untuk mengonfigurasi penerusan syslog ESXi.

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

Pengecualian Persetujuan Akses Google Cloud berlaku.

Enkripsi VMware Engine

Bagian berikut ini menjelaskan praktik terbaik untuk enkripsi penyimpanan di cloud pribadi, dan faktor-faktor mengemudi yang perlu dipertimbangkan saat memilih penyedia kunci untuk cloud pribadi Anda.

Gunakan penyedia kunci yang dikelola Google 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 tetap mengaktifkan enkripsi vSAN di cluster ESXi mereka, dan menonaktifkan enkripsi vSAN merupakan pelanggaran terhadap persyaratan layanan untuk VMware Engine. Banyak organisasi mewajibkan enkripsi 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 AES-256 XTS 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, tetapi tidak untuk KEK itu sendiri yang disimpan dalam 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 diharuskan mengelola sendiri Cloud KMS, Anda dapat menggunakan Cloud KMS yang mematuhi KMIP 1.1 pihak ketiga oleh salah satu vendor yang didukung. Pada kedua kasus tersebut, penyedia kunci dapat digunakan untuk mengenkripsi data dalam penyimpanan dan traffic vMotion selama pengiriman.

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

Penyedia kunci	Kelebihan	Kekurangan
Penyedia kunci default yang dikelola Google	Kemudahan: Di-deploy "siap pakai" tanpa pengelolaan vendor dan tanpa beban operasional Dukungan end-to-end oleh Google Metode termudah untuk merotasi DEK/KEK adalah persyaratan utamanya Tanpa biaya tambahan Redundansi zona bawaan untuk ketersediaan tinggi	Tidak mungkin membawa materi kunci Anda sendiri (BYOK) KEK disimpan dan dikelola di infrastruktur Google. External Key Managers (EKM) tidak didukung.
Penyedia kunci Cloud KMS pihak ketiga	Kontrol penuh atas data terenkripsi dan kunci enkripsi Kunci yang didukung hardware dapat disimpan dalam alat HSM	Kompleksitas tambahan dan overhead operasional Biaya tambahan Kemungkinan latensi tambahan, terutama dalam kasus SaaS KMS Kemungkinan ketersediaan lebih rendah

Perhatikan bahwa sebaiknya jangan mengaktifkan 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 baik dengan penyedia kunci default maupun dengan Cloud KMS eksternal. Rotasi KEK dapat dimulai dari vCenter atau menggunakan API-nya. Pertimbangkan untuk mengotomatiskan rotasi KEK sesuai dengan kebutuhan 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 yang penting bagi bisnis mengandalkan data Anda yang tersedia secara virtual setiap saat, sehingga hanya ada sedikit waktu untuk memulihkan data dari pemadaman layanan yang tiba-tiba. Bagian ini tidak berisi cakupan lengkap semua aspek pencadangan dan pemulihan dari bencana (disaster recovery) yang relevan untuk mendesain strategi pencadangan dan DR secara efektif agar data Anda tetap aman dan tersedia, tetapi memuat pertimbangan utama saat memilih strategi yang tepat untuk lingkungan VMware Engine Anda.

Mencadangkan workload menggunakan Layanan Pencadangan dan DR

Dengan Layanan Pencadangan dan DR, Google Cloud menawarkan solusi pencadangan bawaan yang dikelola secara terpusat dan dapat digunakan untuk berbagai kasus penggunaan, termasuk pencadangan beban kerja di Compute Engine dan Google Cloud VMware Engine. Layanan Pencadangan dan DR adalah solusi tunggal yang direkomendasikan Google untuk pencadangan workload, karena menawarkan berbagai manfaat seperti dukungan workload yang luas, pencadangan yang hemat ruang, pencadangan inkremental selamanya, dan 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 meliputi hal berikut:

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

Apa pun solusi pencadangan pilihan Anda, kami merekomendasikan 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 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 otomatis memindahkan objek penyimpanan 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 menjadi faktor pendorong.

Atau, Anda dapat memilih penyimpanan {i>vSAN<i} 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 arsip jangka panjang, karena ada risiko bahwa ukuran cluster VMware Engine akan terikat dengan penyimpanan.

Menerapkan pemulihan dari bencana dengan Layanan Pencadangan dan DR

Sebaiknya pulihkan aplikasi di VMware Engine menggunakan Layanan Cadangan dan DR. Untuk melindungi workload produksi Anda dari pemadaman pada satu zona di dalam suatu 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 Pencadangan dan DR Google Cloud, VMware Engine kompatibel dengan opsi DR lain seperti VMware Engine SRM dan Zerto. VMware Engine SRM maupun 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
Networking VMware Engine	Mengidentifikasi dan memahami semua alur traffic di lingkungan Anda Gunakan Public IP Service VMware Engine untuk transfer data internet Aturan firewall utara-selatan dan timur-barat yang terpisah di gateway dan firewall terdistribusi di VMware Engine NSX-T Menerapkan prinsip Keamanan Zero-Trust dan segmentasi mikro di NSX-T Men-deploy peralatan firewall pihak ketiga dari portal Cloud Marketplace untuk kemampuan IPS/IDS Gunakan Google Cloud Armor untuk melindungi layanan web di VMware Engine dari serangan DDoS Terhubung ke Layanan Google Cloud secara pribadi tanpa akses internet Mengenkripsi komunikasi antara lingkungan lokal Anda dan Google Cloud Melindungi data Anda dari pemindahan yang tidak sah menggunakan Kontrol Layanan VPC
IAM dan Izin VMware Engine	Menggunakan peran bawaan atau peran khusus untuk memberikan akses ke VMware Engine Membatasi dan mengaudit akses administrator ke VMware Engine secara aktif Mengonfigurasi sumber identitas LDAP atau Active Directory Merotasi sandi akun layanan VMware Engine bawaan
Logging dan Monitoring VMware Engine	Penyerapan log dan metrik VMware Engine Menggunakan agen Cloud Logging untuk logging VM workload Menerapkan kemampuan yang setara dengan kebijakan Transparansi Akses dan Persetujuan Akses
Enkripsi VMware Engine	Menggunakan Penyedia kunci yang dikelola Google yang diaktifkan untuk enkripsi vSAN dalam penyimpanan Otomatiskan rotasi kunci enkripsi sesuai dengan standar organisasi Anda
Pencadangan dan Pemulihan dari Bencana (Disaster Recovery) VMware Engine	Mencadangkan workload menggunakan Pencadangan dan DR Menerapkan pemulihan dari bencana dengan Pencadangan dan DR

Langkah selanjutnya

Coba Google Cloud VMware Engine untuk diri Anda sendiri. Buka fitur, manfaat, dan kasus penggunaan untuk mengetahui informasi selengkapnya.
Baca konsep keamanan VMware Engine.
Pelajari arsitektur referensi, diagram, tutorial, dan praktik terbaik tentang Google Cloud. Kunjungi Cloud Architecture Center untuk mengetahui informasi lebih lanjut.