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 ...