Sichern Ihrer Repositorys und Pipelines

8 Minuten

Wenn Sie die Automatisierung zum Bereitstellen Ihrer Infrastruktur verwenden, werden Ihre Pipeline und Ihr Repository nützlich und wichtig. Sie stellen nun die einzige Möglichkeit dar, Änderungen auf Ihre kontrollierten Umgebungen anzuwenden.

Viele Komponenten Ihrer Azure DevOps-Organisation, Ihres GitHub-Repositorys und Ihrer Pipelines müssen geschützt werden. Die folgende Tabelle enthält einige der wichtigsten zu schützenden Elemente sowie Beispiele für Sicherheitsrisiken, die auftreten können, wenn Sie diese Elemente nicht angemessen schützen.

Zu schützendes Element	Beispielsicherheitsrisiko
Ihre Azure DevOps-Organisation oder das GitHub-Repository, einschließlich der Personen, die Zugriff darauf haben und für welche Aufgaben sie zugelassen sind.	Ein verärgerter ehemaliger Mitarbeiter löscht Ihr Coderepository.
Wichtige Branches in Ihrem Repository und was geschehen muss, um den Code in diesen Branches zu ändern.	Jemand überträgt versehentlich einen unsicheren Bicep-Code in den Mainbranch Ihres Repositorys.
Der Code in Ihrem Repository, einschließlich Ihrer Infrastrukturdefinitionen, Tests und Anwendungscodes.	Jemand vergisst, den Code zu testen, den er oder sie geschrieben hat, und er funktioniert nicht ordnungsgemäß, wenn er für die Produktion freigegeben wird.
Die Pipelinedefinition.	Jemand hat versehentlich einen Pipelineschritt hinzugefügt, der eine Datenbankverbindungszeichenfolge in das Pipelineprotokoll schreibt.
Die Agents oder Runner, die Ihre Pipeline ausführen.	Eine Pipeline, die für einen Pull Request-Entwurf ausgeführt wird, führt zu einem Sicherheitsrisiko auf dem Agent, der später für eine Produktionsbereitstellung verwendet wird.
Alle Aufgaben oder Komponenten von Drittanbietern, die in Ihrer Pipeline ausgeführt werden können.	Eine Pipelineaufgabe eines Drittanbieters sendet die Anmeldeinformationen Ihres Dienstprinzipals an eine schädliche Website.
Die Dienstprinzipale, die Ihre Pipeline für den Zugriff auf Azure verwenden.	Ein nicht zur Produktionsumgebung gehörender Dienstprinzipal nimmt versehentlich eine Änderung an Ihrer Produktionsumgebung vor.
Die Geheimnisse, die Ihre Pipeline für den Zugriff auf externe Systeme verwendet.	Ein Teammitglied schreibt eine neue Pipelinedefinitionsdatei für einen Prototyp und verbindet sie versehentlich mit Ihrer Produktionsumgebung.

Nun lernen Sie einige der Ansätze kennen, die Sie verwenden können, um Governance und Kontrollen für Ihr Coderepository und Ihre Bereitstellungspipelines anzuwenden, sowohl in Azure DevOps als auch in GitHub.

Verwalten von Benutzern und Berechtigungen

Überlegen Sie, wie Sie den Zugriff auf Ihre Azure DevOps-Organisation oder Ihr GitHub-Repository gewähren möchten. Denken Sie darüber nach, wer Zugriff hat und welche Möglichkeiten mit diesem Zugriff einhergehen.

Es empfiehlt sich, die Microsoft Entra-Instanz Ihrer Organisation als Identitätsanbieter Ihrer Pipeline zu verwenden. Auf diese Weise können Sie sicherstellen, dass der Zugriff auf Ihre Pipeline immer automatisch gewährt oder widerrufen wird, wenn jemand zu Ihrem Unternehmen hinzukommt oder es verlässt. Durch die Verwendung von Microsoft Entra können Sie außerdem problemlos Schutzmaßnahmen wie bedingten Zugriff und Multi-Faktor-Authentifizierung implementieren.

Hinweis

Um die Microsoft Entra-Integration mit GitHub zu nutzen, benötigt Ihre Organisation eine GitHub Enterprise-Lizenz.

Sie können auch Teams (in GitHub) oder Gruppen (in Azure DevOps) erstellen, die Gruppen von Benutzern darstellen, denen gemeinsam Berechtigungen erteilt werden können. Auf diese Weise müssen Sie die Berechtigungen nicht einzeln zuweisen. Es ist einfach, die Berechtigungen von Benutzern zu ändern, indem Sie sie zu einem Team oder einer Gruppe hinzufügen oder sie daraus entfernen.

Tipp

Azure DevOps verwendet ein Berechtigungsmodell mit geringsten Rechten, das sich von dem in Azure verwendeten Modell unterscheidet. In Azure DevOps haben Berechtigungen vom Typ Verweigern Vorrang vor Berechtigungen vom Typ Zulassen. Wenn Sie also mehreren Gruppen mit unterschiedlichen Berechtigungen zugewiesen sind, können Sie nur die Aktionen ausführen, die in allen Gruppen zulässig sind.

Vergewissern Sie sich, dass Sie verstehen, wie Berechtigungen zugewiesen werden, insbesondere für Gruppen.

Schützen wichtiger Codebranches

Ihre Pipelines und Automatisierungen sollten auf der Identifizierung spezifischer Codebranches basieren, wie Main. Der Code in diesen Branches ist in der Regel vertrauenswürdig und darf in Ihren Produktionsumgebungen bereitgestellt werden. Wenden Sie Kontrollen an, um sicherzustellen, dass der Code in Ihren wichtigen Branches verifiziert und überprüft worden ist.

Erwägen Sie die Verwendung von Schutzregeln für Branches (in GitHub) oder Branchrichtlinien (in Azure Repos), um das direkte Committen für wichtige Codebranches zu verhindern. Dann können Sie Ihr Team auffordern, Pull Requests zu verwenden, um alle Änderungen zusammenzuführen. Sie können automatisierte Prüfungen und manuelle Überprüfungsprozesse anwenden, um sicherzustellen, dass die Änderungen gültig sind, bevor sie zusammengeführt werden.

Testen und Überprüfen des Codes

Stellen Sie sicher, dass Ihr Team die Erwartungen an die Überprüfung und das Testen des gesamten Codes, einschließlich der Infrastrukturdefinitionen, versteht.

Ihre Pipelinedefinitionen sind YAML-Dateien, also eine Form von Code. Änderungen an Ihren Pipelinedefinitionen müssen überprüft und ausgewertet werden. Andernfalls könnte jemand versehentlich oder vorsätzlich einen Pipelineschritt erstellen, der die Anmeldeinformationen Ihres Dienstprinzipals preisgibt oder eine gefährliche Änderung an Ihrem Azure-Bestand vornimmt.

Alle Änderungen an Pipelinedefinitionsdateien müssen gründlich überprüft werden. Vergewissern Sie sich, dass jeder in Ihrem Team versteht, dass Pipelines über umfassende Berechtigungen verfügen und besonderer Aufmerksamkeit bedürfen.

Schützen Ihrer Pipeline-Agents und -Runner

Ihre Pipeline wird auf Agents (für Azure Pipelines) oder Runner (für GitHub Actions) ausgeführt. Sie können sich Agents und Runner als virtuelle Computer vorstellen. Ihre Pipelinedefinition steuert diese virtuellen Computer durch die Ausführung der von Ihnen bereitgestellten Aufgaben und Skripts.

Sowohl Azure Pipelines als auch GitHub Actions bieten gehostete Agents und Runner, die von Microsoft oder GitHub konfiguriert und gewartet werden. Der Plattformbesitzer konfiguriert die Computer so, dass sie den empfohlenen Sicherheitsmaßnahmen entsprechen. Die Verantwortlichkeiten des Plattformbesitzers umfassen das Patchen von Sicherheitsrisiken des Betriebssystems.

Sie können stattdessen Ihre eigenen physischen oder virtuellen Computer für Ihre Agents und Runner verwenden. Computer dieses Typs werden als selbstgehostete Agents und Runner bezeichnet. Wenn Sie selbstgehostete Agents und Runner verwenden, sind Sie dafür verantwortlich, dass die Computer richtig konfiguriert und vor Bedrohungen geschützt sind.

Von Microsoft gehostete Agents und von GitHub gehostete Runner sind kurzlebig. Alle Dateien oder Konfigurationsänderungen an einem Agent oder Runner werden zerstört, wenn die Ausführung einer Pipeline beendet ist. Wenn Sie Ihren Agent oder Runner selbst hosten, wird derselbe Computer wahrscheinlich für mehrere separate Pipelines oder Umgebungen verwendet, einschließlich Produktions- und Nichtproduktionsumgebungen. Angenommen, jemand erstellt eine Pipelinedefinition, die einige wichtige Dateien auf dem Betriebssystem des Agents ändert, und führt die Pipeline über einen Pull Request aus. Wenn eine Bereitstellung das nächste Mal in Ihrer Produktionsumgebung ausgeführt wird, wird der Agent möglicherweise erneut verwendet. Jetzt können Sie nicht vorhersagen, welche Auswirkungen die beschädigte Datei auf Ihre Produktionsumgebung haben könnte.

Aus diesen Gründen ist es ratsam, wann immer möglich, von Microsoft gehostete Agents und von GitHub gehostete Runner zu verwenden. Wenn Sie selbstgehostete Runner verwenden müssen, sollten Sie die mit ihrer Konfiguration und Verwendung verbundenen Risiken sorgfältig abwägen.

Bewerten von Komponenten von Drittanbietern, die in Ihrer Pipeline ausgeführt werden

Wenn Sie von der Community bereitgestellte GitHub Actions- oder Azure DevOps-Erweiterungen verwenden, sollten Sie wissen, wer sie entwickelt hat und wie sie funktionieren. Pipelinekomponenten von Drittanbietern haben möglicherweise Zugriff auf die Anmeldeinformationen Ihres Dienstprinzipals und damit auf Ihre gesamte Umgebung in Azure.

In Azure DevOps genehmigt der Organisationsadministrator normalerweise jede Erweiterung, bevor sie verwendet werden kann. Wenn Sie der Administrator für Ihre Organisation sind, sollten Sie das Sicherheitsrisiko jeder Komponente, die Sie verwenden, berücksichtigen. Sie sind dafür verantwortlich, sicherzustellen, dass sie vertrauenswürdig und sicher sind.

Wann immer Sie eine Aktion oder Aufgabe eines Drittanbieters verwenden, geben Sie die Version an. Erwägen Sie die Angabe der genauen Version, die Sie überprüft haben. Wenn Sie der Pipeline erlauben, automatisch eine neuere Version zu verwenden, könnte dies ein Risiko darstellen, das Sie nicht überprüft haben.

Schützen des Dienstprinzipals Ihrer Pipeline

Pipelines verwenden Dienstprinzipale für den Zugriff auf Azure und andere Dienste. Es ist wichtig, Ihre Dienstprinzipale zu schützen und dafür zu sorgen, dass ihre Anmeldeinformationen nicht missbräuchlich verwendet werden können. Erwägen Sie das Anwenden mehrerer Schutzebenen.

Zunächst können Sie die Anmeldeinformationen für Ihre Dienstprinzipale schützen:

Verwenden Sie nach Möglichkeit verwaltete Identitäten oder Workloadidentitäten, um das vollständige Speichern von Anmeldeinformationen zu vermeiden. Obwohl Sie nicht für alle Pipelines verwaltete Identitäten oder Workloadidentitäten verwenden können, ist dies nach Möglichkeit die empfohlene Methode.
Planen Sie, wie Sie die Anmeldeinformationen Ihres Dienstprinzipals regelmäßig ändern oder rotieren. Ihr Unternehmen könnte z. B. eine Richtlinie haben, die besagt, dass Anmeldeinformationen alle 90 oder 120 Tage rotiert werden. Überlegen Sie, wer für die Rotation verantwortlich sein wird und wie Sie alle Stellen, an denen die Anmeldeinformation verwendet wird, aktualisieren werden.
Erwägen Sie die Benennung eines Geheimnisverwahrers, dessen Aufgabe es ist, Geheimnisse, Schlüssel und Zertifikate so zu verwalten, dass sie für andere Teile des Unternehmens nicht verfügbar gemacht werden.

Als nächstes sollten Sie sich überlegen, welche Berechtigungen Sie den Dienstprinzipalen erteilen:

Wenden Sie Microsoft Entra-Richtlinien für bedingten Zugriff auf die Dienstprinzipale Ihrer Pipeline an. Diese Richtlinien helfen, riskante Anmeldungen und Verhaltensweisen zu erkennen. Wenn sich beispielsweise die Dienstprinzipale Ihrer Pipeline immer von einer bestimmten geografischen Region aus anmelden, kann der bedingte Zugriff die Anmeldung von unerwarteten Standorten aus erkennen, was darauf hindeuten könnte, dass die Anmeldeinformationen kompromittiert worden sind, und dies verhindern.
Überlegen Sie sorgfältig, welche Berechtigungen Sie den einzelnen Dienstprinzipalen erteilen. Nehmen wir an, Sie verfügen über einen Dienstprinzipal, mit dem Sie die Konfiguration einer freigegebenen Ressource lesen können. Überlegen Sie, ob Sie diesem Dienstprinzipal nur Leser-Zugriff gewähren können, da der Dienstprinzipal keine Aufgaben hat, die weitere Privilegien erfordern.
Verwenden Sie den minimalen Umfang für jede Berechtigung, die Sie einem Dienstprinzipal zuweisen. Wenn Ihr Dienstprinzipal z. B. nur in einer einzelnen Ressourcengruppe bereitgestellt werden muss, dann beziehen Sie die Rollenzuweisung auf diese Ressourcengruppe und nicht auf das gesamte Abonnement.
Verwenden Sie für jede Ihrer Umgebungen separate Dienstprinzipale. Auf diese Weise können sie auch dann nicht auf andere Umgebungen zugreifen, wenn die Anmeldeinformationen eines Dienstprinzipals kompromittiert werden oder wenn jemand Zugriff auf eine einzelne Umgebung erhält.

Schützen Ihrer Dienstverbindungen und Geheimnisse

Eine Dienstverbindung (in Azure Pipelines) oder ein Geheimnis (in GitHub) enthält die Anmeldeinformationen für den Dienstprinzipal, den die Pipeline für den Zugriff auf Ihre Azure-Umgebung verwendet. Es ist wichtig, dass Sie Ihre Dienstverbindungen und Geheimnisse schützen und dass Sie kontrollieren, welche Pipelines die einzelnen Dienstverbindungen und Geheimnisse verwenden. Andernfalls könnten Sie versehentlich einer Nichtproduktionsumgebung die Verwendung eines Dienstprinzipals ermöglichen, der Zugriff auf Produktionsressourcen hat.

Wenn Sie in Azure DevOps eine Dienstverbindung erstellen, können Sie diese so konfigurieren, dass Ihre Genehmigung erforderlich ist, bevor eine neue Pipeline oder Umgebung sie nutzen kann.

Azure DevOps ermöglicht es Ihnen auch, Überprüfungen zu bestimmten Dienstverbindungen zuzuordnen. Überprüfungen stellen eine weitere Schutzebene dar. Sie können z. B. eine Überprüfung für eine Produktionsdienstverbindung konfigurieren, um sicherzustellen, dass sie nur für Code aus dem Mainbranch Ihres Repositorys verwendet wird. Durch diese Überprüfung wird verhindert, dass nicht autorisierter Code in Ihrer Produktionsumgebung bereitgestellt wird.

In GitHub können Sie umgebungsspezifische Geheimnisse konfigurieren, sodass der GitHub Actions-Workflow nur den Geheimniswert bereitstellt, wenn er mit dieser Umgebung arbeitet. Durch die Verwendung von umgebungsspezifischen Geheimnissen und Kontrollmechanismen, z. B. Genehmigungen, können Sie das Risiko verringern, dass eine Bereitstellung in einer Nichtproduktionsumgebung zum Bereitstellen in Ihrer Produktionsumgebung verwendet wird. Sie können auch Workloadidentitäten verwenden, um die Verwendung von Anmeldeinformationen in Ihren GitHub Actions-Workflows zu vermeiden und die Möglichkeit zu beseitigen, dass Anmeldeinformationen offengelegt werden könnten.

Verwenden von GitHub-Sicherheitsfeatures

GitHub bietet Sicherheitsfeatures, die Sie auswerten und verwenden sollten. Zu diesen Features zählen:

Dependabot, das die Abhängigkeiten Ihres Quellcodes auf bekannte Sicherheitsrisiken überprüft.
Geheimnissuche, die Text in Ihrem Repository identifiziert, der wie Schlüssel oder Anmeldeinformationen aussieht. Es ist eine schlechte Methode, Geheimnisse in einem Repository zu speichern. Wenn Sie hinsichtlich eines Geheimnisses in Ihrem Repository gewarnt werden, sollten Sie davon ausgehen, dass der Wert des Geheimnisses gefährdet ist, und es dann widerrufen oder ändern.
Überwachung, um zu verstehen, wer Änderungen an Ihrer GitHub-Konfiguration vorgenommen hat.
Sicherheitsübersicht, die alle Ihre Sicherheitswarnungen in den Repositorys Ihres Unternehmens konsolidiert.

Verwenden von Azure DevOps-Überwachungsprotokollen

Azure DevOps bietet Überwachungsprotokolle, die Ihnen helfen zu verstehen, wer Änderungen an Ihren Pipelines, Branchrichtlinien, Repositorys und anderen Ressourcen vorgenommen hat. Es ist eine geeignete Methode, Überwachungen zu aktivieren und die Überwachungsprotokolle regelmäßig zu überprüfen.

Schützen von Repository und Pipeline

Wir haben die wichtigen Kontrollmechanismen erläutert, die Sie auf Ihr Repository und Ihre Pipeline anwenden können. Sehen wir uns nun an, welche Kontrollmechanismen Sie verwenden können, um die einzelnen wichtigen Elemente zu schützen, die weiter oben in dieser Lerneinheit erwähnt wurden:

Zu schützendes Element	Anzuwendende Steuerelemente
Ihre Azure DevOps-Organisation oder das GitHub-Repository, einschließlich der Personen, die Zugriff darauf haben und für welche Aufgaben sie zugelassen sind.	Verwenden Sie die Microsoft Entra ID für die Authentifizierung. Verwenden Sie Teams und Gruppen zur Zuweisung von Berechtigungen. Aktivieren Sie die Überwachungsprotokollierung, und überprüfen Sie Überwachungsprotokolle regelmäßig.
Wichtige Branches in Ihrem Repository und was geschehen muss, um den Code in diesen Branches zu ändern.	Wenden Sie Branchschutzregeln oder Branchrichtlinien an.
Der Code in Ihrem Repository, einschließlich Ihrer Infrastrukturdefinitionen, Tests und Anwendungscodes.	Erzwingen Sie Anforderungen für die Codeüberprüfung. Fügen Sie automatisierte oder manuelle Tests hinzu. Verwenden Sie auf GitHub entsprechend „Dependabot“ und die Geheimnissuche.
Die Pipelinedefinition.	Erzwingen Sie Anforderungen für die Codeüberprüfung.
Die Agents oder Runner, die Ihre Pipeline ausführen.	Verwenden Sie in Azure Pipelines von Microsoft gehostete Agents. Verwenden Sie in GitHub Actions von GitHub gehostete Runner.
Alle Aufgaben oder Komponenten von Drittanbietern, die in Ihrer Pipeline ausgeführt werden können.	Überprüfen Sie das Sicherheitsrisiko, das mit allen Erweiterungen und Aufgaben von Drittanbietern verbunden ist.
Die Dienstprinzipale, die Ihre Pipeline für den Zugriff auf Azure verwenden.	Verwenden Sie Workloadidentitäten in GitHub Actions. Verwenden Sie für Azure Pipelines entsprechende Dienstprinzipale, und rotieren Sie ihre Anmeldeinformationen regelmäßig. Verwenden Sie für jede Umgebung eigene Dienstprinzipale. Wenden Sie Richtlinien für bedingten Zugriff an.
Die Geheimnisse, die Ihre Pipeline für den Zugriff auf externe Systeme verwendet.	Verwenden Sie in Azure DevOps Genehmigungen und Überprüfungen für Dienstverbindungen. Verwenden Sie in GitHub umgebungsspezifische Geheimnisse und Workloadidentitäten.