Este artículo describe un método de enmascaramiento dinámico de datos (DDM) disponible para los sitios premium de IRI FieldShield que utiliza un sistema basado en proxy para interceptar consultas de aplicaciones a bases de datos conectadas a JDBC. Es uno de varios enfoques para enmascarar datos en vuelo que los usuarios de FieldShield pueden considerar.
Otras opciones de IRI DDM incluyen:Funciones FieldShield invocables por API integradas en programas C/C++/C#, Java o .NET; funciones FieldShield en tiempo real integradas en procedimientos SQL que crean vistas enmascaradas; y desenmascaramiento dinámico de tablas enmascaradas estáticamente para usuarios autorizados.
El sistema basado en proxy que se presenta aquí utiliza un controlador "JDBC SQL Trail" específico de la base de datos, adecuado para su propósito, junto con una aplicación web de configuración y administración llamada SQL Sharp (SQL#). Este diagrama muestra la arquitectura del sistema antes y después de la implementación:
Esta aplicación actualmente es compatible con las siguientes plataformas de bases de datos relacionales:
- Oráculo 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
y requiere los siguientes componentes de terceros:
- MS Windows 7,10 o Server 2012 y posterior (probado).
- Java JDK y JRE 1.8 o posterior.
- Tomcat 8.5 o superior para ejecutar el servidor web SQL#.
- Un navegador web moderno, como:
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
- Oracle o PostgreSQL como la base de datos del repositorio para almacenar:
- Configuración de usuarios y grupos de SQL#
- Acceso a la base de datos y controles de actividad
- Políticas dinámicas de enmascaramiento de datos
- Registros de auditoría de SQL
¿Cómo funciona?
Dentro de la aplicación web SQL#, crea políticas de enmascaramiento de datos para redactar los valores de las columnas en vuelo para todos los usuarios, excepto los autorizados, que se conectan a la base de datos a través del controlador JDBC SQL Trail. Debe instalar y configurar ese controlador para cada instancia de base de datos que desee proteger.
Las políticas de DDM definen qué tablas y columnas enmascarar y cómo aparecerán los valores enmascarados. Una vez que el sistema esté correctamente configurado, todas las consultas conectadas a través del controlador estarán sujetas a la política de enmascaramiento.
También es posible definir políticas para bloquear el inicio de sesión de los usuarios y ciertas actividades de SQL. Se produce un registro de auditoría de actividad SQL y de inicio de sesión completo, y se puede ver en SQL#.
El controlador no diferencia entre los usuarios de la aplicación con fines de bloqueo, enmascaramiento o auditoría. Sin embargo, puede autorizar a usuarios con un nombre específico, haciendo conexiones alternativas del servidor de aplicaciones a la base de datos a través del mismo controlador, para ver los datos desenmascarados.
Creación de una política de enmascaramiento
Para crear una política de enmascaramiento en SQL#, use la Política de enmascaramiento pestaña de la Gestión de ejecución de SQL# pantalla. Seleccione el + (Agregar) ícono a la derecha de la Lista de reglas de enmascaramiento etiqueta.
Asigne un nombre a la regla de enmascaramiento y una descripción opcional. A continuación, puede elegir el tipo de máscara que se aplicará desde Masing Regex: desplegable en Añadir regla de enmascaramiento diálogo.
Las primeras tres opciones están predefinidas, mientras que Regex le permite definir un formato de enmascaramiento personalizado. Haga clic en + (Agregar) ícono a la derecha de TAB/COL etiqueta para agregar una o más combinaciones de tablas y columnas, para especificar qué valores de datos se enmascararán.
Después de realizar cada combinación de tabla y columna, haga clic en Agregar en el medio del cuadro de diálogo para ponerlos en la lista. Cuando haya terminado de especificar las ubicaciones de las tablas y las columnas, haga clic en Agregar en la parte inferior para agregar las ubicaciones a Agregar regla de enmascaramiento diálogo.
Finalmente, haga clic en Guardar en la parte inferior de Agregar regla de enmascaramiento cuadro de diálogo cuando haya terminado con la regla de enmascaramiento. En este punto, todos los usuarios que estén configurados para acceder a los datos verán valores enmascarados cuando se conecten a través del controlador de proxy JDBC SQL Trail.
Para permitir que un usuario vea datos sin enmascarar, debe agregarlos a la Lista de usuarios sin enmascarar , como se describe a continuación.
Otorgamiento de autorización a los usuarios
Dentro de la misma Política de enmascaramiento pestaña de la Gestión de ejecución de SQL# pantalla. Haga clic en + (Agregar) ícono a la derecha de la Lista de usuarios sin máscara etiqueta. Esto mostrará el Buscar usuario cuadro de diálogo en el que puede seleccionar uno o más usuarios para los que no se ocultarán las consultas en las columnas y tablas seleccionadas.
Haga clic en Guardar en la parte inferior del cuadro de diálogo cuando haya terminado de seleccionar usuarios.
Uso de SQL# y SQL Trail desde aplicaciones de base de datos
En este ejemplo, nuestra aplicación de base de datos será IRI Workbench, el entorno de diseño de trabajos de front-end de Eclipse para Voracity, FieldShield y otros productos de software de IRI.
Para habilitar sus aplicaciones para el control SQL y el enmascaramiento dinámico de datos mediante el servidor proxy SQL# y el controlador JDBC SQL Trail, deberá activar SQL# a través de Tomcat y su servidor proxy. También debe configurar el controlador JDBC SQL Trail en la vista Explorador de fuentes de datos de IRI Workbench, así como las políticas de DDM en SQL# como se describe anteriormente.
Esta es una vista de la instancia de Oracle conectada a través del controlador JDBC SQL Trail.
Tenga en cuenta que todas las operaciones normales de la base de datos y los asistentes de trabajo de IRI seguirán funcionando a través de esta conexión. Eso también significa que se bloqueará cualquier actividad no autorizada de IRI Workbench, y todos los comandos SQL emitidos desde aquí a la base de datos conectada se registrarán en el registro de auditoría SQL#.
Esta es una consulta de Workbench en la tabla PEDIDOS que se configuró mediante políticas para DDM en SQL#:
frente a la misma consulta ejecutada por un usuario autorizado, que muestra los datos originales sin enmascarar:
Mientras tanto, en la sección de registro de la aplicación SQL#, puede ver nuestro registro de consulta:
de la dirección IP de IRI Workbench.
