Comportement inattendu dans Cortex AI de Snowflake

1. Introduction

L'IA est partout, mais à quel prix ?

L'IA s'infiltre dans tous les recoins de la technologie, des chatbots dans les outils d'analyse commerciale aux modèles génératifs qui alimentent la découverte de données. Ces innovations offrent des efficacités incroyables et une croissance commerciale florissante, mais elles apportent également des pièges de sécurité inexplorés. Un risque particulièrement préoccupant est l'exposition inattendue des données. Qu'il s'agisse de M365 Co-Pilot, Snowflake Cortex AI ou tout autre service d'IA, votre sécurité n'est que le reflet des politiques d'accès que vous avez configurées.

Dans cet article, nous examinerons comment le CORTEX Search Service de Snowflake, un outil de recherche et de récupération de pointe basé sur l'IA, pourrait finir par exposer des données sensibles au sein de votre base d'utilisateurs Snowflake, même dans un environnement sécurisé avec des politiques d'accès et de masquage strictement configurées.

À la fin de l'article, nous expliquons comment Cyera peut aider à se protéger contre ce problème. Si vous avez besoin d'aide supplémentaire, n'hésitez pas à nous contacter à l'adresse suivante : support@cyera.com.

Nous tenons à remercier toute l'équipe Snowflake pour leur transparence, leur réactivité et leur collaboration tout au long du processus, nous apprécions vraiment leur soutien.

2. Cas d'utilisation : Utilisation abusive de CORTEX Search pour afficher des données sensibles

2.1 Masquage dynamique dans Snowflake

Le masquage dynamique des données est la méthode de Snowflake pour restreindre la façon dont les données sont présentées, en fonction de la personne qui les interroge. Généralement, vous définissez une politique de masquage sur les colonnes sensibles, comme ceci :

• ADMIN voit les données réelles (val).
• Tout le monde voit des données masquées (*****).

Ceci est crucial pour respecter les exigences de conformité, par exemple en protégeant les informations personnelles identifiables (PII) ou les données financières au moment de la requête, sans dupliquer les données.

2.2 Le service de recherche CORTEX

Le CORTEX Search de Snowflake est conçu pour prendre en charge la recherche approximative et les cas d'utilisation RAG (Retrieval Augmented Generation) basés sur les LLM.

En pratique :

• CORTEX fonctionne sous un rôle ayant le privilège CRÉER UN SERVICE DE RECHERCHE CORTEX.
• Les utilisateurs n'ont pas besoin de privilèges SELECT directs sur les tables sous-jacentes.
• Un utilisateur peut interroger des données via CORTEX SEARCH tant qu'il dispose des droits d'USAGE sur le service.

2.3 DROITS DES APPELANTS vs DROITS DES PROPRIÉTAIRES

L'un des concepts les plus importants en matière de sécurité des bases de données est la différence entre les droits de l'appelant et les droits du propriétaire.

Droits des appelants : Le processus ou la fonction s’exécute avec les mêmes privilèges que l’utilisateur qui l’invoque. Si vous disposez de privilèges limités, les capacités de la fonction seront également limitées.

Exemple concret : Imaginez un utilisateur ordinaire dans un outil de collaboration qui ne peut pas voir un dossier privé. Tout script qu'il exécute depuis son compte n'aura toujours pas accès à ce dossier privé — il est limité par **ses** droits.

Droits du propriétaire : Le processus ou la fonction s'exécute avec les privilèges du propriétaire de l'objet, indépendamment de qui l'appelle. Si le propriétaire dispose de privilèges élevés ou d'administrateur, la fonction peut effectuer des actions que l'appelant lui-même ne peut normalement pas faire.

Exemple concret : Dans certains systèmes, comme certaines plateformes SaaS ou procédures stockées avancées, une fonctionnalité s'exécute avec les autorisations d'un rôle privilégié (comme un rôle d'administrateur). Même si un utilisateur ordinaire initie l'action, le code s'exécute avec l'accès élevé du rôle de service et peut lire ou écrire des données auxquelles l'utilisateur ne serait normalement pas autorisé à accéder.

Dans de nombreux systèmes de bases de données, les fonctionnalités s’exécutent avec les droits de l’appelant afin de préserver le principe du moindre privilège. Cependant, dans le scénario CORTEX Search de Snowflake, comme pour d’autres fonctionnalités de Snowflake, le code s’exécute avec les droits du propriétaire du service—souvent un rôle puissant tel que CORTEX_ROLE ou même ACCOUNTADMIN. Cela signifie que toute personne pouvant appeler le service hérite des privilèges, potentiellement plus élevés, du propriétaire pendant cette exécution. Lorsqu’ils sont utilisés de manière appropriée, les droits du propriétaire peuvent faciliter le respect du principe du moindre privilège, comme dans le cas des procédures stockées, où le propriétaire peut déléguer des tâches administratives spécifiques, telles que le nettoyage des anciennes données, à un autre rôle (l’appelant) sans accorder à ce rôle des privilèges plus généraux, comme le droit de supprimer toutes les données d’une table spécifique. Pour Cortex Search, cela pourrait permettre de donner accès à certaines colonnes d’une table sans accorder l’accès à l’ensemble de la table.

Pourquoi c'est important :

• Si CORTEX Search (ou tout autre service à état) dispose d’un accès étendu aux données (droits de propriétaire), alors tout utilisateur pouvant l’invoquer obtient un accès en lecture similaire à celui du propriétaire ayant créé l’index. Même s’ils ne disposent pas du privilège SELECT direct sur une table, ils peuvent récupérer des données non masquées car la requête s’exécute en tant que propriétaire.
• En revanche, si un service utilisait les droits des appelants, il ne renverrait que les données que l'utilisateur réel est autorisé à voir, préservant ainsi le masquage dynamique et les contrôles d'accès.

Ainsi, comme CORTEX Search utilise les droits des propriétaires, il « emprunte » effectivement tous les privilèges du rôle sous lequel il s’exécute, ce qui peut potentiellement permettre à un utilisateur ayant moins de privilèges d’accéder en lecture aux données indexées. L’utilisation de cette fonctionnalité par un administrateur qui ne connaît pas ces détails peut entraîner une divulgation involontaire d’informations au sein du compte Snowflake de l’entreprise.

3. Analyse technique

Étape 1 : Création du service de recherche CORTEX avec AccountAdmin

Vous, en tant que accountadmin, configurez le service de recherche CORTEX afin de permettre à analyst_user d'interroger la table salary_info. Le service est initialisé avec le rôle accountadmin, qui dispose d'un accès complet à toutes les données de l'environnement.

Visuel 1 : Vidéo de création du service CORTEX avec AccountAdmin

Étape 2 : Accorder des autorisations à analyst_user

Ensuite, vous accordez à analyst_user les autorisations nécessaires pour utiliser le Service de Recherche CORTEX.

Visuel 2 : Photo des autorisations accordées à analyst_user

À ce stade, tout semble fonctionner correctement. Cependant, l'administrateur du compte pourrait avoir l'impression erronée que analyst_user peut utiliser le Service de Recherche CORTEX pour interagir avec la table en utilisant ses propres autorisations (analyst_user).

Étape 3 : Exploiter la configuration

Maintenant, analyst_user essaie d'interroger directement la table salary_info,

Sans surprise, ces données sont renvoyées masquées.

Mais ensuite, analyst_user essaie autre chose—ils utilisent le Service de Recherche CORTEX pour interroger la même table :

‍DÉMO COMPLÈTE

Démonstration complète montrant la progression entière depuis la création du service de recherche cortex jusqu'à son utilisation et le contournement de la politique de masquage

4. Solution : Empêcher l'IA d'aller trop loin

Cependant, les administrateurs de compte Snowflake peuvent éviter ce type de comportement.

Pour les utilisateurs de Snowflake (vous) :

✅ Ne déployez pas CORTEX Search avec des rôles hautement privilégiés comme ACCOUNTADMIN, sauf si vous avez l'intention de conférer vos droits aux utilisateurs de CORTEX Search. Utilisez un rôle de service avec le minimum de privilèges avec uniquement l'accès SELECT minimal nécessaire.

✅ Isolez les tables sensibles des services de recherche à usage général. Si une table contient des politiques de masquage ou des données soumises à la conformité, n’indexez pas les colonnes contenant ces données sensibles dans un service Cortex Search.

✅ Faites attention aux autorisations USAGE sur le service Cortex Search - si vous en êtes le propriétaire, tout rôle auquel vous accordez l'autorisation USAGE sur le service pourra accéder à l'ensemble de ses contenus matérialisés.

✅ Audit de l'utilisation des rôles : Vérifiez périodiquement quel rôle a été utilisé pour créer chaque service de recherche CORTEX. Si le créateur avait un accès complet aux tables sensibles, envisagez de révoquer ou de reconstruire le service.

En résumé : Les services d’IA comme CORTEX Search, s’ils sont mal configurés, peuvent entraîner une divulgation involontaire d’informations. Sans une délimitation rigoureuse, ils pourraient permettre à des utilisateurs faiblement privilégiés de contourner discrètement les mécanismes de masquage et d’accéder à des données sensibles, sans qu’aucune autorisation SELECT ne soit requise.

Le principe du moindre privilège doit s'appliquer à l'IA, car l'IA ne fait pas que voir vos données, elle parle aussi.

5. Conclusion : les services d'IA ne sont pas au-dessus des contrôles d'accès

CORTEX Search est un outil puissant basé sur l’IA qui permet la recherche en langage naturel dans les données d’entreprise non structurées. Cependant, cette puissance doit être utilisée de manière responsable. Comme démontré, CORTEX Search fonctionne avec les droits des propriétaires, et non ceux des appelants, ce qui signifie qu’il exécute les requêtes en utilisant les autorisations du rôle privilégié ayant créé le service, et non celles de l’utilisateur qui l’appelle.

Dans ce cas, les résultats attendus et les capacités du mécanisme de masquage dynamique de Snowflake peuvent ne pas être réalisés. Une colonne masquée n'est masquée que lorsque le contrôle d'accès est appliqué. Si mal configuré, CORTEX peut permettre à un utilisateur de contourner SELECT et de voir quand même les valeurs en texte clair.

En effet, l'IA peut devenir un canal involontaire d'exposition des données au sein d'une organisation. C'est pourquoi Cyera est important : il vous aide à découvrir, classifier et protéger automatiquement les données sensibles stockées dans votre environnement. Au lieu de deviner ou de passer des heures à tout examiner manuellement, vous saurez exactement ce qui s'y trouve, à quel point c'est sensible et si c'est à risque.

Divulgation responsable et réponse du fournisseur

Ce problème a été divulgué de manière responsable à l'équipe Snowflake, qui a réagi rapidement et avec professionnalisme. En collaboration avec leurs équipes de sécurité et de produit, des mesures d'atténuation initiales ont déjà été mises en place sous la forme de mises à jour de la documentation du service CORTEX Search afin de clarifier les implications des droits exécutés par le propriétaire. D'autres améliorations sont en cours, notamment la mise à disposition d'un contexte d'exécution des droits de l'appelant pour certains cas d'utilisation Snowflake et des avertissements UI renforcés pour les administrateurs afin d'éviter toute mauvaise configuration involontaire. Nous saluons l'engagement de Snowflake et son implication à renforcer la sécurité de la plateforme.

Cyera est prêt à vous aider à protéger vos données avec DSPM et DLP. Commencez dès aujourd'hui avec une démo.