Sentraliser partnar-VPN-tilgang utan å slå saman partnarane

Framlegget er rimeleg: fem partnartunnelar spreidde over eit dusin berbare maskinar, fem sett klientversjonar, fem støttescript og ein ingeniør som veit korleis dei passar saman. Å flytte dei til eit kontrollert tilgangsnivå løyser endepunktrotet. Samstundes skapar det eit nytt objekt i arkitekturen — ei delt tilgangsteneste som no treng sin eigen autorisasjonsmodell; og feilen alle undervurderer er eit sentralt apparat med alle tunnelar påslått som stille blir eit transittnett mellom organisasjonar som aldri har samtykt i å vere naboar. Den risikoen er eit designval, ikkje noko maskinvaren gjer av seg sjølv. Arbeidet nedanfor er korleis eg held på bekvemmelegheita utan å godta den utilsikta biverknaden.

Start med kontrakten kvar partnar allereie har signert

Før nokon konfigurasjon må du stadfeste at partnaren i det heile tillèt ein delt gateway eller nettstadstilkopling. Ein personleg fjernåtkomstkonto, eit krav om einingstilstand eller ein interaktiv MFA-flyt kan vere ikke-overførbar til ein ubemanna delt tunnel, og å samle tilsette bak éin kopiert klientidentitet er den typen snarvveg som overlever til partnaren reviderer loggane sine. For kvar tillaten tilkopling: registrer målområde, private DNS-domene, autoriserte interne kjelder, kven som eig autentiseringa, og kva som skal skje når tunnelen sviktar. Be partnaren stadfeste den delte tilkoplinga skriftleg, inkludert kjeldeområda dei vil godta. Munnleg godkjenning har ein tendens til å endre meining den veka sikkerheitsteamet deira blir bytt ut.

Den registreringa er leveransen. Klarar du ikkje å skrive henne for éin partnar, er den partnaren ikkje klar for sentralisering.

Rut etter kontekst, ikkje berre etter mål

To partnarar vil etter kvart bruke same private område, fordi kvar organisasjon vel frå same RFC 1918-rom. Éi vanleg rutetabell kan ikkje velje rett partnar berre ut frå ei mål-adresse, så overlappande område treng separate rutekontekstar eller ei anna avtalt løysing. Vidaresendingsdomenemodellen i RFC 4364 skildrar kvifor denne separasjonen er viktig, og ein utrulling treng ikkje køyre MPLS for å krevje same eigenskap frå gateway-plattforma si.

Still plattforma eit direkte spørsmål: kan to partnarar dele same målprefiks og likevel skiljast på kva tilsettkontekst økta kom frå? Er svaret nei, formar den avgrensinga designet meir enn noka leverandørfunksjonsliste.

Der svaret er ja, blir rutekonteksten det du dokumenterer og testar, fordi han er usynleg i ein traceroute.

Avgjer kva den tilsette skriv og kva partnaren loggar

Noko partnararbeid passar i ein applikasjonsproxy eller eit eksternt arbeidsområde som blir opna i konteksten til den partnaren. Anna arbeid treng ruta nettverkstilgang frå eit godkjent tilsettsegment, og dei to gjev ulike kjeldeaddresser og ulike revisjonsspor i den andre enden. Ei delt omsett kjeldeadresse kan tilfredsstille ei tillatingsliste samtidig som ho skjuler kva eining som gjorde kva, så hald på ei påliteleg kopling mellom tilsett og økt og hald applikasjonsautentiseringa på plass i staden for å handsame ei gateway-adresse som ein identitet — noko som er praktisk heilt til partnaren spør kven som gjorde det.

Deretter gå gjennom éi reell oppgåve frå sida til den tilsette: kva dei klikkar på, kva dei blir bedne om, og kva partnaren ville sjå om dei bad om ei loggoppføring. Er den gjennomgangen ikkje reproduserbar, er designet ikkje ferdig.

Avvis partnar-til-partnar-transitt eksplisitt

Delt maskinvare skal aldri innebere delt tillit. Legg avvisinga inn som ei medviten regel med ein namngjeven eigar, ikkje som eit tilfelle av manglande konfigurasjon, og test henne frå begge retningar med ein førespurnad som elles ville lukkast. Testen betyr noko fordi ei løyve som berre manglar kan bli gjenoppretta av neste ingeniør som legg til ei rute for å fikse ei urelatert klage.

Skriv avvisinga inn i partnarregistreringa ved sida av løyva, slik at intensjonen overlever personalbyte.

Køyr det som ei delt teneste, ikkje som ein større berbar maskin

Fornying av tunnelar, rotasjon av legitimasjon, kapasitet og utskifting av gateway blir no alle endringar i ei delt teneste, som betyr at dei treng ein plan og ein kommunikasjonsveg som individuelle berbare maskinar aldri kravde. Eit partnarsertifikat som går ut på ein laurdag er ikkje lenger utfallet for éin brukar; det er kvar økt for den partnaren på ein gong.

Godta nivået berre når ein avvist førespurnad mellom partnarar sviktar nøyaktig som tenkt og ein tillaten tilsettførespurnad når rett mål med rett kjelde. Å fjerne laptopkonfliktar medan grensa til kvar partnar blir halden intakt er heile poenget; eit design der kvart eksterne prefiks er nåbart frå kvar pult har berre flytta problemet.

Hald ein liten tabell over partnar, kontekst, tillatne område og eigar. Han blir det første nokon spør etter under ei hending.