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, Anda dapat mempertimbangkan untuk memulai 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 efek titik kegagalan.

Jaringan VMware Engine

Bagian berikut ini 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 Layanan IP Publik VMware Engine untuk transfer data internet

Traffic internet dapat langsung memasuki cloud pribadi menggunakan Layanan IP Publik dari VMware Engine. Atau, traffic internet dapat masuk menggunakan load balancer publik di Google Cloud. Dalam hal ini, lalu lintas data dirutekan seperti lalu lintas masuk lainnya. Perhatikan bahwa opsi ini bersifat eksklusif satu sama lain. Jika kontrol kustom diperlukan untuk traffic internet, seperti pemfilteran URL, IPS/IDS, atau pemeriksaan traffic yang disediakan oleh layanan atau instance terpusat di lingkungan Google Cloud, 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, 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 pada gateway dan firewall terdistribusi di VMware Engine NSX-T

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

Untuk kontrol akses jaringan yang sangat detail, pastikan Anda menerapkan kebijakan default terbatas pada DFW untuk menolak traffic jaringan antar-instance secara default. Gunakan DFW untuk secara khusus mengizinkan traffic antaraplikasi dan antar-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 pada 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 pada 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 hanya dengan traffic yang dibuka secara sadar.

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

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

Gunakan NSX-T DFW guna menerapkan kontrol traffic untuk segmen keamanan yang sespesifik mungkin seperti virtual machine individual. Prinsip melindungi traffic antara VM individu yang ditolak secara default ini sering disebut juga sebagai "Segmentasi mikro", yang merupakan pendekatan yang lebih terperinci untuk firewall dibandingkan dengan implementasi firewall konvensional antara domain Lapisan 3.

DFW diaktifkan di kernel hypervisor di semua host VMware Engine vSphere di cloud pribadi Anda dan dapat mengontrol aliran traffic antar beban kerja yang berada di segmen yang sama atau berada di segmen NSX 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 terperinci di mana pola traffic harus diizinkan secara eksplisit. Konsep keamanan di mana semua alur jaringan dikontrol oleh proses verifikasi identitas dan perangkat, bukan kepercayaan implisit, juga disebut sebagai Keamanan Zero-Trust.

Men-deploy alat 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 Anda atau di antara segmen jaringan NSX-T, pertimbangkan untuk men-deploy alat firewall pihak ketiga. Perangkat pihak ketiga dapat di-deploy sebagai perangkat multi-NIC antara dua VPC di jaringan Google Cloud Anda atau di dalam cloud pribadi dengan integrasi dengan NSX-T.

Untuk mempelajari arsitektur VMware Engine secara mendalam dengan peralatan terpusat, yang dapat digunakan untuk berbagai kasus penggunaan keamanan lanjutan, seperti IPS/IDS, DDoS, pembongkaran 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 mengarahkan traffic masuk ke workload di VMware Engine melalui VPC pelanggan, sebaiknya tempatkan workload VMware Engine di grup endpoint jaringan hybrid di belakang Traffic Director dan manfaatkan load balancer HTTP(S) eksternal. Kedua penyiapan tersebut dapat Anda gunakan untuk menyertakan Google Cloud Armor untuk aplikasi yang ditampilkan kepada 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 Traffic Director. Dalam kasus lain, sebaiknya gunakan load balancer HTTP(S) eksternal.

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

Menghubungkan 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 mengirimkan traffic melalui internet karena dapat mengurangi biaya dan latensi transfer data keluar. Hal ini juga menghilangkan kebutuhan jalur jaringan ke internet untuk workload yang hanya memerlukan akses Google API. Ikuti pembahasan mengenai Akses Google Pribadi secara mendalam untuk mengetahui detail teknis dan langkah-langkah konfigurasi selengkapnya.

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, kunjungi 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. Kami merekomendasikan 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 menggunakan tunnel IPsec atau menggunakan IPsec bawaan pada lampiran VLAN Interconnect. Selain itu, enkripsi lapisan aplikasi harus diaktifkan di antara 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 seperti bucket Cloud Storage dan set data BigQuery ke dalam perimeter Kontrol Layanan VPC. Beban kerja yang perlu mengakses data di dalam perimeter juga perlu 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 agar dapat mengizinkan API layanan produsen VMware Engine masuk ke dalam perimeter. Untuk panduan mendetail terkait 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 menjaga 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 saat Anda memanfaatkan dari 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 cluster 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
VMware Engine	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	{i>Active Directory<i}, LDAP, Pengguna Lokal, misalnya	Sistem Operasi Tamu	Login SSH atau RDP, operasi file, misalnya

Di Google Cloud IAM, ada dua peran yang telah ditetapkan 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 berkaitan dengan tindakan di portal VMware Engine dan tidak berkaitan dengan tindakan di API atau CLI. Perhatikan bahwa peran dasar juga mencakup kemampuan untuk mengelola layanan VMware Engine (Pemilik, Editor) atau melihat detail layanan (Viewer). Secara umum, sebaiknya gunakan peran bawaan, bukan peran dasar, karena peran tersebut memberikan izin yang lebih mendetail.

Akses terprogram ke VMware Engine menggunakan akun layanan yang menggunakan API atau CLI harus dibatasi menggunakan peran bawaan atau peran khusus karena 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 yang telah ditetapkan, 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 dalam project terpisah, tentukan peran yang diperlukan dalam folder yang umum untuk 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 tercantum sebelumnya. Sebagai gantinya, jaringan tersebut harus menggunakan identitas LDAP dengan izin yang dikonfigurasi di vCenter dan NSX-T. Sebaiknya berikan peran Admin Layanan VMware Engine atau VMware Engine Viewer hanya kepada sejumlah pengguna yang sangat terbatas karena peran ini 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 Admin Layanan VMware Engine sangat andal 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 merupakan tindakan yang tidak sering terjadi dan dapat berdampak tinggi terhadap penagihan atau ketersediaan cluster. Hanya tetapkan peran ini kepada sangat sedikit orang di organisasi Anda.

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

Mengonfigurasi sumber identitas LDAP atau Active Directory

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

Merotasi sandi akun layanan bawaan

VMware Engine membuat 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 sandinya dirotasi secara rutin (misalnya, setiap 60 atau 90 hari). Merotasikan sandi akun pengguna solusi yang biasa digunakan untuk integrasi alat pihak ketiga secara berkala. Semakin sering Anda merotasi sandi akun layanan, semakin kecil kemungkinan sandi 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 oleh 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 yang 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 untuk memulai 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 harus dilakukan hanya 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 kelancaran dan mengalirkan 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 estate 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 mengirim log mereka ke Cloud Logging.

Menerapkan kemampuan yang setara dengan kebijakan Transparansi Akses dan Persetujuan Akses

Meskipun VMware Engine tidak mendukung transparansi akses (AxT) dan persetujuan akses (AxA) di Google Cloud, kami telah mengimplementasikan 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, tetapi Anda perlu mengajukan permintaan dukungan ke Google Cloud untuk mengonfigurasi penerusan syslog ESXi.

Jika Anda memiliki persyaratan peraturan yang ketat, kami akan menerapkan kebijakan untuk memberikan kemampuan yang setara guna mendapatkan 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 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 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 pada cluster ESXi mereka, dan menonaktifkan enkripsi vSAN merupakan pelanggaran persyaratan layanan untuk VMware Engine. Banyak organisasi mewajibkan enkripsi dalam penyimpanan sebagai bagian dari kebijakan perusahaan 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 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 bukan KEK itu sendiri yang disimpan di Cloud Key Management Service (KMS). Anda dapat memilih lokasi Cloud KMS tempat menyimpan KEK Anda.

Sebaiknya gunakan penyedia kunci default yang dikelola Google. Namun, jika perlu mengelola Cloud KMS sendiri, Anda dapat menggunakan Cloud KMS pihak ketiga yang mematuhi KMIP 1.1 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 menunjukkan perbedaan utama antara integrasi penyedia kunci default dan Cloud KMS pihak ketiga:

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

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

Otomatiskan rotasi kunci enkripsi sesuai dengan standar organisasi Anda

Anda bertanggung jawab atas rotasi KEK menggunakan VMware Engine vSphere. Hal ini terjadi baik pada 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 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 yang penting bagi bisnis mengandalkan data Anda yang tersedia hampir setiap saat, sehingga Anda tidak perlu banyak waktu untuk memulihkan data dari pemadaman layanan yang tiba-tiba. Bagian ini tidak berisi cakupan lengkap tentang semua aspek pencadangan dan pemulihan dari bencana yang relevan untuk merancang strategi pencadangan dan DR secara efektif guna menjaga data Anda tetap aman dan tersedia, tetapi berisi pertimbangan utama saat memilih strategi yang tepat untuk lingkungan VMware Engine Anda.

Cadangkan workload Anda menggunakan Layanan Pencadangan dan DR

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 Google Cloud VMware Engine. Layanan Pencadangan dan DR adalah solusi tunggal yang direkomendasikan Google untuk pencadangan beban kerja, karena menawarkan manfaat seperti rentang dukungan workload yang luas, 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 cadangan pihak ketiga. Prasyarat untuk jenis alat ini mencakup hal-hal berikut:

Mereka menyediakan pencadangan tingkat aplikasi
Aplikasi disertifikasi oleh vendor aplikasi
Mereka disertifikasi oleh VMware Engine untuk vSAN
Alat 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 yang hemat biaya untuk retensi cadangan jangka panjang. Cloud Storage adalah penyimpanan objek yang sangat tahan lama dan hemat biaya. Bucket Cloud Storage dapat dikonfigurasi agar 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 merupakan faktor penggerak.

Atau, Anda dapat memilih penyimpanan vSAN untuk meminimalkan RPO. Gunakan opsi penyimpanan ini jika biaya penyimpanan cadangan yang lebih tinggi 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 akan terikat dengan penyimpanan.

Menerapkan pemulihan dari bencana dengan Layanan Pencadangan dan DR

Sebaiknya pulihkan aplikasi di VMware Engine menggunakan Layanan Pencadangan dan DR. Untuk melindungi beban kerja produksi dari pemadaman layanan 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 region tersebut. Jika tidak, sebaiknya pulihkan aplikasi Anda di region sekunder.

Selain Pencadangan dan DR Google Cloud, VMware Engine kompatibel dengan opsi lain untuk DR seperti VMware Engine SRM dan Zerto. SRM VMware Engine 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	Mengidentifikasi dan memahami semua alur traffic di lingkungan Anda Gunakan Layanan IP Publik VMware Engine untuk transfer data internet Memisahkan aturan firewall utara-selatan dan timur-barat pada gateway dan firewall terdistribusi di VMware Engine NSX-T Menerapkan prinsip Keamanan Zero-Trust dan segmentasi mikro di NSX-T Deploy alat 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 Menghubungkan ke Layanan Google Cloud secara pribadi tanpa akses internet Mengenkripsi komunikasi antara lingkungan lokal Anda dan Google Cloud Lindungi data Anda dari pemindahan yang tidak sah menggunakan Kontrol Layanan VPC
IAM dan Izin VMware Engine	Gunakan peran bawaan atau peran khusus untuk memberikan akses ke VMware Engine Membatasi dan secara aktif mengaudit akses administrator ke VMware Engine Mengonfigurasi sumber identitas LDAP atau Active Directory Merotasi sandi akun layanan VMware Engine bawaan
Logging dan Pemantauan VMware Engine	Serap 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 Anda menggunakan Pencadangan dan DR Menerapkan pemulihan dari bencana dengan Pencadangan dan DR

Langkah selanjutnya

Coba Google Cloud VMware Engine 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. Buka Cloud Architecture Center untuk mengetahui informasi selengkapnya.