Websiteeinstellungen und Sicherheit für Azure DevOps lokal

TFS 2017 | TFS 2015 | TFS 2013

Hintergrund

Für viele Releases waren die Standardwebsiteeinstellungen für Azure DevOps Server, die zuvor team Foundation Server (TFS) genannt wurden:

• Eine einzelne HTTP-Bindung für die Azure DevOps Server-Website an Port 8080, ohne hostnamen 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 in den meisten Szenarien sehr einfach eingerichtet und für Endbenutzer bequem sind. Dies gilt insbesondere für:

• Die Verwendung von HTTP anstelle von HTTPS vermeidet das Abrufen und Installieren von Zertifikaten.
• Die Verwendung von 8080 anstelle von 80 vermeidet potenzielle Konflikte mit anderen Websites auf demselben Computer.
• Die Verwendung von "tfs" als virtuelles Verzeichnis für die Website erleichtert das Hosten Azure DevOps Server und anderer Websites auf demselben Port auf demselben Server.
• Die Verwendung des Computernamens anstelle des vollqualifizierten Domänennamens (Fully-Qualified Domain-Name, FQDN) in der öffentlichen URL spart viel Eingabe.
• Wenn sie den Hostnamen in der Bindung nicht angegeben lassen, kann die Verbindung flexibel hergestellt werden. 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, wenn keine HTTPS-Bindung verwendet wird, wird die Kommunikation mit und von Azure DevOps Server während der Übertragung nicht verschlüsselt, es sei denn, andere Lösungen wie IPSec werden verwendet. Sie sind daher potenziell anfällig für böswillige Akteure, die den Inhalt der Kommunikation überwachen oder sogar ändern. Diese Probleme werden bis zu einem gewissen Grad gemildert, wenn Azure DevOps Server in einem Intranet hinter einer Unternehmensfirewall bereitgestellt wird, da die überwiegende Mehrheit der Azure DevOps Server Instanzen dies ist. Aber auch in diesen Szenarien enthalten Daten, die an und von Azure DevOps Server gesendet werden, Quellcode, Arbeitselementdaten und andere Informationen, die häufig von zusätzlicher Sicherheit profitieren können.

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

Angesichts all dieser Tatsachen entschieden wir, dass die Zeit gekommen war, uns stärker für die Verwendung von HTTPS-Bindungen in Azure DevOps Server Bereitstellungen einzusetzen.

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 unserer Meinung nach am häufigsten verwendet werden. In Szenarien, in denen keine dieser Einstellungsgruppen geeignet ist, können die Einstellungen über das Dialogfeld Websiteeinstellungen bearbeiten vollständig angepasst werden.

Die Einstellungsgruppe Standard enthält dieselben Einstellungen, die in früheren Versionen von Azure DevOps Server verwendet wurden. 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 Einstellungsgruppe Standard ausgewählt wird.

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

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

Die HTTP-Bindung an Port 80 wird nur als Benutzerfreundlichkeit hinzugefügt. Eine Umleitung wird so konfiguriert, dass der gesamte Datenverkehr die HTTPS-Bindung an Port 443 verwendet. Die öffentliche URL für diese Einstellungsgruppe hat das Format. https://fully-qualified-domain-name. Standardmäßig stellt diese Einstellungsgruppe neue selbstsignierte Zertifikate bereit und verwendet sie für die HTTPS-Bindung. In der Regel wird die Verwendung selbstsignierter Zertifikate für TFS-Produktionsbereitstellungen nicht empfohlen. Weitere Informationen dazu, wann selbstsignierte Zertifikate verwendet werden sollten und welche weiteren Optionen verfügbar sind, finden Sie unter Zertifikatoptionen unten.

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

Die Einstellungsgruppe "Nur HTTP" stellt eine einzelne HTTP-Bindung an Port 80 ohne angegebenen Hostnamen fest. Die öffentliche URL für diese Einstellungsgruppe hat das Format. http://machine-name.

Bei Verwendung der Einstellungsgruppe HTTPS und HTTP (mit Umleitung) wird die Verwendung einer öffentlichen HTTP-URL nicht empfohlen. Die meisten modernen Browser betrachten den gemischten HTTP- und HTTPS-Inhalt standardmäßig als unsicher und zeigen möglicherweise leere Seiten an. Obwohl es in der Regel möglich ist, die Standardbrowsereinstellungen zu überschreiben 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 unter Verwendung von HTTPS-Bindungen und SSL/TLS-Verschlüsselung steht in engem Zusammenhang mit dem umfassenderen Thema der Public Key Infrastructure (PKI), ein umfangreiches und interessantes Thema, für das bereits eine Vielzahl von Dokumentationen vorhanden ist. Wir versuchen hier nicht, die gesamte Komplexität abzudecken, sondern konzentrieren uns auf allgemeine Optionen zum Konfigurieren 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 organization ebene zu sprechen.

Beispiele für Optionen:

• Zulassen, dass der TFS-Konfigurations-Assistent selbstsignierte Zertifikate für die Verwendung durch die Bereitstellung generieren kann.
• Abrufen eines Zertifikats von einer internen Zertifizierungsstelle.
• Abrufen eines Zertifikats von einer externen Zertifizierungsstelle.

Selbstsignierte Zertifikate

Selbstsignierte Zertifikate sind für Testbereitstellungen von Azure DevOps Server nützlich, da sie sehr einfach bereitzustellen und zu verwenden sind. Sie eignen sich weniger für Produktionsbereitstellungen von Azure DevOps Server, und es wird nicht empfohlen, sie für Azure DevOps Server Bereitstellungen zu verwenden, die im öffentlichen Internet verfügbar sind. 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 beispielsweise den folgenden Fehler an.

Wenn der TFS-Konfigurations-Assistent selbstsignierte Zertifikate für Ihre Bereitstellung generiert, werden zwei erstellt: eines, das im Speicher vertrauenswürdiger Stammzertifizierungsstellen auf dem Server platziert wird, und ein zweites, von der ersten signiert, das im persönlichen Speicher auf dem Server abgelegt und von Azure DevOps Server verwendet wird. Das Einrichten auf diese Weise hilft, die Möglichkeit von Man-in-the-Middle-Angriffen zu minimieren und die Rotation des in der HTTPS-Bindung verwendeten Zertifikats zu ermöglichen, ohne auch 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 manuell auf dem Server zu exportieren und dann auf jeden Client zu importieren.
• Verwenden Sie das PowerShell-Cmdlet Export-Certificate, das in Windows 8/Windows Server 2012 und höheren Betriebssystemen verfügbar ist, um das Zertifikat zu exportieren. Import-Certificate kann dann verwendet werden, um es auf jedem Client zu importieren.
• Verwenden von Gruppenrichtlinie, um die Verteilung an Clients zu automatisieren.

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. In der Regel werden die vertrauenswürdigen Stammzertifikate für diese Instanzen in der Regel bereits an Clientcomputer verteilt, sodass keine zusätzlichen Zertifikate für Azure DevOps Server verteilt werden müssen. Wenn Ihr organization ü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 kostenpflichtig) von einer externen Zertifizierungsstelle bezogen werden. Anweisungen für diesen Prozess, der mit dem Erstellen einer Zertifikatsignaturanforderung beginnt, finden Sie auf den meisten Websites von Zertifizierungsstellen. Wichtige Hinweise:

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

Ändern Ihrer öffentlichen URL

Beachten Sie auch, dass beim Upgrade einer vorhandenen Azure DevOps Server Bereitstellung die Änderung der öffentlichen URL die Endbenutzer beeinträchtigt. Während wir weiterhin empfehlen, von HTTP-Bindungen in HTTPS-Bindungen zu konvertieren, müssen Visual Studio-Clientverbindungen wiederhergestellt 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.