Best practice per le informazioni sensibili nel controllo del codice sorgente

Question

Best practice per le informazioni sensibili nel controllo del codice sorgente

#1 da (5 voti)
#2 da (2 voti)

8

So che questo argomento è stato trattato molto ma non riesco a trovare una risposta alla mia situazione specifica.

Attualmente sto utilizzando .gitignore per escludere il contenuto sensibile e mantenerlo (file di configurazione, ecc.) separatamente. Dato che il mio codebase si espande in un numero sempre maggiore di progetti, questo sta diventando piuttosto difficile da gestire e non ho nemmeno un modo reale per tenere traccia delle modifiche o eseguire correttamente il backup dei file.

Ci sono alcuni strumenti per questo problema, come git-secret , Hashicorp Vault e git-crypt , ma nessuno di questi funziona con Windows, dove faccio tutto il mio sviluppo (per vari motivi).

Attualmente, sono l'unico sviluppatore che lavora all'interno della mia azienda senza piani di espansione. Il controllo del codice sorgente (Gitlab) viene principalmente utilizzato per il mio riferimento e la possibilità di registrare le modifiche. Spingere qualche stringa di connessione o file di configurazione nel controllo del codice sorgente sarebbe un grosso problema o rischio? Quella informazione è attualmente posizionata su un'unità di rete, non protetta (eccetto per le autorizzazioni NTFS)

Ho l'idea che la migliore pratica non è quella di spingere questa roba al controllo del codice sorgente ma ho un'istanza Gitlab ospitata privatamente che non è accessibile al di fuori della rete locale - questo significa che c'è meno rischio?

git security

posta Syntax Error 05.07.2018 - 13:05

fonte

2 risposte

2

Il luogo migliore in cui archiviare le informazioni sensibili è un negozio appositamente creato come Hashicorp Vault che supporta Windows.

Se (per qualsiasi motivo) non sei in grado di usarlo, puoi anche utilizzare git-secret che supporta anche Windows. Il supporto per Windows è stato aggiunto a git-secret in questo PR: link

git-crypt ha anche il supporto sperimentale per Windows:

link

risposta data 05.07.2018 - 13:33

fonte

Leggi altre domande sui tag git security

Il JIT corrente ottimizza i codici macchina generati per la previsione delle filiali in base alle statistiche di runtime? Il miglior metodo di comunicazione tra la tua app e il tuo sito web? PHP, servizio Web, ecc

score 5 · Accepted Answer

Pensando a questo in modo olistico, ci sono diverse cose da considerare:

Il server GitLab è ospitato nella stessa rete dell'ambiente di destinazione?
Hai nomi utente e password nei tuoi file di configurazione?
È possibile separare la configurazione di sicurezza dalla normale configurazione dell'applicazione?

La prima preoccupazione riguarda la politica. Se il software verrà distribuito su una rete separata, è possibile che si verifichino problemi di policy anche se le proprie configurazioni sono crittografate.

Come evitare le informazioni sensibili

Sii specifico su ciò che è sensibile. Ad esempio, il nome di dominio di un server potrebbe non essere sensibile, ma potrebbe essere l'indirizzo IP (o l'associazione dei due). In genere nomi utente e password sono sensibili, così come clientId e chiavi segrete (OAuth2).

Le tue migliori opzioni sono:

Utilizza stringhe di connessione che non richiedono nome utente / password (vedi sotto)
Separa le informazioni sensibili dal Web.config principale
Utilizza attributo file data-to-aspnet-and-azure in AppSettings per leggere un file di configurazione esterno

Alcuni database ti permettono di avere una stringa di connessione in cui nome utente e password non fanno parte del contenuto. Ad esempio, è possibile eseguire l'app con un account di servizio di dominio per connettersi a SQL Server utilizzando la sicurezza integrata. Oppure puoi usare il Portafoglio di Oracle per mantenere il nome utente / password segreti sul computer di destinazione. Alcuni servizi OAuth2 consentono di utilizzare un file .csv o .json memorizzato sulla macchina in una posizione standard.

In altre parole, fai tutto il possibile per evitare di mantenere le informazioni sensibili a cui non appartiene. Se devi apportare modifiche alla tua app per cercare in una posizione sul disco per leggere i bit sensibili, puoi configurarla una volta su ciascun server di destinazione e leggerla dalla tua app.

Configuration Servers

Steeltoe ha portato alcune librerie di integrazione di Spring a C # e hanno persino il supporto per i server Spring Cloud Config . Il server Spring Cloud Config richiede un repository Git sulla rete di distribuzione , ma consente di personalizzare la configurazione dove deve essere. Se la tua applicazione è abbastanza complessa (vale a dire micro-servizi), allora questo sarebbe qualcosa che vale la pena esaminare per mantenere i nomi dei server protetti nello stesso ambiente in cui si trovano i server.

Linea inferiore

Vuoi solo evitare il più possibile le informazioni sensibili, ma mantenere le configurazioni non sensibili nel controllo del codice sorgente. Se non puoi evitare il nome utente / password nel tuo file di configurazione (ad esempio un database diverso che non ha un equivalente di sicurezza integrata), carica solo quel piccolo bit da un file esterno.