Sentraliser partner-VPN-tilgang uten å slå sammen partnerne

Forslaget er rimelig: fem partnertunneler spredt over et dusin bærbare maskiner, fem sett klientversjoner, fem støtteskript og én ingeniør som vet hvordan de passer sammen. Å flytte dem til et kontrollert tilgangsnivå løser endepunktsrotet. Samtidig skaper det et nytt objekt i arkitekturen — en delt tilgangstjeneste som nå trenger sin egen autorisasjonsmodell; og feilen alle undervurderer er et sentralt apparat med alle tunneler aktivert som stille blir et transittnettverk mellom organisasjoner som aldri har samtykket i å være naboer. Den risikoen er et designvalg, ikke noe maskinvaren gjør av seg selv. Arbeidet nedenfor er hvordan jeg beholder bekvemmeligheten uten å akseptere den utilsiktede bivirkningen.

Start med kontrakten hver partner allerede har signert

Før noen konfigurasjon må du bekrefte at partneren i det hele tatt tillater en delt gateway eller nettstedstilkobling. En personlig fjernadgangskonto, et krav om enhetstilstand eller en interaktiv MFA-flyt kan være ikke-overførbar til en ubemannet delt tunnel, og å samle ansatte bak én kopiert klientidentitet er den typen snarvei som overlever til partneren reviderer loggene sine. For hver tillatt tilkobling: registrer destinasjonsområder, private DNS-domener, autoriserte interne kilder, hvem som eier autentiseringen, og hva som skal skje når tunnelen feiler. Be partneren bekrefte den delte tilkoblingen skriftlig, inkludert kildeområdene de vil godta. Muntlig godkjenning har en tendens til å endre betydning den uken sikkerhetsteamet deres byttes ut.

Den registreringen er leveransen. Klarer du ikke å skrive den for én partner, er den partneren ikke klar for sentralisering.

Rut etter kontekst, ikke bare etter destinasjon

To partnere vil etter hvert bruke samme private område, fordi hver organisasjon velger fra samme RFC 1918-rom. Én vanlig rutetabell kan ikke velge riktig partner bare ut fra en destinasjonsadresse, så overlappende områder trenger separate rutekontekster eller en annen avtalt løsning. Videresendingsdomenemodellen i RFC 4364 beskriver hvorfor denne separasjonen er viktig, og en utrulling trenger ikke kjøre MPLS for å kreve samme egenskap fra gateway-plattformen sin.

Still plattformen et direkte spørsmål: kan to partnere dele samme destinasjonsprefiks og likevel skilles på hvilken ansattkontekst økten kom fra? Er svaret nei, former den begrensningen designet mer enn noen leverandørs funksjonsliste.

Der svaret er ja, blir rutekonteksten det du dokumenterer og tester, fordi den er usynlig i en traceroute.

Bestem hva den ansatte skriver og hva partneren logger

Noe partnerarbeid passer i en applikasjonsproxy eller et eksternt arbeidsområde som åpnes i den partnerens kontekst. Annet arbeid trenger rutet nettverkstilgang fra et godkjent ansattsegment, og de to gir forskjellige kildeadresser og forskjellige revisjonsspor i den andre enden. En delt oversatt kildeadresse kan tilfredsstille en tillatelsesliste samtidig som den skjuler hvilken enhet som gjorde hva, så behold en pålitelig kobling mellom ansatt og økt og hold applikasjonsautentiseringen på plass i stedet for å behandle en gateway-adresse som en identitet — noe som er praktisk helt til partneren spør hvem som gjorde det.

Deretter gå gjennom én reell oppgave fra den ansattes side: hva de klikker på, hva de blir bedt om, og hva partneren ville se om de ba om en loggoppføring. Er den gjennomgangen ikke reproduserbar, er designet ikke ferdig.

Avvis partner-til-partner-transitt eksplisitt

Delt maskinvare skal aldri innebære delt tillit. Legg avvisningen inn som en bevisst regel med en navngitt eier, ikke som en tilfeldighet av manglende konfigurasjon, og test den fra begge retninger med en forespørsel som ellers ville lykkes. Testen betyr noe fordi en tillatelse som bare er fraværende kan gjenopprettes av neste ingeniør som legger til en rute for å fikse en urelatert klage.

Skriv avvisningen inn i partnerregistreringen ved siden av tillatelsene, slik at intensjonen overlever personalbytter.

Kjør det som en delt tjeneste, ikke som en større bærbar maskin

Fornyelse av tunneler, rotasjon av legitimasjon, kapasitet og utskifting av gateway blir nå alle endringer i en delt tjeneste, som betyr at de trenger en plan og en kommunikasjonsvei som individuelle bærbare maskiner aldri krevde. Et partner-sertifikat som utløper på en lørdag er ikke lenger én brukers utfall; det er hver økt for den partneren på én gang.

Godta nivået bare når en avvist forespørsel mellom partnere feiler nøyaktig som tiltenkt og en tillatt ansattforespørsel når riktig destinasjon med riktig kilde. Å fjerne laptopkonflikter mens hver partners grense forblir intakt er hele poenget; et design der hvert eksterne prefiks er nåbart fra hver pult har bare flyttet problemet.

Hold en liten tabell over partner, kontekst, tillatte områder og eier. Den blir det første noen spør etter under en hendelse.