TeamCity

Renforcer votre serveur TeamCity

TeamCity est au cœur de votre processus de build. Il génère votre code source sous forme d’artefacts déployables et souvent déploie également ces artefacts, ce qui signifie qu’il a potentiellement accès à des informations sensibles.

Bien qu’il offre un niveau de sécurité élevé par défaut, nous vous suggérons ici quelques mesures supplémentaires à prendre afin renforcer la sécurité de vos pipelines de build.

Conseils d’ordre général

Mettez régulièrement à jour votre serveur TeamCity

Nous vous recommandons fortement de mettre régulièrement TeamCity à jour vers la dernière version disponible.

TeamCity vous avertit automatiquement via l’interface utilisateur dès qu’une nouvelle mise à jour est disponible. Vous pouvez également consulter les nouvelles versions de TeamCity par vous-même dans Server Administration > Updates , ainsi que les mises à jour de plugins disponibles dans Server Administration > Plugins.

D’un point de vue technique, les mises à jour entre les versions de correctifs de bugs au sein d’une même version majeure ou mineure sont rétrocompatibles (par exemple 2020.1.1 → 2020.1.2) et permettent de revenir en arrière assez facilement. Pour toutes les autres mises à niveau majeures, nous faisons de notre mieux pour assurer un fonctionnement aussi fluide que possible, mais il est recommandé de procéder à des sauvegardes pour faciliter le retour à la version antérieure en cas de besoin.

Du point de vue des licences, les mises à jour entre les versions de correctifs de bugs sont sûres elles aussi . Si la version 2020.1.1 est couverte par votre licence, vous pourrez alors passer à n’importe quelle version 2020.1.x.

Abonnez-vous au service de notifications de sécurité

Nous vous recommandons également de vous abonner au service de notifications de sécurité pour obtenir les dernières informations sur les éventuels problèmes de sécurité pouvant affecter TeamCity ou tout autre produit JetBrains.

Informations d’identification

Utilisez des identifiants forts et avec précaution

Nous vous recommandons d’utiliser des identifiants forts, non seulement pour votre serveur TeamCity, mais aussi pour tous les autres services impliqués dans un build ou requis par votre logiciel en production.

Veillez tout particulièrement à ne pas laisser vos informations d’identification sur :

• Des référentiels tels que GitHub, GitLab, etc.
• Des variables d’environnement, qui sont souvent enregistrées ou partagées avec des systèmes de surveillance tiers.
• Le journal de build : assurez-vous de ne pas consigner d’informations sensibles par inadvertance.

De plus, si vous utilisez des paramètres versionnés (au format Kotlin DSL ou XML), ne stockez jamais vos informations d’identification dans vos fichiers de configuration. Optez plutôt pour l’utilisation de jetons.

Stockez vos données sécurisées avec le type de paramètre password

Pour stocker des mots de passe ou d’autres données sécurisées dans les paramètres de TeamCity, il est conseillé d’utiliser le type de paramètre password de TeamCity. Cela permet d’assurer que les valeurs sensibles n’apparaissent jamais dans l’interface utilisateur de TeamCity. Elles seront également remplacées par des astérisques dans le journal de build.

Utilisez un outil de gestion des secrets

Bien que les paramètres de mot de passe soient masqués dans l’interface utilisateur, chiffrés au repos et protégés contre toute exposition en texte brut dans le journal de build, la plupart du temps, ce niveau de sécurité ne suffit pas.

Vous pouvez utiliser un outil tel que HashiCorp Vault afin de gérer et de faire tourner toutes les informations d’identification sensibles que vous utilisez dans un build et qui s’intègre bien avec TeamCity.

Utilisez une authentification externe

Le cas échéant, utilisez l’un de nos modules d’authentification externes, allant de l’intégration de LDAP et Windows Domain à l’authentification via GitHub, GitLab, ou autres. Vous pouvez alors désactiver l’authentification intégrée de TeamCity afin qu’il ne conserve plus les mots de passe hachés dans la base de données interne.

Utilisez une clé de cryptage personnalisée

Les mots de passe nécessaires pour s’authentifier dans des systèmes externes (comme les VCS, outils de suivi des tickets, etc.) sont stockés sous forme brouillée dans [TeamCity Data Directory]( https://www.jetbrains.com/help/teamcity/teamcity-data-directory.html) et peuvent également être stockés dans la base de données. Toutefois, les valeurs sont seulement brouillées et peuvent donc être récupérées par un utilisateur disposant d’un accès au système de fichiers ou à la base de données du serveur.

Pour éviter cela, vous pouvez activer une clé de cryptage personnalisée. Dans ce cas, TeamCity utilisera votre clé personnalisée unique pour chiffrer toutes les valeurs sécurisées au lieu d’utiliser le mécanisme de brouillage par défaut.

Autorisations

Utilisez des rôles prédéfinis

TeamCity propose plusieurs rôlesprédéfinis :

• System Admin
• Project Admin
• Project Developer
• Project Viewer

Créez des groupes d’utilisateurs qui correspondent à votre structure organisationnelle et attribuez-leur les rôles ci-dessus. Ajoutez ensuite vos utilisateurs à leurs groupes respectifs, en leur accordant le niveau d’autorisation le plus bas dont ils ont besoin pour leur travail quotidien.

Il est également recommandé de créer de nouveaux rôles avec des autorisations supplémentaires au lieu d’attribuer immédiatement le rôle de Project Admin à toute personne ayant besoin de plus de droits. (Cela ne fonctionne pas si vous désactivez les autorisations par projet.)

Utilisez les autorisations par projet

Pour renforcer encore la sécurité, vous pouvez également utiliser les autorisations par projet. Avec ce type d’autorisations, vos développeurs peuvent par exemple n’avoir accès qu’à la partie compilation de votre chaîne de build, tandis que les devops peuvent accéder à la partie déploiement pour l’exécution.

N’activez pas la connexion en mode invité

Par défaut, la connexion anonyme à TeamCity est désactivée. Assurez-vous de ne pas l’activer sur les instances de production du serveur TeamCity qui sont exposées à Internet, sauf si vous souhaitez que des utilisateurs externes puissent voir tous vos builds et les fichiers journaux et artefacts associés.

Créez un utilisateur REST distinct

Si vous accédez à l’API REST de TeamCity à partir d’un script ou d’un programme externe, nous vous recommandons de créer un utilisateur séparé disposant d’un nombre d’autorisations limité. Il est également judicieux de créer des jetons d’accès avec expiration automatique au lieu d’utiliser l’identifiant et le mot de passe de l’utilisateur pour accéder à l’API.

Restreignez les autorisations de build de déploiement

Assurez-vous que vos chaînes de build de déploiement n’autorisent pas les builds personnels. Limitez le nombre de développeurs qui peuvent déclencher ces builds, et utilisez un pool d’agents propres séparé pour ces builds.

Serveur TeamCity

Protégez le répertoire de données de TeamCity

Les utilisateurs bénéficiant d’un accès en lecture à peuvent accéder à tous les paramètres du serveur, y compris les mots de passe configurés. Vous devez donc veiller à ce que ce répertoire ne soit lisible que par les utilisateurs du système d’exploitation qui administrent réellement des services.

Protégez votre serveur TeamCity

De façon générale, limitez l’accès à la machine sur laquelle s’exécute votre serveur TeamCity. Activez les journaux d’accès et vérifiez-les régulièrement.

Utilisez le protocole HTTPS partout

Il est recommandé d’activer le HTTPS pour TeamCity. Nous conseillons actuellement d’activer le HTTPS sur votre proxy inverse (comme Nginx ou Apache).

Sécurisez votre base de données externe

Assurez-vous d’utiliser un compte d’utilisateur dédié à la base de données avec des informations d’identification fortes pour le schéma de base de données de votre serveur TeamCity. Envisagez d’utiliser le cryptage de la base de données si celle-ci le permet.

Contrôle de version

Utilisez une version récente de Git

Veillez à toujours utiliser la dernière version stable du système d’exploitation et de Git sur vos agents de build. Faites des mises à jour régulièrement.

Gérez correctement vos clés SSH

Si vous utilisez des clés SSH pour accéder à vos référentiels, ne les stockez pas sur vos agents de build. Utilisez plutôt les fonctionnalités de gestion des clés SSH de TeamCity et chargez-les sur le serveur TeamCity.

De plus, au lieu de désactiver les vérifications d’hôtes connus, veillez à maintenir un fichier .ssh/known_hosts sur le serveur et à créer des agents de build pour chaque hôte auquel vous vous connectez.

Ayez recours à un utilisateur VCS dédié

Si vous n’utilisez pas de fonctionnalités avancées comme le DSL Kotlin ou, de manière plus générale, si vous n’avez pas besoin d’effectuer des commits dans votre référentiel dans le cadre de votre processus de build, nous vous recommandons de conserver un utilisateur VCS dédié sans autorisation d’écriture pour vous connecter à vos référentiels.

Agents de build

Exécutez des builds de production propres

Nous vous recommandons d’activer l’option Enforcing Clean Checkout pour vos builds de production, afin d’éviter toute altération du code source sur un agent.

Utilisez des agents de build jetables et protégés du réseau

Si possible, essayez d’utiliser des agents de build jetables et uniques. Plus la durée de vie de l’agent est limitée, plus les risques de compromission sont faibles. Veillez également à utiliser des règles de pare-feu dépendantes du système d’exploitation afin de désactiver l’accès au réseau entrant pour vos agents cloud.

Utilisez des pools d’agents pour vos différents projets

Si vous exécutez plusieurs agents sur la même machine et que l’option Enable Clean Checkout n’est pas activée, sachez que des agents compromis ou des projets non fiables pourraient modifier le code source dans des répertoires de travail « voisins ».

Pour limiter ce risque, envisagez de n’exécuter qu’un seul agent par machine et utilisez des pools d’agents différents pour chaque projet (privé/public).

Intégrations

Évitez de créer aveuglément des builds pour des requêtes pull publiques

Si vous générez des builds pour des requêtes pull d’utilisateurs inconnus ou extérieurs à votre organisation, sachez que ces requêtes peuvent contenir du code malveillant qui pourrait s’exécuter sur votre agent de build.

Refusez de créer des builds pour des requêtes pull publiques ou utilisez des agents séparés, isolés et jetables. TeamCity propose également un rapport de santé intégré qui détecte et signale les builds de requêtes pull.

Soyez conscient des implications en matière de sécurité si vous utilisez des paramètres versionnés

Lorsque vous utilisez des paramètres versionnés (DSL Kotlin, XML) et qu’ils sont placés dans le même référentiel que le code source, une personne malveillante a la possibilité de modifier et de divulguer les paramètres de configuration du projet. Pour ce faire, vous pouvez par exemple ajouter une étape de build qui affiche les mots de passe ou les envoie quelque part sous forme de fichier.

En option, vous pouvez utiliser un référentiel séparé vers lequel seul un nombre limité d’utilisateurs peuvent faire des commits pour vos paramètres versionnés.

Attention aux plugins tiers

Lors de l’installation de plugins, vérifiez qu’ils proviennent d’une source fiable et que leur code source est disponible. Les plugins peuvent accéder à toutes les informations d’un serveur TeamCity, y compris des informations sensibles.

Stockage des artefacts

Désactivez l’accès anonyme

Quel que soit l’endroit où vous stockez vos artefacts de build (comme S3), assurez-vous de désactiver l’accès anonyme à votre emplacement de stockage.

Utilisez des politiques d’accès appropriées

Utilisez des politiques d’accès adaptées pour protéger votre S3 ou vos autres emplacements de stockage ou référentiels d’artefacts. Recourez également au cryptage si possible. Vérifiez, surveillez et examinez régulièrement les journaux d’accès de vos emplacements de stockage.

Ne placez pas de données sensibles dans des artefacts

Cela semble évident, mais ne stockez pas d’informations d’identification ou autres informations sensibles en texte clair dans les artefacts de votre build.

Historique et Journaux de build

Conservez l’historique de vos builds

Conservez votre historique et vos journaux de build pendant plus longtemps, en particulier pour les builds qui effectuent des déploiements critiques, en spécifiant les règles de nettoyage correspondantes pour votre projet. Veillez également à ne pas accorder d’autorisations « remove build » aux développeurs car cela pourrait permettre de contourner l’archivage.

Ces deux mesures aident à tracer les activités malveillantes même si elles ont eu lieu il y a longtemps.

Archivez les journaux des serveurs et des agents

Rassemblez les journaux du serveur TeamCity et des agents de build dans une archive et placez-les dans un stockage correctement sécurisé.

Partager cet article

Nous avons également réalisé une version PDF de cet article, facile à partager. N’hésitez pas à le diffuser au sein de votre organisation : Télécharger le PDF.

Auteur de l’article original en anglais : Marco Behler