Servicekontos VPN-adgang: certifikat eller delt login

To design dækker næsten enhver uovervåget VPN-opsætning: et delt menneskeligt login gemt i et script, eller et maskincertifikat bundet til værten. De fejler forskellige steder, og det betyder mere end opsætningshastigheden. En gemt adgangskode brækker, når ejeren ændrer den eller forlader os; et certifikat brækker, når det udløber, eller når værten genopbygges uden nøglen. Tre betingelser afgør, hvilken pris du kan bære, og ingen af designene begrænser noget, før autorisationspolitikken gør det.

Start med opgaven, ikke kontoen

Opgaven definerer grænsen: hvilke destinationer, hvilke tjenester, hvilke timer, hvor længe en session må køre. En tunnelrute er kun halvdelen af den grænse. Gatewayen afgør, om sessionen er tilladt; ressourcen bag den afgør, hvad sessionen kan gøre. Skriv listen først, med en navngivet ejer, fordi begge identitetsdesign skal opfylde den.

Hold autentifikation og autorisation adskilt, mens du skriver det ned. Autentifikation svarer på, hvem der forbinder; autorisation svarer på, hvad sessionen må nå bagefter. RADIUS bærer den anden del som attributter som Filter-Id, Framed-IP-Address, Session-Timeout og Class, og gatewayen vedhæfter dem, når login lykkes. Et design, der bytter login og lader autorisationen være urørt, har ikke begrænset noget.

Delt menneskeligt login: adgangskoden bliver grænsen

Genbrug af en menneskelig konto er den hurtigste vej og den, der ældes værst. Legitimationsoplysningen er en adgangskode, så den ender i et script, en miljøfil og en planlæggerkonfiguration, og hver kopi skal roteres. Når ejeren ændrer den en fredag, fejler jobbet ved næste kørsel, og ingen kigger.

MFA er der, hvor dette design normalt bryder sammen. Et script kan ikke svare på en push-anmodning, så kontoen udelades fra politikken, og det er præcis den konto, en angriber ville vælge. Undtagelser, omgåelser af betroede placeringer og undtagelser pr. konto formerer sig, og ingen af dem er synlig for den næste person, der læser tenant-indstillingerne.

Tilskrivning er den anden pris. Hver session i gateway-loggen bærer det samme brugernavn, så den natlige synkronisering kan ikke skelnes fra arbejdet fra den person, der skrev den, og tilbagekaldelse af jobbet betyder tilbagekaldelse af den person.

Maskincertifikat: identitet bundet til værten

Et certifikat ændrer spørgsmålet fra, hvad kontoen ved, til hvad værten er. Med EAP-TLS fremviser klienten et certifikat og beviser besiddelse af den matchende private nøgle; policyserveren mapper subjektet eller computerkontoen til en gruppe og anvender politikken for den gruppe. Ingen prompt, ingen delt hemmelighed i en tekstfil.

Den grænse, den skaber, er snævrere, end folk forventer. Et certifikat autentificerer værten, ikke opgaven, og enhver med root- eller lokale administratorrettigheder kan bruge den nøgle på den vært. Opbevar nøglen, hvor platformen beskytter den: ikke-eksporterbar i Windows-certifikatlageret, TPM-understøttet hvor profilen tillader det, eller en root-ejet 0600-fil på Linux. Kompromittering af værten er kompromittering af legitimationsoplysningen.

Udløb er den tilbagevendende fejl. Et certifikat, der udløber en søndag, stopper jobbet om søndagen, og gatewayen rapporterer normalt en generisk autentifikationsfejl i stedet for at nævne datoen. Kontroller datoerne fra jobværten som en del af runbooken:

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

Tilbagekaldelse kræver en vej, som gatewayen kontrollerer. OpenVPN læser en CRL via crl-verify-indstillingen, og strongSwan afhænger af CRL eller OCSP efter, hvordan forbindelsesprofilen er bygget. Hvis ingen af dem er koblet op, betyder fjernelse af en vært at vente på, at certifikatet udløber.

Tre betingelser, der afgør valget

Kør sammenligningen mod den platform, du har, ikke mod et referencedesign.

Første betingelse: kan gatewayen autorisere en maskinidentitet? Hvis den kun mapper et RADIUS-brugernavn til en katalogbruger, autentificerer et certifikat værten og stopper derefter ved autorisationen. Anden betingelse: har jobbet brug for ressourceadgang, som kun en brugerkonto bærer, såsom en mappet share eller en licens pr. sæde? Så kan en maskinidentitet ikke erstatte den, og det ærlige svar er en dedikeret brugerkonto med en afgrænset politik. Tredje betingelse: hvem kan rotere legitimationsoplysningen uden en person i loopet? Automatisk tilmelding gør certifikater billige at holde; en adgangskode, som én person kender, gør ikke.

Læs tabellen som en liste over omkostninger, ikke som en rangordning. Kolonnen med gemt hemmelighed vinder på tilbagekaldelseshastighed og på kompatibilitet med ressourcer, der kun forstår brugerkonti; certifikatkolonnen vinder på rotation og på ikke at svække MFA for at få et script til at virke.

Læg grænsen i politikken, efter autentifikation

Uanset hvilken identitet du vælger, hører tilladelsesgrænsen til politikken, der kører efter autentifikation. I NPS evalueres netværkspolitikker i rækkefølge, og den første politik, der matcher enhver betingelse, anvender sine indstillinger, så en bred politik anbragt over en snæver afgør resultatet, uanset hvad klienten præsenterer. Microsoft dokumenterer betingelses- og indstillingsmodellen i sit NPS-politikoverblik.

Giv jobbet sin egen gruppe eller politikbetingelse baseret på noget, som maskinidentiteten bærer: en certifikatskabelon, en opkaldsstationsidentifikator eller en adresse fra en dedikeret pulje. Afgræns derefter sessionen med attributter: et Filter-Id til den rolle, din gateway mapper den til, en kort Session-Timeout, så et fastlåst job autentificerer igen i stedet for at holde en session i dagevis, og en Framed-IP-Address fra en pulje, du firewalls på den anden side. Applikationsautorisation holdes adskilt: en tunnel til en databaseserver er ikke tilladelse til at læse en tabel i den.

Bekræft afvisninger, planlæg derefter fjernelse

Adgang, der virker, beviser intet om mindste privilegium. Test i stedet afvisningerne: forbind med jobidentiteten og forsøg at nå en destination uden for listen, åbn en anden samtidig session, hvis gatewayen skal tillade kun én, og gentag login efter tilbagekaldelse af legitimationsoplysningen.

Bekræft derefter den samme session to steder. Gateway-loggen viser den identitet, der autentificerede; policyserverloggen viser, hvilken politik der matchede, og hvilke attributter den returnerede. På OpenVPN registrerer serveren certifikatets common name, og ipsec statusall på strongSwan udskriver den etablerede tunnel med den anvendte identitet. Hvis de to logs er uenige om identiteten, matcher politikken noget andet, end du antager.

Fjernelse hører til i designet, ikke i et oprydningssprint. Skriv alt ned, der skal slettes (certifikat eller konto, gruppemedlemskab, netværkspolitik, puljeindgang, firewallregel på målet), og kør det én gang, mens jobbet er let at genopbygge.

Hvis du starter i dag, arbejd i denne rækkefølge: skriv ressourcelisten, vælg identiteten med de tre betingelser, læg grænsen i politikken, og øv en afvisning, før jobbet går i drift.