Mengapa Melindungi Kata Sandi Jika Kita Bisa Tidak Menggunakannya?

Masalah yang Sudah Kita Anggap Wajar

Hampir setiap aplikasi web memiliki panel administrasi. Dan panel administrasi biasanya memiliki alamat masuk, formulir autentikasi, nama pengguna, dan kata sandi.

Kita sudah begitu terbiasa dengan susunan ini hingga hampir tidak pernah lagi bertanya: apakah semuanya memang harus bekerja seperti ini?

Jika Anda hanya memiliki satu situs, masalahnya mungkin tidak terasa penting. Buat kata sandi yang kuat, aktifkan autentikasi dua faktor, atur pembatasan percobaan masuk—lalu lanjutkan pekerjaan.

Namun, apa yang terjadi ketika jumlah proyek bertambah menjadi sepuluh, dua puluh, atau tiga puluh?

Dalam kasus saya, yang dimaksud adalah ekosistem DigiMeld, yang terdiri dari lebih dari tiga puluh proyek perangkat lunak mandiri. Masing-masing memiliki arsitektur, logika server, dan antarmuka administrasi sendiri.

Artinya, setiap proyek membutuhkan mekanisme akses administratif.

Sekian lama saya menggunakan pendekatan yang cukup lazim: kredensial administrasi terpisah, kata sandi yang kuat, dan penyimpanannya di browser.

Cara itu berhasil.

Namun, pada suatu titik saya mulai berpikir: mengapa saya harus menyimpan begitu banyak kata sandi administratif? Mengapa saya harus melindungi bukan hanya server, tetapi juga sarana untuk mendapatkan akses ke server tersebut?

Dan mungkinkah kebutuhan itu dihilangkan?

Kata Sandi yang Kuat Tidak Menghilangkan Masalahnya

Sarana modern memungkinkan kita membuat kata sandi dengan entropi yang sangat tinggi. Kata sandi acak yang panjang dan dibuat dengan benar hampir mustahil ditebak dengan metode brute force.

Namun, sekuat apa pun kata sandi itu, kita tetap harus menyimpannya di suatu tempat, lalu menggunakannya.

Kita bisa menggunakan pengelola kata sandi, kunci perangkat keras, autentikasi multifaktor, dan pembatasan tambahan. Semua itu memang meningkatkan keamanan.

Namun, arsitektur dasarnya tetap sama: ada antarmuka tertentu yang digunakan pengguna untuk mengirimkan kredensialnya.

Antarmuka itu bisa menerima permintaan. Bisa dipindai. Bisa menjadi sasaran serangan otomatis.

Kita bisa menyembunyikan alamat panel administrasi, mengganti jalur standar dengan rangkaian karakter acak yang panjang, atau membatasi akses berdasarkan IP.

Namun, itu memunculkan pertanyaan baru: di mana alamat tersebut disimpan dan bagaimana cara menggunakannya?

Dan yang terpenting—mengapa harus mempertahankan titik masuk yang selalu tersedia, jika akses administratif hanya dibutuhkan pada saat-saat tertentu?

Saya sampai pada gagasan yang kemudian menjadi dasar solusi saya:

Mungkin yang perlu dilindungi bukanlah akses masuk permanen, melainkan hak untuk mendapatkan akses sementara.

Bagaimana Jika Halaman Masuk yang Biasa Itu Tidak Ada Sama Sekali?

Saya memutuskan untuk meninggalkan model autentikasi administratif tradisional dalam proyek-proyek saya.

Bukan sekadar menyembunyikan formulir masuk.

Bukan mengganti alamatnya.

Bukan mengganti kata sandi dengan kata sandi yang lebih rumit.

Melainkan menghilangkan kebutuhan akan akses masuk berbasis kata sandi yang selalu tersedia.

Tentu saja, antarmuka administrasi tidak menghilang. Antarmuka tersebut tetap diperlukan untuk mengelola aplikasi.

Yang berubah adalah cara untuk mendapatkan akses ke sana.

Sekarang, untuk masuk ke panel administrasi proyek-proyek yang terhubung, saya tidak perlu memasukkan nama pengguna dan kata sandi yang tersimpan.

Sebagai gantinya, saya menggunakan sistem identifikasi dan manajemen akses buatan saya sendiri, MeldID.

Gagasannya cukup sederhana: akses administratif hanya diberikan saat benar-benar dibutuhkan, kepada pengguna tertentu, dan untuk proyek tertentu.

Selain itu, memiliki akun saja tidak otomatis berarti seseorang berhak membuka panel administrasi.

Hak tersebut harus diberikan secara terpisah.

Akses yang Belum Ada Semenit Sebelumnya

Inilah, barangkali, bagian paling menarik dari keseluruhan konsep ini.

Dalam model tradisional, administrator selalu memiliki sarana untuk masuk. Ia bisa menggunakannya hari ini, besok, atau sebulan lagi, selama sarana tersebut masih berlaku.

Saya memutuskan untuk mengubah prinsip ini.

Alih-alih menggunakan kredensial administratif permanen, sistem ini menggunakan kemampuan sementara untuk memulai proses masuk.

Kemampuan tersebut dibuat atas permintaan melalui perangkat seluler tepercaya, memiliki komponen acak yang kuat secara kriptografis, dan berlaku untuk waktu terbatas.

Namun, memiliki tautan sementara itu saja tidak otomatis memberikan akses.

Ini hal yang sangat mendasar.

Misalnya, seseorang memperoleh tautan itu dengan cara tertentu. Dalam sistem biasa yang hanya mengandalkan kerahasiaan alamat, kebocoran semacam itu bisa menjadi masalah serius.

Dalam model saya, tautan itu hanya memungkinkan proses konfirmasi dimulai.

Untuk melanjutkannya, diperlukan persetujuan terpisah melalui perangkat seluler tepercaya yang menggunakan MeldID.

Tanpa konfirmasi yang sesuai, sesi administratif tidak akan dibuat.

Itulah sebabnya saya memandang tautan sementara bukan sebagai pengganti kata sandi, melainkan sebagai salah satu bagian dari prosedur pemberian akses.

Mengetahui ke mana harus mengajukan permintaan dan memiliki hak untuk masuk adalah dua hal yang sama sekali berbeda.

Telepon Menjadi Sarana untuk Mengelola Akses

Dalam model ini, perangkat seluler memiliki peran yang jauh lebih penting daripada sekadar pembuat kode sekali pakai.

Perangkat tersebut digunakan untuk mengonfirmasi tindakan yang berkaitan dengan akses administratif.

Saat saya ingin membuka panel administrasi, sistem meminta konfirmasi melalui MeldID.

Saya melihat permintaan terkait di perangkat tepercaya dan mengonfirmasi tindakan tersebut.

Baru setelah pemeriksaan berhasil, sistem mengizinkan proses masuk dilanjutkan.

Konfirmasi ini terkait dengan tindakan tertentu, bukan sekadar fakta bahwa ponsel telah dibuka kuncinya.

Biometrik pada perangkat seluler memverifikasi pengguna secara lokal, sedangkan sisi server memeriksa konfirmasi kriptografis dari perangkat yang terdaftar.

Pendekatan ini memungkinkan saya untuk tidak hanya mengandalkan kata sandi atau pemberitahuan bahwa pengguna konon telah mengonfirmasi proses masuk.

Keunggulan lainnya adalah perangkat tepercaya dapat dikelola.

Jika suatu perangkat tidak lagi boleh digunakan untuk mengonfirmasi akses, status tepercayanya dapat dicabut.

Setelah itu, perangkat tersebut tidak lagi menjadi sarana autentikasi yang berlaku untuk operasi terkait.

Satu Sistem—Banyak Proyek Mandiri

Saat mulai mengembangkan mekanisme ini, salah satu tugas utama saya adalah mempertahankan kemandirian setiap proyek.

Saya tidak ingin menyatukan semua panel administrasi ke dalam satu aplikasi besar.

Setiap layanan DigiMeld harus tetap mengelola logika, pengaturan, pengguna, dan datanya sendiri.

Karena itu, saya memisahkan kedua tugas tersebut.

MeldID bertanggung jawab atas identifikasi dan pemberian izin administratif.

Sementara itu, setiap proyek bertanggung jawab atas fungsi administrasinya sendiri dan pemeriksaan kewenangan yang berlaku.

Hasilnya adalah model manajemen akses terpusat tanpa perlu memusatkan aplikasinya sendiri.

Selain itu, hak akses diberikan secara terpisah.

Administrator suatu proyek tidak otomatis mendapatkan akses ke proyek lain hanya karena memiliki akun MeldID.

Untuk setiap area administrasi, kita dapat menentukan kelompok pengguna yang diizinkan sendiri.

Sementara itu, hak pengguna biasa dan kewenangan administratif tetap terpisah.

Hal ini sangat praktis untuk ekosistem yang terdiri dari puluhan layanan.

Mengapa Saya Lebih Menyukai Akses Sementara daripada Akses Permanen

Ada satu prinsip lain yang sengaja saya terapkan dalam sistem ini.

Akses administratif tidak seharusnya berlaku tanpa batas waktu.

Izin berlaku untuk waktu terbatas dan berakhir, terlepas dari apakah pengguna masih bekerja di browser atau tidak.

Untuk melanjutkan pekerjaan setelah masa berlaku berakhir, diperlukan prosedur konfirmasi baru.

Dengan demikian, autentikasi yang telah dilakukan sekali tidak berubah menjadi hak yang terus berlaku.

Namun, pembatasan waktu saja tidak cukup.

Kemampuan untuk menghentikan akses yang sudah diberikan sebelum waktunya juga penting.

Karena itu, MeldID menyediakan pencabutan izin administratif secara terpusat.

Saat izin dicabut, proyek-proyek yang terhubung menerima pemberitahuan terkait dan membatalkan sesi administratif yang terkait.

Dengan demikian, pengelolaan akses tidak berakhir saat pengguna berhasil masuk.

Bagi saya, kemampuan untuk mencabut kewenangan sama pentingnya dengan kemampuan untuk memberikannya.

Selain itu, sistem terdistribusi harus memperhitungkan keterlambatan pengiriman pemberitahuan, ketidaktersediaan sementara sejumlah komponen, dan berbagai kondisi operasional lainnya. Batas masa berlaku sesi menjadi perlindungan tambahan.

Apa yang Berubah dalam Pekerjaan Sehari-hari?

Yang paling utama, saya tidak lagi perlu terus-menerus menggunakan kata sandi administratif yang tersimpan.

Saya tidak perlu lagi menyimpan sekumpulan kredensial di browser untuk masuk ke setiap panel administrasi yang terhubung.

Sebagai gantinya, saya mengelola izin melalui satu mekanisme.

Memilih proyek yang diperlukan, mengonfirmasi akses, lalu bekerja.

Saat akses administratif tidak lagi dibutuhkan, akses tersebut bisa dicabut.

Yang sangat praktis adalah ketika proyek baru ditambahkan, saya tidak perlu merancang ulang seluruh sistem autentikasi administratif.

Cukup hubungkan proyek tersebut ke model yang sudah ada dan tentukan izin yang diperlukan.

Tentu saja, ini bukan berarti semua risiko keamanan telah hilang.

Izin sementara, perangkat tepercaya, sesi server, dan infrastruktur pusat juga perlu dilindungi.

Namun, saya tidak perlu lagi menyelesaikan masalah pengelolaan kata sandi administratif yang sama secara terpisah untuk setiap aplikasi.

Dan itulah salah satu tujuan awal saya.

Bukankah Teknologi Seperti Ini Sudah Ada?

Tentu saja, sudah ada.

Autentikasi tanpa kata sandi, manajemen akses istimewa, izin sementara, dan konfirmasi melalui perangkat tepercaya sudah lama dikenal dalam industri keamanan informasi.

Pendekatan seperti ini ditemukan dalam sistem Identity and Access Management, Privileged Access Management, dan konsep Zero Trust.

Saya tidak mengklaim telah menemukan prinsip-prinsip tersebut.

Tujuan saya berbeda.

Saya perlu membuat sistem terintegrasi sendiri yang mengatasi masalah spesifik pada infrastruktur DigiMeld dan memungkinkan pengelolaan akses administratif ke banyak proyek mandiri.

Hasilnya, saya menggabungkan beberapa pendekatan yang sudah dikenal ke dalam satu arsitektur yang sesuai dengan kebutuhan saya.

Dan saya percaya bahwa nilai pekerjaan rekayasa tidak selalu terletak pada penciptaan teknologi yang benar-benar baru.

Terkadang, nilainya terletak pada kemampuan merumuskan masalah dengan tepat dan menemukan solusi yang sesuai.

MeldID Bukan Hanya untuk Panel Administrasi

Ada satu hal yang perlu dijelaskan secara terpisah.

MeldID tidak dibuat hanya sebagai sarana untuk akses administratif saya sendiri.

MeldID juga menyediakan SDK bagi pengembang untuk mengintegrasikan mekanisme identifikasi dan konfirmasi masuk ke aplikasi mereka sendiri.

SDK ini tersedia secara gratis.

Misalnya, pengembang pihak ketiga dapat menggunakan MeldID sebagai lapisan tambahan untuk mengonfirmasi autentikasi pengguna.

Meskipun aplikasi tersebut tetap menggunakan metode masuk tradisional dengan nama pengguna dan kata sandi, memasukkan data tersebut dengan benar mungkin belum cukup untuk menyelesaikan autentikasi.

Pengguna akan menerima permintaan di perangkat seluler tepercaya, lalu dapat mengonfirmasi atau menolak upaya masuk tersebut.

Dengan demikian, risiko akses tanpa izin dapat dikurangi jika kredensial pengguna telah disusupi.

Penting untuk membedakan kemampuan MeldID yang tersedia untuk umum ini dari model akses administratif untuk proyek DigiMeld yang saya kembangkan.

Keduanya menggunakan prinsip kepercayaan dan konfirmasi tindakan yang sama, tetapi menyelesaikan tugas yang berbeda.

Keamanan Bukan Hanya Soal Melindungi Sesuatu yang Sudah Ada

Mengerjakan sistem ini membuat saya memandang mekanisme autentikasi yang biasa digunakan dengan cara berbeda.

Kita sering kali berusaha melindungi sesuatu yang ada karena alasan historis.

Kita menambahkan pemeriksaan baru, pembatasan, kata sandi tambahan, dan lapisan perlindungan.

Terkadang, hal itu memang diperlukan.

Namun, terkadang lebih baik mengajukan pertanyaan lain:

Apakah mekanisme yang kita lindungi itu memang harus tetap ada dalam bentuknya yang sekarang?

Dalam kasus saya, jawabannya tidak.

Saya tidak membutuhkan formulir masuk administratif yang selalu tersedia.

Yang saya butuhkan adalah kemampuan untuk memperoleh kewenangan administratif dengan aman, tepat saat diperlukan.

Itu adalah dua hal yang berbeda.

Peralihan dari yang pertama ke yang kedua tidak hanya mengubah arsitektur teknis, tetapi juga pekerjaan sehari-hari dalam mengelola proyek.

Bukan Titik Akhir, Melainkan Arah yang Dipilih

Saat ini, arsitektur ini sudah beroperasi di sebagian besar ekosistem DigiMeld.

Proyek-proyek yang tersisa secara bertahap beralih ke model akses administratif yang baru.

Saya melakukan migrasi secara bertahap, memeriksa cara kerja setiap aplikasi, dan setelah peralihan selesai, saya berencana mengaudit seluruh sistem sekali lagi.

Beberapa elemen antarmuka dan aturan pengelolaan sesi masih mungkin berubah.

Namun, gagasan utamanya sudah jelas.

Saya tidak ingin kembali ke model yang mengharuskan saya menyimpan dan menggunakan puluhan kata sandi administratif secara terus-menerus untuk mengelola puluhan proyek sendiri.

Namun, saya tidak menganggap implementasi saya sebagai solusi universal untuk semua orang.

Setiap organisasi memiliki kebutuhan, infrastruktur, model ancaman, dan metode administrasi yang berbeda.

Hal yang praktis dan tepat untuk ekosistem DigiMeld belum tentu menjadi pilihan terbaik bagi pengembang lain.

Namun, prinsip pemberian kewenangan sementara patut dipertimbangkan.

Sebagai Penutup

Saya memutuskan untuk membagikan pengalaman ini bukan karena menganggap diri saya penemu metode autentikasi baru.

Juga bukan karena ingin menggambarkan sistem lain sebagai sesuatu yang sepenuhnya aman.

Keamanan mutlak tidak ada.

Menurut saya, cara merumuskan pertanyaannya sendiri menarik.

Alih-alih terus-menerus melindungi akses administratif permanen, kita bisa mempertimbangkan kembali apakah akses itu perlu ada.

Alih-alih menyimpan banyak kata sandi—gunakan izin sementara.

Alih-alih memberikan kepercayaan otomatis setelah autentikasi pertama—konfirmasikan pemberian kewenangan tertentu.

Alih-alih menunggu sesi berakhir—sediakan kemampuan untuk mencabut akses secara terpusat.

Dan, terakhir, alih-alih menggunakan mekanisme masuk yang terpisah di setiap proyek—bangun satu sistem untuk mengelola izin administratif tanpa menghilangkan kemandirian aplikasi.

Saya tidak mengklaim pendekatan ini menghilangkan kemungkinan terjadinya kompromi.

Pendekatan ini hanya mengalihkan fokus dari perlindungan kredensial yang selalu ada ke pemberian dan pencabutan kewenangan yang terkendali.

Mungkin, terkadang cara paling efektif untuk mengurangi permukaan serangan bukanlah menambahkan lapisan perlindungan baru, melainkan meniadakan sesuatu yang sebenarnya tidak dibutuhkan agar sistem dapat berfungsi.

Pemikiran inilah yang menjadi awal kisah MeldID Admin Gateway bagi saya.