Database di partizionamento per migliorare la sicurezza / l'anonimato?

Question

Database di partizionamento per migliorare la sicurezza / l'anonimato?

#1 da (0 voti)
#2 da (0 voti)
#3 da (0 voti)

2

L'obiettivo qui è impedire l'identificazione degli utenti e dei loro dati. È una buona idea dividere il mio database in più di uno, uno per ogni tipo di dati sensibili, nascondendo i collegamenti tra loro?

All'inizio sembra che la risposta sia sì, perché un utente malintenzionato dovrebbe ottenere l'accesso a tutti i database (potenzialmente serviti da server / macchine virtuali / contenitori diversi) al fine di creare relazioni tra i dati e gli utenti e identificarli.

Ovviamente, fare così aggiunge un sacco di complessità al livello dell'applicazione, quindi mi chiedo se questa sia una buona idea.

EDIT: ecco un esempio più concreto.

Il progetto è un sito web. Il codice dell'applicazione viene eseguito sul server A. Le connessioni vengono eseguite dall'applicazione ai database db1, db2 e db3, rispettivamente sugli host B, C e D. Nessuna crittografia (ovviamente le password, ovviamente). Il codice dell'applicazione contiene le credenziali per tutti e tre i database. Quindi ho un "collo di bottiglia di sicurezza" ed è il server A. Inoltre, le relazioni tra i dati non sono memorizzate in un database separato, ma suddivise nei tre database.

Questo cattivo design? Farei meglio a configurare

un solo database (nel server E) e rigorosamente il server A ed E? o
un altro database per contenere i collegamenti tra i dati, per ritardare ulteriormente la possibile identificazione degli utenti?

Altre soluzioni da considerare?

Tutto ciò sarebbe utile anche se il server A è un singolo punto di errore / collo di bottiglia di sicurezza?

attacks databases identification security-by-design

posta pawamoy 15.06.2018 - 11:44

fonte

3 risposte

Leggi altre domande sui tag attacks databases identification security-by-design

"Errore meccanismo di protezione (CWE ID 693) Esistono vulnerabilità XSS durante l'anteprima delle immagini prima di caricarle?

score 0 · Answer 1

L'entità che è in grado di combinare i dati in seguito sarà probabilmente il collo di bottiglia della "sicurezza".

Ovviamente puoi avere una relazione:

       user
     /      \
    A        B

e sperare che un utente malintenzionato abbia accesso solo a A o B o potenzialmente a ENTRAMBI ma qualcuno in qualche modo deve avere una conoscenza su come riassemblare questo insieme ed è qui che si verificherà il collo di bottiglia. Tuttavia, diciamo che qualcuno riesce ad attaccare il collo di bottiglia, potrebbero solo essere in grado di recuperare il collegamento dei set di dati agli utenti, ma non necessariamente ottenere l'accesso ai dati stessi. Diciamo che hai tre server A, B e R dove A, B memorizzano i dati grezzi e R memorizzano le relazioni. Come faresti il controllo degli accessi? Critteste i dati in modo che solo l'utente stesso possa decrittografare le informazioni e metterle insieme? A e B non sanno chi sei, quindi non puoi realmente effettuare il controllo degli accessi su questi set di dati perché se memorizzi CHI ha accesso a quali dati su A e B lo stai già collegando a un utente.

In che modo la tua applicazione accede ai dati? Hai bisogno di eseguire calcoli sui dati? Come lo fai se non conosci le relazioni?

Per me ... questo è semplicemente troppo ampio. Si potrebbe ottenere una risposta significativa per uno scenario specifico ma probabilmente non nel caso generico.

score 0 · Answer 2

La minaccia non è definita abbastanza chiaramente. Hai detto che vuoi impedire l'identificazione degli utenti e dei loro dati, ma non hai detto chi. I tuoi compagni di squadra? Il tuo provider di hosting? Un attaccante casuale? Qualcuno interessato ai tuoi dati e disposto a provare un attacco mirato?

Fondamentalmente hai ammesso che c'è un collo di bottiglia, che è la tua applicazione e il server che la esegue. Quindi la tua idea di dividere il database funzionerà solo contro le minacce che attaccheranno con successo i tuoi database, ma non riusciranno ad attaccare la tua applicazione. Che tipo di minacce sono queste? Non riesco davvero a pensare a molti esempi in questo momento. Forse la minaccia di un ladro che ruba i backup del database: se i backup si trovano in luoghi diversi, le probabilità di rubarli sono inferiori e quindi il ladro ha meno probabilità di ottenere tutti i dati. Ma i backup devono essere comunque crittografati, quindi se vengono utilizzate buone pratiche di crittografia, perché perdere tempo a cercare di implementare un sistema che utilizza più database? Inoltre, considerando che l'aggiunta di complessità nell'applicazione aumenterà la probabilità di bug, alcuni dei quali potrebbero portare a ulteriori vulnerabilità.

Quindi, a mio parere, la domanda è, ancora una volta: quali sono le minacce che stanno per compromettere i tuoi database, ma non la tua applicazione? Dopo aver risposto a questa domanda, l'intera situazione sarà più chiara.

score 0 · Answer 3

Direi che questo rientra in sicurezza dall'oscurità che non è mai un metodo di sicurezza infallibile. Da chi stai cercando di nascondere i dati? Per un utente finale non fa differenza.

Gli sviluppatori e gli amministratori di sistema presumibilmente sarebbero in grado di accedere a tutti i database. Se come dici tu li servi da diversi vms o contenitori, io sono un hacker che si è radicato sul tuo hypervisor o host del contenitore, quindi ho accesso root a tutti loro.

Se i server db sono ospitati da provider diversi, presumibilmente si eseguirà lo stesso sistema operativo e lo stesso sistema DB su ciascun server DB separato, quindi un hacker trova un exploit in un server DB applicabile a tutti gli altri. Aumenteresti solo il numero di server da applicare. in caso contrario, si hanno versioni os e db separate su ciascun provider, si possono riscontrare comportamenti orribili di dipendenza specifici della versione e aumentare il numero di server diversi per cui si gestiscono le patch di sicurezza.