SaaS-administrationsområde bag VPN’en: hvilken adresse kan du stole på?

Offentlige SaaS-sider kan forblive åbne for alle, mens de administrative handlinger bag dem afviser alle uden for VPN’en. Mekanismen, der gør det muligt, er ikke en skjult menu eller en separat login-side; det er et tjek af netværksstien, der leverede anmodningen. Tager du adressebeviset fejl, låser tjekket enten rigtige administratorer ude eller lukker alle ind, der kan skrive et header. Start med det, oprindelsen faktisk modtager.

Hvad oprindelsen faktisk modtager efter tunnelen

Når en browser når det offentlige websted gennem en VPN, der også bærer internettrafik, oversætter gatewayen forbindelsen, før den forlader. SaaS’en ser gatewayens offentlige udgående adresse, typisk én adresse eller et lille interval, og ser aldrig laptopens tunneladresse. Det er derfor, at allowlisting af 10.90.0.42 mislykkes, og hvorfor allowlisting af hele RFC 1918 mislykkes endnu højere: det andet lukker alle private netværk ind, der kan nå dig. Den eneste adresse, der er værd at betinge sig på, er den, din organisation faktisk ejer ved udgangen.

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

Split tunnelling bryder stille antagelsen. Hvis VPN’en kun bærer private kontorruter, forlader anmodningen til det offentlige admin-værtsnavn gennem den lokale udbyder, og oprindelsen ser en boligadresse. Et tilsluttet VPN-ikon beviser intet om netop denne destination, så test destinationen i stedet for tunnelen.

Stop og ret routing, før du skriver nogen politik, hvis udgangsadressen varierer pr. bruger. En betingelse, der kun matcher nogle administratorer, er værre end ingen betingelse, fordi den skjuler problemet indtil en hændelse.

Stol kun på den proxy, der omskriver adressen

De fleste offentlige websteder ligger bag en CDN eller omvendt proxy, så oprindelsens socket-adresse tilhører den frontend og ikke den besøgende. Frontenden videresender normalt den oprindelige adresse i et header, og det header kontrolleres af en angriber, medmindre oprindelsen kun accepterer det fra kendte proxies. Konfigurer listen over betroede kilder eksplicit, og gør oprindelsen utilgængelig fra alle andre steder. Uden den anden halvdel springer en angriber proxyen over og sender headeren direkte.

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

Samme ræsonnement gælder for PROXY-protokollen: den er kun troværdig, når lytteren er bundet til et interface, som proxyen kan nå, og intet andet kan. Manglende adressekontekst skal få det beskyttede tjek til at fejle i stedet for at falde igennem til en standardtilladelse. Et header, der mangler, er ikke bevis på en betroet sti.

Knyt betingelsen til hver beskyttet handling

Sæt tjekket i den autorisationsgrænse, som hver beskyttet handling passerer, ikke i siden, der renderer menuen. Rutegrupper, middleware eller et politiklag fungerer alle; en kopi pr. handler gør ikke, fordi den handler, nogen tilføjer i næste kvartal, ikke vil have den.

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

Den samme grænse skal dække JSON-API’et, eksporter, signerede download-URL’er og WebSocket-håndtrykket, da ingen af dem kræver, at HTML-siden anmodes først. Et download-link, der er oprettet, mens VPN’en var oppe, forbliver gyldigt bagefter, medmindre download-endpointet tjekker igen. Langvarige sessioner har også brug for en revurderingsregel, ellers bliver én autentificeret anmodning en permanent undtagelse. Standardafvisning er den eneste indstilling, der overlever medarbejderudskiftning.

Delte caches er den anden vej uden om tjekket. En cache, der allerede har et beskyttet svar, kan levere det uden at kontakte oprindelsen, så markér admin-svar som private og hold dem ude af delt lager. Hvis en cache skal levere dem, skal adgangstjekket køre før leveringen, hvilket normalt betyder, at det slet ikke kan være en delt cache.

Test de omveje, du lige har lukket

Gennemgå matricen i stedet for den glade vej: en administrator gennem VPN’en, den samme administrator uden den, en ikke-administrator gennem den, og et forfalsket adresse-header. Tilføj en anmodning direkte til oprindelsen og en anmodning med cachet svar, fordi det er de to, der springer frontenden helt over.

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'

Hver anmodning skal returnere den status, politikken lover, og loggen skal registrere, hvilket adressebevis der blev brugt. Dæk IPv6 separat, fordi en dual-stack-oprindelse kan se en anden kildefamilie end den, du testede. Hold almindelige kundehandlinger kørende uden for VPN’en, ellers bliver ændringen rullet tilbage første gang, en kunde klager. Skriv det forventede resultat for hver række, før du kører den, så et overraskende pass er synligt.

Udgående adresse beviser en tilladt netværkssti, ikke en person og ikke en administreret enhed. Hold den som én betingelse ved siden af autentificering og tilladelse, og admin-området forbliver smalt uden at gøre hele produktet til en VPN-only-tjeneste. Den adskillelse er designet, ikke en begrænsning i det.