Archiviazione sicura delle chiavi

Question

Archiviazione sicura delle chiavi

#1 da (1 voti)

2

Abbiamo una soluzione di sicurezza che viene implementata on premise alle aziende con grandi infrastrutture tecniche. Effettuiamo la valutazione della vulnerabilità / configurazione in tempo reale di tutte le risorse critiche nella rete.

Il server delle applicazioni (denominato "il nostro server") dispone di servizi che di solito si connettono ad altre risorse (come server Linux, dispositivi di rete, ecc.) tramite un PAM (Privileged Access Management) di proprietà del cliente. Una volta effettuata la connessione, i dati rilevanti vengono estratti sul nostro server per essere ulteriormente elaborati e quindi inseriti nel database.

Abbiamo qualche altro gruppo di clienti che non hanno un PAM e archiviamo la chiave privata nel nostro database usando AES-256. Le rispettive chiavi AES sono memorizzate sullo stesso server. Non possiamo usare qualcosa come PBKDF2 o bcrypt per archiviare queste password perché devono essere utilizzate per creare connessioni periodiche a tutte le risorse.

Il nostro server è indurito e continuamente monitorato dal nostro team VAPT, quindi le probabilità che venga compromessa sono molto meno. Nel peggiore dei casi, il server viene compromesso e diventa una porta all'intera infrastruttura di rete. Qual è l'apprensione principale di alcuni dei nostri potenziali clienti. In questo momento la risposta e il piano è di revocare l'accesso alla chiave e rimuovere le chiavi pubbliche corrispondenti da tutte le risorse.

C'è un modo in cui possiamo archiviare le chiavi, riutilizzarle e allo stesso tempo proteggerle da chiunque (autorizzato / non autorizzato) che ha accesso al nostro server? Stiamo valutando alcuni HSM anche se preferiremmo una soluzione che non includesse hardware extra.

PS: non vogliamo un intervento manuale ogni volta che la nostra applicazione ha bisogno di connettersi ai server remoti. (Inversa) Anche tutti i server / risorse che si connettono a questo nodo centrale non sono preferibili.

TL DR: In che modo FileZilla può memorizzare le credenziali in sicurezza?

password-management key-management key-exchange key-generation

posta Nakul 18.05.2018 - 19:31

fonte

1 risposta

Leggi altre domande sui tag password-management key-management key-exchange key-generation

Come impedire l'aggiornamento di un token di accesso rubato È sicuro esporre questi particolari servizi derivati di Firebase?

score 1 · Answer 1

Il tuo server deve essere in grado di accedere alla chiave. Pertanto, qualsiasi utente malintenzionato in grado di eseguire codice sul proprio server può accedere alla chiave allo stesso modo. Qualsiasi ulteriore sicurezza può limitare l'impatto sulla violazione entro questo limite.

C'è un piccolo vantaggio nel mettere la chiave in un processore separato e lasciare che il server faccia richieste solo a questo processore separato (derivazione delle chiavi, firma, decrittografia a seconda di quale sia la chiave) e non vedere i bit effettivi di il tasto. Supponendo che il processore separato non sia violato, ciò significa che un utente malintenzionato che viola il server deve continuare a utilizzare il processore separato se desidera continuare a utilizzare la chiave.

Questo non impedisce all'aggressore di causare danni, ma significa che devono avere una presenza più attiva e sostenuta. Non possono semplicemente ottenere la chiave, scaricarla e cancellare le loro tracce. Ciò aumenta le possibilità che tu possa rilevare la violazione. Inoltre, in caso di violazione, è probabile che fornisca una valutazione più precisa, perché è più probabile che ci siano registri affidabili che indicano cosa hanno fatto gli aggressori (e non hanno fatto).

Un altro vantaggio è che se si reinstalla il server dopo una violazione (sempre supponendo che il processore separato non sia stato violato), l'utente malintenzionato non ha più accesso alla vecchia chiave, quindi non è necessario ruotarlo. Non penso che questo sia importante nel tuo scenario; è per lo più importante per le chiavi private quando la chiave pubblica corrispondente è stata ampiamente implementata (ad esempio, per un'autorità di certificazione, questo può fare la differenza tra dover revocare un elenco noto di certificati e sostanzialmente cessare l'attività perché nessuno si fida più di te) .

Il processore separato può essere un modulo di sicurezza hardware adeguato, ma ci sono opzioni più economiche. Un HSM è protetto contro l'intrusione fisica, e questa è una parte significativa del suo costo. Il semplice inserimento della chiave in un server dedicato separato ti offre altrettanti vantaggi rispetto agli attacchi di rete. Può anche essere una macchina virtuale, ma la superficie di attacco è più grande a causa del rischio di canali laterali cross-VM e di attacchi contro l'hypervisor. Un'altra soluzione a basso costo è una smartcard, ma la larghezza di banda è molto limitata.

Si noti che c'è un costo per impostarlo: è utile solo se il processore separato non rivela mai la chiave. Il processore può firmare dati, decrittografare token o derivare chiavi di sessione, ma non consente mai alla chiave a lungo termine di lasciarlo. Non tutti i software supportano questo, ma tali funzionalità possono essere fornite in modo generico da una libreria crittografica, ad esempio tramite motori esterni in OpenSSL.

Se inserisci la chiave in un processore separato, non dimenticare la ridondanza: non sarai in grado di recuperare quella chiave solo ripristinando un backup.