Due sistemi devono condividere un segreto per la firma di JWT. Il segreto deve essere condiviso e memorizzato. Esistono strumenti e indicazioni per farlo in modo sicuro?
Il primo passo è garantire che la tua applicazione sia sicura, non solo per proteggere il segreto in questione, ma anche l'applicazione nel suo complesso. Se la tua applicazione è perfettamente sicura, non ci sarà alcun exploit, e il segreto è sicuro. Sfortunatamente, non siamo perfetti ed è probabile che ci sia qualche vulnerabilità in agguato nell'applicazione che deve ancora essere scoperta.
I seguenti punti ti aiuteranno a ridurre l'impatto, nel caso in cui una vulnerabilità venga rilevata e sfruttata nella tua applicazione:
Conserva importanti segreti al di fuori del database , oppure puoi memorizzare il segreto crittografato , con la sua chiave di decrittografia esterna del database.
Uno degli exploit di exploit più comuni è ottenere l'accesso ai dati tramite SQL Injection. Se il segreto, o la chiave che crittografa il segreto è memorizzato in un file al di fuori del database, hai eliminato quel vettore di attacco.
Utilizza le autorizzazioni file system più severe possibili sul file. È preferibile che l'unico account utente che può accedere a tale file sia l'applicazione in questione.
Altre applicazioni possono essere eseguite su account utente separati in modo che se tali applicazioni vengono compromesse, il tuo segreto sarà comunque sicuro.
La separazione fisica o VM è ancora migliore. Il punto è che non vuoi sfruttare le applicazioni non correlate per compromettere un segreto che viene utilizzato solo dall'applicazione in questione.
Un modo economico per ottenere la separazione fisica sarebbe con un computer di piccole dimensioni sulla rete come Raspberry Pi o HSM, con un singolo scopo dedicato . Dal momento che il tuo particolare segreto è esso stesso una chiave crittografica, potresti esternalizzare fisicamente l'operazione di crittografia. Quel dispositivo potrebbe avere solo un software molto semplice in esecuzione, quindi sai che non c'è modo di estrarre la chiave di crittografia senza rimuovere fisicamente il supporto di archiviazione.
In questa citazione, sostituisci "deficienze" per "vulnerabilità" ed è ancora vero:
"Ci sono due modi per costruire un software design: un modo è renderlo così semplice che non ci sono ovviamente carenze, e l'altro modo è renderlo così complicato che non ci sono evidenti carenze. Il primo metodo è molto più difficile. " - C.A.R. Hoare.
Non ho familiarità con le operazioni del tuo servizio, ma se è accessibile tramite nome utente e password , puoi utilizzare le password definite dall'utente per ricavare le chiavi per decodificare il segreto in base alle esigenze. Ho delineato come funzionerebbe qui: Come possiamo servire dati crittografati sensibili senza memorizzare la chiave? Devo utilizzare password definite dall'utente per le chiavi? Tuttavia, quella soluzione non funzionerà per un sistema autonomo , perché la password dell'utente e la chiave di sessione non sarebbero disponibili.
Dipende molto dal valore di ciò che queste chiavi proteggono.
Per sistemi molto preziosi, di solito investi in un HSM in rete .
Per un sistema con un valore inferiore, puoi utilizzare un sistema di gestione delle chiavi (ad esempio, Vault ).
Per sistemi con poco valore, puoi usare due copie (ciascuna protetta in modo appropriato) del segreto condiviso.
Leggi altre domande sui tag key-management