Après la plateforme de batch scalable, le Data Lake, cette notion selon laquelle toutes les données de l'entreprise devraient être déversées et stockées sans discernement dans un entrepôt commun — de préférence un cluster Hadoop — est devenu au cours de l'année, un nouvel élément central de la communication des éditeurs autour d'Hadoop.

Stocker de grands volumes de données dans un même cluster implique selon les industries, de faire cohabiter des données normales avec des données sensibles (données personnelles, données privées d'un client à qui on revend son service en marque blanche, …).

Par ailleurs le fait qu'un datalake ne soit pas qu'un simple stockage sur HDFS mais un ensemble de solutions de stockage co-localisées (Fichiers, SQL, NoSQL, Recherche) ne simplifie pas la problématique.

Du coup,  cette communication sur le Data Lake s'accompagne de plus en plus d'une communication axée sur la sécurisation d'Hadoop.

Mais où en est vraiment la sécurisation d'Hadoop ? Quelles options pour efficacement sécuriser un Data Lake ?

De quoi est constitué le cluster Hadoop de 2014 ?

En terme de technologies impliquant du stockage de données, le cluster 2014 couvre quatre domaines assez différents :

• Les données brutes : HDFS
• Les bases NoSQL : HBase
• Les bases SQL : principalement Hive
• Les index de moteur de recherche : Solr

Chacun vient avec sa ou ses technologies, parfois avec des recouvrements mais surtout, avec des capacités de sécurisation différentes. Dans la suite de cet article, nous nous limiterons aux technologies citées ci dessus, étant celles que nous estimons les plus utilisées et donc pertinentes dans le cadre d'un data lake, aujourd'hui.

Kerberos, socle commun de toute sécurisation d'un cluster

Ce fait commence à être bien connu. Le socle nécessaire à toute sécurisation d'un cluster Hadoop est Kerberos.

En effet, Kerberos fournit une authentification forte de manière transverse pour les applications d'un cluster.

Le corollaire étant que toute communication entre plusieurs clusters Hadoop est la mise en place de ce que l'on appelle des trusts entre domaines Kerberos.

Dans une perspective de production, cela signifie qu'il est pertinent et nécessaire d'impliquer très tôt l'expertise sécurité, dès le cadrage de l'architecture d'une plateforme Hadoop.

Kerberos peut être géré au choix au moyen d'un couple LDAP / KDC MIT dont FreeIPA fournit un ensemble pratique à utiliser ou Active Directory.

Dans les deux cas, les utilisateurs ainsi que les groupes gérés par la partie LDAP seront ceux disponibles sur le cluster, que ce soit pour les permissions de HDFS, de HBase, …

Par ailleurs, l'intégration d'un domaine Active Directory (si vous utilisez déjà AD en interne) est par ailleurs, une excellente manière d'intégrer rapidement la gestion des identités du ou des clusters dans les process traditionnels. En revanche bien que le provisionnement de comptes et de groupes Unix puissent être standards, il faudra prévoir du code spécifique pour étendre ce provisionnement aux espaces et quotas sur le cluster Hadoop (HDFS, Hive, …).

Les données brutes, un domaine mature

Les données brutes sont généralement stockées sur HDFS. Les fichiers arrivant sur la plateforme étant simplement déversés dans un répertoire.

Le contrôle d'accès sur HDFS s'effectue au moyen d'ACLs étendues, conformes à la spécification POSIX. Cela n'offre pas la flexibilité des ACLs Windows mais cette relative simplicité permet d'un autre côté une mise en oeuvre assez rapide et sans douleurs par rapport au précédent mode de fonctionnement POSIX standard (UGO, Utilisateur, Groupe, Other).

Ainsi il est possible de définir un propriétaire et des permissions restreintes par défaut puis de gérer une liste de permissions POSIX standard par répertoire en fonction des besoins.

Lesquels groupes et utilisateurs provenant comme expliqué plus haut, du LDAP et étant donc gérés en central.

Les bases NoSQL, des ACLs présentes depuis longtemps

En ce qui concerne le NoSQL, HBase est le choix d'une stack Hadoop.

Ce dernier supporte des ACLs étendues par namespace (l'équivalent d'une base de données dans le monde SQL). De plus, elles ne suivent pas le modèle POSIX et offrent un niveau de finesse supplémentaire avec la notion de droit de création (noté 'C') et d'administration (noté 'A').

Ainsi, il est possible de séparer l'administrateur d'un namespace -- par exemple uniquement l'équipe d'exploitation -- de ses utilisateurs, qu'ils puissent écrire ou simplement lire les données.

Les bases SQL, une sécurisation encore grosse maille

En ce qui concerne le SQL, Hive délègue sa sécurisation aux permissions HDFS sans ACLs.

Cela est valable pour les données, ce qui est logique puisqu'une table tout comme une base de données se matérialise par un répertoire sur HDFS dans Hive.

C'est également valable pour les habilitations du metastore qui sont elles stockées dans une base SQL standard externe au cluster.

Par ailleurs, un nouveau mode de sécurisation est récemment apparu, le StdSQLAuth.

Son objectif est d'apporter une sécurité du niveau de ce que l'on retrouve dans les bases SQL traditionnelles et ainsi rattraper le retard de Hive en la matière.

Avec le StdSQLAuth, il sera ainsi possible de gérer les bases et les tables Hive au moyen d'un ensemble de rôles auxquels on attribut des habilitations fines (une habilitation correspondant à un type d'opération SQL).

Les process traditionnels de gestion d'habilitation aux bases de données pourront ainsi être appliqués tels quels.

Cependant, comme nombre des nouvelles fonctionnalités et produits qui apparaissent sur Hadoop ces temps ci, ce mode n'est pas encore totalement sec, il n'est donc pas encore conseillé de s'en servir en production.

Par conséquent, le mode de sécurisation de Hive le plus pertinent et stable aujourd'hui est de se baser sur les permissions HDFS sans ACLs. La version supportant les ACLs sera intégrée à partir de Hive 0.14.

Dans le cadre d'un data lake, l'impact en terme de sécurisation est que l'on doit modéliser les accès en se basant sur des permissions POSIX  standard (Utilisateur, Groupe, Other) pour gérer les accès.

Cela signifie deux choses :

• le propriétaire d'une base ou d'une table est le seul utilisateur habilité à écrire des données ou créer des tables (à noter que par défaut le créateur d'une table est automatiquement son propriétaire)
• le groupe d'une base ou d'une table correspond aux utilisateurs habilités soit à lire, soit à lire et écrire les données. Sans ACLs, impossible d'avoir les deux types d'accès sans ouvrir la base ou la table au reste du monde (permission Other)

Ainsi, même en revenant sur un modèle de permission POSIX standard, on peut obtenir une sécurisation forte et un contrôle strict des accès à des données stockées sur Hive pour peu que l'on ne souhaite pas avoir plusieurs typologies d'accès à une même table (soit lecture, soit lecture et écriture pour tous les habilités).

Les index de moteur de recherche

Dans son intégration sur la stack Hadoop, SolR fourni un connecteur pour stocker son index sur HDFS. Ce dernier supportant Kerberos, il est possible d'utiliser le modèle de permissions POSIX standard afin de gérer les habilitations à l'index du moteur.

Pourquoi pas les ACLs HDFS ?

Aujourd'hui, le connecteur SolR sur HDFS permet d'y stocker l'index. En revanche l'alimentation de ce dernier s'effectue par des jobs MapReduce qui le mettent à jour en mode batch.

Ainsi, si le propriétaire des répertoires de l'index doit être l'utilisateur faisant tourner le processus Solr, le groupe peut être celui du ou des utilisateurs exécutant les batchs MapReduce d'alimentation de ce dernier.

Pour aller plus loin ?

Dans cet article, nous nous sommes volontairement limités à des solutions disponibles sur les dépôts Apache afin de traiter au maximum le PGDC entre les éditeurs du marché.

Malgré cela et bien que des progrès restent à faire dans certains domaines (on pense notamment à Hive), l'isolation des données est un sujet qui peut être relativement bien traité sur Hadoop aujourd'hui.

Peut on pousser la sécurisation plus loin, notamment lorsque l'on opère dans des contextes fortement règlementés ? Tout dépend des outils, HBase par exemple, sait faire du cryptage par table ou column family et des solutions d'anonymisation et de tokenisation — déjà utilisées notamment dans le secteur bancaire — sont disponibles (Voltage, Protegrity, …). Mais tout cela pourrait faire l'objet d'un prochain article !