Planen des Schutzes Ihrer YAML-Pipelines

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

Es wird ein inkrementeller Ansatz zum Schutz Ihrer Pipelines empfohlen. Der Idealfall wäre die Implementierung aller von uns angebotenen Anleitungen. Lassen Sie sich jedoch nicht von der Menge der Empfehlungen abschrecken. Nur weil Sie derzeit nicht alle Änderungen vornehmen können, heißt das nicht, dass Sie jetzt nicht zumindest einige Verbesserungen vornehmen können.

Sicherheitsempfehlungen stehen in Beziehung zueinander

Bei Sicherheitsempfehlungen gibt es komplexe gegenseitige Abhängigkeiten. Ihr Sicherheitsstatus hängt stark davon ab, welche Empfehlungen Sie sich entscheiden zu implementieren. Die Auswahl der Empfehlungen wiederum hängt von den Anliegen Ihrer DevOps- und Sicherheitsteams ab. Darüber hinaus spielen die Richtlinien und Methoden Ihrer Organisation eine erhebliche Rolle.

So können Sie beispielsweise die Sicherheit in einem kritischen Bereich erhöhen und weniger Sicherheit für eine praktischere Anwendung in einem anderen Bereich in Kauf nehmen. Wenn Sie beispielsweise extends-Vorlagen verwenden, damit alle Builds in Containern ausgeführt werden müssen, benötigen Sie möglicherweise keinen separaten Agentpool für jedes Projekt.

Beginnen Sie mit einer fast leeren Vorlage

Ein guter Ausgangspunkt ist das Erzwingen einer Erweiterung aus einer fast leeren Vorlage. Auf diese Weise haben Sie, wenn Sie mit der Umsetzung von Sicherheitsstrategien beginnen, einen zentralen Ort, an dem bereits alle Pipelines erfasst werden.

Weitere Informationen finden Sie unter Vorlagen.

Deaktivieren der Erstellung von klassischen Pipelines

Wenn Sie nur YAML-Pipelines entwickeln, deaktivieren Sie die Erstellung von klassischen Build- und Releasepipelines. Dadurch wird eine Sicherheitsproblematik verhindert, die sich aus YAML- und klassischen Pipelines ergibt, die dieselben Ressourcen wie z. B. identische Dienstverbindungen nutzen.

Sie können die Erstellung von klassischen Buildpipelines und klassischen Releasepipelines unabhängig voneinander deaktivieren. Wenn die Funktion aktiviert ist, können keine klassische Build- oder Releasepipelines, Taskgruppen und Bereitstellungsgruppen über die Benutzeroberfläche oder die REST-API erstellt werden.

Sie können die Erstellung von klassischen Pipelines über zwei Umschaltflächen auf Organisations- oder Projektebene deaktivieren. Navigieren Sie hierfür zu Ihren Organisations-/Projekteinstellungen, und wählen Sie dann im Abschnitt Pipelines die Option Einstellungen aus. Aktivieren Sie im Abschnitt Allgemein die Optionen Deaktivieren der Erstellung von klassischen Buildpipelines und Deaktivieren der Erstellung von klassischen Releasepipelines.

Die Aktivierung auf Organisationsebene wirkt sich auf alle Projekte innerhalb dieser Organisation aus. Andernfalls können Sie auswählen, für welche Projekte Sie die Funktion aktivieren möchten.

Um die Sicherheit neu erstellter Organisationen zu verbessern, deaktivieren wir ab Sprint 226 standardmäßig das Erstellen klassischer Build- und Releasepipelines für neue Organisationen.

Nächste Schritte

Nach der Planung Ihres Sicherheitsansatzes ist zu überlegen, welchen Schutz Ihre Repositorys bieten.