Mantenendo i segreti fuori dal controllo del codice sorgente: stiamo semplicemente spostando il problema?

7

Ho ereditato alcuni progetti in cui i segreti erano nel controllo del codice sorgente in App.config e file simili. Fortunatamente non è un deposito pubblico, quindi il rischio non è così grave come avrebbe potuto essere. Sto cercando modi migliori per gestirlo, come Azure KeyVault. (Ma non intendo che questa domanda sia specifica per quella soluzione.)

In generale, non stiamo semplicemente spostando il problema? Ad esempio, con Azure KeyVault, l'ID app e il segreto dell'app diventano gli elementi necessari per evitare il controllo del codice sorgente. Ecco sfortunatamente tipico esempio di come questo tende a sbagliare. Altri approcci finiscono per essere simili, con chiavi API o file di archivio chiavi che devi proteggere.

Mi sembra che prodotti come Azure KeyVault non siano migliori e inutilmente più complicati dei segreti in un file di configurazione separato e assicurandosi che sia nel tuo .gitignore o equivalente. Questo file dovrebbe essere condiviso come necessario tramite un canale laterale. Ovviamente, probabilmente le persone probabilmente lo invieranno per e-mail l'un l'altro ...

C'è un modo per gestire i segreti che non si limitano a spostare il problema? Credo che questa domanda abbia un'unica risposta chiaramente definita. Per analogia, se dovessi chiedere come HTTPS non sposta solo il problema, la risposta sarebbe che le chiavi CA sono distribuite con il tuo sistema operativo e ci fidiamo di loro perché ci fidiamo del metodo di distribuzione del sistema operativo. (Se dovremmo è una domanda a parte ...)

    
posta TKK 06.12.2018 - 18:56
fonte

3 risposte

12

Potresti dire che stai solo spostando il problema. In definitiva, ci sarà un segreto archiviato da qualche parte a cui l'app ha accesso per avere password, chiavi SSH, qualsiasi cosa.

Ma, se fatto bene, stai spostando il problema da un luogo che è difficile da proteggere in modo appropriato a quello che puoi proteggere meglio. Ad esempio, mettere segreti in un repository pubblico su github equivale a lasciare le chiavi di casa attaccate alla porta principale. Chiunque li desideri non avrà problemi a trovarli. Ma se ci si sposta, ad esempio un keystore su una rete interna senza connettività esterna, si ha una migliore possibilità di mantenere le password sicure. È più come tenere le chiavi in tasca. Non è impossibile perderli (l'equivalente di distribuire la tua password di Azure, ad esempio), ma limita la tua esposizione e tocca le tue chiavi alla tua porta.

    
risposta data 06.12.2018 - 19:07
fonte
4

I segreti come le chiavi di crittografia e le credenziali non dovrebbero essere controllati nel controllo del codice sorgente per alcuni motivi. Il primo è ovviamente che le chiavi e le credenziali di crittografia devono sempre essere basate su una necessità di conoscere le basi e il controllo del codice sorgente non è un modo affidabile per proteggere le informazioni dalla divulgazione. L'altro motivo per cui non vorreste avere questi segreti nel controllo del codice sorgente è in genere perché i segreti sono solitamente (ma non sempre) specifici per un determinato attributo dell'ambiente in cui verrà eseguita la vostra applicazione. (Ad esempio Acquisizione di una chiave privata per creare un digitale firma necessaria per un'autorizzazione del servizio Web, l'endpoint specifico di tale servizio Web può essere eseguito in un ambiente di controllo qualità che richiede una firma QA).

Il modo corretto di trattare un ambientale (o segreto globale) è trattarlo come se fosse un qualsiasi altro attributo di configurazione ambientale, con controlli di sicurezza aggiuntivi per una buona misura. Un modulo di codice ben progettato, indipendente e versionabile dovrebbe essere identico in tutti gli ambienti, in modo tale che l'ambiente in cui vengono distribuiti informi l'applicazione sui suoi attributi (ad esempio dettagli di connessione al database, credenziali, endpoint del servizio Web, percorsi di file, ecc ...) i dettagli di configurazione cruciali per la tua applicazione sono esternalizzati e diventano parametri di configurazione del tuo ambiente.

Ora per indirizzare alcuni dei tuoi argomenti:

In general, aren't we just moving the problem?

Non esiste una sicurezza perfetta, tuttavia "spostare" il problema in un'area in cui possono essere posizionate misure e controlli aggiuntivi migliorerà la difficoltà e ridurrà la probabilità di divulgazione accidentale o dolosa di segreti. Una buona regola da seguire quando si progetta un sistema in cui i dati riservati devono essere protetti è di mettere sempre i controlli in due. Ciò che intendo è garantire che, in caso di divulgazione accidentale o dolosa di informazioni riservate o incidenti di sicurezza, si verifichi un errore o due o più controlli.

Un buon esempio di questo potrebbe essere la memorizzazione di un file crittografato su un server. Ho anche una chiave di decrittazione segreta che devo mantenere riservata in un altro file.

  • Archivia la chiave e il file crittografato nello stesso server (0 Controlli, chiunque abbia accesso al server può banalmente acquisire le informazioni riservate)
  • Eseguire i passaggi precedenti e proteggere l'accesso ai file su entrambi i file in modo che sia leggibile dall'utente runtime dell'applicazione del sistema operativo (1 Control, compromettendo la password dell'utente root o dell'utente runtime dell'applicazione consentirà a un utente malintenzionato di acquisire informazioni riservate informazioni)
  • Memorizza la chiave nella chiave esterna, acquisisci la chiave con più misure di sicurezza come la lista bianca dell'indirizzo IP, l'autenticazione del certificato e altre misure per l'applicazione che possono accedere al file crittografato sul suo file system. (Controlli multipli, si devono verificare più errori dei controlli di sicurezza per la compromissione dei dati riservati)

Ancora una volta, non esiste una sicurezza perfetta, ma l'obiettivo di avere più controlli assicura che si verifichino più guasti per la divulgazione.

It seems to me that products like Azure KeyVault are no better, and pointlessly more complicated,

Complicato sì, inutile è completamente soggettivo. Non possiamo avere una discussione sull'inutilità della sicurezza addizionale senza tener conto realisticamente di quanto seria sarebbe l'esposizione dei dati confidenziali. Se uno potrebbe utilizzare i dati riservati per inviare trasferimenti illegali di cavi fuori dal proprio istituto finanziario, qualcosa come un deposito di chiavi è la cosa più lontana da inutile che ci sarebbe.

than keeping your secrets in a separate config file and making sure it's in your .gitignore or equivalent.

Finché qualcuno non lo controlla accidentalmente nel controllo del codice sorgente, ora il segreto è incorporato nella cronologia del controllo sorgente per sempre.

Of course, people will probably insecurely email it to each other...

La sicurezza non è solo un problema tecnico, è anche un problema di persone. Sarebbe fuori tema, tuttavia, a questo punto, mi sento di provare a parlare di te stesso senza fare il necessario.

Is there a way to manage secrets that doesn't just move the problem? I believe this question has a single clearly defined answer. By analogy, if I were to ask how HTTPS doesn't just move the problem, the answer would be that CA keys are distributed with your OS, and we trust them because we trust the distribution method of the OS.

La sicurezza non sempre fa andare via i problemi, il più delle volte mette i controlli attorno a loro. La tua analogia è concisa perché in effetti è esattamente ciò che fa la crittografia a chiave pubblica-privata. Stiamo "spostando il problema" verso la CA, ponendo totale fiducia nella nostra CA per garantire l'identità dell'entità proprietaria del certificato pubblico. Fondamentalmente, a causa di una serie di fallimenti catastrofici (ad esempio perdere la fiducia nella CA), dovrebbe verificarsi un problema di sicurezza.

Come per molte cose, la sicurezza è una linea che devi tracciare in base a criteri soggettivi, alla natura dei dati, alle conseguenze della divulgazione, alla propensione al rischio, al budget, ecc ...

    
risposta data 06.12.2018 - 20:00
fonte
0

Vale la pena considerare git secret project ( link ) per mantenere i file segreti in reit git crittografati con chiave asimmetrica. Le chiavi pubbliche sono anche in repo, la chiave privata non è.

Le caratteristiche di questo approccio sono:

  • quando un nuovo utente / macchina deve decifrare i file protetti - pubblica / invia la sua chiave pubblica gpg (gnu privacy guard aka pgp). L'utente che può già decodificare i file protetti può ricodificarli con una nuova chiave aggiuntiva, dopo che il nuovo utente può decrittografare i file protetti con la sua chiave privata.
  • ovviamente è necessario controllare chi può eseguire il commit / push sul repository git. In caso contrario, l'utente malintenzionato può impegnare la propria chiave pubblica e attendere fino a quando qualcuno autorizzato decrittografa i file protetti con questa nuova chiave pubblica compromessa.
risposta data 07.12.2018 - 00:25
fonte

Leggi altre domande sui tag