SaaS-administrationsområde bakom VPN: vilken adress kan man lita på?

Offentliga SaaS-sidor kan vara öppna för alla medan de administrativa åtgärderna bakom dem avvisar alla utanför VPN:en. Mekanismen som gör det möjligt är inte en dold meny eller en separat inloggningssida; det är en kontroll av nätverksvägen som levererade begäran. Om adressbeviset är fel låser kontrollen antingen ute riktiga administratörer eller släpper in alla som kan skriva en header. Börja med vad ursprunget faktiskt tar emot.

Vad ursprunget faktiskt tar emot efter tunneln

När en webbläsare når den offentliga webbplatsen via en VPN som också bär internettrafik, översätter gatewayen anslutningen innan den går ut. SaaS:en ser gatewayens offentliga utgående adress, vanligtvis en adress eller ett litet intervall, och ser aldrig laptopens tunneladress. Därför misslyckas det att lägga 10.90.0.42 i tillåtelselistan, och därför misslyckas det att lägga in hela RFC 1918 ännu högre: det andra släpper in varje privat nätverk som kan nå dig. Den enda adress som är värd ett villkor är den som din organisation faktiskt äger vid utgången.

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

Delad tunnling bryter tyst det antagandet. Om VPN:en bara bär privata kontorsrutter går begäran till det offentliga admin-värdnamnet ut via den lokala leverantören och ursprunget ser en bostadsadress. En ansluten VPN-ikon bevisar ingenting om just den här destinationen, så testa destinationen och inte tunneln.

Stanna och rätta routingen innan du skriver någon policy om den utgående adressen varierar per användare. Ett villkor som bara matchar några administratörer är sämre än inget villkor, eftersom det döljer problemet till en incident.

Lita bara på proxyn som skriver om adressen

De flesta offentliga webbplatser ligger bakom en CDN eller omvänd proxy, så ursprungets socketadress tillhör den frontenden och inte besökaren. Frontenden vidarebefordrar vanligtvis den ursprungliga adressen i en header, och den headern kontrolleras av en angripare om inte ursprunget bara accepterar den från kända proxyservrar. Konfigurera listan över betrodda källor explicit och gör ursprunget onåbart från alla andra platser. Utan den andra halvan hoppar en angripare över proxyn och skickar headern 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

Samma resonemang gäller för PROXY-protokollet: det är bara pålitligt när lyssnaren är bunden till ett gränssnitt som proxyn kan nå och inget annat kan. En saknad adresskontext måste få den skyddade kontrollen att misslyckas i stället för att falla igenom till ett standardtillstånd. En header som saknas är inte bevis på en betrodd väg.

Fäst villkoret vid varje skyddad åtgärd

Sätt kontrollen vid auktoriseringsgränsen som varje skyddad åtgärd passerar, inte i sidan som renderar menyn. Ruttgrupper, middleware eller ett policylager fungerar alla; en kopia per hanterare gör det inte, eftersom hanteraren som någon lägger till nästa kvartal inte kommer att ha den.

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

Samma gräns måste täcka JSON-API:et, exporter, signerade nedladdnings-URL:er och WebSocket-handskakningen, eftersom ingen av dem kräver att HTML-sidan begärs först. En nedladdningslänk som skapades medan VPN:en var uppe förblir giltig efteråt om inte nedladdningsslutpunkten kontrollerar igen. Långlivade sessioner behöver också en omvärderingsregel, annars blir en autentiserad begäran ett permanent undantag. Standardnekande är den enda inställningen som överlever personalomsättning.

Delade cachar är den andra vägen runt kontrollen. En cache som redan håller ett skyddat svar kan leverera det utan att kontakta ursprunget, så markera admin-svar som privata och håll dem utanför delad lagring. Om en cache måste leverera dem måste åtkomstkontrollen köras före leveransen, vilket vanligtvis innebär att den inte kan vara en delad cache alls.

Testa kringgåendena du just stängde

Öva matrisen i stället för den lyckliga vägen: en administratör genom VPN:en, samma administratör utan den, en icke-administratör genom den, och en förfalskad adressheader. Lägg till en begäran direkt till ursprunget och en begäran med cachat svar, eftersom det är de två som hoppar över frontenden helt.

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'

Varje begäran bör returnera den status som policyn lovar, och loggen bör registrera vilket adressbevis som användes. Täck IPv6 separat, eftersom ett dual-stack-ursprung kan se en annan källfamilj än den du testade. Håll vanliga kundåtgärder igång utanför VPN:en, annars rullas ändringen tillbaka första gången en kund klagar. Skriv det förväntade resultatet för varje rad innan du kör den, så att ett överraskande godkänt är synligt.

Den utgående adressen bevisar en tillåten nätverksväg, inte en person och inte en hanterad enhet. Håll den som ett villkor bredvid autentisering och behörighet, och adminområdet förblir smalt utan att göra hela produkten till en VPN-only-tjänst. Den separationen är designen, inte en begränsning av den.