Pusatkan akses VPN mitra tanpa menggabungkan para mitra

Usulannya masuk akal: lima tunnel mitra tersebar di selusin laptop, lima set versi klien, lima skrip meja bantuan, dan satu insinyur yang tahu bagaimana semuanya cocok. Memindahkannya ke tingkat akses terkelola menyelesaikan penumpukan endpoint. Ini juga menciptakan objek baru dalam arsitektur Anda, layanan akses bersama yang kini butuh model otorisasinya sendiri, dan kegagalan yang semua orang remehkan adalah perangkat pusat dengan semua tunnel aktif yang diam-diam menjadi jaringan transit antarorganisasi yang tidak pernah setuju menjadi tetangga. Risiko itu adalah pilihan desain, bukan sesuatu yang dilakukan perangkat keras sendiri. Pekerjaan di bawah adalah bagaimana saya menjaga kenyamanan tanpa menerima efek samping yang tak disengaja.

Mulai dari kontrak yang sudah ditandatangani setiap mitra

Sebelum konfigurasi apa pun, pastikan mitra memang mengizinkan gateway bersama atau koneksi situs. Akun akses jarak jauh pribadi, persyaratan postur perangkat, atau alur MFA interaktif mungkin tidak dapat dipindahkan ke tunnel bersama tanpa pengawasan, dan mengumpulkan karyawan di balik satu identitas klien yang disalin adalah jalan pintas yang bertahan sampai mitra mengaudit log mereka. Untuk setiap koneksi yang diizinkan, catat rentang tujuan, domain DNS privat, sumber internal yang diotorisasi, pemilik autentikasi, dan apa yang harus terjadi saat tunnel gagal. Mintalah mitra mengonfirmasi koneksi bersama secara tertulis, termasuk rentang sumber yang akan mereka terima. Persetujuan lisan biasanya berubah makna pada minggu tim keamanan mereka berganti.

Catatan itulah hasilnya. Jika Anda tidak dapat menulisnya untuk satu mitra, mitra itu belum siap dipusatkan.

Rutekan menurut konteks, bukan hanya tujuan

Dua mitra akhirnya akan memakai rentang privat yang sama, karena setiap organisasi memilih dari ruang RFC 1918 yang sama. Satu tabel perutean biasa tidak dapat memilih mitra yang benar hanya dari alamat tujuan, jadi rentang yang tumpang tindih memerlukan konteks perutean terpisah atau desain lain yang disepakati. Model domain penerusan dalam RFC 4364 menjelaskan mengapa pemisahan itu penting, dan penerapan tidak perlu menjalankan MPLS untuk menuntut properti yang sama dari platform gateway-nya.

Tanyakan langsung ke platform: dapatkah dua mitra berbagi prefiks tujuan yang sama dan tetap dibedakan berdasarkan konteks karyawan asal sesi? Jika jawabannya tidak, batasan itu membentuk desain lebih dari daftar fitur vendor mana pun.

Di mana jawabannya ya, konteks perutean menjadi hal yang Anda dokumentasikan dan uji, karena ia tak terlihat dalam traceroute.

Putuskan apa yang diketik karyawan dan apa yang dicatat mitra

Sebagian pekerjaan mitra cocok untuk proxy aplikasi atau ruang kerja jarak jauh yang dibuka dalam konteks mitra tersebut. Pekerjaan lain memerlukan akses jaringan terutekan dari segmen karyawan yang disetujui, dan keduanya menghasilkan alamat sumber dan jejak audit yang berbeda di ujung jauh. Alamat sumber hasil terjemahan bersama dapat memenuhi daftar izin sekaligus menyembunyikan perangkat mana yang melakukan apa, jadi pertahankan catatan andal karyawan-ke-sesi dan biarkan autentikasi aplikasi tetap ada alih-alih memperlakukan alamat gateway sebagai identitas, yang nyaman sampai saat mitra bertanya siapa yang melakukannya.

Lalu telusuri satu tugas nyata dari sisi karyawan: apa yang mereka klik, apa yang diminta, dan apa yang akan dilihat mitra jika meminta entri log. Jika penelusuran itu tidak dapat diulang, desainnya belum selesai.

Tolak transit mitra-ke-mitra secara eksplisit

Perangkat keras bersama tidak boleh menyiratkan kepercayaan bersama. Tambahkan penolakan sebagai aturan yang disengaja dengan pemilik bernama, bukan kecelakaan konfigurasi yang hilang, dan ujilah dari kedua arah dengan permintaan yang seharusnya berhasil. Uji itu penting karena izin yang sekadar tidak ada dapat dipulihkan oleh insinyur berikutnya yang menambahkan rute untuk memperbaiki keluhan tak terkait.

Tuliskan penolakan itu di catatan mitra di samping izin, agar niatnya bertahan melewati pergantian staf.

Jalankan sebagai layanan bersama, bukan sebagai laptop yang lebih besar

Pembaruan tunnel, rotasi kredensial, kapasitas, dan penggantian gateway kini semuanya menjadi perubahan layanan bersama, yang berarti semuanya butuh jadwal dan jalur komunikasi yang tidak pernah diperlukan laptop individual. Sertifikat mitra yang kedaluwarsa pada Sabtu bukan lagi gangguan satu pengguna; itu semua sesi mitra tersebut sekaligus.

Terima tingkat itu hanya ketika permintaan lintas mitra yang ditolak gagal tepat seperti yang dimaksudkan dan permintaan karyawan yang diizinkan mencapai tujuan yang benar dengan sumber yang benar. Menghapus konflik laptop sambil menjaga batas setiap mitra tetap utuh adalah inti persoalannya; desain yang membuat setiap prefiks jarak jauh dapat dijangkau dari setiap meja hanya memindahkan masalahnya.

Simpan tabel kecil berisi mitra, konteks, rentang yang diizinkan, dan pemilik. Itulah hal pertama yang akan diminta orang saat insiden.