Teilen über

Bewährte Sicherheitsmethoden

  • Artikel

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

Wenn Sie Informationen und Daten verarbeiten, insbesondere in einer cloudbasierten Lösung wie Azure DevOps Services, sollten Sicherheit Ihre oberste Priorität haben. Während Microsoft die Sicherheit der zugrunde liegenden Cloudinfrastruktur gewährleistet, liegt die Konfiguration der Sicherheit in Azure DevOps in Ihrer Verantwortung.

Die Einbeziehung bewährter Methoden kann zwar nicht zwingend erforderlich sein, um Ihre Erfahrung erheblich zu verbessern und die Sicherheit zu stärken. Die folgenden Empfehlungen sollen Ihnen helfen, eine sichere Azure DevOps-Umgebung aufrechtzuerhalten.

Sichern Ihrer Azure DevOps-Umgebung

Verwenden Sie die folgenden bewährten Methoden zum Entfernen von Benutzern, zum Überprüfen von Überwachungsereignissen und zur Integration mit Microsoft Entra ID.

Benutzer entfernen

  • Entfernen sie inaktive Benutzer aus MSA-Konten:
    • Wenn Ihre Organisation MSA-Konten verwendet, entfernen Sie direkt inaktive Benutzer aus der Organisation.
    • Leider gibt es keine andere Möglichkeit, den Zugriff für diese Benutzer zu verhindern.
    • Denken Sie daran, dass Sie keine Abfragen für Arbeitsaufgaben erstellen können, die entfernten MSA-Konten zugewiesen sind.
  • Deaktivieren oder Löschen von Microsoft Entra-Benutzerkonten:
    • Wenn Ihre Organisation mit der Microsoft Entra-ID verbunden ist, können Sie das Microsoft Entra-Benutzerkonto deaktivieren oder löschen, während das Azure DevOps-Benutzerkonto aktiv bleibt.
    • Mit diesem Ansatz können Sie den Arbeitsaufgabenverlauf weiterhin mithilfe Ihrer Azure DevOps-Benutzer-ID abfragen.
  • Benutzer-PATs widerrufen:
    • Überprüfen und widerrufen Sie regelmäßig vorhandene Benutzer-PATs.
    • PATs sind wichtige Authentifizierungstoken, und die sichere Verwaltung ist unerlässlich.
  • Widerrufen von speziellen Berechtigungen, die einzelnen Benutzern gewährt werden:
    • Überwachen und widerrufen Sie alle speziellen Berechtigungen, die einzelnen Benutzerkonten gewährt wurden.
    • Stellen Sie sicher, dass Berechtigungen mit dem Prinzip der geringsten Rechte übereinstimmen.
  • Erneutes Zuweisen von Arbeit von entfernten Benutzern:
    • Bevor Sie Benutzer entfernen, weisen Sie alle Arbeitsaufgaben neu zu, die sie verarbeitet haben.
    • Verteilen Sie die Arbeitsauslastung unter den aktuellen Teammitgliedern.

Verwenden Sie Microsoft Entra ID

  • Einzelne Ebene für Identität:
    • Indem Sie Azure DevOps mit Microsoft Entra ID verbinden, richten Sie ein einheitliches Identitätssystem ein.
    • Konsistenz bei allen Diensten reduziert Verwirrung und minimiert Sicherheitsrisiken aufgrund manueller Konfigurationsfehler.
  • End-to-End-Governance:
    • Durch die Nutzung der Microsoft Entra-ID können Sie präzise Governance implementieren.
    • Weisen Sie bestimmten Microsoft Entra-Gruppen unterschiedliche Rollen und Berechtigungen in verschiedenen Ressourcenbereichen zu.
    • Dieser Ansatz gewährleistet kontrollierten Zugriff und richtet sich an bewährte Methoden für die Sicherheit.
  • Sicherheitsfeatures:
    • Die Microsoft Entra-ID ermöglicht zusätzliche Sicherheitsfeatures, z. B.:
      • Mehrstufige Authentifizierung (MFA): Verbessern Sie die Benutzerauthentifizierung, indem Sie mehrere Faktoren erfordern (z. B. Kennwort- und Telefonüberprüfung).
      • Richtlinien für bedingten Zugriff: Definieren Sie Zugriffsregeln basierend auf Bedingungen (z. B. Standort, Gerät oder Risikostufe).

Weitere Informationen finden Sie in den folgenden Artikeln:

Überprüfen von Überwachungsereignissen

Sobald Ihre Organisation von Microsoft Entra unterstützt wird, führen Sie die folgenden Aufgaben aus, um die Sicherheit zu verbessern und Nutzungsmuster zu überwachen:

  • Überwachung aktivieren:
    • Aktivieren Sie in Ihren Sicherheitsrichtlinien die Überwachung.
    • Die Überwachung hilft beim Nachverfolgen und Protokollieren von Ereignissen im Zusammenhang mit Benutzeraktionen, Berechtigungen und Änderungen.
  • Regelmäßige Überprüfung von Überwachungsereignissen:
    • Überprüfen Sie das Überwachungsprotokoll regelmäßig.
    • Suchen Sie nach unerwarteten Verwendungsmustern, insbesondere von Administratoren und anderen Benutzern.

Netzwerk schützen

Die folgenden Funktionen sind effektive Möglichkeiten, um die Sicherheit Ihres Netzwerks zu verbessern, wenn Sie mit Azure DevOps arbeiten.

  • IP-Zulassungsliste:
    • Richten Sie eine Zulassungsliste ein, um den Zugriff auf bestimmte IP-Adressen einzuschränken.
    • Nur Datenverkehr aus vertrauenswürdigen Quellen zulassen, wodurch die Angriffsfläche reduziert wird.
  • Verschlüsselung:
    • Verwenden Sie immer Verschlüsselung für Daten während der Übertragung und ruhenden Daten.
    • Sichere Kommunikationskanäle mit Protokollen wie HTTPS.
  • Zertifikatüberprüfung:
    • Überprüfen Von Zertifikaten beim Herstellen von Verbindungen.
    • Stellen Sie sicher, dass Zertifikate gültig sind und von vertrauenswürdigen Behörden ausgestellt werden.
  • Webanwendungsfirewalls (WAFs):
    • Implementieren Sie WAFs, um böswilligen webbasierten Datenverkehr zu filtern, zu überwachen und zu blockieren.
    • WAFs bieten eine zusätzliche Schutzebene vor gängigen Angriffen.

Weitere Informationen finden Sie unter bewährte Methoden für die Anwendungsverwaltung.

Bereichsbezogene Berechtigungen

Das System verarbeitet Berechtigungen auf verschiedenen Ebenen – einzelnen, Auflistungen, Projekten und Objekten – und weist sie standardmäßig einer oder mehreren integrierten Gruppen zu. Führen Sie die folgenden Aktionen aus, um die Sicherheit zu verbessern:

  • Bieten Sie minimalen Zugriff: Gewähren Sie Benutzern und Diensten den minimalen erforderlichen Zugriff, um ihre Geschäftsfunktionen auszuführen.
  • Vererbung deaktivieren:
    • Deaktivieren Sie nach Möglichkeit die Vererbung.
    • Die Vererbung kann unerwarteten Benutzern versehentlich Zugriff oder Berechtigungen gewähren, da sie standardmäßig zulässig sind.
    • Weitere Informationen finden Sie im Abschnitt zur Berechtigungsvererbung

Weitere Informationen zu Berechtigungen finden Sie in den folgenden Artikeln:

Berechtigungen auf Projektebene

  • Einschränken des Zugriffs auf Projekte und Repositorys:
    • Um das Risiko zu verringern, dass vertrauliche Informationen verloren gehen und unsicheren Code in der Produktion bereitgestellt werden, beschränken Sie den Zugriff auf Projekte und Repositorys.
    • Verwenden Sie entweder die integrierten Sicherheitsgruppen oder benutzerdefinierte Sicherheitsgruppen, um Berechtigungen zu verwalten. Weitere Informationen finden Sie unter Erteilen oder Einschränken von Berechtigungen für bestimmte Aufgaben.
  • Deaktivieren Sie "Öffentliche Projekte zulassen":
    • Deaktivieren Sie in den Richtlinieneinstellungen Ihrer Organisation die Option zum Erstellen öffentlicher Projekte.
    • Mit Azure DevOps Services können Sie die Projektsichtbarkeit von öffentlich zu privat (und umgekehrt) wechseln.
    • Benutzer, die sich nicht bei Ihrer Organisation angemeldet haben, haben schreibgeschützten Zugriff auf öffentliche Projekte.
    • Angemeldete Benutzer können Zugriff auf private Projekte erhalten und zulässige Änderungen vornehmen.
  • Einschränken der Projekterstellung:
    • Verhindern, dass Benutzer neue Projekte erstellen, um die Kontrolle über Ihre Umgebung zu behalten.

Externer Gastzugriff

  • Blockieren des externen Gastzugriffs:
    • Deaktivieren Sie die Richtlinie "Zulassen, dass Einladungen an eine beliebige Domäne gesendet werden" aus, um den externen Gastzugriff zu verhindern.
    • Berücksichtigen Sie diesen Schritt, wenn es keine geschäftliche Notwendigkeit für externe Gäste gibt.
  • Verwenden Sie eine andere E-Mail oder einen anderen UPN für Ihre persönlichen und geschäftlichen Konten:
    • Obwohl dies zulässig ist, verwenden Sie unterschiedliche E-Mail-Adressen oder Benutzerprinzipalnamen (UPNs) für persönliche und geschäftliche Konten.
    • Diese Praxis beseitigt Mehrdeutigkeit, wenn sie zwischen Ihren persönlichen und geschäftlichen Konten mehrdeutig ist.
  • Externe Gastbenutzer gruppieren:
    • Platzieren Sie alle externen Gastbenutzer in einer einzelnen Microsoft Entra-Gruppe.
    • Berechtigungen für diese Gruppe entsprechend verwalten.
    • Entfernen Sie direkte Zuweisungen, um sicherzustellen, dass Gruppenregeln für diese Benutzer gelten. Weitere Informationen finden Sie unter Hinzufügen einer Gruppenregel zum Zuweisen von Zugriffsebenen.
    • Regeln werden regelmäßig auf der Registerkarte "Gruppenregeln" der Seite "Benutzer" neu ausgewertet. Berücksichtigen Sie alle Änderungen der Gruppenmitgliedschaft in der Microsoft Entra-ID, die sich möglicherweise auf Ihre Organisation auswirken. Microsoft Entra-ID kann bis zu 24 Stunden dauern, um die dynamische Gruppenmitgliedschaft zu aktualisieren. Regeln werden alle 24 Stunden automatisch neu ausgewertet und immer dann, wenn eine Gruppenregel geändert wird.

Weitere Informationen finden Sie unter B2B-Gäste in der Microsoft Entra-ID.

Verwalten von Sicherheitsgruppen

Sicherheit und Benutzergruppen

Die folgende Tabelle enthält Empfehlungen zum Zuweisen von Berechtigungen zu Sicherheitsgruppen und Benutzergruppen.

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

Wenn Sie über den Project-Sammlungsadministrator und den Projektadministratorzugriff verfügen, können Sie die Konfiguration Ihrer Organisation oder Ihres Projekts ändern. Um die Sicherheit für diese integrierten Administratorgruppen zu verbessern, sollten Sie den Just-in-Time-Zugriff mithilfe einer PIM-Gruppe (Microsoft Entra Privileged Identity Management) implementieren. Mit diesem Ansatz können Sie nur bei Bedarf erhöhte Berechtigungen erteilen und das Risiko verringern, das mit permanentem Zugriff verbunden ist.

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

Wenn Sie just-in-time-Zugriff mit einer Microsoft Entra Privileged Identity Management (PIM)-Gruppe konfigurieren, stellen Sie sicher, dass jeder Benutzer mit erhöhtem Zugriff auch den Standardzugriff auf die Organisation behält. Auf diese Weise können sie die erforderlichen Seiten anzeigen und ihre Berechtigungen bei Bedarf 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

  • Grundlegendes zu Dienstkonten
  • Erstellen von Einzelzweckdienstkonten:
    • Jeder Dienst sollte über sein dediziertes Konto verfügen, um das Risiko zu minimieren.
    • Vermeiden Sie die Verwendung regulärer Benutzerkonten als Dienstkonten.
  • Befolgen Sie Benennungs- und Dokumentationskonventionen:
    • Verwenden Sie klare, beschreibende Namen für Dienstkonten.
    • Dokumentieren Sie ihren Zweck und die zugehörigen Dienste.
  • Identifizieren und Deaktivieren nicht verwendeter Dienstkonten:
    • Regelmäßige Überprüfung und Identifizierung von Konten, die nicht mehr verwendet werden.
    • Deaktivieren Sie nicht verwendete Konten, bevor Sie das Löschen in Betracht ziehen.
  • Berechtigungen einschränken:
    • Beschränken Sie die Berechtigungen des Dienstkontos auf das erforderliche Minimum.
    • Vermeiden Sie interaktive Anmelderechte für Dienstkonten.
  • Verwenden sie separate Identitäten für Berichtsleser:
    • Wenn Sie Domänenkonten für Dienstkonten verwenden, verwenden Sie eine andere Identität für Berichtsleser.
    • Isolieren Sie Berechtigungen, um unnötigen Zugriff zu verhindern. Weitere Informationen finden Sie unter Dienstkonten und Abhängigkeiten.
  • Lokale Konten für Arbeitsgruppeninstallationen verwenden:
    • Verwenden Sie beim Installieren von Komponenten in einer Arbeitsgruppe lokale Konten für Benutzerkonten.
    • Vermeiden Sie Domänenkonten in diesem Szenario. Weitere Informationen finden Sie unter Dienstkontoanforderungen.
  • Nutzen von Dienstverbindungen:
    • Verwenden Sie nach Möglichkeit Dienstverbindungen.
    • Sie bieten eine sichere Möglichkeit, eine Verbindung mit Diensten herzustellen, ohne geheime Variablen direkt an Builds zu übergeben.
    • Einschränken von Verbindungen auf bestimmte Anwendungsfälle.
  • Überwachen der Dienstkontoaktivität:
    • Implementieren Sie Überwachungs- und Erstellungsstreams.

Weitere Informationen finden Sie unter Allgemeine Dienstverbindungstypen.

Bereichsdienstverbindungen

  • Bereich Azure Resource Manager-Dienstverbindungen :
    • Um den Zugriff einzuschränken, beschränken Sie Ihre Dienstverbindungen auf bestimmte Ressourcen und Gruppen. Vermeiden Sie die Gewährung umfassender Mitwirkenderrechte im gesamten Azure-Abonnement.
    • Verwenden Sie den Workload-Identitätsverbund für die Authentifizierung. Dies ermöglicht geheime Dienstverbindungen in Azure-Pipelines.
  • Verwenden sie den Workload-Identitätsverbund:
    • Der Workload-Identitätsverbund verwendet OpenID Connect (OIDC), um sich mit Azure-Ressourcen zu authentifizieren, ohne geheime Schlüssel zu verwenden.
    • Sie können den Workload-Identitätsverbund automatisch oder manuell erstellen. Berücksichtigen Sie diesen Ansatz, wenn:
      • Sie die Rolle „Besitzer“ für Ihr Azure-Abonnement haben.
      • Sie stellen keine Verbindung mit Azure Stack- oder Azure US Government-Umgebungen bereit.
      • Alle Marketplace-Erweiterungsaufgaben, die Sie verwenden, unterstützen workload identity federation1.
  • Bereichsdefinition für Ressourcengruppen:
    • Stellen Sie sicher, dass die Ressourcengruppe nur die virtuellen Computer (VMs) oder Ressourcen enthält, die für den Buildprozess erforderlich sind.
  • Vermeiden Sie klassische Azure-Dienstverbindungen:
    • Klassische Dienstverbindungen haben keine Bereichsdefinitionsoptionen. Entscheiden Sie sich stattdessen für moderne Azure Resource Manager-Dienstverbindungen.
  • Verwenden Sie zweckspezifische Teamdienstkonten:
    • Authentifizieren Sie Dienstverbindungen mithilfe von zweckspezifischen Teamdienstkonten, um Sicherheit und Kontrolle aufrechtzuerhalten.

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:

  • Dienstprinzipale:
    • Stellen Sie Sicherheitsobjekte in einer Microsoft Entra-Anwendung dar.
    • Definieren Sie, was eine Anwendung in einem bestimmten Mandanten tun kann.
    • Richten Sie während der Anwendungsregistrierung im Azure-Portal ein.
    • Konfiguriert für den Zugriff auf Azure-Ressourcen, einschließlich Azure DevOps.
    • Nützlich für Apps, die einen bestimmten Zugriff und eine bestimmte Steuerung benötigen.
  • Verwaltete Identitäten:
    • Ähnlich wie der Dienstprinzipal einer Anwendung.
    • Stellen Sie Identitäten für Azure-Ressourcen bereit.
    • Zulassen, dass Dienste, die die Microsoft Entra-Authentifizierung unterstützen, Anmeldeinformationen freigeben.
    • Azure verarbeitet die Verwaltung und Drehung von Anmeldeinformationen automatisch.
    • Ideal, wenn Sie eine nahtlose Verwaltung von Anmeldedetails wünschen.

Sparsames Verwenden von PATs

  • Bereichs-PATs auf bestimmte Rollen:
    • Weisen Sie PATs nur die erforderlichen Berechtigungen zu, die für bestimmte Aufgaben erforderlich sind. Vermeiden Sie die Gewährung des globalen Zugriffs auf mehrere Organisationen oder Repositorys.
    • Durch die Bereichsdefinition von PATs wird sichergestellt, dass sie über die erforderlichen Mindestberechtigungen verfügen, wodurch das Risiko eines versehentlichen Missbrauchs verringert wird.
  • Vermeiden Sie Schreib - oder Verwaltungsberechtigungen für Builds und Versionen:
    • PATs sollten keine Schreib- oder Verwaltungsberechtigungen für Builds, Versionen oder andere wichtige Ressourcen besitzen.
    • Durch das Einschränken dieser Berechtigungen können unbeabsichtigte Aktionen verhindert werden, die sich auf Ihre Pipelines oder Bereitstellungen auswirken könnten.
  • Legen Sie Ablaufdaten fest, und bewahren Sie PATs geheim:
    • Legen Sie immer ein Ablaufdatum für PATs fest. Überprüfen und erneuern Sie sie bei Bedarf regelmäßig.
    • Behandeln Sie PATs als kritisch wie Kennwörter. Bewahren Sie sie vertraulich auf, und vermeiden Sie die freigabe öffentlich oder hartcodieren sie in Ihrem Anwendungscode.
  • Vermeiden Sie hartcodierende PATs im Anwendungscode:
    • Es mag zwar praktisch erscheinen, aber vermeiden Sie, PATs direkt in Ihren Code einzubetten.
    • Verwenden Sie stattdessen sichere Konfigurationsdateien oder Umgebungsvariablen, um PATs dynamisch zu speichern und abzurufen.
  • Regelmäßiges Überwachen und Widerrufen nicht verwendeter PATs:
    • Administratoren sollten regelmäßig alle PATs mit den REST-APIs überprüfen.
    • Widerrufen Sie alle PATs, die nicht mehr benötigt werden oder die empfohlenen Kriterien nicht erfüllen.

Weitere Informationen finden Sie in den folgenden Artikeln:

Schützen von Azure Artifacts

Schützen von Azure Boards

Schützen von Azure Pipelines

Richtlinien

  • Anfordern von Bearbeitern außerhalb des ursprünglichen Antragstellers:
    • Wenn sie mindestens einen Prüfer außerhalb des ursprünglichen Antragstellers haben, wird ein gründlicherer Überprüfungsprozess sichergestellt.
    • Der Genehmigende teilt den Mitbesitz der Änderungen und sollte für mögliche Auswirkungen gleichermaßen verantwortlich sein.
  • Ci-Build muss übergeben werden:
    • Erforderlich, dass der Ci-Build (Continuous Integration) übergeben wird, bevor eine PR zusammengeführt wird, wird eine Basislinie für die Codequalität festgelegt.
    • CI-Prüfungen umfassen Code linting, Komponententests und Sicherheitsüberprüfungen (z. B. Viren- und Anmeldeinformationsprüfungen).
  • Die Selbstgenehmigung durch den ursprünglichen Antragsteller nicht zulassen:
    • Verhindern, dass der ursprüngliche PR-Antragsteller seine eigenen Änderungen genehmigt.
    • Diese Aktion stellt einen unvoreingenommenen Überprüfungsprozess sicher und vermeidet potenzielle Interessenkonflikte.
  • Pr-Fertigstellung auch mit "Wait"- oder "Reject"-Stimmen nicht zulassen:
    • Selbst wenn einige Prüfer abwarten oder ablehnen, verhindern Sie den Abschluss der PR.
    • Diese Aktion empfiehlt, vor dem Zusammenführen alle Rückmeldungen zu behandeln.
  • Zurücksetzen von Stimmen des Codeprüfers bei pushierten Änderungen:
    • Wenn die letzten Änderungen an die PR verschoben werden, setzen Sie die Überprüferstimmen zurück.
    • Diese Aktion stellt sicher, dass Prüfer den aktualisierten Code erneut auswerten.
  • Sperren von Releasepipelines an bestimmte Produktionsbranch es:
    • Beschränken Sie Freigabepipelinen auf bestimmte Filialen (in der Regel Produktion oder Haupt).
    • Vermeiden Sie versehentliche Bereitstellungen aus anderen Verzweigungen.
  • Settable-Variablen zur Warteschlangenzeit erzwingen:
    • Aktivieren Sie die Option "Settable zur Warteschlangenzeit erzwingen" für Pipelinevariablen.
    • Diese Aktion verhindert, dass Benutzer variablen Werte während der Pipelineausführung außer Kraft setzen.
  • Außerkraftsetzungen von Variablen im Editor nicht zulassen:
    • Für Variablen, die im Pipeline-Editor festgelegt sind, verbieten Sie Benutzerüberschreibungen.
    • Diese Aktion behält Konsistenz bei und verhindert unbeabsichtigte Änderungen.

Agents

  • Gewähren Sie Berechtigungen sparsam:
    • Beschränken Sie Berechtigungen auf den kleinsten erforderlichen Satz von Konten.
    • Vermeiden Sie zu wenig Zugriff, wodurch die Angriffsfläche reduziert wird.
  • Restriktive Firewalls für verwendbare Agents:
    • Konfigurieren Sie Firewalls so restriktiv wie möglich, während agents weiterhin funktionieren können.
    • Ausgleich zwischen Sicherheit und Nutzbarkeit.
  • Regelmäßiges Aktualisieren von Agentpools:
    • Halten Sie Ihre Agentenflotte auf dem neuesten Stand, indem Sie agenten regelmäßig aktualisieren.
    • Diese Aktion stellt sicher, dass anfälliger Code nicht ausgeführt wird, wodurch das Risiko der Ausbeutung verringert wird.
  • Separater Agentpool für Produktionsartefakte:
    • Verwenden Sie einen eindeutigen Agentpool für Buildartefakte, die für die Produktion bestimmt sind.
    • Das Isolieren von Produktionsartefakten trägt dazu bei, versehentliche Bereitstellungen von nicht Produktionsbranch es zu verhindern.
  • Segment vertraulicher Pools:
    • Erstellen Sie separate Pools für vertrauliche und nicht sensible Workloads.
    • Zulassen von Anmeldeinformationen in Builddefinitionen, die dem entsprechenden Pool zugeordnet sind.

Definitionen

  • Verwenden von YAML für Pipelinedefinitionen:
    • YAML (Yet Another Markup Language) ist der empfohlene Ansatz zum Definieren von Pipelines.
    • Es bietet Rückverfolgbarkeit für Änderungen und erleichtert das Nachverfolgen von Änderungen im Laufe der Zeit.
    • Darüber hinaus können YAML-Pipelines den Genehmigungsrichtlinien und Versionskontrollpraktiken entsprechen.
  • Einschränken des Bearbeitungszugriffs auf Pipelinedefinitionen:
    • Beschränken Sie den Zugriff auf die Bearbeitung von Pipelinedefinitionen auf die erforderlichen Mindestkonten.
    • Dadurch verringern Sie das Risiko von versehentlichen oder nicht autorisierten Änderungen.

Eingabe

  • Überprüfungen der Sanity auf Variablen in Buildskripts einschließen:
    • Implementieren Sie Sanity-Prüfungen in Ihren Buildskripts, um potenzielle Befehleinjektionsangriffe durch settable-Variablen zu mindern.
    • Diese Prüfungen können Eingabewerte überprüfen und unbeabsichtigte oder böswillige Befehle verhindern.
  • Beschränken Sie die Anzahl der buildvariablen Buildvariablen zur Veröffentlichungszeit:
    • Legen Sie so wenige Buildvariablen wie möglich so fest, dass sie zur Veröffentlichungszeit festgelegt werden können.
    • Die Minimierung der Anzahl solcher Variablen reduziert die Angriffsfläche und vereinfacht die Konfigurationsverwaltung.

Aufgaben

  • Remote abgerufene Ressourcen vermeiden:
    • Vermeiden Sie nach Möglichkeit das Abrufen von Ressourcen aus externen URLs während des Buildprozesses.
    • Wenn Remoteressourcen erforderlich sind, verwenden Sie versionsverwaltung und Hashüberprüfung, um die Integrität zu gewährleisten.
  • Vermeiden Sie die Protokollierung geheimer Schlüssel:
    • Protokollieren Sie niemals vertrauliche Informationen, z. B. geheime Schlüssel oder Anmeldeinformationen, in Ihren Buildprotokollen.
    • Die Protokollierung geheimer Schlüssel kann sie unbeabsichtigt verfügbar machen und die Sicherheit gefährden.
  • Verwenden Sie Azure Key Vault für geheime Schlüssel:
    • Statt geheime Schlüssel direkt in Pipelinevariablen zu speichern, verwenden Sie Azure Key Vault.
    • Key Vault bietet eine sichere Möglichkeit, geheime Schlüssel zentral zu verwalten und abzurufen.
  • Einschränken der Ausführung von Builds auf beliebige Verzweigungen oder Tags:
    • Beschränken Sie für sicherheitskritische Pipelines die Ausführung von Builds für alle Verzweigungen oder Tags.
    • Definieren Sie bestimmte autorisierte Verzweigungen oder Tags, um versehentliche oder nicht autorisierte Ausführungen zu verhindern.
  • Vererbung für Pipelineberechtigungen deaktivieren:
    • Geerbte Berechtigungen können übermäßig breit sein und entsprechen möglicherweise nicht genau Ihren Anforderungen.
    • Deaktivieren Sie die Vererbung, und legen Sie Berechtigungen explizit fest, um die Sicherheitsanforderungen anzupassen.
  • Einschränken von Auftragsautorisierungsbereichen:
    • Beschränken Sie die Auftragsautorisierungsbereiche immer auf das erforderliche Minimum.
    • Optimieren Sie Berechtigungen basierend auf den spezifischen Aufgaben, die von jedem Auftrag ausgeführt werden.

Repositorys und Branches

  • Mindestanzahl von Prüfern erforderlich:
    • Aktivieren Sie die Richtlinie "Mindestens eine Anzahl von Prüfern erforderlich", um sicherzustellen, dass jede Pullanforderung Rezensionen von mindestens zwei Genehmigenden empfängt.
    • Dies fördert eine gründliche Codeüberprüfung und Rechenschaftspflicht.
  • Repositoryspezifische Sicherheitsrichtlinien konfigurieren:
    • Anstatt projektweite Richtlinien, passen Sie Sicherheitsrichtlinien auf jedes Repository oder jede Verzweigung an.
    • Angepasste Richtlinien reduzieren Risiken, Erzwingen von Change Management-Standards und Verbessern der Codequalität.
  • Isolieren sie geheime Produktionsschlüssel in einem separaten Schlüsseltresor:
    • Speichern Sie geheime Produktionsgeheimnisse separat in einem Azure Key Vault.
    • Beschränken Sie den Zugriff auf eine bedarfsorientierte Basis, um die Trennung von Nicht-Produktionsbuilds aufrechtzuerhalten.
  • Trennen Sie Testumgebungen von der Produktion:
    • Vermeiden Sie das Mischen von Testumgebungen mit der Produktion.
    • Stellen Sie sicher, dass Anmeldeinformationen und geheime Schlüssel nicht in Produktionskontexten verwendet werden.
  • Freihandeingabe deaktivieren:
    • Durch das Deaktivieren der Freihandeingabe können Sie die Sicherheit verwalten.
    • Forks können sich vermehren, was es schwierig macht, die Sicherheit für alle Kopien nachzuverfolgen.
  • Vermeiden Sie die Bereitstellung geheimer Schlüssel für Freihandbuilds:
    • Verzichten Sie darauf, geheime Schlüssel mit Verzweigungsbuilds zu teilen.
    • Geheime Schlüssel sollten vertraulich bleiben und nicht für Forks verfügbar gemacht werden.
  • Erwägen Sie das manuelle Auslösen von Freihandbuilds:
    • Lösen Sie Builds für Forks manuell aus, anstatt automatische Trigger zuzulassen.
    • Dies bietet eine bessere Kontrolle über Sicherheitskontrollen.
  • Verwenden Sie von Microsoft gehostete Agents für Freihandbuilds:
    • Nutzen Sie von Microsoft gehostete Agents für Verzweigungsbuilds.
    • Diese Agents werden gepflegt und sicher.
  • Scannen von Produktionsbuilddefinitionen in Git-Repositorys:
    • Überprüfen Sie regelmäßig Produktionsbuilddefinitionen, die im Git-Repository Ihres Projekts gespeichert sind.
    • Suchen Sie nach Anmeldeinformationen oder vertraulichen Informationen.
  • Konfigurieren von Branch control checks for production context:
    • Richten Sie Verzweigungskontrollen ein, um die Verwendung vertraulicher Verbindungen (z. B. prod-connection) auf Pipelines einzuschränken, die im Kontext der Produktionsbranch ausgeführt werden.
    • Dies gewährleistet eine ordnungsgemäße Autorisierung und verhindert versehentlichen Missbrauch.

Weitere Informationen finden Sie unter Weitere Sicherheitsüberlegungen.

Schützen von Azure Repos

Schützen von Azure Test Plans

Sichere GitHub-Integrationen

  • Verwenden Sie den OAuth-Fluss anstelle von PATs:
    • Deaktivieren Sie die PAT-basierte Authentifizierung für GitHub-Dienstverbindungen.
    • Entscheiden Sie sich für den OAuth-Fluss, der eine bessere Sicherheit und Integration bietet.
  • Vermeiden Sie Administrator- oder Besitzeridentitäten:
    • Authentifizieren Sie niemals GitHub-Dienstverbindungen mithilfe einer Identität, die ein Administrator oder Besitzer von Repositorys ist.
    • Beschränken Sie Berechtigungen auf die erforderliche Ebene.
  • Vermeiden Sie GitHub-PATs mit vollem Umfang:
    • Vermeiden Sie die Verwendung eines GitHub-PAT mit vollem Umfang, um Dienstverbindungen zu authentifizieren.
    • Verwenden Sie Token mit den minimal erforderlichen Berechtigungen.
  • Vermeiden Sie persönliche GitHub-Konten als Dienstverbindungen:
    • Verwenden Sie keine persönlichen GitHub-Konten als Dienstverbindungen in Azure DevOps.
    • Erstellen Sie stattdessen dedizierte Dienstkonten, oder verwenden Sie Konten auf Organisationsebene.