En las dos pasadas entradas de mi blog, me he centrado en Secure Data Sharing, pero principalmente con Snowflake com pieza clave, tanto a nivel productor como consumidor. En esta neva entrada, amplío el horizonte hacia otras fórmulas para construir tu Espacio de Datos.
1. Comprender las opciones: acceso interno vs. externo
- Interno (entre cuentas Snowflake): se usa Secure Data Sharing, con permisos directos y sin movimiento físico.
- Externo (consumidores en otra plataforma): se requiere abrir el acceso a través de servicios federados o API, sin exponerse directamente.
El objetivo es que el consumidor no tenga acceso directo a las tablas, sino a vistas filtradas, APIs o “product endpoints” controlados por políticas.
2. Opciones técnicas para consumidores en otras plataformas
a) Snowflake Data Marketplace / Snowflake Native App Framework
- Puedes publicar un Data Product controlado que los consumidores acceden mediante contratos de uso.
- Los consumidores interactúan a través de una capa de aplicación (API, vista o app nativa) en lugar de leer las tablas directamente.
- Permite definir parámetros de uso, autenticación y reglas de consumo (similar a Data Contracts ampliados).
b) External Access vía API / Snowflake Data Services
- Snowflake permite crear endpoints controlados mediante Snowflake External Functions o conectores hacia servicios API seguros.
- Puedes exponer vistas agregadas o anonimizadas, y el controlador API impone:
- Autenticación (OAuth2, OpenID Connect).
- Autorización basada en rol o identidad.
- Limitación por cuota, tiempo o región (principio de soberanía de acceso).
Esto es la base para interoperar con plataformas externas (por ejemplo, Databricks, Azure Fabric, AWS Glue, etc.) sin compartir el almacenamiento físico.
c) Snowflake Reader Accounts
- Si el consumidor no tiene Snowflake, el proveedor puede crear una Reader Account vinculada a su propia cuenta.
- Es un “subtenant” aislado que accede al share bajo las mismas reglas de auditoría y trazabilidad.
Este modelo sigue siendo dentro del ecosistema Snowflake, pero te permite mantener governance completa sobre accesos.
d) Federación con Espacios de Datos (Gaia‑X / UNE 0087:2025)
En un Data Space federado, el acceso externo se gestiona mediante:
- Identidades verificadas (verifiable credentials) y metadatos de confianza (catálogos).
- Políticas de uso codificadas (Usage Policies, Privacy by Design).
- Gateways de interoperabilidad: el proveedor expone los datos no de forma directa, sino mediante servicios seguros (API, Data Gateway o Federated Connector).
Snowflake se conecta a esos gateways mediante API REST ‑ JDBC, lo que permite que otras plataformas accedan a datos filtrados y auditados.
3. Cómo limitar realmente el acceso
| Objetivo | Mecanismo en Snowflake | Implementación para consumidores externos |
|---|---|---|
| Restringir columnas / campos | Secure Views o Masking Policies | Exponer solo vistas con información anonimizada o agregada vía API. |
| Controlar desde dónde se accede | Network Policies (direcciones IP, VPC, regiones) | Integrar con federadores o VPN seguras entes de conceder tokens. |
| Autenticación y rol | Role Based Acces Control (RBAC) | Delegar identidad al sistema del consumidor |
| Monitor y auditoría | Access History / Snowflake Events | Registar accesos en logs externos del Data Space |
| Revocación inmediata | Revoke privileges, drop share, o caducidad del token | Políticas automáticas basadas en cumplimiento contractual |
4. Integración con DAMA, Gaia‑X y UNE 0087:2025
| Marco | Principio | Cómo se cumple al limitar acceso externo |
|---|---|---|
| DAMA España | Data Security, Privacy & Access Control | Se definen roles, políticas de exposición y trazabilidad del consumo. |
| Gaia-X | Soberanía e interoperabilidad | El propietario controla quién, bajo qué credenciales y con qué metadatos puede acceder. |
| UNE 0087:2025 | Responsabilidad y trazabilidad en el intercambio | Auditorías, control de origen y uso, posibilidad de revocar acceso por incumplimiento. |
Ejemplo resumido
Una empresa de retail comparte su catálogo de productos con partners que operan en Databricks:
- Los datos se almacenan en Snowflake con políticas de anonimización y versión contractual.
- Se crea una Security View y una External Function expuesta vía API REST.
- Los partners consumen esos datos desde Databricks mediante peticiones autenticadas con token.
- Snowflake registra y audita cada acceso; el proveedor puede revocar el token o modificar la vista en cualquier momento.
Conclusión
Aunque Secure Data Sharing es nativo de Snowflake, la apertura controlada a consumidores externos se logra combinando APIs, identidades verificadas, vistas seguras y políticas de gobernanza. De este modo, puedes extender tu Data Contract y participar en un Espacio de Datos federado cumpliendo plenamente con los principios de Gaia‑X, UNE 0087:2025 y DAMA España.
Foto de portada gracias a Aleksander Dumała: https://www.pexels.com/es-es/foto/ordenador-portatil-llaves-sujetando-dispositivo-20123833/
Alb3rto Alonso 