SaaS administrēšanas zona aiz VPN: kurai adresei uzticēties?

Publiskas SaaS lapas var palikt atvērtas visiem, kamēr administrēšanas darbības aiz tām atsaka ikvienam ārpus VPN. Mehānisms, kas to ļauj, nav ne slēpta izvēlne, ne atsevišķa pieteikšanās lapa; tā ir tīkla ceļa, pa kuru piegādāts pieprasījums, pārbaude. Ja adreses pierādījums ir nepareizs, pārbaude vai nu izslēdz īstus administratorus, vai ielaiž ikvienu, kas prot ierakstīt galveni. Sāciet ar to, ko izcelsme faktiski saņem.

Ko izcelsme faktiski saņem pēc tuneļa

Kad pārlūkprogramma sasniedz publisko vietni caur VPN, kas pārvadā arī interneta trafiku, vārteja pārtulko savienojumu pirms tā iziet. SaaS redz vārtejas publisko izejas adresi, parasti vienu adresi vai nelielu diapazonu, un nekad neredz klēpjdatora tuneļa adresi. Tāpēc neizdodas 10.90.0.42 iekļaušana atļauto sarakstā, un tāpēc neizdodas visas RFC 1918 iekļaušana vēl skaļāk: otrais ielaiž katru privāto tīklu, kas var jūs sasniegt. Vienīgā adrese, kurai ir vērts noteikt nosacījumu, ir tā, kas jūsu organizācijai faktiski pieder izejā.

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

Sadalītais tunelējums klusi salauž šo pieņēmumu. Ja VPN pārvadā tikai privātus biroja maršrutus, pieprasījums uz publisko administrēšanas resursdatora nosaukumu iziet pa vietējo pakalpojumu sniedzēju, un izcelsme redz dzīvojamo adresi. Savienota VPN ikona neko nepierāda par šo konkrēto galamērķi, tāpēc pārbaudiet galamērķi, nevis tuneli.

Apstājieties un izlabojiet maršrutēšanu pirms jebkuras politikas rakstīšanas, ja izejas adrese katram lietotājam atšķiras. Nosacījums, kas atbilst tikai daļai administratoru, ir sliktāks par nosacījuma neesamību, jo tas slēpj problēmu līdz incidentam.

Uzticieties tikai starpniekserverim, kas pārraksta adresi

Lielākā daļa publisko vietņu atrodas aiz CDN vai reversā starpniekservera, tāpēc izcelsmes ligzdas adrese pieder šai priekšpusei, nevis apmeklētājam. Priekšpuse parasti pārsūta sākotnējo adresi galvenē, un šo galveni kontrolē uzbrucējs, ja vien izcelsme to nepieņem tikai no zināmiem starpniekserveriem. Skaidri konfigurējiet uzticamo avotu sarakstu un padariet izcelsmi nesasniedzamu no jebkurienes citur. Bez šīs otrās puses uzbrucējs apiet starpniekserveri un nosūta galveni tieši.

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

Tas pats pamatojums attiecas uz PROXY protokolu: tas ir uzticams tikai tad, kad klausītājs ir piesaistīts saskarnei, kuru starpniekserveris var sasniegt un nekas cits nevar. Trūkstošam adreses kontekstam ir jāizraisa aizsargātās pārbaudes neizdošanās, nevis jānokrīt uz noklusējuma atļauju. Trūkstoša galvene nav uzticama ceļa pierādījums.

Pievienojiet nosacījumu katrai aizsargātajai darbībai

Ievietojiet pārbaudi autorizācijas robežā, kuru šķērso katra aizsargātā darbība, nevis lapā, kas atveido izvēlni. Maršrutu grupas, starpprogrammatūra vai politikas slānis darbojas visas; kopija katram apstrādātājam ne, jo apstrādātājam, ko kāds pievienos nākamajā ceturksnī, tās nebūs.

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

Tai pašai robežai jāaptver JSON API, eksporti, parakstītie lejupielādes URL un WebSocket rokasspiediens, jo neviens no tiem neprasa vispirms pieprasīt HTML lapu. Lejupielādes saite, kas izveidota, kamēr VPN darbojās, paliek derīga arī pēc tam, ja vien lejupielādes galapunkts nepārbauda no jauna. Ilgstošām sesijām arī vajadzīgs pārvērtēšanas noteikums, citādi viens autentificēts pieprasījums kļūst par pastāvīgu izņēmumu. Noklusējuma atteikums ir vienīgais iestatījums, kas pārdzīvo personāla maiņu.

Koplietotie keši ir otrs apiešanas ceļš. Kešs, kurā jau ir aizsargāta atbilde, var to pasniegt, nesazinoties ar izcelsmi, tāpēc atzīmējiet administrēšanas atbildes kā privātas un turiet tās ārpus koplietotās krātuves. Ja kešam tās tomēr jāpasniedz, piekļuves pārbaudei jānotiek pirms pasniegšanas, kas parasti nozīmē, ka tas nemaz nevar būt koplietots kešs.

Pārbaudiet apiešanas ceļus, kurus tikko aizvērāt

Trenējiet matricu, nevis laimīgo ceļu: administrators caur VPN, tas pats administrators bez tā, ne-administrators caur to, un viltota adreses galvene. Pievienojiet pieprasījumu tieši izcelsmei un pieprasījumu ar kešatmiņā saglabātu atbildi, jo tie divi pilnībā apiet priekšpusi.

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'

Katram pieprasījumam jāatgriež statuss, ko sola politika, un žurnālam jāreģistrē, kāds adreses pierādījums tika izmantots. IPv6 aptveriet atsevišķi, jo divu steku izcelsme var redzēt citu avotu saimi nekā pārbaudītā. Turiet parastās klientu darbības darbojamies ārpus VPN, citādi izmaiņas tiks atsauktas, kad klients pirmo reizi sūdzēsies. Pirms izpildes pierakstiet katras rindas gaidāmo rezultātu, lai pārsteidzoša izturēšana būtu redzama.

Izejas adrese pierāda atļautu tīkla ceļu, nevis personu un nevis pārvaldītu ierīci. Turiet to kā vienu nosacījumu blakus autentifikācijai un atļaujai, un administrēšanas zona paliek šaura, nepārvēršot visu produktu par pakalpojumu tikai ar VPN. Šī atdalīšana ir dizains, nevis tā ierobežojums.