Questa è una pessima idea se non ci sono avvertimenti chiari sulla pagina di esempio. Incoraggia gli sviluppatori a mettere i loro segreti nei loro file di configurazione sui loro computer degli sviluppatori. Questi file finiscono nel controllo di versione, che è molto, molto sbagliato.
L'unica posizione in cui i file di configurazione potrebbero avere segreti (vedi sotto su cosa intendo per segreti) si trova su server di produzione rigorosamente controllati a cui possono accedere solo amministratori di sistema fidati. Sul computer dello sviluppatore, lo stesso file può essere presentato come modello:
<configuration>
<adminurl>{{ADMIN_URL}}</adminurl>
<user>{{ADMIN_USER}}</user>
<password>{{ADMIN_PASSWORD}}</password>
<upload>true</upload>
<action>deploy</action>
...
</configuration>
dove i segnaposto saranno sostituiti dai valori effettivi durante la distribuzione (e possono essere sostituiti da valori diversi durante il debugging locale).
I segreti stessi possono essere memorizzati:
- In un controllo versione separato,
- Che è crittografato,
- a cui è possibile accedere solo dal processo che spinge le nuove revisioni alla produzione, nonché dagli stessi amministratori di sistema che hanno comunque un accesso completo ai server.
Quando si distribuiscono le revisioni alla produzione, un'opzione migliore rispetto all'utilizzo di un modello è quella di mettere segreti in un file completamente separato . Questo file può essere crittografato (con solo il processo¹ in cui l'app può decrittografarlo), il che significa che gli sviluppatori possono accedere alla configurazione effettiva (e vedere il valore degli% effettivi adminurl e user ) a scopo di debugging, senza poter accedere al segreto stesso.
I segreti possono anche essere archiviati in un database. I vantaggi, rispetto a un semplice file, sono:
- La capacità di controllo, ovvero la capacità di tenere traccia di chi ha avuto accesso a quali segreti quando.
- Il fatto che tutti i segreti siano memorizzati nella stessa posizione centrale, il che rende semplice la gestione della sicurezza, la revoca delle autorizzazioni, il ripristino dei segreti compromessi, ecc.
Gli svantaggi sono:
- La complessità aggiuntiva, che potrebbe essere troppo travolgente per una piccola applicazione (dato che è necessario distribuire una macchina virtuale separata per il database, assicurarsi che sia protetta, assicurarsi che i registri e il controllo da questa macchina vengano inviati al server dei registri centrale che è protetto, ecc.)
- Il fatto che tutti i segreti siano memorizzati nella stessa posizione centrale, che lo rende un bersaglio perfetto per un aggressore (incluso un dipendente scontento).
Nota che:
-
Quando parlo di segreti, intendo cose come le chiavi segrete per le API. Le password degli utenti effettivi non dovrebbero mai essere archiviate : l'unica cosa che può essere memorizzata è un hash salato, mai la semplice password (né la versione crittografata di esso). Il termine "password" utilizzato nell'esempio è molto fuorviante.
-
weblogic è un terribile nome utente. Jeff Brown è un utente. Cindy Coleman è un utente. admin o web o accounting non sono utenti, perché non corrispondono a una singola persona. Tali nomi incoraggiano la condivisione delle credenziali tra più persone (dando root password a tutti gli sviluppatori, inclusi freelance e stagisti, o accounting password a 5 contabili della società, inclusa quella che verrà licenziata la prossima settimana), che è una pessima idea.
-
Password weblogic123 per l'utente weblogic sucks. Anche come esempio. La password {b>P1.TrFM2WU@I5dc| è un esempio molto migliore.
¹ In Windows, ciò è possibile specificando la proprietà di crittografia del file: la decrittografia viene eseguita in modo trasparente per l'applicazione, in modo che l'app non debba occuparsi delle chiavi di crittografia (e della memorizzazione del chiavi di crittografia). Lo stesso dovrebbe essere possibile anche in altri sistemi operativi.