Centralizirajte dostop partnerjev do VPN, ne da bi partnerje združili

Predlog je razumen: pet partnerskih tunelov, raztresenih po ducatu prenosnikov, pet sklopov različic odjemalca, pet skriptov za pomoč uporabnikom in en inženir, ki ve, kako se vse skupaj ujema. Selitev na nadzorovano raven dostopa odpravi raztresenost končnih točk. Hkrati ustvari nov objekt v arhitekturi — skupno storitev dostopa, ki zdaj potrebuje svoj model avtorizacije; in odpoved, ki jo vsi podcenjujejo, je centralna naprava z vsemi omogočenimi tuneli, ki tiho postane tranzitno omrežje med organizacijami, ki se nikoli niso strinjale, da bodo sosede. To tveganje je oblikovalska odločitev, ne nekaj, kar strojna oprema počne sama. Spodnje delo je način, kako obdržim udobje, ne da bi sprejel nenamerni stranski učinek.

Začnite s pogodbo, ki jo je vsak partner že podpisal

Pred kakršno koli konfiguracijo preverite, ali partner sploh dovoljuje skupno prehodno točko ali povezavo lokacije. Osebni račun za oddaljeni dostop, zahteva glede stanja naprave ali interaktivni tok MFA morda ne bodo prenosljivi na skupni tunel brez nadzora, združevanje zaposlenih za eno kopirano identiteto odjemalca pa je tista bližnjica, ki zdrži, dokler partner ne pregleda svojih dnevnikov. Za vsako dovoljeno povezavo zabeležite ciljne obsege, zasebne domene DNS, pooblaščene notranje vire, lastnika overjanja in kaj naj se zgodi, ko tunel odpove. Prosita partnerja, da skupno povezavo potrdi pisno, vključno z izvornimi obsegi, ki jih bo sprejel. Ustno soglasje običajno spremeni pomen v tednu, ko se zamenja njihova varnostna ekipa.

Ta zapis je rezultat. Če ga ne morete napisati za enega partnerja, ta partner ni pripravljen na centralizacijo.

Usmerjajte po kontekstu, ne le po cilju

Dva partnerja bosta sčasoma uporabila isti zasebni obseg, ker vsaka organizacija izbira iz istega prostora RFC 1918. Ena običajna usmerjevalna tabela ne more izbrati pravega partnerja samo po ciljnem naslovu, zato prekrivajoči se obsegi potrebujejo ločene usmerjevalne kontekste ali drugo dogovorjeno zasnovo. Model posredovalne domene v RFC 4364 opisuje, zakaj je ta ločitev pomembna, in uvedba ne potrebuje delovanja MPLS, da bi od svoje platforme prehoda zahtevala isto lastnost.

Platformi postavite neposredno vprašanje: ali lahko dva partnerja delita isto ciljno predpono in se še vedno razlikujeta po tem, iz konteksta katerega zaposlenega je prišla seja? Če je odgovor ne, ta omejitev oblikuje zasnovo bolj kot kateri koli seznam funkcij ponudnika.

Kjer je odgovor ja, postane usmerjevalni kontekst tisto, kar dokumentirate in preizkušate, ker v traceroute ni viden.

Odločite, kaj vnaša zaposleni in kaj beleži partner

Del partnerskega dela sodi k aplikacijskemu posredniku ali oddaljenemu delovnemu prostoru, odprtem v kontekstu tega partnerja. Drugo delo potrebuje usmerjen omrežni dostop iz odobrenega segmenta zaposlenih, oba pa na drugem koncu ustvarita različne izvorne naslove in različne revizijske sledi. Skupni prevedeni izvorni naslov lahko zadovolji seznam dovoljenj, hkrati pa skrije, katera naprava je kaj storila, zato ohranite zanesljivo povezavo med zaposlenim in sejo ter pustite overjanje aplikacije, namesto da bi naslov prehoda obravnavali kot identiteto — kar je priročno vse do trenutka, ko partner vpraša, kdo je to storil.

Nato prehodite eno resnično opravilo z vidika zaposlenega: na kaj kliknejo, kaj se od njih zahteva in kaj bi partner videl, če bi zahteval vnos v dnevnik. Če ta sprehod ni ponovljiv, zasnova ni dokončana.

Izrecno zavrnite tranzit med partnerji

Skupna strojna oprema nikoli ne sme pomeniti skupnega zaupanja. Zavrnitev dodajte kot namerno pravilo z imenovanim lastnikom, ne kot nesrečo manjkajoče konfiguracije, in jo preizkusite v obe smeri z zahtevo, ki bi sicer uspela. Preizkus je pomemben, ker lahko dovoljenje, ki le manjka, obnovi naslednji inženir, ki doda pot za odpravo nepovezane pritožbe.

Zavrnitev zapišite v partnerjev zapis ob dovoljenjih, da namera preživi kadrovske spremembe.

Vodite jo kot skupno storitev, ne kot večji prenosnik

Podaljševanje tunelov, menjava poverilnic, zmogljivost in zamenjava prehoda postanejo zdaj vse spremembe skupne storitve, kar pomeni, da potrebujejo urnik in komunikacijsko pot, ki ju posamezni prenosniki nikoli niso zahtevali. Partnersko potrdilo, ki poteče v soboto, ni več izpad enega uporabnika; to je izpad vseh sej tega partnerja hkrati.

Raven sprejmite šele, ko zavrnjena zahteva med partnerji odpove natanko po načrtu in dovoljena zahteva zaposlenega doseže pravi cilj s pravim virom. Odprava konflikta prenosnikov ob ohranjeni meji vsakega partnerja je ves smisel; zasnova, v kateri je vsaka oddaljena predpona dosegljiva z vsake pisalne mize, je težavo le premaknila.

Vodite majhno tabelo partnerja, konteksta, dovoljenih obsegov in lastnika. Med incidentom bo to prva stvar, ki jo bo kdo zahteval.