Archiviazione sicura dei segreti delle applicazioni su Linux

Il tuo servizio non deve essere eseguito come root in generale . Utilizzare un utente separato per archiviare il segreto è una precauzione saggia, ma la memorizzazione di file con proprietà root non è migliore per la segretezza rispetto all'utilizzo di un altro utente dedicato per questo. Finché il tuo file segreto ha le autorizzazioni 600 o meno, sarà al sicuro da altri utenti non root . Qualunque cosa che esegue root ha comunque accesso completo. (a meno che tu non stia eseguendo alcune complicate impostazioni di SELinux)

Potrebbe essere utile per utilizzare due utenti per questa singola applicazione per isolare la gestione segreta dal normale funzionamento. O avere due demoni in esecuzione con comunicazioni in tempo reale o avere comandi di utilità per operare sul segreto, ottenendo il privilegio necessario (utente o gruppo) tramite sudo .

Dovresti considerare i potenziali vettori di attacco.

• SQLi se configurato correttamente non garantisce l'accesso al filesystem, ma gli attacchi Path Traversal potrebbero. Esistono altri tipi di attacchi alla tua applicazione ai quali dovresti essere protetto.

• Gli exploit nelle librerie C (ad esempio OpenSSL con la crittografia HTTPS, l'elaborazione delle immagini, ecc.) potrebbero essere possibili. L'utilizzo di un utente separato sui processi esposti in rete può aiutare a limitare l'ambito o aggiungere difficoltà a un attacco.

• Le interruzioni da altri vettori di attacco potrebbero essere un problema. (SSH, altri servizi sulla macchina) Assicurati che qualsiasi cosa con il potenziale di accesso root sia ben protetta.

Tutte queste considerazioni dovrebbero aiutarti a proteggere il segreto stesso. Ora la domanda è, il segreto deve davvero essere archiviato in modo semplice?

Al livello più elementare, sì, il segreto deve essere memorizzato da qualche parte perché sia utilizzabile. Almeno deve essere memorizzato in memoria, ma è necessaria anche una memorizzazione permanente di qualche tipo.

Oltre alla separazione degli utenti di cui abbiamo discusso, potrebbe essere utile scaricare i segreti su un modulo di sicurezza hardware separato o persino su un mini-computer separato. (es. Raspberry Pi) Esiste qualche discussione sulla separazione fisica qui .

Ci sono pochissimi casi in cui il segreto può essere crittografato nella memoria permanente.

Se la tua preoccupazione è il furto del disco rigido, (lasciando il resto della macchina dietro), potresti avere uno script di avvio che interroga qualcun altro dell'hardware per identificatori univoci , e deriva un chiave di crittografia utilizzando una buona funzione di derivazione chiave basata su password; per decifrare il segreto.

Se il cliente può fornire una parte del segreto, sarebbe utile. Ho delineato un modo per ricava chiavi di decrittografia da password utente e token di sessione qui . Questo è un sistema elaborato ma efficace che si concentra sulla limitazione della quantità di tempo in cui un segreto è memorizzato, anche in memoria. (supponendo che non sia necessario un reset automatico della password)

Quello che hai è il modo tradizionale di fare le cose. Ecco come Tomcat, ad esempio, consiglia di farlo, con OWASP concomitante . Quindi, quello che hai non è male.

Tuttavia, esistono altri modi per farlo: i moduli di sicurezza hardware sono storage ad accesso limitato progettato per l'archiviazione delle chiavi. Hashicorp's Vault, KeyWhiz e tecnologie simili sono sistemi di gestione segreti, in pratica il tentativo di essere software HSM. Naturalmente, tutte queste tecnologie devono essere in grado di autenticare il processo - il loro vantaggio è che hanno una varietà di meccanismi per questo. È possibile utilizzare root per accedere a una chiave che viene fornita in memoria solo all'utente Web: potrebbe utilizzare tale chiave per accedere a HSM / Vault / KeyWhiz per poter accedere e modificare la chiave effettiva. Ci sono anche altri meccanismi: quelli specifici di AWS che usano le chiavi EC2, un mucchio di altri. Potresti riuscire a trovare qualcosa che si adatta bene.

La mia opinione personale è che l'utente ristretto provato e vero (usato SOLO per questo scopo) e i file riservati solo a quell'utente non sono un cattivo modo di procedere. Non scala bene, tuttavia, dove potrebbero esserci altre opzioni.

Se il segreto è memorizzato sul server in un modo che è leggibile dall'applicazione senza l'intervento umano, allora è leggibile da almeno root sul computer.

Non importa che il file sia in puro testo; può essere protetto solo da autorizzazioni e root può ignorare tali autorizzazioni. La crittografia del file (o del filesystem in cui si trova) è di aiuto solo se la chiave di crittografia è resa disponibile al processo solo per leggere il file, e ciò richiede un intervento esterno (e la verifica); stai semplicemente spostando il problema dell'accesso al segreto da qualche altra parte.

Anche se si mantiene il controllo di tutti gli account sul sistema - lo si costruisce come un'appliance, ma rimane comunque il problema dell'accesso fisico al sistema. Se sei felice che l'integrità fisica possa essere assicurata, allora hai il problema di mantenere il sistema come un'appliance - come saranno installate le patch?

Sono tutt'altro che convinto che un hsm, anche nell'hardware, fornisce una soluzione completamente sicura, piuttosto che rendere l'accesso normale eccessivamente elaborato (pur complicando, ma non impedendo l'accesso non autorizzato).

Dato che qualsiasi soluzione sarebbe un compromesso sulle tue aspettative, dovresti essere più specifico sui vincoli (costi di sviluppo, costi unitari, volume previsto) insieme a maggiori dettagli sul modello di Thret.