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:

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:
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.
Un ejemplo de lo anterior podría ser el siguiente script de Snowflake:
-- Define privacy domains on CUSTOMERS_TABLE table fields
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:
Se devuelve al usuario con rol ADMIN el resultado de 1 fila.
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
Se devuelve al usuario con rol ROLE_1 un resultado de “3”.
Se devuelve al usuario con rol ROLE_1 un resultado de “5”.
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.
Un ejemplo de uso con una consulta:
Conclusiones
La política DPP es una de las políticas de privacidad más complejas de entender. Muchas personas me han preguntado sobre ella, y pensé que sería una buena idea escribir este artículo para ayudar a los miembros de Snowflake a comprenderla de manera clara, con una visión fácil y rápida.
Debemos tener en cuenta que este tipo de política es muy útil en entornos donde se comparte información sensible y se quiere restringir fuertemente el uso de estos datos. Snowflake cuenta con una lista completa de otras políticas, por lo que es importante comprender bien tu caso de uso antes de aplicar esta u otras funcionalidades.
Artículo original publicado en Medium aquí.