Die integrierte Lösung von Oracle für dieses Problem ist keine Verschlüsselung, sondern eine Zugriffskontrolle mit Database Vault oder Virtual Private Database, um zu verhindern, dass der DBA oder andere Benutzer die Daten sehen, und Transparent Data Encryption, um die Daten im Ruhezustand zu verschlüsseln (OS/file -Level-Verschlüsselung). Dies verhindert nicht nur, dass der DBA die Daten sieht, sondern sie auch ändert oder löscht.
Wenn Sie die Datenwerte trotzdem verschlüsseln möchten, dann sollte die gesamte Verschlüsselung/Entschlüsselung und Schlüsselverwaltung extern erfolgen aus der Datenbank, wo der DBA keinen Zugriff auf die Verschlüsselungsschlüssel hat. Wie das funktioniert, hängt von Ihrem Anwendungsdesign und der Wahl der Programmiersprache(n) ab. Beachten Sie, dass der Aufbau einer robusten Verschlüsselungs- und Schlüsselverwaltungsarchitektur nicht ist eine triviale Übung...
Beachten Sie auch, dass das Verpacken von PL/SQL-Quellcode nur Verschleierung ist des Codes und nicht der Verschlüsselung. Es kann einfach sein mit einer beliebigen Anzahl bestehender Websites oder interner gespeicherter Prozeduren rückgängig gemacht werden. Ein echter DBA hätte auch den Befehl execute any procedure oder sich selbst ausdrücklich die Erlaubnis erteilen können, eine Entschlüsselungsfunktion auszuführen, und sich nicht einmal darum kümmern müssen, was der Schlüssel war (nur Database Vault könnte dies verhindern).
Es wäre auch problematisch, den Schlüssel als Eingabe an die Funktion zu übertragen, anstatt ihn direkt in den Code einzubetten, da der DBA Ihr SQL auf verschiedene Arten sehen kann. Bei der Übertragung per SQL-Abfrage könnte der Schlüssel auch in ADDM-Berichten, Datenbank-Trace-Dateien oder dem Audit-Trail offengelegt werden.
Es gibt nein sicherer Weg, um die Verschlüsselung zu handhaben, wie Sie sie mit PL/SQL beschreiben, die auch die Daten vor dem DBA schützt.
