VPN-tilgang for tjenestekonto: sertifikat eller delt innlogging

To utforminger dekker nesten hvert ubetjente VPN-oppsett: en delt menneskelig innlogging som oppbevares i et skript, eller et maskinseritfikat bundet til verten. De svikter på forskjellige steder, og det betyr mer enn hvor raskt oppsettet er. Et lagret passord knekker når eieren endrer det eller slutter; et sertifikat knekker når det utløper eller når verten bygges på nytt uten nøkkelen. Tre forhold avgjør hvilken kostnad du kan bære, og ingen av utformingene begrenser noe før autorisasjonspolicyen gjør det.

Start med oppgaven, ikke med kontoen

Oppgaven definerer grensen: hvilke mål, hvilke tjenester, hvilke tider, hvor lenge en økt kan vare. En tunnelrute er bare halvparten av den grensen. Gatewayen avgjør om økten er tillatt; ressursen bak den avgjør hva økten kan gjøre. Skriv listen først, med en navngitt eier, fordi begge identitetsutformingene 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. En utforming som bytter ut innloggingen og lar autorisasjonen være, har ikke begrenset noe.

Delt menneskelig innlogging: passordet blir grensen

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

MFA er der denne utformingen vanligvis kollapser. Et skript kan ikke svare på en push-forespørsel, så kontoen blir utelatt fra policyen, og det er nøyaktig kontoen en angriper ville velge. Unntak, omgåelser for klarerte plasseringer og fritak per konto multipliseres, og ingen av dem er synlige for den neste som leser leietakerinnstillingene.

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

Maskinseritfikat: identitet bundet til verten

Et sertifikat endrer spørsmålet fra hva kontoen vet til hva verten er. Med EAP-TLS viser 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 som ligger i en tekstfil.

Grensen det skaper er smalere enn folk forventer. Et sertifikat autentiserer verten, ikke oppgaven, og alle med root- eller lokal administratorrett 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. Kompromittert vert er kompromittert legitimasjon.

Utløp er den tilbakevendende feilen. Et sertifikat som utløper på 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 gjennom crl-verify-alternativet, og strongSwan er avhengig av CRL eller OCSP etter hvordan tilkoblingsprofilen er bygget. Hvis ingen av dem er koblet opp, betyr fjerning av en vert å vente på at sertifikatet utløper.

Tre forhold som avgjør mellom dem

Kjør sammenligningen mot plattformen du har, ikke mot en referanseutforming.

Første forhold: 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 forhold: trenger jobben ressurstilgang som bare en brukerkonto bærer, som en tilkoblet deling eller en lisens per sete? Da kan ikke en maskinidentitet erstatte den, og det ærlige svaret er en dedikert brukerkonto med en avgrenset policy. Tredje forhold: hvem kan rotere legitimasjonen uten en person i loopen? Automatisk registrering gjør sertifikater billige å holde; et passord som én person kjenner, er det ikke.

Les tabellen som en liste over kostnader, 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 autentiseringen

Uansett hvilken identitet du velger, hører tillatelsesgrensen hjemme i policyen som kjøres etter autentiseringen. I NPS evalueres nettverkspolicyer i rekkefølge, og den første policyen som samsvarer med alle forhold, bruker innstillingene sine, så en bred policy plassert over en smal avgjør resultatet uansett hva klienten presenterer. Microsoft dokumenterer modellen for forhold og innstillinger i sin oversikt over NPS-policyer.

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

Verifiser avslagene, planlegg så fjerningen

Tilgang som virker, beviser ingenting om minste privilegium. Test avslagene i stedet: koble til med jobbidentiteten og strekk deg etter et mål utenfor listen, åpne en andre samtidig økt hvis gatewayen skal tillate bare én, og gjenta innloggingen etter at du har tilbakekalt legitimasjonen.

Bekreft så 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 det du antar.

Fjerning hører hjemme i utformingen, ikke i en oppryddingssprint. Skriv ned alt som skal slettes (sertifikat eller konto, gruppemedlemskap, nettverkspolicy, oppføring i gruppen, brannmurregel på målet) og kjør det én gang mens jobben er lett å bygge opp igjen.

Hvis du starter i dag, arbeid i denne rekkefølgen: skriv ressurslisten, velg identiteten med de tre forholdene, legg grensen i policyen, og øv på ett avslag før jobben går live.