Change Management in GitHub als Nachweis für ISO/IEC 27001 und SOC 2 vorlegen

Wenn ein Entwicklungsteam ein Audit nach ISO/IEC 27001 (in Japan als ISMS-Zertifizierung bekannt) oder SOC 2 durchläuft, wird fast sicher nach dem Change Management gefragt. Der gesamte Code liegt in GitHub, Reviews finden statt – und trotzdem stockt es oft bei der Frage, was man eigentlich wie vorzeigen soll.

Dieser Artikel klärt zuerst, was Prüfer beim Change Management bestätigen wollen, und erklärt dann der Reihe nach, welche Einstellungen Sie in GitHub vornehmen sollten und wie Sie Nachweise aufbewahren.

Was Prüfer beim Change Management bestätigen wollen

Die einschlägigen Stellen in den Rahmenwerken:

Keines der beiden schreibt vor, wie GitHub zu konfigurieren ist. Gefragt wird, ob Sie anhand von Aufzeichnungen belegen können, dass Änderungen nach dem festgelegten Verfahren durchgeführt wurden.

In der Praxis läuft die Prüfung meist so ab:

1. Sie legen eine Liste aller Änderungen vor, die im Beobachtungszeitraum in Produktion gingen
2. Aus dieser Liste werden einige Änderungen als Stichprobe gezogen
3. Für jede Stichprobe wird geprüft, ob eine andere Person als der Autor die Änderung genehmigt hat, bevor sie in Produktion ging
4. Bei Notfalländerungen wird geprüft, ob nachträgliche Genehmigungen und Aufzeichnungen vorhanden sind

Sie brauchen also beides: eine Änderungsliste über den gesamten Zeitraum und für jede Änderung den Genehmigungsnachweis. Fehlt eines davon, wird die Erklärung schwierig.

Einstellungen, die Sie in GitHub vornehmen sollten

Vor den Nachweisen steht das Verfahren selbst, das Sie über GitHub-Einstellungen erzwingen. Wenn die Regeln nicht nur in einem Dokument stehen, sondern technisch nicht umgangen werden können, wird die Erklärung im Audit deutlich kürzer.

Für den Branch, der in Produktion geht (etwa main), konfigurieren Sie per Branch-Schutz oder Ruleset Folgendes:

• Pull Request vor dem Merge verpflichtend machen: schließt den Weg, Produktionscode per direktem Push zu ändern
• Mindestens eine Genehmigung verlangen: ohne Genehmigung einer anderen Person als des Autors ist kein Merge möglich
• Genehmigungen bei neuen Pushes zurücksetzen: verhindert, dass nach der Genehmigung unbemerkt Änderungen nachgeschoben werden
• Keine Ausnahme für Administratoren: können Administratoren den Schutz umgehen, lässt sich nicht mehr sagen, dass alle Änderungen genehmigt wurden
• Erzwungenes Umschreiben der Historie (Force Push) und das Löschen des Branches verbieten

Halten Sie außerdem in Ihrer Verfahrensanweisung zum Change Management fest, welcher Branch der Produktions-Branch ist und wer bei Notfällen wie genehmigt und was nachträglich dokumentiert wird. Auch dass Einstellungen und Verfahrensanweisung übereinstimmen, wird im Audit betrachtet.

Warum Screenshots nicht ausreichen

Ein verbreiteter Weg ist, Screenshots von Pull Requests oder den Branch-Schutz-Einstellungen zu machen und in Unterlagen einzufügen. Das hat strukturelle Schwächen:

• Es zeigt nur einen Zeitpunkt. Ein Screenshot der Einstellungen belegt nur, dass sie im Moment der Aufnahme so waren. Wurde der Schutz mitten im Beobachtungszeitraum einmal deaktiviert und wieder aktiviert, ist das nicht zu sehen
• Datum und Herkunft sind schwer überprüfbar. Das Datum im Bild ist Teil des Bildes; Dritte haben keine Möglichkeit zu prüfen, wann und woher es stammt
• Das Sammeln kostet jedes Mal Aufwand. Für jede gezogene Stichprobe die passende Ansicht zu suchen und abzufotografieren, wiederholt sich bei jedem Audit

Auch auf Prüferseite geht der Trend weg von solchen manuellen Nachweisen hin zu Aufzeichnungen, die automatisch mit Zeitstempel versehen und nachverfolgbar sind.

So entsteht ein Nachweis über den gesamten Zeitraum

Es kommt auf zwei Punkte an.

1. Aufzeichnen, wenn die Änderung passiert. Statt kurz vor dem Audit zu sammeln, wird in dem Moment, in dem ein Push oder der Merge eines Pull Requests stattfindet, festgehalten, wann wer was getan hat. Wer erst nachträglich sammelt, erfasst nicht, was in der Zwischenzeit verschwunden ist oder sich verändert hat.

2. In einer Form aufbewahren, die die geprüfte Organisation nachträglich nicht umschreiben kann. Ereignisverlauf und Audit-Log von GitHub sind nützlich, liegen aber in einem System, das die geprüfte Organisation selbst verwaltet. Zudem ist die Aufbewahrungsdauer begrenzt und deckt je nach Plan einen Beobachtungszeitraum von 6 bis 12 Monaten möglicherweise nicht ab. Es lohnt sich, die Aufbewahrungsdauer Ihres Plans einmal zu prüfen.

Um zu zeigen, dass Aufzeichnungen nachträglich nicht verändert wurden, verkettet man den Fingerabdruck (Hashwert) jedes Eintrags mit dem vorherigen. Wird ein einzelner Eintrag in der Mitte geändert, passen alle folgenden Verkettungen nicht mehr – eine Manipulation wird so erkennbar.

Was SPHIOR leistet – und was nicht

Die GitHub-Integration von SPHIOR übernimmt die beiden oben genannten Punkte automatisch.

• Ereignisse wie Pushes sowie das Erstellen und Mergen von Pull Requests werden in dem Moment aufgezeichnet, in dem sie stattfinden
• Jeder Eintrag enthält die Art des Ereignisses, die ausführende Person, den Zeitpunkt und einen Fingerabdruck des gesamten von GitHub gelieferten Inhalts. Der Inhalt selbst wird nicht gespeichert
• Die Einträge werden über verkettete Fingerabdrücke versiegelt, sodass Manipulationen erkennbar sind. Sie können ein Verifizierungspaket exportieren und selbst nachprüfen

Folgendes kann SPHIOR dagegen nicht abdecken:

• Die Review-Genehmigung selbst wird derzeit nicht aufgezeichnet. Erzwingen Sie mit den oben beschriebenen Branch-Schutz-Einstellungen, dass ohne Genehmigung kein Merge möglich ist, und erläutern Sie dies anhand dieser Einstellungen und Ihrer Verfahrensanweisung
• SPHIOR beurteilt nicht das Ergebnis eines Audits. SPHIOR liefert ergänzende Nachweise, die Sie Prüfern vorlegen können

Im kostenlosen Plan werden Aufzeichnungen 90 Tage aufbewahrt. Sobald Sie Nachweise über den gesamten Beobachtungszeitraum benötigen, können Sie zu einem Plan mit längerer Aufbewahrung wechseln (Preise).

Zusammenfassung

• Beim Change Management geht es um die Änderungsliste des Zeitraums und den Genehmigungsnachweis je Änderung
• In GitHub die Genehmigung per Branch-Schutz erzwingen, ohne Ausnahme für Administratoren
• Screenshots zeigen nur einen Zeitpunkt. Verlässlich ist, Ereignisse beim Eintreten in nicht umschreibbarer Form aufzuzeichnen

Damit Sie nicht kurz vor dem Audit hektisch Bildschirme abfotografieren müssen, beginnen Sie mit der Aufzeichnung am besten lange vor dem Audit.