Zona de administrare SaaS din spatele VPN-ului: în ce adresă să ai încredere?

Paginile publice SaaS pot rămâne deschise pentru toți, în timp ce operațiunile administrative din spatele lor resping oricine este în afara VPN-ului. Mecanismul care face asta posibil nu este un meniu ascuns și nici o pagină de autentificare separată; este o verificare a căii de rețea care a livrat cererea. Dacă dovada adresei este greșită, verificarea fie blochează administratorii reali, fie admite oricine poate tasta un antet. Începe cu ce primește de fapt originea.

Ce primește de fapt originea după tunel

Când un browser ajunge la site-ul public printr-un VPN care transportă și trafic de internet, gateway-ul traduce conexiunea înainte ca aceasta să iasă. SaaS-ul vede adresa de ieșire publică a gateway-ului, de obicei o singură adresă sau un interval mic, și nu vede niciodată adresa tunelului laptopului. De aceea adăugarea lui 10.90.0.42 în lista de permisiuni eșuează, și de aceea adăugarea întregului RFC 1918 eșuează și mai tare: a doua admite orice rețea privată care poate ajunge la tine. Singura adresă care merită o condiție este cea pe care organizația ta o deține efectiv la ieșire.

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

Tunelul divizat sparge această presupunere în liniște. Dacă VPN-ul transportă doar rute private de birou, cererea către numele de gazdă administrativ public iese prin furnizorul local și originea vede o adresă rezidențială. O pictogramă VPN conectată nu dovedește nimic despre această destinație anume, așa că testează destinația, nu tunelul.

Oprește-te și repară rutarea înainte de a scrie orice politică dacă adresa de ieșire variază pe utilizator. O condiție care se potrivește doar unor administratori este mai rea decât nicio condiție, pentru că ascunde problema până la un incident.

Ai încredere doar în proxy-ul care rescrie adresa

Majoritatea site-urilor publice stau în spatele unui CDN sau al unui proxy invers, așa că adresa de socket a originii aparține acelui frontend, nu vizitatorului. Frontendul transmite de obicei adresa originală într-un antet, și acel antet este controlat de un atacator dacă originea nu îl acceptă doar de la proxy-uri cunoscute. Configurează explicit lista surselor de încredere și fă originea inaccesibilă din orice alt loc. Fără acea a doua jumătate, un atacator ocolește proxy-ul și trimite antetul direct.

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

Același raționament se aplică protocolului PROXY: este de încredere doar când ascultătorul este legat de o interfață pe care proxy-ul o poate atinge și nimic altceva nu poate. Contextul de adresă lipsă trebuie să facă verificarea protejată să eșueze, nu să cadă într-o permisiune implicită. Un antet absent nu este dovada unei căi de încredere.

Atașează condiția la fiecare operațiune protejată

Pune verificarea la granița de autorizare prin care trece fiecare operațiune protejată, nu în pagina care randează meniul. Grupurile de rute, middleware-ul sau un strat de politici funcționează toate; o copie pentru fiecare handler nu, pentru că handler-ul adăugat de cineva în trimestrul următor nu o va avea.

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

Aceeași graniță trebuie să acopere API-ul JSON, exporturile, URL-urile de descărcare semnate și strângerea de mână WebSocket, fiindcă niciuna nu are nevoie ca pagina HTML să fie cerută mai întâi. Un link de descărcare creat cât timp VPN-ul era activ rămâne valid după aceea, dacă endpointul de descărcare nu verifică din nou. Sesiunile de lungă durată au nevoie și ele de o regulă de reevaluare, altfel o singură cerere autentificată devine o excepție permanentă. Respingerea implicită este singura setare care supraviețuiește fluctuației de personal.

Cache-urile partajate sunt cealaltă cale în jurul verificării. Un cache care deține deja un răspuns protejat îl poate servi fără a contacta originea, așa că marchează răspunsurile administrative ca private și ține-le în afara stocării partajate. Dacă un cache trebuie să le servească, verificarea accesului trebuie să ruleze înainte de servire, ceea ce înseamnă de obicei că nu poate fi deloc un cache partajat.

Testează ocolirile pe care tocmai le-ai închis

Exersează matricea, nu calea fericită: un administrator prin VPN, același administrator fără el, un neadministrator prin el și un antet de adresă falsificat. Adaugă o cerere directă la origine și o cerere cu răspuns din cache, pentru că acelea două ocolesc complet frontendul.

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'

Fiecare cerere ar trebui să returneze starea pe care o promite politica, iar jurnalul ar trebui să înregistreze ce dovadă a adresei a fost folosită. Acoperă IPv6 separat, pentru că o origine cu stivă dublă poate vedea o altă familie de surse decât cea testată. Menține operațiunile obișnuite ale clienților funcționale în afara VPN-ului, altfel schimbarea va fi anulată la prima reclamație a unui client. Scrie rezultatul așteptat pentru fiecare rând înainte de a-l rula, ca o trecere surprinzătoare să fie vizibilă.

Adresa de ieșire dovedește o cale de rețea permisă, nu o persoană și nu un dispozitiv administrat. Ține-o ca o singură condiție lângă autentificare și permisiune, iar zona de administrare rămâne îngustă fără a transforma întregul produs într-un serviciu doar pentru VPN. Acea separare este designul, nu o limitare a lui.