1. Introduction
Il y a presque deux ans, nous évoquions la sécurité des groupes au sein de Google Workspace (en résumé, par défaut, ce n’est pas fou). Néanmoins, d’autres axes existent pour tenter de mettre à mal la sécurité d’un Google Workspace : les comptes de service.
Au sein de Google Cloud Platform (GCP), un « compte de service » est un type de compte spécifique permettant de représenter une application (ou une machine) afin de s’authentifier et d’interagir avec les API de Google (Admin, Drive, Calendar, etc.).
Les comptes de service appartiennent à un projet au sein de GCP et ne sont pas directement visibles au sein de Google Workspace. Ainsi, ils n’appartiennent à aucune Organization Unit (OU) permettant de rajouter certaines restrictions.
Enfin, la délégation de domaine ou Domain-Wide Delegation est une fonctionnalité accessible uniquement aux administrateurs de Google Workspace permettant aux comptes de service Google Cloud Platform d’agir au nom des utilisateurs d’un domaine Google Workspace sans que ces derniers aient à s’authentifier et à autoriser l’application.
Pour utiliser ce compte de service, pas de mot de passe à retenir ! Il est nécessaire de créer une clé privée (au format JSON ou P12).
Une image valant mille mots :
2. Utilisation d’un compte de service
D’une manière plus visuelle, les étapes nécessaires à l’utilisation d’un compte de service sont :
- Création d’un projet Cloud au sein de Cloud Console
- Création d’un « Compte de service » au sein du projet Cloud créé
- Création d’une « clé privée » liée au compte de service (lui-même lié au projet Cloud)
A présent, et en se servant de l’ID client du compte de service, il est possible de créer une délégation de domaine en ajoutant les permissions souhaitées en fonction des différents besoins :
Le proverbe « qui peut le plus peut le moins » ne s’appliquant pas en sécurité, il est préférable de suivre la recommandation de Google en « ajoutant chaque habilitation à laquelle l’application peut accéder, en veillant à ce qu’elles soient suffisamment limitées ».
3. Et le suivi dans tout ça ?
Malheureusement, c’est ici que ça devient problématique ! En effet, comme il est possible de le voir dans les matriochkas, les clés privées sont associées à un compte de service qui lui même est associé à un projet Cloud au sein de GCP et il n’y a pas de méthode « simple » pour lister tout cela !
Google propose d’utiliser son API pour répertorier et modifier les comptes de service. Néanmoins, il semble un peu triste que cette fonctionnalité soit incomplète ! En effet, le code fourni met en avant que la fonction list_service_accounts() prend en paramètre un project_id :
Il sera donc nécessaire de faire une double boucle pour lister l’ensemble des comptes de services au sein de l’ensemble des fichiers grâce notamment à la méthode projects.list.
Ca y est, c’est fini ? Et bien en fait … Non ! Car comme le dit le proverbe « jamais deux sans trois » ! Si vous souhaitez avoir une vision complète, il faut lister l’ensemble des clés de service (de l’ensemble des comptes de services, de l’ensemble des projets). Il est possible de le faire grâce à la méthode projects.serviceAccounts.keys.list.
4. On parle un peu de sécurité ou pas ?
Google c’est cool, les comptes de service c’est super, les clés privées c’est top aussi ! Néanmoins, il est important de garder certains points en tête lorsque l’on utilise tout cela :
- Hormis l’utilisation de l’API, il n’existe pas de solution simple pour afficher l’ensemble des comptes de service ainsi que les clés privées de ces derniers
- Lorsqu’une clé privée est créée, sa date d’expiration est le 1 janv. 10000 (largeee)
- La clé privée est persistante même si l’utilisateur l’ayant créé est supprimé
Le suivi, la documentation ainsi que la rotation des clés de service restent donc une étape cruciale pour assurer un haut niveau de sécurité des comptes de service.
Chez ORHUS, nous avons automatisé cela, parlons-en !