Networking untuk akses intra-cloud yang aman: Arsitektur referensi

Last reviewed 2023-11-13 UTC

Dokumen ini adalah bagian dari rangkaian yang menjelaskan arsitektur keamanan dan jaringan untuk perusahaan yang memigrasikan workload pusat data ke Google Cloud.

Seri ini terdiri dari dokumen berikut:

Workload untuk kasus penggunaan intra-cloud berada di jaringan VPC dan perlu terhubung ke resource lain di Google Cloud. Library tersebut mungkin menggunakan layanan yang disediakan secara native di cloud, seperti BigQuery. Perimeter keamanan disediakan oleh berbagai kemampuan pihak pertama (1P) dan pihak ketiga (3P) seperti firewall, Kontrol Layanan VPC, dan peralatan virtual jaringan.

Dalam banyak kasus, beban kerja ini mencakup beberapa jaringan VPC Google Cloud, dan batas antara jaringan VPC harus diamankan. Dokumen ini membahas keamanan dan konektivitas ini secara mendalam.

Arsitektur lift-and-shift

Skenario pertama untuk kasus penggunaan intra-cloud adalah arsitektur lift-and-shift di mana Anda memindahkan beban kerja yang sudah ada ke cloud apa adanya.

Firewall

Anda dapat membantu membangun perimeter yang aman dengan mengonfigurasi aturan firewall. Anda dapat menggunakan tag jaringan untuk menerapkan aturan firewall terperinci ke kumpulan VM. Tag adalah atribut arbitrer yang terdiri dari string karakter yang ditambahkan ke kolom tags VM pada saat pembuatan VM. Tag juga dapat ditetapkan nanti dengan mengedit VM. Untuk panduan penerapan tentang cara mengelola traffic dengan aturan firewall Google Cloud, lihat Kebijakan firewall jaringan dalam blueprint fondasi perusahaan.

Anda juga dapat menggunakan logging firewall untuk mengaudit dan memverifikasi efek dari setelan aturan firewall.

Anda dapat menggunakan VPC Flow Logs untuk forensik jaringan dan menstreaming log untuk berintegrasi dengan SIEM. Sistem ini dapat memberikan pemantauan real time, korelasi peristiwa, analisis, dan notifikasi keamanan.

Gambar 1 menunjukkan bagaimana aturan firewall dapat menggunakan tag VM untuk membantu membatasi traffic di antara VM dalam jaringan VPC.

Konfigurasi firewall jaringan yang menggunakan tag jaringan untuk menerapkan kontrol traffic keluar yang mendetail.

Gambar 1. Konfigurasi firewall jaringan yang menggunakan tag jaringan untuk menerapkan kontrol keluar yang mendetail.

Alat virtual jaringan

Sebuah network virtual appliance (NVA) adalah VM yang memiliki beberapa antarmuka jaringan. NVA memungkinkan Anda terhubung langsung ke beberapa jaringan VPC. Fungsi keamanan seperti firewall aplikasi web (WAF) dan firewall tingkat aplikasi keamanan dapat diterapkan di VM. Anda dapat menggunakan NVA untuk menerapkan fungsi keamanan pada traffic timur-barat, terutama saat menggunakan konfigurasi hub-spoke, seperti yang ditunjukkan pada gambar 2.

Untuk mengetahui panduan implementasi tentang cara menggunakan NVA di Google Cloud, lihat Peralatan jaringan terpusat di Google Cloud.

Konfigurasi alat jaringan terpusat dalam jaringan VPC Bersama.

Gambar 2. Konfigurasi alat jaringan terpusat dalam jaringan VPC Bersama.

Cloud IDS

Cloud Intrusion Detection System (Cloud IDS) memungkinkan Anda menerapkan pemeriksaan dan logging keamanan native dengan mencerminkan traffic dari subnet di jaringan VPC Anda. Dengan Cloud IDS, Anda dapat memeriksa dan memantau berbagai ancaman di lapisan jaringan dan di lapisan aplikasi untuk dianalisis. Anda membuat endpoint Cloud IDS di jaringan VPC yang terkait dengan project Google Cloud Anda. Endpoint ini memantau traffic masuk dan keluar ke dan dari jaringan tersebut, serta traffic jaringan intra-VPC, dengan menggunakan fungsi pencerminan paket yang disertakan ke dalam stack jaringan Google Cloud. Anda harus mengaktifkan akses layanan pribadi agar dapat terhubung ke project produsen layanan (project yang dikelola Google ) yang menjadi {i>host<i} proses Cloud IDS.

Jika Anda memiliki arsitektur hub-and-spoke, traffic dari setiap jari-jari dapat dicerminkan ke instance Cloud IDS, seperti yang ditunjukkan pada gambar 3.

Konfigurasi Cloud IDS untuk menduplikasi traffic VPC yang menggunakan akses layanan pribadi.

Gambar 3. Konfigurasi Cloud IDS untuk menduplikasi traffic VPC yang menggunakan akses layanan pribadi.

Cloud IDS dapat diamankan di perimeter layanan Kontrol Layanan VPC Anda menggunakan langkah tambahan. Anda dapat membaca lebih lanjut dukungan Kontrol Layanan VPC dalam produk yang didukung.

Peering Jaringan VPC

Untuk aplikasi yang mencakup beberapa jaringan VPC, baik dalam project Google Cloud yang sama maupun resource organisasi yang sama, Peering Jaringan VPC memungkinkan konektivitas antarjaringan VPC. Konektivitas ini memungkinkan traffic tetap berada dalam jaringan Google sehingga tidak melewati internet publik.

Ada dua model untuk menggunakan Peering Jaringan VPC dalam arsitektur lift-and-shift. Salah satunya adalah dengan arsitektur hub-and-spoke yang "murni", dan yang lainnya menggunakan arsitektur hub-and-spoke dengan transittivitas—dengan traffic dari satu jari yang dapat menjangkau jari-jari lainnya. Bagian berikut memberikan detail cara menggunakan Peering Jaringan VPC dengan arsitektur yang berbeda-beda ini.

Arsitektur hub-and-spoke

Sebuah Arsitektur hub-and-spoke adalah model populer untuk konektivitas VPC yang menggunakan Peering Jaringan VPC. Model ini berguna saat perusahaan memiliki berbagai aplikasi yang perlu mengakses serangkaian layanan umum, seperti logging atau autentikasi. Model ini juga berguna jika perusahaan perlu menerapkan serangkaian kebijakan keamanan umum untuk traffic yang keluar dari jaringan melalui hub. Pada model hub-and-spoke murni, pertukaran traffic di antara jari-jari (dikenal sebagai traffic transitif) tidak diizinkan. Gambar 4 menunjukkan arsitektur hub-and-spoke murni yang menggunakan Peering Jaringan untuk menghubungkan spoke ke hub. Untuk panduan implementasi guna membangun jaringan hub-and-spoke, lihat Topologi jaringan Hub-and-spoke dalam blueprint fondasi perusahaan.

Namun, jika tidak memerlukan pemisahan tingkat VPC, Anda dapat menggunakan arsitektur VPC Bersama yang mungkin menyediakan model yang lebih sederhana untuk beberapa perusahaan yang baru memulai di Google Cloud.

Arsitektur jaringan hub-and-spoke yang menggunakan Peering Jaringan VPC untuk isolasi jaringan dan konektivitas non-transitif.

Gambar 4. Arsitektur jaringan hub-and-spoke yang menggunakan Peering Jaringan VPC untuk isolasi jaringan dan konektivitas non-transitif.

Menghubung dan terhubung dengan transitivitas

Untuk mengaktifkan hub-and-spoke dengan transitivitas (traffic dari jari-jari lain dapat menjangkau jari-jari lain melalui hub), ada beberapa pendekatan yang menggunakan Peering Jaringan VPC. Anda dapat menggunakan Peering Jaringan VPC dalam topologi mesh penuh, di mana setiap jaringan VPC secara langsung berhubungan dengan setiap jaringan VPC lain yang perlu dijangkau.

Atau, Anda dapat menggunakan NVA untuk menghubungkan hub dan jari-jarinya secara bersamaan. NVA kemudian berada di belakang load balancer internal yang digunakan sebagai next-hop untuk traffic dari jari-jari VPC. Gambar 5 menunjukkan kedua opsi ini.

Selain itu, Anda dapat menggunakan VPN untuk terhubung antara jaringan hub dan spoke VPC networks. Pengaturan ini memungkinkan keterjangkauan di seluruh koneksi spoke-spoke, yang memberikan transittivitas di seluruh jaringan VPC hub.

Konfigurasi jaringan hub-and-spoke yang menggunakan Cloud VPN untuk isolasi jaringan dan konektivitas transitif.

Gambar 5. Konfigurasi jaringan hub-and-spoke yang menggunakan Cloud VPN untuk konektivitas isolasi jaringan dan transitif.

VPC Bersama

Anda dapat menggunakan VPC Bersama, untuk mempertahankan kontrol terpusat atas resource jaringan seperti subnet, rute, dan firewall di project host. Tingkat kontrol ini memungkinkan Anda menerapkan praktik terbaik keamanan dengan hak istimewa terendah untuk administrasi jaringan, audit, dan kontrol akses karena Anda dapat mendelegasikan tugas administrasi jaringan kepada administrator jaringan dan keamanan. Anda dapat menetapkan kemampuan untuk membuat dan mengelola VM kepada administrator instance menggunakan project layanan. Menggunakan project layanan memastikan bahwa administrator VM hanya diberi kemampuan untuk membuat dan mengelola instance, dan mereka tidak diizinkan untuk membuat perubahan yang berdampak pada jaringan di jaringan VPC Bersama.

Misalnya, Anda dapat menyediakan lebih banyak isolasi dengan menentukan dua jaringan VPC yang berada dalam dua project host dan dengan melampirkan beberapa project layanan ke setiap jaringan, satu untuk produksi dan satu untuk pengujian. Gambar 6 menunjukkan arsitektur yang mengisolasi lingkungan produksi dari lingkungan pengujian menggunakan project terpisah.

Untuk informasi selengkapnya tentang praktik terbaik dalam membuat jaringan VPC, baca Praktik terbaik dan arsitektur referensi untuk desain VPC.

Konfigurasi jaringan VPC bersama yang menggunakan beberapa host dan project layanan yang terisolasi (lingkungan pengujian dan produksi).

Gambar 6. Konfigurasi jaringan VPC bersama yang menggunakan beberapa host dan project layanan yang terisolasi (lingkungan pengujian dan produksi).

Arsitektur layanan hybrid

Arsitektur layanan hybrid menyediakan layanan berbasis cloud tambahan yang dirancang agar Anda dapat menghubungkan dan mengamankan layanan di lingkungan multi-VPC. Layanan berbasis cloud ini melengkapi apa yang tersedia dalam arsitektur lift-and-shift dan dapat mempermudah pengelolaan lingkungan yang disegmentasikan VPC dalam skala besar.

Private Service Connect

Private Service Connect memungkinkan layanan yang dihosting di satu jaringan VPC agar muncul di jaringan VPC lain. Tidak ada persyaratan bahwa layanan dihosting oleh resource organisasi yang sama, sehingga Private Service Connect dapat digunakan untuk menggunakan layanan secara pribadi dari jaringan VPC lain, meskipun jika terpasang ke organisasi lain resource.

Anda dapat menggunakan Private Service Connect dengan dua cara: untuk mengakses Google API atau mengakses layanan yang dihosting di jaringan VPC lain.

Gunakan Private Service Connect untuk mengakses Google API

Saat menggunakan Private Service Connect, Anda dapat menampilkan Google API menggunakan endpoint Private Service Connect yang merupakan bagian dari jaringan VPC Anda, seperti yang ditunjukkan pada gambar 7.

Konfigurasi Private Service Connect untuk mengirim traffic ke Google API menggunakan endpoint Private Service Connect yang bersifat pribadi untuk jaringan VPC Anda.

Gambar 7. Konfigurasi Private Service Connect untuk mengirim traffic ke Google API menggunakan endpoint Private Service Connect yang bersifat pribadi untuk jaringan VPC Anda.

Beban kerja dapat mengirim traffic ke paket Google API global dengan menggunakan endpoint Private Service Connect. Selain itu, Anda dapat menggunakan backend Private Service Connect untuk mengakses satu Google API, yang memperluas fitur keamanan load balancing ke layanan API. Gambar 8 menunjukkan konfigurasi ini.

Konfigurasi Private Service Connect untuk mengirim traffic ke Google API dengan menggunakan backend Private Service Connect.

Gambar 8. Konfigurasi Private Service Connect untuk mengirim traffic ke Google API dengan menggunakan backend Private Service Connect.

Menggunakan Private Service Connect antara jaringan atau entity VPC

Private Service Connect juga memungkinkan pembuat layanan menawarkan layanan ke konsumen layanan di jaringan VPC lain, baik di resource organisasi yang sama maupun di resource organisasi yang berbeda. Jaringan VPC produsen layanan dapat mendukung beberapa konsumen layanan. Konsumen dapat terhubung ke layanan produsen dengan mengirimkan traffic ke endpoint Private Service Connect yang terletak di jaringan VPC konsumen. Endpoint meneruskan traffic ke jaringan VPC yang berisi layanan yang dipublikasikan.

Konfigurasi Private Service Connect untuk memublikasikan dan menggunakan layanan terkelola melalui endpoint.

Gambar 9. Konfigurasi Private Service Connect untuk memublikasikan layanan terkelola melalui lampiran layanan dan memakai layanan melalui endpoint.

Konektor akses serverless VPC

Jaringan konektor akses tanpa server menangani traffic antara lingkungan serverless dan jaringan VPC Anda. Saat membuat konektor di project Google Cloud, Anda dapat memasangnya ke jaringan dan region VPC tertentu. Kemudian, Anda dapat mengonfigurasi layanan serverless agar dapat menggunakan konektor untuk traffic jaringan keluar. Anda can dapat menentukan konektor menggunakan subnet atau rentang CIDR. Traffic yang dikirim melalui konektor ke jaringan VPC berasal dari subnet atau rentang CIDR yang Anda tentukan, seperti yang ditunjukkan pada gambar 10.

Konfigurasi konektor akses VPC serverless untuk mengakses lingkungan serverless Google Cloud menggunakan alamat IP internal di dalam jaringan VPC Anda.

Gambar 10. Konfigurasi konektor akses VPC serverless untuk mengakses lingkungan serverless Google Cloud menggunakan alamat IP internal di dalam jaringan VPC Anda.

Konektor Akses VPC tanpa server didukung di setiap region yang mendukung Cloud Run, Cloud Functions, atau lingkungan standar App Engine. Untuk informasi selengkapnya, lihat daftar layanan yang didukung dan protokol jaringan yang didukung untuk menggunakan konektor akses VPC Serverless.

Kontrol Layanan VPC

Kontrol Layanan VPC membantu Anda mencegah pemindahan data yang tidak sah dari layanan seperti Cloud Storage atau BigQuery dengan mencegah akses yang sah dari internet atau dari project yang bukan bagian dari keamanan perimeter. Misalnya, pertimbangkan skenario saat error manusia atau otomatisasi yang salah menyebabkan kebijakan IAM salah ditetapkan di layanan seperti Cloud Storage atau BigQuery. Hasilnya, resource dalam layanan ini menjadi dapat diakses oleh publik. Dalam hal ini, ada risiko eksposur data. Jika Anda mengonfigurasi layanan ini sebagai bagian dari perimeter Kontrol Layanan VPC, akses masuk ke resource akan diblokir, meskipun jika kebijakan IAM mengizinkan akses.

Kontrol Layanan VPC dapat membuat perimeter berdasarkan atribut klien, seperti jenis identitas (akun layanan atau pengguna) dan asal jaringan (alamat IP atau jaringan VPC).

Kontrol Layanan VPC membantu mengurangi risiko keamanan berikut:

  • Akses dari jaringan tidak sah yang menggunakan kredensial yang dicuri.
  • Pemindahan data yang tidak sah oleh orang dalam yang berniat jahat atau kode yang telah disusupi.
  • Eksposur data pribadi kepada publik yang disebabkan oleh salah konfigurasi kebijakan IAM.

Gambar 11 menunjukkan bagaimana Kontrol Layanan VPC memungkinkan Anda membuat perimeter layanan untuk membantu mengurangi risiko ini.

Perimeter layanan VPC diperluas ke lingkungan hybrid dengan menggunakan layanan akses pribadi.

Gambar 11. Perimeter layanan VPC diperluas ke lingkungan hybrid dengan menggunakan layanan akses pribadi.

Dengan menggunakan aturan masuk dan keluar, Anda dapat mengaktifkan komunikasi antara dua perimeter layanan, seperti ditunjukkan pada gambar 12.

Mengonfigurasi aturan masuk dan keluar untuk berkomunikasi di antara perimeter layanan.

Gambar 12. Mengonfigurasi aturan masuk dan keluar untuk berkomunikasi di antara perimeter layanan.

Untuk rekomendasi mendetail terkait arsitektur deployment Kontrol Layanan VPC, lihat Perimeter layanan mendesain dan arsitek. Untuk mengetahui informasi selengkapnya tentang daftar layanan yang didukung oleh Kontrol Layanan VPC, lihat Produk dan batasan yang didukung.

Arsitektur Terdistribusi Zero-Trust

Kontrol keamanan perimeter jaringan diperlukan, tetapi tidak memadai untuk mendukung prinsip keamanan hak istimewa dan pertahanan terendah secara mendalam. Zero Trust Distributed Architectures dibuat berdasarkan, tetapi tidak hanya mengandalkan, tepi perimeter jaringan untuk penerapan keamanan. Sebagai arsitektur terdistribusi, arsitektur tersebut terdiri dari microservice dengan penerapan kebijakan keamanan per layanan, autentikasi yang kuat, dan workload identity.

Anda dapat mengimplementasikan Zero Trust Distributed Architectures sebagai layanan yang dikelola oleh Traffic Director dan Anthos Service Mesh.

Traffic Director

Traffic Director dapat dikonfigurasi untuk menyediakan mesh microservice Arsitektur Terdistribusi Zero Trust Distributed di dalam cluster GKE menggunakan keamanan layanan. Dalam model ini, pada layanan GKE yang memiliki file bantuan Envoy atau gRPC tanpa proxy, identitas, sertifikat, dan kebijakan otorisasi semuanya dikelola oleh semua hal berikut: Traffic Director, workload identity, Certificate Authority Service, dan IAM. Pengelolaan sertifikat dan penamaan aman disediakan oleh platform, dan semua komunikasi layanan tunduk pada keamanan transportasi mTLS. Gambar 13 menunjukkan cluster dengan konfigurasi ini.

Mesh Arsitektur Zero Trust Distributed Architecture cluster tunggal yang menggunakan Traffic Director.

Gamabar 13. Mesh Arsitektur Zero Trust Distributed Architecture cluster tunggal yang menggunakan Traffic Director.

Kebijakan otorisasi menentukan cara server mengizinkan permintaan masuk atau RPC. Kebijakan otorisasi dapat dikonfigurasi untuk mengizinkan atau menolak permintaan masuk atau RPC berdasarkan berbagai parameter, seperti identitas klien yang mengirim permintaan, host, header, dan atribut HTTP lainnya. Panduan penerapan tersedia untuk mengonfigurasi kebijakan otorisasi pada mesh berdasarkan gRPC dan Envoy.

Pada Gambar 13, arsitektur memiliki satu cluster dan jaringan datar (ruang alamat IP bersama). Beberapa cluster biasanya digunakan dalam Arsitektur Terdistribusi Zero Trust untuk isolasi, lokasi, dan skala.

Dalam lingkungan yang lebih kompleks, beberapa cluster dapat berbagi identitas terkelola saat cluster dikelompokkan berdasarkan fleet. Dalam hal ini, Anda dapat mengonfigurasi konektivitas jaringan di seluruh jaringan VPC independen menggunakan Private Service Connect. Pendekatan ini mirip dengan pendekatan konektivitas jaringan multi-cluster akses hybrid workload seperti yang akan dijelaskan nanti dalam dokumen ini.

Untuk informasi tentang kontrol terperinci cara penanganan traffic dengan Traffic Director, lihat Ringkasan pengelolaan traffic lanjutan.

Anthos Service Mesh

Anthos Service Mesh menyediakan mesh microservice mTLS Zero Trust Distributed Architecture siap pakai yang dibangun di atas fondasi Istio singkat ini. Anda menyiapkan mesh menggunakan flow terintegrasi. Anthos Service Mesh Terkelola, dengan data yang dikelola Google dan perangkat kontrol, didukung di GKE. Bidang kontrol dalam cluster juga tersedia, yang cocok untuk lingkungan lain seperti Google Distributed Cloud Virtualises atau GKE Multi-Cloud. Anthos Service Mesh mengelola identitas dan sertifikat untuk Anda, dengan menyediakan model kebijakan otorisasi berbasis Istio.

Anthos Service Mesh mengandalkan fleet untuk mengelola identitas dan konfigurasi deployment multi-cluster service Seperti halnya Traffic Director, saat workload Anda beroperasi di lingkungan konektivitas jaringan VPC yang datar (atau bersama), tidak ada persyaratan konektivitas jaringan khusus di luar konfigurasi firewall. Jika arsitektur Anda mencakup beberapa cluster Anthos Service Mesh di seluruh jaringan VPC atau lingkungan jaringan yang terpisah, misalnya di seluruh koneksi Cloud Interconnect Anda juga memerlukan gateway timur-barat. Praktik terbaik untuk jaringan Anthos Service Mesh sama dengan praktik yang dijelaskan dalam Praktik terbaik untuk jaringan GKE.

Anthos Service Mesh juga terintegrasi dengan Identity-Aware Proxy (IAP). Dengan IAP, Anda dapat menetapkan kebijakan akses yang terperinci sehingga Anda dapat mengontrol akses pengguna ke workload berdasarkan atribut permintaan asal, seperti identitas pengguna, alamat IP , dan jenis perangkat. Tingkat kontrol ini memungkinkan lingkungan zero-trust menyeluruh.

Anda perlu mempertimbangkan persyaratan cluster GKE saat menggunakan Anthos Service Mesh. Untuk informasi lebih lanjut, lihat Persyaratan dalam dokumentasi "Penginstalan project tunggal di GKE".

Langkah selanjutnya