La crittografia del database impedisce l'accesso basato su file di basso livello al database che elude il sistema di autorizzazione del database. Ciò è particolarmente utile, se è probabile che un utente malintenzionato ottenga l'accesso fisico al computer (pensa a taccuini rubati).
Sui server ha il problema su cosa fare con la chiave / password. Se lo memorizzi al di fuori della crittografia, ti sarà facile per l'attaccante accedervi. Ma non la memorizzazione richiede l'interazione manuale su un riavvio del server che spesso non è desiderabile per motivi di disponibilità.
La crittografia del database non aiuta contro un utente malintenzionato che può sfruttare un'applicazione web che dispone dell'autorizzazione per accedere al database tramite SQL-injection.
Avere un secondo database, in particolare un secondo software di database aumenta la superficie di attacco: sei vulnerabile al insieme di bug di MySQL e H2. E hai bisogno di persone che comprendano entrambi i sistemi per gestirlo in sicurezza.
C'è un vantaggio attraverso: c'è solo un codice molto piccolo che accede alle informazioni di autenticazione. Le vulnerabilità di SQL injection nella stragrande maggioranza del codice non saranno in grado di accedere alle informazioni di autenticazione isolate.
Sul mio posto di lavoro l'abbiamo fatto invece per la nostra applicazione web: utilizziamo diverse connessioni al database a seconda del ruolo dell'utente che esegue le richieste. Ad esempio, un utente anonimo ottiene una connessione al database che ha pochissime autorizzazioni per il database.