Afzonderlijke VPN-identiteiten voor een klein team, zonder directory

Zes mensen delen één VPN-login, een van hen vertrekt, en de enige manier om diens toegang te verwijderen is het geheim te wijzigen dat alle anderen gebruiken. Dat is het echte probleem, en er is geen Active Directory nodig om het op te lossen. Een klein kantoor kan aparte identiteiten bewaren in de lokale opslag die zijn gateway ondersteunt en vertrekken toch als routine behandelen. Het werk zit in het kiezen van de opslag en het opschrijven van de verwijderstappen voordat je ze nodig hebt.

Begin met de inloggegevens die iedereen heeft

Inventariseer waarmee iedereen verbinding maakt voordat je een backend kiest. Eén laptop, een telefoon, misschien een desktop thuis, en elk daarvan is een afzonderlijk inloggegeven of een afzonderlijk apparaatcertificaat. Als je het inloggegeven van iemand niet kunt benoemen, kun je het later niet verwijderen.

Twee mensen die één profiel delen is het geval dat elke volgende stap moeilijker maakt. Los dat eerst op, want geen enkele directory lost een gedeeld geheim op.

Kies de opslag die de gateway echt ondersteunt

Kies de identiteitsopslag die de gateway al ondersteunt, niet die je zou willen draaien. Een gateway met een lokale gebruikersdatabase kan afzonderlijke accounts met beleid per gebruiker bevatten. Een IKEv2-implementatie kan een EAP-identiteit aan een bepaald geheim koppelen, mits de clientmethode en de verifier bij elkaar passen. Op certificaten gebaseerde opstellingen kunnen één certificaat per apparaat uitgeven van een gemeenschappelijke autoriteit, wat het vertrouwensanker gedeeld houdt terwijl de inloggegevens gescheiden blijven.

De locatie van de opslag is minder belangrijk dan de bewerkingen: inschrijving, back-up, vernieuwing en intrekking. Als een daarvan geen antwoord heeft, is de keuze niet af.

Als de gateway zowel lokale accounts als certificaten biedt, geef dan de voorkeur aan wat je team om twee uur in de nacht kan bedienen zonder de leverancier aan de telefoon. Die voorkeur gaat over hersteltijd, niet over welke optie technisch sterker is.

Scheid de persoon van de apparaten

Bepaal wat een inloggegeven vertegenwoordigt: een persoon, een apparaat of beide. Een laptop en een telefoon van één medewerker zijn twee apparaten en één persoon, en het verliezen van de telefoon zou niet automatisch de laptop moeten uitschakelen. Schrijf dat model op, want het bepaalt wat verwijderen betekent.

Leg de eigenaar, het apparaat, de uitgiftedatum en het intrekkingspad voor elk inloggegeven vast. Bewaar dat overzicht ergens waar het kantoor het kan lezen zonder de persoon die het heeft ingesteld. Een tabel met die vier kolommen is genoeg voor zes mensen en schaalt nog steeds naar zestig.

Maak verwijderen een gewone bewerking

Schrijf de vertrekprocedure voordat het eerste vertrek plaatsvindt. Schakel de identiteit uit, beëindig elke actieve sessie en bevestig dat de tunnel echt wegvalt in plaats van te wachten op een timer voor herauthenticatie. Controleer daarna dat het oude inloggegeven faalt vanaf een machine buiten het kantoornetwerk. De hele reeks zou minuten moeten duren en voor niemand anders een nieuwe uitgifte mogen vereisen.

sudo swanctl --terminate --ike alice-laptop

Houd een beheerdersherstelpad aan dat niet afhankelijk is van het uitgeschakelde account, en stem lokale accounts af die later naar een directory verhuizen. Het doel is simpel: één persoon verwijderen is een routineklus, geen project dat andermans profiel raakt. Lokale authenticatie van Access Server is een gedocumenteerd voorbeeld van een opslag die bij deze vorm past.