TeamCity est au c\u0153ur de votre processus de build. Il g\u00e9n\u00e8re votre code source sous forme d’artefacts d\u00e9ployables et souvent d\u00e9ploie \u00e9galement ces artefacts, ce qui signifie qu\u2019il a potentiellement acc\u00e8s \u00e0 des informations sensibles.<\/p>\n
Bien qu\u2019il offre un niveau de s\u00e9curit\u00e9 \u00e9lev\u00e9 par d\u00e9faut, nous vous sugg\u00e9rons ici quelques mesures suppl\u00e9mentaires \u00e0 prendre afin renforcer la s\u00e9curit\u00e9 de vos pipelines de build.<\/p>\n
Nous vous recommandons fortement de mettre r\u00e9guli\u00e8rement TeamCity \u00e0 jour vers la derni\u00e8re version disponible<\/a>.<\/p>\n TeamCity vous avertit automatiquement via l\u2019interface utilisateur d\u00e8s qu\u2019une nouvelle mise \u00e0 jour est disponible. Vous pouvez \u00e9galement consulter les nouvelles versions de TeamCity par vous-m\u00eame dans Server Administration<\/strong> > Updates <\/strong>, ainsi que les mises \u00e0 jour de plugins disponibles dans Server Administration > Plugins<\/strong>.<\/p>\n D’un point de vue technique<\/strong>, les mises \u00e0 jour entre les versions de correctifs de bugs au sein d\u2019une m\u00eame version majeure ou mineure sont r\u00e9trocompatibles (par exemple 2020.1.1 \u2192 2020.1.2) et permettent de revenir en arri\u00e8re assez facilement. Pour toutes les autres mises \u00e0 niveau majeures, nous faisons de notre mieux pour assurer un fonctionnement aussi fluide que possible, mais il est recommand\u00e9 de proc\u00e9der \u00e0 des sauvegardes pour faciliter le retour \u00e0 la version ant\u00e9rieure en cas de besoin.<\/p>\n Du point de vue des licences<\/strong>, les mises \u00e0 jour entre les versions de correctifs de bugs sont s\u00fbres elles aussi . Si la version 2020.1.1 est couverte par votre licence, vous pourrez alors passer \u00e0 n\u2019importe quelle version 2020.1.x.<\/p>\n Nous vous recommandons \u00e9galement de vous abonner au service de notifications de s\u00e9curit\u00e9<\/a> pour obtenir les derni\u00e8res informations sur les \u00e9ventuels probl\u00e8mes de s\u00e9curit\u00e9 pouvant affecter TeamCity ou tout autre produit JetBrains.<\/p>\n Nous vous recommandons d\u2019utiliser des identifiants forts, non seulement pour votre serveur TeamCity, mais aussi pour tous les autres services impliqu\u00e9s dans un build ou requis par votre logiciel en production. <\/p>\n Veillez tout particuli\u00e8rement \u00e0 ne pas laisser vos informations d’identification sur\u00a0:<\/p>\n De plus, si vous utilisez des param\u00e8tres versionn\u00e9s (au format Kotlin DSL ou XML), ne stockez jamais vos informations d\u2019identification dans vos fichiers de configuration. Optez plut\u00f4t pour l’utilisation de jetons<\/a>.<\/p>\n Pour stocker des mots de passe ou d\u2019autres donn\u00e9es s\u00e9curis\u00e9es dans les param\u00e8tres de TeamCity, il est conseill\u00e9 d\u2019utiliser le type de param\u00e8tre password<\/a> de TeamCity. Cela permet d’assurer que les valeurs sensibles n\u2019apparaissent jamais dans l\u2019interface utilisateur de TeamCity. Elles seront \u00e9galement remplac\u00e9es par des ast\u00e9risques dans le journal de build.<\/p>\n Bien que les param\u00e8tres de mot de passe soient masqu\u00e9s dans l\u2019interface utilisateur, chiffr\u00e9s au repos et prot\u00e9g\u00e9s contre toute exposition en texte brut dans le journal de build, la plupart du temps, ce niveau de s\u00e9curit\u00e9 ne suffit pas.<\/p>\n Vous pouvez utiliser un outil tel que HashiCorp Vault<\/a> afin de g\u00e9rer et de faire tourner toutes les informations d\u2019identification sensibles que vous utilisez dans un build et qui s’int\u00e8gre bien avec TeamCity<\/a>.<\/p>\n Le cas \u00e9ch\u00e9ant, utilisez l\u2019un de nos modules d’authentification<\/a> externes, allant de l\u2019int\u00e9gration de LDAP et Windows Domain \u00e0 l\u2019authentification via GitHub, GitLab, ou autres. Vous pouvez alors d\u00e9sactiver l’authentification int\u00e9gr\u00e9e<\/a> de TeamCity afin qu’il ne conserve plus les mots de passe hach\u00e9s dans la base de donn\u00e9es interne.<\/p>\n Les mots de passe n\u00e9cessaires pour s\u2019authentifier dans des syst\u00e8mes externes (comme les VCS, outils de suivi des tickets, etc.) sont stock\u00e9s sous forme brouill\u00e9e dans [TeamCity Data Directory]( https:\/\/www.jetbrains.com\/help\/teamcity\/teamcity-data-directory.html) et peuvent \u00e9galement \u00eatre stock\u00e9s dans la base de donn\u00e9es. Toutefois, les valeurs sont seulement brouill\u00e9es et peuvent donc \u00eatre r\u00e9cup\u00e9r\u00e9es par un utilisateur disposant d’un acc\u00e8s au syst\u00e8me de fichiers ou \u00e0 la base de donn\u00e9es du serveur.<\/p>\n Pour \u00e9viter cela, vous pouvez activer une cl\u00e9 de cryptage personnalis\u00e9e<\/a>. Dans ce cas, TeamCity utilisera votre cl\u00e9 personnalis\u00e9e unique pour chiffrer toutes les valeurs s\u00e9curis\u00e9es au lieu d\u2019utiliser le m\u00e9canisme de brouillage par d\u00e9faut.<\/p>\n TeamCity propose plusieurs r\u00f4les<\/a>pr\u00e9d\u00e9finis :<\/p>\n Cr\u00e9ez des groupes d’utilisateurs<\/a> qui correspondent \u00e0 votre structure organisationnelle et attribuez-leur les r\u00f4les ci-dessus. Ajoutez ensuite vos utilisateurs \u00e0 leurs groupes respectifs, en leur accordant le niveau d’autorisation le plus bas dont ils ont besoin pour leur travail quotidien.<\/p>\n Il est \u00e9galement recommand\u00e9 de cr\u00e9er de nouveaux r\u00f4les avec des autorisations suppl\u00e9mentaires au lieu d\u2019attribuer imm\u00e9diatement le r\u00f4le de Project Admin \u00e0 toute personne ayant besoin de plus de droits. (Cela ne fonctionne pas si vous d\u00e9sactivez les autorisations par projet<\/a>.)<\/p>\n Pour renforcer encore la s\u00e9curit\u00e9, vous pouvez \u00e9galement utiliser les autorisations par projet<\/a>. Avec ce type d’autorisations, vos d\u00e9veloppeurs peuvent par exemple n\u2019avoir acc\u00e8s qu\u2019\u00e0 la partie compilation de votre cha\u00eene de build, tandis que les devops peuvent acc\u00e9der \u00e0 la partie d\u00e9ploiement pour l’ex\u00e9cution.<\/p>\n Par d\u00e9faut, la connexion anonyme \u00e0 TeamCity<\/a> est d\u00e9sactiv\u00e9e. Assurez-vous de ne pas l\u2019activer sur les instances de production du serveur TeamCity qui sont expos\u00e9es \u00e0 Internet, sauf si vous souhaitez que des utilisateurs externes puissent voir tous vos builds et les fichiers journaux et artefacts associ\u00e9s.<\/p>\n Si vous acc\u00e9dez \u00e0 l’API REST de TeamCity<\/a> \u00e0 partir d\u2019un script ou d\u2019un programme externe, nous vous recommandons de cr\u00e9er un utilisateur s\u00e9par\u00e9 disposant d’un nombre d’autorisations limit\u00e9. Il est \u00e9galement judicieux de cr\u00e9er des jetons d’acc\u00e8s<\/a> avec expiration automatique au lieu d\u2019utiliser l’identifiant et le mot de passe de l\u2019utilisateur pour acc\u00e9der \u00e0 l\u2019API.<\/p>\n Assurez-vous que vos cha\u00eenes de build de d\u00e9ploiement n\u2019autorisent pas les builds personnels<\/a>. Limitez le nombre<\/a> de d\u00e9veloppeurs qui peuvent d\u00e9clencher ces builds, et utilisez un pool d\u2019agents propres s\u00e9par\u00e9 pour ces builds.<\/p>\n Les utilisateurs b\u00e9n\u00e9ficiant d’un acc\u00e8s en lecture \u00e0 De fa\u00e7on g\u00e9n\u00e9rale, limitez l\u2019acc\u00e8s \u00e0 la machine sur laquelle s’ex\u00e9cute votre serveur TeamCity. Activez les journaux d\u2019acc\u00e8s et v\u00e9rifiez-les r\u00e9guli\u00e8rement.<\/p>\n Il est recommand\u00e9 d’activer le HTTPS<\/a> pour TeamCity. Nous conseillons actuellement d\u2019activer le HTTPS sur votre proxy inverse (comme Nginx ou Apache).<\/p>\n Assurez-vous d\u2019utiliser un compte d\u2019utilisateur d\u00e9di\u00e9 \u00e0 la base de donn\u00e9es avec des informations d’identification fortes pour le sch\u00e9ma de base de donn\u00e9es de votre serveur TeamCity. Envisagez d\u2019utiliser le cryptage de la base de donn\u00e9es si celle-ci le permet.<\/p>\n Veillez \u00e0 toujours utiliser la derni\u00e8re version stable du syst\u00e8me d\u2019exploitation et de Git sur vos agents de build. Faites des mises \u00e0 jour r\u00e9guli\u00e8rement.<\/p>\n Si vous utilisez des cl\u00e9s SSH pour acc\u00e9der \u00e0 vos r\u00e9f\u00e9rentiels, ne les stockez pas sur vos agents de build. Utilisez plut\u00f4t les fonctionnalit\u00e9s de gestion des cl\u00e9s SSH de TeamCity<\/a> et chargez-les sur le serveur TeamCity.<\/p>\n De plus, au lieu de d\u00e9sactiver les v\u00e9rifications d\u2019h\u00f4tes connus, veillez \u00e0 maintenir un fichier .ssh\/known_hosts<\/a> sur le serveur et \u00e0 cr\u00e9er des agents de build pour chaque h\u00f4te auquel vous vous connectez.<\/p>\n Si vous n\u2019utilisez pas de fonctionnalit\u00e9s avanc\u00e9es comme le DSL Kotlin<\/a> ou, de mani\u00e8re plus g\u00e9n\u00e9rale, si vous n\u2019avez pas besoin d’effectuer des commits dans votre r\u00e9f\u00e9rentiel dans le cadre de votre processus de build, nous vous recommandons de conserver un utilisateur VCS d\u00e9di\u00e9 sans autorisation d\u2019\u00e9criture pour vous connecter \u00e0 vos r\u00e9f\u00e9rentiels.<\/p>\n Nous vous recommandons d\u2019activer l\u2019option Enforcing Clean Checkout<\/a> pour vos builds de production, afin d\u2019\u00e9viter toute alt\u00e9ration du code source sur un agent.<\/p>\n Si possible, essayez d\u2019utiliser des agents de build jetables et uniques. Plus la dur\u00e9e de vie de l\u2019agent est limit\u00e9e, plus les risques de compromission sont faibles. Veillez \u00e9galement \u00e0 utiliser des r\u00e8gles de pare-feu d\u00e9pendantes du syst\u00e8me d\u2019exploitation afin de d\u00e9sactiver l\u2019acc\u00e8s au r\u00e9seau entrant pour vos agents cloud.<\/p>\n Si vous ex\u00e9cutez plusieurs agents sur la m\u00eame machine et que l\u2019option Enable Clean Checkout<\/a> n’est pas activ\u00e9e, sachez que des agents compromis ou des projets non fiables pourraient modifier le code source dans des r\u00e9pertoires de travail \u00ab\u00a0voisins\u00a0\u00bb.<\/p>\n Pour limiter ce risque, envisagez de n’ex\u00e9cuter qu\u2019un seul agent par machine et utilisez des pools d’agents<\/a> diff\u00e9rents pour chaque projet (priv\u00e9\/public).<\/p>\n Si vous g\u00e9n\u00e9rez des builds pour des requ\u00eates pull<\/a> d\u2019utilisateurs inconnus ou ext\u00e9rieurs \u00e0 votre organisation, sachez que ces requ\u00eates peuvent contenir du code malveillant qui pourrait s’ex\u00e9cuter sur votre agent de build.<\/p>\n Refusez de cr\u00e9er des builds pour des requ\u00eates pull publiques ou utilisez des agents s\u00e9par\u00e9s, isol\u00e9s et jetables. TeamCity propose \u00e9galement un rapport de sant\u00e9 int\u00e9gr\u00e9<\/a> qui d\u00e9tecte et signale les builds de requ\u00eates pull.<\/p>\n Lorsque vous utilisez des param\u00e8tres versionn\u00e9s (DSL Kotlin, XML) et qu’ils sont plac\u00e9s dans le m\u00eame r\u00e9f\u00e9rentiel que le code source, une personne malveillante a la possibilit\u00e9 de modifier et de divulguer les param\u00e8tres de configuration du projet. Pour ce faire, vous pouvez par exemple ajouter une \u00e9tape de build qui affiche les mots de passe ou les envoie quelque part sous forme de fichier.<\/p>\n En option, vous pouvez utiliser un r\u00e9f\u00e9rentiel s\u00e9par\u00e9 vers lequel seul un nombre limit\u00e9 d\u2019utilisateurs peuvent faire des commits pour vos param\u00e8tres versionn\u00e9s.<\/p>\n Lors de l\u2019installation de plugins<\/a>, v\u00e9rifiez qu\u2019ils proviennent d\u2019une source fiable et que leur code source est disponible. Les plugins peuvent acc\u00e9der \u00e0 toutes les informations d’un serveur TeamCity, y compris des informations sensibles.<\/p>\n Quel que soit l\u2019endroit o\u00f9 vous stockez vos artefacts de build (comme S3), assurez-vous de d\u00e9sactiver l\u2019acc\u00e8s anonyme \u00e0 votre emplacement de stockage.<\/p>\n Utilisez des politiques d\u2019acc\u00e8s adapt\u00e9es pour prot\u00e9ger votre S3 ou vos autres emplacements de stockage ou r\u00e9f\u00e9rentiels d\u2019artefacts. Recourez \u00e9galement au cryptage si possible. V\u00e9rifiez, surveillez et examinez r\u00e9guli\u00e8rement les journaux d\u2019acc\u00e8s de vos emplacements de stockage.<\/p>\n Cela semble \u00e9vident, mais ne stockez pas d’informations d’identification ou autres informations sensibles en texte clair dans les artefacts de votre build.<\/p>\n Conservez votre historique et vos journaux de build pendant plus longtemps, en particulier pour les builds qui effectuent des d\u00e9ploiements critiques, en sp\u00e9cifiant les r\u00e8gles de nettoyage<\/a> correspondantes pour votre projet. Veillez \u00e9galement \u00e0 ne pas accorder d’autorisations \u00ab\u00a0remove build\u00a0\u00bb aux d\u00e9veloppeurs car cela pourrait permettre de contourner l\u2019archivage.<\/p>\n Ces deux mesures aident \u00e0 tracer les activit\u00e9s malveillantes m\u00eame si elles ont eu lieu il y a longtemps.<\/p>\n Rassemblez les journaux du serveur TeamCity<\/a> et des agents de build<\/a> dans une archive et placez-les dans un stockage correctement s\u00e9curis\u00e9.<\/p>\n Nous avons \u00e9galement r\u00e9alis\u00e9 une version PDF de cet article, facile \u00e0 partager. N\u2019h\u00e9sitez pas \u00e0 le diffuser au sein de votre organisation : T\u00e9l\u00e9charger le PDF<\/a>.<\/p>\nAbonnez-vous au service de notifications de s\u00e9curit\u00e9<\/h3>\n
Informations d\u2019identification<\/h2>\n
Utilisez des identifiants forts et avec pr\u00e9caution<\/h3>\n
\n
Stockez vos donn\u00e9es s\u00e9curis\u00e9es avec le type de param\u00e8tre password<\/h3>\n
Utilisez un outil de gestion des secrets<\/h3>\n
Utilisez une authentification externe<\/h3>\n
Utilisez une cl\u00e9 de cryptage personnalis\u00e9e<\/h3>\n
Autorisations<\/h2>\n
Utilisez des r\u00f4les pr\u00e9d\u00e9finis<\/h3>\n
\n
Utilisez les autorisations par projet<\/h3>\n
N’activez pas la connexion en mode invit\u00e9<\/h3>\n
Cr\u00e9ez un utilisateur REST distinct<\/h3>\n
Restreignez les autorisations de build de d\u00e9ploiement<\/h3>\n
Serveur TeamCity<\/h2>\n
Prot\u00e9gez le r\u00e9pertoire de donn\u00e9es de TeamCity<\/h3>\n
Prot\u00e9gez votre serveur TeamCity<\/h3>\n
Utilisez le protocole HTTPS partout<\/h3>\n
S\u00e9curisez votre base de donn\u00e9es externe<\/h3>\n
Contr\u00f4le de version<\/h2>\n
Utilisez une version r\u00e9cente de Git<\/h3>\n
G\u00e9rez correctement vos cl\u00e9s SSH<\/h3>\n
Ayez recours \u00e0 un utilisateur VCS d\u00e9di\u00e9<\/h3>\n
Agents de build<\/h2>\n
Ex\u00e9cutez des builds de production propres<\/h3>\n
Utilisez des agents de build jetables et prot\u00e9g\u00e9s du r\u00e9seau<\/h3>\n
Utilisez des pools d\u2019agents pour vos diff\u00e9rents projets<\/h3>\n
Int\u00e9grations<\/h2>\n
\u00c9vitez de cr\u00e9er aveugl\u00e9ment des builds pour des requ\u00eates pull publiques<\/h3>\n
Soyez conscient des implications en mati\u00e8re de s\u00e9curit\u00e9 si vous utilisez des param\u00e8tres versionn\u00e9s<\/h3>\n
Attention aux plugins tiers<\/h3>\n
Stockage des artefacts<\/h2>\n
D\u00e9sactivez l\u2019acc\u00e8s anonyme<\/h3>\n
Utilisez des politiques d\u2019acc\u00e8s appropri\u00e9es<\/h3>\n
Ne placez pas de donn\u00e9es sensibles dans des artefacts<\/h3>\n
Historique et Journaux de build<\/h2>\n
Conservez l\u2019historique de vos builds<\/h3>\n
Archivez les journaux des serveurs et des agents<\/h3>\n
Partager cet article<\/h2>\n