Centraliser partner-VPN-adgang uden at sammenlægge partnere

Forslaget er rimeligt: fem partnertunneler spredt over et dusin bærbare computere, fem sæt klientversioner, fem manuskripter til helpdesken og én ingeniør, der ved, hvordan det hele passer sammen. At flytte dem til et kontrolleret adgangslag løser endpoint-udbredelsen. Det skaber også et nyt objekt i arkitekturen, en fælles adgangstjeneste, der nu har brug for sin egen autorisationsmodel, og den fejl, alle undervurderer, er en central enhed med alle tunneler aktiveret, som stille bliver et transitnetværk mellem organisationer, der aldrig har accepteret at være naboer. Den risiko er et designvalg, ikke noget hardwaren gør af sig selv. Arbejdet nedenfor er, hvordan jeg beholder bekvemmeligheden uden at acceptere den utilsigtede bivirkning.

Start med den kontrakt, hver partner allerede har underskrevet

Før enhver konfiguration skal du bekræfte, at partneren overhovedet tillader en fælles gateway eller site-forbindelse. En personlig fjernadgangskonto, et krav om enhedstilstand eller et interaktivt MFA-flow er måske ikke overførbart til en ubemandet fælles tunnel, og at samle medarbejdere bag én kopieret klientidentitet er den slags genvej, der overlever, indtil partneren reviderer deres logs. For hver tilladt forbindelse skal du registrere destinationsområder, private DNS-domæner, autoriserede interne kilder, autentificeringsejeren og hvad der skal ske, når tunnelen fejler. Bed partneren bekræfte den fælles forbindelse skriftligt, inklusive de kildeområder, de vil acceptere. Mundtlig godkendelse skifter normalt betydning i den uge, deres sikkerhedsteam skifter.

Den registrering er leverancen. Kan du ikke skrive den for én partner, er den partner ikke klar til at blive centraliseret.

Rut efter kontekst, ikke kun efter destination

To partnere vil på et tidspunkt bruge det samme private område, fordi hver organisation vælger fra det samme RFC 1918-rum. En enkelt almindelig routingtabel kan ikke vælge den rigtige partner ud fra en destinationsadresse alene, så overlappende områder har brug for separate routingkontekster eller et andet aftalt design. Forwarding-domænemodellen i RFC 4364 beskriver, hvorfor adskillelsen er vigtig, og en udrulning behøver ikke køre MPLS for at kræve den samme egenskab af sin gateway-platform.

Stil platformen et direkte spørgsmål: kan to partnere dele et destinationspræfiks og stadig skelnes ved, hvilken medarbejderkontekst sessionen kom fra? Er svaret nej, former den begrænsning designet mere end nogen leverandørs funktionsliste.

Hvor svaret er ja, bliver routingkonteksten det, du dokumenterer og tester, fordi den er usynlig i en traceroute.

Beslut, hvad medarbejderen skriver, og hvad partneren logger

Noget partnerarbejde passer til en applikationsproxy eller et fjernarbejdsrum åbnet i den partners kontekst. Andet arbejde kræver routed netværksadgang fra et godkendt medarbejdersegment, og de to giver forskellige kildeadresser og forskellige revisionsspor i den fjerne ende. En fælles oversat kildeadresse kan opfylde en allowlist, mens den skjuler, hvilken enhed der gjorde hvad, så bevar en pålidelig registrering af medarbejder-til-session og behold applikationsautentificering i stedet for at behandle en gatewayadresse som en identitet, hvilket er bekvemt lige indtil det øjeblik, partneren spørger, hvem der gjorde det.

Gå derefter gennem én rigtig opgave fra medarbejderens side: hvad de klikker på, hvad de bliver bedt om, og hvad partneren ville se, hvis de bad om en logpost. Er den gennemgang ikke reproducerbar, er designet ikke færdigt.

Afvis partner-til-partner-transit eksplicit

Delt hardware bør aldrig betyde delt tillid. Tilføj afvisningen som en bevidst regel med en navngivet ejer, ikke som et uheld af manglende konfiguration, og test den fra begge retninger med en anmodning, der ellers ville lykkes. Testen er vigtig, fordi en tilladelse, der blot mangler, kan gendannes af den næste ingeniør, der tilføjer en rute for at løse en urelateret klage.

Skriv afvisningen i partnerregistreringen ved siden af tilladelserne, så hensigten overlever personalepleje.

Kør det som en fælles tjeneste, ikke som en større bærbar

Fornyelse af tunneler, rotation af legitimationsoplysninger, kapacitet og udskiftning af gateway bliver nu alle ændringer i en fælles tjeneste, hvilket betyder, at de har brug for en tidsplan og en kommunikationsvej, som individuelle bærbare computere aldrig har krævet. Et partnercertifikat, der udløber en lørdag, er ikke længere én brugers afbrydelse; det er alle sessioner for den partner på én gang.

Acceptér laget først, når en afvist anmodning mellem partnere fejler præcis som tilsigtet, og en tilladt medarbejderanmodning når den rigtige destination med den rigtige kilde. At fjerne bærbar-konflikt og samtidig holde hver partners grænse intakt er hele pointen; et design, hvor hvert fjernt præfiks kan nås fra hvert skrivebord, har bare flyttet problemet.

Hold en lille tabel over partner, kontekst, tilladte områder og ejer. Det bliver det første, nogen beder om under en hændelse.