Masking absent, IBAN exposés : ce que le RGPD reproche au consultant Snowflake
Un secure share ouvert à un partenaire, une masking policy jamais déployée, et des données clients sensibles fuitent. Décryptage de votre exposition RGPD.
- Sur Snowflake, la confidentialité des données repose sur trois briques que vous configurez : RBAC, masking policies et secure data sharing.
- Une masking policy oubliée ou un share trop large peut exposer des données personnelles et déclencher une notification CNIL dans les 72 heures.
- Le consultant est sous-traitant au sens du RGPD : il a des obligations propres et peut voir sa responsabilité engagée directement.
- RC Pro pour la faute de configuration, garantie cyber pour les frais de notification, d'expertise forensic et de gestion de crise : les deux sont complémentaires.
Les trois briques de sécurité que vous tenez entre vos mains
Sur Snowflake, vous n'êtes pas un simple exécutant SQL : vous êtes l'architecte du cloisonnement des données. Trois mécanismes décident, ligne par ligne, qui voit quoi.
- Le RBAC (Role-Based Access Control). Tout accès passe par un rôle. Une hiérarchie de rôles mal pensée — un rôle applicatif qui hérite par erreur d'
ACCOUNTADMIN, ou unGRANTsur un schéma entier au lieu d'une vue — ouvre des portes invisibles. - Les masking policies. Le dynamic data masking masque les colonnes sensibles (IBAN, e-mail, numéro de sécurité sociale) selon le rôle qui interroge. La policy doit être écrite ET appliquée à chaque colonne concernée : une policy définie mais non attachée ne masque rien.
- Le secure data sharing. Un share expose des objets à un autre compte Snowflake sans copie. Un share dont le périmètre est trop large diffuse en clair des données que vous pensiez internes.
Chacune de ces briques est un point de défaillance unique. Et chacune relève typiquement de votre prestation.
Le scénario type : la policy définie mais jamais attachée
Le sinistre le plus fréquent n'est pas un piratage spectaculaire. C'est une erreur de configuration silencieuse.
Vous écrivez une masking policy propre pour la colonne IBAN de la table CLIENTS. Vous la testez sur l'environnement de dev. Mais lors de la promotion en production, le script qui attache la policy à la colonne (ALTER TABLE ... MODIFY COLUMN ... SET MASKING POLICY) échoue silencieusement, ou n'est tout simplement pas exécuté. La policy existe, elle apparaît dans le catalogue — mais elle n'est rattachée à rien.
Résultat : pendant des semaines, tout rôle ayant accès à la table lit les IBAN en clair, alors que l'audit interne suppose que le masking est actif puisque la policy figure bien dans l'inventaire.
La fuite est découverte lors d'un contrôle, ou pire, parce qu'un partenaire ayant reçu un share signale qu'il voit des données qu'il ne devrait pas. À ce moment, l'horloge RGPD démarre.
Ce que dit le RGPD : vous êtes sous-traitant, pas simple témoin
Beaucoup de consultants pensent que la responsabilité RGPD pèse uniquement sur le client (le responsable de traitement). C'est inexact. En configurant des accès à des données personnelles pour le compte d'un client, vous agissez comme sous-traitant au sens de l'article 28 du RGPD.
À ce titre, vous avez des obligations propres :
- mettre en œuvre des mesures techniques appropriées (article 32) — le masking et le cloisonnement RBAC en font partie ;
- n'agir que sur instruction documentée du responsable de traitement ;
- assister le client dans la notification des violations.
En cas de violation, le responsable de traitement doit notifier la CNIL dans les 72 heures et, si le risque pour les personnes est élevé, informer les personnes concernées. Si l'enquête montre que la faille vient d'une masking policy que vous deviez attacher et que vous avez omise, votre responsabilité de sous-traitant peut être engagée — y compris au titre des sanctions, qui peuvent atteindre des montants considérables pour le responsable de traitement, lequel se retournera contre vous.
RC Pro et cyber : deux garanties qui ne couvrent pas la même chose
Face à une fuite de données par erreur de configuration, deux garanties interviennent, et il faut les distinguer.
La RC Pro répond de la faute professionnelle : la masking policy oubliée, le rôle trop permissif, le share mal borné. Elle indemnise le préjudice subi par votre client et finance votre défense quand il se retourne contre vous.
La garantie cyber couvre un autre versant : les frais de gestion de la crise elle-même, qui sont souvent les plus lourds à court terme :
- expertise forensic pour déterminer l'étendue exacte de l'exposition (qui a accédé à quoi, quand) ;
- frais de notification aux personnes concernées et accompagnement dans la déclaration CNIL ;
- communication de crise et accompagnement juridique ;
- défense en cas de procédure administrative.
Pour un consultant qui manipule en permanence des données sensibles, la combinaison des deux est la couverture cohérente : la RC Pro pour la responsabilité, le cyber pour le coût de la réponse à incident.
La checklist de configuration qui vous met hors de cause
La meilleure assurance reste de ne jamais déclencher le sinistre. Avant toute mise en production touchant des données personnelles, déroulez ce contrôle :
- Vérifier l'attachement, pas seulement l'existence des masking policies, via
POLICY_REFERENCES: chaque colonne sensible doit pointer vers sa policy. - Auditer la hiérarchie de rôles avec
GRANTS_TO_ROLES: aucun rôle métier ne doit hériter d'un rôle d'administration. - Lister les shares actifs et leur périmètre exact ; bannir tout share au niveau base ou schéma quand une vue filtrée suffit.
- Activer le principe du moindre privilège : on accorde sur des vues, jamais sur des tables brutes.
- Tracer la conformité dans un document de recette signé par le client : c'est votre preuve d'avoir agi selon les règles de l'art.
Ce document de recette est précieux. En cas de litige, il établit que vous avez livré une configuration conforme à une date donnée, et déplace la charge de la preuve vers tout changement postérieur. Retrouvez les autres risques propres à votre activité sur la page consultant Snowflake.
Questions fréquentes
Oui. En configurant l'accès à des données personnelles pour un client, vous agissez comme sous-traitant au sens de l'article 28 du RGPD. Vous avez des obligations propres (mesures techniques appropriées, action sur instruction documentée) et votre responsabilité peut être engagée en cas de faille de configuration.
Non. Une masking policy doit être à la fois définie et rattachée à chaque colonne sensible via ALTER TABLE. Une policy présente dans le catalogue mais non attachée ne masque rien : c'est l'une des causes de fuite les plus fréquentes et les plus discrètes.
Elle couvre la faute professionnelle et le préjudice causé au client, mais pas les frais spécifiques de la crise cyber (forensic, notification CNIL, communication). Pour ces coûts, une garantie cyber est nécessaire. Les deux sont complémentaires pour un métier de la data.
Le responsable de traitement doit notifier la CNIL dans les 72 heures suivant la prise de connaissance de la violation, et informer les personnes concernées si le risque pour leurs droits est élevé. En tant que sous-traitant, vous devez l'assister sans délai dans cette démarche.
Documentez un contrôle de recette signé par le client attestant l'attachement des masking policies, la hiérarchie RBAC et le périmètre des shares à une date donnée. Cette preuve d'avoir agi selon les règles de l'art déplace la charge vers tout changement postérieur.
Souscrivez votre assurance pro en 2 minutes
Toutes nos protections pour votre activité de Consultant Snowflake — attestation immédiate, sans engagement.
* Tarifs indicatifs « à partir de », selon votre profil, votre activité et les garanties choisies. · Voir la fiche Consultant Snowflake →
Article rédigé et vérifié par l'équipe Insurio — Tutassûr, courtier en assurance immatriculé à l'ORIAS sous le n° 22001730. Information à caractère général ne se substituant pas aux conditions de votre contrat.