Sécurité des données : risques, contrôles et fondements de la gouvernance

Le patrimoine de données a évolué plus vite que la plupart des programmes de sécurité. Les données transitent désormais par des pipelines, des partages avec des partenaires, des agents d’IA et des applications en aval, et ces mouvements créent souvent des points de contrôle que les modèles de sécurité traditionnels n’ont pas été conçus pour gérer à grande échelle. Le chiffrement, le contrôle d’accès et la supervision restent essentiels, mais la sécurité des données dépend désormais de la gouvernance : savoir quelles données existent, à qui elles appartiennent, quel est leur niveau de sensibilité et quelles règles s’y appliquent.

La sécurité et la gouvernance des données sont des disciplines distinctes. Cependant, lorsqu’elles fonctionnent séparément, les politiques sont difficiles à appliquer à mesure que les informations circulent entre les systèmes, les équipes et les environnements. Ce guide explique ce que signifie aujourd’hui la sécurité des données, pourquoi les enjeux ont augmenté, quels sont les principaux risques et réglementations qui façonnent les programmes d’entreprise, et quels contrôles les organisations utilisent pour protéger les données tout au long de leur cycle de vie.

La sécurité des données est l’ensemble des pratiques, contrôles et technologies qui protègent les données numériques contre l’accès non autorisé, la corruption, le vol ou la perte tout au long de leur cycle de vie. Elle doit prendre en compte les données au repos, en transit et en cours d’utilisation, ainsi que les identités, les politiques et les systèmes qui interagissent avec ces données à chaque étape. Les points de contrôle diffèrent selon l’endroit où se trouvent les données et la façon dont elles se déplacent, ce qui rend cette discipline complexe dans la pratique.

Le framework de base est la triade CIA : confidentialité, intégrité et disponibilité. La confidentialité signifie que seuls les utilisateurs, services et charges de travail autorisés peuvent accéder aux données sensibles. L’intégrité signifie que les données restent exactes, complètes et fiables lorsqu’elles sont créées, transformées, interrogées, partagées ou utilisées dans des applications en aval. La disponibilité signifie que les données restent accessibles aux utilisateurs autorisés lorsque l’entreprise en a besoin, y compris en cas de pannes, de perturbations ou d’attaques.

La sécurité des données est liée à la confidentialité des données et à la gouvernance des données, mais s’en distingue. La confidentialité des données définit la manière dont les données personnelles doivent être collectées, utilisées, conservées et divulguées, généralement en réponse à des réglementations telles que le RGPD ou le CCPA. La gouvernance des données définit à qui appartiennent les données, comment elles sont classées, quelles règles s’appliquent et qui ou quoi est autorisé à les utiliser. La sécurité des données applique ces règles par le biais de contrôles d’accès, du chiffrement, du masquage, de la supervision, de politiques de conservation et de la réponse aux incidents.

Les données sensibles ne se limitent plus à un petit nombre de systèmes contrôlés. Elles transitent par des applications SaaS, des data lakes, des data warehouses, des environnements partenaires, des workflows de collaboration et des pipelines d’IA. Une seule colonne contenant des numéros de compte, des informations de santé protégées ou des données financières peut être copiée, transformée, intégrée, partagée ou récupérée à de multiples endroits. La sécurité doit donc suivre les données, plutôt que de supposer que la frontière du réseau tiendra bon.

La pression réglementaire reflète l’évolution du patrimoine de données. Le RGPD, le CCPA, l’HIPAA, la norme PCI DSS et la loi SOX continuent de dicter la manière dont les entreprises protègent les données personnelles, de paiement, de santé et financières. Le règlement DORA est entré en application le 17 janvier 2025 pour les entités financières de l’UE, tandis que les États membres devaient transposer la directive NIS2 dans leur droit national au plus tard le 17 octobre 2024. En Inde, le Digital Personal Data Protection Act de 2023 a établi le cadre relatif aux données personnelles numériques, et les Digital Personal Data Protection Rules de 2025 ont défini les phases des calendriers de mise en œuvre.

La conformité n’est toutefois que le point de départ. Une entreprise peut satisfaire à une exigence d'audit limitée tout en conservant des rôles aux autorisations excessives, des copies obsolètes de données sensibles, des partages partenaires non surveillés ou des charges de travail d'IA qui récupèrent plus de contexte que ce que l'utilisateur devrait voir.

Une sécurité des données efficace nécessite une défense en profondeur : le chiffrement pour protéger les données au repos et en transit, le contrôle d’accès pour restreindre qui peut les utiliser, le masquage et les politiques au niveau des lignes pour limiter l’exposition dans les requêtes, la prévention des pertes de données pour réduire les mouvements inappropriés, la gestion de la posture pour faire remonter les risques, et la supervision continue pour détecter les comportements inhabituels.

L’IA a rendu la sécurité des données encore plus urgente. Les données d'entraînement, les embeddings vectoriels, les systèmes de génération augmentée de récupération (RAG), le contexte accessible par les agents et les sorties des modèles créent des chemins de fuite qui n'existaient pas sous cette forme il y a cinq ans. En matière de contrôle d'accès, la question n'est plus seulement « Ce collaborateur peut-il interroger la table ? », mais aussi « Cet agent peut-il récupérer la ligne, utiliser l'embedding, appeler l'outil et produire une sortie qui expose des données sensibles ? »

De nombreuses entreprises accusent un retard en matière de sécurité de l’IA. Selon l’Enterprise Data Security Confidence Index 2025 de Bedrock Data, 79 % des équipes de sécurité peinent à classifier les données sensibles utilisées dans les systèmes d’IA et de machine learning, et moins de la moitié d’entre elles se disent très confiantes dans leur capacité à contrôler les données sensibles utilisées pour l’entraînement de l’IA.

Regardez cette vidéo pour découvrir comment mettre en œuvre les bonnes pratiques de sécurité avec Trust Center dans Snowflake Horizon :

Le contrôle d’accès est le mécanisme fondamental de la sécurité des données : il s’agit des règles et de leur application qui déterminent qui peut lire, écrire, modifier ou partager des données spécifiques. La gestion des accès définit le cycle de vie opérationnel (comment les accès sont demandés, approuvés, provisionnés, révisés et révoqués), tandis que le contrôle d’accès applique ces décisions par le biais de rôles, d’attributs, de privilèges, de politiques et de pistes d’audit.

La plupart des programmes d’entreprise combinent le contrôle d’accès basé sur les rôles (RBAC), le contrôle d’accès basé sur les attributs (ABAC) et des politiques granulaires. Le RBAC accorde des privilèges par le biais de rôles liés à des fonctions ou des responsabilités professionnelles. L'ABAC évalue des attributs tels que le département, la région, le niveau d'habilitation, la sensibilité des données ou le type de charge de travail. Les règles au niveau des lignes et des colonnes affinent ensuite l'accès à l'intérieur d'une table, de sorte que les utilisateurs peuvent travailler à partir de données partagées sans recevoir la même vue de chaque enregistrement.

Le contrôle d’accès basé sur les rôles est le modèle de contrôle d’accès le plus largement déployé, car il associe les autorisations au mode de fonctionnement actuel des entreprises. Au lieu d’accorder des privilèges directement à chaque utilisateur, les administrateurs accordent des privilèges à des rôles, affectent des utilisateurs à ces rôles et utilisent une hiérarchie de rôles pour hériter des autorisations le cas échéant.

Le principe du moindre privilège doit façonner le modèle de rôles dès le départ. Les rôles doivent accorder l'accès minimal requis pour qu'une personne, un compte de service ou une charge de travail puisse exercer ses fonctions, les privilèges élevés devant être séparés, examinés et limités dans le temps dans la mesure du possible. À mesure que les environnements se développent, les équipes doivent surveiller la prolifération des rôles, les autorisations héritées et les accès basés sur des exceptions.

Le chiffrement des données transforme des données lisibles en texte chiffré que seules les parties autorisées peuvent déchiffrer. Il protège les données au repos dans le stockage, les données en transit sur les réseaux et, selon l’architecture, les données en cours d’utilisation pendant le traitement. Le chiffrement réduit l’exposition en cas d’accès inapproprié au stockage, d’interception du trafic ou de sortie d’une sauvegarde de son environnement prévu.

Le chiffrement au repos protège les données stockées telles que les tables, les fichiers, les snapshots et les sauvegardes. Le chiffrement en transit protège les données lors de leurs déplacements entre les clients, les services, les applications et les composants de la plateforme, généralement via TLS. Le chiffrement en cours d'utilisation est la catégorie la plus difficile, car les données doivent souvent être traitées sous forme lisible. Les plateformes modernes réduisent toutefois de plus en plus l'exposition grâce à des environnements d'exécution sécurisés, à l'application de politiques et à des chemins de traitement soigneusement contrôlés.

Les entreprises doivent disposer d’un modèle opérationnel pour la gestion des clés afin de déterminer qui contrôle les clés, comment elles sont alternées, comment l’accès aux clés est journalisé et si les exigences réglementaires ou internes imposent l’utilisation de clés gérées par le client. Pour les entreprises soumises à des exigences de contrôle strictes, les clés gérées par le client offrent une séparation supplémentaire entre l’opérateur de la plateforme et le modèle de contrôle cryptographique de l’entreprise.

Les principaux mécanismes de chiffrement protègent la couche de données, tandis que la gouvernance détermine quels utilisateurs, charges de travail et politiques peuvent entraîner l’utilisation de données déchiffrées.

Le masquage des données masque les valeurs sensibles aux utilisateurs qui ne devraient pas les voir, tout en préservant une structure suffisante pour l’analyse, les tests ou les opérations. Par exemple, un analyste du support peut avoir besoin de savoir qu’un dossier client existe sans voir l’intégralité du numéro de sécurité sociale, du numéro de carte de crédit ou du code de diagnostic. Un data scientist peut avoir besoin de modèles géographiques ou démographiques sans identifiants directs.

Le masquage statique crée une copie expurgée des données, souvent pour des environnements inférieurs tels que le développement, les tests ou l’entraînement. Le Dynamic Data Masking applique une politique au moment de la requête. Ainsi, la même colonne peut renvoyer des valeurs différentes en fonction du rôle, des attributs ou du contexte de l’utilisateur. La tokenisation est un concept similaire : les valeurs sensibles sont remplacées par des jetons non sensibles qui ne peuvent être inversés que dans des conditions contrôlées. Le chiffrement avec préservation du format peut également protéger les valeurs sensibles tout en conservant la structure attendue par les applications.

Un masquage efficace dépend d’une classification des données précise. Une politique ne peut pas protéger la colonne email_address ou un fichier non structuré contenant des données de paie si l’organisation n’est pas capable d’identifier les données sensibles au préalable. La classification, l’ajout de tags et le masquage fonctionnent de manière optimale sous forme de boucle : découvrir les données sensibles, appliquer un tag, associer la politique appropriée et surveiller si de nouveaux actifs nécessitent le même traitement.

La sécurité au niveau des lignes restreint les lignes qu’un utilisateur peut voir dans une table en fonction de son identité, de son rôle, de ses attributs ou de sa relation avec les données. Elle est particulièrement utile lorsque plusieurs équipes, régions, unités commerciales ou locataires doivent travailler à partir de la même table sans recevoir les mêmes enregistrements.

Une application analytique multi-locataire en est l’exemple classique : l’application peut servir des centaines de clients à partir d’une table partagée, mais chaque client ne doit voir que ses propres lignes. Sans sécurité au niveau des lignes, les équipes créent souvent des vues dupliquées, des extraits ou des filtres spécifiques à l’application qui sont difficiles à auditer et simples à mal configurer.

La sécurité au niveau des lignes est plus pérenne lorsqu’elle est déclarative et associée à l’objet de données plutôt qu’enfouie dans la logique de l’application. Si la politique se situe au niveau de la table, elle s’applique de manière cohérente à l’ensemble des requêtes et des cas d’usage en aval, réduisant ainsi le risque qu’un nouveau tableau de bord, notebook, agent ou application ne contourne le filtre prévu.

La prévention des pertes de données (DLP) est la discipline qui consiste à détecter et à empêcher que les données sensibles ne soient exfiltrées, divulguées ou partagées de manière inappropriée. La cause peut être malveillante, comme le vol d’identifiants et l’exfiltration de données, ou négligente, comme un analyste exportant plus de données que nécessaire, un pipeline écrivant des données sensibles dans un emplacement non géré, ou un partage avec un partenaire qui reste actif après l’évolution d’une relation commerciale.

La DLP moderne combine la classification, l’application des politiques, la supervision et la réponse. La classification identifie les données sensibles. Les étiquettes ou tags de sensibilité donnent du sens à ces données. Les politiques déterminent si les données peuvent être interrogées, copiées, exportées, partagées ou utilisées par une charge de travail. La supervision recherche ensuite les modèles d’accès, l’activité de sortie ou les exceptions aux politiques qui nécessitent une investigation.

La DLP traditionnelle fonctionnait souvent comme un dispositif de contrôle du réseau ou des terminaux, ce qui était logique lorsque les fichiers sensibles transitaient par e-mail, par les terminaux et par des canaux de réseau gérés. Dans un environnement de données moderne, les données sensibles transitent par des pipelines, des partages, des API, des notebooks, des applications et des systèmes d’intelligence artificielle. La DLP doit devenir plus centrée sur les données : les politiques doivent suivre l’objet de données, et pas seulement le chemin réseau.

La gestion de la posture de sécurité des données (DSPM) correspond à la découverte, la classification et l'évaluation continues des risques liés aux données sensibles dans l'ensemble des environnements d'une organisation. Elle répond à trois questions pratiques : Où se trouvent les données sensibles ? Qui ou quoi peut y accéder ? Quel risque existe-t-il en raison de cet accès, de ce lieu ou de l’état de la politique ?

La DSPM a émergé car de nombreux outils de sécurité ont été conçus autour de l’infrastructure, et non des données. Un outil de gestion de la posture de sécurité sur le cloud (CSPM) peut identifier un bucket exposé, un port ouvert ou une politique de gestion des identités et des accès faible, mais il n’indique pas nécessairement à une équipe de sécurité si la ressource exposée contient des dossiers clients, du code source, des données de santé, des données de paiement ou des journaux opérationnels à haut risque. La DSPM se concentre sur les données elles-mêmes : la sensibilité, le lieu, les chemins d’accès, la couverture des politiques, les modèles d’utilisation et les risques.

La DSPM native à la plateforme réduit certaines des lacunes qui surviennent lorsqu'un outil tiers doit explorer chaque magasin de données de manière indépendante. Étant donné que la plateforme sait déjà quels objets existent, quels utilisateurs et rôles peuvent y accéder, quels tags et politiques s’appliquent, et comment les données sont interrogées ou partagées, la découverte et la notation des risques reposent sur des bases plus continues que de simples analyses périodiques.

Les risques liés à la sécurité des données se divisent en trois grandes catégories : les menaces externes, les menaces internes et les risques spécifiques à l’intelligence artificielle.

• Les menaces externes incluent les ransomwares, le phishing, le vol d’identifiants, la compromission de la chaîne d’approvisionnement et les attaques qui utilisent des identités volées ou usurpées pour atteindre les systèmes de données. Celles-ci restent actives car les attaquants n’ont pas besoin d’exploits directs de la base de données s’ils peuvent obtenir des identifiants, compromettre un compte de service ou se déplacer latéralement à partir d’un système connecté.
• Les menaces internes comprennent les initiés malveillants, les utilisateurs négligents, l'informatique fantôme, les erreurs de configuration et les comptes aux privilèges excessifs. Un utilisateur disposant d'un accès étendu peut exécuter une requête sur des données sensibles, les exporter, les partager ou les acheminer vers un processus non géré sans déclencher les mêmes alarmes qu'un attaquant externe. C'est pourquoi le moindre privilège, la séparation des tâches, les examens d'accès et la supervision sont des dispositifs de contrôle de la sécurité des données, et pas seulement des tâches d'administration des identités.
• Les risques spécifiques à l’intelligence artificielle ajoutent une couche plus récente. L’injection de prompt peut amener un système de génération augmentée par la recherche à accéder à un contexte sensible ou à le résumer d’une manière que l’utilisateur n’avait pas prévue. La fuite de données d’entraînement peut révéler des enregistrements sensibles par le biais du comportement ou des résultats du modèle. Le dépassement de prérogatives des agents peut se produire lorsque des agents autonomes reçoivent un accès aux outils ou aux données plus large que celui dont l'utilisateur devrait disposer. L'exfiltration des sorties du modèle peut se produire lorsque des sorties sensibles quittent l'environnement gouverné par le biais d'appels d'outils, de plugins ou d'applications connectées.

Les réglementations affectant la sécurité des données définissent les obligations auxquelles les contrôles de sécurité doivent satisfaire. Une réglementation peut spécifier des mesures de protection, des règles de notification des violations, des attentes en matière d’audit, des limites de conservation ou des droits liés aux données personnelles, et les organisations soumises à cette loi doivent traduire ces exigences en contrôles opérationnels sur l’ensemble de leur patrimoine de données.

• Le Règlement général sur la protection des données (RGPD) est le cadre réglementaire de l'UE fondé sur les droits en matière de données personnelles. Il exige une base légale pour le traitement, accorde aux individus des droits sur leurs données personnelles et crée des obligations en matière de protection, de responsabilité et de notification des violations.
• Le California Consumer Privacy Act (CCPA) s’applique aux informations personnelles des consommateurs de Californie. Il définit les droits de confidentialité des consommateurs et, dans certains scénarios de violation, inclut un droit d’action privée.
• La loi Health Insurance Portability and Accountability Act (HIPAA) régit les informations de santé protégées dans le système de santé américain. Elle exige des garanties administratives, physiques et techniques pour les entités couvertes et les partenaires commerciaux.
• PCI DSS définit les exigences techniques et opérationnelles pour la protection des environnements de données des titulaires de cartes. Le PCI Security Standards Council décrit ses normes comme un cadre de spécifications, d'outils, de mesures et de ressources de support pour le traitement sécurisé des informations des titulaires de cartes.
• SOX se concentre sur les contrôles liés à la création de rapports financiers. Pour les équipes de sécurité des données, la préoccupation pratique est l’intégrité, le contrôle d’accès et l’auditabilité des données financières utilisées dans les processus de création de rapports.
• DORA s’applique aux entités financières de l’UE et se concentre sur la résilience opérationnelle numérique, y compris la capacité à résister, à répondre et à se remettre des perturbations des technologies de l’information et de la communication. Elle est entrée en application le 17 janvier 2025.
• NIS2 élargit les obligations en matière de cybersécurité et de signalement des incidents pour les secteurs stratégiques à travers l’UE.
• Le DPDP Act indien régit les données personnelles numériques en Inde. La loi décrit sa finalité comme la fourniture d’un cadre pour le traitement des données personnelles numériques d’une manière qui reconnaît à la fois le droit des individus à protéger leurs données personnelles et la nécessité de les traiter à des fins légales.

Le problème opérationnel courant n’est pas simplement de savoir quelles règles s’appliquent, mais de prouver que les contrôles d’accès, de masquage, de conservation, de supervision et de réponse aux incidents sont appliqués de manière cohérente sur l’ensemble des systèmes où résident les données réglementées. La gouvernance des données contribue à soutenir la conformité réglementaire en reliant les obligations réglementaires aux actifs de données qu’elles couvrent, afin que les équipes sachent ce qui est protégé, quelle politique s’applique et où se situent les lacunes.

Les programmes de sécurité des données varient selon le secteur d’activité, l’architecture et le profil de risque. Les pratiques ci-dessous couvrent les domaines fondamentaux que la plupart des programmes d’entreprise doivent maîtriser. Elles ne sont pas exhaustives, mais elles reflètent les plus importantes pour les patrimoines de données qui deviennent de plus en plus distribués et qui implémentent des charges de travail d’IA.

Classifier et inventorier les données sensibles

Commencez par les objets qui nécessitent une protection : tables, vues, fichiers, zones de préparation (stages), jeux de données, embeddings, partages, applications et contexte accessible par l’IA. La classification permet d’identifier si ces objets contiennent des informations personnelles (PII), des informations de santé protégées, des données de titulaires de cartes, des identifiants, de la propriété intellectuelle ou d’autres données sensibles. Le travail d’inventaire relie ensuite cette classification aux propriétaires, à la traçabilité des données, aux règles de conservation, aux chemins d’accès et à l’utilisation en aval.

Appliquer l’accès au moindre privilège pour les utilisateurs, les services et les charges de travail

Chaque utilisateur, compte de service, application et charge de travail d'IA ne doit recevoir que l'accès dont il a besoin pour effectuer une tâche définie. L'accès doit avoir un cycle de vie : un nouvel utilisateur reçoit un accès via un processus approuvé, l'accès élevé expire à la fin de la tâche, les utilisateurs inactifs sont supprimés et les comptes de service sont examinés lorsque les pipelines ou les applications changent. Les principes du Zero Trust renforcent ce modèle en traitant chaque demande comme un élément à vérifier en fonction de l’identité, du contexte, de l’appareil, de la charge de travail et de la sensibilité.

Protéger les données sensibles avec des contrôles basés sur des politiques

Le Dynamic Data Masking peut masquer les valeurs sensibles des colonnes au moment de la requête. Les politiques d'accès aux lignes peuvent restreindre les enregistrements par région, locataire, compte ou rôle. La tokenisation peut préserver la structure utile tout en réduisant l’exposition de la valeur d’origine. Ces dispositifs de contrôle sont particulièrement importants lorsque plusieurs équipes utilisent les mêmes données gouvernées. Plutôt que de créer de nombreuses copies d’une table client pour chaque région ou fonction, les équipes appliquent des politiques à l’objet partagé et laissent la plateforme appliquer la vue appropriée.

Sécuriser le déplacement des données, le partage et la collaboration

Chaque fois que des données se déplacent, que ce soit via un pipeline, un partage avec un partenaire, une exportation ou un modèle, cela crée un point de contrôle. La destination est-elle approuvée ? Les données sont-elles toujours classifiées ? La même politique de masquage ou d’accès aux lignes s’applique-t-elle ? Le partage est-il toujours nécessaire ? La collaboration sécurisée fonctionne mieux lorsque les équipes peuvent partager des données gouvernées sans créer d’extraits non gérés.

Superviser l’accès et enquêter sur les activités inhabituelles

L'historique des requêtes, l'historique des accès, l'historique des connexions, les modifications d'objets, les tentatives d'accès échouées et les modifications de politiques aident les équipes de sécurité à détecter les abus, à investiguer les incidents et à prouver l'efficacité des dispositifs de contrôle. La supervision doit combiner le contexte de la politique, le contexte de l’identité et la sensibilité des données : une seule requête sur une table protégée peut être normale pour un rôle et suspecte pour un autre.

Gouverner les données tout au long de leur cycle de vie

Les tables temporaires, les copies de développement, les données de test, les caractéristiques dérivées, les données d'entraînement des modèles, les index vectoriels, les rapports et les données archivées peuvent tous contenir des informations sensibles. Les dispositifs de contrôle du cycle de vie doivent définir la conservation, la suppression, l'archivage, la sauvegarde, la récupération, l'utilisation en développement/test et l'utilisation approuvée de l'IA. Les données de production sensibles ne doivent pas être copiées dans des environnements inférieurs sans contrôles de masquage ou de données synthétiques.

Se préparer à la réponse aux incidents et à la récupération

Les plans de réponse aux incidents doivent définir qui enquête sur les accès suspects, qui peut révoquer les privilèges, qui communique avec les équipes juridiques ou de conformité et comment les preuves sont préservées. Les sauvegardes, la réplication, le basculement, les points de récupération protégés et les tests de restauration font partie de la conversation sur la sécurité des données, car la disponibilité est un élément de la triade de la sécurité de l’information (CIA).

Auditer les contrôles et gérer les exceptions

Les examens d'accès, les exceptions aux politiques, la couverture du masquage, le statut de classification, les enregistrements d'incidents, la rotation des clés, l'application des règles de conservation et les résultats de supervision doivent produire des artefacts que les auditeurs et les équipes de gestion des risques internes peuvent examiner. Les exceptions doivent être explicites, approuvées et limitées dans le temps : une exception permanente est généralement un manquement aux politiques déguisé.

Snowflake réunit la sécurité des données et la gouvernance des données au sein du même plan de contrôle de la plateforme, de sorte que les organisations peuvent définir des politiques, classifier des données, gérer les accès, superviser l'activité et gouverner les charges de travail d'IA sans avoir à maintenir des modèles d'application distincts pour chaque cas d'usage.

Snowflake Horizon Catalog est au cœur de ce modèle. Il fournit des capacités de gouvernance, de découverte et de catalogue pour la plateforme de données, aidant les équipes à gérer les données, les applications et les ressources d'IA avec un contexte partagé, notamment la classification, les politiques de masquage, les politiques d'accès aux lignes, la traçabilité et la supervision de la qualité des données.

Le RBAC, le masquage, les politiques d'accès aux lignes, le balisage et les politiques de protection des données reposent sur le même modèle de données gouverné, ce qui réduit la double saisie entre les équipes de gouvernance et de sécurité. Les politiques de protection des données Snowflake permettent aux équipes de définir des autorisations granulaires une seule fois et de les appliquer de manière cohérente au moment de la requête, sans avoir à créer des rôles ou des vues supplémentaires au fur et à mesure que les données et les équipes se développent.

Le Snowflake Compliance Center offre aux équipes un moyen de superviser la posture de sécurité des comptes Snowflake, de faire remonter les résultats de l'analyseur et d'évaluer la préparation en matière de sécurité des données et d'authentification depuis Snowflake, notamment les résultats de détection axés sur les activités potentiellement suspectes.

Enfin, les charges de travail d'IA s'appuient sur des données gouvernées, mais introduisent de nouveaux modèles d'accès via les agents, les outils, les systèmes de récupération et les sorties des modèles. Horizon sert de catalogue d’IA universel qui unifie le contexte et la gouvernance sur l’ensemble des données et des ressources d’IA, tandis que le partenariat de Snowflake avec Bedrock Data offre une visibilité sur les agents d’IA et les données auxquelles ils peuvent accéder.

Les contrôles de sécurité des données ne sont efficaces que si les fondations sur lesquelles ils reposent le sont. Les politiques d’accès, les règles de masquage, les restrictions au niveau des lignes et la supervision nécessitent tous les mêmes éléments pour fonctionner de manière fiable : une image précise de l’endroit où se trouvent les données sensibles, de la manière dont elles sont classifiées et de qui en est responsable. Sans ce socle, les équipes prennent des décisions raisonnables sur la base d'informations incomplètes, et les lacunes ont tendance à se manifester au pire moment, lors d'une investigation d'incident ou d'un audit de conformité.

La gouvernance fournit cette fondation, aidant les équipes à déterminer où et comment les contrôles de sécurité des données sont appliqués. C’est pourquoi les programmes de sécurité des données les plus solides considèrent la classification, la propriété et les politiques non pas comme des livrables de gouvernance, mais comme des prérequis de sécurité.