Judul Tugas Akhir

Implementasi Mekanisme Least Privilege dan Just-in-Time Access pada Layer Kontrol Akses Pengguna Internal dalam Prototipe Sistem Dompet Digital

Implementasi kontrol akses berlapis pada backend untuk membatasi lingkup akses pengguna internal melalui assignment ticket dan membatasi fitur serta durasi akses sensitif melalui session Just-in-Time.

Ringkasan penelitian

Masalah, pendekatan, dan hasil dalam satu alur baca

Bagian ini sengaja dibuat singkat agar pembaca memahami posisi penelitian sebelum melihat detail teknis.

Masalah

01

Akses internal dapat sah, tetapi tetap terlalu luas.

RBAC memisahkan area berdasarkan role, namun belum otomatis membatasi data sesuai tugas dan durasi penggunaan fitur sensitif.

Pendekatan

02

RBAC diperkuat dengan pembatas konteks dan waktu.

Least Privilege membatasi Customer Support berdasarkan assignment ticket. JIT membuka fitur sensitif melalui session sementara yang spesifik.

Hasil

03

Kontrol berlapis berjalan sesuai rancangan prototipe.

Seluruh 19 skenario menghasilkan keputusan terima atau tolak sesuai hasil yang diharapkan pada pengujian backend.

Metode

Penelitian terapan berbasis prototipe dengan scenario-based black-box testing. Evaluasi dilakukan melalui respons API, perubahan database, serta audit log dan terminal log sebagai bukti pendukung.

Klaim yang tepat

Kombinasi RBAC, Least Privilege, dan Just-in-Time Access berhasil membatasi lingkup serta durasi akses sesuai rancangan dalam lingkungan prototipe.

Mekanisme kontrol akses

Tiga lapisan, tiga pertanyaan yang berbeda

Setiap lapisan memiliki tanggung jawab sendiri dan seluruh keputusan utama ditegakkan pada backend.

RBAC

01

Siapa boleh masuk?

Memisahkan endpoint User, Customer Support, dan Administrator berdasarkan role pada JWT.

Least Privilege

02

Ticket mana boleh diakses?

Memeriksa assigned_cs_id dan konteks ticket agar CS tidak memperoleh akses global ke seluruh pengguna.

Just-in-Time Access

03

Fitur apa dan sampai kapan?

Mengikat session pada CS, ticket, feature, status aktif, dan expired_at sebelum fitur sensitif dijalankan.

Alur operasional

Ticket menjadi konteks utama setiap akses sensitif.

JIT menggunakan contextual auto-approval berdasarkan kondisi backend, bukan persetujuan manual Administrator.

  1. 01User membuat ticket bantuan.
  2. 02CS melakukan claim dan menjadi penanggung jawab ticket.
  3. 03Backend memvalidasi role, assignment, serta status ticket.
  4. 04CS meminta JIT untuk feature sensitif tertentu.
  5. 05Session digunakan satu kali, lalu tidak dapat dipakai kembali.

Hasil pengujian

19 skenario memverifikasi kondisi diterima dan ditolak

Nilai 19/19 berarti hasil aktual sesuai dengan hasil yang dirancang, bukan skor keamanan absolut.

RBAC

Akses sesuai role diterima dan akses lintas role ditolak.

7/7

Least Privilege

Claim serta detail ticket dibatasi berdasarkan assignment CS.

5/5

Just-in-Time Access

Session, feature, konteks ticket, dan waktu divalidasi sebelum eksekusi.

7/7

Bukti yang diamati

Respons dan status HTTP, perubahan state database, data pada tabel jit_sessions, serta audit log dan terminal log.

Interpretasi

Bukti penting bukan hanya request yang berhasil, tetapi juga penolakan lintas role, ticket milik CS lain, session expired, feature mismatch, dan konteks ticket yang tidak valid.

Bukti visual

Diagram utama untuk mempercepat pemahaman

Klik gambar untuk memperbesar. Penjelasan dibuat satu kalimat agar halaman tetap ringan.

Sebelum penguatan Least Privilege

RBAC dasar masih berpotensi memberi lingkup akses yang terlalu luas.

Setelah penguatan Least Privilege

Akses dipersempit ke ticket yang benar-benar ditugaskan kepada CS.

Alur validasi Just-in-Time Access

Fitur sensitif hanya dijalankan setelah session dan konteks dinyatakan valid.

Kontribusi penelitian

Membawa LP dan JIT ke backend application access control layer.

Penelitian memodelkan kontrol akses internal secara terbuka melalui kombinasi role, assignment ticket, status ticket, feature sensitif, session sementara, dan log. Kontribusinya bersifat implementatif dan akademik, bukan penciptaan algoritma baru.

Batas klaim

  • Prototipe bukan sistem dompet digital komersial lengkap dan tidak mencakup integrasi pembayaran nyata.
  • Evaluasi berfokus pada backend enforcement, bukan keamanan jaringan, server, atau deployment production.
  • Hasil 19/19 menunjukkan kesesuaian implementasi dengan rancangan, bukan keamanan absolut.

Repository dan lampiran

Source code dan bukti penelitian

Backend, frontend, dan dokumen pendukung dipisahkan agar implementasi serta bukti pengujian mudah ditinjau.

Nama
Muhammad Syukur
NIM
220705058
Program Studi
Teknologi Informasi
Institusi
UIN Ar-Raniry Banda Aceh
Pembimbing I
Ghufran Ibnu Yasa, M.T.
Pembimbing II
Mulkan Fadhli, S.T., M.T.