Ustawienia i zabezpieczenia witryny internetowej dla lokalnej usługi Azure DevOps

TFS 2017 | TFS 2015 | TFS 2013

Kontekst

W przypadku wielu wersji domyślne ustawienia witryny internetowej dla serwera Azure DevOps Server, wcześniej o nazwie Team Foundation Server (TFS), zostały następujące:

• Pojedyncze powiązanie HTTP dla witryny internetowej usługi Azure DevOps Server na porcie 8080 bez określonej nazwy hosta ani adresu IP.
• Publiczny adres URL (wcześniej nazywany adresem URL powiadomienia) formularza http://machine-name:8080/tfs.

Główną zaletą tych ustawień jest to, że są one bardzo proste do skonfigurowania i wygody dla użytkowników końcowych w większości scenariuszy. W szczególności:

• Używanie protokołu HTTP zamiast protokołu HTTPS pozwala uniknąć konieczności uzyskiwania i instalowania certyfikatów.
• Użycie wersji 8080 zamiast 80 pozwala uniknąć potencjalnych konfliktów z innymi witrynami na tym samym komputerze.
• Użycie "tfs" jako katalogu wirtualnego witryny ułatwia hostowanie serwera Azure DevOps Server i innych witryn internetowych na tym samym porcie na tym samym serwerze.
• Używanie nazwy maszyny zamiast pełnej kwalifikowanej nazwy domeny (FQDN) w publicznym adresie URL znacząco ułatwia pisanie.
• Pozostawienie nazwy hosta w powiązaniu nieokreślonym pozwala na elastyczność nawiązywania połączenia — nazwa komputera, nazwa FQDN lub adres IP będą działać, gdy użytkownicy spróbują nawiązać połączenie z serwerami.

Te ustawienia nie są jednak domyślnie bezpieczne. W szczególności, nie używając powiązania HTTPS, komunikacja z serwerem Azure DevOps Server nie jest szyfrowana podczas przesyłania, chyba że są używane inne rozwiązania, takie jak IPSec. Są one zatem potencjalnie narażone na monitorowanie złośliwych podmiotów, a nawet modyfikowanie zawartości komunikacji. Te problemy są rozwiązywane w pewnym stopniu, gdy serwer Azure DevOps Server jest wdrażany w intranecie za zaporą firmową, ponieważ zdecydowana większość wystąpień usługi Azure DevOps Server. Jednak nawet w tych scenariuszach dane wysyłane do i z usługi Azure DevOps Server zawierają kod źródłowy, dane elementów roboczych i inne informacje, które często mogą korzystać z dodatkowych zabezpieczeń.

Ponadto w programie TFS 2017 istnieją nowe scenariusze uwierzytelniania (uwierzytelnianie konta usługi agenta kompilacji/wydania, osobiste tokeny dostępu), które wysyłają tokeny elementu nośnego za pośrednictwem przewodu. Jeśli te tokeny są uzyskiwane przez złośliwych użytkowników, mogą być używane do podszywania się pod użytkowników, do których należą.

Biorąc pod uwagę wszystkie te elementy, postanowiliśmy, że nadszedł czas, aby bardziej zdecydowanie opowiadać się za użyciem powiązań HTTPS we wdrożeniach usługi Azure DevOps Server.

Ustawianie grup

TfS 2017 przedstawia opcje konfiguracji ustawień witryny sieci Web we wszystkich scenariuszach konfiguracji serwera. Dostępnych jest kilka grup ustawień, które łączą kombinacje powiązań witryn, katalogów wirtualnych i publicznych adresów URL, które zalecamy i uważamy, że będą najczęściej używane. W przypadku scenariuszy, w których żadna z tych grup ustawień nie jest odpowiednia, ustawienia można w pełni dostosować przy użyciu okna dialogowego Edytowanie ustawień witryny.

Grupa ustawień domyślnych zawiera te same ustawienia, które były używane w poprzednich wersjach serwera Azure DevOps Server. Ze wszystkich powodów wymienionych powyżej te ustawienia są nadal domyślne dla nowych wdrożeń usługi Azure DevOps Server. W przypadku istniejących wdrożeń podejmiemy próbę zachowania istniejących ustawień, co często spowoduje wybranie domyślnej grupy ustawień.

Grupa ustawień HTTPS i HTTP (z przekierowaniami) konfiguruje dwa powiązania:

• Jedno powiązanie HTTPS na porcie 443 z w pełni kwalifikowaną nazwą domeny (FQDN) maszyny jako nazwą hosta.
• Jedno powiązanie HTTP na porcie 80, ponownie z nazwą FQDN maszyny jako nazwą hosta.

Powiązanie HTTP na porcie 80 jest dodawane tylko jako wygoda dla użytkowników końcowych — przekierowanie jest skonfigurowane tak, aby cały ruch kończył się przy użyciu powiązania HTTPS na porcie 443. Publiczny adres URL dla tej grupy ustawień ma postać https://fully-qualified-domain-name. Domyślnie ta grupa ustawień będzie aprowizować nowe certyfikaty z podpisem własnym i używać ich do powiązania HTTPS. Zazwyczaj nie zalecamy używania certyfikatów z podpisem własnym do wdrożeń produkcyjnych TFS. Aby uzyskać więcej informacji na temat używania certyfikatów z podpisem własnym i innych dostępnych opcji, zobacz Opcje certyfikatów poniżej.

Grupa ustawień protokołu HTTPS aprowizuje pojedyncze powiązanie HTTPS na porcie 443 z nazwą FQDN maszyny jako nazwą hosta. Ponownie publiczny adres URL dla tej grupy ustawień ma postać https://fully-qualified-domain-name, a certyfikaty z podpisem własnym będą domyślnie aprowizowane.

Grupa ustawień Tylko HTTP konfiguruje pojedyncze wiązanie HTTP na porcie 80 bez określonej nazwy hosta. Publiczny adres URL dla tej grupy ustawień ma postać http://machine-name.

W przypadku korzystania z grupy ustawień HTTPS i HTTP (z przekierowaniem) użycie publicznego adresu URL HTTP nie jest zalecane. Większość nowoczesnych przeglądarek uznaje mieszane treści HTTP i HTTPS za niebezpieczne domyślnie i może wyświetlać puste strony. Chociaż zazwyczaj można zastąpić domyślne ustawienia przeglądarki i zezwolić na niezabezpieczoną zawartość, spowoduje to wyświetlenie środowiska podobnego do przeglądania witryny z wygasłym certyfikatem SSL.

Opcje certyfikatu

Wdrażanie witryn internetowych przy użyciu powiązań HTTPS i szyfrowania SSL/TLS jest ściśle związane z szerszym tematem infrastruktury kluczy publicznych (PKI), który jest bogatym i interesującym tematem, dla którego istnieje już wiele różnych dokumentacji. W tym miejscu nie będziemy próbować obejmować całej złożoności, ale raczej skupimy się na opcjach wysokiego poziomu konfigurowania powiązań HTTPS dla wdrożeń usługi Azure DevOps Server. Wiele organizacji ma określone zasady dotyczące wdrażania certyfikatów, dlatego pierwszym krokiem w podejmowaniu decyzji o tym, jakiego certyfikatu należy użyć do wdrożenia usługi Azure DevOps Server, często jest rozmowa z grupą technologii informatycznych na poziomie organizacji.

Dostępne opcje:

• Zezwolenie kreatorowi konfiguracji serwera TFS na generowanie certyfikatów z podpisem własnym do użycia przez wdrożenie.
• Uzyskiwanie certyfikatu z wewnętrznego urzędu certyfikacji.
• Uzyskiwanie certyfikatu z zewnętrznego urzędu certyfikacji.

Certyfikaty z podpisem własnym

Certyfikaty z podpisem własnym są przydatne w przypadku wdrożeń wersji próbnej usługi Azure DevOps Server, ponieważ są bardzo łatwe do aprowizowania i używania. Są one mniej odpowiednie w przypadku wdrożeń produkcyjnych usługi Azure DevOps Server i nie zalecamy ich użycia w przypadku wdrożeń usługi Azure DevOps Server uwidocznionych w publicznym Internecie. Ogólnie rzecz biorąc, certyfikaty z podpisem własnym są podatne na ataki typu man-in-the-middle. Powodują one również problemy dla użytkowników, ponieważ będą powodować ostrzeżenia i błędy certyfikatów do momentu zainstalowania ich certyfikatów głównych na każdej maszynie klienckiej. Na przykład przeglądarka Edge wyświetli poniższy błąd.

Gdy kreator konfiguracji TFS generuje samopodpisane certyfikaty dla Twojego wdrożenia, utworzy dwa — jeden umieszczany w składnicy Zaufanych Głównych Urzędów Certyfikacji na serwerze, oraz drugi, podpisany przez pierwszy, umieszczany w składnicy Osobistej na serwerze i używany przez Azure DevOps Server. Skonfigurowanie elementów w ten sposób pomaga ograniczyć możliwość ataków typu man-in-the-middle i umożliwia rotację certyfikatu używanego w powiązaniu HTTPS bez konieczności dystrybucji nowego certyfikatu do wszystkich klientów w celu uniknięcia błędów certyfikatów, takich jak pokazany powyżej.

Aby uniknąć tych ostrzeżeń i błędów certyfikatu, możesz wyeksportować certyfikat główny i zainstalować go na komputerach klienckich. Istnieje kilka sposobów, aby to osiągnąć, w tym:

• Użycie przystawki MMC dla certyfikatów do ręcznego wyeksportowania certyfikatu na serwerze, a następnie zaimportowania go na każdym kliencie.
• Za pomocą polecenia cmdlet programu PowerShell Export-Certificate dostępnego w systemie Windows 8/ Windows Server 2012 i nowszych systemach operacyjnych w celu wyeksportowania certyfikatu. Import-Certificate może być następnie użyty do importowania certyfikatu na każdym kliencie.
• Używanie zasad grupy do automatyzowania dystrybucji do klientów.

Wewnętrzne i zewnętrzne urzędy certyfikacji

Wiele dużych organizacji ma własną infrastrukturę kluczy publicznych i może wystawiać certyfikaty z własnych urzędów certyfikacji. Zazwyczaj w takim przypadku zaufane certyfikaty główne dla tych urzędów będą już dystrybuowane na maszyny klienckie, co pozwala uniknąć konieczności dystrybucji dodatkowych certyfikatów dla usługi Azure DevOps Server. Jeśli Twoja organizacja ma własną infrastrukturę kluczy publicznych, może to być dobra opcja dla wdrożenia usługi Azure DevOps Server.

Jeśli inne opcje nie są odpowiednie lub dostępne, certyfikaty mogą być uzyskiwane (zazwyczaj wiąże się z kosztami) z zewnętrznego urzędu certyfikacji. Instrukcje dotyczące tego procesu, który rozpoczyna się od utworzenia żądania podpisania certyfikatu, można znaleźć w większości witryn internetowych urzędu certyfikacji. Kilka ważnych uwag:

• Upewnij się, że nazwa pospolita podana w żądaniu certyfikatu jest zgodna z nazwą hosta, której chcesz użyć w publicznym adresie URL — na przykład tfs.contoso.com.
• W obszarze Właściwości dostawcy usług kryptograficznych zalecamy wybranie dostawcy kryptograficznego Microsoft RSA SChannel i długość klucza 2048 bitów lub większą.

Zmienianie publicznego adresu URL

Należy również zauważyć, że podczas uaktualniania istniejącego wdrożenia usługi Azure DevOps Server zmiana publicznego adresu URL będzie miała wpływ na użytkowników końcowych. Mimo że nadal zalecamy konwertowanie z powiązań HTTP na HTTPS, połączenia klienckie programu Visual Studio będą musiały zostać ponownie ustanowione, stare zakładki nie będą już prawidłowo rozpoznawane i tak dalej. Dlatego ważne jest koordynowanie tego rodzaju zmian z użytkownikami wdrożenia usługi Azure DevOps Server, aby uniknąć znaczących zakłóceń.