Sdílet prostřednictvím


Nastavení a zabezpečení webu pro místní Azure DevOps

TFS 2017 | TFS 2015 | TFS 2013

Pozadí

V mnoha verzích bylo výchozí nastavení webu pro Azure DevOps Server, které se dříve jmenovalo Team Foundation Server (TFS), následující:

  • Jedna vazba HTTP pro web Azure DevOps Server na portu 8080 bez zadaného názvu hostitele nebo IP adresy.
  • Veřejná adresa URL (dříve označovaná jako adresa URL oznámení) formuláře http://machine-name:8080/tfs.

Hlavní výhodou těchto nastavení je, že jsou velmi jednoduchá na nastavení a jsou ve většině scénářů vhodná pro koncové uživatele. Zejména jde o toto:

  • Při použití protokolu HTTP místo HTTPS se vyhnete nutnosti získávat a instalovat certifikáty.
  • Pokud použijete 8080 místo 80, vyhnete se potenciálním konfliktům s jinými weby na stejném počítači.
  • Použití "tfs" jako virtuálního adresáře pro web usnadňuje hostování Azure DevOps Server a dalších webů na stejném portu na stejném serveru.
  • Použití názvu počítače místo plně kvalifikovaného názvu domény (FQDN) ve veřejné adrese URL ušetří spoustu psaní.
  • Ponechání názvu hostitele v nezadané vazbě umožňuje flexibilitu při připojování – název počítače, plně kvalifikovaný název domény nebo IP adresa budou fungovat, když se uživatelé pokusí připojit ke svým serverům.

Tato nastavení ale nejsou ve výchozím nastavení zabezpečená. Zejména pokud nepoužíváte vazbu HTTPS, komunikace do a z Azure DevOps Server se při přenosu nešifruje, pokud se nepoužívají jiná řešení, jako je IPSec. Jsou tak potenciálně ohroženi aktéry se zlými úmysly, kteří monitorují nebo dokonce upravují obsah komunikace. Tyto problémy jsou do určité míry zmírněny, když se Azure DevOps Server nasadí na intranet za podnikovou bránou firewall, stejně jako velká většina Azure DevOps Server instancí. I v těchto scénářích ale data odesílaná do a z Azure DevOps Server zahrnují zdrojový kód, data pracovních položek a další informace, které můžou často těžit z dalšího zabezpečení.

Kromě toho v TFS 2017 existují nové scénáře ověřování (ověřování účtu služby sestavení/vydání agenta, osobní přístupové tokeny), které odesílají nosné tokeny po drátě. Pokud tyto tokeny získají uživatelé se zlými úmysly, můžete je použít k zosobnění uživatelů, kterým patří.

Vzhledem k tomu všemu jsme se rozhodli, že nastal čas důrazněji se zasadíme o použití vazeb HTTPS v Azure DevOps Server nasazeních.

Nastavení skupin

TFS 2017 představuje možnosti konfigurace nastavení webu ve všech scénářích konfigurace serveru. K dispozici je několik skupin nastavení, které sdružují kombinace vazeb webu, virtuálních adresářů a veřejných adres URL, které doporučujeme a věříme, že se budou nejčastěji používat. Ve scénářích, ve kterých není žádná z těchto skupin nastavení vhodná, je možné nastavení plně přizpůsobit pomocí dialogového okna Upravit nastavení webu.

Výchozí skupina nastavení

Skupina výchozích nastavení obsahuje stejná nastavení jako v předchozích verzích Azure DevOps Server. Ze všech výše uvedených důvodů jsou tato nastavení stále výchozí pro nová nasazení Azure DevOps Server. U existujících nasazení se pokusíme zachovat existující nastavení, což často vede k výběru skupiny výchozích nastavení.

HTTPS a HTTP se skupinou nastavení přesměrování.

Skupina nastavení HTTPS a HTTP (s přesměrováním) zřídí dvě vazby:

  • Jedna vazba HTTPS na portu 443 s plně kvalifikovaným názvem domény (FQDN) počítače jako názvem hostitele.
  • Jedna vazba HTTP na portu 80, opět s plně kvalifikovaným názvem domény počítače jako názvem hostitele.

Vazba HTTP na portu 80 je přidaná jenom pro usnadnění pro koncové uživatele – přesměrování je nakonfigurované tak, aby veškerý provoz skončil pomocí vazby HTTPS na portu 443. Veřejná adresa URL pro tuto skupinu nastavení je ve formuláři. https://fully-qualified-domain-name. Ve výchozím nastavení tato skupina nastavení zřídí nové certifikáty podepsané svým držitelem a použije je pro vazbu HTTPS. Pro produkční nasazení TFS obvykle nedoporučujeme používat certifikáty podepsané svým držitelem. 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 níže v části Možnosti certifikátu.

Skupina nastavení pouze HTTPS zřídí jednu vazbu HTTPS na portu 443 s plně kvalifikovaným názvem domény počítače jako názvem hostitele. Znovu platí, že veřejná adresa URL pro tuto skupinu nastavení je ve formátu https://fully-qualified-domain-namea certifikáty podepsané svým držitelem se zřídí ve výchozím nastavení.

Skupina nastavení POUZE HTTP zřídí jednu vazbu HTTP na portu 80 bez zadaného názvu hostitele. Veřejná adresa URL pro tuto skupinu nastavení je ve formuláři. http://machine-name.

Při použití skupiny nastavení HTTPS a HTTP (s přesměrováním) se použití veřejné adresy URL PROTOKOLU HTTP nedoporučuje. Většina moderních prohlížečů považuje smíšený obsah HTTP a HTTPS ve výchozím nastavení za nezabezpečený a může zobrazovat prázdné stránky. I když je obvykle možné přepsat výchozí nastavení prohlížeče a povolit nezabezpečený obsah, výsledkem bude podobné procházení webu s prošlým certifikátem SSL.

Možnosti certifikátu

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 bohaté a zajímavé téma, ke kterému již existuje široká škála dokumentace. Nebudeme se snažit pokrýt celou složitost, ale spíše se zaměříme na možnosti vysoké úrovně konfigurace vazeb HTTPS pro Azure DevOps Server nasazení. Mnoho organizací má specifické zásady týkající se nasazování certifikátů, takže prvním krokem při rozhodování o tom, jaký certifikát použít pro nasazení Azure DevOps Server, je často mluvit se skupinou informačních technologií na úrovni organizace.

Vaše možnosti jsou:

  • Umožňuje průvodci konfigurací sady TFS generovat certifikáty podepsané svým držitelem pro použití v nasazení.
  • Získání certifikátu od interní certifikační autority
  • Získání certifikátu od externí certifikační autority

Certifikáty podepsané svým držitelem

Certifikáty podepsané svým držitelem jsou užitečné pro zkušební nasazení Azure DevOps Server, protože se velmi snadno zřizují a používají. Jsou méně vhodné pro produkční nasazení Azure DevOps Server a nedoporučujeme je používat pro Azure DevOps Server nasazení vystavená na veřejném internetu. Obecně platí, že certifikáty podepsané svým držitelem jsou náchylné k útokům man-in-the-middle. Také způsobují problémy uživatelům, protože budou způsobovat upozornění a chyby certifikátů, dokud se na každý klientský počítač nenainstalují jejich kořenové certifikáty. V prohlížeči Edge se například zobrazí následující chyba.

Chyby certifikátů v Edgi.

Když průvodce konfigurací sady TFS vygeneruje pro vaše nasazení certifikáty podepsané svým držitelem, 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. Nastavení tímto způsobem pomáhá zmírnit možnost útoků man-in-the-middle a umožňuje obměně certifikátů používaných ve vazbě HTTPS, aniž by bylo nutné distribuovat nový certifikát všem klientům, aby se zabránilo chybám certifikátů, jako je ta uvedená výše.

Pokud se chcete těmto upozorněním a chybám certifikátů vyhnout, můžete kořenový certifikát exportovat a nainstalovat ho na klientské počítače. Existuje několik způsobů, jak toho dosáhnout, mezi které patří:

  • Pomocí modulu snap-in Certifikáty konzoly MMC ručně vyexportujte certifikát na serveru a pak ho naimportujte do každého klienta.
  • K exportu certifikátu použijte rutinu PowerShellu Export-Certificate, která je k dispozici v Windows 8/Windows Server 2012 a novějších operačních systémech. Import-Certificate pak můžete použít k jeho importu do každého klienta.
  • Použití Zásady skupiny k automatizaci distribuce do klientů

Interní a externí certifikační autority

Mnoho velkých organizací má vlastní infrastrukturu veřejných klíčů a jsou schopny vydávat certifikáty ze svých vlastních certifikačních autorit. V takovém případě se důvěryhodné kořenové certifikáty pro tyto autority obvykle již distribuují do klientských počítačů, čímž se vyhnete nutnosti distribuovat další certifikáty pro Azure DevOps Server. Pokud má vaše organizace vlastní infrastrukturu veřejných klíčů, může to být vhodná volba pro Azure DevOps Server nasazení.

Pokud jiné možnosti nejsou vhodné nebo dostupné, mohou být certifikáty (obvykle za cenu) získány od externí certifikační autority (CA). Pokyny pro tento proces, který začíná vytvořením žádosti o podepsání certifikátu, najdete na většině webů certifikační autority. Několik důležitých poznámek:

  • Ujistěte se, že běžný název zadaný v žádosti o certifikát odpovídá názvu hostitele, který chcete mít ve veřejné adrese URL – například tfs.contoso.com.
  • Ve vlastnostech zprostředkovatele kryptografických služeb doporučujeme vybrat zprostředkovatele kryptografických služeb Microsoft RSA SChannel a bitovou délku 2048 nebo vyšší.

Změna veřejné adresy URL

Je také potřeba poznamenat, že při upgradu existujícího nasazení Azure DevOps Server změna veřejné adresy URL ovlivní koncové uživatele. I když stále doporučujeme převod z vazeb HTTP na HTTPS, bude potřeba znovu navázat připojení klientů sady Visual Studio, staré záložky se už nebudou správně překládat atd. Proto je důležité koordinovat tento druh změny s uživateli vašeho Azure DevOps Server nasazení, aby nedošlo k významnému přerušení.