A helyszíni Azure DevOps webhelybeállításai és biztonsága

TFS 2017 | TFS 2015 | TFS 2013

Háttér

Számos kiadás esetében a korábban Team Foundation Server (TFS) néven futó Azure DevOps Server alapértelmezett webhelybeállításai a következőek voltak:

• Egyetlen HTTP-kötés az Azure DevOps Server webhelyéhez a 8080-s porton, és nincs megadva állomásnév vagy IP-cím.
• Az űrlap http://machine-name:8080/tfsnyilvános URL-címe (korábbi nevén értesítési URL-cím).

Ezeknek a beállításoknak az elsődleges előnye, hogy a legtöbb forgatókönyvben nagyon egyszerűen beállíthatók és kényelmesek a végfelhasználók számára. Főleg:

• A HTTPS helyett a HTTP használata elkerüli a tanúsítványok beszerzését és telepítését.
• A 8080 helyett a 80-at használva elkerülheti a lehetséges ütközéseket az ugyanazon a gépen található más helyekkel.
• A "tfs" használata a webhely virtuális könyvtáraként megkönnyíti az Azure DevOps Server és más webhelyek üzemeltetését ugyanazon a porton ugyanazon a kiszolgálón.
• A nyilvános URL-címben a teljes tartománynév (FQDN) helyett a gépnév használata sok gépelést takarít meg.
• Ha a gazdanevet nem adja meg a kötésben, rugalmasan csatlakoztatható – a gépnév, a teljes tartománynév vagy az IP-cím mind működni fog, amikor a felhasználók megpróbálnak csatlakozni a kiszolgálóikhoz.

Ezek a beállítások azonban alapértelmezés szerint nem biztonságosak. Különösen azzal, hogy nem használ HTTPS-kötést, az Azure DevOps Server felé és onnan érkező kommunikáció nem lesz titkosítva átvitel közben, kivéve, ha más megoldásokat, például AZ IPSec-et használ. Így potenciálisan sebezhetők a rosszindulatú szereplők számára, amelyek figyelik vagy akár módosítják a kommunikáció tartalmát. Ezeket a problémákat bizonyos mértékig enyhítjük, ha az Azure DevOps Server egy vállalati tűzfal mögötti intraneten van üzembe helyezve, mivel az Azure DevOps Server-példányok túlnyomó többsége igen. Az Azure DevOps Serverre és onnan küldött adatok azonban még ezekben a forgatókönyvekben is tartalmaznak forráskódot, munkaelem-adatokat és egyéb információkat, amelyek gyakran további biztonsági előnyöket is élvezhetnek.

Emellett a TFS 2017-ben új hitelesítési forgatókönyvek is léteznek (build/release agent szolgáltatásfiók-hitelesítés, személyes hozzáférési jogkivonatok), amelyek a tulajdonosi jogkivonatokat a vezetéken keresztül küldik el. Ha ezeket a jogkivonatokat rosszindulatú felhasználók szerezik be, akkor felhasználhatók azoknak a felhasználóknak a megszemélyesítésére, akikhez tartoznak.

Mindezeket figyelembe véve úgy döntöttünk, hogy eljött az ideje a HTTPS-kötések Azure DevOps Server-telepítésekben való használatának.

Csoportok beállítása

A TFS 2017 minden kiszolgálókonfigurációs forgatókönyvben bemutatja a webhelybeállítások konfigurációs beállításait. Több beállításcsoport is rendelkezésre áll, amelyek a webhelykötések, a virtuális könyvtárak és a nyilvános URL-címek kombinációját kötik össze, amelyeket a leggyakrabban használunk. Olyan helyzetekben, ahol egyik beállításcsoport sem megfelelő, a beállítások teljes mértékben testre szabhatók a Webhely beállításainak szerkesztése párbeszédpanelen.

Az Alapértelmezett beállításcsoport ugyanazokat a beállításokat tartalmazza, mint az Azure DevOps Server korábbi verzióiban. A fent felsorolt okok miatt továbbra is ezek a beállítások az alapértelmezettek az új Azure DevOps Server-üzemelő példányokhoz. Meglévő üzemelő példányok esetén megkísérli megőrizni a meglévő beállításokat, ami gyakran az Alapértelmezett beállításcsoport kiválasztását eredményezi.

A HTTPS és a HTTP (átirányítással) beállításcsoport két kötést helyez üzembe:

• Egy HTTPS-kötés a 443-as porton, a gép teljes tartománynevével (FQDN) hosztnévként.
• Egy HTTP-kötés a 80-as porton, ismét a gép teljes tartományneve gazdanévként.

A 80-as portON a HTTP-kötés csak a végfelhasználók kényelme érdekében lesz hozzáadva – az átirányítás úgy van konfigurálva, hogy az összes forgalom a 443-as porton a HTTPS-kötést használja. A beállításcsoport nyilvános URL-címe ilyen formátumban van: https://fully-qualified-domain-name. Alapértelmezés szerint ez a beállításcsoport új önaláírt tanúsítványokat hoz létre, és használja őket a HTTPS-kötéshez. Általában nem javasoljuk az aláíratlan tanúsítványok használatát TFS bevezetésekor éles környezetben. Az önaláírt tanúsítványok használatáról és az elérhető egyéb lehetőségekről az alábbi Tanúsítványbeállítások című témakörben talál további információt.

Az HTTPS csak beállításcsoport egyetlen HTTPS-kötést helyez üzembe a 443-as porton, a szerver FQDN-je mint hosztnév. Ismét, a beállításcsoport nyilvános URL-címe a https://fully-qualified-domain-name formátumban van megadva, és alapértelmezés szerint önaláírt tanúsítványokat állítanak ki.

A CSAK HTTP-beállításcsoport egyetlen HTTP-kötést helyez üzembe a 80-as porton, és nincs megadva állomásnév. A beállításcsoport nyilvános URL-címe a formátum http://machine-name.

A HTTPS és a HTTP (átirányítással) beállításcsoport használatakor nem ajánlott nyilvános HTTP-URL-címet használni. A legtöbb modern böngésző alapértelmezés szerint nem biztonságosnak tartja a vegyes HTTP- és HTTPS-tartalmakat, és üres oldalakat jeleníthet meg. Bár általában felül lehet bírálni az alapértelmezett böngészőbeállításokat, és nem biztonságos tartalmakat lehet engedélyezni, ez olyan élményt eredményez, mint egy lejárt SSL-tanúsítvánnyal rendelkező webhely böngészése.

Tanúsítványbeállítások

A webhelyek HTTPS-kötések és SSL/TLS-titkosítás használatával történő üzembe helyezése szorosan kapcsolódik a nyilvános kulcsú infrastruktúra (PKI) tágabb témaköréhez, amely egy gazdag és érdekes témakör, amelyhez már számos dokumentáció létezik. Itt nem a teljes összetettségre fogunk koncentrálni, hanem a HTTPS-kötések Azure DevOps Server-környezetekhez való konfigurálásának magas szintű lehetőségeire összpontosítunk. Számos szervezet rendelkezik a tanúsítványok üzembe helyezésére vonatkozó speciális szabályzatokkal, ezért az első lépés az, hogy eldöntse, milyen tanúsítványt használjon az Azure DevOps Server üzembe helyezéséhez, gyakran egy szervezeti szintű információtechnológiai csoporttal kell beszélnie.

A lehetőségek a következők:

• Lehetővé teszi, hogy a TFS konfigurációs varázsló önaláírt tanúsítványokat hozzon létre az üzembe helyezéshez.
• Tanúsítvány beszerzése egy belső hitelesítésszolgáltatótól.
• Tanúsítvány beszerzése külső hitelesítésszolgáltatótól.

Önaláírt tanúsítványok

Az önaláírt tanúsítványok hasznosak az Azure DevOps Server próbaverziós üzembe helyezéséhez, mivel nagyon könnyen kiépíthetőek és használhatók. Kevésbé alkalmasak az Azure DevOps Server éles üzembe helyezésére, és nem javasoljuk, hogy a nyilvános interneten közzétett Azure DevOps Server-környezetekhez használják őket. Az önaláírt tanúsítványok általában érzékenyek a közbeékelődéses támadásoknak. Problémákat is okoznak a felhasználók számára, mivel a tanúsítványokkal kapcsolatos figyelmeztetéseket és hibákat okoznak, amíg a főtanúsítványaik nem lesznek telepítve az egyes ügyfélszámítógépeken. Az Edge böngészőben például az alábbi hiba jelenik meg.

Amikor a TFS konfigurációs varázsló önaláírt tanúsítványokat hoz létre az üzemelő példányhoz, két tanúsítványt generál: az egyik a kiszolgáló Megbízható Felső Szintű Hitelesítésszolgáltató tárolójába kerül, a másik pedig, amelyet az első tanúsítvány aláír, a kiszolgáló Személyes tárolójába kerül, és az Azure DevOps Server használja. Az ilyen módon történő beállítás segít enyhíteni a középen belüli támadások lehetőségét, és lehetővé teszi a HTTPS-kötésben használt tanúsítvány rotálását anélkül, hogy új tanúsítványt kellene terjesztenie az összes ügyfélnek a fentihez hasonló tanúsítványhibák elkerülése érdekében.

A tanúsítványokkal kapcsolatos figyelmeztetések és hibák elkerülése érdekében exportálhatja a főtanúsítványt, és telepítheti az ügyfélszámítógépekre. Ennek többféle módja is van, például:

• A Tanúsítványok MMC beépülő modul használatával manuálisan exportálhatja a tanúsítványt a kiszolgálón, majd importálhatja az egyes ügyfelekre.
• A tanúsítvány exportálásához használja a Windows 8/Windows Server 2012 és újabb operációs rendszerekben elérhető PowerShell-parancsmagot. Az importálási tanúsítvány ezután minden ügyfélen importálható.
• Csoportházirend használata az ügyfelek közötti terjesztés automatizálásához.

Belső és külső hitelesítésszolgáltatók

Sok nagy szervezet rendelkezik saját nyilvános kulcsú infrastruktúrával, és képes tanúsítványokat kibocsátani a saját hitelesítésszolgáltatóitól. Ebben az esetben a hatóságok megbízható főtanúsítványai általában már el lesznek osztva az ügyfélgépeken, így nem kell további tanúsítványokat terjeszteni az Azure DevOps Serverhez. Ha a szervezet saját nyilvános kulcsú infrastruktúrával rendelkezik, ez jó választás lehet az Azure DevOps Server üzembe helyezéséhez.

Ha más lehetőségek nem megfelelőek vagy elérhetők, tanúsítványokat lehet beszerezni (általában költséggel) egy külső hitelesítésszolgáltatótól (CA). A tanúsítvány-aláírási kérelem létrehozásával kezdődő folyamat utasításai a legtöbb ca-webhelyen megtalálhatók. Néhány fontos megjegyzés:

• Győződjön meg arról, hogy a tanúsítványkérelemben megadott Közös név megegyezik a nyilvános URL-címben kívánt gazdagép nevével: például tfs.contoso.com.
• A kriptográfiai szolgáltató tulajdonságainál javasoljuk, hogy válassza a Microsoft RSA SChannel kriptográfiai szolgáltatót, és a bitszélesség legyen 2048 vagy annál nagyobb.

A nyilvános URL-cím módosítása

Azt is meg kell jegyezni, hogy egy meglévő Azure DevOps Server-telepítés frissítésekor a nyilvános URL-cím módosítása hatással lesz a végfelhasználókra. Bár továbbra is javasoljuk a HTTP-ről HTTPS-kötésekké való konvertálást, a Visual Studio ügyfélkapcsolatait újra létre kell hozni, a régi könyvjelzők nem oldódnak fel megfelelően, és így tovább. Ezért fontos koordinálni ezt a fajta változást az Azure DevOps Server üzembe helyezésének felhasználóival a jelentős fennakadások elkerülése érdekében.