Come posso impedire ai programmatori di acquisire i dati inseriti dagli utenti?


10

Sto sviluppando un'applicazione web con una forte attenzione alla sicurezza. Quali misure possono essere adottate per impedire a coloro che lavorano sull'applicazione (programmatori, amministratori di database, personale addetto all'assicurazione della qualità) di acquisire valori immessi dall'utente che dovrebbero essere ben protetti, come password, numeri di previdenza sociale e così via?


3
Suggerirei di pubblicare la domanda in: security.stackexchange.com/?as=1
NoChance

"Prevenire" è una parola molto forte. Non puoi impedire agli attori cattivi di fare cose cattive. Quello che puoi fare è imparare e applicare i principi di sicurezza fondamentali come "privilegio minimo", "separazione dei doveri" e "negazione implicita", progettare le cose in modo sicuro e assumere persone di cui ti puoi fidare. Predisporre piani attuabili per mitigare il danno quando si verifica l'inevitabile.
Robert Harvey,

I termini tecnici per le tecnologie di cui hai bisogno: hashing e crittografia.
Robert Harvey,

Risposte:


22

Questo è abbastanza semplice Le banche lo fanno sempre.

Hai tre gruppi di persone coinvolte. Questi sono gruppi di sicurezza. Con autorizzazioni distinte.

Gli sviluppatori non possono assegnare autorizzazioni di sicurezza e non possono vedere i dati di produzione.

Gli operatori non possono assegnare autorizzazioni di sicurezza e non possono creare software.

Persone di sicurezza che impostano le autorizzazioni e non possono né creare software né far funzionare il software.

Gli sviluppatori creano software. Gli operatori lo installano e lo fanno funzionare. Gli addetti alla sicurezza assicurano che i due gruppi siano tenuti separati.


8
OK, ma uno sviluppatore potrebbe ancora aggiungere qualcosa al sistema che invia i dati di produzione al proprio account privato; o scrive i dati di produzione su alcuni server dove li raccoglierà. Penso che l'unico modo per aggirare questo problema sia con un rigoroso regime di revisione del codice.
Dawood ibn Kareem,

3
C'è sempre quel livello di fiducia che viene dato ai dipendenti. Qualcuno deve avere le chiavi del palazzo, e se non puoi fidarti che capiscono il potere che viene loro dato, allora forse non dovremmo dare quelle chiavi a quella persona in primo luogo.
Chris

1
Sì, ma avere chiavi che richiedono più di una persona (come il regime di revisione del codice) significa che ne occorrono due per "smarrirsi" prima di essere compromessi e che è meno probabile che "solo un" impiegato si smarrisca e abusi della chiave assegnata a loro. È tutta una questione di bilanciamento della fiducia e delle conseguenze dell'abuso di tale fiducia. E non dimenticare che le persone e le circostanze cambiano. Una persona degna di fiducia quando vengono fornite le chiavi può accadere che nella vita accadano cose per le quali diventa meno degno di fiducia ...
Marjan Venema,

1
@EmmadKareem: Corretto. Il responsabile della sicurezza imposta e reimposta gruppi e password, ma non può visualizzare i dati. Solo gli operatori possono vedere dati reali. Pensa a dati come denaro reale gestito da veri narratori. I programmatori non toccano i soldi; dicono solo a. Allo stesso modo, le persone della sicurezza non toccano il denaro; solo i narratori toccano il denaro.
S. Lott

1
@EmmadKareem: i DBA non sono sviluppatori. Esistono due gruppi: sicurezza e dati. I DBA dei dati sono una parte speciale delle "operazioni". Essi dovrebbero non avere l'autorizzazione per la sicurezza cambiamento; non possono scrivere codice; vedranno i dati, tuttavia, e devono essere trattati come operatori, non sviluppatori.
S. Lott

2

I programmatori non hanno accesso ai server di produzione. Ma qualcuno deve avere accesso. Non c'è modo di aggirarlo. E c'è sempre la possibilità che qualcuno possa impazzire e abusare del proprio accesso.

I dati sottoposti a hash / salati sono teoricamente sicuri anche dalle persone che hanno pieno accesso per visualizzarli. Ma la maggior parte dei dati non è appropriata per l'hash.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.