Schutz von Repositorys

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

Der Quellcode, die YAML-Datei der Pipeline und die erforderlichen Skripte und Tools werden alle in einem Repository für die Versionskontrolle gespeichert. Berechtigungen und Branchrichtlinien müssen verwendet werden, um sicherzustellen, dass Änderungen am Code und der Pipeline sicher sind. Sie können auch Pipelineberechtigungen und Überprüfungen zu Repositorys hinzufügen.

Außerdem sollten Sie die Standardzugriffssteuerung für Repositorys überprüfen.

Aufgrund des Konzepts von Git bietet der Schutz auf Branchebene keine völlige Sicherheit. Benutzer*innen mit Pushzugriff auf ein Repository können in der Regel neue Branches erstellen. Wenn Sie Open-Source-Projekte in GitHub verwenden, kann jede Person mit einem GitHub-Konto Ihr Repository forken und wiederum Beiträge einbringen. Da Pipelines einem Repository und nicht bestimmten Branches zugeordnet sind, müssen Sie davon ausgehen, dass der Code und die YAML-Dateien nicht vertrauenswürdig sind.

Radgabeln

Wenn Sie öffentliche Repositorys in GitHub erstellen, müssen festlegen, wie mit Forkbuilds umzugehen ist. Forks sind besonders gefährlich, da sie von Quellen außerhalb Ihrer Organisation kommen. Befolgen Sie diese Empfehlungen, um Ihre Produkte vor beigetragenem Code zu schützen.

Hinweis

Die folgenden Empfehlungen gelten in erster Linie für das Erstellen öffentlicher Repositorys über GitHub.

Keine Geheimnisse in Forkbuilds bereitstellen

Standardmäßig sind Ihre Pipelines so konfiguriert, dass Forks erstellt werden, aber Geheimnisse und geschützte Ressourcen werden den Aufträgen in diesen Pipelines nicht standardmäßig verfügbar gemacht. Deaktivieren Sie diesen Schutz nicht.

Hinweis

Wenn Sie den Zugriff von Forkbuilds auf Geheimnisse aktivieren, schränkt Azure Pipelines standardmäßig das Zugriffstoken ein, das für Forkbuilds verwendet wird. Für dieses Token ist der Zugriff auf offene Ressourcen weiter eingeschränkt als bei normalen Zugriffstoken. Um Forkbuilds die gleichen Berechtigungen wie reguläre Builds zu erteilen, aktivieren Sie die Einstellung Forkbuilds erstellen mit den gleichen Berechtigungen wie 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 gibt Ihnen die Möglichkeit, den Code zu prüfen, bevor ein Build ausgelöst wird.

Von Microsoft gehostete Agents für Forkbuilds

Erlauben Sie kein Buildausführung aus Forks auf selbstgehosteten Agents. Damit würden Sie externen Organisationen einen Pfad bereitstellen, über den sie externen Code auf Computern innerhalb Ihres Unternehmensnetzwerks ausführen können. Verwenden Sie von Microsoft gehostete Agents, wann immer dies möglich ist. Verwenden Sie für Ihren selbstgehosteten Agent eine Form der Netzwerkisolation, und stellen Sie sicher, dass Agents zwischen Aufträgen ihren Zustand 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 dem Pull Request. 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 über dieselbe Pipeline wie Ihre geschützten Branches ausgeführt werden. Wenn die YAML-Datei im neuen Branch geändert wird, wird die aktualisierte YAML-Datei zum Ausführen der Pipeline verwendet. 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.

Nächste Schritte

Als Nächstes erfahren Sie mehr über den weiteren Schutz, den Die Überprüfungen geschützter Ressourcen bieten.