Freigeben ü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 Microsoft-Konten (MSAs):Entfernen Sie bei Verwendung von MSAs direkt inaktive Benutzer aus Ihrer Organisation . Sie können keine Abfragen für Arbeitsaufgaben erstellen, die entfernten MSA-Konten zugewiesen sind.
  • Deaktivieren oder löschen Sie Microsoft Entra-Benutzerkonten: Wenn eine Verbindung mit microsoft Entra-ID besteht, deaktivieren oder löschen Sie das Microsoft Entra-Benutzerkonto, während das Azure DevOps-Benutzerkonto aktiv bleibt. Mit dieser Aktion können Sie den Arbeitsaufgabenverlauf weiterhin mithilfe Ihrer Azure DevOps-Benutzer-ID abfragen.
  • Widerrufen von Benutzer-PATs: Überprüfen und widerrufen Sie regelmäßig vorhandene Benutzer-PATs, um die sichere Verwaltung dieser kritischen Authentifizierungstoken sicherzustellen.
  • Widerrufen sie spezielle Berechtigungen, die einzelnen Benutzern gewährt werden: Überwachen und widerrufen Sie alle speziellen Berechtigungen, die einzelnen Benutzern gewährt werden, um die Ausrichtung mit dem Prinzip der geringsten Berechtigungen sicherzustellen.
  • Erneutes Zuweisen von Arbeit von entfernten Benutzern: Bevor Sie Benutzer entfernen, weisen Sie ihre Arbeitsaufgaben den aktuellen Teammitgliedern neu zu, um die Last effektiv zu verteilen.

Verwenden Sie Microsoft Entra ID

  • Einrichten eines einheitlichen Identitätssystems: Verbinden Sie Azure DevOps mit Microsoft Entra ID, um eine einzelne Ebene für Identität zu erstellen. Diese Konsistenz reduziert Verwirrung und minimiert Sicherheitsrisiken durch manuelle Konfigurationsfehler.
  • Implementieren Sie eine differenzierte Governance: Verwenden Sie Die Microsoft Entra-ID, um bestimmten Gruppen in verschiedenen Ressourcenbereichen unterschiedliche Rollen und Berechtigungen zuzuweisen. Diese Aktion stellt den kontrollierten Zugriff sicher und richtet sich an bewährte Methoden für die Sicherheit.
  • Verbessern Sie Sicherheitsfeatures: Aktivieren Sie andere Sicherheitsfeatures mit der Microsoft Entra-ID, z. B.:
    • Mehrstufige Authentifizierung (Multifactor Authentication, MFA): Erfordern Sie mehrere Faktoren wie Kennwort- und Telefonüberprüfung für die Benutzerauthentifizierung. Richtlinien für bedingten Zugriff: Definieren Sie Zugriffsregeln basierend auf Bedingungen wie Standort, Gerät oder Risikostufe.

Weitere Informationen finden Sie in den folgenden Artikeln:

Überprüfen von Überwachungsereignissen

Wenn Ihre Organisation mit Microsoft Entra verbunden ist, führen Sie die folgenden Aufgaben aus, um die Sicherheit zu verbessern und Nutzungsmuster zu überwachen:

  • Überwachung aktivieren: Nachverfolgen und Anzeigen von Ereignissen im Zusammenhang mit Benutzeraktionen, Berechtigungen und Änderungen.
  • Überprüfen Sie Überwachungsereignisse 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.

  • Einrichten der IP-Zulassungsliste: Einschränken des Zugriffs auf bestimmte IP-Adressen, um datenverkehr nur aus vertrauenswürdigen Quellen zuzulassen, wodurch die Angriffsfläche reduziert wird.
  • Verschlüsselung verwenden: Daten während der Übertragung und ruhenden Daten immer verschlüsseln. Sichere Kommunikationskanäle mit Protokollen wie HTTPS.
  • Überprüfen von Zertifikaten: Stellen Sie sicher, dass Zertifikate gültig sind und von vertrauenswürdigen Behörden ausgestellt werden, wenn Verbindungen eingerichtet werden.
  • Implementieren Sie Webanwendungsfirewalls (WAFs): Filtern, überwachen und blockieren Sie bösartigen webbasierten Datenverkehr mit WAFs, um eine zusätzliche Schutzebene vor allgemeinen Angriffen zu gewährleisten.

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

Bereichsberechtigungen

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 den geringsten Berechtigungszugriff: 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

  • Beschränken Sie den Zugriff auf Projekte und Repositorys: Verringern Sie das Risiko, dass vertrauliche Informationen verloren gehen, und stellen Sie unsicheren Code bereit, indem Sie den Zugriff auf Projekte und Repositorys beschränken. Verwenden Sie integrierte oder benutzerdefinierte Sicherheitsgruppen, um Berechtigungen zu verwalten.
  • Deaktivieren Sie "Öffentliche Projekte zulassen": Deaktivieren Sie in den Richtlinieneinstellungen Ihrer Organisation die Option zum Erstellen öffentlicher Projekte. Wechseln Sie bei Bedarf von der sichtbarkeit des Projekts von öffentlich zu privat. Benutzer, die sich nicht angemeldet haben, haben schreibgeschützten Zugriff auf öffentliche Projekte, während angemeldete Benutzer Zugriff auf private Projekte erhalten und zulässige Änderungen vornehmen können.
  • 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, wenn keine geschäftliche Notwendigkeit besteht.
  • Verwenden Sie unterschiedliche E-Mails oder UPNs: Verwenden Sie unterschiedliche E-Mail-Adressen oder Benutzerprinzipalnamen (UPNs) für persönliche und geschäftliche Konten, um Mehrdeutigkeit zwischen persönlichen und geschäftlichen Konten zu vermeiden.
  • Externe Gastbenutzer gruppieren: Platzieren Sie alle externen Gastbenutzer in einer einzelnen Microsoft Entra-Gruppe, und verwalten Sie die Berechtigungen für diese Gruppe entsprechend. Entfernen Sie direkte Zuweisungen, um sicherzustellen, dass Gruppenregeln für diese Benutzer gelten.
  • Regeln regelmäßig neu bewerten: Regeln auf der Registerkarte "Gruppenregeln" der Seite "Benutzer" regelmäßig überprüfen. 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, und Regeln werden alle 24 Stunden automatisch neu ausgewertet, und wenn sich eine Gruppenregel ändert.

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. Weitere Informationen finden Sie unter "Gültige Benutzergruppen".
Ü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 eine Berechtigungsstufe "Verweigern " eine Berechtigungsstufe "Zulassen " außer Kraft setzen. Angenommen, Sie haben zwei Sicherheitsgruppen in Ihrem Azure DevOps-Projekt: Entwickler und Tester. Die Gruppe "Entwickler" verfügt über die Berechtigung zum Bearbeiten von Arbeitsaufgaben, die auf " Zulassen" festgelegt sind. Stellen Sie jedoch sicher, dass bestimmte vertrauliche Arbeitsaufgaben von niemandem bearbeitet werden, außer einigen wichtigen Personen. Erstellen Sie dazu eine neue Sicherheitsgruppe namens "Editoren vertraulicher Elemente", und legen Sie die Berechtigung zum Bearbeiten von Arbeitsaufgaben auf "Verweigern" für diese Gruppe fest. Wenn ein Benutzer Mitglied der Gruppe "Entwickler " und der Gruppe "Editoren für vertrauliche Elemente" ist, hat die Berechtigung "Verweigern " aus der Gruppe "Editoren für vertrauliche Elemente" Vorrang vor der Berechtigung "Zulassen " aus der Gruppe "Entwickler" . Daher kann dieser Benutzer die vertraulichen Arbeitsaufgaben nicht bearbeiten, obwohl er über die Berechtigung "Zulassen " in der Gruppe "Entwickler" verfügt. Mit diesem Verhalten wird sichergestellt, dass Die Berechtigungsverweigerung streng erzwungen wird und eine höhere Sicherheitsstufe und Kontrolle über vertrauliche Aktionen in Ihrer Azure DevOps-Umgebung bietet.
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 nur Dienstkonten zu Benutzerkonten zugewiesen werden.
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.

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

  • Erstellen sie Einzelzweck-Dienstkonten: 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 und dokumentieren Sie deren Zweck und zugehörige Dienste.
  • Identifizieren und Deaktivieren nicht verwendeter Dienstkonten: Überprüfen und Identifizieren 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, um Berechtigungen zu isolieren und unnötigen Zugriff zu verhindern.
  • Verwenden Sie lokale Konten für Arbeitsgruppeninstallationen: Verwenden Sie beim Installieren von Komponenten in einer Arbeitsgruppe lokale Konten für Benutzerkonten. Vermeiden Sie Domänenkonten in diesem Szenario.
  • Nutzen Sie Dienstverbindungen: Verwenden Sie Dienstverbindungen, wenn möglich, um sicher 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 Erstellungsdatenströme, um die Aktivität des Dienstkontos zu überwachen.

Weitere Informationen finden Sie unter Allgemeine Dienstverbindungstypen.

Bereichsdienstverbindungen

  • Bereichs-Dienstverbindungen: Beschränken Sie den Zugriff, indem Sie Ihre Azure Resource Manager-Dienstverbindungen auf bestimmte Ressourcen und Gruppen beschränken. Vermeiden Sie die Gewährung umfassender Mitwirkenderrechte im gesamten Azure-Abonnement.
  • Verwenden Sie den Workloadidentitätsverbund: Authentifizieren sie sich mit Azure-Ressourcen mithilfe von OpenID Connect (OIDC) ohne geheime Schlüssel. Erstellen Sie einen Workloadidentitätsverbund automatisch oder manuell, wenn Sie über die Rolle "Besitzer" für Ihr Azure-Abonnement verfügen, keine Verbindung mit Azure Stack- oder Azure US Government-Umgebungen herstellen, und alle Marketplace-Erweiterungen, die Sie verwenden, unterstützen sie.
  • Bereichsressourcengruppen: Stellen Sie sicher, dass Ressourcengruppen nur die virtuellen Computer (VMs) oder Ressourcen enthalten, die für den Buildprozess erforderlich sind.
  • Vermeiden Sie klassische Dienstverbindungen: Entscheiden Sie sich für moderne Azure Resource Manager-Dienstverbindungen anstelle des klassischen Diensts, der keine Bereichsoptionen enthält.
  • Verwenden Sie zweckspezifische Teamdienstkonten: Authentifizieren Sie Dienstverbindungen mithilfe zweckspezifischer Teamdienstkonten, um Sicherheit und Kontrolle zu gewährleisten.

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:

  • Verwenden Sie 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. Konfigurieren sie 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.
  • Verwenden Sie verwaltete Identitäten: Ähnlich dem 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 für die nahtlose Verwaltung von Anmeldedetails.

Sparsames Verwenden von PATs

  • Festlegen von PATs auf bestimmte Rollen: Weisen Sie PATs nur die erforderlichen Berechtigungen für bestimmte Aufgaben zu. Vermeiden Sie die Gewährung des globalen Zugriffs auf mehrere Organisationen oder Repositorys, um das Risiko eines versehentlichen Missbrauchs zu minimieren.
  • 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 öffentliche Freigaben oder Hardcoding im Anwendungscode.
  • Vermeiden Sie hartcodierende PATs im Anwendungscode: Anstatt PATs direkt in Ihren Code einzubetten, verwenden Sie sichere Konfigurationsdateien oder Umgebungsvariablen, um PATs dynamisch zu speichern und abzurufen. dynamisch.
  • Regelmäßiges Überwachen und Widerrufen nicht verwendeter PATs: Administratoren sollten regelmäßig alle PATs mithilfe der 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 unter Verwalten von PATs mit Richtlinien – für Administratoren und die Verwendung von PATs.

Schützen von Azure Artifacts

Schützen von Azure Boards

Schützen von Azure Pipelines

Richtlinien

  • Externe Prüfer anfordern: Stellen Sie mindestens einen Prüfer außerhalb des ursprünglichen Prüfers für einen gründlichen Überprüfungsprozess sicher. Der Genehmiger teilt den Mitbesitz der Änderungen und Rechenschaftspflicht für mögliche Auswirkungen.
  • Ci-Build muss übergeben werden: Richten Sie einen Basisplan für die Codequalität ein, indem Sie den Ci-Build (Continuous Integration) vor dem Zusammenführen einer PR übergeben müssen. CI-Prüfungen umfassen Codelinting, Komponententests und Sicherheitsüberprüfungen.
  • Selbstgenehmigung nicht zulassen: Verhindern Sie, dass der ursprüngliche PR-Antragsteller ihre eigenen Änderungen genehmigt, um einen unvoreingenommenen Überprüfungsprozess sicherzustellen und Interessenkonflikte zu vermeiden.
  • Pr-Fertigstellung mit "Warte"- oder "Ablehnen"-Abstimmungen nicht zulassen: Verhindern Sie den Abschluss der PR, auch wenn einige Prüfer stimmen, um zu warten oder abzulehnen, und ermutigen Sie, vor dem Zusammenführen alle Rückmeldungen anzugehen.
  • Zurücksetzen von Bearbeiterstimmen zu Änderungen: Zurücksetzen von Bearbeiterstimmen, wenn aktuelle Änderungen an die PR verschoben werden, um sicherzustellen, dass Prüfer den aktualisierten Code neu bewerten.
  • Sperren Von Releasepipelines: Beschränken Sie Freigabepipelines auf bestimmte Verzweigungen (in der Regel Produktion oder Haupt), um versehentliche Bereitstellungen von anderen Zweigstellen zu vermeiden.
  • Erzwingen von feststellbaren Variablen zur Warteschlangenzeit: Aktivieren Sie die Option "Settable zur Warteschlangenzeit erzwingen" für Pipelinevariablen, um zu verhindern, dass Benutzer variable Werte während der Pipelineausführung überschreiben.
  • Außerkraftsetzungen von Variablen im Editor nicht zulassen: Für Variablen, die im Pipeline-Editor festgelegt sind, verbieten Sie Benutzerüberschreibungen, um Konsistenz beizubehalten und unbeabsichtigte Änderungen zu verhindern.

Agents

  • Gewähren Sie Berechtigungen sparsam: Beschränken Sie Berechtigungen auf den kleinsten erforderlichen Satz von Konten, um die Angriffsfläche zu reduzieren.
  • Konfigurieren Sie restriktive Firewalls für Agents: Richten Sie Firewalls so restriktiv wie möglich ein, und ermöglichen Sie dennoch, dass Agents funktionieren, sicherheit und Nutzbarkeit ausgleichen können.
  • Aktualisieren Sie regelmäßig Agentpools: Halten Sie Ihre Agentflotte auf dem neuesten Stand, indem Sie regelmäßig Agents aktualisieren, um sicherzustellen, dass anfälliger Code nicht ausgeführt wird, wodurch das Risiko der Ausbeutung verringert wird.
  • Verwenden Sie einen separaten Agentpool für Produktionsartefakte: Isolieren Sie Produktionsartefakte mithilfe eines unterschiedlichen Agentpools, um 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 Sie YAML für Pipelinedefinitionen: Definieren von Pipelines mithilfe von YAML (Yet Another Markup Language) zur besseren Rückverfolgbarkeit und Einhaltung von Genehmigungsrichtlinien und Versionskontrollpraktiken.
  • Einschränken des Bearbeitungszugriffs auf Pipelinedefinitionen: Beschränken Sie den Zugriff auf Bearbeitungspipelinedefinitionen auf die minimal erforderlichen Konten, um das Risiko von versehentlichen oder nicht autorisierten Änderungen zu verringern.

Eingabe

  • Schließen Sie Überprüfungen auf Variablen in Buildskripts ein: Implementieren Sie Prüfungen in Ihren Buildskripts, um potenzielle Befehleinjektionsangriffe durch settable-Variablen zu mindern. Überprüfen Sie Eingabewerte, und verhindern Sie unbeabsichtigte oder böswillige Befehle.
  • Beschränken Sie buildvariable Buildvariablen zur Veröffentlichungszeit: Minimieren Sie die Anzahl der zur Veröffentlichung festgelegten Buildvariablen, um die Angriffsfläche zu reduzieren und die Konfigurationsverwaltung zu vereinfachen.

Aufgaben

  • Vermeiden Sie remote abgerufene Ressourcen: 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, um unbeabsichtigte Gefährdungen und Sicherheitskompromittierungen zu verhindern.
  • Verwenden Sie Azure Key Vault für geheime Schlüssel: Statt geheime Schlüssel direkt in Pipelinevariablen zu speichern, verwenden Sie Azure Key Vault, um geheime Schlüssel sicher zu verwalten und abzurufen.
  • Beschränken Sie die 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 auftragsautorisierungsbereiche immer auf das erforderliche Minimum. Optimieren Sie Berechtigungen basierend auf den spezifischen Aufgaben, die von jedem Auftrag ausgeführt werden.

Repositorys und Branches

  • Erfordert eine Mindestanzahl von Prüfern: Aktivieren Sie die Richtlinie, um sicherzustellen, dass jede Pullanforderung Rezensionen von mindestens zwei Genehmigenden empfängt, um eine gründliche Codeüberprüfung und Rechenschaftspflicht zu fördern.
  • Konfigurieren Sie repositoryspezifische Sicherheitsrichtlinien: Passen Sie Sicherheitsrichtlinien auf jedes Repository oder jede Verzweigung an, anstatt projektweite Richtlinien, um Risiken zu reduzieren, Änderungsverwaltungsstandards zu erzwingen und die Codequalität zu verbessern.
  • Isolieren Sie geheime Produktionsgeheimnisse in einem separaten Schlüsseltresor: Speichern Sie geheime Produktionsgeheimnisse separat in einem Azure Key Vault, und beschränken Sie den Zugriff auf eine bedarfsorientierte Basis, um die Trennung von Nichtproduktionsbuilds aufrechtzuerhalten.
  • Trennen Sie Testumgebungen von der Produktion: Vermeiden Sie das Mischen von Testumgebungen mit der Produktion, um sicherzustellen, dass Anmeldeinformationen und geheime Schlüssel nicht in Nichtproduktionskontexten verwendet werden.
  • Deaktivieren der Freihandeingabe: Durch das Deaktivieren der Freihandeingabe können Sie die Sicherheit verwalten, indem die Verbreitung von Forks verhindert wird, wodurch die Sicherheit für alle Kopien einfacher nachverfolgt werden kann.
  • Vermeiden Sie die Bereitstellung von Geheimschlüsseln für Verzweigungsbuilds: Teilen Sie geheime Schlüssel nicht mit verzweigten Builds, um sie vertraulich zu halten und nicht forks verfügbar zu machen.
  • Erwägen Sie das manuelle Auslösen von Freihandbuilds: Manuelles Auslösen von Builds für Forks, anstatt automatische Auslöser zuzulassen, um eine bessere Kontrolle über Sicherheitskontrollen zu bieten.
  • Verwenden Sie von Microsoft gehostete Agents für Freihandbuilds: Verwenden Sie von Microsoft gehostete Agents für verzweigte Builds, während sie verwaltet und sicher sind.
  • Scannen Sie Produktionsbuilddefinitionen in Git-Repositorys: Überprüfen Sie regelmäßig Produktionsbuilddefinitionen, die im Git-Repository Ihres Projekts gespeichert sind, auf Anmeldeinformationen oder vertrauliche Informationen.
  • Konfigurieren von Branch control checks for production context: Set up branch control checks to restrict the use of sensitive connections (for example, prod-connection) to pipelines running in the context of the Produktionsbranch, ensuring proper authorization and preventing 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, und entscheiden Sie sich für den OAuth-Fluss für eine bessere Sicherheit und Integration.
  • 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.