Snowflake a érigé la réparation vérifiable en test de la responsabilité cloud partagée

Résumé

• Mandiant a signalé que chaque incident de la campagne Snowflake qu'elle a directement traitée provenait d'identifiants clients compromis et qu'aucune preuve n'indiquait que l'accès non autorisé était dû à une violation 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 néanmoins mis à l'épreuve la responsabilité du fournisseur, car Snowflake contrôlait les surfaces d'authentification, les paramètres par défaut du produit, 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 n'aurait pu créer seul.
• La réparation vérifiable signifie un changement mesurable: MFA par défaut pour les utilisateurs humains dans les nouveaux comptes, règles de mot de passe plus strictes, désactivation automatique des mots de passe compromis, dossiers de preuve client, contrôles d'origine réseau et indicateurs d'adoption montrant une réduction des risques dans l'ensemble du parc installé.
• La responsabilité des clients reste substantielle. Les clients contrôlaient la création d'utilisateurs, l'attribution des 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 configuration de base s'est avérée permissive

La première discipline consiste à délimiter précisément les frontières 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'avait trouvé aucune preuve d'une violation de l'environnement d'entreprise de Snowflake. Les recommandations de Snowflake à ses clients, amplifiées par la CISA à l'adressehttps://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access, invitaient elles aussi les clients à enquêter sur les accès utilisateur non autorisés et à renforcer les contrôles d'identité et de réseau. Les informations examinées n'établissent pas l'existence d'une exploitation de la plateforme Snowflake, d'une évasion inter-tenant ou du vol d'un identifiant maître du fournisseur.

Cette conclusion négative est importante car elle détermine la réponse immédiate. Un client ne doit 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 procéder à la rotation des identifiants, désactiver des comptes, examiner l'historique des connexions et des requêtes, restreindre les réseaux d'origine, passer en revue les rôles, conserver les journaux et informer les personnes concernées ou les régulateurs lorsque cela est requis.

L'erreur inverse serait de dire que le fournisseur n'a aucune responsabilité parce que le premier secret appartenait aux clients. Snowflake exploitait le point de terminaison d'authentification qui acceptait ces mots de passe. Elle fournissait la capacité MFA et choisissait quand modifier le comportement par défaut. Elle exposait ou retenait des champs de télémétrie. Elle fournissait des contrôles de politique réseau et les conclusions du Trust Center. Elle pouvait observer des signaux transversaux qu'aucun locataire ne pouvait voir seul. Elle pouvait ensuite intégrer une protection contre les mots de passe compromis dans le service.

Il s'agit d'un contrôle réel, même si le client était propriétaire du compte.

Le rapport annuel de Snowflake pour l'exercice 2025, disponible à l'adressehttps://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htm, 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 réglementaire est une déclaration de l'entreprise, et non une décision judiciaire. Il est néanmoins pertinent car Snowflake elle-même a divulgué que la campagne affectait le risque commercial au-delà de chaque locataire client. La responsabilité partagée est devenue un enjeu pour une entreprise cotée en bourse.

Le prisme de cet article n'est donc pas « Snowflake a été compromise » ou « les clients sont seuls fautifs ». Il s'agit de la réparation vérifiable. Après une campagne qui exploite un schéma prévisible d'accès par simple mot de passe, d'identifiants obsolètes volés par infostealer et d'absence de restrictions réseau, le fournisseur et les clients ont besoin de preuves que la prochaine campagne similaire trouvera moins d'identifiants viables, moins de sessions par simple mot de passe, moins d'origines sans restriction, de meilleures alertes et une fourniture de preuves plus rapide.

La chaîne de la campagne a utilisé des fonctions ordinaires sous une identité hostile

Mandiant a décrit un enchaînement pratique. Les identifiants avaient été volés par un logiciel malveillant de type infostealer sur des systèmes n'appartenant pas à 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 ne disposaient pas de MFA. Les instances clientes n'avaient pas de listes d'autorisation réseau.

Les attaquants se connectaient avec des clients et outils standards, effectuaient des reconnaissances, sélectionnaient des données, préparaient les résultats, compressaient des fichiers et les récupéraient. Ce schéma utilisait des fonctionnalités de base de données prises en charge, mais sous une identité non autorisée.

Cette distinction est essentielle pour la réparation. Le chiffrement au repos n'était pas la barrière décisive. La documentation de Snowflake sur le chiffrement de bout en bout, disponible à l'adressehttps://docs.snowflake.com/en/user-guide/security-encryption-end-to-end, 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'impact après la connexion. L'aperçu du contrôle d'accès de Snowflake, à l'adressehttps://docs.snowflake.com/en/user-guide/security-access-control-overview, décrit les rôles, les privilèges, la propriété et la hiérarchie. Un identifiant volé avec des accès restreints est différent d'un identifiant doté de privilèges de lecture étendus ou d'administration du 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 qui renvoie une vue unique et une session hostile qui parcourt les principales tables du client.

La classification et le masquage des données peuvent réduire les conséquences. La documentation de Snowflake sur la classification des données sensibles, à l'adressehttps://docs.snowflake.com/en/user-guide/classify-intro, associe la découverte des colonnes sensibles au masquage et aux politiques d'accès aux lignes. Cela ne prouve pas que les clients concerné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 à part entière. Les déchargements en masse sont légitimes dans une plateforme de données. Ils prennent en charge l'analytique, la sauvegarde, les traitements en aval et les flux de travail de modèles. Mais une session inhabituelle créant des étapes temporaires, exportant des volumes importants de 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 doit rendre ces événements mesurables, attribuables et, pour les ensembles de données à haut risque, interruptibles.

La disponibilité de la MFA est devenue un résultat MFA

La MFA était disponible avant la campagne. Les comptes concernés dans le rapport de Mandiant n'en disposaient pas. Cette lacune 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 affirmer en toute honnêteté que le contrôle était disponible. Mais un fournisseur qui voit de nombreux comptes à haute valeur encore accessibles par simple mot de passe n'a pas atteint le résultat de sécurité, il a seulement rendu le paramètre disponible.

L'annonce de Snowflake en septembre 2024, à l'adressehttps://www.snowflake.com/en/blog/multi-factor-identification-default/, a modifié 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 annonçait également des exigences de mot de passe plus strictes pour les mots de passe des nouveaux utilisateurs et ceux 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 nouveaux comptes et les comptes existants est tout aussi significative. Un paramètre par défaut pour les futurs comptes ne supprime pas automatiquement tous les chemins d'accès par simple mot de passe dans le parc installé. 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 doit donc mesurer directement le risque hérité: nombre et proportion d'utilisateurs humains sans MFA, d'utilisateurs humains privilégiés sans MFA, d'utilisateurs avec mot de passe dont la dernière connexion est ancienne, d'utilisateurs avec des identifiants exposés connus, de comptes de service utilisant des mots de passe plutôt qu'une authentification de charge de travail plus forte, et d'exceptions avec des propriétaires métier et des dates d'expiration.

La documentation de Snowflake sur les politiques d'authentification, à l'adressehttps://docs.snowflake.com/en/user-guide/authentication-policies, donne aux administrateurs le contrôle des méthodes d'authentification, des clients, des fournisseurs d'identité et de l'inscription à la MFA. Sa documentation sur l'authentification par paire de clés, à l'adressehttps://docs.snowflake.com/en/user-guide/key-pair-auth, offre aux comptes de service une alternative aux mots de passe statiques. Ces contrôles imposent des obligations aux clients, mais ils définissent également la surface de réparation du fournisseur: le produit doit faciliter les bonnes pratiques, rendre visibles les mauvaises exceptions et rendre la migration moins risquée.

Les directives du NIST sur l'identité numérique, à l'adressehttps://pages.nist.gov/800-63-4/sp800-63b.html, aident à formuler le résultat attendu. Les mots de passe ne résistent pas à la relecture. Les méthodes résistantes à l'hameçonnage ou liées cryptographiquement réduisent la valeur d'un mot de passe volé. Pour les clients de Snowflake, cela signifie que les administrateurs humains doivent passer par une identité fédérée ou une MFA forte, tandis que les utilisateurs de service doivent utiliser des identifiants de charge de travail à portée limitée, qui tournent et peuvent être désactivés sans usurper l'identité d'une personne.

Le blocage des mots de passe compromis a rendu la responsabilité partagée mesurable

La réparation la plus directe du fournisseur après une campagne de vol d'identifiants n'est pas une leçon sur la réutilisation des mots de passe. C'est de faire en sorte que les mots de passe volés connus cessent de fonctionner. L'annonce de Snowflake en décembre 2024, à l'adressehttps://www.snowflake.com/en/blog/leaked-password-protection/, 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 compromis et toujours valides. Ce contrôle répond à l'avantage central de la campagne: des identifiants volés bien avant 2024 sont restés acceptés par le service.

La protection contre les mots de passe compromis ne supprime pas le devoir du client. Les clients doivent toujours assurer la sécurité des terminaux, la gouvernance des sous-traitants, la rotation des mots de passe, la fédération, la conception des utilisateurs de service et le principe du moindre privilège. Mais elle modifie la division du travail. Les clients individuels ne peuvent souvent pas voir le marché mondial des infostealers aussi bien qu'un fournisseur 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 ce 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 celle de l'adoption et de la performance. Combien de mots de passe compromis valides ont été trouvés? Avec quelle rapidité ont-ils été désactivés? Combien appartenaient à des utilisateurs privilégiés? Combien de comptes sont passés du mot de passe à la paire de clés ou à l'accès fédéré? Combien d'événements de désactivation de mot de passe ont entraîné des frictions de support ou des solutions de contournement non sécurisées? Combien de clients ont encore des exceptions? Sans indicateurs, la protection contre les mots de passe compromis reste une bonne annonce.

Avec des indicateurs, elle devient une réparation vérifiable.

L'engagement de la CISA « Secure by Design », disponible à l'adressehttps://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf, illustre 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 indicateurs d'adoption. L'annonce de l'engagement de Snowflake en juillet 2024, à l'adressehttps://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/, a inscrit l'entreprise dans cet engagement public. L'engagement est volontaire et ne constitue pas un verdict juridique sur la campagne. Il est pertinent car il identifie le type de preuve que les clients devraient attendre après l'événement.

La politique réseau constituait une deuxième barrière

Mandiant a identifié l'absence de listes d'autorisation réseau comme un facteur récurrent. La documentation de Snowflake sur les politiques réseau, à l'adressehttps://docs.snowflake.com/en/user-guide/network-policies, indique le paramètre par 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 modèles de connectivité privée pour des frontières plus solides.

Le client est l'acteur le mieux placé pour connaître les origines légitimes: bureaux, VPN, charges de travail cloud, postes de travail de 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 sans restriction est silencieux ou visible. Un programme de réparation vérifiable devrait indiquer quels comptes n'ont pas de politique 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 sont pas suffisants à eux seuls. Un attaquant peut utiliser un VPN approuvé, compromettre une machine de sous-traitant déjà à l'intérieur d'une liste d'autorisation ou voler un jeton après l'authentification. Pourtant, la défense doit être stratifiée. 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. Rompre un seul maillon peut avoir de l'importance. La réparation consiste à réduire le nombre d'environnements clients où tous les maillons restent ouverts simultanément.

Le fournisseur doit également sécuriser la gestion des verrouillages. Les administrateurs peuvent éviter les politiques réseau par crainte de bloquer des utilisateurs métier ou des tâches de service. La simulation, le déploiement progressif, les contacts d'urgence, les exceptions temporaires et des journaux clairs réduisent cette crainte. Plus le chemin de migration est bon, plus il est difficile de considérer l'absence de politique comme normale.

La télémétrie constitue la frontière de la preuve

Après une campagne de vol de données, les clients ont besoin de plus que de simples 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 qui peuvent soutenir ce travail.

LOGIN_HISTORY, à l'adressehttps://docs.snowflake.com/en/sql-reference/account-usage/login_history, fournit les tentatives de connexion avec l'IP source, le client, le succès et les informations sur le facteur. QUERY_HISTORY, à l'adressehttps://docs.snowflake.com/en/sql-reference/account-usage/query_history, fournit l'activité de requête, l'utilisateur, le rôle, le texte de la requête, la taille du résultat, les lignes déchargées et les octets envoyés sur le réseau. ACCESS_HISTORY, à l'adressehttps://docs.snowflake.com/en/sql-reference/account-usage/access_history, peut aider à reconstituer l'accès aux objets et aux colonnes pour les éditions éligibles. La documentation du Trust Center, à l'adressehttps://docs.snowflake.com/en/user-guide/trust-center/overview, décrit les contrôles de posture et les détections pour la MFA, les politiques réseau, les connexions à risque, les adresses IP inhabituelles et les transferts volumineux.

Ce sont des capacités. La capacité n'est pas une preuve de préparation à l'enquête. Les clients doivent avoir le droit 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 terminaux et des tickets. Les différences d'édition peuvent modifier la précision de la portée au niveau des champs. Les vues du fournisseur peuvent avoir des délais qui comptent pour le confinement actif.

Le texte de la requête seul peut ne pas indiquer à l'équipe de confidentialité quelles personnes étaient représentées, à moins que le client ne dispose de cartographies de données.

La réparation vérifiable doit donc inclure des dossiers de preuve. Lorsque Snowflake informe un client potentiellement exposé, le client doit recevoir les identifiants de compte, les utilisateurs, les horodatages, les réseaux d'origine, l'état du premier et du deuxième facteur, les identifiants de client, les identifiants de session et de requête, les rôles, les objets touchés, les noms d'étape, le volume déchargé, le niveau de confiance et les mesures de confinement recommandées.

Un libellé tel que « potentiellement exposé » est acceptable comme introduction, mais il doit être suivi de données suffisantes pour que le client décide si des informations personnelles ont été impliquées.

L'intervention du fournisseur nécessite également une autorisation préalable. Un fournisseur cloud peut voir une activité suspecte avant un client, mais le blocage automatique d'une session peut interrompre la production. Ne pas agir peut permettre le vol. La réparation doit définir des seuils pour la suspension temporaire, les contacts d'urgence avec le client, la préservation des preuves et la dérogation. Les clients doivent désigner des contacts de sécurité capables d'agir à toute heure. Snowflake doit mesurer le délai entre le signal transversal et l'avis au client, ainsi que le délai entre l'avis et le confinement.

La localité des données s'est arrêtée à l'accès

Le choix de la région Snowflake peut avoir de l'importance pour la latence, la résilience, la confidentialité et les achats. La documentation sur les régions prises en charge, à l'adressehttps://docs.snowflake.com/en/user-guide/intro-regions, indique qu'un compte est hébergé dans une région et que les données y restent, sauf si les utilisateurs les copient, les déplacent ou les répliquent explicitement. Elle précise également la limite essentielle: 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 pouvaient être stockées dans une région approuvée. Une identité valide pouvait toujours se connecter d'ailleurs, interroger les données, les décharger vers une étape et en télécharger une copie. L'emplacement du compte source n'empêchait pas l'accès à distance ni l'exportation. Le dossier public de la campagne n'établit pas les pays source et de destination pour chaque victime, de sorte qu'aucune conclusion juridique universelle transfrontalière n'est possible. La leçon architecturale demeure: la localité du stockage n'est pas la localité de l'accès.

Les recommandations de Snowflake sur le partage inter-régions, à l'adressehttps://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.html, 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 un autre pays. Ces recommandations concernent les mouvements approuvés. L'exportation par vol d'identifiants est différente car elle peut créer une copie incontrôlée en dehors de la région sélectionnée sans changer la région du compte source. Un inventaire de données qui n'enregistre que la région source peut être exact mais néanmoins incomplet après une exportation.

La réparation de la souveraineté des données nécessite donc 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 affectations de rôles, les approbations de mouvement et l'analyse des notifications. Les deux parties ont besoin de preuves à leur frontière.

Les cas clients montrent les conséquences, pas un décompte unique

La forme publique de la campagne a été influencée par les divulgations des entreprises concernées. Chaque dossier doit rester dans le cadre de ses propres faits.

Le dépôt de Live Nation en mai 2024, à l'adressehttps://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htm, 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 Ticketmaster, et qu'un acteur criminel a ensuite proposé à la vente de prétendues données utilisateur de l'entreprise. Le dépôt ne nommait pas Snowflake et ne fournissait pas de décompte confirmé des personnes touchées.

La page d'incident de Ticketmaster Canada, à l'adressehttps://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incident, décrivait une base de données cloud tierce isolée, les champs possibles pour certains acheteurs de billets nord-américains, et la limite selon laquelle les comptes clients Ticketmaster n'étaient pas affectés. Le commissaire à la protection de la vie privée du Canada a par la suite identifié Snowflake comme le fournisseur de Ticketmaster lors d'un exposé parlementaire à l'adressehttps://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/, tout en indiquant que l'enquête restait ouverte et que Ticketmaster Canada demeurait le responsable du traitement examiné.

Le dépôt d'AT&T en juillet 2024, à l'adressehttps://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htm, décrivait un accès illégal à un espace de travail AT&T sur une plateforme cloud tierce et l'exfiltration d'enregistrements d'interactions d'appels et de textos. 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, et non comme une attribution autonome.

Ces exemples ne créent pas un décompte de personnes à l'échelle de la campagne. Les quelque 165 organisations potentiellement exposées selon Mandiant constituent une population de notification, et non un nombre confirmé de victimes, un nombre d'enregistrements ou un nombre de personnes touchées. Chaque client détenait des données, des rôles, des durées de conservation, des régions et des obligations de notification différents. La réparation vérifiable doit aider chaque client à délimiter ses propres faits, plutôt que de faire porter tout le poids par un seul chiffre au niveau de la plateforme.

Une note typographique pour les dossiers de preuve

Lorsque les clients reçoivent des preuves de sécurité cloud de gravité élevée, la mise en page peut déterminer si la bonne personne agit rapidement. Un tableau des sessions, des facteurs, des rôles, des objets et des transferts doit être lisible sous pression. Le bloc typographique suivant appartient au corps public car la conception des preuves fait partie de la réparation.

La typographie est l'art et la technique d'arranger les caractères pour rendre le langage écrit lisible, facile à lire et visuellement attrayant. Elle implique le choix des polices, des tailles de points, des longueurs de ligne, de l'interlignage et de l'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés incluent le choix de la police, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

Pour les clients de Snowflake, des preuves lisibles signifient des horodatages dans une base de temps unique, des libellés clairs d'utilisateur et de rôle, la 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 concernés. Une exportation dense de journaux peut être complète mais inutilisable. Un dossier de preuve concis peut faire la différence entre une décision de confinement rapide et une analyse de confidentialité retardée.

Responsabilité par le contrôle pratique

Les attaquants contrôlaient l'activité criminelle: utilisation d'identifiants volés, pénétration dans les environnements clients, préparation des données, leur vol, et tentative de vente ou d'extorsion. Ils sont responsables de ces actes.

Les clients contrôlaient de nombreuses barrières qui ont échoué. Ils créaient des utilisateurs, attribuaient des rôles, choisissaient si les utilisateurs humains pouvaient se connecter avec des mots de passe seuls, conservaient des identifiants obsolètes, autorisaient l'accès des sous-traitants, laissaient certains comptes sans politique réseau, accordaient l'accès aux données et régissaient 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 rejeter toute la responsabilité sur le fournisseur.

Snowflake contrôlait la base de référence et les outils de réparation. L'entreprise contrôlait si les nouveaux utilisateurs humains avaient la MFA par défaut, si les mots de passe compromis étaient désactivés côté fournisseur, si les configurations à risque apparaissaient dans le Trust Center, quels champs de télémétrie étaient disponibles, comment les clients étaient notifiés, comment les recommandations étaient rédigées et à quelle vitesse les contrôles post-campagne étaient déployés.

Un fournisseur qui observe le même schéma chez plusieurs locataires a le devoir de réduire ce schéma à grande échelle, et non pas seulement de dire à chaque client de lire le manuel.

Les fournisseurs d'identité, les sous-traitants et les propriétaires de terminaux contrôlaient les conditions adjacentes. Les appareils de sous-traitants utilisés chez plusieurs clients peuvent propager un incident d'infostealer vers plusieurs locataires cloud. Les fournisseurs d'identité peuvent appliquer des facteurs plus forts et un accès conditionnel. Les terminaux gérés peuvent empêcher les identifiants de se retrouver sur des machines personnelles. Ces acteurs comptent, mais ils n'effacent pas les obligations des clients et du fournisseur concernant le compte Snowflake lui-même.

Les régulateurs, les assureurs et les équipes d'approvisionnement contrôlent les incitations. Les directives du NIST sur la chaîne d'approvisionnement, à l'adressehttps://csrc.nist.gov/pubs/sp/1305/final, soutiennent la définition d'exigences pour les fournisseurs proportionnées à la criticité. Pour un entrepôt de données, cela signifie que les contrats et les renouvellements doivent exiger des indicateurs d'adoption de la MFA, la réponse aux mots de passe compromis, les champs du dossier de preuve, les garanties de rétention, les délais de notification, l'escalade de support et les contrôles de mouvement régional. Un questionnaire de sécurité qui demande uniquement 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 sont soumis par défaut à la MFA ou à un accès fédéré plus fort, et le parc installé montre une proportion croissante de comptes humains protégés et de comptes humains privilégiés. Deuxièmement, les utilisateurs de service abandonnent les mots de passe statiques au profit de paires de clés, OAuth ou d'autres identifiants de charge de travail à portée limitée avec rotation. Troisièmement, les rapports de protection contre les mots de passe compromis confirment les événements de désactivation et le délai 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 conclusions du Trust Center ne sont pas simplement affichées mais corrigées 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 les découvertes tardives et la délimitation des problèmes de confidentialité. Septièmement, les détections de déchargements volumineux et d'origines inhabituelles sont affinées et acheminées vers des personnes capables d'agir. Huitièmement, les notifications du fournisseur incluent des preuves concrètes de session, de requête, de rôle, d'objet et de transfert.

Neuvièmement, les clients concernés peuvent faire correspondre 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 au lieu de se baser sur des formulations de responsabilité partagée.

Les litiges peuvent influencer le dossier mais ne doivent pas remplacer les preuves de contrôle. L'ordonnance au stade des plaidoiries dans le litige multidistrict Snowflake, disponible à l'adressehttps://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdf, a autorisé certaines allégations à procéder tout en les traitant selon des normes procédurales. Il ne s'agit pas d'une conclusion définitive de responsabilité. Cela montre que les tribunaux peuvent examiner les paramètres par défaut du fournisseur, la prévisibilité et le lien de causalité même lorsque le récit public commence par des identifiants client.

Le problème du parc installé

Les paramètres par défaut sécurisés sont plus efficaces au moment de la création. Ils sont plus difficiles à appliquer dans un parc installé où les clients disposent déjà d'automatisation, d'utilisateurs de service, de sous-traitants, de fournisseurs d'identité, de vieux clients et de comptes de secours. Le changement de Snowflake vers la MFA par défaut pour les nouveaux comptes était une étape importante, mais le risque de la campagne résidait largement dans les comptes existants avec des habitudes existantes.

La réparation vérifiable nécessite donc une histoire de migration pour le parc installé, et pas seulement une histoire pour les nouveaux comptes.

Le problème du parc installé comporte plusieurs couches. Premièrement, les anciens utilisateurs humains peuvent encore s'authentifier directement par mot 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 verrouillage. Troisièmement, les utilisateurs de service peuvent être mal classifiés comme humains, ou des humains peuvent utiliser des identifiants de type service. Quatrièmement, les sous-traitants peuvent conserver l'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 ces frictions sans prendre le contrôle du locataire du client. Il peut montrer aux administrateurs une liste priorisée d'identités à risque, réparties 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 à des modèles de paire de clés ou OAuth.

Il peut envoyer des rappels produits répétés liés 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 avec mot de passe uniquement et les laisse inchangés pendant des mois assume ce risque résiduel. Un client qui ne peut pas dire si un compte de sous-traitant est encore nécessaire assume une défaillance 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 auparavant » assume une portée de rôle excessive.

La responsabilité partagée devient concrète lorsque le fournisseur montre les preuves et que le client remédie ou enregistre une exception responsable.

Le dossier de réparation doit séparer trois états: corrigé, exception acceptée et inconnu. Corrigé signifie que la condition à risque a disparu. Exception acceptée 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 de responsabilité. Un programme mature fait tendre le nombre d'inconnus vers zéro. Les assurances publiques omettent souvent cette distinction; la réparation vérifiable en dépend.

Les preuves client doivent relier les journaux techniques aux personnes

Snowflake peut exposer une télémétrie technique riche, mais la réponse en matière de confidentialité et juridique 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 qu'un début. Le client doit savoir quelle table contenait quels champs personnels, quelles 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 ne pas savoir qui notifier.

Ce pont doit être préparé avant un incident. Les propriétaires de données doivent maintenir des inventaires de champs pour les données réglementées, la finalité commerciale, la période de conservation, la politique de masquage et les voies d'exportation approuvées. Les équipes de sécurité doivent savoir où les journaux Snowflake sont conservés en dehors de la plateforme et pendant combien de temps. Les équipes de confidentialité doivent pouvoir demander une liste des tables concernées et recevoir une correspondance avec les catégories de personnes et de champs.

Les équipes juridiques doivent savoir quelles régions et quels contrats clients sont liés à ces enregistrements.

Les preuves fournies par le 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 l'origine était inhabituelle et si la protection contre les mots de passe compromis a ultérieurement 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 reconstituer les preuves alors que le délai pour la notification et la réponse à l'extorsion est déjà entamé.

La campagne a également révélé un problème de rétention pour la télémétrie elle-même. Les historiques natifs peuvent couvrir un an, mais les litiges juridiques, les découvertes tardives et les demandes des régulateurs peuvent s'étendre plus longtemps. Les clients à haut risque doivent diffuser les journaux dans un stockage de sécurité indépendant avec une rétention alignée sur leurs obligations. Un fournisseur doit rendre cette exportation pratique et documentée. Le client doit prouver son bon fonctionnement en reconstituant périodiquement un échantillon de chemin d'accès, de la connexion à la requête jusqu'à la catégorie de données.

La réparation ne peut pas reposer sur la honte des clients

Après une campagne de vol d'identifiants, il est tentant de considérer les clients sans MFA comme la leçon de l'histoire. C'est en partie vrai, mais encore insuffisant. Faire honte publiquement aux clients ne désactive pas les mots de passe compromis, ne redessine pas les paramètres par défaut et ne fournit pas de dossiers de preuve. Cela peut même pousser les clients à cacher des configurations faibles jusqu'à ce qu'un incident impose 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ù les conséquences le justifient. Les clients bénéficient de temps de migration et d'outils, mais ils perdent aussi la possibilité de laisser des lacunes à haut risque invisibles. Les équipes d'approvisionnement demandent alors des indicateurs d'adoption et des comptes d'exceptions, et 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 d'entreprise. Un fournisseur qui crée un paramètre par défaut plus sûr peut brièvement augmenter les frictions pour les clients, mais il réduit également le nombre de cibles disponibles pour les groupes criminels. Un client qui accepte l'application de la règle peut devoir mettre à jour des scripts ou des identités, mais il gagne une meilleure histoire pour les régulateurs, les assureurs et les personnes concernées.

La réparation fonctionne lorsque les deux parties peuvent pointer des conditions modifiées, et non des messages modifiés.

Les achats doivent exiger une télémétrie de réparation

Un acheteur d'une plateforme de données à haute valeur doit traiter la télémétrie post-campagne comme une exigence d'achat. La question n'est pas seulement de savoir si le fournisseur propose désormais la MFA, les politiques réseau, les contrôles de mots de passe compromis et les conclusions du Trust Center. La question est de savoir si l'acheteur peut recevoir la preuve 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'achat doit demander un rapport de couverture d'identité, incluant les utilisateurs humains, les utilisateurs privilégiés, les utilisateurs de service, les comptes dormants, les sous-traitants externes, le statut de fédération, le statut MFA et les exceptions de mot de passe. Il doit demander la couverture réseau par compte, classe d'utilisateur, étapes internes et points de terminaison privés. Il doit demander si la protection contre les mots de passe compromis est activée, quels avis d'événement elle produit et comment un mot de passe désactivé est reflété dans les enregistrements d'audit.

Il doit demander quelles conclusions du Trust Center sont disponibles au niveau d'abonnement souscrit et combien de temps l'historique pertinent est conservé.

Les conditions relatives aux incidents doivent ê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 les notifications de gravité élevée, des champs de preuve qui seront inclus, des contacts d'urgence, de l'escalade de support, de la conservation des journaux et de la coopération pour la délimitation des personnes concernées. Un client qui détient des données personnelles réglementées doit exiger des échantillons de dossiers de preuve avant le renouvellement, et non 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 concernés dans le délai nécessaire.

Cela ne transfère pas tout le travail à 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'achat qui ne demande que des attestations manquera le 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 lors des renouvellements. Si un client reste sur un accès fortement basé sur les mots de passe un an après la campagne, le renouvellement doit imposer une exception nommée ou une migration financée. Si un client ne peut pas recevoir le niveau de détail ACCESS_HISTORY en raison de l'édition, le renouvellement doit documenter si cette limitation est acceptable pour les données stockées. Si les politiques réseau sont absentes, le renouvellement doit identifier clairement le blocage opérationnel. La réparation doit être examinée avant que le levier ne disparaisse dans une nouvelle durée de contrat.

Les preuves de renouvellement doivent également séparer les changements de plateforme des changements de locataire. Snowflake peut déployer un paramètre par défaut plus fort, mais le compte du client peut encore contenir des utilisateurs avec mot de passe uniquement, des rôles étendus, des sous-traitants obsolètes et des étapes non examinées. L'acheteur doit demander le registre des exceptions propre au compte, et non la feuille de route produit du fournisseur.

Cette distinction évite une dérive post-incident familière: le fournisseur annonce un contrôle, les clients supposent que le risque a diminué, et le parc installé reste matériellement exposé.

Pour les conseils d'administration et les équipes de confidentialité, ce dossier 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 concerné 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 faire correspondre les requêtes aux champs réglementés. La réparation vérifiable réside dans ces réponses spécifiques au compte.

Ce qu'il ne faut pas déduire

Un compte rendu mesuré doit é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 toutes les organisations notifiées ont perdu des données. Troisièmement, elle ne prouve pas que tous les clients concernés avaient les mêmes champs, personnes ou obligations légales. Quatrièmement, les modifications des produits après la campagne ne prouvent pas à elles seules une négligence avant les modifications.

Les produits de sécurité évoluent après les incidents pour de nombreuses raisons, notamment de meilleurs renseignements sur les menaces et des normes modifiées.

En même temps, la mesure n'exige pas le silence sur le devoir du fournisseur. Un fournisseur peut être exempt de conclusion de violation de plateforme et néanmoins ê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 fautif pour des contrôles d'identité faibles et néanmoins avoir besoin des données du fournisseur pour enquêter. Une ordonnance judiciaire peut être non définitive et néanmoins montrer que la MFA par défaut et la prévisibilité seront examinées. Une responsabilité équilibrée maintient toutes ces propositions en vie simultanément.

L'évaluation finale est un impact élevé et une confiance élevée. Les preuves confirmées soutiennent une campagne par identifiants clients, et non une violation 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 n'est crédible que lorsque les deux parties peuvent montrer les barrières qu'elles ont fermées. Après cette campagne, le test de Snowflake n'est pas de pouvoir dire que la MFA existait.

Il est de savoir si moins de mots de passe volés peuvent devenir des sessions, si moins de sessions peuvent atteindre des données étendues et si plus de clients peuvent prouver exactement ce qui s'est passé avant que les données ne partent.