Authentifizierungsleitfaden für Azure DevOps

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Verwenden Sie diesen Artikel, um einen Authentifizierungsansatz für Azure DevOps auf Organisationsebene auszuwählen. Sie umfasst Sicherheitsstatus, Governance und Wartung für allgemeine Methoden und verknüpft dann mit implementierungsorientierten Anleitungen.

Details zur Implementierung auf App-Ebene finden Sie unter Authentifizierungsmethoden für Azure DevOps.

Unterschiede zwischen Diensten und Servern

Authentifizierungsoptionen unterscheiden sich zwischen Azure DevOps Services und Azure DevOps Server.

Platform Empfohlene Standardeinstellung Hinweise
Azure DevOps Services Microsoft Entra basierte Authentifizierung Verwenden Sie Microsoft Entra Anmeldung für Benutzer und Microsoft Entra Anwendungsidentitäten für die Automatisierung.
Azure DevOps Server Windows-Authentifizierung, .NET Clientbibliotheken oder PATs, die unterstützt werden Dienstprinzipal- und verwaltete Identitätsmuster für Azure DevOps Authentifizierung gelten für Azure DevOps Dienste, nicht für Azure DevOps Server.

Vergleich allgemeiner Authentifizierungsoptionen

Verwenden Sie die folgende Tabelle, um allgemeine Auswahlmöglichkeiten für Benutzer, Apps, Skripts und Pipelines zu vergleichen.

Method Am besten geeignet für: Sicherheitsstatus Verwaltung von Anmeldeinformationen Funktioniert mit Vermeiden, wenn
Microsoft Entra Benutzeranmeldung Interaktiver Benutzerzugriff auf Azure DevOps Organisationen Starke Option mit zentraler Identitätsgovernance, bedingtem Zugriff und mehrstufiger Authentifizierung Verwaltet durch Microsoft Entra Lebenszyklus- und Mandantenrichtlinien Azure DevOps Services Sie implementieren die unbeaufsichtigte App-zu-App-Automatisierung
Verwaltete Identität Azure gehostete Automatisierung, z. B. Azure Functions oder App Service Stärkste Option für Azure gehostete Automatisierung, da Token kurzlebig sind und Azure den Identitätslebenszyklus verwalten Kein geheimer Clientschlüssel zum Speichern oder Drehen Azure DevOps Services Die Workload wird nicht auf Azure ausgeführt, oder Sie benötigen eine tragbare Identität in allen Umgebungen.
Service Principal Automatisierung außerhalb Azure oder über mehrere Umgebungen und CI/CD-Systeme Starke Option, wenn Sie die geringsten Berechtigungen und moderne Anmeldeinformationsmuster verwenden Sie verwalten App-Identität und -Anmeldeinformationen, es sei denn, ein Partnerfluss entfernt geheime Schlüssel. Azure DevOps Services Eine verwaltete Identität kann die gleiche Anforderung für Azure gehostete Workloads erfüllen.
Azure DevOps Dienstverbindung Azure Pipelines Zugriff auf Azure DevOps Ressourcen Starke Option für die Pipelineautomatisierung, da sie Den Workload-Identitätsverbund verwendet und pat sprawl in Pipelines vermeidet Verwaltet über Azure DevOps Dienstverbindungseinstellungen Azure DevOps Services-Pipelines Das Szenario wird nicht durch Azure Pipelines
Persönliches Zugriffstoken (Personal Access Token, PAT) Kurzlebige persönliche Skripts, einmalige Tests oder Legacykompatibilitätsszenarien Höchstes Risiko, da PATs langlebige Bearerschlüssel sind, die an Benutzerkonten gebunden sind Manuelle Erstellung, Speicherung, Drehung und Sperrung Azure DevOps Services und Azure DevOps Server Produktionsautomatisierung, bei der Dienstprinzipal, verwaltete Identität oder Dienstverbindung verfügbar ist

Important

Erwägen Sie die Verwendung der sichereren Microsoft Entra-Token gegenüber den risikoreicheren persönlichen Zugriffstoken. Weitere Informationen finden Sie unter Reduzieren der PAT-Verwendung. Überprüfen Sie die Authentifizierungsanleitungen , um den richtigen Authentifizierungsmechanismus für Ihre Anforderungen auszuwählen.

  • Verwenden Sie Microsoft Entra Benutzeranmeldung für den Benutzerzugriff auf Azure DevOps Services-Organisationen.
  • Verwenden Sie die verwaltete Identität zuerst für Azure gehostete Automatisierung.
  • Verwenden Sie den Dienstprinzipal für nicht Azure oder die umgebungsübergreifende Automatisierung.
  • Verwenden Sie Azure DevOps Dienstverbindung, wenn Azure Pipelines Azure DevOps Ressourcenzugriff benötigt.
  • Verwenden Sie PATs nur für temporäre, persönliche, ältere oder Azure DevOps Server Szenarien, in denen sicherere Optionen nicht gelten.

Gründe für die Verwendung von PATs

Verwenden Sie PATs in eingeschränkten Szenarien, z. B.:

  • Persönliche Ad-hoc-Skripts
  • Einmalige API-Problembehandlung
  • Ältere Tools, die Microsoft Entra-basierte Authentifizierung nicht verwenden können
  • Azure DevOps Server Szenarien, in denen moderne Cloudidentitätsflüsse nicht verfügbar sind

Wenn Sie PATs verwenden:

  • Beschränken Sie sie auf die erforderlichen Mindestberechtigungen.
  • Verwenden Sie die kürzeste praktische Lebensdauer.
  • Speichern und drehen Sie sie als geheime Schlüssel.
  • Ersetzen Sie sie nach Möglichkeit durch Microsoft Entra-basierte Optionen.

Informationen zum PAT-Lebenszyklus finden Sie unter Verwenden von persönlichen Zugriffstoken und Verwalten von PAT-Richtlinien.

Richtlinien- und Governancesteuerelemente

Verwenden Sie Organisations- und Mandantensteuerelemente, um den Authentifizierungsstatus zu erzwingen:

Checkliste für Entscheidungen

Bevor Sie eine Authentifizierungsmethode auswählen, bestätigen Sie Folgendes:

  • Ist dieser benutzeraktive Zugriff oder die unbeaufsichtigte Automatisierung?
  • Wird die Workload in Azure oder außerhalb Azure gehostet?
  • Ist die Zielplattform Azure DevOps Services oder Azure DevOps Server?
  • Kann dieses Szenario langlebige Anmeldeinformationen vermeiden?
  • Sind Organisationsrichtlinien und Überwachungsanforderungen erfüllt?

Implementierungshandbücher

  • Last updated on