Weitere Sicherheitsaspekte für Azure-Pipelines

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

Bei der Sicherung von Azure-Pipelines gibt es mehrere weitere Überlegungen, die Sie berücksichtigen sollten, z. B. den Schutz der gemeinsamen Infrastruktur, Repositorys, Projekte und vieles mehr.

Schützen der freigegebenen Infrastruktur

Geschützte Ressourcen in Azure Pipelines sind eine Abstraktion der realen Infrastruktur. Befolgen Sie diese Empfehlungen, um die zugrunde liegende Infrastruktur zu schützen.

Verwenden Sie von Microsoft gehostete Pools

Von Microsoft gehostete Pools bieten Isolation und einen sauber virtuellen Computer für jede Ausführung einer Pipeline. Verwenden Sie nach Möglichkeit von Microsoft gehostete Pools anstelle von selbstgehosteten Pools.

Separate Agents für jedes Projekt

Ein Agent kann nur einem einzelnen Pool zugeordnet werden. Sie können Agents über Projekte hinweg freigeben, indem Sie den Pool mehreren Projekten zuordnen. In der Praxis können mehrere Projekte denselben Agent aufeinanderfolgende verwenden. Auch wenn dieser Ansatz kosteneffizient ist, kann dieser Ansatz Lateral Movement-Risiken mit sich bringen.

Um laterale Bewegungen zu vermeiden und Kreuzkontaminationen zwischen Projekten zu verhindern, verwalten Sie separate Agentpools, die jeweils einem bestimmten Projekt zugeordnet sind.

Verwenden von Konten mit geringen Berechtigungen zum Ausführen von Agents

Möglicherweise sind Sie versucht, den Agent unter einer Identität mit direktem Zugriff auf Azure DevOps-Ressourcen auszuführen, kann riskant sein. Diese Einrichtung ist in Organisationen, die Microsoft Entra ID verwenden, weit verbreitet, birgt jedoch Risiken. Wenn Sie den Agent unter einer identitätssichern Microsoft Entra-ID ausführen, kann er direkt auf Azure DevOps-APIs zugreifen, ohne sich auf das Zugriffstoken des Auftrags zu verlassen. Um eine bessere Sicherheit zu gewährleisten, sollten Sie den Agent mit einem nicht privilegierten lokalen Konto ausführen, z. B. Netzwerkdienst.

Wichtig

In Azure DevOps gibt es eine Gruppe namens Project Collection Service Accounts, die irreführend sein können. Durch vererbung werden Mitglieder von Project Collection Service Accounts auch als Mitglieder von Project-Sammlungsadministratoren betrachtet. Einige Kunden führen ihre Build-Agents mit einer identitätssichern Microsoft Entra-ID aus, und diese Identitäten sind möglicherweise Teil von Project Collection Service Accounts. Wenn Angreifer jedoch eine Pipeline auf einem dieser Build-Agents ausführen, könnten sie möglicherweise die Kontrolle über die gesamte Azure DevOps-Organisation erlangen.

Es gibt Fälle, in denen selbst gehostete Agents unter streng privilegierten Konten arbeiten. Diese Agents verwenden diese privilegierten Konten häufig für den Zugriff auf geheime Schlüssel oder Produktionsumgebungen. Aber wenn Angreifer eine kompromittierte Pipeline auf einem dieser Build-Agents ausführen, erhalten sie Zugriff auf diese Geheimnisse. Dann können sich die Gegner lateral durch andere Systeme bewegen, die über diese Konten zugänglich sind.

Um die Systemsicherheit zu verbessern, empfehlen wir die Verwendung des Kontos mit den niedrigsten Rechten für die Ausführung von selbst gehosteten Agents. Sie könnten beispielsweise Ihr Computerkonto oder eine verwaltete Dienstidentität verwenden. Vertrauen Sie Azure Pipelines außerdem mit der Verwaltung des Zugriffs auf Geheime und Umgebungen an.

Minimieren des Umfangs von Dienstverbindungen

Stellen Sie sicher, dass Dienstverbindungen nur zugriff auf die erforderlichen Ressourcen haben. Ziehen Sie nach Möglichkeit die Verwendung des Workload-Identitätsverbunds anstelle eines Dienstprinzipals für Ihre Azure-Dienstverbindung in Betracht. Der Workload-Identitätsverbund verwendet Open ID Connect (OIDC), eine Branchenstandardtechnologie, um die Authentifizierung zwischen Azure und Azure DevOps zu erleichtern, ohne sich auf geheime Schlüssel zu verlassen.

Stellen Sie sicher, dass Ihre Azure-Dienstverbindung nur auf die erforderlichen Ressourcen zugreifen kann. Vermeiden Sie die Gewährung umfassender Mitwirkenderrechte für das gesamte Azure-Abonnement für Benutzer.

Wenn Sie eine neue Azure Resource Manager-Dienstverbindung erstellen, wählen Sie immer eine bestimmte Ressourcengruppe aus. Stellen Sie sicher, dass die Ressourcengruppe nur die erforderlichen virtuellen Computer oder Ressourcen enthält, die für den Build erforderlich sind. Ebenso gewähren Sie beim Konfigurieren der GitHub-App nur Zugriff auf die Repositorys, die Sie mit Azure-Pipelines erstellen möchten.

Schützen von Projekten

Über einzelne Ressourcen hinaus ist es von entscheidender Bedeutung, Ressourcengruppen in Azure DevOps zu berücksichtigen. Ressourcen werden nach Teamprojekten organisiert und verstehen, worauf Ihre Pipeline basierend auf Projekteinstellungen und Eindämmung zugreifen kann, ist unerlässlich.

Jeder Auftrag in Ihrer Pipeline empfängt ein Zugriffstoken mit Berechtigungen zum Lesen geöffneter Ressourcen. In einigen Fällen können Pipelines diese Ressourcen auch aktualisieren. Dies bedeutet, dass Ihr Benutzerkonto möglicherweise keinen direkten Zugriff auf eine bestimmte Ressource, Skripts und Aufgaben hat, die in Ihrer Pipeline ausgeführt werden, dennoch darauf zugreifen können. Darüber hinaus ermöglicht das Sicherheitsmodell von Azure DevOps den Zugriff auf diese Ressourcen aus anderen Projekten innerhalb der Organisation. Wenn Sie den Pipelinezugriff auf bestimmte Ressourcen einschränken möchten, gilt diese Entscheidung für alle Pipelines innerhalb eines Projekts– bestimmte Pipelines können nicht selektiv Zugriff auf offene Ressourcen erhalten.

Separate Projekte

Angesichts der Art der offenen Ressourcen sollten Sie jedes Produkt und jedes Team in separaten Projekten verwalten. Auf diese Weise verhindern Sie, dass Pipelines von einem Produkt versehentlich auf offene Ressourcen von einem anderen Produkt zugreifen, wodurch die Lateralexposition minimiert wird. Wenn jedoch mehrere Teams oder Produkte ein Projekt gemeinsam nutzen, wird die granulare Isolierung ihrer Ressourcen schwierig.

Wenn Ihre Azure DevOps-Organisation vor August 2019 erstellt wurde, haben Sie möglicherweise weiterhin Zugriff auf offene Ressourcen in allen Projekten Ihrer Organisation. Ihr Organisationsadministrator sollte eine kritische Sicherheitseinstellung in Azure-Pipelines überprüfen, die die Projektisolation für Pipelines ermöglicht.

Diese Einstellung finden Sie unter "Organisationseinstellungen>Pipelines-Einstellungen>" oder direkt: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Schützen von Repositorys

In Versionssteuerungsrepositorys können Sie Quellcode, die YAML-Datei der Pipeline und die erforderlichen Skripts und Tools speichern. Um sichere Änderungen am Code und der Pipeline sicherzustellen, ist es wichtig, Berechtigungen und Verzweigungsrichtlinien anzuwenden. Darüber hinaus sollten Sie Pipelineberechtigungen und Überprüfungen zu Repositorys hinzufügen.

Überprüfen Sie außerdem die Standardeinstellungen für die Zugriffssteuerung für Ihre Repositorys.

Denken Sie daran, dass der Entwurf von Git bedeutet, dass der Schutz auf Verzweigungsebene Einschränkungen hat. Benutzer mit Pushzugriff auf ein Repository können in der Regel neue Verzweigungen erstellen. Wenn Sie mit Open-Source-Projekten von GitHub arbeiten, kann jeder Mit einem GitHub-Konto Ihr Repository verzweigen und Beiträge vorschlagen. Da Pipelines einem Repository (keine bestimmten Verzweigungen) zugeordnet sind, ist es wichtig, Code- und YAML-Dateien als potenziell nicht vertrauenswürdig zu behandeln.

Forks

Wenn Sie mit öffentlichen Repositorys von GitHub arbeiten, ist es wichtig, Ihren Ansatz für Freihandbuilds sorgfältig zu berücksichtigen. Schalen, die von außerhalb Ihrer Organisation stammen, stellen besondere Risiken dar. Um Ihre Produkte vor potenziell nicht vertrauenswürdigen Code zu schützen, berücksichtigen Sie die folgenden Empfehlungen:

Hinweis

Diese Empfehlungen gelten in erster Linie für das Erstellen öffentlicher Repositorys von GitHub.

Keine Geheimnisse in Forkbuilds bereitstellen

Standardmäßig sind Ihre Pipelines für die Erstellung von Forks konfiguriert, geheime und geschützte Ressourcen werden jedoch nicht automatisch für die Aufträge in diesen Pipelines verfügbar gemacht. Es ist wichtig, diesen Schutz nicht zu deaktivieren, um die Sicherheit aufrechtzuerhalten.

Hinweis

Wenn Sie Freihandbuilds für den Zugriff auf geheime Schlüssel aktivieren, schränkt Azure Pipelines das standardmäßig verwendete Zugriffstoken ein. Dieses Token hat eingeschränkten Zugriff auf offene Ressourcen im Vergleich zu einem regulären Zugriffstoken. Wenn Sie Verzweigungsbuilds dieselben Berechtigungen wie normale Builds erteilen möchten, verfügen Sie für die Erstellung von Freihandbuilds über die gleichen Berechtigungen wie die Einstellung für reguläre Builds .

Manuelles Auslösen von Forkbuilds erwägen

Sie können automatische Forkbuilds deaktivieren und stattdessen Pull-Request-Kommentare verwenden, um diese Beiträge manuell zu erstellen. Diese Einstellung bietet Ihnen die Möglichkeit, den Code vor dem Auslösen eines Builds zu überprüfen.

Von Microsoft gehostete Agents für Forkbuilds

Vermeiden Sie Builds von Forks auf selbst gehosteten Agents. Auf diese Weise können externe Organisationen externen Code auf Computern innerhalb Ihres Unternehmensnetzwerks ausführen. Verwenden Sie nach Möglichkeit von Microsoft gehostete Agents. Implementieren Sie für selbst gehostete Agents die Netzwerkisolation, und stellen Sie sicher, dass Agents ihren Status zwischen Aufträgen nicht beibehalten.

Codeänderungen überprüfen

Bevor Sie Ihre Pipeline in einem geforkten Pull Request ausführen, überprüfen Sie die vorgeschlagenen Änderungen sorgfältig, und vergewissern Sie sich, dass Sie mit der Ausführung einverstanden sind.

Die Version der yaML-Pipeline, die Sie ausführen, ist die Version aus der Pullanforderung. Achten Sie daher besonders auf Änderungen am YAML-Code und an dem Code, der bei der Ausführung der Pipeline ausgeführt wird, z. B. Befehlszeilenskripts oder Komponententests.

Einschränkung auf GitHub-Tokenbereich

Wenn Sie einen geforkten GitHub-Pull Request kompilieren, stellt Azure Pipelines sicher, dass die Pipeline keine GitHub-Repositoryinhalte ändern kann. Diese Einschränkung gilt nur, wenn Sie die Azure Pipelines-GitHub-App zur Integration in GitHub verwenden. Wenn Sie eine andere Form der GitHub-Integration verwenden, z. B. die OAuth-App, wird die Einschränkung nicht erzwungen.

Benutzerbranches

Benutzer*innen in Ihrer Organisation mit den richtigen Berechtigungen können neue Branches erstellen, die neuen oder aktualisierten Code enthalten. Dieser Code kann dieselbe Pipeline wie Ihre geschützter Branch es ausführen. Wenn die YAML-Datei in der neuen Verzweigung geändert wird, wird das aktualisierte YAML verwendet, um die Pipeline auszuführen. Dieses Design ermöglicht zwar ein hohes Maß an Flexibilität und Self-Service-Funktionalität, aber nicht alle Änderungen sind sicher (unabhängig davon, ob sie mit böser Absicht vorgenommen wurden).

Wenn Ihre Pipeline Quellcode verbraucht oder in Azure Repos definiert ist, müssen Sie das Azure Repos-Berechtigungsmodellvollständig verstehen. Insbesondere kann ein Benutzer mit der Create Branch-Berechtigung auf Repository-Ebene Code in das Repository einbringen, auch wenn er keine Contribute-Berechtigung hat.

Weitere Sicherheitsüberlegungen

Es gibt die folgenden Handvoll anderer Dinge, die Sie beim Sichern von Pipelines berücksichtigen sollten.

Verlassen Sie sich auf PATH

Es ist nicht ratsam auf die PATH-Einstellung des Agents zu vertrauen. Es zeigt möglicherweise nicht, wo dies der Fall ist, da es potenziell durch ein vorheriges Skript oder Tool geändert wurde. Verwenden Sie für sicherheitskritische Skripts und Binärdateien immer einen vollqualifizierten Pfad zum Programm.

Geheime Schlüssel protokollieren

Azure Pipelines versucht, Geheimnisse nach Möglichkeit aus Protokollen zu bereinigen. Diese Filterung erfolgt nach bestem Bemühen und kann nicht jede Art und Weise abfangen, in der Geheimnisse aufgedeckt werden können. Geheimnisse sollten nicht an der Konsole ausgegeben, in Befehlszeilenparametern verwendet oder in Dateien protokolliert werden.

Sperren von Containern

Container verfügen über einige vom System bereitgestellte Volumebereitstellungszuordnungen in den Aufgaben, dem Arbeitsbereich und externen Komponenten, die für die Kommunikation mit dem Host-Agent erforderlich sind. Sie können keine oder alle diese Volumes als schreibgeschützt markieren.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

In der Regel sollten die meisten Personen die ersten drei Verzeichnisse als schreibgeschützt festlegen und als Lese-/Schreibzugriff belassen work . Wenn Sie in einem bestimmten Auftrag oder Schritt nicht in das work Verzeichnis schreiben, können Sie auch schreibgeschützt machen work . Wenn Ihre Pipelineaufgaben jedoch selbst geändert werden, müssen Sie möglicherweise schreibgeschützt bleiben tasks .

Steuern verfügbarer Aufgaben

Sie können die Möglichkeit zum Installieren und Ausführen von Aufgaben aus dem Marketplace deaktivieren, sodass Sie den Code, der in einer Pipeline ausgeführt wird, besser steuern können. Möglicherweise deaktivieren Sie auch alle im Feld verfügbaren Aufgaben (mit Ausnahme des Auscheckens, einer speziellen Aktion für den Agent). Es wird empfohlen, dass Sie in den meisten Fällen keine im Lieferumfang enthaltenen Aufgaben deaktivieren.

Aufgabe, die direkt unter tfx installiert sind, sind immer verfügbar. Wenn beide Features aktiviert sind, sind nur diese Aufgaben verfügbar.

Verwenden des Überwachungsdiensts

Viele Pipelineereignisse werden im Überwachungsdienst aufgezeichnet. Überprüfen Sie das Überwachungsprotokoll regelmäßig, um sicherzustellen, dass keine böswilligen Änderungen vorbei sind. Hier finden Sie Informationen zum Einstieg: https://dev.azure.com/ORG-NAME/_settings/audit.

Nächste Schritte

Überprüfen der Sicherheitsübersicht