Managed Red Tenant
Where Architecture Draws the Line
C'est presque toujours comme ça que ça commence
Mardi après-midi, 16 h 40. Dans l'onglet de gauche, l'Admin Center est ouvert, le rôle de Global Admin est actif depuis douze minutes parce qu'une politique de Conditional Access posait problème. Dans l'onglet de droite arrive une facture d'un fournisseur dont l'admin connaît le nom. Il clique, le PDF est un programme, et l'attaquant se trouve désormais sur le même appareil que le rôle le plus puissant de l'entreprise. Il n'a eu besoin pour cela d'aucune faille de sécurité ni d'un talent particulier, juste d'un appareil qui sert deux mondes à la fois.
Nous connaissons cette scène de presque chaque intervention d'incident response, dans les PME comme dans les grands groupes, et elle nous a appris une chose : une alerte de plus ne sert à rien quand l'attaquant est déjà assis à côté de l'admin. Ce qui aide, c'est une frontière placée en amont de la détection et qu'un clic ne peut pas franchir.
c'est le temps moyen qu'il faut à un attaquant entre le premier accès et le système suivant. Le record est de 27 secondes.
des attaques se passent de tout logiciel malveillant. L'attaquant se connecte comme un collègue, avec des identifiants valides.
de toutes les violations de données confirmées se sont terminées par un ransomware.
appareils effacés en trois heures chez Stryker par un seul compte admin compromis. Un compte, trois heures.
Managed Red Tenant en trois parties
Trois épisodes de moins de deux minutes dans lesquels Jan Geisbauer et Thomas Naunheim expliquent pourquoi des comptes admin séparés ne suffisent pas à eux seuls, pourquoi une PAW sans tenant dédié ne fait que la moitié du chemin et comment le Red Tenant combine les deux en une architecture qui tient au quotidien.
697 chemins documentés. L'attaquant n'en a besoin que d'un.
MITRE ATT&CK recense 222 techniques et 475 sous-techniques avec lesquelles les attaquants étendent leurs droits et progressent dans un environnement. Cela ressemble à de la diversité, mais c'est de la routine : d'abord le clic, puis le pied dans la porte, puis plus de droits, puis le système suivant. Le Managed Red Tenant coupe cette chaîne au seul endroit où elle devient dangereuse, à la frontière de l'admin Tier 0.
Étapes de la kill chain selon MITRE ATT&CK Enterprise. Représentation glueckkanja.
Ce que tu y gagnes
Un Red Tenant n'est pas un produit de plus que ton équipe doit exploiter. C'est un choix d'architecture, et il change quatre choses à la fois.
Un signal,
pas de bruit
Chaque accès admin légitime provient du Red Tenant. Tout le reste est par définition une attaque, et ton SOC le sait à la seconde même. Plus personne ne trie de fausses alertes, et plus personne ne doit deviner à trois heures du matin si le Global Admin est vraiment un collègue.
Un mur, pas un ralentisseur
Si un laptop tombe dans l'univers bureautique, l'attaquant y reste. La PAW posée sur le bureau d'à côté se trouve pour lui dans un autre tenant, et aucun chemin n'y mène. Le saut vers le niveau admin n'est donc plus une question de temps, mais une question d'architecture.
Une preuve, pas une capture d'écran
Chaque modification est versionnée, vérifiée et validée par toi dans le repository. Quand NIS2, ISO 27001 ou l'auditeur demandent des justificatifs, tu ouvres le repository au lieu de collectionner des captures d'écran. La conformité naît ici en passant, comme sous-produit d'un travail propre.
Des admins qui aiment travailler avec
La sécurité qui agace au quotidien finit par être contournée, et justement par les personnes les plus futées de la maison. C'est pourquoi tes admins reçoivent des outils plus rapides que n'importe quel détour. Au final, la variante sûre est aussi la plus confortable, et c'est la seule raison pour laquelle elle tient.
Une séparation à moitié n'est pas une séparation.
Face à un poste d'administration compromis, il existe cinq réponses courantes, et chacune résout une partie du problème. Aucune n'isole vraiment l'administration, car toutes les cinq fonctionnent à l'intérieur de la zone de risque qu'elles sont censées protéger.
Voici à quoi ressemble la frontière
Le Managed Red Tenant est un tenant Microsoft Entra à part entière, monté en greenfield, sans dépendance envers ton tenant de production ni envers le nôtre. N'y vivent que les identités privilégiées, leurs appareils et les ressources qui relaient l'accès. Tes droits restent chez toi et sont attribués via des stratégies cross-tenant, Entitlement Management et Privileged Identity Management, toujours just-in-time et jamais en réserve.
Une identité rouge ne se connecte qu'avec FIDO2 et uniquement depuis un appareil géré par le Red Tenant, car le Conditional Access de ton tenant ne laisse rien passer d'autre. Le chemin vers les systèmes on-premises est pris en charge par Global Secure Access sans un seul endpoint public, et si quelque chose cloche, Continuous Access Evaluation retire l'accès en quelques secondes, sans attendre le prochain login.
Frontière de tenant
- 1Identité rouge, FIDO2 uniquement
- 2Appareil issu du Red Tenant
- 3Conditional Access vérifie les deux
- 4PIM active le rôle just-in-time
- 5Accès à ton tenant, journalisé
Relation cross-tenant établie une seule fois à l'onboarding. Schéma glueckkanja.
Deux classes d'appareils pour que la séparation tienne au quotidien
Ce n'est pas l'adresse IP qui détermine le tier, mais le clavier devant lequel quelqu'un est assis. Chaque niveau reçoit donc l'appareil qui lui correspond, et aucun qui en fasse plus que nécessaire.
PAW : matériel dédié pour le Tier 0
Pour les Global Admins et tous ceux qui touchent à la control plane : un appareil dédié, une personne, une tâche. Ce qui n'a rien à faire sur cette machine n'y arrive même pas, parce qu'Application Control ne le laisse pas passer.
- Application Control, pas d'admin local
- TPM, Secure Boot, monitoring Defender
- FIDO2 uniquement, web limité aux endpoints d'admin
VAW : workstation virtuelle pour le Tier 1
Pour l'administration au sens large d'Azure, de Microsoft 365 et de l'on-premises : une workstation virtuelle, accessible depuis l'appareil de bureau mais jamais intégrée à celui-ci. Elle monte à des centaines d'admins sans que personne ne commande de matériel.
- Azure Virtual Desktop dans le Red Tenant
- Entra Private Access, aucun endpoint public
- Changement d'identité, Compliant Device, FIDO2
Ton chemin vers le Red Tenant
- Atelier de paramétrageAtelier de paramétrageNous nous mettons autour de la table avec toi pour définir les rôles, le tiering, les personas et les processus. On y voit lesquels de tes admins ont besoin d'une PAW et à qui une VAW suffit, et la plupart du temps il faut moins de PAW que tout le monde ne l'imaginait.
- Mise en place sous forme de codeMise en place sous forme de codeTon Red Tenant naît de notre blueprint, entièrement sous forme de code : Entra ID, Intune, Conditional Access, profils d'appareils et la relation cross-tenant avec ton tenant de production, le tout versionné, le tout traçable.
- Transfert et exploitationTransfert et exploitationTes premiers admins Tier 0 déménagent, le reste suit par vagues. À partir de là, nous exploitons l'environnement 24h/24 pour un prix mensuel fixe, et tu as un souci de moins.
Managed as Code, avec ton droit de veto
Le Red Tenant n'est jamais touché dans le portail. Chaque modification, qu'il s'agisse d'une nouvelle stratégie, d'un nouvel appareil ou d'une nouvelle fonctionnalité Microsoft, passe par les mêmes cinq étapes, à chaque fois, et elle ne prend effet que lorsque tu l'as validée.
- 1Modification sous forme de codeLa configuration, les stratégies et les profils d'appareils sont versionnés dans le repository. Chaque modification y commence comme pull request, nulle part ailleurs.
- 2Revue à quatre yeuxUne deuxième personne chez nous examine la modification sur le fond avant qu'elle ne tourne où que ce soit.
- 3Test en stagingLa modification tourne d'abord dans notre environnement de staging avant même de t'être présentée.
- 4Validation clientTon approbateur valide ou refuse. Sans cette validation, rien ne se passe, pas même chez nous.
- 5DéploiementLa pipeline déploie la modification dans ton Red Tenant, de façon journalisée, traçable et reproductible à tout moment.
On reprend depuis le début à chaque modification, y compris pour les nôtres.
Cela répond aussi à la question que chaque acheteur devrait poser, à savoir ce qui se passe si le prestataire lui-même est compromis. La réponse est : rien. Sans ta validation, aucun changement ne prend effet, et nous exploitons ton environnement depuis notre propre Red Tenant, selon les mêmes règles que celles qui s'appliquent au tien.
Ce que tu apportes, ce que nous prenons en charge
Un Red Tenant n'est pas quelque chose que tu commandes le vendredi pour l'utiliser le lundi. C'est un projet avec une fin claire, puis une exploitation que tu n'as pas à assurer toi-même. Pour que personne ne soit pris de court, voici la répartition en toute honnêteté.
Tu apportes
- Un tenant de production que tu veux protéger, plusieurs si besoin, y compris en mode hybride avec Active Directory
- Le matériel PAW pour tes rôles Tier 0, et nous te disons à l'avance exactement quels appareils conviennent
- Deux à trois personnes de ton côté qui accordent les validations et demandent les comptes
- La volonté de séparer réellement l'administration du quotidien, même si les premières semaines demandent de s'y habituer
Nous prenons en charge
- La construction du Red Tenant à partir de notre blueprint, entièrement sous forme de code
- Le durcissement, le provisionnement des appareils et tout le cycle de vie des identités à privilèges
- L'exploitation 24h/24, rattachée à notre CSOC
- Chaque nouveauté livrée par Microsoft, via la même pipeline et avec la même validation
Comme l'ensemble du Red Tenant existe sous forme de code, le déploiement ne prend que très peu de temps, et tes premiers admins Tier 0 travaillent dans le Red Tenant bien avant que le reste ne suive. L'exploitation est facturée à un prix mensuel fixe, sans surprise sur la facture.
Attaque sur le plan de contrôle
Une vingtaine de pages, trois incidents réels décortiqués étape par étape, et une réponse claire sur ce à quoi ressemble en pratique un environnement d'administration isolé et exploité sous forme de code. Écrit pour les CISO et les directions IT, et pour tous ceux qui doivent porter le sujet en interne et ont besoin d'arguments qui tiennent face à un comité de direction.
- Storm-0501, Storm-2949 et Stryker : trois chaînes d'attaque, trois leçons
- Pourquoi MFA, EDR et SOC ne protègent pas le plan d'administration
- Du Red Forest au Red Tenant : sept caractéristiques de l'architecture cible
- Correspondance avec l'article 21 de NIS2, l'annexe A d'ISO 27001 et DORA
Qui exploite le Red Tenant
Nous exploitons des Red Tenants pour des groupes du DAX et des opérateurs d'infrastructures critiques, et nous administrons ces environnements depuis notre propre Red Tenant. Le standard que nous exploitons pour toi s'applique donc d'abord à nous-mêmes.
En tant que prestataire de réponse APT qualifié par le BSI, nous nous retrouvons régulièrement de l'autre côté, là où le feu a déjà pris dans une entreprise. Ce que nous y voyons alimente directement l'architecture, et c'est la raison pour laquelle le Red Tenant ressemble à ce qu'il est.
Managed Dark Tenant
Le Red Tenant garantit qu'un client compromis ne devienne jamais un domaine compromis. Le Managed Dark Tenant répond à la deuxième question, à savoir comment tu restes opérationnel si cela arrive malgré tout : un environnement Microsoft préparé, qui dort en temps normal, qu'un appel à notre hotline 24/7 réveille, et dans lequel ton équipe de crise dispose en quelques heures d'une communication sécurisée, de postes de travail et d'une pipeline de récupération pour Active Directory. L'un est le mur, l'autre le filet de secours.
Vers le Managed Dark TenantTrois façons de commencer. Aucune ne t'engage.
Les questions que nous entendons lors du premier échange
Des réponses courtes et honnêtes, et si ta question manque, pose-la-nous via le formulaire ci-dessous.
Qu'est-ce qu'un Red Tenant, et pourquoi n'administre-t-on pas depuis le tenant de production ?
Un Red Tenant est un tenant Microsoft Entra distinct qui existe exclusivement pour les identités à privilèges et leurs appareils, et le tenant de production est administré depuis celui-ci, jamais depuis lui-même.
La raison est simple : qui compromet un tenant contrôle automatiquement aussi les comptes avec lesquels on le réparerait. Si ces comptes se trouvent dans un autre tenant, le chemin entre l'utilisateur compromis et le contrôle total est coupé. Le nom fait référence au Red Forest, l'ancien modèle de Microsoft d'une forêt d'administration séparée pour Active Directory.
Qu'est-ce que le Microsoft Enterprise Access Model, et que contiennent le Tier 0, le Tier 1 et le Tier 2 ?
L'Enterprise Access Model divise ton environnement en niveaux : la Control Plane (Tier 0) contient tout ce qui gère les identités et les droits, la Management Plane (Tier 1) regroupe les serveurs, les applications et les workloads, et la User Access Plane (Tier 2) se compose des terminaux et des utilisateurs.
La règle sous-jacente veut qu'un niveau supérieur ne soit jamais contrôlable depuis un niveau inférieur. Dans Entra ID, le Tier 0 comprend donc des rôles comme Global Administrator, Privileged Role Administrator, Conditional Access Administrator et Intune Administrator, ainsi qu'Entra Connect et tout ce qui patche, sauvegarde ou surveille ces systèmes.
Comment mettre en œuvre concrètement un concept de tiering, et par quoi commencer ?
Le mieux est de commencer par un inventaire honnête de la Control Plane, c'est-à-dire la question de savoir quels comptes, groupes, comptes de service et applications peuvent aujourd'hui modifier des identités ou des droits. Dans la plupart des environnements, il y en a nettement plus qu'on ne l'aurait pensé.
Ensuite, tu sépares les comptes par niveau, tu remplaces les attributions permanentes par PIM et tu restreins la connexion à des appareils dédiés. Notre Tiering Check gratuit te montre graphiquement où les frontières entre tiers sont franchies aujourd'hui, et c'est le point d'entrée le plus rapide que nous connaissions.
Pourquoi PIM et Conditional Access ne suffisent-ils pas à eux seuls pour les accès à privilèges ?
Tous deux vérifient l'identité et les circonstances de la connexion, mais aucun des deux ne vérifie l'appareil auquel le clavier est raccordé.
Une authentification forte réussie se termine par un token sur le terminal, et si cet appareil est compromis, le token est volé ou la session détournée, alors que PIM et Conditional Access ont correctement fait leur travail jusque-là. Le Red Tenant utilise les deux et exige en plus que l'appareil lui-même provienne de l'environnement isolé.
Qu'est-ce qu'une Privileged Access Workstation, et quand a-t-elle besoin de matériel dédié ?
Une Privileged Access Workstation (PAW) est un poste de travail durci utilisé exclusivement pour les tâches administratives, donc sans messagerie ni navigation générale, avec Application Control, sans admin local et avec une ancre de confiance via TPM et Secure Boot.
Elle a besoin de matériel dédié pour tous les rôles ayant accès à la Control Plane, car c'est là que s'applique le principe du clavier propre : un identifiant ne doit jamais toucher un appareil dont le niveau de confiance est inférieur à celui de la cible. Pour le Tier 1, la variante virtuelle suffit.
PAW ou poste d'administration virtuel : quand la variante virtuelle suffit-elle ?
Pour tout ce qui se trouve en dessous de la Control Plane. La Virtual Access Workstation (VAW) tourne en Azure Virtual Desktop dans le Red Tenant, et tu y accèdes depuis un appareil bureautique conforme via Entra Private Access, avec changement d’identité et FIDO2.
Elle monte en charge sans matériel et couvre Azure, Microsoft 365 et l’on-premises, mais un risque résiduel subsiste, puisque l’accès passe par un appareil Tier 2. C’est précisément pour cela que la Control Plane reste réservée à la PAW matérielle.
Chaque admin a-t-il besoin d’une workstation séparée ?
Non, mais chaque admin a besoin d’une identité séparée et d’un chemin d’accès séparé, et le niveau auquel la personne travaille détermine s’il s’agit d’une PAW physique ou d’une VAW virtuelle.
En pratique, seules quelques personnes disposent de droits Tier 0 et reçoivent une PAW matérielle, tandis que la grande majorité travaille via des VAW. C’est précisément pour cela que le modèle s’adapte aussi bien à 5 qu’à 5 000 admins.
Qu’est-ce qui distingue un Red Tenant d’une PAW dans ton propre tenant ?
La différence tient à l’ancre de confiance. Une PAW dont le compte, les stratégies et la gestion des appareils se trouvent dans le même tenant que les systèmes productifs partage leur sort, car qui contrôle le tenant contrôle aussi la stratégie Intune qui durcit la PAW.
Le Red Tenant déplace le compte, l’appareil et la gestion dans un tenant dédié, inaccessible depuis le tenant productif. La PAW reste la même brique, elle repose simplement sur un autre socle.
Qu’est-ce qui distingue le Red Tenant du Privileged Access Management ?
Les solutions PAM conservent les identifiants et relaient les sessions : elles sécurisent donc le credential, mais pas l’appareil depuis lequel il est utilisé. Si le terminal est compromis, l’attaquant suit simplement la session relayée, et Microsoft écrit lui-même que les solutions PAM seules ne couvrent pas de manière fiable le risque lié à l’appareil.
Le Red Tenant ne remplace pas le PAM, il le complète : PIM et les coffres existants restent utilisables, seulement l’accès vient désormais d’un appareil situé hors de la zone de risque.
Que se passe-t-il si glueckkanja est elle-même compromise ?
Rien qui prendrait effet sans ton approbation. Chaque modification du Red Tenant passe sous forme de code par une pipeline et nécessite la validation d’un Customer Approver de ton côté, et les accès d’urgence sont répartis de telle sorte qu’aucune des deux parties ne peut agir seule.
À cela s’ajoute que nous gérons ton environnement depuis notre propre Red Tenant, avec les mêmes règles que celles qui s’appliquent au tien. Le droit de veto reste toujours au client.
Qu’exige NIS2 pour les comptes admin et les accès privilégiés ?
L’article 21, paragraphe 2, cite entre autres des politiques de contrôle d’accès, l’authentification multifacteur et la sécurité de l’acquisition, du développement et de la maintenance des systèmes, et l’article 20 rend la direction responsable d’en superviser la mise en œuvre et d’en apporter la preuve.
En Allemagne, cela s’applique depuis décembre 2025 via la loi BSI, en Autriche à partir du 1er octobre 2026 via le NISG 2026. Le référentiel IT-Grundschutz du BSI classe la séparation des tâches administratives comme exigence de base et l’externalisation de l’administration dans une structure dédiée comme exigence renforcée. Le Red Tenant en est exactement la mise en œuvre cloud, et le dépôt versionné constitue ta preuve.
Un concept de tiering est-il trop complexe ou trop coûteux pour une entreprise de taille moyenne ?
Trop complexe pour une exploitation en interne, c’est souvent vrai, car la partie coûteuse n’est pas la technique, mais le durcissement, l’entretien, la surveillance et la traçabilité permanents, que personne ne gère en plus du quotidien.
C’est exactement la raison d’être du service managé : la charge est chez nous, où l’automatisation et la répétition la rendent maîtrisable, et un Red Tenant pour 20 admins repose sur le même code qu’un Red Tenant pour 2 000.
Microsoft a retiré le modèle Red Forest. Pourquoi alors un tenant admin séparé ?
Microsoft a retiré ESAE parce que le modèle ne couvrait que les administrateurs on-premises et s’avérait trop complexe à exploiter, pas parce que la séparation aurait été inefficace.
La même documentation précise que Microsoft continue d’exploiter en interne une architecture comparable, recommande des PAW pour toutes les tâches administratives et cite expressément l’isolation sur plusieurs tenants pour les ressources particulièrement sensibles. Le Red Tenant est la version cloud de ce principe, et la charge d’exploitation qui a fait échouer ESAE revient au service managé.
Nous avons le tiering, PIM et Conditional Access. Qu’est-ce qu’un Red Tenant y change ?
Le tiering définit qui a le droit de faire quoi, PIM définit quand, et Conditional Access définit sous quelles conditions. Mais tous les trois résident dans l’environnement même qu’ils sont censés protéger et sont gérés par des rôles qu’un attaquant disposant de droits Global Admin possède également.
Le Red Tenant sort l’administration de cet environnement, tes contrôles existants restent en place et obtiennent une ancre de confiance qui n’est plus accessible de l’intérieur.
