VPN'dan VLAN'ga kirish: avval matritsa, keyin qoidalar
Bir tomonda rollar, boshqa tomonda xizmatlar. Beshta tekshiruv noaniq VPN'dan VLAN'ga kirish loyihasini firewall egasi joriy qila oladigan jadvalga aylantiradi.
Matritsadan boshlang, firewall sintaksisidan emas. Bir tomonda rollar, boshqa tomonda xizmatlar bo'lgan jadvalni ilova egasi ko'rib chiqishi, xavfsizlik egasi muhokama qilishi va shlyuzni ushlab turgan kishi joriy qilishi mumkin. Bu ko'rib chiqish hech kim kelishmagan qoidalarni tuzatishdan arzonroq.
Uni yozishga sarflangan bir soat keyin bir haftalik qoidalar arxeologiyasini tejaydi. Loyiha kim qaysi xizmatga yetib borishini gapiradi va qayta raqamlashdan keyin qoladigan qism ham shu.
1-qadam: rollarni tarmoqlardan oldin nomlang
Kommutatordan emas, odamlardan boshlang. Masofadan ulanadigan har bir guruhni va bu guruh nima qilishini tavsiflovchi bitta gapni yozing, masalan, zaxira darajasini o'qiydigan ombor xodimlari yoki bitta integratsiyani qo'llab-quvvatlayotgan pudratchi. Agar ikki guruh bir xil kirish olsa, bu maqsad uchun ular bitta rol.
Agar rol faqat tashkiliy sxema sababli bo'lsa, shu yerda to'xtang. O'ziga xos xizmat ehtiyoji bo'lmagan rol bir xil kataklar qatoriga aylanadi va bir xil qatorlar birovni keyinchalik qulaylik uchun butun quyi tarmoqni berishga undaydi. Odamlar nima qilishiga qarab bo'ling, ularning xarajatlariga kim imzo chekishiga qarab emas. Kichik ofis uchun oltita rol odatda ko'p va uchtasi ko'pincha to'g'ri.
2-qadam: har bir katakni xizmat bayonotiga aylantiring
«Ilovalar» deb yozilgan katakni tekshirib bo'lmaydi. «Xodimlar hovuzidan 443-portdagi ERP xostiga HTTPS» deb yozilgan katakni tekshirish mumkin. Har bir tarmoq nomini manzil, protokol va port bilan almashtiring, so'ng xizmat usiz ishlamaydigan bog'liqlikni qo'shing, masalan, ichki hal qiluvchi yoki identifikatsiya provayderi.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Yo'nalish ustuni eng qimmat xatolarni ushlaydi. Xodimlarga ilovani ochishga ruxsat ilova serverlariga xodimlarning noutbuklariga qaytib ulanish ochishga ruxsat degani emas va birinchi yo'nalishga ruxsat beruvchi holatli qoida ko'pincha ikkinchisiga ham ruxsat berayotgandek o'qiladi.
3-qadam: identifikatsiya qayerda siyosatga aylanishini hal qiling
Kimdir autentifikatsiyalangan sessiyani shlyuz qo'llay oladigan rolga aylantirishi kerak. Qo'llab-quvvatlanadigan variantlarga autentifikatsiya backend'i taqdim etadigan guruh siyosati, ishonchli sessiya atributlari yoki har bir rol uchun alohida manzillar hovuzlari kiradi. Uchtasi ham ishlaydi; mijoz yuboradigan yorliq ishlamaydi. Shlyuzingiz hujjatlashtiradigan mexanizmni tanlang, forum posti tasvirlaganini emas.
Faqat VLAN'ga tegishlidek ko'rinadigan manzil berish — boshqa libosdagi o'sha javobsizlik. OpenVPN firewall qoidalari bo'yicha Netgate qo'llanmasi bu ajratishni aniq ko'rsatadi: tunnelning ko'tarilishiga ruxsat berish undan trafik o'tishiga ruxsat berishdan boshqa qaror.
Qaysi mexanizmni tanlaganingizni va u qayerda sozlanganini yozing. Rol o'zgarganda, o'sha eslatma bitta tahrir va uchta interfeys bo'ylab qidiruv o'rtasidagi farq. U auditorga ham birinchi navbatda qayerga qarashni aytadi.
4-qadam: manzil ko'radigan manba manzilini kuzating
Yo'naltirish siyosati chegarada haqiqiy manbaga mos kelishi kerak. Agar shlyuz VPN mijozlarini o'z manziliga o'giradi, pastdagi har bir firewall bitta manba ko'radi va rol bo'yicha qaror qabul qilish qobiliyatini yo'qotadi. Agar mijoz manzilini saqlasa, o'sha hovuz uchun qaytish yo'li bo'lishi kerak.
Yakuniy qoidalarni yozishdan oldin ikkala yo'nalishni sinab ko'ring, so'ng kuzatilgan manbani har bir katak yoniga yozing. Xuddi shu tekshiruvni ikki xil roldan ishga tushiring va natijani solishtiring. Agar ikkalasi ham shlyuz manzilini ko'rsatsa, rollar farqi allaqachon yo'qolgan. Shlyuz manba tarjimasini amalga oshirayotganda saqlangan manzillarni taxmin qiladigan matritsa birinchi pastki ACL'da muvaffaqiyatsizlikka uchraydi.
5-qadam: chiqarishdan oldin har bir katakni sinab ko'ring
Har bir ruxsat etilgan katakni bitta vakillik operatsiyasiga, har bir rad etilgan katakni esa salbiy holatga aylantiring. Ikkalasini ham haqiqiy roldagi mijozdan ishga tushiring, shlyuz konsolidan emas, chunki konsol siz sinab ko'rayotgan yo'lni chetlab o'tadi.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'
Ulanadigan salbiy holat — bu topilma, tasodif emas va qoida tuzatilmaguncha uning o'rni matritsada muvaffaqiyatsiz katak. Sinov buyruqlarini jadval yonida saqlang, keyingi taqrizchi mulohazani qaytadan qurmasdan ularni qayta ishga tushirsin.
Tugallangan jadval u yozilgan shlyuzdan uzoqroq yashaydi. Qoidalar firmware va yetkazib beruvchi bilan o'zgaradi, pudratchi bitta loyiha xizmatiga yetib boradi degan qator esa o'sha ish o'zgarmaguncha to'g'ri qoladi.