Classification des données – Comment les catégoriser et où les stocker

Précédemment, nous avons discuté des exigences d’un programme mature de classification des données. Dans cet article, nous allons examiner les mécanismes administratifs d’un tel programme. La classification des données, vous vous en souvenez, inclut généralement un système à trois ou quatre niveaux semblable à celui ci-dessous :

Je recommande aux organisations novices en matière de classification des données de commencer par le système à trois niveaux, car ces niveaux et leurs actions et contrôles correspondants peuvent être difficiles à définir. Le système à trois niveaux considère toutes les données internes comme confidentielles.

La priorité est donc de créer les processus et procédures nécessaires pour soutenir les données confidentielles. Vous pouvez identifier la quantité limitée de données publiques et hautement confidentielles plus tard grâce à des entretiens et à une découverte technique. Ensuite, vous pouvez communiquer clairement vos objectifs à travers l’entreprise, y compris les emplacements, les processus et les applications.

Aujourd’hui, nous allons aborder comment les données sont normalement stockées dans les organisations et où. Ces structures vont avoir un impact énorme sur la portée, les opérations et les décisions techniques de votre programme. Comme chaque organisation a des processus métiers et des technologies différents, chaque projet de classification des données sera également différent.

Données Structurées vs. Non Structurées

Catégoriser les données structurées et non structurées est la composante de classification des données la plus facile à expliquer mais la plus difficile à gérer. Les données structurées sont toutes les données au sein d’une application, généralement une base de données. Les propriétaires d’applications de votre organisation, les administrateurs de bases de données ou le fournisseur de l’application peuvent expliquer les différents types de données stockées dans l’application.

Les organisations s’émerveillent de la quantité de données et du nombre de types de données stockées dans les applications. Les systèmes de gestion des ressources humaines, de gestion de la relation client (CRM), les plateformes de planification des ressources d’entreprise (ERP), les plateformes de comptes et les solutions de fusions et acquisitions ne sont que quelques applications qui détiennent historiquement d’énormes stocks de données structurées. Beaucoup de ces systèmes sont réglementés (par exemple, RH, ERP) et par conséquent, les données doivent être conservées pour une durée déterminée, et dans certains cas, indéfiniment.

« Les fonctions de sécurité et de gouvernance des distributions logicielles individuelles ne répondent pas toujours à toutes les exigences de contrôle d’accès granulaire et aux nouvelles exigences de gouvernance. » – Doug Henschen

Les données non structurées sont des données non stockées dans une application. Les feuilles de calcul Excel, les présentations PowerPoint et les documents Word sont des exemples classiques de données non structurées. Les données non structurées se trouvent souvent dans des rapports générés à partir de systèmes de données structurées.

Les données non structurées sont généralement dix fois plus volumineuses que les données structurées. La raison en est simple : sauvegarder des copies de fichiers importants à plusieurs endroits rassure les employés. L’email représente historiquement la plus grande quantité de données non structurées dans une organisation.

Pensez-y : les employés envoient par email un document important ou sensible pour s’assurer que tout le monde en a une copie, puis enregistrent l’email dans un fichier PST ou dans un dossier sur leur ordinateur portable. Il pourrait y avoir des centaines de copies d’un seul fichier contenant des données hautement sensibles situées dans des centaines d’emplacements à travers le réseau.

Approche Imminente des Lacs de Données et Solutions Cloud

Une tendance actuelle dans le monde des affaires est de chercher de la valeur dans toutes les données structurées que les organisations stockent. Des industries allant de l’immobilier à la gestion des déchets ont découvert une valeur cachée dans les données qu’elles collectent. Certains pourraient penser que cette tendance a commencé dans le secteur financier, mais ils se tromperaient.

L’essor des données a commencé avec l’accent mis sur l’analyse que Google et Facebook ont pionnière. Ces organisations et d’autres similaires ont réalisé qu’elles pouvaient augmenter leur rentabilité et la fidélité de leurs clients si elles ciblaient leur publicité sur des utilisateurs spécifiques.

Les adresses IP, les heures de connexion, les points de survol et d’autres données ont fourni un aperçu unique de leurs utilisateurs qu’ils pouvaient vendre à un plus grand nombre d’annonceurs. Ces informations étaient également utiles à d’autres organisations pour une multitude d’autres raisons. Vous vous souvenez de Cambridge Analytica ? Cette nouvelle valeur des données a été rendue possible par les premiers lacs de données de leur genre, bien qu’ils n’aient pas été nommés ainsi à l’époque.

« La clé est que les nouvelles choses n’ont pas les avantages que nous attendions des anciennes. » – Merv Adrian

Les lacs de données offrent aux organisations l’opportunité unique de « déverser » des données de n’importe quel nombre de sources et de formats. Ils sont généralement non gérés et ouverts à tout compte ayant accès au lac. Quel que soit le but du lac (marketing, insights commerciaux, archivage, etc.), les caractéristiques de classification des données sont les mêmes. Premièrement, il accepte toutes les données. Deuxièmement, c’est une plateforme ouverte par conception. Troisièmement, la majorité de ces solutions migrent vers ou sont construites dans le cloud.

Entrepôt de Données vs. Lac de Données

Les entrepôts de données sont plus sécurisés que les lacs. Cela s’explique par le fait que les données sont nettoyées avant d’y entrer. Voir ci-dessous :

Les entrepôts de données nettoient les données avant d’entrer dans le cloud.

Un lac de données, en revanche, accepte TOUTES les données sans l’étape de transformation et de restructuration :

Un lac de données, contrairement à un entrepôt de données, accepte TOUTES les données, sans poser de questions.

Vous ne pouvez pas vous permettre d’ignorer les problèmes de classification des données qui surgissent lorsque vous accumulez toutes ces données, surtout d’un point de vue conformité réglementaire. Vous devez être impliqué dans la conception du ou des lacs dès le départ.

Peu importe comment le lac est construit, la classification des données doit être une considération dans sa conception. Par exemple, un lac est conçu à des fins d’archivage. Les données hautement confidentielles doivent-elles être incluses ? Les données hautement confidentielles doivent-elles avoir leur propre lac, ou doivent-elles être complètement exclues ?

Appliquer la classification soit au début de l’injection de données, soit à la fin lorsqu’elles sont exportées des magasins de données de processus, est votre meilleure stratégie.

Savoir quels systèmes fournissent des données au lac est important. Lorsque les données sont mises dans un lac, il y a moins de protections disponibles pour les groupes de gouvernance (Cyber, Risque, Conformité, etc.) par rapport aux bases de données d’entreprise ou aux systèmes de bases de données relationnelles.

Avec les systèmes de gestion de bases de données traditionnels, l’équipe de sécurité de l’information pourrait gérer toute la sécurité du réseau et les protections de contrôle d’accès mais faire peu avec les données une fois qu’elles entrent dans le système de gestion de bases de données.

Les structures de lacs de données, cependant, ne viennent pas avec toutes les capacités de gouvernance et les politiques associées à un système de gestion de bases de données traditionnel, de l’intégrité référentielle de base à l’accès basé sur les rôles et la séparation des tâches.

Une façon d’aborder la sécurité des lacs de données est de la considérer comme un pipeline avec des composants en amont, au milieu et en aval, selon Merv Adrian. Les vecteurs de menace associés à chaque étape sont quelque peu différents et doivent donc être abordés différemment.

Les lacs de données apportent une grande valeur à l’organisation mais nécessitent un modèle de gouvernance différent pour maintenir les contrôles de classification.

À Venir

Dans mon prochain article, je vais rassembler tous les éléments que nous avons précédemment discutés avec la Matrice de Contrôles de Gestion des Données.

Ressources Supplémentaires

• Rapport Évaluez la Confidentialité et la Conformité de Vos Communications de Contenu Sensible
• Article de Blog Qu’est-ce qu’un Réseau de Contenu Privé ?
• Article de Blog Kiteworks Utilise Son Propre Réseau de Contenu Privé
• Article de BlogSouveraineté des Données
• Article de BlogUn Système de Gestion de Contenu d’Entreprise