Udskiftning af en lækket VPN-nøgle: hvad serveren skal gøre

En bærbar computer med en klientnøgle blev tabt, og det første skridt er normalt at slette den lokale kopi. Det ændrer intet på serveren, som stadig har en autorisation, der vil acceptere den nøgle, indtil nogen fjerner den. Udskiftning er to operationer, og kun den anden angår den gamle adgangsoplysning.

Den lokale kopi er ikke autoriteten

En VPN-adgangsoplysning accepteres, fordi serverkonfigurationen siger det. For certifikater betyder det, at certifikatet kæder til en betroet udsteder og ikke optræder på en spærreliste, som gatewayen konsulterer. For WireGuard betyder det, at peerens offentlige nøgle optræder i interface-konfigurationen. Når man sletter en fil på en klient, fjerner man én kopi af en hemmelighed og lader acceptreglen være urørt.

Det er derfor en stjålen nøgle bliver ved med at virke efter den oplagte oprydning, og derfor virker hændelsen uafklaret, selv når den nye konfiguration er installeret.

Begynd med serverens regel, og arbejd så udad mod klienten.

Certifikater: serveren træffer beslutningen

Udsted erstatningen gennem udstederens egen proces, så den nye identitet bliver registreret, og træk derefter den gamle tilbage med en signeret tilbagekaldelse. Gatewayen skal være konfigureret til at konsultere den tilbagekaldelseskilde og skal genindlæse den, ellers ligger filen på disken, mens tunnelen fortsat accepterer det gamle serienummer. Aktive sessioner kan også overleve indtil en ny forhandling, så planlæg en genopkobling.

Bekræft, at erstatningen virker til den tilsigtede applikation, og bekræft derefter gennem en godkendt proces, at det tilbagetrukne certifikat ikke længere giver adgang.

Det er to forskellige tests, og begge er nødvendige. RFC 5280 definerer den certifikat- og tilbagekaldelsessemantik, som gatewayen støtter sig til.

WireGuard: peernøglen er identiteten

WireGuard har ikke noget certifikatlag: peerens offentlige nøgle er identiteten, og serverens allowed-ips-post er autorisationen. At fjerne den gamle peer fra interface-konfigurationen er tilbagekaldelsen, og den gælder for nye handshakes med det samme.

Eksisterende sessioner slutter, når det næste handshake fejler, hvilket normalt sker inden for et par minutter og ikke øjeblikkeligt.

Distribuér den nye konfiguration gennem en kanal, du ville betro et password, fordi den private nøgle er adgangsoplysningen. Hold én nøgle per enhed, så én tabt enhed ikke tvinger alle enheder til at skifte.

Hvad ellers var i den pakke

En klientpakke bærer ofte mere end den private nøgle: en statisk TLS-nøgle, et brugernavn og en adgangskode, en forud delt hemmelighed eller et provisioning-token. Afgræns hændelsen til det, der faktisk blev eksponeret, og rotér også de elementer. At rotere certifikatet, mens en delt statisk nøgle bliver liggende, lukker én dør og lader en anden stå åben.

Hvis pakken blev delt mellem enheder, arver hver enhed, der bærer den, eksponeringen.

Skriv ned, hvad der blev roteret, fordi den næste revision vil spørge.

Bevis afvisningen, og registrer derefter udskiftningen

Udskiftningen er fuldført, når to fakta holder: den nye identitet virker til den tilsigtede tjeneste, og den gamle afvises. Verificér det andet med den tilbagetrukne adgangsoplysning fra et testmiljø eller med et kontrolleret forsøg, som organisationen godkender, og læs gatewayens logfiler for at bekræfte, at afvisningen kom fra politik og ikke fra en tastefejl. Registrér derefter den gamle identifikator, den nye og tidspunktet for ændringen, fordi det er de tre værdier, en revisor skal bruge for at genskabe det. Intet andet i billetten vil forklare hullet.

Hold private nøgler ude af billetter og chat, og fjern forældede eksporter fra lager og backup efter politik.

En udskiftning uden en afvisningstest er en antagelse og ikke en rettelse.