RBAC va ABAC: ilovada rollar va kirish huquqlarini qanday loyihalash
Amaliyot3 daqInnovialabs tahririyati
Qisqacha
Nomlangan huquqlarni birlashtiruvchi rollar — RBAC dan boshlang va ABAC qoidalarini faqat kirish ma’lumotlarga bog‘liq bo‘lgan joyda qo‘shing, masalan «o‘z bitimlari» yoki «o‘z filiali bitimlari», hammasini serverda tekshiring.
Qisqa javob
- RBAC (role-based access control): foydalanuvchiga rollar, rollarga huquqlar beriladi. «Menejer bitimlarni tahrirlay oladi». Tushunish va tekshirish oson.
- ABAC (attribute-based access control): qaror foydalanuvchi, obyekt va kontekst atributlari asosida qabul qilinadi. «Menejer bitimni tahrirlay oladi, agar u uning filialiga tegishli va yopilmagan bo‘lsa».
Ko‘pchilik real ilovalar gibrid yondashuvdan foydalanadi: RBAC «odam umuman bunday amalni bajara oladimi» degan savolga, atribut qoidalari esa «aynan qaysi yozuvlar bilan» degan savolga javob beradi.
Taqqoslash
| RBAC | ABAC | |
|---|---|---|
| Qaysi savolga javob beradi | Rol qaysi amallarga ruxsat beradi? | Bu obyekt bilan bu amal hozir mumkinmi? |
| CRM dagi misol | Sotuv menejeri bitimlarni ko‘radi | Menejer faqat o‘z filiali bitimlarini ko‘radi |
| Sozlash murakkabligi | Past | Yuqoriroq: qoidalarni o‘ylab chiqish va test qilish kerak |
| Audit | Oson: rollar va huquqlar ro‘yxati | Qiyinroq: qoidalarni o‘qish kerak |
| Odatiy xavf | Rollar sonining portlashi | Hech kim tushunmaydigan qoidalar |
Rollarni emas, huquqlarni modellashtiring
Eng ko‘p uchraydigan xato — kodda rolni tekshirish: if (user.role === "admin"). Yangi rol paydo bo‘lganda bunday tekshiruvlarning barchasini qidirishga to‘g‘ri keladi. Buning o‘rniga huquqlarni tekshiring, rollar esa shunchaki ularning to‘plami bo‘lsin.
CREATE TABLE permissions (
id serial PRIMARY KEY,
code text UNIQUE NOT NULL -- masalan 'deals.view', 'deals.edit', 'users.manage'
);
CREATE TABLE roles (
id serial PRIMARY KEY,
name text UNIQUE NOT NULL
);
CREATE TABLE role_permissions (
role_id int REFERENCES roles(id),
permission_id int REFERENCES permissions(id),
PRIMARY KEY (role_id, permission_id)
);
CREATE TABLE user_roles (
user_id int REFERENCES users(id),
role_id int REFERENCES roles(id),
PRIMARY KEY (user_id, role_id)
);
Huquq kodlari kodda konstanta sifatida yashaydi, rollar esa bazada saqlanadi va ularni admin panelda reliz qilmasdan o‘zgartirish mumkin.
Ma’lumot muhim bo‘lgan joyda — atributlar
Ko‘rinish sohasi qoidalari odatda bir nechta atributga bog‘liq: egasi, jamoa, filial, yozuv holati. Ularni har bir resurs uchun bitta siyosat funksiyasiga jamlang:
function canEditDeal(user: User, deal: Deal): boolean {
if (!user.permissions.has("deals.edit")) return false;
if (deal.status === "closed") return user.permissions.has("deals.edit_closed");
if (user.permissions.has("deals.edit_any")) return true;
if (deal.ownerId === user.id) return true;
return user.permissions.has("deals.edit_branch") && deal.branchId === user.branchId;
}
Ro‘yxatlar uchun xuddi shu qoidani bazaga so‘rovdagi filtr sifatida qo‘llang, hammasini yuklab interfeysda qatorlarni yashirmang. Aks holda API baribir boshqa filiallar ma’lumotlarini qaytaradi, sahifalash hisoblagichlari esa noto‘g‘ri bo‘ladi.
Tekshiruvlar — serverda
- Interfeys tugmalarni yashirishi mumkin, lekin har bir API endpoint huquqlarni o‘zi tekshiradi. So‘rovni interfeysni chetlab, to‘g‘ridan-to‘g‘ri yuborish mumkin.
- Faqat amalga emas, aniq obyektga kirishni tekshiring. So‘rovda
/deals/42ni/deals/43ga almashtirish begona bitimni ochmasligi kerak — bu klassik IDOR zaifligi (broken object level authorization). - Standart bo‘yicha taqiq: siyosati yo‘q yangi endpoint hamma uchun ishlamasdan, 403 qaytarishi kerak.
- Huquqlar o‘zgarishi va rollar tayinlanishini xavfsizlik hodisasi sifatida loglang.
Rollar portlashining oldini olish
Har bir istisno yangi rolga aylanganda rollar portlashi boshlanadi: «Menejer Toshkent», «Menejer Samarqand», «Menejer Toshkent eksportsiz»…
- Rollar lavozim vazifalarini tasvirlaydi, soha (filial, jamoa, hudud) esa atributlarga o‘tadi.
- Birlashtirilgan rollar o‘rniga bitta foydalanuvchiga bir nechta rol berishga ruxsat bering.
- Kam ishlatiladigan huquqlarni alohida bering, rol variantlarini ko‘paytirmang.
- Rollarni vaqti-vaqti bilan qayta ko‘rib chiqing: ishlatilmaydiganlarini o‘chiring, deyarli bir xillarini birlashtiring.
- Admin panelda har bir rol aynan nimaga ruxsat berishini tushunarli tilda ko‘rsating.
Misol: internet-do‘kon admin paneli
- Rollar: Egasi, Administrator, Kontent-menejer, Qo‘llab-quvvatlash, Ombor.
- Huquqlar:
products.edit,orders.view,orders.refund,users.manage,settings.payments. - Atribut qoidalari: qo‘llab-quvvatlash buyurtmalarni ko‘radi, lekin pulni faqat sozlamalardagi limitgacha qaytaradi; ombor faqat o‘z omborining buyurtmalarini ko‘radi; hech kim o‘z rollarini o‘zgartira olmaydi.