Enmascaramiento dinámico de datos mediante cifrado

Este tutorial proporciona instrucciones sobre cómo configurar y utilizar el enmascaramiento dinámico de datos mediante cifrado en Netezza Performance Server.

El enmascaramiento dinámico de datos ayuda a evitar el acceso no autorizado a datos confidenciales de objetos de base de datos, como campos o columnas de tablas, ocultándolos a usuarios sin privilegios. Las reglas de enmascaramiento sólo se aplican en los resultados de la consulta y los datos de la base de datos no se ven afectados, por lo que pueden ser utilizados por otras aplicaciones que necesiten acceder a estos datos.

Acerca de esta tarea

En este tutorial se utiliza el siguiente esquema de ejemplo:

Esquema utilizado en esta tarea

Las columnas " customer_name " y " customer_address " son las columnas sensibles que deben enmascararse y cifrarse. De todos los usuarios que pueden acceder a estas tablas (es decir, que tienen el privilegio " SELECT ") sólo los que tienen el rol " ACCOUNTS " pueden ver las dos columnas sensibles. Para los demás usuarios, estos valores se enmascaran mediante encriptación.

La forma estándar de hacerlo es restringir el acceso a las tablas subyacentes y superponer vistas a las tablas que cambien los valores en función de la función del usuario. Para ello, primero cambie el nombre de la tabla subyacente y, a continuación, cree una vista, utilizando el nombre original de la tabla, que proyecte valores cifrados para las columnas sensibles en función de los roles que tengan acceso.

Procedimiento

  1. Definir la clave de cifrado:

    Se trata de un paso único.

    Configure una clave de encriptación que se utilizará para el enmascaramiento mediante la creación de una tabla separada a la que sólo los administradores tienen privilegio y acceso. Como administrador de la base de datos:
    create table encryption_keys (key varchar(30)); 
insert into encryption_keys values('<your key value goes here>');
  2. Prepare la tabla base cambiándole el nombre y, a continuación, cree una vista de enmascaramiento sobre ella.
    Como administrador de la base de datos:
    alter table customers rename to customers_table;
create or replace view customers as
select
customer_id,
case when current_role = 'ACCOUNTS' then customer_name
else encrypt(customer_name, (select encryption_keys.key)) end as customer_name,
case when current_role = 'ACCOUNTS' then customer_address
else encrypt(customer_address, (select encryption_keys.key)) end as customer_address,
customer_state,
customer_zip
from customers_table;
    Consejo: En lugar de enmascarar los datos mediante encriptación, puede utilizar el mismo procedimiento para enmascararlos u ocultarlos por completo:
    
CREATE VIEW customers AS 
SELECT customer_id, 
       CASE WHEN current_role = 'ACCOUNTS' THEN customer_name 
            ELSE '*****' -- this could be NULL if the column was not (VAR)CHAR
       END AS customer_name,
       CASE WHEN current_role = 'ACCOUNTS' THEN customer_address
            ELSE '*****'
       END AS customer_address,
       customer_state,
       customer_zip
FROM "$customers_base";
    Sin embargo, la ventaja de enmascarar utilizando cifrado es que, si es necesario, puedes, por ejemplo, unir la columna cifrada de esta tabla a la columna cifrada de otra tabla y seguir manteniendo la relación entre las filas. Esto no sería posible si la columna estuviera simplemente enmascarada o tratada como NULL.
  3. Concede el rol ' ACCOUNTS ' a los usuarios seleccionados.

    En este paso, se concede a un subconjunto de usuarios el privilegio de asumir el rol " ACCOUNTS. Por ejemplo, en un grupo de usuarios ' alice, ' bob, y ' clark, sólo ' alice y ' bob necesitan el privilegio al rol ' ACCOUNTS.

    create role accounts;
grant list on accounts to alice, bob;
    A continuación, conceda el privilegio de ejecutar consultas contra clientes (la vista enmascarada) y pedidos (la tabla).
    grant select on  customers, orders  to  public, accounts;

    En este punto, el enmascaramiento dinámico está configurado y listo para su uso.

Resultados

Supongamos que el usuario " alice " necesita un informe del total de " order_amount, desglosado por el código de estado:
select
sum(order_amount) as total,
customer_state
from customers inner join orders using (customer_id)
group by customer_state;
TOTAL ESTADO_DEL_CLIENTE
10750.01 NY
2000.00 EI
99.99 XX

Alice puede acceder a CLIENTES (la vista enmascarada). La columna ' customer_id ' no está encriptada, y se utiliza para unir contra la tabla ORDERS. La columna " customer_state " no está codificada y se utiliza para hacer el roll-up (por estado). Pero " customer_name y " customer_address " son sensibles. Si decide verlos, están encriptados:

select * from customers order by customer_id;
CUSTOMER_ID NOMBRE_CLIENTE DIRECCIÓN_CLIENTE ESTADO_DEL_CLIENTE CUSTOMER_ZIP
10031 &J.&#+RXV /U/%9$,1WZJ\*?<1L3- EI 90210
21451 INR0-F50_0 1U*"\(7H"V;3S%NH0]!= ['T NY 55555
43918 I_*$)VM0X0 0U+;!="XWV;#T&^Y#F#=8[ NY 98765
60844 M>6%(7Q0Y@ -T+#!9$@9T+#T6L(5L0 NY 55554
80008 H>F0*F]0Y@ 1L>B4*7<#U:WN&Z,JISI7YS< XX 0
Si Alice necesita acceder a las columnas no encriptadas, se le ha concedido el privilegio de asumir el rol ' ACCOUNTS que le permite ver los datos fuente no encriptados:
set role accounts;
select * from customers order by customer_id;
CUSTOMER_ID NOMBRE_CLIENTE DIRECCIÓN_CLIENTE ESTADO_DEL_CLIENTE CUSTOMER_ZIP
10031 Mark F 234 Main Street EI 90210
21451 Clark K 1 Avenida Metrópolis NY 55555
43918 Bruce W 1600 Gotham Lane NY 98765
60844 Pedro P 500 Fifth Ave. NY 55554
80008 Diana P Isla de Themyscira XX 0