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

TFS 2017 | TFS 2015 | TFS 2013

Tło

W przypadku wielu wersji domyślne ustawienia witryny sieci Web dla Azure DevOps Server, wcześniej o nazwie Team Foundation Server (TFS), to:

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

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

• Używanie protokołu HTTP zamiast 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 dla witryny ułatwia hostowanie Azure DevOps Server i innych witryn sieci Web na tym samym porcie na tym samym serwerze.
• Użycie nazwy maszyny zamiast w pełni kwalifikowanej nazwy domeny (FQDN) w publicznym adresie URL powoduje zapisanie wielu typów.
• 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, komunikacji z i z Azure DevOps Server nie są szyfrowane 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 w przypadku wdrożenia Azure DevOps Server w intranecie za zaporą firmową, ponieważ zdecydowana większość wystąpień Azure DevOps Server. Jednak nawet w tych scenariuszach dane wysyłane do i z Azure DevOps Server obejmują 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ć one używane do personifikacji użytkowników, do których należą.

Biorąc pod uwagę to wszystko, zdecydowaliśmy, że nadszedł czas, aby bardziej zdecydowanie opowiadać się za użyciem powiązań HTTPS w Azure DevOps Server wdrożeniach.

Ustawianie grup

Program TFS 2017 przedstawia opcje konfiguracji ustawień witryny internetowej we wszystkich scenariuszach konfiguracji serwera. Dostępnych jest kilka grup ustawień, które łączą kombinacje powiązań lokacji, katalogów wirtualnych i publicznych adresów URL, które zalecamy i uważają, ż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.

Domyślna grupa ustawień zawiera te same ustawienia, które były używane w poprzednich wersjach Azure DevOps Server. Ze wszystkich powodów wymienionych powyżej te ustawienia są nadal domyślne dla nowych wdrożeń 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) aprowizuje 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 w przypadku wdrożeń produkcyjnych serwera 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 zostaną domyślnie aprowidowane.

Grupa ustawień Tylko protokół HTTP aprowizuje pojedyncze powią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 domyślnie uwzględnia mieszaną zawartość HTTP i HTTPS i może wyświetlać puste strony. Chociaż zazwyczaj możliwe jest zastąpienie domyślnych ustawień przeglądarki i zezwolenie 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ć zajmować się całą złożonością, ale raczej skupimy się na opcjach wysokiego poziomu konfigurowania powiązań HTTPS dla wdrożeń Azure DevOps Server. Wiele organizacji ma określone zasady dotyczące wdrażania certyfikatów, więc pierwszym krokiem w podejmowaniu decyzji o tym, jakiego certyfikatu należy użyć do wdrożenia Azure DevOps Server, jest często rozmowa z grupą technologii informatycznych na poziomie organizacji.

Dostępne są następujące 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 Azure DevOps Server, ponieważ są one bardzo łatwe do aprowizacji i używania. Są one mniej odpowiednie w przypadku wdrożeń produkcyjnych Azure DevOps Server i nie zalecamy ich użycia w przypadku wdrożeń 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ż spowodują one 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 serwera TFS wygeneruje certyfikaty z podpisem własnym dla danego wdrożenia, utworzy dwa — jeden umieszczony w magazynie zaufanych głównych urzędów certyfikacji na serwerze, a drugi, podpisany przez pierwszy, który jest umieszczany w magazynie osobistym 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 wymianę 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 pokazano powyżej.

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

• Przy użyciu przystawki MMC certyfikatów w celu 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 Windows 8/Windows Server 2012 i nowszych systemach operacyjnych w celu wyeksportowania certyfikatu. Import-Certificate może następnie służyć do importowania go na każdym kliencie.
• Używanie zasady 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 Azure DevOps Server. Jeśli Twoja organizacja ma własną infrastrukturę kluczy publicznych, może to być dobra opcja dla wdrożenia Azure DevOps Server.

Jeśli inne opcje nie są odpowiednie lub dostępne, certyfikaty mogą być uzyskiwane (zazwyczaj kosztem) od 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. Ważne uwagi:

• Upewnij się, że nazwa pospolita podana w żądaniu certyfikatu jest zgodna z nazwą hosta 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 nieco długości 2048 lub większej.

Zmienianie publicznego adresu URL

Należy również zauważyć, że podczas uaktualniania istniejącego wdrożenia Azure DevOps Server zmiana publicznego adresu URL wpłynie na użytkowników końcowych. Mimo że nadal zalecamy konwersję 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 rozwiązywane i tak dalej. Dlatego ważne jest koordynowanie tego rodzaju zmian z użytkownikami wdrożenia Azure DevOps Server w celu uniknięcia znaczących zakłóceń.