Mengganti Kunci VPN yang Bocor: Apa yang Harus Dilakukan Server

Sebuah laptop yang membawa kunci klien hilang, dan tindakan pertama biasanya menghapus salinan lokal. Itu tidak mengubah apa pun di server, yang masih menyimpan otorisasi yang akan menerima kunci itu sampai seseorang menghapusnya. Penggantian adalah dua operasi, dan hanya operasi kedua yang menyangkut kredensial lama.

Salinan lokal bukanlah otoritas

Kredensial VPN diterima karena konfigurasi di sisi server menyatakannya. Untuk sertifikat, itu berarti sertifikat berantai ke penerbit tepercaya dan tidak muncul di daftar pencabutan yang diperiksa gateway. Untuk WireGuard, itu berarti kunci publik peer muncul dalam konfigurasi antarmuka. Menghapus berkas di klien menghilangkan satu salinan rahasia dan membiarkan aturan penerimaan tidak tersentuh.

Itulah mengapa kunci yang dicuri tetap berfungsi setelah pembersihan yang jelas, dan mengapa insiden itu terasa belum tuntas bahkan ketika konfigurasi baru sudah dipasang.

Mulailah dari aturan server, lalu bekerjalah ke luar menuju klien.

Sertifikat: server memegang keputusan

Terbitkan penggantian melalui proses penerbit itu sendiri agar identitas baru tercatat, lalu tarik yang lama dengan pencabutan bertanda tangan. Gateway harus dikonfigurasi untuk memeriksa sumber pencabutan itu, dan gateway harus memuat ulangnya, atau berkasnya tertinggal di disk sementara terowongan terus menerima nomor seri lama. Sesi aktif juga dapat bertahan sampai negosiasi ulang, jadi rencanakan penyambungan ulang.

Pastikan penggantian berfungsi untuk aplikasi yang dimaksud, lalu pastikan melalui proses yang disetujui bahwa sertifikat yang sudah dipensiunkan tidak lagi membentuk akses.

Itu dua pengujian berbeda dan keduanya wajib. RFC 5280 mendefinisikan semantik sertifikat dan pencabutan yang menjadi landasan gateway.

WireGuard: kunci peer adalah identitasnya

WireGuard tidak memiliki lapisan sertifikat: kunci publik peer adalah identitasnya, dan entri allowed-ips di server adalah otorisasinya. Menghapus peer lama dari konfigurasi antarmuka adalah pencabutannya, dan itu langsung berlaku untuk handshake baru.

Sesi yang ada berakhir ketika handshake berikutnya gagal, yang biasanya terjadi dalam beberapa menit, bukan seketika.

Distribusikan konfigurasi baru melalui saluran yang Anda percayai untuk menyerahkan kata sandi, karena kunci privat adalah kredensialnya. Simpan satu kunci per perangkat, agar satu perangkat yang hilang tidak memaksa setiap perangkat berubah.

Apa lagi yang ada dalam bundel itu

Bundel klien sering membawa lebih dari kunci privat: kunci TLS statis, nama pengguna dan kata sandi, rahasia yang dibagikan sebelumnya, atau token penyediaan. Batasi insiden pada apa yang benar-benar terekspos dan putar juga item tersebut. Memutar sertifikat sementara kunci statis bersama dibiarkan di tempatnya menutup satu pintu dan membiarkan pintu lain terbuka.

Jika bundel dibagikan antarperangkat, setiap perangkat yang membawanya mewarisi paparan itu.

Catat apa yang diputar, karena audit berikutnya akan menanyakannya.

Buktikan penolakan, lalu catat penggantiannya

Penggantian selesai ketika dua fakta terpenuhi: identitas baru berfungsi untuk layanan yang dimaksud, dan identitas lama ditolak. Verifikasi yang kedua dengan kredensial yang sudah dipensiunkan dari lingkungan pengujian, atau dengan percobaan terkendali yang disetujui organisasi, dan baca log gateway untuk memastikan penolakan berasal dari kebijakan, bukan dari salah ketik. Lalu catat pengenal lama, pengenal baru, dan waktu perubahan, karena ketiga nilai itulah yang dibutuhkan auditor untuk merekonstruksinya. Tidak ada hal lain di tiket yang akan menjelaskan celah itu.

Jauhkan kunci privat dari tiket dan obrolan, dan hapus ekspor yang sudah usang dari penyimpanan dan cadangan sesuai kebijakan.

Penggantian tanpa uji penolakan adalah asumsi, bukan perbaikan.