Codifica i record del database a cui possono accedere più utenti

0

Voglio crittografare i dettagli dei clienti serializzati e archiviarli in un database per proteggerli dagli attacchi in cui l'autore dell'attacco ha accesso ai record del database non elaborati. I record devono quindi essere accessibili da più utenti registrati, ma non è necessario indicizzarli o cercarli.

L'approccio ingenuo sarebbe quello di utilizzare una chiave di sistema per la crittografia simmetrica usando AES o simili, tuttavia non sono sicuro che sia più sicuro di nessuna crittografia.

È generalmente sicuro affermare che l'accesso al DB grezzo è più una minaccia dell'accesso al codice sorgente? Supponendo che sia così (che credo sia il caso nella mia situazione), c'è un approccio migliore che posso usare di una chiave di sistema?

Grazie

    
posta David John Smith 30.01.2015 - 04:28
fonte

2 risposte

2

Il problema con l'accesso diretto al database è che gli utenti possono estrarre grandi quantità di dati, ad es. SELECT * FROM TableName.

Se si crittografa i dati nel database utilizzando la crittografia trasparente, gli utenti con accesso ai dati vedono la crittografia in modo trasparente o, in altre parole, vedono i dati in chiaro. Anche se vedono dati crittografati, potrebbero avere una vista configurata per vedere tali dati in chiaro.

Potresti prendere in considerazione la crittografia dei dati a livello di applicazione. Ciò significa che i dati verranno crittografati all'interno del database in modo che i DBA vedano solo i dati crittografati. L'applicazione può quindi decrittografare e pubblicare dati in base ai privilegi dell'utente. Questo potrebbe essere ottimizzato in modo che gli utenti finali vedano solo singoli pezzi di dati alla volta anziché elenchi o volumi e la registrazione potrebbe essere abilitata in modo da poter identificare chi ha effettuato l'accesso a quali dati.

Quindi è necessario considerare come viene implementata la gestione delle chiavi in modo che la chiave di crittografia utilizzata dall'applicazione non venga memorizzata da qualche parte in chiaro e non sia disponibile per nessun utente. AES con una lunghezza di bit pari a 128 o superiore è una chiave simmetrica perfettamente ragionevole da utilizzare.

    
risposta data 30.01.2015 - 21:24
fonte
1

Supponendo che tu intenda "leggi il codice sorgente" e non "modifica il codice sorgente" quando dici "accesso al codice sorgente", quindi Il principio di Kerckhoffs si applica e tu sei effettivamente corretto che l'accesso al database raw sia una minaccia più grande. Questo non vuol dire che dovresti rendere facile per chiunque ottenere il tuo codice sorgente, ma idealmente il tuo sistema dovrebbe essere progettato in modo da non essere intrinsecamente vulnerabile se il tuo codice sorgente è trapelato.

Non riesco a immaginare un modo in cui gli hacker possano accedere ai record del database non elaborati e rimanere al sicuro. I tuoi utenti avranno bisogno di un sistema per convertire quei record in qualcosa di utile, e se si tratta di una chiave, allora dovrai dipendere in qualche modo dagli utenti la chiave in modo sicuro che gli aggressori non potrebbero mai scendere a compromessi. Dovresti utilizzare qualcosa come l'algoritmo di condivisione segreta di Shamir per dare a ciascun utente una chiave univoca, o cambiare il chiave (e reencrypt il tuo database) con una frequenza elevata in modo che gli utenti non possano accedere ai dati. Ciò presuppone che i tuoi aggressori non saranno mai utenti e non saranno mai in grado di compromettere i sistemi dell'utente e non saranno mai in grado di trovare la chiave sul tuo server. Se si intende che gli utenti malintenzionati possono inserire o aggiornare i record del database quando si dice "l'autore dell'attacco ha accesso ai record del database non elaborati", non c'è nulla che si possa fare per impedire che il sistema venga completamente utilizzato. Il tutto urla "cattiva idea".

Generalmente, gli utenti accedono ai database attraverso una pagina Web o un programma, ed è solo quel server Web o software che ha accesso al database. La pagina web o il programma gestisce l'autenticazione e limita ciò che gli utenti possono fare per prevenire gli attacchi. La pagina web o il programma devono essere scritti in modo tale che non accedano ai record degli utenti finché non li ha autenticati con le credenziali archiviate sul server di back-end; questo impedisce agli aggressori di ottenere i tuoi dati in modo molto più efficace di quello di dare via il tuo database e cercare di trovare un algoritmo di crittografia veloce per gli utenti e resistere alla bruteforcing da parte degli aggressori e un metodo di implementazione che proteggerà sufficientemente la tua chiave di decrittazione.

Tutto ciò che viene detto, AES sarebbe un algoritmo accettabile se davvero, davvero volessi farlo in quel modo, nonostante tutte le ragioni per cui sarebbe una cattiva idea.

    
risposta data 30.01.2015 - 21:10
fonte

Leggi altre domande sui tag