Oracles inbyggda lösning på detta problem är inte kryptering, utan åtkomstkontroll med hjälp av Database Vault eller Virtual Private Database för att förhindra DBA eller andra användare från att se respektive data, och Transparent Data Encryption för att kryptera data i vila (OS/fil). -nivå kryptering). Detta hindrar inte bara DBA från att se data, utan från att ändra eller ta bort det också.
Om du ändå vill kryptera datavärdena bör all kryptering/dekryptering och nyckelhantering hanteras externt från databasen där DBA inte kommer att ha tillgång till krypteringsnycklarna. Hur det fungerar beror på din applikationsdesign och val av programmeringsspråk. Tänk på att det inte är att bygga en robust krypterings- och nyckelhanteringsarkitektur en trivial övning...
Tänk också på att paketering av PL/SQL-källkod endast är obfuskation av koden och inte kryptering. Det kan vara lätt vända med valfritt antal befintliga webbplatser eller interna lagrade procedurer. En sann DBA skulle också ha execute any procedure privilegium eller kunna ge sig själva uttryckligt tillstånd att utföra valfri dekrypteringsfunktion och inte ens behöva bry sig om vad nyckeln var (endast Database Vault kunde förhindra detta).
Att överföra nyckeln till funktionen som en ingång istället för att bädda in den direkt i koden skulle också vara problematiskt, eftersom DBA kan se din SQL på hur många olika sätt som helst. När den överförs via SQL-fråga kan nyckeln också exponeras i ADDM-rapporter, databasspårningsfiler eller revisionsspåret.
Det finns ingen säkert sätt att hantera krypteringen som du beskriver med PL/SQL som också skyddar data från DBA.