Zona e administrimit SaaS pas VPN-së: cila adresë duhet besuar?

Faqet publike SaaS mund të mbeten të hapura për të gjithë, ndërsa operacionet administrative pas tyre refuzojnë këdo jashtë VPN-së. Mekanizmi që e bën të mundur këtë nuk është një menu e fshehur as një faqe hyrjeje e veçantë; është një kontroll i rrugës së rrjetit që dërgoi kërkesën. Nëse prova e adresës është gabim, kontrolli ose bllokon administratorët e vërtetë ose pranon këdo që di të shkruajë një header. Filloni me atë që origjina merr në të vërtetë.

Çfarë merr në të vërtetë origjina pas tunelit

Kur një shfletues arrin faqen publike përmes një VPN që transporton edhe trafik interneti, porta përkthen lidhjen para se të dalë. SaaS shikon adresën publike dalëse të portës, zakonisht një adresë ose një interval të vogël, dhe nuk sheh kurrë adresën e tunelit të laptopit. Prandaj dështon shtimi i 10.90.0.42 në listën e lejuar, dhe prandaj dështon edhe më fort shtimi i të gjithë RFC 1918: i dyti pranon çdo rrjet privat që mund t'ju arrijë. E vetmja adresë që meriton një kusht është ajo që organizata juaj zotëron në të vërtetë në dalje.

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

Tunelimi i ndarë e thyen këtë supozim në heshtje. Nëse VPN transporton vetëm rrugë private zyre, kërkesa drejt emrit të hostit administrativ publik del përmes ofruesit lokal dhe origjina sheh një adresë banimi. Një ikonë e lidhur VPN nuk provon asgjë për këtë destinacion konkret, prandaj testoni destinacionin dhe jo tunelin.

Ndaloni dhe rregulloni rrugëtimin përpara se të shkruani çdo politikë nëse adresa dalëse ndryshon sipas përdoruesit. Një kusht që përputhet vetëm me disa administratorë është më keq se asnjë kusht, sepse e fsheh problemin deri në një incident.

Besoni vetëm proksin që e rishkruan adresën

Shumica e faqeve publike qëndrojnë pas një CDN ose një proksi të kundërt, prandaj adresa e socket-it të origjinës i përket asaj balline dhe jo vizitorit. Ballina zakonisht përçon adresën origjinale në një header, dhe atë header e kontrollon një sulmues nëse origjina nuk e pranon vetëm nga proksi të njohur. Konfiguroni shprehimisht listën e burimeve të besuara dhe bëni origjinën të paarritshme nga çdo vend tjetër. Pa atë gjysmën e dytë, një sulmues e anashkalon proksin dhe e dërgon header-in drejtpërdrejt.

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

I njëjti arsyetim vlen edhe për protokollin PROXY: është i besueshëm vetëm kur dëgjuesi është i lidhur me një ndërfaqe që proksi mund ta arrijë dhe asgjë tjetër nuk mundet. Konteksti i munguar i adresës duhet ta dështojë kontrollin e mbrojtur në vend që të bjerë në një leje të parazgjedhur. Një header që mungon nuk është provë e një rruge të besuar.

Lidhni kushtin me çdo operacion të mbrojtur

Vendosni kontrollin në kufirin e autorizimit nëpër të cilin kalon çdo operacion i mbrojtur, jo në faqen që vizaton menunë. Grupet e rrugëve, middleware ose një shtresë politikash funksionojnë të gjitha; një kopje për çdo trajtues nuk funksionon, sepse trajtuesi që dikush shton tremujorin e ardhshëm nuk do ta ketë.

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

I njëjti kufi duhet të mbulojë JSON API, eksportet, URL-të e shkarkimit të nënshkruara dhe shtrëngimin e duarve WebSocket, pasi asnjëri prej tyre nuk kërkon që faqja HTML të kërkohet së pari. Një lidhje shkarkimi e krijuar sa ishte VPN-ja aktive mbetet e vlefshme edhe më pas, përveç nëse pika e shkarkimit rikontrollon. Sesionet afatgjata kanë nevojë gjithashtu për një rregull rivlerësimi, përndryshe një kërkesë e autentikuar bëhet përjashtim i përhershëm. Mohimi i parazgjedhur është i vetmi rregullim që i mbijeton qarkullimit të stafit.

Cache-t e përbashkëta janë rruga tjetër rreth kontrollit. Një cache që mban tashmë një përgjigje të mbrojtur mund ta shërbejë pa kontaktuar origjinën, prandaj shënoni përgjigjet administrative si private dhe mbajini jashtë ruajtjes së përbashkët. Nëse një cache duhet t'i shërbejë ato, kontrolli i aksesit duhet të ekzekutohet para shërbimit, që zakonisht do të thotë se nuk mund të jetë fare cache e përbashkët.

Testoni anashkalimet që sapo mbyllët

Ushtroni matricën, jo rrugën e lumtur: një administrator përmes VPN-së, i njëjti administrator pa të, një jo-administrator përmes saj, dhe një header adrese i falsifikuar. Shtoni një kërkesë drejtpërdrejt në origjinë dhe një kërkesë me përgjigje të cache-uar, sepse këto të dyja e anashkalojnë plotësisht ballinën.

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'

Çdo kërkesë duhet të kthejë statusin që premton politika, dhe regjistri duhet të shënojë cila provë e adresës u përdor. Mbuloni IPv6 veçmas, sepse një origjinë me dy stack mund të shohë një familje burimesh të ndryshme nga ajo që testuat. Mbani operacionet e zakonshme të klientëve funksionale jashtë VPN-së, përndryshe ndryshimi do të kthehet mbrapsht herën e parë që një klient ankohet. Shkruani rezultatin e pritur për çdo rresht përpara se ta ekzekutoni, që një kalim befasues të jetë i dukshëm.

Adresa dalëse provon një rrugë rrjeti të lejuar, jo një person dhe jo një pajisje të menaxhuar. Mbajeni si një kusht pranë autentikimit dhe lejes, dhe zona e administrimit mbetet e ngushtë pa e kthyer të gjithë produktin në një shërbim vetëm për VPN. Ai ndarje është dizajni, jo një kufizim i tij.