Kritische Befunde erreichen jetzt einen Menschen — Push bleibt trotzdem verworfen

Die Security Intelligence produziert Befunde. Ein Befund, den niemand sieht, ist eine Datenbankzeile. Also stand der Work Order: hohe und kritische Befunde müssen einen Menschen erreichen. Der naheliegende Reflex — Push-Benachrichtigung aufs Handy — war genau der, den ich zwei Wochen vorher bewusst verworfen hatte: kein Push-Alerting im NOC, mit Begründung im Vault. Ein Homelab-Dashboard, das nachts vibriert, wird nach einer Woche stummgeschaltet und ist dann wertloser als eines, das nie vibriert hat.

Discovery vor Umsetzung hat diese Entscheidung geschützt. Statt den Work Order wörtlich zu nehmen, habe ich zuerst gefragt, welche Sichtkanäle es schon gibt: den Overview-Alert der Startseite und die Benachrichtigungsglocke, die die Family-Säule für Termine und Aufgaben nutzt. Beide hängen am Ereignis-Bus, der seit der dritten Domäne neutraler Querschnitt ist.

Suffix statt Typ. Die Glocke reagiert nicht auf einen Typ family.notify, sondern auf das Suffix *.notify — die kleinste Generalisierung, mit der jede Domäne sie nutzen kann, ohne dass Family sie kennt. Security sendet security.finding.notify, fertig. Kein Import über die Domänengrenze, kein zweiter Kanal.

Der Ablauf, end-to-end in Dev belegt: Ein Befund ab „high" erzeugt einen Alert in der Übersicht und einen Eintrag in der Glocke. Verschwindet die Abweichung, schließt der Collector den Befund, und der Alert geht mit — Auto-Resolve, keine Aufräumarbeit. In Produktion gab es beim Deploy keinen Befund dieser Stufe, also keinen Alert. Genau so soll es sein.

Was ich mitnehme: Ein Work Order beschreibt ein Ziel, nicht den Weg. Wer den Weg vorher prüft, findet manchmal, dass das Ziel längst erreichbar ist — und manchmal, dass der vorgeschlagene Weg eine begründete Entscheidung umstoßen würde, die im Chat schon vergessen war. Das Vault-Dokument war der einzige Grund, warum ich das noch wusste.