Perché memorizzare le password nel controllo di versione è una cattiva idea?

Il modo in cui lo vedo, non memorizzando le password in Git (o altro controllo di versione) è una convenzione . Suppongo che si possa decidere di non applicarlo con vari risultati, ma ecco perché questo è generalmente disapprovato:

1. Git rende doloroso rimuovere le password dalla cronologia del codice sorgente, cosa che potrebbe dare alle persone la falsa idea che la password fosse già stata rimossa nella versione corrente.
2. Inserendo la password nel controllo del codice sorgente, in pratica decidi di condividere la password con chiunque abbia accesso al repository, inclusi gli utenti futuri. Ciò complica la creazione di ruoli all'interno di un team di sviluppatori, che potrebbe avere privilegi diversi.
3. Il software di controllo del codice sorgente tende a diventare piuttosto complicato, in particolare i sistemi "all-in-one". Ciò significa che esiste il rischio che questo sistema possa essere compromesso, causando una perdita di password.
4. Altri sviluppatori potrebbero non essere a conoscenza del fatto che la password è archiviata e potrebbe manipolare il repository in modo errato - avere le chiavi nell'origine significa che occorre prestare maggiore attenzione quando si condivide il codice (anche all'interno dell'azienda, ciò potrebbe creare la necessità di crittografare canali).

I non posso dire che ogni modello relativo a infosec è buono , ma prima di romperli è sempre una buona idea considerare il modello della minaccia e i vettori di attacco. Se questa particolare password fosse trapelata, quanto sarebbe difficile per un utente malintenzionato usarla per danneggiare la compagnia?

Innanzitutto, il motivo non di sicurezza:

Flusso di lavoro per la modifica della password

Le password cambiano indipendentemente dal codice di un'applicazione software. Se un DBA modifica una password del database, ha senso che gli sviluppatori debbano aggiornare il codice, ottenere una nuova build e rilasciare in produzione e provare a cronometrare tutto? Le password sono un artefatto di configurazione runtime, non un artefatto di sviluppo. Devono essere iniettati tramite file di configurazione, variabili di ambiente o qualsiasi paradigma di configurazione che si sta utilizzando.

Ambito di autorizzazione

Generalmente, i sistemi di controllo delle versioni forniscono il controllo dell'autorizzazione in modo che solo gli utenti autorizzati possano accedervi. Ma all'interno di un repository, i permessi sono generalmente di tipo lettura / scrittura, o di sola lettura, o possibilmente alcuni campanelli e fischietti come fornisce GitHub. È improbabile che trovi limiti di sicurezza che consentano agli sviluppatori di ottenere codice sorgente, ma password non . Se riesci a clonare un repository, puoi clonare un repository. Periodo. In molti ambienti, gli sviluppatori non hanno pieno accesso alla produzione. A volte hanno accesso in sola lettura ai database di produzione, a volte nessun accesso. Che cosa succede se gli sviluppatori hanno generalmente accesso, ma non vuoi che tutti i tirocinanti, i nuovi assunti, ecc. Abbiano accesso?

Ambienti

Che cosa succede se disponi di più ambienti, ad esempio un ambiente di sviluppo, un ambiente di controllo qualità, la gestione temporanea e la produzione? Vuoi memorizzare tutte le loro password nel controllo della versione? In che modo l'app sa quale usare? L'app dovrebbe avere un modo per conoscere l'ambiente, che finirebbe per essere un'impostazione di configurazione. Se è possibile impostare il nome dell'ambiente come impostazione di configurazione, è possibile impostare la password del database come impostazione di configurazione (insieme alla stringa di connessione, nome utente, ecc.)

Storia

Come altri hanno già menzionato, il controllo della versione è progettato per preservare la cronologia. Quindi le password più vecchie saranno ancora recuperabili, il che potrebbe non essere la cosa migliore.

Compromesso

Quante volte abbiamo visto i titoli nelle notizie sul codice sorgente di alcuni prodotti che sono trapelati al mondo? Il codice sorgente è qualsiasi cosa si trovi nel controllo della versione. Questo è probabilmente il motivo principale per non inserire password nel controllo della versione!

Tuttavia ...

Detto questo, le password devono essere memorizzate da qualche parte . Ciò a cui alludono le preoccupazioni di cui sopra non significa necessariamente che non debbano essere memorizzati nel controllo di versione, piuttosto che non dovrebbero essere memorizzati nel repository del codice sorgente del prodotto nel controllo di versione. Avere un repository separato per la gestione della configurazione, le operazioni, ecc. È molto ragionevole. La chiave è dividere le operazioni dallo sviluppo quando si tratta di credenziali di sicurezza, non necessariamente per evitare del tutto il controllo della versione.

Inoltre, per gli ambienti non di produzione, ho memorizzato le password e le chiavi API per i sistemi esterni nei file di configurazione all'interno del codice sorgente del prodotto come predefinite. Perché? Per renderlo indolore quando uno sviluppatore estrae il codice, può semplicemente costruirlo ed eseguirlo senza dover andare a scaricare ulteriori file di configurazione. Queste sono credenziali che raramente cambiano e non portano a segreti commerciali. Ma non lo farei mai con i segreti di produzione.

Quindi la linea di fondo è ... dipende.

È sempre importante tenere presente che i suggerimenti devono essere personalizzati per adattarsi al caso d'uso. Le misure di sicurezza adottate, ad esempio, dall'NSA per proteggere tutti i giorni zero che si tengono in giro per una giornata piovosa dovrebbero essere molto più rigorose delle misure di sicurezza adottate per proteggere i voti su un sito di pubblicazione di foto di gatti. Ad un estremo, posso pensare ad un esempio quando mantenere password / token / etc in un repository git privato potrebbe essere ragionevole:

Se si accede a quel repository solo da una persona e l'applicazione non memorizza alcuna informazione di alcun valore.

In tal caso, vai in città! Basta tenere a mente cosa ha detto @ d33tah nella sua risposta: spazzare via le cose da un repository git può essere sorprendentemente difficile (il punto, dopo tutto, è mantenere una cronologia di tutto per sempre), quindi se in fondo alla strada decidi di voler collabora con più persone ma non vuoi che ottengano il pieno accesso a tutti i tuoi sistemi, quindi avrai un po 'di mal di testa tra le mani.

Questo è ciò a cui veramente si riferisce. Il tuo repository di codice è in qualche modo "pubblico", anche se condiviso solo con i collaboratori. Solo perché vuoi collaborare con qualcuno non significa che vuoi dare loro pieno accesso alla tua infrastruttura (che è effettivamente ciò che accade quando inserisci password / token nel tuo repository di codice). È facile pensare "sì, ma io fidarmi delle persone con cui collaboro!", Ma questo è semplicemente il modo sbagliato di guardare lo scenario, per una serie di ragioni:

1. Nella pratica attuale una grossa frazione di perdite di dati inizia con attori interni (collaboratori, dipendenti). Con uno studio circa il 43% delle violazioni dei dati è iniziato con un attore interno. La metà di quelli erano intenzionali e mezzi accidentali.
2. L'ultimo punto è importante e perché non si tratta solo di fiducia. Circa il 20% delle violazioni dei dati sono accidentali e causate da persone interne. Sono abbastanza intelligente da sapere che non sono abbastanza intelligente per sistemare tutto sempre. Cosa succede se pubblico il mio repository per far posto a qualche divertente strumento di integrazione e dimentico di avere credenziali al suo interno? Cosa succede se ho un disco rigido di backup che ho dimenticato di criptare e esce dal mio ufficio? Cosa succede se una delle mie password viene divulgata e qualcuno la usa per indovinare la password dell'account al mio repository git ( tosse repository gentoo github tosse )? Ci sono un numero qualsiasi di errori accidentali che I possono causare che il mio repository git venga esposto, e se ciò accade e ho credenziali e la persona che li trova sa quello che sta guardando, potrei benissimo essere disintegrato. Sembra un sacco di e ma la realtà è che questo è il modo in cui si verificano le violazioni.
3. Anche se mi fido di qualcuno, ciò non significa che devo dare loro pieno accesso a tutto [Inserire una citazione cheesy su come il potere corrompe]. Ancora una volta, inserire le credenziali in un repository git significa che potenzialmente sto dando pieno accesso a tutta la mia infrastruttura a tutti i miei collaboratori. C'è sempre la possibilità che tu non conosca quella persona così come pensi, e potrebbero decidere di fare qualcosa che non dovrebbero. Anche se conosci personalmente e ti fidi di ognuno dei tuoi collaboratori con la tua vita, ciò non significa che non faranno alcuni degli errori sopra elencati (o una delle infinite opzioni che non ho menzionato) per rilasciare accidentalmente il tuo codice.

In breve, una buona sicurezza consiste nell'avere delle difese stratificate. La maggior parte degli hack avviene perché gli hacker trovano punti deboli in un'area che consente loro di sfruttare le debolezze in un'altra area, che porta da qualche altra parte, che alla fine li porta al payoff big . Avere il maggior numero di protezioni di sicurezza in atto come ha senso per la tua situazione è ciò che mantiene il tutto sicuro. In questo modo quando un hard disk di backup esce dal tuo ufficio e ti accorgi che non è stato crittografato, non devi chiedere "È stato un attacco mirato e ora devo cambiare ogni singola credenziale che ho ovunque perché erano tutti nel repository git su quell'unità di backup? ". Di nuovo, a seconda della situazione, questo potrebbe non essere applicabile a te, ma si spera che questo aiuti a spiegare in quali scenari questo potrebbe avere importanza.

Tenere segreti (password, certificati, chiavi) separati dal codice sorgente rende possibile gestire fonti e segreti in base a diverse politiche. Ad esempio, tutti i tecnici possono leggere il codice sorgente, solo le persone direttamente responsabili dei server di produzione possono accedere ai segreti.

Ciò semplifica la vita degli sviluppatori perché non sono vincolati dalle rigide norme di sicurezza necessarie per proteggere i segreti. Le politiche di controllo del codice sorgente possono essere rese molto più convenienti per loro.

Questa convenzione, come molte altre "best practice" sulla sicurezza, è un modo pratico per assicurarsi che le cose non vadano male a causa di cattive abitudini o routine.

Se ricordi sempre che le tue password sensibili sono nel tuo sistema di controllo della versione e se non dai mai a nessuno che non dovrebbe avere la password di accesso al repository e se il tuo repository è archiviato in modo sicuro come richiedono questi e se il tuo processo di implementazione è allo stesso modo sicuro, protetto e protetto da persone non autorizzate e se puoi essere sicuro che tutti i backup e le copie del tuo repository sono e ... puoi probabilmente aggiungere un altro paio "se" è specifico per il tuo contesto.

... quindi puoi memorizzare le tue password nel tuo sistema di controllo delle versioni.

Nella maggior parte dei casi, almeno uno di quei "se" non è sufficientemente conforme alle tue condizioni, o è al di fuori del tuo controllo.

Ad esempio, in molte impostazioni i tuoi sviluppatori non dovrebbero avere accesso al database di produzione. Oppure il sistema di backup è esternalizzato ad un altro dipartimento. Oppure il tuo processo di build è esternalizzato al cloud.

Ecco perché in generale , non memorizzare le tue password nel tuo sistema di controllo delle versioni è una buona pratica che ti assicura di non cadere in una di quelle trappole perché non le hai pensate . "nessuna password in git" è più facile da ricordare rispetto a un lungo elenco di condizioni che è necessario soddisfare per archiviare le password in modo sicuro sotto il controllo della versione.

Altre risposte sono ottime, ma considera anche il problema dei backup. Hai molta più flessibilità su dove, come e per quanto tempo conservi i backup del tuo repository di codice se non contengono informazioni sensibili su come accedere al tuo server o account di amministrazione.

Da un altro angolo più incentrato sulla sicurezza, solo il tuo backup del codice potrebbe essere un obiettivo interessante per concorrenti immorali nella tua azienda. A seconda del tuo business, la maggior parte dei concorrenti in un paese "stato di diritto" non la toccherebbe comunque. Un codice di backup con password sarà un obiettivo per qualsiasi organizzazione criminale interessata ai dati dei tuoi utenti o interessata a ricattare la tua azienda.

Il danno da una violazione del repository di codice sarebbe maggiore con le password per ragioni simili. Preferiresti che il tuo codice sorgente venga rubato e pubblicato, o che tutti i tuoi utenti siano esposti al furto di identità, con una potenziale causa o persino un procedimento penale contro di te per non aver protetto i loro dati privati (pensa GDPR)?

"perché in realtà è così brutto mettere le tue chiavi direttamente nella tua porta principale, quando viviamo lontano dalla civiltà?"

Perché le persone che vogliono fare cose cattive, lo fanno con facilità e il costo per farlo duramente non è troppo alto. Tieni le chiavi con te non vicino alla porta. Buon senso.

Repository privato? Quante persone hanno accesso per scaricarlo? E quante persone sono connesse ai suoi computer? E poi ... Sono tutti liberati dal pericolo?

Dipende anche dal sistema di controllo del codice sorgente.

Git ha l'atteggiamento secondo cui il sistema di controllo del codice sorgente dovrebbe darti una storia affidabile del progetto. Quale non è un cattivo atteggiamento da avere. Ma c'è l'effetto che se hai controllato una password in git, è molto difficile rimuoverla dal tuo repository.

Perforce ha un comando "obliterare" per quello scopo. Se hai registrato una password, o qualcuno controlla un file video non compresso da 8 gigabyte, o qualcuno ha registrato qualche codice di terze parti che viola il copyright di qualcuno e non dovrebbe mai essere stato registrato, o qualcuno che è stato licenziato ha controllato un sacco di porno su il loro ultimo giorno di lavoro, puoi "cancellarlo". È completamente sparito dal repository e dalla storia.