Sta leggendo da prod a devare problemi di sicurezza? [chiuso]

Non credo sia possibile rispondere in generale. Ma posso pensare ad alcune cose che potrebbero essere valide.

1. Prod contiene dati che dovrebbero essere visualizzati solo da determinate persone. Dato che prod normalmente alimenta dev, i "dati segreti" dovrebbero essere attenuati in qualche modo prima che diventi, oppure i dati stessi sono sensibili al fattore tempo. Se non lo è, allora l'unica differenza tra prod e dev è dev è generalmente più vecchia.
2. Prod ha nomi utente / password / elementi di configurazione sensibili non dovrebbe essere dato agli sviluppatori.

Per lo meno, il tuo esperto di sicurezza dovrebbe essere in grado di identificare la RAGIONE dietro la preoccupazione per la sicurezza piuttosto che dover indovinare. Se non lo è, usa semplicemente la sua autorità in modo irragionevole e non lavora per una soluzione che soddisfi le esigenze di tutti.

È possibile che una società soggetta a controlli PCI o HIPAA possa aver bisogno di scrivere una politica di sicurezza che vieta la condivisione di dati tra dev e prod per rispettare gli standard di sicurezza dei dati, ma è anche possibile che abbia scritto la politica in modo che si applichi a tutti i dati, non solo al PCI o ai dati sanitari.

Questa non è necessariamente una brutta cosa. La sicurezza non è solo la difesa dagli attacchi, ma la protezione dai rischi in generale. Un sacco di problemi sono stati causati da dati che attraversano il confine in entrambe le direzioni, e seguendo una buona politica è possibile evitare perdite.

Una banca aveva un famoso esempio di un problema che avrebbe potuto essere prevenuto seguendo questa politica. Hanno deciso di inviare una lettera di sollecito ai loro mille migliori clienti. Naturalmente, alcuni sviluppatori avevano inserito un nome falso intelligente nel loro database di test. A causa di un mix tra dev e prod, le lettere sono state inviate a tutti i loro buoni clienti con il saluto "Dear Rich Bastard". Anche se non è un rischio "di sicurezza" nel senso che un aggressore non lo ha causato, potrebbe aver perso alcuni buoni clienti a causa di questo errore.

Al contrario, copiare i dati da prod a dev può aprire buchi nel tuo ambiente protetto. Potresti argomentare caso per caso perché i dati X sono sicuri di passare a dev mentre i dati Y non sono sicuri da spostare, ma anche questo introduce rischi. Chi autorizza il trasferimento sicuro dei dati? Chi garantisce che vengano spostati solo i dati sicuri, ma non i dati sensibili? Le porte del firewall sono aperte per spostare i dati e, in tal caso, chi li apre e li chiude? Chi controlla il movimento dei dati? Chi controlla le porte del firewall sono state chiuse? Ci sono molte parti mobili, ognuna delle quali può fallire nel lasciare dati o sistemi esposti.

Una singola politica che vieta tale movimento elimina il rischio, ma a un costo. Ora è necessario spendere risorse per creare i dati del test. È qui che puoi fare un business case: il costo della polizza è X, il rischio evitato dalla politica è Y, ne vale la pena? Semplicemente iniziando l'analisi, potresti arrivare rapidamente alla conclusione che non vale la pena di proseguire.

Non posso parlare pienamente del motivo per cui il responsabile della sicurezza locale lo considera un rischio / preoccupazione per la sicurezza, ma posso dirti due cose che suppongo stia pensando; anche se non sta pensando a queste cose, questa sarà la mia risposta in quanto è questo che mi preoccuperebbe se fossi il responsabile della sicurezza locale della tua organizzazione:

1. Hai detto che il pungolo è bloccato, e non tanto. La mia prima preoccupazione sarebbe rappresentata dai dati sensibili della società, che potrebbero non contenere PII, ma potrebbero essere OUO (solo per uso ufficiale) e trapelare maggiori probabilità di essere trapelati o manipolati in quanto non sembra avere la stretta protezione controlla che dev fa. Ancora una volta posso solo uscire dal contesto che hai impostato nella tua domanda, ma se le informazioni aziendali non sono così strettamente controllate in dev come in prod, allora posso sicuramente vedere la preoccupazione del tuo ragazzo / ragazza della sicurezza.
2. Hai anche detto che i dati possono passare da prod a dev e (non dovrei farlo, ma presumo viceversa, da dev a prod) se i dati possono fluire da almeno prod a dev, allora deve esserci un connessione di rete fisica / logica tra i due. Ancora una volta, gli ambienti di produzione dovrebbero essere sottoposti a controlli di sicurezza più rigorosi in modo da proteggere i dati a cui ci si riferisce. Se c'è una connessione di rete, allora per me è un punto di ingresso per rischi potenzialmente dannosi da inserire in prod. Non sto parlando necessariamente di virus in sé (tuttavia questa minaccia potrebbe essere molto reale se il tuo ambiente di sviluppo, come la maggior parte, ha una postura di sicurezza molto rilassata e consente l'installazione e / o l'adozione di tutti i tipi di configurazioni e software e altri processi luogo), piuttosto qualsiasi tipo di vettore dannoso che potrebbe comportare il compromesso di integrità, riservatezza o disponibilità a causa della connessione di rete (fisica o logica) da prod a dev. Sono sicuro che ci siano dei firewall coinvolti, tuttavia non sono a conoscenza del tipo di ACL o di altre politiche di accesso che voi avete in atto. Questo, di nuovo, meriterebbe preoccupazione dal tuo responsabile della sicurezza.

Questo non è Vangelo, ma viene da un professionista della sicurezza che pensa molto al tuo ragazzo / a.

Speriamo che questo possa darti qualche informazione in più su quello che stanno pensando.

Gli ambienti di produzione e non di produzione dovrebbero essere isolati come best practice. I tuoi ambienti non di produzione probabilmente hanno meno monitoraggio, potrebbero avere codice non sicuro, potrebbero non avere macchine aggiornate, ecc.

Se hai qualcosa che può andare tra questi ambienti, aumenti il rischio di:

• Malware che attraversa da dev a prod
• Confusione e mix di appartenenze o permessi di gruppo
• Persone che utilizzano accidentalmente dev per processi di produzione o processi decisionali
• Le persone vengono confuse su dove stanno accedendo alle informazioni

Se hai un processo ETL che invia gli stessi dati alla produzione e alla non produzione, potresti anche violare i requisiti / le politiche sulla privacy dei dati o requisiti esterni come HIPAA o PCI.

In generale, data non dovrebbe passare dalla produzione allo sviluppo o viceversa. Solo il codice dovrebbe essere migrato da dev alla produzione attraverso un processo ben definito e controllato.

Probabilmente non dovresti condividere i sistemi di autenticazione o almeno gli account tra entrambi gli ambienti. Potresti anche non voler utilizzare account di produzione per ambienti di "addestramento". I sistemi di produzione dovrebbero rimanere isolati da tutto ciò che non è prodotto.

Ho visto ambienti non di produzione e di test in cui sono consentiti tutti i tipi di cose strane, in cui gli account sono stati condivisi tra gli sviluppatori, i dati sono stati scaricati, registrati e analizzati in modi che non sarebbero accettabili per i dati di produzione in qualsiasi organizzazione .

Leggendo alcuni dei tuoi commenti ad altre risposte: Sembra una preoccupazione potrebbe essere troppi dati consentiti nell'ambiente dev. Non è chiaro se si stanno disinfettando i dati, ma potrebbe essere un rischio accettabile avere un mese di dati in dev, ma mettere 5 anni di valore è un'esposizione al rischio eccessiva.

Aggiornerò la mia risposta se aggiungerai ulteriori dettagli alla tua domanda.