Segreti come chiavi di crittografia e credenziali non dovrebbero essere controllati nel controllo del codice sorgente per alcuni motivi. Il primo è ovviamente che le chiavi di crittografia e le credenziali dovrebbero essere sempre sulla base della necessità di conoscere, e il controllo del codice sorgente non è un modo affidabile per proteggere le informazioni dalla divulgazione. L'altro motivo per cui non vorrai tali segreti nel controllo del codice sorgente è in genere perché i segreti sono in genere (ma non sempre) specifici per un determinato attributo dell'ambiente in cui verrà eseguita l'applicazione. (Ad esempio, acquisizione di una chiave privata per creare un digitale firma necessaria per un'autorizzazione del servizio Web, l'endpoint specifico di quel servizio Web potrebbe essere in esecuzione in un ambiente QA che richiede una firma QA).
Il modo corretto di trattare un segreto ambientale (o globale) è trattarlo come faresti con 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 sono distribuiti informi l'applicazione sui suoi attributi (ad es. Dettagli di connessione al database, credenziali, endpoint del servizio Web, percorsi dei file, ecc ...) Ora i dettagli di configurazione cruciali per la tua applicazione sono esternalizzati e diventano parametri di configurazione del tuo ambiente.
Ora per affrontare alcuni dei tuoi argomenti:
In generale, non stiamo semplicemente spostando il problema?
Non esiste una sicurezza perfetta, tuttavia "spostare" il problema in un'area in cui possono essere posti ulteriori provvedimenti e controlli migliorerà la difficoltà e ridurrà la probabilità di divulgazione accidentale o malevola di segreti. Una buona regola da seguire quando si progetta un sistema in cui i dati riservati devono essere protetti è quella di mettere sempre i controlli in due. Ciò che intendo con ciò è garantire che, affinché si verifichi una divulgazione accidentale o dannosa di informazioni riservate o un incidente di sicurezza, ci dovrebbe essere un errore o due o più controlli.
Un buon esempio di ciò 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.
- Memorizza la chiave e il file crittografato nello stesso server (0 controlli, chiunque abbia accesso al server può acquisire banalmente le informazioni riservate)
- Eseguire i passaggi precedenti e proteggere l'accesso ai file su entrambi i file in modo che possano essere letti solo dall'utente runtime dell'applicazione del sistema operativo (1 Controllo, compromettendo la password dell'utente root o l'utente runtime dell'applicazione consentirà a un utente malintenzionato di acquisire informazioni riservate)
- Archivia la chiave nel vault della chiave esterna, acquisisci la chiave con più misure di sicurezza come la lista bianca dell'indirizzo IP, l'autenticazione del certificato e altre misure all'applicazione che può accedere al file crittografato sul suo filesystem. (Controlli multipli, errori multipli dei controlli di sicurezza devono verificarsi per compromettere i dati riservati)
Ancora una volta, non esiste una sicurezza perfetta, ma l'obiettivo di disporre di più controlli garantisce che si verifichino più errori perché avvenga la divulgazione.
Mi sembra che prodotti come Azure KeyVault non siano migliori e inutilmente più complicati,
Sì complicato, inutile è completamente soggettivo. Non possiamo discutere sull'inutilità di una sicurezza aggiuntiva senza tener conto realisticamente di quanto serio sarebbe per i dati riservati essere esposti. Se uno potesse utilizzare i dati riservati per inviare bonifici illeciti fuori dal proprio istituto finanziario, qualcosa come un deposito chiave riguarda la cosa più lontana dall'inutilità che ci sarebbe.
che mantenere i tuoi segreti in un file di configurazione separato e assicurarti che sia nel tuo .gitignore o equivalente.
Fino a quando qualcuno non lo controlla accidentalmente nel controllo del codice sorgente, ora il segreto è incorporato per sempre nella cronologia del controllo del codice sorgente.
Certo, le persone probabilmente lo invieranno per email in modo insicuro ...
La sicurezza non è solo un problema tecnico, è anche un problema di persone. Sarebbe fuori tema, tuttavia a questo punto sento che stai cercando di convincerti a non fare il necessario.
C'è un modo per gestire i segreti che non si limita a spostare il problema? Credo che questa domanda abbia un'unica risposta chiaramente definita. Per analogia, se dovessi chiedere come HTTPS non si limiti a spostare 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.
La sicurezza non sempre risolve i problemi, per lo più mette i controlli intorno a loro. La tua analogia è sintetica perché è esattamente ciò che fa la crittografia a chiave pubblica-privata. Stiamo "spostando il problema" nella CA ponendo fiducia assoluta e totale nella nostra CA per garantire l'identità dell'entità proprietaria del certificato pubblico. Fondamentalmente, a dir poco una catastrofica serie di guasti (ad esempio perdere la fiducia nella CA) dovrebbe verificarsi per causare un problema di sicurezza.
Come per molte cose, la sicurezza è una linea che devi tracciare in base a criteri soggettivi, la natura dei dati, le conseguenze della divulgazione, la propensione al rischio, il budget, ecc ...