Nastavení a zabezpečení webové stránky pro nasazené prostředí Azure DevOps

TFS 2017 | TFS 2015 | TFS 2013

Background

V mnoha verzích jsou výchozí nastavení webu pro Azure DevOps Server, dříve s názvem Team Foundation Server (TFS), následující:

• Jedna vazba HTTP pro web Azure DevOps Serveru 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 je velmi jednoduché nastavit a pohodlně pro koncové uživatele ve většině scénářů. Zejména:

• Použití protokolu HTTP místo protokolu HTTPS se vyhne nutnosti získávat a instalovat certifikáty.
• Použití 8080 místo 80 zabraňuje potenciálním konfliktům s jinými lokalitami na stejném počítači.
• Použití tfs jako virtuálního adresáře pro web usnadňuje hostování Azure DevOps Serveru 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ém adrese URL š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á. Konkrétně se při přenosu nepoužívá vazba HTTPS, komunikace s Azure DevOps Serverem ani z tohoto serveru není šifrovaná, pokud se nepoužívají jiná řešení, jako je IPSec. Jsou tak potenciálně zranitelní vůči škodlivým subjektům, kteří monitorují nebo dokonce upravují obsah komunikace. Tyto problémy se v určitém rozsahu zmírňují, když je Azure DevOps Server nasazený na intranetu za podnikovou bránou firewall, protože velká většina instancí Azure DevOps Serveru je. I v těchto scénářích ale data odesílaná do a z Azure DevOps Serveru 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 build/release agent, osobní přístupové tokeny), které posílají nosné tokeny přes drát. Pokud jsou tyto tokeny získány uživateli se zlými úmysly, dají se použít k zosobnění uživatelů, kterým patří.

Vzhledem ke všem těmto skutečnostem jsme se rozhodli, že nastal čas silněji prosazovat použití vázání HTTPS v nasazeních Azure DevOps Serveru.

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é seskupují 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. Pro scénáře, 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í zahrnuje stejná nastavení jako v předchozích verzích Azure DevOps Serveru. Pro všechna výše uvedená nastavení jsou tato nastavení stále výchozí pro nová nasazení Azure DevOps Serveru. U existujících nasazení se pokusíme zachovat stávající nastavení, což často způsobí výběr skupiny výchozích nastavení.

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řidána pouze jako pohodlí pro koncové uživatele – přesměrování je nakonfigurováno tak, aby veškerý provoz skončil pomocí vazby HTTPS na portu 443. Veřejná adresa URL pro tuto skupinu nastavení má formu 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 v části Možnosti certifikátu níže.

Skupina nastavení HTTPS zřizuje jedinou vazbu HTTPS na portu 443 s plně kvalifikovaným názvem domény počítače jako jménem hostitele. Veřejná URL adresa této skupiny nastavení je opět ve formuláři https://fully-qualified-domain-name, a certifikáty podepsané vlastníkem 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 tvaru http://machine-name..

Při použití skupiny nastavení HTTPS a HTTP (s přesměrováním) se nedoporučuje používat veřejnou adresu URL PROTOKOLU HTTP. Většina moderních prohlížečů bude ve výchozím nastavení považovat smíšený obsah HTTP a HTTPS za nezabezpečený a mohou zobrazit 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 prostředí 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, pro které již existuje široká škála dokumentace. Nebudeme se zde pokoušet pokrýt celou složitost, ale zaměříme se spíše na možnosti vysoké úrovně konfigurace vazeb HTTPS pro nasazení Azure DevOps Serveru. 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 Serveru, je často mluvit se skupinou informačních technologií na úrovni organizace.

K dispozici jsou následující možnosti:

• Povolení průvodce konfigurací TFS k vygenerování samosignovaných certifikátů pro 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 Serveru, protože je velmi snadné zřizovat a používat. Jsou méně vhodné pro produkční nasazení Azure DevOps Serveru a nedoporučujeme je používat pro nasazení Azure DevOps Serveru vystavená veřejnému internetu. Obecně platí, že certifikáty podepsané svým držitelem jsou náchylné k útokům typu man-in-the-middle. Také způsobují problémy pro uživatele, protože způsobí upozornění a chyby certifikátů, dokud se jejich kořenové certifikáty nenainstalují na každém klientském počítači. Například prohlížeč Edge zobrazí následující chybu.

Když průvodce konfigurací TFS vygeneruje vlastnoručně podepsané certifikáty pro vaše nasazení, vytvoří se 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ý, který je podepsán tím prvním a umístěn v osobním úložišti na serveru, přičemž je používán Azure DevOps Serverem. Nastavení tímto způsobem pomáhá zmírnit možnost útoků man-in-the-middle a umožňuje obměnu certifikátu používaného ve vazbě HTTPS, aniž by bylo nutné distribuovat nový certifikát všem klientům, aby se zabránilo chybám certifikátu, jako je výše uvedený certifikát.

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

• Pomocí konzoly MMC a jejího modulu snap-in Certifikáty ručně exportujte certifikát na serveru a pak ho importujte na každého klienta.
• K exportu certifikátu použijte rutinu PowerShellu pro export certifikátu, která je dostupná ve Windows 8 nebo Windows Serveru 2012 a novějších operačních systémech. Certifikát importu je pak možné použít k jeho importu do každého klienta.
• Použití zásad skupiny k automatizaci distribuce klientům.

Interní a externí certifikační autority

Mnoho velkých organizací má vlastní infrastrukturu veřejného klíče a dokáže vydávat certifikáty od vlastních certifikačních autorit. V takovém případě se obvykle důvěryhodné kořenové certifikáty pro tyto autority už distribuují do klientských počítačů, takže není nutné distribuovat další certifikáty pro Azure DevOps Server. Pokud má vaše organizace vlastní infrastrukturu veřejného klíče, může to být vhodná možnost pro nasazení Azure DevOps Serveru.

Pokud jiné možnosti nejsou vhodné nebo dostupné, mohou být certifikáty získány (obvykle za cenu) 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ěkteré důležité poznámky:

• Ujistěte se, že běžný název zadaný v požadavku na certifikát odpovídá požadovanému názvu hostitele ve vaší veřejné adrese URL, například tfs.contoso.com.
• Ve vlastnostech zprostředkovatele kryptografických služeb doporučujeme vybrat Microsoft RSA SChannel Cryptographic Provider s délkou klíče 2048 nebo větší.

Změna veřejné adresy URL

Je také třeba poznamenat, že při upgradu existujícího nasazení Azure DevOps Serveru bude změna veřejné adresy URL mít vliv na koncové uživatele. I když přesto doporučujeme převést z http na vazby HTTPS, bude potřeba znovu navázat připojení klientů sady Visual Studio, staré záložky se už nepřeloží správně a tak dále. Proto je důležité koordinovat tento druh změn s uživateli nasazení Azure DevOps Serveru, aby nedošlo k významnému přerušení.