Wer schon einmal ein ISO-27001- oder NIS-2-Audit erlebt hat, kennt zwei wiederkehrende Befund-Klassen: „Trennung von Verantwortlichkeiten nicht nachweisbar" und „Beweissicherung im Vorfallsfall nicht systematisch geregelt". Beides lässt sich technisch elegant lösen – mit einem 4-Augen-Approval-Flow für sicherheitskritische Mail-Releases und einem unveränderbaren Forensik-Archiv.
4-Augen-Approval: was es technisch bedeutet
Eine quarantänierte Mail enthält etwa eine Sandbox-Threat-Detection oder einen DLP-Treffer. Statt dass ein Admin „Release" klickt und die Mail rausgeht, läuft der Prozess so:
- Operator A öffnet die Quarantäne, prüft den Verdict und beantragt einen Release.
- Operator B (anderer User, anderes Konto) bekommt einen Approval-Eintrag in seine Queue.
- B prüft unabhängig, sieht denselben Verdict, dieselben Anhänge, dieselben CTI-Hits – und genehmigt oder lehnt ab.
- Erst nach Approval ist der Release möglich; ohne Approval gibt der Gateway einen 403 zurück.
Welche Verdikte ein 4-Augen-Approval erzwingen, ist konfigurierbar (Default: virus, sandbox_threat, policy_violation). Approvals laufen ab – Default 24 Stunden – damit „alte" Approvals nicht für spätere, unabhängige Releases recycelt werden.
Was das im Audit bringt
- ISO 27001 A.6.1.2: Trennung von Verantwortlichkeiten – technisch erzwungen, statt per Policy nur dokumentiert.
- NIS-2 Art. 21 (2)(d): Maßnahmen zur Sicherheit der Lieferkette und Geschäftskontinuität – Release-Approvals sind ein protokollierter Kontrollpunkt.
- BSI IT-Grundschutz ORP.1.A14: Doppelkontrolle bei sicherheitskritischen Aktionen – aus dem Bauch entschieden vs. nachweisbar dokumentiert.
Forensik-Archiv: WORM mit Object-Lock
Quarantäne ist kurzlebig: Mails verschwinden nach 30–90 Tagen. Was bleibt für eine Forensik nach 12 Monaten? Antwort: ein Forensik-Archiv mit echten Compliance-Eigenschaften:
- S3-kompatibel mit Object-Lock COMPLIANCE-Modus: Einmal geschrieben, kann nichts und niemand das Objekt vor Ablauf der Aufbewahrungsfrist löschen – nicht einmal der Root-User des Storage-Accounts.
- DB-Index parallel zum Blob-Storage: sucht nach Sender, Empfänger, Subject, Connection-ID, Verdict – ohne den Blob zu deserialisieren.
- Pre-signed URLs für Download: ein Auditor bekommt einen 60-Minuten-Link, der nach Ablauf nutzlos ist.
- Default-Retention: 365 Tage, konfigurierbar pro Verdict-Klasse (Phishing-Verdacht: 6 Monate; Virus: 24 Monate).
Zusammenspiel mit dem Audit-Log
Beide Bausteine speisen in dieselbe audit_log-Tabelle. Wer hat welche Quarantäne-Mail wann gelesen? Wer hat welche Release-Approval angefragt, wer freigegeben? Wer hat welche Mail aus dem Archiv heruntergeladen? Alles lückenlos, alles abfragbar im UI – und wenn nötig per CSV-Export an den Wirtschaftsprüfer übergebbar.
Warum man das nicht „mal eben selbst baut"
Die Versuchung ist groß: ein paar SQL-Tabellen, ein Trello-Board für Approvals, ein S3-Bucket mit Lifecycle-Policy. In der Praxis scheitert das an Race-Conditions (zwei Approver gleichzeitig), an stiller Daten-Mutation (S3 ohne Object-Lock erlaubt Überschreiben) und an fehlender UI-Integration mit dem Quarantäne-Workflow. Eine integrierte Lösung wie SecTepe.Comm spart die 200 Personen-Stunden, die das Eigenbau-Projekt am Ende erfordert.
Fazit
4-Augen-Prinzip und revisionssicheres Forensik-Archiv sind die zwei Bausteine, die in fast jedem Audit-Bericht als Verbesserungspotenzial auftauchen. Sie technisch sauber und benutzbar zu lösen ist möglich – wenn sie als Teil der Mail-Security-Plattform geplant sind, nicht als nachträgliches Bolt-on. Der Aufwand für die Aktivierung in SecTepe.Comm: zwei Klicks und eine Storage-Backend-Konfiguration. Der Auditor bedankt sich.