Bonnes pratiques pour gérer les clés de compte de service

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

Contrairement aux utilisateurs standards, les comptes de service n'ont pas de mot de passe. À la place, les comptes de service utilisent des paires de clés RSA pour l'authentification : si vous connaissez la clé privée d'une paire de clés de compte de service, vous pouvez l'utiliser pour créer un jeton de support JWT et vous servir de celui-ci pour demander un jeton d'accès. Le jeton d'accès obtenu reflète l'identité du compte de service et vous pouvez l'utiliser pour interagir avec les API Google Cloud au nom du compte de service.

Comme la clé privée vous permet de vous authentifier en tant que compte de service, l'accès à la clé privée revient à connaître le mot de passe d'un utilisateur. La clé privée est appelée clé de compte de service. Les paires de clés utilisées par les comptes de service appartiennent à deux catégories : gérées par Google et gérées par l'utilisateur.

Les clés de compte de service peuvent présenter un risque pour la sécurité si elles ne sont pas gérées avec soin. Voici les principales menaces liées aux clés de compte de service :

  • Fuite d'identifiants : les clés de compte de service peuvent se retrouver par inadvertance dans des endroits où elles ne sont pas censées être stockées. Un acteur malintentionné peut utiliser une fuite de clé de compte de service pour s'authentifier et s'implanter dans votre environnement.
  • Élévation des privilèges : si un acteur malintentionné accède à une clé de compte de service mal sécurisée, il peut l'utiliser pour élever ses privilèges.
  • Divulgation d'informations : les clés de compte de service peuvent divulguer par inadvertance des métadonnées confidentielles.
  • Non-répudiation : en s'authentifiant à l'aide d'une clé de compte de service et en laissant le compte de service effectuer des opérations en son nom, un acteur malveillant peut dissimuler son identité et ses actions.

Le meilleur moyen d'atténuer ces menaces est d'éviter les clés de compte de service gérées par l'utilisateur et d'utiliser d'autres méthodes pour authentifier les comptes de service dans la mesure du possible. Vous pouvez également utiliser les conditions IAM et les VPC Service Controls pour limiter les ressources potentiellement accessibles par un compte de service compromis.

Lorsque l'utilisation d'autres méthodes d'authentification n'est pas possible, consultez les bonnes pratiques présentées dans ce guide concernant la gestion, l'utilisation et la sécurisation des clés de compte de service.

Protection contre les fuites d'identifiants

Comme les noms d'utilisateur et les mots de passe, les clés de compte de service sont une forme d'identifiant. Si un utilisateur peut accéder à une clé de compte de service valide, il peut l'utiliser pour s'authentifier et accéder aux ressources auxquelles le compte de service correspondant a accès.

Pour les utilisateurs mal intentionnés, les clés de compte de service peuvent s'avérer encore plus utiles qu'un mot de passe divulgué : toute tentative de connexion à l'aide d'un mot de passe divulgué a peu de chances de réussir si le compte utilisateur a été configuré pour utiliser la validation en deux étapes et les questions d'authentification à la connexion. En revanche, l'authentification à l'aide d'une clé de compte de service divulguée risque de réussir, car les comptes de service ne sont soumis à aucune vérification de connexion supplémentaire.

Les acteurs malveillants peuvent rechercher des clés de compte de service à différents endroits, par exemple :

  • Dépôts de code source de projets Open Source
  • Buckets Cloud Storage publics
  • Vidages de données publiques de services compromis

En plus des emplacements publics, les acteurs malintentionnés peuvent rechercher des clés de compte de service dans des emplacements privés dont la sécurité a été compromise. Voici quelques exemples :

  • Boîtes de messagerie électronique
  • Partages de fichiers
  • Stockage des sauvegardes
  • Répertoires du système de fichiers temporaires

Un moyen efficace de réduire le risque de fuite des clés de compte de service consiste à réduire le nombre de clés en circulation et à décourager la création de nouvelles clés. Dans les sections suivantes, nous allons voir comment limiter le nombre de clés de compte de service en fonctionnement et quelles autres mesures peuvent vous aider à limiter les risques de fuite de comptes de service.

Fournir des alternatives à la création de clés de compte de service

Il peut être difficile de réduire le nombre de clés de compte de service en circulation si les utilisateurs de votre organisation trouvent plus facile de créer des clés de compte de service que d'utiliser des alternatives plus sécurisées.

Pour éviter que les clés de compte de service ne soient créées par commodité, assurez-vous que les utilisateurs connaissent les alternatives à l'utilisation des clés de compte de service et qu'ils peuvent exploiter ces autres méthodes au besoin :

Après vous être assuré que les utilisateurs peuvent authentifier les comptes de service à l'aide d'autres méthodes, utilisez des contraintes de règle d'administration pour limiter l'utilisation des clés de compte de service aux projets sélectionnés.

Limiter les projets pouvant créer des clés de compte de service à l'aide de contraintes de règle d'administration

Il existe plusieurs façons de contourner la nécessité de créer des clés de compte de service, par exemple associer un compte de service à une ressource, utiliser Workload Identity ou la fédération d'identité de charge de travail. Compte tenu de ces alternatives, il est préférable de considérer l'utilisation des clés de compte de service comme une exception plutôt que comme la norme.

Pour éviter tout recours inutile aux clés de compte de service, utilisez des contraintes liées aux règles d'administration :

La modification des contraintes de règle d'administration nécessite l'autorisation orgpolicy.policy.set. Comme ni le rôle de propriétaire (roles/owner), ni le rôle d'éditeur (roles/editor) n'incluent cette autorisation, les contraintes peuvent également être efficaces dans des environnements hors production où certains comptes principaux peuvent disposer d'un accès Propriétaire ou Éditeur aux projets.

Ne pas laisser les clés de compte de service dans des emplacements temporaires

Lorsque vous créez une clé de compte de service à l'aide de Google Cloud Console, la plupart des navigateurs téléchargent immédiatement la nouvelle clé et l'enregistrent dans le dossier de téléchargement de votre ordinateur. Vous devez déplacer immédiatement la clé à l'endroit où vous souhaitez la stocker. Assurez-vous de ne pas laisser par erreur une copie dans le dossier de téléchargement ou dans la corbeille de votre ordinateur.

Vous pouvez réduire le risque de laisser accidentellement des copies de clés de compte de service dans des emplacements temporaires à l'aide de Google Cloud CLI : la commande gcloud iam service-accounts keys create vous permet d'écrire le fichier de clé du compte de service directement à l'emplacement où vous en avez besoin. En outre, sur la plupart des systèmes d'exploitation, la CLI gcloud ajuste automatiquement les autorisations de fichiers afin que le fichier ne soit accessible que par vous.

Ne pas transmettre de clés de compte de service entre utilisateurs

Lorsque vous déployez une application nécessitant une clé de compte de service, vous n'êtes peut-être pas autorisé à créer vous-même une clé de compte de service. À la place, vous devrez peut-être demander à une autre personne de créer une clé de compte de service pour vous.

Dans les cas où plusieurs utilisateurs sont impliqués dans la création et le déploiement d'une clé de compte de service, le risque augmente de conserver les copies de la clé dans des boîtes aux lettres, des historiques de chat et d'autres emplacements. Chaque fois qu'un transfert entre utilisateurs est nécessaire, il peut être plus sûr de télécharger une clé de compte de service :

  1. Lorsque l'utilisateur déploie l'application, créez un certificat autosigné qui utilise une paire de clés RSA 2048 bits sur la machine cible. Pour créer le certificat, vous pouvez utiliser openssl, certutil, New-SelfSignedCertificate ou d'autres outils du système d'exploitation.
  2. Transmettez le fichier de certificat à l'utilisateur autorisé à importer le certificat tout en conservant la clé privée sur la machine cible. Lorsque vous transmettez le certificat, assurez-vous qu'il ne peut pas être remplacé ni altéré, mais vous n'avez pas besoin de le garder confidentiel.
  3. En tant qu'utilisateur disposant des autorisations nécessaires pour gérer les clés de compte de service, importez le certificat afin de l'associer à un compte de service.

Ce processus vous permet d'éviter de transmettre la clé privée et d'échanger uniquement des informations publiques entre les utilisateurs.

Ne pas envoyer de clés de compte de service aux dépôts de code source

Les clés de compte de service sont des identifiants. Elles doivent être protégées contre les accès non autorisés. Si vous envoyez une clé de compte de service à un dépôt de code source, vous augmentez le risque que des utilisateurs non autorisés et des acteurs malintentionnés puissent y accéder :

  • Les acteurs malintentionnés peuvent analyser le code source des dépôts sources publics pour détecter les fuites de clés.
  • À l'avenir, vous pourrez décider de transformer un dépôt source privé en dépôt public sans avoir à vérifier les clés au préalable.
  • D'autres membres de l'équipe peuvent stocker des copies du code source sur leur poste de travail.

Lorsque vous travaillez sur du code qui utilise une clé de compte de service, stockez toujours cette clé séparément du code source afin de réduire le risque de l'envoyer accidentellement au dépôt source. Dans de nombreux cas, vous pouvez réduire davantage ce risque en vous abstenant d'utiliser des clés de compte de service pendant le développement et en utilisant vos identifiants personnels au lieu des clés de compte de service à la place.

De plus, configurez votre système de contrôle source afin qu'il détecte l'envoi accidentel de clés de compte de service :

Ne pas intégrer les clés de compte de service dans les binaires du programme

Les clés de compte de service sont des chaînes qui correspondent à un certain modèle et peuvent être identifiées même si elles sont intégrées dans d'autres fichiers ou binaires. Si un acteur malveillant a accès au binaire, il peut extraire toutes les clés de compte de service intégrées au binaire.

Les fichiers binaires des programmes côté serveur peuvent être hébergés dans des dépôts d'artefacts ou copiés sur des postes de travail de développement à des fins de débogage. Le fait de séparer les clés de compte de service des binaires du programme permet de garantir qu'un utilisateur pouvant accéder au binaire n'a pas implicitement accès aux identifiants du compte de service.

  • Pour les applications côté client telles que les outils, les programmes de bureau ou les applications mobiles, n'utilisez pas de comptes de service. Autorisez plutôt les utilisateurs à s'authentifier avec leurs propres identifiants en utilisant le flux d'autorisation OAuth.
  • Pour les applications côté serveur, n'intégrez pas les clés de compte de service dans le binaire. Au lieu de cela, gardez les clés séparées du binaire d'application.

Identifier les clés de compte de service inutilisées à l'aide d'insights et de métriques

Pour réduire le nombre de clés de compte de service valides en circulation, il est préférable de les désactiver dès qu'elles ne sont plus nécessaires, puis de les supprimer lorsque vous êtes certain de ne plus en avoir besoin. Si vous ne savez pas si une clé est toujours active, vous pouvez utiliser les insights sur les comptes de service et les métriques d'authentification :

Comme les comptes de service appartiennent à un projet Google Cloud, les insights et les métriques doivent être suivis individuellement pour chaque projet.

Procéder à la rotation des clés de compte de service pour réduire le risque de sécurité causé par les clés piratées

Bien que vous puissiez réduire la probabilité de fuite accidentelle d'une clé de compte de service, il peut être difficile d'éliminer complètement le risque.

En cas de fuite d'une clé, les acteurs mal intentionnés peuvent ne pas la trouver immédiatement ; plusieurs jours ou semaines peuvent s'écouler avant qu'une personne ne la trouve. Vous pouvez profiter de ce délai en invalidant régulièrement vos clés de compte de service et en les remplaçant par de nouvelles clés. Plus vous alternez souvent les clés du compte de service, moins il y a de risques qu'une clé de compte de service divulguée soit toujours valide lorsqu'un acteur malintentionné la trouve.

Pour effectuer une rotation des clés, vous pouvez suivre un modèle de type Push ou Pull :

  • Dans un modèle de type Push, vous utilisez un outil ou un système centralisé qui crée régulièrement des clés de compte de service et les transmet aux applications individuelles pour remplacer les clés existantes. Ensuite, l'outil supprime les clés de compte de service obsolètes.

    Dans ce modèle, seul l'outil central nécessite des autorisations pour créer ou importer des clés de compte de service, mais ces autorisations sont requises pour tous les comptes de service qu'il gère.

  • Dans un modèle de type Pull, chaque application gère elle-même la rotation des clés. L'application utilise périodiquement l'API Cloud IAM pour créer ou importer une nouvelle clé de compte de service lors de son authentification avec sa clé existante. Après avoir obtenu une nouvelle clé de compte de service, l'application supprime sa clé précédente.

    Dans ce modèle, le compte de service de chaque application doit être autorisé à créer ou à importer de nouvelles clés de compte de service, mais uniquement pour lui-même.

Si vous avez généré vous-même la paire de clés publique/privée, stocké la clé privée dans un module de sécurité matérielle (HSM) et importé la clé publique dans Google, vous n'aurez peut-être pas besoin pour effectuer une rotation de la clé selon un calendrier régulier. Au lieu de cela, vous pouvez alterner la clé si vous pensez qu'elle a peut-être été compromise.

Utiliser des clés importées pour laisser les clés expirer automatiquement

Les clés de compte de service que vous créez et téléchargez à partir d'IAM n'ont pas de date d'expiration et restent valides jusqu'à ce que vous les supprimiez.

Vous pouvez limiter la validité des clés de compte de service en important une clé de compte de service et en spécifiant une date d'expiration dans le fichier de certificat X.509. Une fois la date d'expiration passée, la clé ne peut plus être utilisée pour l'authentification, mais elle reste associée au compte de service jusqu'à ce que vous la supprimiez.

Limiter la validité des clés de compte de service contribue à limiter le risque de sécurité et peut servir de prévention des défaillances en cas d'échec de la rotation des clés. En revanche, la limitation de la validité des clés augmente le risque de défaillance d'une application si une clé qui n'a pas été renouvelée à temps.

Protection contre l'élévation des privilèges

L'utilisation de clés de compte de service peut vous exposer à des attaques par élévation des privilèges si les clés sont moins sécurisées que les ressources auxquelles elles donnent accès.

Par exemple, supposons qu'un acteur malintentionné soit déjà implanté dans votre environnement et tente maintenant d'accéder à certaines ressources Google Cloud. Même s'il ne dispose pas encore des autorisations d'accès à ces ressources, ses droits peuvent être suffisants pour lui permettre d'accéder à une clé de compte de service stockée sur une VM, un partage de fichiers ou un autre emplacement moins sécurisé. En s'authentifiant à l'aide de la clé de compte de service, l'acteur malintentionné peut emprunter l'identité du compte de service. Le compte de service peut ainsi lui permettre d'accéder aux ressources auxquelles il n'avait pas accès auparavant, entraînant ainsi l'élévation de ses privilèges.

Étant donné qu'une clé de compte de service accorde indirectement l'accès aux ressources sur Google Cloud, vous devez considérer la clé elle-même comme aussi importante et devant être autant protégée que les ressources elles-mêmes.

Les sections suivantes décrivent les bonnes pratiques pour protéger les clés de compte de service et réduire le risque d'accès non autorisé et d'élévation des privilèges.

Éviter de stocker les clés sur un système de fichiers

Les clés de compte de service créées à l'aide de Google Cloud Console ou de la CLI gcloud sont des fichiers JSON. Vous pouvez copier ces fichiers sur le système de fichiers de la machine où ils sont nécessaires. Toutefois, le stockage de clés de compte de service sous forme de fichiers sur un système de fichiers peut exposer à plusieurs risques, en particulier les suivants :

  • Certains systèmes de fichiers tels que NTFS utilisent les autorisations héritées par défaut. À moins d'être désactivée, une autorisation ajoutée à un dossier parent peut rendre par inadvertance un fichier de clé plus accessible et visible par les utilisateurs non autorisés.
  • Dans un environnement virtualisé, des acteurs malintentionnés pourraient compromettre la sécurité du système de fichiers en accédant au disque virtuel sous-jacent.
  • Souvent, les modifications apportées aux autorisations et à l'accès au système de fichiers ne sont pas consignées. Si les autorisations de fichiers sont modifiées par inadvertance et que la clé devient visible pour les utilisateurs non autorisés, il peut être difficile d'analyser quand et par qui ces modifications ont été apportées.
  • Les fichiers peuvent être facilement copiés et, par conséquent, exfiltrés si un acteur malintentionné y accède.

Dans la mesure du possible, évitez de stocker les clés de compte de service sur un système de fichiers. Si vous ne pouvez pas éviter de stocker des clés sur le disque, veillez à restreindre l'accès au fichier de clé, à configurer l'audit d'accès aux fichiers et à chiffrer le disque sous-jacent.

Utiliser un module HSM ou TPM pour stocker des clés

Lorsque vous créez une clé de compte de service à l'aide de Google Cloud Console ou de la CLI gcloud, la clé privée est générée par Google Cloud, puis vous est présentée. De nombreux risques de sécurité associés aux clés de compte de service résultent du fait que la clé privée est, temporairement ou définitivement, disponible en clair et peut donc être difficile à protéger.

Au lieu de laisser Google Cloud générer une paire de clés, vous pouvez utiliser un module de sécurité matérielle (HSM) ou un module Trusted Platform (TPM) pour créer et gérer des clés :

  1. Utilisez un HSM ou un TPM pour générer une paire de clés RSA.
  2. Utilisez la paire de clés pour créer un certificat autosigné.
  3. Importez le certificat en tant que clé de compte de service.
  4. Autorisez l'application à utiliser l'API de signature HSM ou TPM pour signer le jeton JWT afin d'authentifier le compte de service.

Les modules HSM ou TPM permettent d'utiliser une clé privée sans la révéler en clair. L'utilisation d'un module HSM ou TPM pour gérer les clés de compte de service vous permet donc d'appliquer le contrôle des accès tout en limitant le risque de copie des clés vers d'autres systèmes.

Certaines plates-formes fournissent des extraits qui vous permettent d'utiliser un TPM sans interagir directement avec celui-ci. Par exemple, Windows vous permet de gérer les clés protégées par un module TPM à l'aide de l'API CryptoNG en combinaison avec l'identifiant Microsoft Platform Crypto Provider.

Les clés de compte de service gérées par un TPM sont uniques pour une machine physique ou virtuelle. Vous pouvez toujours autoriser plusieurs machines à partager un compte de service en associant la clé de chaque machine à un compte de service commun.

Utiliser un magasin de clés basé sur logiciel

Dans les situations où l'utilisation d'un magasin de clés matérielles n'est pas possible, utilisez un magasin de clés basé sur logiciel pour gérer les clés de compte de service. À l'instar des options matérielles, un magasin de clés basé sur logiciel permet aux utilisateurs ou aux applications d'utiliser des clés de compte de service sans révéler la clé privée. Les solutions de magasin de clés basé sur logiciel peuvent vous aider à contrôler l'accès aux clés de manière précise et à garantir la journalisation de chaque accès de clé.

La sécurité d'un magasin de clés basé sur logiciel dépend généralement du type de protection de sa clé principale. Avant d'utiliser un magasin de clés basé sur logiciel, assurez-vous de vérifier les points suivants :

  • la manière dont la clé principale est sécurisée au repos ;
  • le processus de desscellement et les personnes habilitées à le lancer ;
  • comment les clés sont protégées contre l'extraction de mémoire ;
  • la manière dont le magasin de clés est protégé contre les menaces si un acteur malintentionné obtient un accès à l'interface système ou un accès hyperviseur au système sous-jacent.

Ne pas stocker de clés dans Secret Manager ni dans d'autres magasins de secrets basés sur le cloud.

Google Cloud, ainsi que d'autres fournisseurs de cloud, fournissent des magasins de clés gérés qui vous permettent de gérer différents types de secrets. Exemples : Secret Manager, Azure KeyVault ou AWS Secret Manager. Si vous stockez une clé de compte de service dans l'un de ces magasins de clés, vous devez utiliser le système IAM du fournisseur cloud pour contrôler l'accès au secret. Au lieu d'utiliser IAM pour contrôler l'accès à un secret, qui accorde ensuite un accès aux ressources sur Google Cloud, utilisez la fédération d'identité de charge de travail pour gérer l'accès sans créer de clé de compte de service.

Ne pas utiliser le rôle d'éditeur dans les projets qui autorisent la création ou l'importation de clés de compte de service

L'une des principales différences entre les rôles de base Éditeur (roles/editor) et Propriétaire (roles/owner) est que le rôle Éditeur ne vous permet pas de modifier les stratégies ou les rôles IAM. Par conséquent, vous ne pouvez pas facilement étendre votre propre accès ou accorder à d'autres utilisateurs l'accès aux ressources du projet.

Les limites du rôle d'éditeur peuvent être compromises si un projet contient des comptes de service. Étant donné que les rôles d'éditeur accordent l'autorisation de créer ou d'importer des clés de compte de service, un acteur malintentionné peut créer des clés pour des comptes de service existants et utiliser ces clés pour augmenter leur propre accès ou les transférer à d'autres utilisateurs pour obtenir l'accès aux ressources du projet.

Au lieu d'utiliser le rôle d'éditeur ou tout autre rôle de base, il est préférable d'utiliser les rôles prédéfinis les plus précis ou de créer des rôles personnalisés qui n'accordent que les autorisations nécessaires.

Si vous devez utiliser le rôle d'éditeur, désactivez l'importation des clés de compte de service et la création de clé à l'aide de contraintes de règle d'administration pour vous assurer que Le rôle d'éditeur ne peut pas être utilisé de manière abusive par élévation des privilèges.

Éviter d'utiliser des clés de compte de service pour la délégation au niveau du domaine

La délégation au niveau du domaine vous permet d'emprunter l'identité d'un utilisateur afin de pouvoir accéder aux données d'un utilisateur sans autorisation manuelle de sa part. Bien que les exemples illustrant l'utilisation de la délégation au niveau du domaine suggèrent généralement d'utiliser des clés de compte de service, celles-ci ne sont pas nécessaires pour effectuer une délégation au niveau du domaine.

Lorsque vous utilisez la délégation au niveau du domaine, évitez les clés de compte de service et utilisez plutôt l'API signJwt :

  1. Authentifiez un compte de service à l'aide d'un compte de service associé, de Workload Identity ou d'une fédération d'identité de charge de travail.
  2. Construisez un jeton JWT et utilisez la revendication sub pour spécifier l'adresse e-mail de l'utilisateur pour lequel vous demandez un accès délégué.
  3. Utilisez l'API signJwt pour signer le jeton JWT.
  4. Transmettez le JWT signé à la ressource de jeton OAuth2 pour obtenir un jeton d'accès.

En suivant cette approche, vous n'avez pas à gérer une clé de compte de service, ce qui permet une configuration plus sécurisée.

Se protéger contre les menaces liées à la divulgation d'informations

Éviter de divulguer des informations confidentielles dans les certificats X.509 importés

Pour chaque clé de compte de service, IAM vous permet de télécharger un certificat X.509 à partir du point de terminaison https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL. Ce point de terminaison est public et ne nécessite pas d'authentification.

Pour les clés gérées par Google et les clés gérées par l'utilisateur que vous avez créées à l'aide de Google Cloud Console ou de la CLI gcloud, les certificats X.509 sont créés automatiquement et ne contiennent que des métadonnées de base, telles que l'adresse e-mail et la date d'expiration.

Pour les clés de compte de service importées, le certificat X.509 fourni par le point de terminaison public est le même que celui que vous avez importé. Si le certificat que vous avez importé contient des attributs facultatifs (tels que des informations d'adresse ou d'emplacement intégrées dans le nom commun), ces informations deviennent également accessibles au public. Un acteur malintentionné pourrait utiliser ces informations pour en savoir plus sur votre environnement.

Pour éviter de divulguer des informations confidentielles, n'ajoutez aucun attribut facultatif aux certificats X.509 importés, et utilisez un attribut Subject générique.

Se protéger contre les menaces de non-répudiation

Lorsque vous remarquez une activité suspecte affectant vos ressources Google Cloud et que vous souhaitez analyser ses origines, vous avez besoin de données qui vous permettent de reconstruire la chaîne d'événements ayant entraîné l'activité suspecte. La source principale de données permettant d'effectuer cette analyse est généralement un journal d'audit.

L'analyse des journaux d'audit peut s'avérer plus difficile lorsque des comptes de service sont impliqués : si une activité a été initiée par un compte de service, l'entrée de journal contient l'adresse e-mail du compte de service, mais vous devez également savoir quel utilisateur ou application utilisait le compte de service à ce moment-là.

Les sections suivantes présentent les bonnes pratiques à suivre pour utiliser les clés de compte de service de manière à en suivre l'utilisation.

Utiliser un compte de service dédié pour chaque application

Tous les enregistrements du journal d'audit contiennent un champ principalEmail qui identifie le compte principal qui a initié l'activité. Si vous partagez une clé de compte de service sur plusieurs applications, il peut être difficile d'identifier l'application ayant effectué une activité, car les enregistrements du journal d'audit contiennent la même valeur principalEmail.

Au lieu de partager une clé entre plusieurs applications, créez un compte de service dédié pour chaque application. De cette façon, le champ principalEmail vous permet d'identifier l'application associée à un compte de service, ce qui peut vous aider à reconstruire la chaîne d'événements ayant entraîné une activité suspecte.

Utiliser une clé dédiée pour chaque machine exécutant une application

Si vous exécutez plusieurs copies de la même application sur plusieurs machines, le champ principalEmail peut vous permettre d'identifier l'application, mais pas la machine d'où provient une activité particulière.

Pour vous aider à affiner les sources potentielles d'activité suspecte, créez des clés individuelles pour chaque copie de l'application. De cette façon, vous pouvez utiliser le champ serviceAccountKeyName que de nombreux services ajoutent aux enregistrements de journal d'audit pour distinguer la machine d'origine d'une activité.

Étapes suivantes