SaaS-hallinta-alue VPN:n takana: mihin osoitteeseen voi luottaa?

Julkiset SaaS-sivut voivat pysyä kaikille avoimina, kun taas niiden takana olevat hallintatoimet hylkäävät kaikki VPN:n ulkopuolella olevat. Mekanismi, joka tekee tämän mahdolliseksi, ei ole piilotettu valikko eikä erillinen kirjautumissivu; se on pyynnön toimittaneen verkkopolun tarkistus. Jos osoitetodiste on väärä, tarkistus joko lukitsee oikeat ylläpitäjät ulos tai päästää sisään kenet tahansa, joka osaa kirjoittaa otsakkeen. Aloita siitä, mitä alkuperä todella vastaanottaa.

Mitä alkuperä todella vastaanottaa tunnelin jälkeen

Kun selain saavuttaa julkisen sivuston VPN:n kautta, joka kuljettaa myös internettiliikennettä, yhdyskäytävä muuntaa yhteyden ennen kuin se lähtee. SaaS näkee yhdyskäytävän julkisen lähtevän osoitteen, tyypillisesti yhden osoitteen tai pienen vaihteluvälin, ja ei koskaan näe kannettavan tunneliosoitetta. Siksi 10.90.0.42-osoitteen lisääminen sallittujen luetteloon epäonnistuu, ja siksi koko RFC 1918:n lisääminen epäonnistuu vielä äänekkäämmin: jälkimmäinen päästää sisään jokaisen yksityisverkon, joka voi tavoittaa sinut. Ainoa ehdottamisen arvoinen osoite on se, jonka organisaatiosi todella omistaa uloskäynnissä.

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

Jaettu tunnelointi rikkoo tämän oletuksen hiljaa. Jos VPN kuljettaa vain yksityisiä toimistoreittejä, pyyntö julkiseen hallintakoneen nimeen lähtee paikallisen operaattorin kautta ja alkuperä näkee asuinosoitteen. Yhdistetty VPN-kuvake ei todista mitään tästä tietystä kohteesta, joten testaa kohdetta, älä tunnelia.

Pysähdy ja korjaa reititys ennen kuin kirjoitat yhtään käytäntöä, jos lähtevä osoite vaihtelee käyttäjittäin. Ehto, joka täsmää vain osaan ylläpitäjistä, on huonompi kuin ei ehtoa lainkaan, koska se piilottaa ongelman tapahtumaan asti.

Luota vain välityspalvelimeen, joka kirjoittaa osoitteen uudelleen

Useimmat julkiset sivustot ovat CDN:n tai käänteisen välityspalvelimen takana, joten alkuperän pistokkeen osoite kuuluu sille edustalle, ei kävijälle. Edusta välittää yleensä alkuperäisen osoitteen otsakkeessa, ja hyökkääjä hallitsee sitä otsaketta, ellei alkuperä hyväksy sitä vain tunnetuilta välityspalvelimilta. Määritä luotettujen lähteiden luettelo nimenomaisesti ja tee alkuperästä saavuttamaton kaikkialta muualta. Ilman tuota toista puoliskoa hyökkääjä ohittaa välityspalvelimen ja lähettää otsakkeen suoraan.

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

Sama päättely pätee PROXY-protokollaan: se on luotettava vain, kun kuuntelija on sidottu rajapintaan, johon välityspalvelin pääsee eikä mikään muu pääse. Puuttuvan osoitekontekstin on saatava suojattu tarkistus epäonnistumaan sen sijaan, että se putoaisi oletuslupaan. Puuttuva otsake ei ole todiste luotetusta polusta.

Liitä ehto jokaiseen suojattuun toimintoon

Aseta tarkistus valtuutusrajalle, jonka jokainen suojattu toiminto ylittää, älä valikkoon renderöivään sivuun. Reittiryhmät, middleware tai käytäntökerros toimivat kaikki; kopio per käsittelijä ei toimi, koska käsittelijässä, jonka joku lisää ensi neljänneksellä, ei sitä ole.

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

Saman rajan on katettava JSON API, vienti, allekirjoitetut lataus-URL:t ja WebSocket-kättely, koska mikään niistä ei vaadi HTML-sivun pyytämistä ensin. Latauslinkki, joka luotiin VPN:n ollessa päällä, pysyy voimassa sen jälkeen, ellei latauspäätepiste tarkista uudelleen. Pitkäikäiset istunnot tarvitsevat myös uudelleenarviointisäännön, muuten yhdestä todennetusta pyynnöstä tulee pysyvä poikkeus. Oletusarvoinen kieltäminen on ainoa asetus, joka kestää henkilöstön vaihtumisen.

Jaetut välimuistit ovat toinen tapa kiertää tarkistus. Välimuisti, jossa on jo suojattu vastaus, voi tarjoilla sen ottamatta yhteyttä alkuperään, joten merkitse hallintavastaukset yksityisiksi ja pidä ne poissa jaetusta tallennuksesta. Jos välimuistin on tarjoiltava ne, pääsytarkistus on ajettava ennen tarjoilua, mikä yleensä tarkoittaa, ettei se voi olla jaettu välimuisti lainkaan.

Testaa juuri sulkemasi ohitukset

Käytä läpi matriisi eikä onnellinen polku: ylläpitäjä VPN:n kautta, sama ylläpitäjä ilman sitä, ei-ylläpitäjä sen kautta ja väärennetty osoiteotsake. Lisää suoraan alkuperään menevä pyyntö ja välimuistiin tallennettu vastauspyyntö, koska juuri ne kaksi ohittavat edustan kokonaan.

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'

Jokaisen pyynnön pitäisi palauttaa tila, jonka käytäntö lupaa, ja lokiin pitäisi kirjata, mitä osoitetodistetta käytettiin. Kata IPv6 erikseen, koska kaksoispino-alkuperä voi nähdä eri lähdeperheen kuin testaamasi. Pidä tavalliset asiakastoiminnot toimivina VPN:n ulkopuolella, tai muutos perutaan, kun asiakas valittaa ensimmäisen kerran. Kirjoita jokaisen rivin odotettu tulos ennen sen ajamista, jotta yllättävä läpimeno on näkyvissä.

Lähtevä osoite todistaa sallitun verkkopolun, ei henkilöä eikä hallittua laitetta. Pidä se yhtenä ehtona todennuksen ja luvan rinnalla, ja hallinta-alue pysyy kapeana tekemättä koko tuotteesta vain VPN-palvelua. Tämä erottelu on suunnittelua, ei sen rajoitus.