Centralisera partner-VPN-åtkomst utan att slå ihop partnerna

Förslaget är rimligt: fem partnertunnlar utspridda över ett dussin bärbara datorer, fem uppsättningar klientversioner, fem supportskript och en ingenjör som vet hur de passar ihop. Att flytta dem till en kontrollerad åtkomstnivå löser endpoint-röran. Samtidigt skapar det ett nytt objekt i arkitekturen — en delad åtkomsttjänst som nu behöver sin egen auktoriseringsmodell; och det fel alla underskattar är en central apparat med alla tunnlar aktiverade som tyst blir ett transitnät mellan organisationer som aldrig har gått med på att vara grannar. Den risken är ett designval, inte något hårdvaran gör av sig själv. Arbetet nedan är hur jag behåller bekvämligheten utan att acceptera den oavsiktliga bieffekten.

Börja med avtalet som varje partner redan har undertecknat

Innan någon konfiguration, bekräfta att partnern överhuvudtaget tillåter en delad gateway eller platsanslutning. Ett personligt fjärråtkomstkonto, ett krav på enhetsstatus eller ett interaktivt MFA-flöde är kanske inte överförbart till en obemannad delad tunnel, och att samla anställda bakom en kopierad klientidentitet är den sorts genväg som håller tills partnern granskar sina loggar. För varje tillåten anslutning: registrera destinationsintervall, privata DNS-domäner, auktoriserade interna källor, den som äger autentiseringen och vad som ska hända när tunneln fallerar. Be partnern bekräfta den delade anslutningen skriftligt, inklusive de källintervall de accepterar. Muntligt godkännande brukar byta betydelse den vecka deras säkerhetsteam byts ut.

Den registreringen är leveransen. Kan du inte skriva den för en partner är den partnern inte redo att centraliseras.

Routa efter kontext, inte bara efter destination

Två partner kommer till slut att använda samma privata intervall, eftersom varje organisation väljer ur samma RFC 1918-rymd. En enda vanlig routingtabell kan inte välja rätt partner bara utifrån en destinationsadress, så överlappande intervall behöver separata routingkontexter eller en annan överenskommen design. Vidarebefordringsdomänmodellen i RFC 4364 beskriver varför den separationen spelar roll, och en driftsättning behöver inte köra MPLS för att kräva samma egenskap av sin gateway-plattform.

Ställ en rak fråga till plattformen: kan två partner dela samma destinationsprefix och ändå skiljas åt på vilken anställds kontext sessionen kom från? Om svaret är nej formar den begränsningen designen mer än någon leverantörs funktionslista.

Där svaret är ja blir routingkontexten det du dokumenterar och testar, eftersom den är osynlig i en traceroute.

Bestäm vad den anställde skriver och vad partnern loggar

En del partnerarbete passar i en applikationsproxy eller en fjärrarbetsyta som öppnas i den partnerns kontext. Annat arbete kräver routad nätverksåtkomst från ett godkänt anställdsegment, och båda ger olika källadresser och olika granskningsspår i andra änden. En delad översatt källadress kan uppfylla en tillåtelselista samtidigt som den döljer vilken enhet som gjorde vad, så behåll en tillförlitlig koppling mellan anställd och session och låt applikationsautentiseringen vara kvar i stället för att behandla en gateway-adress som identitet — vilket är praktiskt ända till dess att partnern frågar vem som gjorde det.

Gå sedan igenom en verklig uppgift från den anställdes sida: vad de klickar på, vad de ombeds ange och vad partnern skulle se om de bad om en loggpost. Om den genomgången inte går att upprepa är designen inte klar.

Neka uttryckligen transit mellan partner

Delad hårdvara bör aldrig innebära delat förtroende. Lägg till nekan som en medveten regel med en namngiven ägare, inte som en olycka av saknad konfiguration, och testa den från båda hållen med en begäran som annars skulle lyckas. Testet spelar roll eftersom ett tillstånd som bara saknas kan återställas av nästa ingenjör som lägger till en rutt för att fixa ett orelaterat klagomål.

Skriv in nekan i partnerregistret bredvid tillstånden, så att avsikten överlever personalbyten.

Driv det som en delad tjänst, inte som en större bärbar dator

Förnyelse av tunnlar, rotation av autentiseringsuppgifter, kapacitet och byte av gateway blir nu alla ändringar i en delad tjänst, vilket betyder att de behöver ett schema och en kommunikationsväg som enskilda bärbara datorer aldrig krävde. Ett partnercertifikat som går ut på en lördag är inte längre en användares avbrott; det är varje session för den partnern på en gång.

Acceptera nivån först när en nekad begäran mellan partner misslyckas exakt som avsett och en tillåten anställdbegäran når rätt destination med rätt källa. Att ta bort laptopkonflikter medan varje partners gräns förblir intakt är hela poängen; en design där varje fjärrprefix nås från varje skrivbord har bara flyttat problemet.

Håll en liten tabell över partner, kontext, tillåtna intervall och ägare. Den blir det första någon frågar efter under en incident.