Paramètres de site web et sécurité pour Azure DevOps local

TFS 2017 | TFS 2015 | TFS 2013

Arrière-plan

Pour de nombreuses versions, les paramètres de site web par défaut pour Azure DevOps Server, précédemment nommé Team Foundation Server (TFS), ont été les suivants :

• Liaison HTTP unique pour le site web Azure DevOps Server sur le port 8080, sans nom d’hôte ni adresse IP spécifiés.
• URL publique (précédemment appelée URL de notification) du formulaire http://machine-name:8080/tfs.

Le principal avantage de ces paramètres est qu’ils sont très simples à configurer et pratiques pour les utilisateurs finaux dans la plupart des scénarios. En particulier :

• L’utilisation de HTTP plutôt que HTTPS évite d’avoir à obtenir et à installer des certificats.
• L’utilisation de 8080 plutôt que de 80 évite les conflits potentiels avec d’autres sites sur la même machine.
• L’utilisation de « tfs » comme répertoire virtuel pour le site facilite l’hébergement de Azure DevOps Server et d’autres sites web sur le même port sur le même serveur.
• L’utilisation du nom de l’ordinateur plutôt que du nom de domaine complet (FQDN) dans l’URL publique permet d’économiser beaucoup de saisie.
• Le fait de laisser le nom d’hôte dans la liaison non spécifié offre une certaine flexibilité dans la connexion : le nom de l’ordinateur, le nom de domaine complet ou l’adresse IP fonctionnent tous lorsque les utilisateurs essaient de se connecter à leurs serveurs.

Toutefois, ces paramètres ne sont pas sécurisés par défaut. En particulier, en n’utilisant pas de liaison HTTPS, la communication vers et depuis Azure DevOps Server n’est pas chiffrée en transit, sauf si d’autres solutions telles que IPSec sont utilisées. Ils sont donc potentiellement vulnérables aux acteurs malveillants qui surveillent ou même modifient le contenu de la communication. Ces problèmes sont atténués dans une certaine mesure lorsque Azure DevOps Server est déployé sur un intranet derrière un pare-feu d’entreprise, comme le sont la grande majorité des instances de Azure DevOps Server. Mais même dans ces scénarios, les données envoyées vers et à partir de Azure DevOps Server incluent le code source, les données d’élément de travail et d’autres informations qui peuvent souvent bénéficier d’une sécurité supplémentaire.

En outre, dans TFS 2017, de nouveaux scénarios d’authentification existent (authentification du compte de service de l’agent de génération/mise en production, jetons d’accès personnel) qui envoient des jetons du porteur sur le réseau. Si ces jetons sont obtenus par des utilisateurs malveillants, ils peuvent ensuite être utilisés pour emprunter l’identité des utilisateurs auxquels ils appartiennent.

Compte tenu de tout cela, nous avons décidé que le moment était venu de plaider plus fermement pour l’utilisation de liaisons HTTPS dans les déploiements Azure DevOps Server.

Définition de groupes

TFS 2017 présente les options de configuration des paramètres de site web dans tous les scénarios de configuration de serveur. Plusieurs groupes de paramètres sont fournis, qui regroupent des combinaisons de liaisons de site, de répertoires virtuels et d’URL publiques qui, selon nous, seront les plus couramment utilisées. Pour les scénarios où aucun de ces groupes de paramètres n’est approprié, les paramètres peuvent être entièrement personnalisés à l’aide de la boîte de dialogue Modifier les paramètres du site.

Le groupe de paramètres par défaut inclut les mêmes paramètres que ceux utilisés dans les versions précédentes de Azure DevOps Server. Pour toutes les raisons répertoriées ci-dessus, ces paramètres restent la valeur par défaut pour les nouveaux déploiements Azure DevOps Server. Pour les déploiements existants, nous tenterons de conserver les paramètres existants, ce qui entraîne souvent la sélection du groupe paramètres par défaut.

Le groupe de paramètres HTTPS et HTTP (avec redirection) provisionne deux liaisons :

• Une liaison HTTPS sur le port 443, avec le nom de domaine complet (FQDN) de l’ordinateur comme nom d’hôte.
• Une liaison HTTP sur le port 80, toujours avec le nom de domaine complet de l’ordinateur comme nom d’hôte.

La liaison HTTP sur le port 80 est ajoutée uniquement pour les utilisateurs finaux . Une redirection est configurée pour que tout le trafic finisse par utiliser la liaison HTTPS sur le port 443. L’URL publique de ce groupe de paramètres est de la forme https://fully-qualified-domain-name. Par défaut, ce groupe de paramètres provisionne de nouveaux certificats auto-signés et les utilise pour la liaison HTTPS. Nous ne recommandons généralement pas d’utiliser des certificats auto-signés pour les déploiements TFS de production. Consultez Options de certificat ci-dessous pour plus d’informations sur le moment où il est approprié d’utiliser des certificats auto-signés et les autres options disponibles.

Le groupe de paramètres HTTPS uniquement provisionne une seule liaison HTTPS sur le port 443, avec le nom de domaine complet de l’ordinateur comme nom d’hôte. Là encore, l’URL publique de ce groupe de paramètres est de la forme https://fully-qualified-domain-name, et les certificats auto-signés sont provisionnés par défaut.

Le groupe de paramètres HTTP uniquement approvisionne une seule liaison HTTP sur le port 80 sans nom d’hôte spécifié. L’URL publique de ce groupe de paramètres est de la forme http://machine-name.

Lorsque vous utilisez le groupe de paramètres HTTPS et HTTP (avec redirection), l’utilisation d’une URL publique HTTP n’est pas recommandée. La plupart des navigateurs modernes considèrent le contenu HTTP et HTTPS mixte non sécurisé par défaut et peuvent afficher des pages vides. Bien qu’il soit généralement possible de remplacer les paramètres du navigateur par défaut et d’autoriser le contenu non sécurisé, cela entraîne une expérience similaire à la navigation sur un site avec un certificat SSL expiré.

Options de certificat

Le déploiement de sites web à l’aide de liaisons HTTPS et de chiffrement SSL/TLS est étroitement lié à la rubrique plus large de l’infrastructure à clé publique (PKI), qui est un sujet riche et intéressant pour lequel une grande variété de documentation existe déjà. Nous ne tenterons pas de couvrir toute la complexité ici, mais nous nous concentrerons plutôt sur des options de haut niveau pour la configuration des liaisons HTTPS pour les déploiements Azure DevOps Server. De nombreuses organisations ont des stratégies spécifiques concernant le déploiement des certificats. Par conséquent, la première étape pour décider du certificat à utiliser pour un déploiement de Azure DevOps Server consiste souvent à parler avec un groupe de technologies de l’information de niveau organization.

Options disponibles :

• Autoriser l’Assistant Configuration TFS à générer des certificats auto-signés à utiliser par le déploiement.
• Obtention d’un certificat auprès d’une autorité de certification interne.
• Obtention d’un certificat auprès d’une autorité de certification externe.

Certificats auto-signés

Les certificats auto-signés sont utiles pour les déploiements d’évaluation de Azure DevOps Server, car ils sont très faciles à provisionner et à utiliser. Ils sont moins appropriés pour les déploiements de production d’Azure DevOps Server, et nous vous déconseillons d’en utiliser pour les déploiements Azure DevOps Server exposés à l’Internet public. En règle générale, les certificats auto-signés sont sensibles aux attaques de l’homme du milieu. Elles entraînent également des problèmes pour les utilisateurs, car elles entraînent des avertissements et des erreurs de certificat jusqu’à ce que leurs certificats racine soient installés sur chaque ordinateur client. Par exemple, le navigateur Edge affiche l’erreur ci-dessous.

Lorsque l’Assistant Configuration TFS génère des certificats auto-signés pour votre déploiement, il en crée deux : l’un placé dans le magasin Autorités de certification racines de confiance sur le serveur et un second, signé par le premier, qui est placé dans le magasin Personnel sur le serveur et utilisé par Azure DevOps Server. La configuration de cette façon permet d’atténuer le risque d’attaques par l’homme du milieu et permet la rotation du certificat utilisé dans la liaison HTTPS sans avoir à distribuer un nouveau certificat à tous les clients afin d’éviter les erreurs de certificat comme celle illustrée ci-dessus.

Pour éviter ces avertissements et erreurs de certificat, vous pouvez exporter le certificat racine et l’installer sur les ordinateurs clients. Il existe plusieurs façons d’y parvenir, notamment :

• Utilisation du composant logiciel enfichable MMC Certificats pour exporter manuellement le certificat sur le serveur, puis l’importer sur chaque client.
• À l’aide de l’applet de commande PowerShell Export-Certificate, disponible dans les systèmes d’exploitation Windows 8/Windows Server 2012 et ultérieurs, pour exporter le certificat. Import-Certificate peut ensuite être utilisé pour l’importer sur chaque client.
• Utilisation de stratégie de groupe pour automatiser la distribution aux clients.

Autorités de certification internes et externes

De nombreuses grandes organisations disposent de leur propre infrastructure à clé publique et sont en mesure d’émettre des certificats à partir de leurs propres autorités de certification. En règle générale, lorsque c’est le cas, les certificats racines approuvés pour ces autorités sont déjà distribués sur les ordinateurs clients, ce qui évite d’avoir à distribuer des certificats supplémentaires pour Azure DevOps Server. Si votre organization a sa propre infrastructure à clé publique, cela peut être une bonne option pour votre déploiement Azure DevOps Server.

Lorsque d’autres options ne sont pas appropriées ou disponibles, des certificats peuvent être obtenus (généralement à un coût) auprès d’une autorité de certification externe. Les instructions pour ce processus, qui commence par la création d’une demande de signature de certificat, sont disponibles sur la plupart des sites web de l’autorité de certification. Remarques importantes :

• Assurez-vous que le nom commun fourni dans la demande de certificat correspond au nom d’hôte souhaité dans votre URL publique, par exemple, tfs.contoso.com.
• Sur les propriétés du fournisseur de services de chiffrement, nous vous recommandons de sélectionner Fournisseur de chiffrement SChannel Microsoft RSA et une longueur de bits de 2048 ou plus.

Modification de votre URL publique

Il convient également de noter que lors de la mise à niveau d’un déploiement de Azure DevOps Server existant, la modification de l’URL publique aura un impact sur les utilisateurs finaux. Bien que nous vous recommandons toujours de convertir des liaisons HTTP en HTTPS, les connexions clientes Visual Studio devront être rétablies, les anciens signets ne seront plus résolus correctement, et ainsi de suite. Il est donc important de coordonner ce type de changement avec les utilisateurs de votre déploiement Azure DevOps Server afin d’éviter une interruption importante.