telodico.io

Sicurezza

Il tenant non è casa vostra: la sovranità parte da identità, domini e DNS

Il vero lock-in non è solo nei dati, ma nel tenant che governa identità, domini e DNS. Per una PMI mettere ordine qui riduce incidenti, dipendenze e blocchi operativi, prima ancora di parlare di AI o cloud sovrano.

8 min

Il tenant non è casa vostra: la sovranità parte da identità, domini e DNS

Molte PMI pensano al cloud come a un insieme di applicazioni: posta, file, CRM, gestionale, backup, magari un assistente AI. Il punto più delicato, però, sta prima: chi controlla le identità controlla l’azienda. Se l’account amministratore, il dominio, il DNS e l’accesso al tenant sono gestiti male, tutto il resto è arredamento dentro una casa di cui non si possiedono davvero le chiavi.

La sovranità tecnologica non comincia con una dichiarazione patriottica sul data center. Comincia dal poter rispondere a una domanda semplice: se domani il tenant principale viene bloccato, compromesso o reso inutilizzabile da un errore umano, chi rimette in piedi l’accesso ai sistemi? E in quanto tempo?

Per una PMI questa non è burocrazia da grande banca. È continuità operativa. È la differenza tra un disservizio fastidioso e una settimana di lavoro fermo, con clienti che chiamano, fatture che non partono e tecnici che non riescono ad accedere agli strumenti.

1. Il nuovo perimetro aziendale è l’identità

Per anni il perimetro di sicurezza è stato raccontato come una rete: firewall, VPN, server, antivirus. Oggi, in molte aziende italiane, il perimetro reale è l’identità digitale. L’utente entra con lo stesso account nella posta, nei documenti, nel CRM, negli strumenti di firma, nella piattaforma HR, nei tool di ticketing e sempre più spesso nei servizi AI.

Questo ha un vantaggio enorme: meno password disperse, onboarding più rapido, controllo centralizzato. Ma ha anche un rovescio evidente: quando l’identità è fragile, tutto ciò che dipende da quell’identità diventa fragile. Un account amministratore compromesso non apre una sola porta. Apre il quadro elettrico.

La direttiva NIS2 non parla alle PMI con il linguaggio delle mode, ma il punto è chiaro: richiede misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi di sicurezza dei sistemi informativi. Tra queste rientrano la gestione degli incidenti, la continuità operativa, la sicurezza della supply chain, le politiche di controllo degli accessi e l’uso di autenticazione a più fattori.

Non tutte le PMI ricadono direttamente nel perimetro NIS2. Molte però ci arrivano dalla porta laterale: come fornitori di aziende più grandi, come subfornitori industriali, come operatori in filiere dove il cliente comincia a chiedere evidenze minime. La domanda non sarà più soltanto se avete l’antivirus. Sarà: chi può creare utenti? Chi può revocare accessi? Come gestite l’MFA? Avete i log? Come rientrate se l’amministratore non è disponibile?

Anche il GDPR spinge nella stessa direzione. L’art. 32 chiede misure adeguate al rischio, compresa la capacità di assicurare riservatezza, integrità, disponibilità e resilienza dei sistemi e di ripristinare tempestivamente la disponibilità e l’accesso ai dati personali in caso di incidente. Se l’unico modo per ripristinare l’accesso ai dati passa da un account perso o da un tenant irraggiungibile, la resilienza è più dichiarata che reale.

2. Il lock-in più sottovalutato non è il file: è il pannello di controllo

Quando si parla di vendor lock-in si pensa spesso ai dati: posso esportare le email? Posso migrare i file? Posso cambiare CRM? Sono domande giuste, ma incomplete. Il lock-in più pericoloso, nelle aziende operative, è quello del control plane: il pannello da cui si governano identità, domini, gruppi, permessi, applicazioni collegate, chiavi API e fatturazione.

Un tenant Microsoft 365, Google Workspace, Okta, JumpCloud o di qualunque altro provider non è solo un servizio. È spesso il registro anagrafico digitale dell’azienda. Dentro ci sono utenti, gruppi, ruoli amministrativi, dispositivi, applicazioni SSO, token OAuth, policy MFA, regole di accesso condizionale, talvolta anche la gestione dei device. È comodo, ma non va confuso con la proprietà assoluta.

Il problema non è usare un grande vendor. Il problema è usarlo come se fosse un notaio neutrale delle vostre chiavi. Non lo è. Ha condizioni contrattuali, procedure di recupero, canali di supporto, sistemi antifrode, automatismi di sospensione, vincoli di fatturazione. In circostanze normali funzionano. In circostanze anomale possono diventare il collo di bottiglia.

La scena si è già vista in molte varianti: dominio comprato anni prima da un consulente e mai trasferito; DNS gestito dentro un account personale; tenant creato con una carta aziendale ormai scaduta; amministratore globale associato alla casella di un dipendente uscito; MFA configurata sul telefono di una sola persona; account di recupero che punta alla stessa posta che non funziona. Non sono casi esotici. Sono il quotidiano di una digitalizzazione fatta bene sul piano della produttività e male sul piano del controllo.

La sovranità, qui, è molto concreta. Significa sapere chi ha le chiavi, dove sono registrate, come si revocano, come si recuperano e chi risponde quando il recupero non va a buon fine. Non serve un progetto di identity management da multinazionale. Serve smettere di trattare identità, dominio e DNS come dettagli tecnici lasciati al caso.

3. Domini e DNS: le chiavi che nessuno mette nel piano di continuità

Il dominio aziendale è uno degli asset più critici e meno governati. Senza dominio non c’è posta credibile, non ci sono login federati, non ci sono siti, non ci sono record DNS per SPF, DKIM e DMARC, non ci sono verifiche di proprietà per molti servizi cloud. Eppure in troppe PMI il dominio è trattato come una bolletta: si rinnova finché qualcuno se ne ricorda.

La prima separazione sana è tra dominio, DNS e tenant applicativo. Non significa per forza usare tre fornitori diversi. Significa evitare che un singolo incidente su un account blocchi contemporaneamente posta, autenticazione, sito e possibilità di cambiare configurazione. Se il DNS vive dentro lo stesso ecosistema compromesso o sospeso, anche la migrazione di emergenza diventa più lenta.

Il registrar deve essere intestato all’azienda, non al fornitore storico, non all’ex socio, non alla casella personale del titolare. L’accesso deve avere MFA, contatti aggiornati e procedure di recupero note. I codici di trasferimento e le scadenze non possono vivere solo nella memoria di qualcuno. Lo stesso vale per il DNS: chi può cambiare i record MX? Chi può modificare un CNAME usato da un servizio critico? Chi approva una variazione?

In un incidente reale, il DNS è spesso la leva per deviare traffico, attivare una pagina temporanea, cambiare provider di posta, verificare un nuovo servizio, isolare una piattaforma compromessa. Se quella leva non è disponibile, si resta in attesa. E l’attesa, durante un fermo operativo, costa più del canone del provider.

Per una PMI la buona notizia è che la messa in ordine è relativamente economica. Un system integrator competente può fare in poche giornate ciò che spesso manca da anni: censire i domini, verificare le intestazioni, consolidare il DNS, attivare l’MFA, documentare gli accessi, impostare contatti di recupero non banali, separare i ruoli amministrativi. Non è trasformazione digitale. È igiene industriale.

4. MFA obbligatoria, ma non ingenua

Dire “MFA” non basta. Anche qui il mercato ha venduto una scorciatoia: attivate il secondo fattore e siete a posto. Non è così. Un’MFA configurata male protegge poco e può persino creare un falso senso di sicurezza.

Il caso peggiore è l’amministratore globale con MFA via SMS o con una notifica push approvata distrattamente. Il phishing moderno non chiede più soltanto la password: intercetta sessioni, inganna l’utente con pagine credibili, sfrutta la stanchezza da notifiche. Per gli account più sensibili le soluzioni migliori sono credenziali resistenti al phishing, come le security key FIDO2 o le passkey gestite con criterio. Non serve distribuirle subito a tutta l’azienda. Ma sugli account amministrativi e sugli accessi al registrar, al DNS, al password manager e al tenant principale dovrebbero essere la norma.

C’è poi il tema degli account di emergenza, i cosiddetti break-glass. Devono esistere, ma non devono diventare una porta di servizio dimenticata. Un account di emergenza serve per rientrare quando le policy ordinarie bloccano tutti o quando un sistema di autenticazione secondario ha un problema. Va protetto, monitorato e testato. Se viene usato, deve generare un allarme. Se non viene mai verificato, è solo una promessa.

Un assetto minimo e realistico per una PMI può essere questo:

  • almeno due amministratori nominativi, non condivisi, con privilegi separati e MFA forte;
  • un account di emergenza documentato, custodito e monitorato, con procedura d’uso chiara;
  • accesso al registrar e al DNS protetto con MFA resistente al phishing per chi amministra;
  • password manager aziendale non dipendente in modo cieco dallo stesso SSO che dovrebbe proteggere;
  • log amministrativi conservati abbastanza a lungo da ricostruire cosa è successo;
  • revisione periodica di app OAuth, token, dispositivi e utenti esterni.

Non è una lista da audit cosmetico. È il minimo per poter dire che l’identità è governata e non soltanto subita. La complessità può crescere dopo, quando serve. Prima bisogna eliminare le fragilità che mandano in crisi l’azienda al primo imprevisto.

5. L’AI rende l’identità ancora più centrale

L’arrivo dell’AI in azienda sposta ulteriore peso sull’identità. Un assistente collegato alla posta, ai documenti o al CRM non inventa nuovi permessi: usa quelli che trova. Se i gruppi sono sporchi, se gli utenti hanno accessi accumulati negli anni, se i documenti riservati sono condivisi con mezza azienda, l’AI amplifica il disordine.

Il punto non è fermare l’AI. È evitare di innestarla su un sistema di identità confuso. Prima di dare a un assistente la capacità di cercare, riassumere, proporre risposte o azionare workflow, bisogna sapere quali identità può impersonare, quali dati può leggere, quali azioni può compiere e dove finiscono i log. Vale per gli strumenti integrati nelle suite più diffuse e vale per le soluzioni costruite con modelli, RAG e connettori su misura.

L’AI Act introduce un quadro di obblighi differenziati per i sistemi di AI. Molte applicazioni d’ufficio usate da una PMI non saranno sistemi ad alto rischio, ma il tema del controllo resta. Non per fare teatro normativo, ma perché un assistente con accesso ai dati aziendali è un nuovo livello operativo. E ogni nuovo livello operativo deve avere identità, permessi, log e possibilità di revoca.

Qui la scelta infrastrutturale pesa. Se tutta l’AI passa dal tenant principale, quel tenant diventa ancora più critico. Se invece si costruiscono componenti AI più portabili, con dati indicizzati in un ambiente controllato e connettori governati, si riduce la dipendenza da un singolo fornitore. Non è una scelta ideologica. È architettura del rischio.

Per molte PMI la soluzione ragionevole è ibrida: usare gli strumenti integrati dove danno produttività immediata, ma tenere sotto controllo i dati sensibili, i permessi e le integrazioni. Un integratore vicino, che conosce il gestionale, la posta, i reparti e i fornitori reali, spesso vale più di una piattaforma presentata come universale. L’AI utile non nasce dal comprare la licenza più rumorosa. Nasce dal sapere quali processi si possono automatizzare senza consegnare le chiavi dell’azienda a un meccanismo opaco.

6. Le domande da fare lunedì mattina

Il governo dell’identità non richiede un comitato permanente. Richiede una fotografia onesta e alcune decisioni pratiche. Le PMI sono agili proprio perché non hanno bisogno di mesi per muoversi, se la direzione capisce il rischio e lo traduce in priorità operative.

Le domande iniziali sono poche, ma scomode:

  • chi possiede formalmente il dominio e chi riceve gli avvisi di rinnovo;
  • dove sono gestiti i DNS e chi può modificarli;
  • quanti amministratori globali esistono nel tenant principale;
  • quali account hanno MFA forte e quali usano ancora metodi deboli;
  • come si entra se l’amministratore principale è indisponibile;
  • quali applicazioni esterne hanno accesso via SSO, OAuth o API;
  • quali log sono disponibili e per quanti giorni;
  • quali fornitori possono intervenire sugli accessi e con quali limiti.

Le risposte non devono finire in un manuale da cento pagine. Devono produrre cambiamenti concreti: togliere privilegi inutili, intestare correttamente i domini, proteggere gli account critici, separare le credenziali di emergenza, verificare i contatti di recupero, definire chi chiama chi in caso di blocco. Poi si testa. Un piano non provato è un racconto.

Il fornitore giusto, in questo lavoro, non è quello che vende la console più sofisticata. È quello che accetta di mettere ordine anche nelle cose noiose: registrar, DNS, utenti usciti, gruppi, MFA, password manager, log, procedure di recupero. La sicurezza reale delle PMI passa spesso da queste attività poco scenografiche. Non fanno keynote, ma salvano giornate di lavoro.

La tesi è semplice: se il tenant non è governato, non è casa vostra. Può essere un ottimo ufficio in affitto, efficiente e moderno, ma le chiavi vanno gestite con disciplina. Identità, domini e DNS sono il livello zero della sovranità digitale. Prima del cloud sovrano, prima dell’AI, prima dei grandi piani di compliance, bisogna sapere chi può aprire la porta, chi può chiuderla e come si rientra quando qualcosa va storto.

Riferimenti

Fonti ufficiali

Le versioni autoritative restano quelle pubblicate dagli enti competenti. Verifica sempre alla fonte prima di prendere decisioni operative.

In sintesi

Domande frequenti

Da dove conviene partire concretamente per mettere in sicurezza identità, domini e DNS senza avviare un progetto enorme?

Si parte da una fotografia onesta: censire i domini e verificarne l'intestazione, capire dove sono gestiti i DNS e chi può modificarli, contare gli amministratori globali e verificare quali account hanno MFA forte. Sono attività che un integratore competente può completare in poche giornate. L'obiettivo iniziale non è la sofisticazione, ma eliminare le fragilità che bloccano l'azienda al primo imprevisto.

La mia PMI non rientra direttamente nel perimetro NIS2: devo comunque preoccuparmi di questi controlli?

Sì, perché molte PMI vi arrivano dalla porta laterale come fornitori o subfornitori di aziende più grandi soggette agli obblighi. I clienti inizieranno a chiedere evidenze minime su chi crea utenti, come si gestisce l'MFA, quali log esistono e come si rientra se l'amministratore è indisponibile. Inoltre l'art. 32 del GDPR chiede comunque misure adeguate al rischio e capacità di ripristino.

Ho già attivato l'MFA su tutti gli account: posso considerarmi al sicuro?

Non necessariamente. Un'MFA via SMS o basata su notifiche push approvate distrattamente protegge poco contro il phishing moderno, che intercetta sessioni e sfrutta la stanchezza da notifiche. Per gli account amministrativi, il registrar, il DNS e il password manager servono credenziali resistenti al phishing come le security key FIDO2 o le passkey gestite con criterio.

Cosa sono gli account break-glass e come vanno gestiti senza che diventino un rischio?

Sono account di emergenza che permettono di rientrare quando le policy ordinarie bloccano tutti gli utenti o quando un sistema di autenticazione secondario ha un problema. Devono esistere, essere documentati, custoditi e monitorati, con una procedura d'uso chiara. Se vengono usati devono generare un allarme; se non vengono mai verificati sono solo una promessa non testata.

Vogliamo introdurre un assistente AI collegato a posta e documenti: quali rischi lato identità dobbiamo valutare prima?

Un assistente AI non crea nuovi permessi: usa quelli che trova. Se gruppi sporchi, accessi accumulati negli anni e documenti riservati condivisi con mezza azienda esistono già, l'AI amplifica il disordine. Prima di attivarlo bisogna sapere quali identità può impersonare, quali dati può leggere, quali azioni può compiere e dove finiscono i log, per garantire tracciabilità e revoca.

Perché separare dominio, DNS e tenant applicativo se il fornitore unico è più comodo da gestire?

Perché un singolo incidente su un account non deve bloccare contemporaneamente posta, autenticazione, sito e possibilità di riconfigurare. Se il DNS vive nello stesso ecosistema compromesso o sospeso, anche la migrazione di emergenza rallenta. Il DNS è spesso la leva per deviare traffico, cambiare provider di posta o isolare una piattaforma; se non è disponibile, il fermo operativo si allunga.

Discussione (0)

Carico…


Per commentare serve un'identità verificata. Inserisci la tua email: riceverai un link per accedere senza password.