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 Team Foundation Server (TFS) benannt:

• 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 primäre Vorteil dieser Einstellungen ist, dass sie sehr einfach für Endbenutzer in den meisten Szenarien eingerichtet und bequem sind. Dies gilt insbesondere für:

• Die Verwendung von HTTP anstelle von HTTPS vermeidet die Notwendigkeit, Zertifikate abzurufen und zu installieren.
• Die Verwendung von 8080 anstelle von 80 verhindert potenzielle Konflikte mit anderen Websites auf demselben Computer.
• Die Verwendung von "tfs" als virtuelles Verzeichnis für die Website erleichtert es, Azure DevOps Server und andere Websites auf demselben Port auf demselben Server zu hosten.
• Die Verwendung des Computernamens anstelle des vollqualifizierten Domänennamens (FQDN) in der öffentlichen URL speichert viele Eingaben.
• Durch das Verlassen des Hostnamens in der Bindung, die nicht angegeben ist, kann die Verbindung flexibel sein – Computername, FQDN oder IP-Adresse funktionieren alle, wenn Benutzer versuchen, eine Verbindung mit ihren Servern herzustellen.

Diese Einstellungen sind jedoch nicht standardmäßig sicher. Insbesondere wird die Kommunikation an und von Azure DevOps Server nicht über eine HTTPS-Bindung verschlüsselt, es sei denn, andere Lösungen wie IPSec werden verwendet. Sie sind somit potenziell anfällig für böswillige Akteure, die den Inhalt der Kommunikation überwachen oder ändern. Diese Probleme werden in gewissem Umfang verringert, wenn Azure DevOps Server in einem Intranet hinter einer Unternehmens firewall bereitgestellt wird, da die meisten Azure DevOps Server Instanzen sind. Aber auch in diesen Szenarien umfassen Daten, die an und von Azure DevOps Server gesendet werden, Quellcode, Arbeitselementdaten und andere Informationen, die häufig von zusätzlicher Sicherheit profitieren könnten.

Darüber hinaus sind in TFS 2017 neue Authentifizierungsszenarien vorhanden (Build/Release-Agent-Dienstkontoauthentifizierung, persönliche Zugriffstoken), die Bearertoken über den Draht senden. Wenn diese Token von böswilligen Benutzern abgerufen werden, können sie dann verwendet werden, um die Benutzer zu stellen, denen sie angehören.

Angesichts all dieser Tatsache haben wir beschlossen, dass die Zeit stärker für die Verwendung von HTTPS-Bindungen in Azure DevOps Server Bereitstellungen eingesetzt wurde.

Festlegen von Gruppen

TFS 2017 stellt Konfigurationsoptionen für Websiteeinstellungen in allen Serverkonfigurationsszenarien vor. Mehrere Einstellungsgruppen werden bereitgestellt, die Kombinationen von Websitebindungen, virtuellen Verzeichnissen und öffentlichen URLs bündeln, die empfohlen und angenommen werden, am häufigsten verwendet werden. Für Szenarien, in denen keine dieser Einstellungsgruppen geeignet sind, können Einstellungen mithilfe des Dialogfelds "Website Einstellungen 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. Für vorhandene Bereitstellungen versuchen wir, vorhandene Einstellungen beizubehalten, die häufig dazu führen, dass die Gruppe "Standardeinstellung" ausgewählt wird.

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

• Eine HTTPS-Bindung auf 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 auf Port 80 wird nur als Komfort für Endbenutzer hinzugefügt – eine Umleitung ist konfiguriert, sodass alle Datenverkehr die HTTPS-Bindung auf Port 443 verwenden. Die öffentliche URL für diese Einstellungsgruppe ist das Formular. https://fully-qualified-domain-name. Standardmäßig stellt diese Einstellungsgruppe neue selbst signierte Zertifikate bereit und verwendet sie für die HTTPS-Bindung. Es wird in der Regel nicht empfohlen, selbst signierte Zertifikate für Produktions TFS-Bereitstellungen zu verwenden. Weitere Informationen dazu finden Sie unter "Zertifikatoptionen", wenn es geeignet ist, selbst signierte Zertifikate zu verwenden und welche anderen Optionen verfügbar sind.

Die HTTPS-Einstellungsgruppe stellt eine einzelne HTTPS-Bindung am Port 443 mit dem FQDN des Computers als Hostname bereit. Erneut ist die öffentliche URL für diese Einstellungsgruppe das Formular https://fully-qualified-domain-name, und selbstsignierte Zertifikate werden standardmäßig bereitgestellt.

Die HTTP-Einstellungsgruppe stellt eine einzelne HTTP-Bindung auf Port 80 ohne angegebenen Hostnamen bereit. Die öffentliche URL für diese Einstellungsgruppe ist das Formular. http://machine-name.

Bei Verwendung der HTTPS- und HTTP-Einstellungsgruppe (mit Umleitung) wird die Verwendung einer öffentlichen HTTP-URL nicht empfohlen. Die meisten modernen Browser berücksichtigen standardmäßig die unsicheren HTTP- und HTTPS-Inhalte und können leere Seiten anzeigen. 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 breiteren Thema der öffentlichen Schlüsselinfrastruktur (PKI) verbunden, für das ein umfangreiches und interessantes Thema ist, für das bereits eine Vielzahl von Dokumentationen vorhanden ist. Wir werden nicht versuchen, alle Komplexität hier abzudecken, sondern sich auf hohe Optionen zum Konfigurieren von HTTPS-Bindungen für Azure DevOps Server Bereitstellungen konzentrieren. Viele Organisationen verfügen über bestimmte Richtlinien zur Bereitstellung von Zertifikaten, sodass der erste Schritt beim Entscheiden, 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:

• Ermöglicht es dem TFS-Konfigurations-Assistenten, selbst signierte Zertifikate für die Verwendung durch die Bereitstellung zu generieren.
• Abrufen eines Zertifikats aus einer internen Zertifizierungsstelle.
• Abrufen eines Zertifikats aus einer externen Zertifizierungsstelle.

Selbstsignierte Zertifikate

Selbstsignierte Zertifikate sind nützlich für Testbereitstellungen von Azure DevOps Server, da sie sehr einfach bereitgestellt und verwendet werden können. Sie sind weniger geeignet für Produktionsbereitstellungen von Azure DevOps Server, und es wird nicht empfohlen, sie für Azure DevOps Server Bereitstellungen, die im öffentlichen Internet verfügbar sind, zu verwenden. Im Allgemeinen sind selbst signierte 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 Edgebrowser zeigt beispielsweise den folgenden Fehler an.

Wenn der TFS-Konfigurations-Assistent selbst signierte Zertifikate für Ihre Bereitstellung generiert, erstellt sie zwei - eine, die im Speicher für vertrauenswürdige Stammzertifizierungsstellen auf dem Server platziert wird, und eine zweite, die vom ersten signiert wird, das im persönlichen Speicher auf dem Server platziert und von Azure DevOps Server verwendet wird. Das Einrichten von Dingen auf diese Weise hilft, die Möglichkeit von Man-in-the-Middle-Angriffen zu verringern und die Drehung des zertifikats, das in der HTTPS-Bindung verwendet wird, ohne auch ein neues Zertifikat an alle Clients zu verteilen, um Zertifikatfehler wie oben dargestellt zu vermeiden.

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

• Mithilfe des MMC-Snap-Ins für Zertifikate können Sie das Zertifikat auf dem Server manuell exportieren und dann auf jedem Client importieren.
• Verwenden Sie das Cmdlet "Exportzertifikat", das in Windows 8/ Windows Server 2012 und späteren Betriebssystemen verfügbar ist, um das Zertifikat zu exportieren. Importzertifikat kann dann zum Importieren auf jedem Client verwendet werden.
• Verwenden sie Gruppenrichtlinie, um die Verteilung auf Clients zu automatisieren.

Interne und externe Zertifizierungsstellen

Viele große Organisationen verfügen über eine eigene öffentliche Schlüsselinfrastruktur und können Zertifikate aus 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 öffentliche Schlüsselinfrastruktur 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 einem Kostenaufwand) aus einer externen Zertifizierungsstelle (CA) abgerufen werden. Anweisungen für diesen Prozess, der mit dem Erstellen einer Zertifikatsignaturanforderung beginnt, finden Sie auf den meisten CA-Websites. Wichtige Hinweise:

• Stellen Sie sicher, dass der in der Zertifikatanforderung angegebene Allgemeine Name mit dem gewünschten Hostnamen in Ihrer öffentlichen URL übereinstimmt – z. B. tfs.contoso.com.
• Bei den Eigenschaften des Kryptografiedienstanbieters empfehlen wir die Auswahl des Microsoft RSA SChannel-Kryptografieanbieters und eine Bitlänge von 2048 oder höher.

Ändern ihrer öffentlichen URL

Es sollte auch erwähnt werden, dass beim Upgrade einer vorhandenen Azure DevOps Server-Bereitstellung das Ändern der öffentlichen URL auf Endbenutzer wirkt sich auf Endbenutzer aus. Während wir weiterhin die Konvertierung von HTTP in HTTPS-Bindungen empfehlen, müssen Visual Studio Clientverbindungen erneut eingerichtet werden, alte Lesezeichen werden nicht mehr ordnungsgemäß aufgelöst und so weiter. Daher ist es wichtig, diese Art von Änderung mit den Benutzern Ihrer Azure DevOps Server Bereitstellung zu koordinieren, um erhebliche Unterbrechungen zu vermeiden.