Memindahkan aplikasi web syarikat ke belakang VPN: panduan peralihan

Bayangkan perubahan itu dari sisi pengguna. Seseorang mengklik penanda buku, menjangkakan halaman log masuk yang biasa, tetapi sebaliknya menerima ralat sambungan kerana nama hos kini hanya menjawab di dalam terowong. Saat tunggal itu mengandungi segala yang perlu dilakukan oleh pelan migrasi dengan betul: nama, laluan, sijil, akaun dan operasi di belakangnya. Ikuti langkah di bawah dalam susunan itu dan peralihan tidak lagi menjadi lompatan.

Langkah 1: catat apa yang pengguna lakukan hari ini

Mulakan dengan nama hos dalam bar alamat, port, operasi yang dilakukan orang dan akaun yang mereka gunakan. Jika anda tidak dapat menamakan tiga operasi utama, anda belum bersedia untuk menutup pintu masuk awam, kerana anda tidak akan mengenali yang rosak semasa penerimaan.

Kemudian tentukan siapa khalayak peribadi. Pekerja pada VPN korporat ialah permulaan, bukan jawapan. Kontraktor, kakitangan sokongan dan pasukan kewangan mungkin semuanya memerlukan aplikasi itu dan mungkin tidak semuanya berada di belakang get laluan yang sama.

Langkah 2: pisahkan terowong daripada log masuk

Apabila pengguna mencapai aplikasi melalui VPN, pelayar masih membuka sambungan TLS ke titik akhir aplikasi itu sendiri. Sijil mesti sepadan dengan nama itu, dan aplikasi masih mengesahkan akaun. Tiada apa-apa dalam terowong menggantikan mana-mana satu daripadanya.

Di sinilah migrasi senyap menjadi salah. Seseorang memutuskan alamat peribadi tidak lagi memerlukan sijil yang sah, pengguna belajar mengklik melalui amaran, dan organisasi telah menukar pendedahan awam dengan program latihan mengabaikan amaran keselamatan. Jika aplikasi benar-benar memerlukan sijil dalaman, keluarkan satu daripada pihak berkuasa dalaman dan edarkan kepercayaan dengan betul. Itu perubahan terkawal; halaman amaran bukan.

Kekalkan kebenaran di tempat ia sudah berada. Ringkasan seni bina sifar kepercayaan NIST menyatakan perkara itu secara langsung: lokasi rangkaian bukan alasan untuk memberikan operasi sensitif. Berada di dalam terowong tidak sepatutnya menjadikan akaun baca sahaja sebagai pentadbir.

Langkah 3: cari pemanggil yang bukan pekerja

Buka konfigurasi aplikasi dan senaraikan semua yang bercakap dengannya: URL panggil balik penyedia identiti, webhook penyedia pembayaran, import berjadual, prob pemantauan, klien API rakan kongsi. Setiap satu ialah kebergantungan dengan pemilik, dan setiap satu akan rosak pada masa yang berbeza.

Tentukan laluan yang disokong untuk setiap satu yang mesti kekal. Penyedia webhook tidak boleh menyertai VPN pekerja anda, jadi sama ada dedahkan titik akhir integrasi berskala sempit dengan pengesahan sendiri, atau ubah model integrasi. Membiarkan seluruh aplikasi awam kerana ada satu panggil balik ialah pilihan, dan biasanya pilihan yang salah.

Catat setiap pengecualian dengan destinasi, operasi yang dibenarkan, pengesahan dan pemilik. Akaun VPN generik yang diberikan kepada integrasi ialah cara pengecualian menjadi kekal. Semak senarai pada semakan akses seterusnya, kerana integrasi hidup lebih lama daripada projek yang menambahnya. Pengecualian tanpa tarikh luput ialah keputusan reka bentuk kekal yang tiada siapa buat.

Langkah 4: bersarakan laluan awam, bukan hanya rekod DNS

Jelajahi rantaian penerbitan: DNS, pendengar pengimbang beban, peraturan proksi songsang, tembok api hos dan mana-mana nama alternatif yang masih menunjuk ke alamat lama. Semak kedua-dua keluarga alamat. Menukar rekod A utama hampir tidak membuktikan apa-apa jika CNAME lama atau pendengar IPv6 masih menyediakan aplikasi itu.

Secara selari, sahkan bahawa nama peribadi diselesaikan di dalam terowong dan sijil meliputi nama yang akan ditaip pengguna. Pengguna yang terpaksa menampal alamat berangka telah menemui gejala, bukan penyelesaian.

Hadkan khalayak VPN kepada laluan aplikasi. Akses luas ke rangkaian pejabat menukar satu keputusan pendedahan dengan yang lebih besar, dan antara muka pentadbiran memerlukan sumber dibenarkan sendiri dan bukannya mewarisi peraturan pengguna.

Langkah 5: lalui penerimaan sendiri

Sambung sebagai pengguna yang diluluskan, buka penanda buku, semak sijil, log masuk dan lakukan satu operasi sebenar. Kemudian cuba akaun yang tidak sepatutnya mempunyai operasi itu dan sahkan ia ditolak. Kemudian cuba dari peranti di luar VPN dan sahkan aplikasi tidak dapat dicapai.

Ulang untuk setiap integrasi yang dikekalkan, dan baca log penghantaran penyedia dan bukannya menganggap 200 daripada alat ujian anda sendiri adalah perkara yang sama. Log masuk VPN yang berjaya bukan bukti bagi mana-mana hasil ini.

Langkah 6: latih hari yang buruk

Tentukan apa yang berlaku semasa gangguan terowong: kerja berhenti, atau kaedah akses lain yang diluluskan mengambil alih. Apa pun yang anda pilih, catat dan uji sekali, kerana pembukaan semula awam kecemasan sebagai mekanisme pemulihan tidak berdokumen akhirnya akan dilakukan oleh seseorang di bawah tekanan.

Kekalkan akses pemulihan untuk pentadbir yang menyelenggara get laluan dan aplikasi, dengan pemilik dan tarikh pembuangan. Rekodkan perubahan dan syarat pembalikannya di tempat yang sama, supaya migrasi yang gagal tidak mengunci orang yang akan membaikinya.

Selepas peralihan, penampal, kitaran hayat akaun, kebenaran aplikasi dan audit masih milik anda. Terowong menyempitkan pintu masuk; ia tidak mengambil alih mana-mana tugas itu.