Sirlar va kalitlarni boshqarish: .env, tokenlar va rotatsiya

Har bir veb-ilova va mobil ilova sirlar bilan ishlaydi: ma'lumotlar bazasi paroli, APP_KEY, SMS yoki to'lov provayderi tokeni, SMTP paroli, tashqi API kalitlari. Kod qanchalik puxta yozilgan bo'lmasin, bitta sizib chiqqan token tizimga kirish uchun yetarli bo'lishi mumkin. Shuning uchun ekspertizadan oldin sirlarni "kodda yo'q" deb emas, "qayerda turibdi, kim ko'radi, qachon almashtirilgan" degan savollar bilan tekshirish kerak.

Sirlar qayerda yashaydi

Avval inventarizatsiya qiling. Odatda sirlar quyidagi joylarda topiladi:

• server'dagi .env fayli;
• repozitoriy va uning tarixi (eski commit'lar ham);
• CI/CD sozlamalari va build loglari;
• zaxira nusxalar (arxivda .env ham ketadi);
• ilova loglari (so'rov tanasi yoki sarlavhalar bilan birga);
• mobil ilova build'i (APK/IPA ichidagi satrlar);
• jamoa chatlari va hujjatlar.

Har bir sir uchun oddiy jadval tuzing: nomi, qaysi tizimga kirish beradi, kimda bor, oxirgi marta qachon almashtirilgan.

1. .env repozitoriyga tushmasin

.gitignore da .env borligini tekshiring, lekin bu yetarli emas — fayl ilgari commit qilingan bo'lishi mumkin. Tarixni skanerlang:

gitleaks detect --source . --log-opts="--all"

Agar tarixda haqiqiy sir topilsa, uni tarixdan o'chirish kamlik qiladi: repozitoriy nusxalari allaqachon boshqa joylarda bo'lishi mumkin. To'g'ri yechim — sirni almashtirish (rotatsiya). .env.example faylida faqat kalit nomlari va bo'sh yoki namunaviy qiymatlar bo'lsin.

2. .env brauzerdan ochilmasin

Laravel va boshqa freymvorklarda veb-server ildizi public/ katalogi bo'lishi kerak. Ildiz noto'g'ri sozlangan bo'lsa, https://sayt.uz/.env to'g'ridan-to'g'ri yuklanadi. Nginx'da qo'shimcha himoya:

location ~ /\.(?!well-known) {
    deny all;
}

Tekshirish: curl -I https://sayt.uz/.env va curl -I https://sayt.uz/.git/config — ikkalasi ham 403 yoki 404 qaytarishi kerak.

3. Fayl ruxsatlari

.env faqat ilova ishlaydigan foydalanuvchi va deploy foydalanuvchisi o'qiy oladigan bo'lsin:

chown deploy:www-data .env
chmod 640 .env

Bir server'da bir necha sayt bo'lsa, har biri alohida foydalanuvchi ostida ishlashi kerak. Aks holda bitta saytdagi zaiflik qo'shni saytning sirlarini ham ochib beradi.

4. Eng kam huquq tamoyili

Har bir token faqat kerakli ishni bajara olsin:

• ilova bazaga root yoki superuser bilan emas, faqat o'z bazasiga huquqi bor foydalanuvchi bilan ulansin;
• tashqi API kalitlari imkon bo'lsa IP yoki domen bo'yicha cheklansin;
• o'qish uchun kerak bo'lgan joyda yozish huquqi berilmasin;
• test va production uchun alohida kalitlar bo'lsin.

Shunda bitta kalit sizib chiqsa ham, zarar cheklangan bo'ladi.

5. Loglarda sir qolmasin

Xato loglari ko'pincha so'rovning to'liq tanasini yozadi: parol, OTP kodi, Authorization sarlavhasi. Loglash darajasini production uchun moslang, maxfiy maydonlarni niqoblang va storage/logs brauzerdan ochilmasligini tekshiring. Laravel'da APP_DEBUG=false bo'lishi ham shu bandning bir qismi: debug sahifasi muhit o'zgaruvchilarini ko'rsatishi mumkin.

6. Mobil ilovada sir saqlamang

APK yoki IPA'ni ochib, ichidagi satrlarni ko'rish qiyin emas. Shuning uchun ilova ichiga server tomonidagi maxfiy kalitlarni (to'lov provayderi maxfiy kaliti, admin token) joylashtirmang — ular faqat backend'da bo'lsin. O'z mahsulotimizning mobil ekspertizasida endpoint'lar ochiq satr sifatida saqlanmasligi, R8 minifikatsiya va Dart --obfuscate ishlatilishi, foydalanuvchi tokenlari esa flutter_secure_storage orqali Keystore/Keychain'da saqlanishi bo'yicha tuzatishlar kiritildi. Obfuskatsiya tahlilni qiyinlashtiradi, lekin sirni himoya qilmaydi — sir ilovada umuman bo'lmasligi kerak.

7. Rotatsiya: qachon va qanday

Rotatsiya — sirni yangisiga almashtirib, eskisini bekor qilish. Uni quyidagi hollarda albatta bajaring:

• sir repozitoriy, log yoki chatda ko'ringan bo'lsa;
• sirga kirishi bo'lgan xodim jamoadan ketsa;
• server yoki xodim kompyuterida shubhali holat bo'lsa;
• ekspertizadan oldin, agar sirlar uzoq vaqt almashtirilmagan bo'lsa.

Rotatsiyani xavfsiz bajarish tartibi:

1. Yangi kalitni yarating (provayder panelida yoki yangi parol).
2. Yangi qiymatni .env ga yozing va ilovani qayta yuklang (php artisan config:cache, PHP-FPM yoki queue worker'larni qayta ishga tushiring).
3. Ilova ishlayotganini tekshiring.
4. Eski kalitni provayder tomonida bekor qiling.
5. Jadvalda sanani yangilang.

Sirni o'chirish uni xavfsiz qilmaydi. Sizib chiqqan sir faqat almashtirilganda zararsizlanadi.

APP_KEY haqida alohida

Laravel'da APP_KEY cookie, sessiya va Crypt bilan shifrlangan ma'lumotlar uchun ishlatiladi. Uni shunchaki almashtirsangiz, faol sessiyalar va shifrlangan maydonlar o'qilmay qoladi. Laravel 11 dan boshlab APP_PREVIOUS_KEYS o'zgaruvchisi bor: eski kalitni u yerga yozing, shunda ilova eski ma'lumotlarni o'qiy oladi, yangilarini esa yangi kalit bilan shifrlaydi.

8. Zaxira nusxalar

Zaxira arxivlari ko'pincha butun loyiha katalogini, jumladan .env ni o'z ichiga oladi. Ularni veb-ildizdan tashqarida saqlang, shifrlang va kimga kirish borligini cheklang. backup.zip yoki site.tar.gz kabi fayllar public/ da qolib ketmaganini tekshiring.

Qisqa tekshiruv ro'yxati

• .env repozitoriyda va uning tarixida yo'q.
• /.env va /.git/config brauzerdan ochilmaydi.
• .env ruxsatlari 640, egasi to'g'ri.
• Bazaga ilova cheklangan foydalanuvchi bilan ulanadi.
• Loglarda parol, token, OTP yo'q.
• Mobil build ichida server sirlari yo'q.
• Har bir sir uchun egasi va oxirgi rotatsiya sanasi ma'lum.

Xulosa

Sirlarni boshqarish — murakkab vositalardan emas, tartibdan boshlanadi: inventarizatsiya, eng kam huquq, ochiq joylarni yopish va muntazam rotatsiya. Bu bandlar ekspertizada ham, kundalik ishlashda ham xotirjamlik beradi.

Sipar ekspertizadan oldin server sozlamalari, repozitoriy va build'larni sirlar bo'yicha ham tekshiradi va topilgan joylarni yopib beradi. Skanerlash so'rovini qoldiring.