Ein Rechner, zwei Tabs, ein Klick
Das Szenario ist unspektakulär, und genau das macht es so gefährlich: Ein Administrator sitzt an seinem gewohnten Office-Laptop. Im linken Browser-Tab ist das Microsoft 365 Admin Center geöffnet, Global-Admin- und Intune-Adminrechte inklusive. Im rechten Tab lädt er ein „kostenloses Tool“ herunter, Invoice_2026.pdf.exe. Ein Klick, ein PowerShell-Payload, Persistenz etabliert, Privilege Escalation läuft. Der Weg zu Tier 0, zum Herzstück der Unternehmens-IT, ist offen.
Game Over.
MITRE ATT&CK dokumentiert für Enterprise-Umgebungen aktuell 222 Techniken, dazu 475 Sub-Techniken, zusammen knapp 700 bekannte Wege, um Privilegien zu eskalieren, sich lateral zu bewegen und die sensibelsten Assets eines Unternehmens zu erreichen. Angreifer brauchen davon genau einen. Und in den meisten Incident-Response-Einsätzen, die wir begleiten, zeigt sich dasselbe Muster: Administriert wurde auf demselben Gerät, auf dem auch E-Mails gelesen, gesurft und in Teams gechattet wurde.
Wer „Assume Breach“ ernst meint, und nach NIS2 gibt es dazu wenig Alternativen, muss eine unbequeme Konsequenz akzeptieren: Manche Dinge gehören einfach nicht auf denselben Rechner. Halbe Trennung ist keine Trennung.
Warum die naheliegenden Antworten nicht reichen
Die üblichen Reflexe kennen wir alle. Jump-Server? Ein Reverse-Proxy-Tunnel vom kompromittierten Client, und der Angreifer reitet direkt durch die Jump-Box hindurch: gleiche Maschine, gleicher Browser, gleiches Risiko. Klassisches Privileged Access Management (PAM) im eigenen Tenant aufbauen? Dann stellt sich sofort die Frage: Wer managt die Management-Umgebung? Wenn die geschützten Admin-Workstations im selben Tenant leben, den sie schützen sollen, hat man einen Kreis gebaut, keine Mauer. Und der virtuelle Desktop vom Office-Laptop aus? Der erbt dessen Keylogger. Der Bildschirm ist virtuell, die Tastenanschläge sind echt. Zero Trust endet genau dort, wo Admin und Alltag sich ein Gerät teilen.
Der Managed Red Tenant: Separation als Architektur
Genau hier setzt der Managed Red Tenant (MRT) an: eine dedizierte, vollständig per Code gemanagte und massiv gehärtete Tenant-Umgebung, ausschließlich für administrative Arbeit. Für Tier-0-Aufgaben stehen als Managed Service betriebene Privileged Access Workstations (PAW) bereit, gehärtete Hardware-PAWs als eigene physische Geräte. Für Tier-1-Arbeit dienen VAWs, virtuelle Access Workstations auf Basis von Azure Virtual Desktop, erreichbar nur von compliant Devices, nur mit FIDO2, nur unter Conditional Access. Ergänzt um speziell und maximal sicher konfigurierte iPads für mehr Komfort.
Der entscheidende Punkt für CIOs ist aber nicht die Technik, sondern das Betriebsmodell. Jede Änderung am Red Tenant läuft als Configuration as Code durch eine CI/CD-Pipeline und wird erst nach expliziter Freigabe durch den Kunden deployt. Dieses Shared-Responsibility-Prinzip beantwortet die Frage, die jeder Einkäufer von Managed Services stellen sollte: Was passiert, wenn der Dienstleister selbst kompromittiert wird? Die Antwort: nichts. Ohne Kundenfreigabe ändert sich im Red Tenant keine Zeile Konfiguration. Die Management-Ebene liegt außerhalb der Risikozone des Kunden, das Vetorecht bleibt beim Kunden.
Der operative Gewinn ist doppelt. Erstens entsteht eine Trennschärfe, wie man sie selten hat: Jeder legitime administrative Zugriff auf die Produktionsumgebung kommt per Definition von einer MRT-Maschine. Alles andere ist ein Angriff. Das gibt dem SOC ein Signal ohne Rauschen, auf das es sofort reagieren kann, statt Fehlalarme zu sortieren. Zweitens steht bei einem erfolgreichen Angriff auf die Office-Umgebung eine Mauer im Weg, keine Bodenschwelle: Der Sprung von einem kompromittierten Office-Laptop auf eine Hardware-PAW, die als eigenes Gerät daneben auf dem Schreibtisch steht, ist für Angreifer extrem schwer bis unmöglich.
Und wenn es trotzdem passiert? Das Extra Life.
Jeder erfahrene CIO weiß: Hundertprozentige Sicherheit gibt es nicht. Assume Breach heißt eben auch, das Scheitern der eigenen Verteidigung einzuplanen. Der Stryker-Vorfall im März 2026 hat gezeigt, wie schmal der Grat ist: ein kompromittiertes Intune-Admin-Konto genügte, um Geräte in 79 Ländern zu löschen. Ransomware-Gruppen zielen heute gezielt auf Backups, auf Active Directory, auf genau die Systeme, die man für den Wiederaufbau bräuchte. Wer dann anfängt zu improvisieren, mit verschlüsselten Fileservern, ohne funktionierende Identitäten, mit einer Telefonkette statt Kommunikationsinfrastruktur, verliert Tage und Wochen, in denen das Unternehmen stillsteht.
Wenn der Red Tenant verhindert, dass es „Game Over“ heißt, dann ist der Managed Dark Tenant das Extra Life: eine vorbereitete, im Normalbetrieb ruhende Wiederanlauf-Umgebung, die im Ernstfall aktiviert wird. Ein Anruf bei der 24/7-Notfallnummer startet den Disaster-Recovery-Prozess. Ein virtueller War Room stellt sofort sichere Kommunikation mit allen Schlüssel-Stakeholdern her, unabhängig von der möglicherweise kompromittierten Produktionsumgebung. Weil der Dark Tenant als Infrastructure as Code aufgebaut ist, sind alle kritischen Wiederanlauf-Prozesse vordefiniert und automatisiert: Systemkritische Komponenten wie Active Directory und Identitäten werden sauber wiederhergestellt, statt in der Stresssituation ad hoc zusammengebaut zu werden. Das Ergebnis: eine Recovery Time Objective (RTO) von wenigen Stunden bis wenigen Tagen und ein definiertes Recovery Point Objective (RPO), statt der Wochen, die improvisierte Wiederanläufe in der Praxis regelmäßig kosten.
Resilienz im Doppelpack
Red Tenant und Dark Tenant beantworten zwei verschiedene Fragen, die zusammen erst ein vollständiges Bild ergeben. Der Red Tenant beantwortet: Wie verhindere ich, dass ein kompromittierter Client jemals zur kompromittierten Domäne wird? Der Dark Tenant beantwortet: Wie bleibe ich handlungsfähig, wenn es trotzdem passiert? Das eine ist die Mauer, das andere das Sprungtuch.
Für österreichische Unternehmen kommt eine regulatorische Dimension hinzu, und die wird bald sehr konkret. Mit dem NISG 2026, das am 1. Oktober 2026 in Kraft tritt, fallen rund 4.000 österreichische Unternehmen unter nachweisbare Cybersicherheitspflichten, explizit inklusive Risikomanagement, Business Continuity, Notfallplan und Krisenmanagement. Wer dem Aufsichtsgremium erklären kann, dass administrative Zugriffe architektonisch isoliert sind und für den Ernstfall eine getestete, automatisierte Wiederanlauf-Umgebung bereitsteht, führt eine andere Diskussion als jemand, der auf Awareness-Schulungen und Hoffnung verweist.
Beide Services betreiben wir als Managed Service, mit einem Team, das als BSI-qualifizierter APT-Response-Dienstleister regelmäßig auf der anderen Seite steht, wenn es bereits brennt, und diese Erfahrung direkt in die Architektur zurückfließen lässt. Zu unseren Kunden zählen DAX-Konzerne ebenso wie Betreiber kritischer Infrastrukturen.
Manche Dinge gehören nicht auf denselben Rechner. Und manche Unternehmen können sich kein Game Over leisten. Dann besser mit Mauer und Extra Life.
