Sichere Agents, Projekte und Container

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

Wenn Sie Azure-Pipelines schützen, sollten Sie die gemeinsame Infrastruktur, Repositorys, Projekte und vieles mehr schützen.

Dieser Artikel ist Teil einer Reihe, mit der Sie Sicherheitsmaßnahmen für Azure-Pipelines implementieren können. Weitere Informationen finden Sie unter Secure Azure Pipelines.

Voraussetzungen

Gemeinsame Infrastruktur schützen

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 eine saubere virtuelle Maschine für jeden Lauf einer Pipeline. Verwenden Sie nach Möglichkeit von Microsoft gehostete Pools anstelle von selbst gehosteten Pools.

Separate Agents für jedes Projekt

Ein Agent kann nur einem 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 Agenten aufeinanderfolgend verwenden. Auch wenn dieser Ansatz kosteneffizient ist, kann dieser Ansatz Lateral Movement-Risiken mit sich bringen.

Um die Lateralbewegung zu reduzieren und eine Kreuzkontamination zwischen Projekten zu verhindern, pflegen Sie separate Agentpools, die jeweils einem bestimmten Projekt zugeordnet sind.

Verwenden Sie Konten mit geringen Berechtigungen, um Agenten auszuführen.

Das Ausführen des Agents unter einer Identität mit direktem Zugriff auf Azure DevOps-Ressourcen kann riskant sein. Dieses Risiko ist in Organisationen, die Microsoft Entra ID verwenden, weit verbreitet.

Warum dieses Risiko wichtig ist:

• Wenn Sie den Agent unter einer von entra ID gesicherten Identität ausführen, kann er direkt auf Azure DevOps-APIs zugreifen, ohne sich auf das Zugriffstoken des Auftrags zu verlassen.
• Angreifer, die eine kompromittierte Pipeline auf diesen Build-Agents ausführen, könnten potenziell die Kontrolle über die gesamte Azure DevOps-Organisation erlangen.

Empfehlung: Führen Sie den Agent mit einem nicht privilegierten lokalen Konto aus:

• Windows-Agents: Verwenden des Netzwerkdiensts (NT AUTHORITY\NETWORK SERVICE), des lokalen Diensts oder eines gruppenverwalteten Dienstkontos (gMSA).
• Linux-Agents und macOS-Agents: Erstellen Sie ein dediziertes Nicht-Root-Benutzerkonto (z. B., svc_azuredevops). Dieses Konto sollte keinen sudo- oder sudoers-Zugriff haben, um maximale Sicherheit zu gewährleisten.

Risiken von besonders privilegierten Agents:

Eigenständig gehostete Agents arbeiten manchmal unter hochprivilegierten Konten, um auf Geheimnisse oder Produktionsumgebungen zuzugreifen. Wenn Angreifer eine kompromittierte Pipeline auf einem dieser Build-Agents ausführen, können sie:

• Zugriff auf diese Geheimnisse erhalten
• Quer durch andere Systeme, auf die über diese Konten zugegriffen werden kann

Bewährte Methoden für die Agentsicherheit:

• Verwenden Sie das niedrigste privilegierte Konto, das für die Ausführung von selbst gehosteten Agents möglich ist.
• Erwägen Sie die Verwendung Ihres Computerkontos oder einer verwalteten Dienstidentität.
• Ermöglichen Sie Azure Pipelines das Verwalten des Zugriffs auf geheime Schlüssel und Umgebungen.

Minimieren des Umfangs von Dienstverbindungen

Dienstverbindungen sollten nur auf die erforderlichen Ressourcen zugreifen.

Authentifizierungsempfehlungen:

• Verwenden Sie den Workload-Identitätsverbund anstelle eines Dienstprinzipals für Ihre Azure-Dienstverbindung , wenn möglich.
• 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.

Bereichsempfehlungen:

• Beschränken Sie Ihre Azure-Dienstverbindung , um nur auf erforderliche Ressourcen zuzugreifen.
• Vermeiden Sie die Gewährung umfassender Mitwirkenderrechte für das gesamte Azure-Abonnement.
• 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.
• Gewähren Sie beim Konfigurieren der GitHub-App nur Zugriff auf die Repositorys, die Sie 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 Sie müssen verstehen, auf was Ihre Pipeline basierend auf den Projekteinstellungen und Beschränkungen zugreifen kann.

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. Dieses Berechtigungsmodell bedeutet, dass Ihr Benutzerkonto möglicherweise keinen direkten Zugriff auf eine bestimmte Ressource hat, Skripts und Aufgaben, die in Ihrer Pipeline ausgeführt werden, weiterhin 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.

Repositories schützen

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 Pipeline-Berechtigungen und Überprüfungen zu Repositories 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 forken 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.

Gabeln

Wenn Sie mit öffentlichen Repositorys von GitHub arbeiten, sollten Sie Ihren Ansatz für Fork-Vorgänge sorgfältig berücksichtigen. Schalen, die von außerhalb Ihrer Organisation stammen, stellen besondere Risiken dar. Befolgen Sie diese Empfehlungen, um Ihre Produkte vor potenziell nicht vertrauenswürdigen Code zu schützen.

Keine Geheimnisse in Forkbuilds bereitstellen

Standardmäßig erstellen Ihre Pipelines Forks, aber sie geben nicht automatisch Geheimnisse und geschützte Ressourcen in diesen Pipelines für die Aufträge zugänglich. Deaktivieren Sie diesen Schutz nicht, um die Sicherheit aufrechtzuerhalten.

Möglicherweise manuelles Auslösen von Fork-Builds in Betracht ziehen

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

Verwenden Sie von Microsoft gehostete Agents für Fork-Builds

Vermeiden Sie, Builds von Forks auf selbst gehosteten Agenten auszuführen. Wenn Sie selbst gehostete Agents verwenden, 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 für eine geforkte Pull-Anfrage ausführen, sollten Sie die vorgeschlagenen Änderungen sorgfältig überprüfen und sicherstellen, dass Sie sich dabei wohl fühlen.

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

Einschränkung des GitHub-Token-Bereichs

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 andere Formen der GitHub-Integration verwenden, z. B. die OAuth-App, wird die Einschränkung nicht erzwungen.

Benutzerzweige

Benutzer*innen in Ihrer Organisation mit den richtigen Berechtigungen können neue Branches erstellen, die neuen oder aktualisierten Code enthalten. Dieser Code kann durch dieselbe Pipeline wie Ihre geschützten Zweige laufen. Wenn die YAML-Datei im neuen Branch geändert wird, startet die aktualisierte YAML-Datei die Pipeline. Obwohl dieses Design große Flexibilität und Self-Service bietet, sind nicht alle Änderungen sicher (ob böswillig oder nicht).

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

Berücksichtigen Sie beim Sichern von Pipelines die folgenden Sicherheitsaspekte.

Verlassen Sie sich auf PATH

Es ist gefährlich, sich auf die PATH-Einstellung des Agents zu verlassen. Es zeigt möglicherweise nicht dorthin, wo Sie denken, da ein früheres Skript oder Tool es potenziell geändert hat. Verwenden Sie für sicherheitskritische Skripts und Binärdateien immer einen vollqualifizierten Pfad zum Programm.

Geheimnisse protokollieren

Azure Pipelines versucht, geheime Schlüssel nach Möglichkeit aus Protokollen zu entfernen. Diese Filterung erfolgt nach bestem Bemühen und kann nicht jede Art und Weise abfangen, in der Geheimnisse aufgedeckt werden können. Vermeiden Sie, Geheimnisse an der Konsole auszugeben, sie in Befehlszeilenparametern zu verwenden oder in Dateien zu protokollieren.

Sperren von Containern

Container verfügen über einige vom System bereitgestellte Volumen-Mounts für die Aufgaben, den Arbeitsbereich und externe Komponenten, die erforderlich sind, um mit dem Host-Agenten zu kommunizieren. Sie können beliebige oder alle dieser Volumen 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 legen die meisten Personen die ersten drei Verzeichnisse schreibgeschützt fest und lassen work mit Lese-/Schreibzugriff. Wenn Sie in einem bestimmten Auftrag oder Schritt nicht in das work-Verzeichnis schreiben, können Sie work auch schreibgeschützt machen. Wenn Ihre Pipeline-Aufgaben jedoch Selbstmodifikation beinhalten, müssen Sie möglicherweise tasks als Lese-/Schreibzugriff beibehalten.

Verwenden des Prüfdiensts

Der Prüfdienst zeichnet viele Pipeline-Ereignisse auf. Überprüfen Sie das Auditprotokoll regelmäßig, um sicherzustellen, dass keine böswilligen Änderungen unbemerkt geblieben sind. Um zu beginnen, besuchen Sie https://dev.azure.com/ORG-NAME/_settings/audit.

Nächster Schritt