Ein Account.
Alles weg?
Nicht zwangsläufig.
NIS2 schreibt zehn Risikomaßnahmen vor. Mit Managed Red Tenant und Dark Tenant unterstützen wir bei der technischen Umsetzung. Für ein signifikant reduziertes Angriffsrisiko und die Gewissheit, im Ernstfall in Stunden wieder handlungsfähig zu sein.
Das Interessante am Stryker-Angriff vom 11. März 2026 ist nicht die Zahl der betroffenen Geräte, obwohl 80.000 Geräte in 79 Ländern eine eindrückliche Zahl ist, sondern die Banalität des Mittels: kein Exploit, kein Zero-Day, kein ausgeklügelter Angriff auf Infrastrukturkomponenten, die nur wenige kennen. Ein einziger kompromittierter Intune-Admin-Account reichte aus, und der Angriff sah von außen aus wie normaler Betrieb, weil er das im technischen Sinne war, nur von jemand anderem ausgeführt. Was genau passiert ist, steht im Blogbeitrag zum Stryker-Angriff.
Die meisten Unternehmensinfrastrukturen sind so gebaut, dass dieser Schaden möglich ist, nicht weil die Verantwortlichen nachlässig gewesen wären, sondern weil privilegierte Accounts mit weitreichenden Rechten über Jahre hinweg als praktisch galten: ein Konto, das überall Zugriff hat, spart in der täglichen Arbeit Zeit, und Zeit ist in IT-Abteilungen bekanntlich das Einzige, was noch knapper ist als Budget. Was NIS2 Artikel 21 abstrakt als Risikomaßnahme beschreibt, hat in der Praxis eine konkrete Konsequenz: Privilegierte Identitäten müssen so geschützt sein, dass ihre Kompromittierung nicht die gesamte Infrastruktur mit sich reißt, und die Business-Continuity-Strategie muss einen robusten Notfallbetrieb gewährleisten, der im Ernstfall in Stunden greift.
Was NIS2 ist und wen die Richtlinie betrifft, erklären wir hier. Auf dieser Seite geht es um die technische Umsetzung dieser zwei Anforderungen mit Managed Red Tenant und Managed Dark Tenant.
Managed Red Tenant: damit ein kompromittierter Account nicht zum Generalschlüssel wird
Das Angriffsmuster, das beim Stryker-Vorfall funktioniert hat, ist kein neues: Angreifer kompromittieren einen Account, der ihnen Zugriff auf privilegierte Systeme verschafft, bewegen sich von dort zur restlichen Infrastruktur und richten den Schaden an, für den sie die meisten Berechtigungen haben. Es funktioniert so zuverlässig, weil in den meisten Unternehmen keine strukturelle Trennung zwischen normalen Arbeitsumgebungen und den administrativen Zugängen existiert, die tatsächlich zur Übernahme der gesamten Infrastruktur ausreichen würden.
Managed Red Tenant unterbricht dieses Muster, indem er administrative Identitäten und die dazugehörigen Endgeräte in einen vollständig separierten Microsoft-Tenant überführt, mit eigenen Entra-ID-Konten, eigenen gehärteten Geräten und keiner Netzwerkverbindung zur Produktivumgebung, die ein Angreifer über Lateral Movement nutzen könnte. Wer von einem kompromittierten Standardarbeitsplatz aus versucht, sich zu den kritischen Systemen vorzuarbeiten, findet an dieser Stelle eine Grenze vor, die es vorher nicht gab.
Zu Managed Red TenantManaged Dark Tenant: die vorbereitete Umgebung für den Fall, der nicht eintreten soll, aber kann
Nach einem großflächigen Ransomware-Angriff zerfallen die Probleme, die ein Unternehmen zu bewältigen hat, in zwei Kategorien: die technischen, die lösbar sind, wenn auch nicht schnell, und die organisatorischen, bei denen niemand vorher festgelegt hat, wer im Ernstfall was tut, in welcher Reihenfolge entschieden wird und auf welcher Grundlage überhaupt kommuniziert werden kann, wenn die eigene Infrastruktur nicht mehr vertrauenswürdig ist. Coveware misst die durchschnittliche Ausfallzeit nach einem Ransomware-Angriff auf 24 Tage, und die Erfahrung aus Vorfällen zeigt, dass die Zeit nicht hauptsächlich an fehlenden technischen Mitteln scheitert, sondern daran, dass Prozesse, die man im Normalbetrieb nie braucht, unter extremem Druck zum ersten Mal erfunden werden müssen.
Managed Dark Tenant ist eine vorprovisionierte, vollständig isolierte Microsoft-Umgebung, die im Ernstfall über eine 24/7-Hotline aktiviert wird und dem Krisenteam innerhalb weniger Stunden einsatzbereite Kommunikation, Windows-365-Arbeitsplätze und eine AD-Recovery-Pipeline bereitstellt, alles auf Basis von Infrastructure as Code, alles bereits definiert und getestet, bevor es gebraucht wird. Das Architekturprinzip dahinter heißt Minimum Viable Company: Kommunikation zuerst, dann kritische Dokumente, dann Kernanwendungen, in einer Reihenfolge, die vorher festgelegt und regelmäßig in Fire Drills erprobt wurde.
Zu Managed Dark TenantWir unterstützen bei der technischen Umsetzung bei sieben der zehn Risikomaßnahmen aus NIS2 Artikel 21.
| Risk Measures | GK Services | NIS2 | CSOC | APT Response | Preventive Services | Managed Red Tenant | Managed Dark Tenant | Data Security | Workplace / Azure |
|---|---|---|---|---|---|---|---|---|
| Risk Analysis and Information System Security | 21.2 a) | |||||||
| Incident Handling | 21.2 b) | NEU | NEU | |||||
| Business Continuity | 21.2 c) | NEU | ||||||
| Supply Chain Security | 21.2 d) | NEU | ||||||
| Security in Network and Information Systems | 21.2 e) | |||||||
| Effectiveness of Cybersecurity Risk Management Measures | 21.2 f) | NEU | NEU | |||||
| Basic Computer Hygiene Practices and Cybersecurity Training | 21.2 g) | |||||||
| Cryptography | 21.2 h) | |||||||
| Human Resources Security, Access Control Policies and Asset Management | 21.2 i) | NEU | ||||||
| Multifactor Authentication or Secured Communication | 21.2 j) | NEU |
So setzen wir Red und Dark Tenant bei dir auf
- Assessment und ArchitekturAssessment und ArchitekturGemeinsam identifizieren wir, welche Identitäten und Workloads zu Tier 0 und Tier 1 gehören, und legen die Minimum Viable Company fest, also die kritischen Prozesse und Kommunikationswege, die im Ernstfall als erstes wiederhergestellt werden müssen. Das Ergebnis ist ein Architekturentwurf für beide Tenants, abgestimmt auf vorhandene Microsoft-Lizenzen, bestehende Krisenprozesse und die Active-Directory-Topologie des Kunden.
- Deployment auf Basis von Infrastructure as CodeDeployment auf Basis von Infrastructure as CodeBeide Tenants werden aus unseren bewährten Blueprints provisioniert, jede Konfiguration ist als Code definiert, auditierbar und im Zweifelsfall rückverfolgbar, und jede Änderung durchläuft einen mehrstufigen Test-Prozess mit eigenen Pre-Tenants, bevor sie in der Produktivumgebung landet. Produktive Anpassungen erfordern ein explizites Approval, weil bei hochprivilegierten Umgebungen Kontrolle über jede Änderung keine bürokratische Eigenart ist, sondern Sicherheitsarchitektur.
- 24/7 Operate und Fire Drills24/7 Operate und Fire DrillsDas CSOC überwacht den Red Tenant rund um die Uhr, die Dark-Tenant-Hotline mit Manager on Duty ist jederzeit erreichbar, und regelmäßige Fire Drills testen die Recovery-Pfade unter realistischen Bedingungen, weil eine Notfallumgebung, die im Ernstfall noch nie aktiviert wurde, eine Hypothese ist und keine Lösung.




