Le but de cet article est de donner un état des lieux de ce que j'ai pu observer en terme de sécurité sur les data lakes que j'ai pu croiser dans ma vie de développeur big data.

J'ai travaillé sur des projets big data en banque finance, assurance, marketing automobile, marketing électro ménager, soit 4 data lakes, tous utilisant HDFS. Je milite dans la mesure de mes moyens sur la sécurité en général, et sur la sécurité des data lakes, qui sont mon quotidien.

Statistiques non significatives

Sur 4 clients:

  • deux seulement ont sécurisé leur cluster avec au moins une solution de sécurité autre que le "firewall", en l'occurence Kerberos dans les deux cas. Les deux autres n'ont aucun système de chiffrement au repos (stockage des données) ou en transit (chiffrement des données pendant des transferts réseaux).
  • aucun client n'utilise de comptes nominatifs pour les connexions. Tout le monde utilise des noms génériques de service. Les connexions sont tracées de machine à machine dans un seul cas. Les mots de passe sont changés entre 90 jours (un client) et... Jamais (trois clients).
  • Un client sur 4 utilise un PRA, et un seul client (le même) a un système de sauvegarde sur un autre cluster
  • J'ai été root (ou administrateur de la plateforme Hadoop) sur les machines de production dans deux cas sur quatre, sans être interne de la société en question. Dans 3 cas sur 4, les accès USB étaient ouverts. Dans tous les cas j'ai eu les accès en lecture et en écriture à tout le cluster
  • Un client a laissé les machines du cluster connectées à des machines ouvertes sur l'extérieur
  • Un client a connu pendant ma prestation un vol de données. L'incident a été traité sans alerter le RSSI. La raison est que le sysadmin chargé de la surveillance ne voulait pas perdre son bonus.

Les risques propres aux data lakes

Alors, évidemment, je ne vais pas dérouler tous les risques relatifs à la sécurité informatique. Deux éléments me semblent notoires :

  • si sortir les données de nombreuses applications est complexe et long, le fait est que sur un data lake, c'est enfantin. Toutes les données sont au même endroit, sur le même cluster, et en CSV ou format équivalent. Pourquoi se priver, n'est ce pas? (indice : les raisons légales). Le risque de malveillance interne existe, et est sous estimé. J'aime taquiner mes clients en leur demandant ce qu'il se passe si je chiffre les disques du cluster. Ca ne me pose pas de problème technique puisqu'en tant que développeur big data, j'ai toujours eu accès à toutes les données en écriture et lecture. La réponse est invariablement la même "on te fait confiance".
  • la sécurité, si elle est mise en place, l'est toujours après coup. La raison est simple : le métier ou le sponsor dépensent une fortune pour la mise en place de l'infrastructure et veulent un retour sur investissement au plus tôt. La sécurité n'étant pas jugée fondamentale (du fait qu'on est entre nous, la confiance tout ça), elle n'est pas mise en place au début du projet. Elle l'a été dans un cas sur 2, et toujours après coup.

Les pistes techniques

Je ne suis pas RSSI, mais ce que j'attends a minima reste :

  • l'utilisation de comptes nominatifs sur le cluster, avec une vraie politique de changement de mots de passe
  • que tout déplacement de donnée du cluster vers une machine soit journalisé quelque part, évidemment pas sur une machine sur laquelle j'ai des droits d'écriture
  • la mise en place à minima de kerberos, knox ou ranger, ou toute solution de sécurité équivalente
  • qu'aucune personne ayant accès au cluster depuis son poste ne dispose de moyens de déplacer la donnée hors du SI (donc pas de clé USB, pas de dropbox, drive, et solution équivalente).
  • qu'une entreprise spécialisée dans la sécurité audite un cluster de production périodiquement, idéalement tous les 6 mois

Conclusion

Je pense que le marché sera submergé de data scientists dans trois ans, et que le soufflet du big data s'arrêtera. NON, toutes les entreprises ayant plus de 100 go de données n'ont pas toutes intérêt à partir sur un data lake. En revanche, le besoin est crucial et sous estimé d'ingénieurs big data compétents en sécurité pour :

  • conseiller le client et lui rappeler que le vol de données est un sport (inter)national très amusant, et qu'il n'y a pas de raison intrinsèque qu'il y échappe.
  • auditer le client pour la mise en place du socle minimal de sécurité
  • challenger le RSSI pour que celui ci réalise que mettre toutes ses données au même endroit est une aubaine extraordinaire pour toute personne mal intentionnée. A ce titre, le data lake n'est pas un problème mineur à traiter quand on aura le temps

 

 

 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.