|
Axborot xavfsizligini ta’minlashning standart usullari
|
| bet | 109/118 | | Sana | 17.05.2024 | | Hajmi | 8,17 Mb. | | #240348 |
Bog'liq R. I. Isayev, D. X. Ibatova multimеdiali aloqa tarmoqlari toshkeAxborot xavfsizligini ta’minlashning standart usullari
Bir martalik parolli tizimlar. Bunday tizimlar (RFC-2289) oddiy parolli tizimlarga qaraganda ancha ishonchli hisobladi. Bunday tizimlarda IP-bog‘lama foydalanuvchining parolining nusxasini saqlamasligi va uni tarmoq orqali yubormasligi kerak. Biroq ma’lum xavf ehtimollari mavjud. Uzatilayotgan ketma-ketlik (bir martalik parol) foydalanuvchi parolidan shakllangani uchun, hujumlar avvalgidek real va amalga oshishi mumkin deb taxmin qilish mumkin. Bunday hujumlarni amalga oshirish uchun dasturdan hamma foydalanishi mumkin. Bundan tashqari, tizimdan foydalanish uchun ro‘yxatdan o‘tgan murojatlarning ma’lum sonidan keyin foydalanuvchining tizimga kirishini to‘xtatish kerak. Ko‘pgina tizimlarda bu funksiya ajralmas bo‘lishiga qaramay, avvalo uautentifikatsiya jarayoni uchun ma’lumotlar bazasini qayta ishga tushirish usuli sifatida zarur, bu yangi parolni tarmoq orqali ochiq ko‘rinishda uzatishni talab etmaydi.
Hozirgi paytda tijorat tarmog‘ining uskunalarini autentifikatsiyalash uchun maxsus belgilar qo‘llaniladi. “Aloqa seansiga bostirib kirish” deb ataluvchi hujumlardan himoyalanish bilan bog‘liq muammolarni yechishdan tashqari, bunday tizimlarda eng maxsus belgilarni uzatish uchun qo‘shimcha protokolli xabarlar kerak bo‘lishi mumkin (odatda bunday belgilar “so‘rov/javob” rejimida uzatiladi, bunda server har bir autentifikatsiyalash jarayoni davomida noyob taxminiy raqamni uzatadi).
HMAC-tizimlar. HMAC-tizimlari asosida (HMAC: Keyed-Hashingfor Message Authentication – maxfiy kalitni qo‘llab xesh-funksiyani hisoblash asosida xabarlarni autentifikatsiyalash tizimi, RFC-2104) oldindan taqsimlangan maxfiy kalitni qo‘llab autentifikatsiyalash usuli yotadi. Agar ikkala qatnashuvchi umumiy maxfiy kalitni bilsa, u holda HMAC-tizim istalgan erkin xabarni autentifikatsiyalash uchun qo‘llanilishi mumkin. Bunday usul tasodifiy raqamlar (metka) so‘rovlarini o‘z ichiga oladi, bu NMAS-tizimning avvalgi aloqa seanslaridagi xabarlarni qaytadan uzatishdan himoyalash uchun moslashish qobiliyatini anglatadi.
Afsuski, NMAS-tizimi ulanishlar autentifikatsiyasi uchun to‘g‘ri kelmaydi, chunki maxfiy kalit ochiq ko‘rinishda axborot uzatishni har bir tomonida ma’lum bo‘lishi kerak, bu ayniqsa uzoq vaqtli kalitlardan foydalanganda nomaqbul.
Qabul qilinishicha, NMAS-tizim xavfsizlikning eskiroq usullariga nisbatan afzalroq bo‘lib qo‘llanishi kerak, ayniqsa bu kalitni qo‘llagan xesh-funksiya hosoblariga tegishlidir. MD5 (RFC-1321) algoritmi asosidagi kalitlarni qo‘llaydigan oddiy xesh-funksiyalar, masalan, BGP-protokol (RFC-2385) xavfsizlikni yangi protokollari ro‘yxatidan o‘chirib yuborilyapti, bu xesh-funksiyalari past ishonchlilikka egaligi haqida xulosa chiqarishga imkon beradi.
NMAS-tizim istalgan xesh-funksiya bilan birgalikda, MD5-algoritmi va SHA-1 algoritmlari (RFC-3174) bilan qo‘llanishi mumkin. SHA-1 algoritmi yangi xavfsizlik protokollari uchun afzalroq, chunki bu maqsadlar uchun ko‘proq qo‘llaniladi va ishonchliroq bo‘lishi mumkin.
Tushunish muhimki, NMAS-xavfsizlikni ta’minlash usulini har bir protokolli xabarni himoyalash uchun qo‘llash zarur (kanal sathining kadri). Agar NMAS-tizimini faqat TCP-aloqa seansini boshlang‘ich fazasini autentifikatsiyalash uchun qo‘llanilsa, keyingi TCP-xabarlar hech qanday himoyasiz uzatilsa, katta xatolikka yo‘l qo‘yilgan bo‘ladi.
Hujum qiluvchi dasturiy modullar mavjud, ular TCP-aloqa seanslarini obro‘sini tushirish imkonini beradi. Buning uchun buzg‘unchiga bunday TCP-aloqa seansini obro‘sini tushirish uchunshunday dasturiy modulni qo‘llash zarur, bu NMAS-autentifikatsiyalash jarayoni yakunlangach amalga oshiriladi.
IPsec-arxitekturasi. IP-sathda (tarmoq sathida) IPsec-arxitekturasining asosini tashkil qiladigan autentifikatsiyalash va shifrlash protokollari RFC-4301, RFC-4302, RFC-4303, RFC-4306 va RFC-4307 standartlarida ifodalangan. Mohiyati bo‘yicha ushbu xavfsizlik arxitekturasi yuqori sathdagi protokollarni, TCR- va UDP-protokollarini ham himoya qiladi. U himoyalashni bir tekis taqsimlanishini ta’minlaydi, ya’ni “IP-bog‘lama - IP-bog‘lama”, “IP-bog‘lama - xavfsizlik shlyuzi” va “xavfsizlik shlyuzi - xavfsizlik shlyuzi”. IPsec-arxitekturasining funksional xususiyatlari foydalanuvchining o‘ziga himoyani taqsimlashga imkon beradi, ammo bu kamdan-kam sodir bo‘ladi. Aslida, agar himoyani taqsimlash IP-bog‘lamaning o‘zida bir jinsli bo‘lmasa, IPsec-arxitekturasini qo‘llash har qanday mazmunni yo‘qotadi.
Dasturiy IPsec-modul tarmoq sathining (IP-sath) dasturiy ta’minotiga o‘rnatilsa, u holda u bevosita dastur listingiga (dastur kodi) tatbiq etiladi. Bunday kiritish yo dasturiy-apparat qismni o‘zgartirishni, yo alohida protokollarni almashtirish bilan bog‘liq arxitekturani yangilashni talab qiladi. Boshqa tomondan, IPsec-arxitektura amaliy xizmatlar uchun mutlaqo shaffof. IPsec-protokollar ustida ishlaydigan amaliy xizmatlar o‘z protokollarida hech qanday o‘zgartirishlarsiz o‘z himoyalanganliklarini oshirishlari mumkin. Ammo hozir, IPsec-arxitekturasi Internet-tarmoqda birgalikdagi foydalanishni topguncha, ko‘pgina amaliy xizmatlar IPsec- protokollari ustidan faoliyat olib borishi haqida “taxmin” qilish kerak emas, bu ularni AXni ta’minlashni shaxsiy usullarida alternativi sifatida aks etadi. Ko‘pchilik zamonaviy operatsion tizimlar dasturiy IPsec-modul bilan birgalikda ishlay oladi, biroq, boshqarish nuqtai nazaridan ko‘pgina marshrutizatorlar - yo‘q. TLS-protokolni (Transport Level Security - TLS, RFC-2246) qo‘llaydigan amaliy xizmat, autentifikatsiyalashni ishonchli jarayonlarini o‘tkazishda shaxsiy xususiyatlarini hisobga olish uchun ko‘proq imkoniyatga ega. IPsec-arxitekturasi foydasiga kalitli axborotlarni boshqarish, elektron sertifikatlar yoki taqsimlangan maxfiy kalitlarni qo‘llashga asoslanadi. Bir nechta sabablarga ko‘ra sertifikatlar afzalroq, biroq ular tizim ma’muriyatiga “bosh og‘riq” bo‘lishi mumkin.
Hozirgi paytda IPsec-protokollari va NAT-modullarini (RFC-2993) ishlashi orasida jiddiy mojarolar mavjud. NAT-moduli istalgan protokol bilan birgalikda ishlay olmaydi, uning xabarlari qo‘shimcha joylashtirilgan IP-adreslarni o‘z ichiga oladi. Bu IPsec-protokollarga, agar ular sarlavhada bo‘lsa IP-adresga ega bo‘lgan yuqori sathdagi istalgan protokol xabarlari bilan har bir IP-paketga tegishli. Bu mojaroni ba’zida tunnellash rejimini (TR) qo‘llash hisobiga yechish mumkin, lekin bundan har doim ham bir necha sabablarga ko‘ra foydalanib bo‘lmaydi. IPsec-paketlar bilan NAT-modullarni oson yengishni ta’minlovchi standartni yaratish bo‘yicha ishlar olib borilmoqda.
IPsec-protokollar virtual korporativ tarmoqlarda Virtual Private Network - VPN) yanada kengroq qo‘llaniladi. Boshqa cheklanishlar uchrashidan kelib chiqqan xolda, IPsec-protokollari VPN-tarmoqlar o‘xshash xolatlarda ko‘proq qo‘llaniladi, ya’ni olisdagi kirish usulida. Bunda olisdagi kompyuter IPsec-protokolidan foydalanib Internet orqali o‘zini korporativ tarmog‘ida teskari tunnelni shakllantiradi (himoyalangan virtual bog‘lanish).
TLS-protokoli. Transport sathni xavfsizlik protokoli (Transport Level Security - TLS, RFC-2246) kanalni shifrlash va autentifikatsiyalashni ta’minlaydi, u TCR-protokoli qo‘llangan amaliy protokol bilan shakllantirilgan. TLS-protokoli W3–serverlarda qo‘llash uchun maxsus ishlab chiqilgan bo‘lishiga qaramay, bu uning qo‘llanish sohasini chegaralanishini anglatmaydi. Shunga qaramay, har bir amaliy protokol, TLS-protokolni qo‘llamoqchi bo‘lsa, oxirgining mantiqiy va jarayonli xarakteristikalariga moslashtirilgan bo‘lishi kerak. Odatda, server (“mijoz/server” ulanishida) doimo elektron sertifikat asosida autentifikatsiyalanadi. Foydalanuvchilar shuningdek sertifikatlarga ega bo‘lishi mumkin, uning yordamida autentifikatsiyalashni “qo‘lda” bajarish mumkin, shunga qaramay bu usul keng qo‘llanilmaydi. Afsuski, amaliyotda xatto serverni autentifikatsiyalash jarayoni kriptografik usullarga nisbatan unchalik himoyalanmagan, ular qo‘llanilishi mumkin, chunki amaliy protokollarning (xizmatlar) ko‘pchiligi foydalanuvchilarga autentifikatsiyalashning salbiy natijalarini rad etish imkonini beradi, foydalanuvchilarning ko‘pchiligi shunday qiladilar ham. Protokollarni ishlab chiquvchilar ochiq parollarni qo‘llash nuqtai nazaridan, hatto bog‘lanishlar TLS-protokollari yordamida himoyalangan bo‘lsa ham, ehtiyot bo‘lishlari kerak (agar amaliy xizmatlar server sertifikatsiyasi avtorizatsiyasini o‘tkazsa va aslligini verifikatsiyalay olsa bu talab bir oz yumshatilishi mumkin).
Amaliy xizmatga (protokol) o‘zgartirish kiritish zarurligiga qaramay, TLS-protokoldan foydalanish talab qilinadi, ayniqsa bunday xizmatni ta’minlaydigan vositalar (bepul va tijorat) zarur bo‘lgan joylarda. Bunday vositalar amaliy protokolning listing dasturlariga joylashtirish uchun ishlab chiqilgan. TLS-protokolni qo‘llovchi amaliy xizmat, o‘zining funksional xususiyatlaridan kelib chiqib, faqat IPsec-protokollarni qo‘llaydigan amaliy xizmatlarga nisbatan xavfsizlikni ta’minlashni to‘g‘ri keladigan strategiyasini o‘rnatish qobiliyatiga ega bo‘ladi.
SASL-interfeysi. Mohiyati bo‘yicha, AXni ta’minlashni kelishilgan usullari orqali aniqlanadigan, himoyalanganlik sathining parametrlari. Xususan, agar Axni ta’minlashni kelishilgan usuli barcha keyingi xabarlarni autentifikatsiyalamasa yoki TLS-protokoli kabi asosida yotgan xavfsizlik protokolidan foydalanmasa, barcha TCR-aloqa seanslari“ aloqaseansiga bostirib kirish” turidagi hujumlarga zaif bo‘lib qoladi.
Agarda TLS-protokolini (yoki IPsec-protokollarni) SASL-interfeysi bilan birgalikda qo‘llash kerak bo‘lsa (Simple Authentication and Security Layer- oddiy autentifikatsiyalash va xavfsizlikni ta’minlash sathi), u holda savollar tug‘iladi: “nima uchun birinchi navbatda SASL-interfeysi haqida o‘ylash kerak?” va “Nima uchun autentifikatsiyalash jarayonini amalga oshirish va ularni amalda qo‘llash bo‘yicha TLS-protokolning funksional imkoniyatlaridan foydalanishga harakat qilib ko‘rish mumkin emas?”.
Javob juda oddiy. TLS-protokoli autentifikatsiyalash foydasiga elektron sertifikatlarni yanada kengroq qo‘llashga imkon beradi. Ammo boshqa tomondan, sertifikatlarni tarqatish bo‘yicha muammolar mavjud, chunki faqat serverlar bunday sertifikatga ega, ayni damda foydalanuvchilar autentifikatsiyalangan (TLS-protokoli).
SASL-interfeysi foydalanuvchiga autentifikatsiyaning odatiy bo‘lgan usullarini qo‘llashga imkon beradi, masalan parolli tizimlar (bir martalik va b.q.). Bunday hollarda, yanada samarali bo‘lgan usullarni kombinatsiyasini ko‘rib chiqish foydaliroq, ya’ni TLS-protokoli serverni asosiy himoyasini va autentifikatsiyasini ta’minlaydi, SASL-interfeysi asosidagi autentifikatsiya tizimi esa foydalanuvchilarni tekshirishni ta’minlaydi. Eng jiddiy e’tibor “inson ulanish o‘rtasida” (Manin the Middle) turidagi hujumga bo‘lgan zaiflikni pasaytirishga qaratilishi kerak, ayniqsa dupleks ulanishning turli yo‘nalishlarida autentifikatsiyaning turli usullari qo‘llanilganda.
GSS-API-interfeysi. Yagona xavfsizlik xizmatining amaliy dasturiy interfeysi (Generic Security Service Application Program Interface-GSS-API, RFC-2744), autentifikatsiyalash jarayonlari, yaxlitlik va/yoki konfidensiallikni ta’minlashda amaliy xizmatlar foydasiga dasturiy vositalarni o‘zida ifodalaydi. SASL-interfeysidan farqli o‘laroq, GSS-API-interfeysi UDP-protokolda joylashgan amaliy xizmatlarni osonlik bilan qo‘llashi mumkin. GSS-API-interfeysi protokolli xabarlarda joylashishi mumkin bo‘lgan autentifikatsiyalash jarayonlari foydasiga kodli belgilarni generatsiyalash imkonini beradi. (Ilova. GSS-API-interfeysi taqdim qilgan xavfsizlik protokollari bilan ta’minlanadigan himoyalanganlik darajasi, AXni ta’minlashni bazaviy usullariga bog‘liq. Xuddi shu xolatdan bu protokollarning funksional mos kelishi ham ko‘rilishi mumkin.)
DNSsec-protokoli. DNSsec-protokolining asosiy vazifasi (RFC- 2535) -DNS-yozuvlarni ERI yordamida himoya qilish. ERI DNS-serverining kesh-xotirasida saqlanadigan DNS-yozuvlarni “kesh-xotirani ifloslanishi” turidagi hujumlardan himoyalaydi. Bu yozuvlar, o‘z navbatida, autentifikatsiyalash jarayonini buzish uchun DNS-nomi asosida, shuningdek trafikni buzg‘unchiga qayta yuborib yoki uni chetlab o‘tib qo‘llanishi mumkin. Oxirgisi DNS-tizimni AXni ta’minlashning boshqa usullarini juda kritik qilib qo‘yadi, ayniqsa bu IPsec-arxitekturasiga tegishli.
Odatda DNSsec-protokoli, IP-adresda DNS-nomlarni aks ettirishda ma’lumotlarni himoyalashni ta’minlashga imkon beradi. Shuningdek u aniq DNS-nom bilan bog‘liq boshqa DNS-ma’lumotlarni himoyalashda ham qo‘llanilishi mumkin. Bunday ma’lumotlar faqat xizmatchi bo‘lishi mumkin, bu ularni saqlaydigan DNS-serverning normal ishlashi uchun zarur bo‘ladi yoki himoyalangan virtual ulanish moslashtirilganda IPsec-arxitekturasini xavfsizlik protokollarida qo‘llaniladigan kalit bo‘lishi mumkin. DNS-tizimida umumiy tayinlangan amaliy kalitlarni saqlash konsepsiyasi RFC-3445 standartida “rad etilgan” edi, lekin unga qaramay, ba’zi amaliy xizmatlar foydasiga va xususan IPsec-arxitekturasi uchun kalitlarni saqlash jarayonini standartlashtirish davom etmoqda.
Ko‘p blokli xabarlarning xavfsizligi.RFC-1847 standarti, MIME-protokoli (RFC-2045) bilan aniqlanuvchi ko‘pblokli (ko‘p elementli) tuzilishga (Security/Multiparts) ega bo‘lgan elektron pochta xabarlarini himoya qilish usulini aniqlaydi. Yanada aniqrog‘i, Security/Multiparts-usuli MIME-protokolini to‘ldiradi, u MIME-xabarlarini shifrlash tartibi va qoidalarini va/yoki ularni ERI joylashtirishni aniqlaydi. Odatda ikkita protokol S/MIME (RFC-3156) va Open PGP (RFC-4880) o‘zining xabarlarini himoya qilishda Security/Multiparts-usullaridan foydalanadi. Ko‘pblokli pochta xabarlari tuzilmasini bila turib, qabul qiluvchi osongina xatning shifrlangan elementlarini aniqlashi va rasshifrovka qilishi mumkin.
Security/Multiparts-usuli “shaxsiy (abonentlik) xavfsizlik”ni (“object security”) ta’minlashning shakllaridan birini aks ettiradi, unda oxirgi foydalanuvchi uchun uning shaxsiy xabarlarini himoyalash, uni yetkazib berish usuli va bu xabarlarni oraliqdagi saqlanishidan qat’iy nazarasosiy talab hisoblanadi. Hozirgi paytda Internet-tarmog‘ida “shaxsiy xavfsizlik”ni ta’minlashning yagona shakli yo‘q.
S/MIME-protokolini elektron pochtadan farqli boshqa doirada qo‘llashda aloqa seansini o‘rnatish protokoli hisoblanadi (Session Initiation Protocol, RFC-3261).
Elektron raqamli imzo. O‘zaro munosabatdagi tomonlarni “so‘rov/javob” (“challenge/response”) rejimida autentifikatsiyalashda ERIni qo‘llash autentifikatsiyalashning yuqori ishonchliligini ta’minlaydi. Ochiq kalitli kriptografiyani qo‘llash maxfiy kalitlar qo‘llanadigan tizimlarda eng afzali hisoblanadi, chunki server foydalanuvchining maxfiy kalitini nusxasini saqlashga muhtoj emas. Foydalanuvchi maxfiy kalitga, serverlar esa unga mos keluvchi ochiq kalitga ega bo‘lsa maqsadga muvofiq bo‘ladi. Qat’iy aytganda, ERIni qo‘llash murakkab ish hisoblanadi. Foydalanuvchi hech qachon unga yuborilgan xabar/so‘rovga imzo qo‘ymasligi kerak.
Standart DSS-ERI (Digital Signature Standard - DSS, AQSh federal standarti) va RSA-ERI yaxshi ERI-algoritmlari hisoblanadi, ularning har biri o‘z afzalligiga ega. DSS-ERIni qo‘llash yaxshi ehtimollik xarakteristikali tasodifiy sonlar generatorini qo‘llashni talab qiladi (RFC-4086, Randomness Requirements for Security). Agar buzg‘unchi qandaydir ERI uchun tasodifiy sonni regeneratsiyalashga qodir bo‘lsa yoki agar foydalanuvchi bitta tasodifiy sonni ikkita har xil hujjatda qo‘llasa, u holda foydalanuvchining maxfiy kalitini aniqlash mumkin. DSS-ERI yangi maxfiy kalitlarni generatsiyasi nuqtai nazaridan RSA-ERIga nisbatan yaxshiroq parametrlarga ega, ERIni tekshirish nuqtai nazaridan RSA-ERI ancha yaxshi parametrlarga ega.
Open PGP-protokoli va S/MIME-protokoli. ERI “shaxsiy xavfsizlik”ni ta’minlovchi amaliy xizmatlarni qurishda qo‘llanishi mumkin, ularni elektron pochta protokoli kabi, xabarlarni saqlash va yetkazib berish protokollarida ma’lumotlarni himoyalash uchun qo‘llash mumkin.
Yuqorida ta’kidlab o‘tilganidek, elektronpochtaning ikkita turli himoyalangan protokollari OpenPGP (RFC-3156, RFC-4880) va S/MIME (RFC-2633), himoyalangan elektron pochtaning (Privacy Enhanced Mail - PEM) takomillashgan protokollarini o‘zgartirish uchun mo‘ljallangan. Bulardan qaysi biri muvaffaqiyatli bo‘lishi umuman aniq emas. Bularning ikkalasi himoyalangan elektron pochta bilan birgalikda ishlash uchun ishlab chiqilgan bo‘lishiga qaramay, ikkalasi ham boshqa protokollar tomonidan transportirovka qilinadigan ma’lumotlarni himoyalashga moslashtirilgan. Ikkalasi foydalanuvchilarni aniqlash uchun elektron sertifikatdan foydalanadi, ikkalasi pochta xabarlarining konfidensialligini va autentifikatsiyalashni ta’minlay oladi. Biroq sertifikatlarini formatlari ko‘pgina turlichadir.
Tarixan shunday bo‘lganki, pochta xizmatlari orasidagi asosiy farq (elektron pochta orqali xabarlarni yetkazib berish protokollari), OpenPGP va S/MIME, elektron sertifikatlar o‘zaro qanday bog‘langanligi turiga bog‘liq. S/MIME-xizmatda foydalanuvchilar X.509-sertifikatlarga ega (Tavsiyanoma ITU-T X.509), sertifikatlar bog‘langanligining tuzilmasi (sertifikatlash ustuni) uncha ko‘p bo‘lmagan “ildizli tugunlar”ga ega “daraxt”ni aks ettiradi. PGP - xizmatda umuman qarama-qarshi holat, unda “ishongan serverlar tarmog‘i”dan foydalaniladi, ya’ni istalgan foydalanuvchi kimningdir sertifikatini imzolashi mumkin. Bu holatda sertifikatlash ustuni haqiqatda erkin ustun yoki ustunlar yig‘indisini aks ettiradi.
Tarmoq ekranlari va topologiya. Tarmoq ekranlari (“firewall”) AXni ta’minlashni topologik usullarini aks ettiradi. Ya’ni, ular “yaxshi” tarmoq segmenti (korporativ tarmoqning ichki qismi) va segment bilan ulangan “yomon” tashqi tarmoq orasidagi aniq aniqlangan chegaraga bog‘liq, tarmoq ekranining o‘zi esa (TE) ular orasida bog‘lovchi bo‘g‘in bo‘lib xizmat qiladi, ular orqali axborot translyatsiya qilinadi. TE juda foydali bo‘lishiga qaramay, agar albatta ular tegishlicha qo‘llanilsa, tarmoqlarni himoyalash bo‘yicha ularning imkoniyatlarida ma’lum chegaralar mavjud.
Birinchi chegaralash shundan iboratki, TE o‘zi himoyalaydigan korporativ segmentlar ichidan boshlangan hujumlardan himoya bo‘la olmaydi. Bunday hujumlar oqibatining dolzarbligiga qaramay, bunday hujumlar salmog‘i noma’lum (ehtimol hech qachon ma’lum bo‘lmaydi ham), aynan shunday hujumlar AXni ta’minlashda ko‘pchilik muammolarning sababi bo‘lib qoladi. Agar bu muammoga kengroq nazar solsak, u holda TE aniq belgilangan chegarani talab qilishini taxmin qilib, shu darajagachaki, hatto bunday chegara yo‘qolib ketganda ham TE yordam bermaydi (umuman befoyda). Protokollar yordamida shakllanadigan istalgan tashqi ulanishlar, TE orqali xabarlarni atayin tarqatadigan, bir-biriga o‘tadigan tunnellashtirish rejimidagi istalgan aloqa kanallari, himoyalanmagan simsiz LHT yoki IP-bog‘lama bilan boshlanganto‘g‘ri tashqi ulanishlar korporativ hisoblanib, himoyalanganlik darajasini pasaytiradi. Agar foydalanuvchilar TE orqali trafikni uzatish uchun xavfsizlik protokollarini tunnellashtirish rejimida qo‘llasalar va tunnelning oxirgi nuqtalarida himoyalanganlikning nomaqbul sathini tanlagan bo‘lsalar, TE past samaradorlikka ega bo‘ladi. Agar tunnellanadigan trafik shifrlansa, u holda TE uni ko‘rib chiqolmaydi (nazorat qilolmaydi). TEning ko‘pincha keltiriladigan afzalliklari shundan iboratki, ular korporativ tarmoqning ichki tuzilmasini “tashqi ko‘zlardan” berkitadi (korporativ IP-bog‘lamalar tarkibi). Axborotni “chiqib ketishini” e’tiborga olib, kompyuterlarni muvaffaqiyatli niqoblash ehtimoli juda past.
Yanada tor yondashuvda, TE Internet-tarmog‘i vaInternet-protokollarda bir-biriga o‘tadigan ulanish modelini buzadi. Albatta, hamma protokollar ham o‘z xabarlarini TE orqali oson va xavfsiz tarqatishi mumkin. O‘zini TE yordamida himoyalaydigan tarmoqni korporativ segmentlari, Internet-tarmoqda yangi va foydali axborot manbalaridan “uzilgan” bo‘lishi mumkin.
Agar TE xavfsizlikni umumiy tuzilmasining bir elementi sifatida qo‘llanilsa yaxshiroq ishlaydi. Masalan, aniq sozlangan TE belgilangan W3-serverni funksional bo‘linishi uchun va ma’lumotlar bazasili serverda qo‘llanishi mumkin, ya’ni oxirgilar orasida faqat ochiq aloqa kanali bo‘lishi sharti (trafikni shifrlamasdan) bilan qo‘llaniladi. Xuddi shu tunnellashtirish rejimida faqat shifrlangan trafikni “o‘zidan o‘tkazadigan” TEga ham tegishli. Bunday TEni VPN-tarmoqning bitta segmentini himoya qilishda qo‘llash mumkin. Lekin boshqa tomondan, bu holatda VPN-tarmoqning boshqa segmenti xuddi shunday himoyalangan bo‘lishi kerak.
Kerberos-protokoli. Bu protokol (RFC-4120) ikkita o‘zaro ta’sirlashuvchi tomonlarning hamjihatlikdagi autentifikatsiyalash usuli va kalitli axborotlarni almashishni aniqlaydi. Foydalanuvchini dasturiy Kerberos-moduli maxsus “bilet” va “ishonch hujjatiga” ega. Keyinchalik bu xujjatlarning ikkalasi (ular shifrlangan ko‘rinishda saqlanishi kerak) foydalanuvchi va server o‘rtasida ulanishni o‘rnatish uchun qo‘llaniladi. Server keyin bu hujjatlarning haqiqiyligini tekshirishi mumkin. Shundan so‘ng server va foydalanuvchi dasturiy Kerberos-moduldan so‘rab olib ularga seans kalit ajratishni so‘rashi mumkin, u ma’lumotlarni shifrlash va yaxlitligini himoyalash uchun qo‘llaniladi.
Dasturiy Kerberos-modul shaxsiy protokollar doirasida qo‘llanilishi mumkin. Biroq u SASL-interfeysi va GSSAPI-interfeysi yordamida AXni ta’minlash usuli sifatida ham qo‘llanilishi mumkin. Hozirgi paytda bu protokolning ba’zi zaif tomonlari ham ma’lum, ammo shunga qaramay u himoyalangan variantda qo‘llanilishi mumkin.
SSH-protokoli. Bu protokol (Secure Shell — SSH) UNIX-o‘xshash tizimlarni dasturiy ta’minoti tarkibiga kiradi, “mijoz/server” ulanishni himoyasini ta’minlaydi. Funksional jihatdan u TLS-protokolini eslatadi, biroq u terminallar bilan olisdagi ulanishlarga xizmat qilish uchun optimallashtirilgan. SSH-protokolining eng ratsional xususiyatlaridan biri, u SSH-protokoli bilan himoyalangan, TCR-protokoli ustida joylashgan boshqa amaliy protokollarning xabarlarini yetkazib berishda tunnelli rejimni ta’minlaydi. Bu xususiyat AX sohasini yaxshi tushunadigan foydalanuvchilarga turli funksiyalarni bajarish, ya’ni himoyalanmagan server hamda tarmoqlar orqali pochta xabarlarini yoki yangiliklarni o‘qish va uzatish imkonini beradi. Ushbu protokol VPN-protokollarni almashtirish uchun mo‘ljallanmagan, ammo u ularning o‘rniga qo‘llanishi mumkin.
|
| |
