VPN артындағы SaaS әкімшілік аймағы: қай мекенжайға сену керек?

Түпнұсқа VPN шлюзіңіздің шығыс мекенжайын көреді, ноутбуктің туннель мекенжайын емес. Тек конфигурацияланған прокси тақырыбына сеніңіз, содан кейін әр әкімшілік операцияны қақпалаңыз.

Жалпыға ашық SaaS беттері бәріне ашық қала алады, ал олардың артындағы әкімшілік операциялар VPN-нен тыс әркімді қабылдамайды. Мұны мүмкін ететін тетік жасырын мәзір де, жеке кіру беті де емес; ол сұранысты жеткізген желілік жолды тексеру. Мекенжай дәлелі қате болса, тексеру нақты әкімшілерді сыртта қалдырады немесе тақырып жаза алатын кез келгенді ішке жібереді. Түпнұсқа шын мәнінде не алатынынан бастаңыз.

Туннельден кейін түпнұсқа шын мәнінде не алады

Браузер интернет трафигін де тасымалдайтын VPN арқылы жалпыға ашық сайтқа жеткенде, шлюз қосылымды шығар алдында аударады. SaaS шлюздің жалпыға ашық шығыс мекенжайын көреді, әдетте бір мекенжай немесе шағын ауқым, және ноутбуктің туннель мекенжайын ешқашан көрмейді. Сондықтан 10.90.0.42-ді рұқсат етілгендер тізіміне қосу сәтсіз аяқталады, және сондықтан бүкіл RFC 1918-ді қосу одан да қатты сәтсіз аяқталады: екіншісі сізге жете алатын әрбір жеке желіні ішке жібереді. Шарт қоюға тұрарлық жалғыз мекенжай — ұйымыңыз шығыста шын мәнінде иеленетін мекенжай.

curl -s https://ifconfig.me
dig +short admin.example.com

Бөлінген туннельдеу бұл болжамды үнсіз бұзады. VPN тек жеке кеңсе маршруттарын тасымалдаса, жалпыға ашық әкімшілік хост атауына сұраныс жергілікті провайдер арқылы шығады және түпнұсқа тұрғын үй мекенжайын көреді. Қосылған VPN белгішесі осы нақты межелі орын туралы ештеңе дәлелдемейді, сондықтан туннельді емес, межелі орынды тексеріңіз.

Шығыс мекенжайы пайдаланушыға қарай өзгерсе, кез келген саясатты жазбас бұрын тоқтап, маршруттауды түзетіңіз. Тек кейбір әкімшілерге сәйкес келетін шарт шарттың жоқтығынан жаман, өйткені ол мәселені оқиғаға дейін жасырады.

Мекенжайды қайта жазатын проксиге ғана сеніңіз

Жалпыға ашық сайттардың көбі CDN немесе кері прокси артында, сондықтан түпнұсқаның сокет мекенжайы келушіге емес, сол фронтендке тиесілі. Фронтенд әдетте түпнұсқа мекенжайды тақырыпта жібереді, және бұл тақырыпты шабуылдаушы басқарады, егер түпнұсқа оны тек белгілі проксилерден қабылдамаса. Сенімді көздер тізімін анық конфигурациялаңыз және түпнұсқаны кез келген басқа жерден қолжетімсіз етіңіз. Осы екінші жартысыз шабуылдаушы проксиді айналып өтіп, тақырыпты тікелей жібереді.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

Дәл осы пайымдау PROXY хаттамасына да қатысты: ол тек тыңдаушы прокси жете алатын және басқа ешнәрсе жете алмайтын интерфейске байланғанда ғана сенімді. Мекенжай контекстінің болмауы қорғалған тексеруді сәтсіз етуі керек, әдепкі рұқсатқа түспеуі керек. Жоқ тақырып сенімді жолдың дәлелі емес.

Шартты әрбір қорғалған операцияға тіркеңіз

Тексеруді мәзірді бейнелейтін бетке емес, әрбір қорғалған операция өтетін авторизация шекарасына қойыңыз. Маршрут топтары, middleware немесе саясат қабаты — бәрі жұмыс істейді; әр өңдеушіге көшірме жұмыс істемейді, өйткені келесі тоқсанда қосылған өңдеушіде ол болмайды.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

Дәл осы шекара JSON API-ді, экспорттарды, қол қойылған жүктеу URL-дерін және WebSocket қол алысуын да қамтуы керек, өйткені олардың ешқайсысы алдымен HTML бетін сұрауды қажет етпейді. VPN қосулы кезде жасалған жүктеу сілтемесі жүктеу соңғы нүктесі қайта тексермесе, кейін де жарамды болып қалады. Ұзақ сессияларға да қайта бағалау ережесі қажет, әйтпесе бір аутентификацияланған сұраныс тұрақты ерекшелікке айналады. Әдепкіден бас тарту — қызметкерлер ауысқанда аман қалатын жалғыз параметр.

Ортақ кэштер тексеруді айналып өтудің екінші жолы. Қорғалған жауапты ұстап тұрған кэш оны түпнұсқаға хабарласпай ұсына алады, сондықтан әкімшілік жауаптарды жеке деп белгілеп, оларды ортақ қоймадан тыс ұстаңыз. Егер кэш оларды ұсынуға міндетті болса, қатынау тексеруі ұсынудан бұрын орындалуы керек, бұл әдетте оның мүлде ортақ кэш бола алмайтынын білдіреді.

Жаңа ғана жапқан айналып өтулерді тексеріңіз

Бақытты жолды емес, матрицаны жаттықтырыңыз: VPN арқылы әкімші, онсыз сол әкімші, ол арқылы әкімші емес адам және жалған мекенжай тақырыбы. Тікелей түпнұсқаға сұраныс және кэштелінген жауаппен сұраныс қосыңыз, өйткені дәл осы екеуі фронтендті толық айналып өтеді.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

Әрбір сұраныс саясат уәде еткен күйді қайтаруы керек, ал журнал қай мекенжай дәлелі пайдаланылғанын жазуы керек. IPv6-ны бөлек қамтыңыз, өйткені қос стекті түпнұсқа сіз тексергеннен өзге көз отбасын көруі мүмкін. Қарапайым тұтынушы операцияларын VPN-нен тыс жұмыс істеп тұрсын, әйтпесе тұтынушы бірінші рет шағымданғанда өзгеріс кері қайтарылады. Әр жолдың күтілетін нәтижесін іске қоспас бұрын жазыңыз, күтпеген өту көрінетін болсын.

Шығыс мекенжайы рұқсат етілген желілік жолды дәлелдейді, адамды да, басқарылатын құрылғыны да емес. Оны аутентификация мен рұқсаттың қасында бір шарт ретінде ұстаңыз, сонда бүкіл өнімді тек VPN қызметіне айналдырмай-ақ әкімшілік аймақ тар күйінде қалады. Бұл бөліну — дизайнның өзі, оның шектеуі емес.

Қатысты мақалалар