Beri Pengguna VPN Akses ke Satu Layanan, Bukan ke Subnet

Seorang kontraktor membutuhkan satu aplikasi web internal dan tidak ada yang lain, dan jawaban mudahnya adalah memberinya terowongan ke subnet server. Itu berfungsi sampai hari ia memindainya. Desain yang lebih sempit menuntut lebih banyak pemikiran, karena keterjangkauan, perutean, dan izin aplikasi adalah tiga kontrol terpisah yang harus sepakat.

Tuliskan kebutuhan sebagai layanan, bukan subnet

Mulailah dari host tujuan, protokol, dan port, lalu tambahkan grup pengguna atau perangkat yang harus mencapainya. Sertakan zona DNS privat hanya jika aplikasi menyelesaikan nama, dan sertakan penyedia identitas hanya jika alur masuk membutuhkannya. Sisanya adalah dependensi yang belum Anda justifikasi.

Subnet adalah detail implementasi tim jaringan, sedangkan layanan adalah apa yang diminta bisnis dan unit yang dapat ditinjau dan dihentikan.

Jika daftar dependensi tumbuh melewati tiga item, aplikasi mungkin memerlukan percakapan desainnya sendiri.

Rutekan secara sempit, tetapi tegakkan di tempat lain

Rute atau pemilih yang sempit memberi tahu terowongan paket mana yang harus dibawa; itu bukan kebijakan otorisasi. Filter gateway, firewall host tujuan, dan model izin aplikasi itu sendiri adalah tempat akses diputuskan. Rute yang mencakup satu alamat adalah awal yang baik, dan itu bukan kontrol yang menghentikan pengguna yang bertekad. Pemisahan itulah yang memungkinkan Anda mengubah filter tanpa merancang ulang terowongan.

Sebaliknya, rute lebar dengan filter ketat bisa sah, tetapi hanya jika semua yang terlibat tahu mana yang melakukan penegakan.

Dokumentasikan titik penegakan secara eksplisit, atau perubahan berikutnya akan memindahkannya secara tidak sengaja.

Periksa sumber yang benar-benar dilihat layanan

Target melihat alamat kumpulan klien atau alamat gateway, tergantung apakah Anda menerjemahkan. Aturan firewall host dan log harus cocok dengan sumber sebenarnya. Jika beberapa pengguna berbagi sumber yang diterjemahkan, tidak ada aturan per pengguna di host itu yang dapat membedakan mereka, dan itu adalah batasan desain, bukan bug.

Pilih penerjemahan dengan sengaja: itu menyederhanakan perutean dan menghancurkan identitas sumber, yang penting untuk audit dan untuk aturan per pengguna.

Catat mana dari keduanya yang Anda pilih, di samping aturan yang bergantung padanya.

Otorisasi aplikasi tidak opsional

Mencapai port tidak memberikan peran. Aplikasi tetap membutuhkan login dan izinnya sendiri, karena lapisan jaringan tidak dapat menyatakan catatan mana yang boleh diedit pengguna. Layanan yang memercayai setiap permintaan dari subnet internal mengubah terowongan sempit menjadi akses penuh untuk satu kredensial yang disusupi. Terowongan memutuskan siapa yang boleh membuka soket, dan aplikasi memutuskan apa yang boleh dilakukan dengannya.

Di sinilah desain sempit membayar dua kali, karena lebih sedikit host yang terjangkau berarti lebih sedikit tempat kesalahan tingkat aplikasi dapat dieksploitasi.

Pertahankan aturan jaringan dan peran aplikasi di sistem terpisah, dan hentikan keduanya secara terpisah.

Buktikan jalur yang diizinkan dan yang ditolak

Hubungkan sebagai pengguna yang berwenang dan lakukan satu operasi perwakilan yang tidak berbahaya, lalu coba tujuan yang seharusnya tidak terjangkau. Desain yang hanya menguji separuh pertama tidak teruji, dan uji penolakanlah yang membuktikan desain. Uji sesi baru setelah setiap perubahan aturan, dan lihat jalur kembali jika permintaan datang tetapi balasan tidak.

Jangan nonaktifkan filter penerusan agar uji penerimaan lolos, karena itu mengubah hal yang sedang diuji.

Ketika pengguna tidak lagi membutuhkan layanan, hentikan identitas jarak jauh dan peran aplikasi di sistem masing-masing, dan catat keduanya. Panduan penerusan strongSwan mencakup sisi gateway dari jalur tersebut.