Warum die Aufzeichnung von Genehmigungen und Nachweisen wichtiger ist als ein einfaches „Ja“

Sie haben gerade spätabends die mündliche Genehmigung Ihres Vorgesetzten erhalten, um eine Datenbankänderung auszurollen. Er sagte „los geht's“, Sie führten das Deployment durch, und alles schien in Ordnung. Eine Woche später tritt ein Fehler auf. Im Post-Mortem sagen Sie, Ihr Vorgesetzter habe es genehmigt. Ihr Vorgesetzter sagt, er könne sich an keine derartige Genehmigung erinnern. Jetzt haben Sie zwei Probleme: das technische Problem, das den Ausfall verursacht hat, und einen Streit darüber, wer die Änderung autorisiert hat.

Dieses Szenario spielt sich häufiger ab, als die meisten Teams zugeben. Die Genehmigung erfolgte, aber es gibt keine Aufzeichnung davon. Keinen Nachweis, wer „Ja“ gesagt hat, wann er es gesagt hat oder was er vor der Zustimmung gesehen hat. Ohne diese Aufzeichnung hat die Genehmigung praktisch nie existiert.

Was ein ordentlicher Genehmigungsdatensatz erfassen sollte

Ein ordentlicher Genehmigungsdatensatz beantwortet drei Fragen. Fehlt eine davon, hat Ihr Audit-Trail ein Loch, das später echte Probleme verursachen kann.

So könnte ein vollständiger Genehmigungsdatensatz in einem Pipeline-Audit-Log aussehen:

{
  "change_id": "DEPLOY-2024-11-05-142",
  "approver": {
    "name": "alice.chen",
    "role": "engineering_manager"
  },
  "timestamp": "2024-11-05T14:30:00Z",
  "evidence": [
    {
      "type": "test_results",
      "url": "https://ci.internal/pipeline/1234/test-report"
    },
    {
      "type": "security_scan",
      "summary": "0 critical, 2 high, 5 medium findings - all waived per policy"
    },
    {
      "type": "change_request",
      "url": "https://tickets.internal/CR-7890"
    }
  ]
}

Wer hat genehmigt

Die Pipeline muss die Identität der Person protokollieren, die die Genehmigung erteilt hat. Nicht nur einen Namen, sondern auch ihre Rolle im Team. War es der Tech Lead, der Engineering Manager oder ein DBA? Die Rolle ist wichtig, denn sie sagt Ihnen, ob diese Person überhaupt die Befugnis hatte, diese Art von Änderung zu genehmigen.

Noch wichtiger ist, dass das System überprüfen muss, ob die Genehmigung tatsächlich von dieser Person stammt und nicht von jemand anderem, der ihr Konto verwendet. Aus diesem Grund sollten Genehmigungsworkflows über Systeme laufen, die in die Authentifizierung Ihres Teams integriert sind, und nicht über Chat-Nachrichten oder E-Mails, die leicht gefälscht oder weitergeleitet werden können. Wenn jemand eine „genehmigt“-Nachricht aus einem Slack-Thread kopieren und einfügen kann, haben Sie kein Genehmigungssystem. Sie haben ein Screenshot-Spiel.

Wann wurde genehmigt

Der Zeitstempel muss Minuten und Zeitzone enthalten. Das mag nach Übertreibung klingen, bis Sie bei einer Incident-Untersuchung die Reihenfolge der Ereignisse rekonstruieren müssen.

Betrachten Sie diesen Zeitablauf:

• Änderung eingereicht um 14:00 Uhr
• Genehmigung erteilt um 14:30 Uhr
• Deployment in Produktion um 14:45 Uhr
• Incident erkannt um 15:10 Uhr

Mit sauberen Zeitstempeln können Sie genau sehen, wie sich die Dinge entwickelt haben. Ohne sie müssen Sie raten, ob die Genehmigung vor oder nach dem Deployment erfolgte. Eine Genehmigung, die nach dem Deployment erfolgt, ist überhaupt keine Genehmigung. Es ist eine Benachrichtigung, die als Governance verkleidet ist.

Auf welcher Grundlage wurde genehmigt

Dies ist der Punkt, den die meisten Teams vergessen. Jemand hat eine Änderung genehmigt, aber was hat er tatsächlich gesehen, bevor er auf „Genehmigen“ geklickt hat? Hat er die Testergebnisse überprüft? Das Changelog gelesen? Geprüft, ob die Änderung andere Systeme betrifft? Oder hat er einfach darauf vertraut, dass alles in Ordnung ist?

Die Pipeline sollte die Nachweise erfassen, die der Entscheidung zugrunde lagen. Dies könnten sein:

• Ein Link zum Pipeline-Lauf, der zeigt, dass alle Gates bestanden wurden
• Ein Screenshot der Sicherheitsscan-Ergebnisse
• Das geprüfte Change-Request-Dokument
• Eine Zusammenfassung dessen, was geprüft und bestätigt wurde

Wenn Sie diese Nachweise erfassen, hört die Genehmigung auf, ein reiner Gummistempel zu sein, und wird zu einer überprüfbaren Entscheidung. Jeder kann später zurückblicken und genau sehen, was zum Zeitpunkt der Genehmigung bekannt war, nicht nur, dass jemand „Ja“ gesagt hat.

Aufbau des Audit-Trails

Diese drei Informationen zusammen bilden Ihren Audit-Trail. Ein Audit-Trail ist die vollständige Aufzeichnung dessen, was mit einer Änderung von Anfang bis Ende passiert ist: wer sie vorgenommen hat, wer sie überprüft hat, welche Gates sie passiert hat, wer sie genehmigt hat, wann sie deployed wurde und ob das Deployment erfolgreich war oder fehlschlug.

Ein vollständiger Audit-Trail dient zwei Zwecken. Erstens erfüllt er Compliance-Anforderungen. Unabhängig davon, ob Ihr Unternehmen interne Richtlinien oder externe Vorschriften befolgen muss, ist eine klare Aufzeichnung jeder Änderung und ihres Autorisierers oft obligatorisch.

Zweitens, und praktisch gesehen, macht er Incident-Untersuchungen schneller und weniger stressig. Wenn etwas schiefgeht, müssen Sie nicht Leute ausfindig machen und fragen „Wer hat das gemacht?“ oder „Warum wurde das durchgelassen?“ Die Antworten sind bereits aufgezeichnet. Sie können sich darauf konzentrieren, das Problem zu beheben, anstatt zu rekonstruieren, was passiert ist.

Umsetzung in der Praxis

Die meisten modernen CI/CD-Tools erfassen bereits einige dieser Informationen. GitLab CI/CD, GitHub Actions und Jenkins mit den richtigen Plugins können protokollieren, wer eine Änderung genehmigt hat und wann. Aber der Nachweisteil erfordert normalerweise manuellen Aufwand von der genehmigenden Person.

Die Lösung ist einfach, erfordert aber Disziplin: Machen Sie es zur Gewohnheit, dass der Genehmiger vor der Genehmigung einen Kommentar mit einem Link oder einer Zusammenfassung dessen hinzufügt, was er überprüft hat. Ohne diese Gewohnheit sagen Ihre Genehmigungsaufzeichnungen nur „genehmigt“ ohne Kontext. Das ist kaum besser, als gar keine Aufzeichnung zu haben.

Einige Teams gehen noch weiter, indem sie die Nachweiserfassung direkt in die Pipeline integrieren. Der Genehmigungsschritt kann eine Zusammenfassung der Testergebnisse, Sicherheitsscan-Ergebnisse und Änderungsdetails direkt in der Genehmigungsoberfläche anzeigen. Der Genehmiger sieht alles, was er braucht, ohne die Pipeline verlassen zu müssen, und das System protokolliert, was angezeigt wurde. Dies macht manuelle Kommentare überflüssig und automatisiert die Nachweiserfassung.

Eine kurze Checkliste für Ihre Genehmigungsaufzeichnungen

Wenn Sie Ihren Genehmigungsprozess einrichten oder überprüfen, gehen Sie diese Punkte durch:

• Protokolliert die Pipeline die Identität und Rolle des Genehmigers?
• Ist der Zeitstempel präzise genug, um Ereignisabläufe zu rekonstruieren?
• Werden die Nachweise, die der Genehmigung zugrunde lagen, automatisch oder manuell erfasst?
• Kann jemand, der den Audit-Trail sechs Monate später überprüft, verstehen, warum diese Änderung genehmigt wurde?
• Ist das Genehmigungssystem in die Authentifizierung Ihres Teams integriert, nicht nur eine Chat-Nachricht?

Das Fazit

Eine Genehmigung ohne Aufzeichnung ist keine Genehmigung. Es ist ein Gespräch, an das sich alle Beteiligten möglicherweise unterschiedlich erinnern. Wenn Sie erfassen, wer genehmigt hat, wann genehmigt wurde und welche Nachweise vorlagen, verwandeln Sie ein lockeres „okay, los geht's“ in eine Entscheidung, die überprüft, auditiert und verteidigt werden kann. Das ist der Unterschied zwischen einem Prozess, der so aussieht, als hätte er Kontrollen, und einem, der sie tatsächlich hat.