Gemt VPN-adgangskode: hvem kan dekryptere den, og hvornår

En VPN-klient, der viser en krypteret adgangskode i sin XML, har ikke fortalt dig ret meget. Krypteringsteksten svarer kun, at værdien ikke er gemt som klartekst i den repræsentation. Hvem der kan dekryptere den, med hvilken nøgle, og i hvilken brugerkontekst er de spørgsmål, der afgør, om opbevaringen hjælper. Besvar dem, før du kalder filen sikker eller usikker.

Fastlæg, hvilket objekt der gemmes

Begynd med produktets dokumenterede opbevaringsmodel. En klient kan gemme en gendannelig adgangskode, et token eller en reference til et legitimationslager, og hver har en forskellig eksponering. XML-elementets navn er ikke designet, og en streng, der ligner base64, er heller ikke bevis på kryptering.

Spørg leverandøren eller administratoren, hvilken komponent der læser værdien ved forbindelsestidspunktet.

Find derefter beskyttelses-API'et, hvis det er dokumenteret. I Windows beskytter CryptProtectData data med en nøgle afledt af den krypterende brugers logonoplysninger, og maskinindstillingen ændrer, hvem der kan dekryptere. Det er et konkret eksempel på, hvorfor omfanget betyder noget. Det er ikke bevis for, at en bestemt VPN-klient bruger det API.

Adskil en stjålet kopi fra brug under kørsel

En klient, der genopretter forbindelsen uden at spørge, har brug for en understøttet måde at gendanne legitimationsoplysningen på. Beskyttelse af en sikkerhedskopi fjerner ikke den mulighed. Ethvert program, der kører i den rigtige brugerkontekst, kan muligvis bruge samme vej, og derfor ligger endepunktet selv inden for tillidsgrænsen. Filtilladelser og procesrettigheder indsnævrer den grænse; de fjerner den ikke.

Det er den forskel, en påstand om en offline-fil normalt tager fejl af. Kryptering i hvile kan stoppe nogen, der kopierer én fil uden kontoen. Den stopper ikke kode, der kører som kontoen.

Begge udsagn kan være sande samtidig, og det andet er det, der betyder noget under hændelseshåndtering.

Læs den adgangskontrol, der faktisk gælder

Kontroller filens ACL og mappen ovenover, ikke kun filtilstanden. Sammenlign i Windows brugerprofilens effektive tilladelser med klientens tjeneste eller planlagte opgaves. En hemmelighed, der er beskyttet for én bruger, er ikke automatisk beskyttet mod en administrator, og den er heller ikke automatisk eksponeret for en.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Notér, hvilken identitet der kører klienten, for den identitet er dekrypteringssubjektet.

For en administreret flåde kan den relevante kontrol være enhedsstyring i stedet for filen. Spørg, om legitimationsoplysningen deponeres, om den kan tilbagekaldes eksternt, og hvad processen er, når en enhed mistes.

Planlæg for eksponering i stedet for at teste dekryptering

Kør ikke et ukendt udtræksværktøj mod filen for at bevise en pointe. Det kan virke, det kan beskadige profilen, og under alle omstændigheder ændrer det beviset. Brug det dokumenterede design og en autoriseret vurdering, hvis verifikation virkelig er nødvendig.

Hvis eksponering er fastslået, skal du rotere legitimationsoplysningen hos identitetsejeren.

Sletning af den gemte post er ikke tilbagekaldelse. Det kan forhindre den klient i at tilbyde værdien igen, og det gør intet ved en kopi, der allerede er taget, eller en session, der allerede er godkendt. Udskift legitimationsoplysningen, afslut de sessioner, ejeren kan afslutte, og notér, hvad der blev roteret, og hvornår.

Spørgsmålene til en leverandørgennemgang

Spørg, hvilken hemmelighed der gemmes, hvilken komponent der bruger den, hvilken bruger- eller maskinnøgle der beskytter den, hvilke adgangskontroller der gælder for normal brug og sikkerhedskopier, og hvordan gemmepolitik og fjernannullering håndteres. De fem svar beskriver designet; XML'et gør ikke.

Opbevar svarene sammen med implementeringsregistreringen, så den næste anmelder ikke gentager øvelsen.

En gemt legitimationsoplysning er en handel mellem bekvemmelighed og eksponering. Foretag handlen bevidst, og skriv ned, hvem der accepterede den.