Beri Pengguna VPN Akses kepada Satu Perkhidmatan, Bukan Subnet

Seorang kontraktor memerlukan satu aplikasi web dalaman dan tiada yang lain, dan jawapan mudahnya ialah memberinya terowong ke subnet pelayan. Itu berfungsi sehingga hari dia mengimbasnya. Reka bentuk yang lebih sempit memerlukan lebih banyak pemikiran, kerana kebolehcapaian, penghalaan dan kebenaran aplikasi ialah tiga kawalan berasingan yang mesti bersetuju.

Tulis keperluan sebagai perkhidmatan, bukan subnet

Mulakan dengan hos destinasi, protokol dan port, kemudian tambah kumpulan pengguna atau peranti yang sepatutnya sampai ke sana. Sertakan zon DNS peribadi hanya jika aplikasi menyelesaikan nama, dan sertakan pembekal identiti hanya jika aliran log masuk memerlukannya. Selebihnya ialah kebergantungan yang belum anda justifikasikan.

Subnet ialah butiran pelaksanaan pasukan rangkaian, manakala perkhidmatan ialah apa yang diminta oleh perniagaan dan unit yang boleh disemak dan dihentikan.

Jika senarai kebergantungan melebihi tiga item, aplikasi itu mungkin memerlukan perbualan reka bentuknya sendiri.

Hala sempit, tetapi kuatkuasakan di tempat lain

Laluan atau pemilih sempit memberitahu terowong paket mana yang perlu dibawa; ia bukan dasar kebenaran. Penapis get laluan, tembok api hos destinasi dan model kebenaran aplikasi itu sendiri ialah tempat akses diputuskan. Laluan yang meliputi satu alamat ialah permulaan yang baik, dan ia bukan kawalan yang menghentikan pengguna yang berazam. Pemisahan itulah yang membolehkan anda menukar penapis tanpa mereka bentuk semula terowong.

Sebaliknya, laluan lebar dengan penapis ketat boleh menjadi sah, tetapi hanya jika semua yang terlibat tahu yang mana satu melakukan penguatkuasaan.

Dokumenkan titik penguatkuasaan secara eksplisit, jika tidak perubahan seterusnya akan memindahkannya secara tidak sengaja.

Periksa sumber yang benar-benar dilihat oleh perkhidmatan

Sasaran melihat alamat kumpulan klien atau alamat get laluan, bergantung kepada sama ada anda menterjemah. Peraturan tembok api hos dan log mesti sepadan dengan sumber sebenar. Jika beberapa pengguna berkongsi sumber terjemahan, tiada peraturan setiap pengguna pada hos itu boleh membezakan mereka, dan itu ialah kekangan reka bentuk, bukan pepijat.

Pilih terjemahan dengan sengaja: ia memudahkan penghalaan dan memusnahkan identiti sumber, yang penting untuk audit dan untuk peraturan setiap pengguna.

Catat yang mana satu daripada dua yang anda pilih, di sebelah peraturan yang bergantung padanya.

Kebenaran aplikasi bukan pilihan

Mencapai port tidak memberikan peranan. Aplikasi masih memerlukan log masuk dan kebenarannya sendiri, kerana lapisan rangkaian tidak dapat menyatakan rekod mana yang boleh diedit oleh pengguna. Perkhidmatan yang mempercayai setiap permintaan daripada subnet dalaman menukar terowong sempit menjadi akses penuh untuk satu kelayakan yang terjejas. Terowong menentukan siapa yang boleh membuka soket, dan aplikasi menentukan apa yang boleh dilakukan dengannya.

Di sinilah reka bentuk sempit berbaloi dua kali, kerana lebih sedikit hos yang boleh dicapai bermakna lebih sedikit tempat kesilapan peringkat aplikasi boleh dieksploitasi.

Kekalkan peraturan rangkaian dan peranan aplikasi dalam sistem berasingan, dan hentikan kedua-duanya secara berasingan.

Buktikan kedua-dua laluan yang dibenarkan dan yang ditolak

Sambung sebagai pengguna yang dibenarkan dan lakukan satu operasi wakil yang tidak berbahaya, kemudian cuba destinasi yang sepatutnya tidak boleh dicapai. Reka bentuk yang hanya menguji separuh pertama tidak diuji, dan ujian penolakan itulah yang membuktikan reka bentuk. Uji sesi baharu selepas setiap perubahan peraturan, dan lihat laluan balik jika permintaan tiba tetapi balasan tidak.

Jangan lumpuhkan penapis penghantaran untuk meluluskan ujian penerimaan, kerana itu mengubah perkara yang sedang diuji.

Apabila pengguna tidak lagi memerlukan perkhidmatan, hentikan identiti jauh dan peranan aplikasi dalam sistem masing-masing, dan rekod kedua-duanya. Panduan penghantaran strongSwan merangkumi bahagian get laluan laluan itu.