Wie kann ich das Change Management aus GitHub für SOC 2 oder ISO 27001 nachweisen?
das heygrc team
Im Wesentlichen ja, wenn die Einstellungen korrekt sind. Ein Pull-Request-Workflow zeichnet bereits auf, was geändert wurde (der Diff), wer es überprüft und genehmigt hat, was vor dem Merge ausgeführt wurde (die Checks) und wann der Merge stattfand (der Merge-Commit). SOC 2 CC8.1 und ISO 27001 A.8.32 verlangen, dass Änderungen autorisiert, getestet, genehmigt und nachverfolgbar sind. Ein gut verwaltetes Repository liefert den Großteil dieser Nachweise ohne zusätzliche Tools. Was es nicht automatisch liefert, ist der Nachweis der Durchsetzung (Beweis, dass Genehmigungen nicht umgangen werden können) und die Zuordnung jeder Änderung zu der betroffenen Kontrolle. Diese Punkte müssen Sie ergänzen.
Lassen Sie Branch Protection die Autorisierungsseite abdecken
Change Management umfasst zwei Fragen: Wurde jede Änderung autorisiert und können Sie dies nachweisen? Der Pull Request zeigt den Einzelfall, Branch Protection die Regel. Erfordern Sie Pull Requests mit mindestens einer Genehmigung (zwei, wo die Trennung der Aufgaben wichtig ist), erfordern Sie die Checks, denen Sie vertrauen, und erfordern Sie die Überprüfung durch Code-Owner für die relevanten Pfade. Ein Prüfer, der CC8.1 oder A.8.32 stichprobenartig prüft, fragt, wie Sie wissen, dass eine nicht überprüfte Änderung nicht in den main-Branch gelangen kann: Die Protection-Einstellungen zeigen die aktuelle Regel, jede Genehmigung ist ein Beleg dafür, dass die Regel eingehalten wurde, und falls sich die Regel innerhalb des Prüfzeitraums geändert hat, zeigt das Repository-Audit-Log (Regelsatz- und Protection-Änderungen), wann dies geschah.
Gestalten Sie jeden Pull Request als Änderungsprotokoll
Der PR-Body erklärt das Warum, der Diff das Was, die Check-Läufe zeigen, dass getestet wurde, die Genehmigung, dass eine zweite Person sie akzeptiert hat, und der Merge-Commit, wann die Änderung gemergt wurde. Wann die Änderung tatsächlich bereitgestellt wurde, ist ein Bereitstellungsnachweis (ein Release, eine Umgebung, ein Deploy-Lauf), den das Change Management als eigenen Schritt behandelt, nicht als etwas, das der Merge nachweist. Halten Sie Pull Requests klein genug, damit eine Überprüfung eine echte Überprüfung ist, verlinken Sie das Ticket oder Issue für den geschäftlichen Grund und pushen Sie nicht direkt in den geschützten Branch, selbst wenn es möglich ist, da dies der Weg ist, die von allen anderen geforderte Überprüfung zu umgehen. Eine saubere Historie ist keine Eitelkeit: Sie ist die Grundgesamtheit, aus der ein Prüfer Stichproben zieht.
Wissen, was GitHub nicht nachweist
Drei Lücken. Force-Push kann die Historie auf nicht geschützten Refs überschreiben, und Admins können einige Schutzmaßnahmen umgehen, sodass die Durchsetzungsgeschichte Grenzen hat. Geben Sie diese ehrlich an, statt zu übertreiben. Auch die Aufbewahrung hat Grenzen: Löschen Sie das Repository, und die Pull-Request-Aufzeichnungen gehen damit verloren. Die eigenen Logs von GitHub (Organisations-Audit-Log, Actions-Logs) laufen nach einem begrenzten, planabhängigen Zeitraum ab. Exportieren Sie daher, was Ihr Prüfzeitraum benötigt, bevor dies geschieht. Und nichts im Pull-Request-Protokoll selbst ordnet eine Änderung dem Framework zu: CC8.1 beschriftet keinen Diff, und A.8.32 kommentiert keinen Pull Request. Diese Zuordnung ist das, was eine pro-PR-Compliance-Überprüfung hinzufügt (heygrc postet Befunde, die die Klausel benennen), und baut so die Spur von der Kontrolle zur Änderung an demselben Ort auf, an dem die Änderung bereits existiert.
# Standard-Reviewer für das gesamte Repository* @acme/devs+ /security/ @acme/securityMit Branch Protection, das eine Überprüfung durch Code-Owner erfordert, werden Änderungen unter security/ an das Security-Team zur Genehmigung weitergeleitet. Schützen Sie die CODEOWNERS-Datei selbst auf dieselbe Weise, sonst kann die Regel in einem normalen Pull Request abgeschwächt werden. Autorisierung für die riskanten Pfade, in einer Datei, die ein Prüfer lesen kann.
Verwandt