Dein Blog zum Thema digitales Business

Wenn ein Sicherheitsvorfall aufschlägt, will jeder das Gleiche wissen: Was ist passiert, was war betroffen, und ist der Zustand wieder sauber. In den ersten Stunden greifen viele Teams reflexartig zu den Logs. Das ist richtig, reicht aber nicht. Denn Logs beantworten nur die erste Frage. Die zweite und dritte Frage brauchen etwas anderes: Nachweise.

Logs zeigen, was passiert ist. Nachweise zeigen, was gegolten hat

Ein Log ist eine Aufzeichnung von Ereignissen. Ein Zugriff, ein Deployment, ein fehlgeschlagener Login. Es sagt dir, dass etwas geschehen ist, und meistens wann. Ein Nachweis ist etwas anderes. Er belegt, dass eine Kontrolle zum fraglichen Zeitpunkt tatsächlich gegriffen hat. Dass dieser Build von diesem Commit stammt. Dass diese Freigabe von einer zweiten Person kam. Dass genau dieses Artefakt in Produktion lief und kein anderes.

Der Unterschied klingt akademisch, bis der Ernstfall da ist. Dann ist er entscheidend. Ein Log-Eintrag „Deployment um 14:03“ hilft dir wenig, wenn du nicht belegen kannst, welche Version deployt wurde und ob sie den vorgesehenen Freigabeweg genommen hat.

Warum Logs allein im Ernstfall nicht tragen

Logs haben drei Schwächen, die genau im Incident auffliegen. Erstens sind sie oft veränderbar. Wer Schreibrechte auf das System hat, kann sie im Zweifel auch anpassen oder löschen. Zweitens sind sie lückenhaft. Retention-Fristen von 7 oder 30 Tagen sind normal, und der Zeitpunkt, den du untersuchst, liegt gern davor. Drittens sind sie nicht verknüpft. Ein Log aus der Pipeline, eins aus der Cloud, eins aus dem Repo, aber nichts, das sie zu einer belastbaren Kette zusammenfügt.

Ein Nachweis dreht diese Schwächen um. Er ist signiert, also nicht unbemerkt veränderbar. Er wird zum Zeitpunkt des Ereignisses erzeugt und mit dem Artefakt aufbewahrt, nicht in einem separaten System mit eigener Löschfrist. Und er referenziert die anderen Teile: Commit, Build, Freigabe, Artefakt gehören zusammen.

Woran man einen Nachweis erkennt

Ein brauchbarer Nachweis erfüllt drei Bedingungen. Er ist zum Zeitpunkt der Handlung entstanden, nicht nachträglich rekonstruiert. Er ist an das konkrete Objekt gebunden, etwa über einen Hash des Artefakts. Und er ist gegen Manipulation geschützt, meist durch eine Signatur. Ein Screenshot einer Pipeline-Ansicht ist kein Nachweis. Eine signierte Attestation, die den Build mit seinem Quellstand und seiner Freigabe verbindet, ist einer.

Was ein kleines Team vorhalten sollte

Man muss nicht alles auf einmal aufbauen. Für den Anfang reichen vier Dinge, die im Incident den Unterschied machen:

• Eine Verbindung zwischen Artefakt und Commit, sodass jederzeit klar ist, aus welchem Quellstand ein Deployment stammt.
• Ein Nachweis der Freigabe, der festhält, wer ein Deployment autorisiert hat und dass es nicht die eigene Person war.
• Signierte Build-Ausgaben, damit ein untergeschobenes Artefakt auffällt.
• Eine Aufbewahrung dieser Nachweise, die länger reicht als die Log-Retention und die nicht am selben Ort liegt wie das produktive System.

Das ist kein Werkzeugkauf, sondern eine Frage der Bauweise. Wer die Pipeline so einrichtet, dass diese Nachweise nebenbei entstehen, hat sie im Ernstfall, ohne sie mühsam zusammensuchen zu müssen.

Der Unterschied zahlt sich vor dem Incident aus

Der beste Zeitpunkt, Nachweise einzurichten, ist nicht während des Vorfalls. Im Incident hast du keine Zeit, eine Kette zu rekonstruieren, die nie existiert hat. Dieselben Nachweise, die dir in der Krise die Analyse abkürzen, beantworten im Alltag auch die Fragen von Kunden und Prüfern. Sie sind kein reiner Notfall-Aufwand, sondern die belastbare Version dessen, was Logs nur andeuten.

---

Wollen Sie wissen, ob Ihre Pipeline im Ernstfall Nachweise liefert oder nur Logs? Der GitSecOps QuickCheck prüft Ihre Build- und Deployment-Kette in 3 Werktagen auf genau diese Lücken. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.