Mengapa melindungi kata laluan jika kita boleh tidak menggunakannya?

Masalah yang sudah biasa kita anggap sebagai perkara biasa

Hampir setiap aplikasi web mempunyai panel pentadbiran. Dan lazimnya, panel pentadbiran mempunyai alamat log masuk, borang pengesahan, nama pengguna dan kata laluan.

Kita sudah begitu terbiasa dengan struktur ini sehingga hampir tidak lagi bertanya: adakah semuanya memang perlu berfungsi seperti ini?

Apabila anda hanya mempunyai satu laman web, masalah ini tidak kelihatan besar. Cipta kata laluan yang kukuh, aktifkan pengesahan dua faktor, tetapkan had percubaan log masuk — kemudian teruskan kerja.

Namun, apa yang berlaku apabila jumlah projek meningkat menjadi sepuluh, dua puluh atau tiga puluh?

Dalam kes saya, ini melibatkan ekosistem DigiMeld yang menggabungkan lebih daripada tiga puluh projek perisian yang berdiri sendiri. Setiap satunya mempunyai seni bina, logik pelayan dan antara muka pentadbir tersendiri.

Oleh itu, setiap projek memerlukan mekanisme akses pentadbiran.

Untuk sekian lama, saya menggunakan pendekatan yang agak biasa: kelayakan pentadbir yang berasingan, kata laluan yang kukuh dan penyimpanannya dalam pelayar.

Pendekatan ini berfungsi.

Namun, pada suatu ketika saya mula berfikir: mengapa saya perlu menyimpan begitu banyak kata laluan pentadbir? Mengapa saya perlu melindungi bukan sahaja pelayan, tetapi juga alat untuk mendapatkan akses kepadanya?

Dan mungkinkah saya tidak perlu berbuat demikian?

Saya mendapat satu idea yang kemudiannya menjadi asas kepada penyelesaian saya:

Mungkin yang patut dilindungi bukanlah pintu masuk yang sentiasa tersedia, tetapi hak untuk mendapatkan akses buat sementara waktu.

Bagaimana jika halaman log masuk yang biasa itu langsung tidak wujud?

Saya memutuskan untuk meninggalkan model pengesahan pentadbiran tradisional dalam projek-projek saya.

Bukan sekadar menyembunyikan borang log masuk.

Bukan menukar alamatnya.

Bukan menggantikan kata laluan dengan kata laluan yang lebih rumit.

Sebaliknya, saya menghapuskan keperluan untuk mempunyai pintu masuk berasaskan kata laluan yang sentiasa tersedia.

Sudah tentu, antara muka pentadbiran tidak hilang. Ia masih diperlukan untuk mengurus aplikasi.

Yang berubah ialah cara akses kepadanya diperoleh.

Kini, untuk log masuk ke panel pentadbiran projek yang disambungkan, saya tidak perlu memasukkan nama pengguna dan kata laluan yang disimpan.

Sebaliknya, saya menggunakan sistem pengenalan dan pengurusan akses saya sendiri, MeldID.

Konsepnya agak mudah: akses pentadbiran hanya diberikan apabila benar-benar diperlukan, kepada pengguna tertentu dan untuk projek tertentu.

Hakikat bahawa seseorang mempunyai akaun tidak bermakna mereka berhak membuka panel pentadbiran.

Hak tersebut perlu diberikan secara berasingan.

Akses yang belum wujud seminit yang lalu

Ini mungkin bahagian paling menarik dalam keseluruhan konsep ini.

Dalam model tradisional, pentadbir sentiasa mempunyai cara untuk log masuk. Mereka boleh menggunakannya hari ini, esok atau sebulan lagi, selagi cara tersebut masih sah.

Saya memutuskan untuk mengubah prinsip ini.

Daripada kelayakan pentadbir yang kekal, sistem ini menggunakan keupayaan sementara untuk memulakan proses log masuk.

Keupayaan ini diwujudkan atas permintaan melalui peranti mudah alih yang dipercayai, mengandungi komponen rawak yang kukuh dari segi kriptografi dan mempunyai tempoh sah yang terhad.

Namun, memiliki pautan sementara itu sahaja tidak bermakna seseorang mendapat akses.

Ini perkara yang asas.

Katakan seseorang mendapat pautan itu dengan apa jua cara. Dalam sistem biasa yang bergantung sepenuhnya pada kerahsiaan alamat, kebocoran seperti itu boleh menjadi masalah serius.

Dalam model saya, pautan itu hanya membolehkan proses pengesahan dimulakan.

Untuk meneruskan, kebenaran berasingan melalui peranti mudah alih MeldID yang dipercayai diperlukan.

Tanpa pengesahan yang sepadan, sesi pentadbiran tidak akan diwujudkan.

Itulah sebabnya saya melihat pautan sementara bukan sebagai pengganti kata laluan, tetapi sebagai salah satu elemen dalam proses pemberian akses.

Mengetahui tempat untuk meminta akses dan mempunyai hak untuk log masuk ialah dua perkara yang sama sekali berbeza.

Telefon menjadi alat untuk mengurus akses

Dalam model ini, peranti mudah alih memainkan peranan yang jauh lebih penting daripada sekadar penjana kod sekali guna.

Peranti itu digunakan untuk mengesahkan tindakan yang berkaitan dengan akses pentadbiran.

Apabila saya mahu membuka panel pentadbiran, sistem meminta pengesahan melalui MeldID.

Saya melihat permintaan yang berkenaan pada peranti yang dipercayai dan mengesahkan tindakan itu.

Hanya selepas pemeriksaan berjaya, sistem membenarkan proses log masuk diteruskan.

Pengesahan itu dikaitkan dengan tindakan tertentu, bukan sekadar keadaan telefon yang sudah dibuka kuncinya.

Biometrik mudah alih mengesahkan pengguna secara setempat, manakala pihak pelayan menyemak pengesahan kriptografi daripada peranti yang berdaftar.

Pendekatan ini membolehkan saya tidak bergantung sepenuhnya pada kata laluan atau mesej yang mendakwa pengguna telah mengesahkan log masuk.

Di sini muncul satu lagi kelebihan: peranti yang dipercayai boleh diurus.

Jika sesuatu peranti tidak lagi patut digunakan untuk mengesahkan akses, status dipercayainya boleh ditarik balik.

Selepas itu, peranti tersebut tidak lagi menjadi alat yang sah untuk mengesahkan operasi berkenaan.

Satu sistem — banyak projek yang berdikari

Apabila saya mula membangunkan mekanisme ini, salah satu tugas utama saya ialah mengekalkan kebebasan setiap projek.

Saya tidak mahu menggabungkan semua panel pentadbiran menjadi satu aplikasi besar.

Setiap perkhidmatan DigiMeld harus terus mengurus logik, tetapan, pengguna dan datanya sendiri.

Oleh itu, saya memisahkan dua tugas.

MeldID mengendalikan pengenalan dan pemberian kebenaran pentadbiran.

Projek itu sendiri pula mengendalikan fungsi pentadbirannya serta menyemak kebenaran yang masih berkuat kuasa.

Hasilnya ialah model pengurusan akses berpusat tanpa perlu memusatkan aplikasi itu sendiri.

Selain itu, hak akses diberikan secara berasingan.

Pentadbir satu projek tidak mendapat akses ke projek lain secara automatik hanya kerana mereka mempunyai akaun MeldID.

Bulatan pengguna yang dibenarkan boleh ditentukan secara berasingan untuk setiap bidang pentadbiran.

Pada masa yang sama, hak pengguna biasa dan kuasa pentadbiran diasingkan.

Pendekatan ini ternyata amat mudah untuk ekosistem yang terdiri daripada berpuluh-puluh perkhidmatan.

Mengapa saya lebih menyukai akses sementara berbanding akses kekal

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

Akses pentadbiran tidak sepatutnya kekal tanpa had masa.

Kebenaran itu hanya sah untuk tempoh tertentu dan akan tamat tanpa mengira sama ada pengguna masih menggunakan pelayar atau tidak.

Untuk terus bekerja selepas tempoh itu tamat, proses pengesahan baharu diperlukan.

Ini menghalang pengesahan yang pernah dibuat daripada menjadi hak akses yang sentiasa berkuat kuasa.

Namun, had masa sahaja tidak mencukupi.

Keupayaan untuk menamatkan akses yang telah diberikan lebih awal juga penting.

Oleh itu, MeldID menyediakan fungsi untuk menarik balik kebenaran pentadbiran secara berpusat.

Apabila kebenaran ditarik balik, projek yang disambungkan menerima peristiwa berkaitan dan membatalkan sesi pentadbiran yang terhubung dengannya.

Dengan demikian, pengurusan akses tidak berakhir sebaik sahaja pengguna berjaya log masuk.

Bagi saya, keupayaan untuk menarik balik kuasa sama pentingnya dengan keupayaan untuk memberikannya.

Pada masa yang sama, sistem teragih perlu mengambil kira kelewatan penghantaran peristiwa, ketidaktersediaan sementara sesetengah komponen dan keadaan operasi yang lain. Had tempoh sah sesi berfungsi sebagai satu lagi lapisan perlindungan.

Apakah yang berubah dalam kerja seharian?

Pertama sekali, saya tidak lagi perlu sentiasa merujuk kepada kata laluan pentadbir yang disimpan.

Saya tidak lagi perlu menyimpan satu set kelayakan dalam pelayar untuk log masuk ke setiap panel pentadbiran yang disambungkan.

Sebaliknya, saya mengurus kebenaran melalui satu mekanisme yang sama.

Pilih projek yang diperlukan, sahkan akses dan teruskan kerja.

Apabila akses pentadbiran tidak lagi diperlukan, akses itu boleh ditarik balik.

Yang paling mudah, apabila projek baharu ditambah, saya tidak perlu mereka bentuk semula keseluruhan sistem pengesahan pentadbiran.

Saya hanya perlu menyambungkannya kepada model sedia ada dan menetapkan kebenaran yang diperlukan.

Sudah tentu, ini tidak bermakna semua risiko keselamatan telah hilang.

Kebenaran sementara, peranti yang dipercayai, sesi pelayan dan infrastruktur pusat juga perlu dilindungi.

Namun, saya tidak lagi perlu menyelesaikan masalah pengurusan kata laluan pentadbir yang sama secara berasingan untuk setiap aplikasi.

Dan itulah salah satu matlamat awal saya.

Bukankah teknologi seperti ini sudah wujud?

Sudah tentu wujud.

Pengesahan tanpa kata laluan, pengurusan akses berkeistimewaan, kebenaran sementara dan pengesahan melalui peranti yang dipercayai sudah lama dikenali dalam industri keselamatan maklumat.

Pendekatan sedemikian digunakan dalam sistem Identity and Access Management, Privileged Access Management dan konsep Zero Trust.

Saya tidak mendakwa mencipta prinsip-prinsip ini.

Tugas saya berbeza.

Saya perlu membina sistem bersepadu sendiri yang menyelesaikan masalah khusus infrastruktur DigiMeld dan membolehkan akses pentadbiran kepada banyak projek yang berdiri sendiri diuruskan.

Hasilnya, saya menggabungkan beberapa pendekatan yang sudah dikenali ke dalam satu seni bina yang memenuhi keperluan saya.

Dan saya percaya nilai kerja kejuruteraan tidak semestinya terletak pada penciptaan teknologi yang benar-benar baharu.

Kadang-kadang nilainya terletak pada kebolehan merumuskan masalah dengan tepat dan mencari penyelesaian yang sesuai.

MeldID bukan hanya untuk panel pentadbiran

Di sini ada satu perkara yang perlu dijelaskan secara berasingan.

MeldID bukan dibangunkan semata-mata sebagai alat untuk akses pentadbiran saya sendiri.

MeldID juga menyediakan SDK kepada pembangun untuk menyepadukan mekanisme pengenalan dan pengesahan log masuk ke dalam aplikasi mereka sendiri.

SDK ini juga tersedia secara percuma.

Contohnya, pembangun pihak ketiga boleh menggunakan MeldID sebagai lapisan tambahan untuk mengesahkan log masuk pengguna.

Walaupun aplikasi itu mengekalkan kaedah log masuk tradisional menggunakan nama pengguna dan kata laluan, pemasukan maklumat tersebut dengan betul mungkin tidak mencukupi untuk melengkapkan pengesahan.

Pengguna akan menerima permintaan pada peranti mudah alih yang dipercayai, lalu mengesahkan atau menolak percubaan log masuk itu.

Ini membantu mengurangkan risiko akses tanpa kebenaran sekiranya kelayakan pengguna terjejas.

Penting untuk membezakan keupayaan MeldID yang tersedia kepada umum ini daripada model akses pentadbiran yang saya bangunkan untuk projek DigiMeld.

Kedua-duanya menggunakan prinsip kepercayaan dan pengesahan tindakan yang sama, tetapi menyelesaikan masalah yang berbeza.

Keselamatan bukan sekadar melindungi apa yang sudah wujud

Usaha membangunkan sistem ini mendorong saya melihat mekanisme pengesahan yang biasa digunakan dari sudut yang berbeza.

Kita sering cuba melindungi sesuatu yang wujud atas sebab-sebab sejarah.

Kita menambah pemeriksaan baharu, sekatan, kata laluan tambahan dan lapisan perlindungan.

Kadang-kadang, ini memang perlu.

Namun, ada kalanya lebih baik bertanya soalan yang berbeza:

Adakah mekanisme yang kita lindungi itu benar-benar perlu wujud dalam bentuk yang sama seperti dahulu?

Dalam kes saya, jawapannya tidak.

Saya tidak memerlukan borang log masuk pentadbir yang sentiasa tersedia.

Saya memerlukan cara untuk mendapatkan kuasa pentadbiran dengan selamat tepat pada saat ia diperlukan.

Itu dua tugas yang berbeza.

Dan peralihan daripada tugas pertama kepada tugas kedua mengubah bukan sahaja seni bina teknikal, tetapi juga kerja harian saya dengan projek-projek ini.

Bukan titik penamat, tetapi arah yang telah dipilih

Hari ini, seni bina ini sudah digunakan dalam sebahagian besar ekosistem DigiMeld.

Projek yang selebihnya sedang beralih kepada model akses pentadbiran baharu secara beransur-ansur.

Saya menjalankan migrasi secara berperingkat, menguji setiap aplikasi, dan selepas peralihan selesai, saya merancang untuk menjalankan audit tambahan terhadap keseluruhan sistem.

Sesetengah elemen antara muka dan peraturan pengurusan sesi masih boleh berubah.

Namun, idea utamanya sudah ditetapkan.

Saya tidak mahu kembali kepada model yang memerlukan saya menyimpan dan menggunakan berpuluh-puluh kata laluan pentadbir secara berterusan untuk mengurus berpuluh-puluh projek sendiri.

Pada masa yang sama, saya tidak menganggap pelaksanaan saya sebagai penyelesaian sejagat untuk semua orang.

Organisasi yang berbeza mempunyai keperluan, infrastruktur, model ancaman dan kaedah pentadbiran yang berbeza.

Perkara yang mudah dan sesuai untuk ekosistem DigiMeld tidak semestinya pilihan terbaik bagi pembangun lain.

Namun, prinsip pemberian kuasa sementara wajar diberi perhatian.

Kesimpulannya

Saya memutuskan untuk berkongsi pengalaman ini bukan kerana saya menganggap diri saya pencipta kaedah pengesahan yang baharu.

Dan bukan juga kerana saya mahu menggambarkan satu lagi sistem sebagai benar-benar kebal.

Keselamatan mutlak tidak wujud.

Saya cuma merasakan cara soalan ini dikemukakan itu sendiri menarik.

Daripada terus-menerus melindungi pintu masuk pentadbiran yang sentiasa tersedia, kita boleh menilai semula sama ada pintu itu perlu wujud.

Daripada menyimpan banyak kata laluan, kita boleh menggunakan kebenaran sementara.

Daripada mempercayai pengguna secara automatik selepas pengesahan pertama, kita boleh mengesahkan pemberian kuasa tertentu.

Daripada hanya menunggu sesi tamat, kita boleh menyediakan cara untuk menarik balik akses secara berpusat.

Akhir sekali, daripada menggunakan mekanisme log masuk yang berasingan dalam setiap projek, kita boleh membina satu sistem pengurusan kebenaran pentadbiran sambil mengekalkan kebebasan setiap aplikasi.

Saya tidak mendakwa pendekatan ini menghapuskan kemungkinan pencerobohan.

Pendekatan ini cuma mengalihkan fokus daripada melindungi kelayakan yang sentiasa wujud kepada pemberian dan penamatan kuasa secara terkawal.

Mungkin, kadangkala cara paling berkesan untuk mengurangkan permukaan serangan bukanlah dengan menambah satu lagi mekanisme perlindungan, tetapi dengan meninggalkan sesuatu yang sebenarnya tidak diperlukan oleh sistem untuk berfungsi.

Idea inilah yang menjadi permulaan kisah MeldID Admin Gateway bagi saya.