Comportamiento inesperado en Cortex AI de Snowflake

1. Introducción

IA en todas partes, ¿pero a qué costo?

La IA está infiltrándose en todos los rincones de la tecnología, desde chatbots en herramientas de analítica empresarial hasta modelos generativos que impulsan el descubrimiento de datos. Estas innovaciones ofrecen eficiencias increíbles y un crecimiento empresarial próspero, pero también traen riesgos de seguridad inexplorados. Un riesgo particularmente preocupante es la exposición inesperada de datos. Ya sea M365 Co-Pilot, Snowflake Cortex AI u otro servicio de IA, tu seguridad es tan buena como las políticas de acceso que configuraste.

En esta publicación, examinaremos cómo el CORTEX Search Service, de Snowflake, una herramienta de búsqueda y recuperación de vanguardia impulsada por IA, podría terminar exponiendo datos sensibles dentro de tu base de usuarios de Snowflake, incluso en un entorno seguro con políticas de acceso y enmascaramiento estrictamente configuradas.

Al final de la publicación explicamos cómo Cyera puede ayudar a protegerse contra este problema. Si necesitas más ayuda, comunícate con nosotros en support@cyera.com. 

Queremos agradecer a todo el equipo de Snowflake por su transparencia, capacidad de respuesta y colaboración durante todo el proceso; realmente apreciamos su apoyo.

2. Caso de uso: Uso indebido de CORTEX Search para mostrar datos sensibles

2.1 Enmascaramiento dinámico en Snowflake

Enmascaramiento dinámico de datos es el método de Snowflake para restringir cómo se presenta la información, según quién la consulte. Por lo general, se establece una política de enmascaramiento en columnas sensibles, como esta:

• ADMIN ve datos reales (val).
• Todos los demás ven datos enmascarados (*****).

Esto es crucial para cumplir con los requisitos de conformidad; por ejemplo, proteger PII o información financiera en el momento de la consulta sin duplicar los datos.

2.2 El Servicio de Búsqueda CORTEX

CORTEX Search de Snowflake está diseñado para admitir búsquedas difusas y casos de uso de RAG (Generación Aumentada por Recuperación) impulsados por LLM.

En la práctica:

• CORTEX se ejecuta bajo un rol con el privilegio CREATE CORTEX SEARCH SERVICE.
• Los usuarios no necesitan privilegios directos de SELECT en las tablas subyacentes.
• Un usuario puede consultar datos a través de CORTEX SEARCH siempre que tenga USAGE en el servicio.

2.3 DERECHOS DE LOS LLAMANTES vs DERECHOS DE LOS PROPIETARIOS

Uno de los conceptos más importantes en la seguridad de bases de datos es la diferencia entre derechos del llamante y derechos del propietario.

Derechos de quienes llaman: El proceso o la función se ejecuta con los mismos privilegios que el usuario que lo invoca. Si tienes privilegios limitados, las capacidades de la función estarán igualmente limitadas.

Ejemplo del mundo real: Piensa en un usuario común en una herramienta de colaboración que no puede ver una carpeta privada. Cualquier script que ejecute desde su cuenta seguirá sin tener acceso a esa carpeta privada: está limitado por **sus** permisos.

Derechos del propietario: El proceso o función se ejecuta con los privilegios del propietario del objeto, sin importar quién lo llame. Si el propietario tiene privilegios elevados o de administrador, la función puede hacer cosas que la persona que la invoca normalmente no podría.

Ejemplo del mundo real: En algunos sistemas, como ciertas plataformas SaaS o procedimientos almacenados avanzados, una función se ejecuta con los permisos de un rol privilegiado (como un rol de administrador). Incluso si un usuario normal inicia la acción, el código se ejecuta con el acceso elevado del rol del servicio y puede leer o escribir datos a los que el usuario normalmente no tendría permiso de acceder.

En muchos sistemas de bases de datos, las funciones se ejecutan con los derechos del llamador para preservar el principio de privilegio mínimo. Sin embargo, en el escenario de CORTEX Search de Snowflake, como con otras funciones dentro de Snowflake, el código se ejecuta con los derechos del propietario del servicio—con frecuencia un rol poderoso como CORTEX_ROLE o incluso ACCOUNTADMIN. Eso significa que cualquiera que pueda invocar el servicio hereda los privilegios potencialmente de mayor nivel del propietario durante esa ejecución. Cuando se usan adecuadamente, las semánticas de derechos del propietario pueden facilitar la adherencia al principio de privilegio mínimo, como en el caso de las procedimientos almacenados, donde el propietario puede delegar tareas administrativas específicas, como limpiar datos antiguos, a otro rol (el llamador) sin otorgarle a ese rol privilegios más generales, como privilegios para eliminar todos los datos de una tabla específica. Para Cortex Search, esto podría ayudar a proporcionar acceso a columnas seleccionadas de una tabla sin otorgar acceso a toda la tabla.

Por qué esto importa:

• Si a CORTEX Search (o a cualquier servicio con estado) se le otorga un acceso amplio a los datos (derechos de propietario), entonces cualquier usuario que pueda invocarlo obtiene un acceso de lectura similar al del propietario que creó el índice. Incluso si no tienen privilegio SELECT directo en una tabla, pueden recuperar datos sin enmascarar porque la consulta se ejecuta como el propietario.
• En cambio, si un servicio usara los derechos del que llama, solo devolvería los datos que el usuario real tiene permiso de ver, manteniendo intactos el enmascaramiento dinámico y los controles de acceso.

Entonces, dado que CORTEX Search utiliza los derechos del propietario, en la práctica “toma prestados” todos los privilegios del rol bajo el cual se está ejecutando, lo que potencialmente permite que un usuario con menos privilegios tenga acceso de lectura a los datos indexados. El uso de esta función por parte de un administrador que no esté familiarizado con estos detalles puede resultar en una divulgación no intencional de información dentro de la cuenta de Snowflake de la empresa.

3. Desglose técnico

Paso 1: Crear el servicio de búsqueda CORTEX con AccountAdmin

Tú, como accountadmin, configuras el Servicio de Búsqueda CORTEX para permitir que analyst_user consulte la tabla salary_info. El servicio se inicializa con el rol accountadmin, que tiene acceso completo a todos los datos del entorno.

Visual 1: Video de creación del servicio CORTEX con AccountAdmin

Paso 2: Conceder permisos a analyst_user

A continuación, concedes a analyst_user los permisos necesarios para usar el Servicio de Búsqueda CORTEX.

Visual 2: Foto de subvenciones otorgadas a analyst_user

En este punto, todo parece estar bien. Sin embargo, el accountadmin podría tener la impresión incorrecta de que analyst_user puede usar el Servicio de Búsqueda CORTEX para interactuar con la tabla utilizando sus propias (de analyst_user) permisos.

Paso 3: Explotar la configuración

Ahora, analyst_user intenta consultar directamente la tabla salary_info,

Como era de esperarse, estos datos regresan enmascarados.

Pero entonces, analyst_user intenta otra cosa: utiliza el Servicio de Búsqueda de CORTEX para consultar la misma tabla:

‍DEMO COMPLETA

Demostración completa que muestra todo el proceso, desde crear el servicio de búsqueda de Cortex hasta usarlo y omitir la política de enmascaramiento

4. Solución: Evitar que la IA se extralimite

Sin embargo, los administradores de cuentas de Snowflake pueden evitar esta clase de comportamiento.

Para usuarios de Snowflake (tú):

✅ No implementes CORTEX Search con roles altamente privilegiados como ACCOUNTADMIN a menos que tengas la intención de otorgar tus derechos a los usuarios de CORTEX Search. Usa un rol de servicio con el menor privilegio posible con solo el acceso SELECT mínimo necesario.

✅ Aísla las tablas sensibles de los servicios de búsqueda de propósito general. Si una tabla tiene políticas de enmascaramiento o datos relevantes para el cumplimiento, no indexes las columnas con esos datos sensibles en un servicio de Cortex Search.

✅ Ten cuidado con las concesiones de USAGE en el Servicio de Búsqueda de Cortex: si eres el propietario, cualquier rol al que le concedas USAGE en el servicio podrá acceder a todo su contenido materializado

✅ Audita el uso de roles: Verifica periódicamente qué rol se usó para crear cada CORTEX Search Service. Si el creador tenía acceso completo a tablas sensibles, considera revocar o reconstruir el servicio.

Conclusión: Los servicios de IA como CORTEX Search, si están mal configurados, pueden provocar la divulgación no intencional de información. Sin una delimitación cuidadosa, podrían permitir que usuarios con pocos privilegios atraviesen silenciosamente los muros de enmascaramiento y recuperen datos sensibles, sin necesitar permiso de SELECT.

El principio de privilegio mínimo debe aplicarse a la IA, ya que la IA no solo ve tus datos, también habla.

5. Conclusión: Los servicios de IA no están por encima de los controles de acceso

CORTEX Search es una potente herramienta impulsada por IA que lleva la búsqueda en lenguaje natural a datos empresariales no estructurados. Sin embargo, este poder debe usarse responsablemente. Como se demostró, CORTEX Search se ejecuta con derechos del propietario, no del solicitante, lo que significa que ejecuta las consultas utilizando los permisos del rol con privilegios que creó el servicio, no del usuario que lo está llamando.

En este caso, es posible que no se cumplan los resultados y capacidades esperados del mecanismo de enmascaramiento dinámico de Snowflake. Una columna enmascarada solo se enmascara cuando se aplica el control de acceso. Si está mal configurado, CORTEX puede permitir que un usuario evite SELECT y aun así vea valores en texto claro.

En efecto, la IA puede convertirse en un canal involuntario para exponer datos dentro de una organización. Por eso Cyera es importante: te ayuda a descubrir, clasificar y proteger automáticamente los datos sensibles almacenados en tu entorno. En lugar de adivinar o pasar horas revisando manualmente, sabrás exactamente qué hay, qué tan sensible es y si está en riesgo.

Divulgación responsable y respuesta del proveedor

Este problema se divulgó de manera responsable al equipo de Snowflake, quienes respondieron con prontitud y profesionalismo. En colaboración con sus equipos de seguridad y producto, ya se implementaron mitigaciones iniciales en forma de actualizaciones a la documentación del servicio CORTEX Search para aclarar las implicaciones de los derechos ejecutados por el propietario. Hay más mejoras en camino, incluyendo ofrecer contexto de ejecución con derechos del llamante para casos de uso específicos de Snowflake y advertencias mejoradas en la interfaz para administradores, a fin de prevenir configuraciones incorrectas no intencionales. Agradecemos la participación de Snowflake y su compromiso con fortalecer la postura de seguridad de la plataforma.

Cyera está lista para ayudarte a proteger tus datos con DSPM y DLP. Comienza hoy con una demo.