Kamu Siapa?!

Seorang figur berhasil verifikasi identitas di Gate A, lalu berjalan dan memakai kredensial yang sama untuk masuk ke Gate B yang jauh lebih terbatas, gerbang kedua tetap terbuka dengan indikator peringatan merah alih alih menolak akses.

Bayangkan begini. Tim HR minta dibikinin endpoint baru buat portal internal, urusannya reset password sama lihat data pribadi karyawan. Deadline-nya minggu ini, karena User Acceptance Test udah dijadwalin lusa. Kamu buka editor, pasang middleware yang cek dua hal: token valid, dan role-nya “admin”. Selesai. Testing lolos, soalnya yang nyoba pakai akun admin HR biasa. Deploy.

Dua bulan kemudian, ada laporan aneh. Admin HR di salah satu cabang kecil, yang harusnya cuma ngurus data karyawan di cabangnya sendiri, ternyata bisa reset password direksi pusat. Bisa lihat data pribadi mereka juga. Bukan karena dia hacking apa-apa. Dia cuma login normal, terus buka endpoint yang sama seperti biasa dia pakai. Sistemnya nggak pernah cek satu hal: admin ini sebenarnya boleh akses data siapa aja.

Ini kelalaian yang gampang banget kelewat, karena secara teknis nggak ada yang salah. Token divalidasi. Role dicek. Semua best practice authentication yang biasa diajarin, udah dijalanin. Masalahnya, authentication dan authorization itu dua concern yang beda, dan kelalaian paling umum adalah menganggap kalau authentication sudah selesai, urusan keamanan ikut selesai.

Kalau ini kedengarannya kayak masalah kecil, coba skala-in ke ukuran perusahaan sebesar Twitter.

Juli 2020, akun-akun figur publik di Twitter, termasuk Barack Obama, Elon Musk, Bill Gates, sampai akun resmi Apple dan Uber, kompak nge-tweet ajakan scam bitcoin. Investigasi yang berjalan setelahnya nemuin akar masalahnya bukan di enkripsi yang jebol atau algoritma yang lemah. Attacker melakukan vishing, semacam social engineering lewat telepon, ke beberapa karyawan Twitter buat dapetin kredensial ke tool administratif internal. Begitu punya akses itu, mereka bisa lihat detail akun dan ganti email yang terasosiasi ke akun manapun, termasuk akun akun paling high profile di platform itu.

Yang bikin ini relevan buat kita: laporan investigasi dari New York State Department of Financial Services (NYDFS) soal insiden ini menyoroti bahwa terlalu banyak karyawan yang punya akses ke tool internal tersebut, tanpa lapisan verifikasi tambahan berdasarkan seberapa sensitif akun yang mau diakses. Begitu identitas karyawan itu terverifikasi, entah sah lewat kredensial asli atau curian, tool-nya memperlakukan mereka seolah berhak atas akun siapapun.

Persis pola yang sama kayak endpoint HR tadi. Bedanya cuma skala dan taruhannya.

Sumber: laporan investigasi New York State Department of Financial Services (NYDFS), 2020.

Ini yang bikin banyak developer terjebak di dua ekstrem. Ekstrem pertama, skip aja authorization granular karena dianggap overengineering, toh nanti bisa ditambah kalau emang kebutuhannya muncul. Ekstrem kedua, kebalikannya, bangun sistem permission yang rumit dari awal padahal kebutuhan sebenarnya sederhana. Keduanya sama-sama salah fokus. Zero trust tidak minta kamu bangun sistem yang canggih dari hari pertama. Dia cuma minta kamu tidak pernah berasumsi ada tier yang otomatis dipercaya penuh, termasuk role setinggi apapun.

Bayangin ada dokumen negara yang cuma boleh diakses presiden. Bukan menteri, bukan sekretaris kabinet, bukan siapapun dengan title setinggi apapun selain presiden itu sendiri. Superadmin di sistem kamu juga begitu. Punya role tertinggi bukan berarti otomatis berhak atas semua resource. Kalau ada data atau aksi yang scope-nya seharusnya sempit, role setinggi apapun tetap harus melewati pengecekan itu.

Broken Access Control, kategori kelalaian yang mencakup ini, sudah beberapa periode berturut turut menempati peringkat satu di OWASP Top 10. Bukan kebetulan. NIST juga punya definisi formal soal zero trust architecture di SP 800 207, salah satu prinsip intinya adalah setiap request harus dievaluasi otorisasinya secara eksplisit, terlepas dari posisi jaringan atau identitas yang sebelumnya sudah terverifikasi.

Sebelum menulis endpoint berikutnya, coba jawab dulu pertanyaan pertanyaan ini.

Siapa aja yang seharusnya berhak akses endpoint ini? Kalau jawabannya cuma “yang penting sudah login”, itu tanda kamu belum selesai mikir.
Apakah ada scope spesifik? Misalnya cuma pemilik resource itu sendiri, atau cuma untuk divisi tertentu. Kamu yakin sebuah role boleh akses semuanya ?!
Kalau endpoint ini butuh role tinggi macam admin atau superadmin, apakah tetap ada granularitas tambahan, atau role itu otomatis dianggap boleh semua? Hati-hati klo mau bikin role Super Dewa bisa apapun!!!
Kalau jawaban dari tiga pertanyaan di atas masih belum jelas, itu artinya endpoint ini belum siap dibangun, apapun urgensi deadline-nya.

PRINSIP UTAMA:

Identitas dan Hak Akses itu TIDAK SAMA, tapi Saling Melengkapi