Non è saggio usare Redis per memorizzare PII, chiavi private e altri segreti?

Question

Non è saggio usare Redis per memorizzare PII, chiavi private e altri segreti?

#1 da (5 voti)

8

Sto rivedendo un sistema che sta usando Redis per archiviare tutti i segreti del client, le chiavi private e altre cose. Il problema è che Redis carica l'intero DB nella RAM

Poiché SSL heartbleed , Rowhammer e altri hack sono noti per esporre la memoria a utenti non fidati, penso che qualsiasi altro hack simile potrebbe esporre il intero database, in cui se avessi usato il server SQL, meno chiavi private sarebbero nella RAM in un dato momento.

C'è probabilmente un modo migliore per farlo.

Poiché sono richiesti per ospitare e archiviare i segreti e il PI del cliente, voglio che utilizzino un approccio load on demand e non caricino in modo troppo aggressivo i dati non necessari nella RAM e scarichino quanto prima nella RAM.

Se mi iscrivo alla filosofia che ....

My data is safer from attack when there are fewer copies of it laying around

... qual è l'approccio migliore per ridurre l'esposizione nella RAM? SecureErasing di memoria?

Sto guardando SecureString con ASP.NET e DiskIO , ma mi viene difficile trovare un implementazione end-to-end che non lascia copie non necessarie della stringa nei driver, nelle code di prefetch o in altre posizioni.

asp.net memory privacy tls threat-mitigation

posta random65537 22.03.2015 - 13:43

fonte

1 risposta

Leggi altre domande sui tag asp.net memory privacy tls threat-mitigation

Impostazione del SOC aziendale Quali sono i potenziali problemi di sicurezza che eseguono codice non affidabile in un contenitore Docker come utente non root?

score 5 · Answer 1

Il rischio / problema è esattamente lo stesso e anche la mitigazione. Indipendentemente se carica il database parzialmente o completamente nella memoria. Non ti sarà possibile stabilire quali chiavi sono state compromesse e quali no. Quindi l'unica opzione sarebbe quella di revocarli tutti, indipendentemente dal fatto che si tratti di un database Redis o SQL.

La maggior parte delle volte il motivo per cui le persone utilizzano Redis vs SQL è dovuto a problemi di prestazioni. Penso che la probabilità di un simile attacco di successo sia considerevolmente bassa se si dispone di un design decente e si evita l'esposizione diretta del server del database. Se hanno già implementato questo, l'investimento per risolverlo da una parte sarà grande considerando che metà della base di codice richiederà aggiornamenti. Penso che dovresti esaminare l'isolamento del cluster Redis, monitorare tutte le operazioni (log SIEM), vedere se puoi implementare controlli extra (comportamento anomalia) e verificare il loro piano di risposta agli incidenti in caso di violazione, piuttosto che abbattere la loro soluzione.