Dein Blog zum Thema digitales Business

Ein Kundenvertrag verlangt Aufbewahrung von Zugriffsnachweisen für drei Jahre. Eine Zertifizierung verlangt fünf. Eine behördliche Vorgabe verlangt zehn. GitHub selbst hält sich an keine dieser Fristen. Exportierst du nicht rechtzeitig, hast du nach Ablauf von GitHubs eigenem Limit eine Lücke in der Nachweiskette, unabhängig davon, was dein Vertrag vorschreibt.

Was GitHub tatsächlich vorhält

Bei GitHub Enterprise Cloud listet das Audit Log Ereignisse aus den letzten 180 Tagen, Git-Ereignisse werden nur sieben Tage vorgehalten. Das ist eine feste Grenze, die sich für Enterprise Cloud nicht verlängern lässt. Bei GitHub Enterprise Server, der selbst gehosteten Variante, sieht es anders aus. Dort legt eine Enterprise-Owner-Person die Aufbewahrungsdauer selbst fest, und alles, was über diese Frist hinausgeht, wird dauerhaft von der Festplatte entfernt. Konfigurierbar heißt hier also nicht länger, sondern nur einstellbar. Die Löschung nach Ablauf der Frist bleibt in beiden Fällen die Regel, nicht die Ausnahme.

Der Unterschied zwischen 180 Tagen und einer Vertragsfrist von drei, fünf oder zehn Jahren ist keine Kleinigkeit. Planst du den Export erst, wenn ein Prüfer danach fragt, hast du für alles, was älter als 180 Tage ist, keine Quelle mehr.

Der Export als Pflichtprogramm, nicht als Kür

GitHub bietet dafür Audit Log Streaming an, einen laufenden Export in ein externes System, darunter Amazon S3, Azure Blob Storage, Azure Event Hubs, Google Cloud Storage, Splunk oder Datadog. Extern gespeicherte Daten kannst du so lange aufbewahren, wie es deine eigene Aufbewahrungspflicht verlangt. GitHubs 180-Tage-Grenze spielt dann keine Rolle mehr.

Ein Detail dabei wird leicht übersehen. Ein Stream exportiert Ereignisse ab dem Zeitpunkt, an dem er eingerichtet wird, nicht rückwirkend. Aktivierst du ihn erst, wenn die Vertragsfrist schon zur Debatte steht, hast du die Lücke der letzten Monate nicht geschlossen, sondern nur die nächste offen gehalten. Der richtige Zeitpunkt für die Einrichtung ist der Vertragsschluss, nicht die erste Nachfrage eines Prüfers.

Wer im Archiv was darf

Zugriff auf das Audit Log selbst ist ebenfalls kein Nebenschauplatz. Enterprise-Owner können das Log durchsuchen und exportieren. Läuft ein eingerichteter Stream fehlerhaft, geht die Warnung automatisch an genau diese Rolle, nicht an eine beliebige Administrationsperson. Willst du zusätzliche Personen mit Leserechten ausstatten, ohne ihnen Konfigurationszugriff zu geben, kannst du das über benutzerdefinierte Rollen tun. GitHub erlaubt es ausdrücklich, ein Team so einzurichten, dass es das Audit Log einsehen kann, ohne Einstellungen ändern zu dürfen.

Das ist die Stelle, an der Aufbewahrung und Zugriff zusammenhängen. Ein Archiv, das lange genug aufbewahrt, aber jeder Person mit Repo-Zugriff auch Lösch- oder Konfigurationsrechte einräumt, ist am Ende so wertlos wie ein Archiv, das nach 180 Tagen automatisch leerläuft. Beide Fälle bedeuten dasselbe. Der Nachweis, den dein Vertrag verlangt, existiert im Ernstfall nicht mehr.

Drei Fragen vor Vertragsabschluss

Drei Fragen kannst du vorab klären, statt sie im Ernstfall zu improvisieren. Wie lange muss dieser Vertrag oder diese Vorgabe Nachweise vorhalten, in Jahren, nicht in Tagen. Reicht GitHubs eigene Frist dafür aus, oder muss vor Vertragsbeginn ein Export eingerichtet sein. Und wer bekommt Zugriff auf das exportierte Archiv, mit welchem Recht, lesen, exportieren oder löschen.

Dass ein Ereignis überhaupt im Log steht, sagt noch nichts darüber, ob es im Ernstfall als Beweis taugt oder nur eine von vielen Betriebsangaben ist. Die konzeptionelle Unterscheidung dazu steht in einem eigenen Beitrag zu Monitoring und Auditierbarkeit. Hier geht es nur um die Frist und darum, wer am Ende noch dran darf.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de