Вграденото решение на Oracle за този проблем не е криптиране, а контрол на достъпа с помощта на Database Vault или Virtual Private Database, за да се предотврати съответно DBA или други потребители да виждат данните, и Transparent Data Encryption за шифроване на данните в покой (ОС/файл - ниво на криптиране). Това не само пречи на DBA да вижда данните, но и да ги променя или изтрива.
Ако все пак искате да шифровате стойностите на данните, цялото криптиране/декриптиране и управление на ключове трябва да се извършват външно от базата данни, където DBA няма да има достъп до ключовете за криптиране. Как работи това ще зависи от дизайна на вашето приложение и избора на език(ове) за програмиране. Имайте предвид, че изграждането на стабилно криптиране и архитектура за управление на ключове не тривиално упражнение...
Също така имайте предвид, че опаковането на изходния код на PL/SQL е само обфускация на кода, а не на криптиране. Може да бъде лесно обърнати с помощта на произволен брой съществуващи уеб сайтове или вътрешни съхранени процедури. Истинският DBA също би имал execute any procedure привилегия или да могат да си предоставят изрично разрешение за изпълнение на която и да е функция за дешифриране и дори да не се интересуват какъв е ключът (само Database Vault може да предотврати това).
Предаването на ключа към функцията като вход, вместо директното му вграждане в кода, също би било проблематично, тъй като DBA може да види вашия SQL по различни начини. Когато се предава чрез SQL заявка, ключът може също да бъде изложен в ADDM отчети, файлове за проследяване на бази данни или одитна пътека.
Няма не сигурен начин за обработка на криптирането, както описвате с PL/SQL, който също защитава данните от DBA.
