Eng kam imtiyoz (least privilege)

Serverdagi har bir akkaunt, jarayon va servis o'z ishini bajarishi uchun qandaydir kirish huquqiga muhtoj. Lekin "qandaydir" va "berish qulay bo'lgancha" — bu juda boshqa-boshqa miqdorlar. Eng kam imtiyoz tamoyili (principle of least privilege) shuni aytadi: subyekt o'z vazifasini bajarishi uchun aynan kerak bo'lgan kirish huquqiga ega bo'lishi kerak, undan ortiq emas. Shu tarzda aytilganda bu o'z-o'zidan tushunarli tuyuladi. Amalda esa bu vaqt bosimi ostida eng ko'p voz kechiladigan tamoyil. Chunki keng kirish huquqini berish uni to'g'ri cheklashdan tezroq — toki biror narsa noto'g'ri ketmaguncha.

Bu maqola fayl ruxsatlari, ACL’lar yoki SELinux kontekstlarining mexanikasini qaytadan tushuntirmaydi — ular Fayl ruxsatlari, Fayl ruxsatlari xavfsizligi va SELinux va AppArmor maqolalarida chuqur ko'rib chiqilgan. Uning vazifasi — shu mexanizmlarni bu moduldagi deyarli har bir maqola ortidagi yagona tamoyil bilan bog'lash va "eng kam imtiyoz" bilan "qulaylik" odatda nega bir-biriga zid kelishini tushuntirish.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• eng kam imtiyoz tamoyilini ta’riflash va bu kontekstda "blast radius" (zarar radiusi) nimani anglatishini tushuntirish;
• Linux serverda eng kam imtiyoz qo'llaniladigan to'rtta joyni aniqlash: akkauntlar, jarayonlar, fayl tizimi va tarmoq;
• eng kam imtiyoz nega keyinchalik kirish huquqini olib tashlash orqali emas, default deny (standart bo'yicha rad etish) orqali ta’minlanishini tushuntirish;
• amalda eng kam imtiyozning vaqt o'tishi bilan yemirilishiga sabab bo'ladigan aniq murosani (trade-off) tanib olish.

Blast radius: bu nega muhimligining amaliy sababi

Eng kam imtiyozning qiymati mavhum emas — u blast radius ni cheklash bilan bog'liq: bitta buzib kirilgan credential, jarayon yoki akkaunt yetkaza oladigan zarar hajmi. Agar web ilovaning servis akkaunti faqat o'z konfiguratsiyasini o'qiy olsa va faqat o'z yuklash (upload) katalogiga yoza olsa, shu ilovadagi zaiflikdan foydalangan hujumchi aynan shu ikki imkoniyatni meros qilib oladi. U boshqa foydalanuvchilarning home kataloglarini o'qiy olmaydi, sudo ga ham, shu hostdagi ma’lumotlar bazasi serveriga ham kira olmaydi. Agar o'sha servis "sozlash osonroq bo'lgani uchun" root nomidan ishlaganida, xuddi shu zaiflik endi mashinaning to'liq buzib kirilishini anglatardi.

ps -eo user,pid,cmd | grep nginx

www-data   1842 nginx: worker process
www-data   1843 nginx: worker process
root       1840 nginx: master process

Master jarayonga 80/443-portga bog'lanish (bind) uchun qisqa vaqt root kerak bo'ladi, keyin u imtiyozlardan voz kechadi. Ishonchsiz mijoz ma’lumotlarini haqiqatan tahlil qiladigan worker jarayonlar esa imtiyozsiz www-data akkaunti nomidan ishlaydi. Bu jarayon darajasida qo'llanilgan eng kam imtiyoz. Web server buzib kirilishi kamdan-kam hollarda darhol root shell’ga olib kelishining sababi ham shu — worker jarayonning o'zida topshiradigan root shell yo'q.

Eng kam imtiyoz qo'llaniladigan to'rtta joy

Har bir qatlamda bir xil shablon takrorlanadi: standart holatda kirish huquqi yo'q, keyin aynan keraklisi beriladi. Keng kirish huquqini berib, keyinroq uni toraytirishni eslab qolishga urinilmaydi. Buni alohida ta’kidlash kerak, chunki ikkinchi yondashuv — keng boshlab, keyin toraytirish — tizim ishlay boshlagach, deyarli hech qachon amalga oshmaydi.

Tanlab olib tashlash emas, default deny

Bloklangan portlar ro'yxatidan tashqari barcha chiquvchi va kiruvchi trafikka ruxsat beradigan qilib sozlangan firewall eng kam imtiyozni qo'llamayapti. U blocklist qo'llayapti, bu esa faqat kimdir oldindan nomini aytib qo'ygan tahdidlarni to'xtatadi. Standart holatda hamma narsani rad etadigan va faqat servisga haqiqatan kerak bo'lgan portlarga aniq ruxsat beradigan firewall (Firewall va UFW maqolasida ko'rib chiqiladi) esa eng kam imtiyozni qo'llayapti. Chunki aniq ruxsat berilmagan har qanday narsa, jumladan hech kim bloklashni o'ylamagan narsalar ham rad etiladi.

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

Xuddi shu mantiq sudoers uchun ham amal qiladi. deploy ALL=(ALL) NOPASSWD: ALL kabi qoida hamma narsaga ruxsat beradi va akkaunt egasi undan suiiste’mol qilmaydi, degan umidga tayanadi. deploy ALL=(www-data) NOPASSWD: /usr/bin/systemctl restart myapp kabi qoida esa aynan bitta amalga ruxsat beradi, deploy akkaunti qilmoqchi bo'lgan har qanday boshqa narsa alohida, ongli ruxsatni talab qiladi. sudoers qoidalarini shu darajada aniq cheklash sudo xavfsizligi maqolasida ko'rib chiqiladi.

Amalda eng kam imtiyoz qayerda yemiriladi

Ishlab turgan serverda eng kam imtiyozdan uzoqlashishning ko'p qismini uchta shablon tushuntiradi:

• Sababidan uzoqroq yashab qolgan "hozircha" berilgan ruxsatlar. Dasturchiga production muammosini debug qilish uchun vaqtinchalik root huquqi beriladi va muammo hal bo'lgach, bu huquq hech qachon qaytarib olinmaydi.
• Ruxsat xatosini tahlil qilmaslik uchun berilgan keng ruxsatlar. chmod 777 yoki sudo ALL=(ALL) NOPASSWD: ALL darhol ko'rinadigan belgini "tuzatadi", lekin haqiqatda qaysi kirish huquqi yetishmayotganini hech kim aniqlamaydi. Bu shablon Fayl ruxsatlari xavfsizligi maqolasida bevosita ko'rib chiqilgan.
• Maqsadidan keyin ham saqlanib qolgan akkauntlar va ruxsatlar. Pudratchining akkaunti, bir martalik ma’lumotlar ko'chirish uchun ochilgan vaqtinchalik firewall qoidasi, allaqachon foydalanishdan chiqarilgan servis uchun yozilgan sudo qoidasi — har biri hech qanday faol asosi yo'q, lekin hali ham amalda bo'lgan ruxsat bo'lib qoladi.

Umumiy jihat shundaki, kirish huquqini berish — bitta, ko'rinadigan amal. Kerak bo'lmay qolganda uni olib tashlash esa kimdir uning eskirganini payqashini talab qiladi. Bu esa ongli, muntazam auditsiz kamdan-kam sodir bo'ladi. Modulning keyingi qismidagi Ruxsatlar auditi maqolasi aynan shunday muntazam jarayonni quradi.

Amaliy vaziyat: deployment akkauntini cheklash

Muammo. CI/CD pipeline har bir deployment’dan keyin serverdagi myapp servisini qayta ishga tushirishi kerak. U foydalanadigan akkauntda hozir to'liq sudo huquqi bor. Bu huquq boshida "sozlash paytida ruxsat muammolaridan qochish uchun" berilgan edi.

Joriy ruxsatni tekshirish:

sudo -l -U deploy

User deploy may run the following commands on prod-01:
    (ALL) NOPASSWD: ALL

Haqiqiy talabni aniqlash. Pipeline root nomidan (servislarni boshqarish buni talab qiladi) aynan bitta buyruqni — systemctl restart myapp ni — bajaradi, boshqa hech narsani emas.

Qoidani cheklash (to'liq sintaksis va visudo bilan tekshirish jarayoni uchun sudo xavfsizligi ga qarang):

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

Yangi ruxsat mo'ljallangan buyruqqa mos kelishini va faqat unga mos kelishini tekshirish:

sudo -l -U deploy

User deploy may run the following commands on prod-01:
    (root) NOPASSWD: /usr/bin/systemctl restart myapp

sudo -u deploy sudo -n /usr/bin/systemctl status myapp

Sorry, user deploy is not allowed to execute '/usr/bin/systemctl status myapp' as root on prod-01.

Xulosa. Pipeline’ning haqiqiy ishi — bitta servisni qayta ishga tushirish — avvalgidek ishlayveradi. Qolgan har qanday amal, jumladan servis holatini root sifatida o'qish ham, endi alohida, ongli ruxsatni talab qiladi. Agar deploy akkauntining credential’lari oshkor bo'lsa, blast radius butun mashina emas, bitta servisga qarshi bitta buyruq bo'ladi.

Keng tarqalgan xatolar

• Eng kam imtiyozga bir martalik sozlash qarori sifatida qarash. Tizim rivojlangani sari kirish talablari o'zgaradi. Bir yil oldin to'g'ri cheklangan ruxsat endi haddan tashqari keng bo'lishi yoki ishga qonuniy kerak bo'lgan biror narsani qamrab olmasligi mumkin. Har ikki holatda ham u bir martalik ko'rib chiqishni emas, davriy ko'rib chiqishni talab qiladi.
• Akkauntni cheklab, buyruqning o'z xatti-harakatini cheklamaslik. Bitta skript bilan cheklangan sudo qoidasi o'sha skript qanchalik tor bo'lsa, shunchalik tor. Agar skriptning o'zi ixtiyoriy argumentlarni qabul qilsa yoki uni aldab boshqa buyruqlarni ishga tushirtirish mumkin bo'lsa, cheklov shunchaki ko'rinish uchun. Bu holat sudo xavfsizligi maqolasida bevosita ko'rib chiqiladi.
• "Eng kam imtiyoz"ni "imtiyozsizlik" bilan chalkashtirish. Maqsad akkaunt yoki jarayonning o'z ishini bajarishiga to'sqinlik qilish emas. Qonuniy kerak bo'lgan narsani qila olmaydigan, haddan tashqari cheklangan servisga asabiylashib kengroq ruxsat berib yuboriladi va bu butun maqsadni yo'qqa chiqaradi. Maqsad — texnik jihatdan ishlaydigan eng kichik ruxsat emas, haqiqiy talabga mos keladigan ruxsat.

Mashqlar

1. O'zingiz boshqaradigan mashinada (yoki lab VM’da) ishlayotgan biror servisni tanlang va u qaysi akkaunt nomidan ishlashini aniqlang. Bu akkaunt servisning o'ziga kerak bo'lgandan ortiq biror narsa qila oladimi? Buni qanday tekshirgan bo'lardingiz?
2. Kirish huquqingiz bor tizimda hozir ishlatilayotgandan ko'proq huquq beradigan bitta sudo qoidasi, firewall qoidasi yoki fayl ruxsatini toping va qonuniy foydalanish holatini buzmasdan uni toraytiradigan eng kichik o'zgarishni tasvirlab bering.
3. Default deny firewall siyosati bloklangan portlar ro'yxati bilan default allow siyosatiga qaraganda eng kam imtiyozni nega samaraliroq qo'llashini o'z so'zlaringiz bilan tushuntiring.

Xulosa

Eng kam imtiyoz tizimning har bir qatlamida — akkauntlar, imtiyozni oshirish, fayl tizimi va tarmoqda — subyektga aynan kerak bo'lgan kirish huquqini berishni anglatadi, undan ortiq emas. U keyinchalik olib tashlash orqali emas, default deny siyosatlari orqali ta’minlanadi. Vaqt o'tishi bilan esa u maqsadidan uzoqroq yashab qolgan vaqtinchalik ruxsatlar va ruxsat muammosini tahlil qilmaslik uchun berilgan keng ruxsatlar tufayli yemiriladi. Keyingi maqola, sudo xavfsizligi, bu tamoyilni oddiy akkauntning root bo'lishining eng keng tarqalgan usuliga qo'llaydi.

Manbalar

• NIST SP 800-53: AC-6 Least Privilege
• CISA: Least Privilege
• man7.org: capabilities(7)