Paramètres et sécurité du site web pour Azure DevOps localement

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és 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ée.
• URL publique (précédemment appelée URL de notification) du formulaire http://machine-name:8080/tfs.

L’avantage principal 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 la nécessité d’obtenir et d’installer des certificats.
• L’utilisation de 8080 plutôt que de 80 évite les conflits potentiels avec d’autres sites sur le même ordinateur.
• 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 enregistre un grand nombre de saisies.
• Le fait de laisser le nom d’hôte dans la liaison non spécifiée permet une 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 comme IPSec sont utilisées. Ils sont donc potentiellement vulnérables aux acteurs malveillants qui surveillent ou modifient même 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, car la grande majorité des instances de Azure DevOps Server sont. Toutefois, même dans ces scénarios, les données envoyées à et depuis Azure DevOps Server incluent le code source, les données d’élément de travail et d’autres informations qui pourraient souvent bénéficier d’une sécurité supplémentaire.

En outre, dans TFS 2017, de nouveaux scénarios d’authentification existent (l’authentification du compte de service de l’agent de build/mise en production, les jetons d’accès personnels) 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 temps était venu plus fortement préconiser l’utilisation de liaisons HTTPS dans Azure DevOps Server déploiements.

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 que nous recommandons et croient être 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 le site Paramètres.

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 sont toujours la valeur par défaut pour les nouveaux déploiements de 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 de 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 en tant que nom d’hôte.
• Une liaison HTTP sur le port 80, à nouveau 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 afin 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 vous déconseillons généralement d’utiliser des certificats auto-signés pour les déploiements TFS de production. Consultez les 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 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 du formulaire https://fully-qualified-domain-nameet les certificats auto-signés sont approvisionnés par défaut.

Le groupe de paramètres HTTP uniquement provisionne 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 prennent en compte 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 de navigateur par défaut et d’autoriser le contenu non sécurisé, cela entraîne une expérience similaire à la navigation d’un site avec un certificat SSL expiré.

Options de certificat

Le déploiement de sites web à l’aide de liaisons HTTPS et du chiffrement SSL/TLS est étroitement lié à la rubrique plus large de l’infrastructure à clé publique (PKI), qui est une rubrique riche et intéressante pour laquelle 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 les options générales de configuration des liaisons HTTPS pour les déploiements Azure DevOps Server. De nombreuses organisations ont des stratégies spécifiques concernant le déploiement de certificats. La première étape consiste donc à décider quel certificat utiliser pour un déploiement de Azure DevOps Server est souvent de communiquer avec un groupe de technologies de l’information au niveau de l’organisation.

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 de Azure DevOps Server, et nous ne recommandons pas qu’ils soient utilisés pour Azure DevOps Server déploiements exposés à l’Internet public. En règle générale, les certificats auto-signés sont vulnérables aux attaques de l’intercepteur. Ils provoquent également des problèmes pour les utilisateurs, car ils provoquent des avertissements et des erreurs de certificat jusqu’à ce que leurs certificats racines 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 crée deux : un qui est placé dans le magasin autorités de certification racines de confiance sur le serveur, et une seconde, signée par le premier, qui est placé dans le magasin personnel sur le serveur et utilisé par Azure DevOps Server. La configuration des éléments de cette façon permet d’atténuer la possibilité d’attaques de l’intercepteur et d’activer la rotation du certificat utilisé dans la liaison HTTPS sans avoir également besoin de 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 Windows 8/Windows Server 2012 et les systèmes d’exploitation 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 peuvent émettre des certificats auprès de leurs propres autorités de certification. En règle générale, lorsqu’il s’agit du cas, les certificats racines approuvés pour ces autorités sont déjà distribués aux ordinateurs clients, ce qui évite de devoir distribuer des certificats supplémentaires pour Azure DevOps Server. Si votre organisation dispose de 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, les certificats peuvent être obtenus (généralement à un coût) auprès d’une autorité de certification externe. Vous trouverez des instructions pour ce processus, qui commence par la création d’une demande de signature de certificat, sur la plupart des sites web d’autorité de certification. Remarques importantes :

• Vérifiez 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.
• Dans les propriétés du fournisseur de services de chiffrement, nous vous recommandons de sélectionner microsoft RSA SChannel Cryptographic Provider et une longueur de bits de 2048 ou supérieure.

Modification de votre URL publique

Notez également 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, Visual Studio connexions clientes 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 modification avec les utilisateurs de votre déploiement Azure DevOps Server afin d’éviter une interruption importante.