De ingebouwde oplossing van Oracle voor dit probleem is geen versleuteling, maar toegangscontrole met behulp van Database Vault of Virtual Private Database om te voorkomen dat de DBA of andere gebruikers de gegevens kunnen zien, en Transparent Data Encryption om de gegevens in rust (OS/bestand encryptie op niveau). Dit voorkomt niet alleen dat de DBA de gegevens ziet, maar ook om deze te wijzigen of te verwijderen.
Als u de gegevenswaarden toch wilt versleutelen, moet alle versleuteling/ontsleuteling en sleutelbeheer extern worden afgehandeld uit de database waar de DBA geen toegang heeft tot de coderingssleutels. Hoe dat werkt, hangt af van het ontwerp van uw applicatie en de keuze van de programmeertalen. Houd er rekening mee dat het bouwen van een robuuste architectuur voor versleuteling en sleutelbeheer niet . is een triviale oefening...
Houd er ook rekening mee dat het inpakken van de PL/SQL-broncode slechts verduistering is van de code en niet encryptie. Het kan gemakkelijk ongedaan gemaakt met behulp van een willekeurig aantal bestaande websites of interne opgeslagen procedures. Een echte DBA zou ook de opdracht hebben om execute any procedure privilege of zichzelf expliciete toestemming kunnen geven om een decoderingsfunctie uit te voeren en niet eens te hoeven schelen wat de sleutel was (alleen Database Vault kon dit voorkomen).
Het verzenden van de sleutel naar de functie als invoer in plaats van deze rechtstreeks in de code in te sluiten, zou ook problematisch zijn, omdat de DBA uw SQL op een aantal manieren kan zien. Bij verzending via SQL-query kan de sleutel ook worden weergegeven in ADDM-rapporten, databasetraceerbestanden of de audittrail.
Er is geen veilige manier om de codering af te handelen zoals u beschrijft met PL/SQL die ook de gegevens beschermt tegen de DBA.