La solución integrada de Oracle para este problema no es el cifrado, sino el control de acceso mediante Database Vault o Virtual Private Database para evitar que el DBA u otros usuarios vean los datos, respectivamente, y el cifrado de datos transparente para cifrar los datos en reposo (sistema operativo/archivo). -nivel de cifrado). Esto no solo evita que el DBA vea los datos, sino que también los modifique o elimine.
Si desea cifrar los valores de los datos de todos modos, entonces todo el cifrado/descifrado y la administración de claves deben manejarse externamente. de la base de datos donde el DBA no tendrá acceso a las claves de cifrado. La forma en que funcione dependerá del diseño de su aplicación y la elección de los lenguajes de programación. Tenga en cuenta que construir una arquitectura robusta de encriptación y administración de claves no un ejercicio trivial...
También tenga en cuenta que envolver el código fuente PL/SQL es solo ofuscación del código y no del cifrado. Puede ser fácilmente revertido usando cualquier número de sitios web existentes o procedimientos almacenados internos. Un verdadero DBA también tendría que execute any procedure privilegio o poder otorgarse permiso explícito para ejecutar cualquier función de descifrado y ni siquiera tener que preocuparse por cuál era la clave (solo Database Vault podría evitar esto).
Transmitir la clave a la función como una entrada en lugar de incrustarla directamente en el código también sería problemático, ya que el DBA puede ver su SQL de varias maneras. Cuando se transmite a través de una consulta SQL, la clave también podría estar expuesta en los informes de ADDM, los archivos de seguimiento de la base de datos o la pista de auditoría.
No hay no forma segura de manejar el cifrado como lo describe con PL/SQL que también protege los datos del DBA.
