Bonnes pratiques pour sécuriser les comptes de service

Les comptes de service diffèrent des comptes utilisateur, car ils sont à la fois une ressource et 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.

Pour sécuriser les 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.

Un compte de service peut être utilisé de différentes manières :

  • É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 peut usurper l'identité d'un compte de service pour obscurcir 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 tracer ces actions auprès du mauvais acteur.
  • 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.

Ce guide présente les bonnes pratiques à suivre pour limiter les privilèges des comptes de service et réduire les risques encourus.

Limiter les droits associés à un compte de service

Les comptes de service sont des comptes principaux et peuvent être autorisés à accéder à une ressource comme un compte utilisateur standard.

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.

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 IAM (Identity and Access Management).

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 IAM 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 IAM 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 qui peuvent être inutilisées. Ajustez les stratégies IAM des ressources concernées pour vous assurer qu'une application n'accorde pas plus d'accès que nécessaire.

Se protéger 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, le service 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 elle peut accéder. Si le système ne met pas en œuvre les restrictions d'accès appropriées, l'utilisateur peut laisser le système effectuer des opérations qu'il ne serait pas autorisé à effectuer, grâce à l'élévation des privilèges.
  • Modifications des stratégies IAM, 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 IAM du compte de service contenant un projet ou un dossier Cloud. L'utilisateur peut ensuite étendre l'une de ces stratégies IAM 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.serviceAccountKeys.create
  • iam.serviceAccountKeys.get
  • 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 IAM 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 IAM du compte de service. La stratégie IAM 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 IAM 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.

Se protéger contre les menaces de spoofing

La fédération Workload Identity vous permet de créer une relation d'approbation unidirectionnelle entre un projet Cloud et un fournisseur d'identité externe. Une fois que vous avez établi cette relation d'approbation, vous pouvez échanger les identifiants obtenus du fournisseur d'identité externe vers un jeton STS (Security Token Service). Vous pouvez ensuite utiliser ce jeton STS pour accéder à un compte de service ou emprunter son identité.

Les jetons STS diffèrent des jetons d'accès, car ils ne correspondent pas à une identité Google spécifique. En outre, les jetons STS ne correspondent pas nécessairement à une identité spécifique du fournisseur d'identité externe. À la place, un jeton STS représente un ensemble d'attributs. En fonction de ces attributs, ils peuvent correspondre à une ou plusieurs identités du fournisseur d'identité externe.

Si les attributs représentés par un jeton STS sont ambigus ou utilisés de manière incorrecte, ils pourraient permettre aux individus malveillants d'usurper leur propre identité. La section suivante décrit les bonnes pratiques à appliquer pour vous protéger contre ces menaces de spoofing.

Ne pas autoriser la modification des mappages d'attributs

La fédération Workload Identity utilise des mappages d'attributs pour sélectionner les attributs fournis par le fournisseur d'identité externe qui doivent être intégrés à un jeton STS et leur traduction. La configuration des mappages d'attributs est une étape clé pour configurer la relation d'approbation entre le fournisseur d'identité externe et Google Cloud.

Les mappages d'attributs sont également essentiels à la sécurité avec l'utilisation de la fédération Workload Identity : si vous avez autorisé un compte principal fédéré ou un ensemble de comptes principaux à usurper l'identité d'un compte de service, puis modifier le mappage d'attributs, vous pouvez modifier quels utilisateurs ont accès au compte de service.

Pour modifier les mappages d'attributs, vous devez disposer de l'autorisation iam.googleapis.com/workloadIdentityPoolProviders.update. Les rôles contenant cette autorisation sont les suivants :

  • Propriétaire (roles/owner)
  • Rôle IAM d'administrateur de pools Workload Identity (roles/iam.workloadIdentityPoolAdmin)

Si un utilisateur malveillant est autorisé à modifier les mappages d'attributs, il peut éventuellement modifier les règles de mappage de manière à usurper son identité et à accéder à un compte de service. Pour éviter ces modifications malveillantes, assurez-vous que seuls quelques utilisateurs administratifs sont autorisés à modifier les mappages d'attributs.

Envisagez de créer un projet Cloud dédié pour gérer les pools Workload Identity afin de limiter le risque que des utilisateurs se voient attribuer accidentellement l'un de ces rôles à un niveau supérieur de la hiérarchie des ressources.

Ne pas se fier aux attributs non stables ou fiables

Lorsque vous utilisez la fédération Workload Identity, vous faites confiance à un fournisseur d'identité externe pour authentifier les utilisateurs et pour transmettre des informations précises à l'utilisateur authentifié à Google Cloud.

Un fournisseur d'identité utilise des attributs pour communiquer des informations sur les utilisateurs authentifiés. Bien que certains de ces attributs soient généralement garantis comme fiables, d'autres peuvent ne pas l'être : par exemple, un fournisseur d'identité externe peut intégrer un nom d'utilisateur et un ID utilisateur dans un jeton OpenID Connect. Ces deux attributs identifient de manière unique un utilisateur et peuvent sembler interchangeables. Toutefois, le fournisseur d'identité externe peut permettre aux utilisateurs de modifier leur nom d'utilisateur tout en garantissant la stabilité et la fiabilité de leur ID utilisateur.

Si vos mappages d'attributs reposent sur des attributs qui ne sont pas stables ou fiables, alors un utilisateur malveillant pourrait alors usurper l'identité de l'utilisateur en modifiant son profil utilisateur dans le fournisseur d'identité externe. Par exemple, il peut remplacer son nom d'utilisateur par celui d'un utilisateur récemment supprimé du fournisseur d'identité externe, mais ayant encore accès à un compte de service sur Google Cloud.

Pour éviter de telles attaques, assurez-vous que vos mappages d'attributs ne se basent que sur des attributs garantis comme stables et autorisés par le fournisseur d'identité externe.

Se protéger contre les menaces liées à la 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 IAM de la ressource. Tout comme la ressource elle-même, la stratégie IAM fait partie de l'autre projet Cloud et sa visibilité est également contrôlée par cet autre projet.

L'affichage des stratégies IAM 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 autorisé à afficher une stratégie IAM 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 IAM 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.

Se protéger 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. Vous pouvez également intégrer les informations dans l'en-tête User-Agent afin qu'elles soient enregistrées dans les journaux Cloud Audit.

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.

Étape suivante