Snowflake Business Critical inclut un Trust Center et des scanners de sécurité actifs dès l'ouverture du compte. C'est une fondation utile, mais incomplète : le Trust Center couvre environ 60% de ce que votre équipe DBA doit surveiller. Les 40% restants relèvent de votre périmètre.
Si vous êtes responsable data, DBA ou RSSI sur un compte Business Critical, cet article décrit comment structurer votre posture de sécurité : un plan de maturité en trois phases, les contrôles à mettre en place et un modèle de RACI qui répartit clairement les responsabilités entre les équipes.
1. Le Shared Responsibility Model, la ligne qui change tout
Snowflake est un SaaS, pas un IaaS. Ça veut dire que la plateforme gère l'infrastructure, le patching, le chiffrement at-rest, la disponibilité. Vous gérez tout ce qui touche à vos utilisateurs, vos rôles, vos données.
Cette répartition tient en deux colonnes, séparées par une frontière contractuelle.
Schéma 1 · Shared Responsibility Model Snowflake
Snowflake sécurise la plateforme, vous sécurisez votre usage. Cette frontière est fixée par contrat.
Cette frontière définit qui porte la responsabilité en cas d'incident. Un compte ACCOUNTADMIN partagé entre quatre personnes relève de votre périmètre, pas de celui de Snowflake.
2. Ce que le Trust Center couvre vraiment
Le Trust Center, disponible en GA depuis fin 2024, est une console intégrée à Snowsight qui scanne en continu la configuration de votre compte et remonte des alertes. Deux composants à distinguer.
Schéma 2 · Les deux composants du Trust Center
Scanners = conformité de configuration. Alerts = détection d'événements anormaux. Les deux sont utiles. Aucun des deux ne remplace un SIEM.
Sur l'édition Business Critical, trois scanners additionnels apparaissent : Tri-Secret Secure, Customer Managed Keys, Private Link. Ces trois-là ne sont pas activés par défaut, même en Business Critical. Il faut aller les chercher.
Cet outillage est utile, mais limité sur quatre dimensions.
Limite 1
Pas de corrélation avec votre SI. Une connexion Snowflake suspecte à 3h du matin depuis une IP inconnue ne sera pas rapprochée d'un événement AD ou d'un ticket ITSM. Il faut un SIEM externe (Splunk, Sentinel, Elastic, Datadog, QRadar) qui ingère les logs via ACCOUNT_USAGE ou Snowpipe.
Limite 2
La classification des données n'est pas native. Le Trust Center ne sait pas si votre colonne customer_email doit être masquée. Il faut le déclarer via des tags et des policies SQL (CREATE MASKING POLICY, CREATE ROW ACCESS POLICY).
Limite 3
Traçabilité fine des changements de policies, limitée. Si quelqu'un modifie une masking policy en production, vous le verrez dans ACCOUNT_USAGE.ACCESS_HISTORY, pas dans le Trust Center.
Limite 4
La remédiation reste manuelle. Le scanner détecte un ACCOUNTADMIN inactif depuis 90 jours, il ne le désactive pas. Vous devez faire tourner un workflow opérationnel derrière, et le documenter.
À retenir
Le Trust Center est une excellente fondation. Il ne remplace ni un SIEM, ni une politique de classification des données, ni un RACI. C'est une brique, pas une solution complète.3. Plan de maturité : trois phases successives
Voici comment on sécurise un compte Snowflake dans l'ordre. Phase 1 en 2 à 4 semaines, Phase 2 en 2 à 3 mois, Phase 3 au-delà.
Schéma 3 · Plan de maturité en 3 phases
Trois phases qui se suivent dans cet ordre. La Phase 1 élimine l'essentiel du risque ; les phases suivantes n'apportent leur valeur qu'une fois la Phase 1 stabilisée.
Phase 1 : Quick wins (2 à 4 semaines)
Les actions qui éliminent 70% du risque pour un effort limité. MFA obligatoire pour tous les utilisateurs humains, sans exception. Network policies restrictives sur ACCOUNTADMIN et les comptes de service avec whitelist IP par défaut. Revue des comptes ACCOUNTADMIN (objectif 2 à 3 max, jamais un seul pour éviter le lockout). Activation du Trust Center avec tous les scanners par défaut. Rotation des clés RSA des comptes de service toutes les 90 jours. Ce sont des contrôles de base, encore absents sur beaucoup de comptes en production.
Phase 2 : Opérationnel (2 à 3 mois)
On passe de la checklist initiale au régime de run opérationnel. Intégration des logs Snowflake dans le SIEM : ACCOUNT_USAGE.LOGIN_HISTORY, QUERY_HISTORY, ACCESS_HISTORY. Rétention native Snowflake : 365 jours. Si vous avez besoin de plus (SOC 2 = 7 ans), externaliser vers S3 ou équivalent via des tâches planifiées. Alertes métier personnalisées au-delà de celles du Trust Center : téléchargement massif de données sensibles, requête croisant plus de 3 tables contenant des PII, usage d'un warehouse hors plage horaire, export vers un stage externe. Tri-Secret Secure activé si conformité SOC 2. Private Link pour les connexions depuis votre VPC.
Phase 3 : Gouvernance avancée (long terme)
Dynamic Data Masking : policies appliquées automatiquement selon le rôle. Un analyste marketing voit j***@****.fr, un commercial senior voit l'email complet. La requête SQL est identique, le résultat varie selon le rôle. Row Access Policies : même principe mais par ligne. Un commercial région Sud voit uniquement les clients région Sud, sans que le SQL applicatif ait à le savoir. Revue annuelle du Shared Responsibility Model avec l'équipe sécurité, car les nouveaux services (Snowpark, Cortex, Native Apps) redéfinissent la frontière.
4. Couvrir ce que le Trust Center ne voit pas
Une fois les trois briques en place (Trust Center, SIEM externe, policies SQL), la matrice de couverture s'éclaircit. Voici ce qui couvre quoi.
Schéma 4 · Matrice de couverture de la sécurité Snowflake
Trois briques complémentaires. Aucune ne couvre seule l'intégralité du périmètre ; la couverture complète est atteinte avec les trois en place, une fois la Phase 3 livrée.
5. Ce qu'il faut monitorer, à quelle fréquence, et par qui
Voici la synthèse des contrôles, de leur fréquence et de leur porteur.
Chaque ligne doit avoir un porteur nommé, pas une équipe générique, et un suppléant identifié. Si le porteur principal est absent au moment où une alerte tombe, le relais est prévu à l'avance.
6. Sans RACI, rien ne tient
Dernière brique, et de loin la plus structurante. Sur un compte Snowflake Business Critical, sept rôles minimum interviennent : Data Office, équipe plateforme data, architecture, exploitation, infrastructure, DBA, réseau et sécurité, avec le RSSI en approbateur sur les décisions sensibles. Sans RACI formalisé, chaque alerte Trust Center finit dans un ticket sans porteur.
Structurer le RACI sur trois axes.
Par activité. Typiquement 15 à 20 activités : gestion des comptes, network policies, masking policies, revue des logs, intégration SIEM, conformité SOC 2, gestion des incidents, revue des accès, rotation des clés, documentation. Chaque activité a un R (responsable), un A (approuvant), des C (consultés), des I (informés).
Par phase du plan de maturité. Phase 1 = DBA en R, RSSI en A. Phase 2 = DBA et équipe sécurité en R, Data Office en C. Phase 3 = Data Office en R, DBA en C.
Par criticité d'alerte. Alerte critique : escalade RSSI sous 2 heures. Warning : traitement sous 48 heures par le DBA. Informational : revue hebdomadaire.
Règle opérationnelle
Le RACI n'est pas un document qu'on range. C'est le premier livrable qui doit sortir d'une démarche de sécurisation Snowflake. Sans lui, toutes les autres briques tombent au premier turnover.Passer à l'action
Sécuriser un compte Snowflake Business Critical ne se fait pas en activant le Trust Center et en cochant les cases des scanners par défaut. Ça se fait en trois phases, avec un SIEM externe pour la corrélation, des policies SQL pour la donnée sensible, et un RACI qui nomme des gens.
Chez Bomzai, on accompagne des équipes data sur exactement ces sujets. Audit du Shared Responsibility Model sur votre compte, mise en place du plan de maturité, intégration SIEM, RACI opérationnel signé par les équipes. Avec un objectif de mise en production sous trois mois.