Contrasenya VPN desada: qui pot desxifrar-la i quan

Un client VPN que mostra una contrasenya xifrada al seu XML gairebé no us ha dit res. El text xifrat només respon que el valor no s'emmagatzema com a text pla en aquesta representació. Qui pot desxifrar-lo, amb quina clau i sota quin context d'usuari són les preguntes que decideixen si l'emmagatzematge ajuda. Responeu-les abans de qualificar el fitxer de segur o insegur.

Determineu quin objecte s'emmagatzema

Comenceu pel model d'emmagatzematge documentat del producte. Un client pot desar una contrasenya recuperable, un testimoni o una referència a un magatzem de credencials, i cadascun té una exposició diferent. El nom de l'element XML no és el disseny, i una cadena que sembla base64 tampoc no és prova de xifratge.

Pregunteu al proveïdor o a l'administrador quin component llegeix el valor en el moment de connectar.

Després identifiqueu l'API de protecció si està documentada. A Windows, CryptProtectData protegeix les dades amb una clau derivada de les credencials d'inici de sessió de l'usuari que xifra, i la seva opció d'abast de màquina canvia qui pot desxifrar. És un exemple concret de per què l'abast importa. No és prova que cap client VPN concret faci servir aquesta API.

Separeu una còpia robada de l'ús en temps d'execució

Un client que es reconnecta sense preguntar-vos necessita una manera suportada de recuperar la credencial. Protegir una còpia de seguretat no elimina aquesta capacitat. Qualsevol programa que s'executi en el context d'usuari correcte pot fer servir el mateix camí, i per això el punt final mateix és dins del límit de confiança. Els permisos de fitxer i els privilegis de procés estrenyen aquest límit; no l'eliminen.

Aquesta és la distinció que sol equivocar una afirmació sobre un fitxer fora de línia. El xifratge en repòs pot aturar qui copia un fitxer sense el compte. No atura el codi que s'executa com el compte.

Totes dues afirmacions poden ser certes alhora, i la segona és la que importa durant la resposta a incidències.

Llegiu els controls d'accés que s'apliquen realment

Reviseu l'ACL del fitxer i el directori que hi ha a sobre, no només el mode del fitxer. A Windows, compareu els permisos efectius del perfil d'usuari amb els del servei o la tasca programada del client. Un secret protegit per a un usuari no queda automàticament protegit d'un administrador, ni hi queda automàticament exposat.

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

Anoteu quina identitat executa el client, perquè aquesta identitat és el subjecte del desxifratge.

En un parc gestionat, el control rellevant pot ser la gestió de dispositius més que el fitxer. Pregunteu si la credencial es diposita en dipòsit, si es pot revocar remotament i quin és el procés quan es perd un dispositiu.

Planifiqueu l'exposició en lloc de provar el desxifratge

No executeu una eina d'extracció desconeguda contra el fitxer per demostrar un punt. Pot funcionar, pot danyar el perfil i, en qualsevol cas, canvia les proves. Feu servir el disseny documentat i una avaluació autoritzada si la verificació és realment necessària.

Si es determina l'exposició, canvieu la credencial al propietari de la identitat.

Suprimir l'entrada desada no és revocació. Pot impedir que aquest client torni a oferir el valor, i no fa res per a una còpia ja presa o una sessió ja autoritzada. Substituïu la credencial, acabeu les sessions que el propietari pugui acabar i anoteu què s'ha canviat i quan.

Les preguntes per a una revisió del proveïdor

Pregunteu quin secret s'emmagatzema, quin component l'usa, quina clau d'usuari o de màquina el protegeix, quins controls d'accés s'apliquen a l'ús normal i a les còpies de seguretat, i com es gestionen la política de desament i la invalidació remota. Aquestes cinc respostes descriuen el disseny; l'XML no.

Guardeu les respostes amb el registre de desplegament perquè el següent revisor no repeteixi l'exercici.

Una credencial desada és un intercanvi entre comoditat i exposició. Feu l'intercanvi deliberadament i anoteu qui l'ha acceptat.