Contrasinal VPN gardado: quen pode desifralo e cando

Un cliente VPN que mostra un contrasinal cifrado no seu XML case non lle dixo nada. O texto cifrado só responde que o valor non se almacena como texto plano nesa representación. Quen pode desifralo, con que chave e en que contexto de usuario son as preguntas que deciden se o almacenamento axuda. Respóndaa antes de cualificar o ficheiro de seguro ou inseguro.

Determine que obxecto se almacena

Comece polo modelo de almacenamento documentado do produto. Un cliente pode gardar un contrasinal recuperable, un token ou unha referencia a un almacén de credenciais, e cada un ten unha exposición distinta. O nome do elemento XML non é o deseño, e unha cadea que parece base64 tampouco é proba de cifrado.

Pregunte ao provedor ou ao administrador que compoñente le o valor ao conectar.

Despois identifique a API de protección se está documentada. En Windows, CryptProtectData protexe os datos cunha chave derivada das credenciais de inicio de sesión do usuario que cifra, e a súa opción de ámbito de máquina cambia quen pode desifrar. É un exemplo concreto de por que importa o ámbito. Non é proba de que ningún cliente VPN concreto use esa API.

Separe unha copia roubada do uso en tempo de execución

Un cliente que se reconecta sen preguntarlle necesita unha forma compatible de recuperar a credencial. Protexer unha copia de seguridade non elimina esa capacidade. Calquera programa que se execute no contexto de usuario correcto pode usar a mesma ruta, e por iso o propio punto final está dentro do límite de confianza. Os permisos de ficheiro e os privilexios de proceso estreitan ese límite; non o eliminan.

Esa é a distinción que adoita errar unha afirmación sobre un ficheiro sen conexión. O cifrado en repouso pode deter quen copia un ficheiro sen a conta. Non detén o código que se executa como a conta.

Ambas as afirmacións poden ser certas á vez, e a segunda é a que importa durante a resposta a incidentes.

Lea os controis de acceso que se aplican realmente

Revise a ACL do ficheiro e o directorio superior, non só o modo do ficheiro. En Windows, compare os permisos efectivos do perfil de usuario cos do servizo ou da tarefa programada do cliente. Un segredo protexido para un usuario non queda automaticamente protexido fronte a un administrador, nin automaticamente exposto a el.

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

Rexiste que identidade executa o cliente, porque esa identidade é o suxeito do desifrado.

Nun parque xestionado, o control relevante pode ser a xestión de dispositivos e non o ficheiro. Pregunte se a credencial se deposita en custodia, se se pode revogar de forma remota e cal é o proceso cando se perde un dispositivo.

Planifique a exposición en lugar de probar o desifrado

Non execute unha ferramenta de extracción descoñecida contra o ficheiro para demostrar un punto. Pode funcionar, pode danar o perfil e, en calquera caso, altera as probas. Use o deseño documentado e unha avaliación autorizada se a verificación é realmente necesaria.

Se se determina a exposición, rote a credencial no propietario da identidade.

Eliminar a entrada gardada non é revogar. Pode impedir que ese cliente volva ofrecer o valor, e non fai nada cunha copia xa tomada ou unha sesión xa autorizada. Substitúa a credencial, termine as sesións que o propietario poida terminar e rexistre que se rotou e cando.

As preguntas para unha revisión do provedor

Pregunte que segredo se almacena, que compoñente o usa, que chave de usuario ou de máquina o protexe, que controis de acceso se aplican ao uso normal e ás copias de seguridade, e como se xestionan a política de gardado e a invalidación remota. Esas cinco respostas describen o deseño; o XML non.

Garde as respostas co rexistro de despregamento para que o seguinte revisor non repita o exercicio.

Unha credencial gardada é un intercambio entre comodidade e exposición. Faga o intercambio de forma deliberada e anote quen o aceptou.