Come sapere da chi sto proteggendo le informazioni del database?

transparent database encryption (TDE) or encryption at web server to protect data in a database.

La crittografia trasparente del database significa che non è possibile ignorare i controlli di accesso al database guardando i file memorizzati sul disco. Tu dici che le tue informazioni sono confidenziali; dovresti farlo.

Crittografia sul server web - sembra vago; potrebbe significare una delle due cose:

1. Crittografia del disco del disco rigido del server Web (o crittografia della directory sul disco rigido in cui è archiviato il database). Sembra inutile proteggere i dati nel database se hai abilitato TDE. Certo, potrebbero essere altri dati sensibili sul disco (ad esempio, il codice del server Web che un utente malintenzionato potrebbe sfruttare per trovare buchi), quindi in questo caso si potrebbe prendere in considerazione la crittografia del disco. Nota, la crittografia completa del disco ti protegge solo in caso di andare fisicamente sul server e rimuovere un disco rigido e caricarlo in un altro computer per esaminare i dati. (Ma l'idea alla base di TDE è che tutti i dati nel DB sono inaccessibili).

2. Crittografia per il trasferimento dei dati. Questo è il tuo server web è HTTPS-solo con i client che accedono al tuo sito solo con un certificato attendibile valido, quindi tutte le connessioni / i trasferimenti di dati verso la tua applicazione sono crittografati a chiunque intercetta il traffico di rete. Ne hai sicuramente bisogno se vuoi mantenere i tuoi dati al sicuro; altrimenti è banale rubare le informazioni di autenticazione di un altro utente per ottenere informazioni riservate.

È qui che la comprensione dei rischi e delle minacce è essenziale: ogni settore e ogni organizzazione ha un profilo di rischio diverso.

Per darti un paio di esempi:

• Gli attori chiave di una compagnia petrolifera globale possono essere attivisti ecologici, terroristi, governi stranieri e concorrenti, tutti esterni, ma con diversi vettori di attacco. I governi stranieri possono utilizzare exploit furtivamente finanziati e ben finanziati per ottenere l'accesso a preziosi dati utili, mentre i terroristi potrebbero essere più preoccupati dell'accesso fisico ai pozzi per piazzare esplosivi.

• Un servizio sanitario, pur volendo proteggere i dati medici privati dalla divulgazione, può avere una priorità più strong di mantenere il tempo di attività del sistema al fine di fornire servizi di assistenza sanitaria ai pazienti critici. La loro minaccia chiave identificata potrebbe essere il rischio di interruzione, quindi i controlli saranno concentrati su questo piuttosto che impedire a un utente malintenzionato di ottenere l'accesso.

Quindi hai effettuato una valutazione dei tuoi rischi e gruppi di minacce? I dati nel tuo database sono soggetti alla normativa in cui ti trovi?

Realisticamente, se i dati sono sensibili, si desidera che i controlli prevengano la manomissione dei dati da dbA e impediscano l'accesso a parti esterne, ma la valutazione dei rischi e delle minacce può guidare l'equilibrio della spesa per i controlli.

La securosi in realtà ha fatto un ottimo lavoro (nessuna sorpresa qui), coprendo questo nel loro articolo.

Non sono sicuro di avere abbastanza informazioni qui, ma se - come sto supponendo - stiamo parlando di una configurazione multiutente in cui ogni utente ha i privilegi di accesso per la sua "partizione" DB, quindi per me questo è classificato più come uno scenario di Crittografia Utente / Tokenizzazione.

Detto questo, sono pienamente d'accordo con @Greg_Dolph. Questa non è una "unica risposta giusta", e in questo caso "entrambi" è probabilmente la strada giusta da percorrere.