Authorization nima?

Avtorizatsiya (authorization) — tanilgan foydalanuvchiga ma’lum bir amalni bajarishga ruxsat bor-yo‘qligini aniqlash. Autentifikatsiya "Siz kimsiz?" degan savolga, avtorizatsiya esa "Sizga nima qilish mumkin?" degan savolga javob beradi.

Ofis binosini misol qilib olamiz. Kirishda qo‘riqchi xodimning guvohnomasini tekshiradi — bu autentifikatsiya. Ichkarida esa har bir eshikda kartochka o‘quvchi qurilma bor. Buxgalter buxgalteriyaga kira oladi, lekin server xonasiga kira olmaydi. Tizim administratori server xonasiga kiradi, lekin kassaga kira olmaydi. Direktor esa hamma joyga kira oladi. Har bir eshik oldidagi tekshiruv — avtorizatsiya.

Uch asosiy tushuncha

Har qanday avtorizatsiya qarori uchta savolga asoslanadi:

Tushuncha	Savol	Misol
Subyekt (subject)	Kim?	Aziza, id=7, roli author
Amal (action)	Nima qilmoqchi?	update — tahrirlash
Resurs (resource)	Nima ustida?	42-kitob, egasi id=7

Avtorizatsiya tizimi shu uchlikni oladi va javob beradi: ruxsat yoki rad.

func Can(subject Principal, action string, resource Book) bool

Qarorga qo‘shimcha kontekst ham ta’sir qilishi mumkin: vaqt, IP manzil yoki qurilma. Masalan, "moliyaviy hisobotni faqat ish vaqtida va ofis tarmog‘idan ko‘rish mumkin".

Avtorizatsiya modellari

Ruxsatlarni qanday tashkil qilishning bir nechta keng tarqalgan modeli bor.

ACL — kirish ro‘yxati

ACL (Access Control List) — har bir resurs uchun kim nima qila olishini ko‘rsatadigan ro‘yxat.

42-kitob:
  Aziza (id=7)  → o‘qish, tahrirlash, o‘chirish
  Bobur (id=9)  → o‘qish, tahrirlash
  Hamma         → o‘qish

Operatsion tizimlardagi fayl ruxsatlari va Google Docs’dagi "Ulashish" oynasi shunday ishlaydi. Bu model aniq nazorat beradi. Lekin minglab resurs va foydalanuvchi bo‘lganda ro‘yxatlarni boshqarish qiyinlashadi.

RBAC — rollarga asoslangan

RBAC (Role-Based Access Control) — ruxsatlar foydalanuvchilarga to‘g‘ridan-to‘g‘ri emas, rollarga beriladi. Foydalanuvchiga esa rol biriktiriladi.

Rollar:
  reader → kitoblarni o‘qish
  author → kitoblarni o‘qish, yaratish
  admin  → hamma narsa

Foydalanuvchilar:
  Aziza → author
  Bobur → reader

Yangi xodim kelganda unga faqat rol beriladi. O‘nlab alohida ruxsatlarni qo‘lda sozlash shart emas. Aksariyat ilovalar uchun RBAC yaxshi boshlang‘ich nuqta. U alohida darsda batafsil ko‘riladi.

ABAC — atributlarga asoslangan

ABAC (Attribute-Based Access Control) — qaror subyekt, resurs va kontekst atributlari asosidagi qoidalar bilan qabul qilinadi:

Ruxsat, agar:
  subyekt.bo‘lim == resurs.bo‘lim
  VA subyekt.lavozim ∈ {menejer, direktor}
  VA vaqt ∈ ish_vaqti

ABAC juda moslashuvchan, lekin murakkab. Qoidalar ko‘payganda nima uchun ruxsat berilgani yoki rad etilganini tushunish qiyinlashadi.

ReBAC — munosabatlarga asoslangan

ReBAC (Relationship-Based Access Control) — ruxsat subyekt va resurs orasidagi munosabatga qarab beriladi:

Aziza → 42-kitobning egasi         → tahrirlay oladi
Bobur → Azizaning jamoasi a’zosi → jamoa kitoblarini o‘qiy oladi

Google Drive, GitHub va ijtimoiy tarmoqlar shu modelga yaqin. Resource-based permission modeli darsidagi "faqat o‘z kitobingizni tahrirlay olasiz" qoidasi ReBAC’ning eng sodda ko‘rinishi.

Qaysi birini tanlash kerak?

Amalda modellar ko‘pincha birgalikda ishlatiladi. Keng tarqalgan kombinatsiya:

• RBAC — umumiy amallar uchun: "kim kitob yarata oladi?";
• egalik tekshiruvi — aniq resurs uchun: "kim aynan shu kitobni tahrirlay oladi?".

Bu kursda aynan shu kombinatsiya ishlatiladi. Ko‘pchilik API’lar uchun u yetarli.

Asosiy tamoyillar

1. Sukut bo‘yicha rad etish (deny by default)

Ruxsat aniq berilmagan bo‘lsa, amal rad etiladi.

// ❌ Xavfli: ro‘yxatda bo‘lmagan har qanday rol ruxsat oladi
func canDelete(role string) bool {
    if role == "reader" {
        return false
    }
    return true
}

// ✅ Xavfsiz: faqat aniq ko‘rsatilgan rollar ruxsat oladi
func canDelete(role string) bool {
    return role == "admin"
}

Birinchi funksiyada yangi guest roli qo‘shilsa yoki rol bo‘sh satr bo‘lsa, u kitoblarni o‘chira oladi. Ikkinchisida esa noma’lum har qanday holat rad etiladi.

2. Eng kam huquq (least privilege)

Har bir foydalanuvchi va servis faqat o‘z ishini bajarish uchun zarur bo‘lgan minimal huquqqa ega bo‘lishi kerak. Yangi ro‘yxatdan o‘tgan foydalanuvchi reader rolini oladi, adminni emas. Hisobot servisi bazaga faqat o‘qish huquqi bilan ulanadi.

3. Tekshiruv faqat serverda

Frontend’da tugmani yashirish — bu interfeys qulayligi, himoya emas. Hujumchi brauzerni chetlab o‘tib, API’ga to‘g‘ridan-to‘g‘ri curl bilan so‘rov yuboradi. Har bir tekshiruv albatta server tomonida bo‘lishi kerak.

4. Tekshiruvni markazlashtirish

Ruxsat mantiqi kod bo‘ylab tarqalib ketmasligi kerak. if user.Role == "admin" || user.Role == "editor" || ... kabi shartlar o‘nlab handlerda takrorlansa, ulardan birini yangilash unutiladi. Barcha qoidalar bitta paketda, Can(subject, action, resource) kabi funksiyada jamlanishi lozim.

5. Klient yuborgan ma’lumotga ishonmaslik

Foydalanuvchi ID’si so‘rov tanasidan yoki URL’dan emas, faqat tekshirilgan tokendan olinadi:

// ❌ Istalgan odam boshqa foydalanuvchi nomidan kitob yarata oladi
ownerID := req.OwnerID

// ✅ Egasi — token egasi
p, _ := PrincipalFrom(r.Context())
ownerID := p.UserID

Autentifikatsiya va avtorizatsiya: qisqa taqqoslash

	Autentifikatsiya	Avtorizatsiya
Savol	Siz kimsiz?	Sizga nimaga ruxsat bor?
Tartib	Birinchi	Ikkinchi
Ma’lumot	Parol, token	Rol, egalik, qoidalar
Muvaffaqiyatsizlik	401 Unauthorized	403 Forbidden
Go’da joyi	Auth middleware	Ruxsat middleware, service

Xulosa

• Avtorizatsiya tanilgan foydalanuvchiga amal bajarishga ruxsat bor-yo‘qligini aniqlaydi.
• Har bir qaror subyekt, amal va resursga asoslanadi.
• Asosiy modellar: ACL, RBAC, ABAC va ReBAC. Amalda RBAC va egalik tekshiruvi birga ishlatiladi.
• Sukut bo‘yicha rad eting, minimal huquq bering, tekshiruvni faqat serverda bajaring va qoidalarni bitta joyda saqlang.

Keyingi darsda RBAC’ni Go’da amalga oshiramiz.