Centralizirajte pristup partnera putem VPN-a bez spajanja partnera

Ponuda je razumna: pet partnerskih tunela razasutih po desetak prijenosnika, pet skupova verzija klijenta, pet skripti za podršku i jedan inženjer koji zna kako se sve to uklapa. Prelazak na kontroliranu razinu pristupa rješava razgranatost krajnjih točaka. On istovremeno stvara novi objekt u arhitekturi, zajedničku pristupnu uslugu koja sada treba vlastiti model ovlaštenja, a kvar koji svi podcjenjuju je središnji uređaj sa uključenim svim tunelima koji tiho postaje tranzitna mreža između organizacija koje nikada nisu pristale biti susjedi. Taj rizik je dizajnerska odluka, a ne nešto što hardver čini sam. Posao ispod je kako zadržavam pogodnost bez prihvaćanja slučajne nuspojave.

Pođite od ugovora koji je svaki partner već potpisao

Prije ikakve konfiguracije potvrdite da partner uopće dopušta zajednički pristupnik ili vezu sa lokacijom. Osobni račun za daljinski pristup, zahtjev za stanje uređaja ili interaktivni MFA tok možda se ne mogu prenijeti na zajednički tunel bez nadzora, a okupljanje zaposlenika iza jednog kopiranog identiteta klijenta je ona prečica koja preživi dok partner ne revidira svoje zapise. Za svaku dopuštenu vezu zabilježite raspone odredišta, privatne domene DNS, ovlaštene unutarnje izvore, vlasnika autentikacije i što se treba dogoditi kad tunel padne. Zamolite partnera da zajedničku vezu potvrdi pisano, uključujući raspone izvora koje će prihvatiti. Usmeno odobrenje obično promijeni značenje onog tjedna kad im se izmijeni sigurnosni tim.

Taj zapis je rezultat. Ako ga ne možete napisati za jednog partnera, taj partner nije spreman za centralizaciju.

Usmjeravajte po kontekstu, ne samo po odredištu

Dva partnera će na kraju koristiti isti privatni raspon, jer svaka organizacija bira iz istog prostora RFC 1918. Jedna obična tablica usmjeravanja ne može odabrati ispravnog partnera samo po adresi odredišta, pa rasponi koji se preklapaju trebaju odvojene kontekste usmjeravanja ili drugi dogovoreni dizajn. Model domene prosljeđivanja u RFC 4364 opisuje zašto je to razdvajanje važno, a implementacija ne mora pokretati MPLS da bi tražila isto svojstvo od svoje pristupničke platforme.

Pitajte platformu izravno: mogu li dva partnera dijeliti isti prefiks odredišta i ipak se razlikovati po tome iz kojeg je konteksta zaposlenika došla sesija? Ako je odgovor ne, to ograničenje oblikuje dizajn više od bilo kojeg popisa značajki dobavljača.

Gdje je odgovor da, kontekst usmjeravanja postaje ono što dokumentirate i testirate, jer je nevidljiv u tracerouteu.

Odlučite što zaposlenik upisuje i što partner bilježi

Neki partnerski poslovi odgovaraju proxyju aplikacija ili udaljenom radnom prostoru otvorenom u kontekstu tog partnera. Drugi poslovi traže usmjeren mrežni pristup s odobrenog segmenta zaposlenika, a to dvoje daje različite izvorne adrese i različite revizijske tragove na udaljenoj strani. Zajednička prevedena izvorna adresa može zadovoljiti popis dopuštenja dok skriva koji je uređaj što učinio, pa čuvajte pouzdan zapis o vezi zaposlenika i sesije i zadržite autentikaciju aplikacije umjesto da adresu pristupnika tretirate kao identitet, što je zgodno sve do trenutka kad partner pita ko je to učinio.

Zatim prođite jedan stvarni zadatak sa strane zaposlenika: na što klikću, što se od njih traži i što bi partner vidio kad bi zatražio zapis u dnevniku. Ako taj prolazak nije ponovljiv, dizajn nije dovršen.

Izričito zabranite tranzit između partnera

Zajednički hardver nikada ne smije značiti zajedničko povjerenje. Dodajte zabranu kao namjerno pravilo s imenovanim vlasnikom, a ne kao slučajnost nedostajuće konfiguracije, i testirajte je u oba smjera zahtjevom koji bi inače prošao. Test je važan jer dopuštenje koje tek nedostaje može vratiti sljedeći inženjer koji doda rutu da riješi nepovezanu pritužbu.

Upišite zabranu u partnerski zapis uz dopuštenja, da namjera nadživi promjene osoblja.

Vodite to kao zajedničku uslugu, a ne kao veći prijenosnik

Obnova tunela, rotacija vjerodajnica, kapacitet i zamjena pristupnika sada svi postaju promjene zajedničke usluge, što znači da trebaju raspored i komunikacijski put kakav pojedinačni prijenosnici nikada nisu zahtijevali. Partnerski certifikat koji istekne u subotu više nije prekid za jednog korisnika; to su sve sesije tog partnera odjednom.

Prihvatite razinu tek kad odbijeni zahtjev između partnera padne točno kako je predviđeno i dopušteni zahtjev zaposlenika stigne na pravo odredište s pravim izvorom. Ukloniti sukob prijenosnika i pritom zadržati granicu svakog partnera netaknutom cijela je poanta; dizajn u kojem je svaki udaljeni prefiks dostupan sa svakog stola samo je premjestio problem.

Držite malu tablicu partnera, konteksta, dopuštenih raspona i vlasnika. Bit će prvo što će netko tražiti tijekom incidenta.