Zero Trust gehört zu den Begriffen, die in Ausschreibungen und Vorstandsunterlagen häufiger vorkommen als in Auditberichten. Das hat einen sachlichen Grund: Zero Trust beschreibt eine Entwurfsentscheidung, keine Anforderung. Kein Rechtsakt und keine Managementsystemnorm verlangt Zero Trust namentlich. Für die Compliance zählt deshalb nicht die Bezeichnung, sondern ob die Kontrollen, die sich aus dem Prinzip ergeben, nachweislich wirken.
Eine Bezugsdarstellung gibt es gleichwohl. NIST SP 800-207 „Zero Trust Architecture“ (August 2020) ist die am häufigsten zitierte Ausarbeitung des Modells und beschreibt es als Planungsansatz für Infrastruktur und Arbeitsabläufe. Sie ist eine Veröffentlichung mit Empfehlungscharakter, kein Prüfschema: Es gibt zu ihr kein Zertifikat und keine Konformitätserklärung, und ein Verweis auf sie im Konzeptpapier beantwortet keine der Fragen, die weiter unten im Audit gestellt werden.
Was das Prinzip besagt
Klassische Netzarchitekturen unterscheiden innen und außen. Wer die Perimetergrenze einmal passiert hat, bewegt sich anschließend weitgehend frei. Zero Trust ersetzt diese einmalige Grenzkontrolle durch eine fortlaufende Entscheidung an jedem Zugriffspunkt. Drei Annahmen tragen das Modell:
- Der Standort im Netz begründet kein Vertrauen. Ein Gerät im Bürostandort ist nicht deshalb vertrauenswürdig, weil es dort steht.
- Jede Anfrage wird authentifiziert und autorisiert, nicht nur die erste einer Sitzung.
- Die Entscheidung bezieht neben der Identität auch den Zustand des Geräts, den Kontext des Zugriffs und die Sensibilität der Ressource ein.
Daraus folgen keine neuen Kontrollen, sondern eine andere Anordnung bekannter: starke Authentifizierung, feingranulare Autorisierung, Gerätezustandsprüfung, Segmentierung bis auf die Ebene einzelner Anwendungen und eine Protokollierung, die Zugriffsentscheidungen nachvollziehbar macht.
Welche Missverständnisse über Zero Trust sind im Audit angreifbar?
Drei Missverständnisse begegnen einem regelmäßig, und alle drei sind in einem Audit angreifbar.
Zero Trust ersetzt nicht die Segmentierung. Das Prinzip verlagert die Kontrolle näher an die Ressource, es schafft sie nicht ab. Netztrennung bleibt die Maßnahme, die die Ausbreitung eines Angriffs begrenzt.
Zero Trust ist nicht beschaffbar. Es gibt Bausteine, die das Prinzip unterstützen, aber kein Erzeugnis, dessen Einführung den Zustand herstellt. Wer eine Beschaffung als Umsetzung des Prinzips darstellt, muss im Audit erklären, welche Zugriffsentscheidung sich dadurch tatsächlich geändert hat.
Zero Trust ist nicht zertifizierbar. Zertifiziert wird ein Managementsystem, nicht eine Architektur. Ein Zertifikat nach ISO/IEC 27001 sagt nichts darüber aus, ob eine Organisation nach Zero-Trust-Grundsätzen arbeitet – und umgekehrt.
Was die Vorschriften stattdessen verlangen
Die einschlägigen Vorgaben formulieren Ergebnisse, nicht Architekturen. § 30 Abs. 2 Satz 2 des BSI-Gesetzes ist dabei kein Katalog von Anregungen, sondern ein verbindlicher Mindestumfang: Die Maßnahmen müssen zumindest die dort aufgezählten zehn Punkte umfassen. Einschlägig sind hier zwei davon:
- Nummer 9 – die Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und die Verwaltung von IKT-Systemen, -Produkten und -Prozessen.
- Nummer 10 – die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder zur kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung.
Der Halbsatz zur kontinuierlichen Authentifizierung ist die Stelle, an der ein Zero-Trust-typisches Element im Gesetz unmittelbar anklingt. Er steht dort allerdings als gesetzliche Alternative zur Mehr-Faktor-Authentifizierung, nicht als Architekturvorgabe: Wer Mehr-Faktor-Authentifizierung einsetzt, erfüllt Nummer 10 insoweit, ohne kontinuierlich zu authentifizieren.
Art. 32 Abs. 1 DSGVO verlangt technische und organisatorische Maßnahmen, die dem Risiko angemessen sind, gemessen an Stand der Technik, Implementierungskosten sowie Art, Umfang, Umständen und Zwecken der Verarbeitung. Auch das ist ergebnisoffen. Eine Zero-Trust-Architektur kann die Angemessenheit stützen, sie belegt sie aber nicht von selbst.
Für ISO/IEC 27001 gilt dasselbe in anderer Form: Die gewählten Maßnahmen müssen aus der Risikobehandlung folgen und im Statement of Applicability begründet sein. Eine Architekturentscheidung ersetzt diese Begründung nicht.
Vier Fragen im Audit
Prüfer interessieren sich selten für das Modell und fast immer für seine Folgen. Typisch sind vier Fragen: Welche Ressourcen sind so geschützt, dass ein Zugriff aus dem internen Netz nicht genügt? Woran wird der Zustand eines zugreifenden Geräts erkannt, und was geschieht, wenn er nicht den Vorgaben entspricht? Welche Systeme sind ausgenommen, und wer hat die Ausnahme freigegeben? Und schließlich: Lässt sich für einen konkreten Zugriff im Nachhinein zeigen, welche Kriterien zur Freigabe geführt haben?
An der letzten Frage entscheidet sich der Befund. Eine Architektur, deren Entscheidungen nicht protokolliert werden, ist im Audit nicht prüfbar.
Belastbare Unterlagen
Belastbar sind Unterlagen, die Entwurf, Umsetzung und Wirksamkeit trennen: eine dokumentierte Zugriffsarchitektur mit benannten Schutzbedarfen, die Regelwerke der Zugriffsentscheidung in ihrer aktuellen Fassung, eine gepflegte Liste der Ausnahmen mit Befristung und Freigabe, Protokolle abgelehnter und gewährter Zugriffe für einen Stichprobenzeitraum sowie ein Prüfbericht, der die Wirksamkeit unabhängig bestätigt, etwa aus einem internen Audit oder einem Penetrationstest, der die seitliche Bewegung im Netz gezielt untersucht hat.
Wie führt man Zero Trust ohne Großprojekt ein?
Der verbreitete Fehler ist der Anspruch auf Vollständigkeit. Tragfähiger ist ein schrittweises Vorgehen: mit den Anwendungen beginnen, deren Schutzbedarf am höchsten ist, dort Authentifizierung und Autorisierung verschärfen, die Ergebnisse messen und den Ansatz erst danach ausweiten. Jeder Schritt liefert für sich einen Nachweis. Ein mehrjähriges Programm ohne Zwischenergebnisse liefert bis zu seinem Abschluss keinen.
Zero Trust in Rizzqo
Zero Trust ist eine Entwurfsentscheidung, und Entwurfsentscheidungen lassen sich nicht abhaken. In Rizzqo stehen die Ergebnisse, die ein Prüfer tatsächlich verlangt, als Anforderungen aus ISO/IEC 27002 an den Objekten, deren Kategorie sie betrifft: Zugriffskontrolle, starke Authentifizierung, gesicherte Kommunikation, Protokollierung.
Diese Trennung ist nützlicher, als sie zunächst wirkt. Sie hält die Frage offen, ob eine bestimmte Architekturentscheidung die verlangte Wirkung erzielt, statt sie mit dem Namen der Architektur zu beantworten. Und sie liefert den Maßstab dafür, weil ein Objekt den Schutzbedarf der primären Werte erbt, die es trägt: Wie streng die Prüfung bei jeder Anfrage ausfallen muss, richtet sich nach dem, was tatsächlich daran hängt, und nicht nach dem Reifegrad eines Modells.