La solution intégrée d'Oracle à ce problème n'est pas le chiffrement, mais le contrôle d'accès à l'aide de Database Vault ou Virtual Private Database pour empêcher le DBA ou d'autres utilisateurs de voir les données, respectivement, et Transparent Data Encryption pour chiffrer les données au repos (système d'exploitation/fichier cryptage de niveau). Cela empêche non seulement le DBA de voir les données, mais également de les modifier ou de les supprimer.
Si vous souhaitez quand même chiffrer les valeurs de données, alors tout le chiffrement/déchiffrement et la gestion des clés doivent être gérés en externe de la base de données où le DBA n'aura pas accès aux clés de chiffrement. Le fonctionnement dépendra de la conception de votre application et du choix du ou des langages de programmation. Soyez conscient que la construction d'une architecture robuste de chiffrement et de gestion des clés n'est pas un exercice trivial...
Sachez également que l'encapsulation du code source PL/SQL n'est qu'un obscurcissement du code et non du cryptage. Cela peut être facilement inversée à l'aide de n'importe quel nombre de sites Web existants ou de procédures stockées internes. Un vrai DBA aurait également le droit d'execute any procedure privilège ou être en mesure de s'accorder l'autorisation explicite d'exécuter n'importe quelle fonction de déchiffrement sans même avoir à se soucier de la clé (seul Database Vault pourrait empêcher cela).
Transmettre la clé à la fonction en tant qu'entrée au lieu de l'intégrer directement dans le code serait également problématique, car le DBA peut voir votre SQL de plusieurs façons. Lorsqu'elle est transmise via une requête SQL, la clé peut également être exposée dans les rapports ADDM, les fichiers de trace de la base de données ou la piste d'audit.
Il n'y a non moyen sécurisé de gérer le chiffrement comme vous le décrivez avec PL/SQL qui protège également les données du DBA.
