Least Privilege & Just-in-Time Access untuk Kontrol Akses Pengguna Internal
Implementasi kontrol akses berlapis pada backend untuk membatasi lingkup data pengguna internal melalui tiket tugas dan membatasi durasi operasi sensitif melalui sesi Just-in-Time.
The Security Problem
In many digital wallet and financial backend systems, internal employee permissions are overly broad. Conventional Role-Based Access Control (RBAC) separates duties (e.g. "Customer Support" vs. "Finance"), but once assigned a role, staff often retain persistent ability to query any customer account or execute high-risk operations across the entire database at all hours, creating insider threat risks and credential-hijacking vulnerabilities.
Two-Tiered Control Approach
The research designed and implemented a dual-layer access enforcement architecture on a Go backend:
1. Ticket-Scoped Least Privilege
Customer Support personnel cannot arbitrarily query arbitrary user balances or transaction histories. Read permissions are restricted strictly to the user associated with an actively assigned, in-progress support ticket.
2. Ephemeral Just-in-Time (JIT) Sessions
High-risk operations (such as manual balance reconciliations or account unfreezing) cannot be triggered from regular session tokens. The operator must request a JIT elevation token, valid for a strictly bounded window (TTL), backed by automated audit trail capture.
Empirical Test Results
The prototype backend was evaluated across 19 concrete security scenarios designed to stress authorization boundaries:
- Verified CS access denial to unassigned customer accounts (Out-of-scope block).
- Verified automated session revocation upon ticket closure or reassignment.
- Verified strict expiration and rejection of expired JIT elevation tokens.
- 100% concordance between expected and actual allow/deny outcomes across all 19 test vectors.