Zero Trust Architektur im KMU umsetzen

Warum “Vertraue niemandem” kein Marketing-Slogan ist

Zero Trust ist eines der am meisten missbrauchten Buzzwords der IT-Security-Branche. Jeder Hersteller klebt es auf seine Firewall-Box, sein VPN-Produkt oder sein Cloud-Dashboard. Dabei ist Zero Trust kein Produkt, sondern ein Architekturprinzip: Kein Nutzer, kein Gerät und kein Dienst wird allein deshalb als vertrauenswürdig eingestuft, weil er sich “im Netzwerk” befindet.

Das klassische Sicherheitsmodell – harte Schale, weicher Kern – ging davon aus, dass alles innerhalb der Firmenfirewall sicher ist. Wer erst mal drin war (per VPN, per Kabel im Büro, per Active-Directory-Domain-Join), durfte sich relativ frei bewegen. Genau dieses Modell bricht seit Jahren reihenweise zusammen: Homeoffice, SaaS-Dienste, BYOD und Lieferketten-Angriffe haben den “Perimeter” aufgelöst. Ein kompromittierter Laptop im Homeoffice ist heute der Normalfall, nicht die Ausnahme.

Das US-amerikanische NIST hat die Prinzipien in der Publikation SP 800-207 sauber definiert. Kernaussage: Vertrauen wird nie implizit anhand von Netzwerkstandort, IP-Adresse oder Domain-Mitgliedschaft vergeben, sondern für jede einzelne Zugriffsanfrage explizit und im Kontext bewertet – Nutzeridentität, Gerätezustand, Standort, Risikosignale und die angefragte Ressource fliessen jedes Mal neu in die Entscheidung ein.

Die drei NIST-Grundprinzipien im Detail

NIST SP 800-207 definiert Zero Trust über sieben Kerntenets, die sich in der Praxis auf drei handlungsleitende Prinzipien verdichten lassen:

1. Verify Explicitly (Explizit verifizieren)

Jede Zugriffsanfrage wird anhand aller verfügbaren Datenpunkte authentifiziert und autorisiert – nicht nur einmalig beim Login, sondern kontinuierlich. Zu den Signalen gehören:

• Identität: Wer ist der Benutzer, welcher Rolle gehört er an, wie war sein Anmeldeverhalten in der Vergangenheit?
• Gerätezustand: Ist das Gerät compliant (verschlüsselt, gepatcht, mit EDR ausgestattet), domänenverbunden, Entra-registriert oder komplett unbekannt?
• Standort und Netzwerk: Anmeldung aus der Schweiz, aus einem bekannten Firmenbüro, oder aus einem Land, in dem das Unternehmen nie Mitarbeitende hat?
• Anwendung und Datenklassifizierung: Greift der Benutzer auf eine öffentliche SharePoint-Seite zu oder auf die Lohnbuchhaltung?
• Echtzeit-Risikosignale: Meldet Microsoft Entra ID Protection ein “unmögliches Reisemuster” oder anonyme IP-Adressen (Tor, bekannte Malware-Proxys)?

In der Microsoft-Welt ist Conditional Access genau der Mechanismus, der diese Signale zusammenführt und in eine Access-Entscheidung übersetzt. Dazu gleich mehr im Detail.

2. Least Privilege Access (Minimale Berechtigung)

Jede Identität – ob Mensch, Dienstkonto oder Workload – bekommt nur genau die Rechte, die für die konkrete Aufgabe nötig sind, und zwar zeitlich begrenzt (Just-in-Time statt Standing Access). In der Praxis heisst das: Kein Domain-Admin-Konto für den täglichen E-Mail-Check, keine dauerhafte Global-Admin-Rolle in Microsoft 365, sondern Privileged Identity Management (PIM) mit zeitlich befristeter Rollenaktivierung und Genehmigungspflicht.

3. Assume Breach (Von der Kompromittierung ausgehen)

Die vielleicht wichtigste Denkverschiebung: Du gehst davon aus, dass ein Angreifer bereits im Netzwerk ist oder es sein wird – sei es über einen Phishing-Klick, eine kompromittierte Lieferkette oder ein ungepatchtes Gerät. Die Architektur wird so gebaut, dass ein einzelner kompromittierter Endpunkt oder ein einzelnes gestohlenes Konto nicht automatisch Zugriff auf alles andere ermöglicht. Das erreichst du durch:

• Mikrosegmentierung des Netzwerks (siehe unten)
• Verschlüsselung von Daten im Ruhezustand und bei der Übertragung
• Durchgehendes Logging und Monitoring, um laterale Bewegung schnell zu erkennen
• Regelmässige Übungen: “Was passiert, wenn dieses eine Konto jetzt kompromittiert ist?”

Identity als neuer Perimeter

In einer klassischen Netzwerkarchitektur war die Firewall der Perimeter. In Zero Trust übernimmt die Identität diese Rolle: Der Nachweis, wer du bist und in welchem Zustand sich dein Gerät befindet, ersetzt den Nachweis “ich bin physisch im Bürogebäude” oder “ich bin per VPN eingewählt”.

Das hat handfeste Konsequenzen für die Architektur:

Der Dreh- und Angelpunkt dafür ist in den meisten Schweizer KMU Microsoft Entra ID (ehemals Azure AD), weil M365 ohnehin fast überall im Einsatz ist. Die Identität wird dabei nicht nur beim Login geprüft, sondern durch Continuous Access Evaluation nahezu in Echtzeit überwacht: Wird ein Benutzerkonto deaktiviert oder als kompromittiert markiert, kann ein aktives Access-Token innerhalb von Minuten statt erst nach Ablauf (klassisch bis zu 60–90 Minuten) widerrufen werden.

Conditional Access als Durchsetzungspunkt

Conditional Access (CA) ist in der Microsoft-Welt der zentrale Policy Enforcement Point: Bei jeder Anmeldung an Entra ID werden Signale ausgewertet und eine Regel (“wenn X, dann Y”) angewendet. Eine CA-Regel besteht immer aus Bedingungen (Zuweisungen) und Massnahmen (Kontrollen):

Typische Bedingungen (wer/was/wo):

• Benutzer oder Gruppen (z. B. “alle ausser Notfallkonten”)
• Cloud-Apps oder Aktionen (z. B. “Office 365”, “Azure-Verwaltung”)
• Gerätezustand (compliant über Intune, hybrid-joined)
• Standort (Named Locations, z. B. Firmenbüro-IP-Range oder “Schweiz”)
• Anmelderisiko und Benutzerrisiko (aus Entra ID Protection)
• Client-App-Typ (Browser, moderne App, Legacy-Auth)

Typische Massnahmen (was passiert dann):

• MFA erzwingen
• Compliant-Gerät oder Hybrid-Join-Gerät verlangen
• Passwortänderung erzwingen
• Zugriff komplett blockieren
• Sitzungsdauer begrenzen / Sign-in-Frequenz erhöhen
• App-erzwungene Einschränkungen (z. B. kein Download auf nicht verwalteten Geräten)

Praxisbeispiel: Basis-Policy-Set für ein KMU mit ~80 Mitarbeitenden

Ein bewährter Einstieg orientiert sich an den von Microsoft bereitgestellten Conditional-Access-Vorlagen (“Zero Trust”-Kategorie) und lässt sich so grob nachbauen:

Als Skript lässt sich das u. a. über Microsoft Graph PowerShell prüfen und pflegen:

# Microsoft Graph PowerShell SDK verbinden
Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"

# Alle bestehenden Conditional-Access-Policies auflisten
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State

# Neue Policy: Legacy-Authentifizierung fuer alle blockieren
$params = @{
    DisplayName = "CA001 - Block Legacy Authentication"
    State = "enabledForReportingButNotEnforced"
    Conditions = @{
        Users = @{ IncludeUsers = @("All") }
        Applications = @{ IncludeApplications = @("All") }
        ClientAppTypes = @("exchangeActiveSync", "other")
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("block")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Ein Break-Glass-Konto legst du typischerweise so an:

# Notfallkonto anlegen (Cloud-only, sehr langes zufaelliges Passwort)
New-MgUser -DisplayName "BreakGlass-Emergency-01" `
  -UserPrincipalName "breakglass1@contoso.onmicrosoft.com" `
  -AccountEnabled `
  -PasswordProfile @{ Password = "K9#mP2$xL8vQ4wZ7nR3tY6uJ1sB!" ; ForceChangePasswordNextSignIn = $false } `
  -MailNickname "breakglass1"

Mikrosegmentierung: Vom flachen Netz zur echten Isolation

Während Conditional Access den Identitäts-Layer absichert, sorgt Mikrosegmentierung dafür, dass ein kompromittiertes System sich nicht ungehindert im Netzwerk ausbreiten kann. Klassische KMU-Netze sind oft “flach”: Ein einziges VLAN für alle Clients, Server im gleichen Subnetz wie die Drucker, und der Buchhaltungs-PC kann per Definition jeden anderen Host im Haus per SMB erreichen.

Zero Trust verlangt das Gegenteil: Jedes Segment – idealerweise jeder einzelne Workload – bekommt eine eigene Vertrauenszone, und Kommunikation zwischen Zonen wird explizit erlaubt statt implizit zugelassen (“Default Deny”).

Segmentierungsstufen in der Praxis

1. Makrosegmentierung (Einstieg): Trennung nach Funktionsbereich per VLAN – Clients, Server, Gäste-WLAN, IoT/Drucker, Management-Netz jeweils eigenes VLAN mit Layer-3-Firewall-Regeln dazwischen.
2. Mikrosegmentierung auf Host-Ebene: Innerhalb eines Server-VLANs dürfen z. B. Webserver nur auf den Datenbankserver zugreifen, aber nicht der Fileserver auf den Domain Controller auf Port 445.
3. Identitätsbasierte Mikrosegmentierung: Mit Software-Defined-Networking- oder Endpoint-Firewall-Lösungen (z. B. Windows Defender Firewall mit IPsec-Regeln, oder dedizierte Mikrosegmentierungs-Tools) wird der Zugriff nicht mehr per IP, sondern per Maschinenidentität/Zertifikat gesteuert – das funktioniert auch, wenn sich IP-Adressen per DHCP ändern.

Beispiel: Windows Firewall mit IPsec-Isolation (kostenloser Einstieg)

Ohne teure Zusatzsoftware lässt sich ein Grundmass an Mikrosegmentierung bereits mit Windows Defender Firewall und IPsec-Domänenisolation umsetzen: Nur domänenauthentifizierte Geräte dürfen bestimmte Ports untereinander ansprechen.

# Eingehende Regel: SMB (445) nur von domaenenauthentifizierten Rechnern erlauben
New-NetFirewallRule -DisplayName "SMB nur Domain-Auth" `
  -Direction Inbound -Protocol TCP -LocalPort 445 `
  -Authentication Required `
  -Action Allow

# RDP nur aus dem Management-Subnetz erlauben
New-NetFirewallRule -DisplayName "RDP nur Mgmt-Subnetz" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress 10.10.50.0/24 `
  -Action Allow

# Alles andere auf dem Server-VLAN explizit blockieren (Default Deny)
Set-NetFirewallProfile -Profile Domain -DefaultInboundAction Block

Netzwerksegmentierung mit VLANs und ACLs (Switch-Ebene)

! Beispiel: VLANs auf einem Layer-3-Switch anlegen
vlan 10
 name CLIENTS
vlan 20
 name SERVER
vlan 30
 name IOT-DRUCKER
vlan 99
 name MGMT

! ACL: Clients duerfen NICHT direkt auf Management-VLAN zugreifen
ip access-list extended BLOCK-CLIENT-TO-MGMT
 deny ip 10.10.10.0 0.0.0.255 10.10.99.0 0.0.0.255
 permit ip any any
interface Vlan10
 ip access-group BLOCK-CLIENT-TO-MGMT in

Mehr zur Netzwerktrennung findest du in VLAN Grundlagen und Firewall Grundlagen.

Assume Breach in der Praxis: Von der Theorie zur Übung

“Assume Breach” bleibt abstrakt, solange es nicht durchgespielt wird. Ein bewährtes Format sind Tabletop-Übungen: Ein fiktives Szenario (“Der Laptop des Buchhalters wurde per Phishing kompromittiert”) wird gemeinsam mit IT, Geschäftsleitung und ggf. externem Dienstleister durchgespielt – rein am Konferenztisch, ohne echten Angriff.

Fragen, die eine solche Übung beantworten muss:

• Wie schnell würde die Kompromittierung überhaupt auffallen (Detection)?
• Auf welche Systeme hätte der Angreifer mit den Rechten dieses einen Kontos Zugriff (Blast Radius)?
• Können wir das Konto innerhalb von Minuten sperren und aktive Sitzungen widerrufen?
• Gibt es ein sauberes, unveränderliches Backup, das nicht vom gleichen Konto aus erreichbar/löschbar ist?
• Wer trifft die Entscheidung, betroffene Systeme vom Netz zu nehmen, und wer darf das operativ ausführen?

Diese Fragen führen direkt zu konkreten technischen Massnahmen: Conditional Access mit Continuous Access Evaluation für schnellen Entzug, Mikrosegmentierung für einen kleinen Blast Radius, und unveränderliche Backups (Immutable Storage), die selbst ein Domain-Admin-Konto nicht löschen kann.

Entscheidungsbaum: Wo fange ich im KMU an?

Nicht jedes KMU braucht sofort SASE, Mikrosegmentierung und ein eigenes SOC. Der folgende Ablauf hat sich als realistische Reihenfolge bewährt:

Start: Wo steht die Organisation heute?
│
├─ Ist MFA fuer ALLE Konten (inkl. Admins) aktiv?
│   ├─ NEIN → Schritt 1: MFA flaechendeckend einfuehren (Security Defaults
│   │         oder Conditional Access), Legacy-Auth blockieren
│   └─ JA ↓
│
├─ Gibt es dokumentierte Conditional-Access-Policies mit Geraetecheck?
│   ├─ NEIN → Schritt 2: Intune-Compliance-Policies + CA "Compliant Device"
│   │         fuer M365-Zugriff einfuehren
│   └─ JA ↓
│
├─ Sind privilegierte Rollen (Admin) zeitlich befristet (PIM/JIT)?
│   ├─ NEIN → Schritt 3: Entra PIM einfuehren, Standing Admin-Accounts
│   │         abschaffen
│   └─ JA ↓
│
├─ Ist das interne Netzwerk in Zonen segmentiert (Clients/Server/IoT)?
│   ├─ NEIN → Schritt 4: VLAN-Segmentierung + Default-Deny-ACLs einfuehren
│   └─ JA ↓
│
└─ Gibt es zentrales Logging + Alerting fuer Anomalien?
    ├─ NEIN → Schritt 5: SIEM/Log-Aggregation aufbauen, Continuous
    │         Access Evaluation aktivieren
    └─ JA → Zero-Trust-Reifegrad fortgeschritten: Feintuning,
             Mikrosegmentierung vertiefen, regelmaessige Tabletop-Uebungen

Realistischer Umsetzungsplan über 12 Monate

Zero Trust Network Access (ZTNA) statt klassisches VPN

Ein oft unterschätzter Baustein: Klassische Site-to-Site- oder Client-VPNs gewähren nach der Anmeldung meist pauschalen Netzwerkzugriff – genau das Gegenteil von Zero Trust. ZTNA-Lösungen (z. B. Microsoft Entra Private Access, Cloudflare Access, Zscaler Private Access) ersetzen das Konzept “VPN-Tunnel ins ganze Netz” durch anwendungsspezifische, identitätsbasierte Tunnel: Der Benutzer bekommt nur Zugriff auf die eine freigegebene Anwendung, nicht auf das gesamte Subnetz dahinter.

Für viele Schweizer KMU, die bereits M365 nutzen, ist Microsoft Entra Private Access ein pragmatischer Umstieg, weil dieselben Conditional-Access-Policies wiederverwendet werden können, die auch für SaaS-Zugriffe gelten.

Häufige Fallstricke bei der Umsetzung

• Ausnahmen häufen sich an, bis die Policy zahnlos ist. Jede Ausnahme (“der Chef will kein MFA”) muss dokumentiert, befristet und regelmässig überprüft werden – sonst wächst eine Schatten-Whitelist, die die ganze Architektur untergräbt.
• Break-Glass-Konten werden vergessen. Sie brauchen eigene Monitoring-Alarme (jede Anmeldung mit diesem Konto sollte sofort eine Warnung auslösen) und müssen regelmässig getestet werden.
• Mikrosegmentierung ohne Asset-Inventar. Ohne zu wissen, welche Geräte überhaupt im Netz hängen und wie sie kommunizieren müssen, führt Default-Deny zu Betriebsausfällen. Ein sauberes IT-Dokumentation & Inventar ist Voraussetzung, kein Nice-to-have.
• Legacy-Anwendungen, die kein modernes Auth können. Alte ERP- oder Fachanwendungen mit Basic Auth oder ohne SAML/OIDC-Unterstützung sind der klassische Bruch in der Kette – hier hilft oft ein Application Proxy oder eine schrittweise Ablösung.
• Conditional Access als reines IT-Projekt behandeln. Ohne Kommunikation an die Belegschaft (warum jetzt plötzlich MFA-Prompts, warum wird der private Laptop nicht mehr akzeptiert) sinkt die Akzeptanz und der Druck auf Ausnahmen steigt.

Kurz-Checkliste für den Einstieg

• MFA für alle Konten aktiv, Legacy-Authentifizierung blockiert
• Mindestens ein Break-Glass-Notfallkonto ausserhalb aller CA-Policies angelegt
• Conditional-Access-Policies zuerst im Report-Only-Modus getestet
• Intune-Compliance-Policies für Gerätecheck aktiv
• Privilegierte Rollen über PIM zeitlich befristet statt dauerhaft
• Netzwerk mindestens in Clients/Server/IoT-VLANs getrennt
• Backup-Infrastruktur logisch und per Konto isoliert vom Produktivnetz
• Zentrales Logging vorhanden, um laterale Bewegung erkennen zu können
• Jährliche Tabletop-Übung “Assume Breach” eingeplant

Weiterlernen

• NIST SP 800-207 – Zero Trust Architecture (Originalpublikation)
• Microsoft Entra Conditional Access: Zero Trust Policy Engine
• Microsoft: Zero Trust Deployment Guidance
• Microsoft Entra Conditional Access Deployment planen
• Microsoft Entra Private Access (ZTNA)
• BACS – Schutzmassnahmen für Unternehmen (Bundesamt für Cybersicherheit)

Verwandte Themen: IT-Security Grundlagen für KMU · Entra ID Grundlagen · Entra PIM & Governance · VLAN Grundlagen · Firewall Grundlagen · AD Security Hardening & Tier Model

Videos

YouTube

YouTube