VPN-toegang met serviceaccount: certificaat of gedeelde login

Twee ontwerpen dekken bijna elke onbeheerde VPN-opstelling: een gedeelde menselijke login in een script, of een machinecertificaat dat aan de host is gebonden. Ze falen op verschillende plekken, wat meer uitmaakt dan de installatiesnelheid. Een opgeslagen wachtwoord breekt wanneer de eigenaar het wijzigt of vertrekt; een certificaat breekt wanneer het verloopt of wanneer de host zonder de sleutel opnieuw wordt gebouwd. Drie voorwaarden bepalen welke kosten u kunt dragen, en geen van beide ontwerpen beperkt iets tot het autorisatiebeleid dat doet.

Begin bij de taak, niet bij het account

De taak bepaalt de grens: welke bestemmingen, welke diensten, welke uren, hoe lang een sessie mag lopen. Een tunnelroute is slechts de helft van die grens. De gateway beslist of de sessie is toegestaan; de resource erachter beslist wat de sessie kan doen. Schrijf eerst de lijst op, met een genoemde eigenaar, want beide identiteitsontwerpen moeten eraan voldoen.

Houd authenticatie en autorisatie gescheiden terwijl u het opschrijft. Authenticatie beantwoordt wie er verbindt; autorisatie beantwoordt wat de sessie daarna mag bereiken. RADIUS draagt het tweede deel als attributen zoals Filter-Id, Framed-IP-Address, Session-Timeout en Class, en de gateway voegt ze toe zodra de login slaagt. Een ontwerp dat de login vervangt en de autorisatie ongemoeid laat, heeft niets beperkt.

Gedeelde menselijke login: het wachtwoord wordt de grens

Een menselijk account hergebruiken is de snelste route en degene die het slechtst veroudert. De inloggegevens zijn een wachtwoord, dus het belandt in een script, een omgevingsbestand en een plannerconfiguratie, en elke kopie moet worden geroteerd. Wanneer de eigenaar het op een vrijdag wijzigt, faalt de taak bij de volgende run en niemand kijkt mee.

MFA is waar dit ontwerp meestal instort. Een script kan geen pushverzoek beantwoorden, dus het account wordt van het beleid uitgesloten, en dat is precies het account dat een aanvaller zou kiezen. Uitzonderingen, omzeiling van vertrouwde locaties en vrijstellingen per account vermenigvuldigen zich, en geen ervan is zichtbaar voor de volgende persoon die de tenantinstellingen leest.

Toerekening is de andere kostenpost. Elke sessie in het gatewaylog draagt dezelfde gebruikersnaam, dus de nachtelijke synchronisatie is niet te onderscheiden van het werk van de persoon die hem schreef, en de taak intrekken betekent die persoon intrekken.

Machinecertificaat: identiteit gebonden aan de host

Een certificaat verandert de vraag van wat het account weet naar wat de host is. Met EAP-TLS presenteert de client een certificaat en bewijst het bezit van de bijbehorende privésleutel; de beleidsserver koppelt het subject of het computeraccount aan een groep en past het beleid voor die groep toe. Geen prompt, geen gedeeld geheim in een tekstbestand.

De grens die het creëert is smaller dan mensen verwachten. Een certificaat authenticeert de host, niet de taak, en iedereen met root- of lokale beheerdersrechten kan die sleutel op die host gebruiken. Bewaar de sleutel waar het platform hem beschermt: niet-exporteerbaar in de Windows-certificaatopslag, TPM-ondersteund waar het profiel het toestaat, of een root-eigen 0600-bestand op Linux. Compromis van de host is compromis van de inloggegevens.

Verloop is de terugkerende fout. Een certificaat dat op zondag verloopt, stopt de taak op zondag, en de gateway meldt meestal een algemene authenticatiefout in plaats van de datum te noemen. Controleer de datums vanaf de taakhost als onderdeel van de runbook:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

Intrekking vereist een pad dat de gateway controleert. OpenVPN leest een CRL via de optie crl-verify, en strongSwan is afhankelijk van CRL of OCSP afhankelijk van hoe het verbindingsprofiel is opgebouwd. Als geen van beide is aangesloten, betekent het verwijderen van een host wachten tot het certificaat verloopt.

Drie voorwaarden die tussen beide beslissen

Vergelijk met het platform dat u hebt, niet met een referentieontwerp.

Eerste voorwaarde: kan de gateway een machine-identiteit autoriseren? Als hij alleen een RADIUS-gebruikersnaam aan een directorygebruiker koppelt, authenticeert een certificaat de host en blijft daarna steken bij de autorisatie. Tweede voorwaarde: heeft de taak resourcetoegang nodig die alleen een gebruikersaccount draagt, zoals een gekoppelde share of een licentie per werkplek? Dan kan een machine-identiteit niet vervangen, en het eerlijke antwoord is een toegewijd gebruikersaccount met een beperkt beleid. Derde voorwaarde: wie kan de inloggegevens roteren zonder een persoon in de lus? Automatische inschrijving maakt certificaten goedkoop te onderhouden; een wachtwoord dat één persoon kent, niet.

Lees de tabel als een kostenlijst, niet als een rangorde. De kolom met het opgeslagen geheim wint op intrekkingssnelheid en op compatibiliteit met resources die alleen gebruikersaccounts begrijpen; de certificaatkolom wint op rotatie en op het niet verzwakken van MFA om een script te laten werken.

Leg de grens in het beleid, na de authenticatie

Welke identiteit u ook kiest, de permissielimiet hoort bij het beleid dat na de authenticatie draait. In NPS worden netwerkbeleidsregels op volgorde geëvalueerd en het eerste beleid dat aan elke voorwaarde voldoet, past zijn instellingen toe, dus een breed beleid boven een smal bepaalt de uitkomst, ongeacht wat de client presenteert. Microsoft documenteert het voorwaarden- en instellingenmodel in zijn NPS-beleidsoverzicht.

Geef de taak een eigen groep of beleidsvoorwaarde, gebaseerd op iets dat de machine-identiteit draagt: een certificaatsjabloon, een identificatie van het aanroepende station of een adres uit een toegewezen poel. Beperk daarna de sessie met attributen: een Filter-Id voor de rol waarnaar uw gateway hem koppelt, een korte Session-Timeout zodat een vastgelopen taak opnieuw authenticeert in plaats van dagenlang een sessie vast te houden, en een Framed-IP-Address uit een poel die u aan de andere kant firewallt. Applicatieautorisatie blijft gescheiden: een tunnel naar een databaseserver is geen toestemming om een tabel erin te lezen.

Controleer weigeringen, plan daarna de verwijdering

Toegang die werkt bewijst niets over het minste voorrecht. Test in plaats daarvan de weigeringen: verbind met de taakidentiteit en probeer een bestemming buiten de lijst te bereiken, open een tweede gelijktijdige sessie als de gateway er maar één mag toestaan, en herhaal de login na het intrekken van de inloggegevens.

Bevestig daarna dezelfde sessie op twee plaatsen. Het gatewaylog toont de identiteit die zich authenticeerde; het log van de beleidsserver toont welk beleid overeenkwam en welke attributen het teruggaf. Op OpenVPN registreert de server de common name van het certificaat, en ipsec statusall op strongSwan drukt de opgezette tunnel af met de gebruikte identiteit. Als de twee logs het niet eens zijn over de identiteit, komt het beleid overeen met iets anders dan u aanneemt.

Verwijdering hoort bij het ontwerp, niet bij een opruimsprint. Schrijf alles op wat verwijderd moet worden (certificaat of account, groepslidmaatschap, netwerkbeleid, poelvermelding, firewallregel op het doel) en voer het één keer uit terwijl de taak makkelijk opnieuw te bouwen is.

Als u vandaag begint, werk dan in deze volgorde: schrijf de resourcelijst, kies de identiteit met de drie voorwaarden, leg de grens in het beleid, en oefen één weigering voordat de taak in productie gaat.