Logo NEXSYS menu
Cybersecurity
Corso Cybersecurity Specialist
Corso Blue Team
Corso Ethical Hacking
Corso Incident Responder
Corso Secure Coding
Sistemi & Cloud
Corso Sistemista e Networking
Corso Microsoft 365 Administration
Corso Windows Server Administration
Corso AZ-104 Azure Administrator
Corso Active Directory
Data, AI & Programmazione
Corso Programmazione C#
Corso ASP.NET
Corso React
Corso Machine Learning
Corso Power BI PL-300
Digital Skills & Trends
Corso Microsoft 365 per utenti
Corso Security Awareness
Corso NIS2
Corso AI per aziende
Corso Microsoft 365 Copilot
Modalità & extra
Calendario
Catalogo Pdf
Percorsi Microsoft
Corsi finanziati
Open Badge digitali
Tutti i corsi di Cybersecurity
Tutti i corsi di Sistemi & Cloud
Tutti i corsi di Data & Programmazione
Tutti i corsi di Digital Skills & Trends

Cybersecurity
Consulenza Cybersecurity
Penetration Test
Assessment AD
SOC As a Service
Data Protection DPaaS
Microsoft & Cloud
Soluzioni Modern Workplace
Migrazione Microsoft 365
Microsoft 365 Security Assessment
Consulenza Cloud
Cloud Backup & Recovery
Infrastruttura & Sistemi
Network Security
Firewall aziendali
DNS Security
Endpoint Management (UEM)
Secure Access Service Edge (SASE)
Manifatturiero & Industria 4.0
Servizi, Logistica & GDO
Sanità & Pharma
Pubblica Amministrazione
Studi Professionali

Progettiamo la tua soluzione su misura →

La nostra identità
Certificazioni & Partner
Portfolio clienti
ISO 9001

Nexsys Srl è certificata
ISO 9001:2015

Microsoft Solutions Partner

Siamo Microsoft Solution Partner per il Modern Work

APPROFONDIMENTI E NEWS

Cos’è la Shadow AI e quali sono i rischi per la sicurezza aziendale

Molte organizzazioni sono convinte che il proprio perimetro di sicurezza sia inviolabile, specialmente dopo aver implementato blocchi di rete sui principali assistenti digitali pubblici. La realtà, tuttavia, è molto diversa. Spinti dalla necessità di ottimizzare i tempi e aumentare la produttività quotidiana, i dipendenti integrano autonomamente strumenti di Intelligenza Artificiale nei propri flussi di lavoro, spesso all'insaputa dell'azienda.

Questo fenomeno invisibile prende il nome di Shadow AI.

silouette di un team it di spalle davanti alla scritta shadow ai con icone digitali di lucchetti e monitoraggio della rete.

Shadow AI: il significato del fenomeno

In sintesi: con il termine Shadow AI si definisce l'utilizzo di strumenti, software o servizi basati sull'Intelligenza Artificiale all'interno di un contesto lavorativo senza l'esplicita autorizzazione, il censimento o il controllo da parte dei dipartimenti tecnici e di sicurezza aziendali.

Si tratta dell'evoluzione diretta della vecchia Shadow IT (quando si usavano software o servizi cloud non autorizzati), ma con una velocità di diffusione e un impatto sui dati nettamente superiori. I dipendenti non lo fanno con intenzioni dolose: la tecnologia è accessibile, risolve problemi pratici in pochi secondi e l'adozione avviene in totale buona fede per "fare meglio e prima" il proprio lavoro.

Come si manifesta la Shadow AI nella pratica aziendale?

Quando si pensa all'Intelligenza Artificiale Generativa, il pensiero corre subito alle chat testuali più famose accessibili da browser. In realtà, il fenomeno è molto più subdolo e si nasconde in strumenti insospettabili che i dipendenti utilizzano ogni giorno in totale buona fede:

  • Estensioni del browser non verificate: Correttori di bozze, traduttori automatici o assistenti di scrittura che analizzano in tempo reale i testi digitati dall'utente, inviandoli a server esterni per l'elaborazione.
  • Plugin per lo sviluppo di codice: Estensioni integrate direttamente negli ambienti di programmazione, utilizzate dagli sviluppatori per ottimizzare o correggere stringhe di codice software proprietario.
  • Piattaforme web di grafica e video: Applicazioni online per la manipolazione di immagini aziendali o la creazione di presentazioni che non garantiscono la riservatezza dei materiali caricati.

Il tratto comune di tutte queste situazioni è l'assenza di una licenza Enterprise protetta. Senza un accordo commerciale in cui il fornitore garantisce la totale riservatezza, qualunque dato inserito cessa di essere privato.

I principali rischi della Shadow AI per l'azienda

L'utilizzo incontrollato di queste tecnologie espone l'organizzazione a vulnerabilità strutturali che toccano tre macro-aree critiche: la sicurezza informatica, la tutela legale e la compliance normativa.

1. Data Leakage nei prompt pubblici

È il rischio più frequente. Quando un dipendente inserisce un report finanziario, un verbale di riunione, dati sensibili di clienti o porzioni di codice all'interno di un tool gratuito, quelle informazioni escono dal perimetro aziendale. Se il modello non è configurato per garantire la privacy, i dati inseriti entrano nel dataset di addestramento pubblico del fornitore, diventando potenzialmente accessibili all'esterno.

2. Violazione del GDPR e sanzioni dell'AI Act

L'inserimento di dati personali in piattaforme non censite configura un trattamento illecito e una violazione diretta del GDPR. A questo si aggiungono i severi obblighi imposti dall'AI Act europeo, la normativa che impone alle aziende il censimento e la classificazione dei sistemi IA in uso in base al loro livello di rischio. La presenza di Shadow AI rende impossibile questa mappatura, esponendo l'organizzazione a pesanti sanzioni finanziarie.

3. Perdita di tutela legale degli asset

Gli output generati interamente da un'IA commerciale spesso non sono protetti da copyright. Se un team utilizza tool non autorizzati per creare software, testi strategici o materiali di marketing core, l'azienda rischia di non poter tutelare legalmente quegli asset, rendendoli liberamente copiabili dai concorrenti. Inoltre, aumenta il rischio di plagio involontario derivante da modelli addestrati su dati protetti da proprietà intellettuale altrui.

dettaglio di un occhio cibernetico con il logo ai sulla pupilla, circondato da flussi di codice binario azzurro su sfondo scuro.

Come rilevare la Shadow AI in azienda

Per i team tecnici, il primo passo operativo consiste nell'ottenere visibilità sul traffico di rete. Non si può governare ciò che non si conosce. Per mappare l'uso dell'IA non autorizzata, sul mercato esistono software specifici di monitoraggio — definiti Shadow AI detection tools (spesso integrati nelle soluzioni di sicurezza Cloud e di rete) — che identificano e tracciano le connessioni verso i server dei modelli generativi.

Se vuoi avviare un audit tecnico nella tua infrastruttura, i principali strumenti standard di mercato su cui fare affidamento sono:

  • Soluzioni CASB (Cloud Access Security Broker): Strumenti come Microsoft Defender for Cloud Apps, Netskope o Skyhigh Security. Sono i più efficaci perché analizzano l'uso delle applicazioni Cloud in tempo reale, catalogano i tool di IA usati dai dipendenti e assegnano a ciascuno un livello di rischio in base alla compliance (es. se il tool usa i dati per l'addestramento o no).
  • Filtri DNS e Firewall di Nuova Generazione (NGFW): Sistemi come Cisco Umbrella o le funzionalità evolute di firewall come Fortinet e Palo Alto Networks. Permettono di categorizzare il traffico web e segnalare istantaneamente quando un dispositivo aziendale tenta di scambiare dati con domini legati a servizi di IA generativa emergenti o non censiti.

Non sai da dove partire per mappare i tool non autorizzati?

Contattaci per un’analisi personalizzata con i nostri tecnici.

Come governare il fenomeno: la "AI Policy"

Vietare l'utilizzo dell'Intelligenza Artificiale è una strategia inefficace che non ferma il bisogno di efficienza, ma si limita a spingerlo fuori dal controllo aziendale (alimentando, appunto, la Shadow AI). La soluzione risiede nel governare il fenomeno.

Il primo passo operativo è la creazione di una AI Policy aziendale: un documento ufficiale che stabilisca linee guida chiare sul trattamento dei dati, divida le attività consentite da quelle vietate e definisca una whitelist di strumenti ufficiali e protetti messi a disposizione dall'azienda.

Vuoi mappare il rischio nella tua organizzazione?

Abbiamo preparato una guida pratica e gratuita che include la checklist di autovalutazione per i responsabili IT, Legal e HR e il framework strutturato per creare le tue policy interne.

La tecnologia non basta: il ruolo centrale della formazione

Una policy scritta e un'infrastruttura sicura sono strumenti indispensabili, ma restano fragili se non sono supportati da un cambiamento culturale. La sicurezza informatica e la compliance normativa nell'era dell'Intelligenza Artificiale dipendono interamente dalle competenze delle persone.

I dipendenti devono essere messi in condizione di comprendere il perché determinati utilizzi siano rischiosi, imparando a sfruttare le potenzialità dell'IA in modo sicuro, etico e in linea con gli obiettivi di business dell'organizzazione. La formazione aziendale è l'unico vero ponte in grado di trasformare la Shadow AI in un'opportunità di innovazione governata e competitiva.

Per supportare le organizzazioni in questa transizione, abbiamo sviluppato il Corso di Intelligenza Artificiale per aziende di Nexsys: un percorso formativo personalizzato e orientato al business, progettato specificamente per fornire ai team le competenze necessarie a utilizzare i modelli generativi in totale sicurezza. Attraverso sessioni pratiche, aiutiamo le imprese ad azzerare i rischi di data leakage e ad allineare l'operatività quotidiana dei diversi reparti alle normative vigenti come il GDPR e l'AI Act, trasformando un potenziale pericolo in un vantaggio competitivo concreto.

Prerequisiti tecnici prima del rollout

Prima di abilitare FIDO2 con Cloud Kerberos Trust in produzione, conviene trattare il progetto come un intervento di architettura identita ibrida, non come una semplice opzione di portale. I prerequisiti principali riguardano client, tenant, dominio Active Directory, sicurezza Kerberos, sincronizzazione directory e gestione del dispositivo.

Area

Verifica richiesta

Client Windows

Windows 10 versione 2004 o successiva, oppure Windows 11. Preferibile standardizzare su build aggiornate e gestite.

Join del dispositivo

Dispositivi Microsoft Entra joined o hybrid joined, con registrazione corretta e utente sincronizzato.

Active Directory

Domain Controller Windows Server 2016 o successivi, patching aggiornato, replica sana, DNS e time sync corretti.

Kerberos

Verificare supporto AES e dismissione algoritmi deboli. Per l’approfondimento operativo vedere disabilitare RC4 in Kerberos.

Sincronizzazione identita

Entra Connect o Cloud Sync correttamente configurato, con attributi necessari e utenti sincronizzati verso Entra ID.

Ruoli amministrativi

Privilegi separati tra dominio e cloud; usare account dedicati e tracciare le operazioni eseguite.

Gestione dispositivi

Policy Intune o GPO coerenti. Nei tenant moderni il canale preferenziale e Endpoint Management e UEM con Microsoft Intune.

Sicurezza tenant

Verificare metodi di autenticazione, Conditional Access, breakglass e account privilegiati tramite Microsoft 365 Security Assessment.

 

Progettazione consigliata Nexsys

L’errore tipico e abilitare FIDO2 a tutti gli utenti senza segmentazione, senza pilota e senza processo di recovery. Un progetto passwordless deve invece partire da un disegno operativo: chi usa FIDO2 fisico, chi usa Windows Hello for Business, quali gruppi vengono abilitati, quali account sono esclusi, come si gestisce lo smarrimento della chiave, quali controlli vengono applicati da Conditional Access e quali risorse on-premises sono coinvolte.

  1. Assessment iniziale su tenant e dominio, collegando la verifica cloud al Microsoft 365 Security Assessment e la verifica AD all’Assessment & Hardening Active Directory.
  2. Definizione dei gruppi pilota: IT, amministratori selezionati, utenti high-value, poi progressione per reparti.
  3. Scelta del metodo: FIDO2 hardware per ruoli critici, Windows Hello for Business per utenti con PC gestiti, eventuali passkey solo dove il modello di rischio lo consente.
  4. Configurazione Microsoft Entra Kerberos nel dominio Active Directory interessato.
  5. Distribuzione policy client tramite Intune o GPO, con controlli su TPM, PIN, biometria, hardware security device e cloud trust.
  6. Test controllati su file share, applicazioni IIS, stampanti, mappature di rete, VPN, accessi remoti e scenari di recovery.
  7. Rollout progressivo con reportistica, troubleshooting e revisione periodica dei metodi di autenticazione registrati.

Configurazione Microsoft Entra Kerberos

Il cuore tecnico del modello e la creazione dell’oggetto AzureADKerberos nel dominio Active Directory. L’oggetto si comporta in modo simile a un oggetto RODC logico usato da Microsoft Entra ID per l’emissione dei ticket Kerberos necessari. Non e un Domain Controller fisico e non sostituisce il controllo locale delle autorizzazioni.

La configurazione va eseguita con account amministrativi separati per il piano cloud e per il dominio. Nel modello operativo Nexsys e preferibile usare sessioni tracciate, MFA phishing-resistant sugli amministratori e un processo di change documentato. Gli account di emergenza devono essere gia definiti; la guida interna correlata e Breakglass in Entra ID.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

 

$domain = $env:USERDNSDOMAIN

$cloudCred = Get-Credential    # Hybrid Identity Administrator o ruolo equivalente

$domainCred = Get-Credential   # Domain Admin per il dominio interessato

 

Set-AzureADKerberosServer -Domain $domain `

  -CloudCredential $cloudCred `

  -DomainCredential $domainCred

 

Dopo la configurazione, il dominio deve essere verificato lato replica AD, lato portale Entra e lato client. In ambienti multi-dominio o multi-foresta non va dato per scontato che un solo intervento copra tutto il perimetro: ogni dominio interessato va valutato in base a utenti, risorse e trust esistenti.

Abilitazione FIDO2 e metodi passwordless in Entra ID

Il metodo FIDO2 va abilitato in Authentication Methods di Microsoft Entra ID con targeting per gruppi. La configurazione deve essere esplicita: gruppi abilitati, eventuale attestation, restrizioni sui modelli di chiave supportati, criteri di registrazione e processo di revoca. Per account privilegiati e ruoli critici, la governance deve rientrare in un disegno piu ampio di Identity Security.

  • Creare gruppi pilota dedicati per FIDO2 e per Windows Hello for Business.
  • Abilitare FIDO2 solo ai gruppi selezionati nella prima fase.
  • Documentare modelli di security key ammessi, PIN policy e processo di consegna.
  • Prevedere almeno un metodo di recupero forte e controllato, evitando ritorni incontrollati a fattori deboli.
  • Eseguire audit periodico dei metodi registrati dagli utenti e degli account senza metodo forte.

Policy client: Intune o GPO

Una volta pronto il piano identita, il client deve ricevere policy coerenti. Negli ambienti cloud-managed, Intune e il canale piu naturale per standardizzare Windows Hello for Business, requisiti TPM, PIN, biometria, uso di cloud trust e configurazioni di sicurezza endpoint. Negli ambienti ancora fortemente on-premises, le GPO restano utilizzabili, ma devono essere mantenute coerenti con la strategia Entra ID.

Canale

Configurazioni da presidiare

Microsoft Intune / Endpoint Management

Abilitare Windows Hello for Business, Cloud Trust for on-premises authentication, requisiti TPM/security device, profili account protection, compliance e Conditional Access.

Group Policy

Abilitare Windows Hello for Business, usare Cloud Kerberos Trust per autenticazione on-premises, definire policy PIN/biometria e hardware security device dove richiesto.

Conditional Access

Rendere coerenti i controlli con device compliance, ruoli amministrativi, rischio accesso e metodi di autenticazione resistenti al phishing.

 

Test di validazione prima della produzione

Il test non deve limitarsi al fatto che l’utente riesca ad accedere a Windows. Il vero obiettivo e verificare che l’utente acceda senza password e continui a usare le risorse on-premises senza prompt aggiuntivi, senza fallback manuale alla password e senza perdita di autorizzazioni.

  • Login Windows con security key FIDO2 o Windows Hello for Business.
  • Verifica PRT e stato registrazione dispositivo.
  • Accesso a file share SMB con permessi basati su gruppi AD.
  • Accesso ad applicazioni interne con Integrated Windows Authentication.
  • Mappatura stampanti o drive di rete dove ancora presenti.
  • Test da rete aziendale, VPN e scenario remoto previsto dall’organizzazione.
  • Verifica ticket con klist e analisi event log Kerberos lato client e Domain Controller.
  • Test di smarrimento chiave, reset metodo e revoca accesso.
  • Test sugli account esclusi o privilegiati, senza modificare impropriamente la Password Replication Policy.

Comandi utili per troubleshooting

In fase di troubleshooting conviene partire da evidenze semplici: stato dispositivo, PRT, ticket Kerberos, connettivita verso Domain Controller, DNS, time sync, gruppi utente e policy applicate. La presenza di un login passwordless riuscito non garantisce automaticamente che il ticket Kerberos sia utilizzabile verso ogni risorsa locale.

dsregcmd /status

 

klist

klist purge

 

whoami /groups

nltest /dsgetdc:contoso.local

Test-NetConnection dc01.contoso.local -Port 88

Test-NetConnection dc01.contoso.local -Port 445

 

Se il problema riguarda solo alcune risorse, analizzare ACL, SPN, DNS, trust, deleghe e configurazione Kerberos del servizio. Se il problema riguarda tutti gli accessi on-premises dopo login passwordless, la causa e piu probabilmente nella configurazione Entra Kerberos, nella policy client, nella sincronizzazione utente o nella connettivita verso i Domain Controller.

Limiti e scenari da non forzare

FIDO2 con Cloud Kerberos Trust e potente, ma non deve essere interpretato come una soluzione universale per qualsiasi scenario Windows. Alcuni casi richiedono ancora smart card, certificati, PAM, jump server o architetture diverse.

  • Non usare FIDO2 come unica risposta per accessi RDP, VDI o login diretto sui server se lo scenario non e supportato.
  • Non estendere indiscriminatamente CKT agli account privilegiati senza valutare gruppi built-in, policy di replica password e modello Tier 0.
  • Non lasciare password legacy attive senza controllo: il passwordless perde valore se la password resta il fallback principale e attaccabile.
  • Non trascurare DNS, time sync e salute dei Domain Controller: Kerberos resta sensibile alla qualita dell’infrastruttura AD.
  • Non trattare la sicurezza cloud separatamente da AD. In ambienti ibridi, Identity Security e Assessment & Hardening Active Directory devono essere coordinati.

Account privilegiati, breakglass e recovery

Gli account amministrativi richiedono una progettazione distinta. FIDO2 e un metodo eccellente per account critici, ma non deve eliminare la capacita di recovery. Un tenant deve mantenere account breakglass documentati, monitorati e protetti con criteri coerenti. Allo stesso tempo, gli amministratori non devono usare account privilegiati per attivita quotidiane o per test di rollout utente.

Per questo la configurazione passwordless va collegata a un modello di ruoli, privilegi e account amministrativi. La pagina Nexsys su Microsoft Entra ID Tiering puo essere usata come approfondimento sul piano identita; la guida Breakglass in Entra ID resta invece il riferimento per continuita di accesso amministrativo in scenari critici.

Roadmap di implementazione consigliata

Fase

Obiettivo

Output

1. Assessment

Verificare tenant, Entra ID, metodi MFA, Conditional Access, AD, Kerberos, client e gruppi pilota. Collegare a Microsoft 365 Security Assessment e Assessment AD.

Gap list tecnica, prerequisiti, rischi, utenti pilota.

2. Design

Definire chiavi FIDO2, WHfB, criteri Intune/GPO, gruppi, recovery, breakglass, rollout e rollback.

Documento di architettura e piano operativo.

3. Configurazione

Creare oggetto AzureADKerberos, abilitare metodi Entra, configurare policy client e Conditional Access.

Tenant e dominio pronti per pilota controllato.

4. Pilot

Validare login passwordless, accesso file share, applicazioni Kerberos, VPN, recovery e supporto helpdesk.

Esiti test, anomalie, correzioni e decisione go/no-go.

5. Rollout

Distribuire per gruppi progressivi, monitorando registrazioni, ticket, incidenti e fallback.

Rollout controllato e misurabile.

6. Governance

Audit periodico metodi di autenticazione, chiavi, account privilegiati, ticket Kerberos e compliance dispositivi.

Controllo continuativo e miglioramento della postura.

 

Come Nexsys supporta il progetto

Nexsys supporta aziende e reparti IT nella progettazione e implementazione di accessi passwordless in ambienti Microsoft 365, Entra ID e Active Directory. L’intervento puo partire da un assessment puntuale o inserirsi in un percorso piu ampio di modernizzazione della sicurezza, con focus su identita, dispositivi, Conditional Access, hardening AD e formazione tecnica del personale IT.

L’obiettivo non e abilitare una singola opzione, ma rendere operativo un modello di accesso passwordless che riduca il rischio di furto credenziali e mantenga la compatibilita con le risorse aziendali ancora basate su Active Directory.

Per valutare l’adozione di FIDO2 e Cloud Kerberos Trust nel tuo ambiente Microsoft, richiedi una consulenza tecnica Nexsys con analisi del tenant, del dominio Active Directory e dei dispositivi coinvolti.

FAQ

Cloud Kerberos Trust sostituisce Active Directory?

No. Cloud Kerberos Trust non sostituisce Active Directory e non elimina i Domain Controller. Permette a Microsoft Entra ID di partecipare al rilascio dei ticket necessari per l’accesso passwordless, ma autorizzazioni, ACL, gruppi e service ticket restano governati dall’infrastruttura AD on-premises.

FIDO2 permette di accedere ai file server aziendali senza password?

Si, se l’ambiente e configurato correttamente con Microsoft Entra Kerberos e Cloud Kerberos Trust. L’utente puo accedere a Windows con security key FIDO2 o metodo passwordless e ottenere SSO verso risorse Kerberos come file share SMB e applicazioni interne.

Serve ancora Entra Connect?

Nella maggior parte degli scenari ibridi si, perche gli utenti devono essere sincronizzati tra Active Directory e Microsoft Entra ID. La configurazione va verificata soprattutto se il tenant usa regole di sincronizzazione personalizzate o domini multipli.

FIDO2 funziona anche con RDP o VDI?

Non va dato per scontato. Gli scenari RDP, VDI, login diretto sui server ed “Esegui come” hanno limitazioni specifiche. In questi casi possono essere piu adatti certificati smart card, PAM, jump server o altri modelli di accesso privilegiato.

E meglio usare FIDO2 o Windows Hello for Business?

Dipende dallo scenario. FIDO2 hardware e indicato per account critici e utenti high-value. Windows Hello for Business e spesso piu adatto per utenti con PC aziendali gestiti. In molti progetti i due metodi convivono, con regole diverse per gruppi e ruoli.

Quali controlli vanno fatti prima del rollout?

Vanno verificati tenant Entra ID, metodi di autenticazione, Conditional Access, dispositivi gestiti, salute Active Directory, Domain Controller, DNS, time sync, supporto Kerberos AES, sincronizzazione identita e processo di recovery.