ABAC

ABAC — access qarorini user role’iga emas, subject, object, action va environmentga tegishli atributlarni policy qoidalari orqali baholash asosida beradigan access control modeli. To‘liq nomi Attribute-Based Access Control.

ABAC dinamik, kontekstga bog‘liq va nozik permissionlarni ifodalashga yordam beradi.

Asosiy elementlar

ABAC qarorida odatda to‘rtta element ishlatiladi:

Subject — request qilayotgan principal;
Object — murojaat qilinayotgan resource;
Action — bajariladigan operation;
Environment — vaqt, joy, qurilma va boshqa kontekst.

Policy shu atributlar kombinatsiyasini baholaydi.

Subject atributlari

Subject atributlari:

department;
role;
clearance;
tenant;
employment status;
device trust;
training status;
country;
authentication strength.

Atribut identity provider, HR tizimi yoki sessiondan olinishi mumkin.

Object atributlari

Resource xususiyatlari:

owner;
classification;
tenant;
project;
region;
data type;
sensitivity;
lifecycle state.

Masalan, classification=confidential bo‘lgan document uchun yuqori clearance talab qilinadi.

Action

Action faqat read va write bilan cheklanmaydi.

Masalan:

approve;
export;
share;
decrypt;
print;
delete;
transfer;
administer.

Bir resource’ni ko‘rishga ruxsat bo‘lib, export qilish taqiqlanishi mumkin.

Environment atributlari

Qaror tashqi kontekstga bog‘liq bo‘lishi mumkin:

vaqt;
location;
network;
device posture;
risk score;
emergency mode;
request channel.

Masalan, confidential data faqat managed qurilma va korporativ networkdan ochiladi.

Policy

Policy logical qoida sifatida yoziladi.

Masalan:

subject.department = Finance
AND object.classification <= subject.clearance
AND action = read
AND device.managed = true

Barcha shart bajarilsa access beriladi.

Policy Decision Point

PDP request atributlarini va policy’ni baholab allow yoki deny qarorini chiqaradi.

PDP:

markaziy service;
local library;
policy engine

bo‘lishi mumkin.

Qaror bilan reason yoki obligation qaytarilishi mumkin.

Policy Enforcement Point

PEP requestni ushlab, PDP qarorini amalda bajaradi.

Masalan:

API gateway;
application middleware;
database proxy;
file service.

PEP qarorni chetlab o‘tib resource’ga to‘g‘ridan-to‘g‘ri access bermasligi kerak.

Policy Information Point

PIP kerakli atributlarni taqdim etadi.

Manbalar:

identity provider;
HR;
device management;
asset catalog;
threat system;
database.

Atribut eskirgan yoki unavailable bo‘lsa qaror siyosati aniq bo‘ladi.

Policy Administration Point

Policy’ni yaratish, tasdiqlash va versionlash uchun boshqaruv qatlami.

Policy o‘zgarishi:

owner;
review;
test;
approval;
rollback;
audit

bilan boshqariladi.

Security qoidasi oddiy code change kabi nazoratsiz o‘zgarmaydi.

Deny by default

Kerakli atribut yetishmasa access odatda rad etiladi.

Masalan, device trust ma’lum bo‘lmasa trusted deb qabul qilinmaydi.

Bu fail-closed model.

Availability talabi bilan muvozanat policy’da belgilanadi.

Policy conflict

Bir policy allow, boshqasi deny berishi mumkin.

Combining algorithm:

deny-overrides;
permit-overrides;
first-applicable;
priority

kabi qoidani belgilaydi.

Conflict yashirin qolmasligi uchun policy test qilinadi.

RBAC bilan farqi

RBAC:

role → permission

ABAC:

atributlar + policy → qaror

RBAC tashkilot vazifalari barqaror bo‘lsa sodda.

ABAC ko‘p tenant, region, data classification va dynamic risk uchun moslashuvchan.

Hybrid model

Role subject atributlaridan biri sifatida ABAC policy’da ishlatilishi mumkin.

Masalan:

role = Doctor
AND object.patient_region = subject.region
AND device.managed = true

Bu RBACning tushunarliligini ABAC konteksti bilan birlashtiradi.

Attribute lifecycle

Noto‘g‘ri atribut noto‘g‘ri access qarorini beradi.

Shuning uchun:

source of truth;
update tezligi;
expiration;
ownership;
type;
allowed values

aniq bo‘ladi.

Xodim bo‘limdan ketganda department atributi tez yangilanadi.

Performance

Har requestda ko‘p tashqi tizimdan atribut olish latency yaratadi.

Yondashuvlar:

signed token ichidagi claim;
qisqa cache;
local policy;
batch lookup;
precomputed attribute.

Cache freshness security talabiga mos bo‘ladi.

Explainability

Nega access rad etilganini administrator tushuna olishi kerak.

Ammo clientga sensitive policy detail chiqarilmaydi.

Ichki audit:

qaysi policy;
qaysi atribut;
qaysi version;
allow yoki deny

ni saqlaydi.

Test

Policy testlari:

allow holat;
deny holat;
missing attribute;
conflict;
vaqt chegarasi;
tenant farqi;
device risk;
attribute yangilanishi;
policy version

ni qamrab oladi.

Policy as Code

ABAC policy version control’da code kabi saqlanishi mumkin. Pull request, test, approval va staged deployment orqali o‘zgaradi. Har qaror qaysi policy version bilan chiqarilgani auditda ko‘rsatiladi. Noto‘g‘ri policy tez rollback qilinadi.

Relationship atributi

Access faqat oddiy fieldlarga emas, subject va object orasidagi relationshipga bog‘liq bo‘lishi mumkin. Masalan, user project a’zosi yoki patientning assigned doctori ekanini tekshirish. Relationship manbasi trusted va yangilanadigan bo‘lishi kerak.

Policy simulation

Yangi policy productionga qo‘llanishidan oldin tarixiy requestlar yoki test dataset ustida simulate qilinadi. Qaysi qonuniy access bloklanishi va qaysi yangi access ochilishi ko‘riladi. Shadow mode qarorni log qilib, hali enforce qilmasligi mumkin.

Data classification

ABAC object atributlari to‘g‘ri classificationga tayanadi. Sensitive document noto‘g‘ri public deb belgilansa policy texnik jihatdan to‘g‘ri ishlasa ham access xato bo‘ladi. Classification automation, owner review va default restricted model bilan boshqariladi.

Emergency policy

Favqulodda vaziyatda ayrim accesslar vaqtincha kengaytirilishi mumkin. Emergency atributi, sabab, qisqa expiration va kuchli audit talab qilinadi. Emergency mode doimiy bypassga aylanib qolmasligi kerak.

Bog‘liq tushunchalar

Attribute-Based Access Control, Subject, Object, Action, Environment, Policy Decision Point, Policy Enforcement Point, RBAC, Authorization, Policy engine, IAM