Étanchéité des données dans un écosytème Hadoop

Étanchéité des données dans un écosystème Hadoop

Quelles sont les possibilités offertes par Hadoop pour partager un cluster entre plusieurs utilisateurs, tous en garantissant la séparation des données ?

Hadoop a atteint une bonne maturité et s’attache depuis plusieurs versions à ajouter de plus en plus d’options d’industrialisation, et notamment d’amélioration de la sécurité des données. Ces options peuvent être particulièrement utiles dans le cas d’un environnement mutualisé, mais elles permettent aussi d’assurer la protection des informations dans un environnement de production non partagée avec d’autres entités. Nous allons voir comment restreindre l’accès aux données uniquement aux services autorisés, mais également comment empêcher un service tiers d’accéder aux données d’un autre client.

L’utilisation de Kerberos

Depuis les premières versions d’Hadoop, il est possible de sécuriser les communications entre chaque service d’un cluster via Kerberos. Kerberos est un protocole d’authentification développé par le MIT utilisant un système d’utilisateurs et de clés pour protéger les échanges entre chaque service. Tous service ou application qui souhaite récupérer des données doit d’abord s’authentifier auprès de Kerberos pour pouvoir communiquer avec le cluster. Pour séparer l’accès aux données, les droits sont gérés par les permissions du système de fichier. Un utilisateur Kerberos peut en effet être relié à un utilisateur Hadoop. Ce lien peut être configuré via un fichier de mapping ou, s’il n’est pas configuré, correspondra à équivalence stricte entre les deux utilisateurs (Kerberos et système de fichiers). Par exemple, l’utilisateur test/MY_DOMAIN@HADOOP_SECURE correspondra à l’utilisateur «test» sur le cluster hadoop (s’il existe). Dans le cas d’un environnement mutualisé, chaque service dédié à un client utilisera alors un identifiant et une clé propre à ce client.

La création de plusieurs namespaces

Kerberos constitue un premier niveau de sécurité, mais il est possible d’aller plus loin.

Un cluster Hadoop est composé d’un ensemble de datanodes et de namenodes. Les datanodes s’occupent de stocker les données en elles-mêmes, tandis que le namenode s’occupe de l’accès à ces données. Chaque namenode s’occupe d’un namespace, c’est à dire d’un ensemble de dossiers. Traditionnellement, un cluster Hadoop ne possède qu’un namenode qui s’occupe alors de gérer l’ensemble des fichiers du cluster. Depuis la version 2.7 d’Hadoop, il est possible d’utiliser une fédération Hadoop. Dans une fédération, plusieurs namenodes sont utilisés pour gérer un cluster Hadoop. Chaque namenode s’occupe alors d’un namespace différent. Ce namespace peut être un seul dossier (et ses sous-dossiers) ou un ensemble de dossiers. Dans cette configuration, on peut alors attribuer un namenode à un utilisateur et à ses données. Les utilisateurs ne pourront alors accéder qu’à leur namenode respectif, et même si les données sont stockées sur les mêmes datanodes, ils ne pourront pas accéder aux données des autres utilisateurs. 

Le chiffrement Hadoop

Il est enfin possible depuis les versions les plus récentes d’Hadoop d’ajouter un niveau de sécurité supplémentaire en activant le chiffrement des données sur le cluster. Intitulée « Transparent Encryption », elle permet de définir des zones chiffrées, chaque zone chiffrée possédant sa propre clé de chiffrement. Lorsqu’un client souhaite écrire un nouveau fichier dans une zone chiffrée, le namenode demande au KMS (Key Management Server) de créer une nouvelle clé de chiffrement à partir de la clé de chiffrement de la zone. Les clés de chiffrements sont gérées par le service KMS d’Hadoop . Il s’agit ici d’un chiffrement de bout en bout, il n’y a donc que le client qui puisse lire les données en demandant la clé de déchiffrement au KMS, qui se chargera de vérifier que le client a le droit de lire les données. Cela apporte un avantage certains car les données stockées et transférées via le réseau restent chiffrées. Comme vous pouvez le constater, le processus de chiffrement ajoute une certaine lourdeur aux processus de lecture/écriture. Le chiffrement peut impacter fortement l’utilisation processeur et le temps de réponse des applications s’appuyant sur ces données, cela reste donc une option à étudier attentivement avant de l’activer.

Comme nous avons pu le voir, plusieurs options existent pour garantir l’étanchéité des données. Malgré la nécessité de déployer quelques efforts pour la mise en œuvre, Kerberos reste le premier pas indispensable dans ce sens. La création de plusieurs namespaces est en plus, mais nécessitera un effort de déploiement important et doit donc être pesé avant sa mise en œuvre. Le chiffrement, quant à lui, peut être consommateur et doit rester une option à étudier en dernier lieu.