Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
TFS 2017 | TFS 2015 | TFS 2013
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 :
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 :
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.
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 :
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é.
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 :
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 :
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 :
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.
Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantEntrainement
Module
Configurer les paramètres de l’application web - Training
Configurer les paramètres de l’application web
Certification
Microsoft Certified: Information Security Administrator Associate(beta) - Certifications
As an Information Security Administrator, you plan and implement information security of sensitive data by using Microsoft Purview and related services. You’re responsible for mitigating risks by protecting data inside collaboration environments that are managed by Microsoft 365 from internal and external threats and protecting data used by AI services. You also implement information protection, data loss prevention, retention, insider risk management, and manage information security alerts and activities.