G 2  Suite dans les idées: le compte de service

La plateforme Cloud de Google définit des comptes de services. C’est une avancée et un changement de paradigme pour la suite logicielle.

Tout le développement de cette suite reposait sur des comptes utilisateurs, principalement Gmail. En conséquence toutes les autorisations consistaient à obtenir le consentement de l’utilisateur derrière le compte.

Le consentement de l’utilisateur au dévoiement de ses données

Si ce modèle était adapté pour des applications clientes qui ne traitaient que les données d’un utilisateur unitairement, il ne pouvait pas convenir pour une application maison (du domaine G Suite) . En pour cette application il n’est pas concevable de demander systématiquement le consentement des utilisateurs qui sont dans son domaine.

Aperçu (s’ouvre dans une nouvelle fenêtre)Revenons sur cette notion de consentement. Avec OAuth 2 une application cliente qui souhaite accéder à vos données, vous demande votre consentement. C’est bien et semble respecter le RGPD. Bon dans la réalité comprendre exactement ce qui est engagé derrière un scope et ce que fera réellement l’application est une autre paire de manche.

La résistance au consentement individuel

Mais imaginer une application interne au domaine qui doit consolider plusieurs feuilles de données d’un groupe de personne. Si elle doit obtenir le consentement de tous les propriétaires, cela risque de ne jamais aboutir. Il y aura toujours quelqu’un qui ne répondra pas à la demande.

Consentement par un administrateur

Donc l’enjeu est de donner à une application un niveau d’autorisation sur un scope mais pour l’ensemble des ressources protégées.

Pour cela Google Cloud Platform (GCP) a mis en place des comptes de service.

• Première remarque ces comptes ne sont pas définis dans G Suite mais dans GCP, qui est l’laaS supportant les développements et l’infrastructures de Google.
• Deuxième remarque c’est potentiellement un coût et une contrainte sur le développement d’application.

Modèle de rôle de GCP

Faisons un petit rappel de la gestion des accès et autorisations dans GCP

GCP applique une politique de rôle de type Role Based Access Control (RBAC), pour cela il faut des identités qui sont de plusieurs natures:

• Simple compte Gmail
• Groupe Google
• Domaine G Suite ou Cloud Identity (un annuaire et des accès sans les applications G Suite)
• Des comptes de services

Dans RBAC strictement nous aurions que des identités, mais cette notion n’est toujours pas claire ;-). Et il faut des rôles qui sont des agrégats de permissions générales ou spécifiques à des ressources. Le but est de gérer finement les pouvoirs d’un accès / compte sur des ressources. Il existe de très nombreux rôles et il est possible de faire ses propres mélanges.

Les rôles s’appliquent dans une hiérarchie Domaine / dossier / projet (il est possible de sauter le dossier). La majorité des comptes / identités serviront en interne de GCP pour faire tourner des services, accéder à des ressource. Le compte de service est un peu à part du fait qu’il est visible / utilisable en dehors de GCP.

Compte de service en pratique

Revenons à notre problématique, avoir une application qui accède à toutes les ressources d’un domaine sans besoin du consentement individuel. Comment cela fonctionne-t’il ?

• En premier il faut, mais ce n’est pas obligatoire, déclarer votre organisation ou domaine dans GCP.
  • Cependant comme le compte de service concerne un domaine particulier cela fait sens

• • Ensuite il faut créer un compte de service et lui ajouter une clé d’authentification, en fait une clé RSA (pas un certificat juste la clé privé)

• • Attention ce que vous récupérez est un élément cryptographique fort, il est délivré en clair (pas de passphrase !) et si il est copié, il sera directement exploitable par un autre programme.

• • Ce compte de service va faire tourner une application, il faut donc lui donner un rôle sur cette ressource, par exemple App Engine.

Pour que ce compte soit effectif, il faut l’autoriser à des API, car tout est API chez Google. Dans notre application d’exemple, nous allons lire un classeur, il nous faut alors le scope ‘https://www.googleapis.com/auth/spreadsheets’ ou encore mieux ‘https://www.googleapis.com/auth/spreadsheets.readonly’.

A la différence de l’ancienne console de gestion des API de Google qui ne permettait que de créer des identifiants de client à base de secret, nous disposons maintenant du compte de service et sa clé privée.

L’avant dernière étape purement administrative consiste à autoriser dans le domaine G Suite ce compte aux mêmes API que précédemment.

Mais le processus ne serait pas complet sans cette dernière étape. Il faut donner à ce compte, qui n’est pas une identité de votre domaine, des accès au ressources G Suite. Ceci est particulièrement important car c’est votre dernière limite au pouvoir du compte de service. En fait ce compte apparaît maintenant dans les options de partage de G Suite, il faut l’appeler par son identifiant mail et vous pourrez alors lui donner des autorisations comme à n’importe quel utilisateur.

Tout finit par du code

Finalement mettons en oeuvre tout cela dans une application. Par exemple une Cloud Functions, en fait un serveur Node.js sur lequel vous déployez un service léger déclenché par différents événements (http, Cloud Storage, …).

Voici le code du service que nous allons analyser:

Pour conclure

Donc pour résumé:

• Un compte de service et sa clé privée dans GCP
  • JWT un mécanisme fort d’authentification, sauf si on vole la clé 😉
• L’autorisation sur l’API GCP et G Suite
  • Deux niveaux d’administration sont nécessaires
• L’autorisation d’accès à la ressource dans G Suite

Il faut espérer que ce dernier niveau sera accordé par un véritable gestionnaire de données conscient des traitements que vont emprunter des données peut être personnelles.

Le compte de service est la clé de voûte de tous les développements qui reposent sur l’utilisation des données de G Suite. Par exemple le connecteur EmpowerID de provisioning l’utilise, pour cela il demande des pouvoirs propriétaires sur l’ensemble de l’annuaire. Il est donc important de bien comprendre et pouvoir cadrer les capacités de ces comptes qui peuvent toucher des données sensibles en dehors du consentement des propriétaires.

Sources

https://cloud.google.com/iam/docs/overview[:]