SaaS administrativna zona iza VPN-a: kojoj adresi vjerovati?

Javne SaaS stranice mogu ostati otvorene za sve dok administrativne radnje iza njih odbijaju svakoga izvan VPN-a. Mehanizam koji to omogućava nije skriveni meni ni zasebna stranica za prijavu; to je provjera mrežnog puta koji je dostavio zahtjev. Pogriješite li s dokazom o adresi, provjera ili zaključa stvarne administratore ili propusti svakoga ko može otipkati zaglavlje. Počnite s onim što izvor zapravo prima.

Šta izvor zapravo prima nakon tunela

Kada preglednik dođe do javne stranice kroz VPN koji prenosi i internetski saobraćaj, pristupnik prevede vezu prije nego što izađe. SaaS vidi javnu izlaznu adresu pristupnika, obično jednu adresu ili mali raspon, i nikada ne vidi tunelsku adresu laptopa. Zato dodavanje 10.90.0.42 na listu dozvoljenih ne uspijeva, i zato dodavanje cijelog RFC 1918 ne uspijeva još glasnije: drugo propušta svaku privatnu mrežu koja može doći do vas. Jedina adresa koja je vrijedna uslova jeste ona koju vaša organizacija zaista posjeduje na izlazu.

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

Podijeljeno tuneliranje tiho ruši tu pretpostavku. Ako VPN prenosi samo privatne uredske rute, zahtjev za javno administrativno ime hosta izlazi kroz lokalnog ISP-a i izvor vidi stambenu adresu. Povezana ikona VPN-a ne dokazuje ništa o ovoj konkretnoj destinaciji, pa testirajte destinaciju, a ne tunel.

Zaustavite se i popravite usmjeravanje prije nego što napišete bilo kakvu politiku ako se izlazna adresa razlikuje po korisniku. Uslov koji odgovara samo nekima od administratora gori je od nikakvog uslova, jer skriva problem do incidenta.

Vjerujte samo proksiju koji prepisuje adresu

Većina javnih stranica stoji iza CDN-a ili obrnutog proksija, pa adresa utičnice izvora pripada tom prednjem sloju, a ne posjetiocu. Prednji sloj obično prosljeđuje originalnu adresu u zaglavlju, i to zaglavlje kontrolira napadač osim ako izvor prihvata samo od poznatih proksija. Konfigurirajte listu pouzdanih izvora izričito i učinite izvor nedostupnim sa bilo kojeg drugog mjesta. Bez te druge polovine napadač preskoči proksi i pošalje zaglavlje direktno.

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

Isto razmišljanje vrijedi i za PROXY protokol: pouzdan je samo kada je slušalac vezan za interfejs do kojeg proksi može doći i niko drugi ne može. Nedostajući kontekst adrese mora oboriti zaštićenu provjeru umjesto da padne na podrazumijevano dozvoljavanje. Zaglavlje koje nedostaje nije dokaz pouzdanog puta.

Priložite uslov svakoj zaštićenoj radnji

Stavite provjeru na granicu autorizacije kroz koju prolazi svaka zaštićena radnja, a ne na stranicu koja prikazuje meni. Grupe ruta, middleware ili sloj politike svi rade; kopija po rukovaocu ne radi, jer je rukovalac koji neko doda sljedećeg kvartala neće imati.

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

Ista granica mora pokriti JSON API, izvoze, potpisane URL-ove za preuzimanje i WebSocket rukovanje, jer nijednom od njih nije potrebna HTML stranica da bi bila prvo zatražena. Veza za preuzimanje stvorena dok je VPN bio aktivan ostaje važeća i poslije, osim ako krajnja tačka za preuzimanje ponovo provjeri. Dugotrajne sesije također trebaju pravilo ponovne procjene, inače jedan autentificirani zahtjev postaje trajno izuzeće. Podrazumijevano odbijanje jedina je postavka koja preživi promjenu osoblja.

Dijeljeni keševi su drugi put oko provjere. Keš koji već drži zaštićeni odgovor može ga poslužiti bez kontaktiranja izvora, pa označite administrativne odgovore kao privatne i držite ih izvan dijeljenog skladišta. Ako keš mora da ih poslužuje, provjera pristupa mora se izvršiti prije posluživanja, što obično znači da to nikako ne može biti dijeljeni keš.

Testirajte zaobilazne puteve koje ste upravo zatvorili

Vježbajte matricu, a ne sretan put: administrator kroz VPN, isti administrator bez njega, ne-administrator kroz njega i krivotvoreno zaglavlje adrese. Dodajte zahtjev direktno prema izvoru i zahtjev s keširanim odgovorom, jer su to dva koja potpuno preskaču prednji sloj.

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'

Svaki zahtjev treba vratiti status koji politika obećava, a dnevnik treba zabilježiti koji je dokaz o adresi korišten. Pokrijte IPv6 zasebno, jer dual-stack izvor može vidjeti drugu porodicu izvora od one koju ste testirali. Održavajte uobičajene korisničke radnje dostupnim izvan VPN-a, inače će promjena biti poništena prvi put kada se korisnik požali. Zapišite očekivani rezultat za svaki red prije pokretanja, kako bi iznenađujući prolaz bio vidljiv.

Izlazna adresa dokazuje dozvoljeni mrežni put, a ne osobu i ne upravljani uređaj. Držite je kao jedan uslov pored autentifikacije i dozvole, i administrativna zona ostaje uska bez pretvaranja cijelog proizvoda u uslugu samo za VPN. To razdvajanje je dizajn, a ne njegovo ograničenje.