Migrer depuis un mécanisme d'authentification basé sur des clés de compte de service

Les clés de compte de service sont couramment utilisées pour l'authentification auprès des services Google Cloud. Toutefois, elles peuvent également présenter un risque de sécurité en cas de gestion incorrecte et augmenter votre vulnérabilité face à des menaces telles que les fuites d'identifiants, l'élévation des privilèges, la divulgation d'informations et la non-répudiation.

Dans de nombreux cas, vous pouvez vous authentifier avec des alternatives plus sécurisées aux clés de compte de service. Ce guide vous aide à passer d'un mécanisme d'authentification principal basé sur des clés de compte de service à des alternatives plus sécurisées, en autorisant des exceptions occasionnelles pour les cas où les clés de compte de service sont vraiment nécessaires.

Ce document est destiné aux administrateurs de sécurité qui souhaitent améliorer leur stratégie de sécurité en réduisant l'utilisation des clés de compte de service au profit de mécanismes d'authentification plus sécurisés. Ces administrateurs de sécurité peuvent être chargés de la sécurité des charges de travail de production existantes, des workflows de développement et des processus internes qui utilisent des clés de compte de service.

Présentation

La suppression de clés de compte de service sur des charges de travail existantes nécessite une planification minutieuse afin d'éviter toute interruption accidentelle. Le plan de migration suivant est conçu pour vous permettre d'appliquer des contrôles centralisés tout en minimisant les perturbations pour les développeurs.

Ce plan de migration comprend trois phases :

  • Évaluation : au cours de cette phase, vous évaluez votre environnement existant pour comprendre où se trouvent les clés de compte de service et si celles-ci sont utilisées.
  • Planification : au cours de cette phase, vous décidez des contrôles que vous allez mettre en place et vous informez les personnes concernées du plan de migration.
  • Déploiement : au cours de cette phase, vous commencez à refactoriser les charges de travail pour qu'elles s'authentifient avec des alternatives plus sécurisées que les clés de compte de service. Vous développez également des capacité supplémentaires pour surveiller votre environnement en continu et limiter les risques futurs.

Évaluer l'utilisation des clés de compte de service

Au cours de cette phase, vous évaluez votre environnement existant pour comprendre où se trouvent les clés de compte de service et si celles-ci sont utilisées.

Les sections suivantes décrivent les données que vous pouvez collecter pour mieux comprendre comment les clés de compte de service sont utilisées dans votre organisation.

Collecter des données sur l'utilisation des clés

Commencez par identifier l'emplacement des clés de compte de service et leur utilisation.

Google Cloud fournit des outils permettant de comprendre l'utilisation des comptes de service. Ces outils vous aident à déterminer quels comptes de service et clés ont été récemment utilisés pour l'authentification, quels comptes de service n'ont pas été utilisés au cours des 90 derniers jours et quels comptes de service possèdent des rôles disposant de privilèges excessifs.

Vous pouvez combiner les informations de tous ces outils pour mieux comprendre l'utilisation des comptes de service et des clés dans votre organisation. Pour obtenir un exemple illustrant comment combiner les informations provenant de ces différentes sources dans l'ensemble de votre organisation, consultez l'architecture de référence déployable sur GitHub. Cette architecture de référence agrège les données provenant de divers outils et les exporte régulièrement vers une table BigQuery pour les analyser.

L'architecture de référence déploie un pipeline de données qui interroge l'inventaire des éléments cloud pour identifier les clés de compte de service dans votre organisation. Le pipeline de données combine ensuite ces données avec les données d'utilisation des clés et des autorisations pour le compte associé. La table obtenue, sa_key_usage, vous aide à répondre aux questions suivantes :

  • Combien de clés persistantes ont été créées ? Ce nombre peut s'avérer utile comme métrique de haut niveau pour suivre la progression de votre migration visant à cesser d'utiliser des clés.
  • Quels projets et comptes de service utilisent des clés ? Ces informations vous aident à identifier les propriétaires des charges de travail qui utilisent des clés de compte de service.
  • Quelles clés sont inactives ? Vous pouvez probablement supprimer ces clés sans évaluation supplémentaire de la part des propriétaires des charges de travail.
  • Quelles clés sont associées à des comptes de service qui présentent des recommandations liées à des autorisations en excès ? Si une clé de compte de service est associée à un compte de service trop privilégié, en particulier s'il est doté d'un rôle de propriétaire, d'éditeur ou de lecteur, la clé peut présenter un risque particulièrement élevé. Rechercher les comptes de service présentant des recommandations de rôles peut vous aider à identifier les comptes de service qui présentent trop de privilèges. Après avoir identifié ces comptes de service, vous pouvez décider de prioriser ces charges de travail pour la migration. Vous pouvez également choisir d'appliquer les recommandations de rôle pour réduire de manière proactive les autorisations en excès.

Ce pipeline de données s'exécute quotidiennement et écrit dans une table BigQuery partitionnée par date. Vous pouvez utiliser cette table pour analyser certains comptes de service ou clés spécifiques, ou pour suivre la progression de la correction à l'aide d'un outil de tableau de bord tel que Looker Studio.

Enrichir les données d'utilisation des clés avec davantage de contexte

Après avoir créé votre ensemble de données d'utilisation des clés, vous pouvez éventuellement l'étendre à l'aide de sources de données supplémentaires. Nous vous recommandons d'ajouter les sources de données que vous utilisez déjà pour suivre la gouvernance et la provenance des ressources. Selon votre gouvernance existante, vous pouvez ajouter des données supplémentaires, telles que les suivantes :

  • Informations de propriété provenant d'une base de données de gestion de configuration (CMDB) ou d'un système similaire
  • Informations de gouvernance configurées dans des étiquettes de projet, comme l'équipe ou le centre de coûts responsable d'un projet
  • Informations d'environnement concernant les clés utilisées pour les charges de travail dans des environnements externes à Google Cloud

Élaborer un plan pour réduire l'utilisation des clés de compte de service

Avant de pouvoir déployer des modifications visant à réduire l'utilisation des clés de compte de service, vous devez déterminer quelles charges de travail et quels environnements seront affectés, et comment appliquer ces modifications. Vous devez également communiquer ce plan au sein de votre entreprise et vous assurer que les propriétaires de charge de travail le soutiennent.

Les sections suivantes présentent les sujets clés que votre plan doit aborder. Le plan spécifique à votre organisation dépend de sa taille et des exigences spécifiques de vos charges de travail.

Définir la responsabilité des propriétaires des charges de travail actuelles

Bien qu'une équipe de sécurité centrale puisse évaluer les clés existantes, une migration réussie nécessite des efforts de la part des propriétaires de charges de travail. Pour les clés qui entrent dans le champ de la migration, les propriétaires des charges de travail doivent déterminer laquelle des méthodes d'authentification disponibles fonctionne pour leur cas d'utilisation, puis exécuter cette migration.

Réfléchissez à la façon d'équilibrer les améliorations de votre stratégie de sécurité existante avec les efforts demandés aux propriétaires des charges de travail. Les sections suivantes décrivent deux exemples d'approches : l'une qui accorde la priorité aux améliorations de votre stratégie de sécurité et l'autre qui privilégie fortement la minimisation des efforts requis des propriétaires des charges de travail. L'approche que vous adopterez dans les faits peut varier. Par exemple, vous pouvez décider de sélectionner individuellement les charges de travail concernées.

Exemple : Toutes les charges de travail actuelles sont évaluées pour la migration

Une approche possible consiste à appliquer des contrôles de clés de compte de service pour toutes les charges de travail existantes et futures. Cela implique des étapes telles que les suivantes :

  • Collaborer avec les propriétaires de charges de travail pour évaluer leur utilisation de clés pour les charges de travail existantes
  • Exiger que les propriétaires de charges de travail migrent toutes leurs charges de travail existantes utilisant des clés, sauf si une exception leur a été accordée
  • Empêcher toutes les charges de travail futures d'utiliser des clés de compte de service, sauf si une exception leur a été accordée

Cette approche donne la priorité aux améliorations de votre stratégie de sécurité existante, mais nécessite à court terme plus d'efforts de la part des développeurs et des propriétaires de charges de travail. Pour réussir l'exécution d'un tel plan, vous devez pouvoir compter sur l'engagement des propriétaires de charges de travail à participer à l'examen et à la refactorisation des charges de travail.

Exemple : Aucune des charges de travail actuelles n'est évaluée pour la migration

Une autre approche consiste à autoriser une exception automatique pour les charges de travail existantes, qui leur permet de continuer à utiliser des clés de compte de service, et à n'appliquer les nouveaux contrôles qu'aux charges de travail futures.

Cette approche améliore la stratégie de sécurité des charges de travail futures et réduit la responsabilité des propriétaires des charges de travail actuelles. Toutefois, cela n'améliore pas la stratégie de sécurité des charges de travail existantes.

Identifier les objectifs faciles à atteindre

Dans votre évaluation, vous pouvez être amené à identifier des clés pouvant être supprimées en toute sécurité sans aucune correction supplémentaire requise des propriétaires des charges de travail. Par exemple, si une clé ne présente aucune activité pendant 90 jours, ou si elle concerne des ressources qui ne sont plus actives, vous devriez pouvoir la supprimer en toute sécurité sans avoir à migrer vers un autre mécanisme d'authentification.

Dressez la liste des clés qui répondent à ces critères. Vous utiliserez cette liste pendant la phase de déploiement pour supprimer les clés inutiles. Avant d'ajouter une clé à la liste, vérifiez s'il existe des cas d'utilisation rares nécessitant si la clé du compte de service, par exemple un accès d'urgence en production reposant sur des clés de compte de service.

Planifier l'application des modifications apportées aux règles d'administration

Pour réussir la transition vers l'arrêt de l'utilisation des clés de compte de service, vous devez empêcher la création de nouvelles clés. Pendant la phase de déploiement, vous appliquez la contrainte de règle d'administration iam.disableServiceAccountKeyCreation pour empêcher la création de nouvelles clés de compte de service.

Bien que cette contrainte n'empêche pas l'utilisation de clés existantes, elle peut perturber les charges de travail existantes qui effectuent la rotation régulière de leurs clés. Avant de commencer la phase de déploiement, décidez où vous allez l'appliquer dans votre hiérarchie de ressources afin de minimiser les interruptions.

Vous préférerez peut-être appliquer initialement la contrainte au niveau du projet ou du dossier plutôt qu'au niveau de l'organisation. Par exemple, vous pouvez appliquer la contrainte sur le dossier utilisé pour votre environnement de développement avant de la déployer dans les dossiers de production. Dans une grande organisation comportant de nombreuses équipes, vous pouvez aussi commencer par appliquer la contrainte au dossier d'une seule équipe donnée, puis l'appliquer aux autres dossiers lors de leur migration.

Vous pouvez utiliser des règles d'administration avec des tags pour appliquer des règles d'administration de manière conditionnelle au niveau des projets ou des dossiers.

Concevoir un processus pour les exceptions

Bien que l'objectif de cette migration soit de réduire ou d'éliminer l'utilisation des clés de compte de service, il existe des cas d'utilisation légitimes nécessitant l'utilisation de ces clés. Même si aucune charge de travail existante ne nécessite de clé de compte de service, cela reste possible pour de futures charges de travail. Par conséquent, vous devez définir un processus opérationnel afin d'évaluer et d'approuver des exceptions pour les cas d'utilisation nécessitant des clés de compte de service.

Définissez un processus permettant aux propriétaires de charges de travail de demander une exception qui autorise leur charge de travail à utiliser des clés de compte de service. Assurez-vous que les décideurs chargés d'accorder une exception possèdent bien les connaissances techniques requises pour valider le cas d'utilisation. Consultez les propriétaires des charges de travail pour savoir laquelle des alternatives plus sécurisées aux clés de compte de service peut être mieux adaptée, et conseillez les propriétaires de charges de travail en matière de bonnes pratiques de gestion des clés de compte de service.

Informer les propriétaires des charges de travail des modifications à venir

Une fois que vous avez élaboré un plan, vous devez le communiquer clairement au sein de votre organisation et vous assurer que les personnes concernées, en particulier les responsables expérimentés, sont prêtes à s'engager pour la migration.

Bien que les détails spécifiques de la migration varient selon votre organisation, envisagez d'inclure les aspects suivants dans votre plan de communication :

  • L'impact négatif que peuvent avoir les clés de compte de service non sécurisées sur l'organisation, ainsi que les motivations qui justifient votre abandon des clés de compte de service
  • Les nouveaux contrôles de sécurité visant à empêcher la création de clés de compte de service et leur impact potentiel sur les processus existants
  • Des conseils permettant aux développeurs d'identifier des alternatives plus sécurisées aux clés de compte de service
  • Le processus permettant aux équipes de demander une exception pour autoriser les clés de compte de service, y compris la fréquence de réévaluation de cette exception
  • Le calendrier d'application des modifications proposées

Collaborez avec les propriétaires de charges de travail pour affiner votre plan et vous assurer qu'il fonctionne dans l'ensemble de votre organisation.

Déployer les contrôles et refactoriser les charges de travail

Après avoir créé un plan et l'avoir communiqué aux propriétaires de charges de travail, vous pouvez commencer la migration d'abandon des clés de compte de service.

Au cours de cette phase, vous commencez à refactoriser les charges de travail pour qu'elles s'authentifient avec des alternatives plus sécurisées que les clés de compte de service. Vous développez également des capacité supplémentaires pour surveiller votre environnement en continu et limiter les risques futurs.

Les sections suivantes décrivent les étapes que vous pouvez entreprendre pour refactoriser les charges de travail et supprimer les clés en minimisant les perturbations. Vous pouvez choisir de suivre ces étapes dans n'importe quel ordre, en fonction de la priorité et des efforts requis pour votre organisation.

Appliquer des contrôles pour arrêter la création de clés de compte de service

Pour arrêter la création de nouvelles clés de compte de service, appliquez la contrainte de règle d'administration iam.disableServiceAccountKeyCreation.

Toutefois, avant d'appliquer cette contrainte, vous devez ajouter des tags à tous les projets ou dossiers qui devront être exemptés de la règle. Vous pouvez autoriser des exceptions pour des charges de travail existantes qui ne peuvent pas abandonner les clés de compte de service, ou pour des nouvelles charges de travail qui ont une raison légitime de s'authentifier uniquement avec des clés de compte de service.

Après avoir ajouté des tags aux projets et aux dossiers exemptés, vous pouvez définir une règle d'administration avec des tags pour appliquer la contrainte iam.disableServiceAccountKeyCreation aux projets et dossiers non exemptés.

Pour empêcher la création de clés de compte de service dans tous les projets et dossiers non exemptés, procédez comme suit :

  1. Assurez-vous de disposer des rôles IAM nécessaires pour administrer les tags et administrer les règles d'administration au niveau de l'organisation.

  2. Au niveau de l'organisation, créez une clé de tag et une valeur de tag que vous utiliserez pour définir si un projet ou un dossier doit être exempté de la règle d'administration. Nous vous recommandons de créer un tag ayant comme clé disableServiceAccountKeyCreation et comme valeurs possibles enforced et not_enforced.

    Pour savoir comment créer des clés et des valeurs de tags, consultez la section Créer et définir un tag.

  3. Associez le tag disableServiceAccountKeyCreation à l'organisation et définissez-le sur la valeur enforced. Tous les projets ou dossiers de l'organisation héritent de cette valeur de tag, sauf si elle est remplacée par une valeur de tag différente.

    Pour apprendre à associer des tags à des ressources, consultez la section Associer des tags aux ressources.

  4. Associez à chaque projet ou dossier que vous souhaitez exempter de la règle d'administration le tag disableServiceAccountKeyCreation et définissez sa valeur sur not_enforced. Définir de cette manière une valeur de tag pour un projet ou un dossier remplace la valeur de tag héritée de l'organisation.

  5. Créez une règle d'administration qui empêche la création de clés de compte de service pour toutes les ressources, à l'exception des ressources exemptées. Cette règle doit comporter les règles suivantes :

    • Configurez la contrainte iam.disableServiceAccountKeyCreation pour qu'elle ne soit appliquée à aucune ressource portant le tag disableServiceAccountKeyCreation: not_enforced. La condition de cette règle doit se présenter comme suit :

      resource.matchTag(\"ORGANIZATION_ID/disableServiceAccountKeyCreation\", \"not_enforced\")
      
    • Configurez la contrainte iam.disableServiceAccountKeyCreation à appliquer à toutes les autres ressources.

    Pour découvrir comment créer des règles d'administration avec des conditions de tags, consultez la page Définir une règle d'administration avec des tags.

Corriger les charges de travail existantes

Pour chaque charge de travail qui utilise des clés de compte de service, collaborez avec les propriétaires de la charge de travail afin de choisir et mettre en œuvre une autre méthode d'authentification.

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

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

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

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

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

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

Dans certains cas, il est possible que vous ne puissiez utiliser aucune méthode d'authentification autre que les clés de compte de service. Voici quelques exemples de situations dans lesquelles une clé de compte de service peut être la seule option possible :

  • Vous utilisez des applications commerciales prêtes à l'emploi (COTS) ou des applications SaaS (Software as a Service) qui vous demandent de saisir une clé de compte de service Google Cloud directement dans leur interface utilisateur.
  • Votre charge de travail s'exécute en dehors de Google Cloud et n'est pas authentifiée auprès d'un fournisseur d'identité compatible avec la fédération d'identité de charge de travail.

Dans les cas où vous devez continuer à utiliser les clés de compte de service, assurez-vous de suivre les bonnes pratiques pour gérer les clés de compte de service.

Vous pouvez également décider de ne pas corriger certaines charges de travail si votre évaluation montre que le risque de poursuivre l'utilisation des clés de compte de service ne justifie pas le coût de passer à une autre méthode d'authentification.

Supprimer les clés inutiles

Si vous êtes certain qu'une clé de compte de service n'est pas nécessaire, vous devez la supprimer. Les clés inutiles incluent les suivantes :

  • Clés sans utilisation récente ou clés liées à des ressources inutilisées, que vous avez identifiées dans la section Identifier les objectifs faciles à atteindre de cette page

  • Clés des charges de travail ayant migré vers d'autres méthodes d'authentification

    Après avoir supprimé toutes les clés de compte de service d'un projet, assurez-vous que la contrainte iam.disableServiceAccountKeyCreation est bien appliquée à ce projet. Si le projet était précédemment exempté de cette contrainte, supprimez le tag permettant l'exemption.

Pour supprimer des clés en toute sécurité, nous vous recommandons de désactiver une clé avant de la supprimer. La suppression est irréversible, mais la désactivation vous permet de réactiver rapidement la clé si vous identifiez des problèmes inattendus. Après avoir désactivé la clé, attendez d'être sûr que sa suppression définitive ne causera aucun problème, puis supprimez-la. Si, après avoir désactivé la clé, vous identifiez des problèmes inattendus, réactivez la clé, résolvez les problèmes, puis répétez le processus jusqu'à ce que vous puissiez supprimer la clé en toute sécurité.

Utiliser les commandes intégrées pour réagir aux fuites de clés

Google Cloud propose plusieurs outils et services pour vous aider à détecter les fuites de clés de compte de service et à réagir en conséquence. Envisagez d'utiliser les mécanismes suivants pour vous aider à réagir aux fuites de clés de compte de service :

  • Activez la détection d'anomalies de Security Command Center pour rechercher des clés dans les dépôts publics. Cette analyse crée un résultat account_has_leaked_credentials si des clés piratées sont détectées.
  • Consultez le programme de protection contre le minage de cryptomonnaie de Security Command Center et assurez-vous de remplir les conditions techniques requises pour être éligible. L'utilisation abusive de minage de cryptomonnaie est une attaque courante en cas de fuite d'identifiants.
  • Configurez des contacts essentiels afin que votre équipe de sécurité reçoive les notifications de sécurité de Google Cloud, y compris des abus liés à des clés compromises. Assurez-vous que l'adresse e-mail fait l'objet d'une surveillance active et ne s'appuie pas sur des utilisateurs individuels susceptibles de constituer un point de défaillance unique.

Pour en savoir plus sur la gestion des incidents, consultez la section Créer un processus collaboratif de gestion des incidents.

Amélioration continue de la gestion des comptes de service

Dans la mesure du possible, mettez en œuvre les bonnes pratiques pour gérer les clés de compte de service. L'amélioration de vos processus de gestion des clés peut réduire le risque posé par les clés de compte de service restant dans votre organisation.

Étapes suivantes