Asosiy kontentga o‘tish
Innovialabs

RBAC va ABAC: ilovada rollar va kirish huquqlarini qanday loyihalash

Amaliyot3 daq

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

RBACABAC
Qaysi savolga javob beradiRol qaysi amallarga ruxsat beradi?Bu obyekt bilan bu amal hozir mumkinmi?
CRM dagi misolSotuv menejeri bitimlarni ko‘radiMenejer faqat o‘z filiali bitimlarini ko‘radi
Sozlash murakkabligiPastYuqoriroq: qoidalarni o‘ylab chiqish va test qilish kerak
AuditOson: rollar va huquqlar ro‘yxatiQiyinroq: qoidalarni o‘qish kerak
Odatiy xavfRollar sonining portlashiHech 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/42 ni /deals/43 ga 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.

Ko‘p beriladigan savollar

Kirish ma’lumotlar kimga tegishli ekaniga bog‘liq bo‘lmaganda: kichik ichki vositalar, bir-ikki rolli oddiy admin panellar. «Faqat o‘ziniki» yoki «faqat o‘z filialiniki» degan talab paydo bo‘lishi bilan atribut qoidalari kerak bo‘ladi.

Bunda yordam beramiz

O‘zingiz shug‘ullanmasdan natija olishni istasangiz — biz har kuni shu bilan shug‘ullanamiz.

Loyihani muhokama qilish

Yana o‘qing

G‘oya yoki vazifangiz bormi? Bizga aytib bering

Ish kuni davomida javob beramiz va yechim taklif qilamiz. Konsultatsiya bepul.