Viele Teams glauben, wer gutes Monitoring hat, ist damit auch auditierbar. Das stimmt nicht. Beide Ziele klingen ähnlich, weil beide mit Aufzeichnung zu tun haben. Sie beantworten aber verschiedene Fragen, und die Werkzeuge dafür sind unterschiedlich gebaut.

Was Monitoring beantwortet

Monitoring beantwortet die Frage „läuft es gerade und ist es gesund?“. Es misst Zustand in Echtzeit: Fehlerraten, Latenz, Auslastung, Build-Dauer. Die Daten werden aggregiert, gemittelt und nach einigen Tagen oder Wochen verworfen, weil niemand Rohmetriken von vor drei Monaten pro Sekunde braucht. Monitoring darf lückenhaft sein. Ein verlorener Datenpunkt in einer Zeitreihe ändert das Bild kaum. Der Wert liegt im Trend, nicht im einzelnen Ereignis.

Was Auditierbarkeit beantwortet

Auditierbarkeit beantwortet eine andere Frage: „können wir später zweifelsfrei zeigen, was passiert ist, wer es ausgelöst hat und in welcher Reihenfolge?“. Hier zählt genau das einzelne Ereignis. Wer hat welche Version freigegeben, wann und auf welcher Grundlage. Das muss nachträglich rekonstruierbar sein, oft Monate später und oft von jemandem, der beim Vorgang nicht dabei war. Ein verlorenes Ereignis ist hier kein Rauschen, sondern eine Lücke im Nachweis.

Warum „wir haben doch Logs“ nicht reicht

Der häufigste Denkfehler ist, Logs seien schon der Nachweis. Logs entstehen fürs Debuggen. Sie sind veränderbar, werden rotiert und gelöscht, tragen selten eine feste Zuordnung zu Person und Artefakt und lassen sich nachträglich anpassen, ohne dass es auffällt. Für die Fehlersuche am selben Tag ist das genau richtig. Als Beweis vor einem Prüfer oder nach einem Vorfall tragen sie nicht. Ein Nachweis muss unveränderbar sein oder zumindest erkennbar machen, wenn er verändert wurde. Er muss an das konkrete Artefakt gebunden sein und eine Person oder einen Prozess benennen.

Was Auditierbarkeit technisch braucht

Drei Eigenschaften unterscheiden einen Nachweis von einem Log. Erstens Integrität: die Aufzeichnung ist signiert oder so abgelegt, dass Manipulation auffällt. Zweitens Zuordnung: jedes Ereignis hängt an einer Identität und an dem Artefakt, um das es geht, nicht an einer anonymen Zeile. Drittens Aufbewahrung: die Aufzeichnung überlebt so lange, wie sie gebraucht wird, unabhängig von der kurzen Retention der Monitoring-Systeme. Das ist bewusst anders gebaut als eine Zeitreihe.

Beides braucht man, getrennt gebaut

Die praktische Konsequenz ist einfach. Monitoring und Auditierbarkeit sind kein Widerspruch, aber auch nicht dasselbe System in zwei Ansichten. Wer sein Monitoring zum Audit-Trail umbauen will, bekommt teure, langsame Metriken. Wer seinen Audit-Trail aus Monitoring-Logs zusammensucht, bekommt einen Nachweis mit Löchern. Der saubere Weg ist, die Freigabe- und Nachweiskette dort zu erzeugen, wo die Ereignisse entstehen, in der Pipeline, und sie an das Artefakt zu binden. Monitoring bleibt für den Betrieb, der Nachweis läuft parallel und mit eigenen Regeln für Integrität und Aufbewahrung.

Wer das früh trennt, spart sich die Rekonstruktion im Ernstfall. Im Vorfall oder in der Prüfung ist keine Zeit, aus Metriken einen Nachweis zu basteln, den es nie gab.


Die MHM Digitale Lösungen UG arbeitet an der Nachweis- und Freigabekette in CI/CD-Pipelines: Freigaben, die an das konkrete Artefakt gebunden sind, und Aufzeichnungen, die einer späteren Prüfung standhalten. Wenn Sie wissen wollen, wie belastbar Ihre Pipeline im Ernstfall ist, schreiben Sie an mm@mhm-dl.de.

Hinterlasse einen Kommentar

MHM Digitale Lösungen

Wir machen Software-Lieferketten sicher. GitSecOps prüft und härtet deine Build- und Deployment-Pipeline, damit du gegenüber Kunden und Prüfern bestehst. Hier schreiben wir nüchtern über Supply Chain Security, DevSecOps und digitales Business.

Kontakt