Mode uji coba untuk perimeter layanan

Saat menggunakan Kontrol Layanan VPC, mungkin sulit untuk menentukan dampak pada lingkungan Anda saat perimeter layanan dibuat atau diubah. Dengan mode uji coba, Anda dapat lebih memahami efek pengaktifan Kontrol Layanan VPC dan perubahan pada perimeter di lingkungan yang ada.

Dalam mode uji coba, permintaan yang melanggar kebijakan perimeter tidak ditolak, hanya dicatat. Anda dapat menggunakan mode uji coba untuk menguji konfigurasi perimeter dan memantau penggunaan layanan tanpa mencegah akses ke resource. Kasus penggunaan umum mencakup:

  • Menentukan dampak perubahan pada perimeter layanan yang ada.

  • Melihat pratinjau dampak yang akan ditimbulkan oleh perimeter layanan baru.

  • Memantau permintaan ke layanan yang dilindungi yang berasal dari luar perimeter layanan. Misalnya, melihat dari mana permintaan ke layanan tertentu berasal, atau mengidentifikasi penggunaan layanan yang tidak terduga di organisasi Anda.

  • Di lingkungan pengembangan Anda, buat arsitektur perimeter yang serupa dengan lingkungan produksi Anda. Dengan begitu, Anda dapat mengidentifikasi dan mengurangi masalah apa pun yang akan disebabkan oleh perimeter layanan sebelum mendorong perubahan ke lingkungan produksi.

Perimeter layanan dapat ada menggunakan mode uji coba secara eksklusif. Anda juga dapat memiliki perimeter layanan yang menggunakan mode gabungan yang diterapkan dan uji coba.

Manfaat mode uji coba

Dengan menggunakan mode uji coba, Anda dapat membuat perimeter layanan baru atau mengubah beberapa perimeter yang ada tanpa memengaruhi lingkungan yang ada. Permintaan yang melanggar konfigurasi perimeter baru tidak diblokir. Anda juga dapat memahami dampak perimeter di lingkungan yang tidak semua layanan yang digunakan terintegrasi dengan Kontrol Layanan VPC.

Anda dapat menganalisis log Kontrol Layanan VPC untuk penolakan, mengubah konfigurasi untuk memperbaiki potensi masalah, lalu menerapkan postur keamanan baru.

Jika masalah konfigurasi perimeter tidak dapat diselesaikan, Anda dapat memilih untuk mempertahankan konfigurasi uji coba perimeter dan memantau log untuk melihat penolakan yang tidak terduga yang mungkin mengindikasikan upaya pencurian data. Namun, permintaan ke perimeter tidak ditolak.

Konsep mode uji coba

Mode uji coba beroperasi sebagai evaluasi kedua dari konfigurasi perimeter. Secara default, konfigurasi mode yang diterapkan untuk semua perimeter layanan diwariskan ke dalam konfigurasi mode uji coba, tempat konfigurasi dapat diubah atau dihapus tanpa memengaruhi operasi perimeter layanan.

Karena mode uji coba mewarisi konfigurasi mode yang diterapkan, pada setiap langkah, kedua konfigurasi harus valid. Secara khusus, project hanya dapat berada di satu perimeter dalam konfigurasi yang diterapkan dan satu perimeter dalam konfigurasi uji coba. Akibatnya, perubahan yang mencakup beberapa perimeter, seperti memindahkan project antar-perimeter, harus diurutkan dengan benar.

Mode uji coba hanya mencatat permintaan jika memenuhi kedua kriteria berikut:

  • Permintaan belum ditolak oleh konfigurasi yang diterapkan perimeter.

  • Permintaan melanggar konfigurasi uji coba perimeter.

Misalnya, jika konfigurasi uji coba dan mode penerapan yang identik membatasi bucket Cloud Storage, mode penerapan akan memblokir dan mencatat setiap permintaan ke bucket Cloud Storage. Mode uji coba hanya mencatat perbedaan pelanggaran dibandingkan dengan mode yang diterapkan.

Dalam log audit pemeriksaan kebijakan mode uji coba, nilai kolom metadata.dryRun dalam log audit ditetapkan ke True. Untuk mengetahui informasi selengkapnya, lihat Konten rekaman log audit.

Anda juga dapat membuat perimeter yang hanya memiliki konfigurasi uji coba. Hal ini memungkinkan Anda menyimulasikan dampak perimeter baru yang diterapkan di lingkungan Anda.

Untuk mengevaluasi konfigurasi uji coba perimeter layanan, tetapkan kolom useExplicitDryRunSpec dalam konfigurasi perimeter layanan ke True. Untuk mengetahui informasi selengkapnya, lihat accessPolicies.servicePerimeters.

Semantik kebijakan

Bagian berikut menjelaskan hubungan kebijakan antara mode wajib dan uji coba, serta urutan penyelesaian penegakan.

Batasan keanggotaan unik

Project Google Cloud hanya dapat disertakan dalam satu konfigurasi yang diterapkan dan satu konfigurasi uji coba. Namun, konfigurasi yang diterapkan dan uji coba tidak harus untuk perimeter yang sama. Tindakan ini memungkinkan Anda menguji dampak pemindahan project dari satu perimeter ke perimeter lain tanpa mengorbankan keamanan yang saat ini diterapkan pada project.

Contoh

Project corp-storage saat ini dilindungi oleh konfigurasi yang diterapkan di perimeter PA. Anda ingin menguji dampak pemindahan corp-storage ke perimeter PB.

Konfigurasi uji coba untuk PA belum diubah. Karena konfigurasi uji coba tidak diubah, konfigurasi tersebut mewarisi corp-storage dari konfigurasi yang diterapkan.

Untuk menguji dampaknya, Anda harus menghapus corp-storage dari konfigurasi uji coba untuk PA terlebih dahulu, lalu menambahkan project ke konfigurasi uji coba untuk PB. Anda harus menghapus corp-storage dari konfigurasi uji coba untuk PA terlebih dahulu karena project hanya dapat ada dalam satu konfigurasi uji coba dalam satu waktu.

Setelah Anda yakin bahwa memigrasikan corp-storage dari PA ke PB tidak akan berdampak buruk pada postur keamanan Anda, Anda memutuskan untuk menerapkan perubahan tersebut.

Ada dua cara untuk menerapkan perubahan pada perimeter PA dan PB:

  • Anda dapat menghapus secara manual corp-storage dari konfigurasi yang diterapkan untuk PA dan menambahkan project ke konfigurasi yang diterapkan untuk PB. Karena corp-storage hanya dapat berada dalam satu konfigurasi yang diterapkan dalam satu waktu, Anda harus melakukan langkah-langkah dalam urutan ini.

    -atau-

  • Anda dapat menggunakan alat command line gcloud atau Access Context Manager API untuk menerapkan semua konfigurasi uji coba. Operasi ini berlaku untuk semua konfigurasi uji coba yang diubah untuk perimeter Anda, jadi Anda harus mengoordinasikan operasi ini dengan orang lain di organisasi Anda yang telah mengubah konfigurasi uji coba untuk perimeter Anda. Karena konfigurasi uji coba untuk PA sudah mengecualikan corp-storage, tidak ada langkah tambahan yang diperlukan.

Konfigurasi perimeter yang diterapkan akan dieksekusi terlebih dahulu

Hanya permintaan yang diizinkan oleh konfigurasi perimeter yang diterapkan tetapi ditolak oleh konfigurasi uji coba yang dicatat sebagai pelanggaran kebijakan uji coba. Permintaan yang ditolak oleh konfigurasi yang diterapkan, tetapi akan diizinkan oleh konfigurasi uji coba tidak dicatat.

Tingkat akses tidak memiliki mode uji coba yang setara

Meskipun Anda dapat membuat konfigurasi uji coba untuk perimeter, tingkat akses tidak memiliki konfigurasi uji coba. Dalam praktiknya, ini berarti jika Anda ingin menguji pengaruh perubahan pada tingkat akses terhadap konfigurasi uji coba, Anda harus:

  1. Buat tingkat akses yang mencerminkan perubahan yang ingin Anda lakukan pada tingkat akses yang ada.

  2. Terapkan tingkat akses baru ke konfigurasi uji coba untuk perimeter.

Mode uji coba tidak berdampak negatif pada keamanan

Perubahan pada konfigurasi uji coba untuk perimeter, seperti menambahkan project atau level akses baru ke perimeter, atau mengubah layanan yang dilindungi atau dapat diakses oleh jaringan di dalam perimeter, tidak berdampak pada penegakan perimeter yang sebenarnya.

Misalnya, asumsikan Anda memiliki project yang termasuk dalam perimeter layanan PA. Jika project ditambahkan ke konfigurasi uji coba perimeter lain, keamanan aktual yang diterapkan ke project tidak akan berubah. Proyek terus dilindungi oleh konfigurasi PA perimeter yang diterapkan, seperti yang diharapkan.

Status tindakan dan konfigurasi uji coba

Dengan fitur uji coba, Anda dapat:

  • Membuat perimeter hanya dengan konfigurasi uji coba

  • Memperbarui konfigurasi uji coba perimeter yang ada

  • Memindahkan project baru ke perimeter yang ada

  • Memindahkan project dari satu perimeter ke perimeter lain

  • Menghapus konfigurasi uji coba perimeter

Berdasarkan tindakan yang dilakukan dalam mode uji coba, perimeter dapat berada dalam salah satu status konfigurasi berikut:

Diwariskan dari yang diterapkan: Status default untuk perimeter yang diterapkan. Dalam status ini, setiap perubahan pada konfigurasi yang diterapkan di perimeter juga diterapkan ke konfigurasi uji coba.

Diubah: Konfigurasi uji coba untuk perimeter telah dilihat atau diubah, lalu disimpan. Dalam status ini, perubahan pada konfigurasi yang diterapkan perimeter tidak diterapkan pada konfigurasi uji coba.

Baru: Perimeter hanya memiliki konfigurasi uji coba. Meskipun perubahan dilakukan pada konfigurasi uji coba, hingga perimeter ini memiliki konfigurasi yang diterapkan, statusnya tetap Baru.

Dihapus: Konfigurasi uji coba untuk perimeter telah dihapus. Status ini tetap ada hingga Anda membuat konfigurasi uji coba baru untuk perimeter atau mengurungkan tindakan. Dalam status ini, perubahan pada konfigurasi yang diterapkan perimeter tidak diterapkan pada konfigurasi uji coba.

Batasan mode uji coba

Mode uji coba hanya berlaku untuk perimeter. Hal ini tidak membantu memahami dampak pembatasan akses API Google Cloud ke VIP pribadi atau terbatas. Sebaiknya pastikan semua layanan yang ingin Anda gunakan tersedia di VIP yang dibatasi sebelum Anda mengonfigurasi domain restricted.googleapis.com.

Jika Anda tidak yakin apakah API yang Anda gunakan di lingkungan yang ada didukung oleh VIP yang dibatasi, sebaiknya gunakan VIP pribadi. Anda tetap dapat menerapkan keamanan perimeter untuk layanan yang didukung. Namun, jika Anda menggunakan VIP pribadi, entitas dalam jaringan Anda akan memiliki akses ke layanan yang tidak aman (layanan yang tidak didukung oleh Kontrol Layanan VPC), seperti Gmail dan Drive versi konsumen. Karena VIP pribadi memungkinkan layanan yang tidak didukung oleh Kontrol Layanan VPC, kode yang disusupi, malware, atau pengguna berbahaya dalam jaringan Anda dapat mengirim data secara tidak sah menggunakan layanan yang tidak aman tersebut.

Apa langkah selanjutnya?