Rol dvigateli

1) Avtorizatsiya modellari

RBAC (Role-Based Access Control): subyekt rollarni oladi, rollar huquqlar bilan bog’liq (permissions). Oddiygina boshqarish, odatiy vazifalar uchun yaxshi.
ABAC (Attribute-Based Access Control): yechim sub’ekt atributlari, resurs, harakat va atrof-muhitga (vaqt, IP, mintaqa, xavf) bog’liq. Murakkab qoidalarga moslashuvchan va masshtabli.
RBAC + ABAC gibrid: rollar «asosiy» qobiliyat beradi, atributlar uni toraytiradi (conditions).
(Ixtiyoriy) ReBAC/Relationship-based: munosabatlar grafigi (egasi, jamoa aʼzosi, delegat), hujjatlar va org tuzilmalar uchun foydalidir.

2) Arxitektura: PDP/PEP va oqimlar

PEP (Policy Enforcement Point): yechim qo’llaniladigan joy (API-shlyuz, bekend-usul, SQL-qatlamcha, UI).
PDP (Policy Decision Point): siyosat va atributlar bo’yicha’ALLOW/DENY’ni hisoblaydigan xizmat/kutubxona.
PIP (Policy Information Point): atribut manbalari (IdP/profil, resurs meta-maʼlumotlari, xavf-tezkor, geo).
PAP (Policy Administration Point): ma’muriy interfeys/siyosat ombori (versiyalar, loyihalar, nashr).

Oqim: soʻrov → PEP kontekstni shakllantiradi → PDP yetishmayotgan atributlarni tortadi (PIP orqali) → yechimni hisoblaydi → PEP qoʻllaydi (ruxsat berish/taqiqlash/maydonlarni kesish) → audit.

3) Ma’lumotlar modeli

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• ’resource’ turi va atributlari bilan:’type’,’owner _ id’,’tenant _ id’,’classification’(public/confidential),’region’,’tags’.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• ’roles (id, tenant_id, name, inherits [])’ - ierarxiya va namunalarni qoʻllab-quvvatlang.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• ’assignments (subject_id, role_id, scope)’ - scope: global/loyiha boʻyicha/obyekt boʻyicha.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) Qarorlar qabul qilish prinsiplari

Deny-overrides: aniq taqiqlar ruxsatnomalardan ustundir.
Least Privilege (PoLP): minimal foydalanish imkoniyatini bering, shartlar orqali kengaytiring.
Separation of Duties (SoD): rollar/harakatlar kombinatsiyasini taqiqlash (masalan, «toʻlovni yaratdi» ≠ «bekor qildi»).
Context-aware: yuqori xavf bilan talablarni kuchaytiring (MFA yo’q, shubhali IP).
Determinism: bir xil kontekst → bir xil javob; siyosatning versiyasini jurnalga yozib oling.

5) Sotish patternlari

5. 1 Gibrid RBAC → ABAC (konditsionerlash)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Row/Field-Level Security

DB darajasida: RLS siyosati (’tenant _ id’,’owner _ id’).
API darajasida: Agar’allow: read_sensitive_fields'’boʻlmasa, toʻplamlarni filtrlab, maydonlarni yashiring.

5. 3 «step-up» yechimlari

allow if action == "export" and subject. mfa_verified == true else deny

5. 4. Vaqtinchalik ruxsatnomalar

TTL bilan grantlar:’assignment. expires_at', kirish «oynalari» (resurs mintaqasining ish vaqtida).

6) Unumdorlik va keshlash

Qisqacha TTL bilan’(subject_hash, resource_key, action, policy_version)’kaliti boʻyicha yechimlar keshi (decision cache).
Subyekt atributlarining edge-keshi (tokendagi claims) + resurs atributlarining lazy-fetch.
Incremental invalidation: voqealar bo’yicha nogironlik (rollarni o’zgartirish, siyosatni o’zgartirish, resursni «confidential» ga o’tkazish).
Batch-tekshirish: roʻyxatlar uchun - «filter» (policy-predicate pushdown) bilan baholang.

7) Ko’p ijara (Multi-tenant)

Har bir jadvalda -’tenant _ id’; andoza siyosatlar ijara ichidagi kirishni cheklaydi.
Ijara ma’murlari faqat o’z ijara rollarini/huquqlarini boshqaradilar.
Kross-ijara imkoniyati - faqat aniq taklifnomalar/aniq deny-override bilan shering orqali.

8) Siyosat ma’muriyatchiligi va hayot sikli

Version:’policy. PDP javobida version’, auditda saqlang.
Muhit: draft → canary (trafikning bir qismi/soyali rejim) → prod.
Test matrix: asosiy rollar/atributlar boʻyicha haqiqiylik jadvallari (shartnoma testlari).
Change management: xavfsizlik/komplayens sharhi bilan siyosatga merj-rekvestlar.

9) Audit va kuzatuv

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Metriklar: QPS PDP, yashirin p95, hit-rate kesh, deny ulushi, step-up chastotasi, SoD hodisalari.
Izlash: PDP chaqiruviga span; API soʻrovi bilan bogʻlanish.
Replay: siyosatning yangi versiyasida tarixiy qarorlarni «takrorlash» imkoniyati (safety check).

10) Autentifikatsiya va tokenlar bilan integratsiya

Identifikatsiya - IdP (OIDC/SAML) dan. Tokenlar minimal atributlarga ega:’sub’,’tenant’,’roles’,’auth _ time’,’amr’,’scopes’.
ABAC uchun tokenni shishirmaslik uchun «ogʻir» belgilarni server tomonga (PIP) torting.
Imzolangan resource tokens (capability/taklifnomalar) - cheklangan topshiriqlar uchun.

11) PDP soxta hujjati (soddalashtirilgan holda)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anti-patternlar

«Rol = sahifa» (mavzu sohasi modelisiz yuzlab kichik rollar).
Siyosatni faqat versiya/auditsiz kodda saqlash.
Deny-override va SoD yo’qligi → firibgarlik xavfini oshirish.
Qoidalardagi’user _ id’ning qattiq roʻyxatlari (atributlar/munosabatlar oʻrniga).
Faqatgina UI filtri mavjud boʻlganda maʼlumotlar darajasida (RLS) filtrlashning yoʻqligi.
Rollarni voqealarsiz va kesh nogironligi boʻlmagan qoʻl skriptlari orqali sinxronlashtirish.

13) Keyslar va retseptlar

13. 1 Darajali kamuflyaj:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Faqat MFA bilan maʼlumotlarni eksport qilish:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Vakolat berish (cheklangan token):

Capability-tokenda’resource _ id’,’actions = [» read»]’,’expires _ at’,’aud’mavjud. PEP imzo va muddatni tekshiradi.

14) Test sinovlari

Siyosatchilarning yunit-testlari: asosiy kombinatsiyalar bo’yicha haqiqat jadvallari.
Property-based: «teshiklarni» qidirish uchun tasodifiy atributlarni yaratish.
Golden-tests: tanqidiy endpointlar uchun yechimlar to’plamini tuzatish.
Canary/Shadow: tafovutlarni tuzish bilan siyosatning eski va yangi versiyalarini parallel baholash.

15) «Arxitektura va bayonnomalar» bo’limining bog’liq qobiliyatlari

Autentifikatsiya va avtorizatsiya (OIDC/OAuth2)

Kelishuvlarni boshqarish

Tokenlash va kalitlarni boshqarish

Kuzatilganlik: loglar, metriklar, trastirovkalar

Geo-yo’naltirish va mahalliylashtirish

At Rest/In Transit shifrlash

16) Arxitektorning chek-varaqasi

1. Mavzu va ularning ierarxiyalari aniqlanganmi?
2. Gibrid model bormi: rollar + atributlarda shartlar?
3. PDP deny-overrides, SoD va step-up bilan amalga oshirilganmi?
4. PEP qayerda? (shlyuz, bekend, DB, UI) - hamma joyda bir xilmi?
5. Yechimlar keshlari va hodisalar bo’yicha nogironlik o’rnatilganmi?
6. Siyosatchilar versiyalashtiriladimi, sinovdan o’tkaziladimi, jarayonga aylantiriladimi?
7. Yechimlar, metrika va trassalar auditi yoqilganmi?
8. Koʻp ijara va RLS/field-masking qoʻllab-quvvatlanadimi?
9. Hodisalar va siyosatni regressiya qilish uchun runbook bormi?

Xulosa

RBAC boshqaruvchanlikni, ABAC kontekst va aniqlikni ta’minlaydi. Rollarni atribut shartlari bilan birlashtirib, PDP/PEPni baham ko’rish, siyosatni keshlash, audit va sinovdan o’tkazish orqali siz avtorizatsiyani platforma qobiliyati sifatida qurasiz: mahsulot va tartibga solish talablari uchun oldindan aytib bo’ladigan, tekshiriladigan va ko’paytiriladigan.