Plongez au cœur de l'IA Générative avec notre livre blanc !

logo saagie red

Comment sécuriser l’accès de son projet data : les protocoles Posix, Sentry et Kerberos

Lors des phases de développement, c’est une partie souvent mise de côté voire oubliée : la sécurité. Cependant, c’est un point essentiel si ce n’est primordial. 

En effet, contrôler l’accès aux données, aux codes, aux jobs est nécessaire afin qu’il n’y ait pas de modifications, dégradations ou encore vols. De plus, il faut aussi s’assurer que le projet reste accessible et pérenne dans le temps et ça tout au long de sa vie (et malgré le turnover dans les équipes).

Gérer les accès utilisateurs

Une solution simple devrait être mise en place au début de chaque projet : la création d’un user applicatif ainsi que de groupes ayant différents types d’accès aux données et aux jobs. Un user applicatif va nous servir à lancer les différents jobs directement en son nom. L’avantage premier est qu’il permettra de faire face aux changements (départ/arrivée) au sein de l’équipe de développement. Dans un second temps, il vous simplifiera aussi la lecture lorsque vous parcourrez les données ou logs créés. En effet, il sera plus simple de créer le lien entre les différents outputs et le projet qui en est la source (même si un outil de data lineage sera plus adapté dans cette situation).

Dans le même temps, la création de groupe vous aidera à avoir une gestion des accès plus efficace et simple. En effet, sur la majorité des solutions du marché, il est possible de créer des groupes et d’y associer différents droits à chacun des services/projets/données. La création de groupes est complémentaire à l’utilisation d’un user applicatif. Ainsi, l’arrivée ou le départ de collaborateurs sur le projet deviendra un non événement : il suffira de les ajouter ou supprimer du/des groupe(s).

Au sein de Saagie, la création d’un user applicatif se fait de la même manière qu’un simple utilisateur. L’idée ensuite est de créer un ou plusieurs groupes dans lesquelles le user applicatif et les différents intervenants du projet vont être ajoutés. Ces différents groupes reflèteront tous les niveaux d’accès au projet (jobs et données) : on peut imaginer avoir un premier groupe (développeur) qui pourrait à la fois accéder à la donnée en lecture mais aussi en écriture ainsi que créer et exécuter des jobs et un autre (viewer) qui aurait un droit en lecture seule à la fois sur les jobs et leurs statuts mais aussi sur les données produites.

access

Si vous ne disposez pas d’un outil tel que Saagie pour vous aider à gérer les utilisateurs et groupes, il est tout à fait possible de réaliser la même organisation sur un système Linux : charge à vous de créer les utilisateurs et groupes, et de leur donner les bons accès.

Contrôler l'accès aux données

En ce qui concerne le datalake, plusieurs approches d’organisation sont viables. Ici, nous allons nous focaliser sur l’une d’entre elles qui nous semble être la plus simple à mettre en place. Afin de cloisonner la donnée à la fois d’un point de vu stade de raffinage et projet/utilisation, nous vous conseillons de créer un répertoire à la racine de votre datalake contenant trois sous répertoires. 

Vous devriez obtenir cette arborescence :

arborescence

Une fois votre datalake organisé, il faudra mettre en place une politique de sécurité afin d’assurer que seuls les utilisateurs/groupes autorisés aient accès aux données contenues dans les dossiers projets. Pour ce faire, il existe un combo de plusieurs technologies:

Nous allons désormais nous intéresser plus en détails aux 3 premiers points au travers d’exemples techniques.

Protocole POSIX

Deux possibilités existent pour appliquer les droits POSIX. Si on dispose d’une interface graphique comme HUE pour naviguer dans le DataLake, il est possible de passer par l’interface. Soit par ligne de commande.

Dans notre cas, nous voulons donner les droits au propriétaire et au groupe et ne donner aucun accès aux autres utilisateurs. Il faut donc appliquer les droits 770 sur toute l’arborescence.

Via HUE:

HUE

A noter: Le bit « Sticky » permet d’éviter la suppression du dossier ou du fichier en question par un autre personne que le propriétaire (même en ayant les droits via le groupe). Il faut donc l’appliquer sur les dossiers « raw », « intermediate » et « final ».

En ligne de commande pour affecter les mêmes droits que ci-dessus:

ligne de commande posix 1

Si l’utilisateur ou le groupe n’est pas correctement appliqué:

Ligne de commande posix 2

Les protocoles ACLs

Dans certains cas, nous voulons accorder des droits différents à certains utilisateurs ou groupes. Par exemple si on souhaite qu’un groupe accède à un dossier en lecture et un autre en écriture, les droits POSIX ne sont pas suffisants et nous avons besoin des ACLs. 

Pour affecter des droits ACL sur un dossier ou un fichier, contrairement à POSIX, on doit passer en ligne de commandes. Ces droits fonctionnent de la même manière que POSIX sauf que l’on peut affecter autant de droits sur autant d’utilisateurs et de groupes que souhaité.

En reprenant notre exemple où un dossier doit être en lecture pour un groupe et en écriture pour un autre:

code acls 1

Si l’on souhaite que la même configuration soit affecté à tous les sous dossier et fichier, il est possible de passer par les ACLs « default »:

code acls 2

Pour vérifier que les ACLs sont correctement affectés (-R est facultatif, il permet de voir les ACLs affectés à toute l’arborescence du dossier cible):

code acls 2

Pour des informations complète sur les ACLs et les droits POSIX, vous pouvez vous orienter vers la documentation officielle : ici ! 

Protocole Sentry

Dans le cas où l’on veut intégrer des technologies « SQL like » pour avoir un accès et une lisibilité plus faciles aux données, on va souvent s’orienter vers Hive, Impala ou Presto (les deux premières étant celles utilisés chez la majorité de nos clients). 

Ces technologies nécessitent une couche supplémentaire pour sécuriser les données. En effet, les droits POSIX (lecture, écriture ou exécution) ne suffissent pas, on souhaite avoir une gestion plus fines des accès : accès qu’à certaines tables ou encore certaines colonnes. 

Sentry va nous permettre de répondre à ce besoin.

code sentry 1

Pour conclure !

Dans cet article, nous avons donc vu les bonnes pratiques afin d’assurer la sécurité de vos projets et de leurs données. Chacun de ces points sont faciles à mettre en œuvre et vous permettront de garder des accès sécurisés et pérennes tout au long de la vie de vos projets. 

Un autre point important est d’assurer que le contexte d’exécution reste le même et soit isolé, c’est exactement ce que nous abordons dans cet article !