Password VPN salvata: chi può decifrarla e quando
Il testo cifrato in un file client non dimostra quasi nulla. Identificate il proprietario della chiave, l'uso a runtime e i controlli di accesso prima di giudicare l'archiviazione.
Un client VPN che mostra una password cifrata nel suo XML non vi ha detto quasi nulla. Il testo cifrato risponde soltanto che il valore non è memorizzato come testo in chiaro in quella rappresentazione. Chi può decifrarlo, con quale chiave e in quale contesto utente sono le domande che decidono se l'archiviazione serve. Rispondete prima di definire il file sicuro o non sicuro.
Stabilite quale oggetto viene memorizzato
Partite dal modello di archiviazione documentato del prodotto. Un client può memorizzare una password recuperabile, un token o un riferimento a un archivio di credenziali, e ciascuno ha un'esposizione diversa. Il nome dell'elemento XML non è il progetto, e una stringa che sembra base64 non è nemmeno una prova di cifratura.
Chiedete al fornitore o all'amministratore quale componente legge il valore al momento della connessione.
Poi identificate l'API di protezione se è documentata. In Windows, CryptProtectData protegge i dati con una chiave derivata dalle credenziali di accesso dell'utente che cifra, e la sua opzione con ambito macchina cambia chi può decifrare. È un esempio concreto del perché l'ambito conta. Non è la prova che un determinato client VPN usi quell'API.
Separate una copia rubata dall'uso a runtime
Un client che si riconnette senza chiedervi ha bisogno di un modo supportato per recuperare la credenziale. Proteggere una copia di backup non elimina questa capacità. Qualsiasi programma in esecuzione nel contesto utente corretto può usare lo stesso percorso, ed è per questo che l'endpoint stesso si trova dentro il confine di fiducia. Le autorizzazioni dei file e i privilegi dei processi restringono quel confine; non lo eliminano.
È questa la distinzione che di solito sbaglia un'affermazione su un file offline. La cifratura a riposo può fermare chi copia un file senza l'account. Non ferma il codice che viene eseguito come l'account.
Entrambe le affermazioni possono essere vere contemporaneamente, e la seconda è quella che conta durante la risposta a un incidente.
Leggete i controlli di accesso che si applicano davvero
Controllate l'ACL del file e la directory superiore, non solo il modo del file. In Windows, confrontate le autorizzazioni effettive del profilo utente con quelle del servizio o dell'attività pianificata del client. Un segreto protetto per un utente non è automaticamente protetto da un amministratore, né automaticamente esposto a uno.
icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv
Registrate quale identità esegue il client, perché quell'identità è il soggetto della decifratura.
Per un parco gestito il controllo pertinente può essere la gestione dei dispositivi invece del file. Chiedete se la credenziale è depositata in custodia, se può essere revocata da remoto e qual è la procedura quando un dispositivo si perde.
Pianificate l'esposizione invece di testare la decifratura
Non eseguite uno strumento di estrazione sconosciuto sul file per dimostrare un punto. Può funzionare, può danneggiare il profilo e in ogni caso altera le prove. Usate il progetto documentato e una valutazione autorizzata se la verifica è davvero necessaria.
Se l'esposizione è accertata, ruotate la credenziale presso il proprietario dell'identità.
Eliminare la voce salvata non è una revoca. Può impedire a quel client di offrire di nuovo il valore, e non fa nulla per una copia già presa o una sessione già autorizzata. Sostituite la credenziale, terminate le sessioni che il proprietario può terminare e registrate cosa è stato ruotato e quando.
Le domande per una revisione del fornitore
Chiedete quale segreto è memorizzato, quale componente lo usa, quale chiave utente o macchina lo protegge, quali controlli di accesso si applicano all'uso normale e ai backup, e come vengono gestite la politica di salvataggio e l'invalidazione da remoto. Quelle cinque risposte descrivono il progetto; l'XML no.
Conservate le risposte con il registro di distribuzione, così il prossimo revisore non ripete l'esercizio.
Una credenziale salvata è uno scambio tra comodità ed esposizione. Fate lo scambio deliberatamente e annotate chi lo ha accettato.