Informationen zu Sicherheit, Authentifizierung und Autorisierung

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Azure DevOps verwendet viele Sicherheitskonzepte, um sicherzustellen, dass nur benutzer, die Zugriff auf Features, Funktionen und Daten haben sollen. Konten erhalten Zugriff auf Azure DevOps durch Authentifizierung ihrer Sicherheitsanmeldeinformationen und Autorisierung ihrer Kontoberechtigungen für den Zugriff auf ein Feature oder eine Funktion.

Dieser Artikel baut auf den Informationen unter Erste Schritte mit Berechtigungen, Zugriff und Sicherheitsgruppen auf. Administratoren profitieren vom Verständnis der Kontotypen, Authentifizierungsmethoden, Autorisierungsmethoden und Richtlinien, die zum Schützen von Azure DevOps verwendet werden.


Kontotypen

  • Benutzer
  • Organisationsbesitzer
  • Dienstkonten
  • Dienstprinzipale oder verwaltete Identitäten
  • Auftragsagenten

Authentifizierung

  • Benutzeranmeldeinformationen
  • Windows-Authentifizierung
  • Zweistufige Authentifizierung (2FA)
  • SSH-Schlüsselauthentifizierung
  • Persönliche Zugriffstoken
  • Oauth-Konfiguration
  • Active Directory-Authentifizierungsbibliothek

Autorisierung

  • Mitgliedschaft in einer Sicherheitsgruppe
  • Rollenbasierte Zugriffssteuerung
  • Zugriffsebenen
  • Featureflags
  • Sicherheitsnamespaces und -berechtigungen

Richtlinien

  • URL zur Datenschutzrichtlinie
  • Anwendungsverbindungs- und Sicherheitsrichtlinien
  • Richtlinien für Benutzer
  • Git-Repository- und Branchrichtlinien


Kontotypen

  • Benutzer
  • Dienstkonten
  • Dienstprinzipale oder verwaltete Identitäten
  • Auftragsagenten

Authentifizierung

  • Benutzeranmeldeinformationen
  • Windows-Authentifizierung
  • Zweistufige Authentifizierung (2FA)
  • SSH-Schlüsselauthentifizierung
  • Persönliche Zugriffstoken
  • Oauth-Konfiguration
  • Active Directory-Authentifizierungsbibliothek

Autorisierung

  • Mitgliedschaft in einer Sicherheitsgruppe
  • Rollenbasierte Berechtigungen
  • Zugriffsebenen
  • Featureflags
  • Sicherheitsnamespaces und -berechtigungen

Richtlinien

  • Git-Repository- und Branchrichtlinien

Wichtig

Azure DevOps unterstützt die Authentifizierung alternativer Anmeldeinformationen seit Dem 2. März 2020 nicht mehr. Wenn Sie noch alternative Anmeldeinformationen verwenden, empfehlen wir Ihnen dringend, zu einer sichereren Authentifizierungsmethode (z. B. persönliche Zugriffstoken) zu wechseln. Weitere Informationen

Sowohl unser Clouddienst, Azure DevOps Services als auch der lokale Server Azure DevOps Server unterstützen Softwareentwicklungsprojekte von der Planung bis zur Bereitstellung. Azure DevOps verwendet die Platform-as-a-Service-Infrastruktur von Microsoft Azure und viele Azure-Dienste, einschließlich Azure SQL Datenbanken, um einen zuverlässigen, global verfügbaren Dienst für Ihre Entwicklungsprojekte bereitzustellen.

Weitere Informationen zu den Schritten, die Microsoft unternimmt, um Ihre Projekte in Azure DevOps Services sicher, verfügbar, sicher und privat zu halten, finden Sie in diesem Whitepaper Azure DevOps Services Übersicht über den Datenschutz.

Konten

Während die Standard Typen von interessanten Konten die menschlichen Benutzerkonten sind, die Sie Ihrem organization oder Projekt hinzufügen, unterstützt Azure DevOps andere Arten von Konten, um verschiedene Vorgänge auszuführen. Dazu gehören die folgenden Kontotypen.

  • Organisationsbesitzer: Der Ersteller eines Azure DevOps Services organization oder zugewiesenen Besitzers. Um zu erfahren, wer der Organisationsbesitzer für Ihre organization ist, finden Sie unter Nachschlagen des Organisationsbesitzer.
  • Dienstkonten: Interne Azure DevOps-Konten, die zur Unterstützung eines bestimmten Diensts verwendet werden, z. B. Agent Pool Service, PipelinesSDK. Beschreibungen von Dienstkonten finden Sie unter Sicherheitsgruppen, Dienstkonten und Berechtigungen.
  • Dienstprinzipale oder verwaltete Identitäten: Microsoft Entra-Anwendungen oder verwaltete Identitäten , die Ihrer Organisation hinzugefügt wurden, um Aktionen im Auftrag einer Drittanbieteranwendung auszuführen. Einige Dienstprinzipale beziehen sich auf interne Azure DevOps-Konten, um interne Vorgänge zu unterstützen.
  • Auftrags-Agents: Interne Konten, mit denen bestimmte Aufträge regelmäßig ausgeführt werden.
  • Konten von Drittanbietern: Konten, die Zugriff benötigen, um Web-Hooks, Dienstverbindungen oder andere Anwendungen von Drittanbietern zu unterstützen.

In dieser Dokumentation können Benutzer auf alle Identitäten verweisen, die dem Benutzer-Hub hinzugefügt wurden, einschließlich menschlicher Benutzer und Dienstprinzipale.

  • Dienstkonten: Interne Azure DevOps-Konten, die zur Unterstützung eines bestimmten Diensts verwendet werden, z. B. Agent Pool Service, PipelinesSDK. Beschreibungen von Dienstkonten finden Sie unter Sicherheitsgruppen, Dienstkonten und Berechtigungen.
  • Dienstprinzipale oder verwaltete Identitäten: Microsoft Entra-Anwendungen oder verwaltete Identitäten, die Ihrer Organisation hinzugefügt wurden, um Aktionen im Auftrag einer Drittanbieteranwendung auszuführen. Einige Dienstprinzipale beziehen sich auf interne Azure DevOps-Konten, um interne Vorgänge zu unterstützen.
  • Auftrags-Agents: Interne Konten, mit denen bestimmte Aufträge regelmäßig ausgeführt werden.
  • Konten von Drittanbietern: Konten, die Zugriff benötigen, um Web-Hooks, Dienstverbindungen oder andere Anwendungen von Drittanbietern zu unterstützen.

Die effektivste Methode zum Verwalten von Konten ist das Hinzufügen dieser Konten zu Sicherheitsgruppen.

Hinweis

Den Organisationsbesitzer und Mitgliedern der Gruppe "Projektsammlungsadministratoren" wird voller Zugriff auf die meisten Features und Funktionen gewährt.

Authentifizierung

Die Authentifizierung überprüft eine Kontoidentität basierend auf den Anmeldeinformationen, die bei der Anmeldung bei Azure DevOps angegeben wurden. Diese Systeme sind in die Sicherheitsfeatures dieser anderen Systeme integriert und basieren darauf:

  • Microsoft Entra ID
  • Microsoft-Konto (MSA)
  • Active Directory (AD)

Microsoft Entra ID und MSA unterstützen die Cloudauthentifizierung. Wir empfehlen Microsoft Entra-ID, wenn Sie eine große Benutzergruppe verwalten müssen. Andernfalls können Sie Microsoft-Konten verwenden, wenn eine kleine Benutzerbasis auf Ihre organization in Azure DevOps zugreift. Weitere Informationen finden Sie unter "Zugriff auf Azure DevOps mit Microsoft Entra ID".

Für lokale Bereitstellungen wird AD empfohlen, wenn eine große Gruppe von Benutzern verwaltet wird. Weitere Informationen finden Sie unter Einrichten von Gruppen für die Verwendung in lokalen Bereitstellungen.

Authentifizierungsmethoden, Integration in andere Dienste und Apps

Andere Anwendungen und Dienste können in Azure DevOps in Dienste und Ressourcen integriert werden. Um auf Ihr Konto zuzugreifen, ohne mehrmals nach den Benutzerdaten zu fragen, können Anwendungen die folgenden Authentifizierungsmethoden verwenden.

  • Persönliche Zugriffstoken zum Generieren von Token im eigenen Namen für:

    • Um auf bestimmte Ressourcen oder Aktivitäten zuzugreifen, z. B. Builds oder Arbeitselemente
    • Für Clients wie Xcode und NuGet, die Benutzernamen und Kennwörter als grundlegende Anmeldeinformationen erfordern und Microsoft-Kontos und Microsoft Entra-Features wie mehrstufige Authentifizierung nicht unterstützen
    • Zugreifen auf Azure DevOps-REST-APIs
  • Azure DevOps OAuth zum Generieren von Tokens im Namen von Benutzern für den Zugriff auf REST-APIs. Die Konten- und Profil-APIs unterstützen nur OAuth.

  • SSH-Authentifizierung zum Generieren von Verschlüsselungsschlüsseln für Sie selbst, wenn Sie Linux-, macOS- oder Windows-Systeme verwenden, die Git für Windows ausführen, und keine Git-Anmeldeinformationen-Manager oder persönliche Zugriffstoken für die HTTPS-Authentifizierung verwenden können.

  • Dienstprinzipale oder verwaltete Identitäten zum Generieren von Microsoft Entra-Token im Auftrag einer Anwendung oder eines Diensts, die in der Regel einen Workflow automatisiert, der auf Azure DevOps-Ressourcen zugreifen muss. Die meisten Aktionen, die traditionell von einem Dienstkonto und einem PAT durchgeführt werden, können mithilfe eines Dienstprinzipals oder einer verwalteten Identität durchgeführt werden.

Standardmäßig ermöglicht Ihr Konto oder die Sammlung Zugriff auf alle Authentifizierungsmethoden. Sie können den Zugriff einschränken, aber Sie müssen den Zugriff für jede Methode speziell einschränken. Wenn Sie den Zugriff auf eine Authentifizierungsmethode verweigern, kann keine App diese Methode verwenden, um auf Ihr Konto zuzugreifen. Jede App, die zuvor Zugriff hatte, gibt einen Authentifizierungsfehler aus und kann nicht auf Ihr Konto zugreifen.

Weitere Informationen zum Speichern Ihrer Anmeldeinformationen finden Sie unter Speicher von Anmeldeinformationen für Azure DevOps.

Weitere Informationen zum Auswählen des richtigen Authentifizierungsmechanismus finden Sie unter Leitfaden für die Authentifizierung.

Authorization

Mit der Autorisierung wird überprüft, ob die Identität, die versucht, eine Verbindung herzustellen, über die erforderlichen Berechtigungen für den Zugriff auf einen Dienst, ein Feature, eine Funktion, ein Objekt oder eine Methode verfügt. Die Autorisierung erfolgt immer nach erfolgreicher Authentifizierung. Wenn eine Verbindung nicht authentifiziert ist, tritt ein Fehler auf, bevor eine Autorisierungsprüfung durchgeführt wird. Wenn die Authentifizierung einer Verbindung erfolgreich ist, kann eine bestimmte Aktion weiterhin nicht zulässig sein, da der Benutzer oder die Gruppe nicht berechtigt war, diese Aktion auszuführen.

Die Autorisierung hängt von den Berechtigungen ab, die dem Konto zugewiesen sind. Berechtigungen werden entweder direkt für ein Konto oder über die Mitgliedschaft in einer Sicherheitsgruppe oder Sicherheitsrolle erteilt. Zugriffsebenen und Featureflags können auch den Zugriff auf ein Feature gewähren oder einschränken. Weitere Informationen zu diesen Autorisierungsmethoden finden Sie unter Erste Schritte mit Berechtigungen, Zugriff und Sicherheitsgruppen.

Sicherheitsnamespaces und Berechtigungen

Sicherheitsnamespaces speichern Daten, die die Zugriffsebene bestimmen, die Azure DevOps-Konten zum Ausführen einer bestimmten Aktion für eine bestimmte Ressource haben. Jede Ressourcenfamilie, z. B. Arbeitselemente oder Git-Repositorys, wird durch einen eindeutigen Namespace geschützt. Jeder Sicherheitsnamespace enthält keine oder mehr Zugriffssteuerungslisten (Access Control Lists, ACLs). Jede ACL enthält ein Token, ein Vererbungsflag und einen Satz von null oder mehr Zugriffssteuerungseinträgen (Access Control Entries, ACEs). Jeder ACE enthält einen Identitätsdeskriptor, eine Bitmaske für zulässige Berechtigungen und eine Bitmaske für verweigerte Berechtigungen.

Weitere Informationen finden Sie unter Sicherheitsnamespaces und Berechtigungsreferenz.

Sicherheitsrichtlinien

Um Ihre organization und Ihren Code zu schützen, können Sie viele Richtlinien festlegen. Insbesondere können Sie die folgenden Richtlinien aktivieren oder deaktivieren:

Allgemein

Anwendungsverbindungs- und Sicherheitsrichtlinien

Verwenden Sie die Microsoft Entra-Mandantenrichtlinie, um das Erstellen neuer Organisationen nur auf die gewünschten Benutzer einzuschränken. Diese Richtlinie ist standardmäßig deaktiviert und nur gültig, wenn die Organisation mit der Microsoft Entra-ID verbunden ist. Weitere Details finden Sie unter Einschränken organization Erstellung.

Die folgenden Richtlinien bestimmen den Zugriff, den Sie Benutzern und Anwendungen für Ihre Organisationen gewähren möchten:

Richtlinien für Benutzer

  • Externer Gastzugriff (nur gültig, wenn die Organisation mit Microsoft Entra ID verbunden ist).): Wenn diese Option aktiviert ist, können Einladungen an E-Mail-Konten von Benutzern gesendet werden, die nicht Mitglieder der Microsoft Entra-ID des Mandanten sind, über die Seite "Benutzer ". Weitere Informationen finden Sie unter Hinzufügen externer Benutzer zu Ihrem organization.
  • Zulassen, dass Team- und Projektadministratoren neue Benutzer einladen: Nur gültig, wenn die Organisation mit der Microsoft Entra-ID verbunden ist. Wenn diese Option aktiviert ist, können Team- und Projektadministratoren Benutzer über die Seite Benutzer hinzufügen. Weitere Informationen finden Sie unter Einschränken neuer Benutzerinladungen von Projekt- und Teamadministratoren.
  • Anfordern des Zugriffs: Nur gültig, wenn die Organisation mit der Microsoft Entra-ID verbunden ist. Wenn diese Option aktiviert ist, können Benutzer Zugriff auf eine Ressource anfordern. Eine Anforderung führt zu einer E-Mail-Benachrichtigung an die Administratoren, die nach Bedarf um Überprüfung und Zugriff bitten. Weitere Informationen finden Sie unter Hinzufügen externer Benutzer zu Ihrem organization.
  • Laden Sie GitHub-Benutzer ein: Nur gültig, wenn die Organisation nicht mit der Microsoft Entra-ID verbunden ist. Wenn diese Option aktiviert ist, können Administratoren Benutzer basierend auf ihren GitHub-Benutzerkonten über die Seite Benutzer hinzufügen. Weitere Informationen finden Sie in den häufig gestellten Fragen zur Authentifizierung und Einladung von GitHub-Benutzern.

Gruppe "Project-Scoped-Benutzer"

Standardmäßig können Benutzer, die einem organization hinzugefügt werden, alle organization- und Projektinformationen und -einstellungen anzeigen. Dies umfasst das Anzeigen einer Benutzerliste, einer Liste von Projekten, Abrechnungsdetails, Nutzungsdaten und mehr, auf die über die Organisationseinstellungen zugegriffen wird.

Wichtig

  • Die in diesem Abschnitt beschriebenen Features für eingeschränkte Sichtbarkeit gelten nur für Interaktionen über das Webportal. Mit den REST-APIs oder azure devops CLI-Befehlen können Projektmitglieder auf die eingeschränkten Daten zugreifen.
  • Gastbenutzer, die Mitglieder in der eingeschränkten Gruppe mit Standardzugriff in der Microsoft Entra-ID sind, können nicht nach Benutzern mit der Personenauswahl suchen. Wenn das Vorschaufeature für die Organisation deaktiviertist oder Gastbenutzer keine Mitglieder der eingeschränkten Gruppe sind, können Gastbenutzer alle Microsoft Entra-Benutzer wie erwartet durchsuchen.

Um ausgewählte Benutzer wie Projektbeteiligte, Microsoft Entra-Gastbenutzer oder Mitglieder einer bestimmten Sicherheitsgruppe einzuschränken, können Sie die Sichtbarkeit der Benutzer und die Zusammenarbeit auf bestimmte Projekte in der Vorschaufunktion für die Organisation beschränken. Sobald dies aktiviert ist, werden alle Benutzer oder Gruppen, die der Gruppe "Project-Scoped Users" hinzugefügt wurden, auf folgende Weise eingeschränkt:

  • Kann nur auf die Seiten Übersicht und Projekte der Organisationseinstellungen zugreifen.
  • Kann nur die Projekte verbinden und anzeigen, denen sie explizit hinzugefügt wurden (siehe Hinzufügen von Benutzern zu einem Projekt oder Team).
  • Es können nur Benutzer- und Gruppenidentitäten ausgewählt werden, die dem Projekt, mit dem sie verbunden sind, explizit hinzugefügt wurden.

Weitere Informationen finden Sie unter Verwalten Ihrer Organisation, Einschränken der Benutzersichtbarkeit für Projekte und mehr und Verwalten von Vorschaufeatures.

Warnung

Wenn das Feature " Benutzersichtbarkeit und Zusammenarbeit auf bestimmte Projekte in der Vorschau" für die Organisation beschränkt ist, können projektbezogene Benutzer nicht nach Benutzern suchen, die über die Microsoft Entra-Gruppenmitgliedschaft zur Organisation hinzugefügt wurden, anstatt über eine explizite Benutzereinladung. Dies ist ein unerwartetes Verhalten, an dem an einer Lösung gearbeitet wird. Um dieses Problem selbst zu beheben, deaktivieren Sie die Vorschaufunktion Benutzersichtbarkeit und Zusammenarbeit auf bestimmte Projekte beschränken für die organization.

Git-Repository- und Branchrichtlinien

Um Ihren Code zu schützen, können Sie viele Git-Repository- und Branchrichtlinien festlegen. Weitere Informationen findest du in den folgenden Artikeln.

Azure Repos und Azure Pipelines-Sicherheit

Da Repositorys sowie Build- und Releasepipelines einzigartige Sicherheitsprobleme darstellen, werden andere Features verwendet, die über die in diesem Artikel beschriebenen Features hinausgehen. Weitere Informationen findest du in den folgenden Artikeln.

Nächste Schritte