SaaS-administra areo malantaŭ la VPN: kiun adreson fidu?

Publikaj SaaS-paĝoj povas resti malfermitaj al ĉiuj, dum la administraj operacioj malantaŭ ili rifuzas ĉiun ekster la VPN. La mekanismo, kiu ebligas tion, ne estas kaŝita menuo aŭ aparta ensaluta paĝo; ĝi estas kontrolo de la reta vojo, kiu alportis la peton. Se vi eraros pri la adresa pruvo, la kontrolo aŭ blokos verajn administrantojn aŭ enlasos ĉiun, kiu povas tajpi kaplinion. Komencu per tio, kion la origino efektive ricevas.

Kion la origino efektive ricevas post la tunelo

Kiam retumilo atingas la publikan retejon tra VPN, kiu ankaŭ portas interretan trafikon, la enirejo tradukas la konekton antaŭ ol ĝi eliros. La SaaS vidas la publikan eliran adreson de la enirejo, kutime unu adreson aŭ malgrandan gamon, kaj neniam vidas la tunelan adreson de la tekkomputilo. Tial malsukcesas aldoni 10.90.0.42 al la permeslisto, kaj tial malsukcesas aldoni la tutan RFC 1918 eĉ pli laŭte: la dua enlasas ĉiun privatan reton, kiu povas atingi vin. La sola adreso inda je kondiĉo estas tiu, kiun via organizo efektive posedas ĉe la elirejo.

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

Dividita tunelado kviete rompas tiun supozon. Se la VPN portas nur privatajn oficejajn vojojn, la peto al la publika administra gastnomo eliras tra la loka provizanto kaj la origino vidas loĝejan adreson. Konektita VPN-ikono pruvas nenion pri ĉi tiu konkreta celo, do testu la celon, ne la tunelon.

Haltu kaj riparu la vojigon antaŭ ol vi skribos iun ajn politikon, se la elira adreso varias laŭ uzanto. Kondiĉo, kiu kongruas nur kun iuj administrantoj, estas pli malbona ol neniu kondiĉo, ĉar ĝi kaŝas la problemon ĝis incidento.

Fidu nur la prokuron, kiu reskribas la adreson

Plej multaj publikaj retejoj staras malantaŭ CDN aŭ inversa prokuro, do la poŝa adreso de la origino apartenas al tiu fasado kaj ne al la vizitanto. La fasado kutime plusendas la originalan adreson en kaplinio, kaj tiun kaplinion kontrolas atakanto, krom se la origino akceptas ĝin nur de konataj prokuroj. Agordu la liston de fidindaj fontoj eksplicite kaj faru la originon neatingebla de ie ajn alie. Sen tiu dua duono, atakanto preterpasas la prokuron kaj sendas la kaplinion rekte.

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

La sama rezonado validas por la protokolo PROXY: ĝi estas fidinda nur kiam la aŭskultanto estas ligita al interfaco, kiun la prokuro povas atingi kaj nenio alia povas. Mankanta adresa kunteksto devas malsukcesigi la protektitan kontrolon anstataŭ fali al defaŭlta permeso. Mankanta kaplinio ne estas pruvo de fidinda vojo.

Aldonu la kondiĉon al ĉiu protektita operacio

Metu la kontrolon ĉe la rajtiga limo, kiun trapasas ĉiu protektita operacio, ne en la paĝon, kiu bildigas la menuon. Vojgrupoj, meza programaro aŭ politika tavolo ĉiuj funkcias; kopio por ĉiu traktilo ne, ĉar la traktilo, kiun iu aldonos venontan kvaronojaron, ne havos ĝin.

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

La sama limo devas kovri la JSON API, eksportojn, subskribitajn elŝutajn URL-ojn kaj la WebSocket-manpremon, ĉar neniu el ili bezonas, ke la HTML-paĝo estu unue petita. Elŝuta ligilo kreita dum la VPN estis aktiva restas valida poste, krom se la elŝuta finpunkto rekontrolas. Longdaŭraj sesioj ankaŭ bezonas regulon de reanalizo, alie unu aŭtentigita peto fariĝas daŭra escepto. Defaŭlta rifuzo estas la sola agordo, kiu postvivas personan ŝanĝiĝon.

Dividitaj kaŝmemoroj estas la alia vojo ĉirkaŭ la kontrolo. Kaŝmemoro, kiu jam tenas protektitan respondon, povas liveri ĝin sen kontakti la originon, do marku administrajn respondojn privataj kaj tenu ilin ekster dividita stokado. Se kaŝmemoro devas liveri ilin, la alirkontrolo devas ruliĝi antaŭ la livero, kio kutime signifas, ke ĝi tute ne povas esti dividita kaŝmemoro.

Testu la pretervojojn, kiujn vi ĵus fermis

Ekzercu la matricon anstataŭ la feliĉan vojon: administranto tra la VPN, la sama administranto sen ĝi, ne-administranto tra ĝi, kaj falsigita adresa kaplinio. Aldonu peton rekte al la origino kaj peton kun kaŝmemorita respondo, ĉar tiuj du tute preterpasas la fasadon.

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'

Ĉiu peto devus redoni la staton, kiun la politiko promesas, kaj la protokolo devus registri, kiu adresa pruvo estis uzita. Kovru IPv6 aparte, ĉar duobla-staka origino povas vidi alian fontan familion ol tiu, kiun vi testis. Tenu ordinarajn klientajn operaciojn funkciaj ekster la VPN, alie la ŝanĝo estos malfarita la unuan fojon, kiam kliento plendos. Skribu la atendatan rezulton por ĉiu vico antaŭ ol ruli ĝin, por ke surpriza sukceso estu videbla.

La elira adreso pruvas permesitan retan vojon, ne personon kaj ne administritan aparaton. Tenu ĝin kiel unu kondiĉon apud aŭtentigo kaj permeso, kaj la administra areo restas mallarĝa sen igi la tutan produkton servo nur por VPN. Tiu apartigo estas la dezajno, ne limigo de ĝi.