Bastion SSH atau akses VPN langsung: kebijakan mana yang berlaku?
Lakukan empat pemeriksaan secara berurutan: apa yang dikendalikan bastion, apakah target dapat membedakan jalurnya, apa yang disimpan log, dan di mana kebijakan ditegakkan.
Apakah pengguna VPN boleh mencapai server tanpa melewati host lompat adalah pertanyaan kebijakan yang memakai kostum jaringan. Jika bastion menjalankan kendali yang diwajibkan, maka bergabung ke VPN harus mengarah ke sana, bukan memutarinya. Jika host lompat hanya menjembatani segmen yang dahulu tak terjangkau, jalur langsung yang sempit bisa menjadi pengganti yang jujur. Kerjakan pemeriksaan di bawah ini secara berurutan dan berhenti pada yang pertama gagal, karena jawaban itu menentukan sisanya.
Periksa apa yang sebenarnya dikendalikan bastion
Mulailah dari bukti tentang keadaan sekarang, bukan dari diagram di dokumen rancangan. Lihat konfigurasi SSH dan penyaring paket pada target: jika port 22 masuk hanya diterima dari alamat bastion, host lompat adalah kendali yang dipaksakan. Jika port yang sama menerima koneksi dari seluruh kumpulan VPN, bastion hanyalah kemudahan dan penegakannya berada di tempat yang sama sekali lain. Riwayat tiket biasanya memastikan mana dari keduanya yang lebih dahulu ada.
Nyatakan temuan dalam satu kalimat yang menyebut kendali yang disediakan bastion: pembatasan tujuan, langkah autentikasi kedua, perekaman sesi, atau visibilitas operasional selama insiden. Kalimat itulah yang harus dipertahankan oleh kebijakan pengganti.
Periksa apakah target dapat membedakan jalurnya
Aturan alamat sumber hanya bekerja selama kedua jalur tiba dengan alamat sumber yang berbeda. Gateway VPN yang menyamarkan lalu lintas ke subnet server menghapus perbedaan itu, dan setiap koneksi ke port 22 lalu tampak datang dari gateway. Pemeriksaannya lokal pada target dan hanya sebentar: daftarkan sesi SSH yang terbentuk dan baca alamat pasangan untuk masing-masing.
Ketika kedua jalur melebur menjadi satu alamat, pembedaan harus dilakukan lebih awal, melalui tujuan yang boleh didorong VPN dan melalui penyaring milik gateway sendiri. Menambahkan aturan pada target dalam situasi itu menciptakan ilusi batas tanpa mengubah apa yang tiba.
Periksa apa yang sebenarnya disimpan setiap catatan
Tiga log berbeda menggambarkan tiga peristiwa berbeda, dan tidak satu pun menggantikan yang lain. Catatan koneksi VPN menunjukkan bahwa sebuah identitas masuk ke lingkup jaringan. Catatan penerusan bastion menunjukkan kanal TCP yang meninggalkannya menuju tujuan dan port. Log autentikasi target menunjukkan bahwa sebuah akun masuk melalui SSH. Membacanya bersama-sama itulah yang menghasilkan lini masa; membaca satu saja menghasilkan dugaan.
Tidak satu pun catatan itu memuat apa yang terjadi di dalam sesi terenkripsi antara klien dan target. Jika tinjauan tingkat perintah merupakan syarat, diperlukan mekanisme perekaman yang diterapkan dengan sengaja beserta aturan penanganan datanya sendiri. Mengharapkannya dari log host lompat adalah cara sebuah celah audit tetap tersembunyi sampai ia penting.
Periksa di mana kebijakan sebenarnya ditegakkan
Pengaturan klien seperti ProxyJump adalah permintaan, bukan pembatasan. OpenSSH akan dengan senang hati membuka koneksi langsung ketika tujuan dapat dijangkau, jadi berkas konfigurasi di laptop menggambarkan niat sementara firewall menentukan hasilnya. Penegakan berada pada tujuan yang diizinkan gateway VPN dan pada aturan akses milik target sendiri, dan keduanya tidak dapat disunting pengguna. Audit jalur alternatif pada saat yang sama: antarmuka kedua, pendengar publik, lapisan mesh, atau terowongan lama antar situs masing-masing dapat memulihkan jalan pintas yang baru saja Anda tutup.
Konfigurasikan ProxyJump tetap saja, karena itu membuat rute yang disetujui menjadi yang termudah dan mencegah pekerjaan rutin menghasilkan pengecualian. Pastikan apa yang sebenarnya diselesaikan klien sebelum memercayainya.
ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'
Verifikasi dengan percobaan langsung yang disengaja
Kebijakan yang belum pernah diuji hanyalah harapan. Dari klien yang tersambung ke VPN, coba jalur yang seharusnya kini ditolak, lalu coba jalur yang disetujui, dan simpan kedua hasilnya. Percobaan yang ditolak adalah bukti bahwa perubahan itu berlaku.
nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true
Hasil yang bersih tampak seperti koneksi langsung yang ditolak atau kehabisan waktu ke alamat target, diikuti login berhasil ke host lompat dan entri autentikasi di sisi target yang menyebut sumber yang didukung. Apa pun yang lain berarti batasnya masih berpori, apa pun kata dokumentasinya. Catat tanggal, aturan yang diubah, dan kedua hasilnya, lalu berikan pemilik dan tanggal kedaluwarsa pada jalur pemulihan agar akses darurat tidak diam-diam menjadi rute sehari-hari.