Snowflake: Seguridad mediante una Política de Privacidad diferencial

Escrito por César Segura, Experto en la materia en SDG Group.

La Gobernanza del Dato en las plataformas actuales de datos es un concepto obligatorio que debemos tener en cuenta junto con otros elementos, una vez que has elegido las mejores funcionalidades y componentes para tu arquitectura, como la Ingesta, Transformación y Entrega de datos.

Dentro de la Gobernanza del Dato, hay un paso importante que es la Seguridad y Privacidad de los datos. En otras series de artículos sobre Seguridad, profundizo en la parte de la Capa de Accesibilidad, hablando sobre las diferentes capas. Pero en este artículo me centraré en una funcionalidad específica: una Política de Privacidad de Accesibilidad que ofrece Snowflake.

La Política de Privacidad Diferencial (DPP) se enfoca principalmente en añadir ruido a una tabla o vista que contiene información sensible de tipo PII (Información de Identificación Personal), de forma que los usuarios con acceso restringido puedan seguir consultando la información, pero sin poder recuperar datos sensibles. Solo podrán acceder a datos agregados con ciertas restricciones.

En este artículo abordaremos básicamente tres temas:

• ¿Cuál es el proceso para crear una DPP? Daremos una visión general de un proceso sencillo para crear una DPP.
• ¿Cómo funciona con ejemplos? Mostraremos, a través de un caso simple y algunos ejemplos, cómo una DPP funciona inyectando ruido a la información.
• ¿Por qué se llama Política de Privacidad Diferencial? Comprenderemos el motivo de este nombre, basándonos en los temas anteriores.

1. ¿Cuál es el proceso para crear una DPP?

Cuando deseas crear una DPP, debes definir en qué condiciones, cuando un rol intenta acceder a una tabla, se aplica o no una política. Cuando defines que se aplica, Snowflake, en la Capa de Servicio, asignará cargos a un presupuesto específico que se verá afectado. Ese presupuesto se generará automáticamente dentro de la DPP y se utilizará para limitar el uso que hace un rol específico sobre la tabla afectada. Podrás ampliar la capacidad de ese presupuesto en cuanto al número de consultas ejecutadas (Nbr_Agg), unidades (las unidades se consumen dependiendo de cada consulta y del nivel de ruido que sea necesario aplicar a la tabla) o la ventana de tiempo (semanal, mensual…). Los valores de presupuesto que se indican a continuación son los predeterminados, pero pueden modificarse en cualquier momento.

Un ejemplo de lo anterior podría ser el siguiente script de Snowflake:

CREATE OR REPLACE PRIVACY POLICY
security_db.policies_schema.customers_policy AS () RETURNS privacy_budget ->
CASE
   WHEN CURRENT_ROLE() = 'ACCOUNTADMIN' THEN no_privacy_policy()
   WHEN CURRENT_ROLE() IN ('ROLE_1')
     THEN privacy_budget(budget_name => 'Budget_1')
   WHEN CURRENT_ROLE() IN ('ROLE_2')
     THEN privacy_budget(budget_name => 'Budget_2')
   ELSE privacy_budget(budget_name => 'Budget_Rest')
END;

En el proceso de aplicar tu política a tu tabla, debes definir cuáles son los campos que identifican una entidad dentro de la información de tu tabla. Un ejemplo podría ser el siguiente:

 

Un ejemplo de lo anterior podría ser el siguiente script de Snowflake:

-- Assign the privacy policy to the CUSTOMERS_TABLE table.
ALTER TABLE dp_db.dp_schema.customers_table
ADD PRIVACY POLICY policy_db.diff_priv_policies.customers_policy
ENTITY KEY (id);

Después de esto, debes especificar los dominios de privacidad para los campos con los que deseas gestionar la información sensible; es decir, aquellos que pueden identificar, de forma individual o combinada, la identidad o información sensible. Estos dominios de privacidad permitirán inyectar información con ruido de forma significativa en cada consulta que se realice sobre los datos posteriormente.

ALTER TABLE dp_db.dp_schema.customers_table ALTER (
   COLUMN gender
       SET PRIVACY DOMAIN IN ('Female', 'Male'),
   COLUMN Address
       SET PRIVACY DOMAIN IN ('BCN', 'SAB', 'MAD', 'TAR'),
   COLUMN Birth_date
       SET PRIVACY DOMAIN
           BETWEEN (to_date('01/01/1954'), to_date('12/31/2007'))
);

2. ¿Cómo funciona con ejemplos?

Ahora, imagina el siguiente escenario donde diferentes roles (ADMIN y ROLE_1) quieren ejecutar la misma consulta sobre la tabla afectada por una DPP. En este ejemplo, utilizaremos la siguiente:

1. La consulta 1 es ejecutada por el rol ADMIN en el momento 0.
2. La capa de servicio verificará si la consulta está usando una tabla afectada por una DPP. En este caso, no está afectada por ninguna política porque no se ha aplicado ningún presupuesto; recuerda que al rol ADMIN no se le ha asignado ninguna política específicamente.
3. La inyección de ruido no se activa.
4. La consulta Q1 se ejecuta directamente sobre la tabla CUSTOMERS_TABLE, por lo que los resultados siempre serán deterministas.

5. Se devuelve al usuario con rol ADMIN el resultado de 1 fila.

    

    

   

1. La consulta 1 es ejecutada por el rol ROLE_1 en el momento 0.
2. La capa de servicio verificará si la consulta está utilizando una tabla afectada por una DPP. Está afectada por la política porque se cumple una condición: “ROLE_1 está intentando acceder a los datos”, por lo que el Budget_1 se verá afectado.
3. La inyección de ruido se activa en la tabla CUSTOMERS_TABLE, generando información subyacente que se podrá acceder posteriormente. Esto estará basado en los DOMINIOS DE PRIVACIDAD definidos previamente.
4. El Budget_1 disminuirá su saldo en ambos casos: el contador de consultas agregadas (Nbr_agg) se reducirá en uno y, además, las unidades necesarias para aplicar ruido a la información subyacente aumentarán el gasto acumulado de unidades (en este caso se han consumido +3,6 unidades).
   El límite máximo se alcanzará cuando se llegue al límite de unidades.
   Si usas la siguiente consulta con ESTIMATE_REMAINING_DP_AGGREGATES, podrás ver una estimación de la capacidad actual de tu presupuesto:
   
   
   
   

5. La consulta Q1 se ejecuta a través de la información subyacente con ruido generada a partir de CUSTOMERS_TABLE, por lo que los resultados siempre serán NO deterministas. Cada vez que el rol ROLE_1 ejecute la consulta Q1, se generará nueva información subyacente con ruido

6. Se devuelve al usuario con rol ROLE_1 un resultado de “3”.

    

   Case 3 — ROLE_1 role executes Q1 query AGAIN later:

1. La consulta 1 es ejecutada por el rol ROLE_1 en el tiempo 1 (después de la última ejecución).
   
2. La capa de servicio verificará si la consulta está usando una tabla afectada por una DPP. Está afectada por la política debido a que se cumple una condición: “ROLE_1 está intentando acceder a los datos”, por lo que el Budget_1 se verá afectado.
3. La inyección de ruido se activa en la tabla CUSTOMERS_TABLE, generando información subyacente que podrá ser accedida posteriormente. Esto se basa en los DOMINIOS DE PRIVACIDAD definidos anteriormente.
4. El Budget_1 reducirá su saldo en ambos casos: el contador de consultas agregadas (Nbr_agg) se reducirá en uno y, además, las unidades necesarias para aplicar ruido a la información subyacente aumentarán el gasto acumulado de unidades hasta 4.2 (en este caso, se han usado +0.6 unidades, sumadas a las 3.6 acumuladas previamente). El límite máximo aún no se ha alcanzado, ya que el límite de unidades es 233.
5. La consulta Q1 se ejecuta a través de la información subyacente con ruido generada a partir de CUSTOMERS_TABLE, por lo que los resultados siempre serán NO deterministas. Cada vez que el rol ROLE_1 ejecute Q1, se generará nueva información subyacente con ruido.

6. Se devuelve al usuario con rol ROLE_1 un resultado de “5”.

    

    3. ¿Por qué se llama Política de Privacidad Diferencial?

Se basa en que, cuando ejecutas tu consulta, el resultado no será determinista si te afecta una DPP. En ese caso, se aplicará ruido a tus datos, afectando los resultados cada vez que consultes. Las diferencias respecto al valor correcto (el determinista) dan nombre a esta política de seguridad.

Por eso, puedes usar las funciones DP_INTERVAL_LOW y DP_INTERVAL_HIGH para determinar los márgenes diferenciales aplicados al resultado de la consulta, con un 95% de confianza.

Conclusiones