Policy Enforcement Point (PEP) — himoyalangan resursga yo‘naltirilgan so‘rovni ushlab, avtorizatsiya qarorini amalda bajaradigan komponentdir. U Policy Decision Pointdan qaror oladi, ruxsat berilgan so‘rovni resursga uzatadi, rad etilganini esa to‘xtatadi. PEP API gateway, reverse proxy, middleware, service mesh yoki ilova ichidagi tekshiruv ko‘rinishida bo‘lishi mumkin.
So‘rov oqimi
PEP avval foydalanuvchi yoki xizmat identifikatorini tasdiqlangan autentifikatsiya kontekstidan oladi. Keyin amal, resurs va zarur muhit atributlarini standart so‘rovga aylantirib PDPga yuboradi. Qaror kelgach, permit bo‘lsa operatsiya davom etadi, deny yoki noaniq natija bo‘lsa to‘xtatiladi.
mijoz -> PEP -> PDP
<- permit/deny
-> himoyalangan xizmat
Resurs identifikatorini foydalanuvchi yuborgan satrdan olishning o‘zi yetmaydi. Masalan, /documents/42 so‘rovida hujjatning tenant va egasi ishonchli ma’lumotlar qatlamidan aniqlanadi. Aks holda hujumchi boshqa identifikatorni berib, noto‘g‘ri atribut bilan qaror chiqishiga erishishi mumkin.
To‘liq qamrov
PEPning eng muhim talabi barcha kirish yo‘llarini qamrab olishdir. Interfeys tugmasini yashirish, ammo API endpointni ochiq qoldirish nazorat hisoblanmaydi. Asosiy endpointdan tashqari eksport, ommaviy yuklash, fon vazifasi, WebSocket, ma’muriy va eski versiyadagi APIlar ham tekshiriladi.
Markaziy gateway tashqi trafikni qamraydi, lekin xizmatlararo ichki chaqiruv yoki to‘g‘ridan-to‘g‘ri navbat iste’molchisini ko‘rmasligi mumkin. Shu sabab bir nechta PEP qatlamlari ishlatiladi. Har qatlamning javobgarligi aniq bo‘lib, qarama-qarshi yoki takroriy tekshiruvlar nazorat qilinadi.
Majburiyatlarni bajarish
PDP qaror bilan qo‘shimcha obligation qaytarishi mumkin. PEP javob maydonini maskalash, audit hodisasini yozish, ma’lum tarmoq orqali yo‘naltirish yoki sessiyani kuchli autentifikatsiya qilishni talab etadi. Majburiyat bajarilmasa, ruxsat qarori to‘liq emas va so‘rov rad etiladi.
Ba’zi hollarda PEP faqat kirishni tekshirmay, natijani ham filtrlashi kerak. Ma’lumotlar bazasi so‘rovida tenant filtri qo‘shilishi yoki fayl yuklanishida hajm va tur cheklovi bajarilishi mumkin. Bunday o‘zgartirishlar yashirin yon ta’sirga aylanmasligi uchun hujjatlashtiriladi.
Xato va kechikish
PDP bilan aloqa uzilganda PEPning xatti-harakati oldindan belgilanadi. Himoyalangan operatsiyada fail closed odatda xavfsiz tanlovdir. Past xavfli o‘qish uchun qisqa muddatli, ilgari tasdiqlangan qaror keshdan olinishi mumkin, lekin siyosat va atribut yangiligi hisobga olinadi.
Avtorizatsiya har so‘rovda ishlagani uchun kechikish muhim. Qarorni batch qilish, mahalliy sidecar va ehtiyotkor kesh ishlatilishi mumkin. Optimallashtirish tenant yoki foydalanuvchi kontekstini aralashtirmasligi shart.
Audit va test
PEP so‘rov identifikatori, qaror, sabab kodi va siyosat versiyasini auditga uzatadi. Token yoki maxfiy atribut to‘liq jurnalga yozilmaydi. Testlar ruxsat va rad holatidan tashqari PDP timeouti, yetishmaydigan atribut, eskirgan kesh, ichki endpoint va majburiyat bajarilmasligini qamrab oladi. PEPni chetlab o‘tadigan tarmoq yo‘li arxitektura va xavfsizlik sinovida alohida izlanadi.
Identity uzatish
PEP upstream tasdiqlagan identityni backendga ishonchli shaklda uzatadi. Ochiq internetdan kelgan X-User-Role kabi header avval olib tashlanib, gateway tomonidan qayta yoziladi. Imzolangan token ishlatilsa, backend issuer va audience’ni tekshiradi. Proxy bilan backend orasidagi kanal autentifikatsiyasiz bo‘lsa, hujumchi PEPni chetlab to‘g‘ridan-to‘g‘ri so‘rov yuborishi mumkin.
Siyosat yangilanishi
Enforcement nuqtalari turli versiyada ishlaganda qaror semantikasi bir xil saqlanishi kerak. Capability discovery yoki minimal schema versiyasi mos kelmaydigan PEPni erta aniqlaydi. Policy rollout paytida eski va yangi natijalar shadow rejimida solishtirilib, qonuniy trafikning kutilmagan bloklanishi baholanadi.
Bog‘liq tushunchalar
Policy Decision Point, Policy engine, API gateway, Authorization, Access control, Service mesh, Default deny