Le MFA, une course à obstacles pour Snowflake

Publié par Clément Bohic le 31 oct. 2024 - mis à jour à 12:58

Depuis qu'il s'est trouvé au coeur d'une campagne de cyberattaques, Snowflake tente d'accélérer l'adoption du MFA chez ses clients.

Faut-il changer régulièrement ses mots de passe ?

Snowflake fait partie de ceux qui le recommandent. Il en parle notamment dans un livre blanc qui consigne, en une douzaine de pages, d'autres mesures destinées à réduire le risque de compromission d'authentifiants.

Les dernières évolutions de ce document portent en particulier sur le MFA. En toile de fond, la campagne de cyberattaques au coeur de laquelle Snowflake s'est trouvé au printemps 2024.

Après cet épisode, l'éditeur avait entrepris de favoriser la mise en place du MFA. Notamment en donnant aux admins la possibilité de l'exiger pour tous, utilisateurs SSO compris. Il avait également ajouté deux packages dans son Trust Center. L'un, activé par défaut sans surcoût sur toutes les éditions, vérifie la conformité MFA et l'usage de politiques réseau. L'autre évalue les comptes sur la base du benchmark CIS de Snowflake.

Il était aussi question de rendre le MFA obligatoire pour tout utilisateur humain sur les nouveaux comptes. C'est chose faite depuis peu. En parallèle, une politique plus robuste est mise en place pour la définition des nouveaux mots de passe et de ceux associés à la commande alter user (modification des propriétés et des paramètres d'objet/de session pour un utilisateur existant). Il faut désormais au minimum 14 caractères (contre 8 auparavant). Et on ne peut pas choisir un des cinq derniers mots de passe utilisés.

Snowflake face aux systèmes hérités

Cet été, Snowflake a signé - comme l'ont fait quelque 230 autres organisations - le Secure By Design Pledge de l'ANSSI américaine. Les engagements pris dans ce cadre couvrent 7 objectifs :

Augmenter l'usage du MFA

Réduire l'usage de mots de passe par défaut

Réduire la prévalence de certaines classes de vulnérabilités

Accroître l'installation des correctifs par les clients

Publier une politique de divulgation des vulnérabilités

Démontrer une transparence dans le reporting des vulnérabilités

Augmenter la capacité des clients à réunir des preuves d'intrusion

Au-delà du MFA, ledit livre blanc s'est récemment enrichi de conseils concernant les comptes de service. Pour eux, Snowflake recommande d'utiliser, OAuth ou des paires de clés... aussi longtemps que les systèmes concernés supportent ces méthodes.

Snowflake a par ailleurs introduit une propriété TYPE qui permet de distinguer entre utilisateurs humains (PERSON) et machine (SERVICE). Les premiers se voient appliquer les politiques MFA définies au niveau du compte sauf s'ils sont soumis à des politiques de niveau utilisateur. Les seconds sont exemptés du MFA au niveau du compte et sont soumis à des restrictions telles que l'impossibilité d'utiliser des mots de passe ou du SSO.
Sur les systèmes hérités qui ne prennent en charge que les mots de passe, on n'utilisera pas l'étiquette SERVICE et on appliquera des politiques d'authentification spécifiques. Pour mieux exclure ces systèmes (notamment au niveau du monitoring MFA dans le Trust Center), Snowflake prévoit d'ajouter un type LEGACY_SERVICE.

Pour les utilisateurs humains, Snowflake conseille d'activer le MFA au niveau du fournisseur d'identité - sans oublier, pour les cas où ce dernier serait hors ligne, de définir un accès de secours (compte break-glass). Si l'IDP ne supporte pas le MFA, on utilisera celui de Snowflake - qui peut aussi constituer un double rempart pour les comptes à hauts privilèges.

Pour ce qui est des politiques réseau applicables aux comptes de services, la "nature dynamique du cloud" peut constituer un obstacle. Certains fournisseurs, fait remarquer Snowflake, ne peuvent communiquer de plages stables d'adresses IP. La solution ? Par exemple, utiliser une connectivité privée... si les outils concernés la supportent.