Zero Trust Architecture nach SP 800-207: Ressourcen schützen statt Perimeter verteidigen

Problem in der Praxis

Das klassische Sicherheitsmodell trennt ein vertrauenswürdiges Innen von einem unsicheren Außen. Wer einmal im Netz ist, genießt weitgehende implizite Rechte. Dieses Modell war nie ideal, ist aber mit Cloud-Diensten, mobilen Endgeräten, Homeoffice und Dienstleisterzugriffen vollends überholt. Anwendungen liegen bei mehreren Providern, Mitarbeitende arbeiten von überall, und das Unternehmensnetz ist kein geschlossener Raum mehr.

Die Folgen sind bekannt: Ein kompromittiertes Endgerät oder ein gestohlener Zugang erlaubt nach dem Durchbrechen des Perimeters laterale Bewegung, weil interne Kommunikation kaum geprüft wird. Gleichzeitig erzwingen klassische VPN-Konstrukte oft ein Alles-oder-nichts: Wer verbunden ist, ist drin. SP 800-207 setzt genau hier an und entfernt implizites Vertrauen, indem es jede Kommunikation absichert, unabhängig vom Netzstandort.

CISO-Einordnung

SP 800-207 beschreibt Zero Trust über sieben Grundsätze (Tenets), die zusammen die Logik des Modells aufspannen. Laut NIST SP 800-207 gilt: (1) alle Daten und Dienste werden als Ressourcen behandelt; (2) jede Kommunikation wird abgesichert, unabhängig vom Netzstandort; (3) Zugriff wird pro einzelner Session gewährt; (4) der Zugriff folgt einer dynamischen Policy aus Identität, Geräte-/Asset-Zustand und Verhaltens-/Umgebungsattributen; (5) die Organisation überwacht kontinuierlich die Integrität und Sicherheits-Posture ihrer Assets; (6) Authentifizierung und Autorisierung erfolgen dynamisch und strikt vor jedem Zugriff; (7) die Organisation sammelt maximale Telemetrie, um die Posture laufend zu verbessern.

Architektonisch trennt SP 800-207 Entscheidung und Durchsetzung. Die Policy Engine (PE) fällt die Zugriffsentscheidung, der Policy Administrator (PA) setzt sie in eine Freigabe oder Sperrung um; beide bilden zusammen den Policy Decision Point (PDP). Durchgesetzt wird die Entscheidung am Policy Enforcement Point (PEP), der zwischen Subjekt und Ressource sitzt und die Verbindung erst nach Freigabe öffnet. Der PDP speist sich aus mehreren Quellen, unter anderem CDM-Systemen (Continuous Diagnostics and Mitigation), Threat Intelligence, PKI, Identitätsmanagement und SIEM. Diese Trennung von Entscheidung und Durchsetzung ist der architektonische Kern, an dem sich jede Zero-Trust-Initiative messen lassen muss.

Wichtig für die Einordnung: SP 800-207 ist ein konzeptionelles Referenzmodell, kein Kontrollkatalog und kein zertifizierbarer Standard. Wer die Tenets mit konkreten Maßnahmen unterlegen will, findet die Tiefe im Kontrollkatalog SP 800-53 Rev. 5, vor allem in den Familien Access Control (AC), Identification and Authentication (IA), System and Communications Protection (SC), Audit and Accountability (AU) und System and Information Integrity (SI).

Umsetzungsperspektive

Zero Trust lässt sich nicht einkaufen und nicht im Big-Bang einführen. SP 800-207 beschreibt ausdrücklich eine schrittweise Migration: Bestehende Architektur und Zielarchitektur koexistieren über längere Zeit (Hybridbetrieb), während die Organisation Ressourcen schrittweise hinter Policy-Durchsetzung verlagert.

• Sichtbarkeit zuerst: Subjekte, Geräte und Ressourcen inventarisieren. Ohne belastbares Wissen über Identitäten, Assets und Datenflüsse kann keine sinnvolle Policy formuliert werden.
• Identität als Fundament: starke Authentifizierung und sauberes Identitätsmanagement aufbauen; Identität wird zum primären Steuerungspunkt anstelle der Netztopologie.
• Kritische Ressourcen priorisieren: mit besonders schützenswerten Anwendungen und Datenbeständen beginnen und diese als erste hinter einen PEP legen.
• Policy formulieren und dynamisch halten: Zugriffsregeln aus Identität, Geräte-Posture und Kontext ableiten und kontinuierlich aus Telemetrie nachschärfen.
• Kontinuierliche Überwachung verankern: Asset-Integrität und Posture laufend bewerten; dies entspricht der Logik des kontinuierlichen Monitorings (SP 800-137, ISCM) und speist die Policy Engine.

Der Einstieg ist kein Großprojekt: ein verlässliches Identitäts- und Asset-Inventar, starke Authentifizierung und ein erster geschützter Anwendungsfall liefern bereits den Kern eines Zero-Trust-Bausteins, auf dem weitere Ressourcen aufsetzen.

Typische Fehler

1. Zero Trust wird als Produktkauf verstanden. Ein Tool ersetzt nicht die Architekturentscheidung, Entscheidung und Durchsetzung sauber zu trennen.
2. Das Identitäts- und Asset-Inventar fehlt. Ohne Wissen über Subjekte und Ressourcen bleibt jede dynamische Policy Spekulation.
3. Der Perimeter wird nur verschoben, nicht aufgelöst. Ein zentrales Gateway, hinter dem wieder implizites Vertrauen herrscht, ist kein Zero Trust.
4. Telemetrie wird gesammelt, aber nicht in die Policy zurückgespeist. Maximale Telemetrie ist nur dann wertvoll, wenn sie Entscheidungen und Posture verbessert.
5. Big-Bang-Ambition statt schrittweiser Migration. Wer alles gleichzeitig umstellt, überlastet Betrieb und Nutzer und riskiert Verfügbarkeitsschäden.

Risiken und Trade-offs

Zero Trust verschiebt Komplexität vom Netzrand in die Entscheidungslogik. Der PDP wird zur kritischen Komponente: Fällt er aus oder ist er kompromittiert, steht im Extremfall der gesamte Ressourcenzugriff. Verfügbarkeit, Redundanz und Absicherung von PE und PA sind daher selbst sicherheitskritisch.

Ein zweiter Trade-off betrifft Reibung und Akzeptanz. Strikte, kontextabhängige Prüfung vor jedem Zugriff kann Betrieb und Nutzererlebnis belasten, wenn Policies zu eng oder Datenquellen unzuverlässig sind; zu locker konfiguriert verfehlt das Modell seinen Zweck. Hinzu kommt die Abhängigkeit von der Datenqualität: fehlerhafte Geräte-Posture, veraltete Identitäten oder lückenhafte Telemetrie führen zu falschen Entscheidungen. Und Zero Trust ist eine mehrjährige Transformation mit Investitions- und Migrationskosten, die gegen den Sicherheitsgewinn abzuwägen sind.

Entscheidungspunkte

• Welche Ressourcen sind so kritisch, dass sie zuerst hinter Policy-Durchsetzung gehören?
• Ist unser Identitäts- und Asset-Inventar belastbar genug, um dynamische Policies darauf zu gründen?
• Wie stellen wir Verfügbarkeit und Absicherung des PDP (Policy Engine und Policy Administrator) sicher?
• Welche Datenquellen (CDM, Threat Intel, PKI, IdM, SIEM) speisen unsere Policy, und wie verlässlich sind sie?
• Wie gestalten wir den Hybridbetrieb während der schrittweisen Migration, ohne Verfügbarkeit und Akzeptanz zu gefährden?

Praktische Empfehlungen

1. Behandeln Sie Zero Trust als mehrjährige Migration, nicht als Projekt mit Enddatum: definieren Sie eine Zielarchitektur und planen Sie den Hybridbetrieb bewusst ein.
2. Beginnen Sie mit Sichtbarkeit und Identität: Inventar von Subjekten, Geräten und Ressourcen sowie starke Authentifizierung sind Voraussetzung, nicht Kür.
3. Trennen Sie Entscheidung und Durchsetzung sauber: etablieren Sie einen geschützten PDP (PE und PA) und PEPs vor den kritischen Ressourcen.
4. Machen Sie Policy dynamisch: leiten Sie Zugriff aus Identität, Geräte-Posture und Kontext ab und schärfen Sie ihn aus Telemetrie nach.
5. Unterlegen Sie die Tenets mit Controls aus SP 800-53 Rev. 5 (insbesondere AC, IA, SC, AU, SI) und verankern Sie kontinuierliches Monitoring (SP 800-137) als Datenquelle der Policy Engine.

Relevante Normreferenzen

• NIST SP 800-207 (Zero Trust Architecture, August 2020): sieben Tenets; logische Komponenten Policy Engine (PE), Policy Administrator (PA) als Policy Decision Point (PDP) sowie Policy Enforcement Point (PEP); schrittweise Migration. Public Domain.
• NIST SP 800-53 Rev. 5: Kontrollkatalog zur Unterlegung der Tenets, insbesondere die Familien Access Control (AC), Identification and Authentication (IA), System and Communications Protection (SC), Audit and Accountability (AU) und System and Information Integrity (SI). Public Domain.
• NIST SP 800-137 (ISCM): kontinuierliches Monitoring als Datenquelle für Posture-Bewertung und dynamische Policy. Public Domain.
• NIST SP 800-37 (RMF): Rahmen für eine risikobasierte, schrittweise Einführung. Public Domain.
• NIST CSF 2.0 (NIST.CSWP.29): outcome-orientierte Verankerung von Zero Trust vor allem in den Functions Protect (PR) und Detect (DE), gesteuert durch Govern (GV). Public Domain.
• Ergänzend: ISO/IEC 27001 (ISMS-Rahmen); Edition vor Nutzung prüfen.