Menerima akses jauh VPC memerlukan ujian penolakan

Penerimaan akses jauh ialah jadual hasil yang dijangka, bukan tangkapan skrin halaman yang berfungsi. Bagi setiap kumpulan, tulis apa yang sepatutnya berjaya dan apa yang sepatutnya gagal, kemudian jalankan kedua-duanya dengan identiti ujian khusus dalam tetingkap terkawal. Penolakan ialah bahagian yang membuktikan sempadan; log masuk yang berjaya hanya membuktikan terowong itu wujud. Semua ini berfungsi dengan produk VPN yang telah dipilih.

Gunakan akaun berasingan untuk ujian dan labelkannya supaya tiada siapa menyangka identiti ujian sebagai pengecualian sebenar.

Tulis sempadan sebagai hasil yang dijangka

Mulakan dengan peranan dan bukan komponen: siapa memerlukan perkhidmatan apa, dari mana, dan dengan identiti apa. Ambil VPC contoh: satu kumpulan memerlukan persekitaran ujian melalui HTTPS, satu lagi memerlukan pangkalan data pengeluaran, dan kumpulan ketiga yang lebih kecil mentadbir gateway itu sendiri. Setiap baris mendapat kebenaran yang dijangka dan penolakan yang dijangka, termasuk perkhidmatan jiran dan akaun jiran yang tidak sepatutnya berfungsi. Jadual itulah kriteria penerimaan, dan orang yang tidak menjalankan ujian boleh menyemaknya.

Uji log masuk pangkalan data secara berasingan daripada laluan rangkaian. Port TCP yang boleh dicapai tidak sepatutnya menjadikan akaun pangkalan data yang tidak diluluskan berjaya, dan keahlian VPN tidak sepatutnya mencipta peranan IAM awan atau memberikan akses API pentadbiran. Itu tiga kawalan bebas, dan ketiga-tiganya gagal secara bebas.

Laluan bukan kebenaran

Laluan menjadikan sesuatu laluan mungkin; ia tidak memberikan kebenaran. Menahan laluan ialah pengganti lemah bagi sekatan yang dikuatkuasakan di destinasi, kerana klien sentiasa boleh menambah laluannya sendiri. Kumpulan keselamatan, pemberian pangkalan data dan kebenaran aplikasi itu sendiri kekal sebagai kawalan yang menentukan. Apabila ujian berjaya secara tidak dijangka, lihat dahulu dasar destinasi dan bukan jadual penghalaan yang anda maksudkan untuk klien.

Itulah sebabnya ujian penolakan menyasarkan bahagian pelayan: hasil itu tidak boleh diubah dengan menyunting klien.

Sumber mana yang sebenarnya dilihat oleh kawalan?

Alamat sumber yang dinilai oleh kawalan bergantung pada seni bina gateway. Gateway yang dihoskan di EC2 boleh menyalurkan kolam berpenghalaan, menterjemahkannya ke alamatnya sendiri atau memaparkan alamat berbeza selepas NAT; Client VPN terurus bergabung dengan subnet dan mengikut modelnya sendiri. Kumpulan keselamatan dan ACL rangkaian melihat apa sahaja yang tiba selepas pemprosesan itu. Memeriksa peraturan dengan andaian sumber yang salah ialah cara biasa membina sempadan yang kelihatan betul dan menerima trafik yang salah.

Kaitkan setiap hasil dengan peristiwa paling kecil yang berguna: identiti dan sesi, sumber, operasi, masa dan keputusan. Panggilan API CloudTrail, rekod aliran VPC dan log sesi VPN menjawab soalan berbeza, dan tiada satu pun daripadanya sahaja merupakan audit aplikasi.

Tarik balik identiti dan uji semula

Sertakan penarikan balik dalam jadual yang sama. Buang identiti ujian, sahkan bahawa sesi baharu ditolak, kemudian sahkan secara berasingan bagaimana sesi sedia ada diuruskan, kerana itu tingkah laku berbeza dengan pemilik berbeza. Periksa apa yang berlaku selepas gateway dimulakan semula atau diganti, supaya pengecualian yang ditambah dengan tangan tidak hilang secara senyap atau kembali lebih luas. Sempadan yang hanya bertahan sehingga penggunaan seterusnya bukan sempadan.

Tiada satu pun daripada ini menggantikan kerja tampalan, pemulihan atau kitaran hayat kelayakan. Ia menjadikan janji yang lebih sempit boleh diukur: orang yang betul mencapai perkhidmatan yang betul, sementara laluan, akaun dan permukaan pengurusan berdekatan kekal di luar pemberian.

Simpan jadual bersama penggunaan dan jalankan semula apabila gateway berubah. Ujian itu murah; andaian di belakangnya tidak.