Apakah Anda masih perlu VPN situs jika aplikasi memakai mTLS dan SSO?
Telusuri kanal yang tidak pernah dicakup login aplikasi Anda, lalu putuskan apakah akses jaringan privat berlebihan atau tetap satu-satunya jalur ke host.
Anda masuk lewat mTLS, dasbor termuat, dan klaim bahwa VPN situs kini berlebihan terdengar masuk akal kira-kira selama waktu yang dibutuhkan sampai Anda perlu memulihkan basis data pada pukul dua pagi. Batas TLS aplikasi hanya menjelaskan satu kanal. Host, basis data, target cadangan, dan akun cloud masing-masing membawa jalur masuk, identitas, dan penyetuju sendiri, dan tidak satu pun diuji oleh login yang berhasil.
Berjalanlah keluar dari layar login
Masuklah seperti pengguna biasa dan catat setiap lompatan yang disentuh permintaan: peramban, tepi, pendengar aplikasi, penyimpanan sesi, API backend. Setiap lompatan punya pemilik dan keputusan autentikasi. Sekarang ulangi penelusuran untuk orang yang menambal host, dan untuk tugas yang menulis cadangan malam. Penelusuran itu biasanya menyimpang sejak lompatan pertama.
Penyimpangan itulah pertanyaan yang layak dijawab. VPN situs hanya berlebihan bila setiap kanal dalam penelusuran kedua punya kebijakan masuk dan otorisasi yang berdiri sendiri.
Lima kanal yang tidak pernah dicakup login aplikasi
Tabel di bawah adalah templat inventaris, bukan daftar periksa penerapan. Isi kolom kedua dengan apa yang benar-benar ditegakkan lingkungan Anda hari ini.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Berbagi satu penyedia identitas tidak menyatukan otorisasi ini. Pengguna yang boleh mengirim permintaan API tidak dengan sendirinya boleh mengganti disk mesin virtual atau memulihkan basis data dengan kredensial aplikasi. NIST dalam ringkasan arsitektur tanpa kepercayaan justru karena itu menjaga autentikasi dan otorisasi sumber daya terpisah dari lokasi jaringan.
Insinyur dukungan yang bisa membaca tiket tidak dengan sendirinya boleh membuka konsol di host di belakangnya.
Sebuah jalur hanya nyata jika alternatifnya tetap tertutup
Membatasi keterjangkauan ke pendengar administratif privat adalah pengganti sah bagi VPN situs, asalkan pembatasannya ditegakkan dan bukan sekadar digambar. Kegagalan yang biasa adalah pendengar alternatif yang tidak diingat siapa pun: layanan yang masih terikat ke semua antarmuka, aturan grup keamanan yang dibuka untuk kontraktor, port manajemen yang terjangkau dari internet.
Periksa pendengar, bukan diagram. Di host, daftarkan apa yang benar-benar terikat dengan ss -ltnp dan pastikan port administratif berada di alamat privat. Di konsol cloud, baca aturan masuk untuk subnet beban kerja dan cari 0.0.0.0/0 pada apa pun yang administratif. Lalu coba koneksi dari luar jalur privat, karena uji itulah yang menjawab pertanyaannya.
Satu aturan terbuka ke seluruh dunia pada SSH membatalkan setiap argumen yang dibuat rancangan terowongan.
Tulis peta sebelum membandingkan rancangan
Untuk setiap baris inventaris, catat siapa yang menyetujui identitas, siapa yang memperbarui aturan akses, siapa yang menghapus kredensial saat seseorang keluar, dan siapa yang menangani pemulihan saat jalurnya sendiri rusak. Empat nama per baris cukup untuk menyingkap baris yang jawabannya adalah akun bersama dan halaman wiki berumur tiga tahun.
Lalu validasi satu izin dan satu penolakan per kanal. Izin membuktikan bahwa identitas yang dimaksud dapat mencapai sumber daya lewat jalur yang dimaksud. Penolakan membuktikan bahwa identitas serupa tidak dapat, dan itulah uji yang dilewati orang, karena itulah pendengar alternatif bertahan dari audit. Bandingkan rancangan yang diusulkan dengan hasil ini, bukan dengan konfigurasi TLS aplikasi, yang tidak pernah menguji satu pun darinya.
Di mana VPN situs masih pantas dipertahankan
Terowongan atau gerbang sempit adalah jawaban yang tepat bila sumber daya tidak punya autentikasi sendiri per permintaan: port pemeliharaan basis data, target cadangan, konsol hipervisor, manajemen di luar pita. Pendengar itu memercayai jaringan, jadi jaringan harus menjadi yang mengautentikasi pemanggil.
Itu bukan satu-satunya jawaban. Gerbang yang mengakhiri otorisasi per sumber daya bisa lebih sempit daripada terowongan seluruh subnet dan meninggalkan jejak audit yang lebih baik daripada host lompat bersama.
Urutan kerja: tuntaskan inventaris, tutup alternatifnya, validasi satu penolakan per baris, dan baru kemudian pensiunkan terowongan. Jika suatu baris tidak dapat menghasilkan penolakan, pertahankan jalur privat sampai bisa.