Managed Red Tenant
Where Architecture Draws the Line
Comincia quasi sempre così
Martedì pomeriggio, ore 16:40. Nella scheda di sinistra è aperto l'admin center, il ruolo Global Admin è attivo da dodici minuti perché una policy di Conditional Access faceva i capricci. Nella scheda di destra arriva una fattura da un fornitore di cui l'admin conosce il nome. Clicca, il PDF è un programma, e ora l'attaccante si trova sullo stesso dispositivo del ruolo più potente dell'azienda. Non gli è servita alcuna vulnerabilità né un talento particolare, solo un dispositivo che serve due mondi allo stesso tempo.
Conosciamo questa scena da quasi ogni intervento di incident response, nelle medie imprese come nei grandi gruppi, e ci ha insegnato una cosa: un altro alert non serve a niente quando l'attaccante è già seduto accanto all'admin. Quello che serve è un confine che viene prima della detection e che un clic non può superare.
è il tempo che serve in media a un attaccante per passare dal primo accesso al sistema successivo. Il record è di 27 secondi.
degli attacchi funziona senza malware. L'attaccante accede come farebbe un collega, con credenziali valide.
di tutte le violazioni di dati confermate si è conclusa con un ransomware.
dispositivi cancellati in tre ore da un unico account admin dirottato presso Stryker. Un account, tre ore.
Managed Red Tenant in tre parti
Tre episodi, nessuno lungo due minuti, in cui Jan Geisbauer e Thomas Naunheim spiegano perché gli account admin separati da soli non bastano, perché una PAW senza un tenant dedicato risolve solo metà del problema e come il Red Tenant unisce le due cose in un'architettura che regge il lavoro quotidiano.
697 strade documentate. All'attaccante ne basta una.
MITRE ATT&CK elenca 222 tecniche e 475 sotto-tecniche con cui gli attaccanti estendono i privilegi e si fanno strada in un ambiente. Sembra varietà, ma è routine: prima il clic, poi il piede nella porta, poi più diritti, poi il sistema successivo. Il Managed Red Tenant taglia questa catena nell'unico punto in cui diventa pericolosa, al confine con l'admin Tier 0.
Fasi della kill chain secondo MITRE ATT&CK Enterprise. Elaborazione glueckkanja.
Che cosa ci guadagni
Un Red Tenant non è l'ennesimo prodotto che il tuo team deve gestire. È una decisione di architettura, e cambia quattro cose in una volta sola.
Un segnale,
non rumore
Ogni accesso admin legittimo arriva dal Red Tenant. Tutto il resto è per definizione un attacco, e il tuo SOC lo sa nello stesso istante. Nessuno deve più smistare falsi allarmi, e nessuno deve tirare a indovinare alle tre di notte se il Global Admin sia davvero un collega.
Un muro, non un dosso
Se cade un laptop nel mondo office, l'attaccante resta lì. La PAW sulla scrivania accanto per lui si trova in un altro tenant, e lì non porta nessuna strada. Il salto al livello amministrativo non è più una questione di tempo, ma di architettura.
Una prova, non uno screenshot
Ogni modifica è nel repository, versionata, revisionata e approvata da te. Quando NIS2, ISO 27001 o il revisore chiedono le prove, apri il repository invece di raccogliere screenshot. Qui la compliance nasce di passaggio, come sottoprodotto di un lavoro pulito.
Admin che ci lavorano volentieri
La sicurezza che dà fastidio nel lavoro quotidiano viene aggirata, e proprio dalle persone più sveglie dell'azienda. Per questo i tuoi admin ricevono strumenti più veloci di qualsiasi scorciatoia. Alla fine l'opzione sicura è quella comoda, ed è l'unico motivo per cui tiene.
Una separazione a metà non è una separazione.
A una postazione admin compromessa ci sono cinque risposte diffuse, e ognuna risolve un pezzo del problema. Nessuna isola davvero l'amministrazione, perché tutte e cinque girano dentro la zona di rischio che dovrebbero proteggere.
Ecco com'è fatto il confine
Il Managed Red Tenant è un tenant Microsoft Entra dedicato, realizzato greenfield, senza dipendenze dal tuo tenant produttivo e senza dipendenze dal nostro. Al suo interno vivono solo le identità privilegiate, i loro dispositivi e le risorse che mediano l'accesso. I tuoi diritti restano tuoi e vengono assegnati tramite policy cross-tenant, Entitlement Management e Privileged Identity Management, sempre just-in-time e mai in anticipo.
Un'identità rossa accede solo con FIDO2 e solo da un dispositivo gestito dal Red Tenant, perché Conditional Access nel tuo tenant non lascia passare nient'altro. Il percorso verso i sistemi on-premises lo prende in carico Global Secure Access senza un solo endpoint pubblico, e se qualcosa non torna, Continuous Access Evaluation revoca l'accesso nel giro di secondi, non al login successivo.
Confine tra tenant
- 1Identità rossa, solo FIDO2
- 2Dispositivo dal Red Tenant
- 3Conditional Access verifica entrambi
- 4PIM attiva il ruolo just-in-time
- 5Accesso al tuo tenant, registrato
Relazione cross-tenant stabilita una sola volta durante l'onboarding. Elaborazione glueckkanja.
Due classi di dispositivi, perché la separazione tenga nel lavoro quotidiano
Il tier non lo determina l'indirizzo IP, ma la tastiera a cui qualcuno è seduto. Per questo ogni livello riceve il dispositivo che gli corrisponde, e nessuno che possa fare più del necessario.
PAW: hardware dedicato per il Tier 0
Per i Global Admin e per tutti quelli che mettono le mani sulla control plane: un dispositivo, una persona, un compito. Ciò che su questa macchina non ha nulla da fare non ci arriva nemmeno, perché Application Control non lo consente.
- Application Control, nessun admin locale
- TPM, Secure Boot, monitoring Defender
- Solo FIDO2, web solo verso endpoint amministrativi
VAW: workstation virtuale per il Tier 1
Per l'amministrazione estesa di Azure, Microsoft 365 e on-premises: una workstation virtuale, raggiungibile dal dispositivo office ma mai parte di esso. Scala su centinaia di admin senza che nessuno debba ordinare hardware.
- Azure Virtual Desktop nel Red Tenant
- Entra Private Access, nessun endpoint pubblico
- Cambio di identità, compliant device, FIDO2
Il tuo percorso verso il Red Tenant
- Workshop di parametrizzazioneWorkshop di parametrizzazioneCi sediamo con te e definiamo ruoli, tiering, personas e processi. Strada facendo diventa chiaro quali dei tuoi admin abbiano bisogno di una PAW e a chi basti una VAW, e di solito le PAW sono meno di quante tutti si aspettassero.
- Costruzione come codiceCostruzione come codiceIl tuo Red Tenant nasce dal nostro blueprint, interamente come codice: Entra ID, Intune, Conditional Access, profili dei dispositivi e la relazione cross-tenant con il tuo tenant produttivo, tutto versionato, tutto tracciabile.
- Handover ed esercizioHandover ed esercizioI tuoi primi admin Tier 0 traslocano, il resto segue a ondate. Da quel momento gestiamo l'ambiente 24 ore su 24 a un canone mensile fisso, e tu hai un pensiero in meno.
Managed as Code, con il tuo diritto di veto
Il Red Tenant non viene mai toccato dal portale. Ogni modifica, che sia una nuova policy, un nuovo dispositivo o una nuova funzionalità Microsoft, passa per le stesse cinque stazioni, ogni volta, e diventa effettiva solo dopo che l'hai approvata.
- 1Modifica come codiceConfigurazione, policy e profili dei dispositivi sono versionati nel repository. Ogni modifica parte da lì come pull request, da nessun'altra parte.
- 2Review a quattro occhiUna seconda persona da noi verifica il change nel merito, prima che giri da qualsiasi parte.
- 3Test in stagingIl change gira prima nel nostro ambiente di staging, prima ancora di esserti sottoposto.
- 4Customer approvalIl tuo approver approva o respinge. Senza questa approvazione non succede nulla, nemmeno da noi.
- 5DeploymentLa pipeline distribuisce il change nel tuo Red Tenant, registrato, tracciabile, ripetibile in qualsiasi momento.
Da capo a ogni modifica, anche per le nostre.
Così trova risposta anche la domanda che ogni buyer dovrebbe porre, e cioè che cosa succede se è il fornitore stesso a essere compromesso. La risposta è: niente. Senza la tua approvazione nessun change diventa effettivo, e gestiamo il tuo ambiente dal nostro Red Tenant, secondo le stesse regole che valgono per il tuo.
Che cosa porti tu, che cosa ci prendiamo noi
Un Red Tenant non è qualcosa che ordini venerdì e usi lunedì. È un progetto con una fine chiara e, dopo, un esercizio che non devi sostenere da solo. Perché nessuno abbia sorprese, ecco la divisione onesta dei compiti.
Tu porti
- Un tenant produttivo che vuoi proteggere, anche più di uno, anche ibrido con Active Directory
- L'hardware PAW per i tuoi ruoli Tier 0, e ti diciamo prima esattamente quali dispositivi sono adatti
- Due o tre persone dalla tua parte che concedono le approvazioni e richiedono gli account
- La volontà di separare davvero amministrazione e lavoro quotidiano, anche se le prime settimane sono inconsuete
Noi ci prendiamo
- La costruzione del Red Tenant dal nostro blueprint, interamente come codice
- Hardening, provisioning dei dispositivi e l'intero ciclo di vita delle identità privilegiate
- L'esercizio 24 ore su 24, collegato al nostro CSOC
- Ogni novità che Microsoft rilascia, attraverso la stessa pipeline e con la stessa approvazione
Poiché l'intero Red Tenant esiste come codice, il deployment richiede pochissimo tempo, e i tuoi primi admin Tier 0 lavorano nel Red Tenant molto prima che segua il resto. L'esercizio va a un canone mensile fisso, senza sorprese in fattura.
Attacco alla control plane
Circa 20 pagine, tre incidenti reali smontati passo per passo, e una risposta chiara su come si presenta nella pratica un ambiente di amministrazione isolato e gestito come codice. Scritto per CISO e responsabili IT, e per tutti quelli che devono portare il tema ai piani alti e hanno bisogno di argomenti che reggano davanti a un consiglio di amministrazione.
- Storm-0501, Storm-2949 e Stryker: tre catene di attacco, tre lezioni
- Perché MFA, EDR e SOC non proteggono la management plane
- Dal Red Forest al Red Tenant: sette caratteristiche dell'architettura target
- Mappatura sull'articolo 21 di NIS2, sull'allegato A della ISO 27001 e su DORA
Chi gestisce il Red Tenant
Gestiamo Red Tenant per gruppi quotati al DAX e per operatori di infrastrutture critiche, e amministriamo questi ambienti dal nostro Red Tenant. Lo standard che portiamo avanti per te vale quindi prima di tutto per noi stessi.
Come fornitore di APT response qualificato dal BSI ci troviamo regolarmente dall'altra parte, quando in un'azienda sta già bruciando tutto. Quello che vediamo lì rientra direttamente nell'architettura, ed è il motivo per cui il Red Tenant è fatto come è fatto.
Managed Dark Tenant
Il Red Tenant fa in modo che un client compromesso non diventi mai un dominio compromesso. Il Managed Dark Tenant risponde alla seconda domanda, e cioè come resti operativo se succede comunque: un ambiente Microsoft preparato, che nel funzionamento normale riposa, che una chiamata alla nostra hotline 24/7 risveglia e in cui il tuo team di crisi ha comunicazione sicura, postazioni di lavoro e una pipeline di recovery per Active Directory nel giro di poche ore. Uno è il muro, l'altro è la rete di sicurezza.
Scopri Managed Dark TenantTre modi per iniziare. Nessuno ti vincola.
Domande che sentiamo nel primo colloquio
Risposte brevi e oneste, e se la tua domanda manca, falla nel modulo qui sotto.
Che cos'è un Red Tenant e perché non si amministra dentro il tenant di produzione?
Un Red Tenant è un tenant Microsoft Entra dedicato, che esiste esclusivamente per le identità privilegiate e i loro dispositivi, e il tenant di produzione viene amministrato da lì, mai dal suo interno.
Il motivo è semplice: chi compromette un tenant controlla automaticamente anche gli account con cui lo si riparerebbe. Se questi account si trovano in un altro tenant, il percorso dall'utente compromesso al controllo completo è interrotto. Il nome si rifà al Red Forest, il precedente modello Microsoft di una foresta amministrativa separata per Active Directory.
Che cos'è il Microsoft Enterprise Access Model e che cosa rientra in Tier 0, Tier 1 e Tier 2?
L'Enterprise Access Model divide il tuo ambiente in livelli: la control plane (Tier 0) contiene tutto ciò che gestisce identità e diritti, la management plane (Tier 1) comprende server, applicazioni e workload, e la user access plane (Tier 2) è composta da endpoint e utenti.
La regola che sta dietro è che un livello superiore non deve mai essere controllabile da uno inferiore. In Entra ID al Tier 0 appartengono quindi ruoli come Global Administrator, Privileged Role Administrator, Conditional Access Administrator e Intune Administrator, più Entra Connect e tutto ciò che applica patch, esegue backup o monitora questi sistemi.
Come si realizza in pratica un concept di tiering e da dove si comincia?
Meglio partire da un inventario onesto della control plane, cioè dalla domanda di quali account, gruppi, service account e applicazioni possano oggi modificare identità o diritti. Nella maggior parte degli ambienti sono parecchi di più di quanto si pensasse.
Poi separi gli account per livello, sostituisci le assegnazioni permanenti con PIM e limiti l'accesso ai dispositivi dedicati. Il nostro Tiering Check gratuito ti mostra graficamente dove oggi i confini tra i tier vengono superati, ed è quindi il punto di partenza più rapido che conosciamo.
Perché PIM e Conditional Access da soli non bastano per gli accessi privilegiati?
Entrambi verificano l'identità e le circostanze dell'accesso, ma nessuno dei due verifica il dispositivo a cui è attaccata la tastiera.
Un'autenticazione forte e riuscita finisce in un token sull'endpoint, e se quel dispositivo è compromesso il token viene rubato o la sessione dirottata, benché fino a quel punto PIM e Conditional Access abbiano fatto correttamente il loro lavoro. Il Red Tenant usa entrambi e richiede in più che il dispositivo stesso provenga dall'ambiente isolato.
Che cos'è una Privileged Access Workstation e quando ha bisogno di hardware dedicato?
Una Privileged Access Workstation (PAW) è una postazione hardened usata esclusivamente per attività amministrative, quindi senza mail e senza navigazione generica, con Application Control, senza admin locale e con un trust anchor basato su TPM e Secure Boot.
L'hardware dedicato le serve per tutti i ruoli con accesso alla control plane, perché lì vale il principio della tastiera pulita: una credenziale non deve mai toccare un dispositivo il cui livello di fiducia è inferiore a quello dell'obiettivo. Per il Tier 1 basta la variante virtuale.
PAW o admin workstation virtuale: quando basta la variante virtuale?
Per tutto ciò che sta sotto la control plane. La virtual access workstation (VAW) gira come Azure Virtual Desktop nel Red Tenant, e la raggiungi da un dispositivo office compliant tramite Entra Private Access, con cambio di identità e FIDO2.
Scala senza hardware e copre Azure, Microsoft 365 e on-premises, resta però un rischio residuo, perché l'accesso passa da un dispositivo Tier 2. Proprio per questo la control plane resta riservata alla PAW hardware.
Ogni admin ha bisogno di una workstation separata?
No, ma ogni admin ha bisogno di un'identità separata e di un percorso di accesso separato, e se si tratti di una PAW fisica o di una VAW virtuale lo decide il livello su cui la persona lavora.
Nella pratica solo poche persone hanno diritti Tier 0 e ricevono una PAW hardware, mentre la grande maggioranza lavora tramite VAW. Proprio per questo il modello scala da 5 a 5.000 admin.
Che cosa distingue un Red Tenant da una PAW nel proprio tenant?
La differenza sta nel trust anchor. Una PAW il cui account, le cui policy e la cui gestione dei dispositivi si trovano nello stesso tenant dei sistemi produttivi ne condivide il destino, perché chi controlla il tenant controlla anche la policy Intune che rafforza la PAW.
Il Red Tenant sposta account, dispositivo e gestione in un tenant dedicato, non raggiungibile dal tenant produttivo. La PAW resta lo stesso mattone, solo che poggia su un fondamento diverso.
Che cosa distingue il Red Tenant dal Privileged Access Management?
Le soluzioni PAM custodiscono le credenziali e mediano le sessioni, proteggono quindi la credenziale, ma non il dispositivo da cui viene usata. Se l'endpoint è compromesso, l'attaccante viaggia semplicemente insieme alla sessione mediata, e Microsoft stessa scrive che le soluzioni PAM da sole non coprono in modo affidabile il rischio legato al dispositivo.
Il Red Tenant non sostituisce il PAM, lo completa: PIM e i vault esistenti restano utilizzabili, solo che ora l'accesso arriva da un dispositivo fuori dalla zona di rischio.
Che cosa succede se è glueckkanja stessa a essere compromessa?
Niente che diventi effettivo senza la tua approvazione. Ogni modifica al Red Tenant passa come codice attraverso una pipeline e richiede l'approvazione di un customer approver dalla tua parte, e gli accessi di emergenza sono ripartiti in modo che nessuna delle due parti possa agire da sola.
A questo si aggiunge che amministriamo il tuo ambiente dal nostro Red Tenant, con le stesse regole che valgono per il tuo. Il diritto di veto resta sempre al cliente.
Che cosa richiede NIS2 per gli account admin e gli accessi privilegiati?
L'articolo 21 comma 2 cita tra l'altro le politiche di controllo degli accessi, l'autenticazione a più fattori e la sicurezza nell'acquisizione, nello sviluppo e nella manutenzione dei sistemi, e l'articolo 20 rende la direzione aziendale responsabile di sorvegliare e documentare l'attuazione.
In Germania questo vale da dicembre 2025 tramite la legge sul BSI, in Austria dal 1° ottobre 2026 tramite il NISG 2026. Il BSI-IT-Grundschutz considera la separazione delle attività amministrative un requisito di base e lo spostamento dell'amministrazione in una struttura dedicata un requisito elevato. Il Red Tenant è esattamente la realizzazione cloud di tutto questo, e il repository versionato è la tua prova.
Un concept di tiering è troppo complesso o troppo costoso per una media impresa?
Troppo complesso per la gestione interna spesso lo è davvero, perché la parte costosa non è la tecnologia, ma l'hardening continuo, la manutenzione, il monitoraggio e la raccolta delle prove, che nessuno sbriga nei ritagli di tempo.
È esattamente questo il motivo del managed service: l'impegno sta da noi, dove automazione e ripetizione lo rendono governabile, e un Red Tenant per 20 admin è lo stesso codice di uno per 2.000.
Microsoft ha ritirato il modello Red Forest. Perché allora un tenant admin separato?
Microsoft ha ritirato ESAE perché il modello copriva solo gli amministratori on-premises ed era troppo complesso da gestire, non perché la separazione fosse inefficace.
La stessa documentazione riporta che internamente Microsoft continua a usare un'architettura analoga, raccomanda le PAW per tutte le attività amministrative e, per le risorse che richiedono una protezione particolare, cita espressamente l'isolamento su più tenant. Il Red Tenant è la versione cloud di questo principio, e l'onere di esercizio su cui ESAE è naufragato sta in capo al managed service.
Abbiamo tiering, PIM e Conditional Access. Che cosa cambia un Red Tenant?
Il tiering regola chi può fare che cosa, PIM regola quando, e Conditional Access regola a quali condizioni. Tutti e tre però si trovano nello stesso ambiente che dovrebbero proteggere e sono gestiti da ruoli che anche un attaccante con diritti di Global Admin possiede.
Il Red Tenant porta l'amministrazione fuori da questo ambiente, i tuoi controlli esistenti restano e ricevono un trust anchor che dall'interno non è più raggiungibile.
