Nastavení webu a zabezpečení pro Azure DevOps v místním prostředíWeb site settings and security for Azure DevOps on-premises

TFS 2017 | TFS 2015 | TFS 2013TFS 2017 | TFS 2015 | TFS 2013

PozadíBackground

Pro mnoho verzí bylo výchozí nastavení webu pro Azure DevOps Server, dříve pojmenované Team Foundation Server (TFS):For many releases, the default web site settings for Azure DevOps Server, previously named Team Foundation Server (TFS), have been:

  • Jedna vazba HTTP pro Azure DevOps Server Web na portu 8080 bez zadaného názvu hostitele nebo IP adresy.A single HTTP binding for the Azure DevOps Server web site on port 8080, with no host name or IP address specified.
  • Veřejná adresa URL (dříve označovaná jako adresa URL oznámení) formuláře http://machine-name:8080/tfs .A public URL (previously referred to as the Notification URL) of the form http://machine-name:8080/tfs.

Hlavní výhodou těchto nastavení je, že pro většinu scénářů je velmi jednoduché nastavit a pohodlně pro koncové uživatele.The primary benefit of these settings is that they are very simple to set up and convenient for end users in most scenarios. Zejména jde o toto:In particular:

  • Použití protokolu HTTP místo protokolu HTTPS zabraňuje nutnosti získat a nainstalovat certifikáty.Using HTTP rather than HTTPS avoids the need to obtain and install certificates.
  • Použití 8080 namísto 80 zabraňuje potenciálním konfliktům s jinými lokalitami ve stejném počítači.Using 8080 rather than 80 avoids potential conflicts with other sites on the same machine.
  • Použití "TFS" jako virtuálního adresáře pro lokalitu usnadňuje hostování Azure DevOps Server a dalších webů na stejném portu na stejném serveru.Using "tfs" as the virtual directory for the site makes it easier to host Azure DevOps Server and other web sites on the same port on the same server.
  • Použití názvu počítače místo plně kvalifikovaného názvu domény (FQDN) ve veřejné adrese URL ukládá spoustu psaní.Using the machine name, rather than the fully-qualified-domain-name (FQDN), in the public URL saves a lot of typing.
  • Když název hostitele v nespecifikované vazbě neurčíte, umožní vám to flexibilita při připojování – název počítače, plně kvalifikovaný název domény nebo IP adresa budou všechny fungovat, když se uživatelé pokusí připojit ke svým serverům.Leaving the host name in the binding unspecified allows for flexibility in connecting - machine name, FQDN, or IP address will all work when users try to connect to their servers.

Tato nastavení ale ve výchozím nastavení nejsou bezpečná.These settings are not, however, secure by default. Konkrétně nepoužíváte-li vazbu HTTPS, komunikace do a z Azure DevOps Server není šifrována při přenosu, pokud se nepoužívají jiná řešení jako IPSec.In particular, by not using an HTTPS binding, communication to and from Azure DevOps Server is not encrypted in transit unless other solutions like IPSec are used. V důsledku toho mohou být ohroženy monitorováním škodlivých aktérů nebo dokonce úpravou obsahu komunikace.They are thus potentially vulnerable to malicious actors monitoring or even modifying the contents of the communication. Tyto problémy se v některých případech sníží, když Azure DevOps Server nasazené na intranetu za podnikovou bránou firewall, protože je to velká většina Azure DevOps Server instancí.These issues are mitigated to some extent when Azure DevOps Server is deployed on an intranet behind a corporate firewall, as the vast majority of Azure DevOps Server instances are. I v těchto scénářích ale data odesílaná do a z Azure DevOps Server zahrnují zdrojový kód, data pracovní položky a další informace, které by mohly často těžit z dalšího zabezpečení.But even in these scenarios, data sent to and from Azure DevOps Server includes source code, work item data, and other information which could often benefit from additional security.

Kromě toho v TFS 2017 existují nové scénáře ověřování (ověřování účtu služby Agent sestavení a vydání, tokeny osobních přístupů), které odesílají nosiče nosných tokenů po drátě.Additionally, in TFS 2017 new authentication scenarios exist (build/release agent service account authentication, personal access tokens) which send bearer tokens over the wire. Pokud jsou tyto tokeny získány uživateli se zlými úmysly, mohou být použity k zosobnění uživatelů, ke kterým patří.If these tokens are obtained by malicious users, they can then be used to impersonate the users to whom they belong.

Z tohoto důvodu jsme se rozhodli, že čas měl přicházet k efektivnějšímu Poradce při použití vazeb HTTPS v nasazeních Azure DevOps Server.Given all of this, we decided the time had come to more strongly advocate for the use of HTTPS bindings in Azure DevOps Server deployments.

Nastavení skupinSetting groups

TFS 2017 nabízí možnosti konfigurace nastavení webu ve všech scénářích konfigurace serveru.TFS 2017 presents web site settings configuration options in all server configuration scenarios. Je k dispozici několik skupin nastavení, které seskupují kombinace vazeb webu, virtuálních adresářů a veřejných adres URL, které doporučujeme a že se domníváte, že budou nejčastěji použity.Several setting groups are provided, which bundle up combinations of site bindings, virtual directories, and public URLs which we recommend and believe will be most commonly used. V případě scénářů, kde není žádná z těchto skupin nastavení vhodná, lze nastavení plně přizpůsobit pomocí dialogového okna Upravit nastavení webu.For scenarios where none of these setting groups are appropriate, settings can be fully customized using the Edit Site Settings dialog.

Default setting group

Výchozí skupina nastavení zahrnuje stejná nastavení, která se používají v předchozích verzích Azure DevOps Server.The Default setting group includes the same settings used in previous versions of Azure DevOps Server. U všech výše uvedených důvodů jsou tato nastavení pro nová Azure DevOps Server nasazení stále výchozí.For all of the reasons listed above, these settings are still the default for new Azure DevOps Server deployments. U existujících nasazení se pokusíme zachovat stávající nastavení, což často vede k výběru výchozí skupiny nastavení.For existing deployments, we will attempt to preserve existing settings, which will often result in the Default setting group being selected.

HTTPS and HTTP with redirect setting group

Skupina nastavení HTTPS a HTTP (s přesměrováním) zřídí dvě vazby:The HTTPS and HTTP (with redirect) setting group provisions two bindings:

  • Jedna vazba HTTPS na portu 443 s plně kvalifikovaným názvem domény (FQDN) počítače jako název hostitele.One HTTPS binding on port 443, with the fully-qualified-domain-name (FQDN) of the machine as the Host Name.
  • Jedna vazba HTTP na portu 80 znovu s plně kvalifikovaným názvem domény počítače jako s názvem hostitele.One HTTP binding on port 80, again with the FQDN of the machine as the Host Name.

Vazby HTTP na portu 80 se přidávají jenom jako pohodlí pro koncové uživatele – přesměrování se nakonfiguruje tak, aby veškerý provoz skončil s použitím vazby HTTPS na portu 443.The HTTP binding on port 80 is added only as a convenience for end users - a redirect is configured so that all traffic ends up using the HTTPS binding on port 443. Veřejná adresa URL pro tuto skupinu nastavení má formu https://fully-qualified-domain-name .The Public URL for this setting group is of the form https://fully-qualified-domain-name. Ve výchozím nastavení tato skupina nastavení zřídí nové certifikáty podepsané svým držitelem a bude je používat pro vazbu HTTPS.By default, this setting group will provision new self-signed certificates and use them for the HTTPS binding. Pro produkční nasazení TFS obvykle nedoporučujeme používat certifikáty podepsané svým držitelem.We do not typically recommend using self-signed certificates for production TFS deployments. Další informace o tom, kdy je vhodné používat certifikáty podepsané svým držitelem a jaké další možnosti jsou k dispozici, najdete v části možnosti certifikátu níže.See Certificate Options below for more information on when it is appropriate to use self-signed certificates and what other options are available.

Skupina nastavení pouze HTTPS zřídí jednu vazbu HTTPS na portu 443, přičemž plně kvalifikovaný název domény počítače jako název hostitele.The HTTPS only setting group provisions a single HTTPS binding on port 443, with the FQDN of the machine as the Host Name. Znovu platí, že veřejná adresa URL pro tuto skupinu nastavení je ve formátu https://fully-qualified-domain-name a ve výchozím nastavení budou zřízeny certifikáty podepsané svým držitelem.Again, the Public URL for this setting group is of the form https://fully-qualified-domain-name, and self-signed certificates will be provisioned by default.

Skupina nastavení pouze protokolu HTTP zřídí jednu vazbu HTTP na portu 80 bez zadaného názvu hostitele.The HTTP Only setting group provisions a single HTTP binding on port 80 with no Host Name specified. Veřejná adresa URL pro tuto skupinu nastavení má formu http://machine-name .The Public URL for this setting group is of the form http://machine-name.

Možnosti certifikátuCertificate options

Nasazení webů pomocí vazeb HTTPS a šifrování SSL/TLS úzce souvisí s širším tématem infrastruktury veřejných klíčů (PKI), což je obsáhlé a zajímavé téma, pro které už existuje celá řada dokumentace.Deploying web sites using HTTPS bindings and SSL/TLS encryption is closely related to the broader topic of public key infrastructure (PKI), which is a rich and interesting topic for which a wide variety of documentation already exists. V tomto případě se nebudeme snažit pokrýt veškerou složitost, ale místo toho se budou zaměřit na možnosti vysoké úrovně pro konfiguraci vazeb HTTPS pro nasazení Azure DevOps Server.We will not attempt to cover all of the complexity here, but rather will focus on high level options for configuring HTTPS bindings for Azure DevOps Server deployments. Mnoho organizací má konkrétní zásady týkající se nasazení certifikátů. proto je prvním krokem při rozhodování o tom, jaký certifikát pro Azure DevOps Server nasazení má, často komunikovat se skupinou informačních technologií na úrovni organizace.Many organizations have specific policies around deploying certificates, so the first step in deciding what certificate to use for a Azure DevOps Server deployment is often to talk with an organization-level information technology group.

Vaše možnosti jsou:Options include:

  • Povolení Průvodce konfigurací TFS generovat certifikáty podepsané svým držitelem pro použití v nasazení.Allowing the TFS configuration wizard to generate self-signed certificates for use by the deployment.
  • Získání certifikátu od interní certifikační autority.Obtaining a certificate from an internal Certificate Authority.
  • Získání certifikátu od externí certifikační autority.Obtaining a certificate from an external Certificate Authority.

Certifikáty podepsané svým držitelemSelf-signed certificates

Certifikáty podepsané svým držitelem jsou užitečné pro zkušební nasazení Azure DevOps Server, protože je velmi snadné je zřídit a používat.Self-signed certificates are useful for trial deployments of Azure DevOps Server, since they are very easy to provision and use. Jsou méně vhodné pro produkční nasazení Azure DevOps Server a nedoporučujeme je používat pro Azure DevOps Server nasazení vystavená veřejnému Internetu.They are less appropriate for production deployments of Azure DevOps Server, and we do not recommend they be used for Azure DevOps Server deployments exposed to the public internet. Obecně platí, že certifikáty podepsané svým držitelem jsou náchylné k útokům prostředníkem.Generally, self-signed certificates are susceptible to man-in-the-middle attacks. Můžou taky způsobovat problémy uživatelům, protože způsobí upozornění a chyby certifikátů, dokud se na každém klientském počítači nenainstaluje jejich kořenové certifikáty.They also cause problems for users, since they will cause certificate warnings and errors until their root certificates are installed on each client machine. Například prohlížeč Edge zobrazí níže uvedenou chybu.For example, the Edge browser will show the below error.

Certificate errors in Edge

Když Průvodce konfigurací TFS generuje certifikáty podepsané svým držitelem pro vaše nasazení, vytvoří dva-jeden, který je umístěn v úložišti důvěryhodných kořenových certifikačních autorit na serveru, a druhý, podepsaný první, který je umístěn v osobním úložišti na serveru a používá Azure DevOps Server.When the TFS configuration wizard generates self-signed certificates for your deployment, it will create two - one that is placed in the Trusted Root Certification Authorities store on the server, and a second, signed by the first, that is placed in the Personal store on the server and used by Azure DevOps Server. Nastavení možností tímto způsobem pomáhá zmírnit možnost útoků prostředníkem a umožňuje rotaci certifikátu používaného ve vazbě HTTPS bez nutnosti distribuovat nový certifikát všem klientům, aby se předešlo chybám certifikátu, jako je ten, který je uvedený výše.Setting things up in this way helps to mitigate the possibility of man-in-the-middle attacks and enables rotation of the certificate used in the HTTPS binding without also needing to distribute a new certificate to all clients in order to avoid certificate errors like the one shown above.

Aby se předešlo upozorněním a chybám certifikátů, můžete kořenový certifikát exportovat a nainstalovat ho do klientských počítačů.To avoid those certificate warnings and errors, you can export the root certificate and install it on client machines. To lze provést několika způsoby, včetně těchto:There are several ways to accomplish this, including:

  • Použití modulu snap-in Certifikáty konzoly MMC k ručnímu exportu certifikátu na serveru a jeho následném importu do každého klienta.Using the Certificates MMC snap-in to manually export the certificate on the server and then import it on each client.
  • Pomocí rutiny PowerShellu Export-Certificate dostupné v systému Windows 8/Windows Server 2012 a novějších operačních systémech exportujte certifikát.Using the Export-Certificate powershell cmdlet, available in Windows 8 / Windows Server 2012 and later operating systems, to export the certificate. Import-Certificate se pak dá použít k jeho importu do každého klienta.Import-Certificate can then be used to import it on each client.
  • Použití Zásady skupiny k automatizaci distribuce do klientů.Using Group Policy to automate distribution to clients.

Interní a externí certifikační autorityInternal and external Certificate Authorities

Mnoho velkých organizací má svou vlastní infrastrukturu veřejných klíčů a dokáže vystavovat certifikáty od vlastních certifikačních autorit.Many large organizations have their own public key infrastructure, and are able to issue certificates from their own Certificate Authorities. Obvykle platí, že pokud se jedná o tento případ, důvěryhodné kořenové certifikáty pro tyto úřady již budou distribuovány do klientských počítačů, čímž se vyhnete nutnosti distribuovat další certifikáty pro Azure DevOps Server.Typically, when this is the case, the trusted root certificates for these authorities will already be distributed to client machines, thus avoiding the need to distribute additional certificates for Azure DevOps Server. Pokud má vaše organizace vlastní infrastrukturu veřejných klíčů, může to být pro nasazení Azure DevOps Server dobrá možnost.If your organization has its own public key infrastructure, this can be a good option for your Azure DevOps Server deployment.

Pokud nejsou k dispozici žádné další možnosti nebo k dispozici, mohou se certifikáty získat (obvykle za cenu) od externí certifikační autority (CA).When other options are not appropriate or available, certificates may be obtained (typically at a cost) from an external Certificate Authority (CA). Pokyny pro tento proces, které začínají vytvořením žádosti o podepsání certifikátu, najdete na většině webů CA.Instructions for this process, which starts with creating a Certificate Signing Request, can be found on most CA websites. Některé důležité poznámky:Some important notes:

  • Ujistěte se, že běžný název uvedený v žádosti o certifikát se shoduje s názvem hostitele, který požadujete ve veřejné adrese URL – například tfs.contoso.com.Make sure that the Common Name provided in the certificate request matches up with the host name you want in your public URL - for example, tfs.contoso.com.
  • Ve vlastnostech zprostředkovatele kryptografických služeb doporučujeme vybrat Microsoft RSA SChannel Cryptographic Provider a bitovou délku 2048 nebo vyšší.On the Cryptographic Service Provider Properties, we recommend selecting Microsoft RSA SChannel Cryptographic Provider and a bit length of 2048 or greater.

Změna veřejné adresy URLChanging your public URL

Mělo by se také poznamenat, že při upgradu stávajícího nasazení Azure DevOps Server bude změna veřejné adresy URL mít vliv na koncové uživatele.It should also be noted that when upgrading an existing Azure DevOps Server deployment, changing the public URL will impact end users. I když stále doporučujeme převádět z vazeb HTTP na HTTPS, připojení klientů sady Visual Studio bude nutné znovu navázat, staré záložky nebudou nadále vyřešeny, a tak dále.While we do still recommend converting from HTTP to HTTPS bindings, Visual Studio client connections will need to be re-established, old bookmarks will no longer resolve properly, and so forth. Je proto důležité, abyste tento druh změny koordinovali s uživateli nasazení Azure DevOps Server, aby se předešlo výraznému výpadku.It is therefore important to coordinate this sort of change with the users of your Azure DevOps Server deployment to avoid significant disruption.