AWS Client VPN qoidalari subnetda emas, resursda bo‘lishi kerak

Xodimlar VPC dagi bitta ilovaga yetib borishi kerak va xuddi shu instansdagi ma’lumotlar bazasi tinglovchisiga yetib bormasligi kerak, shuning uchun kimdir VPN endpoint uchun ikkinchi ommaviy subnet qo‘shadi va talab bajarilgan deb e’lon qiladi. Subnetning joylashuvi marshrutlash va mavjudlikni o‘zgartiradi. U bitta portni ham bermaydi yoki olib qo‘ymaydi. Talabni ifodalovchi ruxsat manzil joyida, resursning xavfsizlik guruhida yashaydi va VPN chegarasi o‘sha qoida havola qiladigan dastakni beradi.

Subnetning joylashuvi marshrutlash, avtorizatsiya emas

Endpointning tarmoq bog‘lanishi qayerda joylashgani mijoz trafigini qaysi marshrut jadvali olib o‘tishini va qaysi mavjudlik zonalari nosozlikdan omon qolishini belgilaydi. U bu trafik qaysi instansning qaysi portiga yetishi mumkinligi haqida hech narsa demaydi. Bir subnetga bog‘langan ikki mijoz baribir bir xil manba identifikatori bilan keladi va resurs ularni subnet nomi bilan ajrata olmaydi.

Buning o‘rniga talabdan boshlang: kim chaqiradi, qaysi resurs, qaysi xizmat porti va qaysi yo‘nalish. Keyin o‘sha to‘rt narsani manzil joyida ifodalay oladigan qoida modelini tanlang. Bu yondashuv odatda ortiqcha subnetni loyihadan butunlay olib tashlaydi.

Client VPN bog‘lanish guruhi — aynan o‘sha dastak

Subnetga bog‘langan AWS Client VPN endpoint uchun hujjatlashtirilgan tartib aniq. Mo‘ljallangan xavfsizlik guruhini endpointning maqsadli tarmoq bog‘lanishlariga qo‘llang, so‘ngra o‘sha Client VPN guruhini manba sifatida ishlatib, resursning xavfsizlik guruhida kerakli trafikka ruxsat bering.

Aniqrog‘i, ilova instansining guruhi bog‘lanish guruhidan ilova portiga ruxsat beradi, boshqa hech narsaga emas. AWS ning resursga kirish tartibi bu munosabatni tavsiflaydi va endpoint bog‘lanadigan har bir subnetda bir xil guruh siyosatini saqlashga arziydi, chunki boshqa guruh bilan eskirgan bog‘lanish chegarani jimgina kengaytiradi.

Bu qoida hech kimni autentifikatsiya qilmaydi. Kirish alohida nazorat, resursga yo‘l esa uchinchisi. So‘rov kelishidan oldin uchalasi ham to‘g‘ri bo‘lishi kerak. Qaysi biri muvaffaqiyatsiz bo‘lsa, qaysi tuzatish to‘g‘ri ekanini o‘sha belgilaydi va qoidani o‘zgartirish faqat birinchisi uchun to‘g‘ri javob.

Bitta bog‘lanish guruhi ajrata olmaydigan narsa

Bir xil bog‘lanish guruhi orqasidagi har bir mijoz resursga bir xil xavfsizlik guruhi manbasi sifatida yetib boradi. Turli rollarga ega ikki foydalanuvchi bu qatlamda ajratib bo‘lmaydi, guruh qanday nomlangan yoki teglangan bo‘lishidan qat’i nazar. Client VPN ning tashqi guruh avtorizatsiyasi katalog yoki SAML guruhi uchun manzil prefiksi bo‘yicha kirishni cheklaydi, bu resurs rolidan dag‘alroq va uni identifikatsiya tizimi emas, tarmoq chegarasi sifatida ko‘rish kerak.

Nozikroq farqlar ilovaga tegishli. Ko‘pchilik xodimlar uchun yopiq qolishi kerak bo‘lgan ma’lumotlar bazasi tinglovchisini guruh a’zoligi tartibli qoladi deb umid qilishdan ko‘ra ruxsat etilgan prefiksda umuman yetib bo‘lmaydigan qilib himoya qilish yaxshiroq.

Guruh nomini o‘zgartirish identifikatsiya yaratmaydi va uni har bir jamoa uchun nusxalash faqat tekshiriladigan bog‘lanishlarni ko‘paytiradi.

Bu qoidani har bir VPN loyihasiga ko‘chirmang

O‘z-o‘zini boshqaradigan EC2 VPN darvozasi, marshrutlangan tekshiruv qurilmasi va boshqariladigan Client VPN uch xil paket yo‘lidir. Qaysi manba manzili resursga haqiqatda yetishini, yo‘lda tarjima bo‘lishini va xizmat o‘sha yo‘lda qaysi havola mexanizmlarini qo‘llab-quvvatlashini aniqlang.

Trafikni oraliq qurilma orqali o‘tkazish manba xavfsizlik guruhi havolasini to‘g‘ridan-to‘g‘ri instansdan-instansga trafik kabi saqlamaydi. AWS hujjatlashtiradiki, bunday loyihalarga guruh havolasi o‘rniga tegishli xususiy manba manzillari yoki CIDR kerak bo‘lishi mumkin. Boshqariladigan Client VPN tartibi har bir darvozaning ulangan guruhi uzatilgan paketlar uchun universal identifikatsiya belgisi bo‘lib ishlashiga dalil emas.

Yo‘ldagi bitta NAT sakrashi taxminni buzish uchun yetarli va nosozlik mavjud, ammo hech qachon mos kelmaydigan qoidaga o‘xshaydi.

Amaldagi chegarani ko‘rib chiqing

Resursga ulangan har bir xavfsizlik guruhini o‘qing, chunki ruxsat qoidalari qo‘shiladi va tor qoida boshqa guruhdagi kengroq qoidani bekor qilmaydi. So‘ngra tarmoq ACL ini, xost xavfsizlik devorini va ilovaning o‘z avtorizatsiyasini tekshiring, bular alohida xatolarga ega alohida qatlamlardir.

Xuddi shu resursga qarshi bitta ruxsat etilgan va bitta ataylab chiqarib tashlangan so‘rov bilan yakunlang. Bu juftlik chegarani isbotlaydi, bitta muvaffaqiyatli ulanish esa faqat biror narsa ochiqligini isbotlaydi. Endpointni o‘z ichiga olgan subnetni emas, yo‘lni, amaldagi manbani va mo‘ljallangan xizmat portini tasdiqlang.

Ish tartibi: to‘rt qismli talabni yozing, guruhni bog‘lanishlarga ulang, resurs qoidasini port bilan cheklang, bitta ruxsat va bitta radni tekshiring va shundan keyingina marshrutlash sabablari bilan subnetlarni bo‘lishni ko‘rib chiqing.