La soluzione integrata di Oracle a questo problema non è la crittografia, ma il controllo dell'accesso tramite Database Vault o Virtual Private Database per impedire al DBA o ad altri utenti di vedere i dati, rispettivamente, e Transparent Data Encryption per crittografare i dati inattivi (sistema operativo/file crittografia di livello). Questo non solo impedisce al DBA di vedere i dati, ma anche di alterarli o eliminarli.
Se vuoi comunque crittografare i valori dei dati, allora tutta la crittografia/decodifica e la gestione delle chiavi dovrebbero essere gestite esternamente dal database in cui il DBA non avrà accesso alle chiavi di crittografia. Il modo in cui funziona dipenderà dal design dell'applicazione e dalla scelta dei linguaggi di programmazione. Tieni presente che la creazione di una solida architettura di crittografia e gestione delle chiavi non un esercizio banale...
Tieni inoltre presente che il wrapping del codice sorgente PL/SQL è solo offuscamento del codice e non della crittografia. Può essere facilmente annullato utilizzando un numero qualsiasi di siti Web esistenti o procedure archiviate interne. Un vero DBA dovrebbe anche execute any procedure privilegio o essere in grado di concedersi un'autorizzazione esplicita per eseguire qualsiasi funzione di decrittazione e non doversi nemmeno preoccupare di quale fosse la chiave (solo Database Vault potrebbe impedirlo).
Anche trasmettere la chiave alla funzione come input invece di incorporarla direttamente nel codice sarebbe problematico, poiché il DBA può vedere il tuo SQL in molti modi. Se trasmessa tramite query SQL, la chiave potrebbe anche essere esposta nei report ADDM, nei file di traccia del database o nell'audit trail.
Non c'è non modo sicuro per gestire la crittografia come stai descrivendo con PL/SQL che protegge anche i dati dal DBA.
