Kunci SSH Bocor Sekali, Server Bisa Jadi Milik Orang

Kamu mungkin sudah rajin rotasi password, menutup FTP, dan membatasi akses root. Namun, satu private key lama di laptop mantan kontraktor masih bisa membuka jalan ke server production. Itulah masalah utama akses server tradisional: izin masuk sering hidup lebih lama daripada orang, proyek, dan alasan bisnisnya.

Solusinya bukan sekadar “pakai SSH yang lebih kuat”. Untuk hosting engineer, agency, dan tim DevOps, pendekatan yang lebih waras adalah zero trust SSH dengan short-lived access: akses dibuat saat dibutuhkan, diverifikasi lewat identitas, lalu otomatis mati.

Kenapa SSH dan SFTP Tradisional Mulai Jadi Beban?

SSH tetap kuat secara kriptografi. Masalahnya, cara banyak tim mengelolanya sering berantakan. Akhirnya, private key tersebar, akun Linux menumpuk, dan akses lama jarang diaudit.

SFTP juga sering menjadi pintu belakang yang “resmi”. Agency membuat akun untuk upload file, freelancer mendapat akses sementara, lalu semua orang lupa menutupnya. Karena itu, risiko bukan hanya dari hacker, tetapi juga dari akses sah yang terlalu lama hidup.

Gejala yang biasanya muncul

• Authorized_keys penuh key yang pemiliknya nggak jelas.
• Akun FTP/SFTP dibuat per klien, tetapi jarang dicabut.
• Vendor masih bisa masuk setelah kontrak selesai.
• Audit log hanya menunjukkan user Linux, bukan identitas orang.
• Tim berbagi private key karena “lebih cepat”.

Apa Itu Zero Trust SSH?

Zero trust SSH adalah model akses server yang tidak menganggap jaringan internal, VPN, IP kantor, atau key lama sebagai bukti kepercayaan. Setiap koneksi harus melewati verifikasi identitas, konteks, policy, dan durasi akses.

Dalam praktiknya, engineer login lewat identity provider seperti Google Workspace, Okta, GitHub, atau SSO internal. Setelah itu, sistem menerbitkan certificate atau token SSH yang hanya berlaku beberapa menit atau jam. Setelah kedaluwarsa, akses hilang tanpa perlu seseorang membersihkan file authorized_keys.

Konsep ini sejalan dengan prinsip NIST Zero Trust Architecture: jangan percaya otomatis, selalu verifikasi, dan batasi akses sesuai kebutuhan.

Short-Lived Access: Bagian yang Sering Diremehkan

Banyak tim fokus ke MFA, VPN, dan firewall. Semua itu penting. Namun, durasi akses sering lebih menentukan dampak insiden.

Key permanen yang bocor hari ini masih berbahaya bulan depan. Sebaliknya, certificate SSH berdurasi 15 menit yang bocor punya jendela serang jauh lebih kecil. Jadi, kamu bukan hanya mencegah akses tidak sah, tetapi juga mengecilkan ledakan saat sesuatu tetap bocor.

Framework 5P untuk Mengganti SSH/SFTP Lama

Agar migrasi nggak kacau, gunakan framework 5P: Person, Purpose, Policy, Period, Proof. Framework ini membantu kamu mengganti akses permanen tanpa menghambat tim operasional.

1. Person: identitas manusia dulu, user Linux belakangan

Mulai dari siapa yang masuk, bukan akun apa yang dipakai. Hubungkan akses ke SSO, grup tim, atau direktori karyawan. Dengan begitu, saat seseorang keluar dari organisasi, akses server ikut mati otomatis.

2. Purpose: akses harus punya alasan

Jangan beri akses “buat jaga-jaga”. Pisahkan kebutuhan deploy, debugging, backup, dan emergency. Selain itu, minta alasan singkat saat privilege dinaikkan agar audit lebih berguna.

3. Policy: aturan masuk harus eksplisit

Policy bisa mengatur siapa boleh masuk ke server mana, dari perangkat apa, memakai MFA atau tidak, dan pada jam berapa. Misalnya, agency hanya boleh akses staging, sedangkan production butuh approval tambahan.

4. Period: akses harus kedaluwarsa cepat

Durasi ideal tergantung risiko. Untuk production, mulai dari 15 sampai 60 menit. Untuk staging, kamu bisa sedikit lebih longgar, tetapi tetap hindari akses permanen.

5. Proof: semua aktivitas harus bisa dibuktikan

Audit log harus menjawab tiga pertanyaan: siapa masuk, ke server mana, dan melakukan apa. Bahkan, beberapa tool modern bisa merekam sesi terminal. Ini sangat membantu saat investigasi insiden atau review kepatuhan.

Cara Mengganti SFTP Tanpa Membuat Tim Marah

Menghapus SFTP begitu saja biasanya gagal. Tim konten, agency, atau vendor masih butuh cara upload file. Karena itu, ganti alurnya, bukan hanya tutup portnya.

• Untuk deploy aplikasi, gunakan CI/CD dengan secret terkontrol.
• Untuk upload aset, gunakan object storage seperti S3-compatible bucket.
• Untuk akses darurat, gunakan SSH certificate berdurasi pendek.
• Untuk file WordPress, gunakan workflow Git, backup terjadwal, dan staging aman.

Kalau kamu mengelola WordPress, perhatikan juga celah di environment non-production. Saya pernah membahasnya di artikel staging WordPress yang bisa jadi backdoor hacker. Polanya mirip: akses lama yang “sementara” sering berubah menjadi risiko permanen.

Tooling yang Bisa Kamu Pertimbangkan

Kamu bisa membangun sendiri dengan OpenSSH certificates, bastion host, dan CA internal. Namun, untuk tim yang butuh audit cepat, tool siap pakai sering lebih efisien.

• Teleport untuk access proxy, SSH certificate, session recording, dan RBAC.
• Cloudflare Zero Trust untuk identity-aware access dan private network access.
• OpenSSH CA untuk pendekatan minimalis berbasis certificate.

Pilihan terbaik bukan yang paling mahal, melainkan yang paling konsisten dipakai tim. Karena itu, ukur keberhasilan dari berkurangnya key permanen, bukan dari banyaknya dashboard keamanan.

Checklist Implementasi Zero Trust SSH

1. Inventaris semua user Linux, key SSH, akun SFTP, dan vendor access.
2. Matikan password login SSH, lalu wajibkan key atau certificate.
3. Hubungkan login ke SSO dan MFA.
4. Terapkan SSH certificate berdurasi pendek.
5. Buat policy per role, environment, dan tingkat risiko.
6. Ganti SFTP permanen dengan CI/CD, object storage, atau akses sementara.
7. Aktifkan audit log dan, jika perlu, session recording.
8. Review akses setiap bulan sampai akun liar benar-benar hilang.

Kesimpulan: Jangan Simpan Kunci yang Nggak Perlu Disimpan

Zero trust SSH bukan tren kosmetik. Ini cara praktis untuk menghapus standing server access, memperkecil dampak leaked keys, dan menutup akun FTP yang selama ini luput dari radar. Selain itu, short-lived access membuat keamanan terasa lebih operasional, bukan sekadar dokumen policy.

Kalau kamu mengelola banyak server, mulai dari satu target paling berisiko: production yang masih punya banyak key permanen. Bersihkan dari sana, lalu perluas ke staging, vendor, dan workflow deployment.

FAQ

Apakah zero trust SSH berarti SSH tidak aman?

Bukan. SSH tetap aman jika dikonfigurasi benar. Masalah utama biasanya ada pada key permanen, akun tidak terkelola, dan audit yang lemah.

Berapa durasi ideal short-lived access?

Untuk production, 15 sampai 60 menit biasanya cukup. Untuk staging atau lab, durasi bisa lebih panjang, tetapi tetap sebaiknya kedaluwarsa otomatis.

Apakah SFTP harus dihapus total?

Tidak selalu. Namun, akun SFTP permanen sebaiknya diganti dengan akses sementara, object storage, atau pipeline deploy yang lebih mudah diaudit.