VPN-tilgang med tjenestekonto: sertifikat eller delt innlogging

To design dekker nesten alle uovervåkede VPN-oppsett: en delt menneskelig innlogging holdt i et skript, eller et maskinsertifikat bundet til verten. De svikter på forskjellige steder, og det betyr mer enn oppsettets hastighet. Et lagret passord ryker når eieren endrer det eller slutter; et sertifikat ryker når det utløper eller når verten bygges på nytt uten nøkkelen. Tre betingelser avgjør hvilken kostnad du kan bære, og ingen av designene begrenser noe før autorisasjonspolicyen gjør det.

Start med oppgaven, ikke kontoen

Oppgaven definerer grensen: hvilke destinasjoner, hvilke tjenester, hvilke timer, hvor lenge en økt kan kjøre. En tunnellrute er bare halvparten av den grensen. Gatewayen avgjør om økten er tillatt; ressursen bak bestemmer hva økten kan gjøre. Skriv listen først, med en navngitt eier, fordi begge identitetsdesignene må oppfylle den.

Hold autentisering og autorisasjon fra hverandre mens du skriver det ned. Autentisering svarer på hvem som kobler til; autorisasjon svarer på hva økten kan nå etterpå. RADIUS bærer den andre delen som attributter som Filter-Id, Framed-IP-Address, Session-Timeout og Class, og gatewayen fester dem når innloggingen lykkes. Et design som bytter innloggingen og lar autorisasjonen være urørt, har ikke begrenset noe.

Delt menneskelig innlogging: passordet blir grensen

Gjenbruk av en menneskelig konto er den raskeste veien og den som eldes dårligst. Legitimasjonen er et passord, så det ender i et skript, en miljøfil og en planleggerkonfigurasjon, og hver kopi må roteres. Når eieren endrer det på en fredag, feiler jobben ved neste kjøring, og ingen følger med.

MFA er der dette designet vanligvis kollapser. Et skript kan ikke svare på en push-forespørsel, så kontoen utelates fra policyen, og det er nøyaktig den kontoen en angriper ville valgt. Unntak, omgåelser av klarerte plasseringer og unntak per konto multipliseres, og ingen av dem er synlig for neste person som leser leietakerens innstillinger.

Tilskrivning er den andre kostnaden. Hver økt i gateway-loggen bærer samme brukernavn, så nattsynkroniseringen kan ikke skilles fra arbeidet til personen som skrev den, og å tilbakekalle jobben betyr å tilbakekalle den personen.

Maskinsertifikat: identitet bundet til verten

Et sertifikat endrer spørsmålet fra hva kontoen vet til hva verten er. Med EAP-TLS legger klienten fram et sertifikat og beviser at den har den tilhørende private nøkkelen; policyserveren mapper subjektet eller datamaskinkontoen til en gruppe og bruker policyen for den gruppen. Ingen forespørsel, ingen delt hemmelighet i en tekstfil.

Grensen det skaper er smalere enn folk forventer. Et sertifikat autentiserer verten, ikke oppgaven, og enhver med root- eller lokale administratorrettigheter kan bruke den nøkkelen på den verten. Oppbevar nøkkelen der plattformen beskytter den: ikke-eksporterbar i Windows-sertifikatlageret, TPM-støttet der profilen tillater det, eller en root-eid 0600-fil på Linux. Kompromittering av verten er kompromittering av legitimasjonen.

Utløp er den tilbakevendende feilen. Et sertifikat som utløper en søndag, stopper jobben på søndag, og gatewayen rapporterer vanligvis en generisk autentiseringsfeil i stedet for å navngi datoen. Kontroller datoene fra jobbverten som en del av runbooken:

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

Tilbakekalling trenger en vei som gatewayen kontrollerer. OpenVPN leser en CRL via crl-verify-valget, og strongSwan avhenger av CRL eller OCSP etter hvordan tilkoblingsprofilen er bygget. Hvis ingen av dem er koblet til, betyr fjerning av en vert å vente på at sertifikatet utløper.

Tre betingelser som avgjør mellom dem

Kjør sammenligningen mot plattformen du har, ikke mot et referansedesign.

Første betingelse: kan gatewayen autorisere en maskinidentitet? Hvis den bare mapper et RADIUS-brukernavn til en katalogbruker, autentiserer et sertifikat verten og stopper så ved autorisasjonen. Andre betingelse: trenger jobben ressurstilgang som bare en brukerkonto bærer, som en tilkoblet deling eller en lisens per sete? Da kan en maskinidentitet ikke erstatte, og det ærlige svaret er en dedikert brukerkonto med en avgrenset policy. Tredje betingelse: hvem kan rotere legitimasjonen uten en person i loopen? Automatisk registrering gjør sertifikater billige å holde; et passord som én person kjenner, ikke.

Les tabellen som en kostnadsliste, ikke som en rangering. Kolonnen for lagret hemmelighet vinner på tilbakekallingshastighet og på kompatibilitet med ressurser som bare forstår brukerkontoer; sertifikatkolonnen vinner på rotasjon og på å ikke svekke MFA for å få et skript til å virke.

Legg grensen i policyen, etter autentisering

Uansett hvilken identitet du velger, hører tillatelsesgrensen til policyen som kjøres etter autentisering. I NPS evalueres nettverkspolicyer i rekkefølge, og den første policyen som samsvarer med hver betingelse, bruker innstillingene sine, så en bred policy plassert over en smal avgjør resultatet uansett hva klienten presenterer. Microsoft dokumenterer betingelses- og innstillingsmodellen i sin NPS-policyoversikt.

Gi jobben sin egen gruppe eller policybetingelse, basert på noe maskinidentiteten bærer: en sertifikatmal, en identifikator for den anropende stasjonen eller en adresse fra en dedikert pool. Avgrens deretter økten med attributter: en Filter-Id for rollen gatewayen din mapper den til, en kort Session-Timeout slik at en fastlåst jobb autentiserer seg på nytt i stedet for å holde en økt i dager, og en Framed-IP-Address fra en pool du brannmur på den andre siden. Applikasjonsautorisasjon holdes atskilt: en tunnel til en databaseserver er ikke tillatelse til å lese en tabell i den.

Bekreft avvisningene, planlegg deretter fjerning

Tilgang som virker, beviser ingenting om minste privilegium. Test avvisningene i stedet: koble til med jobbidentiteten og prøv å nå en destinasjon utenfor listen, åpne en andre samtidig økt hvis gatewayen skal tillate bare én, og gjenta innloggingen etter at legitimasjonen er tilbakekalt.

Bekreft deretter den samme økten på to steder. Gateway-loggen viser identiteten som autentiserte; policyserverloggen viser hvilken policy som samsvarte og hvilke attributter den returnerte. På OpenVPN registrerer serveren sertifikatets common name, og ipsec statusall på strongSwan skriver ut den etablerte tunnelen med identiteten som brukes. Hvis de to loggene er uenige om identiteten, samsvarer policyen med noe annet enn du antar.

Fjerning hører til i designet, ikke i en oppryddingssprint. Skriv ned alt som skal slettes (sertifikat eller konto, gruppemedlemskap, nettverkspolicy, pooloppføring, brannmurregel på målet), og kjør det én gang mens jobben er lett å gjenoppbygge.

Hvis du starter i dag, arbeid i denne rekkefølgen: skriv ressurslisten, velg identiteten med de tre betingelsene, legg grensen i policyen, og øv på én avvisning før jobben settes i drift.