Protezione dei dati sensibili dagli sviluppatori

Ho un'applicazione enterprise in esecuzione che utilizza sia datastore MySQL che MongoDB . Tutti i miei team di sviluppo hanno accesso SSH alla macchina per eseguire rilasci di applicazioni, manutenzione, ecc.

Di recente ho sollevato un rischio nel business quando gli utenti hanno iniziato a archiviare dati altamente sensibili sull'applicazione che gli sviluppatori hanno accesso indiretto a questi dati che ha causato un po 'di tempesta, quindi ora sono stato incaricato di proteggere i dati in modo che non accessibile.

A me questo non sembra possibile perché se l'applicazione ha accesso al database quindi uno sviluppatore con accesso alla macchina e all'origine dell'applicazione sarà sempre in grado di accedere ai dati.

La sicurezza non è una bacchetta magica che puoi sventolare alla fine di un progetto, deve essere presa in considerazione e integrata dal primo giorno. Non è un imbroglio, è l'applicazione coerente di una gamma di soluzioni applicate ripetutamente e riviste regolarmente come parte di un intero sistema, che è forte solo come l'anello più debole.

Allo stato attuale hai segnalato un problema di sicurezza che è un buon primo passo. Ora come minimo devi definire: -

• Quali dati stai cercando di proteggere?
• Da chi stai cercando di proteggere quei dati?
• Chi ha effettivamente bisogno di accedere a cosa (e quando)?
• Qual è l'impatto legale / finanziario / commerciale di tali dati compromessi?
• Qual è il bisogno legale / finanziario / commerciale di una persona / gruppo che ha accesso ai dati?
• Qual è il budget che l'azienda è disposta ad assegnare a una strategia di "protezione, protezione" quando in precedenza non era un requisito aziendale?
• Di quale accesso ha bisogno il sistema ai dati?
• Su cosa si basano questo processo e i sistemi su cui questa applicazione si basa?
• Cosa viene fatto per proteggere quegli ambienti?
• Chi sarà responsabile dell'implementazione e della revisione dell'intero processo?

Fino a quando non conoscerai tutti quei dettagli nei quali non hai davvero nulla con cui lavorare. Tali informazioni definiranno quali mitigazioni di tali minacce è possibile (e non è possibile) applicare e perché.

Potrebbe essere che la cosa migliore da fare sia riconoscere che non hai l'esperienza necessaria e che sarebbe meglio portare qualcuno di nuovo con quell'esperienza. Sento abbastanza spesso la risposta che non esiste un budget: se viene considerato veramente importante, verrà trovato il budget.

Hai ragione. Se un'applicazione è in grado di accedere ai contenuti archiviati su macchine aziendali senza che l'utente passi ogni volta informazioni aggiuntive , i programmatori, i manutentori, i amministratori di sistema ecc. Del fornitore di servizi possono accedere a tali contenuti. Questo è fondamentalmente inevitabile, e una delle principali fonti di insicurezza (Edward Snowden era un amministratore di sistema e aveva privilegi speciali al di sopra di "Top Secret" perché semplicemente non esiste un modo per non concederli.)

L'unico modo per evitarlo è richiedere all'utente di fornire informazioni che non arrivano mai alle macchine aziendali. Questo è noioso e soggetto a errori, poiché nessuno può ricordare abbastanza informazioni per formare una barriera di accesso sicura, e quindi le persone inizieranno immediatamente a memorizzare elettronicamente le loro credenziali in un posto, che diventerà quindi il nuovo bersaglio di attacco (e probabilmente un bersaglio più debole di quello che stai mantenendo). Ma se vuoi affermare sinceramente "I nostri dipendenti non sono fisicamente in grado di accedere ai contenuti dei nostri utenti", è l'unico modo.

(Si noti inoltre che un tale modello di business sembra diventare politicamente insostenibile. Le aziende sono state costrette a non operare dai servizi di sicurezza per aver cercato di fare esattamente questo. Comprendo che dare garanzie sulla privacy ha un valore commerciale, ma non può avere valore aziendale rispetto all'obiettivo fondamentale di rimanere in attività.)

Hai perfettamente ragione; alcuni sviluppatori avranno sempre bisogno di accedere ai dati Live, anche solo per diagnosticare problemi di produzione. Il meglio che puoi fare è limitare il danno potenziale riducendo il numero di persone coinvolte.

With great power comes great ... opportunity to really, *really* foul things up. 

Molti sviluppatori non vorranno quella responsabilità e altri, semplicemente non saranno "pronti" a mantenerla, e quindi non dovrebbero avere.

Domanda: Perché il tuo team di sviluppo esegue le versioni Live ?
Suggerirei che hai bisogno di un "team" di Release Management (anche se è solo un sottoinsieme del tuo team, oltre alla rappresentanza aziendale per prendere qualsiasi "decisione" del giorno, come "Go / No-Go")? Ciò eliminerebbe gran parte del "bisogno" per gli sviluppatori di toccare qualsiasi cosa dal vivo.

Hai qualche tipo di accordo di non divulgazione / riservatezza tra sviluppatori e società? È pesante, ma potrebbe avere qualche merito.

Il problema è che i tuoi sviluppatori hanno accesso ai sistemi. Se hanno bisogno di dati di produzione per il debug, dai loro un dump del database in cui tutte le informazioni sensibili vengono rimosse. Quindi gli sviluppatori possono lavorare con quel dump.

L'implementazione di una nuova versione non dovrebbe coinvolgere nessuno sviluppatore, ovvero un'attività di amministrazione pura o, meglio ancora, un'attività completamente automatizzata. Siate anche consapevoli del rilascio e della distribuzione di due compiti molto diversi. Se il tuo processo non è a conoscenza di ciò, modificalo di conseguenza.

Regola n. 1 di sicurezza: se qualcuno ha accesso alle informazioni, ha accesso a tali informazioni

Quella tautologia è fastidiosa, ma è vera. Se si dà accesso a un individuo, questi hanno accesso ai dati. Per gli utenti, questo di solito significa controllo degli accessi, ma per gli sviluppatori ... beh ... sono quelli che devono scrivere il controllo degli accessi.

Se questo è un grosso problema per te (e sembra che lo sia), considera la possibilità di creare sicurezza nel tuo software. Un modello comune è la progettazione di software sicuro a strati. Al livello più basso, un team di sviluppo affidabile progetta software che gestisce il controllo di accesso più semplice. Tale software è validato e verificato da quante più persone possibile. Chiunque progetta quel codice ha accesso a tutto, quindi la fiducia è essenziale.

Successivamente, gli sviluppatori possono creare un controllo degli accessi più flessibile su quel livello principale. Questo codice deve ancora essere V & Vd, ma non è altrettanto rigoroso perché puoi sempre fare affidamento sul livello principale per coprire gli elementi essenziali.

Il modello si estende verso l'esterno.

La parte difficile, in effetti l' arte di progettare questi sistemi, è come costruire ogni livello in modo che gli sviluppatori possano continuare a sviluppare e eseguire il debug pur garantendo alla tua azienda la sicurezza che ti aspetti. In particolare, dovrai accettare che il debug richiede più privilegi di quanto pensi, e il tentativo di bloccarlo provocherà alcuni sviluppatori molto arrabbiati.

Come soluzione laterale, prendere in considerazione la creazione di database "sicuri" a scopo di test in cui gli sviluppatori possono eliminare tutti i meccanismi di sicurezza e eseguire il debug serio.

Alla fine, sia tu che i tuoi sviluppatori dovete comprendere un principio chiave di sicurezza: tutta la sicurezza è un equilibrio tra sicurezza e usabilità. È necessario colpire il proprio equilibrio come azienda. Il sistema non sarà perfettamente sicuro e non sarà perfettamente utilizzabile. Tale equilibrio probabilmente si sposterà anche man mano che la tua azienda cresce e / o le esigenze degli sviluppatori cambiano. Se sei aperto a questa realtà, puoi affrontarla.

Configurare due distribuzioni dell'applicazione che utilizzano anche distribuzioni di database separate. Uno è lo schieramento di produzione e uno è lo schieramento di prova.

La distribuzione di test dovrebbe contenere solo dati di test. Questi possono essere dati fantasy creati a tale scopo o una copia dei dati di produzione che è stata anonimizzata per impedire agli sviluppatori di scoprire le persone e le entità reali dietro i dati.

In due società finanziarie, gli sviluppatori non avevano accesso alle macchine di produzione. Tutte le richieste di modifica delle macchine di produzione dovevano passare attraverso un processo di approvazione, con uno script, ed è stato approvato dai gestori. Il team di sviluppatori ha completato le distribuzioni effettive. Presumo che questa squadra fosse solo dipendenti e abbia superato i controlli in background. Inoltre, non avevano conoscenze degli sviluppatori, quindi probabilmente non potevano curiosare se lo volessero. Inoltre, crittografare tutte le voci del database utilizzando una chiave segreta memorizzata nelle variabili di ambiente. Anche se i database trapelassero pubblicamente nessuno poteva leggerlo. Questa chiave può essere ulteriormente protetta da password (PBKDF) in modo che solo un dirigente possa sbloccarla. Il tuo sistema potrebbe richiedere la password esecutiva all'avvio (o più probabilmente delegato a dev-ops o a un gestore dev-ops). Fondamentalmente la strategia è quella di disperdere le conoscenze in modo che una massa critica delle conoscenze richieste non esista in una persona e ci siano controlli e contrappesi. Ecco come Coca-Cola protegge la sua formula. Onestamente, alcune di queste risposte sono cop-out.

MongoDB ha controlli di sicurezza limitati e dipende da un ambiente sicuro. Associare a una porta e ip specifici (e ssl dal 2.2) e un'autenticazione grezza, ecco cosa offre. MYSQL aggiunge GRANT o ON db.t TO ... I dati a riposo non sono crittografati e ssl non viene utilizzato per impostazione predefinita. Crea una recinzione. L'accesso in sola lettura per gli sviluppatori ai file di registro relativi all'applicazione dovrebbe essere sufficiente per il debug. Automatizza il ciclo di vita dell'applicazione.

Ansible ci ha aiutato ad automatizzare le operazioni standard (distribuzione, aggiornamento, ripristino) su molti ambienti a singolo tennante mentre utilizzava depositi crittografati distinti per archiviare variabili di ambiente sensibili come host, porte e credenziali. Se ogni vault può essere decrittografato solo con ruoli diversi e solo su un host bastion, per le operazioni registrate, la verificabilità offre una sicurezza accettabile. Se si concede SSH, utilizzare selinux per evitare manomissioni delle chiavi, utilizzare un host bastion con autenticazione ldap / kerberos per l'amministrazione e utilizzare saggiamente sudo.