Nuestras 7 mejores prácticas de RBAC en Snowflake

Al crear y trabajar en tu modelo de acceso y asignar permisos a distintos usuarios de tu empresa, el objetivo debe ser una estructura donde los usuarios tengan exactamente los permisos que necesitan (ni más, ni menos) para hacer su trabajo. ¿Por qué el nuevo Analista Junior de Finanzas tendría permiso para eliminar tablas si solo necesita consultar una tabla de balances?

Esto se conoce como el Principio de Mínimo Privilegio, y al aplicarlo a tu modelo de acceso en Snowflake se obtienen varios beneficios:

• Se reduce el riesgo y el impacto de amenazas externas: al restringir el acceso de los usuarios a lo estrictamente necesario, disminuye el riesgo de filtraciones accidentales o maliciosas. Y si llegara a ocurrir una filtración, el daño queda acotado a las áreas de la base de datos a las que pueden acceder las cuentas comprometidas.
• Se minimiza el riesgo de corrupción del sistema y aumenta la estabilidad: limitar el acceso ayuda a prevenir cambios que puedan afectar la integridad o estabilidad de los datos. Los miembros del equipo con exposición limitada no deberían tener permiso para eliminar bases de datos. :)
• Se facilita la auditoría y el monitoreo: mantener solo los privilegios mínimos también significa menos privilegios que monitorear y mantener.
• Se simplifica el cumplimiento normativo: este principio también ayuda a cumplir con requisitos regulatorios de protección de datos —cuando corresponda—, como GDPR o HIPAA, al limitar el acceso a datos sensibles a lo estrictamente necesario.

El Principio de Mínimo Privilegio es una buena forma de arrancar, ya que ofrece un buen equilibrio entre seguridad y mantenimiento. Algunas empresas optan por modelos de seguridad más simplificados, a costa de mayores riesgos, mientras que otras adoptan prácticas más estrictas. Vale la pena investigar el modelo de seguridad Zero-Trust y cómo se relaciona con el Principio de Mínimo Privilegio.

En nuestro artículo anterior mencionamos distintos tipos de roles: account roles, database roles e incluso instance roles. Entre ellos hay diferencias técnicas y conceptuales importantes. Para simplificar, en este artículo nos quedamos con los Account Roles.

Ahora vamos a ver un enfoque distinto para definir roles: según su propósito. Hay 3 tipos de roles que queremos presentar:

• Los Access Roles se usan para controlar el acceso a tus bases de datos.
• Los Functional Roles se otorgan a los usuarios de Snowflake de tu empresa, y los niveles de acceso se controlan otorgándoles los Access Roles necesarios (según el Principio de Mínimo Privilegio).
• Los Service Roles funcionan exactamente igual que los Functional Roles, con la única diferencia de que están destinados a Servicios y no a usuarios finales (humanos).

Ten en cuenta que no hay diferencia técnica entre Access, Functional y Service Roles. Todos se crean como Account Roles.

Access Roles

Los Access Roles se crean para garantizar distintos niveles de acceso a las bases de datos y a sus objetos. Puedes verlos como los bloques básicos de bajo nivel de tu jerarquía.

Una forma sencilla de crear Access Roles es usar roles READ y READWRITE para cada base de datos existente:

• READ: otorga privilegios SELECT sobre todas las tablas/vistas de la base de datos.
• READWRITE: otorga operaciones SELECT, INSERT, UPDATE y DELETE.

Es un buen punto de partida, pero según las necesidades de tu empresa puedes crear Access Roles más granulares (por ejemplo, para acceder a esquemas específicos dentro de una base de datos).

Functional Roles

Los Functional Roles se diseñan para estar alineados con las funciones del negocio, y combinan distintos Access Roles que se les otorgan. Por ejemplo, un rol DATA_ANALYST podría heredar los privilegios de los Access Roles READ\* * creados para algunas bases de datos. En cambio, un rol DATA_ENGINEER podría heredar los READWRITE de esas mismas bases de datos.

Estos son los roles que se otorgan a los usuarios finales. Puedes armarlos según las necesidades reales, usando los Access Roles como bloques de construcción (y teniendo siempre presente el Principio de Mínimo Privilegio).

Service Roles

Este tipo de rol es esencialmente igual a un Functional Role, pero en lugar de otorgarse a usuarios de tu empresa, se asigna a Service Accounts. Estas cuentas las usan herramientas de terceros, como plataformas de BI y dashboards, o cualquier otro SaaS que requiera acceso READ o READWRITE a objetos de base de datos en Snowflake (por ejemplo, Airbyte, Rudderstack, Mode).

Igual que con los Functional Roles, puedes armar los Service Roles según las necesidades reales, usando los Access Roles como bloques de construcción y teniendo siempre presente el Principio de Mínimo Privilegio.

Con estos 3 tipos de roles tienes los bloques necesarios para crear una jerarquía de roles de acceso simple y efectiva.

Uno de los principios clave del desarrollo de software es evitar la repetición de código; el acrónimo D.R.Y. significa "Don't Repeat Yourself" (no te repitas). Con los Access, Functional y Service Roles puedes empezar a esbozar cómo se verá tu jerarquía de roles. Puedes seguir estos 4 pasos para iterar.

1. Define los Functional Roles y Service Roles que necesita tu empresa

Reúne los requisitos de los distintos usuarios de Snowflake de tu empresa y haz una lista de los Functional Roles que necesitas, junto con los niveles de acceso requeridos. Esta lista te permitirá luego esbozar los Access Roles que necesitarás.

2. Crea los Access Roles

Una vez completa tu lista de requisitos, podrás visualizar los Access Roles necesarios. Ya puedes crearlos y otorgarles los privilegios correspondientes sobre los objetos de la base de datos (por ejemplo, FINANCE_DB_READ_ROLE).

3. Crea los Functional Roles y Service Roles (y otórgales los Access Roles)

Con los Access Roles ya creados, tienes todo lo necesario para construir los Functional Roles para tus colegas, así como los Service Roles que usarán los servicios. Para cumplir con los requisitos definidos al inicio, otorga los Access Roles a los Functional/Service Roles que acabas de crear (por ejemplo, DATA_ANALYST).

4. Otorga los Functional Roles a los usuarios y los Service Roles a las Service Accounts

¡Tu jerarquía de roles ya está completa! El último paso es otorgar los Functional Roles a los usuarios de Snowflake y los Service Roles a las Service Accounts. Si hace falta algún ajuste, basta con repetir los pasos 1 a 4.

Lo que no debes hacer…

⛔ No otorgues Access Roles directamente a usuarios finales o Service Accounts

Si te saltas la capa de Functional Roles y otorgas un conjunto de Access Roles directamente a un usuario, terminarás haciendo lo mismo cada vez que se incorpore alguien con responsabilidades similares. Además, ante cualquier ajuste, tendrás que repetirlo manualmente para varios usuarios.

Tener un Functional Role significa que hay un único lugar donde hacer ajustes. Esos cambios se aplican a todos los usuarios que tengan ese Functional Role específico. La capa de Access Roles existe para estandarizar el acceso a los objetos de base de datos en toda tu cuenta; ¡no para usarse directamente!

⛔ No otorgues Functional Roles a otros Functional Roles

¡Mantenlo simple! Cada Functional Role debe ser una composición de Access Roles. Introducir dependencias puede complicar las cosas, sobre todo a medida que tu empresa crece y los puestos evolucionan con el tiempo.

¿Creaste Access Roles para una base de datos, pero se siguen agregando nuevos esquemas y tablas, y terminas actualizando sus privilegios constantemente? ¡Entonces este consejo es para ti! Puedes otorgar privilegios sobre futuros esquemas de una base de datos, así como sobre futuras tablas, vistas u otros objetos. Así, cada vez que se cree un objeto nuevo, el grant se aplica automáticamente.

Usar future grants al crear los Access Roles te ayuda a minimizar las tareas de mantenimiento, asegurando que tus roles tengan los privilegios adecuados cuando aparezcan nuevos objetos de base de datos. ¡Ya no hay que ejecutar nuevas sentencias grant cada vez que se agreguen objetos a tu base de datos!

Cuando se crea un rol personalizado por primera vez, existe de forma aislada, y lo mismo aplica a cualquier objeto que cree ese rol. Por defecto, ni siquiera el rol ACCOUNTADMIN puede modificar o eliminar objetos creados por un rol personalizado. Así que cuando un rol no tiene padre, corres el riesgo de crear objetos en tu cuenta a los que solo ese rol podrá acceder.

Al otorgar un rol personalizado a SYSADMIN, te aseguras de que al menos los roles SYSADMIN (y ACCOUNTADMIN) puedan gestionar los objetos creados por ese rol.

Para cerrar, adopta la buena práctica de otorgar tus Functional Roles a SYSADMIN por defecto.

Snowsight cuenta con una excelente funcionalidad para mostrar la jerarquía de roles existente en la cuenta de Snowflake. Puedes usarla para visualizar los roles que creas y cómo se conectan entre sí.

Busca la opción Graph dentro de Users & Roles. Luego puedes usar la opción Focus para observar un rol específico y sus roles padre/hijo.

O dicho de otra forma, usa los roles adecuados para cada operación administrativa que realices. ¡Recuerda el Principio de Mínimo Privilegio!

El rol ACCOUNTADMIN tiene por defecto muchos más privilegios de los que necesitas para tus operaciones del día a día, así que conviene evitarlo salvo que haya un buen motivo. Esto es lo que puedes usar en su lugar para operaciones comunes:

• Si necesitas crear usuarios o roles, ¡usa USERADMIN!
• Si necesitas gestionar grants (por ejemplo, otorgar un rol a un usuario), ¡usa SECURITYADMIN!
• Si necesitas crear objetos como bases de datos, esquemas o virtual warehouses, ¡usa SYSADMIN!
• Si necesitas crear bases de datos u objetos de base de datos como tablas, vistas o cualquier otro, ¡puedes usar SYSADMIN!
• Si quieres realizar operaciones ad-hoc sobre los datos de una tabla (como un SELECT o un INSERT), ¡usa un Functional Role adecuado!
• Por último, si vas a conectar un servicio de terceros a Snowflake, ¡bajo ningún motivo uses ACCOUNTADMIN! En su lugar, crea y usa un Service Role adecuado :)

Por ejemplo, el paquete SELECT dbt-snowflake-monitoring requiere un privilegio especial IMPORTED PRIVILEGES sobre la base de datos SNOWFLAKE, que solo puede otorgar el rol ACCOUNTADMIN. En este caso, usa USERADMIN para crear un Access Role para ese único privilegio, otorga el privilegio con ACCOUNTADMIN y usa SECURITYADMIN para otorgar el Access Role a un Service Role para dbt.

Contexto

Eres Data Engineer en un equipo de Datos y estás empezando a trabajar en la implementación de Snowflake en tu organización. Te piden gestionar 3 bases de datos:

Esta es una breve descripción de las 3 bases de datos:

• HR_DB contiene datos sobre empleados y headcount.
• FINANCE_DB contiene datos financieros, como balances y estados financieros.
• REPORTING_DB contiene datos para fines de analítica y reportería.

Tu tarea es asegurar que todos en la empresa tengan el acceso correcto a estas bases de datos.

Requisitos

Consultaste a distintos usuarios de Snowflake en tu empresa sobre sus necesidades y recopilaste los siguientes requisitos:

1. Richard, Data Analyst que trabaja con los equipos de Finanzas y RR.HH., pide poder leer todos los datos de Finanzas y RR.HH. para sus análisis. También quiere poder crear tablas de reportería en la base de datos de Reporting.
2. Lily, Data Engineer de tu empresa, necesita trabajar en la carga de datos históricos en las bases de datos de Finanzas y RR.HH.
3. El equipo de Finanzas está usando una nueva herramienta SaaS que necesita leer datos de las bases de datos de Finanzas y RR.HH., y como extra, escribirá algunos datos procesados de vuelta en la base de datos de Finanzas.
4. Te piden configurar una nueva herramienta de BI y dashboards que consumirá datos de la base de datos de Reporting.

Usa el siguiente código para crear las bases de datos en Snowflake:

use role SYSADMIN ;

create database FINANCE_DB ;
create database HR_DB ;
create database REPORTING_DB ;

-- Create tables, views, ...
-- ...

Pasos

Definir los Functional Roles y Service Roles

Con los requisitos en mano, puedes empezar haciendo una lista para detallar exactamente lo que necesitas.

Para los Functional Roles:

Para los Service Roles:

⚠️ Otorgar permisos completos de READWRITE sobre todos los esquemas de una base de datos a una herramienta de terceros como hacemos aquí (Finance SaaS) podría no ser la mejor idea en la vida real. En un escenario más realista, la herramienta solo tendría acceso al conjunto específico de esquemas desde los que necesita leer o en los que necesita escribir. Recuerda que este es un modelo simplificado.

Crear los Access Roles

Con base en las tablas anteriores, ya puedes ver los Access Roles que necesitas:

• HR_READ_ROLE
• HR_READWRITE_ROLE
• FINANCE_READ_ROLE
• FINANCE_READWRITE_ROLE
• REPORTING_READ_ROLE
• REPORTING_READWRITE_ROLE

Como mencionamos antes, los roles READ y READWRITE permitirán ejecutar sentencias SELECT o SELECT, INSERT, UPDATE y DELETE, respectivamente. Así se ve:

Y estas son las sentencias que se deben ejecutar en Snowflake:

-- Create Access Roles for HR_DB
use role USERADMIN ;

create role HR_READ_ROLE
        comment = 'Access Role READ for HR_DB' ;
create role HR_READWRITE_ROLE
        comment = 'Access Role READWRITE for HR_DB' ;

-- Grant Privileges to Access Roles for HR_DB
use role SECURITYADMIN ;

-- Granting Privileges to HR_READ_ROLE
-- Database
grant usage on database HR_DB to role HR_READ_ROLE ;

Expandir código

Ten en cuenta que puedes aprovechar convenciones de nombres fijas para las bases de datos y los Access Roles. Puedes crear un único script y usar templating para reutilizarlo y desplegar fácilmente varias bases de datos junto con sus respectivos Access Roles. Aquí tienes un ejemplo:

-- Assign values to the following variables accordingly
set database_name = 'HR_DB';
set role_read_name = 'HR_READ_ROLE';
set role_readwrite_name = 'HR_READWRITE_ROLE';

-- Create database
use role SYSADMIN ;
create database identifier($database_name) ;

-- Create Access Roles for the database
use role USERADMIN ;
create role identifier($role_read_name) ;
create role identifier($role_readwrite_name) ;

-- Grant Privileges to READ role

Expandir código

Crear los Functional Roles

Con los Access Roles listos, puedes crear fácilmente Functional Roles que representen las necesidades de los usuarios. Aquí es donde empezamos a mirar los requisitos.

Retomando lo que pide Richard:

🎯 Richard, Data Analyst que trabaja con los equipos de Finanzas y RR.HH., pide poder leer todos los datos de Finanzas y RR.HH. para sus análisis. También quiere poder escribir tablas en la base de datos de Reporting.

Así se ve:

Esta es una implementación simple de Access y Functional Roles para cubrir las necesidades de Richard. El rol ANALYST_ROLE es el Functional Role, y es el padre de HR_READ_ROLE, FINANCE_READ_ROLE y REPORTING_READWRITE_ROLE (todos Access Roles).

A Richard se le otorga entonces ANALYST_ROLE. Ahora puede consultar tablas en HR_DB y FINANCE_DB, y modificar datos en REPORTING_DB. Y este rol también se puede otorgar a cualquier otra persona del equipo de Richard con responsabilidades similares. 🎉

En Snowflake se ve así:

-- Create Functional Role ANALYST_ROLE
use role USERADMIN ;

create role ANALYST_ROLE
        comment = 'Functional Role for Data Analysts' ;

-- Grants to role ANALYST_ROLE
use role SECURITYADMIN ;

grant role HR_READ_ROLE to role ANALYST_ROLE ;
grant role FINANCE_READ_ROLE to role ANALYST_ROLE ;
grant role REPORTING_READWRITE_ROLE to role ANALYST_ROLE ;

-- Grant Functional Role to SYSADMIN (good practice mentioned before)
grant role ANALYST_ROLE to role SYSADMIN ;

Expandir código

Ahora, aplicando los mismos principios para Lily:

🎯 Lily, Data Engineer de tu empresa, necesita trabajar en la carga de datos históricos en las bases de datos de Finanzas y RR.HH.

Un ejemplo similar para un Functional Role de Data Engineering:

La configuración es similar, pero en este caso el rol ENGINEER_ROLE es el padre de HR_READWRITE_ROLE y FINANCE_READWRITE_ROLE, y luego se le otorga a Lily.

El SQL se ve así:

-- Create Functional Role ENGINEER_ROLE
use role USERADMIN ;

create role ENGINEER_ROLE
        comment = 'Functional Role for Data Engineers' ;

-- Grants to role ANALYST_ROLE
use role SECURITYADMIN ;

grant role HR_READWRITE_ROLE to role ENGINEER_ROLE ;
grant role FINANCE_READWRITE_ROLE to role ENGINEER_ROLE ;

-- Grant Functional Role to SYSADMIN (good practice mentioned before)
grant role ENGINEER_ROLE to role SYSADMIN ;

Expandir código

Ahora, atendiendo los requisitos del nuevo Finance SaaS:

🎯 El equipo de Finanzas está usando una nueva herramienta SaaS que necesita leer datos de las bases de datos de Finanzas y RR.HH., y como extra, escribirá algunos datos procesados de vuelta en la base de datos de Finanzas.

Esto es fácil, ¿verdad? Aquí está el diagrama:

En este caso se crea un nuevo Service Role, llamado FINANCE_SAAS_ROLE. Actúa esencialmente como un Functional Role, con la única diferencia de que se usa de forma programática y no por un ser humano. El rol hereda los privilegios de FINANCE_READWRITE_ROLE y HR_READ_ROLE, y se otorga a una Snowflake Service Account que utilizará el servicio.

En código:

-- Create Service Role FINANCE_SAAS_ROLE
use role USERADMIN ;

create role FINANCE_SAAS_ROLE
        comment = 'Service Role for Finance SaaS' ;

-- Grants to role FINANCE_SAAS_ROLE
use role SECURITYADMIN ;

grant role FINANCE_READWRITE_ROLE to role FINANCE_SAAS_ROLE ;
grant role HR_READ_ROLE to role FINANCE_SAAS_ROLE ;

-- Grant Service Role to SYSADMIN (good practice mentioned before)
grant role FINANCE_SAAS_ROLE to role SYSADMIN ;

Expandir código

Retomando el caso de uso de la herramienta de BI:

🎯 Te piden configurar una nueva herramienta de BI y dashboards que consumirá datos de la base de datos de Reporting.

¿Como siempre?

En este caso, el único Access Role que necesita BI_ROLE es REPORTING_READ_ROLE. ¡La herramienta de BI ahora podrá ejecutar consultas SELECT para alimentar sus dashboards! 🎉

En código:

-- Create Service Role BI_ROLE
use role USERADMIN ;

create role BI_ROLE
        comment = 'Service Role for BI and Insights Tool' ;

-- Grants to role BI_ROLE
use role SECURITYADMIN ;

grant role REPORTING_READ_ROLE to role BI_ROLE ;

-- Grant Service Role to SYSADMIN (good practice mentioned before)
grant role BI_ROLE to role SYSADMIN ;

-- Grant role to service account

Expandir código

Para cerrar

Con todos los casos de uso cubiertos, ¡nuestra jerarquía de roles inicial está completa! Así se ve todo en conjunto:

Bonus: cómo manejar cambios y ajustes

Uno de los beneficios de tener una jerarquía DRY es que se puede ajustar fácilmente cuando surgen nuevos requisitos. Por ejemplo, imagina que la Data Engineer Lily olvidó pedir acceso READWRITE a REPORTING_DB. Esta solicitud se resuelve de forma muy sencilla:

-- Adjust DATA_ENGINEER functional role
use role SECURITYADMIN ;
grant role REPORTING_READWRITE_ROLE to role DATA_ENGINEER ;

¡Ahora gestionas una jerarquía que se adapta fácilmente a los nuevos requisitos del negocio! 🎉