Cifratura dei dati senza sacrificare le prestazioni delle query

6

Stiamo costruendo un'app web cloud supportata da un db multi-tenant. Per massimizzare la sicurezza, abbiamo in programma di crittografare i dati di ciascun cliente con una chiave separata. Il problema è l'interrogazione. Diciamo che sono nello scrittore di report e vogliono ordinare la loro 1.000.000 di clienti da LastName. Ciò funzionerebbe in modo orribile perché tutte le righe 1M dovrebbero essere non crittografate e quindi ordinate su ogni query!

Ecco le uniche opzioni che potrei trovare. Cosa faresti? Ci sono altre opzioni?

  1. Codifica solo le colonne NPI nel db e non consentire mai loro di ordinare o filtrare in base ai valori NPI.

    PRO : protegge i dati sensibili fornendo al tempo stesso prestazioni eccezionali per le query su colonne non NPI

    CON : non un ottimo UX per i nostri utenti

  2. Come il # 1 ma mantiene una cache non crittografata di colonne NPI nella RAM

    PRO : migliore UX

    CON : ora DataInUse non è crittografato (è meglio di DataAtRest non crittografato ??). Inoltre, i filtri con colonne NPI e non NPI sarebbero molto brutti da codificare. Ad esempio, se il filtro era SELEZIONA TUTTI I CLIENTI DOVE NOME LASTNAME "S%" E BIZTYPE="MEDICO", l'ID del record del cognome dovrebbe prima venire dalla cache e poi inviato al database per limitare ulteriormente i record di biztype.

  3. Rinuncia e conserva tutti i dati non crittografati nel database e applica la crittografia db (SQLServer TDE) o la crittografia del disco.

    PRO : ottimo UX e prestazioni

    CON : le prestazioni ne risentirebbero. Inoltre, se la chiave fosse compromessa, tutti i dati dei nostri clienti sarebbero esposti e saremmo sulla copertina del Wall Street Journal.

posta sisdog 11.07.2015 - 02:48
fonte

3 risposte

1

Il problema è la tua soluzione:

"Per massimizzare la sicurezza, abbiamo in programma di crittografare i dati di ciascun cliente con una chiave separata."

Smettila di farlo. L'utilizzo di una chiave separata per ciascun cliente non viene ridimensionato. Utilizza una sola chiave per l'intero database.

In alternativa, crittografare i dati utilizzando un modulo di sicurezza hardware (HSM) prima di essere inserito nel database. Recupera i dati crittografati e quindi decrittografali con il modulo di sicurezza hardware. Le prestazioni delle query non ne risentiranno. Il collo di bottiglia delle prestazioni passa ora al modulo di sicurezza hardware.

    
risposta data 29.09.2015 - 14:18
fonte
0

Hai considerato l'hashing dei dati su cui desideri indicizzare?

L'idea è semplice. Si aggiunge una colonna in cui si memorizza l'hash salato / pepato di LastName, accanto alla colonna Cognome. Quando il server ha bisogno di cercare Mr Smith, basta semplicemente cancellare il nome Smith e quindi cercare il valore hash.

Il problema di questo approccio è che è possibile ottenere informazioni dal database dagli hash.

    
risposta data 13.07.2015 - 20:24
fonte
0

Un suggerimento per la variante:

  1. Crea un nuovo record ID per ogni nuovo cliente caricato
  2. Cripta il SSN
  3. Lavora solo con il nuovo id per selezionare / recuperare

PRO: prestazioni mantenute, SSN crittografato
CON: un nuovo ID da memorizzare per gli utenti

    
risposta data 11.07.2015 - 08:43
fonte

Leggi altre domande sui tag