Sicherer Zugriff auf Repositorys aus Pipelines

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

Um den Code zu schützen, der ihre Vorgänge ausführt, müssen Organisationen den Zugriff auf ihre Quellcoderepositorys sorgfältig steuern. In diesem Artikel wird beschrieben, wie Azure Pipelines Build- und Releasepipelines sicher auf Repositorys zugreifen können, um das Risiko eines nicht autorisierten Zugriffs zu minimieren.

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

Projektbasierte Identitäten für Pipelines

Eine Pipeline verwendet eine Identität für den Zugriff auf Ressourcen wie Repositorys, Dienstverbindungen und variablen Gruppen während der Ausführung. Pipelines können zwei Arten von Identitäten verwenden: Sammlungsebene oder Projektebene.

Identität auf Sammlungsebene ist einfach einzurichten und zu verwenden, aber Identitäten auf Projektebene priorisieren die Sicherheit. Um die Sicherheit zu verbessern, verwenden Sie Identitäten auf Projektebene, um Pipelines auszuführen. Eine Identität auf Projektebene kann nur innerhalb ihres Projekts auf Ressourcen zugreifen, wodurch die Auswirkungen eines nicht autorisierten Zugriffs durch böswillige Akteure minimiert werden. Weitere Informationen finden Sie unter Bereichsbezogene Buildidentitäten und Auftragsautorisierungsbereich.

Wenn Sie eine Pipeline für die Verwendung einer Identität auf Projektebene konfigurieren möchten, aktivieren Sie „Autorisierungsbereich für Jobs auf das aktuelle Projekt beschränken“ für Nicht-Veröffentlichungs-Pipelines oder „Autorisierungsbereich für Jobs auf das aktuelle Projekt beschränken“ für Veröffentlichungs-Pipelines in den Projekteinstellungen des Pipelineprojekts unter Pipelines>Einstellungen.

Schritte zur Verbesserung der Sicherheit des Repositoryzugriffs

Ein Projektadministrator oder Project Collection-Administrator kann die folgenden Schritte ausführen, um die Sicherheit für den Zugriff auf Git-Repositorys aus Pipelines zu verbessern.

1. Überprüfen Sie die Pipelines, um alle erforderlichen Repositorys zu identifizieren, die sich in anderen Projekten befinden. Wenn Sie die Option 'Auftragsautorisierung auf das aktuelle Projekt für Nicht-Release-Pipelines einschränken' aktivieren, können Pipelines Code nur aus den Repositorys des aktuellen Projekts abrufen.

2. Gewähren Sie Pipelineprojekten Zugriff auf alle anderen Projekte, die sie benötigen. Weitere Informationen finden Sie unter Konfigurieren von Berechtigungen für ein Projekt für den Zugriff auf ein anderes Projekt in derselben Projektsammlung.

3. Gewähren Sie Pipeline-Build-Identitäten Lesezugriff auf jedes Repository, das sie auschecken. Gewähren Sie außerdem Pipeline-Identitäten Lesezugriff auf alle Repositorys, die als Untermodule von erforderlichen Repositorys verwendet werden. Weitere Informationen finden Sie unter Konfigurieren von Berechtigungen für den Zugriff auf ein anderes Repository in derselben Projektsammlung.

4. Aktivieren Sie die folgenden Organisations- oder Projekteinstellungen für das Pipelineprojekt:

   • Beschränken Sie den Auftragsautorisierungsbereich auf das aktuelle Projekt für Nicht-Release-Pipelines.
   • Beschränken Sie den Auftragsautorisierungsbereich auf das aktuelle Projekt für Releasepipelinen , wenn Ihr Projekt Über Releasepipelines verfügt.
   • Schützen Sie den Zugriff auf Repositorys in YAML-Pipelines , wenn Ihr Projekt Über Azure Repos YAML-Pipelines verfügt.

   Aktivieren Sie diese Einstellungen, indem Sie die Schalter auf Ein in den Organisationseinstellungen oder Projekteinstellungen>Pipelines>Einstellungen>Allgemein festlegen.

   Wenn die Einstellungen in den Organisationseinstellungen aktiviert sind, können sie in den Projekteinstellungen nicht außer Kraft gesetzt werden. Wenn die Einstellungen in den Organisationseinstellungen nicht aktiviert sind, können sie auf Projektebene aktiviert werden.

Verwenden eines Repositorys als Untermodul

Wenn ein Repository ein anderes Repository in seinem Projekt als Untermodul verwendet, kann das Auschecken des Untermoduls fehlschlagen, selbst wenn Sie der Pipeline Lesezugriff auf beide Repositories gewähren. Um dieses Problem zu beheben, sollten Sie Submodul-Repositorys gezielt auschecken, bevor Sie die Repositorys auschecken, die diese verwenden. Weitere Informationen finden Sie unter "Untermodule auschecken".

GitHub-Repositorys

Die folgenden Sicherheitsüberlegungen gelten für den Pipelinezugriff auf GitHub-Repositorys. Weitere Informationen finden Sie unter Zugriff auf GitHub-Repositorys.

GitHub-Dienstverbindungen

Um GitHub-Repositorys zu verwenden, erfordert Azure Pipelines eine GitHub-Dienstverbindung. So stärken Sie die Sicherheit der Dienstverbindung:

• Zugriff nur auf die Repositorys zulassen, die für das Ausführen der Pipelines notwendig sind.
• Wählen Sie nicht "Zugriffsberechtigung für alle Pipelines für die Dienstverbindung erteilen" aus. Autorisieren Sie ausdrücklich die Dienstverbindung für jede Pipeline, die sie verwendet.

Authentifizierung für GitHub-Repositorys

Um Builds auszulösen und Code während builds abzurufen, müssen Azure-Pipelines Zugriff auf GitHub-Repositorys erhalten. Dieser Zugriff kann gitHub personal access token (PAT), OAuth oder GitHub Azure Pipelines app authentication verwenden. Weitere Informationen finden Sie unter Zugriff auf GitHub-Repositorys.

Die GitHub Azure Pipelines-App ist der empfohlene Authentifizierungstyp für CI-Pipelines (Continuous Integration). Builds und GitHub-Statusupdates verwenden dann die Azure Pipelines-Identität, anstatt Ihre persönliche GitHub-Identität zu verwenden. Wenn Sie die App installieren, können Sie einschränken, auf welche Repositorys die App für erhöhte Sicherheit zugreifen kann.

OAuth und PAT-Authentifizierung verwenden Ihre persönliche GitHub-Identität und müssen für den Pipelinezugriff autorisiert sein. Die Verwendung eines PAT wird aufgrund von Sicherheitsbedenken abgeraten. Wenn Sie PAT-Authentifizierung verwenden müssen, wählen Sie einen fein abgestimmten PAT aus, und beschränken Sie den Umfang auf bestimmte Benutzer, Repositorys und Berechtigungen. Weitere Informationen finden Sie unter Verwalten Ihrer persönlichen Zugriffstoken.

Verzweigte GitHub-Repositorys

Abgespaltene Repositories erhöhen die Risiken der Ausführung von bösartigem Code oder der Freigabe vertraulicher Informationen in Pipelines. Die von außerhalb Ihrer Organisation stammenden Forks stellen besondere Risiken dar.

Um Risiken von abgezweigten Repositorys zu minimieren, sind Einschränkungen für das Erstellen von Pull-Requests aus abgezweigten GitHub-Repositorys und die Deaktivierung des Erstellens von Pull-Requests aus abgezweigten Repositorys standardmäßig in den Projekteinstellungen oder Organisationseinstellungen, sowie in >Pipelines>Einstellungen>Triggers aktiviert.

Um das Erstellen von verzweigten GitHub-Repositorys zuzulassen, aber die Risiken zu verringern, wählen Sie "Sicheres Erstellen von Pullanforderungen aus verzweigten Repositorys" aus. Diese Einstellung verbietet, geheime Schlüssel verfügbar zu machen oder dieselben Berechtigungen wie normale Builds zu verwenden, und erfordert einen PR-Kommentar von einem Teammitglied, um die Pipeline auszulösen.

Alternativ können Sie "Regeln anpassen" zum Erstellen von Pullanforderungen aus verzweigten Repositorys auswählen, um diese Einstellungen weiter anzupassen.

Weitere Möglichkeiten, die Fork-Sicherheit zu erhöhen, sind:

• Wenn Sie die Pull-Request-Validierung verwenden, um Builds auszulösen, deaktivieren Sie entweder im Trigger-Abschnitt der Pipelinedefinition die Option Builds von Forks dieses Repositorys, oder sorgen Sie dafür, dass Geheime Schlüssel für Builds von Forks verfügbar sind und Fork-Builds dieselben Berechtigungen wie reguläre Builds haben, deaktiviert sind. Sie können auch den Kommentar eines Teammitglieds anfordern, bevor Sie eine Pullanforderung erstellen.

• Verwenden Sie von Microsoft gehostete Agents zum Erstellen von Forks. Ressourcen werden unmittelbar nach den Builds von den Agents gelöscht. Wenn Sie selbst gehostete Agents verwenden, bereinigen und aktualisieren Sie die Agents regelmäßig, oder verwenden Sie separate Agents für verschiedene Forks oder Zweigstellen.

Azure Repos-Repositorien

Beispiel für Azure Repos

Das folgende Beispiel veranschaulicht den Prozess der Verbesserung der Sicherheit für den Azure Repos-Zugriff in einer Pipeline.

Die https://dev.azure.com/fabrikam-tailspin Organisation enthält die Projekte SpaceGameWeb und FabrikamFiber .

• Das SpaceGameWeb-Projekt enthält die Repositorys "SpaceGameWeb " und "SpaceGameWebReact ".

  

• Das FabrikamFiber-Projekt enthält die Repositorys FabrikamFiber, FabrikamChat und FabrikamFiberLib . Das FabrikamFiber-Repository verwendet das FabrikamFiberLib-Repository als Untermodul.

  

Die SpaceGameWeb-Pipeline im SpaceGameWeb-Projekt überprüft das SpaceGameWebReact-Repo im SpaceGameWeb-Projekt und die FabrikamFiber - und FabrikamChat-Repositorys im FabrikamFiber-Projekt .

Wenn das Projekt nicht für die Verwendung einer projektbasierten Buildidentität eingerichtet ist oder um den Zugriff auf Repositorys in YAML-Pipelines zu schützen, kann die SpaceGameWeb-Pipeline auf alle Repositorys in allen Projekten in der Organisation zugreifen und erfolgreich ausgeführt werden.

Verwenden der Identität auf Projektebene

Um die Sicherheit zu verbessern, verwenden Sie eine Identität auf Projektebene, um die Pipeline auszuführen. Aktivieren Sie den Schalter Einschränkung des Genehmigungsbereichs für Aufträge auf das aktuelle Projekt für Nicht-Release-Pipelines in den Projekteinstellungen oder Organisationseinstellungen.

Wenn diese Einstellung aktiviert ist, kann die Pipeline nur auf Ressourcen im SpaceGameWeb-Projekt zugreifen, die nur die Repositorys "SpaceGameWeb" und "SpaceGameWebReact" enthält. Die Pipeline schlägt fehl, da sie die Repositorys im FabrikamFiber-Projekt nicht auschecken kann.

Sie sehen die Fehler remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting und remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Um die Probleme zu beheben, gewähren Sie dem Pipelineprojekt Zugriff auf das FabrikamFiber-Projekt, und gewähren Sie der Pipelineidentität Lesezugriff auf die Repositorys FabrikamFiber, FabrikamChat und FabrikamFiberLib.

Explizites Auschecken des Untermoduls

Das FabrikamFiber-Repository verwendet das FabrikamFiberLib-Repository als Untermodul. Auch wenn Sie der Pipeline Zugriff auf beide Repositorys gewähren, schlägt das Auschecken des FabrikamFiber-Repositorys immer noch fehl, wenn das FabrikamFiberLib-Untermodul ausgecheckt wird.

Um dieses Problem zu beheben, checken Sie das FabrikamFiberLib-Repository explizit aus, bevor Sie das FabrikamFiber-Repository auschecken. Fügen Sie einen checkout: git://FabrikamFiber/FabrikamFiberLib Schritt vor dem checkout: FabrikamFiber Schritt hinzu. Die Beispielpipeline ist jetzt erfolgreich.

Schützen des Zugriffs auf die YAML-Pipeline

Wenn die Beispiel-SpaceGameWeb-Pipeline eine YAML-Pipeline ist und der Schutz des Zugriffs auf Repositorys in YAML-Pipelines aktiviert ist, benötigt die Pipeline die Berechtigung zum Zugriff auf die Repositorys SpaceGameWebReact, FabrikamFiber und FabrikamChat, wenn sie zum ersten Mal ausgeführt wird.

Der folgende Code zeigt die vollständige YAML-Pipeline.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: git://FabrikamFiber/FabrikamFiberLib
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md

Weitere Sicherheitsmaßnahmen für Repositorys

• Um Sicherheitsrisiken von YAML- und klassischen Pipelines zum Teilen von Ressourcen zu verringern, deaktivieren Sie die Erstellung klassischer Pipelines , indem Sie die Erstellung klassischer Buildpipelines deaktivieren und die Erstellung klassischer Releasepipelines in den Projekteinstellungen oder Organisationseinstellungen deaktivieren. Klassische Build- und Releasepipelineerstellung ist für neue Organisationen standardmäßig deaktiviert.

• Verwenden Sie Pipelinevorlagen , um die Pipelinestruktur zu definieren und schädlichen Code infiltration zu verhindern. Vorlagen können auch automatisch Aufgaben ausführen, z. B. die Überprüfung von Anmeldeinformationen oder das Erzwingen von Überprüfungen geschützter Ressourcen.

• Erfordert jedes Mal, wenn eine Pipeline das Repository anfordert, eine manuelle Genehmigung . Weitere Informationen finden Sie unter Genehmigungen und Überprüfungen.

• Verwenden Sie eine geschützte Verzweigungsprüfung , um zu verhindern, dass Pipelines automatisch in nicht autorisierten Verzweigungen ausgeführt werden.

• Legen Sie fest, dass ein Repository nur in angegebenen YAML-Pipelines verwendet werden soll. Weitere Informationen finden Sie unter Hinzufügen von Pipelineberechtigungen zu einer Repositoryressource.

• Beschränken Sie den Umfang des Azure Pipelines-Zugriffstokens, indem Sie das Token nur für Repositorys resources bereitstellen, die im Abschnitt der Pipeline aufgeführt sind. Weitere Informationen finden Sie in Repositoryschutz.

Verwandte Inhalte

• Zugreifen auf Repositorys, Artefakte und andere Ressourcen
• Schützen einer Repository-Ressource
• Pipelineoptionen für Git-Repositorys
• Ressourcensicherheit