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 a déclaré que chaque incident de la campagne qu'il a directement traité provenait de la compromission d'identifiants clients. Il n'a trouvé aucune preuve que l'accès non autorisé aux comptes clients résultait d'une brèche 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 brèche de sa plateforme à l'origine de ces activités.
• Chaîne de contrôle observée:Les comptes compromis n'avaient pas d'authentification multifacteur, conservaient des identifiants exposés dans des historiques de logiciels malveillants de type infostealer, et ne disposaient pas de listes d'autorisation réseau. Les attaquants ont ensuite utilisé des clients Snowflake pris en charge et des opérations SQL pour énumérer les données, les mettre en scène, 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 décompte de violations 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 multifacteur (MFA), les politiques réseau, l'hygiène des terminaux et la minimisation des données. Snowflake contrôlait quelles protections existaient, comment elles étaient présentées et définies par défaut, quels signaux inter-clients la plateforme pouvait voir, et la rapidité avec laquelle les avertissements et un comportement de base plus rigoureux atteignaient la base installée. Ces responsabilités sont concomitantes et non mutuellement exclusives.
• Constat sur la souveraineté:Le choix d'une région Snowflake détermine où sont situés le stockage et le 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 localité des données sans contrôles d'identité, de sortie et de preuve est une décision de placement, pas un contrôle complet de souveraineté.

La plateforme n'a pas été compromise, mais la relation de service a été mise à l'épreuve

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 propre de Snowflake ou la plateforme de production partagée. Une personne disposant d'identifiants valides pouvait entrer dans le compte d'un client sans passer dans un autre locataire, sans exploiter une vulnérabilité logicielle, sans obtenir un compte administrateur du fournisseur, ni briser l'infrastructure qui sépare les clients. Les preuves publiques étayent la compromission de comptes clients. Elles n'étayent 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é directement, la cause racine était la compromission d'identifiants clients. Son enquête n'a trouvé aucune preuve que l'accès non autorisé aux comptes clients provenait d'une brèche de l'environnement d'entreprise de Snowflake. L'avis d'enquête et de renforcement de Snowflakea de même 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.

Cette conclusion négative est importante. Qualifier l'événement de brèche de la plateforme de Snowflake peut laisser entendre qu'un défaut dans le code ou l'infrastructure partagés a ouvert tous les locataires, ou que Snowflake a perdu un identifiant maître qui déverrouillait les clients. Le dossier examiné n'établit ni l'un ni l'autre. Cela masquerait également les mesures que les clients devaient prendre immédiatement: identifier les utilisateurs avec mot de passe seul, procéder à la rotation des identifiants, inspecter l'historique des connexions et des 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 brèche 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 ont accepté les identifiants, les interfaces que les attaquants ont utilisées, le moteur de requête qui a traité leurs commandes, la télémétrie qui a enregistré les sessions, et les contrôles du produit qui auraient pu exiger un second facteur ou restreindre l'origine réseau. Snowflake disposait également d'une visibilité transversale sur les clients qu'aucun client individuel ne pouvait avoir. 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 paramètres par défaut, les avertissements, la détection et l'application par le fournisseur étaient proportionnels à la concentration de données sur son service.

Leformulaire 10-K de Snowflakepour l'exercice 2025 officialise 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 manquement des clients à remplir leurs obligations telles que l'authentification multifacteur (MFA) et les politiques réseau, tout en enregistrant des poursuites judiciaires, des enquêtes réglementaires, des demandes de législateurs, une atteinte à la réputation et la possibilité de litiges en matière d'indemnisation. Il s'agit d'une preuve matérielle de l'entreprise concernant le modèle déclaré de Snowflake et son exposition commerciale. Ce n'est 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é piraté? » et plus large que « Quel mot de passe a été volé? ». C'est: à 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é l'ancien vol de terminaux à l'autorité cloud actuelle

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é retracés jusqu'à une instance Snowflake d'une victime. Cette victime a engagé Mandiant, qui a conclu que l'intrus avait utilisé des identifiants précédemment volés par un logiciel malveillant de type infostealer. Le compte en question n'avait pas l'authentification multifacteur (MFA) activée. Le 22 mai, après avoir identifié des renseignements pointant vers une campagne plus large, Mandiant a contacté Snowflake et a commencé à notifier les victimes potentielles. Snowflake a publié des conseils de détection et de renforcement pour les clients le 30 mai. Dans le rapport de juin, Mandiant et Snowflake avaient notifié environ 165 organisations potentiellement exposées.

Chaque terme de cette dernière phrase doit être protégé de l'inflation. « Environ » indique une estimation. « Potentiellement exposées » décrit une population de notification, pas 165 conclusions d'enquête confirmé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 d'organisations confirmées, de personnes touchées, d'octets exportés ou de 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 des résultats historiques d'infostealers, la première infection associée ayant été observée en novembre 2020. Au moins 79,7 % des comptes exploités par l'acteur avaient une exposition antérieure d'identifiants. Ce pourcentage s'applique aux comptes utilisés par l'acteur dans la campagne analysée, pas à tous les clients Snowflake ni aux 165 organisations notifiées.

Trois conditions ont à plusieurs reprises transformé des secrets exposés en un accès fonctionnel. Les comptes impactés n'étaient pas configurés avec l'authentification multifacteur (MFA). 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 limiteraient les connexions à des origines de confiance. Aucune de ces conditions n'est un exploit inédit. 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 terminal était également plus distribuée que ce que suggère le récit habituel de l'ordinateur portable d'employé. Dans plusieurs enquêtes, Mandiant a trouvé l'infection antérieure par infostealer sur des systèmes de sous-traitants également utilisés pour une activité personnelle, y compris 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és par le client tout en transportant des identifiants pour plusieurs clients. Il peut également contenir un compte administrateur car des sous-traitants spécialisés sont souvent embauché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 propres outils de gestion des terminaux du client.

Il s'agit d'un multiplicateur de dépendance au cloud. L'identifiant est volé sur un terminal, peut-être en dehors du parc de Snowflake ou 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 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 d'extorsion.

Les attaquants portent la responsabilité directe du vol, de l'achat, du test et de l'utilisation des identifiants; de la pénétration dans les environnements clients sans autorisation; du prélèvement des données; et des tentatives 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 comment on peut réduire la récurrence.

Des fonctionnalités prises en charge sont devenues une voie 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 répertorié 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 connues pour sélectionner des données, créer des étapes temporaires, copier les résultats 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 une fonctionnalité ordinaire utilisée 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é les tables précieuses et les étapes disponibles.
4. Les requêtes ont sélectionné les enregistrements que le rôle était autorisé à lire.
5. La mise en scène 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é un 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 sur le chiffrement de bout en bout de Snowflakeindique que les données client sont chiffrées au repos et en transit via TLS, mais elle explique également que Snowflake déchiffre les données lors des transformations ou des 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 manquent 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 à des 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 politique de clé ne soit liée à une décision distincte qui rejette 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 actuel de Snowflakeprend 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 celle d'un identifiant détenantACCOUNTADMIN, une utilisation étendue de l'entrepôt ou un accès de sélection sur des ensembles de données brutes. Un compte de service utilisé par une intégration ne devrait pas hériter de la portée exploratoire d'un administrateur humain. Un rôle temporaire de sous-traitant devrait expirer avec la mission 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 sur la classification des données sensibles de Snowflakerelie la découverte de colonnes personnelles et sensibles à des politiques de masquage et d'accès aux lignes. Il s'agit d'une description des capacités actuelles, pas de la preuve que chaque client affecté avait classifié ou masqué ses données en 2024. Cela 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 métier privilégiée et devrait être régie comme telle. Un entrepôt de données a souvent besoin de déchargements en masse pour des pipelines légitimes, des sauvegardes, la formation 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 devraient être observables et, pour les ensembles de données à haut risque, peuvent justifier une approbation, des limites 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 être exécutées, mais suffisamment inhabituelles dans leur contexte pour mériter une décision de sécurité rapide.

Le client possédait le réglage; Snowflake possédait la base de référence

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

La différence entre disponibilité et application n'est pas sémantique. Une fonctionnalité de sécurité peut être gratuite, documentée, recommandée, et néanmoins absente des sessions qui comptent. Les administrateurs sont confrontés à d'anciennes intégrations, des utilisateurs de service non interactifs, des sous-traitants, des comptes de secours, plusieurs 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 fortes. Sonannonce d'engagement Secure by Design de juillet 2024a mis l'accent sur les contrôles de politique MFA et les vérifications du Centre de confiance. En septembre 2024, Snowflake a annoncé quela MFA 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 la MFA du fournisseur d'identité pour les humains et l'authentification OAuth ou par paire de clés pour les services. La distinction entre les comptes nouveaux et existants est importante. Une valeur par défaut sécurisée protège les créations futures; elle ne supprime pas automatiquement chaque chemin de mot de passe hérité dans la base installée.

Snowflake a ensuite introduit laprotection contre les mots de passe divulgués (Leaked Password Protection), qui utilise des flux de renseignements sur les menaces pour tester les mots de passe signalés comme divulgué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'infostealer qui restaient utilisables. C'est aussi 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 le renseignement inter-services pour rendre un mot de passe volé inopérant 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 clients autorisés et d'exiger l'authentification multifacteur au niveau du compte ou de l'utilisateur. Elle avertit également que les restrictions de type de client sont fournies au mieux et ne doivent pas être la seule limite de sécurité. Leguide actuel sur l'authentification par paire de clésoffre aux utilisateurs de service une alternative aux mots de passe statiques. Ces pages décrivent des capacités disponibles d'ici 2026; elles ne doivent pas être lues rétrospectivement comme la 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 font partie de l'analyse. Leguide actuel du NIST sur l'authentification et la gestion des authentifiantstraite les mots de passe comme non résistants à la relecture et définit la résistance au hameçonnage comme une propriété du protocole qui ne dépend pas de la vigilance de l'utilisateur. L'engagement Secure by Design de la CISA de 2024identifie spécifiquement l'authentification multifacteur par défaut, les nudges persistants du produit, le support de base de l'authentification unique (SSO) et la publication de mesures d'adoption comme des moyens pour les fabricants de logiciels d'augmenter de manière mesurable l'utilisation de l'authentification multifacteur. 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 le fait d'offrir une case à cocher épuise le rôle du fournisseur.

La base de référence responsable distingue les types d'identité. Les administrateurs humains devraient utiliser une authentification multifacteur résistante au hameçonnage ou une identité fédérée fortement régie. Les charges de travail de service devraient utiliser des identifiants de charge de travail qui peuvent être délimités, faire l'objet d'une rotation et être attribués sans prétendre qu'un robot peut répondre à une notification push. L'accès de secours devrait être rare, surveillé, limité dans le temps et testé. Les identités de sous-traitants devraient avoir un propriétaire, une date d'expiration, une posture d'appareil approuvée et aucune réutilisation d'identifiants entre clients. Chaque exception devrait apparaître dans un tableau de bord dont le dénominateur est toutes les identités, pas seulement les employés actifs.

La politique réseau était une seconde porte, pas 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 depuis une origine non fiable.

Ladocumentation actuelle sur les politiques réseau de Snowflakeexplicite la valeur par défaut: sans politique, 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 à l'étape interne avec une configuration supplémentaire. La connectivité privée et les contrôles d'accès public 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, c'est donc au client de 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 l'accessibilité par défaut, la syntaxe de la politique, la capacité à simuler un changement, la protection contre le verrouillage, la journalisation et le fait qu'un administrateur soit averti lorsqu'aucune politique de compte n'existe. Une plateforme peut préserver le choix du client tout en faisant de l'accès public non restreint une exception visible et limitée dans le temps plutôt qu'un état stable silencieux.

Les règles réseau ont aussi des limites. Les attaquants peuvent obtenir une session depuis 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, pas 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 multifacteur aurait exigé un autre facteur. Une politique 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 la mise en scène. 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é. « Politique réseau prise en charge » est un fait produit. « Chaque compte de production a une politique testée couvrant le service et les étapes internes » est un résultat opérationnel. « Authentification multifacteur disponible » est un fait produit. « Aucun humain privilégié ne peut établir une session avec un simple mot de passe réutilisable » est un résultat. La responsabilité partagée ne devient significative que lorsque les deux parties peuvent 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 des motifs entre les comptes: la même infrastructure, des clients inhabituels, des reconnaissances répétées, des commandes de mise en scène 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_HISTORY actuelle de Snowflakeconserve un an de tentatives de connexion et inclut l'utilisateur, l'adresse IP d'origine, le client déclaré, les premier et second facteurs, le succès et les détails de risque associés, avec une latence documentée. Lavue QUERY_HISTORYconserve un an d'activité de requêtes 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 Enterprise 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 autoriser l'accès aux analystes, exporter ou interroger les données, comprendre le comportement normal, rédiger des alertes, les router, les conserver au-delà des fenêtres natives si nécessaire et doter une réponse en personnel. 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 de l'édition Enterprise sur l'historique d'accès au niveau des colonnes peut également affecter la précision avec laquelle un client peut délimiter l'exposition. Ces faits sur le produit et l'exploitation devraient être testés lors de l'approvisionnement, et non découverts après un vol.

LeCentre de confiance actuel de Snowflakevérifie l'inscription à l'authentification multifacteur, la politique réseau du compte, les rôles privilégiés, les utilisateurs dormants, les connexions risquées, les adresses IP inhabituelles et les transferts de données volumineux par le biais d'analyseurs de sécurité et de renseignements sur les menaces. La documentation actuelle précise également les limitations: certains packages doivent être activés; certaines détections peuvent arriver dans un délai d'une heure; et l'existence d'une politique configurée ne prouve pas que son contenu atteint l'objectif visé. Là encore, la capacité actuelle ne prouve pas 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 modèle de défaillance inter-clients est compris.

Le système d'avertissement devrait fonctionner sur deux couches. Au niveau du locataire, les clients ont besoin d'événements immédiats et exportables et de contrôles pour bloquer ou suspendre l'activité. Au niveau du fournisseur, Snowflake a besoin d'analyses de campagne et d'un processus rodé pour notifier les clients avec suffisamment de preuves pour agir. Une notification utile inclut 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 mise en scène, le volume de transfert estimé, le statut de confinement et le niveau de confiance. « Potentiellement exposé » est une étiquette d'ouverture appropriée seulement si elle est suivie des preuves nécessaires pour résoudre le potentiel.

L'intervention du fournisseur doit également être régie. Le blocage automatique d'une session client peut interrompre la production et dépasser l'autorité contractuelle du fournisseur. Ne pas agir peut permettre la poursuite du vol. La conception devrait 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 devraient désigner des personnes capables de recevoir une alerte de haute gravité à toute heure et d'autoriser la suspension. Le fournisseur devrait mesurer le temps entre le signal inter-comptes et le contact client, le temps jusqu'au confinement et la proportion de clients notifiés qui peuvent 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 sur les régions prises en charge de Snowflakeindique 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 déterminent 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, mettre en scène les résultats et les télécharger vers un client. Mandiant a observé le modèle technique de récupération locale à partir d'étapes temporaires. Le dossier public de la campagne n'établit pas le pays source, le pays de destination ou le statut de transfert légal pour chaque victime, de sorte qu'aucune affirmation universelle de transfert transfrontalier illicite n'est étayée. L'architecture montre néanmoins que la seule localisation du stockage ne pouvait pas imposer la localisation de l'utilisateur.

Le partage et la réplication inter-régions créent un chemin de mouvement distinct et légitime. Leguide de partage inter-régions de Snowflakeindique aux organisations de confirmer les restrictions légales et réglementaires avant de répliquer des données vers une autre région ou un autre pays. 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 non contrôlée en dehors de l'environnement sélectionné sans changer 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, depuis 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.
• Preuves et recours:si l'organisation peut prouver d'où provient l'accès, ce qui est sorti, quelles personnes ou enregistrements réglementés ont été impliqués, et à quelle vitesse elle peut contenir et notifier.

Le fournisseur contrôle des parties importantes des quatre couches même lorsque le client choisit la politique. Il propose des régions et y conserve les données du compte. Il authentifie les requêtes 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é transversale 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 du mouvement approuvé. 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 exposée l'autorité pratique de copier les données à l'échelle mondiale.

C'est aussi 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 pour un contexte de requête autorisé. Si l'assurance de l'identité et la portée des rôles sont faibles, la localité cryptographique peut coexister avec une exfiltration opérationnelle.

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

La campagne est souvent décrite à travers des noms de clients éminents, mais le dossier public de chaque client a sa propre portée, ses dates, ses données, sa terminologie et son niveau de confiance. Il est imprudent de transférer les faits d'une entreprise à l'autre ou de convertir une affirmation d'un forum criminel en une population vérifiée.

Leformulaire 8-K de Live Nation du 31 mai 2024indiquait 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 précisait que le 27 mai, un acteur criminel avait mis en vente ce qu'il prétendait être des données d'utilisateurs de l'entreprise, et que Live Nation notifiait les forces de l'ordre, les régulateurs et les utilisateurs comme il se doit. Le dépôt ne nommait pas Snowflake, ne fournissait pas un nombre confirmé de personnes touchées, ni n'expliquait le chemin d'authentification.

Lapage d'incident de Ticketmaster Canadadonne 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 énumère les champs possibles incluant l'adresse courriel, le numéro de téléphone, les informations de carte cryptées et d'autres informations fournies par les clients. Elle précise que les comptes des 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 la connexion Ticketmaster de chaque personne ou pouvait effectuer des transactions via le compte consommateur.

Lafiche parlementaire d'octobre 2025 du Commissariat à la protection de la vie privée du Canadaidentifie 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, ont été impliquées. Elle précise é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é visée par l'enquête. Il s'agit d'un contexte réglementaire utile, mais pas d'une conclusion définitive qui tranche sur le caractère adéquat des garanties, le délai de notification ou la responsabilité.

Leformulaire 8-K d'AT&T du 12 juillet 2024illustre pourquoi les limites des sources comptent même lorsque les incidents sont discutés ensemble. AT&T a déclaré qu'un acteur avait accédé illégalement à un espace de travail AT&T sur une plateforme cloud tierce et avait exfiltré des fichiers du 14 au 25 avril. Les fichiers contenaient des enregistrements d'interactions d'appels et de SMS 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 telles que définies par AT&T. Le dépôt lui-même ne nomme pas Snowflake ou UNC5537. Il étaye les faits de l'incident d'AT&T, et non une attribution de campagne en soi.

Ces enregistrements donnent quatre règles de discipline. Premièrement, utiliser le dépôt d'un client pour ce client uniquement. 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 « pas de contenu de message » ou « compte consommateur non touché » à côté de l'impact. La responsabilité devient moins crédible lorsque l'analyse amplifie les affirmations dramatiques et abandonne celles qui limitent.

Les clients sont restés responsables des données et des identités qu'ils ont déléguées

Le volet client de la responsabilité partagée est substantiel. L'organisation a créé ou approuvé les utilisateurs Snowflake, sélectionné les méthodes 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 législation applicable en matière de protection de la vie privée.

Un client aurait pu interrompre la campagne observée à plusieurs points. Il pouvait procéder à la rotation des mots de passe après une exposition du terminal, interdire les comptes de service avec mot de passe seul, exiger l'authentification multifacteur pour les humains, fédérer l'accès via un fournisseur d'identité gouverné, restreindre les réseaux, expirer les utilisateurs sous-traitants, réduire les octrois de rôles, classifier et masquer les champs sensibles, isoler les privilèges d'exportation, surveiller l'historique des connexions et des requêtes, et répéter les notifications du fournisseur cloud. Pour les ensembles de données réglementés ou à fort impact, ce sont des obligations opérationnelles de base, pas des améliorations facultatives 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 devrait pas s'authentifier depuis un ordinateur personnel non géré. Les sous-traitants devraient utiliser des bureaux virtuels contrôlés par le client ou des appareils avec surveillance des terminaux lorsque cela est possible. Leur identité devrait être unique par client, liée à un répondant, et expirer automatiquement. L'organisation devrait rechercher dans les flux d'exposition d'identifiants les modèles de ses comptes Snowflake et forcer la rotation lorsque des preuves apparaissent, sans attendre une utilisation malveillante 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 de sélection à chaque ligne d'une table de clients, d'employés ou de transactions. Un examen des rôles devrait demander quelles lignes et colonnes peuvent être renvoyées, si des identifiants bruts sont nécessaires, si des ensembles de résultats volumineux peuvent être écrits dans des étapes, et si l'identité peut créer de nouveaux identifiants ou intégrations. Des requêtes exemples sous le rôle constituent une preuve plus solide qu'un nom de rôle à l'apparence propre.

Les clients possèdent également la préparation à la réponse. Ils devraient pouvoir faire correspondre un utilisateur Snowflake à un employé ou un sous-traitant, une requête aux personnes concernées par les données, et une exportation à une analyse de juridiction et de notification. Les historiques natifs d'un an peuvent être insuffisants pour une conservation légale plus longue ou une découverte tardive, de sorte que les clients à haut risque devraient 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 métier 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 devrait contracter pour le délai de notification d'incident, les champs de preuve, la conservation, l'escalade de support, le traitement régional, la visibilité sur les sous-traitants, l'avis de changement de contrôle et l'accès d'assurance. Il devrait é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 devrait être écrite sous forme d'interfaces testables, et non d'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 logiciel malveillant sur l'appareil personnel d'un sous-traitant ni la décision du client de laisser l'authentification multifacteur désactivée. Il contrôlait cependant si un ancien mot de passe pouvait rester le seul facteur, si les origines non restreintes é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 motif transversal entre clients.

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

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

Visibilité de la configuration.Le fournisseur devrait montrer aux administrateurs de sécurité un dénominateur complet: humains sans authentification multifacteur, utilisateurs de service avec mot de passe hérités, comptes dormants, utilisateurs sans restrictions réseau, rôles privilégiés et comptes autorisant l'entrée publique. Les résultats devraient être visibles au niveau de l'organisation et exportables pour 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 exportations volumineuses peuvent former un signal de campagne. Le fournisseur devrait détecter au niveau de la couche de service, contacter les victimes probables et définir quand une activité à 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 devraient pas devenir indisponibles précisément là où le service stocke les données à plus fort impact.

Avertissement et coordination.Une alerte client doit passer par un chemin d'urgence connu et transporter des preuves, pas simplement des conseils pour examiner les journaux. Le fournisseur devrait suivre l'accusé de réception, le confinement et l'exposition récurrente, et il devrait soutenir les demandes des forces de l'ordre et des régulateurs sans réduire des observations incertaines à des décomptes 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 multifacteur par défaut, la désactivation des mots de passe divulgués, les résultats du Centre de confiance et des types d'identité plus forts répondent au chemin observé. La question de responsabilité restante est la couverture: quels utilisateurs et clients sont effectivement protégés, quelles exceptions subsistent et à quelle fréquence un contrôle arrête 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 tire profit de la concentration des données et de l'exploitation d'une frontière de sécurité. L'échelle crée des devoirs que seul le fournisseur peut remplir, en particulier la corrélation inter-locataires et l'ingénierie de la base de référence.

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éral du 29 octobre 2025, le tribunal de district du Montana a jugé que les demandeurs institutions financières avaient suffisamment plaidé certaines théories de négligence contre Snowflake et Ticketmaster pour survivre aux requêtes en irrecevabilité. Le tribunal a traité l'authentification multifacteur par défaut présumée et la prévisibilité comme pertinentes pour le devoir, la violation et la causalité à ce stade procédural.

Cette ordonnance n'est pas une constatation de première instance selon laquelle Snowflake ou Ticketmaster auraient été négligents. Lors d'une requête en irrecevabilité, le tribunal vérifie si les allégations bien plaidées énoncent une réclamation plausible; il ne résout pas les preuves contestées, ne détermine pas le mécanisme final de l'incident pour chaque demandeur, ni n'attribue de dommages-intérêts. Snowflake a contesté les allégations et a fait valoir que les manquements des clients à mettre en œuvre l'authentification multifacteur, les politiques réseau et d'autres garanties étaient à l'origine du préjudice. L'ordonnance est significative car elle montre que le fait de décrire l'authentification multifacteur comme un paramètre client n'a pas automatiquement mis fin à toute réclamation relative au 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 a adopté une répartition différente. Le Commissariat à la protection de la vie privée du Canada a déclaré que Ticketmaster Canada restait le responsable du traitement et était l'entité visée par l'enquête, tandis que le bureau a contacté Snowflake pour obtenir des informations. Cela reflète un principe commun en matière 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 ses propres obligations contractuelles, techniques ou légales.

Le propre formulaire 10-K de Snowflake a reconnu de nombreux poursuites, enquêtes réglementaires et demandes de législateurs, mais n'a pas fait état d'une répartition finale et universelle de la responsabilité. À la date de publication, les sources publiques examinées ici ne permettent pas d'affirmer que 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 multifacteur et des politiques 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 qui en a résulté? Oui. Ces propositions peuvent coexister. Le droit de la responsabilité délictuelle, des contrats, de la protection de la vie privée et des valeurs mobilières peut attribuer des conséquences différemment selon la juridiction et le demandeur, mais l'ingénierie ne devrait pas attendre qu'un slogan gagne.

Un test mesurable de la responsabilité partagée

La réponse la plus forte n'est pas un autre diagramme 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 devraient recevoir des résultats plutôt que des inventaires de fonctionnalités. Les mesures utiles incluent le pourcentage d'utilisateurs humains protégés par une authentification multifacteur résistante au hameçonnage, 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 politiques réseau testées, le nombre d'identités de sous-traitants privilégiés ayant dépassé leur expiration, le temps médian d'alerte sur des origines inconnues, le temps de suspension d'une session à haute confiance, et le temps de production d'un dossier d'exposition au niveau des champs.

Snowflake devrait publier les 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 multifacteur. Une déclaration selon laquelle l'authentification multifacteur est disponible est moins informative que la distribution des connexions par mot de passe seul dans le temps. Une déclaration selon laquelle le Centre de confiance 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 la complétude du dossier de preuves.

Les clients devraient 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 d'anciens utilisateurs sous-traitants et n'a personne pour répondre au contact d'urgence. Le but de valeurs par défaut plus fortes 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 de données de masse.

Ce que le dossier public n'établit toujours pas

Les preuves sont assez solides pour reconstituer un modèle de campagne, mais pas chaque incident de victime.

Le dossier public n'identifie pas toutes les organisations notifiées, ne confirme pas que les 165 ont subi un accès non autorisé, ni ne fournit un total final à l'échelle de la campagne de personnes touchées, de tables, d'enregistrements ou d'octets téléchargés. Il ne montre pas quelles victimes ont payé des demandes d'extorsion ni si la suppression promise a eu lieu.

Il ne publie pas le type d'utilisateur, la hiérarchie des rôles, l'historique de l'authentification multifacteur, 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 relatives aux appareils de sous-traitants issues de plusieurs enquêtes ne devraient pas être attribuées à chaque victime. La statistique de 79,7 % d'exposition des identifiants ne devrait pas être transformée en pourcentage de victimes.

Il n'établit pas de vulnérabilité logicielle, d'évasion inter-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 la preuve que le code du produit a été exploité.

Il ne prouve 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; une analyse de transfert légal nécessiterait des faits sur la source, la destination, la personne concernée, le contrat et la juridiction pour chaque client.

Il ne permet pas de généraliser à d'autres clients les champs possibles de Ticketmaster, la portée des détails d'appels d'AT&T ou tout décompte d'un forum criminel. Le dépôt de Live Nation ne nommait pas Snowflake. Le dépôt d'AT&T ne nommait pas Snowflake ou UNC5537. Une association externe peut être pertinente pour une enquête plus approfondie, mais les dépôts devraient être cités pour ce qu'ils établissent réellement.

Enfin, la documentation actuelle de Snowflake ne prouve pas le fonctionnement des contrôles en avril et mai 2024. L'authentification multifacteur par défaut ultérieure, la protection contre les mots de passe divulgués, la détection du Centre de confiance, 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 ne se comprend pas au mieux comme une compétition entre deux histoires absolues. L'une dit que la plateforme a été piratée et que le fournisseur seul a échoué. Les preuves ne l'étayent pas. L'autre dit que les clients ont perdu des mots de passe et que, par conséquent, la question du fournisseur est close. C'est techniquement incomplet.

UNC5537 a trouvé une jonction évolutive entre la compromission des terminaux et la concentration dans le cloud. Les mots de passe historiques restaient valides. Les identités humaines et de service n'étaient pas toujours séparées. L'authentification multifacteur et les portes réseau étaient absentes. Les fonctions de requête et de mise en scène prises en charge ont déplacé les données rapidement. Le fournisseur pouvait voir un motif transversal entre locataires, tandis que chaque client ne voyait que son propre compte. Une région de stockage choisie pouvait conserver les données sources en place même si une session authentifiée créait une copie non contrôlée ailleurs.

Les clients avaient le devoir le plus clair de gouverner leurs utilisateurs, leurs rôles, leurs terminaux, leurs sous-traitants et leurs données. Snowflake avait le devoir le plus clair de sécuriser et d'observer la frontière du service, de rendre les protections à haute valeur faciles et de plus en plus inévitables, de détecter les comportements 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 obligations légales en fonction des faits et du droit applicable à chaque organisation. Ces répartitions se chevauchent parce que les contrôles se chevauchent.

L'orientation produit post-campagne reconnaît implicitement l'écart entre la capacité et le résultat. L'authentification multifacteur par défaut pour les nouveaux utilisateurs humains, la désactivation des mots de passe divulgués, une politique d'authentification plus forte, la migration des utilisateurs de service et les constatations du Centre de confiance 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 découverte et de l'activation de chaque option correcte par chaque administrateur 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 manque un avertissement, qu'un appareil de sous-traitant soit infecté, qu'un identifiant reste valide et qu'un attaquant utilise les fonctions ordinaires du produit. 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 une erreur prévisible d'une partie, et lorsque les deux parties peuvent prouver ce qu'elles ont fait avant et après.