Simulando Virtual Private Databases

-
Oracle tiene una característica de seguridad llamada Virtual Private Databases (VPDs) que viene incluida como parte del paquete Oracle Avanced Security. Las Virtual Private Databases permiten a los administradores de la base de datos crear procedimientos almacenados que de forma automática agregan una cláusula where a una consulta.

Por poner un ejemplo, si un usuario inicia sesión en una Virtual Private Databases con cualquier herramienta cliente que le permita el acceso y ejecuta la consulta SELECT * FROM DIVISA_CAMBIO podrá obtener resultados completamente distintos a los de otro usuario que haya accedido. Es decir, podríamos limitar el acceso a la tabla para que cada usuario únicamente pueda ver los cambios de divisa de su continente o zona de países.

En el resto de bases de datos, aunque esta funcionalidad no esta implementada, podremos simularla en base a vistas sobre la tabla a consultar y el usuario de conexión.

 Por ejemplo:

  • Empezamos creando la tabla de permisos. En esta tabla indicaremos los usuarios de base de datos y el filtro o filtros que serán aplicados en la vista final.
         CREATE TABLE USERS_FILTERS
           (USER          VARCHAR(50),
            USER_DESC     VARCHAR(255),
            FILTER_1      VARCHAR(5),
            FILTER_2      VARCHAR(5));

  • En esta tabla insertamos dos usuarios y aplicamos los filtros a los que tienen permiso sobre la vista final. Estos usuarios deberán estar dados de alta en la base de datos con los permisos oportunos:
         INSERT INTO USER_FILTERS (USER, USER_DESC, FILTER_1, FILTER_2) 
                 VALUES ('usurioroot', 'usuario root', '00001', '20000');
         INSERT INTO USER_FILTERS (USER, USER_DESC, FILTER_1, FILTER_2) 
                 VALUES ('usuriopub', 'usuario pub', '00002', '30000');

  • Supongamos ahora que en nuestra tabla de origen llamada DATOS_ORIGEN tenemos la siguiente información:

id_key   id_pais    desc_pais    id_empresa   des_empresa  ingresos
---------------------------------------------------------------------
1         00001     España       20000        Sua.SL         24.500
2         00001     España       30000        Fax.SA         44.000
3         00002     Portugal     30000        Trans.SA       14.000


  • Creamos ahora la vista a la cual accederán los usuarios:
CREATE VIEW VISTA_DATOS_ORIGEN (ID_PAIS, DESC_PAIS, INGRESOS) AS
SELECT ID_PAIS, DESC_PAIS, SUM(INGRESOS)
 FROM DATOS_ORIGEN O
 INNER JOIN USER_FILTERS  F ON
              F.FILTER_01=ID_PAIS   AND
              F.FILTER_02=ID_EMPRESA AND
              F.USER = USER       <--- USUARIO DE BBDD
 GROUP BY ID_PAIS, DESC_PAIS;


Ahora, si hacemos una prueba, entrenado con un usuario y otro (usurioroot o usuriopub) y ejecutando la consulta SELECT * FROM VISTA_DATOS_ORIGEN nos devolverá unos resultados u otros.

La base de las VPDs es esta, ahora experimentad vosotros y buscadle utilidad....


Comentarios

Anónimo ha dicho que…
Muy buena aportación
16 de abril de 2013, 7:15
Publicar un comentario

Entradas populares de este blog

-
Imagen
OPTIMIZACIÓN DE MODELOS SSAS TABULAR MODEL 1          Objetivos Los Modelos Tabulares son bases de datos de Analysis Services que se ejecutan en memoria (In-Memory) o en el modo DirectQuery, de tal forma que se accede a los datos directamente desde los orígenes de datos relacionales de back-end. Gracias a los algoritmos de compresión avanzados y al procesador de consultas multiproceso, el motor analítico In-Memory ofrece un acceso rápido a los objetos y los datos de los modelos tabulares para aplicaciones cliente de informes como Microsoft Excel, Microsoft Power View o Microsoft Power BI. DirectQuery es un modo de consulta alternativo para los modelos que son demasiado grandes para caber en la memoria o cuando la volatilidad de los datos impide una estrategia de procesamiento razonable. En esta versión, DirectQuery logra una paridad mayor con modelos en memoria mediante la compatibilidad con orígenes de datos adicionales, la ...
Leer más
-
smtp.office365.com El límite de la tasa de mensajes para Office 365 es 10.000 por día y/o de 30 mensajes por minuto. Si infringe el límite, el servidor saliente no se detendrá, pero el mensaje le devolverá con un NDR. Cuando está por debajo del límite, puede volver a enviar el mensaje. No se recomienda que romper el límite   debido a que su cuenta puede ser finalmente bloqueada por EOP   si con frecuencia supera el límite (se consideran spam).  Estos límites se aplican tanto a los mensajes de correo electrónico enviados dentro de una organización como a los enviados a organizaciones externas. La mejor manera de evitar exceder el límite de velocidad del destinatario es usar grupos de distribución al enviar mensajes a un gran número de destinatarios. Los grupos de distribución almacenados en la libreta de direcciones compartida se cuentan como un único destinatario hacia el límite de tasa de destinatario. Para obtener más información, vea Estrategias para admit...
Leer más

Uso de la función RANKX (DAX)

-
Imagen
La función RANKX devuelve la clasificación de un número (ranking) en una lista de números para cada fila de la tabla. Supongamos que tenemos en nuestro modelo una tabla compuesta por los distintos departamentos o tiendas de nuestra empresa y las ventas contables de cada departamento (FACT_VENTAS_CONTABLES): Para añadir un indicador, por ejemplo, de Ranking de ventas contables hacemos lo siguiente: Creamos un indicador que sea el sumatorio del total de ventas de la tabla:   TOTAL_IMPORTE_VENTAS_CONTABLES:=SUM([IMPORTE_VENTAS_CONTABLES]) Creamos el indicador de Ranking con la función RANKX:    Ranking Ventas Departamento (Ventas         Contables):=IF(NOT(ISBLANK([TOTAL_IMPORTE_VENTAS_CONTABLES])); RANKX(FILTER(ALL(FACT_VENTAS_CONTABLES);[TOTAL_IMPORTE_VENTAS_CONTABLES]);[TOTAL_IMPORTE_VENTAS_CONTABLES];;;DENSE);BLANK()) La función DAX para obtener el ranking la complicamos un poco más atendiendo al criterio de que no mu...
Leer más