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

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. Dans la mesure du possible, vous devez choisir une alternative plus sécurisée pour l'authentification. 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.

Si vous ne pouvez pas utiliser d'alternatives plus sécurisées aux clés de compte de service, ce guide présente les bonnes pratiques à suivre pour gérer, utiliser et sécuriser les 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.

Bonnes pratiques

Fournissez des alternatives à la création de clés de compte de service.
Utilisez des contraintes de règle d'administration pour limiter les projets pouvant créer des clés de compte de service.
Ne laissez pas les clés de compte de service dans des emplacements temporaires.
Ne transmettez pas de clés de compte de service entre les utilisateurs.
N'envoyez de clés de compte de service aux dépôts de code source.
N'intégrez pas les clés de compte de service dans les binaires du programme.
Utilisez des informations et des métriques pour identifier les clés de compte de service inutilisées.
Alternez les clés de compte de service pour réduire le risque de sécurité causé par les clés piratées.
Utilisez des délais d'expiration pour laisser les clés expirer automatiquement.
Utilisez des contraintes de règle d'administration pour désactiver automatiquement les clés divulguées.

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

Assurez-vous que les utilisateurs de votre organisation connaissent les alternatives et peuvent justifier les coûts supplémentaires liés à l'utilisation d'une clé de compte de service en termes de risques et de gestion :

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

Compte tenu des alternatives plus sécurisées aux clés de compte de service, 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.

La rotation des clés consiste à remplacer vos clés existantes par de nouvelles clés, puis à invalider les clés remplacées. Nous vous recommandons d'alterner régulièrement toutes les clés que vous gérez, y compris vos clés de compte de service.

La rotation des clés de compte de service permet de réduire le risque lié aux fuites ou au vol des clés. En cas de fuite d'une clé, l'identification de la clé par les acteurs mal intentionnés peut prendre plusieurs jours, voire plusieurs semaines. Si vous effectuez régulièrement une rotation des clés de votre compte de service, il est plus probable que les clés compromises ne soient pas valides au moment où un acteur malintentionné les récupère.

Disposer d'un processus établi pour la rotation des clés de compte de service vous permet également d'agir rapidement si vous pensez qu'une clé de compte de service a été compromise.

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 délais d'expiration pour laisser les clés expirer automatiquement

Par défaut, les clés de compte de service que vous créez et téléchargez à partir d'IAM n'ont pas de délai d'expiration et restent valides jusqu'à ce que vous les supprimiez. La définition d'un délai d'expiration pour les clés de compte de service peut limiter le risque de sécurité en réduisant la durée de vie des identifiants persistants. Cependant, il existe d'autres risques associés au paramétrage des délais d'expiration. Par exemple, la définition d'un délai d'expiration peut entraîner l'échec des charges de travail lorsque leurs clés expirent.

Utilisez des délais d'expiration lorsque vous avez besoin d'un accès temporaire à un système nécessitant une clé de compte de service. Par exemple, utilisez les délais d'expiration lorsque vous effectuez les opérations suivantes :

  • Développement du code dans un environnement hors production pour une application qui ne peut s'authentifier qu'avec des clés de compte de service
  • Utiliser un outil tiers ne pouvant s'authentifier qu'avec les clés de compte de service

Évitez d'utiliser les délais d'expiration dans les scénarios suivants :

  • Charges de travail de production. En production, une clé de compte de service arrivée à expiration peut entraîner une panne accidentelle. Utilisez plutôt des clés qui n'expirent pas et gérez leur cycle de vie avec la rotation des clés.
  • Charges de travail hors production nécessitant un accès permanent, telles qu'un pipeline d'intégration continue (CI).
  • Systèmes de rotation des clés qui empêchent l'utilisation d'une clé après un certain temps. Pour en savoir plus sur les stratégies de rotation des clés recommandées, consultez la page Rotation des clés de compte de service.

Pour limiter la validité des clés de compte de service, vous pouvez configurer un délai d'expiration pour les nouvelles clés de votre projet, dossier ou organisation. Le délai d'expiration ne s'applique pas aux clés existantes.

Vous pouvez également importer une clé de compte de service et spécifier une date Valid To (date d'expiration) dans le fichier de certificat X.509. Une fois la date d'expiration écoulée, la clé ne peut plus être utilisée pour l'authentification. Toutefois, elle reste associée au compte de service jusqu'à ce que vous la supprimiez.

Désactiver automatiquement les clés divulguées à l'aide de contraintes de règles d'administration

Même si vous suivez toutes les bonnes pratiques concernant les clés de compte de service, il est possible que vos clés de compte de service soient divulguées.

Pour vous aider à gérer les identifiants piratés, assurez-vous que la contrainte de réponse à l'exposition de clés du compte de service est définie sur DISABLE_KEY. Si vous définissez la contrainte sur cette valeur, Google Cloud désactivera automatiquement toutes les clés divulguées qu'il détecte.

Si une clé est désactivée en raison d'une fuite, les champs suivants sont ajoutés aux métadonnées de la clé:

  • "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED" : indique que la clé a été désactivée, car elle était exposée.
  • "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED" : indique que la clé a été exposée publiquement. Cette valeur persiste même si vous réactivez la clé.
  • "extended_status_message": "LINK_TO_EXPOSURE": si elles sont disponibles, les métadonnées contiennent un lien vers l'emplacement où la clé a été détectée, que vous pouvez utiliser pour la corriger.

Ces clés peuvent être réactivées si nécessaire pour atténuer une panne. Toutefois, nous vous recommandons de les désactiver à nouveau dès que possible, car les clés exposées publiquement présentent un risque de sécurité, même si l'exposition initiale est supprimée.

Pour en savoir plus sur les autres bonnes pratiques de gestion des identifiants compromis, consultez la page Gestion des identifiants Google Cloud dont la sécurité a été compromise.

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.

Bonnes pratiques

Éviter de stocker des clés sur un système de fichiers
Utiliser un HSM ou un TPM pour stocker des clés
Utiliser un magasin de clés basé sur logiciel
Ne pas stocker de clés dans Secret Manager ni dans d'autres magasins de secrets basés dans le cloud
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
Éviter d'utiliser des clés de compte de service pour la délégation au niveau du domaine

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

Nous vous déconseillons d'utiliser Secret Manager de Google Cloud pour stocker et alterner les clés de compte de service. En effet, pour accéder aux secrets de Secret Manager, votre application doit disposer d'une identité que Google Cloud peut reconnaître. Si votre application dispose déjà d'une identité que Google Cloud peut reconnaître, elle peut s'authentifier auprès de Google Cloud à l'aide de cette identité au lieu d'utiliser une clé de compte de service.

Le même concept s'applique à d'autres services de gestion de secrets basés sur le cloud, tels qu'Azure KeyVault et AWS Secret Manager. Si une application dispose déjà d'une identité que ces fournisseurs cloud peuvent reconnaître, elle pourra s'authentifier auprès de Google Cloud au lieu d'utiliser une 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 Federation for GKE 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

Bonnes pratiques

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

É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 la console Google Cloud ou de gcloud CLI, 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.

Bonnes pratiques

Utilisez un compte de service dédié pour chaque application.
Utilisez une clé dédiée pour chaque machine exécutant une application.

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