Belajar dari Nol: Membangun Fitur Remote Desktop dari Sisi Security

Waktu pertama kali diminta bikin fitur remote desktop buat salah satu proyek desktop app client (aplikasi internal buat tim support IT mereka), hal pertama yang saya sadari begitu mulai riset: ini bukan cuma soal “share layar dari device A ke device B”, tapi soal security dari ujung ke ujung yang kalau salah sedikit bisa jadi pintu masuk buat orang yang nggak seharusnya punya akses ke komputer siapa pun.

Draft pertama saya — jujur aja — terlalu naif. Saya bikin koneksi socket biasa, kirim gambar layar dan input mouse/keyboard lewat situ, mikir “nanti tinggal tambahin TLS.” Untungnya saya sempet stop dan mikir ulang sebelum ini sempet dipakai beneran, karena begitu saya baca-baca lebih dalam soal gimana tool remote desktop yang udah established (kayak yang biasa dipake buat remote support) di-desain, saya sadar security itu harus jadi bagian dari arsitektur dari awal, bukan layer yang ditempel belakangan.

Enkripsi koneksi

Semua data yang lewat — gambar layar maupun input keyboard/mouse — harus terenkripsi end-to-end. Saya pakai TLS buat channel utama koneksinya, plus nambahin layer encryption khusus buat payload session itu sendiri, jadi seandainya ada satu layer yang somehow kebobol, nggak otomatis semua data ikut kebuka. Ini terdengar berlebihan buat proyek internal kecil, tapi begitu saya bayangin skenario terburuknya — orang asing bisa liat dan kontrol layar komputer kerja klien — ongkos ekstra buat implement double-layer ini kerasa kecil banget dibanding risikonya.

Autentikasi dan otorisasi

Password doang jelas nggak cukup. Saya tambahin token-based auth dengan expiry pendek (bukan token yang hidup selamanya begitu login sekali), dan yang paling penting: setiap sesi remote desktop butuh approval eksplisit dari sisi yang di-remote — nggak ada connect otomatis meskipun kredensialnya bener. Ini keputusan yang sempet didebat sama tim klien karena “kurang praktis” buat kasus urgent, tapi saya keukeuh karena tanpa approval eksplisit, siapa pun yang somehow dapet kredensial bisa connect diam-diam tanpa pemilik komputer sadar sama sekali.

Session handling

Sesi yang idle harus auto-terminate — saya set timeout beberapa menit tanpa aktivitas. Saya juga log setiap sesi: siapa connect, kapan, berapa lama, dari IP mana. Ini bukan cuma buat debugging kalau ada masalah, tapi jadi audit trail yang penting banget kalau tools ini dipakai di lingkungan yang punya kewajiban compliance — dan buat client saya waktu itu, mereka emang butuh log ini buat internal audit tahunan mereka.

Least privilege

Remote desktop tool nggak perlu akses ke seluruh sistem file atau proses di komputer yang di-remote. Saya batasi scope akses-nya sesuai kebutuhan spesifik use case — kalau tujuannya cuma buat troubleshooting UI aplikasi tertentu, tool-nya nggak perlu punya akses buat baca file sensitif di luar itu.

Pelajaran terbesarnya, yang baru beneran kerasa setelah proyek ini selesai: security itu bukan fitur tambahan yang ditempel belakangan setelah “fitur utamanya jalan dulu.” Draft pertama saya yang naif itu kalau saya lanjutin tanpa mikir ulang, ngerombak arsitekturnya belakangan bakal jauh lebih mahal dan lebih ribet daripada mikirin ini dari hari pertama — dan itu belum ngitung risiko kalau versi naif itu sempet ke-deploy duluan.