Bonnes pratiques d'utilisation des comptes de service

Les comptes de service représentent des utilisateurs non humains. Ils sont destinés aux scénarios dans lesquels une charge de travail, telle qu'une application personnalisée, doit accéder à des ressources ou effectuer des actions sans intervention de l'utilisateur final.

Les comptes de service diffèrent des comptes utilisateur standards sur plusieurs points :

  • Ils n'ont pas de mot de passe associé et ne peuvent pas être utilisés pour se connecter via un navigateur.
  • Ils sont créés et gérés en tant que ressources appartenant à un projet Google Cloud. Par opposition, les utilisateurs sont gérés via un compte Cloud Identity ou Google Workspace.
  • Ils sont spécifiques à Google Cloud. Par opposition, les comptes des utilisateurs gérés dans Cloud Identity ou Google Workspace fonctionnent sur une multitude de produits et services Google.
  • Il s'agit à la fois d'une ressource et d'un compte principal :
    • En tant que compte principal, un compte de service peut se voir accorder l'accès à des ressources, comme un bucket Cloud Storage.
    • En tant que ressource, un compte de service est accessible et éventuellement emprunté par d'autres comptes principaux, comme un utilisateur ou un groupe.

Bien qu'un compte de service est un outil utile, il existe plusieurs façons de l'utiliser de manière abusive :

  • Élévation des privilèges : un utilisateur malveillant pourrait accéder aux ressources auxquelles il n'aurait pas accès en se faisant passer pour le compte de service.
  • Spoofing : un tiers malintentionné peut usurper l'identité d'un compte de service pour masquer son identité.
  • Non-répudiation : un utilisateur malhonnête peut dissimuler son identité et ses actions en utilisant un compte de service pour effectuer des opérations en son nom. Dans certains cas, il peut être impossible de retracer ces actions pour identifier le tiers malintentionné.
  • Divulgation d'informations : un individu malveillant pourrait obtenir des informations sur votre infrastructure, vos applications ou vos processus en fonction de l'existence de certains comptes de service.

Pour faciliter la sécurisation des comptes de service, tenez compte de leur nature double :

  • Étant donné qu'un compte de service est une entité principale, vous devez limiter ses privilèges pour réduire le risque potentiel d'un compte de service compromis.
  • Comme un compte de service est une ressource, vous devez empêcher son piratage.

Ce guide présente les bonnes pratiques à suivre pour gérer, utiliser et sécuriser des comptes de service.

Choisir quand utiliser les comptes de service

Tous les scénarios ne nécessitent pas l'utilisation d'un compte de service pour accéder aux services Google Cloud. Vous pouvez vous authentifier avec une méthode plus sécurisée qu'une clé de compte de service dans de nombreux cas. Dans la mesure du possible, nous vous recommandons d'éviter d'utiliser des clés de compte de service.

Lorsque vous accédez aux services Google Cloud à l'aide de Google Cloud CLI, des bibliothèques clientes Cloud, d'outils compatibles avec les identifiants par défaut de l'application, comme Terraform ou REST requêtes, utilisez le schéma suivant pour vous aider à choisir une méthode d'authentification :

Arbre de décision pour choisir une méthode d'authentification en fonction du cas d'utilisation

Ce schéma vous aide à répondre aux questions suivantes :

  1. Exécutez-vous du code dans un environnement de développement à utilisateur unique, tel que votre propre poste de travail, Cloud Shell ou une interface de bureau virtuel ?
    1. Si oui, passez à la question 4.
    2. Si ce n'est pas le cas, passez à la question 2.
  2. Exécutez-vous du code dans Google Cloud ?
    1. Si oui, passez à la question 3.
    2. Sinon, passez à la question 5.
  3. Exécutez-vous des conteneurs dans Google Kubernetes Engine ou GKE Enterprise ?
    1. Si oui, utilisez la fédération d'identité de charge de travail pour GKE pour associer des comptes de service aux pods Kubernetes.
    2. Sinon, associez un compte de service à la ressource.

  4. Votre cas d'utilisation nécessite-t-il un compte de service ?

    Par exemple, vous souhaitez configurer l'authentification et l'autorisation de manière cohérente pour votre application dans tous les environnements.

    1. Si ce n'est pas le cas, authentifiez-vous avec des identifiants utilisateur.
    2. Si oui, empruntez l'identité d'un compte de service avec des identifiants utilisateur.
  5. Votre charge de travail s'authentifie-t-elle avec un fournisseur d'identité externe compatible avec la fédération d'identité de charge de travail ?
    1. Si oui, configurez la fédération d'identité de charge de travail pour permettre aux applications exécutées sur site ou sur d'autres fournisseurs cloud d'utiliser un compte de service.
    2. Si ce n'est pas le cas, créez une clé de compte de service.

Gérer les comptes de service

Les comptes de service diffèrent des comptes utilisateur normaux non seulement dans leur utilisation, mais également dans la manière dont ils doivent être gérés. Les sections suivantes fournissent quelques bonnes pratiques à adopter concernant la gestion des comptes de service.

Bonnes pratiques

Gérez les comptes de service comme des ressources.
Créez des comptes de service à usage unique.
Respectez une convention d'attribution des noms et de documentation.
Identifiez et désactivez les comptes de service inutilisés.
Désactivez les comptes de service inutilisés avant de les supprimer.

Gérer les comptes de service comme des ressources

En règle générale, les comptes utilisateur standards sont gérés selon les processus joiner-mover-leaver de l'organisation : lorsqu'un employé rejoint l'entreprise, un nouveau compte utilisateur est créé à son intention. Lorsqu'il change de service, son compte utilisateur est mis à jour. Lorsqu'il quitte l'entreprise, son compte utilisateur est suspendu ou supprimé.

Par opposition, les comptes de service ne sont associés à aucun employé. À la place, il est préférable de traiter les comptes de service comme des ressources appartenant à une autre ressource ou faisant partie d'une autre ressource, telle qu'une instance de VM spécifique ou une application.

Pour gérer les comptes de service de manière efficace, ne les traitez pas comme des éléments isolés. Au lieu de cela, considérez-les dans le contexte de la ressource à laquelle ils sont associés et gérez le compte de service et la ressource associée comme une seule et même unité : appliquez les mêmes processus, le même cycle de vie et la même vérification au compte de service et à la ressource associée, et faites appel aux mêmes outils pour les gérer.

Créer des comptes de service à usage unique

Partager un même compte de service entre plusieurs applications peut en compliquer la gestion :

  • Les applications peuvent avoir des cycles de vie différents. Si une application est mise hors service, il n'est pas forcément évident de savoir si le compte de service peut lui aussi être mis hors service ou s'il est nécessaire de le conserver.
  • Au fil du temps, les exigences d'accès des applications peuvent diverger. Si plusieurs applications utilisent le même compte de service, vous pouvez être contraint d'autoriser ce compte à accéder à un nombre croissant de ressources, ce qui augmente alors le risque global.
  • Les journaux d'audit Cloud incluent le nom du compte de service qui a accédé à des données ou effectué une modification dessus, mais ils n'affichent pas le nom de l'application qui a utilisé ce compte de service. Si plusieurs applications partagent un même compte de service, vous ne serez pas en mesure de tracer l'activité et de remonter à l'application correspondante.

En particulier, certains services Google Cloud, y compris App Engine et Compute Engine, créent un compte de service par défaut doté du rôle Éditeur (roles/editor) sur le projet par défaut. Lorsque vous créez une ressource telle qu'une instance de machine virtuelle (VM) Compute Engine et que vous ne spécifiez pas de compte de service, la ressource peut utiliser automatiquement le compte de service par défaut. Bien que le compte de service par défaut facilite la mise en route, il est très risqué de partager un compte de service aussi puissant sur plusieurs applications.

Vous pouvez prendre plusieurs mesures pour éviter ces difficultés :

Respecter une convention d'attribution des noms et de documentation

Pour faciliter le suivi de l'association entre un service et une application ou une ressource, respectez une convention d'attribution des noms lors de la création de comptes de service :

  • Ajoutez un préfixe à l'adresse e-mail du compte de service afin d'identifier la manière dont le compte est utilisé. Exemple :
    • vm- pour les comptes de service associés à une instance de VM.
    • wi- pour les comptes de service utilisés par Workload Identity.
    • wif- pour les comptes de service utilisés par la fédération d'identité de charge de travail.
    • onprem- pour les comptes de service utilisés par des applications sur site.
  • Intégrez à l'adresse e-mail du compte de service le nom de l'application, par exemple vm-travelexpenses@ si la VM exécute une application de gestion des dépenses.
  • Utilisez le champ de description pour ajouter un contact, des liens vers la documentation pertinente ou d'autres notes.

N'intégrez pas d'informations ni de termes sensibles dans l'adresse e-mail d'un compte de service.

Identifier et désactiver des comptes de service inutilisés

Lorsqu'un compte de service n'est plus utilisé, désactivez-le. Désactiver les comptes de service inutilisés permet de réduire le risque qu'ils soient utilisés de manière abusive par un utilisateur malveillant, par exemple pour effectuer des mouvements latéraux ou une élévation des privilèges.

Pour les comptes de service à usage unique associés à une ressource particulière, telle qu'une instance de VM, désactivez le compte de service dès que la ressource associée est désactivée ou supprimée.

Pour les comptes de service utilisés à plusieurs fins ou partagés entre plusieurs ressources, il peut être plus difficile de déterminer si le compte de service est toujours utilisé. Dans ce cas, vous pouvez utiliser l'outil Activity Analyzer pour afficher les activités d'authentification les plus récentes de vos comptes de service.

Désactiver les comptes de service inutilisés avant de les supprimer

Si vous supprimez un compte de service, puis créez un nouveau compte de service portant le même nom, celui-ci se voit attribuer une identité différente. Par conséquent, aucune des liaisons IAM d'origine ne s'applique au nouveau compte de service. En revanche, si vous désactivez et réactivez un compte de service, toutes les liaisons IAM restent intactes.

Pour éviter de perdre des liaisons IAM par inadvertance, il est préférable de ne pas supprimer immédiatement les comptes de service. À la place, désactivez un compte de service s'il n'est plus nécessaire et laissez un certain délai s'écouler avant de le supprimer.

Ne supprimez jamais les comptes de service par défaut tels que le compte de service par défaut d'App Engine ou celui de Compute Engine. Il n'est pas possible de recréer ces comptes de service sans désactiver et réactiver l'API correspondante, ce qui peut endommager votre déploiement existant. Si vous n'utilisez pas les comptes de service par défaut, désactivez-les plutôt.

Limiter les droits des comptes de service

Les comptes de service sont des comptes principaux et peuvent être autorisés à accéder à une ressource comme un compte utilisateur standard. Cependant, les comptes de service disposent souvent d'un accès plus important à un plus grand nombre de ressources qu'un utilisateur classique. En outre, à mesure que vous ajoutez des fonctionnalités à vos applications, leurs comptes de service ont tendance à obtenir de plus en plus d'accès au fil du temps. Vous pouvez également oublier de révoquer des accès qui ne sont plus nécessaires.

Bonnes pratiques :

Ne pas utiliser l'attribution automatique de rôles pour les comptes de service par défaut.
Ne pas se fier aux niveaux d'accès lors de l'association d'un compte de service à une instance de VM.
Éviter d'utiliser des groupes pour accorder aux comptes de service l'accès aux ressources.
Éviter d'utiliser la délégation au niveau du domaine.
Ne pas utiliser de comptes de service pour accéder aux données d'un utilisateur sans son autorisation
Utiliser l'API IAM Credentials pour l'élévation temporaire des privilèges
Utiliser des limites d'accès aux identifiants pour réduire les niveaux d'accès des jetons d'accès
Utiliser les recommandations de rôle pour identifier les autorisations inutilisées.
Utiliser les insights sur les mouvements latéraux pour limiter les mouvements latéraux.

Ne pas utiliser l'attribution automatique de rôles pour les comptes de service par défaut

Certains services Google Cloud créent des comptes de service par défaut lorsque vous activez pour la première fois leur API dans un projet Google Cloud. Par défaut, ces comptes de service se voient attribuer le rôle d'éditeur (roles/editor) sur votre projet Google Cloud, ce qui leur permet de lire et de modifier toutes les ressources du projet Google Cloud. Le rôle est accordé pour vous faciliter la tâche, mais n'est pas indispensable au fonctionnement des services. Pour accéder aux ressources de votre projet Google Cloud, les services Google Cloud utilisent des agents de service, et non les comptes de service par défaut.

Pour empêcher les comptes de service par défaut d'obtenir automatiquement le rôle d'éditeur, activez la contrainte Désactiver l'attribution de rôles automatique pour les comptes de service par défaut (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) pour votre organisation. Pour appliquer la contrainte à plusieurs projets Google Cloud, configurez-la sur le dossier ou le nœud d'organisation. L'application de la contrainte ne supprime pas le rôle Éditeur des comptes de service par défaut existants.

Si vous appliquez cette contrainte, les comptes de service par défaut dans les nouveaux projets n'auront aucun accès à vos ressources Google Cloud. Vous devez attribuer les rôles appropriés aux comptes de service par défaut afin qu'ils puissent accéder à vos ressources.

Ne pas se fier aux niveaux d'accès lors de l'association d'un compte de service à une instance de VM

Lorsque vous associez un compte de service à une instance de VM, vous pouvez spécifier un ou plusieurs niveaux d'accès. Les niveaux d'accès vous permettent de restreindre les services accessibles par la VM. Ces restrictions s'appliquent en plus des stratégies d'autorisation.

Les niveaux d'accès sont précis. Par exemple, en utilisant le niveau d'accès https://www.googleapis.com/auth/devstorage.read_only, vous pouvez limiter l'accès aux opérations en lecture seule Cloud Storage, mais vous ne pouvez pas limiter l'accès à des buckets spécifiques. Par conséquent, les niveaux d'accès ne constituent pas un remplacement adapté à des stratégies d'autorisation précises.

Au lieu de s'appuyer sur des niveaux d'accès, créez un compte de service dédié et utilisez des stratégies d'autorisation détaillées pour limiter les ressources auxquelles le compte de service a accès.

Éviter d'utiliser des groupes pour accorder aux comptes de service l'accès aux ressources

Dans une organisation, il est courant que plusieurs employés exécutent des fonctions similaires ou se chevauchant et nécessitent donc un accès similaire aux ressources. En utilisant des groupes, vous pouvez exploiter ces similitudes pour réduire la charge administrative.

Les comptes de service sont destinés à être utilisés par les applications. Il est rare que plusieurs applications exécutent la même fonction et disposent donc d'exigences d'accès similaires ou identiques. Les applications sont plutôt uniques et les ressources auxquelles ils ont besoin d'accéder sont généralement différentes pour chaque application.

L'utilisation de groupes pour accorder l'accès aux ressources aux comptes de service peut avoir un impact négatif :

  • Prolifération de groupes, chaque groupe ne contenant qu'un ou plusieurs comptes de service.
  • Administrateur d'autorisations : avec le temps, un groupe a accès à un nombre croissant de ressources, même si chaque membre du groupe n'a besoin d'accéder qu'à un sous-ensemble de ressources.

À moins que l'objectif d'un groupe ne soit défini avec précision, il est préférable d'éviter d'utiliser des groupes. À la place, accordez directement aux comptes de service l'accès aux ressources dont ils ont besoin.

Éviter d'utiliser la délégation au niveau du domaine

La délégation au niveau du domaine permet à un compte de service d'usurper l'identité d'un utilisateur dans un compte Cloud Identity ou Google Workspace. La délégation au niveau du domaine permet à un compte de service d'effectuer certaines tâches d'administration dans Google Workspace et Cloud Identity, ou d'accéder aux API Google qui ne sont pas compatibles avec les comptes de service extérieurs à Google Cloud.

La délégation au niveau du domaine ne limite pas l'identité d'un compte de service pour usurper l'identité d'un utilisateur particulier, mais permet d'emprunter l'identité de n'importe quel utilisateur dans un compte Cloud Identity ou Google Workspace, y compris les super-administrateurs. Autoriser un compte de service à utiliser la délégation au niveau du domaine peut donc en faire une cible attrayante pour les attaques par élévation des privilèges.

Évitez d'utiliser une délégation au niveau du domaine si vous pouvez accomplir votre tâche directement avec un compte de service ou en utilisant le flux d'autorisation OAuth.

Si vous ne pouvez pas éviter la délégation au niveau du domaine, limitez l'ensemble des niveaux d'accès OAuth que le compte de service peut utiliser. Bien que les niveaux d'accès OAuth ne restreignent pas les utilisateurs que le compte de service peut emprunter, ils limitent les types de données utilisateur auxquels le compte de service peut accéder.

Une application peut nécessiter l'accès à des données utilisateur sensibles ou à caractère personnel, par exemple la boîte aux lettres ou l'agenda d'un utilisateur, des documents stockés dans Google Drive, ou un ensemble de données BigQuery contenant des données sensibles.

Il peut être approprié d'utiliser un compte de service pour accéder aux données utilisateur si l'application effectue des tâches en arrière-plan sans assistance, telles que des analyses d'indexation ou de protection contre la perte de données, ou si l'utilisateur final n'est pas authentifié avec une identité Google. Pour tous les autres scénarios dans lesquels une application agit pour le compte d'un utilisateur final, il est préférable d'éviter l'utilisation de comptes de service.

Au lieu d'utiliser un compte de service pour accéder aux données de l'utilisateur (éventuellement avec une transition entre comptes principaux), utilisez le flux d'autorisation OAuth pour demander l'autorisation de l'utilisateur final. Ensuite, laissez l'application agir sous l'identité de l'utilisateur final. En utilisant OAuth au lieu d'un compte de service, vous garantissez les éléments suivants :

  • Les utilisateurs peuvent examiner les ressources pour lesquelles ils vont accorder l'accès à l'application, et peuvent accorder ou refuser leur autorisation de manière explicite.
  • Les utilisateurs peuvent révoquer leur autorisation à tout moment depuis leur page Mon compte.
  • Vous n'avez pas besoin d'un compte de service ayant accès sans restriction aux données de tous les utilisateurs.

En autorisant l'application à utiliser les identifiants de l'utilisateur final, vous déportez les contrôles d'autorisation sur les API Google Cloud. Cette approche limite le risque d'exposer accidentellement, en raison d'une erreur de codage (problème de type "confused deputy"), des données dont l'accès ne doit pas être autorisé pour l'utilisateur.

Utiliser l'API IAM Credentials pour l'élévation temporaire des privilèges

Certaines applications ne requièrent l'accès à certaines ressources qu'à des moments précis ou dans des circonstances particulières. Exemple :

  • Une application peut nécessiter l'accès aux données de configuration lors du démarrage, mais n'en a plus besoin une fois qu'elle est initialisée.
  • Une application de superviseur peut démarrer périodiquement des tâches en arrière-plan, chacune de ces tâches ayant des exigences d'accès différentes.

Dans de tels scénarios, utiliser un unique compte de service et lui accorder l'accès à toutes les ressources est contraire au principe du moindre privilège : à chaque instant, l'application a probablement accès à davantage de ressources qu'elle n'en a réellement besoin.

Pour vous assurer que les différentes parties de votre application ont accès uniquement aux ressources dont elles ont besoin, utilisez l'API IAM Credentials pour l'élévation temporaire des privilèges :

  • Créez des comptes de service dédiés pour chaque partie de l'application ou cas d'utilisation, et n'accordez à chaque compte de service que l'accès aux ressources nécessaires.
  • Créez un autre compte de service qui sert de superviseur. Accordez au compte de service superviseur le rôle Créateur de jetons du compte de service sur les autres comptes de service, de sorte qu'il puisse demander les jetons d'accès éphémères pour ces comptes de service.
  • Divisez votre application de sorte qu'une partie de l'application puisse servir d'agent de service de jetons et n'autorisez que cette partie de l'application à utiliser le compte de service superviseur.
  • Utilisez l'agent de service de jetons pour émettre des comptes de service de courte durée à utiliser par les autres parties de l'application.

Pour obtenir de l'aide concernant la création d'identifiants éphémères, consultez Créer des identifiants éphémères pour un compte de service.

Utiliser des limites d'accès aux identifiants pour réduire les niveaux d'accès des jetons d'accès

Les jetons d'accès Google sont des jetons de support, ce qui signifie que leur utilisation n'est liée à aucune application. Si votre application transmet un jeton d'accès à une autre application, cette application peut utiliser le jeton de la même manière que votre application. De même, si un jeton d'accès est divulgué à un acteur insatisfaisant, il peut l'utiliser pour obtenir l'accès.

Comme les jetons d'accès sont des jetons de support, vous devez les protéger contre la divulgation ou le masquage des parties non autorisées. Vous pouvez limiter les dommages potentiels dont un jeton d'accès volé peut être à l'origine en limitant les ressources auxquelles il accorde l'accès. Ce processus est appelé "réduction des niveaux d'accès".

Utilisez des limites d'accès aux identifiants pour réduire les niveaux d'accès à chaque fois que vous transmettez un jeton d'accès à une autre application ou à un composant différent de votre application. Définissez la limite d'accès de sorte que le jeton accorde suffisamment d'accès aux ressources requises, mais plus.

Utiliser les recommandations de rôle pour identifier les autorisations inutilisées

Lorsque vous déployez une application pour la première fois, vous ne savez peut-être pas exactement quels rôles et autorisations sont nécessaires pour l'application. Par conséquent, vous pouvez accorder au compte de service de l'application davantage d'autorisations requises.

De même, les exigences d'accès d'une application peuvent évoluer avec le temps. Certains des rôles et des autorisations que vous avez accordés initialement peuvent ne pas être nécessaires.

Servez-vous des recommandations de rôles pour identifier les autorisations réellement utilisées par une application et celles potentiellement inutilisées. Ajustez les stratégies d'autorisation des ressources concernées pour vous assurer qu'une application n'accorde pas plus d'accès que nécessaire.

Utiliser les insights sur les mouvements latéraux pour limiter les mouvements latéraux

Le mouvement latéral se produit lorsqu'un compte de service d'un projet est autorisé à usurper l'identité d'un compte de service d'un autre projet. Par exemple, un compte de service peut avoir été créé dans le projet A, mais dispose des autorisations nécessaires pour emprunter l'identité d'un compte de service dans le projet B.

Ces autorisations peuvent entraîner une chaîne d'usurpations d'identités sur plusieurs projets, ce qui permet aux comptes principaux d'accéder de manière inattendue aux ressources. Par exemple, un compte principal peut usurper l'identité d'un compte de service dans le projet A, puis l'utiliser pour usurper l'identité d'un compte de service dans le projet B. Si le compte de service du projet B est autorisé à usurper l'identité d'autres comptes de service d'autres projets de votre organisation, le compte principal peut continuer à usurper l'identité du compte de service pour passer d'un projet à l'autre, et ainsi obtenir au fur et à mesure les autorisations nécessaires.

L'outil de recommandation fournit des insights sur les mouvements latéraux pour vous aider à résoudre ce problème. Les insights sur les mouvements latéraux identifient les rôles permettant à un compte de service d'un projet d'usurper l'identité d'un compte de service d'un autre projet. Pour savoir comment afficher et gérer directement les insights sur les mouvements latéraux, consultez la page Gérer les insights sur les mouvements latéraux.

Certains insights sur les mouvements latéraux sont associés à des recommandations de rôles. Vous pouvez appliquer ces recommandations pour réduire les mouvements latéraux entre vos projets. Pour en savoir plus, consultez la section Examiner et appliquer les recommandations.

Protection contre les menaces d'élévation des privilèges

Un compte de service qui ne dispose d'aucun rôle, qui n'a pas accès à des ressources et qui n'est associé à aucune règle de pare-feu est généralement limité. Une fois que vous avez accordé à un compte de service l'accès aux ressources, la valeur du compte de service augmente : le compte de service devient plus utile pour vous, mais il devient également une cible plus attractive pour les attaques par élévation des privilèges.

Prenons l'exemple d'un compte de service qui dispose d'un accès complet à un bucket Cloud Storage contenant des informations sensibles. Dans ce cas, le compte de service est aussi efficace que le bucket Cloud Storage lui-même : au lieu d'essayer d'accéder directement au bucket, un utilisateur malveillant pourrait tenter de prendre le contrôle du compte de service. Si cette tentative réussit, l'utilisateur malveillant peut transférer ses privilèges en empruntant l'identité du compte de service, ce qui lui donne accès aux informations sensibles dans le bucket.

Les techniques d'élévation des privilèges impliquant des comptes de service appartiennent généralement aux catégories suivantes :

  • Authentification en tant que compte de service: Vous pourriez accorder par inadvertance une autorisation à un utilisateur pour emprunter l'identité d'un compte de service ; ou créer une clé de compte de service pour un compte de service. Si le compte de service est plus privilégié que l'utilisateur lui-même, l'utilisateur peut s'authentifier en tant que compte de service pour élever ses privilèges et accéder à des ressources auxquelles il n'aurait pas accès autrement.

  • Utiliser des ressources auxquelles un compte de service est associé:si un utilisateur est autorisé à accéder aux pipelines CI/CD, aux instances de VM ou à d'autres systèmes d'automatisation associés à des comptes de service et à les modifier, il peut effectuer des actions à l'aide des comptes de service associés à ces ressources. Par conséquent, même s'il n'est pas autorisé à emprunter l'identité du compte de service, il peut toujours utiliser les autorisations du compte de service pour effectuer des actions qu'il ne serait pas autorisé à effectuer lui-même.

    Par exemple, si un utilisateur dispose d'un accès SSH à une instance de VM Compute Engine, il peut exécuter du code sur l'instance pour accéder à toute ressource à laquelle le compte de service associé de l'instance peut accéder.

  • Modifications des stratégies d'autorisation, groupes ou rôles personnalisés : un utilisateur qui n'a pas accès à un compte de service privilégié peut toujours être autorisé à modifier les stratégies d'autorisation du compte de service contenant un projet ou un dossier Google Cloud. L'utilisateur peut ensuite étendre l'une de ces stratégies d'autorisation pour se donner l'autorisation pour s'authentifier directement ou indirectement en tant que compte de service.

Les sections suivantes décrivent les bonnes pratiques à adopter pour protéger les comptes de service contre les menaces d'élévation des privilèges.

Bonnes pratiques

Éviter d'autoriser les utilisateurs à emprunter des comptes de service bénéficiant de droits plus étendus que les utilisateurs eux-mêmes.
Empêcher les utilisateurs de modifier les stratégies d'autorisation des comptes de service ayant plus de privilèges.
Ne pas autoriser les utilisateurs à créer ou à importer des clés de compte de service.
Ne pas accorder l'accès aux comptes de service au niveau du projet ou du dossier Google Cloud.
Ne pas exécuter de code provenant de sources moins protégées sur des ressources de calcul disposant d'un compte de service privilégié.
Limiter l'accès à l'interface système aux VM ayant un compte de service privilégié associé.
Limiter l'accès au serveur de métadonnées aux utilisateurs et processus sélectionnés.

Éviter d'autoriser les utilisateurs à s'authentifier en tant que comptes de service bénéficiant de droits plus étendus que les utilisateurs eux-mêmes

Le fait d'emprunter l'identité d'un compte de service permet à un utilisateur d'accéder à tout ou partie des ressources auxquelles le compte de service peut accéder. Si le compte de service dispose d'un accès plus étendu que l'utilisateur, il est en réalité plus privilégié que l'utilisateur.

Accorder à un utilisateur l'autorisation d'emprunter l'identité d'un compte de service plus privilégié peut être un moyen de laisser délibérément l'utilisateur augmenter ses privilèges, d'utiliser l'outil sudo sous Linux ou d'utiliser l'élévation sous Windows. À moins de traiter un scénario dans lequel une telle élévation temporaire de privilège est nécessaire, il est préférable d'éviter que les utilisateurs empruntent l'identité d'un compte de service plus privilégié.

Les utilisateurs peuvent également obtenir indirectement les autorisations d'un compte de service en l'associant à une ressource, puis en exécutant du code sur cette ressource. L'exécution du code ne constitue pas un emprunt d'identité du compte de service, car elle n'implique qu'une seule identité authentifiée (le compte de service). Il peut toutefois donner à un utilisateur un accès auquel il n'aurait pas accès autrement.

Les autorisations qui permettent à un utilisateur d'emprunter l'identité d'un compte de service ou d'associer un compte de service à une ressource sont les suivantes:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccountKeys.create
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

Les rôles contenant certaines de ces autorisations incluent, sans s'y limiter :

  • Propriétaire (roles/owner)
  • Éditeur (roles/editor)
  • Utilisateur du compte de service (roles/iam.serviceAccountUser)
  • Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator)
  • Administrateur de clés de compte de service (roles/iam.serviceAccountKeyAdmin)
  • Administrateur de compte de service (roles/iam.serviceAccountAdmin)
  • Utilisateur Workload Identity (roles/iam.workloadIdentityUser)
  • Éditeur Deployment Manager (roles/deploymentmanager.editor)
  • Éditeur Cloud Build (roles/cloudbuild.builds.editor)

Avant d'attribuer l'un de ces rôles à un utilisateur, posez-vous les questions suivantes :

  • À quelles ressources internes et externes au projet Google Cloud actuel l'utilisateur peut-il accéder en empruntant l'identité du compte de service ?
  • Ce niveau d'accès est-il justifié ?
  • Existe-t-il suffisamment de protections permettant de contrôler les circonstances dans lesquelles l'utilisateur peut emprunter l'identité du compte de service ?

N'attribuez pas le rôle si vous ne pouvez pas confirmer toutes les questions. Envisagez plutôt d'accorder à l'utilisateur un autre compte de service moins privilégié.

Empêcher les utilisateurs de modifier les stratégies d'autorisation des comptes de service ayant plus de privilèges

Les utilisateurs autorisés à utiliser un compte de service ou à emprunter son identité sont capturés par la stratégie d'autorisation du compte de service. La stratégie d'autorisation peut être modifiée ou étendue par les utilisateurs disposant de l'autorisation iam.serviceAccounts.setIamPolicy sur le compte de service particulier. Les rôles qui contiennent cette autorisation incluent :

  • Propriétaire (roles/owner)
  • Administrateur de sécurité (roles/iam.securityAdmin)
  • Administrateur de compte de service (roles/iam.serviceAccountAdmin)

Les rôles qui incluent l'autorisation iam.serviceAccounts.setIamPolicy offrent à un utilisateur un contrôle total sur un compte de service :

  • L'utilisateur peut lui-même accorder l'autorisation d'emprunter l'identité du compte de service, ce qui lui permet d'accéder aux mêmes ressources que le compte de service.
  • L'utilisateur peut accorder à d'autres utilisateurs un niveau d'accès identique ou similaire au compte de service.

Avant d'attribuer l'un de ces rôles à un utilisateur, demandez-vous à quelles ressources internes et externes au projet Google Cloud actuel l'utilisateur pourrait accéder en empruntant l'identité du compte de service. Ne laissez pas un utilisateur modifier la stratégie d'autorisation d'un compte de service si celui-ci dispose de plus de privilèges que l'utilisateur.

Ne pas autoriser les utilisateurs à créer ou à importer des clés de compte de service

Les clés de compte de service permettent aux applications ou aux utilisateurs de s'authentifier en tant que compte de service. Contrairement à d'autres formes d'emprunt d'identité de compte de service, l'utilisation d'une clé de compte de service ne nécessite aucune forme d'authentification précédente. Toute personne possédant une clé de compte de service peut l'utiliser.

L'effet net d'une clé de compte de service pour l'authentification est semblable à l'effet de l'emprunt d'identité d'un compte de service. Si un utilisateur a accès à une clé de compte de service ou si vous lui accordez une autorisation de création d'une clé de compte de service, il peut s'authentifier en tant que compte de service et accéder à toutes les ressources auxquelles le compte de service peut accéder.

La création ou l'importation d'une clé de compte de service nécessite l'autorisation iam.serviceAccountKeys.create, incluse pour l'administrateur de clé de compte de service (roles/iam.serviceAccountKeyAdmin) et les éditeurs (roles/editor).

Avant d'attribuer un rôle qui inclut l'autorisation iam.serviceAccountKeys.create à un utilisateur, demandez-vous à quelles ressources internes et externes au projet Google Cloud actuel l'utilisateur pourrait accéder en empruntant l'identité du compte de service. Ne laissez pas un utilisateur créer des clés de compte de service pour les comptes de service qui disposent de plus de privilèges que lui.

Si votre projet Google Cloud ne nécessite pas de clés de compte de service, appliquez les contraintes de règles d'administration Désactiver la création de clés de compte de service et Désactiver l'importation des clés de compte de service au projet Google Cloud ou au dossier englobant. Ces contraintes empêchent tous les utilisateurs de créer et d'importer des clés de compte de service, y compris ceux qui disposent de l'autorisation iam.serviceAccountKeys.create sur un compte de service.

Ne pas accorder l'accès aux comptes de service au niveau du projet ou du dossier Google Cloud

Les comptes de service sont des ressources et font partie de la hiérarchie des ressources. Vous pouvez donc gérer l'accès aux comptes de service à l'un des niveaux suivants :

  • Le compte de service individuel
  • Un projet Google Cloud englobant
  • Un dossier de l'ancêtre du projet Google Cloud
  • Le nœud d'organisation

La gestion de l'accès au niveau du projet Google Cloud ou à un niveau supérieur de la hiérarchie des ressources peut contribuer à réduire les coûts administratifs, mais aussi à accorder davantage de privilèges. Par exemple, si vous accordez à un utilisateur le rôle Créateur de jetons du compte de service dans un projet Google Cloud, il peut emprunter l'identité de n'importe quel compte de service dans le projet Google Cloud. Le fait d'emprunter l'identité d'un compte de service implique que l'utilisateur peut potentiellement accéder à toutes les ressources auxquelles ce compte de service a accès, y compris des ressources extérieures à ce projet Google Cloud.

Pour éviter un tel octroi excessif, ne gérez pas l'accès aux comptes de service au niveau du projet ou du dossier Google Cloud. À la place, gérez individuellement l'accès pour chaque compte de service.

Ne pas exécuter de code provenant de sources moins protégées sur des ressources de calcul disposant d'un compte de service privilégié

Lorsque vous associez un compte de service à une ressource de calcul, telle qu'une instance de VM ou une application Cloud Run, les processus exécutés sur cette ressource peuvent utiliser le serveur de métadonnées pour demander des jetons d'accès et des jetons d'ID. Ces jetons permettent au processus de s'authentifier en tant que compte de service et d'accéder aux ressources en son nom.

Par défaut, l'accès au serveur de métadonnées n'est pas limité à des processus ou à des utilisateurs spécifiques. Au lieu de cela, tout code exécuté sur la ressource de calcul peut accéder au serveur de métadonnées et obtenir un jeton d'accès. Ce code peut comprendre :

  • Le code de votre application.
  • Le code envoyé par les utilisateurs finaux, si votre application autorise toute évaluation de script côté serveur.
  • La lecture du code depuis un dépôt source distant, si la ressource de calcul fait partie d'un système CI/CD.
  • Des scripts de démarrage et d'arrêt, diffusés par un bucket Cloud Storage.
  • Règles applicables aux invités distribuées par VM Manager.

Si le code est envoyé par des utilisateurs ou s'il est lu à partir d'un emplacement de stockage distant, vous devez vous assurer qu'il est fiable et que les emplacements de stockage distant sont au moins sécurisés par le compte de service associé. Si un emplacement de stockage distant est moins bien protégé que le compte de service, un mauvais utilisateur pourrait être en mesure de faire remonter ses droits. Pour ce faire, il peut injecter un code malveillant qui utilise les privilèges du compte de service à cet emplacement.

Limiter l'accès à l'interface système aux VM ayant un compte de service privilégié associé

Certaines ressources de calcul sont compatibles avec l'accès interactif et permettent aux utilisateurs d'obtenir un accès à l'interface système. Exemple :

  • Compute Engine vous permet d'utiliser SSH ou RDP pour vous connecter à une instance de VM.
  • Google Kubernetes Engine vous permet d'exécuter une commande ou de démarrer une interface système dans un conteneur Kubernetes à l'aide de kubectl exec.

Si une instance de VM est associée à un compte de service privilégié, tout utilisateur ayant accès à l'interface système peut s'authentifier et accéder aux ressources en tant que compte de service. Pour empêcher les utilisateurs d'abuser de cette capacité à transmettre leurs droits, vous devez vous assurer que l'accès à l'interface système est au moins aussi sécurisé que le compte de service associé.

Pour les instances Linux, vous pouvez vérifier que l'accès SSH est plus restrictif que l'accès au compte de service associé en utilisant OS Login. Pour vous connecter à une instance de VM sur laquelle OS Login est activé, un utilisateur ne doit pas uniquement avoir l'autorisation d'utiliser OS Login, mais doit également avoir l'autorisation iam.serviceAccounts.actAs sur le compte de service associé.

Le même niveau de contrôle d'accès ne s'applique pas aux instances de VM qui utilisent des clés basées sur les métadonnées ou aux instances Windows : publier une clé SSH vers des métadonnées ou demander des identifiants Windows nécessite un accès aux métadonnées de l'instance de VM et l'autorisation iam.serviceAccounts.actAs sur le compte de service associé. Toutefois, après la publication de la clé SSH ou l'obtention des identifiants Windows, les connexions suivantes ne sont soumises à aucune vérification d'autorisation IAM supplémentaire.

De même, si une instance de VM utilise un module d'authentification Linux connectable personnalisé à des fins d'authentification ou si elle est membre d'un domaine Active Directory, il est possible que les utilisateurs qui n'ont pas l'autorisation d'emprunter l'identité du compte de service sont autorisés à se connecter. Pour plus d'informations, consultez la section Bonnes pratiques pour l'exécution d'Active Directory sur Google Cloud.

Pour les instances de VM qui n'utilisent pas OS Login, envisagez de gérer l'accès à le shell de Identity-Aware Proxy. N'accordez le rôle d'utilisateur de tunnels sécurisés par IAP (roles/iap.tunnelResourceAccessor) qu'aux utilisateurs devant être autorisés à emprunter l'identité du compte de service associé à l'instance de VM.

Limiter l'accès au serveur de métadonnées aux utilisateurs et processus sélectionnés

Lorsque vous associez un compte de service à une instance de VM, les charges de travail déployées sur la VM peuvent accéder au serveur de métadonnées afin de demander des jetons pour les comptes de service. Par défaut, l'accès au serveur de métadonnées n'est limité à aucun processus ou utilisateur spécifique de la VM : même les processus exécutés en tant qu'utilisateur à privilèges faibles, tels que nobody sous Linux ou LocalService sous Windows, disposent d'un accès complet au serveur de métadonnées et peuvent obtenir des jetons pour le compte de service.

Pour limiter l'accès du serveur de métadonnées à des utilisateurs spécifiques, configurez le pare-feu de l'hôte du système d'exploitation invité de sorte que ces utilisateurs puissent ouvrir des connexions sortantes au serveur de métadonnées.

Sous Linux, vous pouvez utiliser les options --uid-owner et --gid-owner pour configurer une règle iptables qui ne s'applique qu'à des utilisateurs ou à des groupes spécifiques. Sous Windows, la commande Set-NetFirewallSecurityFilter vous permet de personnaliser une règle de pare-feu afin qu'elle s'applique aux utilisateurs ou aux groupes sélectionnés.

Protection contre les menaces de divulgation d'informations

Bonnes pratiques :

Éviter de divulguer des informations confidentielles dans les adresses e-mail d'un compte de service.

Éviter de divulguer des informations confidentielles dans les adresses e-mail d'un compte de service

Pour accorder à un compte de service l'accès à une ressource d'un autre projet Google Cloud, vous pouvez ajouter une liaison de rôle à la stratégie d'autorisation de la ressource. Tout comme la ressource elle-même, la stratégie d'autorisation fait partie de l'autre projet Google Cloud et sa visibilité est également contrôlée par ce projet.

L'affichage des stratégies d'autorisation n'est généralement pas considéré comme une opération privilégiée. De nombreux rôles incluent l'autorisation *.getIamPolicy requise, y compris le rôle de lecteur de base.

Un utilisateur pouvant consulter une stratégie d'autorisation peut également voir les adresses e-mail des comptes principaux autorisés à accéder à la ressource. Dans le cas des comptes de service, les adresses e-mail peuvent fournir des indications aux utilisateurs malveillants.

Par exemple, une stratégie d'autorisation peut inclure une liaison pour un compte de service avec l'adresse e-mail jenkins@deployment-project-123.gserviceaccount.com. À un acteur malintentionné, cette adresse e-mail indique non seulement qu'il existe un projet Google Cloud ayant l'ID deployment-project-123, mais que le projet Google Cloud exécute un serveur Jenkins. En choisissant un nom plus générique tel que deployer@deployment-project-123.gserviceaccount.com, vous évitez de divulguer des informations sur le type de logiciel exécuté dans deployment-project-123.

Si vous accordez à un compte de service l'accès aux ressources d'un projet Google Cloud dont l'accès est moins contrôlé (tel qu'un bac à sable ou un projet Google Cloud de développement), assurez-vous que l'adresse e-mail du compte de service ne divulgue pas d'informations. En particulier, ne divulguez pas d'informations confidentielles ou susceptibles de fournir des indications à des pirates informatiques.

Protection contre les menaces de non-répudiation

Chaque fois que vous remarquez une activité suspecte affectant l'une de vos ressources sur Google Cloud, les journaux Cloud Audit sont une source importante d'informations permettant de savoir quand l'activité a eu lieu et quels utilisateurs ont été impliqués.

Chaque fois que les journaux Cloud Audit indiquent que l'activité a été effectuée par un compte de service, ces informations peuvent ne pas suffire pour reconstruire la chaîne complète d'événements : vous devez également identifier l'utilisateur ou l'application à l'origine du compte de service pour effectuer l'activité.

Cette section présente les bonnes pratiques à suivre pour conserver un outil d'audit non-répudiable.

Bonnes pratiques :

Utiliser des clés de compte de service uniquement lorsqu'il n'existe aucune alternative viable
Activer les journaux des accès aux données pour les API IAM
Vérifier que l'historique CI/CD peut être corrélé avec Cloud Audit Logs
Créer des entrées de journal personnalisées pour les utilisateurs individuels d'une application

Utiliser des clés de compte de service uniquement lorsqu'il n'existe aucune alternative viable

Si vous ne pouvez pas utiliser de méthodes d'authentification plus sécurisées, vous devrez peut-être créer une clé de compte de service pour l'application. Toutefois, l'authentification avec une clé de compte de service représente une menace de non-répudiation. Cloud Audit Logs crée un journal lorsqu'un compte de service modifie une ressource. Cependant, si le compte de service est authentifié avec une clé de compte de service, il n'existe aucun moyen fiable d'identifier l'utilisateur de la clé. En comparaison, l'authentification en tant que compte de service en empruntant l'identité du compte de service avec les identifiants utilisateur permet de consigner le compte principal qui agit en tant que compte de service.

Nous vous recommandons d'empêcher la création de clés de compte de service en appliquant la contrainte de règle d'administration Désactiver la création de clés de compte de service au projet Google Cloud ou au dossier englobant. Si vous devez utiliser des clés de compte de service dans le cas d'un scénario qui ne peut être traité avec aucune des alternatives recommandées, accordez une exception à la contrainte de règle de manière aussi restrictive que possible et consultez les bonnes pratiques pour gérer les clés de compte de service.

Activer les journaux d'accès aux données pour les API IAM

Pour vous aider à identifier et à comprendre les scénarios d'emprunt d'identité du compte de service, des services tels que Compute Engine incluent une section serviceAccountDelegationInfo dans les journaux Cloud Audit. Cette section indique si l'identité du compte de service a été empruntée et par quel utilisateur.

Tous les services n'incluent pas les détails d'emprunt d'identité dans leurs journaux Cloud Audit. Pour enregistrer tous les événements d'usurpation d'identité, vous devez également activer les journaux d'accès aux données pour les API suivantes :

  • API IAM (Identity and Access Management) dans tous les projets Google Cloud contenant des comptes de service
  • API Security Token Service dans tous les projets Google Cloud contenant des pools d'identités de charge de travail

En activant ces journaux, vous vous assurez qu'une entrée est ajoutée aux journaux Cloud Audit chaque fois qu'un utilisateur demande un jeton d'accès ou un jeton d'identification pour un compte de service.

Vérifier que l'historique CI/CD peut être corrélé avec les journaux Cloud Audit

Les comptes de service sont couramment utilisés par les systèmes CI/CD pour effectuer des déploiements après qu'une modification de code a été validée et approuvée pour le déploiement. En règle générale, les systèmes CI/CD conservent un historique des événements qui mènent à un déploiement. Cet historique peut inclure les ID des examens de code, des commits et des exécutions de pipeline correspondants, ainsi que des informations sur l'utilisateur qui a approuvé le déploiement.

Si un déploiement modifie des ressources sur Google Cloud, ces modifications sont suivies dans les journaux Cloud Audit des ressources respectives. Les journaux Cloud Audit contiennent des informations sur l'utilisateur ou le compte de service à l'origine de la modification. Cependant, dans un déploiement déclenché par un système CI/CD, le compte de service lui-même est souvent insuffisant pour reconstruire l'intégralité de la chaîne d'événements ayant entraîné la modification.

Pour établir une piste d'audit cohérente entre votre système CI/CD et Google Cloud, vous devez vous assurer que les enregistrements des journaux Cloud Audit peuvent être corrélés aux événements de l'historique de ce système. Si vous rencontrez un événement inattendu dans les journaux Cloud Audit, vous pouvez utiliser cette corrélation pour déterminer si la modification a été effectuée par le système CI/CD, pourquoi elle a été effectuée et qui l'a approuvée.

Les méthodes permettant d'établir une corrélation entre les journaux Cloud Audit et les événements de l'historique du système CI/CD sont les suivantes :

  • Requêtes API Log effectuées par chaque pipeline CI/CD
  • Chaque fois que l'API renvoie un ID d'opération, enregistrez l'ID dans les journaux du système CI/CD.

  • Ajoutez un en-tête HTTP X-Goog-Request-Reason aux requêtes API et transmettez l'ID de l'exécution du pipeline CI/CD. Terraform peut ajouter automatiquement cet en-tête si vous spécifiez un motif de requête.

    Vous pouvez également intégrer les informations dans l'en-tête User-Agent afin qu'elles soient enregistrées dans Cloud Audit Logs.

Pour garantir la non-répudiabilité, configurez les fichiers journaux et les historiques de commit de sorte qu'ils soient immuables et qu'un utilisateur malveillant ne puisse pas masquer leurs traces de manière rétroactive.

Créer des entrées de journal personnalisées pour les utilisateurs individuels d'une application

Les comptes de service sont également utiles pour les applications dans lesquelles un utilisateur s'authentifie avec un schéma d'authentification personnalisé, puis accède indirectement aux ressources Google Cloud. Ces applications peuvent confirmer que l'utilisateur est authentifié et autorisé, puis utiliser un compte de service pour s'authentifier auprès des services Google Cloud et accéder aux ressources. Toutefois, Cloud Audit Logs enregistrera que le compte de service a accédé à une ressource, et non l'utilisateur qui utilisait votre application.

Pour vous aider à tracer cet accès jusqu'à l'utilisateur, concevez une logique d'application permettant d'écrire une entrée de journal personnalisée chaque fois qu'un utilisateur accède à une ressource et de la mettre en corrélation à l'aide de Cloud Audit Logs.

Étapes suivantes