Mendesain dan merancang perimeter layanan

Dokumen ini menjelaskan arsitektur deployment Kontrol Layanan VPC yang direkomendasikan. Dokumen ini ditujukan bagi administrator jaringan, arsitek keamanan, dan profesional operasi cloud yang menjalankan dan mengoperasikan deployment skala produksi yang besar di Google Cloud serta 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 mendesain arsitektur. Penting untuk mempertahankan desain Kontrol Layanan VPC sesederhana mungkin. Sebaiknya hindari desain perimeter yang menggunakan banyak perantara, project jaringan perimeter, atau perimeter DMZ, dan tingkat akses yang rumit.

Menggunakan perimeter terpadu umum

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

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

Saat organisasi menggunakan banyak perimeter yang lebih kecil, tim pengelolaan perimeter harus mengalokasikan resource untuk mengelola traffic timur-barat antar-perimeter organisasi selain traffic utara-selatan dari luar organisasi. Tergantung pada ukuran organisasi dan jumlah perimeter, overhead ini bisa cukup besar. Sebaiknya Anda melapisi perimeter Anda dengan kontrol keamanan tambahan dan praktik terbaik, seperti memastikan bahwa resource dalam Jaringan VPC tidak memiliki traffic egress 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 banyak perimeter dalam satu organisasi

Kasus penggunaan tertentu mungkin memerlukan banyak perimeter untuk organisasi. Misalnya, organisasi yang menangani data layanan kesehatan mungkin menginginkan satu perimeter untuk data yang tidak di-obfuscate dan sangat tepercaya, serta perimeter terpisah untuk data yang dide-identifikasi dan berada di tingkat yang lebih rendah untuk memfasilitasi berbagi dengan entitas eksternal sambil tetap melindungi data yang sangat tepercaya.

Jika organisasi Anda ingin mematuhi standar seperti PCI DSS, Anda mungkin ingin 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 membuat dan membagikan data tingkat lebih rendah seperti data kesehatan pasien yang dide-identifikasi, Anda dapat menggunakan perimeter terpisah untuk memfasilitasi berbagi dengan entitas luar. Untuk mengetahui informasi selengkapnya, lihat pola referensi untuk pertukaran data yang aman.

Selain itu, jika Anda menggunakan organisasi Google Cloud Anda untuk menghosting tenant pihak ketiga yang independen, seperti partner atau pelanggan, pertimbangkan untuk menentukan perimeter untuk setiap tenant. Jika Anda menganggap pemindahan data dari salah satu tenant ini ke tenant lainnya sebagai pemindahan data yang tidak sah, 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 pemindahan data yang tidak sah. Karena membiarkan API tidak terlindungi akan meningkatkan kemungkinan vektor pemindahan data yang tidak sah, harus ada peninjauan dan justifikasi jika organisasi Anda memilih untuk melindungi satu API dan tidak melindungi API lainnya.

Semua proyek baru harus melalui proses peninjauan dan kualifikasi yang dijelaskan di bagian berikut. Sertakan semua project yang memenuhi ketentuan kualifikasi ke dalam perimeter.

Pastikan tidak ada jalur ke VIP pribadi dari VPC mana pun di perimeter. Jika mengizinkan rute jaringan ke private.googleapis.com, Anda meniadakan perlindungan Kontrol Layanan VPC dari pemindahan data yang tidak sah oleh orang dalam. Jika Anda harus mengizinkan akses ke layanan yang tidak didukung, coba pisahkan penggunaan layanan yang tidak didukung ke project terpisah, atau pindahkan seluruh workload ke luar perimeter.

Meninjau dan menentukan kelayakan project

Perusahaan pada umumnya memiliki banyak project yang merepresentasikan workload dan konstruksi tingkat tinggi seperti bidang kontrol, data lake, unit bisnis, dan tahap siklus proses. Selain menyusun project dan komponen ini ke dalam folder, sebaiknya Anda menentukan apakah 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 kuat pada layanan yang tidak didukung oleh Kontrol Layanan VPC?

    Penerapan Kontrol Layanan VPC tidak ambigu, sehingga jenis dependensi ini mungkin tidak berfungsi dalam perimeter. Sebaiknya Anda mengubah workload untuk memisahkan persyaratan layanan yang tidak didukung ke project terpisah, atau memindahkan workload keluar dari perimeter sama sekali.

  • 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 berikutnya