Cybersécurité : Snowflake pense avoir compris

Snowflake impose la MFA

Snowflake prend ainsi des mesures déjà en vigueur ou en cours d’implémentation chez plusieurs acteurs, dont Salesforce, GitHub et Google Cloud.

Outre l’activation par défaut de l’authentification multiple pour tout compte détenu par un humain, créée à partir du mois d’octobre 2024, Snowflake encourage ses clients existants à suivre un lot de bonnes pratiques, dont l’usage d’un SSO et d’un système MFA externes ainsi que l’allongement des mots de passe à 14 caractères minimum, contre huit auparavant. Un mot de passe ne peut être réutilisé qu’après cinq changements.

Snowflake Horizon Catalog contient également deux fonctionnalités prochainement en disponibilité générale. La première confère à la plateforme de l’éditeur une protection native contre l’usage des mots de passe qui auraient été divulgués, ce qui devrait éviter les potentielles exfiltrations de données. Cet outil « vérifiera et désactivera automatiquement [l’accès] aux utilisateurs dont les mots de passe ont été découverts sur le Dark Web », assure l’éditeur dans un billet de blog.

Snowflake se met à la confidentialité différentielle

La seconde consiste à fournir des capacités de confidentialité différentielle. Cette approche exploite différentes approches algorithmiques et des règles pour limiter la réidentification de données sensibles, dont des informations personnelles. Si la règle correspondante est activée, Snowflake peut introduire un bruit aléatoire dans les résultats de requêtes.

« La quantité de bruit ajoutée dépend de la sensibilité de la requête, déterminée par les techniques mathématiques de la confidentialité différentielle », commente Snowflake, dans un billet de blog. « Par exemple, si la requête porte sur le calcul de grands agrégats, le niveau de bruit sera relativement faible, voire négligeable. Si la requête concerne un petit groupe ou même une personne, le bruit sera suffisamment important pour masquer leur identité et protéger vos données les plus sensibles contre les atteintes à la vie privée ».

Aussi, l’activation d’un budget de confidentialité doit permettre de limiter les « pertes de confidentialité » à la suite de requêtes répétées sur un même jeu de données. En contrepartie, la précision des analyses est plus faible et empêche l’usage de certains types de données.

« Snowflake a sélectionné des paramètres par défaut qui équilibrent raisonnablement la protection de la vie privée et l’utilité, conformément aux objectifs des cas d’usage réels, mais vous pouvez toujours définir des paramètres différents pour répondre à vos besoins spécifiques », peut-on lire dans la documentation de l’éditeur. Google a déjà introduit des mécanismes similaires dans BigQuery.

Pour les clients qui ne seraient pas à l’aise avec cette approche, Snowflake prépare un système d’autoclassification des données sensibles et propose le recours aux données synthétiques. À noter qu’il se dote d’une interface de visualisation de lignage de modèles de données et ML accessible depuis SnowSight. Les data stewards, pourront, eux, prochainement consulter l’historique des accès de données à l’échelle d’une organisation. En préversion privée, ils peuvent configurer les demandes d’accès à certains objets en gérant leur visibilité et en confiant la responsabilité à des collaborateurs identifiés comme tels.

Pour protéger les accès machines, l’éditeur introduira « prochainement » en préversion privée la prise en charge des tokens d’accès programmatique (PAT). Ceux-ci doivent renforcer la sécurité de l’authentification par API en limitant la durée de vie des connexions et les permissions des outils des développeurs via ces interfaces. GitHub a récemment revu ce mécanisme au sein de sa plateforme.

En outre, une connectivité privée sortante doit améliorer la protection de l’accès aux services externes sur AWS et Azure. Toutes les fonctionnalités d’interrogation ne sont pas encore disponibles et cette fonctionnalité n’est pas active dans les régions govCloud.

Une porte pour des partenariats

Enfin, le Trust Center, l’interface qui permet de gérer les postures de sécurité s’étoffe en disponibilité générale d’un « Scanner Package ». Il s’agit d’une fonctionnalité s’activant par défaut une fois par jour pour attribuer un score de sévérité aux comportements des utilisateurs ou des machines. Les scores sont agrégés dans l’UI Trust Center. Par exemple, un individu dont l’accès à un environnement Snowflake n’est pas restreint par une politique MFA et/ou réseau générera un score critique. C’est à la fois un mécanisme d’alerte et de remédiation pour les équipes de sécurité. L’année prochaine, Snowflake prévoit de prendre en charge d’autres paquets, dont ceux fournis par des partenaires en tant que Native Apps. Des scanners packages personnalisés seront bientôt disponibles en préversion privée. Ils sont conçus par ALTR, Hunters, OneTrust, Rubrik et TrustLogix.

Au-delà des mécanismes de base activés par défauts, bon nombre des fonctionnalités présentées sont encore en préversion privée ou publique. Un défaut récurrent chez Snowflake. Surtout, la plupart d’entre elles demandent un usage proactif de la part des administrateurs et une sensibilisation des développeurs et des métiers. Espérons que l’éditeur arrive à sensibiliser réellement ces clients, autrement ce ne sera qu’une posture de prédicateur… de postures de sécurité.