Admin e quotidianità sullo stesso computer? Game Over.

Un computer, due tab, un clic

Lo scenario non ha niente di spettacolare, ed è proprio questo a renderlo così pericoloso: un amministratore è al suo solito laptop office. Nel tab di sinistra del browser è aperto il Microsoft 365 Admin Center, diritti di global admin e di Intune admin inclusi. Nel tab di destra scarica un «tool gratuito», Invoice_2026.pdf.exe. Un clic, un payload PowerShell, persistenza stabilita, privilege escalation in corso. La strada verso il Tier 0, verso il cuore dell'IT aziendale, è aperta.

Game Over.

MITRE ATT&CK documenta attualmente 222 tecniche per gli ambienti enterprise, più 475 sotto-tecniche, insieme quasi 700 modi noti per escalare privilegi, muoversi lateralmente e raggiungere gli asset più sensibili di un'azienda. Agli attaccanti ne serve esattamente uno. E nella maggior parte degli interventi di incident response che accompagniamo emerge lo stesso schema: si amministrava sullo stesso dispositivo su cui si leggevano email, si navigava e si chattava in Teams.

Chi prende sul serio l'«Assume Breach», e con NIS2 le alternative sono poche, deve accettare una conseguenza scomoda: alcune cose semplicemente non devono stare sullo stesso computer. Una separazione a metà non è una separazione.

Perché le risposte più ovvie non bastano

I riflessi consueti li conosciamo tutti. Jump server? Un tunnel reverse proxy dal client compromesso, e l'attaccante passa a cavallo direttamente attraverso la jump box: stessa macchina, stesso browser, stesso rischio. Costruire un privileged access management (PAM) classico nel proprio tenant? Allora si pone subito la domanda: chi gestisce l'ambiente di management? Se le admin workstation protette vivono nello stesso tenant che dovrebbero proteggere, si è costruito un cerchio, non un muro. E il desktop virtuale usato dal laptop office? Erediterà il suo keylogger. Lo schermo è virtuale, i tasti premuti sono reali. Lo Zero Trust finisce esattamente dove admin e quotidianità si dividono un dispositivo.

Il Managed Red Tenant: la separazione come architettura

È esattamente qui che entra in gioco il Managed Red Tenant (MRT): un ambiente tenant dedicato, gestito integralmente tramite codice e irrobustito in modo massiccio, destinato esclusivamente al lavoro amministrativo. Per i compiti di Tier 0 sono disponibili privileged access workstation (PAW) gestite come Managed Service, PAW hardware irrobustite come dispositivi fisici dedicati. Per il lavoro di Tier 1 servono le VAW, access workstation virtuali basate su Azure Virtual Desktop, raggiungibili solo da compliant device, solo con FIDO2, solo con Conditional Access. Il tutto integrato da iPad configurati in modo specifico e con la massima sicurezza, per maggiore comodità.

Il punto decisivo per i CIO non è però la tecnica, ma il modello operativo. Ogni modifica al Red Tenant passa come Configuration as Code attraverso una pipeline CI/CD e viene deployata solo dopo un'approvazione esplicita del cliente. Questo principio di shared responsibility risponde alla domanda che ogni acquirente di managed services dovrebbe porre: cosa succede se il fornitore stesso viene compromesso? La risposta: niente. Senza l'approvazione del cliente nel Red Tenant non cambia una riga di configurazione. Il livello di management sta fuori dalla zona di rischio del cliente, il diritto di veto resta al cliente.

Il guadagno operativo è doppio. In primo luogo nasce una nitidezza di separazione che si ha raramente: ogni accesso amministrativo legittimo all'ambiente di produzione arriva per definizione da una macchina MRT. Tutto il resto è un attacco. Questo dà al SOC un segnale senza rumore, a cui può reagire subito invece di smistare falsi allarmi. In secondo luogo, in caso di attacco riuscito all'ambiente office c'è di mezzo un muro, non un dosso: il salto da un laptop office compromesso a una PAW hardware che sta accanto sulla scrivania come dispositivo separato è estremamente difficile, fino a impossibile, per gli attaccanti.

E se succede comunque? L'Extra Life.

Ogni CIO esperto lo sa: la sicurezza al cento per cento non esiste. Assume breach significa anche mettere in conto il fallimento della propria difesa. Il caso Stryker del marzo 2026 ha mostrato quanto sia sottile il confine: è bastato un account admin Intune compromesso per cancellare dispositivi in 79 paesi. I gruppi ransomware oggi puntano in modo mirato ai backup, all'Active Directory, esattamente ai sistemi che servirebbero per la ricostruzione. Chi a quel punto comincia a improvvisare, con fileserver cifrati, senza identità funzionanti, con una catena telefonica invece di un'infrastruttura di comunicazione, perde giorni e settimane in cui l'azienda è ferma.

Se il Red Tenant evita che si arrivi al «Game Over», allora il Managed Dark Tenant è l'Extra Life: un ambiente di ripristino preparato, dormiente nella normale operatività, che viene attivato in caso di emergenza. Una chiamata al numero di emergenza 24/7 avvia il processo di disaster recovery. Una war room virtuale stabilisce immediatamente una comunicazione sicura con tutti gli stakeholder chiave, indipendentemente dall'ambiente di produzione eventualmente compromesso. Poiché il Dark Tenant è costruito come Infrastructure as Code, tutti i processi critici di ripristino sono predefiniti e automatizzati: i componenti di sistema critici come Active Directory e le identità vengono ripristinati in modo pulito, invece di essere assemblati ad hoc sotto stress. Il risultato: un recovery time objective (RTO) da poche ore a pochi giorni e un recovery point objective (RPO) definito, invece delle settimane che nella pratica i ripristini improvvisati costano regolarmente.

Resilienza in doppia copia

Red Tenant e Dark Tenant rispondono a due domande diverse, che solo insieme danno un quadro completo. Il Red Tenant risponde: come evito che un client compromesso diventi mai un dominio compromesso? Il Dark Tenant risponde: come resto operativo se succede comunque? Uno è il muro, l'altro il telo di salvataggio.

Per le aziende austriache si aggiunge una dimensione regolamentare, e diventerà presto molto concreta. Con il NISG 2026, che entra in vigore il 1° ottobre 2026, circa 4.000 aziende austriache ricadono sotto obblighi di cibersicurezza dimostrabili, espressamente inclusi risk management, business continuity, piano di emergenza e gestione delle crisi. Chi può spiegare all'organo di vigilanza che gli accessi amministrativi sono isolati architetturalmente e che per l'emergenza è pronto un ambiente di ripristino testato e automatizzato conduce una discussione diversa da chi rimanda a corsi di awareness e alla speranza.

Entrambi i servizi li gestiamo come Managed Service, con un team che come fornitore di APT response qualificato dal BSI si trova regolarmente sull'altro fronte, quando l'incendio è già in corso, e che fa rifluire questa esperienza direttamente nell'architettura. Tra i nostri clienti figurano gruppi del DAX così come operatori di infrastrutture critiche.

Alcune cose non devono stare sullo stesso computer. E alcune aziende non possono permettersi un Game Over. Allora meglio con muro ed Extra Life.