Zero-Trust-Strategie implementieren: Rollen, Verantwortlichkeiten und Metriken

Wer heute Zero-Trust-Strategie implementieren will, merkt schnell: Die eigentliche Hürde ist selten ein fehlendes Tool, sondern fehlende Klarheit. Zero Trust ist ein Betriebsmodell fr Identitten, Gerte, Netzwerke, Daten und Anwendungen. Es verschiebt Entscheidungen vom „Innen ist vertrauenswrdig“ hin zu „jeder Zugriff wird kontinuierlich verifiziert“. Das greift tief in Prozesse ein: Berechtigungen, Change-Management, Incident Response, Audit-Nachweise und nicht zuletzt in die Nutzererfahrung.

Damit eine Zero-Trust-Initiative nicht als Sammlung einzelner Security-Manahmen endet, braucht es drei Dinge, die im Alltag oft fehlen: (1) ein Rollen- und Verantwortlichkeitsmodell, das IT, Security und Fachbereiche verbindlich macht, (2) umsetzbare Policies, die sich in Betrieb und Projekte integrieren lassen, und (3) Metriken, die Fortschritt und Risiko transparent machen, ohne ein Reporting-Monster zu erzeugen.

Dieser Beitrag liefert genau das: eine praxistaugliche Governance-Struktur, eine RACI-Logik fr kritische Bausteine sowie ein KPI-Set, das sowohl fr IT-Leitung als auch fr Compliance und Audit belastbar ist. Technische Begriffe werden kurz eingeordnet, damit Entscheider und Betriebsverantwortliche dieselbe Sprache sprechen.

Zero-Trust-Strategie implementieren: Was Zero Trust in der Praxis bedeutet (und was nicht)

Zero Trust wird hufig missverstanden als „alles ist verboten, bis es explizit erlaubt wird“. In der Praxis geht es nicht um maximalen Restriktionsgrad, sondern um kontrolliertes Vertrauen mit nachvollziehbarer Begrdung. Die Kernprinzipien lassen sich auf drei operative Leitlinien reduzieren:

• Explizit verifizieren: Zugriff wird an Identitt, Gertezustand, Kontext (Ort, Zeit, Risiko) und Ressource gebunden. Typische Mechanismen sind MFA (Multi-Faktor-Authentisierung) und Conditional Access (kontextbasierte Zugriffsregeln).
• Least Privilege: Jeder bekommt nur die Berechtigungen, die er fr die Aufgabe braucht, und nur so lange wie ntig. Das betrifft Fachanwender ebenso wie Admin-Konten und Service-Accounts.
• Breach annehmen: Man plant, als wre ein Angreifer bereits im Netz. Daraus folgen Segmentierung, saubere Protokollierung und schnelle Reaktion.

Was Zero Trust nicht ist: ein einzelnes Produkt, ein reines Netzwerkprojekt oder eine reine IAM-Manahme. Eine „Zero Trust Architektur“ ist eher ein Zielbild, das cber mehrere Domnen hinweg schrittweise umgesetzt wird: Identitt (IAM), privilegierte Konten (PAM), Endpunkte (Endpoint Management/EDR), Netzwerkzugriff (ZTA/Proxy/VPN-Ersatz), Datenzugriff (DLP/Classification) und Observability (Logging/SIEM).

Warum Rollen und Verantwortlichkeiten cber Erfolg oder Stillstand entscheiden

Zero Trust erzeugt viele neue „kleine Entscheidungen“: Darf ein Dienstkonto ohne MFA noch auf Produktionsdatenbanken zugreifen? Welche Gerteanforderungen gelten fr externe Dienstleister? Welche Ausnahmen sind zulssig, wie lange, und wer genehmigt sie? Wenn diese Entscheidungen nicht in einem klaren Modell verankert sind, entstehen drei typische Fehlerbilder:

• Schatten-Ausnahmen: Teams umgehen Policies, weil Prozesse zu langsam sind oder niemand zustdig ist. Ergebnis: reales Risiko steigt, Audit-Fhigkeit sinkt.
• Overblocking: Security setzt harte Regeln ohne Betriebsrcckopplung. Ergebnis: produktive Arbeit leidet, Projekte verzgern sich, Druck zur Deaktivierung der Kontrollen.
• Messblindheit: Es wird „viel getan“, aber niemand kann sagen, ob Risiko sinkt oder nur Aufwand steigt.

Die Gegenmanahme ist klassische Governance, aber konkret auf Zero Trust zugeschnitten: definierte Rollen, RACI je Control-Baustein und ein schlankes KPI-Set, das direkt aus den Systemen kommt (Identity Provider, Endpoint Management, SIEM, Ticketing).

Rollenmodell fr die Implementierung einer Zero-Trust-Strategie

Je nach Unternehmensgre sind Rollen Personen oder Teams. Wichtig ist: Verantwortlichkeit ist nicht delegierbar, Aufgaben schon. Die folgenden Rollen haben sich in der Praxis bewhrt:

Executive Sponsor (CIO/IT-Leitung oder Geschtsleitung mit IT-Bezug)

Stellt Budget und Prioritt sicher, entscheidet Konflikte zwischen Security und Business, und nimmt Risiken bewusst an (Risk Acceptance). Ohne Sponsor werden Ausnahmen zum Normalzustand.

CISO/Informationssicherheitsverantwortliche

Verantwortet das Sicherheitszielbild, die Policy-Logik und das Risikomodell. Wichtig: nicht „alles selbst betreiben“, sondern Anforderungen prcfbar machen und cber Metriken steuern.

Zero-Trust-Programmleitung (Security/IT gemeinsam)

Orchestriert Roadmap, Abhngigkeiten und Rollout-Wellen. Diese Rolle ist zentral fr Priorisierung: welche Systeme zuerst, welche Kontrollen in welcher Tiefe, und welche Quick Wins den Betrieb sofort entlasten (z. B. Admin-MFA, Gerte-Compliance).

IAM-Owner (Identity and Access Management)

IAM umfasst Identitten, Rollen, Gruppen, Authentisierung und Provisionierung (Joiner/Mover/Leaver). Der IAM-Owner stellt sicher, dass Berechtigungen nachvollziehbar sind und Zugriff nicht „per Mail“ vergeben wird.

PAM-Owner (Privileged Access Management)

PAM steuert privilegierte Konten: Admin-Zugriffe, Break-Glass-Konten, Credential Vaulting, Session Recording. Diese Rolle ist entscheidend, weil Privilegien die hufigste Abkrzung fr Angreifer sind.

Endpoint-Management/Workplace-Owner

Verantwortet Gertezustand (Patchlevel, Verschlsselung, EDR-Agent, Secure Boot) und damit die Grundlage fr Conditional Access. Ohne saubere Gerte-Compliance wird Zero Trust schnell zu „MFA-only“.

Netzwerk- und Plattformbetrieb

Setzt Segmentierung, Zugriffspfade und Plattformkontrollen um (z. B. ZTNA-Gateways, Proxy, Firewall-Regeln, Cloud Security Controls). Wichtig: dokumentierte Standardpfade statt individueller Sonderrouten pro Anwendung.

Application Owner / Systemverantwortliche

Fachlich und technisch verantwortlich fr Anwendungen und Daten. Entscheidet cber Datenklassifikation, Integrationsmuster, Service-Accounts und Umsetzungsfenster. Ohne Application Owner sind saubere Ausnahmeregeln kaum mglich.

Compliance/Datenschutz/Audit Liaison

bersetzt regulatorische Anforderungen (z. B. NIS2 als EU-Richtlinie fr Cybersicherheit, ISO 27001 als Managementsystem-Standard) in prcfbare Evidence-Anforderungen: Welche Logs, welche Genehmigungen, welche Policy-Versionen werden im Audit vorgelegt?

RACI-Matrix: Wer entscheidet, wer setzt um, wer liefert Nachweise?

Eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) verhindert, dass „alle irgendwie beteiligt“ sind. Unten ein praxistauglicher Zuschnitt fr typische Zero-Trust-Bausteine. Passen Sie Rollenbezeichnungen an Ihre Organisation an, nicht die Logik.

RACI (Kurzform, exemplarisch)

Baustein / Entscheidung                     R            A            C                          I
-----------------------------------------------------------------------------------------------------------
Zero-Trust-Policy-Set (Grundregeln)         CISO         Sponsor      IT-Betrieb, Compliance       Fachbereiche
MFA-Standard (wer, wann, Ausnahmen)         IAM-Owner     CISO         Service Desk, Compliance     Alle Nutzer
Conditional Access (Gerät, Standort, Risiko)IAM-Owner     CISO         Endpoint-Owner, SOC          IT-Leitung
PAM-Umfang (Admin, Drittparteien, Notfall)  PAM-Owner     CISO         IT-Betrieb, Audit            Sponsor
Geräte-Compliance-Standards                 Endpoint-OwnerIT-Leitung   CISO, Betriebsrat/HR         Nutzer
Segmentierung / Zugriffspfade               Netzbetrieb   IT-Leitung   CISO, App Owner              SOC
Logging/SIEM-Use-Cases & Retention          SOC/SIEM-OwnerCISO         Datenschutz, IT-Betrieb      Audit
Ausnahmeprozess (Risk Acceptance)           Programmlead  Sponsor      CISO, Compliance, App Owner  Audit
On-/Offboarding (Joiner/Mover/Leaver)       IAM-Owner     IT-Leitung   HR, Fachbereich              CISO
Third-Party-Access (Dienstleister)          PAM-Owner     IT-Leitung   Einkauf, Compliance, App Ow. CISO

Wichtig fr Auditfhigkeit: Zu jedem Baustein muss klar sein, wo die Nachweise entstehen (z. B. Tickets, Policy-Repositories, IdP-Logs, PAM-Reports) und wer sie bei Bedarf reproduzierbar liefern kann.

Governance, die im Betrieb funktioniert: Policies, Ausnahmen und Change-Control

Zero Trust lebt von Policies. Eine Policy ist dabei nicht nur ein Dokument, sondern eine maschinenlesbare Regel (z. B. Conditional-Access-Regel) plus begleitende Governance: Versionierung, Freigabe, Rollout, Monitoring, Ausnahmen.

Policy-Layer, die Sie sauber trennen sollten

• Prinzipien: wenige, stabile Leitlinien (z. B. „Admin-Zugriffe nur cber PAM“).
• Standards: konkret und prcfbar (z. B. „MFA fr alle Remote-Zugriffe“, „Gerte mssen verschlsselt sein“).
• Technische Durchsetzung: Regeln in Systemen (IdP, Endpoint, Netzwerk, Cloud).
• Ausnahmen: zeitlich befristet, risikobasiert, mit Owner und Kompensationsmanahmen (z. B. engere Segmentierung, zustzliche cberwachung).

Vorlage: Mindestinhalt fr einen Ausnahmeprozess (auditfest)

Ausnahmen sind normal, aber sie mssen kontrolliert sein. Ein praktikabler Standard ist ein Ticket- oder Workflow-Template mit folgenden Pflichtfeldern:

• Ressource/Anwendung, betroffene Nutzergruppen oder Konten
• konkrete Policy, von der abgewichen wird
• Begrdung (technisch/organisatorisch), Business-Impact ohne Ausnahme
• Risiko-Einschtzung (z. B. niedrig/mittel/hoch) und Datenklassifikation
• Kompensationsmanahmen (Logging, Segmentierung, temporre Rechte, Monitoring)
• Startdatum, Enddatum (Sunset), Review-Termin
• Genehmiger (Accountable) und verantwortlicher Owner (Responsible)
• Evidence-Link (z. B. Konfiguration, Report, Change-Record)

Change-Control: Warum Zero Trust kein „einmal einstellen“ ist

Neue Anwendungen, neue Integrationen, M&A, Cloud-Migrationen, vernderte Arbeitsplatzmodelle: Das alles verndert Zugriffspfade. Deshalb muss Zero Trust in bestehende Change-Prozesse integriert werden. Praktisch bedeutet das:

• Jeder Change mit Identitts- oder Netzwerkauswirkung bekommt einen Security-Impact-Check (kurzer Fragenkatalog).
• Policies werden versioniert; Rollouts erfolgen in Wellen (Pilot, kontrollierte Gruppen, Breite).
• Rollback ist geplant: Wenn eine Policy zu viel blockiert, muss klar sein, wie schnell und kontrolliert zurcckgestellt wird, ohne Sicherheitslccken zu reien.

Umsetzungslogik: Priorisieren nach Risiko, nicht nach Systemlandschaft

Viele Programme scheitern, weil sie nach Technologie-Tpfen organisiert werden („erst Netzwerk, dann IAM“). Besser ist eine risikobasierte Sequenz entlang typischer Angriffswege und organisatorischer Engpsse.

Stufe 1: Identitt und privilegierte Zugriffe stabilisieren

Wenn Angreifer Identitten cbernehmen, ist „innen/auen“ irrelevant. Deshalb zuerst:

• MFA fr alle Nutzer, insbesondere fr Admin- und Fernzugriffe; Break-Glass-Konten strikt begrenzen und kontrolliert nutzen.
• PAM fr Administratoren und kritische Systeme (Vaulting, zeitlich begrenzte Admin-Rechte, Sitzungsnachvollziehbarkeit).
• Service-Accounts inventarisieren und rotieren; wo mglich auf modernere Verfahren (z. B. kurzlebige Tokens) umstellen.

Stufe 2: Gerte-Compliance als Zugriffsbedingung

Conditional Access ist nur so gut wie die Qualitt der Gerte-Attribute. Definieren Sie Mindestanforderungen (Verschlsselung, Patch-Stand, EDR, Screen-Lock) und koppeln Sie diese an Zugriffe auf kritische Ressourcen.

Stufe 3: Zugriffspfade vereinheitlichen (ZTNA/Proxy, Segmentierung)

Statt breiter Netzwerkzugnge (klassisches VPN) werden zugriffsbezogene Pfade etabliert: Anwender erreichen nur die Anwendungen, die sie brauchen. Segmentierung bedeutet hier nicht zwingend Microsegmentierung bis auf Host-Ebene, sondern zuerst: kritische Zonen trennen, Ost-West-Traffic einschrnken, Admin-Pfade separieren.

Stufe 4: Daten- und Applikationssicht schrfen

Sptestens hier mssen Application Owner liefern: Datenklassifikation, kritische Transaktionen, Schnittstellen, technische Konten. Zero Trust betrifft auch APIs (Application Programming Interface, also definierte Schnittstellen zwischen Systemen): Wer darf welche Daten in welcher Frequenz abrufen, und wie wird Missbrauch erkannt?

Metriken: Was Sie messen sollten, damit Zero Trust steuerbar wird

Ohne Metriken wird Zero Trust zur Glaubensfrage. Mit den falschen Metriken entsteht Aktionismus. Gute KPIs haben drei Eigenschaften: Sie sind (1) aus Systemen ableitbar, (2) fr Entscheidungen nutzbar, (3) robust gegen „Schnrechnen“.

KPI-Set 1: Identity & Access (IAM)

• MFA-Abdeckung: Anteil aktiver Nutzerkonten mit MFA, getrennt nach internen/externen Nutzern und nach privilegierten Konten.
• Starke Authentisierung bei Risiko: Anteil von riskanten Logins, bei denen zustzliche Faktoren erzwungen wurden (aus IdP-Risk-Signalen).
• Joiner/Mover/Leaver-Zeiten: Zeit bis Kontoentzug nach Austritt bzw. Rollenwechsel; wichtig fr Audit und Insider-Risiko.
• Verwaiste Konten: Anzahl Konten ohne Login seit X Tagen oder ohne Owner-Zuordnung.

KPI-Set 2: Privileged Access (PAM)

• PAM-Abdeckung kritischer Admin-Zugriffe: Anteil Admin-Workflows, die cber PAM laufen (nicht nur „PAM ist installiert“).
• Just-in-Time/Just-Enough-Access: Anteil temporr vergebener Admin-Rechte vs. dauerhaft zugewiesener Privilegien.
• Break-Glass-Nutzung: Hufigkeit und Begrdungsqualitt; jedes Ereignis ist ein Review-Trigger.
• Credential-Rotation: Anteil privilegierter Credentials, die innerhalb definierter Fristen rotiert wurden.

KPI-Set 3: Device Trust (Endpoint/Workplace)

• Compliance-Quote: Anteil verwalteter Gerte, die Mindeststandards erfllen (Verschlsselung, Patch, EDR).
• Shadow Devices: erkannte, aber nicht verwaltete Gerte, die Zugriffe versuchen.
• Time-to-Patch (kritisch): Zeit von Verfcgbarkeit bis Installation sicherheitskritischer Updates (nach Kritikalitt gruppiert).

KPI-Set 4: Netzwerk- und Applikationskontrollen

• Reduzierte Zugriffspfade: Anzahl/Anteil der Anwendungen, die ohne breiten Netzwerkzugang erreichbar sind (ZTNA/Proxy statt „Netz frei“).
• Segmentierungsverletzungen: erkannte unzulssige Ost-West-Verbindungen (aus Netzwerk-Telemetrie).
• Service-Account-Risiko: Anzahl Service-Accounts mit weitreichenden Rechten oder ohne Rotation/Owner.

KPI-Set 5: Detection, Response und Audit-Evidence

• Log-Completeness: Anteil kritischer Systeme, deren Auth-, Admin- und Zugriffslogs zentral ankommen (SIEM/Logplattform).
• MTTD/MTTR (Trend): Mean Time To Detect/Respond als Trend, nicht als absolute Wahrheit; wichtig ist Konsistenz der Messmethode.
• Policy-Drift: Abweichungen zwischen definiertem Standard und realer Konfiguration (z. B. deaktivierte Regeln, unreviewte Ausnahmen).
• Evidence-Lead-Time: Zeit, um fr ein Audit die geforderten Nachweise zu liefern (Tickets, Reports, Logauszcge). Das ist ein unterschtzter Management-Indikator.

Reporting-Rhythmus: Wenig, aber verbindlich

Ein sinnvoller Takt ist monatlich operativ (Security/IT-Betrieb) und quartalsweise im Steering (Sponsor, CISO, Compliance). Entscheidend ist, dass jedes KPI-Cluster eine klare Frage beantwortet, zum Beispiel: „Wie wahrscheinlich ist Account Takeover?“ oder „Wie viele Ausnahmen sind technisch begrcndet und befristet?“

Audit- und Regulatorik-Perspektive: Nachweise statt Absichtserklrungen

Ob ISO 27001, interne Revision oder Anforderungen aus NIS2: Prcfungen drehen sich selten um „haben Sie Zero Trust?“, sondern um Kontrollen und Wirksamkeit. Typische Audit-Fragen lauten: Wie stellen Sie sicher, dass nur berechtigte Personen Zugriff auf kritische Systeme haben? Wie werden privilegierte Aktionen protokolliert? Wie werden Ausnahmen genehmigt und cberwacht?

Ein auditfestes Zero-Trust-Programm produziert Evidence-Artefakte „by design“:

• Policy-Versionen mit Freigabeprotokoll (Wer, wann, warum)
• Systemreports: MFA-Abdeckung, PAM-Nutzung, Gerte-Compliance
• Ticket-Evidence: Ausnahmen mit Ablaufdatum, Reviews, Risk Acceptance
• Protokolle: Admin- und Auth-Logs, zentrale Retention und Zugriffsschutz fr Logs (damit Logs selbst nicht manipulierbar sind)

Hinweis aus der Praxis: Auditoren akzeptieren Ausnahmen eher, wenn (1) die Ausnahme befristet ist, (2) eine Kompensationsmanahme dokumentiert ist und (3) die Organisation zeigen kann, dass sie Ausnahmen aktiv abbaut (Metrik: „Ausnahmen cberfllig“).

Kosten, Aufwand und Betriebsfolgen: Wo Zero Trust real Ressourcen bindet

Zero Trust hat Kosten, aber viele entstehen nicht als Lizenz, sondern als Betriebs- und Projektaufwand. Wer das nicht einplant, erzeugt Frust und Schatten-IT. Die wesentlichen Kostentreiber:

• Identittsdaten-Qualitt: Berechtigungsmodelle, Rollenpflege, Ownership (wer ist fr ein Konto verantwortlich?).
• Applikationsnacharbeit: Legacy-Anwendungen ohne moderne Authentisierung oder mit hartkodierten Konten erfordern Anpassungen oder vorgeschaltete Gateways.
• Service Desk und Kommunikation: MFA-Reset, Gerte-Enrollment, Ausnahmeprozesse. Gute Self-Service-Flows senken diese Last spter deutlich.
• Monitoring und Incident Response: Mehr Signale bedeuten mehr Triage. Ohne Use-Case-Priorisierung wird das SOC (Security Operations Center) cberlastet.

Gleichzeitig entstehen betriebliche Vorteile, wenn sauber umgesetzt: weniger langfristige Admin-Rechte, klarere Zugriffspfade, schnellere Deprovisionierung, bessere Nachvollziehbarkeit bei Incidents. Diese Vorteile sollten Sie als Entscheidungskriterium explizit machen, nicht als „Nebenprodukt“ erwarten.

Checkliste: Startklar in 30 Tagen (ohne groe Architekturdebatte)

Die folgenden Punkte sind so gewhlt, dass sie cberwiegend Governance und Grundlagen adressieren und schnell Wirkung entfalten:

• Executive Sponsor benennen, Steering-Terminserie fr 6 Monate festlegen
• Zero-Trust-Programmleitung und Owners fr IAM, PAM, Endpoint, Netzwerk/SIEM offiziell machen
• Top-10 kritische Systeme und Datenbereiche definieren (kann an bestehende Schutzbedarfs- oder Risikolisten ankncpfen)
• Minimal-Policy-Satz verabschieden: MFA, Admin-Zugriff cber PAM, Gerte-Compliance fr kritische Zugriffe, Ausnahmeprozess mit Sunset
• Erste KPI-Baseline ziehen: MFA-Abdeckung, verwaiste Konten, Break-Glass-Nutzung, Gerte-Compliance
• Audit-Evidence-Ort festlegen: wo liegen Policy-Versionen, Reports, Ausnahme-Tickets, Lognachweise?

Hufige Stolpersteine und wie Sie sie vermeiden

„Wir machen erst die perfekte Zielarchitektur“

Ein Zielbild ist wichtig, aber Zero Trust ist ein iteratives Betriebsmodell. Starten Sie mit konturierten Minimal-Policies und messen Sie Effekte. Architektur reift mit den Erkenntnissen aus Ausnahmen, Incidents und Betriebsdaten.

„MFA cberall“ als alleinige Strategie

MFA ist notwendig, aber nicht hinreichend. Ohne PAM, Gerte-Compliance und Logging bleibt das Risiko durch Token-Diebstahl, Fehlkonfigurationen und cberprivilegierte Konten hoch.

Unklare Verantwortlichkeit fr Service-Accounts und Schnittstellen

Service-Accounts sind oft „herrenlos“. Legen Sie Ownership und Rotation fest, sonst bleibt ein dauerhafter Seiteneingang. Das gilt besonders fr Integrationen zwischen Business-Software, Datenbanken und Schnittstellenplattformen.

Zu viele Ausnahmen ohne Sunset

Eine Ausnahme ohne Ablaufdatum ist eine versteckte Policy-berschreibung. Messen Sie cberfllige Ausnahmen und machen Sie sie im Steering sichtbar.

Fazit: Zero Trust ist ein Steuerungsproblem mit technischen Hebeln

Eine Zero-Trust-Strategie scheitert selten, weil „die Technik nicht kann“, sondern weil Entscheidungen nicht sauber verankert sind: Wer setzt Policies fest, wer trgt Risiken, wer liefert Nachweise? Wenn Sie Rollen (Owners), RACI und einen schlanken Satz an Metriken definieren, wird Zero Trust planbar: Ausnahmen werden kontrolliert, Betrieb wird nicht cberfahren, und Audit-Anforderungen lassen sich mit belastbarer Evidence bedienen.

Beginnen Sie mit Identitt, privilegierten Zugriffen und Gerte-Compliance, etablieren Sie einen strikten Ausnahmeprozess mit Sunset und bauen Sie Ihr KPI-Set so, dass es Entscheidungen trgt. Dann wird „Zero Trust“ vom Schlagwort zur operativen Realitt in Ihrer IT.