Administrační zóna SaaS za VPN: které adrese věřit?
Původ vidí odchozí adresu vaší VPN brány, ne tunelovou adresu notebooku. Věřte jen nakonfigurované hlavičce proxy a poté zabezpečte každou administrační operaci.
Veřejné stránky SaaS mohou zůstat otevřené všem, zatímco administrační operace za nimi odmítají každého mimo VPN. Mechanismus, který to umožňuje, není skryté menu ani samostatná přihlašovací stránka; je to kontrola síťové cesty, která požadavek doručila. Pokazte důkaz o adrese a kontrola buď vyřadí skutečné administrátory, nebo pustí každého, kdo umí napsat hlavičku. Začněte tím, co původ skutečně dostává.
Co původ po tunelu skutečně dostává
Když se prohlížeč dostane na veřejný web přes VPN, která přenáší i internetový provoz, brána spojení přeloží, než odejde. SaaS vidí veřejnou odchozí adresu brány, obvykle jednu adresu nebo malý rozsah, a nikdy nevidí tunelovou adresu notebooku. Proto selhává zařazení 10.90.0.42 na seznam povolených a proto selhává zařazení celého RFC 1918 ještě hlasitěji: druhé pustí každou privátní síť, která se k vám může dostat. Jediná adresa, která stojí za podmínku, je ta, kterou vaše organizace na výstupu skutečně vlastní.
curl -s https://ifconfig.me
dig +short admin.example.com
Rozdělené tunelování tento předpoklad tiše boří. Pokud VPN přenáší jen privátní kancelářské trasy, požadavek na veřejné administrační jméno hostitele odejde přes místního poskytovatele a původ vidí rezidenční adresu. Připojená ikona VPN o této konkrétní destinaci nic nedokazuje, takže testujte destinaci, ne tunel.
Zastavte se a opravte směrování, než napíšete jakoukoli politiku, pokud se odchozí adresa liší podle uživatele. Podmínka, která odpovídá jen některým administrátorům, je horší než žádná podmínka, protože skrývá problém až do incidentu.
Věřte jen proxy, která adresu přepisuje
Většina veřejných webů stojí za CDN nebo reverzní proxy, takže adresa socketu původu patří tomuto frontendu, a ne návštěvníkovi. Frontend obvykle předává původní adresu v hlavičce, a tuto hlavičku ovládá útočník, pokud ji původ nepřijímá jen od známých proxy. Nakonfigurujte seznam důvěryhodných zdrojů výslovně a udělejte původ nedostupným odkudkoli jinud. Bez této druhé poloviny útočník proxy obejde a hlavičku pošle přímo.
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
Stejná úvaha platí pro protokol PROXY: je důvěryhodný jen tehdy, když je posluchač vázán na rozhraní, kam se proxy dostane a nic jiného ne. Chybějící kontext adresy musí chráněnou kontrolu nechat selhat, místo aby propadla do výchozího povolení. Chybějící hlavička není důkazem důvěryhodné cesty.
Připojte podmínku ke každé chráněné operaci
Umístěte kontrolu na hranici autorizace, kterou prochází každá chráněná operace, ne na stránku, která vykresluje menu. Skupiny tras, middleware nebo vrstva zásad fungují všechny; kopie na každý handler ne, protože handler, který někdo přidá příští čtvrtletí, ji mít nebude.
user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)
Stejná hranice musí pokrýt JSON API, exporty, podepsané URL pro stahování a handshake WebSocket, protože žádný z nich nepotřebuje, aby byla nejprve vyžádána HTML stránka. Odkaz ke stažení vytvořený, dokud byla VPN zapnutá, zůstává poté platný, pokud koncový bod stahování znovu nezkontroluje. Dlouhodobé relace také potřebují pravidlo přehodnocení, jinak se jeden ověřený požadavek stane trvalou výjimkou. Výchozí zamítnutí je jediné nastavení, které přežije fluktuaci zaměstnanců.
Sdílené cache jsou druhou cestou kolem kontroly. Cache, která už drží chráněnou odpověď, ji může vydat, aniž by kontaktovala původ, takže označte administrační odpovědi jako soukromé a držte je mimo sdílené úložiště. Pokud je cache musí vydávat, kontrola přístupu se musí spustit před vydáním, což obvykle znamená, že to vůbec nemůže být sdílená cache.
Otestujte obejití, která jste právě uzavřeli
Procvičte matici, ne šťastnou cestu: administrátor přes VPN, stejný administrátor bez ní, neadministrátor přes ni a padělaná hlavička adresy. Přidejte požadavek přímo na původ a požadavek s odpovědí z cache, protože právě tyto dva frontend úplně přeskočí.
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'
Každý požadavek má vrátit stav, který politika slibuje, a log má zaznamenat, který důkaz o adrese byl použit. Pokryjte IPv6 zvlášť, protože dvouzásobníkový původ může vidět jinou rodinu zdrojů, než jakou jste testovali. Udržujte běžné zákaznické operace funkční mimo VPN, jinak bude změna vrácena při první stížnosti zákazníka. Napište očekávaný výsledek pro každý řádek před spuštěním, aby byl překvapivý průchod vidět.
Odchozí adresa dokazuje povolenou síťovou cestu, ne osobu a ne spravované zařízení. Držte ji jako jednu podmínku vedle autentizace a oprávnění a administrační zóna zůstane úzká, aniž by se celý produkt změnil ve službu jen pro VPN. Toto oddělení je návrh, ne jeho omezení.