Wer darf auf den Quellcode, die Pipeline und die Produktionsumgebung zugreifen?
Zugriffskontrolle in der Softwareentwicklung befasst sich mit der Frage, wer welche Aktion auf welchen Teil Ihrer Entwicklungspipeline ausführen darf: wer Code lesen darf, wer Code ändern und zusammenführen darf, wer einen Build starten darf und wer ein Release in die Produktion durchführen darf. Dies ist eine spezifischere Frage als die Zugriffskontrolle für eine Organisation im Allgemeinen, da ein Entwicklungsteam mit mehreren Systemen gleichzeitig arbeitet: ein Quellcode-Repository, eine Build- und Testumgebung sowie in der Regel eine separate Produktionsumgebung, in der die Software tatsächlich ausgeführt wird.
Der Grund, warum dieses Thema regelmäßig in Sicherheitsfragelisten und in den Risikomanagementmaßnahmen der Richtlinie (EU) 2022/2555 auftaucht, ist, dass ein Fehler bei der Zugriffskontrolle auf Ihre Entwicklungspipeline unmittelbar auf alle Benutzer Ihrer Software Auswirkungen hat. Wer unbemerkt Code ändern kann, der dann ausgerollt wird, beeinträchtigt nicht nur Ihre eigene Organisation, sondern auch Ihre Kunden. Daher fragt sowohl eine Aufsichtsbehörde als auch ein Abnehmer, der selbst Anforderungen erfüllen muss, nach, wie Sie dies umgesetzt haben.
Warum es um den Quellcode und die Pipeline geht
Ein Entwicklungsteam hat in der Regel mehr Menschen mit breiteren Rechten als streng erforderlich, einfach weil es praktisch funktioniert: Jeder kann überall zugreifen, niemand muss warten. Im Rahmen der Risikomanagementmaßnahmen wird genau an diesem Punkt nachgefragt. Nicht weil Vertrauen falsch wäre, sondern weil Nachweisbarkeit etwas anderes ist als Vertrauen: eine Aufsichtsbehörde oder ein Abnehmer möchte wissen, ob Sie nachweisen können, wer Zugriff hat, nicht nur ob Sie darauf vertrauen.
Die Fragen, die dabei regelmäßig auftauchen, betreffen in der Regel drei Ebenen. Die erste ist das Quellcode-Repository selbst: wer lesen kann, wer ändern kann und ob es eine obligatorische Überprüfung gibt, bevor eine Änderung mit der Hauptversion zusammengeführt wird. Die zweite ist die Build- und Testumgebung: wer einen Build starten kann und ob diese Umgebung Zugriff auf Daten oder Systeme hat, die nicht zu Testzwecken bestimmt sind. Die dritte ist die Produktionsumgebung: wer ein Release tatsächlich ausrollen kann und ob dies eine andere Gruppe von Personen ist als diejenigen, die den Code schreiben.
Trennung zwischen Code-Entwicklung und Deployment
Ein regelmäßig genanntes Unterscheidungsmerkmal in Fragelisten ist, ob die Person, die Code schreibt, auch diejenige ist, die das Release in die Produktion durchführt. Wenn dieselbe Person dies ohne einen Zwischenschritt durch jemand anderen tut, ergibt sich eine Situation, in der ein Fehler oder eine böswillige Änderung unbemerkt in die Produktion gelangt. Viele Organisationen lösen dies durch eine obligatorische zweite Überprüfung, bevor Code zusammengeführt wird, und durch eine separate Rolle oder getrennte Rechte für das tatsächliche Deployment. Wie dies in der Praxis aussieht, unterscheidet sich stark je nach Team und Größe; die Richtlinie selbst schreibt kein bestimmtes Verfahren vor, aber Aufsichtsbehörden und Abnehmer schauen auf die zugrunde liegende Frage: Kann eine Person unkontrolliert Änderungen durchführen, die Kunden beeinflussen.
Geheimnisse und Schlüssel getrennt vom Code
Ein zweiter Punkt, bei dem Fragelisten regelmäßig nachfragen, ist, wo Passwörter, API-Schlüssel und andere Geheimnisse gespeichert werden. Geheimnisse, die im Quellcode selbst stehen, sind für jeden mit Lesezugriff auf diesen Code sichtbar, was eine viel größere Gruppe sein kann als diejenigen, die tatsächlich mit diesem Schlüssel arbeiten sollten. Ein separater Vault für Geheimnisse mit eigenen Zugriffsrechten unabhängig vom Code-Repository ist eine gängige Methode, dies zu trennen. Ob und wie Sie dies umsetzen, ist eine technische Entscheidung; für das Dossier relevant ist vor allem, ob Sie erklären können, warum der gewählte Ansatz angemessen ist für den Umfang und die Risiken dessen, was Sie entwickeln.
Was Sie dokumentieren, nicht nur was Sie einrichten
Die technische Einrichtung von Zugriffsrechten ist das eine; deren Nachweisbarkeit ist das andere, und dieses zweite wird in der Praxis häufiger vergessen. Eine Liste, wer auf welches System zugreifen darf, wann dieser Zugriff gewährt wurde und auf welcher Grundlage, ist genau das Beweismittel, nach dem eine Frageliste oder eine Aufsichtsbehörde fragt. Ohne diese Liste müssen Sie die Antwort bei jeder Frage erneut ermitteln; mit einem lebenden Register neben jeder Maßnahme liegt die Antwort bereits vor. die Erläuterung pro Maßnahme durchgehen vermittelt einen Eindruck davon, wie die Zugriffskontrolle zu den anderen neun Maßnahmen der Sorgfaltspflicht in Beziehung steht.
Ob Ihre Organisation selbst der Sorgfaltspflicht unterliegt oder ob Sie diese Frage erhalten, weil ein Auftraggeber das tut, lässt sich mit einigen wenigen Fragen bestimmen. Für diejenigen, die sich fragen, wie streng die Anforderungen an die Zugriffskontrolle genau sind, wenn ein Kunde verlangt, nachzuweisen, was geregelt ist, bietet die Erläuterung zu Datenschutz und Sicherheit einen breiteren Überblick darüber, woher diese Art von Anforderungen stammt.
Für die eigene Situation, beispielsweise ob eine bestimmte Ausgestaltung Ihrer Entwicklungspipeline ausreichend ist für die Sorgfaltspflicht, die auf Ihnen oder Ihrem Auftraggeber liegt, sind ein Jurist oder die zuständige Aufsichtsbehörde der richtige Ansprechpartner; secria.eu bereitet die Dokumentation vor, aber spricht sich nicht zu individueller Compliance aus.
Möchten Sie sehen, wie die Zugriffskontrolle in den Rest Ihres Dossiers passt, oder haben Sie noch Fragen dazu, was genau mit dieser Maßnahme gemeint ist? die häufig gestellten Fragen lesen beantwortet bereits viele dieser Punkte kurz, und der kostenlose Quick-Check zeigt in wenigen Minuten, wo Ihre Organisation bei diesem Thema steht.