SharePoint on-premise: patch installata, archivi documentali aperti lo stesso. Come lo avrebbe governato CyberGrant

18 luglio 2025. Nessuna credenziale rubata. Nessun allegato aperto per errore. Nessun malware recapitato via mail. Solo una richiesta HTTP inviata a un server SharePoint raggiungibile da internet. Dieci giorni prima Microsoft aveva pubblicato la patch. Non è bastata.

Cosa portare a casa in 30 secondi

• Cosa portare a casa in 30 secondi

  • I server SharePoint Server on-premise (2016, 2019 e Subscription Edition, oltre alle versioni fuori supporto) sono stati colpiti da due zero-day, CVE-2025-53770 (CVSS 9.8) e CVE-2025-53771, in una campagna che i ricercatori hanno chiamato ToolShell. Le due falle aggiravano gli aggiornamenti che Microsoft aveva rilasciato l'8 luglio 2025 per vulnerabilità precedenti.
  • Tra le vittime confermate c'è la National Nuclear Security Administration, l'agenzia che custodisce l'arsenale nucleare statunitense, insieme ad altre articolazioni del Dipartimento dell'Energia, istituzioni governative europee e mediorientali, università e società del settore energetico.
  • L'attaccante non aveva bisogno di autenticarsi: una POST verso l'endpoint ToolPane e la deserializzazione del campo __VIEWSTATE bastavano per eseguire codice sul server. Nessuna password rubata, quindi nessuna autenticazione a più fattori da superare.
  • Il vero danno non è l'accesso, è la web shell che estrae le MachineKey di ASP.NET: con quelle chiavi, l'accesso sopravvive alla patch.
  • Secondo il Verizon DBIR 2026, lo sfruttamento delle vulnerabilità è oggi il primo vettore di accesso iniziale, al 31% contro il 20% dell'anno precedente. Solo il 26% delle vulnerabilità critiche in catalogo CISA KEV è stato rimediato interamente nel 2025, in calo dal 38%.
  • Dentro quelle librerie documentali i file erano archiviati in chiaro. Una piattaforma di collaborazione protegge il documento finché il documento resta sulla piattaforma. Quando cade la piattaforma, non resta niente addosso al file.

Cosa è successo davvero sui server SharePoint on-premise

La catena non era una sorpresa. Era stata dimostrata pubblicamente il 16 maggio 2025 sul palco del Pwn2Own di Berlino, dove un ricercatore di Viettel Cyber Security aveva combinato due vulnerabilità di SharePoint per ottenere esecuzione di codice remoto, incassando un premio da centomila dollari. L'8 luglio Microsoft chiude quelle due falle, CVE-2025-49706 (spoofing) e CVE-2025-49704 (esecuzione di codice remoto). Il fix esiste, è documentato, va installato.

Il 14 luglio una società di ricerca tedesca pubblica una riproduzione funzionante dell'exploit. Il 17 la patch è già superata: due nuove vulnerabilità, CVE-2025-53770 e CVE-2025-53771, aggirano gli aggiornamenti appena distribuiti. Dal 18 luglio lo sfruttamento è massivo. Dalla dimostrazione in gara all'attacco in rete sono passati due mesi. Dalla patch al bypass, nove giorni.

La meccanica è brutalmente semplice. L'attaccante invia una richiesta POST verso l'endpoint ToolPane.aspx mascherando l'header Referer, bypassa il controllo di autenticazione su IIS e forza la deserializzazione di un payload .NET malevolo nel campo __VIEWSTATE. Nessun nome utente, nessuna password, nessuna interazione umana. Il CSIRT Italia lo sintetizza così nel bollettino diffuso da ACN: deserializzazione di dati non attendibili, esecuzione di codice arbitrario da parte di un attaccante remoto non autenticato, punteggio CVSS 9.8.

Poi arriva il passaggio che trasforma un exploit in un problema di lungo periodo. Sul server viene scritta una web shell, nella maggior parte dei casi un file chiamato spinstall0.aspx, il cui unico compito è leggere e restituire le MachineKey di ASP.NET, cioè le chiavi di validazione e cifratura del ViewState.

Microsoft Threat Intelligence ha attribuito la campagna a tre attori legati alla Cina: Linen Typhoon, attivo dal 2012 sul furto di proprietà intellettuale verso governi, difesa e pianificazione strategica; Violet Typhoon, dedito dal 2015 allo spionaggio su ex funzionari pubblici, ONG, think tank, università, media, sanità e finanza; e Storm-2603, che dal 18 luglio ha usato le stesse vulnerabilità per distribuire il ransomware Warlock attraverso modifiche alle Group Policy.

La vulnerabilità riguardava esclusivamente le versioni installate on-premise. SharePoint Online in Microsoft 365 non era interessato. La platea esposta era comunque enorme: secondo la stima di Censys ripresa nella ricostruzione italiana dell'incidente, oltre 10.000 tra aziende e istituzioni risultavano a rischio.

Esposti e compromessi però sono due numeri diversi, ed è il secondo a contare. Eye Security, la società olandese che ha individuato per prima la campagna grazie a un alert EDR su un vecchio server SharePoint di un cliente, ha rilevato oltre 400 sistemi compromessi su più di 23.000 scansionati, rivedendo al rialzo il conteggio delle organizzazioni coinvolte da circa cento a oltre quattrocento nell'arco di pochi giorni.

Il 18 luglio lo sfruttamento raggiunge il Dipartimento dell'Energia statunitense. Tra le articolazioni colpite c'è la National Nuclear Security Administration, l'agenzia che progetta e custodisce l'arsenale nucleare americano e coordina la risposta alle emergenze radiologiche. Nella lista compaiono anche istituzioni governative europee e mediorientali, università e società del settore energetico. Le CVE finiscono nel catalogo KEV della CISA, cioè fra le vulnerabilità note e attivamente sfruttate.

Il 22 luglio Commissione europea, ENISA, CERT-EU e la rete dei CSIRT nazionali pubblicano una dichiarazione congiunta che chiede a tutte le organizzazioni, e in modo esplicito ai soggetti che rientrano nel perimetro NIS2, di valutare l'esposizione al più presto.

Perché la patch non ha chiuso l'incidente

Qui sta il punto che rende questo caso un modello, e non l'ennesima CVE critica.

Le MachineKey non sono un dato qualsiasi. Sono il materiale crittografico con cui il server firma e cifra il ViewState. Chi le possiede può forgiare payload __VIEWSTATE perfettamente validi e continuare a eseguire comandi sul server anche dopo l'installazione dell'aggiornamento. La patch chiude la porta d'ingresso mentre l'attaccante ha già duplicato le chiavi.

È esattamente per questo che ACN, nel proprio bollettino, non si limita a raccomandare l'aggiornamento e aggiunge tre azioni: monitorare e bloccare le richieste POST verso ToolPane.aspx con valori anomali nel campo __VIEWSTATE, verificare che AMSI sia attivo, procedere con la rotazione delle machine key di ASP.NET. Microsoft indica lo stesso percorso e aggiunge il riavvio di IIS su tutti i server.

Le organizzazioni che hanno solo patchato hanno chiuso una vulnerabilità e lasciato aperto un accesso.

Ora aggiungiamo la variabile tempo. Secondo l'IBM Cost of a Data Breach 2025, il tempo medio per identificare e contenere una violazione è sceso a 241 giorni, minimo degli ultimi nove anni. Le violazioni su dati conservati on-premise sono la categoria più rapida da risolvere e si fermano comunque a 217 giorni. Sette mesi. In quella finestra, gli attori di spionaggio leggono e portano via documenti, mentre gli attori ransomware preparano la cifratura.

Dove ha ceduto l'architettura di protezione del dato

Il punto di rottura tecnico è una vulnerabilità software, e su quella si interviene con patch management. Il punto di rottura strutturale è un altro, e non si chiude con nessun aggiornamento. Sono quattro le falle visibili.

Il repository documentale era esposto su internet come applicazione web. SharePoint on-premise nasce per centralizzare gestione e collaborazione sui documenti. Pubblicarlo verso l'esterno significa esporre il contenitore di tutta la conoscenza documentale aziendale a chiunque sappia inviare una richiesta HTTP. La superficie d'attacco non era un server qualsiasi: era l'archivio.

I documenti erano protetti dalla piattaforma, non da sé stessi. Permessi, gruppi, ereditarietà delle librerie: tutti controlli che vivono nel livello applicativo. Compromesso quel livello con privilegi SYSTEM, i controlli non vengono aggirati, semplicemente smettono di applicarsi. Il file, sotto, è un file leggibile.

Il perimetro autorizzativo non aveva segmentazione utile. Un singolo server compromesso dava visibilità su intere raccolte di siti. Come nel caso FICOBA, il raggio della compromissione non è stato limitato dalla sensibilità del dato, ma solo dalla portata dell'accesso ottenuto.

Mancava la fotografia di cosa ci fosse dentro. Dopo un incidente di questo tipo la domanda del board, del legale e dell'autorità è sempre la stessa: quali documenti sono stati esposti, quali contenevano dati personali, quali segreti industriali, quali contratti sotto NDA. Senza classificazione automatica, la risposta si costruisce a mano nelle settimane successive, e resta una stima.

Il contesto italiano rende la domanda meno teorica. Il Rapporto Clusit 2026 colloca lo sfruttamento delle vulnerabilità al secondo posto tra le tecniche di attacco rilevate nel 2025, con il 16,5% del campione e una crescita del 65% rispetto all'anno precedente.

Isolare i server e migrare al cloud è stata la risposta giusta?

La reazione della maggior parte delle organizzazioni colpite è stata rapida e ragionevole: staccare i server SharePoint on-premise dalla rete pubblica, accelerare la migrazione verso l'architettura cloud, rendere obbligatoria l'autenticazione a più fattori.

Tre misure sensate, che risolvono tre problemi diversi da quello che conta.

L'isolamento riduce l'esposizione, non l'accesso già ottenuto. Chi aveva copiato le machine key prima del distacco conserva la capacità di firmare richieste valide. Su un server tornato raggiungibile dopo la bonifica, senza rotazione delle chiavi, quel materiale è ancora spendibile.

La migrazione al cloud sposta la responsabilità della patch, non il modello di protezione. Su SharePoint Online l'aggiornamento lo gestisce Microsoft, ed è un vantaggio reale. Ma il documento resta protetto dai permessi della piattaforma, non da sé stesso, e continua a uscire in chiaro appena qualcuno lo scarica. Cambia chi tiene la chiave di casa, non cosa c'è dentro le stanze.

L'autenticazione a più fattori, in questo caso specifico, non c'entra. L'exploit era pre-autenticazione. Nessuna credenziale rubata, nessuna sessione dirottata, nessun secondo fattore da superare: una richiesta HTTP verso un endpoint pubblico. L'MFA è una misura necessaria, e sarebbe servita contro il movimento laterale successivo, ma presentarla come risposta a questo vettore significa aver letto l'incidente al livello sbagliato.

Il punto è che tutte e tre le misure lavorano sull'accesso. Nessuna lavora sul dato. E la cifratura del contenuto, va detto, non richiede di spostare niente: come abbiamo spiegato in Cifrare i file su SharePoint senza migrazione, i documenti possono restare esattamente dove sono oggi.

Perché il DLP perimetrale non avrebbe cambiato l'esito

Nessun firewall si attiva su una richiesta HTTP legittima verso una porta che deve restare aperta. Nessun DLP di rete blocca l'esfiltrazione se il processo che legge i file è w3wp.exe, cioè il worker di IIS che serve SharePoint. Nessun controllo di uscita interviene quando l'attaccante ha privilegi SYSTEM sul server che ospita i documenti.

Il DLP tradizionale sorveglia le vie di fuga. Qui non c'è stata una via di fuga: c'è stato un cambio di proprietario del contenitore. È lo stesso meccanismo che abbiamo descritto in DLP tradizionale obsoleto, applicato a un archivio documentale invece che a un endpoint.

La domanda corretta non è "come impedisco l'accesso al server". È "cosa resta in mano a chi ottiene il server". Non si protegge l'uscita, si protegge il file alla nascita.

La piattaforma CyberGrant si affianca alla dotazione Microsoft esistente, non la sostituisce, e agisce su questo secondo livello.

Il Connector CyberGrant per SharePoint: la protezione resta nella libreria

Il Connector CyberGrant per SharePoint non è un archivio alternativo. È uno strato di cifratura che vive dentro le librerie SharePoint e OneDrive già esistenti: nessuna migrazione, nessuna modifica alle policy di permesso configurate negli anni, nessun cambio di abitudini per chi lavora sui documenti. Le regole si definiscono per sito o per cartella, e da quel momento i file caricati in quelle aree vengono cifrati con CRYSTALS-Kyber, l'algoritmo riconosciuto dal NIST come standard post-quantum (FIPS 203, ML-KEM, agosto 2024).

Tradotto su questo scenario: l'attaccante ottiene comunque privilegi SYSTEM sul server, ma nella libreria trova blocchi cifrati. Il punto architetturale però è più netto. Il Connector è progettato per escludere dall'accesso anche l'amministratore del tenant Azure, quindi chi conquista privilegi amministrativi sulla piattaforma si ritrova nella stessa posizione dell'admin: fuori. Non è una configurazione da attivare, è il modello di minaccia da cui il prodotto parte.

Tre dettagli pesano in modo specifico su questo caso.

Tutti i formati, non solo Office. Le vittime erano enti governativi, università e società energetiche: dentro quelle librerie c'erano PDF di progetto, immagini, file CAD, sorgenti software. Microsoft Purview cifra i file Office e sugli altri formati cambia l'estensione, un JPEG diventa PJPEG, rendendoli inapribili con le applicazioni native. Il Connector cifra qualsiasi formato mantenendo l'estensione originale, quindi non lascia scoperta la parte dell'archivio che non è Word o Excel. Il confronto completo fra i due modelli di protezione, con il dettaglio su formati, estensioni e accesso dell'amministratore, è in SharePoint non cifra i tuoi file, e Purview non fa quello che pensi.

Nessuna copia in chiaro sul disco. Chi apre un file cifrato in locale lo fa tramite RemoteGrant: il documento viene decifrato in memoria e non lascia copie temporanee sul filesystem. Su un server compromesso, le copie temporanee sono la prima cosa che un attaccante va a cercare.

Nemmeno Copilot legge quello che è cifrato. Copilot e gli altri assistenti AI indicizzano le librerie SharePoint per rispondere alle domande degli utenti: leggono i documenti come li leggerebbe chiunque abbia accesso alla piattaforma. Su un file protetto dal Connector trovano testo cifrato e metadati, mai il contenuto. E la protezione non si ferma al confine del tenant: con FileGrant il file resta cifrato ovunque venga copiato, inoltrato o caricato, quindi nessun sistema di AI, che sia Copilot, ChatGPT o un modello di terze parti, ne legge il contenuto. Un documento che esce cifrato non entra come testo leggibile in nessun modello. È una scelta di governance, non un effetto collaterale: la copertura si definisce per sito o per cartella, quindi si decide quali librerie restano interrogabili dall'AI aziendale e quali devono restare opache.

Vale la pena fermarsi un secondo su questo, perché è lo stesso principio che regge davanti a ToolShell. Un indicizzatore autorizzato e un attaccante con privilegi SYSTEM fanno esattamente la stessa cosa: leggono la libreria. Se il contenuto è cifrato dentro il file, nessuno dei due ottiene testo. La protezione dall'ingestione AI e la protezione dall'esfiltrazione non sono due misure diverse, sono la stessa misura vista da due lati.

Fuori dalla libreria vale la logica di FileGrant. Il file condiviso esce in formato Lock&Go, cifrato anche fuori dalla piattaforma, con divieto di download, blocco della cattura schermo e revoca dell'accesso dopo la condivisione. La condivisione verso un esterno parte con un clic destro da SharePoint, senza creare un utente Azure. Le chiavi master restano nell'infrastruttura del cliente in configurazione a conoscenza zero, non sul server esposto.

Un archivio esfiltrato in chiaro è un incidente senza data di chiusura, perché quei documenti restano leggibili per sempre. Un archivio esfiltrato cifrato è un problema di disponibilità, non di riservatezza. Vale anche per la logica "harvest now, decrypt later": chi archivia oggi materiale cifrato sperando di decifrarlo con la potenza di calcolo di domani trova, davanti, un algoritmo progettato per quello scenario. Su questo punto abbiamo scritto un approfondimento sugli obblighi europei in materia di crittografia post-quantum.

AIGrant: sapere prima cosa c'è dentro le librerie

Il punto cieco di questo incidente, per chi lo ha subito, è stato l'inventario. Migliaia di documenti, decine di raccolte di siti, nessuna classificazione affidabile del contenuto.

AIGrant è l'AI privata on-premise di CyberGrant: indicizza, analizza e classifica automaticamente i documenti in base al contenuto, applica tag di riservatezza, segrega per reparto in comparti stagni, traccia chi accede a cosa e segnala pattern di consultazione anomali per volume, orario o provenienza. I dati non lasciano mai l'infrastruttura aziendale, e ogni interazione è loggata.

Gli effetti concreti sono due. Il primo è la segmentazione: anche con il server compromesso, la visibilità utile si riduce al perimetro classificato, invece di coincidere con l'intero archivio. Il secondo è la ricostruzione: la notifica ex art. 33 GDPR e la segnalazione di incidente prevista dalla NIS2 si fondano su un elenco di documenti classificati, non su una stima costruita a posteriori. Su come questo si incastra nel sistema di gestione abbiamo scritto in NIS2 e GDPR: sistema di gestione e modello organizzativo integrati.

Vale la pena aggiungere il livello endpoint. Nella catena di Storm-2603 il server compromesso è stato solo il punto di partenza: Mimikatz su LSASS per estrarre credenziali, PsExec e Impacket per il movimento laterale, Defender disabilitato via registro. RemoteGrant agisce esattamente lì, con cifratura trasparente sui file locali, controllo di clipboard e supporti rimovibili, protezione dalla cattura schermo e regole di accesso per range IP.

Lo scenario alternativo con CyberGrant attivo

• L'exploit su SharePoint riesce comunque: la vulnerabilità è nel prodotto Microsoft, e nessun layer aggiuntivo la elimina. Cambia cosa l'attaccante trova sul disco.
• I documenti nelle librerie coperte dal Connector sono cifrati con CRYSTALS-Kyber, in qualsiasi formato. L'esfiltrazione massiva produce materiale illeggibile, non un archivio pronto per lo spionaggio industriale.
• I privilegi amministrativi sulla piattaforma non aprono i file: il Connector esclude dall'accesso anche l'amministratore del tenant, e le chiavi master restano on-premise, fuori dal server esposto.
• Nessuna copia temporanea in chiaro sul filesystem del server, perché la decifratura avviene in memoria.
• Nessun sistema di indicizzazione automatica ottiene il contenuto in chiaro, né Copilot dentro il tenant né un modello di terze parti dopo che il file è uscito.
• La classificazione automatica dice, il giorno stesso, quali documenti erano nel perimetro compromesso e quali categorie di dati contenevano.
• L'audit trail granulare rende la notifica dell'incidente un elenco di fatti verificabili, non una ricostruzione approssimata a distanza di settimane.

CyberGrant non elimina i rischi. Li trasforma in controllo e consapevolezza.

Cosa cambia per chi decide

Per il CISO.

1. Il raggio di compromissione si misura sul contenuto, non sull'host. Contare i server esposti è vulnerability management. Sapere quali documenti erano leggibili su quei server è gestione del rischio. Sono due esercizi diversi, e il secondo quasi mai è pronto quando serve.
2. Patchare non è contenere. Questo caso dimostra che una compromissione può sopravvivere alla remediation quando l'attaccante porta via materiale crittografico. Rotazione delle chiavi, riavvio dei servizi e caccia agli indicatori sono parte della patch, non un passaggio successivo facoltativo.
3. La finestra di detection è ancora misurata in mesi. Con 217 giorni medi anche nello scenario più rapido, secondo IBM 2025, la domanda operativa non è se l'attaccante entrerà. È cosa può fare del dato nei sette mesi in cui non lo vedi.

Per il CIO e il CTO.

1. On-premise contro cloud non è l'asse giusto della decisione. SharePoint Online non era vulnerabile a questa CVE, e la migrazione resta una scelta difendibile sul piano della gestione delle patch. Non lo è sul piano della protezione del dato: in entrambi i modelli la sicurezza del documento è una proprietà della piattaforma, e finisce nel momento in cui il file viene scaricato.
2. La protezione va aggiunta al livello giusto, senza rifare l'infrastruttura. La dotazione Microsoft resta dov'è. Il Connector CyberGrant per SharePoint lavora dentro le librerie esistenti: niente migrazione dei documenti, niente ridefinizione dei permessi, autenticazione Microsoft già integrata. Aggiunge cifratura persistente su tutti i formati, esclusione dell'admin di tenant, revoca dopo la condivisione e audit trail sul documento.
3. La governance dell'AI passa dalla stessa leva. I documenti che non devono finire in un indice restano cifrati anche per Copilot, dentro e fuori il tenant, e la copertura si decide per sito o per cartella. Sul fronte opposto, AIGrant non rimpiazza Copilot: presidia il caso in cui serve un assistente che legga davvero i documenti, ma senza che il dato esca dall'azienda.

Domande frequenti

Che cos'è la vulnerabilità ToolShell di SharePoint?

ToolShell è il nome dato alla campagna di attacchi che nel luglio 2025 ha sfruttato due vulnerabilità zero-day di Microsoft SharePoint Server on-premise: CVE-2025-53770, esecuzione di codice remoto con punteggio CVSS 9.8 causata dalla deserializzazione di dati non attendibili nel framework ASP.NET, e CVE-2025-53771, che aggirava i fix rilasciati in precedenza. L'attaccante poteva eseguire codice sul server senza alcuna autenticazione, inviando una richiesta POST verso l'endpoint ToolPane.

Quante organizzazioni sono state colpite dall'attacco a SharePoint del 2025?

Eye Security, la società olandese che ha individuato per prima la campagna, ha rilevato oltre 400 sistemi compromessi su più di 23.000 server scansionati, rivedendo al rialzo il numero di organizzazioni coinvolte da circa cento a oltre quattrocento nell'arco di pochi giorni. Tra le vittime confermate figurano il Dipartimento dell'Energia statunitense e la National Nuclear Security Administration, l'agenzia che custodisce l'arsenale nucleare americano, oltre a istituzioni governative europee e mediorientali, università e società del settore energetico.

L'autenticazione a più fattori avrebbe fermato l'attacco?

No, non contro il vettore iniziale. Le vulnerabilità sfruttate consentivano l'esecuzione di codice sul server senza alcuna autenticazione: nessuna credenziale rubata, nessuna sessione da dirottare, quindi nessun secondo fattore da superare. L'MFA resta una misura necessaria, utile a contenere il movimento laterale nelle fasi successive dell'attacco, ma non è la risposta a una vulnerabilità pre-autenticazione su un servizio esposto a internet.

La patch di Microsoft ha risolto il problema?

Solo in parte. Dopo lo sfruttamento iniziale gli attaccanti installavano una web shell che estraeva le MachineKey di ASP.NET, cioè le chiavi con cui il server firma e cifra il ViewState. Con quelle chiavi l'accesso sopravvive all'installazione dell'aggiornamento. Sia Microsoft sia ACN indicano come passaggi necessari, oltre alla patch, la rotazione delle machine key, il riavvio di IIS e l'attivazione di AMSI in modalità completa.

SharePoint Online in Microsoft 365 era vulnerabile?

No. Le vulnerabilità riguardavano esclusivamente le versioni installate on-premise, cioè SharePoint Server 2016, 2019 e Subscription Edition, oltre alle edizioni fuori supporto. Questo elimina quella specifica CVE per chi usa il cloud Microsoft, ma non cambia il modello di protezione sottostante: anche in SharePoint Online la sicurezza del documento è una proprietà della piattaforma, non del file, e non accompagna il file dopo il download.

Un DLP tradizionale avrebbe fermato l'attacco a SharePoint?

No. Il DLP perimetrale e i controlli di rete intervengono sui canali di uscita, mentre in questo scenario l'attaccante ottiene privilegi elevati sul server che ospita i documenti e legge i file attraverso il processo legittimo di IIS. Non c'è un canale anomalo da bloccare. La protezione efficace è file-centric: cifratura applicata al documento alla creazione, che persiste anche quando l'infrastruttura è compromessa.

Microsoft Purview avrebbe protetto i documenti su SharePoint?

Solo in parte, e la parte scoperta è quella che conta in un incidente come questo. Purview cifra i file Office; sugli altri formati o non applica protezione oppure cambia l'estensione, e un JPEG diventa PJPEG, quindi non si apre più con le applicazioni native. In un archivio che contiene PDF di progetto, immagini, file CAD e sorgenti software, quella parte resta leggibile. C'è poi un secondo limite: con Purview l'amministratore del tenant Azure può aprire i file cifrati, mentre il Connector CyberGrant per SharePoint esclude anche l'admin, il che sposta la protezione al di fuori della portata di chi ottiene privilegi amministrativi sulla piattaforma.

Copilot può leggere i documenti cifrati su SharePoint?

No. Copilot e gli altri assistenti AI indicizzano le librerie SharePoint per rispondere agli utenti: su un file protetto dal Connector CyberGrant trovano testo cifrato e metadati, mai il contenuto. Lo stesso vale fuori dal tenant, perché con FileGrant il file resta cifrato ovunque venga copiato, inoltrato o caricato, quindi nessun sistema di AI, che sia Copilot, ChatGPT o un modello di terze parti, ne legge il contenuto. Un documento che esce cifrato non entra come testo leggibile in nessun modello. La copertura si definisce per sito o per cartella, quindi resta una decisione di governance quali librerie lasciare interrogabili dall'AI aziendale e quali no.

Cosa significa protezione file-centric per un repository documentale?

Significa che il documento è cifrato all'origine e resta cifrato ovunque si trovi: nella libreria SharePoint, sul disco del server, in una copia esfiltrata, sul dispositivo di un destinatario esterno. La chiave non risiede sul sistema che ospita il file. Chi ottiene il controllo del server ottiene blocchi di byte, non contenuti leggibili. La misura di sicurezza non è impedire l'accesso, è rendere inutile ciò che viene preso.

FileGrant sostituisce SharePoint o OneDrive?

No, e non è pensato per farlo. FileGrant si affianca alla dotazione Microsoft esistente e aggiunge il livello che quelle piattaforme non coprono: cifratura persistente con CRYSTALS-Kyber che resta attiva dopo il download, revoca dell'accesso a condivisione avvenuta, protezione anti-cattura schermo, blocco dello scraping da parte di AI pubbliche e audit trail granulare sul singolo documento.

Cosa chiede la NIS2 a chi subisce un incidente come questo?

La NIS2, recepita in Italia con il D.Lgs. 138/2024, impone ai soggetti essenziali e importanti la notifica degli incidenti significativi secondo tempistiche definite e misure di sicurezza proporzionate al rischio, tra cui cifratura, controllo degli accessi e tracciabilità. Nel caso dei server SharePoint la dichiarazione congiunta di Commissione europea, ENISA e CERT-EU ha chiesto esplicitamente ai soggetti in perimetro NIS2 di valutare rapidamente la propria esposizione. La capacità di dire quali documenti erano coinvolti, e non solo quali server, è ciò che rende la notifica fattuale.