Bewährte Sicherheitsmethoden

  • Artikel

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

Wenn Sie mit Informationen und Daten arbeiten, insbesondere in einer cloudbasierten Lösung wie Azure DevOps Services, sollte die Priorisierung der Sicherheit immer Ihr oberstes Anliegen sein. Während Microsoft die Sicherheit der zugrunde liegenden Cloudinfrastruktur verwaltet, liegt es in Ihrer Verantwortung, die Sicherheit in Azure DevOps zu konfigurieren.

Obwohl dies nicht obligatorisch ist, kann die Einbindung bewährter Methoden bei der Verwendung von Azure DevOps Ihre Erfahrung verbessern und sie sicherer machen. Wir haben die folgenden bewährten Methoden zusammengestellt, die darauf abzielen, Ihre Azure DevOps-Umgebung zu schützen:

Sichere Azure DevOps-Umgebung

Entfernen von Benutzern

  • Wenn Ihr organization MSA-Konten verwendet, entfernen Sie inaktive Benutzer direkt aus dem organization, da Sie keine andere Möglichkeit haben, den Zugriff zu verhindern. In diesem Fall können Sie keine Abfrage für Arbeitselemente erstellen, die dem entfernten Benutzerkonto zugewiesen sind. Weitere Informationen finden Sie unter Löschen von Benutzern aus Azure DevOps.
  • Wenn Ihre Organisation mit der Microsoft Entra-ID verbunden ist, können Sie das Microsoft Entra-Benutzerkonto deaktivieren oder löschen und Ihr Azure DevOps-Benutzerkonto aktiv lassen. Auf diese Weise können Sie den Arbeitsaufgabenverlauf weiterhin mithilfe Ihrer Azure DevOps-Benutzer-ID abfragen.
  • Widerrufen von Benutzer-PATs.
  • Widerrufen Sie alle speziellen Berechtigungen, die möglicherweise einzelnen Benutzerkonten erteilt wurden.
  • Weisen Sie Die Arbeit von Benutzern, die Sie entfernen, den aktuellen Teammitgliedern neu zu.

Verwenden Sie Microsoft Entra ID

Integrieren Sie Azure DevOps in microsoft Entra-ID, um eine einzige Ebene für Identität zu haben. Konsistenz und eine einzige autoritative Quelle erhöhen die Übersichtlichkeit und reduzieren sicherheitsrelevante Risiken durch menschliche Fehler und komplexität der Konfiguration. Der Schlüssel zur Endgovernance besteht darin, mehrere Rollenzuweisungen zu haben (mit unterschiedlichen Rollendefinitionen und unterschiedlichen Ressourcenbereichen für dieselben Microsoft Entra-Gruppen). Ohne Microsoft Entra-ID sind Sie allein für die Steuerung des Organisationszugriffs verantwortlich.

Mit der Microsoft Entra-ID können Sie auch auf andere Sicherheitsfeatures zugreifen, z. B. mehrstufige Authentifizierung oder andere Richtlinien für bedingten Zugriff.

Weitere Informationen finden Sie in den folgenden Artikeln:

Überprüfen von Überwachungsereignissen

Sobald Sie über eine von Microsoft Entra gesicherte Organisation verfügen, können Sie die Überwachung in Ihren Sicherheitsrichtlinien aktivieren. Überprüfen Sie regelmäßig Überwachungsereignisse , um unerwartete Nutzungsmuster durch Administratoren und andere Benutzer zu überwachen und darauf zu reagieren.

Netzwerk schützen

Dazu gehören u. a. folgende Möglichkeiten:

  • Richten Sie eine Zulassungsliste ein, um bestimmte IP-Adressen einzuschränken.
  • Verwenden Sie immer die Verschlüsselung.
  • Überprüfen von Zertifikaten.
  • Implementieren Sie Web Application Firewalls (WAFs), damit sie jeden böswilligen webbasierten Datenverkehr zu und von Azure DevOps filtern, überwachen und blockieren können.
  • Weitere Informationen finden Sie in diesem Leitfaden zu bewährten Methoden für die Anwendungsverwaltung.

Bereichsbezogene Berechtigungen

Das System verwaltet Berechtigungen auf unterschiedlichen Ebenen –Einzel-, Sammlungs-, Projekt- und Objektebenen und weist sie standardmäßig einer oder mehreren integrierten Gruppen zu.

Berechtigungen auf Projektebene

  • Beschränken Sie den Zugriff auf Projekte und Repositorys, um das Risiko zu verringern, dass vertrauliche Informationen verloren gehen und unsicherer Code in der Produktion bereitgestellt wird.
  • Verwenden Sie entweder die integrierten Sicherheitsgruppen oder benutzerdefinierte Sicherheitsgruppen, um Berechtigungen zu verwalten. Weitere Informationen finden Sie unter Erteilen oder Einschränken von Berechtigungen zum Auswählen von Aufgaben.
  • Deaktivieren Sie "Öffentliche Projekte zulassen" in den Richtlinieneinstellungen Ihrer organization, um zu verhindern, dass jeder organization Benutzer ein öffentliches Projekt erstellt. mit Azure DevOps Services können Sie die Sichtbarkeit Ihrer Projekte von öffentlich in privat und umgekehrt ändern. Wenn sich Benutzer nicht bei Ihrem organization angemeldet haben, haben sie schreibgeschützten Zugriff auf Ihre öffentlichen Projekte. Wenn sich Benutzer angemeldet haben, können sie Zugriff auf private Projekte erhalten und alle zulässigen Änderungen an ihnen vornehmen.
  • Lassen Sie Benutzern nicht zu, neue Projekte zu erstellen.

Externer Gastzugriff

  • Blockieren Sie den externen Gastzugriff vollständig, indem Sie die Richtlinie "Einladungen an beliebige Domänen senden zulassen" deaktivieren. Es ist eine gute Idee, dies zu tun, wenn es keine geschäftliche Notwendigkeit dafür gibt.
  • Verwenden Sie einen anderen E-Mail- oder Benutzerprinzipalnamen (UPN) für Ihre persönlichen und geschäftlichen Konten, obwohl dies zulässig ist. Durch diese Aktion wird die Herausforderung vermieden, mehrdeutig zwischen Ihren geschäftlichen und persönlichen Konten zu unterscheiden, wenn die E-Mail/UPN identisch ist.
  • Platzieren Sie alle externen Gastbenutzer in einer einzelnen Microsoft Entra-Gruppe, und verwalten Sie die Berechtigungen dieser Gruppe entsprechend. Sie können auf diese Weise einfach verwalten und überwachen.
    • Entfernen Sie direkte Zuweisungen, damit die Gruppenregeln für diese Benutzer gelten. Weitere Informationen finden Sie unter Hinzufügen einer Gruppenregel zum Zuweisen von Zugriffsebenen.
    • Bewerten Sie Regeln regelmäßig auf der Registerkarte Gruppenregeln der Seite Benutzer neu. Klären Sie, ob Änderungen der Gruppenmitgliedschaft in Microsoft Entra ID sich auf Ihre Organisation auswirken könnten. Microsoft Entra-ID kann bis zu 24 Stunden dauern, um die dynamische Gruppenmitgliedschaft zu aktualisieren. Alle 24 Stunden und bei jeder Änderung einer Gruppenregel werden Regeln automatisch im System neu ausgewertet.
  • Weitere Informationen finden Sie unter B2B-Gäste in der Microsoft Entra-ID.

Verwalten von Sicherheitsgruppen

Sicherheit und Benutzergruppen

Sehen Sie sich die folgenden Empfehlungen zum Zuweisen von Berechtigungen für Sicherheitsgruppen und Benutzergruppen an.

Tun Tue nicht
Verwenden Sie Microsoft Entra-ID, Active Directory oder Windows-Sicherheitsgruppen, wenn Sie viele Benutzer verwalten. Ändern Sie nicht die Standardberechtigungen für die Gruppe Gültige Projektbenutzer . Diese Gruppe kann auf Projektinformationen zugreifen und diese anzeigen.
Überlegen Sie beim Hinzufügen von Teams, welche Berechtigungen Sie Teammitgliedern zuweisen möchten, die Bereichspfade, Iterationspfade und Abfragen erstellen und ändern müssen. Fügen Sie mehreren Sicherheitsgruppen, die unterschiedliche Berechtigungsstufen enthalten, keine Benutzer hinzu. In bestimmten Fällen kann die Berechtigungsstufe Verweigern die Berechtigungsstufe Zulassen außer Kraft setzen.
Wenn Sie viele Teams hinzufügen, sollten Sie erwägen, eine benutzerdefinierte Gruppe für Teamadministratoren zu erstellen, in der Sie eine Teilmenge der Berechtigungen zuweisen, die für Projektadministratoren verfügbar sind. Ändern Sie nicht die Standardzuweisungen, die für die Gruppen "Gültige Project-Benutzer " vorgenommen wurden. Wenn Sie Informationen auf instance Ebene anzeigen für eine der Gruppen Gültige Benutzer des Projekts entfernen oder auf Verweigern festlegen, können keine Benutzer in der Gruppe auf das Projekt, die Sammlung oder die Bereitstellung zugreifen, für das Sie die Berechtigung festgelegt haben.
Erwägen Sie, den Arbeitselementabfrageordnern die Berechtigung Mitwirken an Benutzer oder Gruppen zu gewähren, die die Möglichkeit benötigen, Arbeitselementabfragen für das Projekt zu erstellen und zu teilen. Weisen Sie keine Berechtigungen zu, die als Nur Dienstkonten zu Benutzerkonten zuweisen gekennzeichnet sind.
Halten Sie Gruppen so klein wie möglich. Der Zugriff sollte eingeschränkt werden, und die Gruppen sollten häufig überwacht werden.
Nutzen Sie integrierte Rollen, und verwenden Sie standardmäßig die Rolle Mitwirkender für Entwickler. Administratoren werden der Sicherheitsgruppe Projektadministrator zugewiesen, damit sie erhöhte Rechte erhalten und Sicherheitsberechtigungen konfigurieren können.

Weitere Informationen finden Sie unter "Gültige Benutzergruppen".

Just-in-Time-Zugriff für Administratorgruppen

Sie können die Konfiguration Ihrer Organisation oder Ihres Projekts ändern, wenn Sie über project Collection Administrator und Project Administrator Zugriff haben. Um den Zugriff auf diese integrierten Administratorgruppen zu schützen, benötigen Sie just-in-time-Zugriff mithilfe einer PIM-Gruppe (Microsoft Entra Privileged Identity Management).

Konfigurieren des Zugriffs

  1. Erstellen Sie eine rollenzuweisungsfähige Gruppe in der Microsoft Entra-ID.
  2. Fügen Sie Ihre Microsoft Entra-Gruppe zur Azure DevOps-Gruppe hinzu.

Hinweis

Stellen Sie sicher, dass jeder Benutzer mit erhöhtem Zugriff über eine PIM-Gruppe auch über Standardzugriff auf die Organisation verfügt, damit er die Seite anzeigen kann, um seine Berechtigungen zu aktualisieren.

Zugriff verwenden

  1. Aktivieren Sie Ihren Zugriff.
  2. Aktualisieren Sie Ihre Berechtigungen in Azure DevOps.
  3. Ergreifen Sie die Aktion, die Administratorzugriff erfordert.

Hinweis

Benutzer haben einen erhöhten Zugriff in Azure DevOps für bis zu 1 Stunde, nachdem ihr PIM-Gruppenzugriff deaktiviert wurde.

Bereichsdienstkonten

  • Stellen Sie sicher , dass Dienstkonten über keine interaktiven Anmelderechte verfügen.
  • Beschränken Sie die Dienstkontoberechtigungen auf das erforderliche Minimum.
  • Verwenden Sie eine andere Identität für das Berichtslesekonto, wenn Sie Domänenkonten für Ihre Dienstkonten verwenden. Weitere Informationen finden Sie unter Dienstkonten und Abhängigkeiten.
  • Verwenden Sie lokale Konten für Benutzerkonten, wenn Sie eine Komponente in einer Arbeitsgruppe installieren. Weitere Informationen finden Sie unter Dienstkontoanforderungen.
  • Verwenden Sie nach Möglichkeit Dienstverbindungen . Dienstverbindungen bieten einen sicheren Mechanismus zum Herstellen einer Verbindung mit verschiedenen Diensten, ohne dass Geheimnisvariablen direkt an den Build übergeben werden müssen. - Beschränken Sie diese Verbindungen auf den bestimmten Ort, an dem sie verwendet werden sollen, und nichts mehr.
  • Überwachen sie die Aktivität des Dienstkontos, und erstellen Sie Überwachungsstreaming. Mit der Überwachung können Sie verdächtige Anmeldungen und Aktivitäten erkennen und darauf reagieren.
  • Weitere Informationen finden Sie unter Allgemeine Dienstverbindungstypen.

Bereichsdienstverbindungen

  • Beschränken Sie azure Resource Manager und andere Dienstverbindungen nur auf die Ressourcen und Gruppen, auf die sie Zugriff benötigen. Dienstverbindungen sollten nicht über umfassende Mitwirkender Rechte für das gesamte Azure-Abonnement verfügen.
  • Verwenden Sie den Workload-Identitätsverbund für Ihre Azure Resource Manager (ARM)-Dienstverbindungen. Der Workload-Identitätsverbund ermöglicht Es Ihnen, geheime Dienstverbindungen in Azure-Pipelines zu Azure zu erstellen.
  • Gewähren Sie Benutzern keine generischen oder umfassenden Mitwirkender Rechte für das Azure-Abonnement.
  • Verwenden Sie keine Klassischen Azure-Dienstverbindungen, da es keine Möglichkeit gibt, die Berechtigungen einzugrenzen.
  • Stellen Sie sicher, dass die Ressourcengruppe nur Virtual Machines (VMs) oder Ressourcen enthält, auf die der Build Zugriff benötigt.
  • Verwenden Sie ein zweckspezifisches Teamdienstkonto, um eine Dienstverbindung zu authentifizieren.
  • Weitere Informationen finden Sie unter Allgemeine Dienstverbindungstypen.

Auswählen der richtigen Authentifizierungsmethode

Wählen Sie Ihre Authentifizierungsmethoden aus den folgenden Quellen aus:

Berücksichtigen von Dienstprinzipalen

Erkunden Sie Alternativen wie Dienstprinzipale und verwaltete Identitäten , mit denen Sie Microsoft Entra-Token für den Zugriff auf Azure DevOps-Ressourcen verwenden können. Solche Token sind im Vergleich zu PATs weniger riskant, wenn sie kompromittiert werden, und sie enthalten Vorteile wie die einfache Verwaltung von Anmeldeinformationen.

Sparsames Verwenden von PATs

Wenn möglich, wird empfohlen, immer Identitätsdienste für die Authentifizierung anstelle von kryptografischen Schlüsseln zu verwenden, da die sichere Verwaltung von Schlüsseln mit Anwendungscode eine Herausforderung darstellt und zu Fehlern führen kann, z. B. versehentliches Veröffentlichen vertraulicher Zugriffsschlüssel in öffentlichen Coderepositorys wie GitHub. Wenn Sie jedoch persönliche Zugriffstoken (PATs) verwenden müssen, beachten Sie die folgenden Richtlinien:

  • PATs sollten immer auf bestimmte Rollen festgelegt werden.

  • PATs sollten keinen globalen Zugriff auf mehrere Organisationen ermöglichen.

  • PATs sollten keine Schreib- oder Verwaltungsberechtigungen für Builds oder Releases erteilen.

  • PATs sollten über ein Ablaufdatum verfügen und geheim gehalten werden, da sie genauso wichtig sind wie Kennwörter.

  • PATs sollten niemals im Anwendungscode hartcodiert werden, auch wenn es versucht ist, dies zu tun, um den Code zu vereinfachen.

  • Administratoren sollten regelmäßig alle PATs mithilfe der REST-APIs überwachen und alle, die die oben genannten Kriterien nicht erfüllen, widerrufen.

  • Bewahren Sie Ihre PATs als Geheimschlüssel auf. Ihre Token sind so wichtig wie Kennwörter.

  • Speichern Sie Ihre Token an einem sicheren Ort.

  • Verwenden Sie keine hartcodierten Token in Anwendungen. Es kann verlockend sein, Code zu vereinfachen, um ein Token für einen längeren Zeitraum abzurufen und in Ihrer Anwendung zu speichern, aber tun Sie dies nicht.

  • Geben Sie Token ein Ablaufdatum.

  • Weitere Informationen finden Sie in den folgenden Artikeln:

Schützen von Azure Artifacts

Schützen von Azure Boards

Schützen von Azure Pipelines

Richtlinien

  • Erfordert mindestens einen Prüfer außerhalb des ursprünglichen Anforderers. Der genehmigende Person ist mitverantwortlich für die Änderungen und sollte für mögliche Auswirkungen gleichermaßen verantwortlich gemacht werden.
  • Erzwingen, dass der CI-Build eine Überprüfung bestehen muss: Diese Anforderung ist nützlich, um die grundlegende Codequalität durch Code linting, Komponententests und Sicherheitsüberprüfungen wie Viren- und Anmeldeinformationenüberprüfungen einzurichten.
  • Stellen Sie sicher, dass der ursprüngliche Pull Requester die Änderung nicht genehmigen kann.
  • Lassen Sie den Abschluss eines PR (Pull Request) nicht zu, auch wenn einige Prüfer abwarten oder ablehnen.
  • Zurücksetzen von Code reviewer-Stimmen, wenn aktuelle Änderungen gepusht werden.
  • Sperren Sie Releasepipelines, indem Sie sie nur in bestimmten Produktionsverzweigungen ausführen.
  • Aktivieren Sie "Settable zur Warteschlangenzeit für Variablen erzwingen" in den Pipelineeinstellungen Ihrer organization.
  • Lassen Sie "Benutzer diesen Wert beim Ausführen dieser Pipeline außer Kraft setzen" für im Editor festgelegte Variablen nicht zu.

Agents

  • Erteilen Sie berechtigungen für die kleinstmögliche Anzahl von Konten.
  • Verfügen Sie über die restriktivste Firewall, durch die Ihre Agents verwendet werden können.
  • Aktualisieren Sie Pools regelmäßig, um sicherzustellen, dass die Buildflotte keinen anfälligen Code ausführt, den ein böswilliger Akteur ausnutzen kann.
  • Verwenden Sie einen separaten Agent-Pool für Buildartefakte, die in der Produktion bereitgestellt oder bereitgestellt werden.
  • Segmentieren Sie "sensible" Pools aus nicht sensiblen Pools, und lassen Sie nur die Verwendung von Anmeldeinformationen in Builddefinitionen zu, die für diesen Pool gesperrt sind.

Definitionen

  • Verwalten von Pipelinedefinitionen mit YAML (Yet Another Markup Language). YAML ist die bevorzugte Methode zum Verwalten von Pipelinedefinitionen, da sie die Nachverfolgbarkeit für Änderungen bietet und Genehmigungsrichtlinien befolgen kann.
  • Sichern sie die Pipelinedefinition Bearbeiten Sie den Zugriff auf die Mindestanzahl von Konten.

Eingabe

  • Schließen Sie Integritätsprüfungen für Variablen in Buildskripts ein. Eine Integritätsprüfung kann einen Befehlseinschleusungsangriff durch die festlegbaren Variablen entschärfen.
  • Legen Sie so wenige Buildvariablen wie möglich auf "Settable at release time" fest.

Aufgaben

  • Vermeiden Sie remote abgerufene Ressourcen, verwenden Sie jedoch bei Bedarf die Versionsverwaltung und Hashüberprüfung.
  • Protokollieren Sie keine Geheimnisse.
  • Speichern Sie geheime Schlüssel nicht in Pipelinevariablen, verwenden Sie Azure Key Vault. Überprüfen Sie Regelmäßig Ihre Buildpipelines, um sicherzustellen, dass Geheimnisse nicht in Buildpipelinevariablen gespeichert werden.
  • Lassen Sie es Benutzern nicht zu, Builds für beliebige Branches oder Tags in sicherheitskritischen Pipelines auszuführen.
  • Deaktivieren Sie die Vererbung für die Pipeline, da geerbte Berechtigungen umfassend sind und Ihren Anforderungen an Berechtigungen nicht genau entsprechen.
  • Beschränken Sie die Auftragsautorisierungsbereiche in allen Fällen.

Repositorys und Branches

  • Legen Sie die Richtlinie "Mindestanzahl von Prüfern erforderlich" auf on fest, damit jeder Pull Request von mindestens zwei genehmigenden Personen überprüft wird.
  • Konfigurieren Sie Sicherheitsrichtlinien, die für jedes Repository oder jede Verzweigung spezifisch sind, anstatt projektweit. Sicherheitsrichtlinien reduzieren Risiken, erzwingen Change Management-Standards und verbessern die Codequalität Ihres Teams.
  • Speichern Sie geheime Produktionsgeheimnisse in einem separaten Key Vault, und stellen Sie sicher, dass nur auf Bedarfsbasis Zugriff gewährt wird, um Nichtproduktionsbuilds getrennt zu halten.
  • Mischen Sie Testumgebungen nicht mit der Produktion, einschließlich der Verwendung von Anmeldeinformationen.
  • Deaktivieren Sie das Forking. Je mehr Forks es gibt, desto schwieriger ist es, die Sicherheit jedes Forks nachzuverfolgen. Außerdem kann ein Benutzer eine Kopie eines Repositorys ganz einfach in sein eigenes privates Konto forken.
  • Stellen Sie keine Geheimnisse für Forkbuilds bereit.
  • Erwägen Sie, Forkbuilds manuell auszulösen.
  • Verwenden Sie von Microsoft gehostete Agents für Forkbuilds.
  • Überprüfen Sie für Git Ihre Produktionsbuilddefinitionen im Git-Repository des Projekts, damit sie auf Anmeldeinformationen überprüft werden können.
  • Konfigurieren Sie eine Branchsteuerungsprüfung, sodass nur Pipelines, die im Kontext des production Branchs ausgeführt werden, den prod-connectionverwenden können.
  • Weitere Informationen finden Sie unter Weitere Sicherheitsüberlegungen.

Schützen von Azure Repos

Schützen von Azure Test Plans

Sichere GitHub-Integrationen

  • Deaktivieren Sie die pat-basierte Authentifizierung (Personal Access Token), damit der OAuth-Flow mit der GitHub-Dienstverbindung verwendet wird.
  • Authentifizieren Sie GitHub-Dienstverbindungen niemals als Identität, die ein Administrator oder Besitzer von Repositorys ist.
  • Verwenden Sie niemals ein vollständiges GitHub-PAT (Personal Access Token), um GitHub-Dienstverbindungen zu authentifizieren.
  • Verwenden Sie kein persönliches GitHub-Konto als Dienstverbindung mit Azure DevOps.