Hvorfor servernøkler og brukerlegitimasjon trenger hver sin eier
En gateway-identitet og en brukertillatelse er forskjellige hemmeligheter med forskjellige konsekvenser. Tre spørsmål avgjør hvordan hver av dem lagres, utleveres og tilbakekalles.
Nøkkelen som beviser at gatewayen din er seg selv, og legitimasjonen som sier at en person kan bli med, er begge hemmeligheter, og det er der likheten slutter. Den ene identifiserer en tjeneste overfor hver klient; den andre identifiserer én bruker overfor den tjenesten. Å blande dem sparer ett trinn under oppsett og koster en ettermiddag under en hendelse, fordi gjenopprettingen for hver av dem ikke er den samme operasjonen. Oppdelingen er kjedelig å sette opp og minneverdig å hoppe over.
To hemmeligheter, to forskjellige eiere
Gatewayen holder en privat nøkkel eller et sertifikat hvis eneste oppgave er å bevise identiteten sin under håndtrykket. Klienter trenger det matchende offentlige materialet for å verifisere den, og de trenger aldri den private halvdelen. Det er denne asymmetrien som gjør serverautentisering mulig uten å gi hver bruker evnen til å etterligne serveren.
Brukermateriale går den andre veien. En klients private nøkkel, et klient sertifikat eller et passord viser at nettopp denne personen eller enheten har fått tilgang. Det forventes å bli distribuert, kopiert mellom enheter og til slutt tilbakekalt.
WireGuard gjør oppdelingen åpenbar fordi hver deltaker har et nøkkelpar: serverens private nøkkel blir på serveren, og en konfigurasjonsfil du gir en bruker inneholder deres egen private nøkkel pluss serverens offentlige nøkkel. En profil som inneholder serverens private nøkkel er ikke en snarvei, den er et kompromiss som venter på en fildeling.
Tre spørsmål som avgjør oppdelingen
Spør hvem som må kunne lese hemmeligheten, hva en eksponering ville la en angriper gjøre, og om rettelsen er én tilbakekalling eller en gjenoppbygging av tjenesten.
Hvis en bruker kan lese den, og den beviser gatewayens identitet, er svaret på det andre spørsmålet at angriperen kan etterligne serveren din overfor hver klient — det verste utfallet, fordi klienter er laget for å stole på den identiteten. Hvis den bare beviser én bruker, gir eksponeringen den brukeren tilgang til én peer, og tilbakekalling er en rutineoperasjon. Hvis det er en sertifiseringsmyndighetsnøkkel, er eksponeringen verre enn begge, siden angriperen kan lage identiteter som hvert endepunkt stoler på.
De tre svarene gir lagringsregelen: CA-nøkkelen bor offline eller i et pengeskap, gatewaynøkkelen bor på gatewayen, og brukernøkler bor hos brukerne. Ethvert oppsett som legger alle tre i én mappe for enkelhets skyld, har gjort en beslutning om til en ulykke.
Hva en klient faktisk trenger
En klient trenger det offentlige sertifikatet eller den offentlige peernøkkelen, CA-materialet eller fingeravtrykket den skal stole på, sin egen private nøkkel og endepunktdetaljene. Den listen inneholder ingenting som tilhører gatewayens private identitet.
Dokumentasjonen er der dette lekker. En veiledning som sier kopier servermappen og slett det du ikke trenger, har allerede lært bort feil modell, fordi filen som blir igjen etter slettetrinnet sjelden blir kontrollert av noen.
Tilbakekall én bruker uten å røre gatewayen
Fordi brukeridentiteter utstedes separat, kan de trekkes tilbake separat. En sertifikatbasert utrulling tilbakekaller klient sertifikatet og publiserer en oppdatert tilbakekallingsliste; en WireGuard-utrulling fjerner peer-oppføringen fra serverkonfigurasjonen. Ingen av disse operasjonene endrer gatewayens egen nøkkel.
Ta vare på utstedelsesregisteret, ellers vet du ikke hvilken identitet som skal trekkes tilbake. Et regneark er nok, forutsatt at det navngir personen, enheten, serienummeret eller den offentlige nøkkelen og datoen, og forutsatt at noen eier det etter at personen som bygde det, har sluttet.
Kommandoene nedenfor inspiserer et klient sertifikat og tilbakekaller det deretter gjennom en myndighet i OpenSSL-stil, som er flyten easy-rsa pakker inn:
openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pemPubliser den nye listen der klientene kontrollerer den, ellers er tilbakekallingen et notat i en fil som ikke endrer noe. Hvis gatewayen din godtar klient sertifikater uten å konsultere en tilbakekallingsliste, si det eksplisitt i stedet for å antyde at tilbakekalling fungerer.
Hold sikkerhetskopier like atskilt som hemmelighetene
Et gjenoppbyggingsarkiv inneholder med rette gatewaynøkkelen og CA-materialet, fordi en gjenoppretting uten dem ikke kan gjenskape tjenesten. En klientoppsettspakke må ikke, og de to må ikke lagres sammen. Merk hvert arkiv etter hvem som kan holde det, ikke etter datoen det ble laget. Det merket er det en sliten administrator leser klokken to om natten.
Den forskjellen fastsetter også hvem som kan hente hver av dem. Å administrere gatewayen, utstede brukeridentiteter og lese sikkerhetskopier er tre forskjellige fullmakter, og en person som trenger én, trenger ikke automatisk de andre. Skriv ned disse tillatelsene, og kontroller dem deretter mot det lagringen din faktisk tillater, fordi mappearv gir stille mer enn policyen tar sikte på.