RBAC vs ABAC untuk alat internal: memilih perizinan yang dapat diskalakan

Mengapa perizinan bisa berantakan di alat internal

Alat internal berada dekat dengan bagian bisnis yang paling sensitif: data pelanggan, pengembalian dana, faktur, catatan payroll, nilai transaksi, dan komentar internal yang privat. Tidak semua orang seharusnya melihat semuanya, dan lebih sedikit lagi yang seharusnya bisa mengubahnya.

Perizinan biasanya dimulai sederhana: “Support bisa melihat tiket,” “Finance bisa menyetujui pengembalian dana,” “Manajer bisa melihat kinerja tim.” Lalu organisasi berkembang, proses berubah, dan alat itu berubah menjadi tambal sulam pengecualian.

Polanya “meledak nanti” itu umum:

• Penyebaran peran: Anda menambah Support, lalu Support - Senior, lalu Support - EU, lalu Support - EU - Shift Malam, hingga tak ada yang ingat apa saja yang tercakup tiap peran.
• Menumpuk pengecualian: beberapa orang butuh “hanya satu izin tambahan,” jadi toggle satu‑kali menumpuk.
• Paparan tak sengaja: seseorang bisa melihat catatan gaji, PII pelanggan, atau laporan pendapatan karena sebuah layar dipakai ulang tanpa memeriksa akses.
• Workflow rusak: seorang pengguna bisa melihat record tapi tidak bisa mengambil langkah berikutnya (atau lebih buruk, bisa mengambil langkah tanpa melihat konteks).
• Audit menyakitkan: sulit menjawab “Siapa yang bisa menyetujui pengembalian dana di atas $1.000?” tanpa penggalian manual.

Tujuan memilih RBAC atau ABAC sejak awal bukan hanya untuk mengunci layar. Itu untuk menjaga aturan tetap dapat dipahami saat tim baru, wilayah, dan kebijakan muncul.

Model perizinan yang tahan memiliki empat kualitas: mudah dijelaskan, mudah ditinjau, sulit disalahgunakan, dan cepat diubah.

RBAC dalam kata‑kata sederhana (peran dan apa yang mereka buka)

RBAC (role-based access control) adalah pendekatan “judul pekerjaan”. Seorang pengguna mendapat satu atau lebih peran (Support Agent, Admin). Setiap peran memiliki himpunan tetap hal yang boleh dilihat dan dilakukan. Jika dua orang berbagi peran yang sama, mereka mendapat akses yang sama.

RBAC bekerja baik ketika tim umumnya menjalankan tugas yang sama tiap hari dan pertanyaan utama bersifat level‑fitur: “Bisa mereka menggunakan layar ini?” atau “Bisa mereka melakukan aksi ini?”

Contoh peran untuk konsol support:

• Support Agent: melihat tiket, membalas pelanggan, menambah catatan internal
• Support Lead: semua yang bisa dilakukan agent, plus memindahkan tiket dan melihat metrik tim
• Admin: mengelola pengguna, mengubah pengaturan sistem, mengedit aturan perizinan

Inti idenya adalah peran memetakan tanggung jawab, bukan orang tertentu. Ketika tanggung jawab stabil, peran tetap stabil dan model mudah dijelaskan.

RBAC cocok ketika:

• Struktur organisasi jelas (tim, lead, admin)
• Sebagian besar keputusan akses adalah “bisa menggunakan fitur ini?”
• Onboarding perlu dapat diprediksi (tetapkan peran X dan selesai)
• Audit penting (mudah untuk daftar apa yang bisa dilakukan sebuah peran)

Di mana RBAC mulai menyulitkan adalah ketika realitas jadi berantakan. Alat internal mengumpulkan pengecualian: seorang agent yang bisa mengembalikan dana, pengguna finance yang hanya boleh melihat satu region, kontraktor yang bisa melihat tiket tapi bukan PII pelanggan. Jika Anda menyelesaikan tiap pengecualian dengan membuat peran baru, Anda mendapatkan ledakan peran.

Sinyal praktis bahwa RBAC saja gagal: Anda mulai menambahkan “peran khusus” setiap minggu.

ABAC dalam kata‑kata sederhana (aturan berbasis atribut)

ABAC (attribute-based access control) memutuskan akses menggunakan aturan, bukan hanya jabatan. Alih‑alih bertanya “Apa yang bisa peran Finance lakukan?”, ABAC bertanya: “Mengingat siapa orang ini, apa record ini, dan apa konteks saat ini, apakah kita mengizinkan?”

Atribut adalah fakta yang sudah Anda lacak. Sebuah aturan bisa mengatakan:

• “Support agents bisa melihat tiket di region mereka.”
• “Manajer bisa menyetujui pengeluaran di bawah $5.000 selama jam kerja.”

Sebagian besar sistem ABAC bergantung pada beberapa kategori atribut:

• Atribut pengguna: departemen, region, status manajer
• Atribut data: pemilik record, prioritas tiket, status faktur
• Atribut konteks: waktu, jenis perangkat, lokasi jaringan
• Atribut aksi: lihat vs edit vs ekspor

Contoh konkret: seorang support agent bisa mengedit tiket hanya jika (a) prioritas tiket bukan kritis, (b) tiket ditugaskan padanya, dan (c) region pelanggan sesuai region mereka. Anda menghindari membuat peran terpisah seperti Support - EU - Noncritical dan Support - US - Noncritical.

Pertukarannya adalah ABAC bisa menjadi sulit untuk dipahami jika pengecualian khusus terus menumpuk. Setelah beberapa bulan, orang berhenti bisa menjawab pertanyaan sederhana seperti “Siapa yang bisa mengekspor faktur?” tanpa membaca rantai kondisi panjang.

Kebiasaan ABAC yang baik adalah menjaga aturan sedikit, konsisten, dan diberi nama dalam bahasa sederhana.

Akses level‑record: tempat sebagian besar kesalahan terjadi

Banyak tim menganggap perizinan sebagai “bisa membuka layar ini?” Itu baru lapisan pertama. Akses level‑record menjawab pertanyaan berbeda: meskipun Anda bisa membuka layar, baris mana yang boleh Anda lihat atau ubah?

Seorang support agent dan analis finance mungkin sama‑sama mengakses halaman Customers. Jika Anda berhenti pada akses level‑layar, Anda berisiko menunjukkan semuanya ke semua orang. Aturan level‑record mempersempit data yang dimuat di dalam halaman itu.

Aturan level‑record umum termasuk:

• Hanya pelanggan Anda (assigned_owner_id = current_user.id)
• Hanya region Anda (customer.region IN current_user.allowed_regions)
• Hanya cost center Anda (invoice.cost_center_id IN current_user.cost_centers)
• Hanya tiket tim Anda (ticket.team_id = current_user.team_id)
• Hanya record yang Anda buat (created_by = current_user.id)

Akses level‑record harus ditegakkan di tempat data diambil dan dimodifikasi, bukan hanya di UI. Dalam praktik, itu berarti lapisan query, endpoint API, dan logika bisnis.

Mode kegagalan khas adalah “halaman terkunci, API terbuka.” Sebuah tombol disembunyikan untuk non-admin, tetapi endpoint masih mengembalikan semua record. Siapa pun yang punya akses ke aplikasi kadang bisa memicu panggilan itu dengan mengulang request atau mengubah filter.

Cek kewajaran model Anda dengan beberapa pertanyaan:

• Jika pengguna memanggil endpoint langsung, apakah mereka masih hanya mendapatkan record yang diizinkan?
• Apakah endpoint list, detail, export, dan count menerapkan aturan yang sama?
• Apakah create, update, dan delete diperiksa terpisah (bukan hanya read)?
• Apakah admin melewati aturan secara sengaja, atau karena kecelakaan?

Perizinan layar menentukan siapa yang boleh masuk ke sebuah ruangan. Akses level‑record menentukan laci mana yang boleh mereka buka setelah di dalam.

Contoh nyata: support, finance, dan manajer

Tujuannya bukan “keamanan sempurna.” Tujuannya perizinan yang bisa dipahami hari ini, dan bisa diubah nanti tanpa merusak alur kerja.

Tim Support

Support biasanya membutuhkan aturan level‑record, karena “semua tiket” jarang benar.

Model sederhana: agent bisa membuka dan memperbarui tiket yang ditugaskan pada mereka, plus apa pun yang ada di antrian mereka. Team lead bisa memindahkan tiket dan turun tangan pada eskalasi. Manajer sering perlu dashboard tanpa kemampuan mengedit setiap tiket.

Aksi massal dan ekspor adalah twist umum. Banyak tim mengizinkan bulk‑close, membatasi bulk reassignment, dan membatasi ekspor ke lead dan manajer dengan pencatatan.

Tim Finance

Akses finance kebanyakan tentang langkah persetujuan dan jejak audit yang bersih.

Setup umum: seorang AP clerk bisa membuat tagihan dan menyimpan draft, tapi tidak bisa menyetujui atau membayar. Controller bisa menyetujui dan melepaskan pembayaran. Auditor harus bersifat read‑only, termasuk lampiran, tanpa kemampuan mengubah data vendor.

Aturan realistis: “AP clerks bisa mengedit draft yang mereka buat; begitu diserahkan, hanya controller yang bisa mengubahnya.” Itu adalah akses level‑record (status + pemilik) dan seringkali lebih cocok dengan ABAC daripada menambah peran.

Manajer

Kebanyakan manajer butuh visibilitas luas tapi kemampuan edit terbatas.

Polanya: manajer bisa melihat sebagian besar data operasional, tapi hanya bisa mengedit record yang dimiliki tim mereka atau terkait bawahan langsung (permintaan cuti, tujuan, catatan performa). Atribut seperti team_id, manager_id, dan employment status biasanya lebih jelas daripada membuat peran terpisah untuk tiap departemen.

Di antara kelompok ini, Anda biasanya butuh:

• Support: visibilitas berdasarkan penugasan/antrian, ekspor hati‑hati, pemindahan terkontrol
• Finance: aturan berbasis status (draft vs submitted vs approved), persetujuan ketat, akses read‑only yang audit‑safe
• Manajer: melihat luas, edit sempit (record milik tim atau bawahan langsung)

Matriks keputusan: peran vs atribut vs aturan level‑record

Daripada berdebat “mana yang lebih baik,” tanyakan bagian mana dari masalah akses Anda cocok dengan tiap model. Kebanyakan tim berakhir dengan hybrid: peran untuk akses luas, atribut untuk pengecualian, dan filter level‑record untuk “barang saya.”

Perlakukan logika perizinan seperti tagihan bulanan. Setiap peran, aturan, dan pengecualian tambahan membutuhkan waktu untuk dites, dijelaskan, dan debug. Gunakan jumlah sekecil mungkin yang memenuhi skenario nyata hari ini.

Default praktis:

• Mulai dengan RBAC untuk jalur besar (Support, Finance, Manager).
• Tambahkan ABAC untuk kondisi berulang (region, senioritas, tier pelanggan).
• Tambahkan aturan level‑record ketika pengguna harus melihat “barang mereka”, bukan seluruh tabel.

Langkah demi langkah: desain perizinan sebelum Anda membangun layar

Jika Anda memutuskan perizinan setelah UI jadi, Anda biasanya berakhir dengan terlalu banyak peran atau tumpukan kasus khusus. Rencana sederhana mencegah pembangunan ulang terus‑menerus.

1) Mulai dari aksi, bukan layar

Tuliskan apa yang sebenarnya dilakukan orang dalam setiap workflow:

• View (baca)
• Create
• Edit
• Approve
• Export
• Delete

Dalam alur pengembalian dana, Approve bukan sama dengan Edit. Perbedaan itu sering menentukan apakah Anda butuh aturan ketat atau cukup peran.

2) Definisikan peran yang sesuai dengan jabatan

Pilih peran yang orang kenal tanpa perlu rapat: Support Agent, Support Lead, Finance Analyst, Finance Manager, Auditor, Admin. Hindari peran seperti “Support Agent - Can edit VIP notes.” Itu cepat meledak.

3) Daftar atribut yang menciptakan pengecualian nyata

Tambahkan ABAC hanya jika benar‑benar berfaedah. Atribut tipikal: region, tim, tier pelanggan, kepemilikan, dan jumlah.

Jika pengecualian terjadi kurang dari sekali sebulan, pertimbangkan langkah persetujuan manual daripada aturan perizinan permanen.

4) Tulis aturan level‑record sebagai kebijakan satu kalimat

Akses level‑record adalah titik di mana sebagian besar alat internal rusak. Tulis aturan yang bisa Anda tunjukkan ke manajer non‑teknis:

“Support Agents can view tickets in their region.”

“Finance Analysts can edit invoices they created until they’re approved.”

“Managers can approve refunds over $500 only for their team.”

Jika Anda tidak bisa menyatakan sebuah aturan dalam satu kalimat, proses itu mungkin butuh kejelasan.

5) Uji dengan lima orang nyata sebelum membangun

Jalankan skenario nyata:

• Seorang support agent menangani pelanggan VIP
• Seorang finance analyst memperbaiki faktur
• Seorang manajer menyetujui pengembalian dana besar
• Seorang admin melakukan pemeliharaan
• Seorang auditor yang harus melihat riwayat tapi tidak mengubah apapun

Perbaiki kebingungan di sini, sebelum berubah jadi labirin perizinan.

Perangkap umum (dan cara menghindarinya)

Sebagian besar kegagalan perizinan bukan karena memilih RBAC atau ABAC. Mereka terjadi ketika pengecualian kecil menumpuk sampai tak ada yang bisa menjelaskan siapa bisa melakukan apa, dan mengapa.

Ledakan peran biasanya dimulai dengan “Support Lead butuh satu tombol ekstra,” lalu berkembang menjadi 25 peran yang berbeda oleh satu izin. Jaga peran tetap luas (sesuai pekerjaan) dan gunakan sejumlah kecil pengecualian berbasis aturan untuk kasus tepi yang sering muncul.

Logika atribut yang tak terbaca adalah versi ABAC dari masalah yang sama. Jika Anda punya kondisi seperti “department == X AND region != Y” berserakan di mana‑mana, audit berubah jadi tebak‑tebakan. Gunakan kebijakan bernama (meskipun hanya label konsisten di dokumen bersama) sehingga Anda bisa mengatakan “kebijakan RefundApproval” daripada mengurai formula.

Ekspor, laporan, dan aksi massal adalah tempat kebocoran sering terjadi. Tim mengunci tampilan record, lalu lupa bahwa Export CSV atau pembaruan massal melewati cek yang sama. Perlakukan setiap jalur non‑layar sebagai aksi kelas‑satu dengan pemeriksaan izin sendiri.

Perangkap yang perlu diawasi:

• Peran baru untuk tiap pengecualian
• Aturan atribut yang susah dibaca atau tak bernama
• Ekspor, laporan terjadwal, dan aksi massal melewatkan cek
• Alat berbeda menjawab pertanyaan akses yang sama dengan cara berbeda
• Aturan level‑record diterapkan di satu tempat tapi tidak di tempat lain

Perbaikan paling aman adalah satu sumber kebenaran untuk peran, atribut, dan aturan level‑record, ditegakkan secara konsisten di logika backend Anda.

Daftar cepat sebelum Anda kirim

Jika model Anda sulit dijelaskan, akan lebih susah di‑debug ketika seseorang bilang, “Saya seharusnya bisa melihat pelanggan itu” atau “Kenapa mereka bisa mengekspor daftar ini?”

Lima cek yang menangkap kebanyakan kejutan:

• Bisakah pengguna nyata menggambarkan akses mereka dalam satu kalimat (misal: “Saya Support, region = EU, saya bisa melihat tiket untuk region saya tapi tidak bisa mengekspor”)? Jika tidak, aturan mungkin terlalu tersebar.
• Apakah Anda punya jawaban eksplisit untuk “siapa yang bisa mengekspor?” dan “siapa yang bisa menyetujui?” Perlakukan ekspor dan persetujuan sebagai aksi berisiko tinggi.
• Apakah aturan level‑record ditegakkan di mana pun data diambil (endpoint API, laporan, job background), bukan hanya dengan menyembunyikan tombol?
• Apakah default aman untuk aksi sensitif (deny by default)? Role, atribut, dan layar baru seharusnya tidak mendapatkan izin kuat secara tidak sengaja.
• Bisakah Anda menjawab “Siapa yang bisa melihat record ini dan kenapa?” dalam waktu kurang dari satu menit menggunakan satu sumber kebenaran (peran, atribut, dan kepemilikan/status record)?

Contoh: Finance mungkin melihat semua faktur, tapi hanya Approver yang bisa menyetujui, dan hanya Manager yang bisa mengekspor daftar vendor lengkap. Support bisa melihat tiket, tapi hanya tim pemilik tiket yang bisa melihat catatan internal.

Mengubah perizinan tanpa merusak semuanya

Perizinan berubah karena alasan membosankan: manajer baru, finance terpecah menjadi AP dan AR, atau perusahaan mengakuisisi tim lain. Rencanakan perubahan sehingga pembaruan kecil, dapat dibalik, dan mudah ditinjau.

Hindari mengikat akses ke satu “super role” besar. Tambahkan akses baru sebagai peran baru, atribut baru, atau aturan record sempit, lalu uji terhadap tugas nyata.

Tambahkan akses tanpa merombak semuanya

Saat departemen baru muncul (atau merger menambah tim), jaga core role tetap stabil dan tambahkan lapisan di sekitarnya.

• Pertahankan peran dasar sedikit (Support, Finance, Manager), lalu tambahkan add‑on kecil (Refunds, Export, Approvals).
• Pilih atribut untuk perubahan organisasi (team, region, cost center) sehingga grup baru tidak butuh peran baru.
• Gunakan aturan level‑record untuk kepemilikan dan penugasan (ticket.assignee_id, invoice.cost_center).
• Tambahkan langkah persetujuan untuk aksi sensitif (payout, write‑off).
• Perlakukan ekspor hampir di mana‑mana sebagai izin sendiri.

Akses sementara tidak seharusnya memerlukan perubahan peran permanen. Untuk penutup liburan atau respons insiden, gunakan pemberian berbatas waktu: “Finance Approver selama 48 jam,” dengan tanggal habis dan alasan yang diwajibkan.

Ritme audit dan log yang siap investigasi

Gunakan ritme tinjauan sederhana: bulanan untuk perizinan berisiko tinggi (uang, ekspor), kuartalan untuk sisanya, dan setelah reorganisasi atau merger.

Catat cukup banyak informasi untuk menjawab siapa melakukan apa, pada record mana, dan mengapa itu diizinkan:

• Siapa yang melihat, mengubah, menyetujui, atau mengekspor
• Kapan terjadi (dan dari mana jika Anda menangkapnya)
• Record apa yang disentuh (ID, tipe, before/after untuk edit)
• Mengapa itu diizinkan (peran, atribut, aturan record, pemberian sementara)
• Siapa yang memberi akses (dan kapan berakhir)

Langkah berikutnya: terapkan model yang bisa Anda pertahankan

Mulailah dengan model perizinan kecil dan membosankan. Itu yang bertahan enam bulan perubahan.

Default yang baik adalah RBAC sederhana: segelintir peran yang cocok dengan fungsi kerja nyata (Support Agent, Support Lead, Finance, Manager, Admin). Gunakan peran itu untuk mengontrol pintu besar seperti layar mana yang ada, aksi apa yang tersedia, dan workflow mana yang bisa dimulai.

Lalu tambahkan ABAC hanya jika Anda terus melihat pengecualian nyata. Jika satu‑satunya alasan Anda ingin ABAC adalah “mungkin berguna nanti,” tunggu. ABAC bersinar ketika kondisi penting (batas jumlah, pembatasan region, kepemilikan, status), tetapi ia perlu pengujian hati‑hati dan kepemilikan yang jelas.

Tulis aturan sebagai kalimat biasa terlebih dulu. Jika sebuah aturan sulit diucapkan dalam satu kalimat, akan sulit dipelihara.

Jika Anda menginginkan cara cepat untuk mempiloti ini dalam alat internal nyata, platform no‑code seperti AppMaster (appmaster.io) dapat membantu Anda memodelkan peran, field data seperti owner/team/status, dan workflow yang ditegakkan di backend sejak awal, sebelum keputusan UI mengunci asumsi berisiko.