Résumé
- Mandiant a rapporté que chaque incident de campagne Snowflake qu'elle a traité directement provenait d'identifiants clients compromis et n'a trouvé aucune preuve que l'accès non autorisé résultait d'une brèche de l'environnement d'entreprise de Snowflake. Son rapport de campagne est disponible à l'adressehttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
- La campagne a tout de même mis à l'épreuve la responsabilité du fournisseur car Snowflake contrôlait les surfaces d'authentification, les paramètres par défaut des produits, les conseils de sécurité, la télémétrie des comptes, les outils de politique réseau, les vérifications du Trust Center et les modifications post-campagne qu'aucun client individuel ne pouvait créer seul.
- La réparation vérifiable signifie un changement mesurable: MFA par défaut pour les utilisateurs humains dans les nouveaux comptes, des règles de mot de passe plus strictes, la désactivation automatique des mots de passe divulgués, des packs de preuves clients, des contrôles d'origine réseau et des métriques d'adoption montrant une réduction des risques dans l'ensemble de la base installée.
- La responsabilité des clients reste substantielle. Les clients contrôlaient la création d'utilisateurs, les attributions de rôles, la rotation des mots de passe, l'inscription à la MFA dans les comptes existants, l'accès des sous-traitants, les listes d'autorisation réseau, la minimisation des données, les privilèges d'exportation et la préparation aux enquêtes.
La plateforme n'a pas été compromise; la base de référence était permissive
La première discipline est de maintenir la limite exacte de la campagne. Le rapport de Mandiant de juin 2024 indiquait que les accès non autorisés dans les incidents qu'elle a traités provenaient d'identifiants clients compromis et qu'elle n'a trouvé aucune preuve d'une brèche de l'environnement d'entreprise de Snowflake. Les recommandations de Snowflake aux clients, amplifiées par la CISA à l'adresse source: cisa.gov, ont également dirigé les clients pour enquêter sur les accès non autorisés et renforcer les contrôles d'identité et de réseau.
Le dossier examiné n'établit pas d'exploitation de la plateforme Snowflake, d'évasion inter-locataires ou de vol d'un identifiant maître du fournisseur.
Cette constatation négative est importante car elle façonne la réponse immédiate. Un client ne devrait pas attendre un correctif du fournisseur si le problème actif est un identifiant utilisateur valide sans MFA, sans liste d'autorisation réseau et avec des privilèges de rôle étendus. Le client doit faire pivoter les identifiants, désactiver les comptes, inspecter l'historique des connexions et des requêtes, restreindre les réseaux d'origine, réviser les rôles, conserver les journaux et notifier les personnes ou les régulateurs concernés si nécessaire.
L'erreur inverse est de dire que le fournisseur n'avait aucune responsabilité parce que le premier secret appartenait aux clients. Snowflake exploitait le point de terminaison d'authentification qui acceptait ces mots de passe. Il fournissait la capacité MFA et choisissait quand modifier le comportement par défaut. Il exposait ou retenait des champs de télémétrie. Il fournissait des contrôles de politique réseau et des résultats du Trust Center. Il pouvait voir des signaux inter-clients qu'aucun locataire ne pouvait voir. Il a pu ultérieurement construire une protection contre les mots de passe divulgués dans le service.
C'est un contrôle réel, même si le client possédait le compte.
Le dépôt annuel de Snowflake pour l'exercice 2025 à l'adresse SEC source expose la position de l'entreprise en matière de responsabilité partagée et décrit les conséquences juridiques, réglementaires et de réputation suite à l'activité de 2024. Un dépôt est une représentation de l'entreprise, pas une décision judiciaire. Il est néanmoins pertinent car Snowflake lui-même a divulgué que la campagne affectait le risque commercial au-delà d'un seul locataire client. La responsabilité partagée est devenue une question d'entreprise publique.
L'angle de l'article n'est donc pas « Snowflake a été compromise » ou « seuls les clients ont échoué ». Il s'agit de la réparation vérifiable. Après qu'une campagne a exploité un schéma prévisible d'accès par mot de passe seul, d'identifiants obsolètes issus de voleurs d'informations et de restrictions réseau absentes, le fournisseur et les clients ont besoin de preuves que la prochaine campagne similaire aura moins d'identifiants viables, moins de sessions sans mot de passe, moins d'origines non restreintes, de meilleures alertes et une livraison plus rapide des preuves.
Le chemin de la campagne utilisait des fonctions ordinaires sous une identité hostile
Mandiant a décrit une chaîne pratique. Des identifiants avaient été volés par des logiciels malveillants voleurs d'informations sur des systèmes non détenus par Snowflake, y compris des machines de sous-traitants utilisées pour des activités personnelles dans certains cas. Ces identifiants sont restés valides, parfois pendant des années. Les comptes manquaient de MFA. Les instances clients manquaient de listes d'autorisation réseau. Les attaquants se sont connectés avec des clients et outils standards, ont effectué des reconnaissances, sélectionné des données, mis en scène les résultats, compressé des fichiers et les ont récupérés.
Le schéma utilisait des fonctionnalités de base de données prises en charge sous une identité non autorisée.
Cette distinction est centrale pour la réparation. Le chiffrement au repos n'était pas la barrière décisive. La documentation de chiffrement de bout en bout de Snowflake à l'adresse source: docs.snowflake.com décrit le chiffrement au repos et en transit, mais explique également que les données doivent être utilisées lors des opérations sur les tables et peuvent être déchargées et téléchargées par des utilisateurs autorisés. Un attaquant qui satisfait l'authentification du compte et hérite d'un rôle peut demander au service des résultats lisibles.
Le chiffrement ne remplace pas l'assurance de l'identité, la conception des rôles, le contrôle des exportations et la détection.
Le contrôle d'accès déterminait le rayon d'explosion après la connexion. L'aperçu du contrôle d'accès de Snowflake à l'adresse source: docs.snowflake.com décrit les rôles, privilèges, propriété et hiérarchie. Un identifiant volé avec un accès restreint est différent d'un identifiant avec des privilèges de lecture étendus ou d'administration de compte. Un compte de service conçu pour un pipeline est différent d'un administrateur sous-traitant. Le moindre privilège n'est pas un slogan; c'est la différence entre une session hostile renvoyant une vue et une session hostile parcourant les tables majeures du client.
La classification et le masquage des données peuvent réduire les conséquences. La documentation de classification des données sensibles de Snowflake à l'adresse source: docs.snowflake.com relie la découverte de colonnes sensibles aux politiques de masquage et d'accès aux lignes. Cela ne prouve pas que les clients affectés disposaient de tels contrôles. Cela montre une voie de réparation: les clients doivent identifier les champs personnels et réglementés, exposer des vues plutôt que des tables brutes lorsque c'est possible, et séparer les rôles d'exportation des rôles de lecture ordinaires.
Le chemin d'exfiltration observé fait également de l'exportation un contrôle en soi. Les déchargements en masse sont légitimes dans une plateforme de données. Ils soutiennent l'analyse, la sauvegarde, le traitement en aval et les workflows de modélisation. Mais une session inhabituelle créant des étapes temporaires, exportant de grands résultats et les téléchargeant depuis une origine inconnue n'est pas simplement « une requête ». C'est un événement de mouvement de données. La réparation devrait rendre ces événements mesurables, attribuables et, pour les ensembles de données à haut risque, interruptibles.
La disponibilité de la MFA est devenue les résultats de la MFA
La MFA était disponible avant la campagne. Les comptes réussis dans le rapport de Mandiant en manquaient. Ce fossé est au cœur du différend sur la responsabilité partagée. Un administrateur client pouvait activer la MFA, et beaucoup ne l'ont pas fait. Un fournisseur peut dire honnêtement que le contrôle était disponible. Mais un fournisseur qui voit encore de nombreux comptes à haute valeur accessibles par mot de passe seul n'a pas atteint le résultat de sécurité, seulement rendu le paramètre disponible.
L'annonce de Snowflake de septembre 2024 à l'adresse source: snowflake.com a fait évoluer la posture du produit. Elle indiquait que la MFA serait appliquée par défaut pour les utilisateurs humains dans les comptes créés à partir d'octobre 2024 et que les utilisateurs de service ne seraient pas soumis à cette exigence spécifique. Elle a également annoncé des exigences de mot de passe plus fortes pour les mots de passe nouvellement créés et modifiés. Il s'agit d'une réparation significative car elle modifie le chemin par défaut pour les futurs comptes.
La distinction entre les comptes nouveaux et existants est tout aussi significative. Un défaut pour les futurs comptes ne supprime pas automatiquement chaque chemin sans mot de passe dans la base installée. Les clients existants peuvent avoir des utilisateurs hérités, des comptes de service, des sous-traitants, des comptes de secours et des clients plus anciens.
Un dossier de réparation vérifiable devrait donc mesurer directement le risque hérité: nombre et part des utilisateurs humains sans MFA, des utilisateurs humains privilégiés sans MFA, des utilisateurs de mot de passe avec des dates de dernière connexion obsolètes, des utilisateurs avec des identifiants connus exposés, des comptes de service utilisant des mots de passe plutôt qu'une authentification de charge de travail plus forte, et des exceptions avec des propriétaires métier et des dates d'expiration.
La documentation sur les politiques d'authentification de Snowflake à l'adresse source: docs.snowflake.com donne aux administrateurs des contrôles sur les méthodes d'authentification, les clients, les fournisseurs d'identité et l'inscription à la MFA. Sa documentation sur l'authentification par paire de clés à l'adresse source: docs.snowflake.com offre aux comptes de service une alternative aux mots de passe statiques.
Ces contrôles imposent des devoirs aux clients, mais ils définissent également la surface de réparation du fournisseur: le produit devrait rendre les bons schémas plus faciles, les mauvaises exceptions visibles et la migration moins risquée.
Les directives d'identité numérique du NIST à l'adresse source: pages.nist.gov aident à énoncer le résultat. Les mots de passe ne résistent pas à la relecture. Les méthodes résistantes au phishing ou cryptographiquement liées réduisent la valeur d'un mot de passe volé. Pour les clients Snowflake, cela signifie que les administrateurs humains devraient passer par une identité fédérée ou une MFA forte, tandis que les utilisateurs de service devraient utiliser des identifiants de charge de travail limités qui tournent et peuvent être désactivés sans usurper l'identité d'une personne.
Le blocage des mots de passe divulgués a rendu la responsabilité partagée mesurable
La réparation la plus directe du fournisseur après une campagne d'identifiants volés n'est pas une leçon sur la réutilisation des mots de passe. C'est faire en sorte que les mots de passe connus divulgués cessent de fonctionner. L'annonce de Snowflake de décembre 2024 à l'adresse source: snowflake.com indiquait qu'elle désactiverait automatiquement les mots de passe détectés sur le dark web via un processus préservant la confidentialité lorsqu'ils sont confirmés comme divulgués et toujours valides. Ce contrôle répond à l'avantage central de la campagne: des identifiants volés bien avant 2024 restaient acceptés par le service.
La protection contre les mots de passe divulgués ne supprime pas le devoir du client. Les clients ont toujours besoin de sécurité des points de terminaison, de gouvernance des sous-traitants, de rotation des mots de passe, de fédération, de conception des utilisateurs de service et du moindre privilège. Mais elle modifie la division du travail. Les clients individuels ne peuvent souvent pas voir le marché mondial des voleurs d'informations aussi bien qu'un fournisseur de cloud.
Un fournisseur peut acheter ou recevoir des renseignements sur les menaces, faire correspondre les identifiants exposés de manière contrôlée et désactiver un mot de passe avant que chaque client ne le découvre indépendamment. C'est le type de contrôle au niveau du fournisseur qui transforme la responsabilité partagée d'une clause en un comportement système.
La question de la preuve est l'adoption et la performance. Combien de mots de passe divulgués valides ont été trouvés? À quelle vitesse ont-ils été désactivés? Combien appartenaient à des utilisateurs privilégiés? Combien de comptes sont passés du mot de passe à un accès par paire de clés ou fédéré? Combien d'événements de mot de passe désactivé ont entraîné des frictions de support ou des contournements dangereux? Combien de clients ont encore des exceptions? Sans métriques, la protection contre les mots de passe divulgués reste une bonne annonce. Avec des métriques, elle devient une réparation vérifiable.
L'engagement « Secure by Design » de la CISA à l'adresse source: cisa.gov encadre cette distinction. Il demande aux fabricants d'aller au-delà des contrôles optionnels vers des résultats mesurables tels que la MFA par défaut et les métriques d'adoption. L'annonce de l'engagement de Snowflake en juillet 2024 à l'adresse source: snowflake.com a placé l'entreprise dans cet engagement public. L'engagement est volontaire et non un verdict juridique sur la campagne. Il est pertinent car il identifie le type de preuves que les clients devraient attendre après l'événement.
La politique réseau était une deuxième porte
Mandiant a identifié l'absence de listes d'autorisation réseau comme un facteur récurrent. La documentation sur les politiques réseau de Snowflake à l'adresse source: docs.snowflake.com indique le défaut pratique: sans politique, les utilisateurs peuvent se connecter depuis n'importe quel ordinateur ou appareil. Les clients peuvent restreindre l'accès par emplacements réseau autorisés ou bloqués et utiliser des schémas de connectivité privée pour des limites plus fortes.
Le client est l'acteur le mieux placé pour connaître les origines légitimes: bureaux, VPN, charges de travail cloud, postes de travail des sous-traitants gérés et fournisseurs d'intégration approuvés. Snowflake ne peut pas deviner chaque chemin valide sans interrompre le service. Mais Snowflake contrôle si l'accès public non restreint est silencieux ou visible. Un programme de réparation vérifiable devrait signaler quels comptes manquent de politiques réseau, quels utilisateurs privilégiés les contournent, si l'accès aux étapes internes est couvert et si les politiques correspondent réellement aux origines approuvées par l'entreprise.
Les contrôles réseau ne suffisent pas seuls. Un attaquant peut utiliser un VPN approuvé, compromettre une machine de sous-traitant déjà dans une liste d'autorisation ou voler un jeton après authentification. Pourtant, la défense devrait être en couches. Un mot de passe volé, pas de MFA, pas de restriction réseau, un rôle étendu et une exportation non surveillée forment une chaîne. Briser n'importe quel maillon peut compter. La réparation est le processus de réduction du nombre d'environnements clients où tous les maillons restent ouverts ensemble.
Le fournisseur devrait également rendre la gestion des blocages sûre. Les administrateurs peuvent éviter les politiques réseau par crainte de bloquer les utilisateurs métier ou les tâches de service. La simulation, le déploiement progressif, les contacts d'urgence, les exceptions temporaires et les journaux clairs réduisent cette crainte. Meilleure est la voie de migration, plus il est difficile de traiter les politiques manquantes comme ordinaires.
La télémétrie est la limite de la preuve
Après une campagne de vol de données, les clients ont besoin de plus que des assurances générales. Ils doivent savoir qui s'est connecté, d'où, avec quel facteur, en utilisant quel client, sous quel rôle, quelles requêtes ont été exécutées, quels objets ont été touchés, quelles données ont été déchargées, quelles étapes ont été utilisées et quelle quantité de données a été déplacée. La documentation actuelle de Snowflake décrit plusieurs vues pouvant soutenir ce travail.
LOGIN_HISTORY à l'adresse source: docs.snowflake.com fournit les tentatives de connexion avec IP source, client, succès et informations sur les facteurs. QUERY_HISTORY à l'adresse source: docs.snowflake.com fournit l'activité des requêtes, l'utilisateur, le rôle, le texte de la requête, la taille des résultats, les lignes déchargées et les octets envoyés sur le réseau. ACCESS_HISTORY à l'adresse source: docs.snowflake.com peut aider à reconstruire l'accès aux objets et colonnes pour les éditions éligibles.
La documentation de Trust Center à l'adresse source: docs.snowflake.com décrit les vérifications de posture et les détections pour la MFA, les politiques réseau, les connexions risquées, les adresses IP inhabituelles et les transferts importants.
Ce sont des capacités. La capacité n'est pas une preuve de préparation aux enquêtes. Les clients doivent avoir les droits d'interroger les vues, de les exporter vers un stockage de sécurité durable, de comprendre la latence et la rétention, et de les corréler avec les données du fournisseur d'identité, des points de terminaison et de la gestion des tickets. Les différences d'édition peuvent modifier la précision du cadrage au niveau des champs. Les vues du fournisseur peuvent avoir des délais importants pour le confinement actif.
Le texte de la requête seul peut ne pas indiquer à une équipe de confidentialité quels individus étaient représentés, à moins que le client ne dispose de cartographies de données.
La réparation vérifiable devrait donc inclure des packs de preuves. Lorsque Snowflake notifie un client potentiellement exposé, le client devrait recevoir des identifiants de compte, des utilisateurs, des horodatages, des réseaux d'origine, le statut du premier et du deuxième facteur, des identifiants de client, des identifiants de session et de requête, des rôles, des objets touchés, des noms d'étapes, le volume déchargé, la confiance et le confinement recommandé.
Une étiquette telle que « potentiellement exposé » est acceptable comme ouverture, mais elle doit être suivie de suffisamment de données pour que le client décide si des informations personnelles étaient impliquées.
L'intervention du fournisseur a également besoin d'une autorisation préalable. Un fournisseur de cloud peut voir une activité suspecte avant le client, mais bloquer automatiquement une session peut interrompre la production. Ne pas agir peut permettre le vol. La réparation devrait définir des seuils pour la suspension temporaire, les contacts d'urgence du client, la préservation des preuves et le dépassement. Les clients devraient désigner des contacts de sécurité capables d'agir à toute heure. Snowflake devrait mesurer le temps entre le signal inter-clients et l'avis au client, et le temps entre l'avis et le confinement.
La localisation des données s'arrêtait à l'accès
Le choix de la région Snowflake peut compter pour la latence, la résilience, la confidentialité et l'approvisionnement. La documentation des régions prises en charge à l'adresse source: docs.snowflake.com indique qu'un compte est hébergé dans une région et que les données y restent à moins que les utilisateurs ne les copient, déplacent ou répliquent explicitement. Elle indique également la limite clé: le choix de la région ne limite pas l'accès des utilisateurs à Snowflake.
La campagne a transformé cette limite en problème de souveraineté. Les tables d'un client peuvent avoir été stockées dans une région approuvée. Une identité valide pouvait toujours se connecter depuis ailleurs, interroger les données, les décharger vers une étape et en télécharger une copie. Le placement du compte source n'empêchait pas l'accès ou l'exportation à distance. Le dossier public de la campagne n'établit pas les pays source et destination pour chaque victime, donc aucune conclusion juridique transfrontalière universelle n'est soutenable. La leçon architecturale demeure: la localité de stockage n'est pas la localité d'accès.
Les conseils de partage entre régions de Snowflake à l'adresse source: docs.snowflake.com avertissent les clients de confirmer les restrictions légales et réglementaires avant de répliquer des données vers une autre région ou pays. Ces conseils concernent le mouvement approuvé. L'exportation pilotée par identifiant est différente car elle peut créer une copie non contrôlée en dehors de la région sélectionnée sans changer la région du compte source. Un inventaire des données qui enregistre uniquement la région source peut être exact et encore incomplet après une exportation.
La réparation de la souveraineté des données a donc besoin de quatre couches: où les données faisant autorité sont hébergées, quelles identités peuvent se connecter depuis quels appareils et juridictions, quelles fonctions de mouvement peuvent créer des copies et quelles preuves existent après un incident. Snowflake contrôle les offres de régions, l'authentification, les outils réseau, les mécanismes d'exportation et la télémétrie. Les clients contrôlent la base juridique, les champs de données, les attributions de rôles, les approbations de mouvement et l'analyse des notifications. Les deux côtés ont besoin de preuves à leur limite.
Les cas clients montrent les conséquences, pas un décompte maître unique
La forme publique de la campagne a été influencée par les divulgations des entreprises affectées. Chaque dossier doit rester dans ses propres faits.
Le dépôt de Live Nation de mai 2024 à l'adresse SEC source indiquait que la société avait identifié une activité non autorisée dans un environnement de base de données cloud tiers contenant principalement des données de Ticketmaster et qu'un acteur criminel avait ensuite proposé à la vente des données d'utilisateurs présumées de la société. Le dépôt ne nommait pas Snowflake ni ne fournissait un nombre confirmé de personnes affectées.
La page d'incident de Ticketmaster Canada à l'adresse source: help.ticketmaster.ca décrivait une base de données cloud tierce isolée, des champs possibles pour certains acheteurs de billets nord-américains et la limite selon laquelle les comptes clients de Ticketmaster n'étaient pas affectés. Le Commissaire à la protection de la vie privée du Canada a ensuite identifié Snowflake comme le fournisseur de Ticketmaster dans un briefing parlementaire à l'adresse source: priv.gc.ca, tout en indiquant que l'enquête restait ouverte et que Ticketmaster Canada restait le responsable du traitement examiné.
Le dépôt d'AT&T de juillet 2024 à l'adresse SEC source décrivait un accès illégal à un espace de travail AT&T sur une plateforme cloud tierce et l'exfiltration d'enregistrements d'appels et de messages texte. Le dépôt ne nommait pas Snowflake. Il est utile pour comprendre un incident divulgué d'espace de travail cloud tiers et ses limites de champ, pas comme une attribution autonome.
Ces exemples ne créent pas un décompte de personnes à l'échelle de la campagne. L'estimation d'environ 165 organisations potentiellement exposées par Mandiant est une population de notification, pas un nombre de victimes confirmé, un nombre d'enregistrements ou un nombre d'individus affectés. Chaque client détenait des données, des rôles, des rétentions, des régions et des devoirs de notification différents. La réparation vérifiable doit aider chaque client à cadrer ses propres faits plutôt que de faire jouer un seul nombre au niveau de la plateforme.
Une note de typographie pour les packs de preuves
Lorsque les clients reçoivent des preuves de sécurité cloud de haute sévérité, la mise en page peut décider si la bonne personne agit rapidement. Un tableau des sessions, facteurs, rôles, objets et transferts doit être lisible sous pression. Le bloc de typographie suivant appartient au corps public car la conception de la preuve fait partie de la réparation.
Pour les clients Snowflake, une preuve lisible signifie des horodatages dans une seule base temporelle, des étiquettes claires pour les utilisateurs et les rôles, une séparation de l'activité confirmée des soupçons, un statut MFA visible et des liens directs entre les requêtes, les étapes, le volume de transfert et les magasins de données affectés. Un export dense de journaux peut être complet mais inutilisable. Un pack de preuves concis peut faire la différence entre une décision de confinement rapide et une analyse de confidentialité retardée.
Responsabilité par contrôle pratique
Les attaquants contrôlaient l'activité criminelle: utiliser des identifiants volés, entrer dans les environnements clients, mettre en scène des données, les prendre et tenter de les vendre ou de faire du chantage. Ils sont responsables de cette conduite.
Les clients contrôlaient de nombreuses portes défaillantes. Ils créaient des utilisateurs, attribuaient des rôles, choisissaient si les utilisateurs humains pouvaient se connecter avec un mot de passe seul, conservaient des identifiants obsolètes, autorisaient l'accès des sous-traitants, laissaient certains comptes sans politiques réseau, accordaient l'accès aux données et gouvernaient les exportations. Un client dont l'entrepôt à haute valeur acceptait un ancien mot de passe depuis une origine inconnue sans MFA ni rôles restreints ne peut pas transférer toute la responsabilité au fournisseur.
Snowflake contrôlait la base de référence et les outils de réparation. Il contrôlait si les nouveaux utilisateurs humains avaient la MFA par défaut, si les mots de passe divulgués étaient désactivés côté fournisseur, si les configurations risquées apparaissaient dans Trust Center, quels champs de télémétrie étaient disponibles, comment les clients étaient notifiés, comment les conseils étaient rédigés et à quelle vitesse les contrôles post-campagne étaient livrés. Un fournisseur qui voit le même schéma à travers les locataires a le devoir de réduire ce schéma à l'échelle, pas seulement de dire à chaque client de lire le manuel.
Les fournisseurs d'identité, les sous-traitants et les propriétaires de points de terminaison contrôlaient les conditions adjacentes. Les appareils de sous-traitants utilisés sur plusieurs clients peuvent propager un incident de voleur d'informations dans plusieurs locataires cloud. Les fournisseurs d'identité peuvent appliquer des facteurs plus forts et un accès conditionnel. Les points de terminaison gérés peuvent garder les identifiants hors des machines personnelles. Ces acteurs comptent, mais ils n'effacent pas les devoirs du client et du fournisseur sur le compte Snowflake lui-même.
Les régulateurs, assureurs et équipes d'approvisionnement contrôlent les incitations. Les conseils du NIST sur la chaîne d'approvisionnement à l'adresse source: csrc.nist.gov soutiennent la définition d'exigences fournisseur proportionnées à la criticité. Pour un entrepôt de données, cela signifie que les contrats et renouvellements devraient demander des métriques d'adoption de la MFA, la réponse aux mots de passe divulgués, les champs des packs de preuves, les garanties de rétention, les délais de notification, l'escalade du support et les contrôles de mouvement régional.
Un questionnaire de sécurité qui demande seulement si la MFA existe est trop superficiel après cette campagne.
Ce qui prouverait une réparation durable
Le dossier de réparation devrait inclure au moins dix résultats.
Premièrement, tous les nouveaux utilisateurs humains ont par défaut la MFA ou un accès fédéré plus fort, et la base installée montre une part croissante de comptes humains et privilégiés protégés. Deuxièmement, les utilisateurs de service s'éloignent des mots de passe statiques vers des identifiants de charge de travail limités (paire de clés, OAuth) avec rotation. Troisièmement, la protection contre les mots de passe divulgués rapporte des événements de désactivation confirmés et le temps moyen de désactivation. Quatrièmement, la couverture des politiques réseau augmente, en particulier pour les comptes privilégiés et les étapes internes.
Cinquièmement, les résultats du Trust Center ne sont pas simplement affichés mais corrigés avec des propriétaires d'exception et des dates d'expiration. Sixièmement, la rétention et l'exportation de la télémétrie sont suffisantes pour la découverte tardive et le cadrage de la confidentialité. Septièmement, les détections de déchargements importants et d'origines inhabituelles sont ajustées et acheminées à des personnes capables d'agir. Huitièmement, les notifications du fournisseur incluent des preuves concrètes de session, requête, rôle, objet et transfert.
Neuvièmement, les clients affectés peuvent cartographier les requêtes aux personnes et aux catégories de données réglementées. Dixièmement, les contrats clients et les examens de renouvellement intègrent des preuves plutôt que de se fier à la formulation de responsabilité partagée.
Le contentieux peut influencer le dossier mais ne devrait pas remplacer les preuves de contrôle. L'ordonnance de phase de plaidoirie dans le litige multidistrict Snowflake à l'adresse source: govinfo.gov a permis à certaines allégations de procéder tout en les traitant selon des normes procédurales. Ce n'est pas une constatation finale de responsabilité. Cela montre que les tribunaux peuvent examiner les paramètres par défaut du fournisseur, la prévisibilité et la causalité même lorsque l'histoire publique commence par des identifiants clients.
Le problème de la base installée
Les paramètres de sécurité par défaut sont plus efficaces au moment de la création. Ils sont plus difficiles dans une base installée où les clients ont déjà de l'automatisation, des utilisateurs de service, des sous-traitants, des fournisseurs d'identité, des clients anciens et des comptes d'urgence. Le changement de MFA par défaut de Snowflake pour les nouveaux comptes était une étape matérielle, mais le risque de la campagne résidait fortement dans les comptes existants avec des habitudes existantes. La réparation vérifiable a donc besoin d'une histoire de migration pour la base installée, pas seulement une histoire de nouveaux comptes.
Le problème de la base installée a plusieurs couches. Premièrement, les anciens utilisateurs humains peuvent encore s'authentifier directement avec des mots de passe parce que la fédération n'a jamais été achevée. Deuxièmement, les utilisateurs privilégiés peuvent avoir des exceptions parce que les administrateurs craignent le blocage. Troisièmement, les utilisateurs de service peuvent être mal classifiés comme humains ou les humains peuvent utiliser des identifiants de type service. Quatrièmement, les sous-traitants peuvent conserver un accès après la fin d'un projet.
Cinquièmement, les comptes dormants peuvent encore avoir des rôles qui atteignent des données sensibles. Sixièmement, les intégrations peuvent échouer si les règles de mot de passe ou les politiques réseau changent soudainement.
Le fournisseur peut réduire cette friction sans prendre le contrôle du locataire du client. Il peut montrer aux administrateurs une liste prioritaire des identités risquées, divisée par privilège et portée des données. Il peut fournir des politiques de simulation qui montrent qui serait bloqué par la MFA ou les restrictions réseau. Il peut exiger des propriétaires d'exception et des dates d'expiration. Il peut distinguer les comptes de secours des comptes hérités ordinaires. Il peut fournir des aides à la migration pour les utilisateurs de service passant aux schémas de paire de clés ou OAuth.
Il peut envoyer des notifications produit répétées liées au risque réel plutôt que des bannières génériques.
Les clients doivent alors agir. Un client qui reçoit un tableau de bord montrant des utilisateurs privilégiés sans mot de passe et les laisse inchangés pendant des mois possède ce risque résiduel. Un client qui ne peut pas dire si un compte de sous-traitant est encore nécessaire possède un échec de gouvernance des identités. Un client qui laisse un compte de service lire des tables brutes entières parce que « le pipeline en avait besoin » possède une portée de rôle excessive. La responsabilité partagée devient concrète lorsque le fournisseur montre la preuve et que le client soit corrige, soit enregistre une exception responsable.
Le dossier de réparation devrait séparer trois états: corrigé, excepté et inconnu. Corrigé signifie que la condition risquée a disparu. Excepté signifie qu'un propriétaire métier l'a acceptée avec des contrôles compensatoires et une date de révision. Inconnu signifie que personne n'a pris la responsabilité. Un programme mature pousse le nombre d'inconnus vers zéro. Les assurances publiques sautent souvent cette distinction; la réparation vérifiable en dépend.
Les preuves client doivent connecter les journaux techniques aux personnes
Snowflake peut exposer une télémétrie technique riche, mais la réponse juridique et de confidentialité nécessite un pont entre les objets techniques et les personnes et obligations. Un identifiant de requête, un nom de rôle ou un chemin d'étape n'est que le début. Le client doit savoir quelle table contenait quels champs personnels, quels personnes concernées étaient représentées, quelles règles nationales ou étatiques s'appliquent, quelles obligations contractuelles de notification existent et quels systèmes en aval ont reçu des copies. Sans ce pont, le client peut savoir que des octets sont partis mais pas qui notifier.
Ce pont devrait être préparé avant un incident. Les propriétaires de données devraient maintenir des inventaires de champs pour les données réglementées, l'objectif métier, la période de rétention, la politique de masquage et les routes d'exportation approuvées. Les équipes de sécurité devraient savoir où les journaux Snowflake sont conservés en dehors de la plateforme et pendant combien de temps. Les équipes de confidentialité devraient pouvoir demander une liste des tables affectées et recevoir une cartographie des catégories de personnes et de champs.
Les équipes juridiques devraient savoir quelles régions et quels contrats clients sont attachés à ces enregistrements.
Les preuves du fournisseur peuvent faciliter cela. Si une notification inclut les rôles exacts, les objets, les étapes et le volume, le client peut éviter une recherche large et lente. Si le fournisseur indique également si la MFA était présente, si la source était inhabituelle et si la protection contre les mots de passe divulgués a ensuite désactivé l'identifiant, le client peut comprendre la cause et le confinement. Si le fournisseur ne donne que des conseils généraux, le client doit reconstruire les preuves alors que l'horloge pour la notification et la réponse à l'extorsion tourne déjà.
La campagne a également exposé une question de rétention pour la télémétrie elle-même. Les historiques natifs peuvent couvrir un an, mais les litiges juridiques, la découverte tardive et les enquêtes réglementaires peuvent s'étendre plus longtemps. Les clients à haut risque devraient diffuser les journaux vers un magasin de sécurité indépendant avec une rétention alignée sur leurs obligations. Un fournisseur devrait rendre une telle exportation pratique et documentée. Le client devrait prouver qu'elle fonctionne en reconstruisant périodiquement un chemin d'accès échantillon, de la connexion à la requête à la catégorie de données.
La réparation ne peut pas reposer sur la honte du client
Après une campagne d'identifiants, il est tentant de traiter les clients sans MFA comme la leçon de l'histoire. C'est en partie vrai et encore insuffisant. Faire honte publiquement aux clients ne désactive pas les mots de passe divulgués, ne reconçoit pas les paramètres par défaut ni ne livre des packs de preuves. Cela peut même amener les clients à cacher des configurations faibles jusqu'à ce qu'un incident force la divulgation.
Le meilleur modèle est le durcissement progressif. Le fournisseur commence par la visibilité, puis des paramètres par défaut plus forts, puis des avertissements ciblés, puis une gouvernance des exceptions, puis une application pour les catégories de risque où la conséquence le justifie. Les clients reçoivent du temps et des outils de migration, mais ils perdent également la capacité de laisser des lacunes à haut risque invisibles. Les équipes d'approvisionnement demandent ensuite des métriques d'adoption et des comptes d'exceptions, pas seulement des listes de fonctionnalités.
Cette approche reconnaît que les plateformes cloud sont des systèmes d'exploitation partagés pour les données métier. Un fournisseur qui rend un paramètre par défaut plus sûr peut brièvement augmenter les frictions client, mais il réduit également le pool de cibles disponibles pour les groupes criminels. Un client qui accepte l'application peut avoir besoin de mettre à jour des scripts ou des identités, mais il gagne un argument plus fort pour les régulateurs, les assureurs et les personnes concernées. La réparation fonctionne lorsque les deux côtés peuvent montrer des conditions changées, pas des messages changés.
L'approvisionnement devrait exiger une télémétrie de réparation
Un acheteur d'une plateforme de données à haute valeur devrait traiter la télémétrie post-campagne comme une exigence d'approvisionnement. La question n'est pas seulement de savoir si le fournisseur offre désormais la MFA, les politiques réseau, les contrôles de mots de passe divulgués et les résultats de Trust Center. La question est de savoir si l'acheteur peut recevoir des preuves que ces contrôles sont actifs, complets et testés dans son propre compte. La disponibilité des fonctionnalités est le langage du fournisseur. La couverture des contrôles est le langage opérationnel.
Le dossier d'approvisionnement devrait demander un rapport de couverture des identités, incluant les utilisateurs humains, les utilisateurs privilégiés, les utilisateurs de service, les comptes dormants, les sous-traitants externes, le statut de la fédération, le statut de la MFA et les exceptions de mot de passe. Il devrait demander la couverture réseau par compte, classe d'utilisateurs, étapes internes et points de terminaison privés.
Il devrait demander si la protection contre les mots de passe divulgués est activée, quelles notifications d'événement elle produit et comment un mot de passe désactivé est reflété dans les enregistrements d'audit. Il devrait demander quels résultats de Trust Center sont disponibles au niveau contracté et pendant combien de temps l'historique pertinent est conservé.
Les conditions d'incident devraient être tout aussi concrètes. Une clause de notification générique est faible après cette campagne. Les clients ont besoin de délais pour la notification de haute sévérité, des champs de preuves qui seront inclus, des contacts d'urgence, de l'escalade du support, de la préservation des journaux et de la coopération dans le cadrage des personnes concernées. Un client qui détient des données personnelles réglementées devrait exiger des packs de preuves échantillons avant le renouvellement, pas après le vol.
Un exercice sur table peut tester si le fournisseur et le client peuvent passer d'une connexion suspecte à une analyse des champs affectés dans la fenêtre nécessaire.
Cela ne fait pas tout reposer sur Snowflake. Le client doit maintenir ses propres cartographies, conserver les journaux et connaître ses obligations de confidentialité. Mais le fournisseur contrôle de nombreux faits nécessaires pour que la cartographie devienne utilisable. Un processus d'approvisionnement qui ne demande que des attestations passera à côté du problème opérationnel. Un processus qui demande une télémétrie de réparation révélera si la responsabilité partagée est prête pour la prochaine campagne.
Les mêmes preuves devraient apparaître dans les renouvellements. Si un client reste sur un accès fortement basé sur les mots de passe un an après la campagne, le renouvellement devrait forcer une exception nommée ou une migration financée. Si un client ne peut pas recevoir de détails au niveau ACCESS_HISTORY en raison de l'édition, le renouvellement devrait documenter si cette limitation est acceptable pour les données stockées. Si les politiques réseau sont absentes, le renouvellement devrait identifier clairement le bloqueur opérationnel.
La réparation devrait être examinée avant que l'effet de levier ne disparaisse dans un autre terme contractuel.
Les preuves de renouvellement devraient également séparer le changement de plateforme du changement de locataire. Snowflake peut livrer un paramètre par défaut plus fort, mais le compte du client peut encore contenir des utilisateurs sans mot de passe, des rôles étendus, des sous-traitants obsolètes et des étapes non révisées. L'acheteur devrait demander le registre des exceptions du compte lui-même, pas seulement la feuille de route produit du fournisseur.
Cette distinction empêche une dérive post-incident familière: le fournisseur annonce un contrôle, les clients supposent que le risque a bougé et la base installée reste matériellement exposée.
Pour les conseils d'administration et les équipes de confidentialité, ce registre au niveau du locataire est le pont entre la réparation technique et la confiance juridique. Une affirmation selon laquelle « la MFA est disponible » ne répond pas à la question de savoir si le compte affecté l'utilisait. Une affirmation selon laquelle « les politiques réseau existent » ne répond pas à la question de savoir si l'identifiant volé pouvait atteindre les données depuis une origine inhabituelle.
Une affirmation selon laquelle « la télémétrie est conservée » ne répond pas à la question de savoir si l'organisation peut cartographier les requêtes aux champs réglementés. La réparation vérifiable vit dans ces réponses spécifiques au compte.
Ce qu'il ne faut pas inférer
Un compte retenu devrait éviter quatre sauts. Premièrement, la campagne ne prouve pas que la plateforme de production de Snowflake a été compromise. Deuxièmement, elle ne prouve pas que chaque organisation notifiée a perdu des données. Troisièmement, elle ne prouve pas que chaque client affecté avait les mêmes champs, personnes ou obligations juridiques. Quatrièmement, les changements de produit post-campagne ne prouvent pas par eux-mêmes la négligence avant les changements. Les produits de sécurité évoluent après des incidents pour de nombreuses raisons, y compris une meilleure intelligence des menaces et des normes modifiées.
En même temps, la retenue n'exige pas le silence sur le devoir du fournisseur. Un fournisseur peut être exempt d'une constatation de brèche de plateforme et toujours être responsable de la conception par défaut, de la qualité de la télémétrie et des avertissements inter-clients. Un client peut être en faute pour des contrôles d'identité faibles et encore avoir besoin des données du fournisseur pour enquêter. Une ordonnance de litige peut être non définitive et encore montrer que la MFA par défaut et la prévisibilité seront examinées. Une responsabilité équilibrée maintient toutes ces propositions vivantes à la fois.
L'évaluation finale est un impact élevé et une confiance élevée. Les preuves confirmées soutiennent une campagne d'identifiants clients, pas une brèche de la plateforme Snowflake. Mais les preuves montrent également pourquoi les paramètres par défaut du fournisseur, la télémétrie et l'automatisation de la sécurité inter-clients font partie de la responsabilité. La responsabilité partagée est crédible uniquement lorsque les deux côtés peuvent montrer les portes qu'ils ont fermées. Après cette campagne, le test de Snowflake n'est pas de savoir s'il peut dire que la MFA existait.
C'est de savoir si moins de mots de passe volés peuvent devenir des sessions, moins de sessions peuvent atteindre des données larges et plus de clients peuvent prouver exactement ce qui s'est passé avant que les données ne partent.