Varför servernycklar och användaruppgifter behöver separata ägare

Nyckeln som bevisar att din gateway är sig själv och uppgiften som säger att en person får ansluta är båda hemligheter, och det är där likheten slutar. Den ena identifierar en tjänst inför varje klient; den andra identifierar en användare inför den tjänsten. Att blanda dem sparar ett steg vid installationen och kostar en eftermiddag under en incident, eftersom återställningen för var och en inte är samma åtgärd. Uppdelningen är tråkig att ställa in och minnesvärd att hoppa över.

Två hemligheter, två olika ägare

Gatewayen håller en privat nyckel eller ett certifikat vars enda uppgift är att bevisa sin identitet under handskakningen. Klienter behöver motsvarande offentliga material för att verifiera den, och de behöver aldrig den privata halvan. Det är den asymmetrin som gör serverautentisering möjlig utan att ge varje användare förmågan att imitera servern.

Användarmaterial går åt andra hållet. En klients privata nyckel, ett klientcertifikat eller ett lösenord visar att just den här personen eller enheten har fått åtkomst. Det förväntas distribueras, kopieras mellan enheter och till slut återkallas.

WireGuard gör uppdelningen uppenbar eftersom varje deltagare har ett nyckelpar: serverns privata nyckel stannar på servern, och en konfigurationsfil du ger en användare innehåller deras egen privata nyckel plus serverns offentliga nyckel. En profil som innehåller serverns privata nyckel är ingen genväg, den är en kompromiss som väntar på en fildelning.

Tre frågor som avgör uppdelningen

Fråga vem som måste kunna läsa hemligheten, vad en exponering skulle låta en angripare göra och om åtgärden är en återkallning eller en ombyggnad av tjänsten.

Om en användare kan läsa den och den bevisar gatewayens identitet, är svaret på den andra frågan att angriparen kan imitera din server inför varje klient — det värsta utfallet, eftersom klienter är byggda för att lita på den identiteten. Om den bara bevisar en användare ger exponeringen den användaren åtkomst till en peer, och återkallning är en rutinåtgärd. Om det är en certifikatmyndighets nyckel är exponeringen värre än båda, eftersom angriparen kan skapa identiteter som varje slutpunkt litar på.

De tre svaren ger lagringsregeln: CA-nyckeln bor offline eller i ett kassaskåp, gatewaynyckeln bor på gatewayen och användarnycklar bor hos användarna. Varje arrangemang som lägger alla tre i en mapp för enkelhetens skull har förvandlat ett beslut till en olycka.

Vad en klient faktiskt behöver

En klient behöver det offentliga certifikatet eller den offentliga peernyckeln, CA-materialet eller fingeravtrycket som den ska lita på, sin egen privata nyckel och slutpunktens uppgifter. Listan innehåller ingenting som tillhör gatewayens privata identitet.

Dokumentationen är där detta läcker. En guide som säger kopiera servermappen och radera det du inte behöver har redan lärt ut fel modell, eftersom filen som blir kvar efter raderingssteget sällan kontrolleras av någon.

Återkalla en användare utan att röra gatewayen

Eftersom användaridentiteter utfärdas separat kan de dras tillbaka separat. En certifikatbaserad utrullning återkallar klientcertifikatet och publicerar en uppdaterad återkallningslista; en WireGuard-utrullning tar bort peer-posten från serverkonfigurationen. Ingen av dessa åtgärder ändrar gatewayens egen nyckel.

Spara utfärdanderegistret, annars vet du inte vilken identitet som ska dras tillbaka. Ett kalkylark räcker, förutsatt att det namnger personen, enheten, serienumret eller den offentliga nyckeln och datumet, och förutsatt att någon sköter det efter att personen som byggde det har slutat.

Kommandona nedan inspekterar ett klientcertifikat och återkallar det sedan genom en myndighet i OpenSSL-stil, vilket är flödet som easy-rsa paketerar:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publicera den nya listan där klienterna kontrollerar den, annars är återkallningen en anteckning i en fil som inte ändrar något. Om din gateway accepterar klientcertifikat utan att konsultera en återkallningslista, säg det explicit i stället för att antyda att återkallning fungerar.

Håll säkerhetskopior lika åtskilda som hemligheterna

Ett återuppbyggnadsarkiv innehåller med rätta gatewaynyckeln och CA-materialet, eftersom en återställning utan dem inte kan återskapa tjänsten. Ett klientinstallationspaket får inte, och de två får inte lagras tillsammans. Märk varje arkiv efter vem som får hålla det, inte efter datumet det skapades. Det är den märkningen en trött administratör läser klockan två på natten.

Den skillnaden avgör också vem som får hämta var och en. Att administrera gatewayen, utfärda användaridentiteter och läsa säkerhetskopior är tre olika befogenheter, och den som behöver en behöver inte automatiskt de andra. Skriv ned dessa behörigheter och kontrollera dem sedan mot vad din lagring faktiskt tillåter, eftersom katalogarv ger tyst mer än policyn avser.