Managed Red Tenant
Where Architecture Draws the Line
Así empieza casi siempre
Martes por la tarde, 16:40. En la pestaña izquierda está abierto el centro de administración, el rol de Global Admin lleva doce minutos activo porque una política de Conditional Access daba problemas. En la pestaña derecha llega una factura de un proveedor cuyo nombre el administrador conoce. Hace clic, el PDF resulta ser un programa, y el atacante está ahora en el mismo dispositivo que el rol más poderoso de la empresa. Para eso no ha necesitado ni una vulnerabilidad ni un talento especial, solo un dispositivo que sirve a dos mundos a la vez.
Conocemos esta escena de casi todas las intervenciones de respuesta a incidentes, tanto en empresas medianas como en grandes grupos, y nos ha enseñado una cosa: otra alerta más no ayuda cuando el atacante ya está sentado junto al administrador. Lo que ayuda es un límite que está antes de la detección y que un clic no puede cruzar.
necesita un atacante de media desde el primer acceso hasta el siguiente sistema. El récord está en 27 segundos.
de los ataques funcionan sin malware. El atacante inicia sesión como un compañero más, con credenciales válidas.
de todas las brechas confirmadas terminaron en ransomware.
dispositivos borró en Stryker una sola cuenta de administrador secuestrada en tres horas. Una cuenta, tres horas.
Managed Red Tenant en tres partes
Tres episodios, ninguno de dos minutos, en los que Jan Geisbauer y Thomas Naunheim explican por qué las cuentas de administrador separadas no bastan por sí solas, por qué una PAW sin tenant propio es solo la mitad del trabajo y cómo el Red Tenant combina ambas cosas en una arquitectura que sobrevive al día a día. Los vídeos están en inglés.
697 caminos documentados. El atacante necesita uno.
MITRE ATT&CK recoge 222 técnicas y 475 subtécnicas con las que los atacantes escalan privilegios y se abren paso por un entorno. Suena a variedad, pero es rutina: primero el clic, luego el pie en la puerta, luego más permisos y luego el siguiente sistema. El Managed Red Tenant corta esta cadena en el único punto en que se vuelve peligrosa, el límite hacia el administrador Tier 0.
Fases de la kill chain según MITRE ATT&CK Enterprise. Ilustración glueckkanja.
Lo que ganáis con ello
Un Red Tenant no es otro producto que vuestro equipo tenga que operar. Es una decisión de arquitectura, y cambia cuatro cosas a la vez.
Una señal,
sin ruido
Todo acceso administrativo legítimo procede del Red Tenant. Cualquier otra cosa es por definición un ataque, y vuestro SOC lo sabe en ese mismo segundo. Nadie clasifica ya falsos positivos y nadie tiene que adivinar a las tres de la mañana si el Global Admin es de verdad un compañero.
Un muro, no un badén
Si cae un portátil en el mundo de oficina, el atacante se queda allí. La PAW que está al lado en la mesa vive para él en otro tenant, y hasta allí no lleva ningún camino. El salto al nivel de administración deja de ser cuestión de tiempo y pasa a ser cuestión de arquitectura.
Una prueba, no una captura de pantalla
Cada cambio queda versionado, revisado y aprobado por vosotros en el repositorio. Cuando NIS2, ISO 27001 o el auditor pidan evidencias, abrís el repositorio en lugar de recopilar capturas de pantalla. Aquí el cumplimiento surge de paso, como subproducto de un trabajo limpio.
Administradores a los que les gusta usarlo
La seguridad que molesta en el día a día se esquiva, y la esquivan precisamente las personas más listas de la casa. Por eso vuestros administradores reciben herramientas más rápidas que cualquier rodeo. Al final la opción segura es la cómoda, y esa es la única razón por la que aguanta.
Una separación parcial no es una separación.
A un puesto de administración comprometido hay cinco respuestas habituales, y cada una resuelve un trozo del problema. Ninguna aísla realmente la administración, porque las cinco funcionan dentro de la zona de riesgo que deberían proteger.
Así es el límite
El Managed Red Tenant es un tenant propio de Microsoft Entra, creado desde cero, sin dependencia de vuestro tenant productivo ni del nuestro. Allí viven solo las identidades privilegiadas, sus dispositivos y los recursos que median el acceso. Vuestros permisos se quedan con vosotros y se otorgan mediante políticas cross-tenant, entitlement management y Privileged Identity Management, siempre just in time y nunca por adelantado.
Una identidad roja inicia sesión solo con FIDO2 y solo desde un dispositivo que gestiona el Red Tenant, porque el Conditional Access de vuestro tenant no deja pasar nada más. Global Secure Access se ocupa del camino hacia los sistemas on-premises sin un solo endpoint público, y si algo no cuadra, Continuous Access Evaluation retira el acceso en cuestión de segundos, no en el siguiente inicio de sesión.
Límite del tenant
- 1Identidad roja, solo FIDO2
- 2Dispositivo del Red Tenant
- 3Conditional Access comprueba ambos
- 4PIM activa el rol just in time
- 5Acceso a vuestro tenant, registrado
Relación cross-tenant establecida una sola vez durante el onboarding. Ilustración glueckkanja.
Dos clases de dispositivo para que la separación aguante el día a día
El tier no lo define la dirección IP, sino el teclado ante el que alguien se sienta. Por eso cada nivel recibe el dispositivo que le corresponde, y ninguno que pueda hacer más de lo necesario.
PAW: hardware dedicado para Tier 0
Para Global Admins y para todos los que tocan el control plane: un dispositivo, una persona, una tarea. Lo que no pinta nada en esa máquina nunca llega a ella, porque el control de aplicaciones no lo permite.
- Control de aplicaciones, sin administrador local
- TPM, Secure Boot, monitorización con Defender
- Solo FIDO2, web solo a endpoints de administración
VAW: estación de trabajo virtual para Tier 1
Para la administración amplia de Azure, Microsoft 365 y on-premises: una estación de trabajo virtual, accesible desde el equipo de oficina pero nunca parte de él. Escala a cientos de administradores sin que nadie pida hardware.
- Azure Virtual Desktop en el Red Tenant
- Entra Private Access, sin endpoint público
- Cambio de identidad, dispositivo conforme, FIDO2
Vuestro camino al Red Tenant
- Taller de parametrizaciónTaller de parametrizaciónNos sentamos con vosotros y definimos roles, tiering, personas y procesos. Por el camino queda claro qué administradores necesitan una PAW y a quién le basta una VAW, y normalmente son menos PAW de las que todos esperaban.
- Construcción como códigoConstrucción como códigoVuestro Red Tenant nace de nuestro blueprint, íntegramente como código: Entra ID, Intune, Conditional Access, perfiles de dispositivo y la relación cross-tenant con vuestro tenant productivo, todo versionado, todo trazable.
- Handover y operaciónHandover y operaciónVuestros primeros administradores Tier 0 se mudan, el resto sigue por oleadas. A partir de ahí operamos el entorno las 24 horas a un precio mensual fijo, y vosotros tenéis una preocupación menos.
Managed as code, con vuestro derecho de veto
El Red Tenant nunca se toca en un portal. Cada cambio, sea una política nueva, un dispositivo nuevo o una nueva función de Microsoft, pasa por las mismas cinco estaciones, todas las veces, y solo se aplica cuando vosotros lo habéis aprobado.
- 1Cambio como códigoConfiguración, políticas y perfiles de dispositivo viven versionados en el repositorio. Cada cambio empieza allí como pull request, en ningún otro sitio.
- 2Revisión a cuatro ojosUna segunda persona de nuestro equipo revisa el cambio antes de que se ejecute en ningún sitio.
- 3Prueba en stagingEl cambio se ejecuta primero en nuestro entorno de staging, antes incluso de presentároslo.
- 4Customer approvalVuestro approver aprueba o rechaza. Sin esa aprobación no ocurre nada, tampoco de nuestro lado.
- 5DespliegueLa pipeline despliega el cambio en vuestro Red Tenant, registrado, trazable, repetible en cualquier momento.
Cada cambio empieza desde el principio, también los nuestros.
Eso responde también a la pregunta que todo comprador debería hacer, es decir, qué pasa si el propio proveedor se ve comprometido. La respuesta es nada. Sin vuestra aprobación no se aplica ningún cambio, y operamos vuestro entorno desde nuestro propio Red Tenant con las mismas reglas que rigen para el vuestro.
Lo que aportáis, de lo que nos encargamos
Un Red Tenant no es algo que se pide el viernes y se usa el lunes. Es un proyecto con un final claro y, después, una operación que no tenéis que cargar vosotros. Para que nadie se lleve sorpresas, aquí está el reparto sincero.
Vosotros aportáis
- Un tenant productivo que queréis proteger, varios si queréis, híbrido con Active Directory si queréis
- El hardware de las PAW para vuestros roles Tier 0, y os decimos de antemano exactamente qué dispositivos sirven
- Dos o tres personas de vuestro lado que concedan aprobaciones y soliciten cuentas
- La voluntad de separar de verdad la administración del trabajo diario, aunque las primeras semanas resulte extraño
Nosotros nos encargamos de
- Crear el Red Tenant a partir de nuestro blueprint, íntegramente como código
- Endurecimiento, aprovisionamiento de dispositivos y todo el ciclo de vida de las identidades privilegiadas
- La operación las 24 horas, conectada a nuestro CSOC
- Cada novedad que publique Microsoft, por la misma pipeline y con la misma aprobación
Como todo el Red Tenant existe como código, el despliegue se realiza en muy poco tiempo, y vuestros primeros administradores Tier 0 trabajan en el Red Tenant mucho antes de que siga el resto. La operación funciona a un precio mensual fijo, sin sorpresas en la factura.
Ataque al plano de control
Unas 20 páginas, tres incidentes reales desmontados paso a paso y una respuesta clara a cómo es en la práctica un entorno de administración aislado y operado como código. Escrito para CISOs y dirección de TI, y para todos los que tienen que llevar el tema hacia arriba y necesitan argumentos que aguanten delante de un consejo de dirección. El documento está en inglés.
- Storm-0501, Storm-2949 y Stryker: tres cadenas de ataque, tres lecciones
- Por qué MFA, EDR y un SOC no protegen el plano de gestión
- Del Red Forest al Red Tenant: siete características de la arquitectura objetivo
- Correspondencia con el artículo 21 de NIS2, el anexo A de ISO 27001 y DORA
Quién opera el Red Tenant
Operamos Red Tenants para empresas del DAX y operadores de infraestructuras críticas, y gestionamos esos entornos desde nuestro propio Red Tenant. El estándar que operamos para vosotros se aplica, por tanto, primero a nosotros mismos.
Como proveedor de respuesta APT cualificado por el BSI alemán, estamos con frecuencia al otro lado cuando en una empresa ya hay fuego. Lo que vemos allí vuelve directamente a la arquitectura, y esa es la razón por la que el Red Tenant es como es.
Managed Dark Tenant
El Red Tenant se encarga de que un cliente comprometido nunca se convierta en un dominio comprometido. El Managed Dark Tenant responde a la segunda pregunta, es decir, cómo seguís operativos si ocurre de todos modos: un entorno de Microsoft preparado que reposa durante la operación normal, que se despierta con una llamada a nuestra línea 24/7 y en el que vuestro equipo de crisis dispone en pocas horas de comunicación segura, puestos de trabajo y una pipeline de recuperación para Active Directory. Uno es el muro, el otro es la red de seguridad.
Managed Dark TenantTres formas de empezar. Ninguna os compromete.
Preguntas que escuchamos en la primera conversación
Respondidas de forma breve y sincera, y si falta la vuestra, preguntadnos en el formulario de abajo.
¿Qué es un Red Tenant y por qué no se administra dentro del tenant productivo?
Un Red Tenant es un tenant propio de Microsoft Entra que existe únicamente para las identidades privilegiadas y sus dispositivos, y el tenant productivo se administra desde allí, nunca desde dentro de sí mismo.
La razón es sencilla: quien compromete un tenant controla automáticamente también las cuentas con las que se repararía. Si esas cuentas viven en otro tenant, el camino desde un usuario comprometido hasta el control total queda cortado. El nombre remite al Red Forest, el modelo anterior de Microsoft de un bosque de administración separado para Active Directory.
¿Qué es el Microsoft Enterprise Access Model y qué corresponde a Tier 0, Tier 1 y Tier 2?
El Enterprise Access Model divide vuestro entorno en planos: el control plane (Tier 0) contiene todo lo que gestiona identidades y permisos, el management plane (Tier 1) abarca servidores, aplicaciones y cargas de trabajo, y el user access plane (Tier 2) se compone de dispositivos y usuarios.
La regla de fondo es que un plano superior nunca debe poder controlarse desde uno inferior. En Entra ID, Tier 0 incluye por eso roles como Global Administrator, Privileged Role Administrator, Conditional Access Administrator e Intune Administrator, además de Entra Connect y todo lo que parchea, respalda o monitoriza esos sistemas.
¿Cómo se implementa un concepto de tiering en la práctica y por dónde se empieza?
Lo mejor es empezar con un inventario sincero del control plane, es decir, con la pregunta de qué cuentas, grupos, cuentas de servicio y aplicaciones pueden cambiar hoy identidades o permisos. En la mayoría de los entornos resultan ser muchos más de lo que nadie esperaba.
Después separáis las cuentas por plano, sustituís las asignaciones permanentes por PIM y restringís el inicio de sesión a dispositivos dedicados. Nuestro tiering check gratuito os muestra gráficamente dónde se cruzan hoy los límites de tier, y por eso es la vía de entrada más rápida que conocemos.
¿Por qué PIM y Conditional Access por sí solos no bastan para el acceso privilegiado?
Ambos verifican la identidad y las circunstancias del inicio de sesión, pero ninguno de los dos verifica el dispositivo al que está conectado el teclado.
Una autenticación fuerte y exitosa termina en un token en el endpoint, y si ese dispositivo está comprometido, el token se roba o la sesión se secuestra aunque PIM y Conditional Access hayan hecho su trabajo correctamente hasta ese momento. El Red Tenant utiliza ambos y exige además que el propio dispositivo proceda del entorno aislado.
¿Qué es una Privileged Access Workstation y cuándo necesita hardware dedicado?
Una Privileged Access Workstation (PAW) es un puesto de trabajo endurecido que se usa exclusivamente para tareas administrativas, es decir, sin correo ni navegación general, con control de aplicaciones, sin administrador local y con una raíz de confianza en TPM y Secure Boot.
Necesita hardware dedicado para todos los roles con acceso al control plane, porque allí rige el principio del teclado limpio: una credencial nunca debe tocar un dispositivo cuyo nivel de confianza sea inferior al del objetivo. Para Tier 1 basta la variante virtual.
¿PAW o estación de administración virtual? ¿Cuándo basta la variante virtual?
Para todo lo que está por debajo del control plane. La estación de acceso virtual (VAW) se ejecuta como Azure Virtual Desktop dentro del Red Tenant, y la alcanzáis desde un dispositivo de oficina conforme mediante Entra Private Access, con cambio de identidad y FIDO2.
Escala sin hardware y cubre Azure, Microsoft 365 y on-premises, aunque queda un riesgo residual porque el acceso pasa por un dispositivo Tier 2. Justo por eso el control plane queda reservado a la PAW de hardware.
¿Necesita cada administrador una estación de trabajo separada?
No, pero cada administrador necesita una identidad separada y una ruta de acceso separada, y que sea una PAW física o una VAW virtual lo decide el plano en el que trabaja la persona.
En la práctica solo unas pocas personas tienen derechos Tier 0 y reciben una PAW de hardware, mientras que la gran mayoría trabaja a través de VAW. Justo por eso el modelo escala de 5 a 5.000 administradores.
¿Qué distingue un Red Tenant de una PAW en el propio tenant?
La diferencia está en el ancla de confianza. Una PAW cuya cuenta, políticas y gestión de dispositivos viven en el mismo tenant que los sistemas productivos comparte su destino, porque quien controla el tenant controla también la política de Intune que endurece la PAW.
El Red Tenant traslada cuenta, dispositivo y gestión a un tenant propio, inalcanzable desde el tenant productivo. La PAW sigue siendo el mismo componente, solo que se apoya en otro cimiento.
¿Qué distingue el Red Tenant del Privileged Access Management?
Las soluciones PAM custodian credenciales y median sesiones, así que protegen la credencial, pero no el dispositivo desde el que se usa. Si el endpoint está comprometido, el atacante simplemente viaja dentro de la sesión mediada, y la propia Microsoft escribe que las soluciones PAM por sí solas no cubren de forma fiable el riesgo del dispositivo.
El Red Tenant no sustituye a PAM, sino que lo complementa: PIM y las bóvedas existentes siguen siendo utilizables, solo que ahora el acceso procede de un dispositivo fuera de la zona de riesgo.
¿Qué pasa si glueckkanja resulta comprometida?
Nada que pueda aplicarse sin vuestra aprobación. Cada cambio en el Red Tenant pasa como código por una pipeline y necesita la aprobación de un customer approver de vuestro lado, y los accesos de emergencia están repartidos de modo que ninguna de las partes puede actuar sola.
A eso se suma que gestionamos vuestro entorno desde nuestro propio Red Tenant, con las mismas reglas que rigen para el vuestro. El derecho de veto queda siempre en el cliente.
¿Qué exige NIS2 para las cuentas de administrador y los accesos privilegiados?
El artículo 21, apartado 2, nombra entre otras cosas políticas de control de acceso, autenticación multifactor y seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas, y el artículo 20 hace responsable a la dirección de supervisar y demostrar la implementación.
En Alemania se aplica desde diciembre de 2025 mediante la ley del BSI, en Austria desde el 1 de octubre de 2026 mediante la NISG 2026. La protección básica de TI del BSI alemán considera la separación de las actividades administrativas un requisito básico y el traslado de la administración a una estructura propia un requisito elevado. El Red Tenant es la implementación en la nube de exactamente eso, y el repositorio versionado es vuestra prueba.
¿Es un concepto de tiering demasiado complejo o caro para una empresa mediana?
Demasiado complejo para operarlo en propio lo es a menudo, porque la parte cara no es la tecnología, sino el endurecimiento, el mantenimiento, la monitorización y la documentación probatoria continuos, de los que nadie se ocupa de pasada.
Esa es exactamente la razón del servicio gestionado: el esfuerzo recae en nosotros, donde la automatización y la repetición lo hacen manejable, y un Red Tenant para 20 administradores es el mismo código que uno para 2.000.
Microsoft retiró el modelo Red Forest. ¿Por qué entonces un tenant de administración separado?
Microsoft retiró ESAE porque el modelo solo cubría a administradores on-premises y era demasiado complejo de operar, no porque la separación fuera ineficaz.
La misma documentación señala que Microsoft sigue operando internamente una arquitectura comparable, recomienda PAW para todas las actividades administrativas y menciona expresamente el aislamiento en varios tenants para recursos que requieren un enfoque altamente defensivo. El Red Tenant es la versión en la nube de ese principio, y el esfuerzo operativo en el que fracasó ESAE recae en el servicio gestionado.
Ya tenemos tiering, PIM y Conditional Access. ¿Qué cambia un Red Tenant?
El tiering define quién puede hacer qué, PIM define cuándo y Conditional Access define bajo qué condiciones. Los tres, sin embargo, viven en el mismo entorno que deben proteger y los gestionan roles que un atacante con derechos de Global Admin también posee.
El Red Tenant saca la administración de ese entorno, vuestros controles actuales se mantienen y obtienen un ancla de confianza que ya no es alcanzable desde dentro.
Más sobre el tema
Sin Malware. Solo una Cuenta de Administrador.
El 11 de marzo de 2026, Handala borró dispositivos en 79 países utilizando únicamente una cuenta de administrador de Intune ...
