"Haram havola bosmang" degan maslahat — bu yolg'on xavfsizlik

Har yili xavfsizlik bo'yicha treninglarda foydalanuvchilarga bir xil narsa aytiladi: URLni tekshiring, HTTPS borligini qarang, parolni noma'lum saytlarda kiritmang. Nazariy jihatdan yaxshi maslahat. Ammo amalda biz autentifikatsiya tizimlarini shunday murakkab qilib qo'ydikki, foydalanuvchilardan har chorakda o'zgarib turadigan jumboqni yechishni talab qilayotganmiz.

Haqiqat shundaki: phishing — bu ko'pincha foydalanuvchining xatosi emas. Bu arxitektura xatosi.

Ishonchli saytlar ham aldamchi ko'rinishi mumkin

O'zingizning tashkilotdagi kirish jarayonini bir daqiqa ko'rib chiqing. Agar ko'pchilik kabi bo'lsangiz, kirish tugmasi foydalanuvchilarni uchinchi tomon identifikatsiya provayderlari, federatsiya xizmatlari va tokenizatsiya nuqtalari orqali yo'naltiradi. Bularning barchasi haqiqiy phishing xurujlariga juda o'xshaydi.

Masalan, shunday zanjir bo'lishi mumkin:

https://ilova.sizningkompaniya.uz → 
https://auth.identifikatsiya-providery.uz/sizningkompaniya →
https://sso.federatsiya-hizmati.uz/session/token →
https://verify.autentifikatsiya-protsessor.uz/mfa

Bu URL-larning hech biri sizning kompaniya domenida joylashgan emas. Hech biri esda qolmaydi. Hech biri foydalanuvchilarga haqiqiy va soxta narsani farqlash imkonini bermaydi.

Hujumkori bu tajribani takrorlash uchun atigi uch narsaga muhtoj: ishonchli shablon, o'g'irlangan logotip va parol kiritish maydonchasi. URL o'zi ma'nosiz bo'lib qoldi, chunki biz foydalanuvchilarni uni e'tiborsiz qoldirishga o'rgatdik.

URL-lar bu vazifa uchun yaratilmagan

Rostini aytganda, URL tuzilishi murakkab va biz texnik bo'lmagan foydalanuvchlardan uni dasturchilar kabi tahlil qilishni kutmasligimiz kerak.

Mana bu URLni ko'rib chiqing:

https://login.test.ichki.example-korporatsiya.uz/auth/tasdiqlash

Ko'pchilik "test" va "ichki" so'zlarini ko'rganda, ko'zlari yumiladi. Ular kompaniya nomini qidiradilar, topganda ham, atrofidagi infratuzilma ishonchli yoki yo'q — buni aniqlay olmaydilar.

Xost nomi aniqdan umumiyga o'qiladi (login → test → ichki → example-korporatsiya → uz). Ya'ni eng muhim belgi — asl domen — o'rtada berkitilgan. Foydalanuvchilar URL ichida brend nomini qayerda bo'lsa, shu yerda izlashni o'rganadilar. Bu esa aynan phishing hujumchilar foydalanadigan odat.

Protokol → Subdomenlar → Domen → TLD → Yo'l
    |          |           |       |      |
  HTTPS      login      example   uz    /auth

Dasturchilar buni intuitiv ravishda tushunadilar. Oddiy foydalanuvchilarga esa shunday murakkab URL-larni normal deb ko'rsatganda, ularga shans yo'q:

https://auth.kompaniya.shubhali-provayder.uz
https://kompaniya.auth-provayder.uz/sso/abc123
https://auth-provayder.uz/kompaniya-kirish

Dasturchilarning mas'uliyati

Mana bu yerda siz uchun muhim jihat bor: siz foydalanuvchilarni sukut bo'yicha himoya qiladigan autentifikatsiya tizimlarini loyihalash imkoniyatiga egasiz.

Foydalanuvchilarni uchinchi tomon domenlari orqali adashishga majbur qilish o'rniga, quyidagi tamoyillarni qo'llang:

1. O'zingizning identifikatsiya domenini boshqaring.

Asosiy brend domeni autentifikatsiyani amalga oshirishi kerak. Agar uchinchi tomon identifikatsiya provayderlaridan foydalanishingiz kerak bo'lsa, maxsus subdomen talab qiling:

✓ https://login.sizningkompaniya.uz
✗ https://auth.vendor.uz/sizningkompaniya

2. Doimiy subdomen iyerarxiyasi.

Agar asosiy ilovangiz app.kompaniya.uz da bo'lsa, autentifikatsiyangiz auth.kompaniya.uz da bo'lishi kerak — boshqa infratuzilma ostida uch daraja chuqurlikda emas.

3. Aqlli yo'naltirish.

Tashqi xizmatlarga (so'rovnomalar, to'lov protsessorlari, qo'llab-quvvatlash portallari) havola qilish kerak bo'lganda, o'zingizning domeningizdan server tomonidan yo'naltirishdan foydalaning. Bu foydalanuvchilarga doimiy tajriba beradi va "agar bizning domenimizdan kelmasa, biznikiga o'xshamaydi" degan hisni mustahkamlaydi.

4. SMS va telefon raqamlariga bir xil munosabatda bo'ling.

"Bu raqamga qo'ng'iroq qiling" yoki "bu kodni yuboring" xabarlari email havola qilari kabi xavfli. Har doim foydalanuvchilar allaqachon ishonadigan sahifada aloqa ma'lumotlarini ko'rsating.

Foydalanuvchilar bilan birga o'sadigan xavfsizlik qurish

RFC 2119 atamalari faqat byurokratik jargon emas — bu dizayn falsafasi. Autentifikatsiya xavfsizligi "TAVSIYA ETILADI" emas, balki "MAJMUR" bo'lganda, bugungi kun holatiga olamiz: federatsiya identifikatsiya xizmatlarining ochiq cho'li, ishonchli saytlar scam-lardan farq qilmaydigan darajada.

Xavfsizlikda g'olib bo'ladigan tashkilotlar — foydalanuvchilarni eng zaif bo'g'in deb hisoblashni to'xtatib, xavfsiz tanlovni oson tanlovga aylantiruvchi tizimlar quradiganlar.

Haqiqat shundaki: siz dizayn muammosini xavfsizlik treningi bilan yecholmaysiz.

Bu sizning startup yoki biznesingiz uchun nimani anglatadi

Agar autentifikatsiya jarayonlarini qurayotgan yoki saqlayotgan bo'lsangiz, hozir auditarov qilish vaqti keldi. O'zingizdan so'rang:

• Yangi foydalanuvchi URL orqali alone sizning kirish sahifangizni taniydimi?
• Barcha autentifikatsiya tajribalaringiz foydalanuvchilar tan olgan domenlar orqali o'tadimi?
• Uchinchi tomon xizmatlarining BYO domen imkoniyatlaridan foydalanayapsizmi, yoki ularning standart URL-larini qabul qilayapsizmi?

Bu faqat xavfsizlik spektakli haqida emas — bu ishonch qurish haqida. Autentifikatsiya tajribasiga ishonch hosil qilgan foydalanuvchilar, mahsulotingizga ishonadigan foydalanuvchilardir.

NameOceanda biz domen strategiyasi xavfsizlik arxitekturasi bilan qanday bog'liqligini ko'rdik. Sizning domeningiz — bu faqat manzil emas, bu foydalanuvchi ishonchining asosiy toshi. Uning siz uchun ishlashiga ishonch hosil qiling, xolos.