Bonnes pratiques d'utilisation des comptes de service

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.
/

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

Les comptes de service fournissent une identité pour les applications sans surveillance, telles que les tâches par lot, les processus de nœud de calcul qui envoient les messages dans une file d'attente ou les agents de surveillance des ressources. En utilisant un compte de service, vous permettez à ces applications de s'exécuter sans interaction de l'utilisateur. De plus, si l'application accède à une ressource, vous pouvez utiliser Cloud Audit Logs pour remonter jusqu'au compte de service utilisé par l'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. Pour aider à tracer cet accès jusqu'à l'utilisateur, l'application peut écrire une entrée de journal personnalisée chaque fois qu'un utilisateur accède à une ressource, et vous pouvez corréler les entrées de journal personnalisées avec Cloud Audit Logs.

Contrairement aux utilisateurs, les comptes de service ne peuvent pas s'authentifier en se connectant avec un mot de passe ni avec l'authentification unique (SSO, single sign-on). En revanche, les comptes de service fonctionnent avec un autre ensemble de méthodes d'authentification. Les sections suivantes décrivent comment choisir entre ces méthodes. Vous pouvez également utiliser le schéma suivant pour vous aider à choisir une méthode d'authentification :

Utiliser les comptes de service

La section suivante décrit les bonnes pratiques pour choisir quand et comment utiliser les comptes de service.

Utiliser si possible des comptes de service rattachés

Pour permettre à une application déployée sur Google Cloud d'utiliser un compte de service, associez le compte de service à la ressource de calcul sous-jacente. En associant ainsi le compte de service, vous autorisez l'application à obtenir des jetons pour le compte de service et à utiliser ces jetons pour accéder aux API et aux ressources Google Cloud.

Pour obtenir des jetons d'accès dans l'application, utilisez si possible les bibliothèques clientes. Les bibliothèques clientes utilisent les identifiants par défaut de l'application pour rechercher automatiquement les identifiants associés et acquérir des jetons d'accès pour votre application.

Dans les cas où l'utilisation des bibliothèques clientes n'est pas pratique, ajustez votre application pour obtenir un jeton de manière automatisée auprès du serveur de métadonnées. Les ressources de calcul permettant d'accéder au serveur de métadonnées sont les suivantes :

Pour obtenir la liste complète des ressources de calcul permettant d'associer un compte de service, consultez la page Gérer l'emprunt d'identité d'un compte de service.

Utiliser Workload Identity pour associer des comptes de service aux pods Kubernetes

Si vous utilisez Google Kubernetes Engine, vous exécutez peut-être une combinaison d'applications différentes sur un même cluster GKE. Les applications individuelles sont susceptibles de nécessiter l'accès à des ressources et des API différentes.

Si vous associez un compte de service à un cluster GKE ou à l'un de ses pools de nœuds, tous les pods exécutés sur le cluster ou le pool de nœuds peuvent par défaut emprunter l'identité du compte de service. Lorsque vous partagez un compte de service unique entre différentes applications, il devient difficile d'attribuer au compte de service un ensemble de privilèges approprié :

  • Si vous n'accordez l'accès qu'aux ressources requises par l'ensemble des applications, certaines applications sont susceptibles d'échouer car elles ne peuvent pas accéder à certaines de leurs ressources.
  • Si vous accordez l'accès à toutes les ressources dont chaque application particulière a besoin, vous accordez un accès excessif.

Une meilleure approche pour gérer l'accès aux ressources dans un environnement GKE consiste à utiliser Workload Identity :

  1. N'associez pas de comptes de service à des clusters ou à des pools de nœuds GKE.
  2. Créez un compte de service dédié pour chaque pod Kubernetes nécessitant l'accès à des API ou ressources Google.
  3. Créez un compte de service Kubernetes pour chaque pod Kubernetes qui nécessite l'accès à des API ou ressources Google, et associez-le au pod.
  4. Utilisez Workload Identity pour créer un mappage entre les comptes de service et les comptes de service Kubernetes correspondants.

Utiliser la fédération d'identité de charge de travail pour permettre aux applications s'exécutant sur site ou chez d'autres fournisseurs cloud d'utiliser un compte de service

Si votre application s'exécute sur site ou chez un autre fournisseur cloud, vous ne pouvez pas associer un compte de service aux ressources de calcul sous-jacentes. Toutefois, l'application peut avoir accès aux identifiants spécifiques à l'environnement tels que :

  • Identifiants temporaires AWS
  • Jetons d'accès Azure Active Directory
  • Jetons d'accès OpenID ou jetons d'identification émis par un fournisseur d'identité sur site tel que les services AD FS (Active Directory Federation Services) ou KeyCloak

Si votre application a accès à l'un de ces identifiants et doit accéder à des API ou ressources Google Cloud, utilisez la fédération d'identité de charge de travail.

La fédération d'identité de charge de travail vous permet de créer une relation d'approbation unidirectionnelle entre un projet Google Cloud et un fournisseur d'identité externe. Une fois l'approbation établie, les applications peuvent utiliser les identifiants émis par le fournisseur d'identité de confiance pour emprunter l'identité d'un compte de service, selon un processus en trois étapes :

  1. Obtention des identifiants auprès du fournisseur d'identité approuvé, par exemple un jeton OpenID Connect.
  2. Utilisation de l'API Security Token Service (STS) pour échanger les identifiants contre un jeton Google STS temporaire.
  3. Utilisation du jeton STS pour s'authentifier auprès de l'API IAM Service Account Credentials et obtenir des jetons d'accès Google de courte durée pour un compte de service.

Ce processus est automatique lorsque vous utilisez une bibliothèque cliente ou un outil de ligne de commande compatible pour accéder aux services Google Cloud.

Grâce à la fédération d'identité de charge de travail, vous pouvez autoriser les applications à utiliser les mécanismes d'authentification fournis par l'environnement externe, et ainsi éviter d'avoir à stocker et gérer des clés de compte de service.

Utiliser l'API IAM Credentials pour obtenir des identifiants

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 obtenir les identifiants éphémères :

  • 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.

Utiliser les clés de compte de service s'il n'existe aucune alternative viable

Il arrive parfois que l'association d'un compte de service ne soit pas possible, et que ni Workload Identity, ni la fédération d'identité de charge de travail ne représentent des options viables. Par exemple, vous pouvez utiliser une application tierce qui doit accéder à vos ressources Google Cloud et qui n'est pas compatible avec la fédération d'identité.

Dans les cas où les autres approches d'authentification ne sont pas viables, créez une clé de compte de service pour l'application. Une clé de compte de service permet à une application de s'authentifier en tant que compte de service, de la même manière qu'un utilisateur peut s'authentifier avec un nom d'utilisateur et un mot de passe. Les clés de compte de service sont un type de secret et doivent donc être protégées contre les accès non autorisés.

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 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.

Ne pas utiliser de comptes de service lors du développement

Au quotidien, vous pouvez utiliser des outils comme Google Cloud CLI, gsutil ou terraform. N'utilisez pas de compte de service avec ces outils. À la place, faites-leur utiliser vos identifiants en exécutant gcloud auth login (pour la CLI gcloud et gsutil) ou gcloud auth application-default login (pour terraform et les outils tiers).

Vous pouvez utiliser une approche similaire pour le développement et le débogage des applications que vous prévoyez de déployer sur Google Cloud. Une fois déployée, l'application peut nécessiter un compte de service. Toutefois, quand vous l'exécutez sur votre poste de travail local, vous pouvez l'autoriser à utiliser vos identifiants personnels.

Pour vous assurer que votre application est compatible avec les identifiants personnels et les identifiants de compte de service, utilisez les bibliothèques clientes Cloud et les identifiants par défaut de l'application.

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.

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.

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 Cloud, ce qui lui permet de lire et de modifier toutes les ressources du projet 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 Cloud, les services Google Cloud utilisent des agents de service et 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 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.

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 :

  • Usurpation d'identité directe : vous pouvez, par inadvertance, autoriser l'utilisateur à usurper 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 utiliser cette fonctionnalité pour transmettre ses privilèges et accéder à des ressources auxquelles il n'aurait pas accès autrement.

  • Usurpation d'identité indirecte : si un utilisateur ne peut pas s'approprier directement un compte de service, il peut le faire indirectement si le compte de service est utilisé par un pipeline CI/CD, une instance de VM ou un autre système d'automatisation auquel l'utilisateur peut accéder. Par conséquent, si le système n'empêche pas une telle usurpation d'identité indirecte, cet utilisateur pourrait effectuer des opérations 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 indirectement remplacer l'identité du compte de service associé à l'instance de VM et accéder à toutes les ressources Google Cloud que le compte de service peut utiliser.

  • 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 Cloud. L'utilisateur peut ensuite étendre l'une de ces stratégies d'autorisation pour se donner l'autorisation pour emprunter directement ou indirectement le 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.

Éviter d'autoriser les utilisateurs à emprunter des 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 un compte de service plus privilégié peut être un moyen de laisser délibérément les utilisateurs augmenter ses privilèges, d'utiliser l'outil sudo sous Linux ou d'utiliser l'élévation de processus 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 un compte de service plus privilégié.

Les autorisations qui permettent à un utilisateur de se faire passer pour un compte de service 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 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 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 à d'autres formes d'usurpation d'identité. Si vous accordez à un utilisateur l'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, l'utilisateur peut emprunter l'identité du 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 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 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 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 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 Cloud englobant
  • Un dossier de l'ancêtre du projet Cloud
  • Le nœud d'organisation

La gestion de l'accès au niveau du projet Cloud ou à un niveau supérieur de la hiérarchie des ressources peut contribuer à réduire les coûts administratifs, mais à accorder davantage de privilèges. Par exemple, si vous accordez à un utilisateur le rôle Créateur de jetons de compte de service dans un projet Cloud, il peut emprunter l'identité de n'importe quel compte de service dans le projet Cloud. Le fait d'emprunter l'identité d'un compte de service implique que l'utilisateur peut potentiellement accéder à toutes les ressources auxquelles ces comptes de service ont accès, y compris des ressources extérieures à ce projet 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 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 d'emprunter l'identité du 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 emprunter l'identité du compte de service et accéder aux ressources en son nom. 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 prêtable 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 service compte sont autorisés à se connecter.

Pour les instances de VM qui n'utilisent pas OS Login, envisagez de gérer l'accès à l'interface système de Identity-Aware Proxy. N'accordez le rôle d'utilisateur de tunnels sécurisés par IAP qu'aux utilisateurs devant être autorisés à emprunter le 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

É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 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 Cloud et sa visibilité est également contrôlée par cet autre 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 malveillant, cette adresse e-mail indique non seulement qu'il existe un projet Cloud ayant l'ID deployment-project-123, mais que le projet 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 Cloud dont l'accès est moins contrôlé (tel qu'un bac à sable ou un projet 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.

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 Cloud contenant des comptes de service
  • API Security Token Service dans tous les projets Cloud contenant des pools Workload Identity

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.

Étapes suivantes