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 ECDSA pour l'authentification. Comme la clé privée de la paire de clés RSA 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 clés de compte de service présentent 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 clé de compte de service divulguée pour s'authentifier et accéder à 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 donné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.
Cette page 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.
Les acteurs malveillants peuvent trouver les clés de compte de service plus utiles qu'un mot de passe divulgué. Par exemple, 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 de différentes manières :
- Dépôts de code source de projets Open Source.
- Vidages de données publiques de services piratés
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.
Éviter de laisser les clés de compte de service dans des emplacements temporaires
Lorsque vous créez une clé de compte de service, déplacez-la immédiatement à 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.
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.
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 à la place.
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 qui y sont intégrées.
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.
- 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.
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.
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 ont un délai d'expiration d'un an et restent valides jusqu'à ce que vous les supprimiez. Vous pouvez également définir votre propre délai d'expiration. 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 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.
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.
Utiliser une clé dédiée pour chaque machine exécutant une application
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é.