SaaS administravimo sritis už VPN: kuriuo adresu pasitikėti?

Vieši SaaS puslapiai gali likti atviri visiems, o administravimo operacijos už jų atsisako visų, esančių už VPN ribų. Mechanizmas, kuris tai leidžia, nėra paslėptas meniu ar atskiras prisijungimo puslapis; tai tinklo kelio, kuriuo buvo pristatyta užklausa, patikra. Suklydus dėl adreso įrodymo, patikra arba užrakina tikrus administratorius, arba įleidžia bet ką, kas moka įvesti antraštę. Pradėkite nuo to, ką šaltinis iš tikrųjų gauna.

Ką šaltinis iš tikrųjų gauna po tunelio

Kai naršyklė pasiekia viešą svetainę per VPN, kuris taip pat perduoda interneto srautą, tinklų sietuvas išverčia ryšį prieš jam išeinant. SaaS mato viešą sietuvo išėjimo adresą, paprastai vieną adresą arba nedidelį diapazoną, ir niekada nemato nešiojamojo kompiuterio tunelio adreso. Štai kodėl nepavyksta įtraukti 10.90.0.42 į leidžiamų sąrašą, ir štai kodėl įtraukti visą RFC 1918 nepavyksta dar garsiau: antrasis įleidžia kiekvieną privatų tinklą, kuris gali jus pasiekti. Vienintelis adresas, vertas sąlygos, yra tas, kurį jūsų organizacija faktiškai valdo išėjime.

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

Skeltas tuneliavimas tyliai sugriauna šią prielaidą. Jei VPN perduoda tik privačius biuro maršrutus, užklausa į viešą administravimo mazgo vardą išeina per vietinį tiekėją, ir šaltinis mato gyvenamąjį adresą. Prisijungto VPN piktograma nieko neįrodo apie šią konkrečią paskirties vietą, todėl tikrinkite paskirties vietą, o ne tunelį.

Sustokite ir sutvarkykite maršrutizavimą prieš rašydami bet kokią politiką, jei išėjimo adresas skiriasi pagal vartotoją. Sąlyga, kuri tinka tik daliai administratorių, yra blogiau nei jokios sąlygos, nes ji slepia problemą iki incidento.

Pasitikėkite tik tuo tarpiniu serveriu, kuris perrašo adresą

Dauguma viešų svetainių yra už CDN arba atvirkštinio tarpinio serverio, todėl šaltinio lizdo adresas priklauso tam frontendui, o ne lankytojui. Frontendas paprastai persiunčia pradinį adresą antraštėje, ir tą antraštę kontroliuoja užpuolikas, nebent šaltinis priima ją tik iš žinomų tarpinių serverių. Aiškiai sukonfigūruokite patikimų šaltinių sąrašą ir padarykite šaltinį nepasiekiamą iš bet kur kitur. Be tos antrosios pusės užpuolikas apeina tarpinį serverį ir siunčia antraštę tiesiogiai.

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

Ta pati logika galioja PROXY protokolui: jis patikimas tik tada, kai klausytojas susietas su sąsaja, kurią tarpinis serveris gali pasiekti ir niekas kitas negali. Trūkstamas adreso kontekstas turi sugriauti apsaugotą patikrą, o ne nukristi į numatytąjį leidimą. Trūkstama antraštė nėra patikimo kelio įrodymas.

Prisekite sąlygą prie kiekvienos apsaugotos operacijos

Įdėkite patikrą į įgaliojimų ribą, kurią kerta kiekviena apsaugota operacija, o ne į puslapį, kuris atvaizduoja meniu. Maršrutų grupės, tarpinė programinė įranga arba politikos sluoksnis visi veikia; kopija kiekvienam apdorojimo įrenginiui ne, nes apdorojimo įrenginiui, kurį kas nors pridės kitą ketvirtį, jos nebus.

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

Ta pati riba turi apimti JSON API, eksportus, pasirašytus atsisiuntimo URL ir WebSocket rankos paspaudimą, nes nė vienam iš jų nereikia, kad HTML puslapis būtų pirmiausia užklaustas. Atsisiuntimo nuoroda, sukurta veikiant VPN, lieka galiojanti ir vėliau, nebent atsisiuntimo pabaigos taškas patikrintų iš naujo. Ilgalaikėms sesijoms taip pat reikia perkainojimo taisyklės, kitaip viena autentifikuota užklausa tampa nuolatine išimtimi. Numatytasis atsisakymas yra vienintelis nustatymas, kuris išgyvena darbuotojų kaitą.

Bendri podėliai yra kitas būdas apeiti patikrą. Podėlis, kuriame jau yra apsaugotas atsakymas, gali jį pateikti nesusisiekdamas su šaltiniu, todėl pažymėkite administravimo atsakymus kaip privačius ir laikykite juos už bendros saugyklos ribų. Jei podėlis privalo juos pateikti, prieigos patikra turi būti vykdoma prieš pateikimą, o tai paprastai reiškia, kad jis apskritai negali būti bendras podėlis.

Išbandykite apėjimus, kuriuos ką tik uždarėte

Praktikuokite matricą, o ne laimingą kelią: administratorius per VPN, tas pats administratorius be jo, ne administratorius per jį ir suklastota adreso antraštė. Pridėkite užklausą tiesiai į šaltinį ir užklausą su podėlyje saugomu atsakymu, nes būtent šie du visiškai apeina frontendą.

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'

Kiekviena užklausa turi grąžinti tą būseną, kurią žada politika, o žurnale turi būti įrašyta, koks adreso įrodymas buvo naudojamas. IPv6 apimkite atskirai, nes dvigubo steko šaltinis gali matyti kitą šaltinio šeimą nei ta, kurią išbandėte. Įprastas klientų operacijas palikite veikiančias už VPN, kitaip pakeitimas bus atšauktas, kai klientas pirmą kartą pasiskųs. Prieš paleisdami užrašykite kiekvienos eilutės laukiamą rezultatą, kad netikėtas praėjimas būtų matomas.

Išėjimo adresas įrodo leistiną tinklo kelią, o ne asmenį ir ne valdomą įrenginį. Laikykite jį viena sąlyga šalia autentifikavimo ir leidimo, ir administravimo sritis išlieka siaura, nepaverčiant viso produkto paslauga tik su VPN. Tas atskyrimas yra dizainas, o ne jo apribojimas.