Sicherheit ist kein Zustand. Sie ist ein Regelkreis.

Warum die Serversicherheit im Mittelstand nicht an Unwissen scheitert, sondern an Zerfall — und wie aus Inventar, Automation und Überwachung ein System wird, das sich selbst im sicheren Zustand hält.

Fragen Sie einen Geschäftsführer, ob seine Server abgesichert sind, und die Antwort lautet fast immer: ja. Man hat den Dienstleister damit beauftragt, es steht in einem Protokoll, es wurde abgenommen. Das Beunruhigende an dieser Antwort ist nicht, dass sie falsch wäre. Sie war einmal richtig. Sie beschreibt einen Zustand, den es gab — an dem Tag, an dem jemand ihn hergestellt hat.

Sicherheit ist kein Möbelstück, das man einmal aufstellt. Sie ist ein Gleichgewicht, das von selbst zerfällt. Ein Admin öffnet für einen Test schnell einen Port und vergisst, ihn zu schließen. Ein neuer Server geht in Betrieb, ein bisschen anders konfiguriert als die anderen, weil es gerade schnell gehen musste. Ein Update ändert eine Voreinstellung. Kein einzelner dieser Schritte ist ein Fehler. In Summe entsteht daraus über Monate etwas, das niemand mehr vollständig kennt: eine Flotte aus lauter Sonderfällen, deren tatsächlicher Zustand von dem, was man glaubt, langsam abdriftet.

Das ist das eigentliche Problem — nicht der Angriff, sondern die Drift. Und gegen Drift hilft kein Projekt. Ein Projekt hat ein Ende. Drift nicht.

Man kann nicht absichern, was man nicht kennt

Der erste Reflex ist meist der Ruf nach Dokumentation: eine Liste, was überhaupt läuft. Ein Inventar. Das ist richtig — aber es ist nur die halbe Bewegung, und die weniger interessante Hälfte.

Denn ein Inventar, das nur beschreibt, ist ein Museum. Es sagt Ihnen, was einmal wahr war, und veraltet in dem Moment, in dem Sie es fertigstellen. Eine gepflegte Excel-Liste der Server ist besser als nichts, aber sie hat mit der Realität denselben Vertrag wie das Abnahmeprotokoll von oben: Sie stimmt am Tag der Erstellung.

Interessant wird ein Inventar erst, wenn es aufhört, Nachschlagewerk zu sein, und anfängt, Befehlszentrale zu werden. In meinem Stack übernimmt diese Rolle GLPI — die zentrale CMDB, in der jeder Server, jede Anlage, jeder Dienst geführt wird. Der entscheidende Schritt ist nicht, dass diese Liste existiert, sondern wie sie genutzt wird: als Dynamic Inventory. Die Automation fragt vor jedem Lauf live bei GLPI an, welche Systeme es überhaupt gibt, statt sich auf eine gepflegte Datei zu verlassen, die jemand aktuell halten müsste. Die Wahrheit über die Flotte liegt an genau einer Stelle — und diese Stelle ist nicht mehr Dokumentation, sondern der Ausgangspunkt jeder Handlung.

Damit ist die Frage „Welche Server haben wir?" keine Recherche mehr. Sie ist eine Abfrage.

Beschreibung ist nicht Durchsetzung

Zu wissen, was man hat, ändert noch nichts an dessen Zustand. Hier kommt der zweite Baustein ins Spiel, und mit ihm der Denkfehler, den man vermeiden muss: Ansible als „Werkzeug zur Server-Automatisierung" zu verstehen, greift zu kurz. Automatisierung klingt nach Bequemlichkeit — schneller, weniger Handarbeit. Das stimmt, ist aber nebensächlich.

Die eigentliche Eigenschaft ist Idempotenz. Ein Playbook beschreibt nicht Schritte, die man ausführt, sondern einen Zustand, der gelten soll: root-Login per SSH deaktiviert, Passwort-Anmeldung aus, Firewall aktiv mit definiertem Regelsatz, Intrusion Prevention scharf. Man führt es aus, und der Server geht in diesen Zustand — egal, wo er vorher stand. Man führt es morgen erneut aus, und nichts passiert, weil der Zustand schon gilt. Man führt es nach einer unbemerkten Änderung aus, und die Abweichung wird stillschweigend zurückgesetzt.

Das ist keine technische Kuriosität. Das ist die Sicherheitsgarantie. Der gewünschte Zustand wird einmal deklariert und beliebig oft wieder hergestellt. Drift verliert ihre Macht, weil sie nicht mehr akkumuliert — sie wird beim nächsten Lauf eingeebnet.

Und daraus folgt der Satz, der eigentlich das ganze Prinzip trägt:

Kein Server ist ein Sonderfall.

Die Sicherheit einer Flotte liegt nicht darin, dass jeder Server irgendwie abgesichert ist, sondern darin, dass alle nach derselben Vorlage identisch sind. Wird ein neuer Server aufgesetzt, bekommt er per Bootstrapping in Minuten dieselbe Baseline wie alle anderen — key-only, gehärteter SSH-Dienst, einheitlicher Firewall- und Fail2ban-Standard. Die Homogenität ist die Sicherheit. Jede Ausnahme ist ein zukünftiges Loch.

Durchsetzung ohne Prüfung ist Glaube

Jetzt fehlt noch das entscheidende Stück, ohne das das Ganze eine elegante Illusion bliebe. Denn ein Playbook, das ich gestern ausgeführt habe, sagt mir nichts darüber, ob der Zustand heute noch gilt. Zwischen zwei Läufen kann alles passieren. Wer sich allein auf die Durchsetzung verlässt, hat den ersten Fehler nur verlagert: Statt zu glauben, die Server seien abgesichert, glaubt er, sie seien es geblieben.

Deshalb schließt sich der Kreis erst mit der Überwachung — und die hat zwei Augen, die zwei verschiedene Fragen stellen.

Das erste Auge ist Zabbix, und es fragt: Gilt der deklarierte Zustand noch? Das ist Konformität. Ist die Firewall noch aktiv, ist der root-Login noch aus, läuft der gehärtete Dienst wie vorgesehen? Zabbix ist bei mir nicht nur dafür da, zu melden, ob ein Server überhaupt läuft. Es prüft, ob der Server noch der Server ist, den Ansible hergestellt hat.

Das zweite Auge ist Wazuh, und es fragt etwas anderes: Versucht gerade jemand, den Zustand zu brechen? Das ist keine Konformitäts-, sondern eine Angriffsfrage — Log-Analyse, Rootkit-Erkennung, und vor allem File Integrity Monitoring. Und hier schließt sich ein besonders eleganter Kreis: Wazuh überwacht genau die Dateien, die Ansible durchsetzt. Die SSH-Konfiguration, die sudo-Rechte, die Firewall-Regeln. Rührt etwas außer der Reihe an diesen Dateien, meldet Wazuh das in dem Moment, in dem es geschieht — nicht erst beim nächsten Ansible-Lauf.

Der Unterschied lässt sich in einem Bild fassen:

Zabbix ist der Wächter, der in Runden prüft, ob die Tür noch abgeschlossen ist. Wazuh ist das Immunsystem, das den Einbruchsversuch selbst bemerkt, während er passiert.

Man braucht beides. Eine abgeschlossene Tür sagt nichts über den, der gerade am Schloss hantiert; und ein bemerkter Einbruchsversuch nützt wenig, wenn man nicht auch weiß, ob die Grundsicherung überhaupt noch steht.

Beide Signale enden am selben Ort: als Ticket in GLPI, verknüpft mit genau dem betroffenen Asset. Eine Abweichung ist damit kein stilles Risiko mehr, das jahrelang unentdeckt bleibt, sondern ein sichtbarer, zuständiger, behebbarer Vorgang.

Damit ist der Regelkreis vollständig:

GLPI weiß, was existiert → Ansible setzt durch, wie es sein soll → Zabbix prüft, ob es so bleibt, und Wazuh bemerkt, wenn jemand daran rüttelt → beide melden die Abweichung als Ticket zurück in GLPI, wo sie behandelt wird.

Inventar, Durchsetzung, Prüfung, Angriffserkennung, Rückkopplung. Keine dieser Komponenten ist für sich genommen bemerkenswert. Bemerkenswert ist, dass sie sich zu einer Schleife schließen, die keinen Endpunkt hat — und genau das braucht ein Problem, das selbst keinen Endpunkt hat.

Warum das kein Compliance-Thema ist

An dieser Stelle wird das Ganze gern in die falsche Schublade gelegt: als Nachweis, als Erfüllung einer Norm, als Häkchen für den nächsten Audit. Das ist nicht falsch, aber es verkauft die Sache unter Wert — und es lenkt vom eigentlichen Gewinn ab.

Der Gewinn ist zunächst operativ. Ein neuer Server ist in Minuten auf dem Sicherheitsniveau der gesamten Flotte, nicht in Tagen. Der Sicherheitsfragebogen eines Kunden lässt sich ehrlich beantworten, weil man den Zustand seiner Systeme kennt und nicht hofft. Und wenn nachts etwas driftet oder jemand am Schloss hantiert, entsteht ein Ticket, kein Vorfall.

Das ist keine Pflichtübung, die Geld kostet. Das ist Betriebsfähigkeit, die Vertrauen erzeugt — und Vertrauen ist im Mittelstand ein Verkaufsargument, kein Kostenblock. Ein Unternehmen, das auf Anhieb belegen kann, dass seine Infrastruktur in einem definierten, überwachten, sich selbst korrigierenden Zustand läuft, gewinnt Ausschreibungen, die andere verlieren, weil sie ehrlicherweise passen müssten.

Vom Zustand zum System

Der Unterschied, auf den alles hinausläuft, ist ein grammatischer. „Wir haben unsere Server abgesichert" ist Vergangenheit — ein abgeschlossenes Projekt, das ab dem nächsten Tag zu zerfallen beginnt. „Unsere Server halten sich selbst im sicheren Zustand" ist Gegenwart, und zwar dauerhafte: eine Eigenschaft des Systems, keine Aufgabe auf einer To-do-Liste.

Sicherheit ist kein Zustand, den man erreicht. Sie ist ein Gleichgewicht, das ständig zerfällt — und das man deshalb ständig neu herstellen muss.

Die Frage ist nur, ob ein Mensch das tut, der irgendwann müde wird und Dinge übersieht, oder ein Regelkreis, der nicht müde wird und nichts vergisst.

Nur: Dieser Regelkreis produziert Fakten, die Maschinen verstehen. Tickets, Prüfergebnisse, Abweichungen. Die Geschäftsführung sieht davon nichts — und für sie ist die entscheidende Frage nicht, ob ein Dienst gehärtet läuft, sondern was dieser ganze Maschinenzustand für das Geschäftsrisiko bedeutet. Wie man aus einem technisch sauberen Regelkreis eine Risikoposition macht, über die eine Geschäftsführung entscheiden kann, ist eine eigene Frage. Sie ist das Thema des zweiten Teils.

Über den Autor

Gerd Kopp ist Wirtschaftsinformatiker und war über 14 Jahre CIO, zuletzt als Head of Corporate Operations. Seit 2020 ist er selbstständiger Interim Manager und IT-Berater. Er arbeitet mit Mittelstandsunternehmen, die Wachstum, Effizienz und Wettbewerbsfähigkeit nicht dem Zufall überlassen wollen — und die verstanden haben, dass die richtigen Prozesse, Strukturen, Technologien und der gezielte Einsatz von KI dabei keine Nebensache sind, sondern der Unterschied.

Mehr unter gerds-it.de. In seinem Innovation Lab erprobt und bewertet er Technologien und Architekturen wie die hier beschriebene, bevor sie in den Produktiveinsatz gehen.

Transparenzhinweis: Dieser Beitrag entstand mit KI-Unterstützung. Konzept, Architektur und die zugrunde liegende Praxis stammen aus meinem eigenen Stack — die KI war Werkzeug, nicht Autor.