Les récents vols de données client semblent s’accumuler pour Snowflake, le géant du cloud spécialisé dans la gestion des données. Après Ticketmaster, c’est au tour de LendingTree de confirmer une fuite de données via sa filiale QuoteWizard, stockées chez Snowflake. Face à ces incidents à répétition, le fournisseur reste discret, se contentant de rappeler qu’il n’y a pas eu de faille dans ses propres systèmes. Mais que cache réellement Snowflake ?

Une responsabilité rejetée sur les clients

Plutôt que d’admettre une quelconque responsabilité, Snowflake pointe du doigt le manque d’authentification multifacteur (MFA) chez ses clients touchés. Une mesure de sécurité que Snowflake n’impose pas et n’active pas par défaut. Comble de l’ironie, un compte de démonstration appartenant à un ex-employé de Snowflake a lui-même été compromis, faute de MFA.

Sous le modèle de responsabilité partagée de Snowflake, les clients sont responsables de l’application de la MFA auprès de leurs utilisateurs.

– Snowflake

Cette position de Snowflake interroge. Ne serait-il pas judicieux de protéger par défaut les comptes clients avec une authentification forte, plutôt que de faire reposer ce fardeau sur les utilisateurs ? D’autres acteurs comme 23andMe ont réagi bien différemment dans des situations similaires, en réinitialisant les mots de passe et en imposant la MFA.

L’ampleur de l’incident encore floue

Si Ticketmaster et LendingTree ont révélé avoir été touchés, combien d’autres des 9800 clients de Snowflake sont concernés ? Mystère, Snowflake restant évasif sur l’étendue de l’incident. L’entreprise affirme avoir notifié un « nombre limité » de clients potentiellement affectés. Mais s’agit-il de dizaines, de centaines? Snowflake ne précise pas.

De même, on ignore depuis quand Snowflake a connaissance de ces intrusions. Si des accès non autorisés ont été détectés à partir de mi-avril, pourquoi avoir attendu fin mai pour alerter les clients ? Snowflake disposait-il d’indices bien avant sans réagir ? Beaucoup de questions restent en suspens.

Une communication minimaliste qui interroge

Au delà des zones d’ombres sur l’incident en lui-même, c’est l’attitude de Snowflake qui interpelle. Sollicité à de multiples reprises, le fournisseur s’est refusé à tout commentaire et n’a daigné que répéter ses déclarations sibyllines. Même sur des points cruciaux comme la nature des données exposées, Snowflake reste mutique. Décidément peu loquace pour une entreprise dont la transparence est censée être une valeur clé.

Ce silence assourdissant tranche avec la réaction d’autres acteurs confrontés à des fuites de données. On pense notamment à Okta, qui n’avait pas hésité à communiquer en détail sur son incident de sécurité l’an dernier. Une transparence saluée, bien loin de l’opacité dont fait preuve Snowflake.

Un électrochoc nécessaire pour Snowflake ?

Cet épisode souligne les failles béantes dans l’approche sécurité de Snowflake. Au delà des mesures réactives comme la réinitialisation des mots de passe et l’application forcée de la MFA qui brillent par leur absence, c’est une véritable prise de conscience qui semble nécessaire.

• Imposer l’authentification multifacteur par défaut
• Mettre en place une surveillance proactive des accès suspects
• Adopter une communication transparente en cas d’incident

Autant de chantiers qui attendent Snowflake pour restaurer la confiance. Car au-delà de la sécurité de sa plateforme, c’est la crédibilité même de l’entreprise qui est en jeu. Dans un marché du cloud ultra-concurrentiel et sur un sujet aussi sensible que les données, les clients en attendent plus de leur fournisseur. A Snowflake de relever le défi, pour ne pas voir fondre sa réputation comme neige au soleil.