Managed Red Tenant

Ein Red Tenant ist ein eigener Microsoft-Entra-Tenant, der ausschließlich für privilegierte Identitäten und deren Geräte existiert, und der Produktions-Tenant wird von dort aus administriert, nie aus sich selbst heraus.

Der Grund dafür ist einfach: Wer einen Tenant kompromittiert, kontrolliert automatisch auch die Konten, mit denen man ihn reparieren würde. Liegen diese Konten in einem anderen Tenant, ist der Weg vom kompromittierten Anwender zur vollständigen Kontrolle unterbrochen. Der Name lehnt sich an den Red Forest an, Microsofts früheres Modell einer separaten Admin-Gesamtstruktur für Active Directory.

Das Enterprise Access Model teilt eure Umgebung in Ebenen: Die Control Plane (Tier 0) enthält alles, was Identitäten und Rechte verwaltet, die Management Plane (Tier 1) umfasst Server, Anwendungen und Workloads, und die User Access Plane (Tier 2) besteht aus Endgeräten und Anwendern.

Die Regel dahinter lautet, dass eine höhere Ebene nie von einer niedrigeren aus kontrollierbar sein darf. In Entra ID gehören zu Tier 0 deshalb Rollen wie Global Administrator, Privileged Role Administrator, Conditional Access Administrator und Intune Administrator, dazu Entra Connect und alles, was diese Systeme patcht, sichert oder überwacht.

Am besten mit einer ehrlichen Inventur der Control Plane, also der Frage, welche Konten, Gruppen, Dienstkonten und Anwendungen heute Identitäten oder Rechte verändern können. In den meisten Umgebungen sind das deutlich mehr, als man vorher gedacht hätte.

Danach trennt ihr die Konten pro Ebene, ersetzt permanente Zuweisungen durch PIM und beschränkt die Anmeldung auf dedizierte Geräte. Unser kostenloser Tiering-Check zeigt euch grafisch, wo Tier-Grenzen heute überschritten werden, und ist damit der schnellste Einstieg, den wir kennen.

Beide prüfen die Identität und die Umstände der Anmeldung, aber keiner von beiden prüft das Gerät, an dem die Tastatur hängt.

Eine erfolgreiche, starke Authentifizierung endet in einem Token auf dem Endgerät, und ist dieses Gerät kompromittiert, wird das Token gestohlen oder die Session übernommen, obwohl PIM und Conditional Access ihre Arbeit bis dahin korrekt erledigt haben. Der Red Tenant nutzt beide und setzt zusätzlich voraus, dass das Gerät selbst aus der isolierten Umgebung stammt.

Eine Privileged Access Workstation (PAW) ist ein gehärteter Arbeitsplatz, der ausschließlich für administrative Tätigkeiten genutzt wird, also ohne Mail und allgemeines Browsing, mit Application Control, ohne lokalen Admin und mit einem Vertrauensanker über TPM und Secure Boot.

Dedizierte Hardware braucht sie für alle Rollen mit Zugriff auf die Control Plane, denn dort gilt das Prinzip der sauberen Tastatur: Eine Anmeldeinformation darf nie ein Gerät berühren, dessen Vertrauensniveau niedriger ist als das des Ziels. Für Tier 1 reicht die virtuelle Variante.

Für alles unterhalb der Control Plane. Die virtuelle Access Workstation (VAW) läuft als Azure Virtual Desktop im Red Tenant, und ihr erreicht sie von einem compliant Office-Gerät aus über Entra Private Access, mit Identitätswechsel und FIDO2.

Sie skaliert ohne Hardware und deckt Azure, Microsoft 365 und On-Premises ab, allerdings bleibt ein Restrisiko, weil der Zugriff über ein Tier-2-Gerät läuft. Genau deshalb bleibt die Control Plane der Hardware-PAW vorbehalten.

Nein, aber jeder Admin braucht eine separate Identität und einen separaten Zugriffsweg, und ob das eine physische PAW oder eine virtuelle VAW ist, entscheidet die Ebene, auf der die Person arbeitet.

In der Praxis haben nur wenige Personen Tier-0-Rechte und bekommen eine Hardware-PAW, während die breite Mehrheit über VAWs arbeitet. Genau deshalb skaliert das Modell von 5 bis 5.000 Admins.

Der Unterschied liegt im Vertrauensanker. Eine PAW, deren Konto, Richtlinien und Geräteverwaltung im selben Tenant liegen wie die produktiven Systeme, teilt deren Schicksal, denn wer den Tenant kontrolliert, kontrolliert auch die Intune-Richtlinie, die die PAW härtet.

Der Red Tenant verlagert Konto, Gerät und Verwaltung in einen eigenen Tenant, der vom produktiven Tenant aus nicht erreichbar ist. Die PAW bleibt derselbe Baustein, sie steht nur auf einem anderen Fundament.

PAM-Lösungen verwahren Zugangsdaten und vermitteln Sitzungen, sie sichern also das Credential, aber nicht das Gerät, von dem aus es genutzt wird. Ist der Endpunkt kompromittiert, läuft der Angreifer in der vermittelten Sitzung einfach mit, und Microsoft selbst schreibt, dass PAM-Lösungen allein das Geräterisiko nicht zuverlässig abdecken.

Der Red Tenant ersetzt PAM nicht, sondern ergänzt es: PIM und bestehende Tresore bleiben nutzbar, nur kommt der Zugriff jetzt von einem Gerät außerhalb der Risikozone.

Nichts, was ohne eure Freigabe wirksam würde. Jede Änderung am Red Tenant läuft als Code durch eine Pipeline und braucht die Freigabe eines Customer Approvers auf eurer Seite, und Notfallzugänge sind so aufgeteilt, dass keine Seite allein handeln kann.

Dazu kommt, dass wir eure Umgebung aus unserem eigenen Red Tenant heraus verwalten, mit denselben Regeln, die auch für eure gelten. Das Vetorecht bleibt immer beim Kunden.

Artikel 21 Absatz 2 nennt unter anderem Konzepte für die Zugriffskontrolle, Multi-Faktor-Authentifizierung und Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen, und Artikel 20 macht die Geschäftsleitung dafür verantwortlich, die Umsetzung zu überwachen und zu belegen.

In Deutschland gilt das seit Dezember 2025 über das BSI-Gesetz, in Österreich ab dem 1. Oktober 2026 über das NISG 2026. Der BSI-IT-Grundschutz kennt die Trennung administrativer Tätigkeiten als Basisanforderung und die Auslagerung der Administration in eine eigene Struktur als erhöhte Anforderung. Der Red Tenant ist die Cloud-Umsetzung genau davon, und das versionierte Repository ist euer Nachweis.

Zu komplex für den Eigenbetrieb ist es oft tatsächlich, denn der teure Teil ist nicht die Technik, sondern die dauerhafte Härtung, Pflege, Überwachung und Nachweisführung, die niemand nebenbei erledigt.

Genau das ist der Grund für den Managed Service: Der Aufwand liegt bei uns, wo Automatisierung und Wiederholung ihn beherrschbar machen, und ein Red Tenant für 20 Admins ist derselbe Code wie einer für 2.000.

Microsoft hat ESAE zurückgezogen, weil das Modell nur On-Premises-Administratoren abdeckte und im Betrieb zu komplex war, nicht weil die Trennung unwirksam gewesen wäre.

Dieselbe Dokumentation hält fest, dass Microsoft intern weiterhin eine vergleichbare Architektur betreibt, empfiehlt PAWs für alle administrativen Tätigkeiten und nennt für besonders schutzbedürftige Ressourcen ausdrücklich die Isolation über mehrere Tenants. Der Red Tenant ist die Cloud-Fassung dieses Prinzips, und der Betriebsaufwand, an dem ESAE gescheitert ist, liegt beim Managed Service.

Tiering regelt, wer was darf, PIM regelt, wann, und Conditional Access regelt, unter welchen Bedingungen. Alle drei liegen aber in derselben Umgebung, die sie schützen sollen, und werden von Rollen verwaltet, die ein Angreifer mit Global-Admin-Rechten ebenfalls besitzt.

Der Red Tenant holt die Administration aus dieser Umgebung heraus, eure bestehenden Kontrollen bleiben erhalten und bekommen einen Vertrauensanker, der von innen nicht mehr erreichbar ist.