Zero Trust ist ein Konzept, das heute in fast jeder Sicherheitspräsentation vorkommt. Wenn wir jedoch die praktische Umsetzung betrachten, sehen wir es oft am falschen Ort, mit falschen Erwartungen und mit falschen Werkzeugen eingesetzt. Der Hauptgrund dafür ist, dass Zero Trust als Technologie oder käufliches Produkt positioniert wird. In Wirklichkeit ist Zero Trust keine lizenzierte, verpackte oder herstellerspezifische Lösung. Es ist eine architektonische Perspektive und, was noch wichtiger ist, eine Denkweise.

Das Wesen von Zero Trust ist klar: Never trust, always verify. Vertrauen Sie keinem Benutzer, keinem Gerät, keiner Verbindung implizit. Vertrauen ist ein Zustand, der kontinuierlich neu verdient werden muss. Dieser Ansatz eliminiert die klassische Annahme “innen ist sicher, außen ist gefährlich” vollständig. Denn in der modernen IT-Welt sind innen und außen nicht mehr durch klare Grenzen getrennt.

Zusammenfassung:

• Zero Trust ist ein architektonischer Ansatz, kein Produkt
• Es lehnt das Konzept des impliziten Vertrauens ab
• Es basiert auf kontinuierlicher Verifikation

Dieser Artikel ist Teil einer Serie, die IT-Infrastruktur als System behandelt. Zum Ausgangspunkt: IT-Infrastruktur ist keine Produktsammlung

Zero Trust gehört keinem Hersteller

Zero Trust begann sich durch die Visionen von Sicherheitsanbietern zu formen. Es muss jedoch eine wichtige Unterscheidung getroffen werden: Zero Trust ist kein Konzept, das einem Hersteller “gehört”. Es kann nicht durch eine einzelne Technologie repräsentiert werden.

Der Grund ist folgender: Zero Trust erfordert, dass mehrere Schichten gleichzeitig konsistent zusammenarbeiten. Wenn Netzwerk-, Sicherheits-, Identitäts-, Benutzer-, Geräte- und Anwendungsschichten isoliert voneinander arbeiten, bleibt Zero Trust nur eine Erzählung. Es hat kein architektonisches Gegenstück.

Kernpunkte:

• Zero Trust gehört keinem Hersteller
• Es kann nicht mit einer einzigen Technologie aufgebaut werden
• Schichtübergreifende Konsistenz ist erforderlich

Benutzer- und Geräteverifizierung: Wo die Architektur beginnt

Die Zero Trust Architektur beginnt mit einer grundlegenden Frage:

“Sollte dieser Benutzer mit diesem Gerät wirklich auf die Ressource zugreifen, auf die er gerade zugreifen möchte?”

Um eine sinnvolle Antwort zu geben, ist der erste Schritt die Verifikation der Benutzer und Geräte, die dem Netzwerk beitreten. Active Directory, LDAP oder moderne Identity-Provider stehen im Zentrum dieser Struktur. Auf welche Ressourcen ein Benutzer zugreifen kann, wird nicht nur durch seine Identität, sondern auch durch seine Rolle und seinen Risikostatus bestimmt.

Aus Zero Trust Perspektive geht es jedoch nicht nur darum, wer der Benutzer ist — der Status des Geräts, ob es zum Unternehmensbestand gehört und ob es den Sicherheitsrichtlinien entspricht, sind ebenfalls Teil dieser Entscheidung.

Wichtige Erkenntnisse:

• Benutzerverifikation allein ist nicht ausreichend
• Geräteidentität und -zustand werden ebenfalls bewertet
• Zugriffsentscheidungen sind kontextabhängig

VPN ≠ Zero Trust: Der richtige Rahmen für Remote-Zugriff

Remote-Arbeit ist keine Ausnahme mehr — sie ist der Standard. Dennoch arbeiten viele Organisationen noch immer mit klassischer VPN-Logik: Der Benutzer verbindet sich mit dem VPN und wird sofort Teil des gesamten lokalen Netzwerks. Das ist kein Zero Trust. Das ist einfach nur Remote-Zugriff.

In einer Zero Trust Architektur bedeutet Remote-Zugriff nicht “Zugriff auf alles”. Der Benutzer greift nur auf die Anwendungen oder Ressourcen zu, für die er autorisiert ist. Das Ziel ist immer dasselbe: Zugriff minimieren und kontinuierlich verifizieren.

Kernpunkte:

• VPN ≠ Zero Trust
• Zugriff sollte auf die Ressource, nicht auf das gesamte Netzwerk erfolgen
• Autorisierung wird kontinuierlich verifiziert

Kontinuierliche Verifikation und MFA

Was Zero Trust von klassischen Sicherheitsansätzen unterscheidet, ist, dass Authentifizierung nicht als einmaliges Ereignis behandelt wird. Mit sich änderndem Benutzer- und Geräteverhalten wird der Zugriff kontinuierlich neu bewertet.

Hier kommt die Multi-Faktor-Authentifizierung (MFA) ins Spiel. Zusätzliche Schichten wie SMS, mobile App-Benachrichtigungen, Hardware-Token oder biometrische Verifikation werden eingesetzt. Besonders für kritische Anwendungen wie Mail-Server, Finanzsysteme oder ERP werden Benutzer in regelmäßigen Abständen zur erneuten Verifikation aufgefordert.

Zusammenfassung:

• Verifikation ist kontinuierlich
• MFA ist eine Kernkomponente von Zero Trust
• Intervalle werden für kritische Ressourcen verkürzt

Firewall: Der Policy-Entscheidungspunkt

Die Firewall-Schicht spielt eine zentrale Rolle in der Zero Trust Architektur. Diese Rolle geht jedoch weit über das klassische “Gerät, das den Internetzugang kontrolliert” hinaus. Im Zero Trust Ansatz ist die Firewall ein Entscheidungspunkt mit Identitäts- und Kontextbewusstsein.

Auf der Firewall definierte Regeln sollten nicht nur auf IP oder Port basieren. Wenn benutzer-, gruppen- und anwendungsbasierte Regeln geschrieben werden können, wird Zero Trust wirklich implementierbar.

Um zu verstehen, wie Switches, Firewalls und APs zusammenarbeiten: Switch, Firewall, AP — Warum die richtige Produktwahl allein nicht ausreicht

Diese Schicht zusammengefasst:

• Firewall ist der Policy-Entscheidungspunkt
• Identitäts- und Anwendungsbewusstsein sind unerlässlich
• Port-basierte Regeln sind nicht ausreichend

Die Access-Schicht: Wo Zero Trust beginnt

Zero Trust wird nicht nur auf der Firewall- und VPN-Schicht angewendet. Die Access-Schicht ist der Ausgangspunkt der Architektur. 802.1X und NAC-Lösungen kommen hier ins Spiel. Alle Switch-Ports und drahtlosen Zugänge werden von einem zentralen System kontrolliert. Benutzer oder Geräte werden verifiziert, bevor sie dem Netzwerk beitreten, und basierend auf dieser Verifikation werden VLANs dynamisch zugewiesen oder Richtlinien angewendet.

Kernpunkte:

• Zero Trust beginnt in der Access-Schicht
• 802.1X bietet zentrale Kontrolle
• Statische VLAN / SSID-Strukturen skalieren nicht

Geräteprofiling und IoT

In modernen Zero Trust Architekturen werden nicht nur Benutzergeräte, sondern alle mit dem Netzwerk verbundenen Endpunkte unter Kontrolle gebracht. Drucker, Kameras, IP-Telefone, Kartenleser — alle werden in den Verifikationsprozess einbezogen.

Nächste-Generation-NAC-Lösungen kombinieren mehrere Parameter wie DHCP-Fingerprint, CDP/LLDP-Informationen und Gerätehersteller-Daten für das Geräteprofiling. Ob das Gerät aktuell ist, sein Sicherheitsstatus und die Einhaltung von Unternehmensstandards werden alle bewertet.

Kernpunkte:

• Geräteprofiling ist von entscheidender Bedeutung
• MAC-Adresse allein ist nicht ausreichend
• Inventarintegration ist unerlässlich

Gastzugang: Vertrauen wird nie angenommen

Selbst der Gastzugang wird in der Zero Trust Architektur kontrolliert. Gastbenutzer werden über Gastportale verifiziert und erhalten nur für eine bestimmte Dauer und mit bestimmten Berechtigungen Zugang. Gäste können in der Regel nur auf das Internet zugreifen; ihr Zugang zu Unternehmensressourcen ist eingeschränkt.

Zusammenfassung:

• Gastzugang ist nicht unbegrenzt
• Zeit- und berechtigungsbasierte Kontrollen werden angewendet
• Vertrauen wird nie angenommen

Kontinuierliches Monitoring: Der kritischste Teil der Architektur

Zugriff und Verhalten werden auf jeder Schicht überwacht und protokolliert. Wenn eine Anomalie oder riskante Aktivität erkannt wird, schränkt das System automatisch den Zugriff ein oder fordert zusätzliche Verifikation an.

Für den Aufbau echter Sichtbarkeit in Ihrer Infrastruktur: Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen und proaktiv handeln

Fazit

Zero Trust ist kein Produkt. Es kann nicht mit einem einzigen Gerät aufgebaut werden. Man kann nicht sagen “wir haben es implementiert, wir sind fertig.”

Zero Trust ist eine lebendige Architektur, in der Firewall-, Switch- und WLAN-Infrastruktur zusammenarbeiten, indem sie Benutzer- und Geräteinformationen von einem zentralen Punkt beziehen, wobei der Zugriff in jeder Phase erneut hinterfragt wird. Deshalb sollte Zero Trust nicht als zu kaufende Technologie, sondern als zu gestaltende und zu betreibende Kompetenz betrachtet werden.

Hinweis

Dieser Artikel erschien ursprünglich in kürzerer, erzählerischer Form auf Substack. Diese Version erweitert die architektonische Grundlage der Serie.

👉 Lesen Sie den Artikel auf Substack: Hier klicken

Verwandte Artikel

Architektur & Sicherheitsdesign

• 📐 IT-Infrastruktur ist keine Produktsammlung — Der Grundlagenartikel dieser Serie
• 🏗️ Switch, Firewall, AP — Warum die richtige Produktwahl allein nicht ausreicht — Systemdenken im Core-Network-Design
• 📊 Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen — Echte Transparenz in der Infrastruktur aufbauen

Technisches Engineering

• 🔐 802.1X Projekte erfolgreich umsetzen: Praxiseinblicke — Identitätsbasierter Zugang in Unternehmensnetzwerken
• 🛡️ Network Packet Broker (NPB) Masterclass — Erweiterte Traffic-Sichtbarkeit und Sicherheitsstrategie
• 🛠️ Die Hintertür des Netzwerks: Next-Gen Console Server Architektur — Out-of-Band-Zugang wenn alles andere versagt

Warum echtes Infrastrukturdesign mit Systemen beginnt, nicht mit Tools

Dieser Artikel bildet das architektonische Fundament der Serie. Bevor wir über Switches, Firewalls, WLAN, Zero Trust oder 802.1X sprechen, muss eines klar sein:

IT-Infrastruktur ist nicht die Summe der gekauften Produkte. Sie ist das Ergebnis davon, wie Systeme gemeinsam unter Druck funktionieren.

Wo die meisten Infrastrukturprojekte wirklich scheitern

Die meisten Infrastrukturinitiativen beginnen mit guten Absichten. Eine Erneuerung wird geplant, ein Budget freigegeben – und die Diskussion dreht sich schnell um Produktvergleiche. Hersteller werden bewertet, Feature-Listen verglichen, Datenblätter studiert.

Doch viele dieser Projekte scheitern in der Praxis – nicht weil die gewählten Produkte schlecht sind, sondern weil die Infrastruktur nie zu einem System wird.

Was ich über die Jahre immer wieder beobachte: Jede Komponente funktioniert für sich genommen einwandfrei, aber das Gesamtverhalten der Umgebung ist unvorhersehbar. Identität wird an einer Stelle verwaltet, Segmentierung an einer anderen, Policy-Durchsetzung wieder woanders – und der Betrieb wird manuell zusammengehalten. Wenn etwas bricht, hat keine einzelne Schicht den vollständigen Kontext.

Die Infrastruktur existiert. Aber Infrastrukturverhalten existiert nicht.

Produkte lösen Probleme. Systeme tragen Organisationen.

Ein Produkt ist dafür konzipiert, ein spezifisches Problem zu lösen. Eine Infrastruktur ist dafür konzipiert, eine Organisation zu tragen.

Diese Unterscheidung ist subtil, aber entscheidend. Produkte können ersetzt werden. Systeme müssen sich weiterentwickeln.

Wenn Infrastruktur als Sammlung von Tools gebaut wird, werden Entscheidungen lokal optimiert. Jedes Team wählt, was für seinen Bereich am besten funktioniert. Im Laufe der Zeit häufen sich diese lokalen Optimierungen zu globaler Komplexität an. Integration wird fragil, Troubleshooting wird langsam, und jede Änderung birgt Risiken.

Systemorientiertes Design funktioniert anders. Es beginnt mit grundlegenden Fragen:

• Wo hat Identität ihren Ursprung, und wie weit reicht sie?
• Wo werden Vertrauensgrenzen definiert?
• Welche Komponenten treffen Policy-Entscheidungen, welche setzen sie nur durch?
• Wie wird Kontext über Schichten hinweg erhalten?
• Was passiert operativ, wenn etwas ausfällt?

Ohne klare Antworten auf diese Fragen werden selbst die besten Produkte irgendwann gegeneinander arbeiten.

Für einen tiefen Einblick, wie Identität und Vertrauensgrenzen in der Praxis definiert werden: Zero Trust Mindset: Sicherheit als Architektur, nicht als Produkt

Architektur zeigt sich unter Druck

Infrastrukturdesign ist einfach, wenn alles funktioniert. Architektur zeigt sich erst, wenn etwas schiefgeht.

Incidents, Skalierungsereignisse, Sicherheitsverletzungen und operative Änderungen legen Designannahmen offen, die nie dokumentiert wurden. In Umgebungen aus lose verbundenen Produkten verwandeln sich diese Momente in Feuerlöschübungen. Provisorische Lösungen werden dauerhaft. Mit der Zeit verliert die Infrastruktur ihre Kohärenz.

Gut designte Systeme verhalten sich anders. Sie degradieren graceful. Verantwortlichkeiten sind klar. Ausfälle sind begrenzt. Wiederherstellungspfade sind im Voraus bekannt. Das ist kein Zufall – es ist das Ergebnis bewusster architektonischer Entscheidungen.

Integration ist kein Feature

Eines der häufigsten Missverständnisse im Infrastrukturdesign ist es, Integration als Checkbox zu behandeln. Produkte werden als integriert angenommen, weil sie dieselben Standards unterstützen oder vom selben Hersteller stammen.

Echte Integration geht nicht um Kompatibilität. Sie geht um geteilten Kontext.

Identitätsbewusste Durchsetzung, konsistente Segmentierung, einheitliches Logging, vorhersehbares Policy-Verhalten – das wird nicht durch den Kauf „integrierter" Produkte garantiert. Es muss als Teil eines Systems designed, getestet und betrieben werden.

Ohne das existiert Integration nur auf Folien.

Betrieb definiert die echte Architektur

Die wahre Architektur einer Umgebung findet sich nicht in Diagrammen. Sie findet sich in operativen Workflows.

• Wie werden Änderungen ausgerollt?
• Wie werden Incidents diagnostiziert?
• Wie werden Ausnahmen behandelt?
• Wie wird Automatisierung eingeführt?
• Wie werden Verantwortlichkeiten auf Teams verteilt?

Wenn diese Workflows manuell, fragmentiert oder undokumentiert sind, wird die Infrastruktur diese Realität widerspiegeln – unabhängig davon, wie modern der Technologie-Stack erscheint.

Deshalb sind Automatisierung, Observability und Lifecycle-Management keine optionalen Extras. Sie sind architektonische Elemente. Infrastruktur, die nicht konsistent betrieben werden kann, wird niemals sicher skalieren.

Einen praktischen Rahmen für den Aufbau echter Sichtbarkeit in Ihrer Infrastruktur finden Sie hier: Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen und proaktiv handeln

Warum das wichtig ist, bevor wir über Networking sprechen

Networking ist oft der erste Ort, wo diese Probleme sichtbar werden. Traffic-Flows legen kaputte Vertrauensmodelle offen. Segmentierung zeigt fehlende Identität. Performance-Probleme enthüllen architektonische Abkürzungen.

Aber Networking ist nicht die Ursache. Es ist der Spiegel.

Deshalb beginnt diese Serie hier. Bevor wir in Core-Network-Design, Vendor-Strategien, Zero Trust oder 802.1X eintauchen, brauchen wir ein gemeinsames Verständnis: Infrastruktur muss als System mit Absicht behandelt werden – nicht als Einkaufsliste mit Budget.

Das Prinzip, das den Rest dieser Serie leitet

Jeder folgende Artikel baut auf einem einzigen Prinzip auf:

Zuerst das System designen. Dann die Produkte wählen.

Wenn diese Reihenfolge umgekehrt wird, wird Infrastruktur teuer und fragil. Wenn diese Reihenfolge eingehalten wird, wird Infrastruktur vorhersehbar und anpassungsfähig.

Was als nächstes kommt

Der nächste Artikel dieser Serie wendet dieses Denken direkt auf das Core-Netzwerk an:

• Warum ein Core-Netzwerk keine Liste von Switches, Firewalls und Access Points ist
• Wie Integration, Kapazitätsplanung und operativer Kontext echte Netzwerkarchitektur definieren

Dieser erste Artikel setzt die Baseline. Alles andere baut darauf auf.

Hinweis

Dieser Artikel erschien ursprünglich in kürzerer, erzählerischer Form auf Substack. Diese Version erweitert die architektonische Grundlage der Serie.

👉 Lesen Sie den Artikel auf Substack: Hier klicken

Verwandte Artikel

Architektur & Sicherheitsdesign

• 🏗️ Switch, Firewall, AP — Warum die richtige Produktwahl allein nicht ausreicht — Systemdenken im Core-Network-Design
• 🛡️ Zero Trust Mindset: Sicherheit als Architektur, nicht als Produkt — Warum Zero Trust eine Philosophie und kein Produkt ist
• 📊 Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen — Echte Transparenz in der Infrastruktur aufbauen

Technisches Engineering

• 🛠️ Die Hintertür des Netzwerks: Next-Gen Console Server Architektur — Out-of-Band-Zugang wenn alles andere versagt
• 🛡️ Network Packet Broker (NPB) Masterclass — Erweiterte Traffic-Sichtbarkeit und Sicherheitsstrategie
• 🔐 802.1X Projekte erfolgreich umsetzen: Praxiseinblicke — Identitätsbasierter Zugang in Unternehmensnetzwerken