JetBrains - Renforcer 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.

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.

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.

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.

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.

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.

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

TeamCity propose plusieurs rôles pré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 . )

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

VIII-2-1. Attention aux plugins tiers▲

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

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

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.

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