Snowflake se ha convertido en uno de los actores clave del mundo de los datos: ofrece a sus clientes una plataforma de data cloud versátil que da soporte a todo tipo de capacidades analíticas. Para hacerlo de forma segura, Snowflake provee un conjunto flexible de funciones de control y gestión de accesos.
Manejar bien las mejores prácticas para gestionar el acceso a Snowflake es fundamental. Sin un diseño cuidadoso, los roles y los grants se vuelven difíciles de manejar muy rápido, lo que termina generando duplicación, inconsistencias y, en última instancia, riesgos para la seguridad de tus datos. Seguir un conjunto de estándares y patrones bien definidos aporta seguridad, transparencia y simplicidad.
En este post entramos a fondo en los conceptos clave y en cómo controlar mejor el acceso en Snowflake. Si eres administrador de Snowflake o data engineer y buscas entender mejor el control de acceso, este post es para ti.
Conceptos clave del control de acceso en Snowflake
Snowflake usa un enfoque de Role-Based Access Control (RBAC) para gestionar qué pueden ver y hacer los usuarios y otros sistemas. En RBAC, tener un determinado rol implica contar con ciertos privilegios.
Veamos algunos términos:
- User: una entidad que permite a una persona (o servicio) conectarse a Snowflake.
- Object: una entidad a la que un User puede acceder (por ejemplo, una tabla, una vista o una base de datos), siempre que tenga los privilegios adecuados.
- Privilege: una operación que un User puede ejecutar sobre un Object, si su Role la tiene concedida.
- Role: una entidad puente entre Users y Privileges. Los privilegios se otorgan a los Roles, y los Roles se otorgan a los Users.
En resumen, como lo plantea Snowflake:
Los privilegios se otorgan a los roles, y los roles se otorgan a los usuarios, para especificar las operaciones que los usuarios pueden realizar sobre los objetos del sistema.
A partir de estos 4 conceptos clave, las secciones y diagramas que siguen se irán apoyando unos en otros hasta llegar a una configuración de control de acceso mínima, pero completa.
Users
Un User de Snowflake es una identidad que puede conectarse a una Account de Snowflake y ejecutar un conjunto de operaciones permitidas. Cada persona de tu equipo de datos debería tener un User de Snowflake con el que se conecte y corra consultas. Un User de Snowflake también puede usarlo un sistema externo: por ejemplo, herramientas de BI (como Tableau o Looker) o herramientas ELT (como Stitch o Fivetran).
En definitiva, lo que pueden hacer los Users de Snowflake es el tema central del control de acceso.
Objects
Los Objects son las primitivas de Snowflake a las que se puede otorgar acceso. Los más evidentes son las bases de datos, los esquemas y las tablas, pero también incluyen objetos a nivel de cuenta como los warehouses, las storage integrations, etc.
Estos son algunos ejemplos comunes de Objects de Snowflake:
| Securable Object | Nivel | Descripción |
|---|---|---|
| Database | Account-level | Las bases de datos son los objetos clave que mantienen al resto de objetos securables aislados y agrupados lógicamente. |
| Schema | Database-level | Una agrupación lógica de objetos como tablas, vistas, stages, etc. |
| Table | Schema-level | El objeto que contiene los datos y ocupa almacenamiento físico. En la mayoría de los casos, las tablas son la pieza clave para que Snowflake sea útil. Existen varios tipos de tablas, cada uno pensado para distintos casos de uso. |
| View | Schema-level | Una tabla disfrazada. Da acceso a datos, pero no ocupa almacenamiento. Una vista se define como una consulta sobre otras tablas. Existen varios tipos de vistas, cada uno para distintos casos de uso. |
| Virtual Warehouse | Account-level | Los recursos de cómputo principales que se necesitan para correr consultas o cargar datos en Snowflake. |
| Storage Integration | Account-level | Un objeto que conecta un bucket de S3 (también GCS y Azure Blob storage) con Snowflake, lo que permite a los Users cargar o descargar datos desde Snowflake, o consultar el contenido del bucket directamente. |
| Snowpipe | Schema-level | Un objeto que automatiza la carga de datos desde S3 (o GCS y Azure Blob storage) a las tablas en cuanto llegan archivos nuevos al bucket. |
| Stage | Schema-level | Ubicación de archivos de datos (CSV, Parquet, etc.) en almacenamiento en la nube. Hay dos tipos de stages: internos (almacenamiento gestionado por Snowflake) y externos (almacenamiento autogestionado). |
Privileges
Los privilegios son un concepto esencial del control de acceso. Permiten realizar una operación individual, o a veces un conjunto de operaciones, sobre un objeto.
Por ejemplo, sobre una Table de Snowflake, un User podría tener el privilegio de hacer SELECT sobre sus datos, INSERT de filas, DELETE, etc. Sobre una Database de Snowflake, un User podría ejecutar CREATE SCHEMA o MONITOR.
La tabla siguiente describe brevemente algunos de los privilegios clave que pueden otorgarse sobre los objetos clave.
| Object | Object Privilege | Descripción |
|---|---|---|
| Database | USAGE | Permite usar y ver la base de datos, pero se requieren privilegios adicionales para realizar acciones sobre ella. |
| MONITOR | Permite ejecutar un comando DESCRIBE. | |
| CREATE SCHEMA | Permite crear (o clonar) un esquema en la base de datos. | |
| IMPORTED PRIVILEGES | Solo aplica a bases de datos compartidas y permite que otros account roles accedan a los objetos compartidos. Para más información sobre imported privileges, consulta https://docs.snowflake.com/en/user-guide/data-share-consumers#option-1-objects-in-a-share-not-associated-with-a-database-role. | |
| Schema | USAGE | Permite ver y usar el esquema, pero aun así se requieren privilegios adicionales sobre los objetos del esquema para verlos o ejecutar comandos sobre ellos. |
| MONITOR | Permite ejecutar un comando DESCRIBE. | |
| CREATE TABLE / CREATE VIEW / CREATE STAGE / CREATE PIPE | / CREATE STAGE / CREATE PIPE Permite crear una tabla / vista / stage / pipe en el esquema. | |
| Table | SELECT | Permite consultar la tabla para obtener datos. |
| INSERT | Permite insertar filas en la tabla. | |
| UPDATE | Permite actualizar datos existentes en la tabla. | |
| TRUNCATE | Permite borrar todos los datos de la tabla. | |
| DELETE | Permite borrar todas las filas o un subconjunto específico de filas de la tabla. | |
| View | SELECT | Permite consultar la vista para obtener datos (sin importar las tablas subyacentes ni los privilegios otorgados sobre ellas). |
| Stage | USAGE | Permite usar el stage externo en una sentencia SQL. |
| READ | Permite ejecutar cualquier comando que lea el stage interno (GET, LIST, COPY INTO). | |
| WRITE | Permite ejecutar cualquier comando que escriba en el stage interno (PUT, REMOVE, COPY INTO). |
Puedes consultar la lista completa de privilegios de objeto disponibles para el control de acceso en Snowflake aquí.
Con esta lista a la mano, al auditar accesos te resultará útil recordar que los privilegios se otorgan en distintos niveles según dónde se cree el objeto (a nivel de cuenta, de base de datos o de esquema).
Privilegio Ownership
Snowflake usa un enfoque de Role-Based Access Control (RBAC) […]
👆La primera frase de esta sección solo era cierta a medias. Snowflake combina RBAC con un concepto clave de otro modelo de control de acceso: Discretionary Access Control (DAC). En DAC, cada objeto debe tener un propietario.
En la implementación de DAC de Snowflake, cada objeto es propiedad del Role que se usó para crearlo. Que un Role sea propietario de un objeto significa que tiene el privilegio OWNERSHIP sobre él.
Es importante entender que los Users no son propietarios de los objetos; lo son los Roles. Suponiendo que todos los Analistas de tu equipo de datos tienen el mismo Role, los objetos que cree un Analista serán propiedad de todos los Analistas.
Ten en cuenta que el privilegio OWNERSHIP sobre un objeto se puede transferir a otro Role. Por ejemplo, quizá quieras transferir la propiedad de una tabla a un rol "más poderoso" para limitar quién puede otorgar acceso a otros roles.
Privilegios sobre objetos futuros
A veces, al configurar inicialmente el control de acceso, los objetos aún no existen. Sin embargo, ya sabes de antemano que vas a querer que un determinado rol tenga acceso a ellos en cuanto se creen. Snowflake nos permite anticiparnos otorgando ciertos privilegios sobre objetos futuros.
Por ejemplo, al rol ANALYST se le puede otorgar el privilegio SELECT sobre las tablas futuras de la base de datos GOLDEN_DB, o sobre las tablas futuras de un esquema específico. Échale un vistazo a esta documentación de Snowflake para más detalles sobre la precedencia de los grants sobre objetos futuros.
Roles
Puedes pensar los roles de Snowflake como llaves. 🔑 Tienes una llave de tu casa, otra del auto y quizá una de la oficina. Si tienes un vecino cercano, puede que tenga una llave de repuesto de tu casa (por si surge una emergencia). Las llaves de tu casa les dan acceso a ti y a tu vecino.
De forma similar, en términos de Snowflake, un rol otorgado a un usuario le da acceso a distintas operaciones y objetos. Aquí tienes una ilustración de cómo nuestro organigrama podría mapearse a Roles de Snowflake.
Tipos de roles
En Snowflake existen tres tipos clave de Roles:
- account roles
- database roles
- instance roles
Además, existen los application roles, vinculados a las Snowflake Native Applications, un tema interesante que merece su propio post y queda fuera del alcance de Snowflake Roles 101.
Account Role
Los roles originales de Snowflake, los Account Roles, son los roles estándar y se caracterizan por:
- poder recibir privilegios sobre cualquier objeto securable de la cuenta,
- tener nombres únicos a nivel de Account, y
- poder otorgarse a Users o a otros Account Roles.
Database Role
Como su nombre lo indica, un Database Role está vinculado a una Database específica, y:
- solo se le pueden otorgar privilegios sobre los objetos de esa base de datos (esquemas, tablas, vistas, etc.),
- su nombre es único dentro de la Database en la que se crea,
- se puede otorgar a otros Database Roles (dentro de la misma Database) y a Account Roles,
- no se puede otorgar directamente a Users, y
- tiene por defecto el privilegio
USAGEsobre su base de datos.
Instance Role
Los Instance Roles son el tipo de rol que menos se usa. Están vinculados a una Snowflake Class Instance y se otorgan a Account Roles, lo que permite a los Users ejecutar métodos de la Class Instance.
Al momento de escribir esto, solo Snowflake puede crear Classes. Lee más sobre las Snowflake Classes disponibles aquí.
¿Qué tipo de Role conviene usar?
Si recién estás empezando, los Account Roles te van a llevar bastante lejos.
La cosa se pone interesante cuando empiezas a pensar en los database roles y en su potencial para simplificar y estandarizar tu configuración, ya que le permiten al propietario de una base de datos autogestionar los privilegios sobre ella sin necesidad de ACCOUNTADMIN.
Además, si trabajas con Snowflake Shares para compartir tus datos, los database roles hacen que el control de acceso sea más fácil de configurar.
Jerarquía de roles
Los Roles también se pueden otorgar a otros Roles. Al hacerlo, se crea una jerarquía de roles.
La forma más sencilla de explicar una jerarquía de roles es con un ejemplo. Con la jerarquía de abajo, Splinter, con su rol SYSADMIN, cuenta con el superconjunto de privilegios de los roles DATA_ENG_ROLE, ANALYST_ROLE y DB_MANAGER_ROLE, mientras que Kim solo tiene los privilegios de DATA_ENG_ROLE y DB_MANAGER_ROLE.
Account Roles por defecto en Snowflake
Cuando creas una cuenta de Snowflake y abres Admin / Users & Roles, vas a ver un conjunto de roles que Snowflake crea por defecto. Estos roles system-defined no se pueden eliminar, ni tampoco se puede modificar el conjunto estándar de privilegios que cada uno tiene. Cada uno cumple su propósito:
ACCOUNTADMIN: el rol modo dios, que puede hacer cualquier cosa a nivel de cuenta. Sé muy cuidadoso al otorgarlo. Ten en cuenta queACCOUNTADMINhereda todos los privilegios deSECURITYADMINySYSADMIN.SECURITYADMIN: este rol tiene el privilegio a nivel de cuentaMANAGE GRANTS, que le permite otorgar (o revocar) grants sobre cualquier objeto de la cuenta a (o desde) otros roles. Ten en cuenta queSECURITYADMINhereda todos los privilegios que recibe del rolUSERADMIN.USERADMIN: como su nombre indica, este rol se usa para crear y gestionar usuarios (apoyándose en los privilegios a nivel de cuentaCREATE USERyCREATE ROLE).SYSADMIN: este rol puede crear todos los objetos de la cuenta (incluidas bases de datos, warehouses y otros objetos a nivel de esquema).PUBLIC: a todos los usuarios de la cuenta se les otorga el rolPUBLICpor defecto, pero, a menos que se le conceda acceso explícito a objetos, no puede hacer gran cosa. Aun así, ten mucho cuidado de no otorgarle accidentalmente privilegios sobre datos importantes, porque todos los usuarios de la cuenta podrán acceder a ellos. O, mejor todavía, no le otorgues ningún privilegio al rolPUBLIC. 😉
Por último, ORGADMIN merece una mención especial. Se utiliza para operaciones a nivel de organización, como crear más cuentas de Snowflake, y no encaja del todo en la jerarquía de roles por defecto.
Al crear roles personalizados y armar una jerarquía de roles, Snowflake recomienda que todos los roles personalizados terminen siendo descendientes de SYSADMIN.
Por nuestra experiencia trabajando con muchas cuentas de Snowflake, es común ver que la mayoría de los objetos de las bases de datos los crea y los tiene como propios ACCOUNTADMIN. En general es una mala práctica: deja ver que se ha pensado poco en el control de acceso y es señal de que ACCOUNTADMIN se está usando como rol por defecto, lo cual puede llevar a errores destructivos, como borrar datos o usuarios. En la Parte II de esta serie cubriremos algunas mejores prácticas de control de acceso. 🙌
Rol por defecto del User
Al conectarse a Snowflake, un usuario inicia una sesión, que en la mayoría de los casos requiere fijar un rol. Si no se especifica, Snowflake recurre al rol por defecto del usuario.
Roles secundarios
Los roles secundarios son una forma de permitirle a un usuario aprovechar las capacidades de acceso de varios roles a la vez. La mayoría de los clientes de Snowflake solo usan roles primarios (un único rol), pero los roles secundarios son una capacidad poderosa que ayuda a evitar la necesidad de combinar varios roles.
Así como ejecutas el comando use role para fijar tu rol primario en una sesión, puedes ejecutar use secondary roles. La diferencia principal es que este comando acepta dos opciones:
use secondary roles allactiva todos los roles a los que se le ha dado acceso al usuario.use secondary roles nonedesactiva los roles secundarios.
Uniendo todas las piezas
Bien, bien… "¡Muéstrame algo de SQL!! 💢", ya te escucho.
Armemos el rompecabezas con un ejemplo de extremo a extremo: configurar desde cero una cuenta de Snowflake y dejarla lista para que Kim y Rufus puedan usarla según sus necesidades.
En resumen:
- Creamos los Users, los Roles y la Database.
use role SECURITYADMIN;
create role DATA_ENGINEER_ROLE;
create role DB_MANAGER_ROLE;
create role ANALYST_ROLE;
use role USERADMIN;
create user KIM;
use role SYSADMIN; -- objects are owned by the active role
create database SOURCE_DB;
create warehouse ANALYSIS_WH;
- Se otorgan privilegios sobre los objetos securables a los Roles.
use role SECURITYADMIN;
grant USAGE, MODIFY, CREATE SCHEMA
on database SOURCE_DB to role DB_MANAGER_ROLE;
grant USAGE on database SOURCE_DB to role ANALYST_ROLE;
grant USAGE, OPERATE
on warehouse ANALYSIS_WH to role ANALYST_ROLE;
- Los Roles se enlazan en una jerarquía, creando herencia de privilegios.
use role SECURITYADMIN;
grant role DB_MANAGER_ROLE to role DATA_ENGINEER_ROLE;
grant role ANALYST_ROLE to role DATA_ENGINEER_ROLE;
grant role DATA_ENGINEER_ROLE to role SYSADMIN;
- Los Users acceden a los objetos securables al recibir Roles.
use role SECURITYADMIN;
grant role DATA_ENGINEER_ROLE to user KIM;
grant role ANALYST_ROLE to user RUFUS;
Con esto llegamos a una configuración que:
- le permite a Kim:
- crear esquemas en
SOURCE_DBy usarla, - usar y operar el
ANALYSIS_WH. - le permite a Rufus:
- usar
SOURCE_DB(si te preguntas si faltan privilegios adicionales sobre esquemas y bases de datos, tienes 💯 razón, pero los dejamos fuera por simplicidad), - usar y operar el
ANALYSIS_WH.
Aunque es una configuración muy simple, te da todos los bloques que necesitas para implementar tu propio modelo RBAC en Snowflake. En la Parte II del post veremos las mejores prácticas de RBAC en Snowflake y te dejaremos algunas recomendaciones con opinión.
Frequently asked
questions
Crear un rol
create role FINANCE_ROLE; -- Account role
create database role SOURCE_DB.READ_DB_ROLE; -- Database role
Consultar el rol por defecto de un usuario
1describe user SELECT_DOGFOOD;
Establecer el rol por defecto de un usuario
Para actualizar el rol por defecto del usuario, puedes ejecutar el siguiente comando:
1alter user SELECT_DOGFOOD set default_role=DATA_ENG_ROLE;
Mostrar los roles de tu cuenta
1show roles;
Ejecutar una consulta con un rol distinto
use role USERADMIN;
drop user EX_EMPLOYEE_USER; -- query requires USERADMIN role
Otorgar ownership en Snowflake
grant ownership
on database FIVETRAN_DB
to role FIVETRAN_ROLE
copy current grants; -- keeps existing grants on the database
grant ownership
on all tables
in schema DEV_ANALYTICS.DBT_KIM
to role DEV_ROLE
revoke current grants; -- resets existing grants on all tables
Otorgar un rol a un usuario de Snowflake
Este es un ejemplo de cómo otorgar el rol SYSADMIN a un usuario llamado IAN_WHITESTONE:
1grant role SYSADMIN to user IAN_WHITESTONE;
Dar acceso a un usuario a un warehouse
Para permitir que un usuario ejecute consultas en un warehouse de Snowflake, primero le otorgas al rol el privilegio usage sobre el warehouse:
1grant usage on warehouse COMPUTE_XLARGE_WH to role DATA_ENG_ROLE;
Luego, otorga ese rol al usuario:
1grant role DATA_ENG_ROLE to user IAN_WHITESTONE;
Otorgar un rol a otro rol de Snowflake
Como se vio antes en este post, también puedes otorgar un rol a otro rol, en lugar de a un usuario.
1grant role DATA_ENG_ROLE to role SYSADMIN;
Ver qué privilegios se le han otorgado a un rol
Ten en cuenta que, al correr la consulta anterior, tu Role activo debe ser el Role que estás consultando o cualquiera de sus Roles padres en la jerarquía.
Mostrar los roles otorgados a un usuario
Este es un ejemplo para ver todos los usuarios a los que se les ha otorgado el rol ACCOUNTADMIN:
show grants of role ACCOUNTADMIN;
select *
from table(result_scan(last_query_id()))
where "granted_to" = 'USER';
Quitar el acceso a un objeto
Lo opuesto a grant es revoke. Así se revocan privilegios de un rol:
1revoke USAGE on all databases from role ANALYST_ROLE;
Auditar los roles, grants y privilegios de un usuario de Snowflake
- Audita qué Roles se le han otorgado a un User:
1show grants to user HOLISTICS_USERf;
2. Ahora que sabes qué Roles puede asumir un User, puedes profundizar en los privilegios que tiene cada uno.
1show grants to role HOLISTICS_ROLE;
Este enfoque se vuelve tedioso rápido, sobre todo si hay una jerarquía de roles compleja. Existen distintos recursos y herramientas para auditar y gestionar el control de acceso, pero esta respuesta aceptada de StackOverflow es un excelente punto de partida. Si te interesa avanzar hacia un control de acceso bien gestionado, considera permifrost, de GitLab, que puede darte las consultas que conviene ejecutar para llegar a la especificación deseada.
Otorgar select sobre todas las tablas futuras de un esquema y una base de datos
Ten en cuenta que hay una distinción entre objetos all y future. Otorgar un privilegio sobre objetos future no lo otorga sobre all los objetos existentes, y viceversa.
allhace referencia a los objetos que existen en el momento en que se ejecuta la consulta.futuresolo hace referencia a los objetos que aún no se han creado.
Por eso, para otorgar select sobre todas las tablas y también sobre las tablas futuras de un esquema, tendrás que ejecutar 2 consultas: una para las tablas all y otra para las future (u otros objetos como views o schemas).
grant select
on future tables
in schema MY_DATABASE.FOO_SCHEMA
to role BAR_ROLE
copy current grants;
grant select
on future tables
in database MY_DATABASE
to role BAR_ROLE
copy current grants;
grant select
on all tables
Expandir código
¿Quién puede ver qué usuarios y roles existen, y qué rol se le ha otorgado a cada usuario?
Todo el mundo. Cualquier rol, incluido el rol por defecto PUBLIC, le permite al User ver todos los usuarios y roles que existen en la cuenta, así como qué roles se le han otorgado a cada usuario. Sin embargo, no todo el mundo puede ver qué privilegios tienen los roles.
Sobre Tasman Analytics
Tasman es una consultora boutique de analítica que convierte datos desordenados en valor de negocio real. Creemos que las empresas merecen plataformas de datos que de verdad marquen la diferencia.
Nuestra experiencia en datos abarca analítica, business intelligence y data science. Con oficinas en el Reino Unido y los Países Bajos, atendemos clientes en toda Europa desde 2017.
Basamos nuestro trabajo en tres pilares esenciales:
- PEOPLE: les enseñamos a nuestros clientes exactamente lo que necesitan y cómo armar un equipo de datos de alto rendimiento. Mientras tanto, sentamos las bases adecuadas para sus procesos, su cultura y sus formas de trabajar con datos, para que su nuevo equipo arranque con ventaja.
- TECH: construimos un modern data stack que les da a nuestros clientes una única fuente de verdad, adaptada a sus necesidades y basada en las mejores prácticas de la industria.
- INSIGHTS: ayudamos a nuestros clientes a definir e interpretar las métricas que importan para que tengan una visión estratégica de su negocio. Una vez que sabemos qué funciona, creamos dashboards de reporting confiables y herramientas de self-service para que puedan priorizar, decidir y actuar más rápido y con confianza.
Descubre más sobre nuestro enfoque y cómo podemos acelerar tu recorrido con datos en [email protected] o en nuestro sitio tasman.ai.
Jovan Saković · Sr. Data Engineer en Tasman Analytics
Jovan trabaja actualmente en Tasman Analytics, ayudando a sus clientes a llegar al valor de negocio lo más rápido posible mediante el despliegue de plataformas de datos escalables y probadas. Con más de 20 clientes acumulados en Tasman, ha trabajado con una amplia variedad de herramientas del MDS, pero lo que más le entusiasma sigue siendo Terraform-ear cuentas de Snowflake. A Jovan le gusta forjar alianzas con productos en los que cree, como Metaplane, Prefect y, por supuesto, SELECT.