Pusatkan Akses VPN Rakan Kongsi Tanpa Menggabungkan Rakan Kongsi

Cadangan itu munasabah: lima terowong rakan kongsi bertaburan di sedozen komputer riba, lima set versi klien, lima skrip meja bantuan, dan seorang jurutera yang tahu bagaimana semuanya serasi. Memindahkannya ke lapisan akses terkawal menyelesaikan keadaan bertaburan di titik akhir. Ia juga mencipta objek baharu dalam seni bina anda, iaitu perkhidmatan akses dikongsi yang kini memerlukan model kebenarannya sendiri; dan kegagalan yang semua orang terlepas pandang ialah sebuah perkakas pusat dengan semua terowong dihidupkan secara senyap menjadi rangkaian transit antara organisasi yang tidak pernah bersetuju menjadi jiran. Risiko itu ialah pilihan reka bentuk, bukan sesuatu yang dilakukan perkakasan dengan sendirinya. Kerja di bawah ialah cara saya mengekalkan kemudahan tanpa menerima kesan sampingan yang tidak disengajakan.

Mulakan daripada kontrak yang sudah ditandatangani setiap rakan kongsi

Sebelum sebarang konfigurasi, pastikan rakan kongsi membenarkan get laluan atau sambungan tapak dikongsi sama sekali. Akaun akses jauh peribadi, keperluan postur peranti, atau aliran MFA interaktif mungkin tidak boleh dipindahkan ke terowong dikongsi tanpa pengawasan, dan mengumpulkan pekerja di belakang satu identiti klien yang disalin ialah jalan pintas yang bertahan sehingga rakan kongsi mengaudit log mereka. Bagi setiap sambungan yang dibenarkan, catat julat destinasi, domain DNS persendirian, sumber dalaman yang dibenarkan, pemilik pengesahan, dan apa yang patut berlaku apabila terowong gagal. Minta rakan kongsi mengesahkan sambungan dikongsi itu secara bertulis, termasuk julat sumber yang akan mereka terima. Kelulusan lisan cenderung berubah makna pada minggu pasukan keselamatan mereka bertukar.

Rekod itu ialah hasilnya. Jika anda tidak dapat menulisnya untuk satu rakan kongsi, rakan kongsi itu belum bersedia untuk dipusatkan.

Halakan mengikut konteks, bukan destinasi semata-mata

Dua rakan kongsi akhirnya akan menggunakan julat persendirian yang sama, kerana setiap organisasi memilih daripada ruang RFC 1918 yang sama. Satu jadual penghalaan biasa tidak boleh memilih rakan kongsi yang betul berdasarkan alamat destinasi semata-mata, jadi julat yang bertindih memerlukan konteks penghalaan berasingan atau reka bentuk lain yang dipersetujui. Model domain penghantaran dalam RFC 4364 menerangkan mengapa pemisahan ini penting, dan sesuatu penggunaan tidak perlu menjalankan MPLS untuk memerlukan sifat yang sama daripada platform get laluannya.

Tanya platform itu soalan terus: bolehkah dua rakan kongsi berkongsi satu awalan destinasi dan masih dibezakan mengikut konteks pekerja yang mana sesi itu datang? Jika jawapannya tidak, kekangan itu membentuk reka bentuk lebih daripada mana-mana senarai ciri vendor.

Di mana jawapannya ya, konteks penghalaan menjadi perkara yang anda dokumentasikan dan uji, kerana ia tidak kelihatan dalam traceroute.

Tentukan apa yang ditaip pekerja dan apa yang dilog rakan kongsi

Sesetengah kerja rakan kongsi sesuai dengan proksi aplikasi atau ruang kerja jauh yang dibuka dalam konteks rakan kongsi itu. Kerja lain memerlukan akses rangkaian berhalakan daripada segmen pekerja yang diluluskan, dan kedua-duanya menghasilkan alamat sumber dan jejak audit yang berbeza di hujung jauh. Alamat sumber terjemahan yang dikongsi boleh memenuhi senarai benaran sambil menyembunyikan peranti mana yang melakukan apa, jadi kekalkan rekod pekerja-ke-sesi yang boleh dipercayai dan biarkan pengesahan aplikasi kekal, bukannya menganggap alamat get laluan sebagai identiti, yang mudah sehingga tepat apabila rakan kongsi bertanya siapa yang melakukannya.

Kemudian jalankan satu tugas sebenar dari sisi pekerja: apa yang mereka klik, apa yang diminta daripada mereka, dan apa yang akan dilihat rakan kongsi jika mereka meminta entri log. Jika langkah itu tidak boleh diulang, reka bentuknya belum selesai.

Nafikan transit rakan kongsi-ke-rakan kongsi secara jelas

Perkakasan dikongsi tidak sepatutnya sekali-kali membayangkan kepercayaan dikongsi. Tambah penafian itu sebagai peraturan yang disengajakan dengan pemilik bernama, bukan sebagai kemalangan konfigurasi yang tertinggal, dan ujinya dari kedua-dua arah dengan permintaan yang sepatutnya berjaya. Ujian itu penting kerana kebenaran yang hanya tiada boleh dipulihkan oleh jurutera seterusnya yang menambah laluan untuk membaiki aduan yang tidak berkaitan.

Tulis penafian itu ke dalam rekod rakan kongsi di sebelah kebenaran, supaya niatnya kekal melepasi pertukaran kakitangan.

Jalankannya sebagai perkhidmatan dikongsi, bukan komputer riba yang lebih besar

Pembaharuan terowong, putaran kelayakan, kapasiti dan penggantian get laluan semuanya menjadi perubahan perkhidmatan dikongsi sekarang, bermakna ia memerlukan jadual dan laluan komunikasi yang tidak pernah diperlukan oleh komputer riba individu. Sijil rakan kongsi yang luput pada hari Sabtu bukan lagi gangguan seorang pengguna; ia gangguan setiap sesi rakan kongsi itu sekali gus.

Terima lapisan itu hanya apabila permintaan merentas rakan kongsi yang dinafikan gagal tepat seperti yang dimaksudkan dan permintaan pekerja yang dibenarkan sampai ke destinasi yang betul dengan sumber yang betul. Menghapuskan konflik komputer riba sambil mengekalkan sempadan setiap rakan kongsi ialah keseluruhan tujuannya; reka bentuk di mana setiap awalan jauh boleh dicapai dari setiap meja hanya memindahkan masalah itu.

Simpan jadual kecil rakan kongsi, konteks, julat yang dibenarkan dan pemilik. Ia akan menjadi perkara pertama yang diminta sesiapa semasa insiden.