Wbudowanym rozwiązaniem Oracle nie jest szyfrowanie, ale kontrola dostępu przy użyciu Database Vault lub Virtual Private Database, aby uniemożliwić administratorowi lub innym użytkownikom wyświetlanie danych, oraz Transparent Data Encryption do szyfrowania danych w spoczynku (system operacyjny/plik szyfrowanie na poziomie). To nie tylko uniemożliwia administratorowi dostęp do danych, ale także zmienia je lub usuwa.
Jeśli mimo wszystko chcesz zaszyfrować wartości danych, całe szyfrowanie/odszyfrowywanie i zarządzanie kluczami powinny być obsługiwane zewnętrznie z bazy danych, w której administrator nie będzie miał dostępu do kluczy szyfrowania. Sposób, w jaki to działa, będzie zależeć od projektu aplikacji i wyboru języków programowania. Pamiętaj, że tworzenie solidnej architektury szyfrowania i zarządzania kluczami nie trywialne ćwiczenie...
Należy również pamiętać, że zawijanie kodu źródłowego PL/SQL jest tylko zaciemnianiem kodu, a nie szyfrowania. To może być łatwe cofnięte przy użyciu dowolnej liczby istniejących witryn internetowych lub wewnętrznych procedur przechowywanych. Prawdziwy administrator DBA miałby również execute any procedure przywilej lub możliwość przyznania sobie wyraźnego pozwolenia na wykonanie dowolnej funkcji odszyfrowywania i nawet nie muszą się przejmować tym, jaki był klucz (tylko Database Vault może temu zapobiec).
Przesyłanie klucza do funkcji jako danych wejściowych zamiast osadzania go bezpośrednio w kodzie również byłoby problematyczne, ponieważ administrator danych może zobaczyć Twój kod SQL na wiele sposobów. Po przesłaniu przez zapytanie SQL klucz może być również ujawniony w raportach ADDM, plikach śledzenia bazy danych lub ścieżce audytu.
Nie ma nie bezpieczny sposób obsługi szyfrowania, jak opisujesz w PL/SQL, który również chroni dane przed DBA.
