La campagne de vol d'identifiants de Snowflake et les limites de la responsabilité partagée

Résumé

• Périmètre confirmé de la campagne:Mandiant a attribué une campagne à motivation financière à UNC5537 et indiqué que tous les incidents de cette campagne traités directement par Mandiant provenaient d'identifiants clients compromis. L'enquête n'a révélé aucune preuve que l'accès non autorisé aux comptes clients résultait d'une compromission de l'environnement d'entreprise de Snowflake. Snowflake a également déclaré n'avoir trouvé aucune preuve de vulnérabilité, de mauvaise configuration ou de compromission de sa plateforme à l'origine de cette activité.
• Chaîne de contrôle observée:Les comptes compromis ne disposaient pas d'authentification multifactorielle, utilisaient des identifiants exposés dans des historiques d'infostealers et n'avaient pas de listes d'autorisation réseau. Les attaquants ont ensuite utilisé les clients Snowflake pris en charge et des opérations SQL pour énumérer les données, les stocker temporairement, les compresser et les télécharger. Environ 165 organisations ont été notifiées comme potentiellement exposées; il ne s'agit pas d'un nombre de compromissions confirmées, de personnes ou d'enregistrements.
• Constat sur la responsabilité partagée:Les clients contrôlaient leurs utilisateurs, leurs rôles, la rotation des mots de passe, l'activation de l'authentification multifactorielle, les stratégies réseau, l'hygiène des terminaux et la minimisation des données. Snowflake contrôlait les protections disponibles, leur présentation et leurs valeurs par défaut, les signaux inter-clients que la plateforme pouvait observer, ainsi que la rapidité avec laquelle les avertissements et les comportements de base plus stricts atteignaient le parc installé. Ces responsabilités sont concurrentes et non mutuellement exclusives.
• Constat sur la souveraineté:Choisir une région Snowflake détermine l'emplacement du stockage et du calcul du compte; la documentation de Snowflake indique expressément que cela ne limite pas l'accès des utilisateurs. Dans cette campagne, une identité valide pouvait transformer un ensemble de données stocké régionalement en une copie téléchargée. La localisation des données sans contrôles d'identité, de sortie et de preuve constitue une décision de placement, et non un contrôle complet de souveraineté.

La plateforme n'a pas été compromise, mais la relation de service a été testée

La première discipline dans cette affaire est le vocabulaire. Une instance client Snowflake n'est pas la même chose que l'environnement d'entreprise de Snowflake ou la plateforme de production partagée. Une personne disposant d'identifiants valides pouvait pénétrer dans le compte d'un client sans traverser vers un autre locataire, exploiter une vulnérabilité logicielle, obtenir un compte administrateur du fournisseur ou briser l'infrastructure qui sépare les clients. Les preuves publiques étayent une compromission de compte client. Elles ne soutiennent pas une compromission technique à l'échelle de la plateforme.

Lerapport de campagne UNC5537 de Mandiantest inhabituellement direct sur ce point. Pour chaque incident associé à la campagne que Mandiant a traité, la cause première était des identifiants clients compromis. Son enquête n'a trouvé aucune preuve que l'accès non autorisé aux comptes clients provenait d'une compromission de l'environnement d'entreprise de Snowflake. L'avis d'enquête et de renforcement de Snowflakea également séparé les comptes clients ciblés de la plateforme de production et a fourni aux clients des requêtes et des indicateurs pour enquêter sur leurs propres environnements. La CISA a amplifié ces conseils dans unealerte du 3 juin 2024.

Ce constat négatif est important. Qualifier l'événement de compromission de la plateforme Snowflake peut impliquer qu'un défaut dans le code ou l'infrastructure partagée a ouvert tous les locataires, ou que Snowflake a perdu un identifiant maître qui déverrouillait les clients. Les archives examinées n'établissent ni l'un ni l'autre. Cela obscurcirait également les mesures que les clients devaient prendre immédiatement: identifier les utilisateurs avec mot de passe seul, faire tourner les identifiants, inspecter l'historique de connexion et de requêtes, restreindre les réseaux, réduire les privilèges des rôles et préserver les preuves.

L'erreur inverse consiste à traiter l'absence de compromission de la plateforme comme l'absence de question de responsabilité du fournisseur. Un service cloud n'est pas simplement un disque neutre sur lequel un client place des bits. Snowflake a construit et exploité les points de terminaison d'authentification qui acceptaient les identifiants, les interfaces que les attaquants utilisaient, le moteur de requête qui exécutait leurs commandes, la télémétrie qui enregistrait les sessions et les contrôles produits qui auraient pu exiger un second facteur ou restreindre l'origine réseau.

Snowflake avait également une visibilité inter-clients qu'aucun client individuel ne pouvait posséder. Le fait qu'un contrôle décisif était configurable par le client détermine qui avait le devoir opérationnel de le configurer. Cela ne répond pas à la question de savoir si les valeurs par défaut, les avertissements, la détection et l'application du fournisseur étaient proportionnels à la concentration de données sur son service.

Leformulaire 10-Kde Snowflake pour l'exercice 2025 formalise sa position. Il indique que Snowflake est responsable de la sécurité de la plateforme et de l'infrastructure cloud sous-jacente, tandis que les clients sélectionnent et configurent les contrôles pour leurs environnements. Il attribue l'accès de mai 2024 au non-respect par les clients de leurs obligations telles que l'authentification multifactorielle et les stratégies réseau, tout en enregistrant des poursuites judiciaires, des enquêtes réglementaires, des demandes de législateurs, des atteintes à la réputation et la possibilité de litiges en responsabilité. Il s'agit de preuves matérielles de la position déclarée de Snowflake et de son exposition commerciale. Cela ne constitue pas une décision indépendante selon laquelle toute responsabilité ou réclamation légale incombe au client.

La question utile est donc plus étroite que « Qui a été compromis? » et plus large que « Qui a perdu son mot de passe? ». Elle est la suivante: à chaque étape, du secret volé aux données téléchargées, quel acteur pouvait empêcher, détecter, interrompre, reconstruire ou avertir de l'action? La responsabilité suit le contrôle sur ces étapes.

La campagne a relié d'anciens vols sur terminaux à des droits d'accès cloud actuels

Mandiant a d'abord obtenu des renseignements sur les menaces en avril 2024 concernant des enregistrements de base de données qui ont ensuite été reliés à une instance Snowflake victime. Cette victime a engagé Mandiant, qui a conclu que l'intrus avait utilisé des identifiants précédemment volés par un infostealer. Le compte concerné n'avait pas l'authentification multifactorielle activée. Le 22 mai, après avoir identifié des renseignements indiquant une campagne plus large, Mandiant a contacté Snowflake et a commencé à informer les victimes potentielles.

Snowflake a publié des conseils de détection et de renforcement pour les clients le 30 mai. Au moment du rapport de juin, Mandiant et Snowflake avaient informé environ 165 organisations potentiellement exposées.

Chaque terme de cette dernière phrase doit être protégé contre toute exagération. « Environ » indique une estimation. « Potentiellement exposées » décrit une population de notification, pas 165 conclusions d'enquête achevées. « Organisations » ne signifie pas comptes, bases de données, personnes ou enregistrements. Certaines organisations peuvent exploiter plusieurs comptes Snowflake, et un compte peut contenir des données sur une population beaucoup plus large. Le rapport ne fournit pas de total à l'échelle de la campagne pour les organisations confirmées, les personnes touchées, les octets exportés ou les paiements d'extorsion.

L'historique des identifiants explique pourquoi une connexion cloud en 2024 pouvait commencer par une infection de terminal des années plus tôt. Mandiant a constaté que la plupart des identifiants utilisés par UNC5537 étaient présents dans les résultats historiques d'infostealers, l'infection la plus ancienne associée ayant été observée en novembre 2020. Au moins 79,7 % des comptes exploités par l'acteur avaient fait l'objet d'une exposition antérieure d'identifiants. Ce pourcentage s'applique aux comptes utilisés par l'acteur dans la campagne analysée, et non à tous les clients Snowflake ou aux 165 organisations informées.

Trois conditions ont transformé à plusieurs reprises des secrets exposés en accès fonctionnel. Les comptes touchés n'étaient pas configurés avec l'authentification multifactorielle. Les mots de passe trouvés dans les enregistrements d'infostealers restaient valides, parfois pendant des années. Les instances client concernées ne disposaient pas de listes d'autorisation réseau qui auraient restreint les connexions à des origines de confiance. Aucune de ces conditions n'est une nouvelle exploitation.

Ensemble, elles formaient un chemin d'autorisation durable: connaître le localisateur de compte, le nom d'utilisateur et le mot de passe encore valide; se connecter depuis un système contrôlé par l'attaquant; recevoir une session; hériter du rôle attribué; interroger tout ce que ce rôle peut lire.

La dimension des terminaux était également plus distribuée que ne le suggère le récit conventionnel des ordinateurs portables des employés. Dans plusieurs enquêtes, Mandiant a trouvé l'infection antérieure par infostealer sur des systèmes de sous-traitants qui étaient également utilisés pour des activités personnelles, notamment des jeux ou des téléchargements piratés. Un appareil de sous-traitant peut se trouver en dehors du parc de terminaux géré par le client tout en transportant des identifiants pour plusieurs clients.

Il peut également contenir un compte administratif, car les sous-traitants spécialisés sont souvent engagés pour construire ou exploiter des plateformes de données. Le client qui a créé l'utilisateur reste responsable de l'identité et de ses privilèges, mais l'exposition peut être invisible pour les outils de gestion des terminaux du client.

Ceci est un multiplicateur de dépendance cloud. L'identifiant est volé sur un terminal, peut-être en dehors à la fois du parc de Snowflake et de celui du propriétaire des données. L'identifiant est accepté par un service mondial. Le rôle peut atteindre un entrepôt consolidé contenant des années d'enregistrements provenant de plusieurs systèmes d'entreprise. L'attaquant n'a plus besoin de compromettre ces systèmes sources un par un. La valeur analytique qui rendait l'entrepôt utile au client a également rendu l'accès réussi précieux pour un acteur de l'extorsion.

Les attaquants portent la responsabilité directe du vol, de l'achat, du test et de l'utilisation d'identifiants; de l'entrée dans les environnements clients sans autorisation; de la prise de données; et de la tentative de vente ou d'extorsion. Décrire les défaillances de contrôle qui ont rendu ces crimes possibles ne dilue pas cette responsabilité. Cela explique pourquoi la même technique criminelle a réussi à grande échelle et où la récurrence peut être réduite.

Des fonctionnalités prises en charge sont devenues un chemin d'exfiltration

La campagne ne s'est pas arrêtée à l'authentification. Mandiant a observé des accès via Snowsight, SnowSQL, des pilotes et des outils de base de données. L'acteur a listé les utilisateurs, les rôles, les sessions, les noms d'organisation, les bases de données, les schémas et les tables. Il a utilisé des opérations SQL familières pour sélectionner des données, créer des étapes temporaires, copier la sortie de requête dans des fichiers compressés et récupérer ces fichiers sur une machine locale. Dans plusieurs cas, des commandes similaires sont apparues dans différents environnements clients.

Cette séquence rend l'incident lisible comme l'utilisation de fonctionnalités ordinaires sous une identité non autorisée:

1. Un nom d'utilisateur et un mot de passe clients valides ont établi une session.
2. La session a hérité des rôles et des privilèges d'objet attribués par le client.
3. La reconnaissance a identifié des tables précieuses et des étapes disponibles.
4. Des requêtes ont sélectionné les enregistrements que le rôle était autorisé à lire.
5. Le staging temporaire etCOPY INTOont converti les résultats en fichiers téléchargeables.
6. GETa déplacé les fichiers vers un client contrôlé par l'attaquant.

Aucune étape de cette chaîne n'a nécessité de dysfonctionnement de la base de données. C'est pourquoi le chiffrement au repos, bien que nécessaire, n'était pas le contrôle décisif. Ladocumentation de Snowflake sur le chiffrement de bout en boutindique que les données clients sont chiffrées au repos et sous TLS en transit, mais elle explique également que Snowflake déchiffre les données pendant les transformations ou les opérations sur les tables, et permet aux utilisateurs de décharger et de télécharger les résultats. Le chiffrement protège les fichiers et le transport contre les parties qui n'ont pas d'autorisation ou de clés. Il n'empêche pas une identité acceptée avec un rôle autorisé de demander au service de renvoyer des résultats lisibles.

Le même principe s'applique aux clés gérées par le client. Le contrôle des clés peut répondre aux scénarios de fournisseur, de stockage et de révocation, mais un compte en cours d'exécution doit utiliser sa hiérarchie de clés pour servir les requêtes autorisées. À moins qu'une stratégie de clé ne soit connectée à une décision distincte rejetant la session ou l'opération, la base de données ne peut pas distinguer le propriétaire du compte d'un intrus qui a satisfait à la politique d'authentification configurée par le propriétaire.

La conception des rôles contrôlait donc le rayon après la connexion. Lemodèle de contrôle d'accès actuelde Snowflake prend en charge les contrôles d'accès basés sur les rôles et discrétionnaires, la propriété, la hiérarchie des rôles et les privilèges d'objet. Un identifiant attribué uniquement à une base de données ou une vue étroite présente une conséquence différente de celui titulaire d'unACCOUNTADMIN, d'une large utilisation d'entrepôt ou d'un accès sélectif à des ensembles de données brutes. Un compte de service utilisé par une intégration ne doit pas hériter de la portée exploratoire d'un administrateur humain. Le rôle temporaire d'un sous-traitant doit expirer avec l'engagement plutôt que de rester dormant avec un mot de passe valide.

Les politiques de protection des données peuvent réduire le résultat même lorsqu'un rôle est compromis. Ladocumentation de Snowflake sur la classification des données sensiblesrelie la découverte de colonnes personnelles et sensibles aux politiques de masquage et d'accès aux lignes. Il s'agit d'une description des capacités actuelles, et non d'une preuve que chaque client touché avait classifié ou masqué ses données en 2024. Elle pose la question de conception: le client a-t-il exposé des tables historiques complètes à des identités qui n'avaient besoin que d'agrégats, de partitions récentes, de champs tokenisés ou de vues approuvées?

L'exportation est elle-même une fonction commerciale privilégiée et doit être gouvernée comme telle. Un entrepôt de données a souvent besoin de déchargements en masse pour des pipelines légitimes, des sauvegardes, l'entraînement de modèles et des systèmes en aval. Une interdiction générale est rarement réaliste.

Mais la création d'une étape, le déchargement d'un résultat inhabituellement volumineux ou l'utilisation d'un client et d'une origine réseau inconnus doivent être observables et, pour les ensembles de données à haut risque, peuvent justifier une approbation, des limitations de débit, des restrictions de destination, une élévation de courte durée ou un rôle d'exportation distinct. Les commandes de la campagne étaient suffisamment normales pour s'exécuter, mais suffisamment inhabituelles en contexte pour mériter une décision de sécurité rapide.

Le client détenait le paramètre; Snowflake détenait la base de référence

L'authentification multifactorielle est le test le plus pointu de la responsabilité partagée, car les deux parties peuvent énoncer un fait vrai. L'administrateur client était capable et censé l'activer. Snowflake proposait l'authentification multifactorielle depuis 2015 et les stratégies réseau depuis 2016. En même temps, les comptes réussis de 2024 pouvaient s'authentifier sans authentification multifactorielle, ce qui signifie que la base de référence effective du service autorisait un chemin par mot de passe seul pour ces comptes.

La différence entre disponibilité et application n'est pas sémantique. Une fonction de sécurité peut être gratuite, documentée, recommandée, et toujours absente des sessions qui comptent. Les administrateurs font face à d'anciennes intégrations, des utilisateurs de service non interactifs, des sous-traitants, des comptes de secours, de multiples clients et la peur du verrouillage. Ces contraintes expliquent les frictions d'adoption; elles ne justifient pas de laisser un accès humain privilégié dépendre d'un mot de passe réutilisable.

Elles donnent également au fournisseur les informations nécessaires pour construire des outils de migration, séparer les identités humaines et de service, et rendre les exceptions explicites.

Après la campagne, la direction publique de Snowflake est passée de la recommandation à des valeurs par défaut plus strictes. Sonannonce de l'engagement Secure by Designde juillet 2024 a mis l'accent sur les contrôles de politique d'authentification multifactorielle et les vérifications du Trust Center. En septembre 2024, Snowflake a déclaré quel'authentification multifactorielle serait appliquée par défautpour les utilisateurs humains dans les comptes créés à partir d'octobre 2024, tout en recommandant l'authentification unique (SSO) avec authentification multifactorielle du fournisseur d'identité pour les humains et OAuth ou l'authentification par paire de clés pour les services. La distinction entre les nouveaux comptes et les comptes existants est importante. Une valeur par défaut sécurisée protège la création future; elle ne retire pas automatiquement chaque chemin de mot de passe hérité dans le parc installé.

Snowflake a introduit par la suite laprotection des mots de passe divulgués, qui utilise des flux de renseignements sur les menaces pour tester les mots de passe divulgués signalés dans un processus préservant la confidentialité et désactiver un mot de passe lorsqu'il est confirmé comme encore valide. Ce contrôle côté fournisseur répond directement à l'un des avantages d'UNC5537: d'anciens identifiants d'infostealers restés utilisables. C'est également la preuve que la responsabilité partagée peut évoluer. Les clients doivent toujours gérer les identités et les rotations, mais le fournisseur peut utiliser l'intelligence inter-services pour faire cesser de fonctionner un mot de passe volé avant que chaque client ne le trouve indépendamment.

Ladocumentation actuelle sur les politiques d'authentificationpermet aux administrateurs de contrôler les méthodes et les clients autorisés et d'exiger l'authentification multifactorielle au niveau du compte ou de l'utilisateur. Elle avertit également que les restrictions de type de client sont au mieux un effort et ne doivent pas être la seule frontière de sécurité. Lesconseils actuels sur l'authentification par paire de clésoffrent aux utilisateurs de service une alternative aux mots de passe statiques. Ces pages décrivent des capacités disponibles d'ici 2026; il ne faut pas les lire rétroactivement comme une preuve des fonctionnalités exactes, des valeurs par défaut ou de l'état d'application pour chaque client en avril 2024.

Les normes aident à expliquer pourquoi les valeurs par défaut du fournisseur doivent être incluses dans l'analyse. Lesconseils actuels du NIST sur l'authentification et la gestion des authentifiantstraitent les mots de passe comme non résistants à la relecture et définissent la résistance au phishing comme une propriété du protocole qui ne dépend pas de la vigilance de l'utilisateur. L'engagement Secure by Design de la CISAde 2024 identifie spécifiquement l'authentification multifactorielle par défaut, les incitations persistantes du produit, le support SSO de base et la publication de mesures d'adoption comme des moyens par lesquels les fabricants de logiciels peuvent augmenter de manière mesurable l'utilisation de l'authentification multifactorielle. Snowflake a signé cet engagement volontaire après la campagne. L'engagement n'est pas un verdict juridique sur la conception de Snowflake en 2024, mais il rejette l'idée que proposer une case à cocher épuise le rôle du fournisseur.

La base de référence responsable distingue les types d'identité. Les administrateurs humains doivent utiliser une authentification multifactorielle résistante au phishing ou une identité fédérée fortement gouvernée. Les charges de travail de service doivent utiliser des identifiants de charge de travail qui peuvent être délimités, tournés et attribués sans prétendre qu'un robot peut répondre à une notification push. L'accès de secours doit être rare, surveillé, limité dans le temps et testé.

Les identités des sous-traitants doivent avoir un propriétaire, une expiration, une posture de dispositif approuvée et aucune réutilisation d'identifiants entre clients. Chaque exception doit apparaître dans un tableau de bord dont le dénominateur est toutes les identités, et non seulement les employés actifs.

La stratégie réseau était une deuxième porte, non un substitut à l'identité

Le troisième facteur récurrent de Mandiant était l'absence de listes d'autorisation réseau. Un identifiant valide pouvait donc être utilisé à partir d'une infrastructure qui n'avait aucune raison commerciale d'atteindre l'entrepôt du client. Les restrictions réseau ne répareraient pas un mot de passe volé, mais elles pourraient rendre ce mot de passe insuffisant à partir d'une origine non fiable.

Ladocumentation actuelle de Snowflake sur les stratégies réseaurend la valeur par défaut explicite: sans stratégie, les utilisateurs peuvent se connecter depuis n'importe quel ordinateur ou appareil. Les clients peuvent autoriser ou bloquer des plages d'adresses IP et des points de terminaison privés, appliquer des contrôles au niveau du compte ou de l'utilisateur, et restreindre l'accès aux étapes internes avec une configuration supplémentaire. La connectivité privée et les contrôles d'accès publics peuvent encore renforcer les comptes à haute sensibilité.

Le client connaît ses bureaux approuvés, ses charges de travail cloud, ses VPN, ses sous-traitants et ses points de terminaison d'intégration, donc le client doit définir la liste d'autorisation utilisable. Snowflake ne peut pas déduire chaque origine légitime sans perturber les activités. Pourtant, le fournisseur contrôle la portée par défaut, la syntaxe de la stratégie, la capacité de simuler un changement, la protection contre le verrouillage, la journalisation et le fait qu'un administrateur soit averti lorsqu'aucune stratégie de compte n'existe.

Une plateforme peut préserver le choix du client tout en rendant l'accès public illimité une exception visible et limitée dans le temps plutôt qu'un état stationnaire silencieux.

Les règles réseau ont également des limites. Les attaquants peuvent obtenir une session à partir d'un appareil de sous-traitant approuvé, passer par un VPN d'entreprise autorisé, compromettre une charge de travail à l'intérieur du cloud autorisé, ou voler un jeton après l'authentification. Les grandes entreprises peuvent avoir des adresses de sortie changeantes qui rendent les listes statiques difficiles. La connectivité privée peut exclure les outils SaaS qui ne la prennent pas en charge. Ce sont des raisons d'associer les contrôles réseau à une identité forte et à la détection de comportement, non des raisons de les omettre.

La campagne démontre la valeur de portes indépendantes. La rotation des mots de passe aurait invalidé les identifiants historiques. L'authentification multifactorielle aurait exigé un autre facteur. Une stratégie réseau aurait rejeté les origines inconnues. Le moindre privilège aurait réduit les données visibles. Les contrôles d'exportation auraient pu interrompre le staging. La détection aurait pu raccourcir le temps de présence. Aucune mesure unique n'est parfaite; l'attaquant a réussi là où plusieurs étaient simultanément absentes ou permissives.

Pour la responsabilité, chaque porte a besoin d'un propriétaire et d'une mesure d'efficacité. « Stratégie réseau prise en charge » est un fait produit. « Chaque compte de production a une stratégie testée couvrant le service et les étapes internes » est un résultat opérationnel. « Authentification multifactorielle disponible » est un fait produit. « Aucun humain privilégié ne peut établir une session avec un mot de passe réutilisable seul » est un résultat. La responsabilité partagée ne devient significative que lorsque les deux parties peuvent démontrer les résultats à leur frontière.

Le fournisseur a vu une campagne que chaque client ne pouvait voir que comme un incident

Un client individuel pouvait inspecter ses propres connexions réussies et échouées, les clients, les adresses IP, le texte des requêtes, les rôles, les étapes et les mouvements de données. Snowflake pouvait corréler les motifs entre les comptes: la même infrastructure, des clients inhabituels, des reconnaissances répétées, des commandes de staging similaires, une augmentation des connexions par mot de passe seul, ou des identifiants correspondant à des flux de renseignements sur les menaces. Cette asymétrie est la responsabilité non contractuelle la plus importante du fournisseur. Elle est créée par l'exploitation du service à grande échelle.

Lavue LOGIN_HISTORYactuelle de Snowflake conserve un an de tentatives de connexion et inclut l'utilisateur, l'adresse IP d'origine, le client signalé, les premier et second facteurs, le succès et des détails de risque connexes, avec une latence documentée.QUERY_HISTORYconserve un an d'activité de requête et relie une requête à l'événement d'authentification, à la session, à l'utilisateur, au rôle, au texte, aux octets de résultat, aux lignes déchargées et aux octets envoyés sur le réseau. Les clients d'entreprise peuvent utiliserACCESS_HISTORYpour reconstruire les tables, vues, colonnes, étapes, politiques et objets modifiés consultés. Ces schémas fournissent la matière première pour une enquête de haute qualité.

L'historique brut n'est pas la même chose que la détection. Un client doit accorder l'accès aux analystes, exporter ou interroger les données, comprendre le comportement normal, écrire des alertes, les acheminer, les conserver au-delà des fenêtres natives si nécessaire, et doter une équipe d'intervention. Une latence de télémétrie de deux heures peut être acceptable pour un examen rétrospectif mais trop lente pour certaines décisions d'exportation en masse. Une limite d'édition Enterprise sur l'historique d'accès au niveau des colonnes peut également affecter la précision avec laquelle un client peut évaluer l'exposition.

Ces faits sur les produits et l'exploitation doivent être testés lors de l'approvisionnement, et non découverts après un vol.

LeTrust Centeractuel de Snowflake vérifie l'inscription à l'authentification multifactorielle, la stratégie réseau du compte, les rôles privilégiés, les utilisateurs dormants, les connexions à risque, les adresses IP inhabituelles et les transferts de données volumineux au moyen de scanners de sécurité et de renseignements sur les menaces. La documentation actuelle indique également des limitations: certains packages doivent être activés; certaines détections peuvent arriver dans l'heure; et l'existence d'une stratégie configurée ne prouve pas que son contenu atteint l'objectif visé. Encore une fois, la capacité actuelle n'est pas une preuve de ce qu'un client donné ou Snowflake a détecté au printemps 2024. Elle montre ce qu'un fournisseur peut transformer en produit une fois qu'un schéma de défaillance inter-clients est compris.

Le système d'alerte doit fonctionner sur deux couches. À la couche du locataire, les clients ont besoin d'événements immédiats et exportables et de contrôles pour bloquer ou suspendre l'activité. À la couche du fournisseur, Snowflake a besoin d'analyses de campagne et d'un processus éprouvé pour informer les clients avec suffisamment de preuves pour agir.

Une notification utile comprend les identifiants de compte et d'utilisateur, les horodatages en UTC, l'infrastructure source, le facteur d'authentification, les identifiants de session et de requête, les commandes, les objets et colonnes touchés, les actions de staging, le volume de transfert estimé, le statut de confinement et la confiance. « Potentiellement exposé » n'est une étiquette d'ouverture appropriée que si elle est suivie des preuves nécessaires pour résoudre le potentiel.

L'intervention du fournisseur nécessite également une gouvernance. Bloquer automatiquement une session client peut interrompre la production et peut dépasser l'autorité contractuelle du fournisseur. Ne pas agir peut permettre la poursuite du vol. La conception doit donc définir à l'avance les seuils de risque, les suspensions temporaires, les canaux d'escalade client, les contacts d'urgence et un processus de dérogation rapide. Les clients doivent désigner des personnes capables de recevoir une alerte de gravité élevée à toute heure et d'autoriser la suspension.

Le fournisseur doit mesurer le temps entre le signal inter-comptes et le contact client, le temps jusqu'au confinement et la proportion de clients notifiés pouvant récupérer un dossier de preuves complet.

La localité des données n'a pas rendu l'accès local

Snowflake commercialise et documente le déploiement régional parce que les clients ont des exigences de latence, de résilience, de confidentialité, de réglementation et de souveraineté. Ladocumentation de Snowflake sur les régions prises en chargeindique que chaque compte est hébergé dans une région et que les données restent dans cette région à moins que les utilisateurs ne les copient, déplacent ou répliquent explicitement. La même page contient la limite critique: les régions dictent où les données sont stockées et le calcul provisionné; elles ne limitent pas l'accès des utilisateurs à Snowflake.

Cette distinction transforme la chaîne UNC5537 en un cas de souveraineté. Avant l'intrusion, les tables d'un client pouvaient être stockées et traitées dans un pays ou un emplacement cloud régional sélectionné. Après une authentification réussie, l'attaquant pouvait interroger le compte régional depuis ailleurs, stocker temporairement les résultats et les télécharger sur un client. Mandiant a observé le schéma technique de récupération locale à partir d'étapes temporaires.

Les archives publiques de la campagne n'établissent pas le pays source, le pays de destination ou le statut légal du transfert pour chaque victime, de sorte qu'aucune allégation universelle de transfert transfrontalier illégal n'est fondée. L'architecture montre néanmoins que la localité de stockage seule ne pouvait pas imposer la localité de l'utilisateur.

Le partage et la réplication inter-régions créent un chemin de mouvement légitime distinct. Lesconseils de Snowflake sur le partage inter-régionsindiquent aux organisations de confirmer les restrictions légales et réglementaires avant de répliquer des données vers une région ou un pays différent. Il s'agit d'un mouvement planifié sous l'administration du client. L'exportation basée sur les identifiants est différente: elle peut créer une copie incontrôlée en dehors de l'environnement sélectionné sans modifier l'emplacement du compte source. Un inventaire de données qui n'enregistre que la région source continuera d'indiquer « UE » ou « Canada » même après qu'un attaquant a retiré une copie.

La souveraineté des données a donc au moins quatre couches:

• Placement:où les ressources de stockage et de calcul faisant autorité sont provisionnées.
• Accès:quelles identités humaines et machines peuvent se connecter, à partir de quels appareils, réseaux et juridictions.
• Mouvement:quelles requêtes, déchargements, partages, réplications, connecteurs et téléchargements peuvent créer une autre copie.
• Preuve et recours:si l'organisation peut prouver d'où l'accès a eu lieu, ce qui a quitté, quelles personnes ou enregistrements réglementés étaient impliqués, et avec quelle rapidité elle peut contenir et notifier.

Le fournisseur contrôle des parties importantes des quatre couches même lorsque le client choisit la politique. Il offre des régions et y conserve les données de compte. Il authentifie les demandes et expose les contrôles réseau. Il exécute les commandes d'exportation et enregistre les métadonnées des requêtes. Il détient une visibilité inter-clients sur les menaces et peut désactiver les mots de passe divulgués. Le client décide de sa base légale, des catégories de données, des rôles, des origines autorisées, du masquage, de la conservation et des mouvements approuvés.

Un engagement d'hébergement régional sans ces contrôles complémentaires peut satisfaire une exigence étroite de localisation du centre de données tout en laissant l'autorité pratique de copier les données exposée mondialement.

C'est également pourquoi le chiffrement et la souveraineté ne doivent pas être confondus. Le chiffrement peut protéger un objet stocké de l'opérateur d'infrastructure ou d'un lecteur non autorisé de la couche de stockage. Une application qui doit analyser l'objet rend nécessairement les données disponibles dans un contexte de requête autorisé. Si l'assurance de l'identité et la portée du rôle sont faibles, la localité cryptographique peut coexister avec l'exfiltration opérationnelle.

Les divulgations des clients montrent des conséquences différentes, pas une compromission uniforme

La campagne est souvent décrite à travers des noms de clients éminents, mais les archives publiques de chaque client ont leur propre portée, dates, données, terminologie et confiance. Il est dangereux de transférer les faits d'une entreprise à une autre ou de convertir une déclaration d'un forum criminel en une population vérifiée.

Leformulaire 8-Kde Live Nation du 31 mai 2024 indiquait avoir identifié une activité non autorisée le 20 mai dans un environnement de base de données cloud tiers contenant des données de l'entreprise, principalement de Ticketmaster. Il indiquait que le 27 mai un acteur criminel avait proposé à la vente ce qu'il prétendait être des données d'utilisateurs de l'entreprise, et que Live Nation informait les forces de l'ordre, les régulateurs et les utilisateurs selon ce qui était approprié. La déclaration ne nommait pas Snowflake, ne fournissait pas de nombre confirmé de personnes touchées et n'expliquait pas le chemin d'authentification.

Lapage d'incidentde Ticketmaster Canada donne un niveau de détail différent. Elle décrit un accès non autorisé à une base de données cloud isolée hébergée par un fournisseur de services de données tiers, indique que la base de données contenait des informations personnelles limitées de certains acheteurs de billets nord-américains, et liste les champs possibles incluant le courriel, le numéro de téléphone, des informations de carte cryptées et d'autres informations fournies par les clients. Elle indique que les comptes clients Ticketmaster n'ont pas été touchés. Cette dernière limite est importante: la compromission d'un entrepôt de données dorsal ne prouve pas que l'attaquant a obtenu les identifiants Ticketmaster de chaque personne ou pouvait effectuer des transactions via le compte consommateur.

Lafiche d'information parlementairedu Commissariat à la protection de la vie privée du Canada d'octobre 2025 identifie Snowflake comme le fournisseur tiers utilisé par Ticketmaster, donne une fenêtre d'incident du 2 avril au 18 mai 2024 pour Ticketmaster Canada, et indique que des informations personnelles de millions de personnes, y compris des Canadiens, étaient impliquées. Elle indique également que l'enquête restait ouverte et que Ticketmaster Canada, en tant que responsable du traitement en vertu de la LPRPDE, était l'entité faisant l'objet de l'enquête. Il s'agit d'un contexte réglementaire utile, mais pas d'une conclusion définitive qui résout la question de l'adéquation des garanties, du moment de la notification ou de la responsabilité.

Leformulaire 8-Kd'AT&T du 12 juillet 2024 illustre pourquoi les limites des sources sont importantes même lorsque les incidents sont discutés ensemble. AT&T a déclaré qu'un acteur avait illégalement accédé à un espace de travail AT&T sur une plateforme cloud tierce et exfiltré des fichiers du 14 avril au 25 avril. Les fichiers contenaient des enregistrements d'interactions d'appels et de messages texte pour presque tous les clients sans fil d'AT&T et les clients d'opérateurs de réseau mobile virtuels concernés pour des périodes spécifiées en 2022 et un jour en 2023. AT&T a déclaré que les fichiers ne contenaient pas le contenu des appels ou des messages, les numéros de sécurité sociale, les dates de naissance ou d'autres informations personnelles selon la définition d'AT&T. La déclaration elle-même ne nomme pas Snowflake ou UNC5537. Elle étaye les faits de l'incident d'AT&T, et non une attribution de campagne en soi.

Ces archives donnent quatre règles de discipline. Premièrement, utiliser la déclaration d'un client uniquement pour ce client. Deuxièmement, distinguer une base de données, un compte organisationnel et une connexion consommateur. Troisièmement, distinguer les champs de données du nombre de personnes qu'ils représentent. Quatrièmement, préserver les faits négatifs tels que « aucun contenu de message » ou « compte consommateur non touché » à côté de l'impact. La responsabilité devient moins crédible lorsque l'analyse étend les affirmations dramatiques et omet les limitantes.

Les clients restaient responsables des données et des identités qu'ils déléguaient

Le côté client de la responsabilité partagée est substantiel. L'organisation a créé ou approuvé les utilisateurs Snowflake, sélectionné les chemins d'authentification, attribué les rôles, chargé les données, conservé l'historique, choisi une région, activé les intégrations et décidé quels employés et sous-traitants pouvaient interroger l'entrepôt. Elle détenait également la relation principale avec les personnes représentées dans ses données et conservait généralement les obligations de responsable du traitement en vertu de la loi applicable sur la protection de la vie privée.

Un client aurait pu interrompre la campagne observée à plusieurs points. Il pouvait faire tourner les mots de passe après une exposition du terminal, interdire les comptes de service avec mot de passe seul, exiger l'authentification multifactorielle pour les humains, fédérer l'accès via un fournisseur d'identité gouverné, restreindre les réseaux, faire expirer les utilisateurs sous-traitants, réduire les attributions de rôles, classifier et masquer les champs sensibles, isoler le privilège d'exportation, surveiller l'historique de connexion et de requêtes, et répéter les notifications des fournisseurs cloud.

Pour les ensembles de données réglementés ou à fort impact, ce sont des obligations opérationnelles de base, et non des améliorations optionnelles déléguées à l'approvisionnement.

La gouvernance des terminaux et des sous-traitants mérite une attention particulière. Un utilisateur ayant un rôle cloud à fort impact ne doit pas s'authentifier depuis un ordinateur personnel non géré. Les sous-traitants doivent utiliser des bureaux virtuels ou des appareils contrôlés par le client avec surveillance des terminaux lorsque cela est possible. Leur identité doit être unique par client, liée à un parrain et expirer automatiquement.

L'organisation doit rechercher les flux d'exposition d'identifiants pour les motifs de ses comptes Snowflake et forcer la rotation lorsque des preuves apparaissent, sans attendre une utilisation abusive confirmée.

Le moindre privilège doit être testé par rapport aux données, et non à l'intitulé du poste. « Analyste » peut sembler non administratif tout en conservant un accès sélectif à chaque ligne d'une table de clients, d'employés ou de transactions. Un examen des rôles doit demander quelles lignes et colonnes peuvent être renvoyées, si les identifiants bruts sont nécessaires, si les ensembles de résultats en masse peuvent être écrits dans des étapes et si l'identité peut créer de nouveaux identifiants ou intégrations. Des requêtes d'exemple sous le rôle sont une preuve plus solide qu'un nom de rôle à l'apparence propre.

Les clients sont également propriétaires de la préparation à la réponse. Ils doivent être capables de faire correspondre un utilisateur Snowflake à un employé ou un sous-traitant, une requête à des personnes concernées touchées, et une exportation à une juridiction et une analyse de notification. Les historiques natifs d'un an peuvent être insuffisants pour une conservation légale plus longue ou une découverte différée, de sorte que les clients à haut risque doivent diffuser les événements pertinents vers un magasin de sécurité indépendant.

Les alertes du fournisseur ont besoin d'un chemin testé vers l'équipe de sécurité du client, le bureau de la protection de la vie privée, le propriétaire commercial et le décideur exécutif.

Leguide de la chaîne d'approvisionnement du cadre de cybersécurité du NISTrecommande de définir et de communiquer les exigences des fournisseurs en fonction de la criticité. Appliqué ici, un client Snowflake doit contracter pour le moment de la notification d'incident, les champs de preuves, la conservation, l'escalade du support, le traitement régional, la visibilité des sous-traitants, l'avis de changement de contrôle et l'accès à l'assurance. Il doit également maintenir un plan de sortie ou d'isolement pour les fonctions de données dont la perte ou la compromission serait intolérable. La responsabilité partagée doit être écrite comme des interfaces testables, et non un paragraphe qui n'apparaît qu'après un incident.

Snowflake restait responsable de la réduction des risques au niveau du service

Snowflake ne contrôlait pas le malware sur l'appareil personnel d'un sous-traitant ou la décision du client de laisser l'authentification multifactorielle désactivée. Il contrôlait si un ancien mot de passe pouvait rester le seul facteur, si les origines illimitées étaient la valeur par défaut silencieuse, si les configurations risquées produisaient des avertissements persistants et ce que le fournisseur faisait après avoir observé un schéma entre les clients.

La responsabilité du fournisseur dans cette affaire comporte six parties.

Base de référence sécurisée.L'accès humain privilégié ne doit pas dépendre d'un mot de passe réutilisable seul. Les identités de service doivent avoir un type distinct et des méthodes sans mot de passe prises en charge. Les nouvelles valeurs par défaut doivent atteindre les comptes à haut risque existants par une application progressive, des exceptions explicites et une aide à la migration plutôt que de protéger uniquement les nouveaux locataires.

Visibilité de la configuration.Le fournisseur doit montrer aux administrateurs de sécurité un dénominateur complet: les humains sans authentification multifactorielle, les utilisateurs de service existants avec mots de passe, les comptes dormants, les utilisateurs sans restrictions réseau, les rôles privilégiés et les comptes autorisant l'entrée publique. Les constats doivent être visibles au niveau de l'organisation et exportables pour l'audit.

Détection inter-clients.L'infrastructure réutilisée, les identifiants divulgués, les clients inhabituels, les séquences de reconnaissance, la création d'étapes temporaires et les grandes exportations peuvent former un signal de campagne. Le fournisseur doit détecter au niveau du service, contacter les victimes probables et définir quand une activité de haute confiance déclenche un blocage temporaire.

Télémétrie exploitable.Les clients ont besoin de preuves d'authentification, de requête, d'objet, d'étape et de transfert avec une conservation suffisante et une latence assez faible pour contenir un vol actif. Des preuves de plus haute fidélité ne doivent pas devenir indisponibles précisément là où le service stocke les données les plus importantes.

Avertissement et coordination.Une alerte client doit passer par un itinéraire d'urgence connu et contenir des preuves, pas seulement des conseils pour examiner les journaux. Le fournisseur doit suivre l'accusé de réception, le confinement et l'exposition récurrente, et il doit soutenir les demandes des forces de l'ordre et des régulateurs sans réduire les observations incertaines en nombres de victimes confirmés.

Vérification post-incident.Les fonctionnalités et les valeurs par défaut annoncées ont besoin de mesures d'adoption et d'efficacité. Les modifications ultérieures de Snowflake vers l'authentification multifactorielle par défaut, la désactivation des mots de passe divulgués, les résultats du Trust Center et des types d'identité plus forts traitent le chemin observé. La question de responsabilité restante est la couverture: quels utilisateurs et clients sont réellement protégés, quelles exceptions demeurent et à quelle fréquence un contrôle arrête-t-il une tentative réelle ou simulée?

Cette répartition ne fait pas de Snowflake le responsable du traitement pour chaque ensemble de données client, ni ne rend le fournisseur responsable de chaque configuration client. Elle reconnaît qu'une entreprise de cloud profite de la concentration des données et de l'exploitation d'une frontière de sécurité. L'échelle crée des obligations que seul le fournisseur peut remplir, en particulier la corrélation entre locataires et l'ingénierie de base.

Les litiges ultérieurs testent la même frontière sans encore la résoudre

Snowflake et les entreprises touchées ont fait face à des litiges civils consolidés après les incidents. Dans uneordonnance d'un tribunal fédéraldu 29 octobre 2025, le tribunal de district du Montana a jugé que les plaignants du secteur financier avaient suffisamment plaidé certaines théories de négligence à l'encontre de Snowflake et de Ticketmaster pour survivre aux motions de rejet. Le tribunal a traité l'authentification multifactorielle par défaut alléguée et la prévisibilité comme pertinentes pour le devoir, la violation et le lien de causalité à ce stade procédural.

Cette ordonnance n'est pas une constatation de première instance selon laquelle Snowflake ou Ticketmaster était négligent. Sur une motion de rejet, le tribunal vérifie si les allégations bien plaidées énoncent une demande plausible; il ne résout pas les preuves contestées, ne détermine pas le mécanisme d'incident final pour chaque plaignant et n'alloue pas de dommages-intérêts. Snowflake a contesté les allégations et fait valoir que les manquements des clients à mettre en œuvre l'authentification multifactorielle, les stratégies réseau et d'autres garanties ont causé le préjudice.

L'ordonnance est significative parce qu'elle montre que décrire l'authentification multifactorielle comme un paramètre client n'a pas automatiquement mis fin à toute réclamation de devoir du fournisseur. Elle ne remplace pas le dossier final sur le fond.

L'enquête canadienne sur la protection de la vie privée comportait une répartition différente. Le Commissariat à la protection de la vie privée a déclaré que Ticketmaster Canada restait le responsable du traitement et l'entité sous enquête, tandis que le bureau a contacté Snowflake pour obtenir des informations. Cela reflète un principe commun de protection de la vie privée: l'externalisation du stockage n'externalise pas le devoir du responsable du traitement de protéger et de notifier. Cela ne signifie pas que le fournisseur de services n'a pas de devoirs contractuels, techniques ou légaux propres.

Le propre 10-K de Snowflake a reconnu de nombreuses poursuites, enquêtes réglementaires et demandes de législateurs, mais n'a pas rapporté de répartition finale universelle de la responsabilité. À la date de publication, les sources publiques examinées ici ne soutiennent pas l'affirmation selon laquelle Snowflake a été légalement exonéré, que chaque client était légalement en faute ou qu'un tribunal ou un régulateur final a adopté la répartition opérationnelle de cet article.

La responsabilité opérationnelle peut être évaluée avant la responsabilité finale. L'accès par mot de passe seul était-il prévisible? Oui. Le client pouvait-il exiger l'authentification multifactorielle et des stratégies réseau? Oui. Snowflake pouvait-il concevoir des valeurs par défaut et détecter l'activité inter-clients? Oui. Les criminels ont-ils intentionnellement exploité le chemin résultant? Oui. Ces propositions peuvent coexister.

La responsabilité délictuelle, contractuelle, en matière de protection de la vie privée et des valeurs mobilières peut attribuer des conséquences différemment selon la juridiction et le plaignant, mais l'ingénierie ne doit pas attendre qu'un slogan l'emporte.

Un test mesurable de responsabilité partagée

La réponse la plus forte n'est pas un autre schéma avec « client » d'un côté et « fournisseur » de l'autre. C'est un ensemble de contrôles dont la couverture et le comportement en cas d'échec peuvent être démontrés.

Les conseils d'administration doivent recevoir des résultats plutôt que des inventaires de fonctionnalités.

Les mesures utiles comprennent le pourcentage d'utilisateurs humains protégés par une authentification multifactorielle résistante au phishing, le nombre d'utilisateurs de service capables d'utiliser un mot de passe, l'âge de chaque exception de secours, le pourcentage de comptes avec des stratégies réseau testées, le nombre d'identités de sous-traitants privilégiés au-delà de l'expiration, le temps médian d'alerte sur les origines inconnues, le temps pour suspendre une session de haute confiance et le temps pour produire un dossier d'exposition au niveau des champs.

Snowflake devrait publier des progrès agrégés là où il peut le faire sans exposer les clients. L'engagement de la CISA envisage explicitement des statistiques d'adoption par utilisateur et type d'authentification multifactorielle. Une déclaration selon laquelle l'authentification multifactorielle est disponible est moins informative que la distribution des connexions par mot de passe seul au fil du temps. Une déclaration selon laquelle le Trust Center est activé est moins informative que le nombre de constatations critiques restant ouvertes au-delà d'une période définie.

Une déclaration selon laquelle des clients suspects ont été notifiés est moins informative que la latence de notification et l'exhaustivité du dossier de preuves.

Les clients doivent exiger la même rigueur d'eux-mêmes. Un fournisseur ne peut pas sauver une organisation qui crée des rôles larges, ignore les constatations, conserve les anciens utilisateurs sous-traitants et n'a personne pour répondre au contact d'urgence. L'objectif de valeurs par défaut plus strictes n'est pas de transférer la propriété de la sécurité du client à Snowflake. C'est de rendre les omissions prévisibles moins susceptibles de devenir un vol massif de données.

Ce que les archives publiques n'établissent toujours pas

Les preuves sont assez solides pour reconstituer un schéma de campagne, mais pas chaque incident victime.

Les archives publiques n'identifient pas toutes les organisations notifiées, ne confirment pas que les 165 ont subi un accès non autorisé, ni ne fournissent un total final à l'échelle de la campagne pour les personnes touchées, les tables, les enregistrements ou les octets téléchargés. Elles ne montrent pas quelles victimes ont payé des demandes d'extorsion ni si la suppression promise a eu lieu.

Elles ne publient pas le type d'utilisateur, la hiérarchie des rôles, l'historique d'authentification multifactorielle, la configuration réseau, le propriétaire du terminal, la séquence de session, les colonnes consultées ou le volume d'exportation pour chaque organisation. Les constatations sur les appareils de sous-traitants provenant de plusieurs enquêtes ne doivent pas être attribuées à chaque victime. La statistique de 79,7 % d'exposition d'identifiants ne doit pas être transformée en pourcentage de victimes.

Elles n'établissent pas de vulnérabilité logicielle, d'échappement entre locataires, de compromission de la plateforme de production de Snowflake, de vol d'un identifiant maître du fournisseur ou d'accès à tous les clients Snowflake. L'utilisation observée de clients et de commandes pris en charge est une preuve d'abus d'identifiants, et non une preuve que le code du produit a été exploité.

Elles ne prouvent pas que les données régionales ont franchi une frontière nationale dans chaque incident. L'architecture permettait l'accès à distance et le téléchargement local; l'analyse légale du transfert nécessiterait des faits sur la source, la destination, la personne concernée, le contrat et la juridiction pour chaque client.

Elles ne permettent pas de généraliser les champs possibles de Ticketmaster, la portée des détails d'appels d'AT&T ou tout décompte de forum criminel à d'autres clients. La déclaration de Live Nation n'a pas nommé Snowflake. La déclaration d'AT&T n'a pas nommé Snowflake ou UNC5537. Une association externe peut être pertinente pour une enquête plus approfondie, mais les déclarations doivent être citées pour ce qu'elles établissent réellement.

Enfin, la documentation actuelle de Snowflake ne prouve pas le fonctionnement des contrôles en avril et mai 2024. L'authentification multifactorielle par défaut ultérieure, la protection des mots de passe divulgués, la détection du Trust Center, les politiques d'authentification et les changements d'identité peuvent réduire la récurrence, mais les preuves publiques d'adoption, de couverture des exceptions, de performance de détection et d'efficacité indépendante restent plus limitées que les descriptions des fonctionnalités.

La responsabilité partagée doit survivre au moment où une recommandation est ignorée

La campagne Snowflake n'est pas mieux comprise comme un concours entre deux histoires absolues. Une histoire dit que la plateforme a été piratée et que le fournisseur seul a échoué. Les preuves ne la soutiennent pas. L'autre dit que les clients ont perdu des mots de passe et que la question du fournisseur est donc close. C'est techniquement incomplet.

UNC5537 a trouvé une jonction évolutive entre la compromission des terminaux et la concentration cloud. Les mots de passe historiques restaient valides. Les identités humaines et de service n'étaient pas toujours séparées. Les portes de l'authentification multifactorielle et du réseau étaient absentes. Les fonctions de requête et de staging prises en charge déplaçaient rapidement les données. Le fournisseur pouvait voir un schéma entre les locataires, tandis que chaque client ne voyait que son propre compte.

Une région de stockage choisie pouvait maintenir les données sources en place même si une session authentifiée créait une copie incontrôlée ailleurs.

Les clients avaient le devoir le plus clair de gouverner leurs utilisateurs, rôles, terminaux, sous-traitants et données. Snowflake avait le devoir le plus clair de sécuriser et d'observer la frontière de service, de rendre les protections à haute valeur faciles et de plus en plus inévitables, de détecter le comportement de campagne et de fournir des preuves. Les attaquants portaient la responsabilité directe des actes criminels. Les régulateurs et les tribunaux doivent évaluer les devoirs légaux sur la base des faits et du droit applicable à chaque organisation. Ces répartitions se chevauchent parce que les contrôles se chevauchent.

La direction produit post-campagne reconnaît implicitement l'écart entre la capacité et le résultat. L'authentification multifactorielle par défaut pour les nouveaux utilisateurs humains, la désactivation des mots de passe divulgués, une politique d'authentification plus stricte, la migration des utilisateurs de service et les résultats du Trust Center rapprochent la sécurité de la base de référence du fournisseur. Ils n'effacent pas la responsabilité du client. Ils rendent le système partagé moins dépendant de la capacité de chaque administrateur à trouver et activer chaque option correcte avant qu'un mot de passe volé ne soit testé.

C'est le test de responsabilité durable pour une plateforme de données cloud. Supposons qu'un client manquera un avertissement, qu'un appareil de sous-traitant sera infecté, qu'un identifiant restera valide et qu'un attaquant utilisera des fonctions produit ordinaires. Demandez ensuite si la valeur par défaut bloque la connexion, si une autre porte rejette l'origine, si le rôle révèle peu, si l'exportation déclenche une intervention et si les preuves parviennent au client à temps.

La responsabilité partagée n'est crédible que lorsque le service reste défendable après l'erreur prévisible d'une partie, et lorsque les deux parties peuvent prouver ce qu'elles ont fait avant et après.