Establecimiento de políticas de seguridad mediante Oracle Virtual Private Database

La base de datos privada virtual de Oracle es un método dinámico para controlar el acceso a la base de datos que requiere el establecimiento de políticas de seguridad. Pero preste atención a la gestión y la auditoría.

En entregas anteriores de esta serie sobre seguridad de Oracle, examinamos Oracle Grant Security y Grant Execution Security y señalamos las ventajas y desventajas de cada enfoque. Ahora veamos otra alternativa de seguridad de Oracle, la base de datos privada virtual (VPD).

¿Te faltan partes de la serie?

Infórmate sobre estos artículos:
«Oracle diseña la seguridad desde cero»
«Control de acceso con Oracle Authorization Security»
«Uso del modelo de seguridad de cumplimiento autorizado de Oracle para un mejor control»

Las bases de datos privadas virtuales tienen varios otros nombres en la documentación de Oracle, incluida la seguridad de nivel de fila (RLS) y el control de acceso detallado (FGAC). Independientemente del nombre, la seguridad VPD proporciona una nueva forma de controlar el acceso a los datos de Oracle. Lo más interesante es la naturaleza dinámica de VPD. En tiempo de ejecución, Oracle realiza estas proezas casi mágicas al modificar dinámicamente las declaraciones SQL del usuario final:

1. Oracle recopila información de contexto de la aplicación cuando un usuario inicia sesión y luego llama a una función de política que devuelve un predicado. Un predicado es una cláusula where que califica un conjunto específico de filas en una tabla.
2. Oracle reescribe las consultas dinámicamente agregando predicados a la declaración SQL del usuario.

Cada vez que se ejecuta una consulta en la tabla de destino, Oracle invoca esta estrategia y genera una vista temporal con los predicados de la cláusula where pegados al final de la consulta de la siguiente manera:
Seleccione *P1 del libro

El modelo de seguridad VPD utiliza el paquete Oracle dbms_rls (RLS significa seguridad de nivel de fila) para hacer cumplir la política de seguridad y el contexto de la aplicación. Esto requiere definir una política para controlar el acceso a tablas y filas (Figura A).

Figura A

El VPD participa en la creación de políticas de seguridad y cuando los usuarios acceden a tablas (o vistas) que tienen políticas de seguridad. La política de seguridad modifica el SQL del usuario, agregando cláusulas where para restringir el acceso a filas específicas en la tabla de destino. Echemos un vistazo más de cerca a cómo funciona.

contexto de aplicación
Para que VPD utilice correctamente la política de seguridad para agregar cláusulas where al SQL del usuario final, Oracle debe conocer los detalles sobre los permisos de los usuarios. Esto se hace al iniciar sesión usando el paquete dbms_session de Oracle. Al iniciar sesión, el activador de inicio de sesión de la base de datos se ejecuta para establecer el contexto de la aplicación para el usuario llamando a dbms_session.set_context. El procedimiento set_context se puede utilizar para establecer cualquier cantidad de variables sobre el usuario final, incluido el nombre de la aplicación, el nombre de usuario y la información específica del límite de filas. Una vez que se recopilan estos datos, la política de seguridad usará esta información para construir una cláusula where de tiempo de ejecución para agregar a la declaración SQL del usuario final. El procedimiento set_context establece varios parámetros utilizados por VPD y acepta tres parámetros:
dbms_session.set_context(espacio de nombres, atributo, valor)

Por ejemplo, supongamos que tenemos una tabla de publicación y queremos restringir el acceso según el tipo de usuario final. Los administradores podrán ver todos los libros de su editorial, mientras que los autores solo podrán ver sus propios libros. Supongamos que el usuario JSMITH es el administrador y el usuario MAULT es el autor. Al iniciar sesión, el disparador de inicio de sesión de la base de datos de Oracle generará los valores apropiados y ejecutará la instrucción que se muestra en el Listado A.

Después de la ejecución, podemos ver estos valores usando la vista Oracle session_context. VPD utilizará estos datos en tiempo de ejecución para generar cláusulas where. Tenga en cuenta que cada usuario tiene su propio valor de session_context específico, como se muestra en el Listado B.

Ahora veamos cómo la política de seguridad de VPD usa esta información de contexto de la aplicación. En el Listado C, creamos una función de política de seguridad llamada book_access_policy que crea dos tipos de cláusulas where basadas en la información del contexto_sesión de cada usuario final. Tenga en cuenta que Oracle utiliza la función sys_context para recopilar valores.

Mire de cerca el código en el Listado C. Si los usuarios se definieran como administradores, su cláusula where (d_predicate) sería:
donde on(empresa) = ‘RAMPANT_TECHPRESS’;

Para los autores, obtienen una cláusula where diferente:
donde superior(nombre del autor) = ‘MAULT’;

DPV en acción
Ya estamos listos para presentar nuestro VPD. En el Listado D, vemos resultados muy diferentes de la misma consulta SQL, según el contexto de la aplicación del usuario final específico.

Claramente, VPD es una forma completamente diferente de administrar el acceso a Oracle que los mecanismos de seguridad basados ​​en autorización. VPD tiene muchos beneficios:

• Seguridad dinámica: no es necesario mantener funciones y autorizaciones complejas.
• Seguridad múltiple: puede colocar varias políticas en cada objeto o superponerlas sobre otras políticas base. Esto hace que VPD sea ideal para aplicaciones web implementadas por muchas empresas.
• Sin puertas traseras: los usuarios ya no eluden las políticas de seguridad integradas en las aplicaciones porque las políticas de seguridad están adjuntas a los datos.
• Se pueden definir reglas de acceso complejas: con VPD, puede usar valores de datos para especificar reglas de acceso complejas que son difíciles de crear de forma segura con autorización. Puede restringir fácilmente el acceso a las filas.

Por supuesto, la seguridad VPD también tiene algunos inconvenientes:

• Difícil seguridad a nivel de columna: debido a que el acceso se controla agregando cláusulas where, el acceso a nivel de columna solo se puede mantener definiendo varias vistas para cada tipo de usuario final.
• Cada usuario requiere una ID de Oracle: a diferencia de la seguridad administrada externamente, VPD requiere que se defina una ID de usuario de Oracle para cada persona que se conecte a la base de datos. Esto aumenta el mantenimiento y los gastos generales.
• Difícil de auditar: es difícil escribir un script de auditoría que defina los derechos de acceso exactos de cada usuario designado. El problema se vuelve aún más agudo para las tiendas con enfoques de seguridad mixtos.

Problemas con VPD híbrido y seguridad de autorización
Ahora que hemos establecido el campo de la seguridad y la auditoría, debe quedar claro que tenemos que idear una manera de garantizar que los enfoques de seguridad no se mezclen de manera inapropiada. Cada uno de estos mecanismos de seguridad proporciona una protección de acceso adecuada por sí solo, pero cuando estos enfoques se combinan, a menudo es difícil, si no imposible, identificar los derechos de acceso de un usuario individual. Debe decidir si los beneficios de seguridad de VPD valen el enfoque de administración adicional.

Siguiente en la serie:

Revisamos la seguridad de autorización, la seguridad de aplicación de autorización y la seguridad de VPD. Ahora estamos listos para explorar la auditoría para la seguridad de Oracle. Oracle proporciona una variedad de métodos de auditoría, incluidos Oracle DDL y Server Error Triggers, Oracle Audit SQL Commands y Oracle’s Fine-Grained Auditing Facility.

o