Cara Tambah Kawalan Akses Berasaskan Peranan (RBAC) pada Aplikasi Anda

Untuk menambah kawalan akses berasaskan peranan, berikan setiap pengguna satu atau lebih peranan (contohnya admin, editor, pembaca), tentukan tindakan yang boleh dilakukan oleh setiap peranan, dan semak kebenaran tersebut di pelayan untuk setiap permintaan — bukan sekadar dengan menyembunyikan butang. Semak juga bahawa rekod yang diakses itu tergolong dalam akaun atau pasukan pengguna. Mulakan dengan beberapa peranan tetap dalam pangkalan data anda, dan uji dengan cuba mencapai data pengguna lain secara langsung.

Pengesahan vs kebenaran

Dua perkataan yang sering bercampur:

• Pengesahan ialah siapa anda? — log masuk. Lihat cara menambah log masuk pada aplikasi anda.
• Kebenaran ialah apa yang anda dibenarkan lakukan? — halaman, rekod dan tindakan mana yang boleh dicapai oleh pengguna yang telah log masuk.

RBAC ialah cara paling biasa untuk melaksanakan kebenaran. Ia penting: setakat September 2026, Broken Access Control berada di tangga pertama OWASP Top 10:2025, senarai risiko keselamatan aplikasi web paling serius yang digunakan secara meluas. Kegagalan biasa ialah pengguna membaca rekod pengguna lain dengan menukar ID dalam URL, atau pengguna biasa memanggil laluan API khusus admin.

Pilih model

Dalam amalan, kebanyakan aplikasi menggabungkan dua perkara: peranan untuk jenis tindakan yang boleh diambil seseorang, dan pemilikan untuk rekod mana yang boleh mereka tindakkan. "Editor boleh sunting catatan" ialah peraturan peranan; "…catatan dalam ruang kerja mereka sendiri" ialah peraturan pemilikan. Anda perlukan kedua-duanya.

Mulakan dengan lebih ringkas daripada yang anda sangkakan. Admin, ahli dan pembaca sudah meliputi bilangan aplikasi yang mengejutkan. Lebih mudah membahagikan satu peranan kemudian daripada merungkai sepuluh peranan yang tiada siapa faham.

Reka peranan sebelum menulis kod

Tulis jadual kebenaran dalam bahasa biasa dahulu. Ia berfungsi sebagai spesifikasi untuk AI dan sebagai pelan ujian anda:

Tentukan juga kes tepi: bolehkah pemilik terakhir keluar? Bolehkah admin membuang pemilik? Apa yang dilihat oleh pengguna yang dibuang?

Langkah demi langkah

1. Pastikan log masuk berfungsi dahulu

RBAC berada di atas pengesahan. Pelayan mesti tahu dengan pasti siapa yang membuat setiap permintaan, daripada sesi atau token yang disahkan — jangan sekali-kali daripada ID pengguna yang dihantar oleh pelayar dalam badan permintaan.

2. Simpan peranan dalam pangkalan data

Untuk aplikasi satu pasukan, lajur role pada pengguna sudah memadai. Untuk pasukan, gunakan jadual keahlian:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Jangan benarkan pengguna menetapkan peranan mereka sendiri melalui kemas kini profil biasa. Perubahan peranan mesti melalui titik akhir khusus yang menyemak kebenaran.

3. Semak kebenaran di pelayan, di satu tempat

Tulis satu pembantu — sesuatu seperti can(user, 'projects.delete', project) — dan panggilnya dalam setiap laluan API, tindakan pelayan dan kerja latar belakang yang membaca atau mengubah data. Satu fungsi pusat lebih mudah disemak dan diuji berbanding semakan yang bertebaran dalam kod. Tolak secara lalai: jika tiada peraturan membenarkan sesuatu tindakan, ia ditolak.

4. Hadkan setiap pertanyaan

Setiap pertanyaan untuk data pasukan perlu termasuk pasukan: where organization_id = :currentOrg, bukan sekadar where id = :id. Ini menghalang seseorang daripada menukar /projects/123 kepada /projects/124 dan melihat projek syarikat lain. Pulangkan "tidak dijumpai" dan bukan "dilarang" untuk rekod dalam pasukan lain, supaya anda tidak mendedahkan bahawa ia wujud.

5. Tambah perlindungan peringkat pangkalan data di tempat yang penting

Row-level security (RLS) Postgres membolehkan pangkalan data menguatkuasakan baris mana yang boleh dilihat oleh setiap pengguna. Ia penting jika pelayar bercakap terus dengan pangkalan data (seperti dalam sesetengah perkhidmatan belakang yang dihoskan), dan lapisan kedua yang berguna untuk jadual sensitif jika tidak.

6. Cerminkan peranan dalam antara muka

Sekarang sembunyikan atau lumpuhkan apa yang pengguna tidak boleh lakukan, supaya aplikasi tidak mengelirukan. Ini hanya untuk kebolehgunaan; semakan pelayanlah yang melindungi.

7. Log tindakan sensitif

Rekodkan siapa yang menukar peranan, memadam data atau mengeksport rekod, dan bila. Log audit membantu dengan soalan sokongan dan insiden.

8. Uji seperti penyerang

Log masuk sebagai setiap peranan dan cuba setiap tindakan dalam jadual kebenaran. Kemudian cuba perkara yang sepatutnya tidak berfungsi: panggil laluan API admin sebagai pembaca, tukar ID dalam URL dan permintaan, buang diri sendiri sebagai pemilik terakhir. Ujian automatik untuk jadual kebenaran berberbaloi ditulis sebaik peraturan stabil.

Prompt yang berkesan

Tambah kawalan akses berasaskan peranan. Peranan bagi setiap organisasi: owner, admin, member, viewer, disimpan dalam jadual memberships. Kebenaran ada dalam jadual ini: [tampal jadual anda]. Cipta satu pembantu can(user, action, resource) di pelayan, tolak secara lalai, dan gunakannya dalam setiap laluan API. Hadkan setiap pertanyaan mengikut organization_id. Sembunyikan tindakan yang pengguna tidak boleh lakukan dalam UI, tetapi jangan sekali-kali bergantung pada itu untuk keselamatan.

Semak setiap laluan API dan fungsi pelayan dalam aplikasi ini. Bagi setiap satu, senaraikan data yang dibaca atau diubah, sama ada ia menyemak pengguna telah log masuk, sama ada ia menyemak peranan mereka, dan sama ada ia menghadkan pertanyaan kepada organisasi mereka. Betulkan mana-mana yang tiada semakan, dan tunjukkan senarai itu kepada saya.

Tambah halaman /admin khusus admin tempat pemilik boleh menukar peranan ahli. Halang membuang atau menurunkan pemilik terakhir, log setiap perubahan peranan dengan siapa yang membuatnya dan bila, dan pastikan titik akhir perubahan peranan menolak sesiapa yang bukan pemilik.

Kesilapan biasa

• Menyemak peranan hanya di bahagian hadapan. API masih terbuka kepada sesiapa yang memanggilnya.
• Mempercayai ID dari pelanggan — userId atau role dalam badan permintaan dan bukannya sesi.
• Pertanyaan tanpa had yang mengambil rekod hanya mengikut ID rekod.
• Peranan disemak pada halaman tetapi tidak pada laluan API, eksport, muat turun fail atau webhook.
• Admin mengikut alamat e-mel yang dikodkan keras dalam kod (if email === 'me@...'), yang mudah dilupakan dan sukar ditukar.
• Terlalu banyak peranan terlalu awal, yang tiada siapa dapat terangkan enam bulan kemudian.
• Sesi lapuk: pengguna yang diturunkan pangkatnya kekal mempunyai hak admin sehingga mereka log keluar. Semak peranan daripada pangkalan data, atau muat semula, untuk tindakan sensitif.

Senarai semak RBAC

• Jadual kebenaran ditulis dalam bahasa biasa, kes tepi diputuskan
• Pelayan mengenali pengguna daripada sesi, tidak sekali-kali daripada data permintaan
• Peranan disimpan dalam pangkalan data; pengguna tidak boleh menukar peranan sendiri
• Satu semakan kebenaran pusat, tolak secara lalai, digunakan dalam setiap laluan
• Setiap pertanyaan dihadkan kepada organisasi atau pemilikan pengguna
• Row-level security di tempat pelayar boleh mencapai pangkalan data
• UI menyembunyikan apa yang pengguna tidak boleh lakukan (untuk kebolehgunaan sahaja)
• Tindakan sensitif direkodkan
• Setiap peranan diuji, termasuk panggilan API terus dan ID yang ditukar

Kawalan akses hanyalah satu item dalam senarai yang lebih panjang; senarai semak keselamatan untuk aplikasi yang dibina dengan AI meliputi yang selebihnya. Jika anda membina alat untuk kakitangan dalaman anda sendiri, cara membina alat dalaman menunjukkan di mana peranan sesuai.

RBAC pada Mythex

Mythex tidak menyediakan sistem log masuk atau peranan terbina dalam untuk pengguna aplikasi anda. Anda memilih pustaka atau pembekal auth dan menerangkan peranan, dan ejen menyambungkannya ke dalam kod serta pangkalan data Postgres projek anda (tambah log masuk pada aplikasi anda). Peranan ruang kerja Mythex anda sendiri, seperti Owner dan Member, mengawal siapa yang boleh menyunting projek Mythex anda, bukan siapa yang boleh menggunakan aplikasi yang anda terbitkan. Gunakan mod Plan untuk bersetuju tentang jadual kebenaran sebelum membina, kemudian gunakan prompt semakan di atas dan uji setiap peranan dalam Pratonton sebelum anda menerbitkan. Prompt keselamatan dalam dokumentasi ialah susulan yang berguna.

Soalan lazim