Websiteeinstellungen und -sicherheit für lokale Azure DevOps

TFS 2017 | TFS 2015 | TFS 2013

Hintergrund

Für viele Versionen wurden die Standardwebsiteeinstellungen für Azure DevOps Server, zuvor als Team Foundation Server (TFS) bezeichnet, folgende:

• Eine einzelne HTTP-Bindung für die Azure DevOps Server-Website auf Port 8080, ohne Hostname oder IP-Adresse angegeben.
• Eine öffentliche URL (zuvor als Benachrichtigungs-URL bezeichnet) des Formulars http://machine-name:8080/tfs.

Der Hauptvorteil dieser Einstellungen besteht darin, dass sie sehr einfach für Endbenutzer in den meisten Szenarien eingerichtet und komfortabel sind. Im Besonderen:

• Die Verwendung von HTTP anstelle von HTTPS vermeidet die Notwendigkeit, Zertifikate abzurufen und zu installieren.
• Wenn Sie 8080 anstelle von 80 verwenden, werden potenzielle Konflikte mit anderen Websites auf demselben Computer vermieden.
• Die Verwendung von "tfs" als virtuelles Verzeichnis für die Website erleichtert das Hosten von Azure DevOps Server und anderen Websites auf demselben Port auf demselben Server.
• Die Verwendung des Computernamens anstelle des vollqualifizierten Domänennamens (FQDN) in der öffentlichen URL erspart viel Tipparbeit.
• Das Nicht-Angaben des Hostnamens in der Bindung erlaubt Flexibilität bei der Verbindung – Computername, FQDN oder IP-Adresse können alle verwendet werden, um eine Verbindung zu den Servern der Benutzer herzustellen.

Diese Einstellungen sind jedoch nicht standardmäßig sicher. Insbesondere ist die Kommunikation mit und von Azure DevOps Server während der Übertragung nicht verschlüsselt, wenn keine HTTPS-Bindung verwendet wird, es sei denn, es werden andere Lösungen wie IPSec eingesetzt. Sie sind somit potenziell anfällig für böswillige Akteure, die den Inhalt der Kommunikation überwachen oder sogar ändern. Diese Probleme werden teilweise abgemildert, wenn Azure DevOps Server in einem Intranet hinter einer Unternehmensfirewall bereitgestellt wird, wie es bei den meisten Azure DevOps Server-Instanzen der Fall ist. Aber auch in diesen Szenarien umfassen Daten, die an Azure DevOps Server gesendet werden, Quellcode, Arbeitsaufgabendaten und andere Informationen, die häufig von zusätzlicher Sicherheit profitieren könnten.

Darüber hinaus gibt es in TFS 2017 neue Authentifizierungsszenarien (Build/Release Agent-Dienstkontoauthentifizierung, persönliche Zugriffstoken), die Bearertoken über das Netzwerk senden. Wenn diese Token von böswilligen Benutzern abgerufen werden, können sie verwendet werden, um die Identität der Benutzer, denen sie angehören, zu imitieren.

Angesichts all dieser Tatsache haben wir entschieden, dass die Zeit gekommen war, um die Verwendung von HTTPS-Bindungen in Azure DevOps Server-Bereitstellungen stärker zu befürworten.

Festlegen von Gruppen

TFS 2017 bietet Konfigurationsoptionen für Websiteeinstellungen in allen Serverkonfigurationsszenarien. Es werden mehrere Einstellungsgruppen bereitgestellt, die Kombinationen aus Websitebindungen, virtuellen Verzeichnissen und öffentlichen URLs bündeln, die wir empfehlen und glauben, am häufigsten verwendet werden. Bei Szenarien, in denen keine dieser Einstellungsgruppen geeignet ist, können Einstellungen mithilfe des Dialogfelds "Websiteeinstellungen bearbeiten" vollständig angepasst werden.

Die Gruppe "Standardeinstellung" enthält die gleichen Einstellungen, die in früheren Versionen von Azure DevOps Server verwendet werden. Aus allen oben aufgeführten Gründen sind diese Einstellungen weiterhin die Standardeinstellung für neue Azure DevOps Server-Bereitstellungen. Bei vorhandenen Bereitstellungen versuchen wir, vorhandene Einstellungen beizubehalten, was häufig dazu führt, dass die Standardeinstellungsgruppe ausgewählt wird.

Die HTTPS- und HTTP-Einstellungsgruppe (mit Umleitung) stellt zwei Bindungen bereit:

• Eine HTTPS-Bindung am Port 443 mit dem vollqualifizierten Domänennamen (FQDN) des Computers als Hostname.
• Eine HTTP-Bindung auf Port 80, erneut mit dem FQDN des Computers als Hostname.

Die HTTP-Bindung für Port 80 wird nur als Komfort für Endbenutzer hinzugefügt – eine Umleitung ist so konfiguriert, dass der gesamte Datenverkehr die HTTPS-Bindung auf Port 443 verwendet. Die öffentliche URL für diese Einstellungsgruppe hat die Form https://fully-qualified-___domain-name. Standardmäßig stellt diese Einstellungsgruppe neue selbstsignierte Zertifikate bereit und verwendet sie für die HTTPS-Bindung. Es wird in der Regel nicht empfohlen, selbstsignierte Zertifikate für TFS-Bereitstellungen in der Produktion zu verwenden. Weitere Informationen dazu, wann es für die Verwendung von selbstsignierten Zertifikaten geeignet ist und welche anderen Optionen verfügbar sind, finden Sie unter "Zertifikatoptionen" weiter unten.

Die Https-Einstellungsgruppe stellt eine einzelne HTTPS-Bindung auf Port 443 bereit, wobei der FQDN des Computers als Hostname verwendet wird. Auch hier ist die öffentliche URL für diese Einstellungsgruppe das Formular https://fully-qualified-___domain-name, und selbstsignierte Zertifikate werden standardmäßig bereitgestellt.

Die Gruppe "Nur HTTP-Einstellung" stellt eine einzelne HTTP-Bindung für Port 80 ohne angegebenen Hostnamen bereit. Die öffentliche URL für diese Einstellungsgruppe hat die Form http://machine-name..

Wenn Sie die Einstellungsgruppe HTTPS und HTTP (mit Umleitung) verwenden, wird die Verwendung einer öffentlichen HTTP-URL nicht empfohlen. Die meisten modernen Browser betrachten standardmäßig die unsicheren HTTP- und HTTPS-Inhalte und zeigen möglicherweise leere Seiten an. Obwohl es in der Regel möglich ist, die Standardbrowsereinstellungen außer Kraft zu setzen und unsichere Inhalte zuzulassen, führt dies zu einer Erfahrung, die dem Durchsuchen einer Website mit einem abgelaufenen SSL-Zertifikat ähnelt.

Zertifikatoptionen

Die Bereitstellung von Websites mit HTTPS-Bindungen und SSL/TLS-Verschlüsselung ist eng mit dem umfassenderen Thema der Public Key-Infrastruktur (PKI) verknüpft, das ein umfangreiches und interessantes Thema ist, für das bereits eine Vielzahl von Dokumentationen vorhanden ist. Wir werden nicht versuchen, hier alle Komplexitäten abzudecken, sondern konzentrieren uns auf allgemeine Optionen für die Konfiguration von HTTPS-Bindungen für Azure DevOps Server-Bereitstellungen. Viele Organisationen verfügen über spezifische Richtlinien für die Bereitstellung von Zertifikaten. Daher besteht der erste Schritt bei der Entscheidung, welches Zertifikat für eine Azure DevOps Server-Bereitstellung verwendet werden soll, häufig mit einer Informationstechnologiegruppe auf Organisationsebene zu sprechen.

Zu den Optionen gehören:

• Es wird zugelassen, dass der TFS-Konfigurationsassistent selbstsignierte Zertifikate zur Verwendung durch die Bereitstellung generiert.
• Erhalten eines Zertifikats von einer internen Zertifizierungsstelle.
• Abrufen eines Zertifikats von einer externen Zertifizierungsstelle.

Selbstsignierte Zertifikate

Selbstsignierte Zertifikate sind nützlich für Testbereitstellungen von Azure DevOps Server, da sie sehr einfach bereitzustellen und zu verwenden sind. Sie eignen sich weniger für Produktionsbereitstellungen von Azure DevOps Server, und wir empfehlen nicht, sie für Azure DevOps Server-Bereitstellungen zu verwenden, die für das öffentliche Internet verfügbar gemacht werden. Im Allgemeinen sind selbstsignierte Zertifikate anfällig für Man-in-the-Middle-Angriffe. Sie verursachen auch Probleme für Benutzer, da sie Zertifikatwarnungen und Fehler verursachen, bis ihre Stammzertifikate auf jedem Clientcomputer installiert sind. Der Edge-Browser zeigt z. B. den folgenden Fehler an.

Wenn der TFS-Konfigurations-Assistent selbstsignierte Zertifikate für Ihre Bereitstellung generiert, erstellt er zwei – eines, das im Speicher für vertrauenswürdige Stammzertifizierungsstellen auf dem Server platziert wird, und ein zweites, das vom ersten Zertifikat signiert wird und im Persönlichen Speicher auf dem Server platziert und von Azure DevOps Server verwendet wird. Das Einrichten von Elementen auf diese Weise hilft, die Möglichkeit von Man-in-the-Middle-Angriffen zu minimieren und ermöglicht die Erneuerung des Zertifikats in der HTTPS-Bindung, ohne ein neues Zertifikat an alle Clients verteilen zu müssen, um Zertifikatfehler wie den oben gezeigten zu vermeiden.

Um diese Zertifikatwarnungen und Fehler zu vermeiden, können Sie das Stammzertifikat exportieren und auf Clientcomputern installieren. Es gibt mehrere Möglichkeiten, dies zu erreichen, einschließlich:

• Verwenden des MMC-Snap-Ins "Zertifikate", um das Zertifikat auf dem Server manuell zu exportieren und dann auf jedem Client zu importieren.
• Verwenden Sie das PowerShell-Cmdlet "Export-Certificate ", das in Windows 8/ Windows Server 2012 und höher verfügbar ist, um das Zertifikat zu exportieren. Import-Certificate kann dann verwendet werden, um es auf jedem Client zu importieren.
• Verwenden von Gruppenrichtlinien zum Automatisieren der Verteilung an Clients.

Interne und externe Zertifizierungsstellen

Viele große Organisationen verfügen über eine eigene Public Key-Infrastruktur und können Zertifikate von ihren eigenen Zertifizierungsstellen ausstellen. Wenn dies der Fall ist, werden die vertrauenswürdigen Stammzertifikate für diese Behörden bereits an Clientcomputer verteilt, wodurch die Notwendigkeit vermieden wird, zusätzliche Zertifikate für Azure DevOps Server zu verteilen. Wenn Ihre Organisation über eine eigene Public Key-Infrastruktur verfügt, kann dies eine gute Option für Ihre Azure DevOps Server-Bereitstellung sein.

Wenn andere Optionen nicht geeignet oder verfügbar sind, können Zertifikate (in der Regel zu kosten) von einer externen Zertifizierungsstelle erhalten werden. Anweisungen für diesen Prozess, der mit dem Erstellen einer Zertifikatsignaturanforderung beginnt, finden Sie auf den meisten Zertifizierungsstellenwebsites. Einige wichtige Hinweise:

• Stellen Sie sicher, dass der in der Zertifikatanforderung angegebene gemeinsame Name mit dem gewünschten Hostnamen in Ihrer öffentlichen URL übereinstimmt , z. B. tfs.contoso.com.
• In den Eigenschaften des Kryptografiedienstanbieters empfehlen wir, Microsoft RSA SChannel Cryptographic Provider und eine Bitlänge von 2048 oder höher auszuwählen.

Ändern der öffentlichen URL

Beachten Sie außerdem, dass sich das Ändern der öffentlichen URL beim Upgrade einer vorhandenen Azure DevOps Server-Bereitstellung auf Endbenutzer auswirkt. Obwohl weiterhin empfohlen wird, von HTTP in HTTPS-Bindungen zu konvertieren, müssen Visual Studio-Clientverbindungen neu eingerichtet werden, alte Lesezeichen werden nicht mehr ordnungsgemäß aufgelöst usw. Daher ist es wichtig, diese Art von Änderung mit den Benutzern Ihrer Azure DevOps Server-Bereitstellung zu koordinieren, um erhebliche Unterbrechungen zu vermeiden.