Subject — xavfsizlik va dasturiy modelda obyekt ustida amal bajarishni so‘raydigan faol identitet yoki kuzatiladigan manba rolini bildiradi. Access control tizimida foydalanuvchi, xizmat hisobi yoki jarayon subject bo‘lishi mumkin; Observer patternda esa holati o‘zgarganda kuzatuvchilarga xabar beradigan obyekt subject deb ataladi. Kontekst ma’noni ajratadi.
Access control subyekti
Autentifikatsiya credentialni tekshirib principalni aniqlaydi. Runtime security context shu principal, rol, guruh, tenant, qurilma va sessiya atributlaridan subject hosil qiladi. Authorization siyosati subjectning resource ustida action bajarishiga ruxsat borligini baholaydi. Masalan, user:42 subjecti invoice:91 obyektini read qilishi mumkinmi degan qaror olinadi.
Subject har doim inson emas. Backend service, scheduled job, API client va workload identity ham amal tashabbuskori. “Tizimning o‘zi bajardi” audit uchun yetarli emas; qaysi xizmat, qaysi delegatsiya va qaysi asl foydalanuvchi nomidan ishlagani saqlanadi.
Delegatsiya va impersonation
Xizmat foydalanuvchi nomidan boshqa xizmatga murojaat qilsa, token audience, scope va delegation zanjiri cheklanadi. Asl subject bilan texnik caller alohida maydonda yuritiladi. Aks holda downstream log barcha amalni gateway nomiga yozib, javobgarlikni yo‘qotadi.
Administratorning impersonation funksiyasi support uchun kerak bo‘lishi mumkin. U aniq approval, vaqt chegarasi va ko‘rinadigan audit bilan ishlaydi. Impersonation sessiyasi oddiy admin sessiyasidan ajratiladi va maxfiy amallarni qayta tasdiqlash talab etilishi mumkin.
Subject atributlari
RBAC qarorni subject roliga asoslaydi. ABAC vaqt, joy, qurilma holati va ma’lumot tasnifi kabi atributlarni qo‘shadi. Atribut manbasi ishonchli va yangilanishi nazoratli bo‘lishi kerak. Foydalanuvchi HTTP headerda o‘zi yuborgan role=admin qiymati subject atributi sifatida qabul qilinmaydi.
Subject identifier barqaror bo‘lishi lozim. Email o‘zgarishi yoki qayta boshqa odamga berilishi mumkin, shuning uchun ichki immutable ID ishlatiladi. Hisob o‘chirilganda eski audit yozuvlari tarixiy subjectga bog‘langan holda qoladi.
Observer patterndagi ma’no
Observer dizaynida subject observerlar ro‘yxatini saqlaydi yoki event publisher orqali obunalarni boshqaradi. Holat o‘zgarganda notify chaqiriladi va observerlar yangilanadi. Push modelda subject yangi qiymatni yuboradi, pull modelda observer subjectdan kerakli holatni o‘qiydi.
Observer callbacki subject qulfini ushlab turgan paytda chaqirilsa, qayta kirish va deadlock yuz berishi mumkin. Obunadan chiqish, observer hayot sikli, notification tartibi va xato siyosati aniqlanadi. Xavfsizlikdagi subject bilan bu rolni aralashtirmaslik uchun kodda principal, publisher kabi aniqroq nomlar ko‘pincha foydali.
Audit semantikasi
Har audit yozuvi subject, action, resource, qaror, vaqt va qarorni bergan policy versiyasini saqlaydi. Autentifikatsiya qilinmagan so‘rov uchun ham anonymous subject yoki request ID ishlatiladi. Subject display name keyin o‘zgarsa tarixiy yozuvning immutable IDsi saqlanadi. Privacy talabi logda ortiqcha shaxsiy atribut yozmaslikni talab qiladi; diagnostika uchun zarur rol va tenant yetarli bo‘lishi mumkin. Distributed tracing subjectning to‘liq tokenini span atributiga yozmaydi. Token o‘rniga nazoratli pseudonymous ID berilib, maxfiy credential log va metric tizimiga tarqalishining oldi olinadi.
Subject bloklanganda faol sessiyalar, refresh tokenlar va delegatsiya zanjirlari qanday bekor qilinishi siyosatda ko‘rsatiladi. Faqat asosiy hisob statusini o‘zgartirish downstream keshlangan ruxsatni darhol to‘xtatmasligi mumkin. Revocation hodisasi xizmatlarga tarqatiladi, qisqa token muddati esa kechikish oqibatini cheklaydi.
Bog‘liq tushunchalar
Principal, Authorization, Security context, RBAC, Observer pattern, Resource