Delen via

Website-instellingen en -beveiliging voor Azure DevOps on-premises

TFS 2017 | TFS 2015 | TFS 2013

Achtergrond

Voor veel releases zijn de standaardwebsite-instellingen voor Azure DevOps Server, voorheen Team Foundation Server (TFS), het volgende geweest:

  • Eén HTTP-binding voor de Azure DevOps Server-website op poort 8080, zonder hostnaam of IP-adres opgegeven.
  • Een openbare URL (voorheen de meldings-URL genoemd) van het formulier http://machine-name:8080/tfs.

Het belangrijkste voordeel van deze instellingen is dat ze in de meeste scenario's heel eenvoudig kunnen worden ingesteld en handig zijn voor eindgebruikers. In het bijzonder:

  • Als u HTTP gebruikt in plaats van HTTPS, hoeft u geen certificaten te verkrijgen en te installeren.
  • Als u 8080 gebruikt in plaats van 80, voorkomt u mogelijke conflicten met andere sites op dezelfde computer.
  • Door tfs te gebruiken als de virtuele map voor de site, is het eenvoudiger om Azure DevOps Server en andere websites op dezelfde poort op dezelfde server te hosten.
  • Als u de computernaam gebruikt in plaats van de volledig gekwalificeerde domeinnaam (FQDN), bespaart dat veel typen in de openbare URL.
  • Als u de hostnaam in de niet-opgegeven binding laat staan, kunt u flexibel verbinding maken: computernaam, FQDN of IP-adres werken allemaal wanneer gebruikers verbinding proberen te maken met hun servers.

Deze instellingen zijn echter niet standaard beveiligd. Met name door geen HTTPS-binding te gebruiken, wordt communicatie naar en van Azure DevOps Server tijdens overdracht niet versleuteld, tenzij andere oplossingen zoals IPSec worden gebruikt. Ze zijn dus mogelijk kwetsbaar voor kwaadwillende actoren die de inhoud van de communicatie controleren of zelfs wijzigen. Deze problemen worden beperkt tot op zekere hoogte wanneer Azure DevOps Server wordt geïmplementeerd op een intranet achter een bedrijfsfirewall, omdat de meeste Azure DevOps Server-exemplaren dat zijn. Maar zelfs in deze scenario's bevatten gegevens die worden verzonden naar en van Azure DevOps Server broncode, werkitemgegevens en andere informatie die vaak voordeel kan hebben van extra beveiliging.

Daarnaast bestaan er in TFS 2017 nieuwe verificatiescenario's (verificatie van build-/release-agentserviceaccounts, persoonlijke toegangstokens) waarmee bearertokens over de netwerkverbinding worden verzonden. Als deze tokens worden verkregen door kwaadwillende gebruikers, kunnen ze worden gebruikt om de gebruikers bij wie ze horen te imiteren.

Gezien dit alles hebben we besloten dat het tijd was om sterk te pleiten voor het gebruik van HTTPS-bindingen in Azure DevOps Server-implementaties.

Configuratie van groepen

TFS 2017 bevat configuratieopties voor website-instellingen in alle serverconfiguratiescenario's. Er zijn verschillende instellingsgroepen beschikbaar, die combinaties van sitebindingen, virtuele mappen en openbare URL's bundelen die het meest worden gebruikt. Voor scenario's waarin geen van deze instellingsgroepen geschikt is, kunnen instellingen volledig worden aangepast met behulp van het dialoogvenster Site-instellingen bewerken.

Standaardinstellingsgroep

De groep Standaardinstellingen bevat dezelfde instellingen die worden gebruikt in eerdere versies van Azure DevOps Server. Om alle bovenstaande redenen zijn deze instellingen nog steeds de standaardinstelling voor nieuwe Azure DevOps Server-implementaties. Voor bestaande implementaties proberen we bestaande instellingen te behouden. Dit leidt er vaak toe dat de standaardinstellingsgroep wordt geselecteerd.

HTTPS en HTTP met omleidingsinstellingsgroep.

De instellingsgroep HTTPS en HTTP (met omleiding) richt twee bindingen in:

  • Eén HTTPS-binding op poort 443, met de fully qualified-domain-name (FQDN) van de machine als hostnaam.
  • Eén HTTP-binding op poort 80, opnieuw met de FQDN van de computer als hostnaam.

De HTTP-binding op poort 80 wordt alleen toegevoegd als gemak voor eindgebruikers. Er wordt een omleiding zo geconfigureerd dat al het verkeer de HTTPS-binding op poort 443 gebruikt. De publieke URL voor deze instellingsgroep heeft het formaat https://fully-qualified-domain-name. Deze instellingsgroep richt standaard nieuwe zelfondertekende certificaten in en gebruikt deze voor de HTTPS-binding. We raden doorgaans niet aan zelfondertekende certificaten te gebruiken voor TFS-productie-implementaties. Zie De onderstaande certificaatopties voor meer informatie over wanneer het geschikt is om zelfondertekende certificaten te gebruiken en welke andere opties beschikbaar zijn.

De HTTPS-instellingsgroep richt één HTTPS-binding in op poort 443, met de FQDN-naam van de computer als hostnaam. Wederom is de openbare URL voor deze instellingsgroep van de vorm https://fully-qualified-domain-name, en worden zelfondertekende certificaten standaard ingericht.

De instellingsgroep ALLEEN HTTP richt één HTTP-binding in op poort 80 zonder hostnaam opgegeven. De publieke URL voor deze instellingsgroep is van de vorm http://machine-name.

Wanneer u de instellingsgroep HTTPS en HTTP (met omleiding) gebruikt, wordt het gebruik van een openbare HTTP-URL niet aanbevolen. De meeste moderne browsers beschouwen de gemengde HTTP- en HTTPS-inhoud standaard onveilig en kunnen lege pagina's weergeven. Hoewel het meestal mogelijk is om de standaardbrowserinstellingen te overschrijven en onveilige inhoud toe te staan, resulteert dit in een ervaring die vergelijkbaar is met het bladeren door een site met een verlopen SSL-certificaat.

Certificaatopties

Het implementeren van websites met HTTPS-bindingen en SSL/TLS-versleuteling is nauw verwant aan het bredere onderwerp van openbare-sleutelinfrastructuur (PKI), een uitgebreid en interessant onderwerp waarvoor al een groot aantal documentatie bestaat. We proberen hier niet alle complexiteit te behandelen, maar richten ons eerder op opties op hoog niveau voor het configureren van HTTPS-bindingen voor Azure DevOps Server-implementaties. Veel organisaties hebben specifiek beleid voor het implementeren van certificaten, dus de eerste stap bij het bepalen welk certificaat moet worden gebruikt voor een Azure DevOps Server-implementatie is vaak om te praten met een informatietechnologiegroep op organisatieniveau.

De volgende opties zijn beschikbaar:

  • De TFS-configuratiewizard toestaan om zelfondertekende certificaten te genereren voor gebruik door de implementatie.
  • Een certificaat verkrijgen van een interne certificeringsinstantie.
  • Een certificaat verkrijgen van een externe certificeringsinstantie.

Zelfondertekende certificaten

Zelfondertekende certificaten zijn handig voor proefimplementaties van Azure DevOps Server, omdat ze zeer eenvoudig kunnen worden ingericht en gebruikt. Ze zijn minder geschikt voor productie-implementaties van Azure DevOps Server en we raden u niet aan ze te gebruiken voor Azure DevOps Server-implementaties die beschikbaar zijn voor het openbare internet. Over het algemeen zijn zelfondertekende certificaten vatbaar voor man-in-the-middle-aanvallen. Ze veroorzaken ook problemen voor gebruikers, omdat ze certificaatwaarschuwingen en -fouten veroorzaken totdat hun basiscertificaten op elke clientcomputer zijn geïnstalleerd. In de Edge-browser wordt bijvoorbeeld de onderstaande fout weergegeven.

Certificaatfouten in Edge.

Wanneer de TFS-configuratiewizard zelfondertekende certificaten voor uw implementatie genereert, worden er twee gemaakt. Een die wordt geplaatst in de store Vertrouwde Basiscertificeringsinstanties op de server en een tweede, ondertekend door de eerste, die wordt geplaatst in de persoonlijke store op de server en wordt gebruikt door Azure DevOps Server. Door dingen op deze manier in te stellen, kunt u de mogelijkheid van man-in-the-middle-aanvallen beperken en het certificaat dat in de HTTPS-binding wordt gebruikt, roteren zonder dat u ook een nieuw certificaat naar alle clients hoeft te distribueren om certificaatfouten te voorkomen, zoals hierboven wordt weergegeven.

Als u deze certificaatwaarschuwingen en -fouten wilt voorkomen, kunt u het basiscertificaat exporteren en installeren op clientcomputers. U kunt dit op verschillende manieren doen, waaronder:

Interne en externe certificeringsinstanties

Veel grote organisaties hebben hun eigen openbare-sleutelinfrastructuur en kunnen certificaten uitgeven van hun eigen certificeringsinstanties. Wanneer dit het geval is, worden de vertrouwde basiscertificaten voor deze autoriteiten doorgaans al gedistribueerd naar clientcomputers, waardoor er geen extra certificaten voor Azure DevOps Server hoeven te worden gedistribueerd. Als uw organisatie een eigen openbare-sleutelinfrastructuur heeft, kan dit een goede optie zijn voor uw Azure DevOps Server-implementatie.

Wanneer andere opties niet geschikt of beschikbaar zijn, kunnen certificaten worden verkregen (meestal tegen kosten) van een externe certificeringsinstantie (CA). Instructies voor dit proces, dat begint met het maken van een certificaatondertekeningsaanvraag, vindt u op de meeste CA-websites. Enkele belangrijke opmerkingen:

  • Zorg ervoor dat de algemene naam die is opgegeven in de certificaataanvraag overeenkomt met de hostnaam die u wilt gebruiken in uw openbare URL, bijvoorbeeld tfs.contoso.com.
  • In de eigenschappen van de cryptografische serviceprovider wordt u aangeraden Microsoft RSA SChannel Cryptographic Provider en een bitlengte van 2048 of hoger te selecteren.

Uw openbare URL wijzigen

Er moet ook worden opgemerkt dat bij het upgraden van een bestaande Azure DevOps Server-implementatie het wijzigen van de openbare URL van invloed is op eindgebruikers. Hoewel we nog steeds aanraden om over te stappen van HTTP naar HTTPS-bindingen, moeten Visual Studio-clientverbindingen opnieuw worden ingesteld, en zullen oude bladwijzers niet langer correct functioneren, enzovoort. Het is daarom belangrijk om dit soort wijzigingen te coördineren met de gebruikers van uw Azure DevOps Server-implementatie om aanzienlijke onderbrekingen te voorkomen.

  • Last updated on