SaaS-beheararea efter de VPN: hokker adres kinst fertrouwe?

Iepenbiere SaaS-siden kinne iepen bliuwe foar elkenien, wylst de behearoperaasjes dêrefter elkenien bûten de VPN wegerje. It meganisme dat dat mooglik makket is gjin ferburgen menu en ek gjin aparte oanmeldside; it is in kontrôle fan it netwurkpaad dat it fersyk levere hat. Krijst it adresbewiis ferkeard, dan slút de kontrôle echte behearders bûten of lit elkenien ta dy’t in kop tikje kin. Begjin mei wat de oarsprong eins ûntfangt.

Wat de oarsprong nei de tunel eins ûntfangt

As in browser de iepenbiere side berikt fia in VPN dy’t ek ynternetferkear draacht, oerset de gateway de ferbining foardat dy fuortgiet. De SaaS sjocht it iepenbiere útgongsadres fan de gateway, meastentiids ien adres of in lyts berik, en sjocht nea it tuneladres fan de laptop. Dêrom mislearret it tafoegjen fan 10.90.0.42 oan de tastiene list, en dêrom mislearret it tafoegjen fan hiel RFC 1918 noch lûder: it twadde lit elk privee-netwurk ta dat dy berikke kin. It iennichste adres dat in betingst wurdich is, is dat wat dyn organisaasje by de útgong eins besit.

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

Split-tuneling brekt dy oanname stil. As de VPN allinnich privee kantoarrûtes draacht, giet it fersyk nei de iepenbiere behearhostnamme fia de lokale provider nei bûten en sjocht de oarsprong in wenadres. In ferbûn VPN-ikoan bewiist neat oer dizze spesifike bestimming, dus test de bestimming en net de tunel.

Stop en meitsje it rûten yn oarder foardatst watfoar belied dan ek skriuwst as it útgongsadres per brûker ferskilt. In betingst dy’t allinnich by guon behearders past is slimmer as gjin betingst, want it ferberget it probleem oant in ynsidint.

Fertrou allinnich de proxy dy’t it adres weromskriuwt

De measte iepenbiere siden steane efter in CDN of omkearde proxy, dus it socketadres fan de oarsprong heart by dat frontend en net by de besiker. It frontend stjoert meastentiids it oarspronklike adres yn in kop troch, en dy kop wurdt troch in oanfaller kontrolearre, útsein as de oarsprong him allinnich fan bekende proxys akseptearret. Konfigurearje de list fan fertroude boarnen eksplisyt en meitsje de oarsprong ûnberikber fan oeral oars. Sûnder dy twadde helte slacht in oanfaller de proxy oer en stjoert de kop direkt.

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

Deselde redenearring jildt foar it PROXY-protokoll: it is allinnich betrouber as de listener bûn is oan in ynterface dy’t de proxy berikke kin en nimmen oars. Ûntbrekkende adreskontekst moat de beskerme kontrôle mislearje litte ynstee fan troch te fallen nei in standerttastimming. In kop dy’t ûntbrekt is gjin bewiis fan in fertroude rûte.

Heech de betingst oan elke beskerme operaasje

Set de kontrôle by de autorisaasjegrins dy’t elke beskerme operaasje passearret, net yn ’e side dy’t it menu rendert. Rûtegroepen, middleware of in beliedslaach wurkje allegear; in kopy per handler net, want de handler dy’t immen folgjend fearnsjier tafoeget hat him net.

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

Deselde grins moat de JSON API, eksporten, ûndertekene download-URL’s en de WebSocket-hânskikking dekke, want gjinien fan harren hat de HTML-side nedich om earst oanfrege te wurden. In downloadkeppeling dy’t makke is wylst de VPN oan wie, bliuwt dêrnei jildich, útsein as it download-einpunt wer kontrolearret. Langduorjende sesjes hawwe ek in werbeoardielingsregel nedich, oars wurdt ien authentisearre fersyk in permaninte útsûndering. Standertwegering is de iennichste ynstelling dy’t personielsferrin oerlibbet.

Dielde caches binne de oare manier om de kontrôle. In cache dy’t al in beskerme antwurd hat, kin it tsjinje sûnder de oarsprong te berikken, dus markearje behear-antwurden as privee en hâld se bûten dielde opslach. As in cache se tsjinje moat, moat de tagongskontrôle foar it tsjinjen rinne, wat meastentiids betsjut dat it hielendal gjin dielde cache wêze kin.

Test de omgongen dy’tst krekt sletten hast

Oefenje de matrix ynstee fan it lokkige paad: in behearder fia de VPN, deselde behearder sûnder, in net-behearder der troch, en in ferfalske adreskop. Foegje in fersyk direkt nei de oarsprong ta en in fersyk mei in cache-antwurd, want dy twa slane it frontend hielendal oer.

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'

Elk fersyk heart de status werom te jaan dy’t it belied ûnthjit, en it log heart te registrearjen hokker adresbewiis brûkt is. Dek IPv6 apart, want in dual-stack-oarsprong kin in oare boarnerfamylje sjen as dy’tst test hast. Hâld gewoane klantoperaasjes bûten de VPN wurkjen, oars wurdt de feroaring weromdraaid de earste kear dat in klant klaget. Skriuw it ferwachte resultaat foar elke rige foardatst dy rinne litst, sadat in ferrassend slagjen sichtber is.

It útgongsadres bewiist in tastien netwurkpaad, gjin persoan en gjin beheard apparaat. Hâld it as ien betingst njonken autentikaasje en tastimming, en it beheararea bliuwt smel sûnder it hiele produkt yn in allinnich-VPN-tsjinst te feroarjen. Dy skieding is it ûntwerp, net in beheining dêrfan.