Ilova xavfsizligi: mobil ilovada ma'lumotni himoyalash minimumi
Mobil ilova xavfsizligi uchun amaliy minimum: login, token saqlash, shifrlash va 2026-yilgi O'zbekiston talablari — tayyor tekshiruv ro'yxati bilan.
Unical IT
Ilova xavfsizligi haqidagi maqolalarning ko'pi o'nlab tahdidlarni sanab chiqadi-yu, savolga javob bermaydi: ilovani chiqarishdan oldin eng kamida nima qilish kerak? Bu post aynan shu haqda. Unda uchta asosiy narsa bor: autentifikatsiya, shifrlash va token saqlash. Ularga O'zbekiston qonunchiligi va mahalliy to'lov tizimlari bilan ishlashdagi o'ziga xos jihatlar qo'shilgan.
Maqola biznes egalari, mahsulot menejerlari va dasturchilarga mo'ljallangan. Oxirida ilovangizni yoki pudratchingiz ishini tekshirish uchun tayyor ro'yxat bor.
Nega aynan shu uchtasi?
Mobil xavfsizlik bo'yicha asosiy xalqaro yo'riqnoma — OWASP Mobile Top 10 ning 2024-yilgi yakuniy versiyasi. Ro'yxatning yuqori qismida quyidagilar turibdi:
- M1 — login ma'lumotlari va kalitlardan noto'g'ri foydalanish;
- M3 — xavfsiz bo'lmagan autentifikatsiya va avtorizatsiya;
- M5 — xavfsiz bo'lmagan aloqa (tarmoq);
- M9 — ma'lumotlarni xavfsiz bo'lmagan usulda saqlash;
- M10 — kriptografiyaning yetarli emasligi.
Ko'rinib turibdiki, o'ntadan beshtasi to'g'ridan-to'g'ri "kim kirayapti, ma'lumot qanday uzatiladi va qayerda saqlanadi" degan savollarga borib taqaladi. Bu uchta yo'nalishni to'g'ri qilsangiz, eng ko'p uchraydigan xatolarning katta qismini yopgan bo'lasiz.
1. Autentifikatsiya: o'zingiz yozmang
Birinchi va eng muhim maslahat: agar majbur bo'lmasangiz, autentifikatsiyani noldan yozmang. Parollarni xeshlash, sessiyalarni bekor qilish, urinishlar sonini cheklash, parolni tiklash — har birida nozik xatolar ko'p uchraydi.
Qachon tayyor yechim yetarli
Agar ilovangiz oddiy bo'lsa — katalog, buyurtma berish, sodiqlik dasturi — tayyor xizmatlar (Firebase Authentication, Supabase Auth, Auth0, Keycloak) ishni tezroq va ishonchliroq bajaradi. Bu holda alohida autentifikatsiya tizimi uchun pul to'lashning hojati yo'q, buni ochiq aytamiz.
Faqat bitta narsani tekshiring: foydalanuvchi ma'lumotlari qaysi davlatdagi serverda saqlanadi va bu O'zbekiston talablariga mos keladimi. Bu haqda quyida alohida bo'lim bor.
Qachon o'z tizimingiz kerak
- Foydalanuvchi bazasi 1C yoki mavjud CRM bilan qattiq bog'langan bo'lsa;
- Bir nechta rol bo'lsa (mijoz, menejer, filial rahbari, kuryer);
- Ma'lumotlar qonun bo'yicha O'zbekistonda qolishi shart bo'lsa.
Amaliy minimum
- Mobil ilovalarda OAuth 2.0 + PKCE. Mobil ilova "client secret"ni xavfsiz saqlay olmaydi: APK yoki IPA faylni ochib, ichidagi har qanday satrni o'qish mumkin. PKCE aynan shu muammoni hal qiladi.
- SMS orqali bir martalik kod (OTP) — to'g'ri cheklovlar bilan. O'zbekistonda telefon raqami bilan kirish odatiy hol, SMS esa mahalliy shlyuzlar orqali yuboriladi. Shartlar: kod 4–6 xonali, 2–5 daqiqa amal qiladi, bitta raqamga va bitta IP manzilga so'rovlar soni cheklangan. Cheklovsiz OTP endpoint ham ochiq eshik, ham har oy SMS uchun katta hisob.
- Avtorizatsiya faqat serverda tekshiriladi. Ilovada "Admin" tugmasini yashirish himoya emas. Har bir API so'rovida server "bu foydalanuvchi aynan shu buyurtmani ko'rishga haqlimi?" deb tekshirishi kerak. Eng ko'p uchraydigan xato:
niga almashtirib, birovning buyurtmasini ko'rish. - Biometrik kirish (Face ID, barmoq izi) — qulaylik uchun, asosiy himoya sifatida emas. U qurilmada saqlangan tokenni "qulfdan chiqaradi", serverga esa biometrik ma'lumot yuborilmaydi.
2. Token saqlash: eng ko'p xato qilinadigan joy
Foydalanuvchi tizimga kirgach, ilova token oladi. Qisqa muddatli access token API so'rovlari uchun ishlatiladi, uzoq muddatli refresh token esa yangi access token olish uchun. Bu tokenlarni qayerda saqlash juda muhim.
Qayerda saqlash mumkin va mumkin emas
| Saqlash joyi | Platforma | Token uchun yaroqlimi? | Izoh |
|---|---|---|---|
| Keychain | iOS | ✅ Ha | Tizim darajasida shifrlanadi. dan foydalaning |
| Keystore + EncryptedSharedPreferences / DataStore | Android | ✅ Ha | Kalit apparat darajasida himoyalangan bo'lishi mumkin |
, | Flutter / React Native | ✅ Ha | Ichida Keychain va Keystore'dan foydalanadi |
| SharedPreferences / UserDefaults (oddiy) | Android / iOS | ❌ Yo'q | Ochiq matn ko'rinishida saqlanadi |
| AsyncStorage | React Native | ❌ Yo'q | Shifrlanmagan |
| SQLite (shifrlanmagan) | Barchasi | ❌ Yo'q | Zaxira nusxalarda va root qilingan qurilmada o'qiladi |
| Kod ichida (hardcode) | Barchasi | ❌ Hech qachon | Ilovani ochib, darhol topish mumkin |
Tokenlar bilan ishlash qoidalari
- Access token muddati qisqa bo'lsin — daqiqalar, uzog'i bilan bir necha soat. Kunlar yoki oylar emas.
- Refresh token rotatsiyasi: har safar foydalanilganda yangisi beriladi, eskisi bekor qilinadi. Eski token qayta ishlatilsa, server butun sessiyani yopishi kerak, chunki bu o'g'irlik belgisi.
- "Barcha qurilmalardan chiqish" funksiyasi. Foydalanuvchi telefonini yo'qotsa, uni serverda bekor qila olishi kerak.
- Tokenni logga yozmang. Crashlytics, Sentry va konsol loglari ko'pincha tokenlar sizib chiqadigan joy bo'ladi.
- API kalitlari (xarita, SMS shlyuz, to'lov tizimi kalitlari) ilova ichida emas, serverda turishi kerak. Ilova so'rovni o'z serveringizga yuboradi, server esa tashqi xizmatga murojaat qiladi.
3. Shifrlash: tarmoqda va qurilmada
Tarmoqda (in transit)
- Faqat HTTPS, TLS 1.2 yoki undan yuqori. Android'da
sozlamasi, iOS'da ATS (App Transport Security) istisnolarsiz bo'lsin. - Sertifikatni tekshirishni o'chirmang. Test paytida "vaqtincha" o'chirilgan tekshiruv keyin production'ga ham o'tib ketishi tez-tez uchraydi.
- Certificate pinning — moliya, sog'liq yoki shaxsiy hujjatlar bilan ishlaydigan ilovalar uchun. Oddiy katalog ilovasi uchun bu ortiqcha murakkablik bo'lishi mumkin: sertifikat yangilanganda ilova ishlamay qolish xavfi bor. Pinning qilsangiz, albatta zaxira kalitni ham qo'shing.
Qurilmada (at rest)
- Iloji boricha kamroq ma'lumot saqlang. Ilova passport seriyasi yoki to'liq tranzaksiyalar tarixini qurilmada keshlashi shart emas.
- Saqlash zarur bo'lsa — SQLCipher yoki platformaning shifrlangan saqlash vositalaridan foydalaning, kalit esa Keystore yoki Keychain'da tursin.
- O'z shifrlash algoritmingizni o'ylab topmang. Standart kutubxonalar va AES-GCM kabi tekshirilgan rejimlardan foydalaning. OWASP'dagi M10 bandi aynan "o'zimiz yozib qo'ya qolamiz" degan yondashuv natijasidir.
Serverda
- Parollar faqat bcrypt, scrypt yoki Argon2 bilan xeshlanadi. MD5 va SHA-1 yaroqsiz.
- Ma'lumotlar bazasi zaxira nusxalari ham shifrlangan bo'lishi kerak. Ochiq S3 bucket yoki ochiq qoldirilgan bazaning zaxirasi butun bazaning sizib chiqishiga olib keladi.
O'zbekiston konteksti: nimani hisobga olish kerak
Shaxsga doir ma'lumotlar qonuni 2026-yilda o'zgardi
"Shaxsga doir ma'lumotlar to'g'risida"gi qonunning 27-1-moddasi uzoq vaqt O'zbekiston fuqarolarining shaxsiy ma'lumotlarini mamlakat ichidagi serverlarda saqlashni talab qilib kelgan. 2026-yil 26-martda imzolangan o'zgarishlarga ko'ra (Kun.uz, Daryo):
- Biometrik va genetik ma'lumotlar, shuningdek telekom operatorlari abonentlarining ma'lumotlari endi ham O'zbekistondagi serverlarda saqlanishi shart;
- Boshqa shaxsiy ma'lumotlarni chet elda saqlash mumkin, agar quyidagi shartlardan biri bajarilsa: davlat yetarli himoya darajasiga ega deb tan olingan, vakolatli organ tasdiqlagan standart shartnoma bandlari ishlatilgan yoki tasdiqlangan xalqaro standartlarga rioya qilingan.
Ilova uchun amaliy xulosa. Face ID va barmoq izi qurilmadan chiqmaydi, shuning uchun muammo tug'dirmaydi. Lekin ilovangiz KYC uchun selfi yoki yuz suratini serverga yuklasa, bu biometrik ma'lumot bo'lishi mumkin va mahalliy serverda saqlanishi kerak. Chet eldagi bulutli xizmatni tanlashdan oldin u mamlakatning tasdiqlangan ro'yxatda bor-yo'qligini tekshiring. Bu ma'lumotlar yangiliklar asosida berildi, aniq qaror qabul qilishdan oldin qonun matnini Lex.uz da ko'ring yoki yurist bilan maslahatlashing.
Payme, Click, Uzcard/Humo: karta ma'lumotlarini saqlamang
Ilovangizda to'lov bo'lsa, eng to'g'ri arxitektura bitta: karta raqami sizning serveringizga umuman kelmaydi. Karta ma'lumoti to'g'ridan-to'g'ri to'lov tizimiga yuboriladi, siz esa javob sifatida token olasiz. Payme, Click va boshqa mahalliy provayderlarning hujjatlarida kartalarni tokenlash va takroriy to'lov uchun API'lar bor. Ulardan foydalaning.
Yana ikkita mahalliy jihat:
- To'lov tizimidan keladigan callback'larni (to'lov tasdiqlangani haqidagi xabarlarni) imzo yoki login-parol orqali tekshiring. Aks holda kimdir "to'landi" degan soxta so'rov yuborishi mumkin.
- Merchant kalitlari faqat serverda turadi. Ilova ichida, GitHub'da yoki Telegram chatida emas.
1C va CRM bilan integratsiya
Ko'p mahalliy kompaniyalarda ilova 1C bilan to'g'ridan-to'g'ri bog'lanadi. Ba'zan 1C'ning HTTP-servisi internetga to'g'ridan-to'g'ri ochib qo'yilganini va unga "admin/admin" bilan kirish mumkinligini uchratamiz. To'g'ri sxema: ilova → sizning API serveringiz (autentifikatsiya, cheklovlar, loglar bilan) → ichki tarmoqdagi 1C. Bunday integratsiyalarni qanday qurish haqida CRM va ERP xizmatimiz sahifasida batafsil yozganmiz.
Ilovani chiqarishdan oldingi tekshiruv ro'yxati
Bu ro'yxatni ilovangiz yoki pudratchingiz ishiga qo'llab ko'ring. "Yo'q" deb belgilangan har bir band ochiq qolgan xavfdir.
Autentifikatsiya
- [ ] OTP so'rovlari raqam va IP bo'yicha cheklangan
- [ ] Noto'g'ri kod kiritish urinishlari soni cheklangan
- [ ] Har bir API endpoint foydalanuvchining huquqini serverda tekshiradi
- [ ] Boshqa foydalanuvchining ID'sini qo'yib, uning ma'lumotini olib bo'lmaydi
- [ ] "Barcha qurilmalardan chiqish" funksiyasi ishlaydi
Tokenlar va kalitlar
- [ ] Tokenlar Keychain yoki Keystore'da saqlanadi
- [ ] Access token muddati qisqa, refresh token rotatsiya qilinadi
- [ ] Ilova kodida API kaliti, parol yoki merchant ma'lumoti yo'q
- [ ] Loglarda token va shaxsiy ma'lumotlar yo'q
Shifrlash
- [ ] Barcha so'rovlar HTTPS orqali, sertifikat tekshiruvi yoqilgan
- [ ] Parollar serverda bcrypt yoki Argon2 bilan xeshlangan
- [ ] Zaxira nusxalar shifrlangan va ochiq joyda turmaydi
Qonun va to'lovlar
- [ ] Karta ma'lumotlari serverga kelmaydi, faqat to'lov tizimi tokeni saqlanadi
- [ ] To'lov callback'larining haqiqiyligi tekshiriladi
- [ ] Biometrik ma'lumotlar (agar serverga yuklansa) O'zbekistonda saqlanadi
- [ ] Foydalanuvchidan ma'lumotlarni qayta ishlashga rozilik olinadi
Qachon tashqi yordam kerak, qachon kerak emas
Ochiq aytamiz: oddiy ilova uchun yuqoridagi ro'yxatni tajribali dasturchi o'zi ham bajara oladi. Tayyor autentifikatsiya xizmati va platformaning standart xavfsiz saqlash vositalari ishning katta qismini hal qiladi.
Tashqi audit yoki tajribali jamoa quyidagi holatlarda kerak bo'ladi:
- ilova pul, hujjatlar yoki sog'liq ma'lumotlari bilan ishlasa;
- 1C, CRM va to'lov tizimlari bir vaqtda ulangan bo'lsa;
- ilova allaqachon ishlayotgan bo'lsa-yu, uni kim va qanday yozganini hech kim aniq bilmasa.
Unical IT veb va mobil ilovalar ishlab chiqishda shu ro'yxatni loyiha boshidanoq arxitekturaga kiritadi, chunki keyin tuzatish ancha qimmatga tushadi. Mavjud ilovangizni tekshirib ko'rmoqchi bo'lsangiz, biz bilan bog'laning. Hech bo'lmasa, qaysi bandlar ochiq qolganini aniqlab beramiz.
Yana o‘qing
Mobil ilova MVP uchun funksiyalarni qanday saralash kerak: ortiqcha imkoniyat byudjetni qanday yeydi, Payme/Click bilan amaliy misol va tayyor tekshiruv ro'yxati.
Mobil ilova qanday yaratiladi? 7 bosqich: har birida mijoz nima qilishi kerak, qancha vaqt ketadi, App Store va Google Play talablari va O'zbekiston nuanslari.
Apple Developer akkaunti, D-U-N-S, review jarayoni va eng ko'p uchraydigan rad sabablari: O'zbekistondagi biznes uchun nashrdan oldingi tekshiruv ro'yxati.