Protezione dei dati sensibili dagli sviluppatori

La sicurezza non è una bacchetta magica che puoi sventolare alla fine di un progetto, deve essere considerata e costruita dal primo giorno. Non è un bolt-on, è l'applicazione coerente di una gamma di soluzioni applicate iterativamente e revisionato regolarmente come parte di un intero sistema, che è strong solo quanto l'anello più debole.

Così com'è stato segnalato un problema di sicurezza che è un buon primo passo. Ora come minimo devi definire: -

• Quali dati stai cercando di proteggere?
• Chi stai cercando di proteggere i dati da?
• Chi in realtà ha bisogno di accedere a cosa (e quando)?
• Qual è l'impatto legale / finanziario / commerciale di tali dati che vengono compromessi?
• Qual è l'esigenza legale / finanziaria / aziendale per una persona / gruppo che ha accesso ai dati?
• Quale budget è l'azienda disposta ad assegnare a una strategia di "sicurezza, sicurezza" quando non era un requisito aziendale in precedenza?
• Di che tipo di accesso ha bisogno il sistema per i dati?
• In cosa consiste questo processo e questi sistemi su cui si basa questa applicazione?
• Che cosa è fatto per proteggere quegli ambienti?
• Chi sarà responsabile dell'implementazione e della revisione dell'intero processo?

Finché non conosci tutti quei dettagli in realtà non hai nulla con cui lavorare. Queste informazioni definiranno quali attenuazioni a quelle minacce che puoi (e non puoi) applicare e perché.

Può 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. Ascolto abbastanza spesso la risposta che non c'è un budget: se è considerato veramente importante, verrà trovato il budget.

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

L'unico modo per evitare ciò è richiedere all'utente di fornire informazioni che non siano mai disponibili per le macchine aziendali. Questo è noioso e soggetto a errori, dal momento che nessuno può ricordare abbastanza informazioni per formare una barriera di accesso sicura, e quindi le persone inizieranno immediatamente a memorizzare le proprie credenziali elettronicamente in qualche posto, che diventerà 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 simile modello di business sembra diventare politicamente insostenibile. Le aziende sono state costrette a ritirarsi dai servizi di sicurezza per aver tentato di fare esattamente questo. Capisco che dare garanzie sulla privacy abbia un valore aziendale, ma non può possibilmente hanno più valore aziendale rispetto all'obiettivo fondamentale di rimanere in attività.)

Hai perfettamente ragione; alcuni sviluppatori avranno sempre bisogno di accedere ai dati Live, se non altro 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 questa responsabilità e altri, semplicemente non saranno "pronti" a tenerlo, e quindi non dovrebbero avere.

Domanda: perché il tuo team Sviluppo esegue Live releases ?
Ti suggerirei di avere bisogno di un "team" di gestione dei rilasci (anche se questo è solo un sottoinsieme della tua squadra, oltre alla rappresentanza aziendale per prendere "decisioni" quotidiane, come "Go / No-Go")? Ciò rimuoverebbe gran parte della "necessità" per gli sviluppatori di toccare qualsiasi cosa Live.

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, allora danno loro un dump del database in cui tutte le informazioni sensibili vengono rimosse. Quindi gli sviluppatori possono lavorare con quel dump.

La distribuzione di una nuova versione non dovrebbe coinvolgere nessuno sviluppatore, che è una pura attività di amministrazione, o meglio ancora, un'attività completamente automatizzata. Ricordati inoltre di rilasciare e distribuire due compiti molto diversi. Se il tuo processo non ne è a conoscenza, cambiala di conseguenza.

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

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

Se questo è un grosso problema per te (e sembra così), considera la possibilità di costruire sicurezza nel tuo software. Un modello comune è progettare software sicuro a strati. Al livello più basso, un team di sviluppo fidato progetta un software che gestisce il più completo controllo degli accessi. Quel software è validato e verificato da quante più persone possibile. Chiunque stia progettando quel codice ha accesso a tutto, quindi la fiducia è essenziale.

Successivamente, gli sviluppatori possono creare un controllo di accesso 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 l'essenziale.

Il modello si estende verso l'esterno.

La parte difficile, anzi la arte del design di questi sistemi, è come costruire ogni livello in modo che gli sviluppatori possano continuare a sviluppare ed eseguire il debug pur continuando a fornire alla tua azienda la sicurezza che ti aspetti. In particolare, dovrai accettare il fatto che richieda il debug di più privilegi di quanto tu pensi che dovrebbe, e il tentativo di bloccarli causerà alcuni sviluppatori molto arrabbiati.

Come soluzione collaterale, considera la possibilità di creare database "sicuri" a scopo di test, in cui gli sviluppatori possono rimuovere tutti i meccanismi di sicurezza e fare il debug serio.

Alla fine, sia tu che i tuoi sviluppatori dovete capire un principio chiave di sicurezza: Tutta la sicurezza è un equilibrio tra sicurezza e usabilità. dovete colpire da soli equilibrio come una società. Il sistema non sarà perfettamente sicuro e non sarà perfettamente utilizzabile. Questo equilibrio probabilmente si sposterà anche quando la tua azienda cresce e / o le richieste di cambiamento degli sviluppatori. Se sei aperto a questa realtà, puoi affrontarlo.

Configurare due distribuzioni dell'applicazione che utilizzano anche distribuzioni di database separate. Uno è la distribuzione di produzione e uno è la distribuzione di test.

L'implementazione del test dovrebbe avere solo dati di test. Può trattarsi sia di dati fantasy creati a tale scopo sia di una copia dei dati di produzione che è stata anonimizzata per impedire agli sviluppatori di scoprire le persone reali e le entità dietro ai dati.

In due società finanziarie, gli sviluppatori non avevano accesso alle macchine di produzione. Tutte le richieste di modifica delle macchine di produzione sono state sottoposte a un processo di approvazione, a uno script e approvate dai gestori. Il team di sviluppo ha completato le distribuzioni effettive. Presumo che questa squadra fosse solo dipendente e ha superato i controlli di background. Inoltre non avevano conoscenze dello sviluppatore, quindi probabilmente non potevano curiosare se volevano. Oltre a questo, si crittografano tutte le voci del database utilizzando una chiave segreta memorizzata nelle variabili di ambiente. Anche se i database trapelassero pubblicamente nessuno potrebbe leggerlo. Questa chiave può essere ulteriormente protetta da password (PBKDF) in modo che solo un dirigente possa sbloccarla. Il sistema potrebbe richiedere la password di amministratore all'avvio (o più probabilmente delegato a sviluppatori o un gestore di sviluppo). Fondamentalmente la strategia è quella di disperdere la conoscenza in modo che una massa critica di conoscenze richieste non esista in una sola persona e che ci siano controlli-equilibrio. 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. Collegando uno specifico ip e port (e ssl dal 2.2) e un'autentica autenticazione, ecco cosa offre. MYSQL aggiunge GRANT o ON db.t TO ... I dati a riposo non sono crittografati e ssl non è usato di default. Crea una recinzione. L'accesso di sola lettura per gli sviluppatori ai file di registro relativi alle applicazioni dovrebbe essere sufficiente per eseguire il debug. Automatizza il ciclo di vita dell'applicazione.

Ansible ci ha aiutato ad automatizzare le operazioni standard (distribuire, aggiornare, ripristinare) su molti ambienti single-tennant utilizzando contemporaneamente depositi crittografati distinti per memorizzare variabili di ambiente sensibili come host, porte e credenziali. Se ogni deposito può essere decifrato solo da ruoli diversi e solo su un host bastion, per le operazioni registrate, la verificabilità fornisce una sicurezza accettabile. Se si concede SSH, utilizzare selinux per evitare la manomissione dei tasti, utilizzare un host bastion con autenticazione ldap / kerberos per l'amministrazione e utilizzare sudo con saggezza.