Mendesain dan merancang perimeter layanan

Dokumen ini menjelaskan arsitektur deployment Kontrol Layanan VPC yang direkomendasikan. Dokumen ini ditujukan untuk administrator jaringan, arsitek keamanan, dan tenaga profesional operasi cloud yang menjalankan dan mengoperasikan deployment skala produksi besar di Google Cloud dan ingin mengurangi risiko kehilangan data sensitif.

Karena perlindungan Kontrol Layanan VPC memengaruhi fungsi layanan cloud, sebaiknya Anda merencanakan pengaktifan Kontrol Layanan VPC terlebih dahulu, dan mempertimbangkan Kontrol Layanan VPC selama desain arsitektur. Penting untuk menjaga desain Kontrol Layanan VPC sesederhana mungkin. Sebaiknya hindari desain perimeter yang menggunakan beberapa jembatan, project jaringan perimeter, atau perimeter DMZ, dan tingkat akses yang kompleks.

Menggunakan perimeter terpadu umum

Satu perimeter besar, yang disebut sebagai perimeter terpadu umum, memberikan perlindungan paling efektif terhadap pemindahan data yang tidak sah dibandingkan dengan menggunakan beberapa perimeter yang tersegmentasi.

Perimeter terpadu yang umum juga memberikan manfaat overhead pengelolaan yang lebih rendah bagi tim yang bertanggung jawab atas pembuatan dan pemeliharaan perimeter. Karena layanan dan resource jaringan dalam perimeter dapat berkomunikasi dengan bebas dengan izin kontrol jaringan dan IAM yang diperlukan, tim yang bertanggung jawab atas pengelolaan perimeter akan terutama memperhatikan akses utara-selatan, yaitu akses dari internet ke resource di dalam perimeter.

Jika organisasi menggunakan beberapa perimeter yang lebih kecil, tim pengelolaan perimeter harus mencurahkan resource untuk mengelola traffic east-west di antara perimeter organisasi selain traffic north-south dari luar organisasi. Bergantung pada ukuran organisasi dan jumlah perimeter, overhead ini dapat cukup besar. Sebaiknya Anda membuat beberapa lapisan perimeter dengan kontrol keamanan tambahan dan praktik terbaik, seperti memastikan bahwa resource dalam jaringan VPC tidak memiliki traffic keluar internet langsung.

Perimeter layanan tidak dimaksudkan untuk menggantikan atau mengurangi kebutuhan akan kontrol IAM. Saat menentukan kontrol akses, sebaiknya pastikan prinsip hak istimewa terendah diikuti dan praktik terbaik IAM diterapkan.

Untuk mengetahui informasi selengkapnya, lihat Membuat perimeter layanan.

Menggunakan beberapa perimeter dalam satu organisasi

Kasus penggunaan tertentu mungkin memerlukan beberapa perimeter untuk organisasi. Misalnya, organisasi yang menangani data layanan kesehatan mungkin menginginkan satu perimeter untuk data tepercaya tinggi yang tidak di-obfuscate dan perimeter terpisah untuk data tingkat rendah yang dide-identifikasi untuk memfasilitasi berbagi dengan entitas eksternal sekaligus melindungi data tepercaya tinggi.

Jika organisasi Anda ingin mematuhi standar seperti PCI DSS, sebaiknya Anda memiliki perimeter terpisah di sekitar data yang diatur.

Jika berbagi data adalah kasus penggunaan utama untuk organisasi Anda, pertimbangkan untuk menggunakan lebih dari satu perimeter. Jika Anda membuat dan membagikan data tingkat rendah seperti data kesehatan pasien yang dide-identifikasi, Anda dapat menggunakan perimeter terpisah untuk memfasilitasi berbagi dengan entitas luar. Untuk informasi selengkapnya, lihat pola referensi untuk pertukaran data aman.

Selain itu, jika Anda menggunakan organisasi Google Cloud untuk menghosting tenant pihak ketiga independen seperti partner atau pelanggan, sebaiknya tentukan perimeter untuk setiap tenant. Jika Anda menganggap pergerakan data dari salah satu tenant ini ke tenant lainnya sebagai eksfiltrasi, sebaiknya terapkan perimeter terpisah.

Desain perimeter

Sebaiknya aktifkan semua layanan yang dilindungi saat Anda membuat perimeter, yang membantu mengurangi kompleksitas operasional dan meminimalkan potensi vektor eksfiltrasi. Karena membiarkan API tidak dilindungi akan meningkatkan kemungkinan vektor eksfiltrasi, harus ada peninjauan dan justifikasi jika organisasi Anda memilih untuk melindungi satu API dan tidak melindungi API lainnya.

Semua project baru harus melalui proses peninjauan dan kualifikasi yang dijelaskan di bagian berikut. Sertakan dalam perimeter semua project yang lulus kondisi kualifikasi.

Pastikan tidak ada jalur ke VIP pribadi dari VPC mana pun di perimeter. Jika mengizinkan rute jaringan ke private.googleapis.com, Anda akan membatalkan perlindungan Kontrol Layanan VPC dari pemindahan data oleh pihak internal. Jika Anda harus mengizinkan akses ke layanan yang tidak didukung, coba isolasi penggunaan layanan yang tidak didukung ke project terpisah, atau pindahkan seluruh beban kerja ke luar perimeter.

Meninjau dan menentukan kelayakan project

Perusahaan umum memiliki banyak project yang mewakili workload dan konstruksi tingkat tinggi seperti bidang kontrol, data lake, unit bisnis, dan tahap siklus proses. Selain mengatur project dan komponen ini ke dalam folder, sebaiknya Anda memenuhi syarat agar project dan komponen tersebut berada di dalam atau di luar perimeter Kontrol Layanan VPC. Untuk membuat kualifikasi, pertimbangkan pertanyaan berikut:

  • Apakah ada komponen yang memiliki dependensi keras pada layanan yang tidak didukung Kontrol Layanan VPC?

    Penerapan Kontrol Layanan VPC tidak ambigu, sehingga jenis dependensi ini mungkin tidak berfungsi dalam perimeter. Sebaiknya ubah workload untuk mengisolasi persyaratan layanan yang tidak didukung ke dalam project terpisah, atau pindahkan workload sepenuhnya dari perimeter.

  • Apakah ada komponen yang tidak memiliki data sensitif dan tidak menggunakan data sensitif dari project lain?

Jika Anda menjawab ya untuk salah satu pertanyaan sebelumnya, sebaiknya Anda tidak memasukkan project ke dalam perimeter. Anda dapat mengatasi masalah ini, seperti yang dibahas dalam topik Desain daftar yang diizinkan. Namun, sebaiknya Anda meminimalkan kompleksitas perimeter.

Langkah selanjutnya