Cosa si può fare per proteggere le password che potrebbero essere archiviate in testo normale o hash in un repository git?

Bene, tutte le risposte sensate possono essere riassunte in una semplice regola:

• Non farlo!

Non esiste un modo sicuro per trasferire password o altri valori sensibili in un repository Git che verrà clonato da un cast di sviluppatori in rotazione. E non esiste un modo automatico e infallibile per cogliere tali commit errati. Quindi tutti i consigli devono essere costruiti attorno a questi concetti:

1. Impedire agli sviluppatori di farlo;
2. Rilevandoli rapidamente quando lo fanno;
3. Rimedio a eventuali errori che superano le tue misure.

Quindi il consiglio che posso dare è:

Hai bisogno di sviluppatori che ti fregano

Se ai tuoi sviluppatori non ti frega niente di correttezza e sicurezza, allora abbandona ogni speranza. Puoi portare un cavallo all'acqua ma non puoi farlo bere.

Esame accurato e approfondito del codice

Anche se hai degli sviluppatori che se ne fregano, probabilmente continueranno a scivolare di tanto in tanto. Ciò significa che i tuoi sviluppatori devono rivedere il codice dell'altro, individuare gli errori e richiederne la correzione.

Automazione degli sviluppatori di prim'ordine

Perché i tuoi sviluppatori hanno bisogno di password sensibili in primo luogo? Nella mia esperienza, questo è un sintomo che manca all'automazione degli sviluppatori. Ad esempio, uno scenario comune è che l'applicazione interagisce con un RDBMS e quindi, un database condiviso viene creato da qualche parte e gli sviluppatori hanno bisogno di credenziali per accedere a tale.

Quindi aggiustalo. Utilizza uno strumento come Docker o Vagrant così che gli script di compilazione forniscano agli sviluppatori le istanze locali di tutte le risorse esterne di cui l'applicazione necessita, con la minima necessità di configurare stringhe di connessione o nomi utente o password o altro.

Strumenti per l'analisi del codice

Esistono strumenti di analisi che sono in grado di assistere a tale processo di revisione ispezionando il codice e indovinando i punti in cui potrebbero esserci problemi. Questi strumenti non possono mai essere completamente affidabili; produrranno alcuni falsi positivi e mancheranno alcuni problemi reali. Alcuni degli strumenti sono anche solo cattivi, quindi valuta attentamente qualsiasi cosa prima di impegnarti. Ho valutato SonarQube su programmi Java ed ero generalmente impressionato da esso; contiene alcune regole per cercare possibili punti deboli di sicurezza . (Non ho affiliazioni con la compagnia.)

Strumenti di gestione segreti

Invece di scrivere i tuoi programmi in modo che leggano i segreti delle variabili d'ambiente o dei file di configurazione (o anche dei segreti hardcoded!), scrivili in modo che li ottengano da un sistema di gestione segreto come Vault o Keywhiz . Ciò tuttavia richiede ai tuoi sviluppatori di lavorare un po 'più difficile per apprendere lo strumento e integrarlo con esso, il che a sua volta richiede loro di fregarsene.

Standardizza la gestione segreta

Se non adotti uno strumento come Vault o Keywhiz, dovresti comunque uniformare il meccanismo in base al quale le tue applicazioni accedono a password e altri segreti. Ad esempio, richiedi a tutte le tue applicazioni di leggere le loro password da un file chiamato appname-credentials.json . Quindi puoi:

1. Chiedi ai revisori del codice di rifiutare qualsiasi codice che non segua la pratica;
2. Aggiungi una regola a .gitignore per rifiutare i nomi di file che soddisfano tale modello.

Struttura del codice base per fornire una posizione "sicura" per i file sensibili

("Sicuro" nelle virgolette spaventose perché mentre questo è incrementalmente più sicuro di un sacco di codebase che vedo, non è poi così sicuro ...)

Un problema che continuo a vedere in molte applicazioni Java è che ottengono tutta la loro configurazione dai file di configurazione che vengono raggruppati con l'archivio JAR o WAR dell'applicazione. Lo fanno perché:

1. I popolari strumenti di sviluppo Java come Maven o Gradle forniscono un meccanismo convenzionale predefinito per raggruppare tali file di configurazione;
2. I framework Java popolari fanno ampio uso di tali file e rendono molto facile accedervi;
3. Gli sviluppatori, il più delle volte, non gliene frega niente della sicurezza o della correttezza.

Un trucco che è stato utilizzato in molti progetti di cui ho fatto parte è configurare lo strumento di compilazione in modo che, oltre alle posizioni predefinite, aggreghi anche i file di configurazione da un'altra posizione standard del progetto che ha un file .gitignore che impedisce l'accesso a qualsiasi cosa lì dentro.

Questo ha ancora un punto debole: le password non vengono archiviate, ma vengono raggruppate nei file di archivio dell'applicazione creati dagli sviluppatori. Se poi li distribuiscono a persone esterne, hanno rivelato le password.

Una cosa che potresti fare è memorizzare le password all'interno di un file di configurazione (ad esempio Laravel lo memorizza all'interno di .ENV) e quindi evitare di commetterlo al repository, aggiungendolo a .gitignore.

Gli utenti dovranno crearne uno manualmente dopo aver scaricato il repository.

Molti strumenti di analisi statica del codice supporteranno la ricerca di password codificate e segnalandole: questo potrebbe accadere nelle prime fasi del processo di integrazione continua, il che renderebbe almeno meno probabile la fusione del codice con password hardcoded.

link

In definitiva, tuttavia, questa è un'opportunità di formazione per gli sviluppatori: se uno sviluppatore vuole introdurre di nascosto le password hardcoded, è possibile che, nonostante i blocchi automatici, sia possibile. Processo, politica e procedura hanno il loro posto - e penso che sia qui la vera risposta.