Il problema non è tanto il luogo in cui si eseguono operazioni di crittografia / decrittografia, ma come si gestiscono le chiavi, i dati crittografati e come si gestisce la crittografia stessa.
La preoccupazione immediata che ho a che fare con l'uso di stored procedure è che la chiave sarà più facilmente accessibile dal livello del database. Questo presenta una vulnerabilità in quanto il tuo database ora si presenta come un componente che se viene compromesso da solo, allora anche i tuoi dati sensibili sono quasi sicuramente compromessi.
Quanto sopra è una VERA vulnerabilità che ti impedirà di raggiungere la conformità agli standard attraverso una serie di standard diversi (ad esempio HIPAA, PCI, ecc.)!
In definitiva, il punto più debole in uno schema di crittografia simmetrica è la debolezza della gestione delle chiavi. Alcune delle soluzioni più sicure (e costose) utilizzano qualcosa chiamato HSM che memorizzerà in modo sicuro le chiavi e le fornirà come necessario per applicazioni in modo sicuro.
Altri modi per risolvere questo problema sono la crittografia del canale tra l'applicazione e i server di database e la richiesta ai server delle applicazioni di fornire la chiave per le stored procedure per la crittografia / decrittografia. Questa è una buona soluzione perché un utente malintenzionato che ha compromesso il database non avrebbe avuto accesso alla chiave, o se l'utente malintenzionato ha compromesso il server delle applicazioni, quindi non avrebbe avuto accesso al database (in teoria). Ciò impedisce un singolo punto di errore.