Perimeter layanan desain dan arsitek

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

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

Menggunakan perimeter terpadu yang sama

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

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

Saat organisasi menggunakan beberapa perimeter yang lebih kecil, tim pengelolaan perimeter harus menyediakan resource untuk mengelola traffic timur-barat antarperimeter organisasi selain traffic utara-selatan dari luar organisasi. Bergantung pada ukuran organisasi dan jumlah perimeter, overhead ini dapat cukup besar. Sebaiknya Anda melapisi perimeter Anda dengan kontrol keamanan dan praktik terbaik tambahan, seperti memastikan bahwa resource dalam jaringan VPC tidak memiliki traffic keluar internet langsung.

Perimeter layanan tidak dimaksudkan untuk menggantikan atau mengurangi kebutuhan kontrol IAM. Saat menentukan kontrol akses, sebaiknya Anda memastikan bahwa prinsip hak istimewa terendah dipatuhi 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 yang tepercaya dan tidak di-obfuscate, dan perimeter terpisah untuk data dengan tingkat yang lebih rendah dan dide-identifikasi guna memfasilitasi berbagi dengan entity eksternal sambil tetap melindungi data dengan tingkat kepercayaan tinggi.

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

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

Selain itu, jika Anda menggunakan organisasi Google Cloud untuk menghosting tenant pihak ketiga yang independen, seperti partner atau pelanggan, sebaiknya tentukan 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 membuat perimeter, yang membantu mengurangi kompleksitas operasional dan meminimalkan potensi vektor pemindahan yang tidak sah. Karena membiarkan API tidak dilindungi akan meningkatkan kemungkinan vektor pemindahan yang tidak sah, harus ada peninjauan dan justifikasi jika organisasi Anda memilih untuk melindungi satu API dan bukan yang lain.

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

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

Meninjau dan memenuhi syarat proyek

Sebuah 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 mengatur project dan komponen ini ke dalam folder, sebaiknya Anda memenuhi syarat untuk berada di dalam atau di luar perimeter Kontrol Layanan VPC. Untuk membuat kualifikasi, pertimbangkan pertanyaan-pertanyaan berikut:

  • Apakah ada komponen yang memiliki dependensi kuat 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 beban kerja untuk mengisolasi persyaratan untuk layanan yang tidak didukung ke dalam project terpisah, atau pindahkan beban kerja sepenuhnya keluar dari perimeter.

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

Jika Anda menjawab ya untuk salah satu pertanyaan sebelumnya, sebaiknya jangan menempatkan project ke dalam perimeter. Anda dapat mengatasi hal ini, seperti yang dibahas dalam topik Desain daftar yang diizinkan. Namun, sebaiknya minimalkan kompleksitas perimeter.

Langkah selanjutnya