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 motivée financièrement à UNC5537 et a indiqué que chaque incident de la campagne qu'elle a directement traité provenait d'identifiants clients compromis. Elle n'a trouvé aucune preuve que l'accès non autorisé aux clients découlait d'une brèche dans 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 l'activité.
• Chaîne de contrôle observée:Les comptes compromis ne disposaient pas d'authentification multifacteur, conservaient des identifiants exposés dans des historiques de logiciels malveillants de vol d'informations et n'avaient 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 préparer, 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 brèches confirmées, de personnes ou d'enregistrements.
• Constat de responsabilité partagée:Les clients contrôlaient leurs utilisateurs, rôles, rotation des mots de passe, inscription à l'AMF, politiques réseau, hygiène des terminaux et minimisation des données. Snowflake contrôlait les protections existantes, leur présentation et leurs valeurs par défaut, les signaux inter-clients que la plateforme pouvait voir, ainsi que la rapidité des alertes et du renforcement du comportement de base sur la base installée. Ces responsabilités sont concurrentes, non mutuellement exclusives.
• Constat de souveraineté:Choisir une région Snowflake détermine où se trouvent le stockage et le calcul du compte; la documentation de Snowflake précise expressément que cela ne limite pas l'accès des utilisateurs. Dans cette campagne, une identité valide pouvait transformer un ensemble de données stocké régionalement en une copie téléchargée. La localisation des données sans contrôles d'identité, de sortie et de preuve est une décision de placement, pas un contrôle de souveraineté complet.

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 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, exploiter une vulnérabilité logicielle, obtenir un compte administrateur du fournisseur ou briser l'infrastructure séparant les clients. Les preuves publiques soutiennent une compromission de compte client. Elles ne soutiennent pas une compromission technique à l'échelle de la plateforme.

Le rapport de campagne UNC5537 de Mandiant est inhabituellement direct sur ce point. Pour chaque incident associé à la campagne que Mandiant a lui-même traité, la cause première était des identifiants clients compromis. Son enquête n'a trouvé aucune preuve que l'accès non autorisé aux comptes clients provenait d'une brèche dans l'environnement d'entreprise de Snowflake. La propre notice d'enquête et de durcissement de Snowflake a également séparé les comptes clients ciblés de la plateforme de production et a fourni aux clients des requêtes et indicateurs pour enquêter sur leurs propres environnements.

CISA a amplifié ces conseils dans une alerte du 3 juin 2024.

Cette constatation négative est importante. Qualifier l'événement de brèche de la plateforme Snowflake peut sous-entendre qu'un défaut dans le code ou l'infrastructure partagée a ouvert chaque locataire, ou que Snowflake a perdu un identifiant maître qui a déverrouillé les clients. Le dossier examiné n'établit ni l'un ni l'autre. Cela obscurcirait également les actions que les clients devaient prendre immédiatement: identifier les utilisateurs avec mot de passe seul, faire pivoter les identifiants, inspecter l'historique des connexions et des requêtes, restreindre les réseaux, réduire les privilèges des rôles et conserver 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 utilisées par les attaquants, le moteur de requêtes qui a traité leurs commandes, la télémétrie qui a enregistré les sessions et les contrôles produit qui auraient pu exiger un deuxième facteur ou restreindre l'origine réseau.

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

Le formulaire 10-K de Snowflake pour l'exercice 2025 formalise sa position. Il indique que Snowflake est responsable de la plateforme et de la sécurité 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 à l'incapacité des clients à remplir leurs obligations telles que l'AMF et les politiques réseau, tout en enregistrant des poursuites, des enquêtes réglementaires, des demandes de législateurs, des atteintes à la réputation et la possibilité de litiges 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 chaque responsabilité ou réclamation légale appartient au client.

La question utile est donc plus étroite que « Qui a été compromis? » et plus large que « Quel mot de passe a été volé? » Elle est: à chaque étape, du secret volé aux données téléchargées, quel acteur a pu prévenir, détecter, interrompre, reconstruire ou alerter sur l'action? La responsabilité suit le contrôle sur ces étapes.

La campagne a combiné un vol de terminal ancien à une autorité cloud actuelle

Mandiant a obtenu pour la première fois un renseignement sur les menaces en avril 2024 concernant des enregistrements de base de données ultérieurement attribués à 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 vol d'informations. Le compte concerné n'avait pas d'AMF 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 durcissement pour les clients le 30 mai. Au moment du rapport de juin, Mandiant et Snowflake avaient notifié environ 165 organisations potentiellement exposées.

Chaque terme dans cette dernière phrase doit être protégé contre l'inflation. « Environ » marque une estimation. « Potentiellement exposées » décrit une population notifiée, pas 165 conclusions médico-légales complètes. « 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 affecté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 sorties historiques de logiciels malveillants de vol d'informations, l'infection associée la plus précoce ayant été observée en novembre 2020. Au moins 79,7 % des comptes exploités par l'acteur avaient une exposition antérieure des 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 transformé à plusieurs reprises des secrets exposés en un accès fonctionnel. Les comptes impactés n'étaient pas configurés avec l'AMF. Les mots de passe trouvés dans les enregistrements de logiciels malveillants de vol d'informations restaient valides, parfois pendant des années. Les instances client concernées manquaient de listes d'autorisation réseau qui auraient restreint les connexions à des origines de confiance. Aucune de ces conditions n'est une exploitation nouvelle.

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 ne le suggère le récit conventionnel de l'ordinateur portable d'un employé. Dans plusieurs enquêtes, Mandiant a trouvé l'infection antérieure par un logiciel malveillant de vol d'informations sur des systèmes de sous-traitants également utilisés pour des activités personnelles, notamment des jeux ou des téléchargements piratés. Un appareil de sous-traitant peut se situer en dehors du parc de terminaux gérés du client tout en transportant des identifiants pour plusieurs clients.

Il peut également détenir un compte administratif car les 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 outils de terminal du client.

C'est un multiplicateur de dépendance 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 métier. L'attaquant n'a plus besoin de compromettre ces systèmes source 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 l'entrée non autorisée dans les environnements clients; de la prise de données; et de la tentative de vente ou d'extorsion. Décrire les défaillances de contrôle qui ont rendu ces crimes possibles ne dilue pas cette responsabilité. Cela explique pourquoi la même technique criminelle a réussi à grande échelle et où la récurrence peut être réduite.

Des fonctionnalités prises en charge sont devenues une voie d'exfiltration

La campagne ne s'est pas arrêtée à l'authentification. Mandiant a observé un accès via Snowsight, SnowSQL, des pilotes et des outils de base de données. L'acteur a listé les utilisateurs, rôles, sessions, noms d'organisation, bases de données, schémas et tables. Il a utilisé des opérations SQL courantes pour sélectionner des données, créer des stages temporaires, copier les résultats de requêtes 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 compréhensible 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 privilèges d'objet attribués par le client.
3. La reconnaissance a identifié les tables de valeur et les stages disponibles.
4. Les requêtes ont sélectionné les enregistrements que le rôle était autorisé à lire.
5. Le stage 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'exigeait que la base de données fonctionne mal. C'est pourquoi le chiffrement au repos, bien que nécessaire, n'était pas le contrôle décisif. La documentation de chiffrement de bout en bout de Snowflake indique que les données clients 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 opérations sur les tables et permet aux utilisateurs de décharger et 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 doit utiliser sa hiérarchie de clés pour servir les requêtes autorisées. À moins qu'une politique de clé ne soit connectée à une décision distincte rejetant la session ou l'opération, la base de données ne peut pas distinguer le propriétaire du compte d'un intrus qui a satisfait à la politique d'authentification configurée par le propriétaire.

La conception des rôles contrôlait donc le rayon d'action après la connexion. Le modèle de contrôle d'accès actuel de Snowflake prend en charge les contrôles d'accès basés sur les rôles et discrétionnaires, la propriété, la hiérarchie des rôles et les privilèges d'objet. Un identifiant attribué uniquement à une base de données ou vue étroite présente une conséquence différente de celui détenantACCOUNTADMIN, une large utilisation de l'entrepôt ou un accès en sélection sur des ensembles de données bruts. Un compte de service utilisé par une intégration ne devrait pas hériter de la portée exploratoire d'un administrateur humain.

Le rôle temporaire d'un 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. La documentation de classification des données sensibles de Snowflake relie la découverte de colonnes personnelles et sensibles à des politiques de masquage et d'accès aux lignes. Il s'agit d'une description de capacité actuelle, pas d'une preuve que chaque client affecté avait classifié ou masqué ses données en 2024. Elle établit 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 gouvernée en tant que telle. Un entrepôt de données a souvent besoin de déchargements en masse pour des pipelines légitimes, des sauvegardes, l'entraînement de modèles et des systèmes aval. Une interdiction générale est rarement réaliste.

Mais créer un stage, décharger un résultat inhabituellement volumineux ou utiliser un client et une origine réseau non familiers devrait être observable et, pour les ensembles de données à haut risque, pourrait 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 séparé. 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 paramètre; Snowflake possédait la ligne de base

L'AMF est le test de responsabilité partagée le plus aigu car les deux côtés peuvent énoncer un fait vrai. L'administrateur client était capable et censé l'activer. Snowflake proposait l'AMF depuis 2015 et les politiques réseau depuis 2016. Dans le même temps, les comptes réussis en 2024 pouvaient s'authentifier sans AMF, ce qui signifie que la ligne de base effective du service permettait un chemin par 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 pourtant absente des sessions qui comptent. Les administrateurs font face à des intégrations anciennes, des utilisateurs de service non interactifs, des sous-traitants, des comptes de secours, plusieurs clients et la peur du verrouillage. Ces contraintes expliquent la friction 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 l'information nécessaire pour construire des outils de migration, séparer les identités humaines et de service, et rendre les exceptions explicites.

Après la campagne, l'orientation publique de Snowflake est passée de la recommandation à des paramètres par défaut plus forts. Son annonce d'engagement Secure by Design de juillet 2024 mettait l'accent sur les contrôles de politique d'AMF et les vérifications Trust Center. En septembre 2024, Snowflake a déclaré que l'AMF serait appliquée par défaut pour les utilisateurs humains dans les comptes créés à partir d'octobre 2024, tout en recommandant le SSO avec AMF du fournisseur d'identité pour les humains et l'authentification OAuth ou par paire de clés pour les services. La distinction entre comptes nouveaux et existants est importante.

Une valeur par défaut sécurisée protège les créations futures; elle ne retire pas automatiquement chaque chemin de mot de passe hérité dans la base installée.

Snowflake a ensuite introduit la protection des mots de passe divulgués, qui utilise des flux de renseignement sur les menaces pour tester les mots de passe divulgués signalés dans un processus préservant la confidentialité et désactiver un mot de passe lorsqu'il est confirmé comme toujours valide. Ce contrôle côté fournisseur répond directement à l'un des avantages d'UNC5537: les anciens identifiants de logiciels malveillants de vol d'informations qui restaient utilisables. C'est également la preuve que la responsabilité partagée peut évoluer.

Les clients doivent toujours gérer les identités et les rotations, mais le fournisseur peut utiliser le renseignement interservices pour faire cesser l'utilisation d'un mot de passe volé avant que chaque client ne le trouve indépendamment.

La documentation actuelle des politiques d'authentification permet aux administrateurs de contrôler les méthodes et clients autorisés et d'exiger l'AMF au niveau du compte ou de l'utilisateur. Elle avertit également que les restrictions de type de client sont au mieux et ne devraient pas constituer la seule frontière de sécurité. Les directives actuelles sur les paires de clés offrent aux utilisateurs de service une alternative aux mots de passe statiques. Ces pages décrivent les capacités disponibles d'ici 2026;

elles ne doivent pas être lues rétrospectivement comme une preuve des fonctionnalités, des valeurs par défaut ou de l'état d'application exacts pour chaque client en avril 2024.

Les normes aident à expliquer pourquoi les paramètres par défaut du fournisseur appartiennent à l'analyse. Les directives actuelles d'authentification et de gestion des authentifiants du NIST traitent les mots de passe comme non résistants à la relecture et définissent la résistance au phishing comme une propriété de protocole qui ne dépend pas de la vigilance de l'utilisateur.

L' engagement Secure by Design de la CISA de 2024 identifie spécifiquement l'AMF par défaut, les incitations persistantes du produit, le support de base du 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'AMF. Snowflake a signé cet engagement volontaire après la campagne. L'engagement n'est pas un verdict juridique sur la conception 2024 de Snowflake, mais il rejette l'idée qu'offrir une case à cocher épuise le rôle du fournisseur.

La ligne de base responsable distingue les types d'identité. Les administrateurs humains devraient utiliser une AMF résistante au phishing ou une identité fédérée fortement gouvernée. Les charges de travail de service devraient utiliser des identifiants de travail pouvant être délimités, rotés et attribués sans faire semblant 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 des 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 deuxième 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é depuis une infrastructure n'ayant aucune raison professionnelle d'accéder à l'entrepôt du client. Les restrictions réseau n'auraient pas réparé un mot de passe volé, mais elles auraient pu rendre ce mot de passe insuffisant depuis une origine non fiable.

La documentation actuelle des politiques réseau de Snowflake rend la valeur par défaut explicite: sans politique, les utilisateurs peuvent se connecter depuis n'importe quel ordinateur ou appareil. Les clients peuvent autoriser ou bloquer des plages 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 au stage interne avec une configuration supplémentaire. La connectivité privée et les contrôles d'accès public peuvent renforcer davantage les comptes à haute sensibilité.

Le client connaît ses bureaux approuvés, ses charges de travail cloud, ses VPN, ses sous-traitants et ses points de terminaison d'intégration, donc le client doit définir la liste d'autorisation utilisable. Snowflake ne peut pas déduire chaque origine légitime sans perturber l'activité. Pourtant, le fournisseur contrôle l'accessibilité par défaut, la syntaxe de la politique, la capacité de 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é, se router via un VPN d'entreprise autorisé, compromettre une charge de travail dans le 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 à une détection comportementale, 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'AMF 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 le staging. La détection aurait pu raccourcir le temps de séjour. 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 stages internes » est un résultat opérationnel. « AMF disponible » est un fait produit. « Aucun humain privilégié ne peut établir une session avec un mot de passe réutilisable seul » est un résultat. La responsabilité partagée devient significative seulement 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, clients, adresses IP, texte de requête, rôles, stages et mouvements de données. Snowflake pouvait corréler des modèles entre comptes: la même infrastructure, des clients inhabituels, des reconnaissances répétées, des commandes de staging similaires, une augmentation des connexions par mot de passe seul ou des identifiants correspondant à des flux de renseignement sur les menaces. Cette asymétrie est la responsabilité non contractuelle la plus importante du fournisseur. Elle est créée en opérant le service à grande échelle.

La vue LOGIN_HISTORY actuelle de Snowflake conserve un an de tentatives de connexion et inclut l'utilisateur, l'IP d'origine, le client signalé, le premier et le deuxième facteurs, le succès et les détails de risque associés, avec une latence documentée. QUERY_HISTORY conserve un an d'activité de requêtes et relie une requête à l'événement d'authentification, la session, l'utilisateur, le rôle, le texte, les octets de résultat, les lignes déchargées et les octets envoyés sur le réseau.

Les clients Enterprise peuvent utiliser ACCESS_HISTORY pour reconstruire les tables, vues, colonnes, stages, politiques et objets modifiés auxquels on a accédé. Ces schémas fournissent la matière première pour une enquête de haute qualité.

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

Ces faits produit et opérationnels devraient être testés lors de l'achat, pas découverts après un vol.

Le Trust Center actuel de Snowflake vérifie l'inscription à l'AMF, 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 importants via des scanners de sécurité et de renseignement sur les menaces. La documentation actuelle indique également des limitations: certains packages doivent être activés; certaines détections peuvent arriver dans l'heure; et l'existence d'une politique configurée ne prouve pas que son contenu atteint l'objectif visé.

Encore une fois, la capacité actuelle n'est pas une preuve de ce qu'un client donné ou Snowflake a détecté au printemps 2024. Cela montre ce qu'un fournisseur peut industrialiser une fois qu'un schéma de défaillance inter-clients est compris.

Le système d'alerte 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'analytique de campagne et d'un processus éprouvé pour notifier les clients avec suffisamment de preuves pour agir.

Une notification utile inclut les identifiants du compte et de l'utilisateur, les horodatages en UTC, l'infrastructure source, le facteur d'authentification, les identifiants de session et de requête, les commandes, les objets et colonnes touchés, les actions de staging, le volume de transfert estimé, le statut de confinement et la confiance. « Potentiellement exposé » 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 a également besoin de gouvernance. Bloquer automatiquement une session client peut interrompre la production et peut dépasser l'autorité contractuelle du fournisseur. Ne pas agir peut permettre la poursuite du vol. La conception devrait donc définir les seuils de risque, les suspensions temporaires, les canaux d'escalade client, les contacts d'urgence et un processus de dérogation rapide à l'avance. Les clients devraient nommer des personnes capables de recevoir une alerte de haute sévérité à 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 ensemble complet de preuves.

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

Snowflake commercialise et documente le déploiement régional car les clients ont des exigences de latence, de résilience, de confidentialité, de réglementation et de souveraineté. La documentation des régions prises en charge de Snowflake indique que chaque compte est hébergé dans une région et que les données restent dans cette région sauf si les utilisateurs les copient, les déplacent ou les répliquent explicitement. La même page contient la limite critique: les régions dictent où les données sont stockées et le calcul est 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, préparer les résultats et les télécharger vers un client. Mandiant a observé le schéma technique de récupération locale depuis des stages 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, donc aucune affirmation universelle de transfert transfrontalier illicite n'est soutenable. L'architecture montre néanmoins que la localisation du stockage seule ne pouvait pas imposer la localisation de l'utilisateur.

Le partage et la réplication inter-régions créent une voie de mouvement légitime distincte. Les directives de partage inter-régions de Snowflake demandent aux organisations de confirmer les restrictions légales et réglementaires avant de répliquer des données vers une région ou un pays différent. Il s'agit d'un mouvement planifié sous administration client. L'exportation pilotée par les identifiants est différente: elle peut créer une copie non contrôlée en dehors de l'environnement sélectionné sans modifier l'emplacement du compte source.

Un inventaire des 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.
• Preuve et remède:si l'organisation peut prouver d'où provenait l'accès, ce qui est parti, quelles personnes ou enregistrements réglementés étaient impliqués, et à quelle vitesse elle peut confiner et notifier.

Le fournisseur contrôle des parties importantes de ces 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 demandes et expose les contrôles réseau. Il exécute les commandes d'exportation et enregistre les métadonnées de requête. Il détient une visibilité inter-clients sur les menaces et peut désactiver les mots de passe divulgués. Le client décide de sa base légale, de ses catégories de données, de ses rôles, de ses origines autorisées, de son masquage, de sa conservation et de ses mouvements approuvés.

Un engagement d'hébergement régional sans ces contrôles complémentaires peut satisfaire une exigence étroite d'emplacement 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é contre l'opérateur d'infrastructure ou un lecteur non autorisé de la couche de stockage. Une application qui doit analyser l'objet rend nécessairement les données disponibles à un contexte de requête autorisé. Si l'assurance d'identité et la portée des rôles sont faibles, la localisation cryptographique peut coexister avec l'exfiltration opérationnelle.

Les divulgations des clients montrent des conséquences différentes, pas une brèche uniforme

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

Le formulaire 8-K de Live Nation du 31 mai 2024 a indiqué 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 a déclaré que le 27 mai, un acteur criminel avait proposé à la vente ce qu'il prétendait être des données utilisateur de l'entreprise, et que Live Nation notifiait les forces de l'ordre, les régulateurs et les utilisateurs selon les besoins. Le dépôt ne nommait pas Snowflake, ne fournissait pas de nombre confirmé de personnes affectées et n'expliquait pas le chemin d'authentification.

La page d'incident de Ticketmaster Canada donne un niveau de détail différent. Elle décrit un accès non autorisé à une base de données cloud isolée hébergée par un fournisseur de services de données tiers, indique que la base de données contenait des informations personnelles limitées de certains acheteurs de billets nord-américains et liste les champs possibles, dont l'email, 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 clients Ticketmaster n'ont pas été affectés.

Cette dernière limite est importante: la compromission d'un entrepôt de données back-end n'est pas une preuve que l'attaquant a obtenu l'identifiant Ticketmaster de chaque personne ou pouvait effectuer des transactions via le compte consommateur.

La fiche parlementaire d'octobre 2025 du Commissariat à la protection de la vie privée du Canada identifie Snowflake comme le fournisseur tiers utilisé par Ticketmaster, donne une fenêtre d'incident du 2 avril au 18 mai 2024 pour Ticketmaster Canada, et indique que les informations personnelles de millions de personnes, dont des Canadiens, étaient impliquées. Elle précise également que l'enquête restait ouverte et que Ticketmaster Canada, en tant que responsable du traitement au sens de la LPRPDE, était l'entité sous enquête.

Il s'agit d'un contexte réglementaire utile, mais pas d'une conclusion finale qui résout l'adéquation des garanties, le délai de notification ou la responsabilité.

Le formulaire 8-K d'AT&T du 12 juillet 2024 illustre pourquoi les limites des sources sont importantes même lorsque les incidents sont discutés ensemble. AT&T a déclaré qu'un acteur avait accédé illégalement à un espace de travail AT&T sur une plateforme cloud tierce et exfiltré des fichiers du 14 au 25 avril. Les fichiers contenaient des enregistrements d'interactions d'appels et de textes pour presque tous les clients sans fil d'AT&T et les clients d'opérateurs de réseau mobile virtuels pertinents 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 de contenu d'appels ou de textes, de numéros de sécurité sociale, de dates de naissance ou d'autres informations personnelles selon la définition d'AT&T. Le dépôt lui-même ne nomme pas Snowflake ou UNC5537. Il soutient les faits de l'incident d'AT&T, pas une attribution de campagne à lui seul.

Ces dossiers 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 un identifiant 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 affecté » parallèlement à l'impact. La responsabilité devient moins crédible lorsque l'analyse élargit les affirmations dramatiques et supprime les limites.

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

Le côté client de la responsabilité partagée est substantiel. L'organisation a créé ou approuvé des utilisateurs Snowflake, sélectionné les chemins d'authentification, attribué des rôles, chargé des données, conservé l'historique, choisi une région, activé des 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 du droit applicable à la protection des données.

Un client aurait pu interrompre la campagne observée à plusieurs points. Il aurait pu faire pivoter les mots de passe après une exposition de terminal, interdire les comptes de service avec mot de passe seul, exiger l'AMF pour les humains, fédérer l'accès via un fournisseur d'identité gouverné, restreindre les réseaux, faire expirer les utilisateurs sous-traitants, réduire les octrois de rôles, classifi er et masquer les champs sensibles, isoler le privilège d'exportation, surveiller l'historique des connexions et des requêtes, et répéter les notifications au 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 optionnelles déléguées aux achats.

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

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

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

Les clients possèdent également la préparation à la réponse. Ils devraient être capables de mapper un utilisateur Snowflake à un employé ou sous-traitant, une requête aux personnes concernées et une exportation à une juridiction et une analyse de notification. Les historiques natifs d'un an peuvent être insuffisants pour une conservation légale plus longue ou une découverte tardive, donc les clients à haut risque devraient diffuser les événements pertinents vers un stockage de sécurité indépendant.

Les alertes du fournisseur doivent emprunter un chemin d'urgence connu vers l'équipe de sécurité du client, le bureau de la vie privée, le propriétaire métier et le décideur exécutif.

Le guide de la chaîne d'approvisionnement du cadre de cybersécurité du NIST recommande de définir et de communiquer les exigences des fournisseurs en fonction de la criticité. Appliqué ici, un client Snowflake devrait contractualiser le délai de notification d'incident, les champs de preuve, la conservation, l'escalade de support, le traitement régional, la visibilité des sous-traitants, le préavis de modification 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 rédigée comme des interfaces testables, pas un paragraphe qui n'apparaît qu'après un incident.

Snowflake est resté 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'AMF désactivée. Il contrôlait 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 alertes persistantes et ce que le fournisseur faisait après avoir observé un schéma entre clients.

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

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

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

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

Télémétrie actionnable.Les clients ont besoin de preuves d'authentification, de requête, d'objet, de stage et de transfert avec une rétention suffisante et une latence suffisamment faible pour contenir un vol actif. Les preuves de plus haute fidélité ne devraient pas devenir indisponibles précisément là où le service stocke les données au plus fort impact.

Alerte et coordination.Une alerte client doit transiter par une voie d'urgence connue et porter des preuves, pas seulement un conseil de consulter les journaux. Le fournisseur devrait suivre l'accusé de réception, le confinement et l'exposition récurrente, et soutenir les demandes des forces de l'ordre et des régulateurs sans transformer des observations incertaines en décomptes de victimes confirmés.

Vérification post-incident.Les fonctionnalités et valeurs par défaut annoncées nécessitent des mesures d'adoption et d'efficacité. Les changements ultérieurs de Snowflake vers l'AMF par défaut, la désactivation des mots de passe divulgués, les constats Trust Center et des types d'identité plus forts répondent à la voie observée. La question de responsabilité qui reste est la couverture: quels utilisateurs et clients sont réellement 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 cloud profite 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 base.

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

Snowflake et les entreprises concernées ont fait face à des litiges civils consolidés après les incidents. Dans une ordonnance judiciaire fédérale du 29 octobre 2025, le tribunal de district du Montana a estimé que les plaignants institutions financières avaient suffisamment plaidé certaines théories de négligence contre Snowflake et Ticketmaster pour survivre aux requêtes en rejet. Le tribunal a traité l'AMF par défaut allégué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 conclusion de procès selon laquelle Snowflake ou Ticketmaster a été négligent. Sur une requête en rejet, le tribunal teste si des 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 plaignant et n'alloue pas les dommages. Snowflake a contesté les allégations et a fait valoir que les défaillances des clients à mettre en œuvre l'AMF, les politiques réseau et d'autres mesures de protection avaient causé le préjudice.

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

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

Le propre 10-K de Snowflake a reconnu de nombreuses poursuites, enquêtes réglementaires et demandes de législateurs, mais n'a pas rapporté d'attribution finale universelle de responsabilité. À la date de publication, les sources publiques examinées ici ne soutiennent pas le fait de déclarer que Snowflake a été légalement exonéré, que chaque client était légalement en faute, ou qu'un tribunal ou 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'AMF et les politiques réseau? Oui. Snowflake pouvait-il concevoir des valeurs par défaut et détecter l'activité inter-clients? Oui. Des criminels ont-ils intentionnellement exploité le chemin résultant? Oui. Ces propositions peuvent coexister.

Le droit de la responsabilité délictuelle, contractuel, de la protection des données et des valeurs mobilières peut attribuer des conséquences différemment selon la juridiction et le plaignant, mais l'ingénierie ne devrait pas attendre qu'un slogan gagne.

Un test mesurable de 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 de défaillance 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 AMF résistante au phishing, le nombre d'utilisateurs de service capables d'utiliser un mot de passe, l'âge de chaque exception de secours, le pourcentage de comptes avec des politiques réseau testées, le nombre d'identités de sous-traitants privilégiées après expiration, le temps médian pour alerter sur des origines inconnues, le temps pour suspendre une session à haute confiance et le temps pour produire un dossier d'exposition au niveau champ.

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

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

Les clients 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 constats, 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 massif de données.

Ce que le dossier public n'établit toujours pas

Les preuves sont suffisamment solides pour reconstruire un schéma 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é et ne fournit pas de total final à l'échelle de la campagne des personnes, tables, enregistrements ou octets téléchargés affectés. Il ne montre pas quelles victimes ont payé des demandes d'extorsion ou 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'AMF, 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 constats d'appareils de sous-traitants issus de plusieurs enquêtes ne devraient pas être attribués à chaque victime. La statistique d'exposition d'identifiants de 79,7 % 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 à chaque client Snowflake. L'utilisation observée de clients et commandes pris en charge est une preuve d'abus d'identifiants, pas la preuve que le code 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; l'analyse juridique du transfert nécessiterait des faits de source, de destination, de personne concernée, contractuels et juridictionnels pour chaque client.

Il ne permet pas de généraliser les champs possibles de Ticketmaster, la portée des détails d'appel d'AT&T ou tout décompte de forum criminel à d'autres clients. Le dépôt de Live Nation ne nommait pas Snowflake. Le dépôt d'AT&T ne nommait pas Snowflake ni 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'AMF par défaut ultérieure, la protection des mots de passe divulgués, la détection Trust Center, les politiques d'authentification et les changements d'identité peuvent réduire la récurrence, mais les preuves publiques d'adoption, de couverture des exceptions, de performance de détection et d'efficacité indépendante restent plus limitées que les descriptions de fonctionnalités.

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

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

UNC5537 a trouvé une jonction évolutive entre la compromission de terminal et la concentration cloud. Les mots de passe historiques restaient valides. Les identités humaines et de service n'étaient pas toujours séparées. L'AMF et les portes réseau étaient absentes. Les fonctions de requête et de staging prises en charge déplaçaient rapidement les données. Le fournisseur pouvait voir un schéma entre les locataires, tandis que chaque client ne voyait que son propre compte. Une région de stockage choisie pouvait maintenir les données source en place même pendant qu'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, rôles, terminaux, sous-traitants et 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 le comportement de campagne et de fournir des preuves. Les attaquants avaient la responsabilité directe des actes criminels. Les régulateurs et les tribunaux doivent évaluer les devoirs légaux sur les faits et le droit applicables à chaque organisation. Ces attributions se chevauchent car les contrôles se chevauchent.

L'orientation produit post-campagne reconnaît implicitement l'écart entre capacité et résultat. L'AMF 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 constats Trust Center rapprochent la sécurité de la ligne de base du fournisseur. Ils n'effacent pas la responsabilité du client. Ils rendent le système partagé moins dépendant du fait que chaque administrateur trouve et active chaque option correcte avant qu'un mot de passe volé ne soit testé.

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

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