VPN-åtkomst för tjänstekonton: certifikat eller delad inloggning
Jämför ett maskincertifikat med ett lagrat lösenord för obevakad VPN-åtkomst och lägg den verkliga behörighetsgränsen i policyn som körs efter inloggningen.
Två utformningar täcker nästan varje obevakad VPN-konfiguration: en delad mänsklig inloggning som förvaras i ett skript, eller ett maskincertifikat bundet till värden. De fallerar på olika ställen, och det spelar större roll än hur snabbt det är att sätta upp. Ett lagrat lösenord går sönder när ägaren byter det eller slutar; ett certifikat går sönder när det löper ut eller när värden byggs om utan nyckeln. Tre villkor avgör vilken kostnad du kan bära, och ingen av utformningarna begränsar något förrän auktoriseringspolicyn gör det.
Börja med uppgiften, inte med kontot
Uppgiften definierar gränsen: vilka mål, vilka tjänster, vilka tider, hur länge en session får pågå. En tunnelväg är bara halva den gränsen. Gatewayen avgör om sessionen är tillåten; resursen bakom den avgör vad sessionen får göra. Skriv listan först, med en namngiven ägare, eftersom båda identitetsutformningarna måste uppfylla den.
Håll autentisering och auktorisering åtskilda medan du skriver ned det. Autentisering svarar på vem som ansluter; auktorisering svarar på vad sessionen får nå efteråt. RADIUS bär den andra delen som attribut som Filter-Id, Framed-IP-Address, Session-Timeout och Class, och gatewayen fäster dem när inloggningen lyckas. En utformning som byter ut inloggningen och lämnar auktoriseringen orörd har inte begränsat något.
Delad mänsklig inloggning: lösenordet blir gränsen
Att återanvända ett mänskligt konto är den snabbaste vägen och den som åldras sämst. Uppgiften är ett lösenord, så det hamnar i ett skript, en miljöfil och en konfiguration för en schemaläggare, och varje kopia behöver roteras. När ägaren byter det en fredag misslyckas jobbet vid nästa körning och ingen tittar.
MFA är där den här utformningen vanligtvis kollapsar. Ett skript kan inte svara på en push-förfrågan, så kontot utesluts från policyn, och det är precis det konto en angripare skulle välja. Undantag, kringgåenden för betrodda platser och befrielser per konto multipliceras, och ingen av dem syns för nästa person som läser klientinställningarna.
Tillskrivning är den andra kostnaden. Varje session i gatewayloggen bär samma användarnamn, så nattsynkroniseringen går inte att skilja från arbetet som personen som skrev den utförde, och att återkalla jobbet betyder att återkalla den personen.
Maskincertifikat: identitet bunden till värden
Ett certifikat ändrar frågan från vad kontot vet till vad värden är. Med EAP-TLS visar klienten upp ett certifikat och bevisar innehav av den matchande privata nyckeln; policyservern mappar subjektet eller datorkontot till en grupp och tillämpar policyn för den gruppen. Ingen prompt, ingen delad hemlighet som ligger i en textfil.
Gränsen det skapar är snävare än folk förväntar sig. Ett certifikat autentiserar värden, inte uppgiften, och alla med root- eller lokal administratörsrätt kan använda nyckeln på den värden. Förvara nyckeln där plattformen skyddar den: icke-exporterbar i Windows certifikatarkiv, TPM-stödd där profilen tillåter det, eller en root-ägd 0600-fil på Linux. En komprometterad värd är en komprometterad inloggningsuppgift.
Utgång är det återkommande felet. Ett certifikat som löper ut på en söndag stoppar jobbet på söndagen, och gatewayen rapporterar vanligtvis ett allmänt autentiseringsfel i stället för att namnge datumet. Kontrollera datumen från jobbvärden som en del av runbooken:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcertsÅterkallelse behöver en väg som gatewayen kontrollerar. OpenVPN läser en CRL via crl-verify-alternativet, och strongSwan är beroende av CRL eller OCSP beroende på hur anslutningsprofilen är byggd. Om ingen av dem är inkopplad innebär borttagning av en värd att vänta på att certifikatet löper ut.
Tre villkor som avgör mellan dem
Gör jämförelsen mot den plattform du har, inte mot en referensutformning.
Första villkoret: kan gatewayen auktorisera en maskinidentitet? Om den bara mappar ett RADIUS-användarnamn till en kataloganvändare autentiserar ett certifikat värden och fastnar sedan vid auktoriseringen. Andra villkoret: behöver jobbet resursåtkomst som bara ett användarkonto bär, som en mappad delning eller en licens per plats? Då kan en maskinidentitet inte ersätta den, och det ärliga svaret är ett dedikerat användarkonto med en avgränsad policy. Tredje villkoret: vem kan rotera uppgiften utan en person i loopen? Automatisk registrering gör certifikat billiga att hålla; ett lösenord som en person känner till är det inte.
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
Läs tabellen som en lista över kostnader, inte som en rangordning. Kolumnen för lagrad hemlighet vinner på återkallelsehastighet och på kompatibilitet med resurser som bara förstår användarkonton; certifikatkolumnen vinner på rotation och på att inte försvaga MFA för att få ett skript att fungera.
Lägg gränsen i policyn, efter autentiseringen
Vilken identitet du än väljer hör behörighetsgränsen hemma i policyn som körs efter autentiseringen. I NPS utvärderas nätverkspolicyer i ordning och den första policyn som matchar alla villkor tillämpar sina inställningar, så en bred policy placerad ovanför en snäv avgör resultatet oavsett vad klienten presenterar. Microsoft dokumenterar modellen för villkor och inställningar i sin översikt över NPS-principer.
Ge jobbet en egen grupp eller policyvillkor, baserat på något som maskinidentiteten bär: en certifikatmall, en identifierare för den anropande stationen eller en adress från en dedikerad pool. Begränsa sedan sessionen med attribut: en Filter-Id för rollen som gatewayen mappar den till, en kort Session-Timeout så att ett fastlåst jobb autentiserar sig igen i stället för att hålla en session i dagar, och en Framed-IP-Address från en pool som du brandväggar på andra sidan. Applikationsauktorisering hålls åtskild: en tunnel till en databasserver är inte tillstånd att läsa en tabell inuti den.
Verifiera avslagen, planera sedan borttagningen
Åtkomst som fungerar bevisar ingenting om minsta behörighet. Testa i stället avslagen: anslut med jobbidentiteten och sträck dig efter ett mål utanför listan, öppna en andra samtidig session om gatewayen ska tillåta bara en, och upprepa inloggningen efter att du återkallat inloggningsuppgiften.
Bekräfta sedan samma session på två ställen. Gatewayloggen visar identiteten som autentiserade; policyserverloggen visar vilken policy som matchade och vilka attribut den returnerade. På OpenVPN registrerar servern certifikatets common name, och ipsec statusall på strongSwan skriver ut den upprättade tunneln med identiteten som används. Om de två loggarna inte är överens om identiteten matchar policyn något annat än det du antar.
Borttagning hör till utformningen, inte till en städsprint. Skriv ned allt som ska tas bort (certifikat eller konto, gruppmedlemskap, nätverkspolicy, poolpost, brandväggsregel på målet) och kör igenom det en gång medan jobbet är lätt att bygga upp igen.
Om du börjar i dag, arbeta i den här ordningen: skriv resurslistan, välj identiteten med de tre villkoren, lägg gränsen i policyn och öva ett avslag innan jobbet går live.