Datos compartidos en Snowflake: qué revoca un permiso

Termina la colaboración con un proveedor. El equipo retira su cuenta del acceso compartido y comprueba que ya no puede consultar la base. El ticket queda cerrado con una frase tranquilizadora: «Datos retirados».

Pero el informe que el proveedor descargó el martes sigue en su carpeta. También puede seguir existiendo el extracto que alimentaba una aplicación. La comprobación técnica era correcta; la conclusión abarcaba más de lo que se había comprobado.

Este escenario es hipotético. Sirve para delimitar una propiedad muy útil de Snowflake: revocar el acceso a datos compartidos permite cortar una vía de consulta, pero no acredita la retirada de los resultados que ya salieron por ella. Si queremos poder cerrar una colaboración con garantías operativas, necesitamos diseñar también esa segunda parte.

Qué ocurre al retirar una cuenta de un share

Un share es el mecanismo con el que un proveedor concede a otras cuentas acceso a determinados objetos. En el funcionamiento descrito por Secure Data Sharing, compartir no exige copiar los datos a la cuenta consumidora. Esta crea una base importada desde la que puede consultarlos. El proveedor conserva control sobre el acceso compartido.

La documentación de gestión de shares precisa el efecto de retirar una cuenta: la base que esa cuenta había creado a partir del share queda invalidada y sus consultas y operaciones dejan de funcionar. Añadir de nuevo la cuenta no restaura aquella base; el consumidor necesita crear otra a partir del share.

Ese comportamiento tiene dos consecuencias diferentes. Permite interrumpir el consumo por esa vía y puede provocar una interrupción en los procesos que dependían de ella. Por eso la revocación merece una decisión consciente sobre el momento y el impacto. Si existe una urgencia que obliga a cortar inmediatamente, conocer las dependencias ayuda a gestionar las consecuencias; no convierte la urgencia en una razón para posponer el corte.

El alcance aquí son los shares directos y las bases importadas descritas en esas páginas. No estamos certificando todas las modalidades de colaboración, las configuraciones entre regiones ni las condiciones particulares de un producto del Marketplace.

Solo lectura protege el origen, no borra lo leído

Snowflake establece que las bases importadas son de solo lectura: el consumidor puede consultar sus datos, pero no insertar, actualizar ni crear objetos dentro de ellas. Tampoco puede clonar la base importada o sus tablas. Estas restricciones delimitan operaciones sobre esos objetos; no justifican deducir que un resultado consultado nunca puede conservarse fuera.

La distinción resulta más clara si dejamos de hablar de «el dato» como si fuera una sola cosa. Tenemos el objeto compartido, la información que devolvió una consulta y los productos que alguien elaboró con esa información. Una hoja de cálculo ya guardada no vuelve a consultar el permiso original cada vez que se abre.

En una arquitectura concreta pueden existir controles adicionales que limiten lo que se obtiene, las herramientas disponibles o los destinos admitidos. Habrá que evaluarlos. Lo que no podemos hacer es atribuir esas garantías al mero hecho de que el acceso se llame seguro o de que la base sea de solo lectura.

Esta es también una decisión de producto. Un consumidor que necesita conservar una fotografía mensual puede tener una razón legítima para guardar resultados. Si el acuerdo exige que todo desaparezca cuando cese el acceso, ese requisito debe hacerse compatible con el uso previsto desde el principio. Descubrir la contradicción al cerrar la colaboración llega bastante tarde.

El mapa de retirada del dato

Para discutir ese cierre propongo un mapa de retirada del dato. Es una síntesis propia para este artículo, no una función de Snowflake ni una certificación. Vincula cada lugar donde puede quedar información con una evidencia de cierre que sí corresponda a ese lugar.

Acceso al origen

Identifica la cuenta, el share y los objetos afectados. La evidencia es que la vía concreta ha dejado de permitir el consumo, con el alcance y el momento documentados.

Resultados conservados

Identifica extractos, archivos o tablas independientes que el consumidor haya declarado. Su retirada requiere una actuación y una comprobación propias; no se deduce del cambio de permiso del origen.

Productos derivados

Identifica informes, indicadores y aplicaciones que utilizan esa información. Debe quedar claro cuáles pueden mantenerse, cuáles dejan de actualizarse y cuáles deben retirarse según lo acordado.

Cierre pendiente

Recoge destinos desconocidos, comprobaciones incompletas y el responsable de resolverlas. Una laguna explícita permite decidir; una casilla verde que la esconde impide hacerlo.

Su límite es importante: el mapa organiza evidencia disponible, no descubre por sí solo todas las copias. Tampoco demuestra que un tercero haya cumplido una eliminación solo porque lo declare. Permite diferenciar observación directa, comprobación aportada y asunto todavía sin verificar.

Volvamos al proveedor del principio. Supongamos que conocemos tres destinos: la base importada, un extracto mensual y un informe agregado. Revocar el share cierra el primero. El segundo espera una actuación del consumidor. Para el tercero, el acuerdo puede permitir conservar el informe o exigir retirarlo. Contar «uno de tres» tampoco daría un porcentaje útil de seguridad: los destinos tienen consecuencias distintas y podrían faltar otros.

La mejor retirada empieza antes de compartir

Cuando una colaboración solo necesita ciertos resultados, entregar todas las columnas crea un problema de retirada mayor del necesario. La forma de la información compartida condiciona lo que habrá que controlar después. Esa elección pertenece al diseño del producto de datos, además de a la administración de permisos.

Las políticas de proyección de Snowflake ilustran bien la necesidad de leer los límites. Pueden restringir que una columna aparezca en la salida de una consulta. La documentación advierte, sin embargo, de que no garantizan impedir inferencias deliberadas y de que una relación con una tabla no protegida puede revelar valores coincidentes. Restringir una salida concreta tiene utilidad; convertirlo en una promesa absoluta de ausencia de filtraciones excede esa utilidad.

No hace falta acumular controles por catálogo. Hace falta describir qué información necesita realmente el receptor y qué exposición estamos aceptando. A veces una vista más limitada conserva todo el valor del intercambio. En otras ocasiones, el propósito exige detalle individual y habrá que asumir un perímetro de control más amplio.

El mismo razonamiento aparece al discutir portabilidad y dependencias en Iceberg: compartir una capacidad técnica no resuelve automáticamente los acuerdos de operación que la acompañan. Aquí el acuerdo decisivo es qué significa terminar el acceso y qué trabajo queda cuando ese acceso desaparece.

Una descripción de cierre que se pueda defender

Un cierre útil puede decir: «Acceso al share revocado y comprobado; extracto mensual pendiente de retirada por el consumidor; informe agregado conservado dentro del alcance acordado». Es menos rotundo que «datos retirados» y mucho más informativo.

La pregunta que conviene resolver antes de compartir es sencilla: cuando retiremos este permiso, ¿qué dejará de funcionar, qué información seguirá existiendo y quién podrá acreditarlo? Si esas respuestas están claras, la revocación será una capacidad operativa real, con un límite conocido.