Data Sec : comment sécuriser les données sur le Cloud Azure ?

Lors de la mise en place d’une plateforme data, l’une des premières étapes consiste à réfléchir aux données utiles. Ces données peuvent provenir de différents systèmes externes aussi bien au sein de l’entreprise que de partenaires. En fonction du contenu, il peut s’agir de données publiques ou internes à l’entreprise. Dans le second cas, ces données peuvent être soit consultables par l’ensemble des salariés, soit uniquement accessibles à un département identifié (marketing, finance, etc.), soit être à caractère personnel (telles que des données RH ou une base clients).

Il est donc capital de préparer un environnement sécurisé avant de stocker ces données internes.

Dans cet article, nous allons voir les points à prendre en compte au niveau du cloud. En tant que partenaire Microsoft, nous parlerons du Cloud Azure, mais ces bonnes pratiques en termes de sécurité peuvent s’appliquer à n’importe quel cloud provider, si l’on fait abstraction des services spécifiques à Azure.

Evaluer la sensibilité des données

La sécurisation d’une plateforme data se fait en fonction de la sensibilité des données qui vont être stockées, manipulées et qui vont transiter au sein de cette plateforme.

L’effort n’est bien entendu pas le même en fonction du niveau de sensibilité des données.

Différents niveaux de sensibilité des données :

Toutes les données n’ont pas le même niveau de sensibilité. Une classification des données est opérée en fonction de leur niveau de sensibilité :

• Donnée personnelle: permet d’identifier une personne. Par exemple : nom, numéro de sécurité sociale, etc. ;
• Donnée sensible: information portant sur les opinions politiques, la religion, la santé, etc. d’un individu ;
• Donnée confidentielle: il s’agit de données métiers qui ne doivent pas être communiquées à l’extérieur d’une entreprise ou d’un département ;
• Données normales: concerne toutes les données ne rentrant pas dans les 3 catégories précédentes.

Il existe des outils permettant d’analyser les données. A la suite de ces analyses, une classification vous est proposée. C’est le cas, par exemple, de Azure SQL Database avec l’outil « Découverte et classification des données ».

Dans le cas de données sensibles, personnelles ou confidentielles, il est possible d’avoir recours à différentes techniques pour protéger ces données des personnes amenées à les manipuler :

• masquage dynamique de données (en remplaçant certains caractères par des “X”, par exemple) ;
• mise en place d’une sécurité au niveau des lignes permettant d’accéder uniquement aux lignes autorisées ;
• cryptage au niveau des colonnes, etc.

Nous ne détaillerons pas dans cet article ces différentes techniques mais il est important de savoir qu’elles existent.

Chiffrement des données : encryption at rest / in transit

Les attaques pour récupérer des données sont de plus en plus nombreuses. Même si tout doit être mis en place en termes de sécurité, d’un point de vue réseau, pour prévenir ces attaques (VPN, VNET, WAF, etc.), il arrive malheureusement que certaines d’entre elles aboutissent. L’idée est donc de rendre ces données inutilisables pour les attaquants : c’est le but du chiffrement (« encryption » en anglais). Il sera alors nécessaire d’avoir une clé pour déchiffrer ces données.

Le chiffrement des données est donc indispensable. La donnée peut se trouver dans deux états différents :

• au repos lorsqu’elle est stockée sur disque (at rest) ;
• en mouvement (in transit) lorsqu’elle est copiée d’un point A à un point B, par exemple.

De manière générale, les ressources Azure qui stockent ou traitent des données, gèrent le chiffrement au repos et le chiffrement en mouvement par défaut. Il faut donc simplement s’assurer que c’est bien le cas.

Pour plus d’informations, n’hésitez pas à consulter la documentation de Microsoft.

Stocker les secrets avec Azure Key Vault

Pour accéder aux données, il est nécessaire de connaître le sésame. Vous pouvez mettre en place toutes les sécurités possibles : si vos secrets (mot de passe, clé d’accès, etc.) sont stockés en clair au vu et au su de tous, il sera aisé d’accéder aux données.
C’est pourquoi il est indispensable d’utiliser le service Azure Key Vault qui permet de stocker les secrets, clés et certificats en toute sécurité. Il reste ensuite à autoriser les services dont l’accès est nécessaire.
Par exemple, Data Factory met à disposition des linked services de type Azure Key Vault :

Au sein d’un autre linked services, il est possible de faire référence au Key Vault :

Audit de l’accès aux données

Lorsqu’il est question de sécurité, il est important de pouvoir tracer les différentes activités pour l’accès à la donnée. C’est ce que permet l’audit.
Cette fonctionnalité est accessible sur la plupart des services Azure qui stockent de la donnée : Azure SQL Database, Azure Synapse, Storage Account (compte de stockage), etc.
Lorsqu’un problème se produit (comme une corruption des données ou une tentative d’intrusion), l’audit permettra de retracer l’historique de l’accès à la donnée et ainsi d’identifier l’origine de ce problème.

Exemple d’audit d’une base de données :

Stockage de données avec Azure Data Lake Gen2

Les comptes de stockage Azure mettent à disposition plusieurs services : objets blob, partage de fichiers, file d’attente, table.

Lors de la création du compte de stockage, il faut activer l’option « espace de noms hiérarchique » pour créer un Data Lake Gen2. A partir de là, il est possible de créer des conteneurs dans lesquels vous pourrez stocker les données. Nous parlerons, dans un prochain article sur l’ingestion, des trois conteneurs à créer en fonction des différents niveaux de qualité des données : bronze, argent et or.

Le service Azure Data Lake Gen2 (ADLS2) permet de stocker une quantité illimitée (en théorie) de données. Ces données peuvent être de tout type : structurées, semi-structurées ou non-structurées.

L’accès aux services Azure est régi par les RBAC (Role Based Access Control). L’accès se fait en positionnant des rôles. Ces rôles bénéficient d’un certain nombre de droits sur les ressources.
Les rôles que vous retrouverez pour l’ensemble des services sont :

• propriétaire ;
• contributeur ;
• lecteur.

Pour chaque service, il existe ensuite des RBAC spécifiques. Par exemple, pour un compte de stockage, il y a les rôles suivants : contributeur au compte de stockage, lecteur du compte de stockage, etc.
Le positionnement des RBAC est un prérequis pour pouvoir accéder au service en lui-même.

Un des atouts de ADLS2, par rapport à un compte de stockage de type blob, est de pouvoir gérer une organisation hiérarchique des données.
Il est, bien entendu, possible de contrôler l’accès aux différents niveaux de cette hiérarchie. Ceux-ci sont gérés via les ACL (Access Control List).
Il s’agit de contrôles d’accès de type POSIX tels qu’il en existe sur UNIX. Trois entités différentes coexistent : le propriétaire, les utilisateurs appartenant au groupe et les autres utilisateurs.

Pour chaque entité, les droits suivants peuvent être positionnés :

• un droit de lecture ;
• un droit d’écriture ;
• un droit d’exécution.

Le premier niveau de configuration de ces permissions se situe au niveau du conteneur. Il est possible de configurer manuellement ces permissions ou encore d’utiliser le SDK. Par exemple, en python :
[https://docs.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-directory-file-acl-python#manage-directory-permissions].

Notons qu’à l’heure de l’écriture de cet article, la fonctionnalité pour positionner les droits ACL de manière récursive est en public preview.

Nous allons voir pourquoi il peut être important de pouvoir positionner des droits de manière récursive.

Il est possible de configurer manuellement les ACL via le portail ou Azure Storage Explorer.
Nous allons voir ici la deuxième solution.

Positionner des droits d’accès avec Azure Storage Explorer

Pour positionner les droits ACL manuellement, il suffit de faire un clic droit sur le conteneur et d’accéder à la section « Gérer l’accès ».

Dans le menu ci-dessous, vous retrouverez les différentes permissions qu’il est possible d’appliquer en fonction des niveaux :

Pour chaque entité (propriétaire, groupe, etc.), il y a deux types d’autorisation :

• “Accès” : donne accès à un répertoire ou à un fichier. L’accès à un répertoire ne donne pas les droits sur le contenu dudit répertoire.
• “Par défaut” : donne accès à l’ensemble des niveaux enfants qui seront créés ultérieurement. Ainsi, tous les sous-répertoires et fichiers contenus par le répertoire avant le positionnement de ce droit ne seront pas accessibles.

Ce qu’il faut savoir, c’est que les RBAC sont prioritaires face aux ACL.
Si un utilisateur, groupe ou service principal a un rôle “contributeur du compte de stockage”, alors il aura accès à l’intégralité du data lake et ce, peu importent les ACL que vous aurez positionnés.
Il faut donc d’abord positionner les RBAC avec un rôle “lecteur du compte de stockage” afin que les ACLs soient réellement appliqués.

Il peut donc s’avérer très utile de positionner les droits de manière récursive a posteriori. De plus, il est conseillé de gérer ces droits par l’intermédiaire de groupes : l’idéal est d’utiliser des groupes pour la gestion des droits (groupes AD dans le cas d’une architecture hybride, groupes Azure AD dans le cas d’une architecture full cloud).

De manière générale, il est conseillé d’utiliser un compte de test qui vous permettra de vérifier que les droits ont été positionnés correctement.

Audit de sécurité avec Azure Security Center

Microsoft met à votre disposition un outil permettant de faire un audit de sécurité : Azure Security Center.
Après avoir analysé l’ensemble de vos services, l’outil produit un rapport avec des propositions d’actions pour renforcer la sécurité : activer l’audit, le chiffrement en transit, etc.
Les actions à réaliser sont classées en fonction de leur criticité.

La sécurité, pilier de l’architecture

La sécurité est l’un des piliers d’une bonne architecture. A l’heure de la prédominance des données, il est crucial de s’assurer que les données de votre entreprise sont en sécurité.
La tâche n’est pas forcément complexe mais elle mérite de réfléchir et d’être le plus agile possible. En effet, la sécurité mise en place au démarrage sera très certainement amenée à évoluer au fur et à mesure.

Nous verrons dans un prochain article la sécurité à mettre en place lorsqu’il est question d’utiliser Azure Databricks pour traiter les données.