Infrastruktur & Security
Die meisten Heimnetze arbeiten bis heute mit einer einzigen Sicherheitsannahme: Wer drin ist, ist berechtigt. Die Firewall trennt außen von innen, und alles innen redet ungehindert miteinander. Das hält genau so lange, bis ein einziges Gerät kompromittiert ist — ein Fernseher, eine Kamera, ein NAS mit alter Firmware.
Zero Trust dreht die Annahme um: Das Netzwerk ist kein Ausweis. Nicht der Standort einer Verbindung entscheidet, sondern die nachgewiesene Identität beider Seiten — bei jeder einzelnen Verbindung neu. Das klingt nach Konzernarchitektur, lässt sich aber mit vier frei verfügbaren Bausteinen auch im Kleinen bauen. Dieser Text beschreibt, was die vier tun, wie sie zusammenspielen — und was dabei erfahrungsgemäß schiefgeht.
Der Kern in vier Fragen
Zero Trust ist kein Produkt, sondern eine Reihenfolge
Jede Verbindung muss vier Fragen beantworten, bevor Daten fließen. Kein Produkt beantwortet alle vier — deshalb braucht es mehrere Bausteine, und deshalb ist die Reihenfolge wichtiger als die Werkzeugauswahl.
-
Wer bist du?
Identität muss kryptografisch nachweisbar sein, nicht behauptet. Eine IP-Adresse ist keine Identität — sie ist eine Wegbeschreibung, und sie lässt sich übernehmen. Ein Zertifikat, das an einen Dienst gebunden ist, ist eine.
-
Darfst du mit genau diesem Dienst sprechen?
Autorisierung gehört an die Verbindung, nicht an das Netzsegment. „Datenbank erreichbar aus dem Server-VLAN“ ist eine Netzregel. „Dieser eine Dienst darf mit dieser einen Datenbank sprechen“ ist eine Zero-Trust-Regel — und der Unterschied zeigt sich erst, wenn im selben VLAN etwas Fremdes steht.
-
Womit weist du dich aus, und wie lange gilt das?
Statische Passwörter in Konfigurationsdateien sind der Normalfall und das größte Einzelrisiko. Ein Geheimnis, das nie abläuft, muss nur einmal abfließen. Kurzlebige, automatisch erneuerte Credentials machen einen Diebstahl zu einem Problem mit Verfallsdatum.
-
Und wenn dich jemand nur ausprobiert?
Alles Bisherige regelt berechtigten Verkehr. Am Rand steht der unberechtigte: Anmeldeversuche, Scans, bekannte Angriffsmuster. Der gehört erkannt und geblockt, bevor er die Kontrollebene überhaupt beschäftigt.
Die Bausteine
Vier Werkzeuge, vier Zuständigkeiten
Alle vier sind quelloffen und laufen auf sparsamer Hardware. Entscheidend ist, dass jedes genau eine Frage beantwortet und den anderen nicht ins Handwerk pfuscht.
Consul
Ein Service-Mesh mit Dienstverzeichnis. Jeder Dienst bekommt eine eigene Identität samt Zertifikat; Verbindungen zwischen Diensten laufen beidseitig authentifiziert und verschlüsselt (mTLS).
- Dienste finden einander über Namen statt über feste Adressen
- Regeln beschreiben, wer mit wem darf — unabhängig vom Netz
- Gesundheitsprüfungen nehmen kaputte Instanzen automatisch heraus
OpenBao / Vault
Ein Tresor, der Geheimnisse nicht nur verwahrt, sondern sie auf Anfrage erzeugt — mit Ablaufdatum. OpenBao ist der quelloffene Zweig, der nach dem Lizenzwechsel von HashiCorp Vault entstanden ist.
- Datenbank-Zugänge auf Zeit statt Passwort in der Konfigurationsdatei
- Eine eigene Zertifizierungsstelle für die Dienst-Zertifikate
- Signierte SSH-Zertifikate mit Minuten-Laufzeit statt dauerhaft hinterlegter Schlüssel
CrowdSec
Wertet Logdateien auf Angriffsmuster aus und sperrt die Quelle — lokal über sogenannte Bouncer in Firewall oder Reverse Proxy. Erkannte Angreifer werden anonymisiert geteilt, sodass alle Teilnehmer von den Beobachtungen der anderen profitieren.
- Verhalten statt starrer Sperrlisten
- Sperren laufen von selbst wieder ab
- Die Auswertung ist vom Blockieren getrennt — man kann erst mitlesen, dann scharf schalten
Das Zusammenspiel
Der Tresor betreibt die Zertifizierungsstelle. Das Mesh holt sich dort die Dienst-Zertifikate und erneuert sie fortlaufend. Anwendungen fragen ihre Zugangsdaten beim Tresor an, statt sie mitzubringen. Die Randabwehr hält davon fern, was gar nicht erst hereingehört.
Kein Baustein kennt die Aufgabe des anderen — genau das macht sie einzeln austauschbar.
Vorher / nachher
Was sich konkret ändert
| Situation | Klassisch | Mit Zero Trust |
|---|---|---|
| Dienst A ruft Dienst B | Erlaubt, weil beide im selben Netz stehen | Erlaubt, weil eine Regel genau diese Beziehung nennt — beidseitig per Zertifikat nachgewiesen |
| Datenbank-Passwort | Steht in einer Konfigurationsdatei, gilt unbegrenzt | Wird bei Bedarf erzeugt, läuft nach Stunden ab, wird automatisch erneuert |
| Administrativer Zugriff | Ein hinterlegter Schlüssel, dauerhaft gültig | Ein signiertes Zertifikat auf Anforderung, gültig für die Dauer der Arbeit |
| Gerät wird kompromittiert | Angreifer erreicht alles im selben Segment | Angreifer erreicht, wofür dieses eine Gerät eine Regel hat — mehr nicht |
| Anmeldeversuche von außen | Laufen bis zum Dienst durch | Werden am Rand erkannt und die Quelle zeitweise gesperrt |
Stolpersteine
Was man vorher wissen sollte
Diese Architektur bringt echten Gewinn, aber sie verschiebt das Risiko — sie beseitigt es nicht. Drei Punkte, die in jeder ehrlichen Planung vorkommen sollten:
Kurzlebige Zertifikate sind nur so gut wie ihre Erneuerung
Der Charme kurzer Laufzeiten ist zugleich die größte Betriebsfalle: Was in Minuten oder Stunden abläuft, muss zuverlässig und unbeaufsichtigt erneuert werden. Bleibt die Erneuerung aus, fällt der Dienst nicht langsam aus, sondern schlagartig — und zwar erst Wochen nach dem Fehler, der die Automatik stillgelegt hat. Die Ablaufzeitpunkte der Zertifizierungsstelle gehören darum genauso überwacht wie die Dienste selbst, mit Vorwarnung statt Ausfallmeldung.
Die Kontrollebene wird zum Single Point of Failure
Wer Geheimnisse und Zertifikate zentralisiert, macht diese Zentrale zur Voraussetzung für alles andere. Ist der Tresor versiegelt oder nicht erreichbar, starten Dienste nicht mehr — auch solche, die vorher jahrelang mit einer Konfigurationsdatei ausgekommen sind. Das ist beherrschbar, verlangt aber eine bewusste Entscheidung: Wie kommt man wieder herein, wenn genau dieser Weg ausfällt? Diese Antwort muss vor dem Ernstfall aufgeschrieben und geprobt sein, und sie darf nicht in dem System liegen, das gerade ausgefallen ist.
Halb eingeführt ist gefährlicher als gar nicht
Ein Mesh, in dem die Hälfte der Dienste läuft, erzeugt das Gefühl von Absicherung, während die andere Hälfte weiter offen spricht. Besser ist es, einen kleinen Bereich vollständig umzustellen und den Rest bewusst als „noch klassisch“ zu führen — mit einer Liste, die das festhält. Sicherheitsarchitektur, die man nicht mehr überblickt, ist keine.
Reihenfolge
Womit anfangen
Wer alles gleichzeitig einführt, hat am Ende vier halbfertige Systeme. Eine Reihenfolge, die sich bewährt hat, weil jeder Schritt für sich schon Nutzen bringt:
| Schritt | Warum an dieser Stelle |
|---|---|
| Randabwehr | Wirkt sofort, ändert nichts an den Diensten, und die Auswertung läuft zunächst im Beobachtungsmodus mit |
| Tresor | Zuerst nur als Ablage für vorhandene Geheimnisse. Der Gewinn ist schon hier spürbar: Sie stehen nicht mehr in Dateien und Verläufen |
| Dynamische Zugänge | Ein einzelner Dienst bekommt Zugangsdaten auf Zeit. Erst wenn Erneuerung und Rücknahme sauber laufen, folgt der nächste |
| Dienst-Identitäten | Der größte Eingriff, deshalb zuletzt — und begrenzt auf eine Gruppe zusammengehöriger Dienste statt auf alles |
Zwischen den Schritten gehört jeweils eine Phase, in der nichts Neues dazukommt und nur beobachtet wird. Die meisten Probleme dieser Architektur zeigen sich nicht bei der Einrichtung, sondern zwei Wochen später beim ersten unbeaufsichtigten Erneuerungslauf.
