Menerima akses jarak jauh VPC memerlukan uji penolakan

Penerimaan akses jarak jauh adalah tabel hasil yang diharapkan, bukan tangkapan layar halaman yang berfungsi. Untuk setiap grup, tuliskan apa yang seharusnya berhasil dan apa yang seharusnya gagal, lalu jalankan keduanya dengan identitas uji khusus dalam jendela terkendali. Penolakan adalah bagian yang membuktikan batas; login yang berhasil hanya membuktikan bahwa terowongan itu ada. Semua ini bekerja dengan produk VPN yang sudah dipilih.

Gunakan akun terpisah untuk pengujian, dan beri label agar tidak ada yang mengira identitas uji sebagai pengecualian nyata.

Tuliskan batas sebagai hasil yang diharapkan

Mulailah dari peran, bukan dari komponen: siapa membutuhkan layanan apa, dari mana, dan dengan identitas apa. Ambil VPC ilustratif: satu grup membutuhkan lingkungan uji melalui HTTPS, grup lain membutuhkan basis data produksi, dan grup ketiga yang lebih kecil mengelola gateway itu sendiri. Setiap baris mendapat izin yang diharapkan dan penolakan yang diharapkan, termasuk layanan tetangga dan akun tetangga yang seharusnya tidak berfungsi. Tabel itulah kriteria penerimaan, dan orang yang tidak menjalankan pengujian dapat meninjaunya.

Uji login basis data secara terpisah dari jalur jaringan. Port TCP yang dapat dijangkau tidak boleh membuat akun basis data yang tidak disetujui berhasil, dan keanggotaan VPN tidak boleh membuat peran IAM cloud atau memberikan akses API administratif. Itu tiga kontrol independen, dan ketiganya gagal secara independen.

Rute bukan otorisasi

Rute membuat jalur menjadi mungkin; rute tidak memberikan izin. Menahan rute adalah pengganti lemah bagi pembatasan yang ditegakkan di tujuan, karena klien selalu dapat menambahkan rutenya sendiri. Grup keamanan, pemberian basis data, dan otorisasi aplikasi itu sendiri tetap menjadi kontrol yang menentukan. Ketika sebuah uji berhasil secara tak terduga, lihat dulu kebijakan tujuan, bukan tabel perutean yang Anda maksudkan untuk klien.

Itulah sebabnya uji penolakan menyasar sisi server: hasil itu tidak dapat diubah dengan menyunting klien.

Sumber mana yang sebenarnya dilihat kontrol?

Alamat sumber yang dievaluasi kontrol bergantung pada arsitektur gateway. Gateway yang dihosting di EC2 dapat meneruskan kumpulan yang dirutekan, menerjemahkannya ke alamatnya sendiri, atau menampilkan alamat berbeda setelah NAT; Client VPN terkelola terhubung ke subnet dan mengikuti modelnya sendiri. Grup keamanan dan ACL jaringan melihat apa pun yang tiba setelah pemrosesan itu. Memeriksa aturan dengan asumsi sumber yang salah adalah cara umum membangun batas yang tampak benar dan meloloskan lalu lintas yang salah.

Korelasikan setiap hasil dengan peristiwa terkecil yang berguna: identitas dan sesi, sumber daya, operasi, waktu, dan keputusan. Panggilan API CloudTrail, catatan aliran VPC, dan log sesi VPN menjawab pertanyaan berbeda, dan tidak satu pun sendirian merupakan audit aplikasi.

Cabut identitas dan uji lagi

Sertakan pencabutan dalam tabel yang sama. Hapus identitas uji, pastikan sesi baru ditolak, lalu pastikan secara terpisah bagaimana sesi yang ada diperlakukan, karena itu perilaku berbeda dengan pemilik berbeda. Periksa apa yang terjadi setelah gateway dimulai ulang atau diganti, agar pengecualian yang ditambahkan dengan tangan tidak hilang diam-diam atau kembali lebih luas. Batas yang hanya bertahan sampai penerapan berikutnya bukanlah batas.

Tidak satu pun dari ini menggantikan pekerjaan penambalan, pemulihan, atau siklus hidup kredensial. Ini membuat janji yang lebih sempit dapat diukur: orang yang tepat mencapai layanan yang tepat, sementara rute, akun, dan permukaan manajemen di sekitarnya tetap di luar pemberian.

Simpan tabel bersama penerapan dan jalankan lagi saat gateway berubah. Pengujiannya murah; asumsi di baliknya tidak.